| --- Log opened Sat Jul 05 00:00:05 2014 | ||
| dalias | stekern, nice! how is it working now? | 00:39 |
|---|---|---|
| stekern | dalias: hard to say, haven't got around to test it yet | 07:07 |
| stekern | ...and I'm still missing stuff in src/thread | 07:10 |
| stekern | but I can build libc-tests at least, so I'll spend some time fixing the build failures in there | 07:10 |
| stekern | but in general, I haven't seen any issues in the statically built busybox I'm using in my dev setup | 07:11 |
| stekern | but again, what I've been doing with that can't really be called of any 'test-coverage' of sort ;) | 07:12 |
| blueCmd | looks like I will have to write a Xilinx DDR <-> WB interface | 10:35 |
| stekern | blueCmd: would it make sense to write it as a wb<->axi converter? | 11:13 |
| blueCmd | stekern: I was considering that | 11:43 |
| blueCmd | I guess that would be higher value to the community and less maintainance | 11:43 |
| blueCmd | stekern: why hasn't someone already written one? | 11:43 |
| sb0 | blueCmd, what's "Xilinx DDR"? | 11:44 |
| blueCmd | sb0: MiG i guess | 11:46 |
| blueCmd | DDR3 | 11:46 |
| sb0 | what FPGA? | 11:46 |
| blueCmd | Kintex7 | 11:46 |
| sb0 | use misoc | 11:46 |
| blueCmd | haha :) | 11:46 |
| blueCmd | let's have a look | 11:47 |
| sb0 | https://github.com/Florent-Kermarrec/misoc-kc705 | 11:47 |
| sb0 | including ddr3 | 11:47 |
| sb0 | but at reduced performance level, and this whole port is a tad dirty. if you clean it up, I can merge it. | 11:48 |
| blueCmd | I don't care about performance yet, so that's fine | 11:49 |
| blueCmd | sb0: Ok, you win. I'll give misoc a go. | 11:50 |
| sb0 | good. a much better investment than in the proprietary and crappy xilinx mig. | 11:50 |
| blueCmd | sb0: are you available for some consultation? | 11:50 |
| blueCmd | how to structure my design to make best use of misoc | 11:50 |
| sb0 | what do you mean by 'consultation'? | 11:51 |
| blueCmd | Currently I have: https://github.com/bluecmd/mexiko/tree/master/rtl/ (mexiko.sv and orpsoc/orpsoc.sv). | 11:51 |
| blueCmd | sb0: well, if you're on a train or something I could wait until you are not :) | 11:52 |
| blueCmd | that's what I mean | 11:52 |
| sb0 | ah. then yeah, go ahead and ask questions :) | 11:53 |
| blueCmd | sb0: you're probably inclined to answer ("everything!"), but how would I best go on to introduce misoc in my design? | 11:54 |
| blueCmd | as in "replace everything". | 11:54 |
| blueCmd | sorry, that was a weird sentence. let me rephrase | 11:54 |
| sb0 | you should use misoc to handle all the building and integration process | 11:54 |
| sb0 | you can still interface to legacy verilog cores, if you don't want to rewrite them | 11:55 |
| blueCmd | right. do I still handle "wb_g18" and "rom" as cores, or will I need to port them? | 11:55 |
| blueCmd | ah, that's wonderful | 11:55 |
| sb0 | e.g. the old minimac from milkymist: https://github.com/m-labs/misoc/blob/master/misoclib/minimac3/__init__.py | 11:55 |
| sb0 | lm32 and mor1kx are also encapsulated in a similar way | 11:56 |
| sb0 | what's "rom"? a wishbone rom? use the migen-provided core for thagt | 11:56 |
| sb0 | *that | 11:56 |
| blueCmd | so I could begin with replacing my top-level with misoc and treat orpsoc as core? | 11:56 |
| blueCmd | that's obviously not preferred though | 11:56 |
| sb0 | if it's for the bootloader, misoc already provides a mechanism to automate that | 11:56 |
| sb0 | ah, no | 11:56 |
| sb0 | create a 'target' file | 11:57 |
| sb0 | and then use misoc build.py to load and build it | 11:57 |
| blueCmd | sb0: yes, it's for the bootloader so I'd much rather use your builtin thing | 11:57 |
| sb0 | misoc already provides a bootloader | 11:57 |
| sb0 | if there are some missing features, patches welcome | 11:57 |
| sb0 | https://github.com/m-labs/blinkie | 11:57 |
| sb0 | so you create a target file like that for your platform | 11:58 |
| sb0 | what board is it btw? | 11:58 |
| sb0 | misoc also supports execute-in-place from flash, so you don't have to waste BRAM on bootloader ROMs | 11:58 |
| blueCmd | sb0: hitechglobal.com/Boards/Kintex-7_PCIE.htm | 12:00 |
| blueCmd | sb0: ah, execute in place - that's a nice touch | 12:01 |
| blueCmd | sb0: how big is it? | 12:01 |
| blueCmd | the bootloader | 12:01 |
| sb0 | a couple dozen KB | 12:02 |
| sb0 | depends what features you build in | 12:02 |
| blueCmd | right. I'll probably use my own bootloader for now (partly because I enjoy writing it) | 12:03 |
| sb0 | what do you need? | 12:04 |
| sb0 | https://github.com/m-labs/misoc/tree/master/software/bios < that's the misoc bios | 12:04 |
| sb0 | if you use another, it'll make it harder to merge your stuff upstream... | 12:04 |
| sb0 | or you have to submit a patch against build.py for it to support external bootloaders | 12:04 |
| blueCmd | sb0: can't I load arbitary data in roms? | 12:06 |
| sb0 | you can. but the existing misoc bootloader ROM mechanisms (which you don't have to use) are designed to work with the provided bootloader | 12:07 |
| sb0 | what happens is the soc class asks build.py to provide BIOS data, and make.py in turn runs make in the bios directory, reads the built binary, and provides it to the soc class | 12:08 |
| sb0 | you can either add an option in build.py for it to provide alternate bootloader data, or not use this mechanism at all and read your bootloader in your soc class | 12:09 |
| sb0 | I'd recommend #1 | 12:09 |
| blueCmd | hm. 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 enjoyment | 12:09 |
| blueCmd | yes, #1 sounds like the best option | 12:10 |
| blueCmd | maybe 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.bin | 12:12 |
| dalias | stekern, 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 completeness | 12:56 |
| dalias | on the other hand busybox is a good test for missing or broken syscalls since it uses so many | 12:56 |
| dalias | actually missing __set_thread_area.s _could_ affect anything that relies on TLS working, even for non-multithreaded use | 12:58 |
| dalias | i can help you with what these functions need to do if you have any questions | 12:58 |
| dalias | they're all pretty easy | 12:59 |
| stekern | dalias: yeah, I'll probably take a look at those in the evening | 13:02 |
| stekern | and I'll ask if anything is unclear | 13:02 |
| stekern | left is to clean-up the setjmp stuff too | 13:03 |
| blueCmd | sb0: CSRs, how do they map to or1k? do you have a wishbone interface or something? | 13:23 |
| blueCmd | ah, found it. wishbone2csr | 13:25 |
| sb0 | all csrs are put to a "csr" bus, which is then bridged to wb | 13:25 |
| blueCmd | sb0: i'm a bit concerned about the "free stuff" that is included. looking at the csr map there are a lot of devices | 13:32 |
| blueCmd | crg, identifier, timer0, buttons, leds, dfii, lasmicron, memtest_w, memtest_r in my case | 13:32 |
| blueCmd | oh well, I'll continue and inspect the result | 13:34 |
| blueCmd | hm raise NotImplementedError("Register too large") | 13:44 |
| blueCmd | anyway, time for lunch. | 13:44 |
| blueCmd | sb0: 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 interconnect | 13:45 |
| sb0 | :) | 13:49 |
| sb0 | stekern, what's the purpose of 8-bit relocations? | 13:49 |
| dalias | good question :) | 13:52 |
| dalias | i cant think of anywhere relocs < 32 bit could work | 13:53 |
| dalias | short jumps are only possible within a single TU | 13:53 |
| blueCmd | sb0: so "#define CSR_DFII_PI0_WRDATA_SIZE 16" triggers "Register too large" in misoclib/gensoc/cpuif.py", line 41, in _get_rw_functions | 14:01 |
| blueCmd | I 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 anything | 14:02 |
| sb0 | yeah, 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 |
| sb0 | you can modify cpuif.py to skip those regs, since the code doesn't use the generated functions anywhere (which is something that needs fixing btw) | 14:07 |
| blueCmd | right | 14:10 |
| blueCmd | weird that florent didn't have that issue (or that he left the patch uncommitted) | 14:10 |
| sb0 | knowing Florent a bit, I'm willing to bet that his 'patch' is commenting out the "raise" line... | 14:16 |
| blueCmd | :D | 14:19 |
| stekern | sb0: no idea, I've been wondering the same thing | 14:38 |
| blueCmd | hah, my bootloader is now 1012 bytes. my self-imposed 1KiB limit is getting close :) | 15:01 |
| stekern | sb0: is the de0 nano port somewhere else? | 15:19 |
| stekern | ah, never mind | 15:20 |
| stekern | I was looking in the wrong place | 15:20 |
| sb0 | blueCmd, are you writing it in asm? | 15:24 |
| sb0 | blueCmd, 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 up | 15:25 |
| sb0 | of course, if you want a very small bootloader, you can offload some of this to PC software... | 15:25 |
| blueCmd | sb0: I have a board diagnostics software written in C that the bootloader can load | 15:40 |
| blueCmd | that sortof does the same thing, but it needs to be loaded to memory currently | 15:41 |
| sb0 | how do you load it when you need to debug the sdram? (which tends to be a regular trouble-maker...) | 15:42 |
| sb0 | misoc puts the bootloader code in flash and its data in BRAM, so it works even when the sdram is broken | 15:43 |
| blueCmd | sb0: I would BRAM 0-256 KiB and DDR3 512-1024MiB | 15:52 |
| olofk | stekern: I love the bash-completion. I've been considering that as well :) | 21:40 |
| stekern | I can post it as a patch to fusesoc if you want | 21:49 |
| stekern | I've improved it slightly | 21:49 |
| blueCmd | weird stuff | 21:49 |
| blueCmd | I can read/write stuff to wb_ram - my basic cksum += addr^data checks out on the data written | 21:50 |
| blueCmd | I can do the same with ram_wb - checksum checks out as well | 21:50 |
| blueCmd | I can jump and execute code inside the RAM for ram_wb - but only in Verilator (not on hardware) | 21:51 |
| blueCmd | executing in wb_ram doesn't work for neither | 21:51 |
| blueCmd | stekern: what have I f*cked up? :-) the instruction bus? | 21:52 |
| stekern | is the wb_intercon the same for verilator and hw? | 21:53 |
| blueCmd | should be | 21:53 |
| blueCmd | hm, interesting. if I stop it it is inside _board_exit | 21:56 |
| blueCmd | for wb_ram | 21:56 |
| blueCmd | when using* | 21:56 |
| stekern | so... what is the difference between hw and verilator? | 22:00 |
| stekern | I can't promise that nothing broke with my fetch/icache rework, but it has been working fine in all my tests here | 22:01 |
| blueCmd | hm | 22:01 |
| stekern | so 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 error | 22:02 |
| stekern | ibus or dbus? | 22:02 |
| blueCmd | stekern: using the latest and greatest!(?) | 22:02 |
| blueCmd | stekern: I don't know, I just see the 0x200 on next pc | 22:02 |
| stekern | that's good! | 22:02 |
| stekern | ah, right | 22:02 |
| blueCmd | but it is an l.sw so probably d | 22:03 |
| stekern | well, I did rework the lsu/dcache too =) | 22:03 |
| stekern | I'm working on a multiplier improvement now too | 22:04 |
| stekern | (since you were speaking of greatest) ;) | 22:04 |
| stekern | well, right *now* I'm working on the musl thread stuff. but I have a halfbaked mul improvement | 22:05 |
| blueCmd | haha, you never get bored! I mean, I feel productive, but I have my seasons, as you probably have seen | 22:06 |
| stekern | two .s's down, one to go | 22:06 |
| stekern | I 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 |
| olofk | Fuck this shit! I just finished reading through the backlog, and now I'm so tired I can't keep my eyes open | 22:09 |
| blueCmd | olofk: haha :) | 22:11 |
| stekern | yeah, you've been away for a while, sorry we couldn't keep quiet ;) | 22:11 |
| blueCmd | stekern: rolled back to 3.0 and it didn't seem to change anything | 22:16 |
| blueCmd | olofk: do you have any hints on the differences I'm seeing while using wb_ram and ram_wb? | 22:18 |
| stekern | blueCmd: ok, so then we can rule that out | 22:31 |
| blueCmd | it always seems to be when returning from __impure_init (or it might be confirmation bias on my part) | 22:33 |
| blueCmd | it restores r9 from stack, jumps to r9 and ends up at wrong places | 22:33 |
| blueCmd | stekern: where is "r1"? I want to inspect it | 22:36 |
| blueCmd | using cappucino if that matters | 22:36 |
| stekern | in mor1kx_rf_cappucino.v | 22:38 |
| stekern | well, in mor1kx_rf_ram.v to be precise | 22:39 |
| stekern | (I'm planning on zapping that file and use the generic rams instead btw) | 22:39 |
| blueCmd | stekern: right, I was just about to ask about rf?ram | 22:40 |
| blueCmd | meh, finding the right verilator path sucks | 22:45 |
| stekern | ? | 22:48 |
| stekern | dalias: https://github.com/skristiansson/musl-or1k/commit/a465b7c67d36030fbd36253e646260d471ad898b | 22:48 |
| stekern | heh, just noticed a bug when I looked at that paste myself ;) | 22:49 |
| blueCmd | top->soc_i->mor1kx0->mor1kx_cpu->cappuccino__DOT__mor1kx_cpu->mor1kx_rf_cappuccino->rfa->ram | 22:49 |
| blueCmd | stekern: that's the path | 22:49 |
| stekern | ah, you mean *that* path | 22:49 |
| dalias | stekern, at a glance, it looks good. have you tested it at all? | 22:54 |
| dalias | i'll take a look later | 22:54 |
| stekern | that's next =) I've 'compile' tested it against libc-tests though | 22:55 |
| blueCmd | stekern: I have two traces with PC, INSN, r1 and r9 in them | 22:56 |
| stekern | blueCmd: congrats! ;) | 22:56 |
| blueCmd | when restoring r9 from the stack it ends up with 0x0 instead of 0x20dc as it should | 22:56 |
| blueCmd | wb_ram returns 0x0, ram_wb returns 0x20dc | 22:57 |
| stekern | can't you just dump a vcd and take a peek what's going on?= | 22:57 |
| blueCmd | vcd? | 22:57 |
| blueCmd | remember that this is like my first large hardware project :P | 22:57 |
| stekern | blueCmd: you can get a nice waveform dump by supplying the --vcd command to fusesoc | 22:59 |
| blueCmd | stekern: not using fusesoc | 22:59 |
| stekern | (well, it's actually supplying it to Vorpsoc_top) | 22:59 |
| stekern | so the verilator generated executable | 23:00 |
| blueCmd | I saw code that referred to vcds but I don't think they are in the latest testbenches for verilator | 23:00 |
| stekern | they are | 23:00 |
| blueCmd | ah, they moved to tb-utils | 23:01 |
| stekern | yes, I had just dug up the link to that for you ;) | 23:02 |
| blueCmd | hah | 23:02 |
| blueCmd | right, I'll probably add that back at some point - kind of enjoy debugging via text though | 23:02 |
| blueCmd | that said - is this a mor1kx or wb_ram problem I wonder? | 23:03 |
| stekern | yeah, 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 look | 23:03 |
| stekern | blueCmd: wb_ram problem of course! mor1kx doesn't have any bugs! | 23:07 |
| stekern | =P | 23:07 |
| blueCmd | well, 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 |
| blueCmd | stekern: do you use burst modes and stuff like that for the I bus that you're not using for the D bus? | 23:12 |
| stekern | ah... you might be on to something | 23:16 |
| blueCmd | well this would be a D bus access when I think of it | 23:17 |
| stekern | what was the address of the ram? | 23:17 |
| stekern | 0xee000000? | 23:18 |
| blueCmd | 0x3e00 | 23:18 |
| blueCmd | is the location | 23:18 |
| blueCmd | well, r1 = 0x3e00 | 23:18 |
| blueCmd | and it tries to read with an offset of -4 I think | 23:18 |
| blueCmd | yes, -4 | 23:19 |
| stekern | so it's not 0xee000000 anymore? | 23:19 |
| blueCmd | stekern: that's my G18 flash | 23:19 |
| blueCmd | so no | 23:19 |
| stekern | ah | 23:19 |
| stekern | ok, then nothing | 23:19 |
| stekern | https://github.com/bluecmd/mexiko/blob/master/rtl/orpsoc/orpsoc.sv#L119 | 23:20 |
| blueCmd | you mean that those things do stuff? | 23:21 |
| blueCmd | I thought they were just for decoration | 23:21 |
| stekern | that makes all accesses to addresses above 0x80000000 uncached | 23:21 |
| stekern | but if you have the ram below that, it's of course not related | 23:22 |
| blueCmd | ah ok | 23:22 |
| blueCmd | yep it's burst related | 23:28 |
| blueCmd | I just tore out everything burst related in wb_ram and it works | 23:28 |
| stekern | but 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: http://www.veripool.org/projects/verilator/wiki/Manual-verilator | 23:29 |
| blueCmd | might be because of the case not covering all the cases in https://github.com/openrisc/orpsoc-cores/blob/master/cores/wb_ram/rtl/verilog/wb_funcs.v | 23:29 |
| stekern | what case isn't covered? | 23:31 |
| blueCmd | right. 2^2 = 4, not 8 | 23:32 |
| blueCmd | sometimes I wonder :) | 23:32 |
| stekern | I don't think this is right: https://github.com/openrisc/orpsoc-cores/blob/master/cores/wb_ram/rtl/verilog/wb_ram.v#L36 | 23:35 |
| blueCmd | so I managed to add a checksum calculation, RAM read-back and verifier in my 1 KiB bootloader as well | 23:38 |
| stekern | but I'm not convinced that would be the problem | 23:38 |
| blueCmd | it's PARing the design now anyway, hopefully I will have a new data point when that has finished | 23:42 |
| stekern | it's not right, because there could be two bursts coming after each other without cyc&stb de-asserting | 23:42 |
| stekern | this is strange too: https://github.com/openrisc/orpsoc-cores/blob/master/cores/wb_ram/rtl/verilog/wb_ram.v#L42 | 23:43 |
| stekern | ah, no. that's right. | 23:43 |
| blueCmd | HAH! IT WORKS ! :D:D | 23:47 |
| blueCmd | I just booted my newlib diagnostics program using my own bootloader from the G18 flash! | 23:48 |
| blueCmd | now. How do I make puts add \r instead of just \n? | 23:49 |
| stekern | https://github.com/openrisc/or1k-src/blob/or1k/libgloss/or1k/uart.c#L103 | 23:53 |
| stekern | or here already: https://github.com/openrisc/or1k-src/blob/or1k/libgloss/or1k/write.c#L44 | 23:55 |
| blueCmd | stekern: thank you! | 23:57 |
| --- Log closed Sun Jul 06 00:00:06 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!