From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Tue, 21 May 2019 10:50:30 -0400 Subject: [U-Boot] U-Boot PXA support In-Reply-To: <1b0dea32-fbab-9b74-fd86-595f10853dbe@denx.de> References: <20190506132604.GQ31207@bill-the-cat> <1d1f058fea839eb19f85d6e89c03e2515db74a83.camel@toradex.com> <6f0369b56bf7c431d14698798ce7b20950d77b07.camel@toradex.com> <233e768bbc3a33aca8ef9d4ec3520ce71cc8895f.camel@toradex.com> <10cff9fb7044fd0f1964411a10f4b720ca3d74f3.camel@toradex.com> <1b0dea32-fbab-9b74-fd86-595f10853dbe@denx.de> Message-ID: <20190521145030.GI22232@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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: