[U-Boot] U-Boot PXA support

Marek Vasut marex at denx.de
Tue May 21 14:34:19 UTC 2019


On 5/21/19 4:29 PM, Marcel Ziswiler wrote:
> On Tue, 2019-05-21 at 14:49 +0200, Marek Vasut wrote:
>> On 5/21/19 12:33 PM, Marcel Ziswiler wrote:
>>> On Tue, 2019-05-21 at 12:50 +0300, Alex Sadovsky wrote:
>>>> It's slightly off-topic but I wonder whether this ongoing
>>>> deprecation
>>>> of ARMv4 and ARMv5 (first in GCC, then in U-Boot) really
>>>> simplifies
>>>> anything at all.
>>>> There are tons of devices that are still working good and there
>>>> are
>>>> even ARMv5-based MCUs that are still produced (such as CH561
>>>> manufactured by WCH).
>>>
>>> Please note that as of today Marvell is also still producing them
>>> PXAs
>>> which are not to go end-of-life before later next year I believe.
>>>
>>>> IMHO it makes sense to drop only the XScale-specific tuning first
>>>> and
>>>> to treat PXA (and similar CPUs) as a more generic armv5te. I
>>>> wonder
>>>> what to do when GCC drops ARMv5 completely...
>>>
>>> I believe it was only an issue with early gcc 8 but does work just
>>> fine
>>> again with later 8.2 or 8.3 versions.
>>>
>>> However, what is more concerning to me is that in today's
>>> convoluted
>>> moloch known as U-Boot there may simply not be any space any more
>>> for
>>> something truly embedded but somewhat limited like PXA based
>>> hardware.
>>
>> If we ignore the PXA25x/26x, the PXA27x has loads of SRAM for U-Boot
>> SPL
>> and then can load U-Boot proper into DRAM. What's the problem ?
> 
> At least on the Colibri PXA270 it is more about NOR flash storage. The
> factory configuration block gets stored at an offset of 0x40000 which
> leaves only 256 KB for the boot loader. However, of course one could
> migrate it all over to using SPL and store U-Boot proper after the
> factory configuration block. But to change all that for our very oldest
> module which is going end-of-live the next year may not make too much
> sense.

True

> So the real issue with U-Boot for such platforms is basically that the
> complexity and footprint increased steadily leaving them behind and
> eventually just removing them may be the logical conclusion. After all
> we are talking about just a boot loader which is used to boot the
> "real" system and good is. However, if even one percent of today's U-
> Boot is actually used for booting it is probably already quite a lot
> (;-p).

The size growth is a problem, even for todays' systems, and it
contradicts this "universal" part in U-Boot . That's a real issue which
should be addressed , and this fevered push for DM/DT conversion does
not help at all.

-- 
Best regards,
Marek Vasut


More information about the U-Boot mailing list