Re: Linux on IPAQ 214 (PXA310)

Oliver Ford pisze:
> Kevin O'Connor wrote:
>> On Sun, Mar 16, 2008 at 11:33:20AM +0000, Oliver Ford wrote:
>>> Kevin O'Connor wrote:
>>>> Also, using the right cache flushing functions is crucial to working
>>>> with "wirq". Is your haret detecting the machine as a pxa (and thus
>>>> using the xscale cache flushes)?
>>>>
>>> Ah yes, that might be it. It is detecting it as a PXA but haret only
>>> has support for the pxa2xx (xscale). I'm not sure how different the
>>> caching in the pxa3xx, which I think is xscale3, is. For one, the
>>> xscale3 docs say it has an L2 cache, although Eric Miao (on the
>>> kernel list) says the pxa310 doesn't, which seems to be correct from
>>> poking with the code. This leaves me a little confused as to what is
>>> what.
>>
>> It looks like there is a different cache flush for xscale3. See
>> arch/arm/mm/proc-xsc3.S.
>>
>> I can bring over the cache function, but I need a reliable way to
>> detect the processor. Do you know of a mechanism?
>>
>> If you have patches for haret, I'd like to see them. Ultimately, we
>> should have one version of haret for all machines.
>>
>> -Kevin
> My changes to haret are all over the place, and most of them are
> temporary or just dumping lots of debugging info while I learnt about
> how it all worked and what was going on. A lot of it was changes we
> made to turn off more stuff in the hardware shut-down procedures and
> extra cache clearing I tried adding to the assembly to stop the random
> memory problems, but that just turned out to be the mapping and so
> isn't necessary at all. Very little is actually needed to make the
> thing work. When I've got somewhere with it all I'll put together a
> summary of what's actually required, as well as a breakdown of the
> GPIOs for the machine, the MFP configuration registers and how that
> all works.
>
> I seem to remember one of the coprocessor registers has the cpu id in
> it and that might include the xScale3 ident, I'll look in the docs for
> you at some point in the next few days, unless Vega has time to find it?
>
> Meanwhile, I've got the bluetooth mostly working. I spent a lot of
> time trying to reproduce the firmware upgrade that windows does. I can
> do this but it doesn't quite behave the same so I've hit a bit of a
> dead end with that. It turns out though, that the chip works without
> the upgrade, and I can see it from my laptop. It won't respond to
> anything until I get hcid of bluz-utils working, which in turn won't
> work without dbus. D-Bus, which I'm quickly growing to hate, just
> seg-faults immediately. I know very little about debugging linux
> seg-faults so this may take me a little while.
>
> Thanks all
>
> Oliver
>
>
>
Is it what you were thinking about?

page 85 of 3rd Generation Intel XScale® Microarchitecture Developer’s Manual
7.2.1 Register 0: ID & Cache Type Registers
Table 28. Main ID Register

bits 15:13
Microarchitecture Generation
0b011 = 3rd generation microarchitecture
This field reflects a specific set of architecture features
supported by the microarchitecture. When new features
are added/deleted/modified this field changes. This
allows software that is not dependent on ASSP features
to target code at a specific microarchitecture generation.

12:10
Microarchitecture Revision:
This field reflects revisions of microarchitecture
generations. Differences include errata that dictate
different operating conditions, software work-around, etc.

Vega
Received on Wed Mar 19 2008 - 13:33:37 EST