From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Brezillon Date: Wed, 1 Jun 2016 15:22:06 +0200 Subject: [U-Boot] [linux-sunxi] [PATCH v2 7/7] spl: nand: sunxi: add support for NAND config auto-detection In-Reply-To: <20160601153507.2b57177f@i7> References: <1464780204-17737-1-git-send-email-boris.brezillon@free-electrons.com> <1464780204-17737-8-git-send-email-boris.brezillon@free-electrons.com> <20160601153507.2b57177f@i7> Message-ID: <20160601152206.3b3a5d7d@bbrezillon> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, 1 Jun 2016 15:35:07 +0300 Siarhei Siamashka wrote: > On Wed, 1 Jun 2016 13:23:24 +0200 > Boris Brezillon 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 > > Acked-by: Hans de Goede > > 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