Graeme Russ wrote: > Hi All, > > I've been thinking about where U-Boot runs in memory on my sc520 > based board and it appears that it is always executing from ROM and > I started pondering if I should attempt to relocate U-Boot into RAM.
Yes. All u-boot ports that I am aware of relocate themselves and run out of RAM. > Note: Please correct me if I am mistaken and U-Boot does indeed run > from RAM on i386 / sc520 It should. This may be the next layer of your onion. > This, of course, would give me the benefit of having unfettered access > to the flash that U-Boot is located on for things like environment > storage, upgrade in place etc. > > My thought is to not actually 'Relocate' U-Boot but to use a very > handy feature of the sc520 - The ability to map the BOOTCS (Boot ROM > Chip Select) to anywhere in memory using a PAR (Programmable Address > Region). I'm not competent to help/advise you on your sc520 BOOTCS feature, but would suggest that staying in the mainstream will be much easier in the long term. The mainstream is to use the existing code to block copy u-boot to RAM, do some relocation fixups, and then run out of RAM. [snip] > One problem I can think of is that the linker will point all the jump > labels into RAM - not an issue for the 16-bit code which uses relative > jumps, but I think I may run into issues during the real to protected > mode transition (far jump) which, by definition, has to happen before > I get access to the full memory space. How do I tell the linker that > these jumps should target 0x38040000+ and not 0x08040000+ ? I'm not sure how this works for u-boot on an x86 target. Fully relocatable is the preferable link policy. IIRC, usually x86 programs can be linked to be fully relocatable - the code can exceed +/-32K and still work, as long as each call is within +/-32K of the target label. There is a small piece of u-boot that runs in ROM that copies it to RAM and then does a jump to it. This will have to be a far jump in x86. I also recall that the transition from reset mode to full 32 bit mode is a real PITA (was there once, don't care to return ;-), but I would expect that already exists in the u-boot x86 port. Actually, I would expect the transition to "protected" mode and the jump to RAM are one and the same. Otherwise your execution location has to be fixed (in RAM) - it seems like some targets (arm?) have this limitation. > Does all this sound logical? viable? sensible? practical? > > Regards, > > Graeme Good luck, gvb _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
