'bootipq' and 'bootm' difference in uboot (was: Sysupgrade from initramfs on IPQ4019)

There's a config file I'm missing somewhere that bootipq is using.

If I try running the stock 'bootipq' against the new kernel/rootfs, it bails out like this:
(IPQ40xx) # bootipq
Saving Environment to NAND...
Erasing Nand...
Erasing at 0xef000 -- 100% complete.
Writing to Nand... done
Boot count=1
Creating 1 MTD partitions on "nand1":
0x000000000000-0x000003800000 : "mtd=0"
UBI: attaching mtd2 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 126976 bytes
UBI: smallest flash I/O unit: 2048
UBI: VID header offset: 2048 (aligned 2048)
UBI: data offset: 4096
UBI: attached mtd2 to ubi0
UBI: MTD device name: "mtd=0"
UBI: MTD device size: 56 MiB
UBI: number of good PEBs: 448
UBI: number of bad PEBs: 0
UBI: max. allowed volumes: 128
UBI: wear-leveling threshold: 4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 4
UBI: available PEBs: 16
UBI: total number of reserved PEBs: 432
UBI: number of PEBs reserved for bad PEB handling: 4
UBI: max/mean erase counter: 3/1
Read 0 bytes from volume kernel to 84000000
No size specified -> Using max size (2920448)
Config not availabale
bootipq failed!!
resetting ...

That config file crops up when I try booting the recovery firmware:
(IPQ40xx) # bootipq
Saving Environment to NAND...
Erasing Nand...
Erasing at 0xef000 -- 100% complete.
Writing to Nand... done
Boot count=2
Creating 1 MTD partitions on "nand1":
0x000003800000-0x000007000000 : "mtd=0"
UBI: attaching mtd2 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 126976 bytes
UBI: smallest flash I/O unit: 2048
UBI: VID header offset: 2048 (aligned 2048)
UBI: data offset: 4096
UBI: attached mtd2 to ubi0
UBI: MTD device name: "mtd=0"
UBI: MTD device size: 56 MiB
UBI: number of good PEBs: 448
UBI: number of bad PEBs: 0
UBI: max. allowed volumes: 128
UBI: wear-leveling threshold: 4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 2
UBI: available PEBs: 210
UBI: total number of reserved PEBs: 238
UBI: number of PEBs reserved for bad PEB handling: 4
UBI: max/mean erase counter: 1/0
Read 0 bytes from volume kernel to 84000000
No size specified -> Using max size (3682304)
Booting kernel from FIT Image at 84000000 ...
Using 'config@5' configuration
Trying 'kernel@1' kernel subimage
Description: ARM OpenWrt Linux-3.14.43
Type: Kernel Image
Compression: gzip compressed
Data Start: 0x840000e4
Data Size: 3280614 Bytes = 3.1 MiB
Architecture: ARM
OS: Linux
Load Address: 0x80208000
Entry Point: 0x80208000
Hash algo: crc32
Hash value: d45cb75b
Hash algo: sha1
Hash value: 7d0f77af6009e920da10a169d0ed1b62793326d2
Verifying Hash Integrity ... crc32+ sha1+ OK
Flattened Device Tree from FIT Image at 84000000
Using 'config@5' configuration
Trying 'fdt@5' FDT blob subimage
Description: ARM OpenWrt qcom-ipq40xx-ap.dkxx device tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x84345b90
Data Size: 32664 Bytes = 31.9 KiB
Architecture: ARM
Hash algo: crc32
Hash value: 12ad0337
Hash algo: sha1
Hash value: a0f533bcbdc5eea1bfd8afe488d5c6e33617d5be
Verifying Hash Integrity ... crc32+ sha1+ OK
Booting using the fdt blob at 0x84345b90
Uncompressing Kernel Image ... OK
Loading Device Tree to 86ff5000, end 86ffff97 ... OK
Using machid 0x8010100 from environment
Starting kernel ...

That's the part I'm missing - that 'config@5' part. If I try manually booting the recovery firmware, it fails because it's using the wrong config file:
(IPQ40xx) # ubi read 0x84000000 kernel
Read 0 bytes from volume kernel to 84000000
No size specified -> Using max size (2920448)
(IPQ40xx) # bootm
Booting kernel from FIT Image at 84000000 ...
Using 'config@1' configuration
Trying 'kernel@1' kernel subimage
Description: ARM OpenWrt Linux-4.9.86
Type: Kernel Image
Compression: gzip compressed
Data Start: 0x840000e4
Data Size: 2763349 Bytes = 2.6 MiB
Architecture: ARM
OS: Linux
Load Address: 0x80208000
Entry Point: 0x80208000
Hash algo: crc32
Hash value: 2250ad7e
Hash algo: sha1
Hash value: 422cdbe798cc33a8f5a341e6526b152d2f870cc9
Verifying Hash Integrity ... crc32+ sha1+ OK
Flattened Device Tree from FIT Image at 84000000
Using 'config@1' configuration
Trying 'fdt@1' FDT blob subimage
Description: ARM OpenWrt netgear_wac510 device tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x842a2c74
Data Size: 34034 Bytes = 33.2 KiB
Architecture: ARM
Hash algo: crc32
Hash value: c9cee5a1
Hash algo: sha1
Hash value: 56fcd1b6cbee8e6f9b61d6c4bacea03b3cd5b5c5
Verifying Hash Integrity ... crc32+ sha1+ OK
Booting using the fdt blob at 0x842a2c74
Uncompressing Kernel Image ... OK
Loading Device Tree to 86ff4000, end 86fff4f1 ... OK
Using machid 0x8010100 from environment
Starting kernel ...

More digging...

Tim

Config file is loaded from FIT configuration partition

Aha.... So, the difference between the stock recovery firmware booting or not are those 'config' lines. This is when the stock recovery firmware works:
Booting kernel from FIT Image at 84000000 ...
Using 'config@5' configuration
Trying 'kernel@1' kernel subimage
..........
Flattened Device Tree from FIT Image at 84000000
Using 'config@5' configuration
Trying 'fdt@5' FDT blob subimage

When it doesn't, those '@5's are '@1's instead.

After reading up on this, am I right in thinking there's different versions of the DTS in the same file? Does that mean the reason the kernel can't find the UBI rootfs is because it needs to be defined in the DTS somehow?

I've tried bootm 0x84000000#config@5 on the stock firmware and it just errors:
(IPQ40xx) # bootm 0x84000000#config@5
Booting kernel from FIT Image at 84000000 ...
ERROR: can't get kernel image!
(IPQ40xx) #

So I'm still not doing something right...

Tim

1 Like

OpenWRT uses config@1 so you gotta change mkits.sh

OK, so there's different 'profiles' stored in the DTS...

When I go through the Netgear firmware update script, it doesn't touch the kernel. It only upgrades the rootfs. The original DTB I extracted at the beginning of this came from the kernel in the firmware update which is not used on the device itself.

I wonder if the kernel on the device itself is different from the one provided in the firmware updates, in that it has these multiple DTS profiles in it. That would explain why booting it with config@1 fails, but booting it with config@5 works.

I'm going to try extracting the live kernel from the device itself (not the firmware update one) and see if I can get the DTS with all the profiles in it.

Tim

I think I'm getting somewhere.......

I think the NAND chip isn't supported by the kernel properly, either because of the wrong driver or because the DTS is missing an entry.

In uboot, the MTD partitions are:

(IPQ40xx) # mtdparts

device nand1 <mtd0>, # parts = 4
 #: name                size            offset          mask_flags
 0: rootfs              0x03800000      0x00000000      0
 1: rootfs_1            0x03800000      0x03800000      0
 2: var_config          0x00f00000      0x07000000      0
 3: Oops_log            0x000c0000      0x07f00000      0

The two partitions 'rootfs' and 'rootfs_1' are UBI partitions with the 'kernel' volumes in them. 'rootfs' is the primary partition and 'rootfs_1' is the backup factory firmware.

When I boot into the initramfs image, I can only see 'rootfs', not 'rootfs_1' or the other partitions. As such, I can only extract the kernel volume from the primary partition, which is the pure OpenWrt one.

I can't get to the 'rootfs_1' partition. If I can't get to it, perhaps the kernel can't see the whole device properly and as such cannot mount the UBI volumes within that contain the proper rootfs?

What do you think? Am I getting things confused?

Tim

NAND chip is supported properly as it is exactly the same one that is used on 8devices Jalapeno and it runs just fine without any issues