Oliver Ford wrote:
Kevin O'Connor wrote:
On Fri, Mar 07, 2008 at 01:22:21PM +0000, Oliver Ford wrote:
Further to the not shutting down properly thoughts, I was looking at the
resume-into-boot feature of HaRET, in the hope that letting windows do
the hardware shutdown would be more successful. Unfortunately I can't
work out how to find the required RESUMEADDR. Is there some method for
doing this?
I found it by just searching ram for the signature. It is 0xea0003fe
followed by 4K of zeros. It is usually aligned on some large boundary
near the top of ram. (For example, it is at 0xa0040000 on Apache and
0x30100000 on Hermes.)
Note that the resume-into-boot feature of haret has never really been
tested.
I notice that the resume into boot handler checks for a specific
instruction at the beginning of winCE's resume handler. Is this always
what it is, even for the newest versions of windows mobile? If so, I may
just try searching the entire memory for it and attempting the resume
tracing stuff a each place, see where it gets to. My ipaq is running Win
Mobile 6 (CE v5.2.1711).
I don't know if it still holds true for wince 6, but I think there is
a good chance it does.
-Kevin
Thanks. It's no longer necessary though. We have fixed the kernel oops
in normal boot process. We think it is just HaRET over-estimating the
amount of RAM and then the kernel trying to use memory that isn't there.
Including a specific RAMSIZE instruction fixes it.
The memory issue turned out to be more complicated, and will require
some significant modification to the prepForKernel() routine in HaRET.
I'm not quite sure how this should be put in. This is what I've figured out:
The HP iPAQ 214 has a weird memory map.
It has 128MB of ram, in two 64MB blocks
Bits 31 and 30 set which bank:
00 - not RAM - something else
01 - not RAM - something else
10 - RAM bank 1
11 - RAM bank 2
Bits 0-25 address within each bank.
Bits 26-29 are not connected, which means setting them to anything makes
no difference.
This means the first bank exists at 0x80000000 through to 0x83FFFFFF but
is mirrored at 0x84000000 to 0x87FFFFFF and so on, until 0xBFFFFFFF.
Bank 2 exists at 0xC0000000 to 0xC3FFFFFF and 0xC4000000 to .... all the
way up to 0xFFFFFFFF.
Windows gets around this by using 0xBC000000 through to 0xC3FFFFFF,
which looks like its in a straight line and allocates the video ram at
0xBC422000.
This all causes problems for the perpForKernel() code when it's checking
whether it's current (windows memory side) location of the kernel
overlaps with where the preloader will put it. Of course, different
addresses can represent the same actual space.
It also causes problems when the kernel is written to 0xA0000000 (which
we have been using, just because we know it works), as this is
0x00000000 in bank 1 and the video ram (0xBC422000) is actually at
0x00422000 in bank 1.
If the kernel+tags+initrd images are bigger than 0x00400000 (4MB), this
overwrites the video. This doesn't actually stop the kernel booting, and
after a few seconds the pxa framebuffer driver kicks in and all is
well. It does however mean I can't read the FB_WRITE output of the haret
preloader for reading the CRC checks etc. I've tried loading the kernel
at 0xBD000000, which is just after the video ram. The kernel just
doesn't boot. Have you any idea why this might be? Does the kernel need
to be on some kind of boundary (other than the 4 byte one, of course)?
Thanks again,
Oliver
_______________________________________________
Haret mailing list
[email protected]
https://handhelds.org/mailman/listinfo/haret
