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