[U-Boot] [PATCH 1/4] Use absolute addressing for mpc85xx boot page

[Trent Piepho]

On Tue, 14 Oct 2008, Wolfgang Denk wrote:
> In message <1223941151-13969-1-git-send-email-tpiepho at freescale.com> you wrote:
>> The boot page and reset vector need to be at the absolute address
>> 0xfffff000 and 0xfffffffc, respectively, when the CPU boots.
> ...
>> To handle to both different U-Boot image sizes and flash locations, what we
>> do is take the upper bits of the boot page from the location of .text and
>> the lower bits are taken from the absolute address 0xfffff000.  How many
>> bits to take depends on the size of the flash bank.  In effect the upper
>
> I would like to point out that it is essential that the code must  be
> able  to handle the situation where the flash bank size is unknown at
> compile time, and becomes known anly at runtime when the flash driver
> probes the actual flash size on the board.

This is an issue for how the local bus controller is programmed and has
nothing to do with my patch.

>> The bss segment should go after the end of the u-boot image.  Which is only
>> at the fixed address 0 for platforms that don't remap flash.  For those
>
> I'm not sure what you mean here. Bss becomes significant only after
> relocation to RAM. By then, it must be located in a valid RAM area.
> "fixed address 0" is no such valid address.

One way to avoid editing the linker script when changing the image size is to
*link* u-boot with bss at 0.  But that only works for boards that have have
*linked* the boot page at 0xffff_f000, it doesn't work for boards, like
mpc8572ds, that link the boot page at 0xefff_f000.  The way I find address to
link bss at works for all boards.

>> -  .bootpg ADDR(.text) + 0x7f000 :
>> +  __flash_mask = 128M - 1;
>
> Does the linker actually understand the "128M" notation? Interesting -
> I didn't know that.

If it didn't understand the notation, I sure wouldn't have tested my patches
very well!  I'm using this on mpc8572ds hardware now.  I tested the other
platforms and verified that the u-boot image remains unchanged, as it should.

> But - where is the number coming from? I guess that's a hard-wired
> flash size for this specific board?
>
> This is bad, for two reasons: it means we have to maintain the same
> data in several places (in the linker script plus in the board config
> file), and second, we cannot handle boards where several size options
> exist.

This data doesn't exist in the board config file.  The linker scripts already
in effect contain this data.  I have a calculation that uses the flash bank
size.  What's there now is the result of a calculation that uses the flash
bank size.  Change the flash mapping and the result changes.  The existing
scripts depend on the flash mapping just as much as mine does, if not more.

Which is not that much of a dependency really.  If you look at the comments to
the patch, it's only an issue in certain extreme cases that current don't
exist.