[U-Boot-Users] How to support multiple flash sizes ?

[Wolfgang Denk]

In message <200605091250.45978.laurent.pinchart at tbox.biz> you wrote:
>
> The only place where U-Boot handles flash memory mapping is in cpu_init_f (in 
> cpu/mpc8260/cpu_init.c). The flash is mapped using CFG_OR0_PRELIM and 
> CFG_BR0_PRELIM which are compile-time constants. I can't find any flash 
> remapping code.

Please check again. Guess what  the  "PRELIM"  means.  BTW:  This  is
documented in the README.

> Where does it remap the flash after detecting its size ?

In the flash driver.

> > Why do you define a TEXT_BASE+256kB location for your environment then?
> 
> That was copied from another board's configuration file. I'd like to put the 

Never copy anything without really understanding why you need it, and
what it means for your baord.

> other boards. The monitor must be located at 0xFFF00000 and is thus at a 
> known constant offset from the *end* of the flash. As I don't know the flash 

You are wrong. You can, for example, map your flash at 0x40000000  as
well.  The  location  of the reset entry point has nothing to do with
your final flash mapping.

BTW: You may consider switching to use a low-boot  configuration  (i.
e.  0x100  reset vector). This usually has several advantages, easier
mapping and better flash use being just the most obvious.

> size at compile time, I can't define the environment address as an offset 
> from the beginning of the flash.

This can be done, too, if really necessary (which it rarely is).  See
for example the definition of CFG_FLASH_BASE for the PCU_E board. But
really:  this  is  just meant as a demonstration that such a thing is
possibe. I did NOT say that it was a good idea. Just use a sane flash
mapping. Say, you map it at 0x40000000, ok?

> Let's assume I'm using a 16MB flash chip, with options up to 128MB.
> 
> To accommodate space for the largest possible flash, I must define 
> CFG_FLASH_BASE to 0xF8000000 with a 128MB size. TEXT_BASE *must* be defined 

No. You can use any other base address as well. Let's  say,  you  use
0xF0000000, or 0xE0000000.

> to 0xFFF00000, as the processor's interrupt vectors are located at that 
> address. The flash is mapped from 0xF8000000 to 0xFFFFFFFF, but physically 

The reset vector's location has NOTHING to do with  the  final  flash
mapping.

> At bootup, the processor starts running at 0xFFF00100. This is inside the 8th 
> flash copy in its mapping, and the monitor is stored in flash at the correct 
> offset, so everything works correctly.

No. At reset, there is no mapping at all, and  the  defaults  of  the
processor  apply.  Please  re-read the relevant section in the User's
manual. At this point, no code has  been  run,  so  it  is  obviously
completely irrelevant if you will later map the flash to this address
or any other one (if this will work is a different story, but here it
is irrelevant).

> When U-Boot wants to write the environment, it will try to erase sector 
> 0xFFF40000. This leads to an error, as U-Boot knows the flash is only 16MB 
> large, and 0xFFF40000 is thus outside the flash.

This is a misconfiguration of your board. Fix it.

> Is this clearer, or is there still something you don't understand ?

Ummm... I don't think it's me who doesn't understand ;-)

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The project was large enough and management communication poor enough
to prompt many members of the team to see themselves  as  contestants
making  brownie  points,  rather  than as builders making programming
products. Each suboptimized  his  piece  to  meet  his  targets;  few
stopped to think about the total effect on the customer.
                              - Fred Brooks, "The Mythical Man Month"