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

[Eugen Hristev]

On 10/21/24 15:30, Benedikt Spranger wrote:
> On Mon, 21 Oct 2024 10:17:54 +0300
> Eugen Hristev <eugen.hristev at linaro.org> wrote:
> 
> Hi,
>    
>>>>> 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 ).
> I do not recall any issue mentioned about a license issue, when I send
> out UBI patches for the AT91boostrap over a decade ago. It was a simple
> "nice, I put it in a branch, but we do not need it."
> I followed the UBI topic in AT91bootstrap loosely after that.

The patches that I saw ( I do not recall whether they were yours or not) 
while I was maintaining the project were GPL and about 4000 LOC.
It was adding more than 12k to the size.

> 
>> Second, all UBI stacks are huge in terms of code and memory.
> OK. Maybe we have a different view on huge. The board I am supporting
> now is the successor of a AT91SAM9263 board. This (old) board use
> AT91boootstrap with UBI support. BTW: The original requirement for UBI
> support was to fit into 4k (PPC 440 bootloader).
> 
>> 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.
> OK. This need some more in depth view:
> A SPL needs UBI read support only. This support can be done in less
> then 4k, as I mentioned before. So UBI full read/write support?
> You're right. It does not fit.
> 
> Needed read support?
> It definitly fit (and works fine for over a decade).

I am glad you see you have an implementation that works. I am no longer 
maintaining that project so I cannot say anything about the possibility 
of ever merging it.

> 
>> ... and yes, doing a custom in-house small UBI implementation would
>> be challenging, and costly.
> If you look at ubispl, you got some clue, what's needed. The UBI
> support to the AT91boostrap (for the AT91SAM9263) is about ~450 LOC.
> Managable, but why should I do it, when U-Boot SPL does the job...

I can understand that. Nobody asked you to do 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.
> To be clear: The U-Boot *SPL* does not work with the NAND dm driver.
> 
> The old NAND driver does. So from a developers view I can spend some
> spare cycles on that, from a overall project view: we use the old
> driver, since it is working.

Ok, so my understanding was wrong, in fact you cannot use NAND dm in the 
SPL. It may be that there are some missing components from U-boot proper 
that are not built in (or some quirk/initialization)
So this can be looked into by the people interested, and I can 
understand that you have a solution that works for you.


> 
> Regards
>      Benedikt Spranger