[U-Boot] [PATCH 0/7] sunxi: Add support for the CHIP Pro

[Tom Rini <trini@konsulko.com>]

On Thu, Nov 10, 2016 at 12:57:09PM +0100, Heiko Schocher wrote:
> Hello Maxime,
> 
> Am 09.11.2016 um 15:44 schrieb Maxime Ripard:
> >Hi Heiko,
> >
> >On Wed, Nov 09, 2016 at 08:47:12AM +0100, Heiko Schocher wrote:
> >>Am 08.11.2016 um 17:21 schrieb Maxime Ripard:
> >>>The CHIP Pro is a SoM made by NextThing Co, and that embeds a GR8 SIP, an
> >>>AXP209 PMIC, a WiFi BT chip and a 512MB SLC NAND.
> >>>
> >>>Since the first Allwinner device coming whit an SLC NAND that doesn't have
> >>>the shortcomings (and breakages) the MLC NAND has, we can finally enable
> >>>the NAND support on a board by default.
> >>>
> >>>This is the occasion to introduce a bunch of additions needed imo to be
> >>>able to come up with a sane NAND support for our users.
> >>>
> >>>The biggest pain point is that the BROM uses a different ECC and randomizer
> >>>configuration than for the rest of the NAND. In order to lessen the number
> >>>of bitflips, you also need to pad with random data the SPL image.
> >>>
> >>>Since it's quite tedious to do right (and most users won't be able to
> >>>figure it out) and since if it is not done right, it will eventually turn
> >>>into an unusable system (which is bad UX), we think that the best solution
> >>>is to generate an SPL image that already embeds all this. We'll possible
> >>>have to do the same thing for the U-Boot image (at least for the random
> >>>padding) on MLC NANDs.
> >>>
> >>>The only drawback from that is that you need to flash it raw, instead of
> >>>using the usual nand write, but it's just a different command, nothing
> >>>major anyway.
> >>>
> >>>In order to flash it, from a device switched in FEL, on your host:
> >>>sunxi-fel spl spl/sunxi-spl.bin
> >>>sunxi-fel write 0x4a000000 u-boot-dtb.bin
> >>>sunxi-fel write 0x43000000 spl/sunxi-spl-with-ecc.bin
> >>>sunxi-fel exe 0x4a000000
> >>>
> >>>And on the board, once u-boot is running (assuming the NAND is already
> >>>erased):
> >>>
> >>>nand write.raw.noverify 0x43000000 0 40
> >>>nand write.raw.noverify 0x43000000 0x400000 40
> >>>
> >>>nand write 0x4a000000 0x800000 0xc0000
> >>>
> >>>I also encountered some weird bug in the private libgcc that prevents
> >>>U-Boot from loading. Disabling CONFIG_USE_PRIVATE_LIBGCC fixes that.
> >>
> >>What was the problem?
> >
> >It has been reported here:
> >http://lists.denx.de/pipermail/u-boot/2016-August/264513.html
> 
> Hmm.. could not find, what was the real problem ...

And since it's another area we're just borrowing kernel code for, it'd
be good to figure out what odd corner-case is going wrong somewhere and
what the fix is.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161111/1cdc6261/attachment.sig>