[U-Boot] [linux-sunxi] [PATCH v2 7/7] spl: nand: sunxi: add support for NAND config auto-detection

[Boris Brezillon]

On Wed, 1 Jun 2016 15:35:07 +0300
Siarhei Siamashka <siarhei.siamashka at gmail.com> wrote:

> On Wed,  1 Jun 2016 13:23:24 +0200
> Boris Brezillon <boris.brezillon at free-electrons.com> 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 <boris.brezillon at free-electrons.com>
> > Acked-by: Hans de Goede <hdegoede at redhat.com>  
> 
> 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.
> 
> 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. 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, 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 :-)

Oh, come one! I just did the test, and we save 352 bytes when dropping
the auto-detection code. Do we really want to delay the NAND support
just because you want the perfect solution (which as I already said,
will not be trivial to implement).

I'm not telling that your approach is wrong, just that it's not a
priority right now, so let's move on and improve it iteratively.


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com