[linux-cirrus] Re: bootmem_init_node failure with 64M TS-7250

On Fri, Dec 29, 2006 at 08:39:36PM -0500, Charles Moschel wrote:

> Well, RedBoot was a bit of a red herring for me, initially.  I found it
> did pass ATAGs correctly, but the redboot banner still says 32M RAM was
> available (0x02000000).  And when I tried Lennert's suggestion of
> changing PHYS_OFFSET and loading the kernel at 0xe0008000, RedBoot
> helpfully asked if I was sure, because the address appeared to be
> outside of RAM (see boot log below).

Note that Redboot runs with the MMU on, and that 'load' takes a
virtual address while 'exec' takes a physical address.


> For the record, I tried this without success: didn't even make it to
> "Uncompressing the kernel ...":
> 
> RedBoot> load -r -b 0xe0008000 -h 192.168.2.1 -m http /~ccm/zImage
> Specified address (0xe0008000) is not believed to be in RAM - continue
> (y/n)? y

There likely is no mapping for the e0000000 virtual address.

If Redboot _did_ map 64M, you could load the kernel at virt 0x02008000
(assuming that that would map to phys 0xe0008000) and then tell exec to
exec from 0xe0008000.


> Raw file loaded 0xe0008000-0xe0147413, assumed entry at 0xe0008000
> RedBoot> exec -c "mem=8M@0xe0000000 mem=8M@0xe1000000 mem=8M@0xe4000000
> mem=8M@0xe5000000 mem=8M@0x0 mem=8M@0x1000000 mem=8M@0x4000000
> mem=8M@0x5000000 console=ttyAM0,115200 root=/dev/nfs
> nfsroot=192.168.2.1:/home/ts7200 ip=192.168.2.30"

Caveat emptor.  If you don't give 'exec' an address, it will copy the
kernel image from whatever address you've loaded it at (0xe00008000 in
this case) to 0x00008000 and then jump to 0x00008000.

In your case (because there's no mapping at e0008000) it's likely just
copying crap to 0x00008000 and then jumping there.

Other related posts: