[Hpipaq21x-devel] Haret booting

[Oliver Ford]

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
> bootlinux
>
>
> 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 
and 0xC0000000-0xC3FFFFFF.

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,

Oliver