On Wed, 1 Jun 2016 13:23:24 +0200
Boris Brezillon <boris.brezil...@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.brezil...@free-electrons.com>
> Acked-by: Hans de Goede <hdego...@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 :-)
[1] http://lists.denx.de/pipermail/u-boot/2015-September/226963.html
--
Best regards,
Siarhei Siamashka
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
