From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Fri, 22 May 2015 15:51:14 +0200 Subject: [U-Boot] Proposal to add NAND-boot support for Sunxi SPL In-Reply-To: <555F00F5.8070103@ultimaker.com> References: <1432216765-8421-1-git-send-email-r.spliet@ultimaker.com> <555E1F0F.5000001@redhat.com> <555F00F5.8070103@ultimaker.com> Message-ID: <555F3452.2090400@redhat.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Roy, On 22-05-15 12:12, Roy Spliet wrote: > Hello Hans, > > Sorry for ignoring the second half of your question so far. Here's what's on my mind. > Op 21-05-15 om 20:08 schreef Hans de Goede: >> Hi Roy, >> >> 2) What is the plan to add support for loading files from nand in u-boot proper, >> so that we can get (e.g.) extlinux.conf + kernel +dtb from a /boot on nand ? > > For the full U-boot I agree we want both MMC and NAND support, regardless of where it was loaded from. From what I can tell U-boot already has UBI support. It sounds like a logical step to try and construct a proper NAND driver for U-boot that either co-exists with this SPL driver or, even better, shares code. That way, I only assume that the UBI and UBIFS layers will take care of all the rest. Ack. > The NAND framework in u-boot resembles Linux in many ways. I'm currently in doubt whether we should take Boris' driver as a starting point, or rather use something heavily reduced that re-uses this SPL code. Either way, in U-boot we can perform a clean NAND-chip detection, preferably based on DT definitions as we also use on Linux, and take care of everything proper like PLL settings and a bunch of parameters which are now hard-coded or a configuration option in sunxi-common.h. Have you seen Yassin Jaffer's work porting Boris' code to u-boot ? https://github.com/yassinjaffer/u-boot/commits/sunxi-nand Last time I mailed with Yassin (added to the Cc) he was ok with someone else picking this up and continuing with it as the does not have time to work on it. > SPL is a different story. I don't know the exact size restriction, but for A10 I've heard it might be as little as 30KB. > Current SPL with my patches and without MMC is already 23KiB. The BROM loads the SPL to a 32K sram and the stack sits in that same SRAM. Note I've some patches which switch the SPL from using a fill blown malloc to using simple-malloc.c which saves a significant amount of space, and the mmc code is not really that big, so I think we should be able to cram this all into the SPL. > I personally think we can reduce it slightly by taking out support for reading everything other than the bootloader partition from SPL (so remove non-syndrome mode, remove the random seeds table...), I agree that removing (#if 0 it for now?) non boot partition support makes sense as a space saving measure. > but it certainly doesn't leave any room for the full NAND framework to do ID-based NAND chip detection. What info do we need when we're only reading ? If the BROM can get away with a fixed way of reading the nand for booting, we should be able to make the SPL get away with it too ... I do really believe that we should be able to deal with different nand chips from a single binaries, with cheap chinese devices like the mk802 the chances are simply to big that the nand will differ from one revision to the next. > I personally think it's acceptable if NAND-SPL does not have MMC support and vice-versa. Distros already need to build and distribute a u-boot-with-spl.bin per supported board. This doubles the number of builds they have to do and the number of files they need to distribute. If at all possible I would really like to have a unified SPL binary. > For NAND, SPL is only loaded when there is no first-level bootloader found on the MMC, so I safely dare to assume U-boot isn't there. MMCs are generally not so tiny that SPL fits but U-boot doesn't. Right, this is mostly for distro / end-user convenience (and also to avoid needing to build all boards twice when preparing a pull-req). Regards, hans