[U-Boot] Proposal to add NAND-boot support for Sunxi SPL

[Hans de Goede]

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