Adding Support for Verizon CR1000A

maybe, can you try parted to fix those errors?

Also if the partition table is ok in theory there is also a way to skip the loop device entirely. An ipq806x device makes use of it so there should be some examples there. Maybe the problem is just corrupted partition due to some tests?

i think i found the problem... but can't fix it?

[   14.068373] mount_root: overlay filesystem in /dev/loop0 has not been formatted yet
[   14.073873] mount_root: no usable overlay filesystem found, using tmpfs overlay
[   14.080733] overlayfs: null uuid detected in lower fs '/', falling back to xino=off,index=off,nfs_export=off.
sh: mkfs.f2fs: not found
^^ this 

it looks similar to but not exactly as i have all other mkfs.* but not mkfs.f2fs?

root@OpenWrt:/# mkf
mkfifo     mkfs.ext2  mkfs.ext3  mkfs.ext4

i've added f2fs-tools to the list for this device but it's still missing?

DEVICE_PACKAGES := ipq-wifi-verizon_cr1000a e2fsprogs kmod-fs-ext4 losetup kmod-ath11k-pci mdio-tools ethtool-full kmod-spi-dev spidev-test kmod-sfp libubox libubus parted f2fs-tools

Update: checked out/built from scratch - same issue :expressionless:

The loop device is already ext4 formated, I guess the f2fs logic is just a fallback.
I also think this is a problem regarding a broken partition table.

What happens, when you setup the loop device manually?

losetup -o 10685440 /dev/loop0 /dev/mmcblk0p20

The offset "106685440" was the value from your last sysupgrade, but that may need adjusted if you build a new sysupgrade file

offset=$(tar xf $tar_file ${board_dir}/root -O | wc -c)

And mount /dev/loop0 afterwards?

BTW, how large is the rootfs partition?

root@OpenWrt:/# losetup -o 10788864 /dev/loop0 /dev/mmcblk0p20
[  112.237225] loop0: detected capacity change from 0 to 286428


root@OpenWrt:/# mount /dev/loop0 
mount: can't find /dev/loop0 in /etc/fstab

fstab is empty

root@OpenWrt:/# cat etc/fstab 
# <file system> <mount point> <type> <options> <dump> <pass>

and this is the partitions on mmc as parted sees them. It sees that GPT is not using all available space ( that's what it complains about at boot time, i think)

Using /dev/mmcblk0
(parted) print                                                            
Warning: Not all of the space available to /dev/mmcblk0 appears to be used, you
can fix the GPT to use all of the space (an extra 98304 blocks) or continue with
the current setting? 
Fix/Ignore? I                                                             
Model: MMC 004GA0 (sd/mmc)
Disk /dev/mmcblk0: 3959MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name           Flags
 1      17.4kB  542kB   524kB                0:SBL1
 2      542kB   804kB   262kB                0:BOOTCONFIG
 3      804kB   1066kB  262kB                0:BOOTCONFIG1
 4      1066kB  2639kB  1573kB               0:QSEE
 5      2639kB  4212kB  1573kB               0:QSEE_1
 6      4212kB  4474kB  262kB                0:DEVCFG
 7      4474kB  4736kB  262kB                0:DEVCFG_1
 8      4736kB  4998kB  262kB                0:APDP
 9      4998kB  5260kB  262kB                0:APDP_1
10      5260kB  5522kB  262kB                0:RPM
11      5522kB  5785kB  262kB                0:RPM_1
12      5785kB  6047kB  262kB                0:CDT
13      6047kB  6309kB  262kB                0:CDT_1
14      6309kB  6571kB  262kB                0:APPSBLENV
15      6571kB  7357kB  786kB                0:APPSBL
16      7357kB  8144kB  786kB                0:APPSBL_1
17      8144kB  8406kB  262kB                0:ART
18      8406kB  29.4MB  21.0MB               0:HLOS
19      29.4MB  50.3MB  21.0MB               0:HLOS_1
20      50.3MB  208MB   157MB                rootfs
21      208MB   241MB   33.6MB               0:WIFIFW
22      241MB   399MB   157MB                rootfs_1
23      399MB   432MB   33.6MB               0:WIFIFW_1
24      432MB   566MB   134MB                rootfs_data
25      566MB   567MB   524kB                0:ETHPHYFW
26      567MB   569MB   2097kB               certificate
27      569MB   571MB   2097kB               oops
28      571MB   3867MB  3296MB               data
29      3867MB  3869MB  2097kB               backup_bd


the script also fails on


cp: can't stat '': No such file or directory

because of -n option?

Update: yes that gpt discrepancy is just a warning if there is empty space left on the device. I suspect it's just overprovisioning.

Does this device need this?

you need to mount the device manually, there is no fstab entry.


mount -t ext4 /dev/loop0 /tmp/loopdevice

for example

hmm, i was expecting it to be there for auto mounting... anyway

root@OpenWrt:/# mkdir /tmp/new_root
root@OpenWrt:/# mount -t ext4 /dev/loop0 /tmp/new_root
[49966.953572] I/O error, dev loop0, sector 2 op 0x0:(READ) flags 0x1000 phys_seg 1 prio class 2
[49966.953630] EXT4-fs (loop0): unable to read superblock
mount: mounting /dev/loop0 on /tmp/new_root failed: I/O error

I've also noticed that when loading initramfs kernel the u-boot is doing extra things, like initializing AQR phy (takes a few things). After that user-space firmware uploading is not needed, but if executed takes ~10-20 secs. If loading directly into flashed openwrt, this initialization is not happening AND firmware uploading takes 2+ min :(.

@robimarko is there a way to trigger that u-boot initialization? (without using aq_load_fw, as that requires firmware written into partition, and I'd rather prefer to make it work with minimal changes)

If AQR-s dont have SPI-NOR attached to them with FW then you must load it either via U-boot or from userspace.

You cant avoid aq_load_fw if you want to do it via U-boot.

I have been planning to add FW loading to the AQR PHY driver in the kernel for a while so its easier to load the FW from some kind of storage as its not redistributable but it would avoid having to change U-boot bootcmd

so, I've renamed existing GPT partition too but still getting the same result. I'm not even sure why does it detects changes? twice?

[   14.031540] loop0: detected capacity change from 0 to 307500
[   14.077562] loop0: detected capacity change from 307500 to 285356
[   14.078433] mount_root: overlay filesystem in /dev/loop0 has not been formatted yet
[   24.385132] loop0: detected capacity change from 0 to 307500
[   24.447983] loop0: detected capacity change from 307500 to 285356
[   24.450383] MTD: Attempt to mount non-MTD device "/dev/loop0"

Partition renaming doesn't help here.

The only thing you can try, is to play with the pad-to option in the image recipe:

For the QNAP and the Zyxel the only working value is 64k, but maybe your eMMC needs a different padding?

@robimarko trying to put AQR firmware to

25      566MB   567MB   524kB                0:ETHPHYFW

via dd of=/dev/mmcblk0p25 if=/mnt/usb/aqr-v5.6.7.cld

but still getting

IPQ807x# aq_load_fw 8

MMC read: dev # 0, block # 1106254, count 1024 ... 1024 blocks read: OK
bad magic on ETHPHYFW partition

do i need to do anything extra there? the same firmware loads nicely via userspace tool

folks here use mtd device but it should not matter?;a=commit;h=bd17683261e1dde1fdd4223745852de1ce8cfc89

i guess i have a success here (after adding the package finally)?

root@OpenWrt:/# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                11.3M     11.3M         0 100% /rom
tmpfs                   936.4M    104.0K    936.3M   0% /tmp
/dev/loop0              137.1M     43.6M     93.5M  32% /overlay
overlayfs:/overlay      137.1M     43.6M     93.5M  32% /
tmpfs                   512.0K         0    512.0K   0% /dev

You need to add a proper u-boot header via QCA u-boot tools:

What package did you add?


~/openwrt/openwrt$ cat .config | grep f2fs
# CONFIG_PACKAGE_libf2fs-selinux is not set
# CONFIG_PACKAGE_f2fs-tools-selinux is not set
# CONFIG_PACKAGE_f2fsck-selinux is not set
# CONFIG_PACKAGE_mkf2fs-selinux is not set

Thanks for the hint. Will try tonight. Is there any newer firmware available? Also, where would the uboot take firmware from? There is some SPI flash but it's not jedec compatible...