Kevin O'Connor wrote:
The kernel is compiled with a start of memory address. You'll need to
recompile it with a new address. I'm not that familiar with the
process, but take a look at:
#define PHYS_OFFSET UL(0xa0000000)
in asm-arm/arch-pxa/memory.h. I seem to recall reading about some
people that wanted to make this setting config driven.
-Kevin
Thanks, I had looked for that in /arch/arm/mach-pxa/ for ages, didn't
expect it to be in the headers!
Changing that up to 0xbc000000 allows me to boot the kernel from the
place it's really at. I can now try increasing the memory up so it can
use the whole 128MB at some point.
The only problem being haret now realises it overwrites the video memory
so doesn't display the CRCs.
To get around the problem of it overwriting the video ram I've just
changed PHYSOFFSET_INITRD in linboot.cpp to
(PHYSOFFSET_KERNEL + 0x1000000) instead of +0x500000, this means the
kernel sits just before it (provided it's < 4MB) and the initrd sits
just after it. Without the a000->bc00 modification, I can see the CRC
checking complete and it jump to the kernel. There is a brief moment
when the kernel overwrites the video with something just before the
pxafb driver comes up and sorts everything out. This way I assume the
kernel reclaims all the memory once it's booted.
On other fronts, we eventually got the MMC system working. This was
mostly by finding the card insert and write-protect GPIOS and building
them into our kernel machine C file. With the ability to mount an SD
card I now have a crude scripted system (courtesy of busybox mostly)
which continually mounts the card, runs a script on it, unmounts it and
waits 20seconds. This way, despite not having any form of input yet I
can modify programs without needing to reset and go through windows
again (takes ages for windows to boot on this thing). The only annoying
thing is that the LCD dies after 10 minutes. It is just the LCD as I can
still flash the blue LED. I guess this is the power management chip
deciding everything has gone to sleep. I have no idea how to go about
stopping this. Anyone got any ideas?
Today I've spent most of my time working out what windows does with the
bluetooth and FFUART and finally got the bluetooth chip to talk HCI with
a program of mine in linux. It should be a reasonably simple affair to
get it running with the bluez-utils tomorrow. All of the watching in
windows was made significantly more difficult because the 'watch
muutrace' and the pxa debug tracing don't seem to work.
Using simply something like 'addlist mmutrace p2v(0x40E00000)' doesn't
work as the p2v() evaluates as virtual 0xa8e00000 which nothing seems to
use. Forcing it to watch virtual 0x80e00000, the only other mapping to
the same region that I can find in the 'dump mmu' list just freezes the
PDA. The PXA tracing just never traps anything in either case. One part
of this that I didn't understand is that the xScale 3 docs say the debug
registers take a 'modified virtual address' that has been combined with
the 'process ID'. If each process has a different ID, how are you
supposed to (using the debug system) watch a specific physical location,
like for instance trying to trap anything reading or writing to the UART?
For anyone reading who's interested and for the benefit of having the
details out on the web, this is how I did it and how far we've got...
Fortunately windows uses DMA on the FFUART to talk to the bluetooth chip
so I got around it by using the standard 'watch mylist' type command
with a list that includes all the gpios, all the UART state and control
registers, the relevant DMA channel registers and a large chunk memory
the DMA points to/from. I now have a little recipe for bringing the BT
chip up in linux, consisting of flicking around 6 different GPIOs with
the odd 3 6 or 500ms delay. Windows does this quite consistently and it
works in linux too. The linux UART driver (pxa27x_uart) doesn't seem to
support turning on the hardware flow control, which is needed for the BT
chip to talk to you. So for the time being I just poke the UART
registers from the program after the driver has done what it thinks is
enough. I'll ask the kernel list about this in the next few days.
As an update, we now have control over... the blue LED, the MMC/SD card
system (but not yet the SDIO8686 wireless chip on it), the UARTs and the
bluetooth chip sitting on one. We also know about the following GPIOS:
3(_2): The blue LED - active high (wired to the GPIO3_2 pin not the
actual GPIO3 pin, which is an MMC data line)
15: mmc1 card detect
102: mmc1 write protect
53, 71, 124, 114, 81: All used in the bluetooth wakeup process - still
not sure what they actually DO.
77: wired to the BT chip, config'ed to the ffuart's receive line
78: wired to the BT chip, config'ed to ffuart's transmit line,
79: BT chip, ffuart's clear to send line
84: BT chip, ffuart's request to send line (The actual GPIO bit also
goes up and down in windows, but not in linux, this confuses me)
3 though 8: wired to MMC card slot, config'ed to MMC1 on the chip
54-69, 72-76 and 127: wired to LCD pins, config'ed to LCD driver as in
Zylonite configuration in kernel (almost).
Gpios 70 and 71 are config'ed to the LCD in the zylonite kernel file but
not on the iPAQ in winCE. Also, 71 is part of the bluetooth wake up so
definitely isn't LCD. I don't where these two signals have gone, and so
neither does linux yet but it seems to work fine regardless. This also
confuses me.
Sorry for the length of that one and if anyone wants any precise details
just ask. :)
Oliver
_______________________________________________
Haret mailing list
[email protected]
https://handhelds.org/mailman/listinfo/haret
