Actions
Forum Thread Details
  • State Not Answered
  • Replies 6 replies
  • Subscribers 303 subscribers
  • Views 537 views
  • Users 0 members are here
Related

XilinxLinux 2013.4 Kernel Panic

Former Member

Hi.
I have a big problem using Xilinx Linux - branch Xilinx-v2013.4
First, I successfully finished Speedway tutorial and my linux has run on target.
Now I want to use the latest stable version of Xilinx Linux for ZedBoard. Result:
Kernel Panic!
In detail, my problem looks like:

[...]
RAMDISK: gzip image found at block 0
RAMDISK: incomplete write (18154 != 32768)
write error
VFS: Mounted root (ext2 filesystem) on device 1:0.
EXT2-fs (ram0): error: ext2_get_inode: unable to read inode block - inode=6145, block=24708
devtmpfs: error mounting -5
Freeing unused kernel memory: 172K (c056b000 - c0596000)
EXT2-fs (ram0): error: ext2_get_inode: unable to read inode block - inode=4097, block=16387
EXT2-fs (ram0): error: ext2_get_inode: unable to read inode block - inode=4097, block=16387
EXT2-fs (ram0): error: ext2_get_inode: unable to read inode block - inode=4097, block=16387
Kernel panic - not syncing: No init found.  Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
CPU0: stopping
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.12.0-xilinx #1
[<c0014ef8>] (unwind_backtrace+0x0/0x11c) from [<c0011404>] (show_stack+0x10/0x14)
[<c0011404>] (show_stack+0x10/0x14) from [<c03ea514>] (dump_stack+0x84/0xc8)
[<c03ea514>] (dump_stack+0x84/0xc8) from [<c00137b0>] (ipi_cpu_stop+0x3c/0x6c)
[<c00137b0>] (ipi_cpu_stop+0x3c/0x6c) from [<c0013dc0>] (handle_IPI+0x64/0xa8)
[<c0013dc0>] (handle_IPI+0x64/0xa8) from [<c00084e0>] (gic_handle_irq+0x54/0x5c)
[<c00084e0>] (gic_handle_irq+0x54/0x5c) from [<c0011e80>] (__irq_svc+0x40/0x70)
Exception stack(0xc0599f70 to 0xc0599fb8)
9f60:                                     c0a0c9f0 00000000 00000000 00000000
9f80: c0599fc0 00000000 ffffffff c058d950 c0a09200 413fc090 00000000 00000000
9fa0: c0a0c9fc c0599fb8 c000ef9c c000efa0 60000113 ffffffff
[<c0011e80>] (__irq_svc+0x40/0x70) from [<c000efa0>] (arch_cpu_idle+0x24/0x2c)
[<c000efa0>] (arch_cpu_idle+0x24/0x2c) from [<c0052e64>] (cpu_startup_entry+0xb8/0x12c)
[<c0052e64>] (cpu_startup_entry+0xb8/0x12c) from [<c056ba2c>] (start_kernel+0x2b0/0x304)


What I did:
* built my fsbl, bitstream and u-boot (same branch as mentioned above), merged it to the boot.bin with sdk-xilinx tools...
* built my ramdisk image, like it is described in speedway tutorial, and wrapped it with u-boot tools to uramdisk...
* built the kernel with additional arguments for u-boot header (...0x8000 ...)
* built the device tree with modified parameters for:
->uFFFCbootargs = "console=ttyPS0,115200 root=/dev/ram rw ip=192.168.1.10 earlyp- rintk";

->mdio:
mdio {
tttt#address-cells = <1>;
tttt#size-cells = <0>;
ttttphy0: phy@0 {
tttttcompatible = "marvell,88e1510";
tttttdevice_type = "ethernet-phy";
tttttreg = <0>;
tttttmarvell,reg-init = <3 16 0xff00 0x1e 3 17 0xff0 0x0a>;
tttt} ;
and sdio frequency, set to 33333000

It is still not working.
Does anybody know y?
Thanks in advance

Parents
  • 0

    Hi jona.sander,

    Have you built your own hardware platform (PS7 configuration --> FSBL) or are you using one from the SpeedWay?

    I created a new Vivado 2013.4 platform to explore the ZedBoard presets available in the Zynq IP block customization window.  According to these presets, the Clock Configuration shows that the SDIO peripheral clock is supplied at 50MHz.  I didn't add any other IP blocks to my block design so I disabled the M AXI GP0 interface within the PS-PL Configuration screen.

    I built this hardware platform, exported to SDK and combined with the pre-built 2013.4 release u-boot.elf to make a new boot.bin which appears to boot my ZedBoard into the 2013.4 release Linux without encountering the problems you described above.

    Also, standard SDHC clock rate for SD cards is specified at 50MHz and that is the value set for the SDIO device within the Xilinx 2013.4 Linux release archive devicetree.dtb.  I believe that both the hardware platform and the devicetree SDIO clock settings should be set to 50MHz, is there a reason that you need to change to 33.333MHz?

    If the SDIO clock setting is not the problem, I can offer the suggestion of trying to isolate which of the components you have built (FSBL, U-boot, Linux kernel, devicetree, and ramdisk) is causing the problems you mentioned by starting with the Xilinx release and swapping the new components in, one at a time, to narrow down where the root of the trouble exists.

    Please post your results here to share with the rest of the community.

    Regards,

    -Kevin

Reply
  • 0

    Hi jona.sander,

    Have you built your own hardware platform (PS7 configuration --> FSBL) or are you using one from the SpeedWay?

    I created a new Vivado 2013.4 platform to explore the ZedBoard presets available in the Zynq IP block customization window.  According to these presets, the Clock Configuration shows that the SDIO peripheral clock is supplied at 50MHz.  I didn't add any other IP blocks to my block design so I disabled the M AXI GP0 interface within the PS-PL Configuration screen.

    I built this hardware platform, exported to SDK and combined with the pre-built 2013.4 release u-boot.elf to make a new boot.bin which appears to boot my ZedBoard into the 2013.4 release Linux without encountering the problems you described above.

    Also, standard SDHC clock rate for SD cards is specified at 50MHz and that is the value set for the SDIO device within the Xilinx 2013.4 Linux release archive devicetree.dtb.  I believe that both the hardware platform and the devicetree SDIO clock settings should be set to 50MHz, is there a reason that you need to change to 33.333MHz?

    If the SDIO clock setting is not the problem, I can offer the suggestion of trying to isolate which of the components you have built (FSBL, U-boot, Linux kernel, devicetree, and ramdisk) is causing the problems you mentioned by starting with the Xilinx release and swapping the new components in, one at a time, to narrow down where the root of the trouble exists.

    Please post your results here to share with the rest of the community.

    Regards,

    -Kevin

Children
No Data