* [U-Boot] U-Boot PXA support @ 2019-05-06 13:26 Tom Rini 2019-05-09 14:02 ` Tom Rini 2019-05-16 14:53 ` Marcel Ziswiler 0 siblings, 2 replies; 31+ messages in thread From: Tom Rini @ 2019-05-06 13:26 UTC (permalink / raw) To: u-boot 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! -- 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/20190506/f4c3cb61/attachment.sig> ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-06 13:26 [U-Boot] U-Boot PXA support Tom Rini @ 2019-05-09 14:02 ` Tom Rini 2019-05-09 14:56 ` Marek Vasut 2019-05-16 14:53 ` Marcel Ziswiler 1 sibling, 1 reply; 31+ messages in thread From: Tom Rini @ 2019-05-09 14:02 UTC (permalink / raw) To: u-boot 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! -- 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/20190509/1b756d8a/attachment.sig> ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-09 14:02 ` Tom Rini @ 2019-05-09 14:56 ` Marek Vasut 2019-05-09 15:03 ` Vasily Khoruzhick 0 siblings, 1 reply; 31+ messages in thread From: Marek Vasut @ 2019-05-09 14:56 UTC (permalink / raw) To: u-boot 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. -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-09 14:56 ` Marek Vasut @ 2019-05-09 15:03 ` Vasily Khoruzhick 2019-05-09 15:12 ` Marek Vasut 0 siblings, 1 reply; 31+ messages in thread From: Vasily Khoruzhick @ 2019-05-09 15:03 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-09 15:03 ` Vasily Khoruzhick @ 2019-05-09 15:12 ` Marek Vasut 2019-05-09 15:22 ` Tom Rini 0 siblings, 1 reply; 31+ messages in thread From: Marek Vasut @ 2019-05-09 15:12 UTC (permalink / raw) To: u-boot 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 ... -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-09 15:12 ` Marek Vasut @ 2019-05-09 15:22 ` Tom Rini 0 siblings, 0 replies; 31+ messages in thread From: Tom Rini @ 2019-05-09 15:22 UTC (permalink / raw) To: u-boot 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! -- 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/20190509/4231f452/attachment.sig> ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-06 13:26 [U-Boot] U-Boot PXA support Tom Rini 2019-05-09 14:02 ` Tom Rini @ 2019-05-16 14:53 ` Marcel Ziswiler 2019-05-16 15:02 ` Marek Vasut ` (2 more replies) 1 sibling, 3 replies; 31+ messages in thread From: Marcel Ziswiler @ 2019-05-16 14:53 UTC (permalink / raw) To: u-boot 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 at lists.denx.de > https://lists.denx.de/listinfo/u-boot ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-16 14:53 ` Marcel Ziswiler @ 2019-05-16 15:02 ` Marek Vasut 2019-05-21 8:44 ` Marcel Ziswiler 2019-05-16 17:49 ` Tom Rini 2019-05-29 14:12 ` Tom Rini 2 siblings, 1 reply; 31+ messages in thread From: Marek Vasut @ 2019-05-16 15:02 UTC (permalink / raw) To: 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 ? :) -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-16 15:02 ` Marek Vasut @ 2019-05-21 8:44 ` Marcel Ziswiler 2019-05-21 9:50 ` Alex Sadovsky 2019-05-21 12:51 ` Tom Rini 0 siblings, 2 replies; 31+ messages in thread From: Marcel Ziswiler @ 2019-05-21 8:44 UTC (permalink / raw) To: u-boot 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). ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-21 8:44 ` Marcel Ziswiler @ 2019-05-21 9:50 ` Alex Sadovsky 2019-05-21 10:33 ` Marcel Ziswiler 2019-05-21 12:47 ` Marek Vasut 2019-05-21 12:51 ` Tom Rini 1 sibling, 2 replies; 31+ messages in thread From: Alex Sadovsky @ 2019-05-21 9:50 UTC (permalink / raw) To: u-boot 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... ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-21 9:50 ` Alex Sadovsky @ 2019-05-21 10:33 ` Marcel Ziswiler 2019-05-21 12:49 ` Marek Vasut 2019-05-21 13:47 ` Tom Rini 2019-05-21 12:47 ` Marek Vasut 1 sibling, 2 replies; 31+ messages in thread From: Marcel Ziswiler @ 2019-05-21 10:33 UTC (permalink / raw) To: u-boot 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-21 10:33 ` Marcel Ziswiler @ 2019-05-21 12:49 ` Marek Vasut 2019-05-21 14:29 ` Marcel Ziswiler 2019-05-21 13:47 ` Tom Rini 1 sibling, 1 reply; 31+ messages in thread From: Marek Vasut @ 2019-05-21 12:49 UTC (permalink / raw) To: u-boot 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 ? -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-21 12:49 ` Marek Vasut @ 2019-05-21 14:29 ` Marcel Ziswiler 2019-05-21 14:34 ` Marek Vasut 0 siblings, 1 reply; 31+ messages in thread From: Marcel Ziswiler @ 2019-05-21 14:29 UTC (permalink / raw) To: u-boot 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). ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-21 14:29 ` Marcel Ziswiler @ 2019-05-21 14:34 ` Marek Vasut 2019-05-21 14:50 ` Tom Rini 0 siblings, 1 reply; 31+ messages in thread From: Marek Vasut @ 2019-05-21 14:34 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-21 14:34 ` Marek Vasut @ 2019-05-21 14:50 ` Tom Rini 2019-05-21 16:43 ` Simon Glass 0 siblings, 1 reply; 31+ messages in thread From: Tom Rini @ 2019-05-21 14:50 UTC (permalink / raw) To: u-boot 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> ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-21 14:50 ` Tom Rini @ 2019-05-21 16:43 ` Simon Glass 0 siblings, 0 replies; 31+ messages in thread From: Simon Glass @ 2019-05-21 16:43 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-21 10:33 ` Marcel Ziswiler 2019-05-21 12:49 ` Marek Vasut @ 2019-05-21 13:47 ` Tom Rini 1 sibling, 0 replies; 31+ messages in thread From: Tom Rini @ 2019-05-21 13:47 UTC (permalink / raw) To: u-boot 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! -- 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/31970db0/attachment.sig> ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-21 9:50 ` Alex Sadovsky 2019-05-21 10:33 ` Marcel Ziswiler @ 2019-05-21 12:47 ` Marek Vasut 2019-05-21 13:47 ` Alex Sadovsky 1 sibling, 1 reply; 31+ messages in thread From: Marek Vasut @ 2019-05-21 12:47 UTC (permalink / raw) To: u-boot 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. -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-21 12:47 ` Marek Vasut @ 2019-05-21 13:47 ` Alex Sadovsky 2019-05-21 13:58 ` Tom Rini 2019-05-21 14:03 ` Marek Vasut 0 siblings, 2 replies; 31+ messages in thread From: Alex Sadovsky @ 2019-05-21 13:47 UTC (permalink / raw) To: u-boot 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-21 13:47 ` Alex Sadovsky @ 2019-05-21 13:58 ` Tom Rini 2019-05-21 14:03 ` Marek Vasut 1 sibling, 0 replies; 31+ messages in thread From: Tom Rini @ 2019-05-21 13:58 UTC (permalink / raw) To: u-boot 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 ;) -- 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/13a2fe9f/attachment.sig> ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-21 13:47 ` Alex Sadovsky 2019-05-21 13:58 ` Tom Rini @ 2019-05-21 14:03 ` Marek Vasut 1 sibling, 0 replies; 31+ messages in thread From: Marek Vasut @ 2019-05-21 14:03 UTC (permalink / raw) To: u-boot 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 -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-21 8:44 ` Marcel Ziswiler 2019-05-21 9:50 ` Alex Sadovsky @ 2019-05-21 12:51 ` Tom Rini 1 sibling, 0 replies; 31+ messages in thread From: Tom Rini @ 2019-05-21 12:51 UTC (permalink / raw) To: u-boot 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. -- 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/6c85b08f/attachment.sig> ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-16 14:53 ` Marcel Ziswiler 2019-05-16 15:02 ` Marek Vasut @ 2019-05-16 17:49 ` Tom Rini 2019-05-17 14:46 ` Marcel Ziswiler 2019-05-29 14:12 ` Tom Rini 2 siblings, 1 reply; 31+ messages in thread From: Tom Rini @ 2019-05-16 17:49 UTC (permalink / raw) To: u-boot 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-8.1.0-nolibc-arm-linux-gnueabi.tar.xz Can you point me at the gcc-8.2 toolchain you're talking about please? Thanks! -- 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/20190516/248eb2b4/attachment.sig> ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-16 17:49 ` Tom Rini @ 2019-05-17 14:46 ` Marcel Ziswiler 0 siblings, 0 replies; 31+ messages in thread From: Marcel Ziswiler @ 2019-05-17 14:46 UTC (permalink / raw) To: u-boot 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-8.1.0-nolibc-arm-linux-gnueabi.tar.xz > > 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-tools/gnu-toolchain/gnu-a/downloads#panel2a [2] https://releases.linaro.org/components/toolchain/binaries/ > Thanks! ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-16 14:53 ` Marcel Ziswiler 2019-05-16 15:02 ` Marek Vasut 2019-05-16 17:49 ` Tom Rini @ 2019-05-29 14:12 ` Tom Rini 2019-05-30 9:14 ` Marcel Ziswiler 2 siblings, 1 reply; 31+ messages in thread From: Tom Rini @ 2019-05-29 14:12 UTC (permalink / raw) To: u-boot 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? -- 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/20190529/78f753dd/attachment-0001.sig> ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-29 14:12 ` Tom Rini @ 2019-05-30 9:14 ` Marcel Ziswiler 2019-05-30 9:29 ` Marek Vasut 2019-05-30 10:45 ` Alex Sadovsky 0 siblings, 2 replies; 31+ messages in thread From: Marcel Ziswiler @ 2019-05-30 9:14 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-30 9:14 ` Marcel Ziswiler @ 2019-05-30 9:29 ` Marek Vasut 2019-05-30 11:47 ` Marcel Ziswiler 2019-05-30 10:45 ` Alex Sadovsky 1 sibling, 1 reply; 31+ messages in thread From: Marek Vasut @ 2019-05-30 9:29 UTC (permalink / raw) To: u-boot 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 ? -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-30 9:29 ` Marek Vasut @ 2019-05-30 11:47 ` Marcel Ziswiler 2019-05-31 19:34 ` Marek Vasut 0 siblings, 1 reply; 31+ messages in thread From: Marcel Ziswiler @ 2019-05-30 11:47 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-30 11:47 ` Marcel Ziswiler @ 2019-05-31 19:34 ` Marek Vasut 0 siblings, 0 replies; 31+ messages in thread From: Marek Vasut @ 2019-05-31 19:34 UTC (permalink / raw) To: u-boot 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 > -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-30 9:14 ` Marcel Ziswiler 2019-05-30 9:29 ` Marek Vasut @ 2019-05-30 10:45 ` Alex Sadovsky 2019-05-30 11:19 ` Tom Rini 1 sibling, 1 reply; 31+ messages in thread From: Alex Sadovsky @ 2019-05-30 10:45 UTC (permalink / raw) To: u-boot > - 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* [U-Boot] U-Boot PXA support 2019-05-30 10:45 ` Alex Sadovsky @ 2019-05-30 11:19 ` Tom Rini 0 siblings, 0 replies; 31+ messages in thread From: Tom Rini @ 2019-05-30 11:19 UTC (permalink / raw) To: u-boot 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. -- 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/20190530/738f9e95/attachment.sig> ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2019-05-31 19:34 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-05-06 13:26 [U-Boot] U-Boot PXA support Tom Rini 2019-05-09 14:02 ` Tom Rini 2019-05-09 14:56 ` Marek Vasut 2019-05-09 15:03 ` Vasily Khoruzhick 2019-05-09 15:12 ` Marek Vasut 2019-05-09 15:22 ` Tom Rini 2019-05-16 14:53 ` Marcel Ziswiler 2019-05-16 15:02 ` Marek Vasut 2019-05-21 8:44 ` Marcel Ziswiler 2019-05-21 9:50 ` Alex Sadovsky 2019-05-21 10:33 ` Marcel Ziswiler 2019-05-21 12:49 ` Marek Vasut 2019-05-21 14:29 ` Marcel Ziswiler 2019-05-21 14:34 ` Marek Vasut 2019-05-21 14:50 ` Tom Rini 2019-05-21 16:43 ` Simon Glass 2019-05-21 13:47 ` Tom Rini 2019-05-21 12:47 ` Marek Vasut 2019-05-21 13:47 ` Alex Sadovsky 2019-05-21 13:58 ` Tom Rini 2019-05-21 14:03 ` Marek Vasut 2019-05-21 12:51 ` Tom Rini 2019-05-16 17:49 ` Tom Rini 2019-05-17 14:46 ` Marcel Ziswiler 2019-05-29 14:12 ` Tom Rini 2019-05-30 9:14 ` Marcel Ziswiler 2019-05-30 9:29 ` Marek Vasut 2019-05-30 11:47 ` Marcel Ziswiler 2019-05-31 19:34 ` Marek Vasut 2019-05-30 10:45 ` Alex Sadovsky 2019-05-30 11:19 ` Tom Rini
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.