[U-Boot-Users] Running u-boot from Flash itself
Hi, I'm woriking on a custom MPC8540 board. I configured L2 cache as SRAM and I'm able to relocate u-boot to L2 SRAM and run it. Is there any way to run u-boot from flash itself, (i.e) relocating only the R/W sections? I tried to relocate the u-boot from the end of rotext(_erotext in the .lds file). But the global variable addresses still shows flash address. I guess updating register R30 will point to the correct address, and it is done in these statements? /* First our own GOT */ add r14, r14, r15 /* the the one used by the C code */ add r30, r30, r15
Is there any other modifications do I need to run from flash? First of all is this possible?
--Thanks, Selva
In message f1ed94ed0611131034l507e63c1j68ef0b4fe57109c7@mail.gmail.com you wrote:
SRAM and I'm able to relocate u-boot to L2 SRAM and run it. Is there any way to run u-boot from flash itself, (i.e) relocating only the R/W sections? I tried to relocate the u-boot from the end of
Why would you want to do this?
Is there any other modifications do I need to run from flash? First of all is this possible?
It is possible, but it makes no sense to me. Remember that with most flash chips it is impossible to erase or porogram the flash and read normal data from it at the same time. So you would either lose all flash programming features (including savceenv etc.), or you would have to create flash code that get's relocated to RAM for execution - it's much easier to relocate everything.
Best regards,
Wolfgang Denk
On 11/13/06, Wolfgang Denk wd@denx.de wrote:
In message f1ed94ed0611131034l507e63c1j68ef0b4fe57109c7@mail.gmail.com you wrote:
Is there any other modifications do I need to run from flash? First of all is this possible?
It is possible, but it makes no sense to me. Remember that with most flash chips it is impossible to erase or porogram the flash and read normal data from it at the same time. So you would either lose all flash programming features (including savceenv etc.), or you would have to create flash code that get's relocated to RAM for execution - it's much easier to relocate everything.
Actually, the avr32/atstk1000 port does run directly from flash. It sets up different VMA and LMA addresses for the writable sections in the linker scripts and copies the data section from flash to RAM in the early startup code.
Flash programming is handled by putting certain functions into a .flashprog section which is loaded into the icache and locked.
As for the usefulness of it....well, I'm quite frankly not sure. It does mean that certain features won't work without some modifications (e.g. the FAT filesystem and the networking code bloat the .bss something awful, making it not fit in the internal RAM on AP7000) and the standard flash drivers can't be used. Both of these problems are fixable though, and running directly from flash means less copying and therefore possibly faster bootup time. Sure, reading from flash is often slower than reading from RAM, but that's what the caches are for.
Even though I might submit patches to de-bloat the FAT and networking code (zeroing out a 200K section isn't _that_ expensive, but it isn't exactly free either, and it may have a negative effect on the boot time) I'll probably add relocation support to the avr32 code first.
Haavard
In message 1defaf580611140302h3d2717f2o8ad840390d64c897@mail.gmail.com you wrote:
Actually, the avr32/atstk1000 port does run directly from flash. It sets up different VMA and LMA addresses for the writable sections in the linker scripts and copies the data section from flash to RAM in the early startup code.
Flash programming is handled by putting certain functions into a .flashprog section which is loaded into the icache and locked.
As for the usefulness of it....well, I'm quite frankly not sure. It
Arghhhhh.... you really don't want to do that. At least I don't want you to do that.
May I please ask you to change the AVR code such that it works the same way as U-Boot works on all other architectures?
I don't want to have such a divergence in design philosophy. I apologize that I did not notice this earlier (so I could have rejected this code right from the beginning).
Best regards,
Wolfgang Denk
On 11/14/06, Wolfgang Denk wd@denx.de wrote:
Arghhhhh.... you really don't want to do that. At least I don't want you to do that.
I sort of suspected you would say something like that ;)
May I please ask you to change the AVR code such that it works the same way as U-Boot works on all other architectures?
Sure. I'll try to get it done within the next couple of days.
I don't want to have such a divergence in design philosophy. I apologize that I did not notice this earlier (so I could have rejected this code right from the beginning).
Yeah, I'm sorry I didn't really think about it myself as a major diversion. The avr32 code has evolved through a few prototypes where it made sense to do it this way due to very restricted resources. I though I'd gotten rid of most of the peculiarities, but I guess I left a few.
I'll send you a pull request when it's done.
Haavard
participants (3)
-
Haavard Skinnemoen -
Selvamuthukumar V -
Wolfgang Denk