
Hello Eugen,
Am Mon, Oct 21, 2024 at 10:17:54AM +0300 schrieb Eugen Hristev:
Hello,
On 10/21/24 09:03, Alexander Dahl wrote:
Hello Benedikt,
Am Fri, Oct 18, 2024 at 04:19:08PM +0200 schrieb Benedikt Spranger:
On Fri, 18 Oct 2024 15:11:20 +0200 Alexander Dahl ada@thorsis.com wrote:
Hello Alexander,
Am Fri, Oct 18, 2024 at 10:30:00AM +0200 schrieb Benedikt Spranger:
OK, you might say the nand_atmel NAND driver is obsolete, but it was the only solution to get booting from NAND running. The new DM based NAND driver refused to do anything usefull, so I dropped it after spending a couple of days debugging it:
Strange. I have at least three different boards with SAMA5D27 successfully booting from NAND flash with the new DM based driver (unfortunately none of them upstreamed, which also won't change in the foreseeable future, sorry).
OK.
Do you use at91bootstrap as 2nd level bootloader like me or something else?
I use the U-Boot SPL. There is no UBI support in at91boostrap. There were some attemps, but... No interest at the at91bootstrap side.
It's not about interest. There are two main reasons: First, all open source UBI stacks are GPL. At91bootstrap is not GPL and it cannot take GPL restricted code (being MIT ). Second, all UBI stacks are huge in terms of code and memory. At91bootstrap is a second stage that should fit in 16k , 32k or 64k depending on the platform. So far this restriction could not be met by any UBI implementation. ... and yes, doing a custom in-house small UBI implementation would be challenging, and costly.
I suspected technical reasons, but nice to know it's also licensing.
(Side note: To increase robustness we considered storing bootloaders (and maybe U-Boot env) in SPI-NOR flash with longer data retention, and use UBI on raw NAND for everything else.)
Yeah, been there. Wanted at91bootstrap to boot from SPI-NOR which is _not_ Quad-SPI, and the feature request was closed with "if you wanna do it by yourself, ask our support for help". :-/
iirc at91bootstrap can boot from raw spi-nor (yes, not UBI)
Speaking of at91bootstrap 3.x and later: It can, but only if you use the QSPI port, it does not work with flexcom for example. See https://github.com/linux4sam/at91bootstrap/issues/181 for reference.
For me it was basically getting the dts for U-Boot correct, but I got that running with all U-Boot releases since 2023.04 up to 2024.10. Could you share some more detail?
I face all the trouble in SPL. And since the SPL is the essential part here (UBI support) I gave up at one point. I simply couldn't any usefull read data from the NAND flash, but all 0.
You can not store bootstrap or SPL in UBI, it must sit in first sector of raw NAND, I suppose that's how you load SPL? Did you try reading/writing raw NAND from there? I'm not familiar with SPL, does it consider dts? I could share my dts parts if that helps you.
SPL should use dts. However on at91 platforms, SPL is dangerously close to the SRAM limit where it should fit, and it has been challenging in the last years to either make it fit or remove it.
(What I do here: SoC loads at91bootstrap from raw NAND at offset 0, at91bootstrap loads U-Boot from raw NAND at some offset like 0x20000, U-Boot (proper) loads everything else from UBI.)
Either way, it is interesting to see that the U-boot proper NAND dm driver does not work without at91bootstrap. There may be NAND quirks in at91bootstrap board init that may influence this (pins resets, timing delays, etc).
Think this is a misunderstanding here. I have this combination running, and from the discussions on NAND issues on at91 on this list I think at least two developers at Microchip, too. From my understanding U-Boot proper completely (re)initializes everything required to get NAND to work. I can not speak about U-Boot SPL though, never tried that.
You can test NAND driver by booting at91bootstrap and Uboot from another medium, like sd-card. In this way, at91bootstrap will not touch NAND device, and you have a clean U-boot booted.
Lets hear what Benedikt has tried. ;-)
Greets Alex