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

[Benedikt Spranger <b.spranger@linutronix.de>]

On Mon, 21 Oct 2024 10:17:54 +0300
Eugen Hristev <eugen.hristev@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.

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

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

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

Regards
    Benedikt Spranger