Le 05/10/2010 07:42, Graeme Russ a écrit :
On Tue, Oct 5, 2010 at 4:40 PM, Graeme Russgraeme.russ@gmail.com wrote:
On Tue, Oct 5, 2010 at 4:34 PM, Wolfgang Denkwd@denx.de wrote:
Dear Graeme Russ,
In messageAANLkTikqE0_DEqHs-tX3A4XuEXJhM0CYW_+j6izhmktw@mail.gmail.com you wrote:
Can NAND SPL initialise and size memory before loading U-Boot into RAM?
It has to. You cannot load into and run from uninitialized RAM ;-)
If so, could the relocation code be added to NAND SPL so only one copy operation is performed?
I'm afraid it cannot, due to size limitations. The NAND loader often hast to fit into as little a 2 or 4 KiB...
For x86, the actual relocation calculations can be done in a probably a few dozen bytes of code. It contains:
- One offset calculation
- A single tight loop
- Two comparisons (probably not needed in the generic case as they are used
to filter out x86 specific code outside .text)
- An offset addition
If the only constraint is space then it _may_ be possible in some scenarios (although I do acknowledge that previous trival changes have caused the size constaint to be violated)
Another alternative is to load into upper memory and have the relocation code detect that U-Boot is already there and skip the copy operation
The loader would have to know something about the way u-boot relocates itself, and this may change based on configuration.
For instance, on ARM, if either icache or dcache are configured, u-boot will reserve the upper 64 KB for TLB and thus relocate 64 KB lower than if neither icache nor dcache are configured. Ditto for VFD, LCD framebuffer, etc. Only after these allocations, and thus below them, is u-boot finally relocated.
An independent loader would thus have to figure all this out in order to know how exactly where u-boot expects to relocate, otherwise it may put u-boot at a location which would be almost, but not quite, entirely unlike the intended one -- and that's the worst possible choice, as we now hit the dreaded 'relocate over oneself' issue.
OTOH, the u-boot board.c may possibly be modified so that the the final location of the u-boot code only depend on its code size, not its configuration options. Something like, in descending order: u-boot code, data and bss; TLBs, VFDs, framebuffers, etc; malloc arena; and stack.
Regards,
Graeme
Amicalement,