[U-Boot] U-Boot PXA support

[U-Boot] U-Boot PXA support

[Tom Rini]

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>

[U-Boot] U-Boot PXA support

[Tom Rini]

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>

[U-Boot] U-Boot PXA support

[Marek Vasut]

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

[U-Boot] U-Boot PXA support

[Vasily Khoruzhick]

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

[U-Boot] U-Boot PXA support

[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 ...

-- 
Best regards,
Marek Vasut

[U-Boot] U-Boot PXA support

[Tom Rini]

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>

[U-Boot] U-Boot PXA support

[Marcel Ziswiler]

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

[U-Boot] U-Boot PXA support

[Marek Vasut]

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

[U-Boot] U-Boot PXA support

[Tom Rini]

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>

[U-Boot] U-Boot PXA support

[Marcel Ziswiler]

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!

[U-Boot] U-Boot PXA support

[Marcel Ziswiler]

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).

[U-Boot] U-Boot PXA support

[Alex Sadovsky]

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...

[U-Boot] U-Boot PXA support

[Marcel Ziswiler]

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.

[U-Boot] U-Boot PXA support

[Marek Vasut]

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

[U-Boot] U-Boot PXA support

[Marek Vasut]

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

[U-Boot] U-Boot PXA support

[Tom Rini]

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>

[U-Boot] U-Boot PXA support

[Tom Rini]

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>

[U-Boot] U-Boot PXA support

[Alex Sadovsky]

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.

[U-Boot] U-Boot PXA support

[Tom Rini]

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>

[U-Boot] U-Boot PXA support

[Marek Vasut]

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

[U-Boot] U-Boot PXA support

[Marcel Ziswiler]

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).

[U-Boot] U-Boot PXA support

[Marek Vasut]

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

[U-Boot] U-Boot PXA support

[Tom Rini]

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>

[U-Boot] U-Boot PXA support

[Simon Glass]

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

[U-Boot] U-Boot PXA support

[Tom Rini]

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>

[U-Boot] U-Boot PXA support

[Marcel Ziswiler]

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

[U-Boot] U-Boot PXA support

[Marek Vasut]

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

[U-Boot] U-Boot PXA support

[Alex Sadovsky]

> - 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

[U-Boot] U-Boot PXA support

[Tom Rini]

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>

[U-Boot] U-Boot PXA support

[Marcel Ziswiler]

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

[U-Boot] U-Boot PXA support

[Marek Vasut]

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