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.
Tool/software: Linux
Hi
I am looking for help in trying to debug why I cannot get my root filesystem to mount.
I am using an am355x on the latest SDK on a board based on the BeagleBoneBlack
It is intended that this will be a small filesystem resident on a SPI NOR flash.
The chip we are using a N25Q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB.
It is partitioned within the device tree as:
&spi0 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&spi0_pins>; spi-flash@0 { compatible = "micron,n25q256a","jedec,spi-nor"; spi-max-frequency = <48000000>; status = "okay"; reg = <0>; m25p,fast-read; #address-cells = <1>; #size-cells = <1>; partition@0 { label = "SPL"; reg = <0x00000000 0x00020000>; }; partition@20000 { label = "u-boot"; reg = <0x00020000 0x00066000>; }; partition@86000 { label = "dtb"; reg = <0x00086000 0x00010000>; }; partition@96000 { label = "kernel"; reg = <0x00960000 0x0050a000>; }; partition@5a0000 { label = "-"; reg = <0x005a0000 0x01a60000>; }; }; };
on booting the kernel these appear as:
[ 1.094466] m25p80 spi1.0: n25q256a (32768 Kbytes) [ 1.098993] 5 ofpart partitions found on MTD device spi1.0 [ 1.104083] Creating 5 MTD partitions on "spi1.0": [ 1.108555] 0x000000000000-0x000000020000 : "SPL" [ 1.114522] 0x000000020000-0x000000086000 : "u-boot" [ 1.120532] 0x000000086000-0x000000096000 : "dtb" [ 1.126190] 0x000000960000-0x000000e6a000 : "kernel" [ 1.132166] 0x0000005a0000-0x000002000000 : "-"
I have used BitBake and the instructions in processors.wiki.ti.com/.../Processor_SDK_Building_The_SDK to create a ubifs and ubi
I modified the descriptors within my MACHINE config for these to try and match the chip we are using.
These modifications were:
MKUBIFS_ARGS = "-F -m 256 -e 126976 -c 110" UBINIZE_ARGS = "-m 256 -p 4KiB"
I then transfer the .ubi file via u-boot (sf erase and sd write) in to the intended location of the chip
- SPL, u-boot, kernel and devicetree are all loaded and run from SPI flash without problem
The rootfs however fails to mount, specifically failing to "attach" the mtd4:
[ 0.000000] Kernel command line: console=ttyO0,115200n8 noinitrd ip=off rw ubi.mtd=4,256 noinitrd rootfstype=ubifs m em=256M root=ubi0:rootfs rootwait=1 <snip> [ 1.607933] ubi0: attaching mtd4 [ 1.617855] ubi0 error: validate_ec_hdr: bad data offset 512, expected 320 [ 1.624236] ubi0 error: validate_ec_hdr: bad EC header [ 1.637806] Erase counter header dump: [ 1.641286] magic 0x55424923 [ 1.644762] version 1 [ 1.647511] ec 0 [ 1.667801] vid_hdr_offset 256 [ 1.670715] data_offset 512 [ 1.673627] image_seq 645878812 [ 1.677020] hdr_crc 0x63941dbf [ 1.687801] erase counter header hexdump: [ 1.691567] CPU: 0 PID: 1 Comm: swapper Not tainted 4.4.19-gdb0b54cdad #74 [ 1.707811] Hardware name: Generic AM33XX (Flattened Device Tree) [ 1.713466] Backtrace: [ 1.715779] [<c00134e4>] (dump_backtrace) from [<c00136e0>] (show_stack+0x18/0x1c) [ 1.737804] r7:00000000 r6:00000000 r5:cd824000 r4:cdd19340 [ 1.743107] [<c00136c8>] (show_stack) from [<c02b9848>] (dump_stack+0x24/0x28) [ 1.767829] [<c02b9824>] (dump_stack) from [<c0448640>] (validate_ec_hdr+0xc0/0x12c) [ 1.775023] [<c0448580>] (validate_ec_hdr) from [<c04492a4>] (ubi_io_read_ec_hdr+0x168/0x218) [ 1.797806] r7:cd824000 r6:55424923 r5:cdd19340 r4:00000000 [ 1.803097] [<c044913c>] (ubi_io_read_ec_hdr) from [<c044e388>] (ubi_attach+0x184/0x14b0) [ 1.817804] r10:cdd11a80 r9:c09a531c r8:00000000 r7:cd824000 r6:00000000 r5:cd824000 [ 1.825102] r4:00000000 [ 1.827465] [<c044e204>] (ubi_attach) from [<c0442dec>] (ubi_attach_mtd_dev+0x640/0xbf0) [ 1.857801] r10:fffff000 r9:00000140 r8:cdc73800 r7:cd824000 r6:00000000 r5:cdc73800 [ 1.865098] r4:00000001 [ 1.867463] [<c04427ac>] (ubi_attach_mtd_dev) from [<c08f67bc>] (ubi_init+0x1e4/0x26c) [ 1.887801] r10:fffff000 r9:c0865488 r8:c08654b4 r7:c090d680 r6:c090d684 r5:cdc73800 [ 1.895099] r4:00000000 [ 1.897462] [<c08f65d8>] (ubi_init) from [<c00096bc>] (do_one_initcall+0x98/0x1e4) [ 1.917805] r10:00000000 r9:c08d3600 r8:000000a9 r7:cdd19280 r6:c091ac60 r5:c08f65d8 [ 1.925103] r4:c091ac60 [ 1.927478] [<c0009624>] (do_one_initcall) from [<c08d3e80>] (kernel_init_freeable+0x138/0x1cc) [ 1.957802] r10:00000008 r9:c08d3600 r8:000000a9 r7:c0907834 r6:c0914120 r5:c0964d80 [ 1.965102] r4:c0964d80 [ 1.967472] [<c08d3d48>] (kernel_init_freeable) from [<c068002c>] (kernel_init+0x18/0xf4) [ 1.987801] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0680014 [ 1.995097] r4:c0964d80 [ 1.997461] [<c0680014>] (kernel_init) from [<c000fab8>] (ret_from_fork+0x14/0x3c) [ 2.027801] r5:c0680014 r4:00000000 [ 2.031133] ubi0 error: ubi_io_read_ec_hdr: validation failed for PEB 0 [ 2.037279] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd4, error -22 [ 2.057817] UBI error: cannot attach mtd4 [ 2.061786] hctosys: unable to open rtc device (rtc0) [ 2.081261] vmmcsd_fixed: disabling [ 2.084658] ALSA device list: [ 2.087413] No soundcards found. [ 2.109328] UBIFS error (pid: 1): cannot open "ubi0:rootfs", error -19VFS: Cannot open root device "ubi0:rootfs" or unknown-block(0,0): error -19 [ 2.127837] Please append a correct "root=" boot option; here are the available partitions: [ 2.135613] 1f00 128 mtdblock0 (driver?) [ 2.158792] 1f01 408 mtdblock1 (driver?) [ 2.163487] 1f02 64 mtdblock2 (driver?) [ 2.177811] 1f03 5160 mtdblock3 (driver?) [ 2.182509] 1f04 27008 mtdblock4 (driver?) [ 2.187203] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 2.194875] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
I have tried several variations of the bootargs without succees:
Including:
root=/dev/mtd4 root=/dev/mtdblock root=ubi0:rootfs
I would be grateful for any suggestions as to what I might be doing wrong.
Best regards,
Richard
Hi
digging further I find that my mkfs.ubi arguments do not look to be a good fit for the SPI NOR flash I am using (I think I must have confused myself reading NAND-centric documentation).
However if I change my mkfs/uninize argumentsas so:
MKUBIFS_ARGS = "-F -m 1 -e 65408 -c 225" UBINIZE_ARGS = "-m 1 -p 64KiB -O 64"
- figures based on using the 64KB "sector" for erase partition not the 4KB "sub sector" reported
- and are similar to values in e2e.ti.com/.../1531937
I get what looks to be a very similar error:
[ 1.607933] ubi0: attaching mtd4 [ 1.617843] ubi0 error: validate_ec_hdr: bad VID header offset 64, expected 256 [ 1.624627] ubi0 error: validate_ec_hdr: bad EC header [ 1.637792] Erase counter header dump: [ 1.641272] magic 0x55424923 [ 1.644747] version 1 [ 1.647495] ec 0 [ 1.667788] vid_hdr_offset 64 [ 1.670620] data_offset 128 [ 1.673532] image_seq 422620020 [ 1.676925] hdr_crc 0x37adbf5b [ 1.687787] erase counter header hexdump: [ 1.691553] CPU: 0 PID: 1 Comm: swapper Not tainted 4.4.19-gdb0b54cdad #74 [ 1.707799] Hardware name: Generic AM33XX (Flattened Device Tree) [ 1.713453] Backtrace: [ 1.715767] [<c00134e4>] (dump_backtrace) from [<c00136e0>] (show_stack+0x18/0x1c) [ 1.737791] r7:00000000 r6:00000000 r5:cd824000 r4:cdd19340 [ 1.743093] [<c00136c8>] (show_stack) from [<c02b9848>] (dump_stack+0x24/0x28) [ 1.767814] [<c02b9824>] (dump_stack) from [<c0448640>] (validate_ec_hdr+0xc0/0x12c) [ 1.775008] [<c0448580>] (validate_ec_hdr) from [<c04492a4>] (ubi_io_read_ec_hdr+0x168/0x218) [ 1.797792] r7:cd824000 r6:55424923 r5:cdd19340 r4:00000000 [ 1.803083] [<c044913c>] (ubi_io_read_ec_hdr) from [<c044e388>] (ubi_attach+0x184/0x14b0) [ 1.817790] r10:cdd11a80 r9:c09a531c r8:00000000 r7:cd824000 r6:00000000 r5:cd824000 [ 1.825089] r4:00000000 [ 1.827453] [<c044e204>] (ubi_attach) from [<c0442dec>] (ubi_attach_mtd_dev+0x640/0xbf0) [ 1.857788] r10:fffff000 r9:00000140 r8:cdc73800 r7:cd824000 r6:00000000 r5:cdc73800 [ 1.865085] r4:00000001 [ 1.867450] [<c04427ac>] (ubi_attach_mtd_dev) from [<c08f67bc>] (ubi_init+0x1e4/0x26c) [ 1.887788] r10:fffff000 r9:c0865488 r8:c08654b4 r7:c090d680 r6:c090d684 r5:cdc73800 [ 1.895085] r4:00000000 [ 1.897446] [<c08f65d8>] (ubi_init) from [<c00096bc>] (do_one_initcall+0x98/0x1e4) [ 1.917792] r10:00000000 r9:c08d3600 r8:000000a9 r7:cdd19280 r6:c091ac60 r5:c08f65d8 [ 1.925093] r4:c091ac60 [ 1.927469] [<c0009624>] (do_one_initcall) from [<c08d3e80>] (kernel_init_freeable+0x138/0x1cc) [ 1.957788] r10:00000008 r9:c08d3600 r8:000000a9 r7:c0907834 r6:c0914120 r5:c0964d80 [ 1.965089] r4:c0964d80 [ 1.967459] [<c08d3d48>] (kernel_init_freeable) from [<c068002c>] (kernel_init+0x18/0xf4) [ 1.987788] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0680014 [ 1.995087] r4:c0964d80 [ 1.997451] [<c0680014>] (kernel_init) from [<c000fab8>] (ret_from_fork+0x14/0x3c) [ 2.027788] r5:c0680014 r4:00000000 [ 2.031122] ubi0 error: ubi_io_read_ec_hdr: validation failed for PEB 0 [ 2.037266] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd4, error -22 [ 2.057806] UBI error: cannot attach mtd4 [ 2.061758] hctosys: unable to open rtc device (rtc0) [ 2.081243] vmmcsd_fixed: disabling [ 2.084647] ALSA device list: [ 2.087400] No soundcards found. [ 2.109312] UBIFS error (pid: 1): cannot open "ubi0:rootfs", error -19VFS: Cannot open root device "ubi0:ro9 [ 2.127822] Please append a correct "root=" boot option; here are the available partitions: [ 2.135601] 1f00 128 mtdblock0 (driver?) [ 2.158779] 1f01 408 mtdblock1 (driver?) [ 2.163475] 1f02 64 mtdblock2 (driver?) [ 2.177797] 1f03 5160 mtdblock3 (driver?) [ 2.182494] 1f04 27008 mtdblock4 (driver?) [ 2.187188] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 2.194861] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Thanks for any suggestions
All the best,
Richard
Hi
I spent a bit of time approaching this from the other direction trying to understand what is going on
So I enabled mtd and UBI support in u-boot;
I have defined my partitions as follows for the moment
=> mtdparts ---mtdparts_init--- last_ids : nor0=spi1.0 env_ids : nor0=spi1.0 last_parts: mtdparts=spi1.0:0x00020000@0x00000000(SPL),0x00066000@0x00020000(u-boot),0x00010000@0x00086000(dtb),0x0050a000@0x00096000(kernel),-(rootfs) env_parts : mtdparts=spi1.0:0x00020000@0x00000000(SPL),0x00066000@0x00020000(u-boot),0x00010000@0x00086000(dtb),0x0050a000@0x00096000(kernel),-(rootfs) last_partition : nor0,0 env_partition : nor0,0 ---list_partitions--- device nor0 <spi1.0>, # parts = 5 #: name size offset mask_flags 0: SPL 0x00020000 0x00000000 0 1: u-boot 0x00066000 0x00020000 0 2: dtb 0x00010000 0x00086000 0 3: kernel 0x0050a000 0x00096000 0 4: rootfs 0x01a60000 0x005a0000 0 --- mtd_part_info: partition number 0 for device nor0 (spi1.0) active partition: nor0,0 - (SPL) 0x00020000 @ 0x00000000
and have succesfully used ubi part to create a ubi partition on the mtd:rootfs
specifcally i typed the command as: ubi part rootfs
this completes with the following output (along with an example of ubi info)
UBI DBG eba (pid 1): initialize EBA sub-system UBI DBG eba (pid 1): EBA sub-system is initialized UBI DBG gen (pid 1): ubi0 major is 0 ubi0: attached mtd1 (name "mtd=4", size 26 MiB) ubi0: PEB size: 4096 bytes (4 KiB), LEB size: 3968 bytes ubi0: min./max. I/O unit sizes: 1/256, sub-page size 1 ubi0: VID header offset: 64 (aligned 64), data offset: 128 ubi0: good PEBs: 6752, bad PEBs: 0, corrupted PEBs: 0 ubi0: user volume: 0, internal volumes: 1, max. volumes count: 23 ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 0 ubi0: available PEBs: 6748, total reserved PEBs: 4, PEBs reserved for bad PEB handling: 0 => ubi info 0 UBI: MTD device name: "mtd=4" UBI: MTD device size: 26 MiB UBI: physical eraseblock size: 4096 bytes (4 KiB) UBI: logical eraseblock size: 3968 bytes UBI: number of good PEBs: 6752 UBI: number of bad PEBs: 0 UBI: smallest flash I/O unit: 1 UBI: VID header offset: 64 (aligned 64) UBI: data offset: 128 UBI: max. allowed volumes: 23 UBI: wear-leveling threshold: 4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 0 UBI: available PEBs: 6748 UBI: total number of reserved PEBs: 4 UBI: number of PEBs reserved for bad PEB handling: 0 UBI: max/mean erase counter: 1/0
This would lead to believe the options I should be supplying to mkfs.ubi and ubinize are
MKUBIFS_ARGS = "-F -m 1 -e 3968 -c 6752 -x zlib"
UBINIZE_ARGS = "-m 1 -p 4KiB -O 64"
However when I run MACHINE=<my-board> bitbake core-image-minimal
Log data follows:
| DEBUG: Executing python function set_image_size
| DEBUG: Python function set_image_size finished
| DEBUG: Executing shell function do_image_ubifs
| Error: too small LEB size 3968, minimum is 15360
this seems like an issue that has cropped up for others in the past (e.g.http://lists.infradead.org/pipermail/linux-mtd/2013-July/047665.html)
can anyone suggest what is the best way to modify the mkfs tool used within the arago build so that I can work around this eraseblock size limitation?
- or indeed if there is another cleaner solution
Thanks for any help.
Best regards,
Richard
Hi Pavel
I have used the Arago Project to create a very stripped down version of core-image-minimal (all unnecessary features removed, BusyBox over systemd)
It is currently working for our application as a NFS image for testing; I now need to weigh up the different options for how the rootfs is constructed (and indeed partitioned) for the ultimate target.
Part of this involves getting my head around the differences in schemes and where the tradeoffs are (e.g. between size, boot time, robustness and performance)
From the documentation UBIFS looked to be recommended as a good first choice over JFFS2.
As it stands for either of these it looks as though I have to modify the tools to allow them to construct an image that would work on the small NOR chip we are using.
So I was planning to configure the Arago Project recipe to build both (and probably a couple of others) so I could try them out and see how they differed.
I am grateful for any and all recommendations; or feedback on this approach
Best regards,
Richard