[U-Boot] U-Boot PXA support
Hey folks,
I'm attempting, again, to see what we need to do in order to use gcc-8.x for U-Boot and ran into, again: https://patchwork.ozlabs.org/patch/920329/ which in short is that when using -mcpu=xscale gcc-8.x throws an odd error: cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch [-Werror]
Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which suggests perhaps something broke in upstream gcc. Looking at the kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that leads to different failures (seen here with gcc-7.3): CC drivers/usb/gadget/pxa25x_udc.o {standard input}: Assembler messages: {standard input}:779: Error: selected processor does not support `pld [lr]' in ARM mode {standard input}:1201: Error: selected processor does not support `pld [r7]' in ARM mode {standard input}:2519: Error: selected processor does not support `pld [r3]' in ARM mode {standard input}:2796: Error: selected processor does not support `pld [r3]' in ARM mode
So, what should we do about this? Is there still active interest in supporting the PXA platforms? Thanks folks!
On Mon, May 06, 2019 at 09:26:04AM -0400, Tom Rini wrote:
Hey folks,
I'm attempting, again, to see what we need to do in order to use gcc-8.x for U-Boot and ran into, again: https://patchwork.ozlabs.org/patch/920329/ which in short is that when using -mcpu=xscale gcc-8.x throws an odd error: cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch [-Werror]
Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which suggests perhaps something broke in upstream gcc. Looking at the kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that leads to different failures (seen here with gcc-7.3): CC drivers/usb/gadget/pxa25x_udc.o {standard input}: Assembler messages: {standard input}:779: Error: selected processor does not support `pld [lr]' in ARM mode {standard input}:1201: Error: selected processor does not support `pld [r7]' in ARM mode {standard input}:2519: Error: selected processor does not support `pld [r3]' in ARM mode {standard input}:2796: Error: selected processor does not support `pld [r3]' in ARM mode
So, what should we do about this? Is there still active interest in supporting the PXA platforms? Thanks folks!
ping? Thanks!
On 5/9/19 4:02 PM, Tom Rini wrote:
On Mon, May 06, 2019 at 09:26:04AM -0400, Tom Rini wrote:
Hey folks,
I'm attempting, again, to see what we need to do in order to use gcc-8.x for U-Boot and ran into, again: https://patchwork.ozlabs.org/patch/920329/ which in short is that when using -mcpu=xscale gcc-8.x throws an odd error: cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch [-Werror]
Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which suggests perhaps something broke in upstream gcc. Looking at the kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that leads to different failures (seen here with gcc-7.3): CC drivers/usb/gadget/pxa25x_udc.o {standard input}: Assembler messages: {standard input}:779: Error: selected processor does not support `pld [lr]' in ARM mode {standard input}:1201: Error: selected processor does not support `pld [r7]' in ARM mode {standard input}:2519: Error: selected processor does not support `pld [r3]' in ARM mode {standard input}:2796: Error: selected processor does not support `pld [r3]' in ARM mode
So, what should we do about this? Is there still active interest in supporting the PXA platforms? Thanks folks!
ping? Thanks!
Maybe we should just remove it.
On Thu, May 9, 2019 at 7:56 AM Marek Vasut marex@denx.de wrote:
On 5/9/19 4:02 PM, Tom Rini wrote:
On Mon, May 06, 2019 at 09:26:04AM -0400, Tom Rini wrote:
Hey folks,
I'm attempting, again, to see what we need to do in order to use gcc-8.x for U-Boot and ran into, again: https://patchwork.ozlabs.org/patch/920329/ which in short is that when using -mcpu=xscale gcc-8.x throws an odd error: cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch [-Werror]
Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which suggests perhaps something broke in upstream gcc. Looking at the kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that leads to different failures (seen here with gcc-7.3): CC drivers/usb/gadget/pxa25x_udc.o {standard input}: Assembler messages: {standard input}:779: Error: selected processor does not support `pld [lr]' in ARM mode {standard input}:1201: Error: selected processor does not support `pld [r7]' in ARM mode {standard input}:2519: Error: selected processor does not support `pld [r3]' in ARM mode {standard input}:2796: Error: selected processor does not support `pld [r3]' in ARM mode
So, what should we do about this? Is there still active interest in supporting the PXA platforms? Thanks folks!
ping? Thanks!
Maybe we should just remove it.
+1, almost no one uses it nowadays.
-- Best regards, Marek Vasut
On 5/9/19 5:03 PM, Vasily Khoruzhick wrote:
On Thu, May 9, 2019 at 7:56 AM Marek Vasut marex@denx.de wrote:
On 5/9/19 4:02 PM, Tom Rini wrote:
On Mon, May 06, 2019 at 09:26:04AM -0400, Tom Rini wrote:
Hey folks,
I'm attempting, again, to see what we need to do in order to use gcc-8.x for U-Boot and ran into, again: https://patchwork.ozlabs.org/patch/920329/ which in short is that when using -mcpu=xscale gcc-8.x throws an odd error: cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch [-Werror]
Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which suggests perhaps something broke in upstream gcc. Looking at the kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that leads to different failures (seen here with gcc-7.3): CC drivers/usb/gadget/pxa25x_udc.o {standard input}: Assembler messages: {standard input}:779: Error: selected processor does not support `pld [lr]' in ARM mode {standard input}:1201: Error: selected processor does not support `pld [r7]' in ARM mode {standard input}:2519: Error: selected processor does not support `pld [r3]' in ARM mode {standard input}:2796: Error: selected processor does not support `pld [r3]' in ARM mode
So, what should we do about this? Is there still active interest in supporting the PXA platforms? Thanks folks!
ping? Thanks!
Maybe we should just remove it.
+1, almost no one uses it nowadays.
Well, there are still a few users of Zipit Z2 and there was some interest in Sharp Zaurus, but ...
On Thu, May 09, 2019 at 05:12:25PM +0200, Marek Vasut wrote:
On 5/9/19 5:03 PM, Vasily Khoruzhick wrote:
On Thu, May 9, 2019 at 7:56 AM Marek Vasut marex@denx.de wrote:
On 5/9/19 4:02 PM, Tom Rini wrote:
On Mon, May 06, 2019 at 09:26:04AM -0400, Tom Rini wrote:
Hey folks,
I'm attempting, again, to see what we need to do in order to use gcc-8.x for U-Boot and ran into, again: https://patchwork.ozlabs.org/patch/920329/ which in short is that when using -mcpu=xscale gcc-8.x throws an odd error: cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch [-Werror]
Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which suggests perhaps something broke in upstream gcc. Looking at the kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that leads to different failures (seen here with gcc-7.3): CC drivers/usb/gadget/pxa25x_udc.o {standard input}: Assembler messages: {standard input}:779: Error: selected processor does not support `pld [lr]' in ARM mode {standard input}:1201: Error: selected processor does not support `pld [r7]' in ARM mode {standard input}:2519: Error: selected processor does not support `pld [r3]' in ARM mode {standard input}:2796: Error: selected processor does not support `pld [r3]' in ARM mode
So, what should we do about this? Is there still active interest in supporting the PXA platforms? Thanks folks!
ping? Thanks!
Maybe we should just remove it.
+1, almost no one uses it nowadays.
Well, there are still a few users of Zipit Z2 and there was some interest in Sharp Zaurus, but ...
I don't see anything for Zipit Z2 that's been updated more recently than about 5 years ago, sadly. Vasily, do you want to post a patch to drop that board since it's yours? Thanks!
Hi Tom
On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote:
Hey folks,
I'm attempting, again, to see what we need to do in order to use gcc- 8.x for U-Boot and ran into, again: https://patchwork.ozlabs.org/patch/920329/ which in short is that when using -mcpu=xscale gcc-8.x throws an odd error: cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch [-Werror]
Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which suggests perhaps something broke in upstream gcc. Looking at the kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that leads to different failures (seen here with gcc-7.3): CC drivers/usb/gadget/pxa25x_udc.o {standard input}: Assembler messages: {standard input}:779: Error: selected processor does not support `pld [lr]' in ARM mode {standard input}:1201: Error: selected processor does not support `pld [r7]' in ARM mode {standard input}:2519: Error: selected processor does not support `pld [r3]' in ARM mode {standard input}:2796: Error: selected processor does not support `pld [r3]' in ARM mode
So, what should we do about this? Is there still active interest in supporting the PXA platforms? Thanks folks!
We are actually still shipping Colibri PXA270 modules for another one or two years I believe after which Marvell stops selling us chips.
The strange thing is that I build U-Boot master more or less daily without any known issues currently using the regular gcc 8.2 2019.01 tool chain from ARM.
The only issue is the missing DM_MMC and/or DM_USB conversion which I started working on a long time ago but never came around properly debugging. I may pick that one up tomorrow again.
Cheers
Marcel
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
On 5/16/19 4:53 PM, Marcel Ziswiler wrote:
Hi Tom
On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote:
Hey folks,
I'm attempting, again, to see what we need to do in order to use gcc- 8.x for U-Boot and ran into, again: https://patchwork.ozlabs.org/patch/920329/ which in short is that when using -mcpu=xscale gcc-8.x throws an odd error: cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch [-Werror]
Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which suggests perhaps something broke in upstream gcc. Looking at the kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that leads to different failures (seen here with gcc-7.3): CC drivers/usb/gadget/pxa25x_udc.o {standard input}: Assembler messages: {standard input}:779: Error: selected processor does not support `pld [lr]' in ARM mode {standard input}:1201: Error: selected processor does not support `pld [r7]' in ARM mode {standard input}:2519: Error: selected processor does not support `pld [r3]' in ARM mode {standard input}:2796: Error: selected processor does not support `pld [r3]' in ARM mode
So, what should we do about this? Is there still active interest in supporting the PXA platforms? Thanks folks!
We are actually still shipping Colibri PXA270 modules for another one or two years I believe after which Marvell stops selling us chips.
The strange thing is that I build U-Boot master more or less daily without any known issues currently using the regular gcc 8.2 2019.01 tool chain from ARM.
The only issue is the missing DM_MMC and/or DM_USB conversion which I started working on a long time ago but never came around properly debugging. I may pick that one up tomorrow again.
Would you like to co-maintain the PXA ? :)
On Thu, 2019-05-16 at 17:02 +0200, Marek Vasut wrote:
On 5/16/19 4:53 PM, Marcel Ziswiler wrote:
Hi Tom
On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote:
Hey folks,
I'm attempting, again, to see what we need to do in order to use gcc- 8.x for U-Boot and ran into, again: https://patchwork.ozlabs.org/patch/920329/ which in short is that when using -mcpu=xscale gcc-8.x throws an odd error: cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch [-Werror]
Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which suggests perhaps something broke in upstream gcc. Looking at the kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that leads to different failures (seen here with gcc-7.3): CC drivers/usb/gadget/pxa25x_udc.o {standard input}: Assembler messages: {standard input}:779: Error: selected processor does not support `pld [lr]' in ARM mode {standard input}:1201: Error: selected processor does not support `pld [r7]' in ARM mode {standard input}:2519: Error: selected processor does not support `pld [r3]' in ARM mode {standard input}:2796: Error: selected processor does not support `pld [r3]' in ARM mode
So, what should we do about this? Is there still active interest in supporting the PXA platforms? Thanks folks!
We are actually still shipping Colibri PXA270 modules for another one or two years I believe after which Marvell stops selling us chips.
The strange thing is that I build U-Boot master more or less daily without any known issues currently using the regular gcc 8.2 2019.01 tool chain from ARM.
The only issue is the missing DM_MMC and/or DM_USB conversion which I started working on a long time ago but never came around properly debugging. I may pick that one up tomorrow again.
Would you like to co-maintain the PXA ? :)
Sure, but it may as well just be the PXA's very last steps before being laid to rest (;-p).
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...
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.
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 ?
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.
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).
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.
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.
Hi,
On Tue, 21 May 2019 at 08:50, Tom Rini trini@konsulko.com wrote:
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.
I'll reply in a new thread.
Regards, Simon
On Tue, May 21, 2019 at 10:33:39AM +0000, 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.
As Marek touched on elsewhere, part of the problem is maintainer overload. Many of these older platforms just don't get the same focus as the newer ones as the people that are listed as maintaining them have a lot of other areas to focus on. But if we can bring back PowerPC 8xx, we can keep PXA going, I'm sure.
I wish I could have merged in Simon Goldschmidt's series to introduce a more generic "fail to build if $X is over the limit" framework as to me, one of the big things that halts size growth is when platforms fail to build rather than silently overflow their run-time space.
Now I see colibri_pxa270 is currently (gcc-7.3) at 247k. And I'm sure that's larger than desired, but how close to the hard limit is it? Is thumb2 valid on that setup?
Thanks!
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.
On 21/05/2019, Marek Vasut marex@denx.de 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).
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.
On Tue, May 21, 2019 at 04:47:44PM +0300, Alex Sadovsky wrote:
On 21/05/2019, Marek Vasut marex@denx.de 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).
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.
Just for the record, we don't (unless the maintainer agrees, ie zipitz2 removal) proactively drop code. But we do try and put out warnings about things not being updated to new APIs in time.
PXA in particular, Marek is listed as the maintainer and has asked if someone would like it instead. So I'd really appreciate it if someone with continued interest in PXA says they'll take it over. That mainly means fixing (by migration) the various drivers that don't use DM yet, to use DM and for the "PXA" symbols in scripts/config_whitelist.txt migrating them to Kconfig. Dropping boards that no one has interest in and even replacing them with boards people have and have interest in, is great. And I'd be totally happy with someone wanting to maintain PXA support until the end of time ;)
On 5/21/19 3:47 PM, Alex Sadovsky wrote:
On 21/05/2019, Marek Vasut marex@denx.de 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
On Tue, May 21, 2019 at 08:44:57AM +0000, Marcel Ziswiler wrote:
On Thu, 2019-05-16 at 17:02 +0200, Marek Vasut wrote:
On 5/16/19 4:53 PM, Marcel Ziswiler wrote:
Hi Tom
On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote:
Hey folks,
I'm attempting, again, to see what we need to do in order to use gcc- 8.x for U-Boot and ran into, again: https://patchwork.ozlabs.org/patch/920329/ which in short is that when using -mcpu=xscale gcc-8.x throws an odd error: cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch [-Werror]
Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which suggests perhaps something broke in upstream gcc. Looking at the kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that leads to different failures (seen here with gcc-7.3): CC drivers/usb/gadget/pxa25x_udc.o {standard input}: Assembler messages: {standard input}:779: Error: selected processor does not support `pld [lr]' in ARM mode {standard input}:1201: Error: selected processor does not support `pld [r7]' in ARM mode {standard input}:2519: Error: selected processor does not support `pld [r3]' in ARM mode {standard input}:2796: Error: selected processor does not support `pld [r3]' in ARM mode
So, what should we do about this? Is there still active interest in supporting the PXA platforms? Thanks folks!
We are actually still shipping Colibri PXA270 modules for another one or two years I believe after which Marvell stops selling us chips.
The strange thing is that I build U-Boot master more or less daily without any known issues currently using the regular gcc 8.2 2019.01 tool chain from ARM.
The only issue is the missing DM_MMC and/or DM_USB conversion which I started working on a long time ago but never came around properly debugging. I may pick that one up tomorrow again.
Would you like to co-maintain the PXA ? :)
Sure, but it may as well just be the PXA's very last steps before being laid to rest (;-p).
To be somewhat serious, active care and maintenance is an important part of keeping things alive long term.
On Thu, May 16, 2019 at 02:53:55PM +0000, Marcel Ziswiler wrote:
Hi Tom
On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote:
Hey folks,
I'm attempting, again, to see what we need to do in order to use gcc- 8.x for U-Boot and ran into, again: https://patchwork.ozlabs.org/patch/920329/ which in short is that when using -mcpu=xscale gcc-8.x throws an odd error: cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch [-Werror]
Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which suggests perhaps something broke in upstream gcc. Looking at the kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that leads to different failures (seen here with gcc-7.3): CC drivers/usb/gadget/pxa25x_udc.o {standard input}: Assembler messages: {standard input}:779: Error: selected processor does not support `pld [lr]' in ARM mode {standard input}:1201: Error: selected processor does not support `pld [r7]' in ARM mode {standard input}:2519: Error: selected processor does not support `pld [r3]' in ARM mode {standard input}:2796: Error: selected processor does not support `pld [r3]' in ARM mode
So, what should we do about this? Is there still active interest in supporting the PXA platforms? Thanks folks!
We are actually still shipping Colibri PXA270 modules for another one or two years I believe after which Marvell stops selling us chips.
The strange thing is that I build U-Boot master more or less daily without any known issues currently using the regular gcc 8.2 2019.01 tool chain from ARM.
Oh, that is interesting. The failure that triggers this comes from https://cdn.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc...
Can you point me at the gcc-8.2 toolchain you're talking about please? Thanks!
On Thu, 2019-05-16 at 13:49 -0400, Tom Rini wrote:
On Thu, May 16, 2019 at 02:53:55PM +0000, Marcel Ziswiler wrote:
Hi Tom
On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote:
Hey folks,
...
So, what should we do about this? Is there still active interest in supporting the PXA platforms? Thanks folks!
We are actually still shipping Colibri PXA270 modules for another one or two years I believe after which Marvell stops selling us chips.
The strange thing is that I build U-Boot master more or less daily without any known issues currently using the regular gcc 8.2 2019.01 tool chain from ARM.
Oh, that is interesting. The failure that triggers this comes from https://cdn.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc...
Can you point me at the gcc-8.2 toolchain you're talking about please?
Sure, sorry. I just use the GCC 8.2-2019.01 one from Arm [1] which even Linaro now links to on their releases download server (e.g. gcc-8 link on [2]). I also just now tested their very latest one GCC 8.3-2019.03 which works just fine as well. OK?
[1] https://developer.arm.com/tools-and-software/open-source-software/developer-... [2] https://releases.linaro.org/components/toolchain/binaries/
Thanks!
On Thu, May 16, 2019 at 02:53:55PM +0000, Marcel Ziswiler wrote:
Hi Tom
On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote:
Hey folks,
I'm attempting, again, to see what we need to do in order to use gcc- 8.x for U-Boot and ran into, again: https://patchwork.ozlabs.org/patch/920329/ which in short is that when using -mcpu=xscale gcc-8.x throws an odd error: cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch [-Werror]
Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which suggests perhaps something broke in upstream gcc. Looking at the kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that leads to different failures (seen here with gcc-7.3): CC drivers/usb/gadget/pxa25x_udc.o {standard input}: Assembler messages: {standard input}:779: Error: selected processor does not support `pld [lr]' in ARM mode {standard input}:1201: Error: selected processor does not support `pld [r7]' in ARM mode {standard input}:2519: Error: selected processor does not support `pld [r3]' in ARM mode {standard input}:2796: Error: selected processor does not support `pld [r3]' in ARM mode
So, what should we do about this? Is there still active interest in supporting the PXA platforms? Thanks folks!
We are actually still shipping Colibri PXA270 modules for another one or two years I believe after which Marvell stops selling us chips.
The strange thing is that I build U-Boot master more or less daily without any known issues currently using the regular gcc 8.2 2019.01 tool chain from ARM.
The only issue is the missing DM_MMC and/or DM_USB conversion which I started working on a long time ago but never came around properly debugging. I may pick that one up tomorrow again.
I want to circle back to this. Thanks again for confirming that other toolchains are happy here (and figuring out a path forward for everyone is on my TODO list still). And I agree we need to figure out something about the size growth. But this still leaves one question open. There are, after dropping zipitz2, 2 PXA platforms. Do you want to take over the MAINTAINER role from Marek for them?
Hi Tom
On Wed, 2019-05-29 at 10:12 -0400, Tom Rini wrote:
On Thu, May 16, 2019 at 02:53:55PM +0000, Marcel Ziswiler wrote:
Hi Tom
On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote:
Hey folks,
I'm attempting, again, to see what we need to do in order to use gcc- 8.x for U-Boot and ran into, again: https://patchwork.ozlabs.org/patch/920329/ which in short is that when using -mcpu=xscale gcc-8.x throws an odd error: cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch [-Werror]
Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which suggests perhaps something broke in upstream gcc. Looking at the kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that leads to different failures (seen here with gcc-7.3): CC drivers/usb/gadget/pxa25x_udc.o {standard input}: Assembler messages: {standard input}:779: Error: selected processor does not support `pld [lr]' in ARM mode {standard input}:1201: Error: selected processor does not support `pld [r7]' in ARM mode {standard input}:2519: Error: selected processor does not support `pld [r3]' in ARM mode {standard input}:2796: Error: selected processor does not support `pld [r3]' in ARM mode
So, what should we do about this? Is there still active interest in supporting the PXA platforms? Thanks folks!
We are actually still shipping Colibri PXA270 modules for another one or two years I believe after which Marvell stops selling us chips.
The strange thing is that I build U-Boot master more or less daily without any known issues currently using the regular gcc 8.2 2019.01 tool chain from ARM.
The only issue is the missing DM_MMC and/or DM_USB conversion which I started working on a long time ago but never came around properly debugging. I may pick that one up tomorrow again.
I want to circle back to this. Thanks again for confirming that other toolchains are happy here (and figuring out a path forward for everyone is on my TODO list still). And I agree we need to figure out something about the size growth. But this still leaves one question open. There are, after dropping zipitz2, 2 PXA platforms.
Let me name those two:
- Colibri PXA270
Our customers already had to commit to a last-time-buy and we will phasing out shipments next year. I don't think anybody is doing any new designs with them since quite a while.
- HP iPAQ Pocket PC h2200
A consumer device with PXA255 from back in 2002. There has not been any activity on h2200 from its maintainer Lukasz Dalek for almost 5 years now. Without anybody actually owning such hardware stepping up it will be quite impossible to maintain.
Do you want to take over the MAINTAINER role from Marek for them?
While I would love to do so I really don't think that makes too much sense at all. We probably should just drop PXA support entirely, move on and concentrate our resources on newer stuff like e.g. my patch sets for Apalis iMX8 and Colibri iMX8X which did not get any more attention since more resp. almost a month now.
Cheers
Marcel
On 5/30/19 11:14 AM, Marcel Ziswiler wrote:
Hi Tom
On Wed, 2019-05-29 at 10:12 -0400, Tom Rini wrote:
On Thu, May 16, 2019 at 02:53:55PM +0000, Marcel Ziswiler wrote:
Hi Tom
On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote:
Hey folks,
I'm attempting, again, to see what we need to do in order to use gcc- 8.x for U-Boot and ran into, again: https://patchwork.ozlabs.org/patch/920329/ which in short is that when using -mcpu=xscale gcc-8.x throws an odd error: cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch [-Werror]
Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which suggests perhaps something broke in upstream gcc. Looking at the kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that leads to different failures (seen here with gcc-7.3): CC drivers/usb/gadget/pxa25x_udc.o {standard input}: Assembler messages: {standard input}:779: Error: selected processor does not support `pld [lr]' in ARM mode {standard input}:1201: Error: selected processor does not support `pld [r7]' in ARM mode {standard input}:2519: Error: selected processor does not support `pld [r3]' in ARM mode {standard input}:2796: Error: selected processor does not support `pld [r3]' in ARM mode
So, what should we do about this? Is there still active interest in supporting the PXA platforms? Thanks folks!
We are actually still shipping Colibri PXA270 modules for another one or two years I believe after which Marvell stops selling us chips.
The strange thing is that I build U-Boot master more or less daily without any known issues currently using the regular gcc 8.2 2019.01 tool chain from ARM.
The only issue is the missing DM_MMC and/or DM_USB conversion which I started working on a long time ago but never came around properly debugging. I may pick that one up tomorrow again.
I want to circle back to this. Thanks again for confirming that other toolchains are happy here (and figuring out a path forward for everyone is on my TODO list still). And I agree we need to figure out something about the size growth. But this still leaves one question open. There are, after dropping zipitz2, 2 PXA platforms.
Let me name those two:
- Colibri PXA270
Our customers already had to commit to a last-time-buy and we will phasing out shipments next year. I don't think anybody is doing any new designs with them since quite a while.
I still have one , I am really fond of the devkit design.
- HP iPAQ Pocket PC h2200
A consumer device with PXA255 from back in 2002. There has not been any activity on h2200 from its maintainer Lukasz Dalek for almost 5 years now. Without anybody actually owning such hardware stepping up it will be quite impossible to maintain.
Let's remove this one.
Do you want to take over the MAINTAINER role from Marek for them?
While I would love to do so I really don't think that makes too much sense at all. We probably should just drop PXA support entirely, move on and concentrate our resources on newer stuff like e.g. my patch sets for Apalis iMX8 and Colibri iMX8X which did not get any more attention since more resp. almost a month now.
When did you say the Colibri PXA270 goes away ?
On Thu, 2019-05-30 at 11:29 +0200, Marek Vasut wrote:
On 5/30/19 11:14 AM, Marcel Ziswiler wrote:
Hi Tom
On Wed, 2019-05-29 at 10:12 -0400, Tom Rini wrote:
On Thu, May 16, 2019 at 02:53:55PM +0000, Marcel Ziswiler wrote:
Hi Tom
On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote:
Hey folks,
I'm attempting, again, to see what we need to do in order to use gcc- 8.x for U-Boot and ran into, again: https://patchwork.ozlabs.org/patch/920329/ which in short is that when using -mcpu=xscale gcc-8.x throws an odd error: cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch [-Werror]
Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which suggests perhaps something broke in upstream gcc. Looking at the kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that leads to different failures (seen here with gcc-7.3): CC drivers/usb/gadget/pxa25x_udc.o {standard input}: Assembler messages: {standard input}:779: Error: selected processor does not support `pld [lr]' in ARM mode {standard input}:1201: Error: selected processor does not support `pld [r7]' in ARM mode {standard input}:2519: Error: selected processor does not support `pld [r3]' in ARM mode {standard input}:2796: Error: selected processor does not support `pld [r3]' in ARM mode
So, what should we do about this? Is there still active interest in supporting the PXA platforms? Thanks folks!
We are actually still shipping Colibri PXA270 modules for another one or two years I believe after which Marvell stops selling us chips.
The strange thing is that I build U-Boot master more or less daily without any known issues currently using the regular gcc 8.2 2019.01 tool chain from ARM.
The only issue is the missing DM_MMC and/or DM_USB conversion which I started working on a long time ago but never came around properly debugging. I may pick that one up tomorrow again.
I want to circle back to this. Thanks again for confirming that other toolchains are happy here (and figuring out a path forward for everyone is on my TODO list still). And I agree we need to figure out something about the size growth. But this still leaves one question open. There are, after dropping zipitz2, 2 PXA platforms.
Let me name those two:
- Colibri PXA270
Our customers already had to commit to a last-time-buy and we will phasing out shipments next year. I don't think anybody is doing any new designs with them since quite a while.
I still have one , I am really fond of the devkit design.
Thanks, you could keep using it with e.g. the latest Colibri iMX8QXP (;-p). Should I send you one? I believe we also sent Stefano a full kit with a Colibri iMX6DL.
- HP iPAQ Pocket PC h2200
A consumer device with PXA255 from back in 2002. There has not been any activity on h2200 from its maintainer Lukasz Dalek for almost 5 years now. Without anybody actually owning such hardware stepping up it will be quite impossible to maintain.
Let's remove this one.
Do you want to take over the MAINTAINER role from Marek for them?
While I would love to do so I really don't think that makes too much sense at all. We probably should just drop PXA support entirely, move on and concentrate our resources on newer stuff like e.g. my patch sets for Apalis iMX8 and Colibri iMX8X which did not get any more attention since more resp. almost a month now.
When did you say the Colibri PXA270 goes away ?
Well, the original PXA270 went end-of-life more than 5 years ago. We re-designed for the die-shrinked PXA270M which will now end-of-life next year. Anyway, it is no longer orderable but customers having put in their last-time-buy quantities will still get them shipped next year.
https://developer.toradex.com/products/colibri-pxa270#revision-history
On 5/30/19 1:47 PM, Marcel Ziswiler wrote:
On Thu, 2019-05-30 at 11:29 +0200, Marek Vasut wrote:
On 5/30/19 11:14 AM, Marcel Ziswiler wrote:
Hi Tom
On Wed, 2019-05-29 at 10:12 -0400, Tom Rini wrote:
On Thu, May 16, 2019 at 02:53:55PM +0000, Marcel Ziswiler wrote:
Hi Tom
On Mon, 2019-05-06 at 09:26 -0400, Tom Rini wrote:
Hey folks,
I'm attempting, again, to see what we need to do in order to use gcc- 8.x for U-Boot and ran into, again: https://patchwork.ozlabs.org/patch/920329/ which in short is that when using -mcpu=xscale gcc-8.x throws an odd error: cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch [-Werror]
Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which suggests perhaps something broke in upstream gcc. Looking at the kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that leads to different failures (seen here with gcc-7.3): CC drivers/usb/gadget/pxa25x_udc.o {standard input}: Assembler messages: {standard input}:779: Error: selected processor does not support `pld [lr]' in ARM mode {standard input}:1201: Error: selected processor does not support `pld [r7]' in ARM mode {standard input}:2519: Error: selected processor does not support `pld [r3]' in ARM mode {standard input}:2796: Error: selected processor does not support `pld [r3]' in ARM mode
So, what should we do about this? Is there still active interest in supporting the PXA platforms? Thanks folks!
We are actually still shipping Colibri PXA270 modules for another one or two years I believe after which Marvell stops selling us chips.
The strange thing is that I build U-Boot master more or less daily without any known issues currently using the regular gcc 8.2 2019.01 tool chain from ARM.
The only issue is the missing DM_MMC and/or DM_USB conversion which I started working on a long time ago but never came around properly debugging. I may pick that one up tomorrow again.
I want to circle back to this. Thanks again for confirming that other toolchains are happy here (and figuring out a path forward for everyone is on my TODO list still). And I agree we need to figure out something about the size growth. But this still leaves one question open. There are, after dropping zipitz2, 2 PXA platforms.
Let me name those two:
- Colibri PXA270
Our customers already had to commit to a last-time-buy and we will phasing out shipments next year. I don't think anybody is doing any new designs with them since quite a while.
I still have one , I am really fond of the devkit design.
Thanks, you could keep using it with e.g. the latest Colibri iMX8QXP (;-p). Should I send you one? I believe we also sent Stefano a full kit with a Colibri iMX6DL.
Which ES ? ;-)
- HP iPAQ Pocket PC h2200
A consumer device with PXA255 from back in 2002. There has not been any activity on h2200 from its maintainer Lukasz Dalek for almost 5 years now. Without anybody actually owning such hardware stepping up it will be quite impossible to maintain.
Let's remove this one.
Do you want to take over the MAINTAINER role from Marek for them?
While I would love to do so I really don't think that makes too much sense at all. We probably should just drop PXA support entirely, move on and concentrate our resources on newer stuff like e.g. my patch sets for Apalis iMX8 and Colibri iMX8X which did not get any more attention since more resp. almost a month now.
When did you say the Colibri PXA270 goes away ?
Well, the original PXA270 went end-of-life more than 5 years ago. We re-designed for the die-shrinked PXA270M which will now end-of-life next year. Anyway, it is no longer orderable but customers having put in their last-time-buy quantities will still get them shipped next year.
With latest greatest U-Boot ? :)
https://developer.toradex.com/products/colibri-pxa270#revision-history
- HP iPAQ Pocket PC h2200
A consumer device with PXA255 from back in 2002. There has not been any activity on h2200 from its maintainer Lukasz Dalek for almost 5 years now. Without anybody actually owning such hardware stepping up it will be quite impossible to maintain.
I still have one (and a box of similar ones). PDAs are good as cheap ARM SBC for different kind of educational purposes. Though I have to accept that such reason isn't big enough for mainline support.
Cheers, Alex
On Thu, May 30, 2019 at 01:45:22PM +0300, Alex Sadovsky wrote:
- HP iPAQ Pocket PC h2200
A consumer device with PXA255 from back in 2002. There has not been any activity on h2200 from its maintainer Lukasz Dalek for almost 5 years now. Without anybody actually owning such hardware stepping up it will be quite impossible to maintain.
I still have one (and a box of similar ones). PDAs are good as cheap ARM SBC for different kind of educational purposes. Though I have to accept that such reason isn't big enough for mainline support.
If someone is willing to put in the time to be the maintainer I am happy for things to stay, no matter how old they are.
participants (6)
-
Alex Sadovsky -
Marcel Ziswiler -
Marek Vasut -
Simon Glass -
Tom Rini -
Vasily Khoruzhick