Hi, On Wed, Jun 01, 2016 at 03:35:07PM +0300, Siarhei Siamashka wrote: > On Wed, 1 Jun 2016 13:23:24 +0200 > Boris Brezillon <[email protected]> wrote: > > > NAND chips are supposed to expose their capabilities through advanced > > mechanisms like READID, ONFI or JEDEC parameter tables. While those > > methods are appropriate for the bootloader itself, it's way to > > complicated and takes too much space to fit in the SPL. > > > > Replace those mechanisms by a dumb 'trial and error' mechanism. > > > > With this new approach we can get rid of the fixed config list that was > > used in the sunxi NAND SPL driver. > > > > Signed-off-by: Boris Brezillon <[email protected]> > > Acked-by: Hans de Goede <[email protected]> > > We can also have these NAND parameters stored in the SPL header and > added there by a NAND image builder tool. This may save some precious > space in the SPL and also improve the reliability of detection.
So you want to favour a solution that hardcodes the NAND configuration over a solution that runtime-detects what it needs? I think we are aiming for two very different use-cases: we want to have everything working ahead of time on various NAND chips during production, you want to have the end-users being able to reflash something after the production. Boris' solution address both use-cases, yours address only the latter. > Yes, this brings the necessity of the image builder tool into the > spotlight (something that converts the "u-boot-sunxi-with-spl.bin" > to a NAND image) but this has always been a problem. I know you like it a lot, but I don't see how u-boot-sunxi-with-spl.bin is relevant here. It's an image that has always been built for the MMC. We are talking about the NAND here, that will use a different image format anyway to deal with the randomizer and the ECC, that will have to use redundancy for the SPL, U-Boot and probably environment images, that will have to be padded with random data, and doesn't want to waste the useless (on NAND) padding that is used in that image. > We have some > ongoing discussion about this in the linux-sunxi mailing list: > https://groups.google.com/forum/#!topic/linux-sunxi/HsWRG-nuV-w > > It also makes a lot of sense to have the NAND support functionality > enabled in the SPL for all sunxi boards by default On all the sunxi boards that have NAND at least. > so the code size does matter. We still do have the runtime > decompression opportunity as the strategic reserve [1], which should > provide additional 4 or 5 KiB of space for the code. Still we need > to be very careful about using up this reserve, to ensure that it is > well spent on something useful (such as NAND support) instead of > being just wasted by the bloatware cultists :-) Good thing we are talking about NAND support and not some bloat then :) Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
