On Thu, Oct 4, 2012 at 2:23 PM, Julius Baxter <[email protected]> wrote: > 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.
Sorry, which _are_ likely to be stand alone applications. Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
