UBIFS image support?

[swechencheng]

Hi, I am wondering if there is support to directly transfer the whole ubifs image through uuu. I build the rootfs by using ubifs for SOC_DEFAULT_IMAGE_FSTYPES in Yocto. The product is a custom board based on iMX6UL with raw NAND Spansion S34ML04G200BHI (SLC). I tried something like:

# burn rootfs
FBK: ucmd source /tmp/mtd.sh; flash_erase /dev/mtd${nandrootfs} 0 0
FBK: ucmd mkfifo /tmp/ubifs_pipe
FBK: acmd source /tmp/mtd.sh; ubiformat /dev/mtd${nandrootfs} -f /tmp/ubifs_pipe
FBK: ucp _rootfs t:/tmp/ubifs_pipe

And no surprise it does not work. So, is there any way to transfer large image into FBK? Thanks in advance. BR/Chencheng

[allenxh]

The file size is too large. I am not sure if you must generate the single large ubifs image or if you can use the rootfs tarball with following commands.

burn rootfs

FBK: ucmd source /tmp/mtd.sh; flash_erase /dev/mtd${nandrootfs} 0 0 FBK: ucmd source /tmp/mtd.sh; ubiattach /dev/ubi_ctrl -m ${nandrootfs} FBK: ucmd source /tmp/mtd.sh; ubimkvol /dev/ubi0 -Nnandrootfs -m FBK: ucmd source /tmp/mtd.sh; mkdir -p /mnt/mtd FBK: ucmd source /tmp/mtd.sh; mount -t ubifs ubi0:nandrootfs /mnt/mtd FBK: acmd export EXTRACT_UNSAFE_SYMLINKS=1; tar -jx -C /mnt/mtd FBK: ucp _rootfs.tar.bz2 t:- FBK: sync FBK: ucmd umount /mnt/mtd

On Mon, Aug 12, 2024 at 10:02 AM Chencheng Zhang @.***> wrote:

Hi, I am wondering if there is support to directly transfer the whole ubifs image through uuu. I build the rootfs by using ubifs for SOC_DEFAULT_IMAGE_FSTYPES in Yocto. The product is a custom board based on iMX6UL with raw NAND Spansion S34ML04G200BHI (SLC). I tried something like:

burn rootfs

FBK: ucmd source /tmp/mtd.sh; flash_erase /dev/mtd${nandrootfs} 0 0 FBK: ucmd mkfifo /tmp/ubifs_pipe FBK: acmd source /tmp/mtd.sh; ubiformat /dev/mtd${nandrootfs} -f /tmp/ubifs_pipe FBK: ucp _rootfs t:/tmp/ubifs_pipe

And no surprise it does not work. So, is there any way to transfer large image into FBK? Thanks in advance. BR/Chencheng

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Sincerely,

Han XU

[swechencheng]

The file size is too large. I am not sure if you must generate the single large ubifs image or if you can use the rootfs tarball with following commands. # burn rootfs FBK: ucmd source /tmp/mtd.sh; flash_erase /dev/mtd${nandrootfs} 0 0 FBK: ucmd source /tmp/mtd.sh; ubiattach /dev/ubi_ctrl -m ${nandrootfs} FBK: ucmd source /tmp/mtd.sh; ubimkvol /dev/ubi0 -Nnandrootfs -m FBK: ucmd source /tmp/mtd.sh; mkdir -p /mnt/mtd FBK: ucmd source /tmp/mtd.sh; mount -t ubifs ubi0:nandrootfs /mnt/mtd FBK: acmd export EXTRACT_UNSAFE_SYMLINKS=1; tar -jx -C /mnt/mtd FBK: ucp _rootfs.tar.bz2 t:- FBK: sync FBK: ucmd umount /mnt/mtd … On Mon, Aug 12, 2024 at 10:02 AM Chencheng Zhang @.> wrote: Hi, I am wondering if there is support to directly transfer the whole ubifs image through uuu. I build the rootfs by using ubifs for SOC_DEFAULT_IMAGE_FSTYPES in Yocto. The product is a custom board based on iMX6UL with raw NAND Spansion S34ML04G200BHI (SLC). I tried something like: # burn rootfs FBK: ucmd source /tmp/mtd.sh; flash_erase /dev/mtd${nandrootfs} 0 0 FBK: ucmd mkfifo /tmp/ubifs_pipe FBK: acmd source /tmp/mtd.sh; ubiformat /dev/mtd${nandrootfs} -f /tmp/ubifs_pipe FBK: ucp _rootfs t:/tmp/ubifs_pipe And no surprise it does not work. So, is there any way to transfer large image into FBK? Thanks in advance. BR/Chencheng — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.> -- Sincerely, Han XU

Hi thanks for your reply. I know tar ball works and I have succeeded on that. And I understand the tar ball gives us flexibility on strict raw NAND partition. I am seeking the possibility of new way of packaging whole image, so that does not break our existing production line too much. BR/Chencheng

[allenxh]

I am not sure if it works, but it is no harm to try

burn rootfs

FBK: ucmd source /tmp/mtd.sh; flash_erase /dev/mtd${nandrootfs} 0 0 FBK: acmd source /tmp/mtd.sh; ubiformat /dev/mtd${nandrootfs} -f - FBK: ucp _rootfs t:-

On Mon, Aug 12, 2024 at 10:20 AM Chencheng Zhang @.***> wrote:

The file size is too large. I am not sure if you must generate the single large ubifs image or if you can use the rootfs tarball with following commands. # burn rootfs FBK: ucmd source /tmp/mtd.sh; flash_erase /dev/mtd${nandrootfs} 0 0 FBK: ucmd source /tmp/mtd.sh; ubiattach /dev/ubi_ctrl -m ${nandrootfs} FBK: ucmd source /tmp/mtd.sh; ubimkvol /dev/ubi0 -Nnandrootfs -m FBK: ucmd source /tmp/mtd.sh; mkdir -p /mnt/mtd FBK: ucmd source /tmp/mtd.sh; mount -t ubifs ubi0:nandrootfs /mnt/mtd FBK: acmd export EXTRACT_UNSAFE_SYMLINKS=1; tar -jx -C /mnt/mtd FBK: ucp rootfs.tar.bz2 t:- FBK: sync FBK: ucmd umount /mnt/mtd … <#m-921507782081842576_> On Mon, Aug 12, 2024 at 10:02 AM Chencheng Zhang @.*> wrote: Hi, I am wondering if there is support to directly transfer the whole ubifs image through uuu. I build the rootfs by using ubifs for SOC_DEFAULT_IMAGE_FSTYPES in Yocto. The product is a custom board based on iMX6UL with raw NAND Spansion S34ML04G200BHI (SLC). I tried something like:

burn rootfs FBK: ucmd source /tmp/mtd.sh; flash_erase

/dev/mtd${nandrootfs} 0 0 FBK: ucmd mkfifo /tmp/ubifs_pipe FBK: acmd source /tmp/mtd.sh; ubiformat /dev/mtd${nandrootfs} -f /tmp/ubifs_pipe FBK: ucp _rootfs t:/tmp/ubifs_pipe And no surprise it does not work. So, is there any way to transfer large image into FBK? Thanks in advance. BR/Chencheng — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.*> -- Sincerely, Han XU

Hi thanks for your reply. I know tar ball works and I have succeeded on that. And I understand the tar ball gives us flexibility on strict raw NAND partition. I am seeking the possibility of new way of packaging whole image, so that does not break our existing production line too much. BR/Chencheng

— Reply to this email directly, view it on GitHub https://github.com/nxp-imx/mfgtools/issues/433#issuecomment-2284266190, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA54P2BU54URQKZGCTNLOALZRDHEDAVCNFSM6AAAAABMMLVAASVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBUGI3DMMJZGA . You are receiving this because you commented.Message ID: @.***>

-- Sincerely,

Han XU

[swechencheng]

Thanks Allen, But no luck:

2:411-0000000000000000>Start Cmd:FBK: acmd source /tmp/mtd.sh; ubiformat /dev/mtd${nandrootfs} -f -
2:411-0000000000000000>Okay (0.052s)
2:411-0000000000000000>Start Cmd:FBK: ucp _rootfs t:-
ubiformat: mtd5 (nand), size 513802240 bytes (490.0 MiB), 3920 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
0%bscan: scanning eraseblock 1347 -- 34 % complete

It gets stuck at 0%.

[allenxh]

If you boot to the kernel and burn this ubifs image(or a smaller one), does it work?

On Tue, Aug 13, 2024 at 2:03 AM Chencheng Zhang @.***> wrote:

Thanks Allen, But no luck:

2:411-0000000000000000>Start Cmd:FBK: acmd source /tmp/mtd.sh; ubiformat /dev/mtd${nandrootfs} -f - 2:411-0000000000000000>Okay (0.052s) 2:411-0000000000000000>Start Cmd:FBK: ucp _rootfs t:- ubiformat: mtd5 (nand), size 513802240 bytes (490.0 MiB), 3920 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes 0%bscan: scanning eraseblock 1347 -- 34 % complete

It gets stuck at 0%.

— Reply to this email directly, view it on GitHub https://github.com/nxp-imx/mfgtools/issues/433#issuecomment-2285492157, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA54P2EFEE6QDEOW7I6ANO3ZRGVSXAVCNFSM6AAAAABMMLVAASVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBVGQ4TEMJVG4 . You are receiving this because you commented.Message ID: @.***>

-- Sincerely,

Han XU

[swechencheng]

Currently not possible. If I boot into a rootfs, I am not able to unmount the ubi partition to run nand format. Or do you mean run another initramfs via serial download with nand format in its init script? I doubt if the size of initramfs will be too big to be transferred through serial...