[Hpipaq21x-devel] Haret booting
jet at oliford.co.uk
Thu Oct 30 15:18:23 CET 2008
Kuba Irzabek wrote:
> Hi Oliver,
> I tried to boot a vanilla 2.6.27 kernel with zylonite default config
> from haret - experimenting just for fun and learning. But I cannot get
> it to work even a litlle bit.
> I compiled the kernel using Angstrom toolchain (OpenEmbedded). I put
> haret.exe, kernel and default.txt in My Documents folder.
> This is my default.txt:
> set kernel "zImage-2.6.27"
> set ramaddr 0xa0000000
> set ramsize 0x04000000
> set initrd "initrd.bin"
> set cmdline "rdinit=/sbin/init"
> set mtype 1233
> set kernelcrc 0
> set fbduringboot 1
> I tried also with different ramaddr (taken from your default.txt),
> uncompressed kernel image and without initrd and cmdline (I'm not sure
> if I need initrd to put anything on screen using framebuffer). Of
> course when using initrd I compiled the kernel with support for that.
> I compiled haret from cvs and compressed the initrd from rootfs of
> angstrom-base-image, which I built myself from the dev branch.
> The result is only some garbage on the lcd and ipaq hanging. I would
> like to see some output from kernel on the screen. On haret mailing
> list you wrote (in the beginning of your work with ipaq) you succeded
> in using stock kernel with haret - it displayed splash logo, etc.
> Could you please tell me what is needed to do this (if you remember of
> course)? I'm just curios why it isn't working.
Firstly, I have never (even with the ipaq21x kernel) got the zImage to
work from HaRET, for some reason it just dies. Copy the Image file in
instead, it's a bit bigger but works.
The memory is a bit complicated...
The first 64MB runs from 0x80000000 to 0x83FFFFFF and repeats upwards
until 0xBFFFFFFFF. The second bank then goes from 0xC0000000 up to
0xC3FFFFFF and repeats up to 0xFFFFFFFF. Windows gets around the problem
by simply saying there is 128MB from 0xBC000000 up to 0xC3FFFFFF. The
windows framebuffer seems to sit somewhere slightly into the 0xBC000000
area iirc. Linux wants to be loaded at 0xA0000000 (you can change this
by playing with a memory.h file, I can't remember where in the source it
is though). Of course thats the same block as the 0xBC000000 block, but
HaRET won't know this because the address is different.
This by the way is the reason that you only get 64MB of memory in linux
if you use HaRET to load it, because HaRET doesn't have the ability to
pass the information about both blocks of memory to the kernel (not the
original version anyway, I have my own that does now). My MMC boot
loader specifically informs the kernel that it has 0xA000000-0xA3FFFFFF
If you're really getting into all of this there is some useful debugging
you can do. In the kernel you can put this code to play with the blue LED:
#define setGPIO __REG(0x40e00018)
#define clearGPIO __REG(0x40e00024)
#define dirGPIO __REG(0x40e0000c)
#define mfprGPIO3 __REG(0x40e1027c)
#define mfprGPIO3_2 __REG(0x40e102e0)
mfprGPIO3 = 0x0844;
__asm ( "nop\n nop\n nop" : : );
mfprGPIO3_2 = 0x8C40;
__asm ( "nop\n nop\n nop" : : );
dirGPIO |= 0x08;
setGPIO = 0x08;
(Theoretically you can do the green LED with dirGPIO |= 0x20 etc and
setting the appropriate MFPR).
More usefully, you can leave data in the low 24 bits of the 2 real-time
clock alarm registers, like:
#define STORE1 __REG(0x4090002c)
#define STORE2 __REG(0x40900030)
STORE1 = 0x123456;
STORE2 = 0xABCDEF;
and read them back in HaRET after a reboot with:
pdump 0x4090002c 8
I used to end up having to plant these bits of code throughout the
kernel to see where it got to. Now days I have a direct serial link
which makes life an awful lot easier.
> P.S. What is the state of wifi right now?
At present I'm having a huge amount of difficulty getting ALSA working
again after the merge of the latest kernel. I have found a few bugs in
the kernel which the ALSA people are dealing with. Once I've got the
latest kernel rebuilt and released I'll get back to the WiFI/MMC problems.
Hope that helps,
More information about the Hpipaq21x-devel