Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Linux BigPhysArea Crashes Ramdisk

Status
Not open for further replies.

banjo

Advanced Member level 2
Advanced Member level 2
Joined
Dec 24, 2005
Messages
648
Helped
127
Reputation
254
Reaction score
8
Trophy points
1,298
Visit site
Activity points
8,064
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.
 

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.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top