[PATCH 0/5] collected fallout of porting an ATSAMA5D27 based board

[Alexander Dahl]

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 at 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