> Am 15.02.2024 um 09:31 schrieb Andreas Kemnade <andreas@xxxxxxxxxxxx>:
>
> On Wed, 14 Feb 2024 23:42:58 +0100
> "Arnd Bergmann" <arnd@xxxxxxxx> wrote:
>
>> On Wed, Feb 14, 2024, at 13:26, Dmitry Baryshkov wrote:
>>> On Tue, 13 Feb 2024 at 23:22, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>>>> On Tue, Feb 13, 2024 at 9:12 PM Arnd Bergmann <arnd@xxxxxxxx> 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
