On Wed, 1 Jun 2016 15:35:07 +0300 Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
On Wed, 1 Jun 2016 13:23:24 +0200 Boris Brezillon boris.brezillon@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@free-electrons.com Acked-by: Hans de Goede hdegoede@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.