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