From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Mon, 02 Jun 2008 14:06:27 -0500 Subject: [U-Boot-Users] [PATCH 8/8] New board SIMPC8313 support: nand_boot.c, sdram.c, simpc8313.c In-Reply-To: <200806022043.26243.sr@denx.de> References: <587822.81594.qm@web83501.mail.sp1.yahoo.com> <200805311511.28106.sr@denx.de> <20080602164835.GA3513@loki.buserror.net> <200806022043.26243.sr@denx.de> Message-ID: <484444B3.9070508@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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