--- Log opened Sat May 24 00:00:02 2014 | ||
stekern | ah, 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 beginning | 08:27 |
stekern | so... 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 up | 08:28 |
stekern | I 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 |
blueCmd | stekern: could I ask you to install 'schroot' on your hardware and do schroot --help | 11:26 |
blueCmd | for me that doesn't work | 11:26 |
blueCmd | (as in it just hangs) | 13:44 |
stekern | blueCmd: works here: https://asciinema.org/a/9764 | 14:16 |
stekern | (and that's also a demonstration how "blasting fast" sshing to the hardware works ;)) | 14:16 |
blueCmd | stekern: wow, that's slower than in the simulator | 14:27 |
blueCmd | stekern: is your rootfs an NFS share? | 14:28 |
stekern | yes | 14:55 |
stekern | which "simulator"? | 14:55 |
stekern | it's faster than or1ksim at least | 14:55 |
blueCmd | stekern: sorry, or1ksim | 14:57 |
blueCmd | when using ECDSA it wasn't that slow IIRC | 14:58 |
blueCmd | but I used authkeys also | 14:58 |
stekern | ECDSA? | 14:58 |
blueCmd | RSA/DSA/ECDSA | 14:59 |
blueCmd | algorithms I assume | 14:59 |
stekern | ah, right | 15:03 |
stekern | heh... it's not *that* slow actually, but I had nscd and apache2 running, eating up all the CPU | 15:06 |
stekern | https://asciinema.org/a/9765 | 15:09 |
stekern | that's more like it | 15:09 |
stekern | blueCmd: I'm hacking together a quick-and-dirty dual-core soc for de0_nano now btw | 15:13 |
stekern | the spinlock thing was a dead end... so I need to get faster boots than 10-15 min to figure out what's going on | 15:14 |
blueCmd | stekern: that's better! | 15:16 |
blueCmd | nice with dual core for de0_nano | 15:16 |
blueCmd | http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=836&PartNo=1 looks quite nice | 15:21 |
_franck_ | blueCmd: the bad thing is that USB, Ethernet, UART, Micro SD and 1GB DDR3 are on the HPS side | 15:25 |
_franck_ | you need to bridge them to the FPGA | 15:25 |
blueCmd | ah yes | 15:25 |
blueCmd | that sucks | 15:25 |
stekern | the DDR3 is no problem | 15:26 |
stekern | all the other you can't just "bridge" | 15:26 |
blueCmd | http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830&PartNo=1 | 15:26 |
_franck_ | this board is quite the same as the Sockit from arrow | 15:26 |
_franck_ | Ethernet ? | 15:28 |
blueCmd | Ah, uhm | 15:28 |
stekern | you have some nice expansion boards for that anyway ;) | 15:29 |
blueCmd | Yeah | 15:29 |
_franck_ | http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=139&No=502&PartNo=2 | 15:30 |
_franck_ | this one looks good. It's more expansive | 15:30 |
blueCmd | Too little memory | 15:31 |
blueCmd | I want something to run a permanent builder | 15:31 |
stekern | blueCmd: is there something you can't do with the qemu-user setup? | 16:29 |
blueCmd | stekern: yes, pthreads | 16:38 |
blueCmd | I 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 emulation | 16:39 |
wondiws | are there prebuilt images for OpenRISC for the DE2-115 by any chance? | 17:23 |
wondiws | I find quite a few documents about the toolchain for software development, but not so much documentation about building the hdl core etc. | 17:23 |
blueCmd | wondiws: a co-worker to me wants to build that as well | 17:24 |
blueCmd | sadly, I don't think there is one. | 17:24 |
blueCmd | adding it to orpsoc systems should be simple though, a top-level file, wishbone layout and pin constraints I guess | 17:25 |
wondiws | I 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 |
blueCmd | Nope, nobody has made one | 17:27 |
wondiws | should I get it to work i'll let u know ;) | 17:27 |
wondiws | what does the "official" board cost actually? | 17:28 |
wondiws | the OrSOC one | 17:28 |
_franck_ | if I had a de2-115, I would certainly not buy an Orsoc board | 17:30 |
blueCmd | wondiws: there is no official board | 17:32 |
blueCmd | de2-115 is an nice board and I'm thinking of getting one myself | 17:33 |
stekern | crap... it didn't work on first try... | 17:35 |
wondiws | ok, let's get down to business, I read something like there's multiple cores/configurations to choose from? | 17:50 |
stekern | how do you mean? | 18:00 |
wondiws | nevermind, I think it will be clear to me shortly | 18:04 |
stekern | 2nd try, and it boots as long as in verilato | 18:04 |
stekern | r | 18:04 |
wondiws | mor1kx, that's where I get the cpu source from? | 18:06 |
stekern | yes, that's (one of) the cpu implementation(s) | 18:06 |
wondiws | oh, that brings me to the earlier question ;) | 18:06 |
stekern | but I'd suggest start of just bluntly copy the de0_nano port and modify it for your board | 18:07 |
stekern | (try to build it as is first, so you know that works) | 18:07 |
stekern | https://github.com/openrisc/orpsoc-cores/tree/master/systems/de0_nano | 18:08 |
wondiws | is this de0_nano port all-included? are all the sources needed in there? | 18:08 |
stekern | no, but fusesoc (the build system) will fetch the sources for you | 18:12 |
stekern | https://github.com/olofk/fusesoc | 18:12 |
stekern | but, everything you need to touch to modify it for your port is in the de0_nano directory | 18:13 |
stekern | (well, ideally, at least ;)) | 18:14 |
blueCmd | stekern: what board is the 'de1' port? | 18:17 |
wondiws | DE1 I suppose | 18:19 |
wondiws | might be more like my DE2 than the DE0 actually | 18:20 |
blueCmd | so, that's a board? | 18:20 |
blueCmd | ok | 18:20 |
blueCmd | well, I would use de0_nano | 18:20 |
blueCmd | since both stekern and I use it and can vouch for that it's working | 18: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 |
wondiws | how do I make fusesoc fetch the dependencies automatically then? | 18:23 |
wondiws | can't find core "jtag_tap" | 18:23 |
stekern | yes, you can pick DE1 too | 18:27 |
stekern | _franck_ can vouch for that that is working ;) | 18:28 |
stekern | wondiws: http://opencores.org/or1k/ORPSoC#Set_Up | 18:29 |
_franck_ | de1 _is_ working :) | 18:33 |
wondiws | ah, I can't build "in source" | 18:41 |
blueCmd | poke53281: 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: http://797239a7a902c9ef.paste.se/ | 18:48 |
blueCmd | I guess it has to do with the wrong state between the driver / adapter | 18:48 |
blueCmd | stekern: I just uploaded a new libc with the gcc atomics used instead | 19:08 |
blueCmd | stekern: let me know if you find any problems, hopefully it's faster | 19:08 |
stekern | ok, I'll give it a spin | 19:11 |
poke53281 | @blueCmd: Do you use just ATA or a controller? | 19:18 |
blueCmd | poke53281: in the dts? I use just ata like you did here: https://github.com/s-macke/jor1k-toolchain-builder/blob/master/patches/or1ksim.dts | 19:19 |
poke53281 | Ok, so the CTL address have to be defined according to the ATA spec of QEMU. | 19:20 |
poke53281 | the 9e000100 | 19:21 |
blueCmd | I see | 19:21 |
blueCmd | http://750f786930817ae5.paste.se/ that is what I changed in qemu | 19:22 |
poke53281 | How did you change the QEMU code? | 19:22 |
poke53281 | Ok :) | 19:22 |
blueCmd | it's mainly copy/paste from sh4 r2d | 19:22 |
poke53281 | Ok, using CF seem to be the best option. | 19:23 |
poke53281 | reg-shift 2 is also fine | 19:24 |
poke53281 | I don't know what this sysbus_mmio_map(busdev, 0, base); is doing. especially the second parameter. | 19:25 |
blueCmd | neither do I :) | 19:26 |
blueCmd | I did a very basic dig but didn't find out anything useful | 19:26 |
poke53281 | well 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 |
blueCmd | yes | 19:27 |
poke53281 | Therefore you need this reg shift and have to define PIO-mode and the register position. | 19:27 |
poke53281 | DMA is of course not possible without a controller. | 19:28 |
poke53281 | But I can't see any obvious errors, The code you copied from sh4 seems to be fine. | 19:28 |
blueCmd | do you see any problems using a controller? | 19:28 |
blueCmd | the reason I don't use one is that I don't want to add ISA or PCI | 19:29 |
poke53281 | No, 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 |
blueCmd | ack. | 19:31 |
blueCmd | makes sense | 19:31 |
blueCmd | I guess I'll printf here and there in the MMIO IDE driver and see why it doesn't respond on the IDENTIFY thing then | 19:31 |
poke53281 | So, 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 |
poke53281 | Yes, just do a little bit debugging. I think the error should be trivial. | 19:34 |
poke53281 | Maybe you have to exchange the second parameter in the two sysbus_mmio_map callings | 19:35 |
poke53281 | "IDENTIFY" should work even without drives connected. | 19:38 |
blueCmd | http://8a874081041606eb.paste.se/ | 19:40 |
blueCmd | so things are happening at least | 19:40 |
blueCmd | WIN_IDENTIFY = 0xEC also | 19:41 |
poke53281 | I am checking | 19:43 |
blueCmd | hm setting IDE_CFATA as drive_kind might do something maybe | 19:44 |
poke53281 | "read addr=0x7" | 19:46 |
poke53281 | is this already shifted by two? | 19:46 |
poke53281 | Because with reg-shift of 2 the registers should have a distance of four bytes | 19:46 |
poke53281 | so is addr=x the registers addr or the memory address? | 19:47 |
blueCmd | the output is from DEBUG_IDE and from ide_ioport_read | 19:49 |
poke53281 | Ok, then it should be correct | 19:51 |
blueCmd | datapoint: if I comment the failure of IDENTIFY out, it continues and detects 'sda' with gibberish name and size | 19:54 |
poke53281 | hehe | 19:54 |
blueCmd | so i'm thinking data writes qemu -> guest kernel is not working | 19:54 |
blueCmd | so maybe the interrupt thing then | 19:55 |
poke53281 | the 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 |
poke53281 | Maybe you should also print the debug messages for the interrupt controller. | 19:57 |
blueCmd | right, it does that however | 19:57 |
blueCmd | or it should do | 19:57 |
poke53281 | IDE: write addr=0x7 val=0xec | 19:58 |
poke53281 | This is the identiy call | 19:58 |
blueCmd | http://878177e7dcee93cd.paste.se/ | 19:58 |
poke53281 | Ahh, Ok | 19:58 |
poke53281 | IDE_CFATA | 19:58 |
poke53281 | Special handling for compact flash devices. | 19:59 |
blueCmd | IDE_HD is the default | 19:59 |
blueCmd | I didn't see any difference when using IDE_CFATA | 19:59 |
poke53281 | Hmm, strange | 20:03 |
poke53281 | So, the kernel thinks it is a generic ATA device, not Compact Flash. Interesting that there is a difference between those. | 20:04 |
poke53281 | But the QEMU code does not seem to differ between those two options. So, both should be compatible. | 20:05 |
poke53281 | Ok, I would suggest to check the interrupts first. | 20:06 |
blueCmd | ack, will do! | 20:06 |
blueCmd | poke53281: http://7d1b68b98a789974.paste.se/ bingo | 20:08 |
poke53281 | Problem with QEMU I guess | 20:12 |
poke53281 | Maybe change the line to sysbus_connect_irq(busdev, 1, irq); | 20:13 |
poke53281 | Trial&Error | 20:13 |
blueCmd | so apparently IDE_CMD_DISABLE_IRQ is set | 20:14 |
poke53281 | Hmm, 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 |
blueCmd | IDE IDENTITY: kind: 0 | 20:18 |
blueCmd | !!! IRQ RAISED | 20:18 |
blueCmd | random: nonblocking pool is initialized | 20:18 |
blueCmd | irq 15: nobody cared (try booting with the "irqpoll" option) | 20:18 |
poke53281 | Uhmm, maybe the interrupt is triggered before the driver is loaded. | 20:23 |
blueCmd | well, it did print IDE IDENTIFY | 20:25 |
blueCmd | ide: write control addr=0x0 val=0a | 20:33 |
blueCmd | that disables interrupt | 20:33 |
poke53281 | looks like the command is never send to my implementation of ATA. | 20:40 |
poke53281 | Ahh, Ok. Bit number is is the interrupt enable/disable bit. | 20:43 |
blueCmd | s/is is/0x02 is/ ? | 20:43 |
poke53281 | Yes, Ok. this could be used. I have also implemented it. | 20:44 |
poke53281 | yes | 20:44 |
poke53281 | Bit number 2 | 20:44 |
poke53281 | case 0xEC: // identify device | 20: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 |
blueCmd | looks similiar | 20:45 |
poke53281 | Stupid question. Did you tell qemu to add a hard drive to the ATA-device? One, which supports ATA? | 20:47 |
blueCmd | -hda test.img | 20:47 |
blueCmd | that's what I did | 20:47 |
poke53281 | ATA 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 |
blueCmd | right | 20:49 |
poke53281 | So, 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 |
stekern | blueCmd: seems the whole board crashed when I tried to install the updated glibc | 20:58 |
blueCmd | poke53281: implementation as in or1ksim? | 20:59 |
blueCmd | stekern: hm | 20:59 |
blueCmd | stekern: how did you try to install it? | 20:59 |
poke53281 | First I did it myself, than I changed or1ksim a little bit. But nothing special. Only to avoid the controller. | 21:00 |
poke53281 | So, the same kernel works for both. | 21:00 |
poke53281 | or1ksim and jor1k | 21:00 |
blueCmd | hm | 21:01 |
stekern | apt-get install libc6 | 21:02 |
blueCmd | stekern: my turn of saying "works for me" ;) | 21:07 |
blueCmd | try dist-upgrade | 21:07 |
blueCmd | to be fair, I'm only testing in qemu-system and qemu-user | 21:07 |
stekern | no or1ksim? | 21:08 |
blueCmd | I haven't tested with that no | 21:08 |
stekern | I need to update my qemu... | 21:09 |
stekern | I'll test with or1ksim too | 21:10 |
blueCmd | thanks | 21:10 |
poke53281 | blueCmd: How do you solve the issue I described here: https://bugs.launchpad.net/qemu/+bug/1245703 | 21:12 |
poke53281 | do you use the sysroot option of qemu-user? | 21:13 |
blueCmd | poke53281: I don't use -L | 21:14 |
blueCmd | https://github.com/bluecmd/or1k-debian/blob/master/README | 21:14 |
blueCmd | that's how I do | 21:14 |
blueCmd | stekern: I get programs hanging with the new libc when running in qemu-system, but that might be because of the false l.swa/lwa | 21:16 |
stekern | mmmm... | 21:21 |
stekern | at least or1ksim fails to boot now too, but that might be due too halfbaked install | 21:22 |
stekern | -o | 21:22 |
blueCmd | sorry about that | 21:22 |
blueCmd | you should be able to dpkg -x libc6*.deb initramfs/ | 21:23 |
stekern | ah, well, it's not like it's a mission critical production system =) | 21:23 |
blueCmd | :P | 21:23 |
stekern | I've got enough other boards to play with in the meantime | 21:24 |
stekern | blueCmd: is this updated? | 21:27 |
stekern | http://openrisc.debian.net/qemu-or1k-static | 21:27 |
blueCmd | stekern: nope | 21:27 |
blueCmd | I can update it | 21:27 |
stekern | I didn't use that, just wondering | 21:27 |
stekern | I can't even chroot into the initramfs now... | 21:28 |
blueCmd | yeah, but you can use dpkg -x from your host system | 21:31 |
stekern | hmm, yes, but that didn't help | 21:43 |
blueCmd | really? weird | 21:52 |
blueCmd | libc libc6 libc6-dev libc-dev are packages you might want to update as well I guess | 21:52 |
stekern | can you point me to them? | 21:52 |
stekern | I just picked the ones in the cache, maybe they are borken there | 21:53 |
blueCmd | http://openrisc.debian.net/pool/main/e/eglibc/ | 21:53 |
wondiws | with altera you can't use pll's with the "free" "web edition", right? | 22:05 |
wondiws | or you get "time_limited" or something... | 22:06 |
blueCmd | I think you can, I'm pretty sure I have | 22:06 |
stekern | you can use plls | 22:07 |
stekern | didn't help using the ones from there neither | 22:07 |
wondiws | ? | 22:07 |
stekern | it stalls at: [....] Starting the hotplug events dispatcher: udevdsystemd-udevd[129]: starting version 204 | 22:07 |
blueCmd | stekern: http://openrisc.debian.net/tmp/rebuilt-libc/ - those should be the old ones I guess | 22:08 |
stekern | wondiws: sorry, I switched topic after I answered your question | 22:08 |
blueCmd | I wonder if that has something to do with memory barriers or something | 22:09 |
stekern | but why is it working for you? | 22:09 |
blueCmd | it's only working in qemu-user | 22:09 |
stekern | doesn't it boot at all with qemu-system? | 22:09 |
blueCmd | I can boot somewhat if I do init=/bin/bash | 22:09 |
stekern | aha | 22:10 |
blueCmd | stekern: it hangs before "login" is to be executed or something like that | 22:10 |
stekern | ok...but for me it hangs long before that | 22:10 |
blueCmd | it might be the same thing though | 22:11 |
blueCmd | if you can, try booting with init=/bin/bash and play around | 22:11 |
stekern | copying back the old libc6_2.18-4_or1k.deb made it boot | 22:17 |
wondiws | how do I test my orpsoc-build if it has any life? | 22:41 |
blueCmd | wondiws: bin/fusesoc build de2_115 | 22:43 |
wondiws | I did, it was succesful | 22:44 |
wondiws | I uploaded it | 22:44 |
blueCmd | cool | 22:44 |
wondiws | but now I suppose I have to have an executable image as well? | 22:44 |
blueCmd | yep | 22:44 |
blueCmd | openocd should be fine | 22:44 |
blueCmd | http://opencores.org/or1k/ORCONF2013_Workshop_ORPSoC_On_DE0_Nano has documentation how to use that | 22:44 |
wondiws | I got to install the toolchain as well I'm afraid... | 22:45 |
blueCmd | well, if you want to compile something :P | 22:45 |
blueCmd | but for openocd you don't need that | 22:45 |
wondiws | good | 22:45 |
wondiws | I first need to know if I can use my de2-115 board ofcourse | 22:46 |
wondiws | then I'll install the toolchain with pleasure :) | 22:46 |
wondiws | but the documentation uses or1k_generic.cfg, my openeocd directory which I pulled from openrisc github has no such file | 22:56 |
blueCmd | wondiws: http://786ed9a2a83e3d75.paste.se/ | 22:59 |
wondiws | I don't understand OpenOCD :S | 23:22 |
wondiws | "received CRC not same as calculated CRC :S | 23:23 |
wondiws | blueCmd, you still here? | 23:53 |
--- Log closed Sun May 25 00:00:04 2014 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!