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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
