[U-Boot] U-Boot PXA support

[Tom Rini <trini@konsulko.com>]

On Tue, May 21, 2019 at 04:34:19PM +0200, Marek Vasut wrote:
> 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.

As I thought I had said before, I think it's really interesting how
Zephyr takes a DT and spits out a lot of static information.  Taking
that idea far enough for platforms where no, we don't need any real
run-time detection of this-or-that could be pretty interesting and
result in some real space reduction.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190521/00a0b41b/attachment.sig>