[U-Boot] [PATCH 0/4] Convert MPC85xx platforms to a single linker script

[Trent Piepho]

On Wed, 15 Oct 2008, Wolfgang Denk wrote:
> In message <Pine.LNX.4.64.0810141231490.3705 at t2.domain.actdsltmp> you wrote:
>>
>> All the mpc85xx platforms hard code the size of the flash via the local bus
>
> No, they don't.

Name one that doesn't.

>> controller settings.  For example, if you look in include/configs/MPC8572DS.h
>> you will find these lines:
>>
>> #define CFG_BR0_PRELIM          0xe8001001
>> #define CFG_OR0_PRELIM          0xf8000ff7
>
> Mind the "PRELIM" part in that names. PRELIM as in PRELIMINARY.

For all the Freescale mpc85xx platforms, PRELIM also means final.  But even
for something like tqm85xx, this preliminary mapping is compiled in, is it
not?  This compiled in mapping is the one that must be taken into account when
linking the u-boot image.  Trying changing the BR0 value for tqm85xx and not
editing the boot script and see what happens.  Doesn't work.  Then try using
my boot script and see what happens.  Does work.

>> you'd be running from the flash you just re-mapped, that makes things a little
>> more interesting.  Then you could do a CFI query to the base of that mapping
>> to get the bank size, then resize the mapping to the correct value.  I'm not
>> sure how to figure out the port size.  Maybe one could try 8, 16 and 32 bit
>> ports and see which one worked, but that sounds a little iffy.  Actually, I
>
> You might want to have a look at the CFI driver, then.

I'm not seeing where it programs the local bus controller while u-boot is
running from flash.

>> think this must be in the cpu reset strapping somewhere, otherwise how would
>> it boot?
>>
>> But again, this has nothing to do with my patch.  I'm just improving the way
>> the linker script works.  If you want to talk about how the local bus
>> controller is programmed, can we have another thread please?  Something like
>> "TODO: dynamically determine Freescale eLBC parameters at run time".
>
> We are talking about your patches here, which claim to cover "all
> MPC85xx" boards.

You're talking about dynamically programming the local bus controller.  My
patches have nothing to do with that.

>>> But in the patch you submit you hard-wire certain flash  bank  sizes
>>> into the linker scriopts, don't you?
>>
>> Not really.  I'm calculating the boot page location in a better way.
>
> Now what. First you say you do, then you say you don't?

First of all, the boot scripts already have the boot flash bank location and
size hardwired in.  Secondly, it doesn't really matter.  It only makes a
difference in certain extreme situations of a very small flash bank mapped in
an unusual manner or a very very large u-boot image.

>> The expression from tqm85xx will let you change the image size without being
>> edited.  Why not use that one then?  Suppose you decide to change the location
>
> He. Funny that you come up with that example.
>
>> of the flash bank?  Then it won't work, unless you edit the linker script.
>
> "Change the location of the flash bank" - what exactly do you mean by
> that?

Change CFG_BR0_PRELIM (and probably also TEXT_BASE and CFG_FLASH_BASE too).

>> create a broken image (that is 8MB+ in size).  If you want to support a board
>> with a 2 MB flash bank with the mpc8540eval style script, you need to copy the
>> entire linker script and edit it.  With my method method, you can create a two
>> line script:
>> __flash_mask = 2M - 1;
>> INCLUDE cpu/mpc85xx/u-boot.lds
>
> And what do I do with a board that can have 2, 4, 8, 16, 32 or 64  MB
> of flash?

Same thing as now.  You have to pick values for CFG_B/OR0_PRELIM, FLASH_BASE
and TEXT_BASE.  You can almost certainly just use cpu/mpc85xx/u-boot.lds,
unless you've chosen very odd values for BR0/OR0/TEXT_BASE.  In that case can
you make the two line custom script from above, and set __flash_mask based on
what you chose for B/OR0.

>> This is what my patch is for.  Letting all existing 85xx boards use one
>> script.  And if a board is created that can't use the script alone, it can be
>> handled easily, re-using the common script without duplicating any code.
>> Clearly this is an improvement over how things work now, is it not?
>
> I'd be happy if that works, but somehow you don't add the missing
> pieces of explanation I'm looking for.

How does it not work?  Programming the local bus controller has nothing to do
with my patch in any way.

Did you actually look at the patch?  You're going on about how the local bus
controller is programmed, doing CFI querying while u-boot is still running out
of the boot flash bank, the image can't be linked with bss at 0 and all these
things that have nothing what so ever to do with my patch.