| juliusb | mmm | 01:01 |
|---|---|---|
| juliusb | quite easily, as the pipeline and bus behaviour would be different | 01:02 |
| juliusb | is this on the or1200? | 01:02 |
| _franck_ | yes | 01:02 |
| juliusb | cache enabled exercises all sorts of corner cases in burst logic in memory slaves | 01:02 |
| _franck_ | this openrisc cpu give me headache since I start working on it :) | 01:04 |
| _franck_ | s/start/started | 01:05 |
| juliusb | :P | 01:06 |
| _franck_ | so you mean it could me an RTL problem ? on the memory controller ? | 01:07 |
| juliusb | yes | 01:07 |
| _franck_ | I think I'll start using the one you are using in orpsoc | 01:07 |
| _franck_ | for now, I'm using the one stefan wrote | 01:08 |
| juliusb | oh odd | 01:08 |
| juliusb | that should be solid? | 01:08 |
| _franck_ | well it was in the de0 port of orpsoc here http://git.openrisc.net/cgit.cgi/stefan/orpsoc/tree/boards/altera/de0_nano/rtl/verilog/wb_sdram_ctrl | 01:09 |
| _franck_ | since it was my starting point | 01:09 |
| _franck_ | I never changed it.... | 01:09 |
| _franck_ | however, I'll be my next step for sure | 01:10 |
| _franck_ | which one are you using for sdram ? | 01:10 |
| juliusb | i use mainly DDR controllers | 01:11 |
| _franck_ | ok I'll try the versatile_mem_ctrl | 01:12 |
| juliusb | that one should be OK these days | 01:13 |
| juliusb | can you not simulate the program running with icache enabled? | 01:13 |
| _franck_ | you mean an RTL sim ? | 01:14 |
| juliusb | yeah | 01:15 |
| _franck_ | I didn't try RTL sim that much (I should do it to debug such problems) because I don't know it that much | 01:16 |
| juliusb | ah OK | 01:17 |
| juliusb | it's a very good skill to debug these things | 01:17 |
| _franck_ | If I've started with this may be that I'll have less trouble debugging.... | 01:18 |
| _franck_ | I put it after the sdram controller change on ma todo list | 01:18 |
| _franck_ | :) | 01:18 |
| juliusb | :) | 01:19 |
| _franck_ | ok, enought for tonight | 01:19 |
| _franck_ | see ya, good night | 01:19 |
| juliusb | nice one mate | 01:36 |
| juliusb | :) | 01:36 |
| stekern | _franck_: versatile_mem_controller should definately have more test-coverage than my controller, so test with that is probably a good idea | 06:07 |
| dwhite | newbie question: is it easier to build applications (e.g. procps utils) for openrisc using a cross compiler on my amd64 system, or by setting up a build environment within or1ksim? | 06:22 |
| gxti | dwhite: you need a cross chain to get to that point anyway, might as well use it | 06:23 |
| dwhite | I have a cross compiler built. I'm wondering at what point will it be more painful (as I compile more complex apps) to try to maintain a library chain as well, or is that not as painful as I anticipate? | 06:24 |
| dwhite | i'm concerned that not all applications will have well behaving ./configure scripts and Makefiles. Has anyone created a built environment within a simulator or openrisc platform? | 06:34 |
| dwhite | s/built/build | 06:34 |
| gxti | i don't know anything about or1ksim specifically, but there's nothing wrong with the idea | 06:35 |
| gxti | obviously your compile times are going to be longer | 06:35 |
| dwhite | right | 06:35 |
| dwhite | my goal is to get node.js + google v8 working within openrisc. google v8 is highly assembler dependant, so I know there's porting to be done there. | 06:37 |
| gxti | heh, good luck :) | 06:38 |
| stekern | our llvm backend is starting to be able to compile something more useful than just trivial testcases, I've managed to compile my membenchmark and link it with (gcc compiled) newlib. | 17:34 |
| stekern | it doesn't get calling functions with variadic parameters right yet though | 17:35 |
| stekern | I don't quite get why, IMO I'm doing everything required for that to work... | 17:35 |
| juliusb | cool! | 17:48 |
| juliusb | sorry, i forgot to answer you question about relocations from the other day too | 17:48 |
| stekern | I'm still wondering ;) | 17:49 |
| juliusb | i'm not sure how getting global addresses in at link time really works | 17:49 |
| juliusb | doesn't it just make that symbol's address available, though? | 17:50 |
| juliusb | i'm not sure what you mean by the fact that the instruction turned into l.ori r0, r0, lo(addr) | 17:50 |
| juliusb | you mean llvm did that somehow? | 17:50 |
| stekern | I had a bug that made loading a global address into a register: l.ori rX, r0, globaladdress | 17:51 |
| juliusb | in the linker....? | 17:52 |
| stekern | let's assume rX is r3, then when disassembling the object before linking, I had: l.ori r3, r0, globaladdress | 17:52 |
| stekern | or actually: l.ori r3, r0, 0 | 17:52 |
| juliusb | yep | 17:53 |
| stekern | after linking it turns into: l.ori r0, r0, <globaladdress address> | 17:53 |
| juliusb | byut there's data in the object file somewhere saying that '0' value needs to be filled in at link time | 17:53 |
| juliusb | and then it clobbers the rX value? | 17:54 |
| juliusb | is this with our latest binutils? | 17:54 |
| stekern | yes | 17:54 |
| juliusb | ytes i had an issue at link time where it was doing some incorrect packing of the operands into the instruction | 17:54 |
| stekern | or no, but I presume it does that too | 17:55 |
| juliusb | but fixed that | 17:55 |
| juliusb | but you're saying the global address value is right? | 17:55 |
| stekern | yes, the linker is doing everything as it should | 17:55 |
| stekern | I'm just curious how it does it "under the hood" | 17:55 |
| juliusb | yeah, i'm not really sure :-/ | 17:57 |
| juliusb | especially how it handles that lo() and hi() stuff | 17:57 |
| juliusb | i guess, actually, that is pretty straight forward. which thing in particular are you wanting to know about? | 17:57 |
| juliusb | where it gets the symbol from or how it packs it in or how this is indicated in the object file or all of the above? | 17:58 |
| stekern | mostly how it packs/patches it in, but a pointer to the source files where it is handled would be great | 17:58 |
| juliusb | yeah, I'm not certain - i just had a look through. It was a little more obvious in the older binutils port (You could see it doing shifting and masking to pack values into the immediate fields of instructions) but now with the CGEN-based stuff, it's all pretty obscure. Basically, you just provide some functions to handle certain things which then are called by the generic linker code I think | 18:12 |
| juliusb | but it was a while since I was debugging the older linker internals | 18:12 |
| juliusb | so can't recall, but the things we rely on are a bit spread out. I think the bfd/elf32-or1k.c file has some useful stuff in it, regarding relocations | 18:13 |
| pgavin | relocations are handled in or1k-src/bfd/elf32-or1k.c | 18:32 |
| pgavin | it's handled pretty automatically | 18:33 |
| pgavin | you just tell it what the relocs look like, (see reloc_howto_type and or1k_elf_howto_table) | 18:34 |
| pgavin | the part involving where to put the immediate in the encoded instruction is handled by cgen | 18:34 |
| pgavin | see cpu/or1kcommon.cpu | 18:34 |
| stekern | pgavin: thanks for the pointers, I'll check those out | 19:03 |
| pgavin | np | 19:06 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!