[U-Boot-Users] [PATCH 8/8] New board SIMPC8313 support: nand_boot.c, sdram.c, simpc8313.c

[Scott Wood <scottwood@freescale.com>]

Stefan Roese wrote:
> On Monday 02 June 2008, Scott Wood wrote:
>> but even then I'd 
>> rather use the space for things like SPD-based SDRAM initialization.
> 
> Are you talking about a full-blown I2C SPD DIMM detection and 
> autoconfiguration? The code I know from 4xx is much too complicated and big 
> for a 4k NAND booting image.

Yeah, it may not be possible; my point was more along the the lines of 
if I were going to spend effort to squeeze in some bit of complex code, 
it wouldn't be the fully generic NAND driver with all the API glue.

>> The NAND controller on the 8313 exposes a very different programming
>> interface than what nand_spl expects.  I don't think there's much that
>> could be re-used, other than the high-level functions like nand_load().
> 
> Isn't there a chance to change those NAND handling functions (like 
> nand_read_page()) in nand_boot.c to be more flexible, that they can be used 
> by "different" NAND drivers too? Could be that we need to simplify the 
> current implementation somehow. Perhaps to use something as you did in your 
> implementation like nand_read_next_block() instead of this nand_read_page(). 
> Addressing arbitrary blocks/pages seems not needed and could cut down the 
> current code quite a bit.

Possibly -- but the code in nand_command() and nand_read_page() is 
pretty much entirely inapplicable to the elbc fcm nand controller.  The 
programming interface of elbc fcm is higher level than that.

We can share nand_load(), but that's about it.

> I would really like to avoid that all newer NAND booting platforms (and I 
> expact there will come more and more in the near future), to implement their 
> own NAND loading routines.

Agreed -- but at the very least we'll need a couple different 
implementations of nand_read_next_block().

-Scott