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

[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.

> 
> 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)
> 
>>> 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).

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.

Eugen

> 
> Greets
> Alex