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

--- Log opened Sat Jul 05 00:00:05 2014
daliasstekern, nice! how is it working now?00:39
stekerndalias: hard to say, haven't got around to test it yet07:07
stekern...and I'm still missing stuff in src/thread07:10
stekernbut I can build libc-tests at least, so I'll spend some time fixing the build failures in there07:10
stekernbut in general, I haven't seen any issues in the statically built busybox I'm using in my dev setup07:11
stekernbut again, what I've been doing with that can't really be called of any 'test-coverage' of sort ;)07:12
blueCmdlooks like I will have to write a Xilinx DDR <-> WB interface10:35
stekernblueCmd: would it make sense to write it as a wb<->axi converter?11:13
blueCmdstekern: I was considering that11:43
blueCmdI guess that would be higher value to the community and less maintainance11:43
blueCmdstekern: why hasn't someone already written one?11:43
sb0blueCmd, what's "Xilinx DDR"?11:44
blueCmdsb0: MiG i guess11:46
sb0what FPGA?11:46
sb0use misoc11:46
blueCmdhaha :)11:46
blueCmdlet's have a look11:47
sb0including ddr311:47
sb0but at reduced performance level, and this whole port is a tad dirty. if you clean it up, I can merge it.11:48
blueCmdI don't care about performance yet, so that's fine11:49
blueCmdsb0: Ok, you win. I'll give misoc a go.11:50
sb0good. a much better investment than in the proprietary and crappy xilinx mig.11:50
blueCmdsb0: are you available for some consultation?11:50
blueCmdhow to structure my design to make best use of misoc11:50
sb0what do you mean by 'consultation'?11:51
blueCmdCurrently I have: ( and orpsoc/
blueCmdsb0: well, if you're on a train or something I could wait until you are not :)11:52
blueCmdthat's what I mean11:52
sb0ah. then yeah, go ahead and ask questions :)11:53
blueCmdsb0: you're probably inclined to answer ("everything!"), but how would I best go on to introduce misoc in my design?11:54
blueCmdas in "replace everything".11:54
blueCmdsorry, that was a weird sentence. let me rephrase11:54
sb0you should use misoc to handle all the building and integration process11:54
sb0you can still interface to legacy verilog cores, if you don't want to rewrite them11:55
blueCmdright. do I still handle "wb_g18" and "rom" as cores, or will I need to port them?11:55
blueCmdah, that's wonderful11:55
sb0e.g. the old minimac from milkymist:
sb0lm32 and mor1kx are also encapsulated in a similar way11:56
sb0what's "rom"? a wishbone rom? use the migen-provided core for thagt11:56
blueCmdso I could begin with replacing my top-level with misoc and treat orpsoc as core?11:56
blueCmdthat's obviously not preferred though11:56
sb0if it's for the bootloader, misoc already provides a mechanism to automate that11:56
sb0ah, no11:56
sb0create a 'target' file11:57
sb0and then use misoc to load and build it11:57
blueCmdsb0: yes, it's for the bootloader so I'd much rather use your builtin thing11:57
sb0misoc already provides a bootloader11:57
sb0if there are some missing features, patches welcome11:57
sb0so you create a target file like that for your platform11:58
sb0what board is it btw?11:58
sb0misoc also supports execute-in-place from flash, so you don't have to waste BRAM on bootloader ROMs11:58
blueCmdsb0: ah, execute in place - that's a nice touch12:01
blueCmdsb0: how big is it?12:01
blueCmdthe bootloader12:01
sb0a couple dozen KB12:02
sb0depends what features you build in12:02
blueCmdright. I'll probably use my own bootloader for now (partly because I enjoy writing it)12:03
sb0what do you need?12:04
sb0 < that's the misoc bios12:04
sb0if you use another, it'll make it harder to merge your stuff upstream...12:04
sb0or you have to submit a patch against for it to support external bootloaders12:04
blueCmdsb0: can't I load arbitary data in roms?12:06
sb0you can. but the existing misoc bootloader ROM mechanisms (which you don't have to use) are designed to work with the provided bootloader12:07
sb0what happens is the soc class asks to provide BIOS data, and in turn runs make in the bios directory, reads the built binary, and provides it to the soc class12:08
sb0you can either add an option in for it to provide alternate bootloader data, or not use this mechanism at all and read your bootloader in your soc class12:09
sb0I'd recommend #112:09
blueCmdhm. right. it's not that I _need_ anything else, your BIOS is probably fine - but I'm writing my own for my own benefit and enjoyment12:09
blueCmdyes, #1 sounds like the best option12:10
blueCmdmaybe it would make sense to have 'software/bios' configurable. that way you can point it an arbitary diretory with a Makefile that will spit out bios.bin12:12
daliasstekern, ok i'll take a look in a bit. if all that's left is thread stuff busybox should fully work already so yes it's not a test for completeness12:56
daliason the other hand busybox is a good test for missing or broken syscalls since it uses so many12:56
daliasactually missing __set_thread_area.s _could_ affect anything that relies on TLS working, even for non-multithreaded use12:58
daliasi can help you with what these functions need to do if you have any questions12:58
daliasthey're all pretty easy12:59
stekerndalias: yeah, I'll probably take a look at those in the evening13:02
stekernand I'll ask if anything is unclear13:02
stekernleft is to clean-up the setjmp stuff too13:03
blueCmdsb0: CSRs, how do they map to or1k? do you have a wishbone interface or something?13:23
blueCmdah, found it. wishbone2csr13:25
sb0all csrs are put to a "csr" bus, which is then bridged to wb13:25
blueCmdsb0: i'm a bit concerned about the "free stuff" that is included. looking at the csr map there are a lot of devices13:32
blueCmdcrg, identifier, timer0, buttons, leds, dfii, lasmicron, memtest_w, memtest_r in my case13:32
blueCmdoh well, I'll continue and inspect the result13:34
blueCmdhm     raise NotImplementedError("Register too large")13:44
blueCmdanyway, time for lunch.13:44
blueCmdsb0: nice job, I'm enjoying working with misoc so far - a _lot_ of the headaches associated with verilog / systemverilog / vhdl hell is solved nicely by using misoc to interconnect13:45
sb0stekern, what's the purpose of 8-bit relocations?13:49
daliasgood question :)13:52
daliasi cant think of anywhere relocs < 32 bit could work13:53
daliasshort jumps are only possible within a single TU13:53
blueCmdsb0: so "#define CSR_DFII_PI0_WRDATA_SIZE 16" triggers "Register too large" in misoclib/gensoc/", line 41, in _get_rw_functions14:01
blueCmdI tried to switch to use florent's repositories thinking he might have commits pending to be merged, but that doesn't seem to have helped anything14:02
sb0yeah, I guess that's because you have a lot of DQ bits on your DRAM, and the data regs for DRAM bit banging won't fit into the largest C-supported integer type (64-bit)14:07
sb0you can modify to skip those regs, since the code doesn't use the generated functions anywhere (which is something that needs fixing btw)14:07
blueCmdweird that florent didn't have that issue (or that he left the patch uncommitted)14:10
sb0knowing Florent a bit, I'm willing to bet that his 'patch' is commenting out the "raise" line...14:16
stekernsb0: no idea, I've been wondering the same thing14:38
blueCmdhah, my bootloader is now 1012 bytes. my self-imposed 1KiB limit is getting close :)15:01
stekernsb0: is the de0 nano port somewhere else?15:19
stekernah, never mind15:20
stekernI was looking in the wrong place15:20
sb0blueCmd, are you writing it in asm?15:24
sb0blueCmd, one nice feature of a bootloader is the ability to read/write registers and bit-bang simple sdram commands... very useful for bringing up sdram on boards where it acts up15:25
sb0of course, if you want a very small bootloader, you can offload some of this to PC software...15:25
blueCmdsb0: I have a board diagnostics software written in C that the bootloader can load15:40
blueCmdthat sortof does the same thing, but it needs to be loaded to memory currently15:41
sb0how do you load it when you need to debug the sdram? (which tends to be a regular trouble-maker...)15:42
sb0misoc puts the bootloader code in flash and its data in BRAM, so it works even when the sdram is broken15:43
blueCmdsb0: I would BRAM 0-256 KiB and DDR3 512-1024MiB15:52
olofkstekern: I love the bash-completion. I've been considering that as well :)21:40
stekernI can post it as a patch to fusesoc if you want21:49
stekernI've improved it slightly21:49
blueCmdweird stuff21:49
blueCmdI can read/write stuff to wb_ram - my basic cksum += addr^data checks out on the data written21:50
blueCmdI can do the same with ram_wb - checksum checks out as well21:50
blueCmdI can jump and execute code inside the RAM for ram_wb - but only in Verilator (not on hardware)21:51
blueCmdexecuting in wb_ram doesn't work for neither21:51
blueCmdstekern: what have I f*cked up? :-) the instruction bus?21:52
stekernis the wb_intercon the same for verilator and hw?21:53
blueCmdshould be21:53
blueCmdhm, interesting. if I stop it it is inside _board_exit21:56
blueCmdfor wb_ram21:56
blueCmdwhen using*21:56
stekernso... what is the difference between hw and verilator?22:00
stekernI can't promise that nothing broke with my fetch/icache rework, but it has been working fine in all my tests here22:01
stekernso that's one thing you could try, checkout the commit before that (if you are even using that recent mor1kx version)22:01
blueCmd__impure_init gets a bus error22:02
stekernibus or dbus?22:02
blueCmdstekern: using the latest and greatest!(?)22:02
blueCmdstekern: I don't know, I just see the 0x200 on next pc22:02
stekernthat's good!22:02
stekernah, right22:02
blueCmdbut it is an l.sw so probably d22:03
stekernwell, I did rework the lsu/dcache too =)22:03
stekernI'm working on a multiplier improvement now too22:04
stekern(since you were speaking of greatest) ;)22:04
stekernwell, right *now* I'm working on the musl thread stuff. but I have a halfbaked mul improvement22:05
blueCmdhaha, you never get bored! I mean, I feel productive, but I have my seasons, as you probably have seen22:06
stekerntwo .s's down, one to go22:06
stekernI have too, but I can't let stuff completely be during my down seasons ;)22:07
stekern(getting bored) that's my biggest problem, I easily *do* get bored. That's why I'm jumping around like crazy between projects...22:09
olofkFuck this shit!  I just finished reading through the backlog, and now I'm so tired I can't keep my eyes open22:09
blueCmdolofk: haha :)22:11
stekernyeah, you've been away for a while, sorry we couldn't keep quiet ;)22:11
blueCmdstekern: rolled back to 3.0 and it didn't seem to change anything22:16
blueCmdolofk: do you have any hints on the differences I'm seeing while using wb_ram and ram_wb?22:18
stekernblueCmd: ok, so then we can rule that out22:31
blueCmdit always seems to be when returning from __impure_init (or it might be confirmation bias on my part)22:33
blueCmdit restores r9 from stack, jumps to r9 and ends up at wrong places22:33
blueCmdstekern: where is "r1"? I want to inspect it22:36
blueCmdusing cappucino if that matters22:36
stekernin mor1kx_rf_cappucino.v22:38
stekernwell, in mor1kx_rf_ram.v to be precise22:39
stekern(I'm planning on zapping that file and use the generic rams instead btw)22:39
blueCmdstekern: right, I was just about to ask about rf?ram22:40
blueCmdmeh, finding the right verilator path sucks22:45
stekernheh, just noticed a bug when I looked at that paste myself ;)22:49
blueCmdstekern: that's the path22:49
stekernah, you mean *that* path22:49
daliasstekern, at a glance, it looks good. have you tested it at all?22:54
daliasi'll take a look later22:54
stekernthat's next =) I've 'compile' tested it against libc-tests though22:55
blueCmdstekern: I have two traces with PC, INSN, r1 and r9 in them22:56
stekernblueCmd: congrats! ;)22:56
blueCmdwhen restoring r9 from the stack it ends up with 0x0 instead of 0x20dc as it should22:56
blueCmdwb_ram returns 0x0, ram_wb returns 0x20dc22:57
stekerncan't you just dump a vcd and take a peek what's going on?=22:57
blueCmdremember that this is like my first large hardware project :P22:57
stekernblueCmd: you can get a nice waveform dump by supplying the --vcd command to fusesoc22:59
blueCmdstekern: not using fusesoc22:59
stekern(well, it's actually supplying it to Vorpsoc_top)22:59
stekernso the verilator generated executable23:00
blueCmdI saw code that referred to vcds but I don't think they are in the latest testbenches for verilator23:00
stekernthey are23:00
blueCmdah, they moved to tb-utils23:01
stekernyes, I had just dug up the link to that for you ;)23:02
blueCmdright, I'll probably add that back at some point - kind of enjoy debugging via text though23:02
blueCmdthat said - is this a mor1kx or wb_ram problem I wonder?23:03
stekernyeah, I try to do that as far as possible too, but when I'm as far as you are now, then I usually dump a vcd and take a look23:03
stekernblueCmd: wb_ram problem of course! mor1kx doesn't have any bugs!23:07
blueCmdwell, if it has it owuld have been there since april at least (I just took a random commit way back to try even more)23:08
blueCmdstekern: do you use burst modes and stuff like that for the I bus that you're not using for the D bus?23:12
stekernah... you might be on to something23:16
blueCmdwell this would be a D bus access when I think of it23:17
stekernwhat was the address of the ram?23:17
blueCmdis the location23:18
blueCmdwell, r1 = 0x3e0023:18
blueCmdand it tries to read with an offset of -4 I think23:18
blueCmdyes, -423:19
stekernso it's not 0xee000000 anymore?23:19
blueCmdstekern: that's my G18 flash23:19
blueCmdso no23:19
stekernok, then nothing23:19
blueCmdyou mean that those things do stuff?23:21
blueCmdI thought they were just for decoration23:21
stekernthat makes all accesses to addresses above 0x80000000 uncached23:21
stekernbut if you have the ram below that, it's of course not related23:22
blueCmdah ok23:22
blueCmdyep it's burst related23:28
blueCmdI just tore out everything burst related in wb_ram and it works23:28
stekernbut about the vcd dumping, if you want to hack it back in directly to the tb, there's a simple example under "How do I generate waveforms (traces) in C++?" here:
blueCmdmight be because of the case not covering all the cases in
stekernwhat case isn't covered?23:31
blueCmdright. 2^2 = 4, not 823:32
blueCmdsometimes I wonder :)23:32
stekernI don't think this is right:
blueCmdso I managed to add a checksum calculation, RAM read-back and verifier in my 1 KiB bootloader as well23:38
stekernbut I'm not convinced that would be the problem23:38
blueCmdit's PARing the design now anyway, hopefully I will have a new data point when that has finished23:42
stekernit's not right, because there could be two bursts coming after each other without cyc&stb de-asserting23:42
stekernthis is strange too:
stekernah, no. that's right.23:43
blueCmdHAH! IT WORKS ! :D:D23:47
blueCmdI just booted my newlib diagnostics program using my own bootloader from the G18 flash!23:48
blueCmdnow. How do I make puts add \r instead of just \n?23:49
stekernor here already:
blueCmdstekern: thank you!23:57
--- Log closed Sun Jul 06 00:00:06 2014

Generated by 2.15.2 by Marius Gedminas - find it at!