IRC logs for #openrisc Saturday, 2014-05-24

--- Log opened Sat May 24 00:00:02 2014
stekernah, finally, a lockup that makes sense!08:26
stekern....well, all the prior made sense when I found the reason, but this makes sense from the beginning08:27
stekernso... the problem I've been having is that the timer is per-cpu, this is what we want for the clock-events, but for reading a raw timer value, this messes things up08:28
stekernI added a global simple free running timer, and now both cores are sitting and waiting for a spinlock to release instead... so probably I have to proof-read my spinlock implementations a bit.08:30
blueCmdstekern: could I ask you to install 'schroot' on your hardware and do schroot --help11:26
blueCmdfor me that doesn't work11:26
blueCmd(as in it just hangs)13:44
stekernblueCmd: works here:
stekern(and that's also a demonstration how "blasting fast" sshing to the hardware works ;))14:16
blueCmdstekern: wow, that's slower than in the simulator14:27
blueCmdstekern: is your rootfs an NFS share?14:28
stekernwhich "simulator"?14:55
stekernit's faster than or1ksim at least14:55
blueCmdstekern: sorry, or1ksim14:57
blueCmdwhen using ECDSA it wasn't that slow IIRC14:58
blueCmdbut I used authkeys also14:58
blueCmdalgorithms I assume14:59
stekernah, right15:03
stekernheh... it's not *that* slow actually, but I had nscd and apache2 running, eating up all the CPU15:06
stekernthat's more like it15:09
stekernblueCmd: I'm hacking together a quick-and-dirty dual-core soc for de0_nano now btw15:13
stekernthe spinlock thing was a dead end... so I need to get faster boots than 10-15 min to figure out what's going on15:14
blueCmdstekern: that's better!15:16
blueCmdnice with dual core for de0_nano15:16
blueCmd looks quite nice15:21
_franck_blueCmd: the bad thing is that USB, Ethernet, UART, Micro SD and 1GB DDR3 are on the HPS side15:25
_franck_you need to bridge them to the FPGA15:25
blueCmdah yes15:25
blueCmdthat sucks15:25
stekernthe DDR3 is no problem15:26
stekernall the other you can't just "bridge"15:26
_franck_this board is quite the same as the Sockit from arrow15:26
_franck_Ethernet ?15:28
blueCmdAh, uhm15:28
stekernyou have some nice expansion boards for that anyway ;)15:29
_franck_this one looks good. It's more expansive15:30
blueCmdToo little memory15:31
blueCmdI want something to run a permanent builder15:31
stekernblueCmd: is there something you can't do with the qemu-user setup?16:29
blueCmdstekern: yes, pthreads16:38
blueCmdI have some stuff to test with qemu-system before ruling it out completely, I think the ethernet controller there is quite slow, so it might be better to do ATA emulation16:39
wondiwsare there prebuilt images for OpenRISC for the DE2-115 by any chance?17:23
wondiwsI find quite a few documents about the toolchain for software development, but not so much documentation about building the hdl core etc.17:23
blueCmdwondiws: a co-worker to me wants to build that as well17:24
blueCmdsadly, I don't think there is one.17:24
blueCmdadding it to orpsoc systems should be simple though, a top-level file, wishbone layout and pin constraints I guess17:25
wondiwsI noticed there is one (and a guide) for the DE0-Nano, so I imagined there would be one for the DE2-115 as well :)17:25
blueCmdNope, nobody has made one17:27
wondiwsshould I get it to work i'll let u know ;)17:27
wondiwswhat does the "official" board cost actually?17:28
wondiwsthe OrSOC one17:28
_franck_if I had a de2-115, I would certainly not buy an Orsoc board17:30
blueCmdwondiws: there is no official board17:32
blueCmdde2-115 is an nice board and I'm thinking of getting one myself17:33
stekerncrap... it didn't work on first try...17:35
wondiwsok, let's get down to business, I read something like there's multiple cores/configurations to choose from?17:50
stekernhow do you mean?18:00
wondiwsnevermind, I think it will be clear to me shortly18:04
stekern2nd try, and it boots as long as in verilato18:04
wondiwsmor1kx, that's where I get the cpu source from?18:06
stekernyes, that's (one of) the cpu implementation(s)18:06
wondiwsoh, that brings me to the earlier question ;)18:06
stekernbut I'd suggest start of just bluntly copy the de0_nano port and modify it for your board18:07
stekern(try to build it as is first, so you know that works)18:07
wondiwsis this de0_nano port all-included? are all the sources needed in there?18:08
stekernno, but fusesoc (the build system) will fetch the sources for you18:12
stekernbut, everything you need to touch to modify it for your port is in the de0_nano directory18:13
stekern(well, ideally, at least ;))18:14
blueCmdstekern: what board is the 'de1' port?18:17
wondiwsDE1 I suppose18:19
wondiwsmight be more like my DE2 than the DE0 actually18:20
blueCmdso, that's a board?18:20
blueCmdwell, I would use de0_nano18:20
blueCmdsince both stekern and I use it and can vouch for that it's working18:21
blueCmd(when you get to the point to regenerate the wishbone interconnect you will have a problem with resizes I think, unless someone fixed that, just shout then)18:21
blueCmd((the issue is that the resize stage has been moved from the top level to the generated files but the top level file hasn't been updated, so the output of the wishbone generation will generate a total of 2 resizes)18:22
wondiwshow do I make fusesoc fetch the dependencies automatically then?18:23
wondiwscan't find core "jtag_tap"18:23
stekernyes, you can pick DE1 too18:27
stekern_franck_ can vouch for that that is working ;)18:28
_franck_de1 _is_ working :)18:33
wondiwsah, I can't build "in source"18:41
blueCmdpoke53281: I'm trying to get ATA to work for qemu-system. I had a look at your patches for or1ksim and have managed to get this output:
blueCmdI guess it has to do with the wrong state between the driver / adapter18:48
blueCmdstekern: I just uploaded a new libc with the gcc atomics used instead19:08
blueCmdstekern: let me know if you find any problems, hopefully it's faster19:08
stekernok, I'll give it a spin19:11
poke53281@blueCmd: Do you use just ATA or a controller?19:18
blueCmdpoke53281: in the dts? I use just ata like you did here:
poke53281Ok, so the CTL address have to be defined according to the ATA spec of QEMU.19:20
poke53281the 9e00010019:21
blueCmdI see19:21
blueCmd that is what I changed in qemu19:22
poke53281How did you change the QEMU code?19:22
poke53281Ok :)19:22
blueCmdit's mainly copy/paste from sh4 r2d19:22
poke53281Ok, using CF seem to be the best option.19:23
poke53281reg-shift 2 is also fine19:24
poke53281I don't know what this sysbus_mmio_map(busdev, 0, base); is doing. especially the second parameter.19:25
blueCmdneither do I :)19:26
blueCmdI did a very basic dig but didn't find out anything useful19:26
poke53281well the problem is, that the direct access to the ATA device is not so common. Usually you use a controller, and this specifies how ATA is accessed.19:27
poke53281Therefore you need this reg shift and have to define PIO-mode and the register position.19:27
poke53281DMA is of course not possible without a controller.19:28
poke53281But I can't see any obvious errors, The code you copied from sh4 seems to be fine.19:28
blueCmddo you see any problems using a controller?19:28
blueCmdthe reason I don't use one is that I don't want to add ISA or PCI19:29
poke53281No, I don't see a problem. But I am not sure which one supports dts. You don't have to implement ISA or PCI for this. The ATA-Generic driver is probably the easiest way. We should be focus on this before implementing a controller.19:31
blueCmdmakes sense19:31
blueCmdI guess I'll printf here and there in the MMIO IDE driver and see why it doesn't respond on the IDENTIFY thing then19:31
poke53281So, the error about the "IDENTIFY" problem is more or less the first command, which is send to the ATA-Device. Either the command was never received correctly or the interrupt was never triggered. I guess it is the first.19:32
poke53281Yes, just do a little bit debugging. I think the error should be trivial.19:34
poke53281Maybe you have to exchange the second parameter in the two sysbus_mmio_map callings19:35
poke53281"IDENTIFY" should work even without drives connected.19:38
blueCmdso things are happening at least19:40
blueCmdWIN_IDENTIFY = 0xEC also19:41
poke53281I am checking19:43
blueCmdhm setting IDE_CFATA as drive_kind might do something maybe19:44
poke53281"read addr=0x7"19:46
poke53281is this already shifted by two?19:46
poke53281Because with reg-shift of 2 the registers should have a distance of four bytes19:46
poke53281so is addr=x the registers addr or the memory address?19:47
blueCmdthe output is from DEBUG_IDE and from ide_ioport_read19:49
poke53281Ok, then it should be correct19:51
blueCmddatapoint: if I comment the failure of IDENTIFY out, it continues and detects 'sda' with gibberish name and size19:54
blueCmdso i'm thinking data writes qemu -> guest kernel is not working19:54
blueCmdso maybe the interrupt thing then19:55
poke53281the debug output does not tell me anything about the interrupt. According to my implementation the device has to trigger the interrupt after the idendity command is send.19:57
poke53281Maybe you should also print the debug messages for the interrupt controller.19:57
blueCmdright, it does that however19:57
blueCmdor it should do19:57
poke53281IDE: write addr=0x7 val=0xec19:58
poke53281This is the identiy call19:58
poke53281Ahh, Ok19:58
poke53281Special handling for compact flash devices.19:59
blueCmdIDE_HD is the default19:59
blueCmdI didn't see any difference when using IDE_CFATA19:59
poke53281Hmm, strange20:03
poke53281So, the kernel thinks it is a generic ATA device, not Compact Flash.   Interesting that there is a difference between those.20:04
poke53281But the QEMU code does not seem to differ between those two options. So, both should be compatible.20:05
poke53281Ok, I would suggest to check the interrupts first.20:06
blueCmdack, will do!20:06
blueCmdpoke53281: bingo20:08
poke53281Problem with QEMU I guess20:12
poke53281Maybe change the line to sysbus_connect_irq(busdev, 1, irq);20:13
blueCmdso apparently IDE_CMD_DISABLE_IRQ is set20:14
poke53281Hmm, maybe QEMU use this as default in order to make it easier for the controllers. That a hard drive can directly trigger a CPU interrupt is highly unusual.20:16
blueCmdIDE IDENTITY: kind: 020:18
blueCmd!!! IRQ RAISED20:18
blueCmdrandom: nonblocking pool is initialized20:18
blueCmdirq 15: nobody cared (try booting with the "irqpoll" option)20:18
poke53281Uhmm, maybe the interrupt is triggered before the driver is loaded.20:23
blueCmdwell, it did print IDE IDENTIFY20:25
blueCmdide: write control addr=0x0 val=0a20:33
blueCmdthat disables interrupt20:33
poke53281looks like the command is never send to my implementation of ATA.20:40
poke53281Ahh, Ok. Bit number is is the interrupt enable/disable bit.20:43
blueCmds/is is/0x02 is/ ?20:43
poke53281Yes, Ok. this could be used. I have also implemented it.20:44
poke53281Bit number 220:44
poke53281case 0xEC: // identify device20:45
poke53281            this.readbuffer = this.identifybuffer;20:45
poke53281            this.readbufferindex = 0;20:45
poke53281            this.readbuffermax = 256;20:45
poke53281            this.SR = ATA_SR_DRDY | ATA_SR_DSC | ATA_SR_DRQ;20:45
poke53281            if (!(this.DCR & ATA_DCR_IEN)) {20:45
poke53281                this.intdev.RaiseInterrupt(15);20:45
poke53281            }20:45
blueCmdlooks similiar20:45
poke53281Stupid question. Did you tell qemu to add a hard drive to the ATA-device? One, which supports ATA?20:47
blueCmd-hda test.img20:47
blueCmdthat's what I did20:47
poke53281ATA supports two drives. One registers tells him, if master,slave or both are available. Then he can mask one out and sends the identify command to one drive.20:48
poke53281So, at the moment I am a little bit puzzled. My implementation with the my Linux kernel version works. And I think that I followed the specification.20:57
stekernblueCmd: seems the whole board crashed when I tried to install the updated glibc20:58
blueCmdpoke53281: implementation as in or1ksim?20:59
blueCmdstekern: hm20:59
blueCmdstekern: how did you try to install it?20:59
poke53281First I  did it myself, than I changed or1ksim a little bit. But nothing special. Only to avoid the controller.21:00
poke53281So, the same kernel works for both.21:00
poke53281or1ksim and jor1k21:00
stekernapt-get install libc621:02
blueCmdstekern: my turn of saying "works for me" ;)21:07
blueCmdtry dist-upgrade21:07
blueCmdto be fair, I'm only testing in qemu-system  and qemu-user21:07
stekernno or1ksim?21:08
blueCmdI haven't tested with that no21:08
stekernI need to update my qemu...21:09
stekernI'll test with or1ksim too21:10
poke53281blueCmd: How do you solve the issue I described here:
poke53281do you use the sysroot option of qemu-user?21:13
blueCmdpoke53281: I don't use -L21:14
blueCmdthat's how I do21:14
blueCmdstekern: I get programs hanging with the new libc when running in qemu-system, but that might be because of the false l.swa/lwa21:16
stekernat least or1ksim fails to boot now too, but that might be due too halfbaked install21:22
blueCmdsorry about that21:22
blueCmdyou should be able to dpkg -x libc6*.deb initramfs/21:23
stekernah, well, it's not like it's a mission critical production system =)21:23
stekernI've got enough other boards to play with in the meantime21:24
stekernblueCmd: is this updated?21:27
blueCmdstekern: nope21:27
blueCmdI can update it21:27
stekernI didn't use that, just wondering21:27
stekernI can't even chroot into the initramfs now...21:28
blueCmdyeah, but you can use dpkg -x from your host system21:31
stekernhmm, yes, but that didn't help21:43
blueCmdreally? weird21:52
blueCmdlibc libc6 libc6-dev libc-dev are packages you might want to update as well I guess21:52
stekerncan you point me to them?21:52
stekernI just picked the ones in the cache, maybe they are borken there21:53
wondiwswith altera you can't use pll's with the "free" "web edition", right?22:05
wondiwsor you get "time_limited" or something...22:06
blueCmdI think you can, I'm pretty sure I have22:06
stekernyou can use plls22:07
stekerndidn't help using the ones from there neither22:07
stekernit stalls at: [....] Starting the hotplug events dispatcher: udevdsystemd-udevd[129]: starting version 20422:07
blueCmdstekern: - those should be the old ones I guess22:08
stekernwondiws: sorry, I switched topic after I answered your question22:08
blueCmdI wonder if that has something to do with memory barriers or something22:09
stekernbut why is it working for you?22:09
blueCmdit's only working in qemu-user22:09
stekerndoesn't it boot at all with qemu-system?22:09
blueCmdI can boot somewhat if I do init=/bin/bash22:09
blueCmdstekern: it hangs before "login" is to be executed or something like that22:10
stekernok...but for me it hangs long before that22:10
blueCmdit might be the same thing though22:11
blueCmdif you can, try booting with init=/bin/bash and play around22:11
stekerncopying back the old libc6_2.18-4_or1k.deb made it boot22:17
wondiwshow do I test my orpsoc-build if it has any life?22:41
blueCmdwondiws: bin/fusesoc build de2_11522:43
wondiwsI did, it was succesful22:44
wondiwsI uploaded it22:44
wondiwsbut now I suppose I have to have an executable image as well?22:44
blueCmdopenocd should be fine22:44
blueCmd has documentation how to use that22:44
wondiwsI got to install the toolchain as well I'm afraid...22:45
blueCmdwell, if you want to compile something :P22:45
blueCmdbut for openocd you don't need that22:45
wondiwsI first need to know if I can use my de2-115 board ofcourse22:46
wondiwsthen I'll install the toolchain with pleasure :)22:46
wondiwsbut the documentation uses or1k_generic.cfg, my openeocd directory which I pulled from openrisc github has no such file22:56
wondiwsI don't understand OpenOCD :S23:22
wondiws"received CRC not same as calculated CRC :S23:23
wondiwsblueCmd, you still here?23:53
--- Log closed Sun May 25 00:00:04 2014

Generated by 2.15.2 by Marius Gedminas - find it at!