Actions
Forum Thread Details
  • State Verified Answer
  • Replies 7 replies
  • Subscribers 326 subscribers
  • Views 2559 views
  • Users 0 members are here
Related

SD card boot + rootfs

micahstevens

Hi,

I've been attempting to get the UltraZed_IOCC_BSP to boot and run the rootfs off the SD card. I can import the fresh BSP and build it, using those images the example boots as an initramfs image fine. I can log in, etc. 

Step 1:

If I merely switch Image Packaging Configuration -> Root Filesystem Type to "SD card". Then I rebuild with petalinux-build. I then put BOOT.BIN, image.ub and system.dtb on the first fat32 partition of 1 gig on a 16 gig sd-card. I then use 'dd' to write rootfs.ext3 to the second partition. 

Kernel begins to boot, but fails some time after the logging to the serial port stops. (See #2 below).  Here is a link to the boot log: 

Pastebin Log

Step 2: 

If I go in and add the console=ttyPS0,115200 stuff to the boot args (petalinux-config -> Kernel Bootargs) I notice it's pointing the rootfs to the wrong partition, so I update the argument string. 

Original: earlycon clk_ignore_unused root=/dev/mmcblk0p2 rw rootwait

Updated: earlycon earlyprintk clk_ignore_unused root=/dev/mmcblk1p2 rw rootwait console=ttyPS0,115200

This works better as I can now see that I'm getting a kernel panic:

Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError

Pastebin Log

Step 3: 

Based on some research I discovered that as it's delivered, the BSP does not configure a write protect pin for the SD card in the device tree. (MIO 44) - however the system will look for the write protect jumper status (SD_WP_N on the carrier board). This prevents a partition from being mounted in RW mode. If you put 'disable-wp;' in the @sdhci0/1 device tree entries in system-user.dtsi, this pin (MIO 44?) will no be referenced and you can mount the filesystems on the card in RW mode.

I was able to verify this works in initramfs, but it did not fix the above kernel panic. 

Question: Do you see that I'm doing something wrong here? Has anyone run into this before? It seems like this should be a simple operation, but I've been working on various iterations of the build for several days and nothing seems to work. I would love some insight on a procedure that works (or a working BSP would be AMAZING) 

Thank you in advance for any help! 

My system-user.dtsi.

My project config.

My u-boot environment.

  • 0

    The lines in your log just before things fall apart are:

    [    1.596896] GPIO IRQ not connected
    [    1.600109] XGpio: /amba_pl@0/gpio@80000000: registered, base is 504
    [    1.606638] GPIO IRQ not connected
    [    1.609849] XGpio: /amba_pl@0/gpio@80010000: registered, base is 496
    [    1.616214] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError

    On my system, the equivalent lines are:

    [    1.337569] GPIO IRQ not connected
    [    1.337583] XGpio: /amba_pl@0/gpio@80000000: registered, base is 330
    [    1.337727] GPIO IRQ not connected
    [    1.337740] XGpio: /amba_pl@0/gpio@80010000: registered, base is 322
    [    1.337878] GPIO IRQ not connected
    [    1.337890] XGpio: /amba_pl@0/gpio@80020000: registered, base is 319

    So perhaps you're missing a GPIO block that it's expecting to find at 0x80020000?

    We've gotten this working on the IOCC by building off of the DisplayPort reference design.  PM me and I can send you a document explaining what we've done so far.

  • 0 in reply to Former Member

    I went back and looked at my design, and I've got three GPIO blocks instantiated in the fabric, so that's why those are in my boot log.  Yours is probably different.  If it helps, my boot log is here: https://pastebin.com/XkUyX1xV

  • 0 in reply to Former Member

    Hi!

    Thanks for taking a look. This is a good point, I'm expecting 3, but it's not hanging when I boot into a RAM rootfs, so I wonder what the difference is there? I'll look more into it, I missed this entirely. 

    I'll also try the same experiment with the DisplayPort design. I'll PM you. 

  • 0

    Boot from SD Card:

    I started with a project from scratch, instead of the downloaded BSP. I then added this manual kernel bootcmd:

     earlycon earlyprintk clk_ignore_unused root=/dev/mmcblk1p2 rw rootwait console=ttyPS0,115200

    Then added "disable-wp;" to the system-user.dtsi file as I described in the original post, and then in u-boot used 'run sdboot' instead of letting it boot normally into RAM. This mounted the second partition as EXT3 RW, and used that as the root file system instead of using RAM. 

    This leads me to believe a couple things, the petalinux-config program does not configure the kernel boot parameters correctly. This should be corrected and I'll post something over at Xilinx about it. Also it seems like it should reconfigure u-boot to boot from the SD card, but it doesn't. There's an undocumented step missing of going into u-boot and telling the default boot to be the sdboot command. 

    Hope this helps someone else. 

  • 0

    Hello micahstevens,

    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    "This leads me to believe a couple things, the petalinux-config program does not configure the kernel boot parameters correctly. This should be corrected and I'll post something over at Xilinx about it. Also it seems like it should reconfigure u-boot to boot from the SD card, but it doesn't. There's an undocumented step missing of going into u-boot and telling the default boot to be the sdboot command. "

     

    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    i am facing some issues in making SD card ext4 partition to be loaded as rootfs in ultrazed. 

    Could you please share the details of the changes/patch you used to correct the kernel and u-boot parameters to boot from SD card.

  • 0 in reply to vishal.bh30

    Hi vishal.bh30,

    Can you share the beginning of your boot log?  The kernel should print out the boot arguments early in the boot sequence, and you can use this to confirm that your settings are propagating correctly.

    I didn't have to change anything for uboot outside of Petalinux.  I only set the Petalinux project config to boot off an external SD partition, and configured the boot line for the kernel.

    I've also got a bootargs line in my devicetree (which is the same as what I configured directly in the kernel), but I haven't figured out how Petalinux/uboot decides which to use.  I think it takes the devicetree one, but I'll have to do some experiments to confirm.

    Hope that helps a little.

  • 0 in reply to Former Member

    Also, a minimal petalinux configuration we're using is here: https://github.com/stevenbell/ultrazynqbuilder

    You should be able to copy everything in the "petalinux" directory as a new project, import your HDF, and build.  This is using the DisplayPort kernel branch, so you may need to change that.