• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 103 subscribers
  • Views 1016 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Creating Nand Flash Image

Bill
Intellectual 645 points

5078.boot.log

I am currently running a keystone II EVM but we are going to be getting custom hardware in fairly soon and I wanted to be sure that I would be able to bring the board up from empty flash with my own filesystem and kernel. On the EVM i have been running a custom compiled kernel just by replacing the files in the boot partition with my uImage, and DTS, so I know they are running correctly. I am not trying to turn my kernel images, and Rootfile system into a UBI image. How I understand it now is that the EVM has three MTD partition on it, MTD0 being the bootloader (I have mine in SPI nor flash), MTD1 being U-boot params, and MTD2 being the UBI image.

Within my UBI image I should have 2? volumes. Volume 0 "boot" containing my boot monitor, uImage, and .dtb.

Volume 2 should have my rootfs. I have gotten this by extracting the .cpio.gz that came with the MCSDK release.

To create my two volumes, I put my three boot files in a directory and did a mkfs.ubifs and got a boot.img file

I did the same thing with the rootfs and go t a rootfs.img file

I then used this ubinize.cfg to create my ubi image.

[boot]
mode=ubi
image=boot.img
vol_type=dynamic
vol_id=0
vol_name=boot
vol_size=10MiB
[rootfs]
mode=ubi
image=rootfs.img
vol_id=1
vol_type=dynamic
vol_size=100MiB
vol_name=rootfs
vol_flags=autoresize

I then flashed this to the nand at the begining of the mtd2 partition.

Now when I boot I am able to load the three boot files but then I get a kernel panic. Attached is the output of the boot.

Am I missing any steps in this process? I am not very familiar with this process so I could be missing a very simple and easy step.

  • 0
    TI__Guru** 116100 points

    Hi Bill,

    Your UBIFS flashing steps and understanding on KS2 boot & rootfs partitions seems to correct.

    1) Try to pass "init=/bin/init or init=/sbin/init" in bootarg

    2) Boot the board through NFS and try the below command to mount "rootfs" partition in 'mnt' to check filesystem present or not.

    http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Exploring#Updating_Boot_volume_images_from_Linux_kernel

    mount -t ubifs ubi0_1 /mnt

    3) Try to use different filesystem (rootfs) and not .cpio.gz
  • 0 in reply to Titusrathinaraj Stalin
    Prodigy 150 points

    Hi Titus, I work with Bill. We have a nand.bin from the MCSDK distribution ... it works, but we'd like to make some modifications. It would be an excellent starting point to be able to recreate the nand.bin in the MCSDK distribution. Is that possible? I believe there's insufficient information in the distribution to recreate that file -- can TI provide us what we need?

  • 0 in reply to Matt Cobb
    TI__Guru** 116100 points

    Hi Matt,

    Could you please tell us that what type of code are you talking about (nand.bin)?

    SYS/BIOS/Linux-C6x/Linux/ or OOB demo (out of box demo)

    I presume that you are working on Keystone II as like Bill.

    So, nand.bin is UBIFS image which has kernel image (uImage) , dtb, monitor and roortfs.

    Try to create "k2h-evm-ubifs.ubi" with your custom binaries.

    http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Exploring#Using_UBIFS_file_system

    Please let me know if you are not looking into this and correct me if I'm wrong.

  • 0 in reply to Titusrathinaraj Stalin
    Prodigy 150 points

    Hi Titus,

    Yes, k2h-evm-ubifs.ubi is identical to the nand.bin that is given in the mcsdk distribution under mcsdk_bios_*/tools/program_evm/binaries/evm_k2h/.

    I did not realize that the .ubi file existed in the *_linux* directory, or that the "parts" of the file were there as well. Bill was aware, though, and is trying to recreate from the parts (after which we'll try substituting our custom code). He's had some root access problems that we're trying to get around with Cygwin, perhaps with some luck.


    Thanks,
    Matt

  • 0 in reply to Titusrathinaraj Stalin
    Prodigy 150 points

    We continue to try both recreating the TI-supplied files from the TI-supplied parts, and creating our custom files from changes to the TI parts.

    In trying to recreate k2h-evm-ubifs.ubi we have hit a couple of issue. We've tried to duplicate the recipe TI provides as closely as possible, but have used a newer version of the zlib library.

    We ran into an error in that ubinize.cfg does not have a vol_size= line under [rootfs]. We added vol_size=100MiB

    This resulted in a *.ubi which is identically sized to k2h-evm-ubifs.ubi (good), and functions (good), but does not give us exactly the same output on bootup (a little concerning), and has plenty of differences when comparing the binaries (identical would have made me happier).

    We're proceeding to try to recreate tisdk-rootfs.ubifs from the extracted file system. But the above issues mean we're not on as solid a footing as I'd prefer. Do you know why we would have differences in our *.ubi, when we've used the same file inputs and the same commands? Can the zlib tool version explain this?

    Thanks,
    Matt

  • 0 in reply to Matt Cobb
    TI__Guru** 116100 points

    Hi Matt,

    This resulted in a *.ubi which is identically sized to k2h-evm-ubifs.ubi (good), and functions (good), but does not give us exactly the same output on bootup (a little concerning), and has plenty of differences when comparing the binaries (identical would have made me happier).

    Could you please attach the both the logs (TI SDK and yours).

  • 0 in reply to Titusrathinaraj Stalin
    Prodigy 150 points

    Hi Titus,

    The log outputs that I had been concerned about turned out to be a matter of first boot vs. subsequent boot, not our file vs. factory file.

    Updating our other concerns: Most importantly, we were able to create our own working *.ubi file. We switched to using the tar version of the ubifs file, but also moved to a virtual machine where we had root access. We think that was the critical step in making it work.

    Since we had already started down the path of trying to duplicate the *.ubi file that TI provides, we continued with that to see if we could get some resolution. Just trying to duplicate the final step (ubinize) using the factory ubifs and cfg inputs, we end up with files that differ in 4000+ bytes ... but just calling ubinize twice ourselves produces similar differences ... so something about that step is not repeatable, but we've gotten as close as we can expect to. We also were unable to reproduce a duplicate of tisdk-rootfs.ubifs, in this case even the file sizes differed by about 380 kB. We've decided to move on however, given that we've got a custom image that appears to work fine.

    Thanks,
    Matt