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
_______________________________________________
Haret mailing list
[email protected]
https://handhelds.org/mailman/listinfo/haret
