[U-Boot-Users] Kernel Panic
I am currently trying to boot an kernel with inital ramdisk using u-boot on an EP885C, but I am running into the following problem when I try to boot the kernel:
Linux version 2.4.22 (wdhaine@prod-pci) (gcc version 3.3.3) #1 Mon Jul 18 12:45:35 EDT 2005 On node 0 totalpages: 16384 zone(0): 16384 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: console=ttyS0,9600 console=ttyS0 root=/dev/ram0 init=/linuxrc rw
...
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize loop: loaded (max 8 devices)
...
RAMDISK: Compressed image found at block 0 Freeing initrd memory: 466k freed Kernel panic: VFS: Unable to mount root fs on 01:00
I would think that this is purely a kernel problem; however, it did not crop up until I started using u-boot. As shown above, I have ramdisk support built into the kernel, and I am passing it a root device in the kernel command line, so this doesn't seem to be an FAQ type of problem.
In order to get the kernel to run, I had to copy the ppcboot.h bd_t struct into my linux port and change the IMAP_ADDR to get the kernel to boot. I am thinking that somehow the bd_t struct changes could make the it impossible to use /dev/ram0 correctly. Other than that, I am stumped. Any help would be greatly apprectiated.
Will Haines
Will Haines <will.haines <at> embedded-sys.com> writes:
I am currently trying to boot an kernel with inital ramdisk using u-boot on an EP885C, but I am running into the following problem when I try to boot the kernel:
I realize now that this is probably very off topic. I'm sorry about posting it here--the problem does not seem to be related to u-boot after all.
Will
In message loom.20050718T195232-439@post.gmane.org you wrote:
I am currently trying to boot an kernel with inital ramdisk using u-boot on an EP885C, but I am running into the following problem when I try to boot the kernel:
...
RAMDISK: Compressed image found at block 0 Freeing initrd memory: 466k freed Kernel panic: VFS: Unable to mount root fs on 01:00
So it found the ramdisk, but could not mount the filesystem. Assuming this is an ext2 file system - did you enable ext2 support in your kernel configuration?
I would think that this is purely a kernel problem; however, it did not crop up
It is.
In order to get the kernel to run, I had to copy the ppcboot.h bd_t struct into my linux port and change the IMAP_ADDR to get the kernel to boot. I am thinking
Wrong approach. Don't copy and duplicate code. Just #include ppcboot.h - this is what it was made for.
that somehow the bd_t struct changes could make the it impossible to use /dev/ram0 correctly. Other than that, I am stumped. Any help would be greatly
The ramdisk was recognized correctly. It's the content that did not match.
U-Boot has nothing to do with that.
Best regards,
Wolfgang Denk
Hello,
I have a problem when I boot the AT91RM9200 board with u-boot 1.0.0
when starting kernel ...
I got this message error
Error : unrecognized/unsupported machine ID (r1 = 0x000000fb)
Avalable machine support :
ID(hex) NAME 00000106 Atmel AT91RM9300-DK
Please check your kernel config and/or bootloader.
I presume that the bootloader is U-Boot 1.0.0
Linux kernel version : 2.6.12 glibc 2.3.5 gcc 3.4.4
Any idea to fix it?
Regards
Christian
In message 00d101c58bdc$382f7f30$6b01a8c0@cc you wrote:
I have a problem when I boot the AT91RM9200 board with u-boot 1.0.0
This is your first problem: you are using very old software. Please use the latest version of U-Boot (= top of tree in CVS) instead.
when starting kernel ... I got this message error Error : unrecognized/unsupported machine ID (r1 = 0x000000fb)
Here are problems 2 and 3:
2: you have an unrecognized/unsupported machine ID
3: you post to the wrong list. This has nothing to do with U-Boot.
Any idea to fix it?
Assign and/or configure a valid machine ID.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 00d101c58bdc$382f7f30$6b01a8c0@cc you wrote:
I have a problem when I boot the AT91RM9200 board with u-boot 1.0.0
This is your first problem: you are using very old software. Please use the latest version of U-Boot (= top of tree in CVS) instead.
when starting kernel ... I got this message error Error : unrecognized/unsupported machine ID (r1 = 0x000000fb)
Here are problems 2 and 3:
2: you have an unrecognized/unsupported machine ID
3: you post to the wrong list. This has nothing to do with U-Boot.
Use Linux-ARM mailing list: http://www.arm.linux.org.uk/mailinglists/ "You are STRONGLY advised to read the etiquette and FAQ before posting to these mailing lists"
Any idea to fix it?
Assign and/or configure a valid machine ID.
Visit http://www.arm.linux.org.uk/developer/machines/
-- Steven
Wolfgang Denk <wd <at> denx.de> writes:
The ramdisk was recognized correctly. It's the content that did not match.
U-Boot has nothing to do with that.
I can see that my ramdisk was improperly made before, but I am still at a loss to understand why if I make a gzipped version of my filesystem, I get to this point:
VFS: Mounted root (ext2 filesystem). Mounted devfs on /dev Freeing unused kernel memory: 44k init
and the board reboots, bringing me back to the u-boot prompt. If I make an uncompressed version, it will boot and even bring me to a Busybox prompt, but if I try to execute an ls command, the board reboots.
This problem even occurs when I try to use the test ramdisk filesystem provided in the Wiki for u-boot; I get to:
VFS: Mounted root (ext2 filesystem). Mounted devfs on /dev Freeing unused kernel memory: 44k init
and the board reboots. I understand that this probably has nothing to do with u-boot, but I do not know where else to turn with this problem. Thank you for any help you can provide or any other list that might have a better handle on what is making the board reboot. Even if there is nothing that you can suggest, I thank you for at least taking the time to help me on my previous post.
Will Haines
In message loom.20050718T230327-483@post.gmane.org you wrote:
I can see that my ramdisk was improperly made before, but I am still at a loss to understand why if I make a gzipped version of my filesystem, I get to this point:
VFS: Mounted root (ext2 filesystem). Mounted devfs on /dev Freeing unused kernel memory: 44k init
and the board reboots, bringing me back to the u-boot prompt. If I make an uncompressed version, it will boot and even bring me to a Busybox prompt, but if I try to execute an ls command, the board reboots.
Sounds like a memory probem to me. Are you absolutely sure that the kernel sees the correct size of your RAM, and that all of it is actually working, without any gaps or overlaps or mirroring?
and the board reboots. I understand that this probably has nothing to do with u-boot, but I do not know where else to turn with this problem. Thank you for
It may have to do with U-Boot, more precisely with your memory initialization.
Best regards,
Wolfgang Denk
Wolfgang Denk <wd <at> denx.de> writes:
Sounds like a memory probem to me. Are you absolutely sure that the kernel sees the correct size of your RAM, and that all of it is actually working, without any gaps or overlaps or mirroring?
If you mean the UPM RAM words, my setup perfectly matches the table in the manual. Also, I have 64 Mb of ram, and u-boot recognizes it as such. As for all of it working, I am going to run the u-boot memory test on the whole thing to see if there are any problems. Do you have any other suggestions that might make it more apparent if my memory is not correct?
It may have to do with U-Boot, more precisely with your memory initialization.
Am I right in saying that the following problem is indicative of a memory problem? When I plugged the BDI into the board in an attempt to figure out where the problem occured exactly, I got the following output:
...
VFS: Mounted root (ext2 filesystem). Oops: Kernel Mode Software FPU Emulation, sig: 8 NIP: C0048000 XER: 20000000 LR: C0048224 SP: C3A25E30 REGS: c3a25d80 TRAP: 1000 Not tainted MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK = c3a24000[1] 'swapper' Last syscall: 6 last math 00000000 last altivec 00000000 GPR00: 00000000 C3A25E30 C3A24000 C3A15960 C3A15960 C00FE4CC 00000000 C3BEB1A8 GPR08: C3A30580 00000000 C3A15970 C3A15970 22008082 00000000 03FFE000 00000001 GPR16: 007FFF40 00000000 00000001 007FFF00 03FF8B5C FFFFFFFF 00000000 03BCF308 GPR24: 00000000 C3A25F60 C00FE4CC C0110000 C3A306D0 C0111314 C3A1B800 C3A15960 Call backtrace: C3BEC5D0 C0065DC8 C0045BBC C00360A0 C0036758 C00367D0 C004AAC0 C004AE38 C011DF84 C00026A0 C0002280 C0006B60 Kernel panic: Attempted to kill init! <0>Rebooting in 180 seconds..
I read in the FAQ that memory misconfigured PowerPCs tend to have floating point exceptions. I am not able to look at the memory indicated in the call backtrace without killing the board. Is there some other way to better understand this backtrace?
I am starting to be convinced that somehow to SDRAM is not initialized correctly, but past the UPM RAM words and writing the MAR and MCR, I am not sure what else has to be done to initialize it correctly. Any guidance would be greatly appreciated. I'm very new to this, and your help has been invaluable.
Thanks again, Will Haines
In message loom.20050719T182347-661@post.gmane.org you wrote:
If you mean the UPM RAM words, my setup perfectly matches the table in the manual. Also, I have 64 Mb of ram, and u-boot recognizes it as such. As
Please RTFM, the UPM table is just half of the story.
for all of it working, I am going to run the u-boot memory test on the whole thing to see if there are any problems. Do you have any other suggestions that might make it more apparent if my memory is not correct?
Check if there are mirrored areas.
Am I right in saying that the following problem is indicative of a memory problem? When I plugged the BDI into the board in an attempt to figure out
No. Memory problems is just one of the possible explanations.
Call backtrace: C3BEC5D0 C0065DC8 C0045BBC C00360A0 C0036758 C00367D0 C004AAC0 C004AE38 C011DF84 C00026A0 C0002280 C0006B60
And what did the backtrace show?
I read in the FAQ that memory misconfigured PowerPCs tend to have floating point exceptions. I am not able to look at the memory indicated in the call backtrace without killing the board. Is there some other way to better
Why not? You can type "halt" at the BDI any time...
I am starting to be convinced that somehow to SDRAM is not initialized correctly, but past the UPM RAM words and writing the MAR and MCR, I am not sure what else has to be done to initialize it correctly. Any guidance
Read the chip manufacturer's manual again.
Best regards,
Wolfgang Denk
participants (4)
-
CG -
Steven Scholz -
Will Haines -
Wolfgang Denk