On Thu, Oct 4, 2012 at 12:51 PM, R. Diez <[email protected]> wrote: > > >>This way users can override them in their applications >> if desired. >> [...] >> +.weak _board_mem_base >> +.weak _board_mem_size >> +.weak _board_clk_freq > > Is making those symbols weak the right solution? That would fix the RAM size > at compilation time, wouldn't it? > > I already encountered this issue when generating test suite executables and > running them against different simulators. I had to change the RAM size once > for one of the simulators, and I had to build new test executables just for > that reason. > > Would it be possible to change the memory layout for the OpenRISC boards, so > that the stack area comes first, and the RAM afterwards? The idea is to have > a single binary which does not depend on the target's RAM size. There should > be a minimum required RAM size, but after starting up, the application could > call some routine and set the highest available RAM address, maybe after > inspecting the system it's running on. > > At the moment, the stack is at the top of the RAM, which makes it hard to > keep the RAM size flexible.
Why not change the linker script to allocate a sane amount of memory space for stack and place this area after the data RAM? This then introduces a minimum RAM size that the executable is compatible with. Remember, this is just for libgloss-based executables, which are not likely to be stand alone and not very big. Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
