[U-Boot] cuImage and multi image?
Hi,
I have a cuImage kernel in order to support legacy u-boot and a ramdisk image. Kernel boots fine if these two images are separate and "bootm $kernel $ramdisk" is used. But I can not make it to work using a single multi image that contains the kernel and ramdisk images. Is it even technically possible to boot a multi-image with cuboot wrapper?
On the cuImage kernel I have load address set to 0x400000 and the entry address set to 0x400554 due to the cuboot wrapper. But to make a multi image, both the load and the entry addresses should be set to zero. And u-boot (1.1.2) bootm takes the entry address of the multi image (i.e. 0x0) as the kernel entry address. 0x0 is certainly not the entry address for a cuImage kernel.
Is there a possible workaround other than using two separate images?
Thanks, -Shawn.
Shawn Jin wrote:
Hi,
I have a cuImage kernel in order to support legacy u-boot and a ramdisk image. Kernel boots fine if these two images are separate and "bootm $kernel $ramdisk" is used. But I can not make it to work using a single multi image that contains the kernel and ramdisk images. Is it even technically possible to boot a multi-image with cuboot wrapper?
Try the following steps: ------ 1. cp <your ramdisk.gz> arch/powerpc/boot/ramdisk.image.gz 2. make cuImage.initrd.<your target>
You can get one Image, cuImage.initrd.<your target>, including kernel and ramdisk.
Cheers Tiejun
On the cuImage kernel I have load address set to 0x400000 and the entry address set to 0x400554 due to the cuboot wrapper. But to make a multi image, both the load and the entry addresses should be set to zero. And u-boot (1.1.2) bootm takes the entry address of the multi image (i.e. 0x0) as the kernel entry address. 0x0 is certainly not the entry address for a cuImage kernel.
Is there a possible workaround other than using two separate images?
Thanks, -Shawn. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
I have a cuImage kernel in order to support legacy u-boot and a ramdisk image. Kernel boots fine if these two images are separate and "bootm $kernel $ramdisk" is used. But I can not make it to work using a single multi image that contains the kernel and ramdisk images. Is it even technically possible to boot a multi-image with cuboot wrapper?
Try the following steps:
- cp <your ramdisk.gz> arch/powerpc/boot/ramdisk.image.gz
- make cuImage.initrd.<your target>
You can get one Image, cuImage.initrd.<your target>, including kernel and ramdisk.
A follow up question. With this method, the total image size (uncompressed) is limited to the 4MB (the link address of the boot wrapper)?
Thanks, -Shawn.
-----Original Message----- From: Shawn Jin [mailto:shawnxjin@gmail.com] Sent: Tuesday, September 21, 2010 1:53 AM To: Chen, Tiejun Cc: ppcdev; uboot Subject: Re: cuImage and multi image?
I have a cuImage kernel in order to support legacy u-boot and a ramdisk image. Kernel boots fine if these two images are
separate and
"bootm $kernel $ramdisk" is used. But I can not make it to
work using
a single multi image that contains the kernel and ramdisk
images. Is
it even technically possible to boot a multi-image with cuboot wrapper?
Try the following steps:
- cp <your ramdisk.gz> arch/powerpc/boot/ramdisk.image.gz
- make cuImage.initrd.<your target>
You can get one Image, cuImage.initrd.<your target>,
including kernel and ramdisk.
A follow up question. With this method, the total image size (uncompressed) is limited to the 4MB (the link address of the boot wrapper)?
No.
Cheers Tiejun
Thanks, -Shawn.
On Tue, 21 Sep 2010 03:03:22 +0200 "Chen, Tiejun" Tiejun.Chen@windriver.com wrote:
-----Original Message----- From: Shawn Jin [mailto:shawnxjin@gmail.com] Sent: Tuesday, September 21, 2010 1:53 AM To: Chen, Tiejun Cc: ppcdev; uboot Subject: Re: cuImage and multi image?
I have a cuImage kernel in order to support legacy u-boot and a ramdisk image. Kernel boots fine if these two images are
separate and
"bootm $kernel $ramdisk" is used. But I can not make it to
work using
a single multi image that contains the kernel and ramdisk
images. Is
it even technically possible to boot a multi-image with cuboot wrapper?
Try the following steps:
- cp <your ramdisk.gz> arch/powerpc/boot/ramdisk.image.gz
- make cuImage.initrd.<your target>
You can get one Image, cuImage.initrd.<your target>,
including kernel and ramdisk.
A follow up question. With this method, the total image size (uncompressed) is limited to the 4MB (the link address of the boot wrapper)?
No.
Yes, unless you change the link address, or provide a vmlinux_alloc callback (which currently only happens on true OF, not cuImage).
Unless you're talking about the "(uncompressed)"? The limit applies to the uncompressed boot image -- anything that the bootwrapper itself is decompressing. It does not apply to any further uncompression of the ramdisk itself.
-Scott
-----Original Message----- From: linuxppc-dev-bounces+tiejun.chen=windriver.com@lists.ozlabs.or g [mailto:linuxppc-dev-bounces+tiejun.chen=windriver.com@lists.o
zlabs.org] On Behalf Of Scott Wood
Sent: Wednesday, September 22, 2010 1:53 AM To: Chen, Tiejun Cc: ppcdev; uboot Subject: Re: [U-Boot] cuImage and multi image?
On Tue, 21 Sep 2010 03:03:22 +0200 "Chen, Tiejun" Tiejun.Chen@windriver.com wrote:
-----Original Message----- From: Shawn Jin [mailto:shawnxjin@gmail.com] Sent: Tuesday, September 21, 2010 1:53 AM To: Chen, Tiejun Cc: ppcdev; uboot Subject: Re: cuImage and multi image?
I have a cuImage kernel in order to support legacy
u-boot and a
ramdisk image. Kernel boots fine if these two images are
separate and
"bootm $kernel $ramdisk" is used. But I can not make it to
work using
a single multi image that contains the kernel and ramdisk
images. Is
it even technically possible to boot a multi-image with cuboot wrapper?
Try the following steps:
- cp <your ramdisk.gz> arch/powerpc/boot/ramdisk.image.gz
- make cuImage.initrd.<your target>
You can get one Image, cuImage.initrd.<your target>,
including kernel and ramdisk.
A follow up question. With this method, the total image size (uncompressed) is limited to the 4MB (the link address of
the boot
wrapper)?
No.
Yes, unless you change the link address, or provide a vmlinux_alloc callback (which currently only happens on true OF, not cuImage).
Unless you're talking about the "(uncompressed)"? The limit applies to the uncompressed boot image -- anything that the bootwrapper itself is decompressing. It does not apply to any further uncompression of the ramdisk itself.
He should point the latter, "the total image size", including ramdisk. But the link address should be limited for the boot Image, not for the attached ramdisk.
Tiejun
-Scott
Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
A follow up question. With this method, the total image size (uncompressed) is limited to the 4MB (the link address of
the boot
wrapper)?
No.
Yes, unless you change the link address, or provide a vmlinux_alloc callback (which currently only happens on true OF, not cuImage).
Unless you're talking about the "(uncompressed)"? The limit applies to the uncompressed boot image -- anything that the bootwrapper itself is decompressing. It does not apply to any further uncompression of the ramdisk itself.
He should point the latter, "the total image size", including ramdisk. But the link address should be limited for the boot Image, not for the attached ramdisk.
Thanks for the clarification. Scott, so what are the things that the bootwrapper is decompressing? The kernel for sure. And anything else? I understand that the ramdisk image will be decompressed later when trying to boot it.
I have a large ramdisk image. The size of the image itself (i.e. the *.gz) is about 4MB. When the ramdisk was being decompressed in the later stage. It had the following errors. It seems to me that the ramdisk image somehow was corrupted. Did the script wrapper mess up the image? Is there any known bug in the wrapper? My kernel is 2.6.33. BTW the ramdisk image can be mounted properly if it's separated from the kernel image.
RAMDISK: gzip image found at block 0 uncompression error VFS: Mounted root (ext2 filesystem) readonly on device 1:0. Freeing unused kernel memory: 104k init EXT2-fs (ram0): error: ext2_check_page: bad entry in directory #336: : rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0 EXT2-fs (ram0): error: remounting filesystem read-only Kernel panic - not syncing: No init found. Try passing init= option to kernel. Call Trace: [c7821f30] [c0006cd8] show_stack+0x40/0x168 (unreliable) [c7821f70] [c001cefc] panic+0x8c/0x178 [c7821fc0] [c00026d4] init_post+0xe4/0xf4 [c7821fd0] [c01ee224] kernel_init+0x108/0x130 [c7821ff0] [c000dcc0] kernel_thread+0x4c/0x68 Rebooting in 180 seconds..
Thanks, -Shawn.
-----Original Message----- From: Shawn Jin [mailto:shawnxjin@gmail.com] Sent: Wednesday, September 22, 2010 1:43 PM To: Chen, Tiejun Cc: Scott Wood; ppcdev; uboot Subject: Re: [U-Boot] cuImage and multi image?
A follow up question. With this method, the total image size (uncompressed) is limited to the 4MB (the link address of
the boot
wrapper)?
No.
Yes, unless you change the link address, or provide a
vmlinux_alloc
callback (which currently only happens on true OF, not cuImage).
Unless you're talking about the "(uncompressed)"? The
limit applies
to the uncompressed boot image -- anything that the bootwrapper itself is decompressing. It does not apply to any further uncompression of the ramdisk itself.
He should point the latter, "the total image size",
including ramdisk.
But the link address should be limited for the boot Image,
not for the
attached ramdisk.
Thanks for the clarification. Scott, so what are the things that the bootwrapper is decompressing? The kernel for sure. And anything else?
I think you can read the file, arch/powerpc/boot/zImage.lds.S, to understand this :)
I understand that the ramdisk image will be decompressed later when trying to boot it.
I have a large ramdisk image. The size of the image itself (i.e. the *.gz) is about 4MB. When the ramdisk was being decompressed
Did you try to change link_address on the file, arch/powerpc/boot/wrapper?
in the later stage. It had the following errors. It seems to me that the ramdisk image somehow was corrupted. Did the script wrapper mess up the image? Is there any known bug in the wrapper? My kernel is 2.6.33.
I tried this mechanism on v2.6.34 and it's fine.
BTW the ramdisk image can be mounted properly if it's separated from the kernel image.
Did you try boot the uImage and the ramdisk separately? For example, you can boot this as the following command: # bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr}
Please use this to check if your ramdisk is valid.
Can you paste the whole log from the u-boot prompt?
Tiejun
RAMDISK: gzip image found at block 0 uncompression error VFS: Mounted root (ext2 filesystem) readonly on device 1:0. Freeing unused kernel memory: 104k init EXT2-fs (ram0): error: ext2_check_page: bad entry in directory #336: : rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0 EXT2-fs (ram0): error: remounting filesystem read-only Kernel panic - not syncing: No init found. Try passing init= option to kernel. Call Trace: [c7821f30] [c0006cd8] show_stack+0x40/0x168 (unreliable) [c7821f70] [c001cefc] panic+0x8c/0x178 [c7821fc0] [c00026d4] init_post+0xe4/0xf4 [c7821fd0] [c01ee224] kernel_init+0x108/0x130 [c7821ff0] [c000dcc0] kernel_thread+0x4c/0x68 Rebooting in 180 seconds..
Thanks, -Shawn.
I have a large ramdisk image. The size of the image itself (i.e. the *.gz) is about 4MB. When the ramdisk was being decompressed
Did you try to change link_address on the file, arch/powerpc/boot/wrapper?
No. I don't have to. Right? The link_address is still 0x400000.
Did you try boot the uImage and the ramdisk separately? For example, you can boot this as the following command: # bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr}
Mine is a cuImage. I'm pretty sure that my ramdisk is valid when it's a separate image. I used "bootm <kernel_addr> <ramdisk_addr>" to boot.
Can you paste the whole log from the u-boot prompt?
In the previous run the ramdisk image was corrupted because the single image was loaded at 0x800000. But the boot message showed that the initrd image was at 0x0066c000-0x009ae825. So it was over the 8MB area.
However after the load address was changed to 0x04000000 (64MB), the ramdisk still seemed corrupted but with different error messages.
=> bootm ## Booting image at 04000000 ... Image Name: Linux-2.6.33.5 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 4424922 Bytes = 4.2 MB Load Address: 00400000 Entry Point: 00400554 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Memory <- <0x0 0x8000000> (128MB) ENET0: local-mac-address <- 00:09:9b:01:58:64 CPU clock-frequency <- 0x7270e00 (120MHz) CPU timebase-frequency <- 0x7270e0 (8MHz) CPU bus-frequency <- 0x3938700 (60MHz)
zImage starting: loaded at 0x00400000 (sp: 0x07d1cbd0) Allocating 0x22a1e1 bytes for kernel ... gunzipping (0x00000000 <- 0x0040c000:0x0066b0ac)...done 0x21c6c8 bytes Attached initrd image at 0x0066c000-0x009ae825 initrd head: 0x1f8b0808
Linux/PowerPC load: root=/dev/ram Finalizing device tree... flat tree at 0x9bb300 Using my870 machine description Linux version 2.6.33.5 (shawn@ubuntu) (gcc version 4.2.2) #4 Tue Sep 21 09:23:51 PDT 2010 Found initrd at 0xc066c000:0xc09ae825 Zone PFN ranges: DMA 0x00000000 -> 0x00008000 Normal 0x00008000 -> 0x00008000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x00000000 -> 0x00008000 MMU: Allocated 72 bytes of context maps for 16 contexts Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: root=/dev/ram PID hash table entries: 512 (order: -1, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 124072k/131072k available (2080k kernel code, 6836k reserved, 84k data, 52k bss, 104k init) Kernel virtual memory layout: * 0xfffdf000..0xfffff000 : fixmap * 0xfde00000..0xfe000000 : consistent mem * 0xfddfa000..0xfde00000 : early ioremap * 0xc9000000..0xfddfa000 : vmalloc & ioremap SLUB: Genslabs=12, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 .... <snipped> .... RAMDISK: gzip image found at block 0 uncompression error VFS: Mounted root (ext2 filesystem) readonly on device 1:0. Freeing unused kernel memory: 104k init EXT2-fs (ram0): error: ext2_check_page: bad entry in directory #336: : unaligned directory entry - offset=0, inode=74187384, rec_len=2081, name_len=126 EXT2-fs (ram0): error: remounting filesystem read-only attempt to access beyond end of device ram0: rw=0, want=156831968, limit=32768 Buffer I/O error on device ram0, logical block 78415983 attempt to access beyond end of device ram0: rw=0, want=112233212, limit=32768 Buffer I/O error on device ram0, logical block 56116605 attempt to access beyond end of device ram0: rw=0, want=6626681482, limit=32768 Buffer I/O error on device ram0, logical block 3313340740 attempt to access beyond end of device ram0: rw=0, want=184684282, limit=32768 Buffer I/O error on device ram0, logical block 92342140 Kernel panic - not syncing: No init found. Try passing init= option to kernel. Call Trace: [c7821f30] [c0006cd8] show_stack+0x40/0x168 (unreliable) [c7821f70] [c001cefc] panic+0x8c/0x178 [c7821fc0] [c00026d4] init_post+0xe4/0xf4 [c7821fd0] [c01ee224] kernel_init+0x108/0x130 [c7821ff0] [c000dcc0] kernel_thread+0x4c/0x68 Rebooting in 180 seconds..
Thanks, -Shawn.
Can you paste the whole log from the u-boot prompt?
In the previous run the ramdisk image was corrupted because the single image was loaded at 0x800000. But the boot message showed that the initrd image was at 0x0066c000-0x009ae825. So it was over the 8MB area.
However after the load address was changed to 0x04000000 (64MB), the ramdisk still seemed corrupted but with different error messages.
=> bootm ## Booting image at 04000000 ... Image Name: Linux-2.6.33.5 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 4424922 Bytes = 4.2 MB Load Address: 00400000 Entry Point: 00400554 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Memory <- <0x0 0x8000000> (128MB) ENET0: local-mac-address <- 00:09:9b:01:58:64 CPU clock-frequency <- 0x7270e00 (120MHz) CPU timebase-frequency <- 0x7270e0 (8MHz) CPU bus-frequency <- 0x3938700 (60MHz)
zImage starting: loaded at 0x00400000 (sp: 0x07d1cbd0) Allocating 0x22a1e1 bytes for kernel ... gunzipping (0x00000000 <- 0x0040c000:0x0066b0ac)...done 0x21c6c8 bytes Attached initrd image at 0x0066c000-0x009ae825 initrd head: 0x1f8b0808
Linux/PowerPC load: root=/dev/ram Finalizing device tree... flat tree at 0x9bb300 Using my870 machine description Linux version 2.6.33.5 (shawn@ubuntu) (gcc version 4.2.2) #4 Tue Sep 21 09:23:51 PDT 2010 Found initrd at 0xc066c000:0xc09ae825
The following shows the boot message that the same kernel and the same ramdisk were loaded separately. The difference is that when boot from two separate images, the ramdisk is loaded to the top of RAM (0x79d9000-0x7d1b825). While when booting from the single image, the ramdisk is loaded to the place immediately after the uncompressed kernel image (0x0066c000-0x009ae825). I'm not familiar with how the kernel uses the memory. But it seems clear from this failure that the kernel overwrites to where the initrd locates.
Anyone can shed some light on why the kernel would overwrite the initrd area? BTW, if the initrd is small enough, the single image method works well. Maybe we should have relocated the initrd to the top of available ram just like u-boot's bootm?
=> bootm 1000000 2000000 ## Booting image at 01000000 ... Image Name: Linux-2.6.33.5 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1040228 Bytes = 1015.8 kB Load Address: 00400000 Entry Point: 00400554 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading RAMDisk Image at 02000000 ... Image Name: 16MB Ramdisk Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size: 3418149 Bytes = 3.3 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Ramdisk to 079d9000, end 07d1b825 ... OK Memory <- <0x0 0x8000000> (128MB) ENET0: local-mac-address <- 00:09:9b:01:58:64 CPU clock-frequency <- 0x7270e00 (120MHz) CPU timebase-frequency <- 0x7270e0 (8MHz) CPU bus-frequency <- 0x3938700 (60MHz)
zImage starting: loaded at 0x00400000 (sp: 0x07d1cbd0) Allocating 0x22a1e1 bytes for kernel ... gunzipping (0x00000000 <- 0x0040c000:0x0066b0ac)...done 0x21c6c8 bytes Using loader supplied ramdisk at 0x79d9000-0x7d1b825 initrd head: 0x1f8b0808
Linux/PowerPC load: root=/dev/ram Finalizing device tree... flat tree at 0x678300 Using my870 machine description Linux version 2.6.33.5 (shawn@ubuntu) (gcc version 4.2.2) #4 Tue Sep 21 09:23:51 PDT 2010 Found initrd at 0xc79d9000:0xc7d1b825
Thanks, -Shawn.
-----Original Message----- From: Shawn Jin [mailto:shawnxjin@gmail.com] Sent: Thursday, September 23, 2010 4:23 AM To: Chen, Tiejun Cc: Scott Wood; ppcdev; uboot Subject: Re: [U-Boot] cuImage and multi image?
I have a large ramdisk image. The size of the image itself
(i.e. the
*.gz) is about 4MB. When the ramdisk was being decompressed
Did you try to change link_address on the file,
arch/powerpc/boot/wrapper?
No. I don't have to. Right? The link_address is still 0x400000.
I means you can change link_address to other value according to the Image size. Try set link_address='0x5000000'.
Did you try boot the uImage and the ramdisk separately? For
example, you can boot this as the following command:
# bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr}
Mine is a cuImage. I'm pretty sure that my ramdisk is valid when it's a separate image. I used "bootm <kernel_addr> <ramdisk_addr>" to boot.
Can you paste the whole log from the u-boot prompt?
In the previous run the ramdisk image was corrupted because the single image was loaded at 0x800000. But the boot message showed that the initrd image was at 0x0066c000-0x009ae825. So it was over the 8MB area.
However after the load address was changed to 0x04000000 (64MB), the ramdisk still seemed corrupted but with different error messages.
This should be the same reason, 'uncompression error'.
Cheers Tiejun
=> bootm ## Booting image at 04000000 ... Image Name: Linux-2.6.33.5 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 4424922 Bytes = 4.2 MB Load Address: 00400000 Entry Point: 00400554 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Memory <- <0x0 0x8000000> (128MB) ENET0: local-mac-address <- 00:09:9b:01:58:64 CPU clock-frequency <- 0x7270e00 (120MHz) CPU timebase-frequency <- 0x7270e0 (8MHz) CPU bus-frequency <- 0x3938700 (60MHz)
zImage starting: loaded at 0x00400000 (sp: 0x07d1cbd0) Allocating 0x22a1e1 bytes for kernel ... gunzipping (0x00000000 <- 0x0040c000:0x0066b0ac)...done 0x21c6c8 bytes Attached initrd image at 0x0066c000-0x009ae825 initrd head: 0x1f8b0808
Linux/PowerPC load: root=/dev/ram Finalizing device tree... flat tree at 0x9bb300 Using my870 machine description Linux version 2.6.33.5 (shawn@ubuntu) (gcc version 4.2.2) #4 Tue Sep 21 09:23:51 PDT 2010 Found initrd at 0xc066c000:0xc09ae825 Zone PFN ranges: DMA 0x00000000 -> 0x00008000 Normal 0x00008000 -> 0x00008000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x00000000 -> 0x00008000 MMU: Allocated 72 bytes of context maps for 16 contexts Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: root=/dev/ram PID hash table entries: 512 (order: -1, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 124072k/131072k available (2080k kernel code, 6836k reserved, 84k data, 52k bss, 104k init) Kernel virtual memory layout:
- 0xfffdf000..0xfffff000 : fixmap
- 0xfde00000..0xfe000000 : consistent mem
- 0xfddfa000..0xfde00000 : early ioremap
- 0xc9000000..0xfddfa000 : vmalloc & ioremap
SLUB: Genslabs=12, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 ....
<snipped> .... RAMDISK: gzip image found at block 0 uncompression error VFS: Mounted root (ext2 filesystem) readonly on device 1:0. Freeing unused kernel memory: 104k init EXT2-fs (ram0): error: ext2_check_page: bad entry in directory #336: : unaligned directory entry - offset=0, inode=74187384, rec_len=2081, name_len=126 EXT2-fs (ram0): error: remounting filesystem read-only attempt to access beyond end of device ram0: rw=0, want=156831968, limit=32768 Buffer I/O error on device ram0, logical block 78415983 attempt to access beyond end of device ram0: rw=0, want=112233212, limit=32768 Buffer I/O error on device ram0, logical block 56116605 attempt to access beyond end of device ram0: rw=0, want=6626681482, limit=32768 Buffer I/O error on device ram0, logical block 3313340740 attempt to access beyond end of device ram0: rw=0, want=184684282, limit=32768 Buffer I/O error on device ram0, logical block 92342140 Kernel panic - not syncing: No init found. Try passing init= option to kernel. Call Trace: [c7821f30] [c0006cd8] show_stack+0x40/0x168 (unreliable) [c7821f70] [c001cefc] panic+0x8c/0x178 [c7821fc0] [c00026d4] init_post+0xe4/0xf4 [c7821fd0] [c01ee224] kernel_init+0x108/0x130 [c7821ff0] [c000dcc0] kernel_thread+0x4c/0x68 Rebooting in 180 seconds..
Thanks, -Shawn.
participants (4)
-
Chen, Tiejun -
Scott Wood -
Shawn Jin -
tiejun.chen