On Sun, Apr 8, 2012 at 6:33 AM, Julius Baxter <[email protected]> wrote: > --- > arch/openrisc/cpu/cpu.c | 4 +++- > arch/openrisc/cpu/start.S | 13 ++++++++----- > 2 files changed, 11 insertions(+), 6 deletions(-) >
Hi Sorry, I should have explained this better in the comment. Basically I found that when compiling an image to be run out of flash on the ml501 based on the upstream code, things didn't work with either of the compiler ports we have currently (the existing one, and the new one Pete Gavin and I have been playing with.) The old tool chain linked OK but didn't run properly - and the new tool chain fails at linking. This was due to the symbols for _start, _exception_handler and __reset being a long way away (I believe in the case of _start, we're executing flash in 0xf0000000 and needed to jump to wherever in RAM we relocated to, and a PC-relative relocation couldn't cut it (this never worked, actually, in the code I submitted upstream, for XIP from flash, anyway, on ml501.) I'm not sure about the case of _exception_handler or __reset if the relocations were too large, but to be safe these were also changed to absolute values instead of PC-relative values (the new linker complained when linking them, anyway, so I presume they need to be absolute jumps.) With this change, and the other I've posted which is fixing a bug relating to an error in the calculation of the stack area, the ml501 image boots and runs in the simulator. Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
