possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Peter Maydell]

QEMU includes some models of old Arm machine types which are
a bit problematic for us because:
 * they're written in a very old way that uses numerous APIs that we
   would like to get away from (eg they don't use qdev, they use
   qemu_system_reset_request(), they use vmstate_register(), etc)
 * they've been that way for a decade plus and nobody particularly has
   stepped up to try to modernise the code (beyond some occasional
   work here and there)
 * we often don't have test cases for them, which means that if we
   do try to do the necessary refactoring work on them we have no
   idea if they even still work at all afterwards

All these machine types are also of hardware that has largely passed
away into history and where I would not be surprised to find that
e.g. the Linux kernel support was never tested on real hardware
any more.

So I would like to explore whether we can deprecate-and-drop
some or all of them. This would let us delete the code entirely
rather than spending a long time trying to bring it up to scratch
for a probably very small to nonexistent userbase. The aim of this
email is to see if anybody is still using any of these and would be
upset if they went away. Reports of "I tried to use this machine
type and it's just broken" are also interesting as they would
strongly suggest that the machine has no real users and can be
removed.

The machines I have in mind are:

PXA2xx machines:

akita                Sharp SL-C1000 (Akita) PDA (PXA270)
borzoi               Sharp SL-C3100 (Borzoi) PDA (PXA270)
connex               Gumstix Connex (PXA255)
mainstone            Mainstone II (PXA27x)
spitz                Sharp SL-C3000 (Spitz) PDA (PXA270)
terrier              Sharp SL-C3200 (Terrier) PDA (PXA270)
tosa                 Sharp SL-6000 (Tosa) PDA (PXA255)
verdex               Gumstix Verdex Pro XL6P COMs (PXA270)
z2                   Zipit Z2 (PXA27x)

OMAP1 machines:

cheetah              Palm Tungsten|E aka. Cheetah PDA (OMAP310)
sx1                  Siemens SX1 (OMAP310) V2
sx1-v1               Siemens SX1 (OMAP310) V1

OMAP2 machines:

n800                 Nokia N800 tablet aka. RX-34 (OMAP2420)
n810                 Nokia N810 tablet aka. RX-44 (OMAP2420)

The one SA1110 machine:

collie               Sharp SL-5500 (Collie) PDA (SA-1110)

Obviously if we can remove all the machines that used a given
SoC, that's much more effective than if we just delete one or two.

I don't have any test images for the SA1110 or OMAP1 machines,
so those are the ones I am most keen to be able to drop.
I do have test images for a few of the pxa2xx and the OMAP2 machines.

thanks
-- PMM

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Guenter Roeck]

On 2/12/24 04:32, Peter Maydell wrote:
> QEMU includes some models of old Arm machine types which are
> a bit problematic for us because:
>   * they're written in a very old way that uses numerous APIs that we
>     would like to get away from (eg they don't use qdev, they use
>     qemu_system_reset_request(), they use vmstate_register(), etc)
>   * they've been that way for a decade plus and nobody particularly has
>     stepped up to try to modernise the code (beyond some occasional
>     work here and there)
>   * we often don't have test cases for them, which means that if we
>     do try to do the necessary refactoring work on them we have no
>     idea if they even still work at all afterwards
> 
> All these machine types are also of hardware that has largely passed
> away into history and where I would not be surprised to find that
> e.g. the Linux kernel support was never tested on real hardware
> any more.
> 
> So I would like to explore whether we can deprecate-and-drop
> some or all of them. This would let us delete the code entirely
> rather than spending a long time trying to bring it up to scratch
> for a probably very small to nonexistent userbase. The aim of this
> email is to see if anybody is still using any of these and would be
> upset if they went away. Reports of "I tried to use this machine
> type and it's just broken" are also interesting as they would
> strongly suggest that the machine has no real users and can be
> removed.
> 
> The machines I have in mind are:
> 
> PXA2xx machines:
> 
> akita                Sharp SL-C1000 (Akita) PDA (PXA270)
> borzoi               Sharp SL-C3100 (Borzoi) PDA (PXA270)
> connex               Gumstix Connex (PXA255)
> mainstone            Mainstone II (PXA27x)
> spitz                Sharp SL-C3000 (Spitz) PDA (PXA270)
> terrier              Sharp SL-C3200 (Terrier) PDA (PXA270)
> tosa                 Sharp SL-6000 (Tosa) PDA (PXA255)
> verdex               Gumstix Verdex Pro XL6P COMs (PXA270)
> z2                   Zipit Z2 (PXA27x)
> 
> OMAP1 machines:
> 
> cheetah              Palm Tungsten|E aka. Cheetah PDA (OMAP310)
> sx1                  Siemens SX1 (OMAP310) V2
> sx1-v1               Siemens SX1 (OMAP310) V1
> 
> OMAP2 machines:
> 
> n800                 Nokia N800 tablet aka. RX-34 (OMAP2420)
> n810                 Nokia N810 tablet aka. RX-44 (OMAP2420)
> 
> The one SA1110 machine:
> 
> collie               Sharp SL-5500 (Collie) PDA (SA-1110)
> 
> Obviously if we can remove all the machines that used a given
> SoC, that's much more effective than if we just delete one or two.
> 
> I don't have any test images for the SA1110 or OMAP1 machines,
> so those are the ones I am most keen to be able to drop.
> I do have test images for a few of the pxa2xx and the OMAP2 machines.
> 
> thanks
> -- PMM

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Guenter Roeck]

[ sorry for the earlier noise; accidentally hit "send" ]

On 2/12/24 04:32, Peter Maydell wrote:
> QEMU includes some models of old Arm machine types which are
> a bit problematic for us because:
>   * they're written in a very old way that uses numerous APIs that we
>     would like to get away from (eg they don't use qdev, they use
>     qemu_system_reset_request(), they use vmstate_register(), etc)
>   * they've been that way for a decade plus and nobody particularly has
>     stepped up to try to modernise the code (beyond some occasional
>     work here and there)
>   * we often don't have test cases for them, which means that if we
>     do try to do the necessary refactoring work on them we have no
>     idea if they even still work at all afterwards
> 
> All these machine types are also of hardware that has largely passed
> away into history and where I would not be surprised to find that
> e.g. the Linux kernel support was never tested on real hardware
> any more.
> 
> So I would like to explore whether we can deprecate-and-drop
> some or all of them. This would let us delete the code entirely
> rather than spending a long time trying to bring it up to scratch
> for a probably very small to nonexistent userbase. The aim of this
> email is to see if anybody is still using any of these and would be
> upset if they went away. Reports of "I tried to use this machine
> type and it's just broken" are also interesting as they would
> strongly suggest that the machine has no real users and can be
> removed.
> 
> The machines I have in mind are:
> 
> PXA2xx machines:
> 
> akita                Sharp SL-C1000 (Akita) PDA (PXA270)
> borzoi               Sharp SL-C3100 (Borzoi) PDA (PXA270)
> connex               Gumstix Connex (PXA255)
> mainstone            Mainstone II (PXA27x)
> spitz                Sharp SL-C3000 (Spitz) PDA (PXA270)
> terrier              Sharp SL-C3200 (Terrier) PDA (PXA270)
> tosa                 Sharp SL-6000 (Tosa) PDA (PXA255)
> verdex               Gumstix Verdex Pro XL6P COMs (PXA270)
> z2                   Zipit Z2 (PXA27x)
> 
I test akita, borzoi, spitz, and terrier. Upstream Linux removed support
for mainstone, tosa, and z2 from the Linux kernel as of version 6.0, so
I am no longer testing those.

I never managed to boot connex or verdex.

> OMAP1 machines:
> 
> cheetah              Palm Tungsten|E aka. Cheetah PDA (OMAP310)
> sx1                  Siemens SX1 (OMAP310) V2
> sx1-v1               Siemens SX1 (OMAP310) V1
> 
I test sx1. I don't think I ever tried cheetah, and I could not get sx1-v1
to work.

> OMAP2 machines:
> 
> n800                 Nokia N800 tablet aka. RX-34 (OMAP2420)
> n810                 Nokia N810 tablet aka. RX-44 (OMAP2420)
> 
I never managed to get those to boot the Linux kernel.

> The one SA1110 machine:
> 
> collie               Sharp SL-5500 (Collie) PDA (SA-1110)
> 
I do test collie.

All the ones I use still boot the latest Linux kernel.

> Obviously if we can remove all the machines that used a given
> SoC, that's much more effective than if we just delete one or two.
> 
> I don't have any test images for the SA1110 or OMAP1 machines,
> so those are the ones I am most keen to be able to drop.
> I do have test images for a few of the pxa2xx and the OMAP2 machines.
> 
I don't mind dropping them, just listing what I use for testing the
Linux kernel. I suspect I may be the only "user" of those boards,
though, both in Linux and qemu.

Guenter

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Marcin Juszkiewicz]

W dniu 12.02.2024 o 15:36, Guenter Roeck pisze:

>> The machines I have in mind are:
>>
>> PXA2xx machines:
>>
>> akita                Sharp SL-C1000 (Akita) PDA (PXA270)
>> borzoi               Sharp SL-C3100 (Borzoi) PDA (PXA270)
>> connex               Gumstix Connex (PXA255)
>> mainstone            Mainstone II (PXA27x)
>> spitz                Sharp SL-C3000 (Spitz) PDA (PXA270)
>> terrier              Sharp SL-C3200 (Terrier) PDA (PXA270)
>> tosa                 Sharp SL-6000 (Tosa) PDA (PXA255)
>> verdex               Gumstix Verdex Pro XL6P COMs (PXA270)
>> z2                   Zipit Z2 (PXA27x)
>>
> I test akita, borzoi, spitz, and terrier. Upstream Linux removed support
> for mainstone, tosa, and z2 from the Linux kernel as of version 6.0, so
> I am no longer testing those.

I do wonder are those Zaurus models also boot kernels which QEMU boots. 
Would love to see someone still using those old palmtops. I put my 
Zauruses (collie, poodle, c7x0) into drawer long time ago.

>> OMAP2 machines:
>>
>> n800                 Nokia N800 tablet aka. RX-34 (OMAP2420)
>> n810                 Nokia N810 tablet aka. RX-44 (OMAP2420)
>>
> I never managed to get those to boot the Linux kernel.

They were working in 2008. I was running Maemo and Poky Linux then. 
Never tried later.

>> The one SA1110 machine:
>>
>> collie               Sharp SL-5500 (Collie) PDA (SA-1110)
>>
> I do test collie.

Can you share kernel/initrd/config? I wanted to boot something at 20th 
anniversary of buying one but was unable to build anything bootable on 
either QEMU/collie or physical one.

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Guenter Roeck]

Hi,

On Tue, Feb 13, 2024 at 02:42:29PM +0100, Marcin Juszkiewicz wrote:
> 
> > > The one SA1110 machine:
> > > 
> > > collie               Sharp SL-5500 (Collie) PDA (SA-1110)
> > > 
> > I do test collie.
> 
> Can you share kernel/initrd/config? I wanted to boot something at 20th
> anniversary of buying one but was unable to build anything bootable on
> either QEMU/collie or physical one.
> 

You'll find it at
	https://github.com/groeck/linux-build-test/tree/master/rootfs/arm

Essentially it is collie_defconfig plus some additional configuration
options (BLK_DEV_INITRD and EABI are essential), and the rootfs is
rootfs-sa110.cpio.gz. It boots from initrd. I never managed to get it
booting from flash.

Guenter

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Peter Maydell]

On Mon, 12 Feb 2024 at 14:36, Guenter Roeck <linux@roeck-us.net> wrote:
> On 2/12/24 04:32, Peter Maydell wrote:
> > The machines I have in mind are:
> >
> > PXA2xx machines:
> >
> > akita                Sharp SL-C1000 (Akita) PDA (PXA270)
> > borzoi               Sharp SL-C3100 (Borzoi) PDA (PXA270)
> > connex               Gumstix Connex (PXA255)
> > mainstone            Mainstone II (PXA27x)
> > spitz                Sharp SL-C3000 (Spitz) PDA (PXA270)
> > terrier              Sharp SL-C3200 (Terrier) PDA (PXA270)
> > tosa                 Sharp SL-6000 (Tosa) PDA (PXA255)
> > verdex               Gumstix Verdex Pro XL6P COMs (PXA270)
> > z2                   Zipit Z2 (PXA27x)
> >
> I test akita, borzoi, spitz, and terrier. Upstream Linux removed support
> for mainstone, tosa, and z2 from the Linux kernel as of version 6.0, so
> I am no longer testing those.
>
> I never managed to boot connex or verdex.
>
> > OMAP1 machines:
> >
> > cheetah              Palm Tungsten|E aka. Cheetah PDA (OMAP310)
> > sx1                  Siemens SX1 (OMAP310) V2
> > sx1-v1               Siemens SX1 (OMAP310) V1
> >
> I test sx1. I don't think I ever tried cheetah, and I could not get sx1-v1
> to work.
>
> > OMAP2 machines:
> >
> > n800                 Nokia N800 tablet aka. RX-34 (OMAP2420)
> > n810                 Nokia N810 tablet aka. RX-44 (OMAP2420)
> >
> I never managed to get those to boot the Linux kernel.
>
> > The one SA1110 machine:
> >
> > collie               Sharp SL-5500 (Collie) PDA (SA-1110)
> >
> I do test collie.
>
> All the ones I use still boot the latest Linux kernel.
>
> > Obviously if we can remove all the machines that used a given
> > SoC, that's much more effective than if we just delete one or two.
> >
> > I don't have any test images for the SA1110 or OMAP1 machines,
> > so those are the ones I am most keen to be able to drop.
> > I do have test images for a few of the pxa2xx and the OMAP2 machines.
> >
> I don't mind dropping them, just listing what I use for testing the
> Linux kernel. I suspect I may be the only "user" of those boards,
> though, both in Linux and qemu.

Mmm; there's not much point in both QEMU and the kernel
maintaining code that nobody's using. Are you considering
dropping support for any of these SoC families from the kernel?

It sounds like between the two of us we do have at least one
test image per SoC type if we do keep any of these, but
if it isn't going to inconvenience kernel testing I'm
inclined to go ahead with deprecate-and-drop for the whole lot.
(With QEMU's deprecate-and-drop policy, that would be "announce
deprecation now for 9.0, keep in 9.1, remove before 9.2 release
at the end of the year".) At a minimum I would like to drop
the OMAP1 and OMAP2 boards, as that's the biggest code burden.

thanks
-- PMM

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Guenter Roeck]

On Tue, Feb 13, 2024 at 03:14:21PM +0000, Peter Maydell wrote:
> On Mon, 12 Feb 2024 at 14:36, Guenter Roeck <linux@roeck-us.net> wrote:
> > On 2/12/24 04:32, Peter Maydell wrote:
> > > The machines I have in mind are:
> > >
> > > PXA2xx machines:
> > >
> > > akita                Sharp SL-C1000 (Akita) PDA (PXA270)
> > > borzoi               Sharp SL-C3100 (Borzoi) PDA (PXA270)
> > > connex               Gumstix Connex (PXA255)
> > > mainstone            Mainstone II (PXA27x)
> > > spitz                Sharp SL-C3000 (Spitz) PDA (PXA270)
> > > terrier              Sharp SL-C3200 (Terrier) PDA (PXA270)
> > > tosa                 Sharp SL-6000 (Tosa) PDA (PXA255)
> > > verdex               Gumstix Verdex Pro XL6P COMs (PXA270)
> > > z2                   Zipit Z2 (PXA27x)
> > >
> > I test akita, borzoi, spitz, and terrier. Upstream Linux removed support
> > for mainstone, tosa, and z2 from the Linux kernel as of version 6.0, so
> > I am no longer testing those.
> >
> > I never managed to boot connex or verdex.
> >
> > > OMAP1 machines:
> > >
> > > cheetah              Palm Tungsten|E aka. Cheetah PDA (OMAP310)
> > > sx1                  Siemens SX1 (OMAP310) V2
> > > sx1-v1               Siemens SX1 (OMAP310) V1
> > >
> > I test sx1. I don't think I ever tried cheetah, and I could not get sx1-v1
> > to work.
> >
> > > OMAP2 machines:
> > >
> > > n800                 Nokia N800 tablet aka. RX-34 (OMAP2420)
> > > n810                 Nokia N810 tablet aka. RX-44 (OMAP2420)
> > >
> > I never managed to get those to boot the Linux kernel.
> >
> > > The one SA1110 machine:
> > >
> > > collie               Sharp SL-5500 (Collie) PDA (SA-1110)
> > >
> > I do test collie.
> >
> > All the ones I use still boot the latest Linux kernel.
> >
> > > Obviously if we can remove all the machines that used a given
> > > SoC, that's much more effective than if we just delete one or two.
> > >
> > > I don't have any test images for the SA1110 or OMAP1 machines,
> > > so those are the ones I am most keen to be able to drop.
> > > I do have test images for a few of the pxa2xx and the OMAP2 machines.
> > >
> > I don't mind dropping them, just listing what I use for testing the
> > Linux kernel. I suspect I may be the only "user" of those boards,
> > though, both in Linux and qemu.
> 
> Mmm; there's not much point in both QEMU and the kernel
> maintaining code that nobody's using. Are you considering
> dropping support for any of these SoC families from the kernel?
> 
Not me personally. Arnd is the one mostly involved in dropping
support of obsolete hardware from the kernel.

> It sounds like between the two of us we do have at least one
> test image per SoC type if we do keep any of these, but
> if it isn't going to inconvenience kernel testing I'm
> inclined to go ahead with deprecate-and-drop for the whole lot.
> (With QEMU's deprecate-and-drop policy, that would be "announce
> deprecation now for 9.0, keep in 9.1, remove before 9.2 release
> at the end of the year".) At a minimum I would like to drop
> the OMAP1 and OMAP2 boards, as that's the biggest code burden.
> 

I am copying Arnd, the OMAP1 Linux kernel maintainers, PXA2 maintainers,
and the Linux omap mailing list for input. Sorry for the noise for those
who don't care, but I think it is useful to have your voices heard.

Personally I think it very unlikely that anyone is using the latest Linux
kernel on any of the affected machines, but I may be wrong.

Thanks,
Guenter

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Arnd Bergmann]

On Tue, Feb 13, 2024, at 16:36, Guenter Roeck wrote:
> On Tue, Feb 13, 2024 at 03:14:21PM +0000, Peter Maydell wrote:
>> On Mon, 12 Feb 2024 at 14:36, Guenter Roeck <linux@roeck-us.net> wrote:
>> > On 2/12/24 04:32, Peter Maydell wrote:
>> > > The machines I have in mind are:
>> > >
>> > > PXA2xx machines:
>> > >
>> > > akita                Sharp SL-C1000 (Akita) PDA (PXA270)
>> > > borzoi               Sharp SL-C3100 (Borzoi) PDA (PXA270)
>> > > connex               Gumstix Connex (PXA255)
>> > > mainstone            Mainstone II (PXA27x)
>> > > spitz                Sharp SL-C3000 (Spitz) PDA (PXA270)
>> > > terrier              Sharp SL-C3200 (Terrier) PDA (PXA270)
>> > > tosa                 Sharp SL-6000 (Tosa) PDA (PXA255)
>> > > verdex               Gumstix Verdex Pro XL6P COMs (PXA270)
>> > > z2                   Zipit Z2 (PXA27x)
>> > >
>> > I test akita, borzoi, spitz, and terrier. Upstream Linux removed support
>> > for mainstone, tosa, and z2 from the Linux kernel as of version 6.0, so

It was 6.3 (about one year ago).

>> > I am no longer testing those.
>> >
>> > I never managed to boot connex or verdex.

I kept specifically the pxa boards that would be sensible to port
to devicetree because they had qemu support. gumstix verdex is the
one with the most RAM out of those; spitz, sharpsl and their
variants are the ones that some of us still have around.

Robert had working devicetree support for some machines out of tree
that he has not submitted, and presumably not worked on since.

Unless someone starts working on converting the remaining
pxa board files to DT, we can probably remove them after the
next LTS kernel a year from now.

I have no objection to removing them from qemu if that helps,
the existing qemu releases should be sufficient for anyone
trying the conversion.

>> > > OMAP1 machines:
>> > >
>> > > cheetah              Palm Tungsten|E aka. Cheetah PDA (OMAP310)
>> > > sx1                  Siemens SX1 (OMAP310) V2
>> > > sx1-v1               Siemens SX1 (OMAP310) V1
>> > >
>> > I test sx1. I don't think I ever tried cheetah, and I could not get sx1-v1
>> > to work.

This is similar. omap1 development is slightly more active
than pxa, but then again they have no DT support today and
are unlikely to ever get there at this point.

Out of the five machines that are still supported in the
kernel, I think three still run on hardware (osk, ams-delta
and nokia770), while the other ones were left there only
for their qemu support. I don't mind removing them from
the kernel as well if they are gone from qemu.

>> > > OMAP2 machines:
>> > >
>> > > n800                 Nokia N800 tablet aka. RX-34 (OMAP2420)
>> > > n810                 Nokia N810 tablet aka. RX-44 (OMAP2420)
>> > >
>> > I never managed to get those to boot the Linux kernel.

I think Tony still tests these on both hardware and qemu.
The platform side here is much more modern than any of the
others above since it does use DT and it has enough RAM
to be somewhat usable.

On the other hand, this is the one platform actually using
the cursed arm1136r0 core (not counting imx31 and
realview here as I'm not aware of any real users), and
anything that would get us closer to dropping support for
this CPU would be welcome ;-)

>> > > The one SA1110 machine:
>> > >
>> > > collie               Sharp SL-5500 (Collie) PDA (SA-1110)
>> > >
>> > I do test collie.

Adding Linus Walleij and Stefan Lehner to Cc, as they were
interested in modernizing sa1100 back in 2022. If they
are still interested in that, they might want to keep collie
support.

Surprisingly, at the time I removed unused old board files,
there was a lot more interest in sa1100 than in the newer
pxa platform, which I guess wasn't as appealing for
retrocomputing yet.

>> > All the ones I use still boot the latest Linux kernel.
>> >
>> > > Obviously if we can remove all the machines that used a given
>> > > SoC, that's much more effective than if we just delete one or two.
>> > >
>> > > I don't have any test images for the SA1110 or OMAP1 machines,
>> > > so those are the ones I am most keen to be able to drop.
>> > > I do have test images for a few of the pxa2xx and the OMAP2 machines.
>> > >
>> > I don't mind dropping them, just listing what I use for testing the
>> > Linux kernel. I suspect I may be the only "user" of those boards,
>> > though, both in Linux and qemu.
>> 
>> Mmm; there's not much point in both QEMU and the kernel
>> maintaining code that nobody's using. Are you considering
>> dropping support for any of these SoC families from the kernel?
>> 
> Not me personally. Arnd is the one mostly involved in dropping
> support of obsolete hardware from the kernel

These are all clearly among the least maintained boards we have
left in the kernel after the last purge. At the time I asked
for remaining users in 2022, I kept pretty much anything that
had the slightest chance of still being used and I was already
planning another round for the next LTS kernel in early 2023
that would be more aggressive about removing things that
nobody is working on modernizing.

>> It sounds like between the two of us we do have at least one
>> test image per SoC type if we do keep any of these, but
>> if it isn't going to inconvenience kernel testing I'm
>> inclined to go ahead with deprecate-and-drop for the whole lot.
>> (With QEMU's deprecate-and-drop policy, that would be "announce
>> deprecation now for 9.0, keep in 9.1, remove before 9.2 release
>> at the end of the year".) At a minimum I would like to drop
>> the OMAP1 and OMAP2 boards, as that's the biggest code burden.
>
> I am copying Arnd, the OMAP1 Linux kernel maintainers, PXA2 maintainers,
> and the Linux omap mailing list for input. Sorry for the noise for those
> who don't care, but I think it is useful to have your voices heard.
>
> Personally I think it very unlikely that anyone is using the latest Linux
> kernel on any of the affected machines, but I may be wrong.

I imagine that the Nokia machines are the most likely to still
be used somewhere.

       Arnd 

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Linus Walleij]

On Tue, Feb 13, 2024 at 9:12 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Tue, Feb 13, 2024, at 16:36, Guenter Roeck wrote:
> > On Tue, Feb 13, 2024 at 03:14:21PM +0000, Peter Maydell wrote:
> >> On Mon, 12 Feb 2024 at 14:36, Guenter Roeck <linux@roeck-us.net> wrote:
> >> > On 2/12/24 04:32, Peter Maydell wrote:

> >> > > The one SA1110 machine:
> >> > >
> >> > > collie               Sharp SL-5500 (Collie) PDA (SA-1110)
> >> > >
> >> > I do test collie.
>
> Adding Linus Walleij and Stefan Lehner to Cc, as they were
> interested in modernizing sa1100 back in 2022. If they
> are still interested in that, they might want to keep collie
> support.

I'm not personally interested in the Collie, I have a SA1100 hardware
but not that one.

> Surprisingly, at the time I removed unused old board files,
> there was a lot more interest in sa1100 than in the newer
> pxa platform, which I guess wasn't as appealing for
> retrocomputing yet.

Andrea Adami and Dmitry Eremin-Solenikov did the work in 2017 to
modernize it a bit, and Russell helped out. I was under the impression
that they only used real hardware though!

The Collie is popular because it is/was easy to get hold of and
easy to hack. PXA was in candybar phones (right?) which
are just veritable fortresses and really hard to hack so that is why
there is no interest (except for the occasional hyperfocused Harald
Welte), so those are a bit like the iPhones: you *can* boot something
custom on them, but it won't be easy or quick, and not as fun and
rewarding.

The thriving world of PostmarketOS only exist because Google was
clever to realize devices should have a developer mode.

Yours,
Linus Walleij

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Arnd Bergmann]

On Tue, Feb 13, 2024, at 22:21, Linus Walleij wrote:

> The Collie is popular because it is/was easy to get hold of and
> easy to hack. PXA was in candybar phones (right?) which
> are just veritable fortresses and really hard to hack so that is why
> there is no interest (except for the occasional hyperfocused Harald
> Welte), so those are a bit like the iPhones: you *can* boot something
> custom on them, but it won't be easy or quick, and not as fun and
> rewarding.

The PXA machines that we support in kernel and qemu are either
industrial/embedded machines or upgraded versions of the SA1100
PDAs (sharpsl), not phones.

OTOH, these chips came out between 2003 and 2007 so I can
also see how people at the time had already moved away from
using pure PDAs to Symbian or Blackberry phones, so there
might just be fewer PDAs that got sold with PXA than with
SA1100 before there were smartphones.

      Arnd

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Dmitry Baryshkov]

On Tue, 13 Feb 2024 at 23:22, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Tue, Feb 13, 2024 at 9:12 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tue, Feb 13, 2024, at 16:36, Guenter Roeck wrote:
> > > On Tue, Feb 13, 2024 at 03:14:21PM +0000, Peter Maydell wrote:
> > >> On Mon, 12 Feb 2024 at 14:36, Guenter Roeck <linux@roeck-us.net> wrote:
> > >> > On 2/12/24 04:32, Peter Maydell wrote:
>
> > >> > > The one SA1110 machine:
> > >> > >
> > >> > > collie               Sharp SL-5500 (Collie) PDA (SA-1110)
> > >> > >
> > >> > I do test collie.
> >
> > Adding Linus Walleij and Stefan Lehner to Cc, as they were
> > interested in modernizing sa1100 back in 2022. If they
> > are still interested in that, they might want to keep collie
> > support.
>
> I'm not personally interested in the Collie, I have a SA1100 hardware
> but not that one.
>
> > Surprisingly, at the time I removed unused old board files,
> > there was a lot more interest in sa1100 than in the newer
> > pxa platform, which I guess wasn't as appealing for
> > retrocomputing yet.
>
> Andrea Adami and Dmitry Eremin-Solenikov did the work in 2017 to
> modernize it a bit, and Russell helped out. I was under the impression
> that they only used real hardware though!

I used both Qemu and actual hardware (having collie, poodle, tosa and
c860 that was easy).

The biggest issue with Zaurus PDAs was that supporting interesting
parts of the platform (PCMCIA, companion chips) required almost
rebootstrapping of the corresponding drivers.
E.g. I had a separate driver for the LoCoMo chip which worked properly
with the DT systems.
PCMCIA was a huuuge trouble and it didn't play well at all. The driver
must be rewritten to use the component framework.

lf there is interest in modernising / updating StrongARM / PXA
devices, please count me in. I don't have time to lead the effort, but
I'd like to contribute.

> The Collie is popular because it is/was easy to get hold of and
> easy to hack. PXA was in candybar phones (right?) which
> are just veritable fortresses and really hard to hack so that is why
> there is no interest (except for the occasional hyperfocused Harald
> Welte), so those are a bit like the iPhones: you *can* boot something
> custom on them, but it won't be easy or quick, and not as fun and
> rewarding.
>
> The thriving world of PostmarketOS only exist because Google was
> clever to realize devices should have a developer mode.

There were two projects that worked on reenabling phones and PDAs from
that era, hack'n'dev and handhelds.org. I think both of them were dead
when the Zaurus was still alive and kicking.

-- 
With best wishes
Dmitry

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Marcin Juszkiewicz]

W dniu 14.02.2024 o 1:26 PM, Dmitry Baryshkov pisze:
>> The thriving world of PostmarketOS only exist because Google was
>> clever to realize devices should have a developer mode.

> There were two projects that worked on reenabling phones and PDAs from
> that era, hack'n'dev and handhelds.org. I think both of them were dead
> when the Zaurus was still alive and kicking.

I left handhelds.org developer community in 2007 due to trademark wars 
when admins wanted to take control of several projects hosted there.

LinuxToGo was created in 2006 and some projects moved there from hh.org 
server.

Most of OpenZaurus/Ångström developers abandoned Zaurus devices in 2008. 
Usually in favour of Nokia 770/n800/n810 tablets.

Both OpenZaurus and Ångström used own hosting in handhelds.org era.

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Andrea Adami]

On Wed, Feb 14, 2024 at 2:39 PM Marcin Juszkiewicz
<marcin.juszkiewicz@linaro.org> wrote:
>
> Most of OpenZaurus/Ångström developers abandoned Zaurus devices in 2008.
> Usually in favour of Nokia 770/n800/n810 tablets.
>
> Both OpenZaurus and Ångström used own hosting in handhelds.org era.

I joined OpenEmbedded in that years and it was the only reliable repository.
The most recent works for kernel have been committed there, in the
meta-handheld layer.
Due to my limited knowledge I could only contribute to finish MTD
support for Zaurus.

I don't have anymore the devices, in perspective I can only imagine
Qemu support if any.
It was fun, thanks to all for your support!

Cheers
Andrea Adami

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Arnd Bergmann]

On Wed, Feb 14, 2024, at 13:26, Dmitry Baryshkov wrote:
> On Tue, 13 Feb 2024 at 23:22, Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Tue, Feb 13, 2024 at 9:12 PM Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Tue, Feb 13, 2024, at 16:36, Guenter Roeck wrote:
>> > > On Tue, Feb 13, 2024 at 03:14:21PM +0000, Peter Maydell wrote:
>>
>> Andrea Adami and Dmitry Eremin-Solenikov did the work in 2017 to
>> modernize it a bit, and Russell helped out. I was under the impression
>> that they only used real hardware though!
>
> I used both Qemu and actual hardware (having collie, poodle, tosa and
> c860 that was easy).
>
> The biggest issue with Zaurus PDAs was that supporting interesting
> parts of the platform (PCMCIA, companion chips) required almost
> rebootstrapping of the corresponding drivers.
> E.g. I had a separate driver for the LoCoMo chip which worked properly
> with the DT systems.
> PCMCIA was a huuuge trouble and it didn't play well at all. The driver
> must be rewritten to use the component framework.

If we want to actually go there, I think the best option for PCMCIA
support is likely to replace the entire "soc_common" pcmcia driver
with a simple drivers/pata/ storage driver and no support for
other cards. There was a driver until commit 38943cbd25a2
("ata: remove palmld pata driver") that could serve as an
template.

      Arnd

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Andreas Kemnade]

On Wed, 14 Feb 2024 23:42:58 +0100
"Arnd Bergmann" <arnd@arndb.de> wrote:

> On Wed, Feb 14, 2024, at 13:26, Dmitry Baryshkov wrote:
> > On Tue, 13 Feb 2024 at 23:22, Linus Walleij <linus.walleij@linaro.org> wrote:  
> >> On Tue, Feb 13, 2024 at 9:12 PM Arnd Bergmann <arnd@arndb.de> wrote:  
> >> > On Tue, Feb 13, 2024, at 16:36, Guenter Roeck wrote:  
> >> > > On Tue, Feb 13, 2024 at 03:14:21PM +0000, Peter Maydell wrote:  
> >>
> >> Andrea Adami and Dmitry Eremin-Solenikov did the work in 2017 to
> >> modernize it a bit, and Russell helped out. I was under the impression
> >> that they only used real hardware though!  
> >
> > I used both Qemu and actual hardware (having collie, poodle, tosa and
> > c860 that was easy).
> >
> > The biggest issue with Zaurus PDAs was that supporting interesting
> > parts of the platform (PCMCIA, companion chips) required almost
> > rebootstrapping of the corresponding drivers.
> > E.g. I had a separate driver for the LoCoMo chip which worked properly
> > with the DT systems.
> > PCMCIA was a huuuge trouble and it didn't play well at all. The driver
> > must be rewritten to use the component framework.  
> 
> If we want to actually go there, I think the best option for PCMCIA
> support is likely to replace the entire "soc_common" pcmcia driver
> with a simple drivers/pata/ storage driver and no support for
> other cards. There was a driver until commit 38943cbd25a2
> ("ata: remove palmld pata driver") that could serve as an
> template.
> 
hmm, main usage for PCMCIA/CF in those devices was often something else,
not storage, at least on the IPAQ h2200. Wondering wether that road is
actually good. When I was mainly using those devices, I was not good in
mainlining things.
I loved that daylight-visible display.

Regards,
Andreas 

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Arnd Bergmann]

On Thu, Feb 15, 2024, at 09:31, Andreas Kemnade wrote:
> On Wed, 14 Feb 2024 23:42:58 +0100
> "Arnd Bergmann" <arnd@arndb.de> wrote:
>> On Wed, Feb 14, 2024, at 13:26, Dmitry Baryshkov wrote:
>> > On Tue, 13 Feb 2024 at 23:22, Linus Walleij <linus.walleij@linaro.org> wrote:  
>> >> On Tue, Feb 13, 2024 at 9:12 PM Arnd Bergmann <arnd@arndb.de> wrote:  
>> >> > On Tue, Feb 13, 2024, at 16:36, Guenter Roeck wrote:  
>> >> > > On Tue, Feb 13, 2024 at 03:14:21PM +0000, Peter Maydell wrote:  
>> >>
>> >> Andrea Adami and Dmitry Eremin-Solenikov did the work in 2017 to
>> >> modernize it a bit, and Russell helped out. I was under the impression
>> >> that they only used real hardware though!  
>> >
>> > I used both Qemu and actual hardware (having collie, poodle, tosa and
>> > c860 that was easy).
>> >
>> > The biggest issue with Zaurus PDAs was that supporting interesting
>> > parts of the platform (PCMCIA, companion chips) required almost
>> > rebootstrapping of the corresponding drivers.
>> > E.g. I had a separate driver for the LoCoMo chip which worked properly
>> > with the DT systems.
>> > PCMCIA was a huuuge trouble and it didn't play well at all. The driver
>> > must be rewritten to use the component framework.  
>> 
>> If we want to actually go there, I think the best option for PCMCIA
>> support is likely to replace the entire "soc_common" pcmcia driver
>> with a simple drivers/pata/ storage driver and no support for
>> other cards. There was a driver until commit 38943cbd25a2
>> ("ata: remove palmld pata driver") that could serve as an
>> template.
>> 
> hmm, main usage for PCMCIA/CF in those devices was often something else,
> not storage, at least on the IPAQ h2200. Wondering wether that road is
> actually good. When I was mainly using those devices, I was not good in
> mainlining things.

Do we still support any non-storage CF devices that someone might
actually use? Do you have a specific example in mind? These are
the currently supported devices that I see:

git grep -B4 -w depends.*PCMCIA | grep "Kconfig-\(config\|menuconfig\)" | grep -v ^drivers/pcmcia
drivers/ata/Kconfig-config PATA_PCMCIA
drivers/bluetooth/Kconfig-config BT_HCIDTL1
drivers/bluetooth/Kconfig-config BT_HCIBT3C
drivers/bluetooth/Kconfig-config BT_HCIBLUECARD
drivers/comedi/Kconfig-menuconfig COMEDI_PCMCIA_DRIVERS
drivers/mmc/host/Kconfig-config MMC_SDRICOH_CS
drivers/mtd/maps/Kconfig-config MTD_PCMCIA
drivers/mtd/maps/Kconfig-config MTD_PCMCIA_ANONYMOUS
drivers/net/arcnet/Kconfig-menuconfig ARCNET
drivers/net/arcnet/Kconfig-config ARCNET_COM20020_CS
drivers/net/can/sja1000/Kconfig-config CAN_EMS_PCMCIA
drivers/net/can/sja1000/Kconfig-config CAN_PEAK_PCMCIA
drivers/net/can/softing/Kconfig-config CAN_SOFTING_CS
drivers/net/ethernet/3com/Kconfig-config NET_VENDOR_3COM
drivers/net/ethernet/3com/Kconfig-config PCMCIA_3C574
drivers/net/ethernet/3com/Kconfig-config PCMCIA_3C589
drivers/net/ethernet/8390/Kconfig-config PCMCIA_AXNET
drivers/net/ethernet/8390/Kconfig-config APNE
drivers/net/ethernet/8390/Kconfig-config PCMCIA_PCNET
drivers/net/ethernet/amd/Kconfig-config PCMCIA_NMCLAN
drivers/net/ethernet/fujitsu/Kconfig-config NET_VENDOR_FUJITSU
drivers/net/ethernet/fujitsu/Kconfig-config PCMCIA_FMVJ18X
drivers/net/ethernet/smsc/Kconfig-config PCMCIA_SMC91C92
drivers/net/ethernet/xircom/Kconfig-config NET_VENDOR_XIRCOM
drivers/net/ethernet/xircom/Kconfig-config PCMCIA_XIRC2PS
drivers/parport/Kconfig-config PARPORT_PC_PCMCIA
drivers/scsi/pcmcia/Kconfig-menuconfig SCSI_LOWLEVEL_PCMCIA
drivers/ssb/Kconfig-config SSB_PCMCIAHOST_POSSIBLE
drivers/tty/Kconfig-config IPWIRELESS
drivers/tty/serial/8250/Kconfig-config SERIAL_8250_CS
drivers/usb/host/Kconfig-config USB_SL811_CS
sound/pcmcia/Kconfig-menuconfig SND_PCMCIA

     Arnd

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Dmitry Baryshkov]

On Thu, 15 Feb 2024 at 10:45, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Feb 15, 2024, at 09:31, Andreas Kemnade wrote:
> > On Wed, 14 Feb 2024 23:42:58 +0100
> > "Arnd Bergmann" <arnd@arndb.de> wrote:
> >> On Wed, Feb 14, 2024, at 13:26, Dmitry Baryshkov wrote:
> >> > On Tue, 13 Feb 2024 at 23:22, Linus Walleij <linus.walleij@linaro.org> wrote:
> >> >> On Tue, Feb 13, 2024 at 9:12 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >> >> > On Tue, Feb 13, 2024, at 16:36, Guenter Roeck wrote:
> >> >> > > On Tue, Feb 13, 2024 at 03:14:21PM +0000, Peter Maydell wrote:
> >> >>
> >> >> Andrea Adami and Dmitry Eremin-Solenikov did the work in 2017 to
> >> >> modernize it a bit, and Russell helped out. I was under the impression
> >> >> that they only used real hardware though!
> >> >
> >> > I used both Qemu and actual hardware (having collie, poodle, tosa and
> >> > c860 that was easy).
> >> >
> >> > The biggest issue with Zaurus PDAs was that supporting interesting
> >> > parts of the platform (PCMCIA, companion chips) required almost
> >> > rebootstrapping of the corresponding drivers.
> >> > E.g. I had a separate driver for the LoCoMo chip which worked properly
> >> > with the DT systems.
> >> > PCMCIA was a huuuge trouble and it didn't play well at all. The driver
> >> > must be rewritten to use the component framework.
> >>
> >> If we want to actually go there, I think the best option for PCMCIA
> >> support is likely to replace the entire "soc_common" pcmcia driver
> >> with a simple drivers/pata/ storage driver and no support for
> >> other cards. There was a driver until commit 38943cbd25a2
> >> ("ata: remove palmld pata driver") that could serve as an
> >> template.
> >>
> > hmm, main usage for PCMCIA/CF in those devices was often something else,
> > not storage, at least on the IPAQ h2200. Wondering wether that road is
> > actually good. When I was mainly using those devices, I was not good in
> > mainlining things.
>
> Do we still support any non-storage CF devices that someone might
> actually use? Do you have a specific example in mind? These are
> the currently supported devices that I see:

The Bluetooth over the PCMCIA UART worked last time I checked it and
according to your grep it is still a valid user.

If we are talking about re-bootstrap of the PCMCIA subsystem, hostap
and orinoco come to my mind. We dropped those drivers a while ago, but
back at that time they were very useful. Also I had the out-of-tree
driver for Sharp 0.3 MP cameras using CF interface (yeah, sure, all of
those are out-of-tree nowadays).

>
> git grep -B4 -w depends.*PCMCIA | grep "Kconfig-\(config\|menuconfig\)" | grep -v ^drivers/pcmcia
> drivers/ata/Kconfig-config PATA_PCMCIA
> drivers/bluetooth/Kconfig-config BT_HCIDTL1
> drivers/bluetooth/Kconfig-config BT_HCIBT3C
> drivers/bluetooth/Kconfig-config BT_HCIBLUECARD
> drivers/comedi/Kconfig-menuconfig COMEDI_PCMCIA_DRIVERS
> drivers/mmc/host/Kconfig-config MMC_SDRICOH_CS
> drivers/mtd/maps/Kconfig-config MTD_PCMCIA
> drivers/mtd/maps/Kconfig-config MTD_PCMCIA_ANONYMOUS
> drivers/net/arcnet/Kconfig-menuconfig ARCNET
> drivers/net/arcnet/Kconfig-config ARCNET_COM20020_CS
> drivers/net/can/sja1000/Kconfig-config CAN_EMS_PCMCIA
> drivers/net/can/sja1000/Kconfig-config CAN_PEAK_PCMCIA
> drivers/net/can/softing/Kconfig-config CAN_SOFTING_CS
> drivers/net/ethernet/3com/Kconfig-config NET_VENDOR_3COM
> drivers/net/ethernet/3com/Kconfig-config PCMCIA_3C574
> drivers/net/ethernet/3com/Kconfig-config PCMCIA_3C589
> drivers/net/ethernet/8390/Kconfig-config PCMCIA_AXNET
> drivers/net/ethernet/8390/Kconfig-config APNE
> drivers/net/ethernet/8390/Kconfig-config PCMCIA_PCNET
> drivers/net/ethernet/amd/Kconfig-config PCMCIA_NMCLAN
> drivers/net/ethernet/fujitsu/Kconfig-config NET_VENDOR_FUJITSU
> drivers/net/ethernet/fujitsu/Kconfig-config PCMCIA_FMVJ18X
> drivers/net/ethernet/smsc/Kconfig-config PCMCIA_SMC91C92
> drivers/net/ethernet/xircom/Kconfig-config NET_VENDOR_XIRCOM
> drivers/net/ethernet/xircom/Kconfig-config PCMCIA_XIRC2PS
> drivers/parport/Kconfig-config PARPORT_PC_PCMCIA
> drivers/scsi/pcmcia/Kconfig-menuconfig SCSI_LOWLEVEL_PCMCIA
> drivers/ssb/Kconfig-config SSB_PCMCIAHOST_POSSIBLE
> drivers/tty/Kconfig-config IPWIRELESS
> drivers/tty/serial/8250/Kconfig-config SERIAL_8250_CS
> drivers/usb/host/Kconfig-config USB_SL811_CS
> sound/pcmcia/Kconfig-menuconfig SND_PCMCIA
>
>      Arnd



-- 
With best wishes
Dmitry

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Marcin Juszkiewicz]

W dniu 15.02.2024 o 9:52 AM, Dmitry Baryshkov pisze:
>>>> If we want to actually go there, I think the best option for PCMCIA
>>>> support is likely to replace the entire "soc_common" pcmcia driver
>>>> with a simple drivers/pata/ storage driver and no support for
>>>> other cards.

>>> hmm, main usage for PCMCIA/CF in those devices was often something else,
>>> not storage,

>> Do we still support any non-storage CF devices that someone might
>> actually use? Do you have a specific example in mind? These are
>> the currently supported devices that I see:

> The Bluetooth over the PCMCIA UART worked last time I checked it and
> according to your grep it is still a valid user.

If we want to keep those pda devices in Linux kernel then dropping 
whatever PCMCIA which is not a storage sounds like sane way.

No one is going to use such old PDA as daily tool nowadays. And if they 
want then 6.6 LTS kernel would work better due to WiFi drivers being 
still present.

Bluetooth CF cards are old, v1.x tech. WiFi is 802.11b unless you manage 
to get one of those libertas_cs cards but they were rare even when new 
(I was involved in starting 2.6 driver for it). Camera cards had own 
out-of-tree drivers at that time.

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[H. Nikolaus Schaller]

> Am 15.02.2024 um 09:31 schrieb Andreas Kemnade <andreas@kemnade.info>:
> 
> On Wed, 14 Feb 2024 23:42:58 +0100
> "Arnd Bergmann" <arnd@arndb.de> wrote:
> 
>> On Wed, Feb 14, 2024, at 13:26, Dmitry Baryshkov wrote:
>>> On Tue, 13 Feb 2024 at 23:22, Linus Walleij <linus.walleij@linaro.org> wrote:  
>>>> On Tue, Feb 13, 2024 at 9:12 PM Arnd Bergmann <arnd@arndb.de> wrote:  
>>>>> On Tue, Feb 13, 2024, at 16:36, Guenter Roeck wrote:  
>>>>>> On Tue, Feb 13, 2024 at 03:14:21PM +0000, Peter Maydell wrote:  
>>>> 
>>>> Andrea Adami and Dmitry Eremin-Solenikov did the work in 2017 to
>>>> modernize it a bit, and Russell helped out. I was under the impression
>>>> that they only used real hardware though!  
>>> 
>>> I used both Qemu and actual hardware (having collie, poodle, tosa and
>>> c860 that was easy).
>>> 
>>> The biggest issue with Zaurus PDAs was that supporting interesting
>>> parts of the platform (PCMCIA, companion chips) required almost
>>> rebootstrapping of the corresponding drivers.
>>> E.g. I had a separate driver for the LoCoMo chip which worked properly
>>> with the DT systems.
>>> PCMCIA was a huuuge trouble and it didn't play well at all. The driver
>>> must be rewritten to use the component framework.  
>> 
>> If we want to actually go there, I think the best option for PCMCIA
>> support is likely to replace the entire "soc_common" pcmcia driver
>> with a simple drivers/pata/ storage driver and no support for
>> other cards. There was a driver until commit 38943cbd25a2
>> ("ata: remove palmld pata driver") that could serve as an
>> template.
>> 
> hmm, main usage for PCMCIA/CF in those devices was often something else,
> not storage, at least on the IPAQ h2200. Wondering wether that road is

There was a WiFi CF card for the Zaurus devices and I remember having
donated one to someone who could make the drivers work.

Unfortunately my devices are collecting dust and the batteries may be
bad now.

> actually good. When I was mainly using those devices, I was not good in
> mainlining things.

Same for me...

BR,
Nikolaus

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Aaro Koskinen]

Hi,

On Tue, Feb 13, 2024 at 09:11:38PM +0100, Arnd Bergmann wrote:
> On Tue, Feb 13, 2024, at 16:36, Guenter Roeck wrote:
> >> > > OMAP1 machines:
> >> > >
> >> > > cheetah              Palm Tungsten|E aka. Cheetah PDA (OMAP310)
> >> > > sx1                  Siemens SX1 (OMAP310) V2
> >> > > sx1-v1               Siemens SX1 (OMAP310) V1
> >> > >
> >> > I test sx1. I don't think I ever tried cheetah, and I could not get sx1-v1
> >> > to work.
> 
> This is similar. omap1 development is slightly more active
> than pxa, but then again they have no DT support today and
> are unlikely to ever get there at this point.
> 
> Out of the five machines that are still supported in the
> kernel, I think three still run on hardware (osk, ams-delta
> and nokia770), while the other ones were left there only
> for their qemu support. I don't mind removing them from
> the kernel as well if they are gone from qemu.

I'm one of the OMAP1 Linux kernel maintainers, and I have Palm TE which
I have been using for testing and development (and reporting bugs,
regressions) along with those other boards you mentioned.

Since I have the real Palm HW, I haven't used QEMU for that particular
board. But however I use QEMU SX1 support frequently as it's quickest way
to check if OMAP1 is bootable, and if the basic peripherals are working.
SX1 is close to Palm/AMS-Delta, and also it's ARMv4T which is rare these
days. I think it's useful to keep it in QEMU as long there are hardware
that people use.

So my wish is to keep at least SX1 support in QEMU as long as ARMv4T
supported in the Linux kernel.

> >> > > OMAP2 machines:
> >> > >
> >> > > n800                 Nokia N800 tablet aka. RX-34 (OMAP2420)
> >> > > n810                 Nokia N810 tablet aka. RX-44 (OMAP2420)
> >> > >
> >> > I never managed to get those to boot the Linux kernel.
> 
> I think Tony still tests these on both hardware and qemu.
> The platform side here is much more modern than any of the
> others above since it does use DT and it has enough RAM
> to be somewhat usable.

I have also these boards (real hardware) and test them frequently with
mainline Linux. However, QEMU support I haven't used/needed. I recall it
was a bit buggy, and some changes in mainline made the kernel unbootable.
Unless Tony needs the support, I guess they are good to go.

(Arnd: RAM isn't everything. Some of the OMAP1 boards today are still
more useful than N800/N810, even with modern bloaty Linux.)

A.

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Tony Lindgren]

* Aaro Koskinen <aaro.koskinen@iki.fi> [240214 01:27]:
> On Tue, Feb 13, 2024 at 09:11:38PM +0100, Arnd Bergmann wrote:
> > I think Tony still tests these on both hardware and qemu.
> > The platform side here is much more modern than any of the
> > others above since it does use DT and it has enough RAM
> > to be somewhat usable.
> 
> I have also these boards (real hardware) and test them frequently with
> mainline Linux. However, QEMU support I haven't used/needed. I recall it
> was a bit buggy, and some changes in mainline made the kernel unbootable.
> Unless Tony needs the support, I guess they are good to go.

I've only used real hardware to test omap1 for at least 10 years, and I
have currently no omap1 devices booting. Still hoping to add n770 and
osk back at some point though for basic boot testing.

I could see qemu being handy for automating boot testing for git bisect,
but as far as I'm concerned no objections to dropping old device support
for qemu.

IMO it's best to concentrate on where there is activity and users, and try
to make thing easier to maintain in the long run. Anything with users and
active development happening we should try to help and encourage :)

Regards,

Tony

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Arnd Bergmann]

On Wed, Feb 14, 2024, at 02:27, Aaro Koskinen wrote:
> On Tue, Feb 13, 2024 at 09:11:38PM +0100, Arnd Bergmann wrote:
>
> I'm one of the OMAP1 Linux kernel maintainers, and I have Palm TE which
> I have been using for testing and development (and reporting bugs,
> regressions) along with those other boards you mentioned.
>
> Since I have the real Palm HW, I haven't used QEMU for that particular
> board. But however I use QEMU SX1 support frequently as it's quickest way
> to check if OMAP1 is bootable, and if the basic peripherals are working.
> SX1 is close to Palm/AMS-Delta, and also it's ARMv4T which is rare these
> days. I think it's useful to keep it in QEMU as long there are hardware
> that people use.
>
> So my wish is to keep at least SX1 support in QEMU as long as ARMv4T
> supported in the Linux kernel.

Makes sense. We have a couple of other ARMv4T systems in the kernel
that are still being tested (ep93xx, at91rm9200, clps71xx, imx1,
nspire, integrator/ap), but none of the others have any qemu
support apparently unless you count "-Mintegratorpb -cpu arm925".
All of these are are using DT or getting there (ep93xx), so we'll
probably keep them around for a while.

Similarly, we support a couple of ARMv4 (non-T) targets in the
kernel (footbridge, sa1100, rpc, moxart, gemini), but the only
one with qemu support here is sa1100/collie.

>> >> > > OMAP2 machines:
>> >> > >
>> >> > > n800                 Nokia N800 tablet aka. RX-34 (OMAP2420)
>> >> > > n810                 Nokia N810 tablet aka. RX-44 (OMAP2420)
>> >> > >
>> >> > I never managed to get those to boot the Linux kernel.
>> 
>> I think Tony still tests these on both hardware and qemu.
>> The platform side here is much more modern than any of the
>> others above since it does use DT and it has enough RAM
>> to be somewhat usable.
>
> I have also these boards (real hardware) and test them frequently with
> mainline Linux. However, QEMU support I haven't used/needed. I recall it
> was a bit buggy, and some changes in mainline made the kernel unbootable.
> Unless Tony needs the support, I guess they are good to go.

Thanks for confirming.

> (Arnd: RAM isn't everything. Some of the OMAP1 boards today are still
> more useful than N800/N810, even with modern bloaty Linux.)

Obviously RAM isn't everything, but the machines with just 32MB
or less do seem very small for real workloads, so I admit I
dismiss them easily. I am curious what you run on those, are
there any embedded distros that maintain good support for 32MB
systems on modern kernel/musl/Xorg/..., or are you using
omething older or highly customized?

     Arnd

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Daniel Mack]

On 2/13/24 21:11, Arnd Bergmann wrote:
> On Tue, Feb 13, 2024, at 16:36, Guenter Roeck wrote:
>> On Tue, Feb 13, 2024 at 03:14:21PM +0000, Peter Maydell wrote:
>>> On Mon, 12 Feb 2024 at 14:36, Guenter Roeck <linux@roeck-us.net> wrote:
>>>> On 2/12/24 04:32, Peter Maydell wrote:
>>>>> The machines I have in mind are:
>>>>>
>>>>> PXA2xx machines:
>>>>>
>>>>> akita                Sharp SL-C1000 (Akita) PDA (PXA270)
>>>>> borzoi               Sharp SL-C3100 (Borzoi) PDA (PXA270)
>>>>> connex               Gumstix Connex (PXA255)
>>>>> mainstone            Mainstone II (PXA27x)
>>>>> spitz                Sharp SL-C3000 (Spitz) PDA (PXA270)
>>>>> terrier              Sharp SL-C3200 (Terrier) PDA (PXA270)
>>>>> tosa                 Sharp SL-6000 (Tosa) PDA (PXA255)
>>>>> verdex               Gumstix Verdex Pro XL6P COMs (PXA270)
>>>>> z2                   Zipit Z2 (PXA27x)
>>>>>
>>>> I test akita, borzoi, spitz, and terrier. Upstream Linux removed support
>>>> for mainstone, tosa, and z2 from the Linux kernel as of version 6.0, so
> 
> It was 6.3 (about one year ago).
> 
>>>> I am no longer testing those.
>>>>
>>>> I never managed to boot connex or verdex.
> 
> I kept specifically the pxa boards that would be sensible to port
> to devicetree because they had qemu support. gumstix verdex is the
> one with the most RAM out of those; spitz, sharpsl and their
> variants are the ones that some of us still have around.
> 
> Robert had working devicetree support for some machines out of tree
> that he has not submitted, and presumably not worked on since.
> 
> Unless someone starts working on converting the remaining
> pxa board files to DT, we can probably remove them after the
> next LTS kernel a year from now.

I agree. Once the machines are removed, people who were actively using
them would be incentivized to work on a DT port. That's not very
complicated to do when you have the hardware to test, but almost
impossible if you don't.


Best regards,
Daniel

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Peter Maydell]

On Tue, 13 Feb 2024 at 15:36, Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Tue, Feb 13, 2024 at 03:14:21PM +0000, Peter Maydell wrote:
> > On Mon, 12 Feb 2024 at 14:36, Guenter Roeck <linux@roeck-us.net> wrote:
> > > On 2/12/24 04:32, Peter Maydell wrote:
> > > > The machines I have in mind are:
> > > >
> > > > PXA2xx machines:
> > > >
> > > > akita                Sharp SL-C1000 (Akita) PDA (PXA270)
> > > > borzoi               Sharp SL-C3100 (Borzoi) PDA (PXA270)
> > > > connex               Gumstix Connex (PXA255)
> > > > mainstone            Mainstone II (PXA27x)
> > > > spitz                Sharp SL-C3000 (Spitz) PDA (PXA270)
> > > > terrier              Sharp SL-C3200 (Terrier) PDA (PXA270)
> > > > tosa                 Sharp SL-6000 (Tosa) PDA (PXA255)
> > > > verdex               Gumstix Verdex Pro XL6P COMs (PXA270)
> > > > z2                   Zipit Z2 (PXA27x)

> > > > OMAP1 machines:
> > > >
> > > > cheetah              Palm Tungsten|E aka. Cheetah PDA (OMAP310)
> > > > sx1                  Siemens SX1 (OMAP310) V2
> > > > sx1-v1               Siemens SX1 (OMAP310) V1

> > > > OMAP2 machines:
> > > >
> > > > n800                 Nokia N800 tablet aka. RX-34 (OMAP2420)
> > > > n810                 Nokia N810 tablet aka. RX-44 (OMAP2420)

> > > > The one SA1110 machine:
> > > >
> > > > collie               Sharp SL-5500 (Collie) PDA (SA-1110)

> I am copying Arnd, the OMAP1 Linux kernel maintainers, PXA2 maintainers,
> and the Linux omap mailing list for input. Sorry for the noise for those
> who don't care, but I think it is useful to have your voices heard.

Thanks to everybody for your input on this thread. My
proposal is to drop from QEMU:
 * all the PXA2xx machines
 * all the OMAP2 machines
 * the cheetah OMAP1 machine

leaving (at least for now) sx1, sx1-v1, collie.

Rationale:
 * for QEMU dropping individual machines is much less beneficial
   than if we can drop support for an entire SoC
 * the OMAP2 QEMU code in particular is large, old and unmaintained,
   and none of the OMAP2 kernel maintainers said they were using
   QEMU in any of their testing/development
 * although Guenter is currently booting test kernels on some
   of the PXA2xx machines, nobody seemed to be using them as part
   of their active kernel development and my impression from the
   thread is that PXA is the closest of all these SoC families to
   being dropped from the kernel soon
 * nobody said they were using cheetah, so it's entirely
   untested and quite probably broken
 * on the other hand the OMAP1 sx1 model does seem to be being
   used as part of kernel development, and there was interest
   in keeping collie around

I'm going to mark these as deprecated for the QEMU 9.0 release,
which by our deprecate-and-drop policy means they will be
still present in 9.0 (due out in April) and 9.1 (August-ish),
and removed in 9.2 (December).

I'm potentially open to persuasion if anybody thinks I'm
being too drastic here; persuasion that came attached to
a desire to help modernise the QEMU code for the relevant
machines would be the most effective :-)

thanks
-- PMM

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Guenter Roeck]

On Fri, Mar 08, 2024 at 03:41:48PM +0000, Peter Maydell wrote:
> On Tue, 13 Feb 2024 at 15:36, Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On Tue, Feb 13, 2024 at 03:14:21PM +0000, Peter Maydell wrote:
> > > On Mon, 12 Feb 2024 at 14:36, Guenter Roeck <linux@roeck-us.net> wrote:
> > > > On 2/12/24 04:32, Peter Maydell wrote:
> > > > > The machines I have in mind are:
> > > > >
> > > > > PXA2xx machines:
> > > > >
> > > > > akita                Sharp SL-C1000 (Akita) PDA (PXA270)
> > > > > borzoi               Sharp SL-C3100 (Borzoi) PDA (PXA270)
> > > > > connex               Gumstix Connex (PXA255)
> > > > > mainstone            Mainstone II (PXA27x)
> > > > > spitz                Sharp SL-C3000 (Spitz) PDA (PXA270)
> > > > > terrier              Sharp SL-C3200 (Terrier) PDA (PXA270)
> > > > > tosa                 Sharp SL-6000 (Tosa) PDA (PXA255)
> > > > > verdex               Gumstix Verdex Pro XL6P COMs (PXA270)
> > > > > z2                   Zipit Z2 (PXA27x)
> 
> > > > > OMAP1 machines:
> > > > >
> > > > > cheetah              Palm Tungsten|E aka. Cheetah PDA (OMAP310)
> > > > > sx1                  Siemens SX1 (OMAP310) V2
> > > > > sx1-v1               Siemens SX1 (OMAP310) V1
> 
> > > > > OMAP2 machines:
> > > > >
> > > > > n800                 Nokia N800 tablet aka. RX-34 (OMAP2420)
> > > > > n810                 Nokia N810 tablet aka. RX-44 (OMAP2420)
> 
> > > > > The one SA1110 machine:
> > > > >
> > > > > collie               Sharp SL-5500 (Collie) PDA (SA-1110)
> 
> > I am copying Arnd, the OMAP1 Linux kernel maintainers, PXA2 maintainers,
> > and the Linux omap mailing list for input. Sorry for the noise for those
> > who don't care, but I think it is useful to have your voices heard.
> 
> Thanks to everybody for your input on this thread. My
> proposal is to drop from QEMU:
>  * all the PXA2xx machines
>  * all the OMAP2 machines
>  * the cheetah OMAP1 machine
> 
> leaving (at least for now) sx1, sx1-v1, collie.
> 
> Rationale:
>  * for QEMU dropping individual machines is much less beneficial
>    than if we can drop support for an entire SoC
>  * the OMAP2 QEMU code in particular is large, old and unmaintained,
>    and none of the OMAP2 kernel maintainers said they were using
>    QEMU in any of their testing/development
>  * although Guenter is currently booting test kernels on some
>    of the PXA2xx machines, nobody seemed to be using them as part
>    of their active kernel development and my impression from the
>    thread is that PXA is the closest of all these SoC families to
>    being dropped from the kernel soon
>  * nobody said they were using cheetah, so it's entirely
>    untested and quite probably broken
>  * on the other hand the OMAP1 sx1 model does seem to be being
>    used as part of kernel development, and there was interest
>    in keeping collie around
> 
> I'm going to mark these as deprecated for the QEMU 9.0 release,
> which by our deprecate-and-drop policy means they will be
> still present in 9.0 (due out in April) and 9.1 (August-ish),
> and removed in 9.2 (December).
> 
> I'm potentially open to persuasion if anybody thinks I'm
> being too drastic here; persuasion that came attached to
> a desire to help modernise the QEMU code for the relevant
> machines would be the most effective :-)
> 

sgtm

Guenter

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Peter Maydell]

On Fri, 8 Mar 2024 at 15:41, Peter Maydell <peter.maydell@linaro.org> wrote:
> Thanks to everybody for your input on this thread. My
> proposal is to drop from QEMU:
>  * all the PXA2xx machines
>  * all the OMAP2 machines
>  * the cheetah OMAP1 machine
>
> leaving (at least for now) sx1, sx1-v1, collie.

This has now gone through. I'm now looking for test images
for these remaining boards, so we can keep them from breaking
when we do refactoring and code cleanup/modernization.
Specifically, I'm looking for:
 * QEMU command line
 * all the binary blobs that go with it (hosted somewhere that
   doesn't mind when our CI downloads all the images to run
   its tests...)
 * ideally, exercising the SD card interface if present

Could the people who are still using/testing these boards
help here ?

thanks
-- PMM

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Guenter Roeck]

On 10/15/24 10:13, Peter Maydell wrote:
> On Fri, 8 Mar 2024 at 15:41, Peter Maydell <peter.maydell@linaro.org> wrote:
>> Thanks to everybody for your input on this thread. My
>> proposal is to drop from QEMU:
>>   * all the PXA2xx machines
>>   * all the OMAP2 machines
>>   * the cheetah OMAP1 machine
>>
>> leaving (at least for now) sx1, sx1-v1, collie.
> 
> This has now gone through. I'm now looking for test images
> for these remaining boards, so we can keep them from breaking
> when we do refactoring and code cleanup/modernization.
> Specifically, I'm looking for:
>   * QEMU command line
>   * all the binary blobs that go with it (hosted somewhere that
>     doesn't mind when our CI downloads all the images to run
>     its tests...)
>   * ideally, exercising the SD card interface if present
> 
> Could the people who are still using/testing these boards
> help here ?
> 

You'll find everything at https://github.com/groeck/linux-build-test.git,
but give me a couple of days and I'll create explicit information.
Is it ok if I create a github repository specifically for this purpose,
or does it have to be direct file downloads ?

Note that my tests only boot from sd card for sx1. I also don't have
tests for sx1-v1, only for sx1. I don't recall if I ever tried sx1-v1.

Thanks,
Guenter

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Peter Maydell]

On Tue, 15 Oct 2024 at 18:30, Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 10/15/24 10:13, Peter Maydell wrote:
> > On Fri, 8 Mar 2024 at 15:41, Peter Maydell <peter.maydell@linaro.org> wrote:
> >> Thanks to everybody for your input on this thread. My
> >> proposal is to drop from QEMU:
> >>   * all the PXA2xx machines
> >>   * all the OMAP2 machines
> >>   * the cheetah OMAP1 machine
> >>
> >> leaving (at least for now) sx1, sx1-v1, collie.
> >
> > This has now gone through. I'm now looking for test images
> > for these remaining boards, so we can keep them from breaking
> > when we do refactoring and code cleanup/modernization.
> > Specifically, I'm looking for:
> >   * QEMU command line
> >   * all the binary blobs that go with it (hosted somewhere that
> >     doesn't mind when our CI downloads all the images to run
> >     its tests...)
> >   * ideally, exercising the SD card interface if present
> >
> > Could the people who are still using/testing these boards
> > help here ?
> >
>
> You'll find everything at https://github.com/groeck/linux-build-test.git,
> but give me a couple of days and I'll create explicit information.

Yeah, I had a look at that but could only find the rootfs
and got a bit lost trying to figure out what the QEMU
commandline would end up being :-)

> Is it ok if I create a github repository specifically for this purpose,
> or does it have to be direct file downloads ?

A github repo should be OK -- I'm pretty sure we can download
from there (e.g. we already download some rootfs images from
your linux-build-test github repo).

> Note that my tests only boot from sd card for sx1. I also don't have
> tests for sx1-v1, only for sx1. I don't recall if I ever tried sx1-v1.

Looking at the QEMU machine model code they don't differ
much -- sx1-v1 has a bit less flash, and that's about it.

thanks
-- PMM

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Guenter Roeck]

On 10/15/24 10:35, Peter Maydell wrote:
> On Tue, 15 Oct 2024 at 18:30, Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On 10/15/24 10:13, Peter Maydell wrote:
>>> On Fri, 8 Mar 2024 at 15:41, Peter Maydell <peter.maydell@linaro.org> wrote:
>>>> Thanks to everybody for your input on this thread. My
>>>> proposal is to drop from QEMU:
>>>>    * all the PXA2xx machines
>>>>    * all the OMAP2 machines
>>>>    * the cheetah OMAP1 machine
>>>>
>>>> leaving (at least for now) sx1, sx1-v1, collie.
>>>
>>> This has now gone through. I'm now looking for test images
>>> for these remaining boards, so we can keep them from breaking
>>> when we do refactoring and code cleanup/modernization.
>>> Specifically, I'm looking for:
>>>    * QEMU command line
>>>    * all the binary blobs that go with it (hosted somewhere that
>>>      doesn't mind when our CI downloads all the images to run
>>>      its tests...)
>>>    * ideally, exercising the SD card interface if present
>>>
>>> Could the people who are still using/testing these boards
>>> help here ?
>>>
>>
>> You'll find everything at https://github.com/groeck/linux-build-test.git,
>> but give me a couple of days and I'll create explicit information.
> 
> Yeah, I had a look at that but could only find the rootfs
> and got a bit lost trying to figure out what the QEMU
> commandline would end up being :-)
> 

Surprise :-)

>> Is it ok if I create a github repository specifically for this purpose,
>> or does it have to be direct file downloads ?
> 
> A github repo should be OK -- I'm pretty sure we can download
> from there (e.g. we already download some rootfs images from
> your linux-build-test github repo).
> 

Please let me know if https://github.com/groeck/linux-test-downloads.git
meets your needs. For now I added 'collie'. I'll add more after it is
in a state that is useful for you.

Thanks,
Guenter

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Peter Maydell]

On Tue, 15 Oct 2024 at 19:12, Guenter Roeck <linux@roeck-us.net> wrote:
> Please let me know if https://github.com/groeck/linux-test-downloads.git
> meets your needs. For now I added 'collie'. I'll add more after it is
> in a state that is useful for you.

Yes, that's great, exactly what we need. I've put together a QEMU
'functional test' case that downloads the collie rootfs and image
and checks that they boot. (I'll send the patches for that out
in a bit.)

(I've coded the test case to pull the binaries for a specific
git revision of that repo rather than always-from-head, so
we're testing always the same thing against head-of-QEMU.)

thanks
-- PMM

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Guenter Roeck]

On 10/17/24 05:42, Peter Maydell wrote:
> On Tue, 15 Oct 2024 at 19:12, Guenter Roeck <linux@roeck-us.net> wrote:
>> Please let me know if https://github.com/groeck/linux-test-downloads.git
>> meets your needs. For now I added 'collie'. I'll add more after it is
>> in a state that is useful for you.
> 
> Yes, that's great, exactly what we need. I've put together a QEMU
> 'functional test' case that downloads the collie rootfs and image
> and checks that they boot. (I'll send the patches for that out
> in a bit.)
> 
> (I've coded the test case to pull the binaries for a specific
> git revision of that repo rather than always-from-head, so
> we're testing always the same thing against head-of-QEMU.)
> 

Sounds good. I now also added information for sx1, so you should
be able to use that as well. Please let me know if you need any
others.

Thanks,
Guenter

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Peter Maydell]

On Thu, 17 Oct 2024 at 15:12, Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 10/17/24 05:42, Peter Maydell wrote:
> > On Tue, 15 Oct 2024 at 19:12, Guenter Roeck <linux@roeck-us.net> wrote:
> >> Please let me know if https://github.com/groeck/linux-test-downloads.git
> >> meets your needs. For now I added 'collie'. I'll add more after it is
> >> in a state that is useful for you.
> >
> > Yes, that's great, exactly what we need. I've put together a QEMU
> > 'functional test' case that downloads the collie rootfs and image
> > and checks that they boot. (I'll send the patches for that out
> > in a bit.)
> >
> > (I've coded the test case to pull the binaries for a specific
> > git revision of that repo rather than always-from-head, so
> > we're testing always the same thing against head-of-QEMU.)
> >
>
> Sounds good. I now also added information for sx1, so you should
> be able to use that as well. Please let me know if you need any
> others.

I think sx1 and collie are all we need currently.

By the way, it looks to me like QEMU has a regression
somewhere where we can't boot that sx1 test for the SD
card version -- it hangs during kernel boot waiting for
the MMC card. (An elderly QEMU binary I have boots OK.)
I'm looking into what's happened there.

-- PMM

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Guenter Roeck]

On 10/17/24 07:29, Peter Maydell wrote:
> On Thu, 17 Oct 2024 at 15:12, Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On 10/17/24 05:42, Peter Maydell wrote:
>>> On Tue, 15 Oct 2024 at 19:12, Guenter Roeck <linux@roeck-us.net> wrote:
>>>> Please let me know if https://github.com/groeck/linux-test-downloads.git
>>>> meets your needs. For now I added 'collie'. I'll add more after it is
>>>> in a state that is useful for you.
>>>
>>> Yes, that's great, exactly what we need. I've put together a QEMU
>>> 'functional test' case that downloads the collie rootfs and image
>>> and checks that they boot. (I'll send the patches for that out
>>> in a bit.)
>>>
>>> (I've coded the test case to pull the binaries for a specific
>>> git revision of that repo rather than always-from-head, so
>>> we're testing always the same thing against head-of-QEMU.)
>>>
>>
>> Sounds good. I now also added information for sx1, so you should
>> be able to use that as well. Please let me know if you need any
>> others.
> 
> I think sx1 and collie are all we need currently.
> 
> By the way, it looks to me like QEMU has a regression
> somewhere where we can't boot that sx1 test for the SD
> card version -- it hangs during kernel boot waiting for
> the MMC card. (An elderly QEMU binary I have boots OK.)
> I'm looking into what's happened there.
> 

Yes, you are correct. I did a quick check; the problem started with v9.1.
v9.0 boots fine.

I didn't notice since I still use v9.0 in my testing.

Thanks,
Guenter

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Peter Maydell]

On Thu, 17 Oct 2024 at 16:29, Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 10/17/24 07:29, Peter Maydell wrote:
> > On Thu, 17 Oct 2024 at 15:12, Guenter Roeck <linux@roeck-us.net> wrote:
> >>
> >> On 10/17/24 05:42, Peter Maydell wrote:
> >>> On Tue, 15 Oct 2024 at 19:12, Guenter Roeck <linux@roeck-us.net> wrote:
> >>>> Please let me know if https://github.com/groeck/linux-test-downloads.git
> >>>> meets your needs. For now I added 'collie'. I'll add more after it is
> >>>> in a state that is useful for you.
> >>>
> >>> Yes, that's great, exactly what we need. I've put together a QEMU
> >>> 'functional test' case that downloads the collie rootfs and image
> >>> and checks that they boot. (I'll send the patches for that out
> >>> in a bit.)
> >>>
> >>> (I've coded the test case to pull the binaries for a specific
> >>> git revision of that repo rather than always-from-head, so
> >>> we're testing always the same thing against head-of-QEMU.)
> >>>
> >>
> >> Sounds good. I now also added information for sx1, so you should
> >> be able to use that as well. Please let me know if you need any
> >> others.
> >
> > I think sx1 and collie are all we need currently.
> >
> > By the way, it looks to me like QEMU has a regression
> > somewhere where we can't boot that sx1 test for the SD
> > card version -- it hangs during kernel boot waiting for
> > the MMC card. (An elderly QEMU binary I have boots OK.)
> > I'm looking into what's happened there.
> >
>
> Yes, you are correct. I did a quick check; the problem started with v9.1.
> v9.0 boots fine.

It's an issue with commit 1ab08790bb75e4 -- when we did a refactor
of the SD card emulation we didn't notice that the omap mmc
controller was also using the sd_cmd_type_t enum and relied
on the values of that enum matching the meanings of the
different values of the controller's MMC_CMD register Type field.
I'm just testing a patch.

thanks
-- PMM

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Philippe Mathieu-Daudé]

On 17/10/24 13:07, Peter Maydell wrote:
> On Thu, 17 Oct 2024 at 16:29, Guenter Roeck <linux@roeck-us.net> wrote:


>>> By the way, it looks to me like QEMU has a regression
>>> somewhere where we can't boot that sx1 test for the SD
>>> card version -- it hangs during kernel boot waiting for
>>> the MMC card. (An elderly QEMU binary I have boots OK.)
>>> I'm looking into what's happened there.
>>>
>>
>> Yes, you are correct. I did a quick check; the problem started with v9.1.
>> v9.0 boots fine.
> 
> It's an issue with commit 1ab08790bb75e4 -- when we did a refactor
> of the SD card emulation we didn't notice that the omap mmc
> controller was also using the sd_cmd_type_t enum and relied
> on the values of that enum matching the meanings of the
> different values of the controller's MMC_CMD register Type field.
> I'm just testing a patch.

Doh indeed I missed that use in omap_mmc_command()...

Thanks for the quick analysis!

Phil.

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Philippe Mathieu-Daudé]

On 12/2/24 13:32, Peter Maydell wrote:

> So I would like to explore whether we can deprecate-and-drop
> some or all of them. This would let us delete the code entirely
> rather than spending a long time trying to bring it up to scratch
> for a probably very small to nonexistent userbase. The aim of this
> email is to see if anybody is still using any of these and would be
> upset if they went away. Reports of "I tried to use this machine
> type and it's just broken" are also interesting as they would
> strongly suggest that the machine has no real users and can be
> removed.
> 
> The machines I have in mind are:
> 
> PXA2xx machines:

> connex               Gumstix Connex (PXA255)
> verdex               Gumstix Verdex Pro XL6P COMs (PXA270)

I can still run U-boot on these, but Gumstix webs are
slowly disappearing with the prebuilt images there were
sharing. Their wiki is also dead. I'm happy to use a stable
release for my pflash experiments.

> OMAP2 machines:
> 
> n800                 Nokia N800 tablet aka. RX-34 (OMAP2420)
> n810                 Nokia N810 tablet aka. RX-44 (OMAP2420)

For me these are broken since 2020 (commit 7998beb9c2 "arm/nseries:
use memdev for RAM"), this was discussed in
https://lore.kernel.org/qemu-devel/f2f276a9-a6ad-a2f8-2fbc-f1aca5423f79@amsat.org/
but there was no clear consensus so I gave up testing them.

Re: possible deprecation and removal of some old QEMU Arm machine types (pxa2xx, omap, sa1110)

[Philippe Mathieu-Daudé]

On 14/2/24 08:37, Philippe Mathieu-Daudé wrote:
> On 12/2/24 13:32, Peter Maydell wrote:
> 
>> So I would like to explore whether we can deprecate-and-drop
>> some or all of them. This would let us delete the code entirely
>> rather than spending a long time trying to bring it up to scratch
>> for a probably very small to nonexistent userbase. The aim of this
>> email is to see if anybody is still using any of these and would be
>> upset if they went away. Reports of "I tried to use this machine
>> type and it's just broken" are also interesting as they would
>> strongly suggest that the machine has no real users and can be
>> removed.
>>
>> The machines I have in mind are:


>> OMAP2 machines:
>>
>> n800                 Nokia N800 tablet aka. RX-34 (OMAP2420)
>> n810                 Nokia N810 tablet aka. RX-44 (OMAP2420)
> 
> For me these are broken since 2020 (commit 7998beb9c2 "arm/nseries:
> use memdev for RAM"), this was discussed in
> https://lore.kernel.org/qemu-devel/f2f276a9-a6ad-a2f8-2fbc-f1aca5423f79@amsat.org/
> but there was no clear consensus so I gave up testing them.

Eh good news the tests work again:

$ make check-avocado AVOCADO_TAGS='machine:n800 machine:n810' 
AVOCADO_ALLOW_UNTRUSTED_CODE=1 QEMU_TEST_FLAKY_TESTS=1 
AVOCADO_SHOW=app,console
   AVOCADO tests/avocado
JOB ID     : e089badc8daeae0882eb48e452164d00e8e19c18
JOB LOG    : job-2024-02-14T07.44-e089bad/job.log
  (1/2) tests/avocado/machine_arm_n8x0.py:N8x0Machine.test_n800: \
console: [    0.000000] Linux version 2.6.35~rc4-129.1-n8x0 
(abuild@build08) (gcc version 4.4.2 20091027 (MeeGo 4.4.2-7) (GCC) ) #1 
PREEMPT Mon Jul 12 15:04:46 UTC 2010
console: [    0.000000] CPU: ARMv6-compatible processor [4107b362] 
revision 2 (ARMv6TEJ), cr=00c5387f
console: [    0.000000] CPU: VIPT aliasing data cache, VIPT aliasing 
instruction cache
console: [    0.000000] Machine: Nokia N800
console: [    0.000000] Memory policy: ECC disabled, Data cache writeback
console: [    0.000000] OMAP2420
console: [    0.000000]
console: [    0.000000] SRAM: Mapped pa 0x40200000 to va 0xfe400000 
size: 0x100000
console: [    0.000000] Built 1 zonelists in Zone order, mobility 
grouping on.  Total pages: 32512
console: [    0.000000] Kernel command line: printk.time=0 console=ttyS1
console: PID hash table entries: 512 (order: -1, 2048 bytes)
console: Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
console: Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
console: Memory: 128MB = 128MB total
console: Memory: 124008k/124008k available, 7064k reserved, 0K highmem
console: Virtual kernel memory layout:
console: vector  : 0xffff0000 - 0xffff1000   (   4 kB)
console: fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
console: DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
console: vmalloc : 0xc8800000 - 0xf8000000   ( 760 MB)
console: lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
console: modules : 0xbf000000 - 0xc0000000   (  16 MB)
console: .init : 0xc0008000 - 0xc0029000   ( 132 kB)
console: .text : 0xc0029000 - 0xc0379000   (3392 kB)
console: .data : 0xc038e000 - 0xc03ba2e0   ( 177 kB)
console: SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, 
Nodes=1
console: Hierarchical RCU implementation.
console: RCU-based detection of stalled CPUs is disabled.
console: Verbose stalled-CPUs detection is disabled.
console: NR_IRQS:368
console: ------------[ cut here ]------------
console: WARNING: at arch/arm/mach-omap2/clkt_clksel.c:194 
omap2_clksel_recalc+0xcc/0xe0()
console: clock: Could not find fieldval 0 for clock iva1_ifck parent core_ck
console: Modules linked in:
console: [<c002fa1c>] (unwind_backtrace+0x0/0xf0) from [<c0053850>] 
(warn_slowpath_common+0x4c/0x64)
console: [<c0053850>] (warn_slowpath_common+0x4c/0x64) from [<c00538e8>] 
(warn_slowpath_fmt+0x2c/0x3c)
console: [<c00538e8>] (warn_slowpath_fmt+0x2c/0x3c) from [<c00388b4>] 
(omap2_clksel_recalc+0xcc/0xe0)
console: [<c00388b4>] (omap2_clksel_recalc+0xcc/0xe0) from [<c003a91c>] 
(propagate_rate+0x20/0x50)
console: [<c003a91c>] (propagate_rate+0x20/0x50) from [<c003a928>] 
(propagate_rate+0x2c/0x50)
console: ---[ end trace 1b75b31a2719ed1c ]---
console: ------------[ cut here ]------------
console: WARNING: at arch/arm/mach-omap2/clkt_clksel.c:194 
omap2_clksel_recalc+0xcc/0xe0()
console: clock: Could not find fieldval 0 for clock dsp_fck parent core_ck
console: Modules linked in:
console: [<c002fa1c>] (unwind_backtrace+0x0/0xf0) from [<c0053850>] 
(warn_slowpath_common+0x4c/0x64)
console: [<c0053850>] (warn_slowpath_common+0x4c/0x64) from [<c00538e8>] 
(warn_slowpath_fmt+0x2c/0x3c)
console: [<c00538e8>] (warn_slowpath_fmt+0x2c/0x3c) from [<c00388b4>] 
(omap2_clksel_recalc+0xcc/0xe0)
console: [<c00388b4>] (omap2_clksel_recalc+0xcc/0xe0) from [<c003a91c>] 
(propagate_rate+0x20/0x50)
console: [<c003a91c>] (propagate_rate+0x20/0x50) from [<c003a928>] 
(propagate_rate+0x2c/0x50)
console: ---[ end trace 1b75b31a2719ed1d ]---
console: ------------[ cut here ]------------
console: WARNING: at arch/arm/mach-omap2/clkt_clksel.c:194 
omap2_clksel_recalc+0xcc/0xe0()
console: clock: Could not find fieldval 0 for clock dsp_irate_ick parent 
dsp_fck
console: Modules linked in:
console: [<c002fa1c>] (unwind_backtrace+0x0/0xf0) from [<c0053850>] 
(warn_slowpath_common+0x4c/0x64)
console: [<c0053850>] (warn_slowpath_common+0x4c/0x64) from [<c00538e8>] 
(warn_slowpath_fmt+0x2c/0x3c)
console: [<c00538e8>] (warn_slowpath_fmt+0x2c/0x3c) from [<c00388b4>] 
(omap2_clksel_recalc+0xcc/0xe0)
console: [<c00388b4>] (omap2_clksel_recalc+0xcc/0xe0) from [<c003a91c>] 
(propagate_rate+0x20/0x50)
console: [<c003a91c>] (propagate_rate+0x20/0x50) from [<c003a928>] 
(propagate_rate+0x2c/0x50)
console: ---[ end trace 1b75b31a2719ed1e ]---
console: Clocking rate (Crystal/DPLL/MPU): 19.2/658/329 MHz
console: omap_hwmod: l3_hwmod: cannot be enabled (3)
console: omap_hwmod: l4_core_hwmod: cannot be enabled (3)
console: omap_hwmod: l4_wkup_hwmod: cannot be enabled (3)
console: GPMC revision 2.0
console: IRQ: Found an INTC at 0xfa0fe000 (revision 2.1) with 96 interrupts
console: Total of 96 interrupts on 1 active controller
console: OMAP GPIO hardware version 1.8
console: OMAP clockevent source: GPTIMER1 at 32000 Hz
console: Console: colour dummy device 80x30
console: Calibrating delay loop... 897.01 BogoMIPS (lpj=3506176)
console: pid_max: default: 32768 minimum: 301
console: Mount-cache hash table entries: 512
console: CPU: Testing write buffer coherency: ok
console: devtmpfs: initialized
console: NET: Registered protocol family 16
console: MUX: setup L15_24XX_I2C1_SDA (0xfa000112): 0x0018 -> 0x0000
console: MUX: setup M19_24XX_I2C1_SCL (0xfa000111): 0x0018 -> 0x0000
console: MUX: setup H19_24XX_I2C2_SDA (0xfa000114): 0x001f -> 0x0000
console: MUX: setup J15_24XX_I2C2_SCL (0xfa000113): 0x001f -> 0x0010
console: N8x0 MIPID config loaded
console: N8x0 Blizzard initialized
console: MUX: setup H18_24XX_MMC_CMD (0xfa0000f4): 0x001f -> 0x0000
console: MUX: setup H15_24XX_MMC_CLKI (0xfa0000fe): 0x001f -> 0x0000
console: MUX: setup G19_24XX_MMC_CLKO (0xfa0000f3): 0x000f -> 0x0000
console: MUX: setup F20_24XX_MMC_DAT0 (0xfa0000f5): 0x000f -> 0x0000
console: MUX: setup F19_24XX_MMC_DAT_DIR0 (0xfa0000f9): 0x000f -> 0x0000
console: MUX: setup G18_24XX_MMC_CMD_DIR (0xfa0000fd): 0x000f -> 0x0000
console: MUX: setup H14_24XX_MMC_DAT1 (0xfa0000f6): 0x001f -> 0x0000
console: MUX: setup E19_24XX_MMC_DAT2 (0xfa0000f7): 0x000f -> 0x0000
console: MUX: setup D19_24XX_MMC_DAT3 (0xfa0000f8): 0x000f -> 0x0000
console: MUX: setup E20_24XX_MMC_DAT_DIR1 (0xfa0000fa): 0x000f -> 0x0000
console: MUX: setup F18_24XX_MMC_DAT_DIR2 (0xfa0000fb): 0x000f -> 0x0000
console: MUX: setup E18_24XX_MMC_DAT_DIR3 (0xfa0000fc): 0x001f -> 0x0000
console: MUX: setup AA10_242X_DMAREQ0 (0xfa0000e5): 0x001f -> 0x0002
console: MUX: setup AA6_242X_DMAREQ1 (0xfa0000e6): 0x000f -> 0x0002
console: MUX: setup E4_242X_DMAREQ2 (0xfa000074): 0x0018 -> 0x0002
console: MUX: setup G4_242X_DMAREQ3 (0xfa000073): 0x0018 -> 0x0002
console: MUX: setup D3_242X_DMAREQ4 (0xfa000072): 0x0018 -> 0x0002
console: MUX: setup E3_242X_DMAREQ5 (0xfa000071): 0x0018 -> 0x0002
console: TUSB 6010
console: OMAP DMA hardware revision 4.0
console: bio: create slab <bio-0> at 0
console: SCSI subsystem initialized
console: i2c_omap i2c_omap.1: bus 1 rev3.4 at 400 kHz
console: i2c_omap i2c_omap.2: bus 2 rev3.4 at 400 kHz
console: Tahvo/Betty driver initialising
console: Betty v2.1 found
console: Retu/Vilma driver initialising
console: Vilma v1.5 found
console: Bluetooth: Core ver 2.15
console: NET: Registered protocol family 31
console: Bluetooth: HCI device and connection manager initialized
console: Bluetooth: HCI socket layer initialized
console: Switching to clocksource 32k_counter
console: musb_hdrc: version 6.0, tusb-omap-dma, peripheral, debug=0
console: tusb: Unable to detect TUSB6010
console: Could not start tusb6010 (-19)
console: musb_hdrc musb_hdrc: musb_init_controller failed with status -19
console: NET: Registered protocol family 2
console: IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
console: TCP established hash table entries: 4096 (order: 3, 32768 bytes)
console: TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
console: TCP: Hash tables configured (established 4096 bind 4096)
console: TCP reno registered
console: UDP hash table entries: 256 (order: 0, 4096 bytes)
console: UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
console: NET: Registered protocol family 1
console: PMU: registered new PMU device of type 0
console: NetWinder Floating Point Emulator V0.97 (double precision)
console: squashfs: version 4.0 (2009/01/31) Phillip Lougher
console: JFFS2 version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
console: fuse init (API version 7.14)
console: msgmni has been set to 242
console: alg: No test for stdrng (krng)
console: io scheduler noop registered
console: io scheduler cfq registered (default)
console: omapfb: ls041y3 rev 8f LCD detected, 24 data lines
console: omapfb: configured for panel ls041y3
console: omapfb: DISPC version 2.0 initialized
console: omapfb: RFBI version 1.0 initialized
console: omapfb: s1d13745 LCD controller rev 1 initialized (CNF pins 3)
console: omapfb omapfb: s1d1374x: setting update mode to auto
console: Console: switching to colour frame buffer device 100x30
console: omapfb: Framebuffer initialized. Total vram 770048 planes 1
console: omapfb: Pixclock 21940 kHz hfreq 24.9 kHz vfreq 51.0 Hz
console: omap_rng omap_rng: OMAP Random Number Generator ver. 00
console: Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
console: serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a 16550A
console: serial8250.1: ttyS1 at MMIO 0x4806c000 (irq = 73) is a 16550A
console: console [ttyS1] enabled
console: serial8250.2: ttyS2 at MMIO 0x4806e000 (irq = 74) is a 16550A
console: brd: module loaded
console: loop: module loaded
console: Menelaus rev 2.2
console: OneNAND driver initializing
console: omap2-onenand omap2-onenand: initializing on CS0, phys base 
0x04000000, virtual base c8880000
console: Muxed OneNAND(DDP) 256MB 1.8V 16-bit (0x48)
console: OneNAND version = 0x0000
console: Scanning device for bad blocks
console: Creating 5 MTD partitions on "omap2-onenand":
console: 0x000000000000-0x000000020000 : "bootloader"
console: 0x000000020000-0x000000080000 : "config"
console: 0x000000080000-0x000000280000 : "kernel"
console: 0x000000280000-0x000000680000 : "initfs"
console: 0x000000680000-0x000010000000 : "rootfs"
console: PPP generic driver version 2.4.2
console: PPP Deflate Compression module registered
console: PPP BSD Compression module registered
console: tun: Universal TUN/TAP device driver, 1.6
console: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
console: mice: PS/2 mouse device common for all mice
console: lm8323 2-0045: sent 2 bytes of -121 total
console: lm8323 2-0045: sending read cmd 0x82 failed
console: lm8323 2-0045: sent 2 bytes of -121 total
console: lm8323 2-0045: sent 2 bytes of -121 total
console: lm8323 2-0045: sent 2 bytes of -121 total
console: lm8323 2-0045: sent 2 bytes of -121 total
console: lm8323 2-0045: sent 2 bytes of -121 total
console: lm8323 2-0045: sent 3 bytes of -121 total
console: lm8323 2-0045: sent 3 bytes of -121 total
console: lm8323 2-0045: sending read cmd 0x80 failed
console: lm8323 2-0045: device not found
console: TSC2005 driver initializing
PASS (2.61 s)
  (2/2) tests/avocado/machine_arm_n8x0.py:N8x0Machine.test_n810: /
console: [    0.000000] Linux version 2.6.35~rc4-129.1-n8x0 
(abuild@build08) (gcc version 4.4.2 20091027 (MeeGo 4.4.2-7) (GCC) ) #1 
PREEMPT Mon Jul 12 15:04:46 UTC 2010
console: [    0.000000] CPU: ARMv6-compatible processor [4107b362] 
revision 2 (ARMv6TEJ), cr=00c5387f
console: [    0.000000] CPU: VIPT aliasing data cache, VIPT aliasing 
instruction cache
console: [    0.000000] Machine: Nokia N810
console: [    0.000000] Memory policy: ECC disabled, Data cache writeback
console: [    0.000000] OMAP2420
console: [    0.000000]
console: [    0.000000] SRAM: Mapped pa 0x40200000 to va 0xfe400000 
size: 0x100000
console: [    0.000000] Built 1 zonelists in Zone order, mobility 
grouping on.  Total pages: 32512
console: [    0.000000] Kernel command line: printk.time=0 console=ttyS1
console: PID hash table entries: 512 (order: -1, 2048 bytes)
console: Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
console: Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
console: Memory: 128MB = 128MB total
console: Memory: 124008k/124008k available, 7064k reserved, 0K highmem
console: Virtual kernel memory layout:
console: vector  : 0xffff0000 - 0xffff1000   (   4 kB)
console: fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
console: DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
console: vmalloc : 0xc8800000 - 0xf8000000   ( 760 MB)
console: lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
console: modules : 0xbf000000 - 0xc0000000   (  16 MB)
console: .init : 0xc0008000 - 0xc0029000   ( 132 kB)
console: .text : 0xc0029000 - 0xc0379000   (3392 kB)
console: .data : 0xc038e000 - 0xc03ba2e0   ( 177 kB)
console: SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, 
Nodes=1
console: Hierarchical RCU implementation.
console: RCU-based detection of stalled CPUs is disabled.
console: Verbose stalled-CPUs detection is disabled.
console: NR_IRQS:368
console: ------------[ cut here ]------------
console: WARNING: at arch/arm/mach-omap2/clkt_clksel.c:194 
omap2_clksel_recalc+0xcc/0xe0()
console: clock: Could not find fieldval 0 for clock iva1_ifck parent core_ck
console: Modules linked in:
console: [<c002fa1c>] (unwind_backtrace+0x0/0xf0) from [<c0053850>] 
(warn_slowpath_common+0x4c/0x64)
console: [<c0053850>] (warn_slowpath_common+0x4c/0x64) from [<c00538e8>] 
(warn_slowpath_fmt+0x2c/0x3c)
console: [<c00538e8>] (warn_slowpath_fmt+0x2c/0x3c) from [<c00388b4>] 
(omap2_clksel_recalc+0xcc/0xe0)
console: [<c00388b4>] (omap2_clksel_recalc+0xcc/0xe0) from [<c003a91c>] 
(propagate_rate+0x20/0x50)
console: [<c003a91c>] (propagate_rate+0x20/0x50) from [<c003a928>] 
(propagate_rate+0x2c/0x50)
console: ---[ end trace 1b75b31a2719ed1c ]---
console: ------------[ cut here ]------------
console: WARNING: at arch/arm/mach-omap2/clkt_clksel.c:194 
omap2_clksel_recalc+0xcc/0xe0()
console: clock: Could not find fieldval 0 for clock dsp_fck parent core_ck
console: Modules linked in:
console: [<c002fa1c>] (unwind_backtrace+0x0/0xf0) from [<c0053850>] 
(warn_slowpath_common+0x4c/0x64)
console: [<c0053850>] (warn_slowpath_common+0x4c/0x64) from [<c00538e8>] 
(warn_slowpath_fmt+0x2c/0x3c)
console: [<c00538e8>] (warn_slowpath_fmt+0x2c/0x3c) from [<c00388b4>] 
(omap2_clksel_recalc+0xcc/0xe0)
console: [<c00388b4>] (omap2_clksel_recalc+0xcc/0xe0) from [<c003a91c>] 
(propagate_rate+0x20/0x50)
console: [<c003a91c>] (propagate_rate+0x20/0x50) from [<c003a928>] 
(propagate_rate+0x2c/0x50)
console: ---[ end trace 1b75b31a2719ed1d ]---
console: ------------[ cut here ]------------
console: WARNING: at arch/arm/mach-omap2/clkt_clksel.c:194 
omap2_clksel_recalc+0xcc/0xe0()
console: clock: Could not find fieldval 0 for clock dsp_irate_ick parent 
dsp_fck
console: Modules linked in:
console: [<c002fa1c>] (unwind_backtrace+0x0/0xf0) from [<c0053850>] 
(warn_slowpath_common+0x4c/0x64)
console: [<c0053850>] (warn_slowpath_common+0x4c/0x64) from [<c00538e8>] 
(warn_slowpath_fmt+0x2c/0x3c)
console: [<c00538e8>] (warn_slowpath_fmt+0x2c/0x3c) from [<c00388b4>] 
(omap2_clksel_recalc+0xcc/0xe0)
console: [<c00388b4>] (omap2_clksel_recalc+0xcc/0xe0) from [<c003a91c>] 
(propagate_rate+0x20/0x50)
console: [<c003a91c>] (propagate_rate+0x20/0x50) from [<c003a928>] 
(propagate_rate+0x2c/0x50)
console: ---[ end trace 1b75b31a2719ed1e ]---
console: Clocking rate (Crystal/DPLL/MPU): 19.2/658/329 MHz
console: omap_hwmod: l3_hwmod: cannot be enabled (3)
console: omap_hwmod: l4_core_hwmod: cannot be enabled (3)
console: omap_hwmod: l4_wkup_hwmod: cannot be enabled (3)
console: GPMC revision 2.0
console: IRQ: Found an INTC at 0xfa0fe000 (revision 2.1) with 96 interrupts
console: Total of 96 interrupts on 1 active controller
console: OMAP GPIO hardware version 1.8
console: OMAP clockevent source: GPTIMER1 at 32000 Hz
console: Console: colour dummy device 80x30
console: Calibrating delay loop... 803.49 BogoMIPS (lpj=3137536)
console: pid_max: default: 32768 minimum: 301
console: Mount-cache hash table entries: 512
console: CPU: Testing write buffer coherency: ok
console: devtmpfs: initialized
console: NET: Registered protocol family 16
console: MUX: setup L15_24XX_I2C1_SDA (0xfa000112): 0x0018 -> 0x0000
console: MUX: setup M19_24XX_I2C1_SCL (0xfa000111): 0x0018 -> 0x0000
console: MUX: setup H19_24XX_I2C2_SDA (0xfa000114): 0x001f -> 0x0000
console: MUX: setup J15_24XX_I2C2_SCL (0xfa000113): 0x001f -> 0x0010
console: N8x0 MIPID config loaded
console: N8x0 Blizzard initialized
console: MUX: setup H18_24XX_MMC_CMD (0xfa0000f4): 0x001f -> 0x0000
console: MUX: setup H15_24XX_MMC_CLKI (0xfa0000fe): 0x001f -> 0x0000
console: MUX: setup G19_24XX_MMC_CLKO (0xfa0000f3): 0x000f -> 0x0000
console: MUX: setup F20_24XX_MMC_DAT0 (0xfa0000f5): 0x000f -> 0x0000
console: MUX: setup F19_24XX_MMC_DAT_DIR0 (0xfa0000f9): 0x000f -> 0x0000
console: MUX: setup G18_24XX_MMC_CMD_DIR (0xfa0000fd): 0x000f -> 0x0000
console: MUX: setup H14_24XX_MMC_DAT1 (0xfa0000f6): 0x001f -> 0x0000
console: MUX: setup E19_24XX_MMC_DAT2 (0xfa0000f7): 0x000f -> 0x0000
console: MUX: setup D19_24XX_MMC_DAT3 (0xfa0000f8): 0x000f -> 0x0000
console: MUX: setup E20_24XX_MMC_DAT_DIR1 (0xfa0000fa): 0x000f -> 0x0000
console: MUX: setup F18_24XX_MMC_DAT_DIR2 (0xfa0000fb): 0x000f -> 0x0000
console: MUX: setup E18_24XX_MMC_DAT_DIR3 (0xfa0000fc): 0x001f -> 0x0000
console: MUX: setup AA10_242X_DMAREQ0 (0xfa0000e5): 0x001f -> 0x0002
console: MUX: setup AA6_242X_DMAREQ1 (0xfa0000e6): 0x000f -> 0x0002
console: MUX: setup E4_242X_DMAREQ2 (0xfa000074): 0x0018 -> 0x0002
console: MUX: setup G4_242X_DMAREQ3 (0xfa000073): 0x0018 -> 0x0002
console: MUX: setup D3_242X_DMAREQ4 (0xfa000072): 0x0018 -> 0x0002
console: MUX: setup E3_242X_DMAREQ5 (0xfa000071): 0x0018 -> 0x0002
console: TUSB 6010
console: OMAP DMA hardware revision 4.0
console: bio: create slab <bio-0> at 0
console: SCSI subsystem initialized
console: i2c_omap i2c_omap.1: bus 1 rev3.4 at 400 kHz
console: i2c_omap i2c_omap.2: bus 2 rev3.4 at 400 kHz
console: Tahvo/Betty driver initialising
console: Betty v2.1 found
console: Retu/Vilma driver initialising
console: Vilma v1.5 found
console: Bluetooth: Core ver 2.15
console: NET: Registered protocol family 31
console: Bluetooth: HCI device and connection manager initialized
console: Bluetooth: HCI socket layer initialized
console: Switching to clocksource 32k_counter
console: musb_hdrc: version 6.0, tusb-omap-dma, peripheral, debug=0
console: tusb: Unable to detect TUSB6010
console: Could not start tusb6010 (-19)
console: musb_hdrc musb_hdrc: musb_init_controller failed with status -19
console: NET: Registered protocol family 2
console: IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
console: TCP established hash table entries: 4096 (order: 3, 32768 bytes)
console: TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
console: TCP: Hash tables configured (established 4096 bind 4096)
console: TCP reno registered
console: UDP hash table entries: 256 (order: 0, 4096 bytes)
console: UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
console: NET: Registered protocol family 1
console: PMU: registered new PMU device of type 0
console: NetWinder Floating Point Emulator V0.97 (double precision)
console: squashfs: version 4.0 (2009/01/31) Phillip Lougher
console: JFFS2 version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
console: fuse init (API version 7.14)
console: msgmni has been set to 242
console: alg: No test for stdrng (krng)
console: io scheduler noop registered
console: io scheduler cfq registered (default)
console: omapfb: ls041y3 rev 8f LCD detected, 24 data lines
console: omapfb: configured for panel ls041y3
console: omapfb: DISPC version 2.0 initialized
console: omapfb: RFBI version 1.0 initialized
console: omapfb: s1d13745 LCD controller rev 1 initialized (CNF pins 3)
console: omapfb omapfb: s1d1374x: setting update mode to auto
console: Console: switching to colour frame buffer device 100x30
console: omapfb: Framebuffer initialized. Total vram 770048 planes 1
console: omapfb: Pixclock 21940 kHz hfreq 24.9 kHz vfreq 51.0 Hz
console: omap_rng omap_rng: OMAP Random Number Generator ver. 00
console: Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
console: serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a 16550A
console: serial8250.1: ttyS1 at MMIO 0x4806c000 (irq = 73) is a 16550A
console: console [ttyS1] enabled
console: serial8250.2: ttyS2 at MMIO 0x4806e000 (irq = 74) is a 16550A
console: brd: module loaded
console: loop: module loaded
-console: Menelaus rev 2.2
console: OneNAND driver initializing
console: omap2-onenand omap2-onenand: initializing on CS0, phys base 
0x04000000, virtual base c8880000
console: Muxed OneNAND(DDP) 256MB 1.8V 16-bit (0x48)
console: OneNAND version = 0x0000
console: Scanning device for bad blocks
console: Creating 5 MTD partitions on "omap2-onenand":
console: 0x000000000000-0x000000020000 : "bootloader"
console: 0x000000020000-0x000000080000 : "config"
console: 0x000000080000-0x000000280000 : "kernel"
console: 0x000000280000-0x000000680000 : "initfs"
console: 0x000000680000-0x000010000000 : "rootfs"
console: PPP generic driver version 2.4.2
console: PPP Deflate Compression module registered
console: PPP BSD Compression module registered
console: tun: Universal TUN/TAP device driver, 1.6
console: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
console: mice: PS/2 mouse device common for all mice
console: lm8323 2-0045: sent 2 bytes of -121 total
console: lm8323 2-0045: sending read cmd 0x82 failed
console: lm8323 2-0045: sent 2 bytes of -121 total
console: lm8323 2-0045: sent 2 bytes of -121 total
console: lm8323 2-0045: sent 2 bytes of -121 total
console: lm8323 2-0045: sent 2 bytes of -121 total
console: lm8323 2-0045: sent 2 bytes of -121 total
console: lm8323 2-0045: sent 3 bytes of -121 total
console: lm8323 2-0045: sent 3 bytes of -121 total
console: lm8323 2-0045: sending read cmd 0x80 failed
console: lm8323 2-0045: device not found
console: TSC2005 driver initializing
PASS (2.30 s)
RESULTS    : PASS 2 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | 
CANCEL 0
JOB TIME   : 5.49 s