On Wed, 1 Jun 2016 15:35:07 +0300 Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
> 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 :-) 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 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
