Linux BigPhysArea Crashes Ramdisk

[banjo]

we have a system running an AMCC 405EX processor. It has 1 GIG of DRAM and I am trying get 768MB of BigPhysArea to use for data storage. We have used this processor in a couple of other configurations. One has only 256MB and no data storage. Another has 512MB with 256MB for the OS and 256MB for data storage. This 1 GIG variation has 1 GIG with the target of 256MB for the OS and 768MB for data storage. All run the same Linux.

It is booting Linux 3.4. It can see the entire 1 GIG without difficulty. If I boot with no BigPhysArea, then everything is normal. However, if I enable BigPhysArea, it crashes when attempting to unzip the Ramdisk. If I reduce the BigPhysArea, it will also boot OK.

When it boots OK the output is

Ebtables v2.0 registered
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing unused kernel memory: 188k freed

When it crashes the output is

Ebtables v2.0 registered
RAMDISK: gzip image found at block 0
VFS: Cannot open root device "ram" or unknown-block(1,0): error -2
Please append a correct "root=" boot option; here are the available partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
Rebooting in 1 seconds..

I have tried numerous environment variable settings, kernel boot options and nothing seems to help. For some unknown reason, the OS is setting up the Ramdisk so that it collides with the BigPhysArea, at least that is my interpretation.

Questions:

1. Any hints on how to troubleshoot this?

2. Anyone know a tutorial on setting up Linux kernels or anything else that would help?

3. Has anyone every had this problem before?

Thanks.

 

[banjo]

To close the issue, I did find the root cause. Problem was actually in U-BOOT. U-BOOT had two errors that masked the problem. The second rank of DDR dram was not properly enabled AND the first rank had the wrong size. This gave the unfortunate effect of making it appear that 1 GIG was available when really it was only 512MB.
The Linux Kernel was passed info that it had 1 GIG and everything worked until something tried to occupy space in the fictitious upper 512MB. Apparently, the memory test in U-BOOT was not checking across the whole address range as it always claimed the entire 1 GIG was fine.