IRC logs for #openrisc Tuesday, 2016-06-14

--- Log opened Tue Jun 14 00:00:52 2016
-!- Netsplit *.net <-> *.split quits: bandvig04:26
olof_If I only have 32k RAM, do I need some special linker script to avoid gcc putting things at higher addresses?04:37
olof_Having trouble with the DDR2, so I'm using block RAM for now04:38
ZipCPU|Laptopolof_: Are you using an MMU as well, or just physical memory?  If just physical memory, then yes, I think you will need to adjust your linker script.07:00
olof_Just physical mem07:22
olof_Stupid linker scripts. All I want to do is say that I have 32k of memory. That's it07:46
ZipCPUNot familiar with linker scripts?  They're really not that hard, although they haven't been very forgiving in my experience.07:50
ZipCPUSurely you have a MEMORY section at the top that specifies how much memory you have, and where it is located?07:51
olof_I've used linker scripts before, but not often enough to remember how to setup a minimal configuration07:51
olof_Yeah, I created a MEMORY section and a SECTIONS section07:51
olof_ram (rwx) : ORIGIN = 0x0, LENGTH = 64k07:52
olof_That's my MEMORY section07:52
olof_I just want everything to end up there07:52
ZipCPUIs that line giving you any errors?  Or are you struggling then with the SECTIONS section?07:52
olof_That one is ok07:54
olof_ah sorry. No07:54
olof_I get /opt/or1k-elf/lib/gcc/or1k-elf/4.9.2/../../../../or1k-elf/lib/crt0.o: In function `_or1k_start':07:55
olof_(.text+0x18): undefined reference to `__bss_start'07:55
ZipCPUOk, that's simple enough, after the code line in your SECTIONS section, insert a line07:55
ZipCPU__bss_start = .07:55
ZipCPUThen place your BSS memory following.07:55
olof_I think the reason why I want a linker script at all is because newlib tries to write something (stack? heap?) just below 32MB07:56
ZipCPUThe linker script should specify where it goes, not newlib.07:56
olof_I tried ".bss : { *(.bss) } > ram", but that didn't work07:57
ZipCPUWhat error did you get?07:57
ZipCPUHave you defined the "__bss_start" symbol, as I suggested above?07:58
olof_ah.. sorry. Missed that one. Was too busy talking :)07:58
ZipCPUI don't know if the line needs a semicolon or not, but judging from my own linker file all my symbol assignment lines also end in semicolons.07:59
olof_Cool. Now I just got this one /opt/or1k-elf/lib/gcc/or1k-elf/4.9.2/../../../../or1k-elf/lib/crt0.o: In function `_or1k_start':08:00
olof_(.text+0x20): undefined reference to `end'08:00
olof_It feels wrong to set that one to '.' as well08:00
olof_But at least it lets me compile08:00
ZipCPUOk, how about "end = ORIGIN(ram) + LENGTH(ram)-1;"08:00
olof_Much better08:01
ZipCPUI'm not familiar with how the "end" symbol is being used, though.  Is it being used to specify the end of all RAM, or just the end of your program and where your heap should begin?08:01
olof_Haven't got a clue08:01
ZipCPUSurely the crt0.s file would tell you ...?08:02
olof_In newlib?08:05
ZipCPUQuite possibly.  Checking now ...08:06
ZipCPUOk, I don't seem to have the OR1k version of newlib, so ... sorry, I can't check.  ;)08:08
olof_That gave me some ideas though08:09
olof_I likely want to override _or1k_board_mem_size somehow08:09
olof_How do I override them? Do I have to create a new libboard?08:10
olof_Ahh.. this is probably dead simple once I figure it out08:12
ZipCPUYeah ... probably.08:14
LoneTechiirc, it is possible to just link with a .o that has the symbols08:14
ZipCPUCan't be that simple: doesn't __bss_start move dependent upon how much code you have?08:14
LoneTechthat's done by linker script, isn't it?08:15
ZipCPUIsn't that what we're discussing?08:15
ZipCPUolof_: I am also going to highly discourage you from using the NULL address for anything valid.08:16
olof_LoneTech: That sounds familiar08:16
LoneTechright. iirc the libboard only contains one object file, with a handful of symbols for the benefit of the linker script08:16
LoneTechexample: newlib-1.18.0/libgloss/or32/ordb2a.S08:16
ZipCPUAt one time I put all my peripherals, starting at zero, and then had a program go ... wild on me.  My flash has never been the same since.08:16
LoneTechas it's actually linked in because of those symbols, you can make your own variant of the object file to link explicitly as a simple way of overriding it08:16
olof_I think I have created a .o now that defines the symbols08:17
olof_Now how do I link it in?08:17
LoneTechinclude it on your gcc (or ld) command line08:17
LoneTechor archive it into a library, put it in your toolchain's lib directory as libboard-whatever.a, and use -mboard=whatever08:19
LoneTechbeen quite some time since I did this08:19
olof_same here. I looked at the ordb2a.S you linked to, and apparently I wrote that one :)08:22
olof_So I used to know how to do it at least08:22
LoneTechbasically -mboard=foo does -lboard-foo08:26
olof_Managed to compile now, but it doesn't seem to overrride anything yet08:29
LoneTechcrt0.S reads from those words. where's the linker script?08:32
LoneTechah, lib/ldscripts/*.x* I assume08:33
LoneTechthough I think the linker script doesn't care that much about the end of memory, it places everything low08:35
LoneTechit places _end after the bss08:35
ZipCPUIs that where _end goes?  I was wondering ever since it came up ...08:36
LoneTechcrt0.S writes zeroes from __bss_start to end08:37
LoneTechso the value of _end should be a usable marker for memory required; heap and stack go above it08:38
olof_The problem is here I think08:38
ZipCPUOk, that makes a lot of sense ... now.  But ... shouldn't stack go *below* end?08:38
olof_That's the only reference to mem_size that I can find08:38
LoneTech_start reads _board_mem_base and _board_mem_size, sums them, and stores that as stack08:41
LoneTechend is the end of statically allocated stuff, i.e. stuff the linker is placing. stack is outside of that, growing down, and in multithreaded things may be in multiple places08:42
LoneTechmaybe I'm looking at a very obsolete crt0 though08:42
* LoneTech finally starts reading the linked one08:43
LoneTechthat symbol is renamed a more descriptive or1k_exception_stack_top08:44
olof_Why is it so horribly complicated to set up the stack pointer? It looks like things are just being added and subtracted and moved around08:54
LoneTechit's not horribly complicated08:54
ZipCPUShouldn't it just be as simple as ... setting it?  With the ZipCPU, the linker determines the stack address, and crt0 just sets the value.08:54
LoneTechthe board constants say where RAM is, start and size. those are summed to place the stack at the end of ram.08:55
LoneTechyes, IMHO much of this should be in symbols, not data words08:55
LoneTechit's a little odd to have crt0 calculate some of these things, like it doesn't actually want ram size, only end.08:56
olof_Aha! Now I foun08:58
olof_d the word in the memory at least08:58
LoneTechnm may be your friend08:58
olof_Is there an easy way to just hack the elf file and change it?08:58
LoneTechwell, I could make some sort of script for it using nm and objcopy.. not sure what the better way is09:00
ZipCPUWhy would you want to hack the ELF file?  That sounds very ... non-portable, and unmaintainable?09:02
olof_If I only good override the damn symbol!!09:02
LoneTechwhy can't you?09:03
olof_ZipCPU: This was supposed to be a quick hack to avoid having to deal with the DDR2 controller right now, but I have spent all day on this09:03
olof_LoneTech: I don't know09:03
ZipCPUGotta run.09:03
olof_ZipCPU: Thanks for all the help09:04
LoneTechit should be as simple as linking with your own board object file (e.g. ordb2a.o)09:04
LoneTechit's also time for me to leave09:04
olof_LoneTech: I have created a simple .S file that just defines the symbol. I turn it into an object file and try to link it09:04
olof_ah ok. Thanks for the help09:04
LoneTech suggests the symbols are even weak09:05
LoneTechsee you later, sorry I haven't sorted it all out09:06
olof_Finally! I got it09:07
olof_I had to the existing -mboard option. That probably took precedence over my object file09:08
olof_Unfortunately that didn't help :(09:10
olof_It puts the stack just below 8MB instead09:10
olof_Which is far from my 32k09:10
olof_So... I wouldn't recommend using OpenRISC for anything embedded09:11
olof_At least not with newlib09:11
olof_I don't really need a libc though. Just thought it would be convenient to have printf09:15
ZipCPUjuliusb: olofk: Perhaps I'm not the first, but I did register and request for a presentation spot at ORCONF2016!!10:56
SMDwrkZipCPU Great!12:20
olofkZipCPU: The abstract looks great. You're number three by the way... or number two if we don't count my test submission :)15:38
ZipCPUolofk: Thanks!15:48
shorneolofk: trying to get down to 32k huh? I wouldnt think its really an openrisc arch problem, seems more like toolchain18:18
shornesearching google now for 32k ram newlib examples18:19
--- Log closed Wed Jun 15 00:00:54 2016

Generated by 2.15.2 by Marius Gedminas - find it at!