Hi, On Wed, Mar 12, 2008 at 04:30:57PM +0000, Oliver Ford wrote: > 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: [...] > 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.
I'd say you probably want to do the same thing in Haret and Linux then. Define RAMADDR to be 0xBC000000 and compile Linux with that address also. Otherwise, I think trying to get Linux to work with non sequential memory is going to be a real pain. > 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)? 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 _______________________________________________ Haret mailing list [email protected] https://handhelds.org/mailman/listinfo/haret
