[U-Boot] am335x based board nand boot crashes to ubi0 error

matti kaasinen matti.kaasinen at gmail.com
Mon Jan 9 10:32:50 CET 2017


I made two trials with NANDARGS/nandroot variable in
include/configs/am335x_evm.h that made booting work:
nandroot 'ubi0:rootfs rw ubi.mtd=NAND.file-system,512'
and
nandroot 'ubi0:rootfs rw ubi.mtd=NAND.file-system'
However, nandroot 'ubi0:rootfs rw ubi.mtd=NAND.file-system,2048' did not
work as VID header in ubifs partition created by linux had VID header
position 512.

I tried also:
ubiformat /dev/mtd9  -s 2048
Then ubiattach crashed without -O 2048 option. So, possibly it's better not
providing VID header position in nandroot parameter at all. MTD commands
seem working fine with defaults. If nothing else than default is fed as VID
headr in ubiformat, that should also be fed in nandroot variable.

I found the reason why bootcmd_nand0 variable was missing even though
boot_targets variable had nand0 parameter.
There is a mistake in BOOTENV_DEV_NAND macro definition in:
ti-u-boot/
include/configs/am335x_evm.h:
========= original macro
#define BOOTENV_DEV_NAND(devtypeu, devtypel, instance) \
    "bootcmd_" #devtypel "=" \
    "run nandboot\0"

========= fixed macro
#define BOOTENV_DEV_NAND(devtypeu, devtypel, instance) \
    "bootcmd_" #devtypel  #instance "=" \
    "run nandboot\0"

naturally it could be just as simple as below
#define BOOTENV_DEV_NAND(devtypeu, devtypel, instance) \
    "bootcmd_nand0=" \
    "run nandboot\0"

Now nand boot works.
Only booting worry is that I don't seem to get fdt properly fed to u-boot.
In my opinion simply replacing am335x-evm.dts with myfdt.dts should work,
but still cd_gpio does not get properly detected. So either fdt does not
get loaded or, cd_gpio logic does not work properly. I use quite same dts
file as in Linux side that works fine with mmc card.
This is now very minor problem as car boots fine with main booting device.
Cheers,
Matti

2017-01-06 11:23 GMT+02:00 matti kaasinen <matti.kaasinen at gmail.com>:

> It seems that
> http://www.denx.de/wiki/publish/DULG/DULG-enbw_cmc.html#Section_9.1.5.2.
> Chapter 9.1.5.3.4. Installing UBI images (if no UBI Volumes exist): is
> mentioning a problem like this. Figures in error message are swapped,
> though. Anyhow, the root problem could be the fact that my ubiformat
> statement misses '-s' switch. I'll try that on Monday.
>
> 2017-01-05 16:16 GMT+02:00 matti kaasinen <matti.kaasinen at gmail.com>:
>
>> Hi!
>> I would need help related to nand boot with am335x based board. Board
>> boots from mmc (sd card), but not from nand flash.
>> I have been using yocto/poky build system with meta-ti layer that brings
>> up u-boot-ti-staging. Current u-boot version is 2016.05 and
>> linux-ti-staging-rt-4.4.
>>
>> I have used am335x_evm config (include/configs/am335x_evm.h) that I have
>> made minor modifications to suit it to my board. Most of the modifications
>> are made to board/ti/am335x/board.c and mux.c to adapt to different
>> memories and pin mappings and lack of card id eeprom.
>>
>> This story is "follow up" to http://lists.denx.de/pipermail
>> /u-boot/2017-January/277168.html. So, I2C was initialized somehow when
>> booting from mmc, but not when booting from nand.
>>
>> "Follow up" part:
>> Board did still not start booting kernel even though I2C init problem was
>> fixed.
>>
>> The reason was that boot_targets variable has been assigned with
>> mmc0 legacy_mmc0 mmc1 legacy_mmc1 nand0 pxe dhcp
>> when main u-boot is brought up. These values are iterated when
>> distro_bootcmd is executed.
>> distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target};
>> done
>> I made minor modification to distro_bootcmd:
>> distro_bootcmd=for target in ${boot_targets}; do echo "======= ${target}
>> =======" ; run bootcmd_${target}; done
>> Please find the distro_bootcmd running results below:
>> => run distro_bootcmd
>> ======= mmc0 =======
>> Card did not respond to voltage select!
>> ======= legacy_mmc0 =======
>> Card did not respond to voltage select!
>> Card did not respond to voltage select!
>> ======= mmc1 =======
>> data abort
>> pc : [<8ff70fa0>]          lr : [<8ff701e9>]
>> reloc pc : [<8081dfa0>]    lr : [<8081d1e9>]
>> sp : 8ef286f0  ip : 8ff5891d     fp : 00000003
>> r10: 8ffb3b18  r9 : 8ef32ed8     r8 : 8ef41b10
>> r7 : 8ff584bd  r6 : 8ef39478     r5 : 8ef39500  r4 : 47810000
>> r3 : 8ff70f91  r2 : 00014892     r1 : 00000000  r0 : 8ef39500
>> Flags: nZCv  IRQs off  FIQs on  Mode SVC_32
>> Resetting CPU ...
>>
>> So, MMC1 was troublemaker this time.
>> I removed mmc1 from that command - I do not have mmc1 on my board.
>> => setenv boot_targets ' mmc0 legacy_mmc0  nand0 '
>>
>> Please find modified command results below:
>> => run distro_bootcmd
>> ======= mmc0 =======
>> Card did not respond to voltage select!
>> ======= legacy_mmc0 =======
>> Card did not respond to voltage select!
>> Card did not respond to voltage select!
>> ======= nand0 =======
>> ## Error: "bootcmd_nand0" not defined
>>
>> NOTE!! Is this a bug in u-boot-ti? There is no bootcmd_nand0 in u-boot
>> memory at this time. However, there is bootcmd_nand. So, I changed nand0 to
>> nand
>> => setenv boot_targets ' mmc0 legacy_mmc0  nand'
>> => run distro_bootcmd
>> ======= mmc0 =======
>> Card did not respond to voltage select!
>> ======= legacy_mmc0 =======
>> Card did not respond to voltage select!
>> Card did not respond to voltage select!
>> ======= nand =======
>> Booting from nand ...
>>
>> NAND read: device 0 offset 0x80000, size 0x40000
>>  262144 bytes read: OK
>>
>> NAND read: device 0 offset 0x200000, size 0x800000
>>  8388608 bytes read: OK
>> Kernel image @ 0x82000000 [ 0x000000 - 0x2c4fd8 ]
>> ## Flattened Device Tree blob at 88000000
>>    Booting using the fdt blob at 0x88000000
>>    Loading Device Tree to 8ef1b000, end 8ef27614 ... OK
>>
>> Starting kernel ...
>>
>> [    0.000000] Booting Linux on physical CPU 0x0
>> [    0.000000] Initializing cgroup subsys cpu
>>
>> ....... lots of listing and then ......
>> [    1.172458] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>> [    1.179257] nand: Micron MT29F2G08ABAEAWP
>> [    1.183469] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048,
>> OOB size: 64
>> [    1.191491] nand: using OMAP_ECC_BCH8_CODE_HW ECC scheme
>> [    1.197164] 10 ofpart partitions found on MTD device 8000000.nand
>> [    1.203607] Creating 10 MTD partitions on "8000000.nand":
>> [    1.209285] 0x000000000000-0x000000020000 : "NAND.SPL"
>> [    1.216261] 0x000000020000-0x000000040000 : "NAND.SPL.backup1"
>> [    1.223834] 0x000000040000-0x000000060000 : "NAND.SPL.backup2"
>> [    1.231275] 0x000000060000-0x000000080000 : "NAND.SPL.backup3"
>> [    1.238794] 0x000000080000-0x0000000c0000 : "NAND.u-boot-spl-os"
>> [    1.246571] 0x0000000c0000-0x0000001c0000 : "NAND.u-boot"
>> [    1.254316] 0x0000001c0000-0x0000001e0000 : "NAND.u-boot-env"
>> [    1.261612] 0x0000001e0000-0x000000200000 : "NAND.u-boot-env.backup1"
>> [    1.269653] 0x000000200000-0x000000a00000 : "NAND.kernel"
>> [    1.283112] 0x000000a00000-0x000010000000 : "NAND.file-system"
>> [    1.520856] tps65217 0-0024: TPS65217 ID 0xe version 1.2
>> [    1.526486] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
>> [    1.533461] omap_i2c 4802a000.i2c: bus 1 rev0.11 at 400 kHz
>> [    1.539830] ubi0: attaching mtd9
>> [    1.543810] ubi0 error: validate_ec_hdr: bad VID header offset 512,
>> expected 2048
>> [    1.551672] ubi0 error: validate_ec_hdr: bad EC header
>> [    1.557063] Erase counter header dump:
>> [    1.560998]  magic          0x55424923
>> [    1.564930]  version        1
>> [    1.568041]  ec             1
>> [    1.571151]  vid_hdr_offset 512
>> [    1.574444]  data_offset    2048
>> [    1.577831]  image_seq      1630296601
>> [    1.581762]  hdr_crc        0x988c84d
>> [    1.585600] erase counter header hexdump:
>> [    1.589844] CPU: 0 PID: 1 Comm: swapper Not tainted
>> 4.4.39-rt49-g9d47072444 #2
>> [    1.597427] Hardware name: Generic AM33XX (Flattened Device Tree)
>> [    1.603824] Backtrace:
>> [    1.606422] [<c0013380>] (dump_backtrace) from [<c001357c>]
>> (show_stack+0x18/0x1c)
>> [    1.614370]  r7:00000000 r6:00000001 r5:cf027000 r4:cf419000
>> [    1.620337] [<c0013564>] (show_stack) from [<c0295998>]
>> (dump_stack+0x24/0x28)
>> [    1.627937] [<c0295974>] (dump_stack) from [<c03c1e24>]
>> (validate_ec_hdr+0xc0/0x12c)
>> [    1.636077] [<c03c1d64>] (validate_ec_hdr) from [<c03c2a6c>]
>> (ubi_io_read_ec_hdr+0x168/0x218)
>> [    1.645047]  r7:cf027000 r6:55424923 r5:cf419000 r4:00000000
>> [    1.651012] [<c03c2904>] (ubi_io_read_ec_hdr) from [<c03c75d0>]
>> (ubi_attach+0x164/0x14b8)
>> [    1.659607]  r10:cf3e3c80 r9:c07d5b1c r8:00000000 r7:cf027000
>> r6:00000000 r5:cf027000
>> [    1.667854]  r4:00000000
>> [    1.670519] [<c03c746c>] (ubi_attach) from [<c03bc768>]
>> (ubi_attach_mtd_dev+0x6d0/0xc50)
>> [    1.679011]  r10:00000800 r9:00000840 r8:cf3d8400 r7:cf027000
>> r6:00000000 r5:cf3d8400
>> [    1.687256]  r4:fffff800
>> [    1.689923] [<c03bc098>] (ubi_attach_mtd_dev) from [<c0743300>]
>> (ubi_init+0x1c8/0x250)
>> [    1.698240]  r10:0000006e r9:c079d600 r8:00000000 r7:c0756734
>> r6:c0756738 r5:cf3d8400
>> [    1.706487]  r4:00000000
>> [    1.709153] [<c0743138>] (ubi_init) from [<c00096a4>]
>> (do_one_initcall+0x98/0x1e0)
>> [    1.717099]  r8:00000000 r7:cf3e6a80 r6:c07623a0 r5:c0743138
>> r4:c07623a0
>> [    1.724169] [<c000960c>] (do_one_initcall) from [<c0722e84>]
>> (kernel_init_freeable+0x138/0x1dc)
>> [    1.733301]  r8:c07225ec r7:c0751838 r6:c0751834 r5:c079d600
>> r4:00000007
>> [    1.740386] [<c0722d4c>] (kernel_init_freeable) from [<c053948c>]
>> (kernel_init+0x10/0xf0)
>> [    1.748973]  r10:00000000 r9:00000000 r8:00000000 r7:00000000
>> r6:00000000 r5:c053947c
>> [    1.757220]  r4:00000000
>> [    1.759887] [<c053947c>] (kernel_init) from [<c000f980>]
>> (ret_from_fork+0x14/0x34)
>> [    1.767835]  r5:c053947c r4:00000000
>> [    1.771596] ubi0 error: ubi_io_read_ec_hdr: validation failed for PEB 0
>> [    1.778549] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd9,
>> error -22
>> [    1.785991] UBI error: cannot attach mtd9
>> [    1.790295] hctosys: unable to open rtc device (rtc0)
>> [    1.801005] UBIFS error (pid: 1): cannot open "ubi0:rootfs", error
>> -19VFS: Cannot open root device "ubi0:rootfs" or unknown-block(0,0): error
>> -19
>> [    1.814905] Please append a correct "root=" boot option; here are the
>> available partitions:
>> [    1.823726] 1f00             128 mtdblock0  (driver?)
>> [    1.829039] 1f01             128 mtdblock1  (driver?)
>> [    1.834351] 1f02             128 mtdblock2  (driver?)
>> [    1.839661] 1f03             128 mtdblock3  (driver?)
>> [    1.844974] 1f04             256 mtdblock4  (driver?)
>> [    1.850282] 1f05            1024 mtdblock5  (driver?)
>> [    1.855606] 1f06             128 mtdblock6  (driver?)
>> [    1.860915] 1f07             128 mtdblock7  (driver?)
>> [    1.866245] 1f08            8192 mtdblock8  (driver?)
>> [    1.871553] 1f09          251904 mtdblock9  (driver?)
>> [    1.876884] Kernel panic - not syncing: VFS: Unable to mount root fs
>> on unknown-block(0,0)
>>
>> Now I'm terrified!!
>> This reminds me for years back when I tried to boot from 3.x kernel
>> written ubifs partition from u-boot.
>> I never managed in that. I could touch ubifs filesystem from Linux or
>> u-boot, but if I did so from Linux, I could not touch it from u-boot
>> anymore and vice versa.
>> Later on it worked with newer u-boot.
>>
>> Procedure I did now from SD card booted linux 4.4 for writing rootfs to
>> mtdblock9 is listed below:
>> -------------------------------------------------
>>     flash_erase /dev/mtd9 0 0 > /dev/null
>>     ubiformat /dev/mtd9 > /dev/null
>>
>>     ubiattach -p /dev/mtd9 > /dev/null
>>     ubimkvol -N rootfs -m /dev/ubi0 > /dev/null
>>     mkdir -p /mnt/flash
>>     mount -t ubifs ubi0:rootfs /mnt/flash > /dev/null
>>
>>     tar -C /mnt/flash -xf rootfs.tgz > /dev/null
>>     sync
>>     umount /mnt/flash > /dev/null
>>     ubidetach -p /dev/mtd9 > /dev/null
>> -------------------------------------------------
>> Did I do anything wrong in creating that? It is quite accessible from
>> Linux.
>> Do anyone know how to fix this problem? Have nand boot been tested with
>> am335x_evm board? I'm somewhat worried about that as there was that nand0
>> device in boot_targets...
>>
>> Thanks,
>> Matti
>>
>>
>


More information about the U-Boot mailing list