From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Tue, 21 May 2019 16:03:30 +0200 Subject: [U-Boot] U-Boot PXA support In-Reply-To: References: <20190506132604.GQ31207@bill-the-cat> <1d1f058fea839eb19f85d6e89c03e2515db74a83.camel@toradex.com> <6f0369b56bf7c431d14698798ce7b20950d77b07.camel@toradex.com> <3eeda2c9-da1c-9a0d-58e4-409aa024013d@denx.de> Message-ID: <9f2fa2c6-83eb-227b-e7fc-da862fb2de91@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 5/21/19 3:47 PM, Alex Sadovsky wrote: > On 21/05/2019, Marek Vasut wrote: >> On 5/21/19 11:50 AM, 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). >>> >>> 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... >> >> Do you want to step up and help maintain these platforms ? >> The real problem is maintainer overload and that's what this solves, it >> reduces the workload on maintainers. The legacy code needs to be updated >> and retested, and it seems there's just no interest in that. If there is >> someone who's willing to stick around for some time and take care of >> those platforms, great. > Of course I understand the maintainers' load. If PXA support (or > anything other that I'm using) is an obstacle in its current form and > should be fixed (e.g. ported to newer APIs), I have interest in > providing patches to fix it. You can always Cc: me in case of > ARMv5/PXA-related questions, although I can test only the hardware > that I have (probably this comment was too obvious). We need more people to implement and review those patches :) > My point was about pro-active removal (i.e. removal of the code that > isn't a definite obstacle yet) and about judging about the code > usefulness only by the age of last changes (there are somehow stable > things after all). > > Of course I'm not against the removal of such things that are broken > && nobody fixes them for some time. See above -- Best regards, Marek Vasut