IRC logs for #openrisc Sunday, 2012-05-06

juliusbquite easily, as the pipeline and bus behaviour would be different01:02
juliusbis this on the or1200?01:02
juliusbcache enabled exercises all sorts of corner cases in burst logic in memory slaves01:02
_franck_this openrisc cpu give me headache since I start working on it :)01:04
_franck_so you mean it could me an RTL problem ? on the memory controller ?01:07
_franck_I think I'll start using the one you are using in orpsoc01:07
_franck_for now, I'm using the one stefan wrote01:08
juliusboh odd01:08
juliusbthat should be solid?01:08
_franck_well it was in the de0 port of orpsoc here
_franck_since it was my starting point01:09
_franck_I never changed it....01:09
_franck_however, I'll be my next step for sure01:10
_franck_which one are you using for sdram ?01:10
juliusbi use mainly DDR controllers01:11
_franck_ok I'll try the versatile_mem_ctrl01:12
juliusbthat one should be OK these days01:13
juliusbcan you not simulate the program running with icache enabled?01:13
_franck_you mean an RTL sim ?01:14
_franck_I didn't try RTL sim that much (I should do it to debug such problems) because I don't know it that much01:16
juliusbah OK01:17
juliusbit's a very good skill to debug these things01: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 list01:18
_franck_ok, enought for tonight01:19
_franck_see ya, good night01:19
juliusbnice one mate01:36
stekern_franck_: versatile_mem_controller should definately have more test-coverage than my controller, so test with that is probably a good idea06:07
dwhitenewbie 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
gxtidwhite: you need a cross chain to get to that point anyway, might as well use it06:23
dwhiteI 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
dwhitei'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
gxtii don't know anything about or1ksim specifically, but there's nothing wrong with the idea06:35
gxtiobviously your compile times are going to be longer06:35
dwhitemy 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
gxtiheh, good luck :)06:38
stekernour 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
stekernit doesn't get calling functions with variadic parameters right yet though17:35
stekernI don't quite get why, IMO I'm doing everything required for that to work...17:35
juliusbsorry, i forgot to answer you question about relocations from the other day too17:48
stekernI'm still wondering ;)17:49
juliusbi'm not sure how getting global addresses in at link time really works17:49
juliusbdoesn't it just make that symbol's address available, though?17:50
juliusbi'm not sure what you mean by the fact that the instruction turned into l.ori r0, r0, lo(addr)17:50
juliusbyou mean llvm did that somehow?17:50
stekernI had a bug that made loading a global address into a register: l.ori rX, r0, globaladdress17:51
juliusbin the linker....?17:52
stekernlet's assume rX is r3, then when disassembling the object before linking, I had: l.ori r3, r0, globaladdress17:52
stekernor actually: l.ori r3, r0, 017:52
stekernafter linking it turns into: l.ori r0, r0, <globaladdress address>17:53
juliusbbyut there's data in the object file somewhere saying that '0' value needs to be filled in at link time17:53
juliusband then it clobbers the rX value?17:54
juliusbis this with our latest binutils?17:54
juliusbytes i had an issue at link time where it was doing some incorrect packing of the operands into the instruction17:54
stekernor no, but I presume it does that too17:55
juliusbbut fixed that17:55
juliusbbut you're saying the global address value is right?17:55
stekernyes, the linker is doing everything as it should17:55
stekernI'm just curious how it does it "under the hood"17:55
juliusbyeah, i'm not really sure :-/17:57
juliusbespecially how it handles that lo() and hi() stuff17:57
juliusbi guess, actually, that is pretty straight forward. which thing in particular are you wanting to know about?17:57
juliusbwhere 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
stekernmostly how it packs/patches it in, but a pointer to the source files where it is handled would be great17:58
juliusbyeah, 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 think18:12
juliusbbut it was a while since I was debugging the older linker internals18:12
juliusbso 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 relocations18:13
pgavinrelocations are handled in or1k-src/bfd/elf32-or1k.c18:32
pgavinit's handled pretty automatically18:33
pgavinyou just tell it what the relocs look like, (see reloc_howto_type and or1k_elf_howto_table)18:34
pgavinthe part involving where to put the immediate in the encoded instruction is handled by cgen18:34
pgavinsee cpu/or1kcommon.cpu18:34
stekernpgavin: thanks for the pointers, I'll check those out19:03

Generated by 2.15.2 by Marius Gedminas - find it at!