On 10/21/24 15:30, Benedikt Spranger wrote:
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.
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