| --- Log opened Tue Jun 14 00:00:52 2016 | ||
| -!- Netsplit *.net <-> *.split quits: bandvig | 04: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 now | 04:38 |
| ZipCPU|Laptop | olof_: 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 mem | 07:22 |
| olof_ | Stupid linker scripts. All I want to do is say that I have 32k of memory. That's it | 07:46 |
| ZipCPU | Not familiar with linker scripts? They're really not that hard, although they haven't been very forgiving in my experience. | 07:50 |
| ZipCPU | Surely 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 configuration | 07:51 |
| olof_ | Yeah, I created a MEMORY section and a SECTIONS section | 07:51 |
| olof_ | ram (rwx) : ORIGIN = 0x0, LENGTH = 64k | 07:52 |
| olof_ | That's my MEMORY section | 07:52 |
| olof_ | I just want everything to end up there | 07:52 |
| ZipCPU | Is that line giving you any errors? Or are you struggling then with the SECTIONS section? | 07:52 |
| olof_ | That one is ok | 07:54 |
| olof_ | ah sorry. No | 07: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 |
| ZipCPU | Ok, that's simple enough, after the code line in your SECTIONS section, insert a line | 07:55 |
| ZipCPU | __bss_start = . | 07:55 |
| ZipCPU | Then 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 32MB | 07:56 |
| ZipCPU | The linker script should specify where it goes, not newlib. | 07:56 |
| olof_ | I tried ".bss : { *(.bss) } > ram", but that didn't work | 07:57 |
| ZipCPU | What error did you get? | 07:57 |
| olof_ | Same | 07:58 |
| ZipCPU | Have you defined the "__bss_start" symbol, as I suggested above? | 07:58 |
| olof_ | ah.. sorry. Missed that one. Was too busy talking :) | 07:58 |
| ZipCPU | I 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 well | 08:00 |
| olof_ | But at least it lets me compile | 08:00 |
| ZipCPU | Ok, how about "end = ORIGIN(ram) + LENGTH(ram)-1;" | 08:00 |
| olof_ | Much better | 08:01 |
| ZipCPU | I'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 clue | 08:01 |
| ZipCPU | Surely the crt0.s file would tell you ...? | 08:02 |
| olof_ | In newlib? | 08:05 |
| ZipCPU | Quite possibly. Checking now ... | 08:06 |
| ZipCPU | Ok, 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 though | 08:09 |
| olof_ | I likely want to override _or1k_board_mem_size somehow | 08: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 out | 08:12 |
| ZipCPU | Yeah ... probably. | 08:14 |
| LoneTech | iirc, it is possible to just link with a .o that has the symbols | 08:14 |
| ZipCPU | Can't be that simple: doesn't __bss_start move dependent upon how much code you have? | 08:14 |
| LoneTech | that's done by linker script, isn't it? | 08:15 |
| ZipCPU | Isn't that what we're discussing? | 08:15 |
| ZipCPU | olof_: I am also going to highly discourage you from using the NULL address for anything valid. | 08:16 |
| olof_ | LoneTech: That sounds familiar | 08:16 |
| LoneTech | right. iirc the libboard only contains one object file, with a handful of symbols for the benefit of the linker script | 08:16 |
| LoneTech | example: newlib-1.18.0/libgloss/or32/ordb2a.S | 08:16 |
| ZipCPU | At 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 |
| LoneTech | as 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 it | 08:16 |
| olof_ | I think I have created a .o now that defines the symbols | 08:17 |
| olof_ | Now how do I link it in? | 08:17 |
| LoneTech | include it on your gcc (or ld) command line | 08:17 |
| LoneTech | or archive it into a library, put it in your toolchain's lib directory as libboard-whatever.a, and use -mboard=whatever | 08:19 |
| LoneTech | been quite some time since I did this | 08: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 least | 08:22 |
| LoneTech | basically -mboard=foo does -lboard-foo | 08:26 |
| olof_ | Managed to compile now, but it doesn't seem to overrride anything yet | 08:29 |
| LoneTech | crt0.S reads from those words. where's the linker script? | 08:32 |
| LoneTech | ah, lib/ldscripts/*.x* I assume | 08:33 |
| LoneTech | though I think the linker script doesn't care that much about the end of memory, it places everything low | 08:35 |
| LoneTech | it places _end after the bss | 08:35 |
| ZipCPU | Is that where _end goes? I was wondering ever since it came up ... | 08:36 |
| LoneTech | crt0.S writes zeroes from __bss_start to end | 08:37 |
| LoneTech | so the value of _end should be a usable marker for memory required; heap and stack go above it | 08:38 |
| olof_ | The problem is here I think | 08:38 |
| olof_ | https://github.com/openrisc/newlib/blob/or1k/libgloss/or1k/crt0.S#L548 | 08:38 |
| ZipCPU | Ok, 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 find | 08:38 |
| LoneTech | _start reads _board_mem_base and _board_mem_size, sums them, and stores that as stack | 08:41 |
| LoneTech | end 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 places | 08:42 |
| LoneTech | maybe I'm looking at a very obsolete crt0 though | 08:42 |
| * LoneTech finally starts reading the linked one | 08:43 | |
| LoneTech | that symbol is renamed a more descriptive or1k_exception_stack_top | 08: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 around | 08:54 |
| LoneTech | it's not horribly complicated | 08:54 |
| ZipCPU | Shouldn'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 |
| LoneTech | the board constants say where RAM is, start and size. those are summed to place the stack at the end of ram. | 08:55 |
| LoneTech | yes, IMHO much of this should be in symbols, not data words | 08:55 |
| LoneTech | it'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 foun | 08:58 |
| olof_ | d the word in the memory at least | 08:58 |
| LoneTech | nm may be your friend | 08:58 |
| olof_ | Is there an easy way to just hack the elf file and change it? | 08:58 |
| LoneTech | well, I could make some sort of script for it using nm and objcopy.. not sure what the better way is | 09:00 |
| ZipCPU | Why 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 |
| LoneTech | why 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 this | 09:03 |
| olof_ | LoneTech: I don't know | 09:03 |
| ZipCPU | Gotta run. | 09:03 |
| olof_ | ZipCPU: Thanks for all the help | 09:04 |
| LoneTech | it should be as simple as linking with your own board object file (e.g. ordb2a.o) | 09:04 |
| LoneTech | it's also time for me to leave | 09: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 it | 09:04 |
| olof_ | ah ok. Thanks for the help | 09:04 |
| LoneTech | https://github.com/openrisc/newlib/tree/or1k/libgloss/or1k/boards suggests the symbols are even weak | 09:05 |
| LoneTech | see you later, sorry I haven't sorted it all out | 09:06 |
| olof_ | Finally! I got it | 09:07 |
| olof_ | I had to the existing -mboard option. That probably took precedence over my object file | 09:08 |
| olof_ | Unfortunately that didn't help :( | 09:10 |
| olof_ | It puts the stack just below 8MB instead | 09:10 |
| olof_ | Which is far from my 32k | 09:10 |
| olof_ | So... I wouldn't recommend using OpenRISC for anything embedded | 09:11 |
| olof_ | At least not with newlib | 09:11 |
| olof_ | I don't really need a libc though. Just thought it would be convenient to have printf | 09:15 |
| ZipCPU | juliusb: olofk: Perhaps I'm not the first, but I did register and request for a presentation spot at ORCONF2016!! | 10:56 |
| SMDwrk | ZipCPU Great! | 12:20 |
| olofk | ZipCPU: The abstract looks great. You're number three by the way... or number two if we don't count my test submission :) | 15:38 |
| ZipCPU | olofk: Thanks! | 15:48 |
| shorne | olofk: trying to get down to 32k huh? I wouldnt think its really an openrisc arch problem, seems more like toolchain | 18:18 |
| shorne | searching google now for 32k ram newlib examples | 18:19 |
| --- Log closed Wed Jun 15 00:00:54 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!