My question is why?
And the answer is NO, DO NOT USE THE MTD utility as it does not handle bad blocks at all.
I just dont see why, ubi utils are here for a reason
It is possible to create an Xiaomi HDR1 image, which can be flashed using the WEB interface of the stock firmware.
Stock firmwares 1.0.17/1.1.19 has a vulnerability in the mkxqimage utility that can be exploited to write data via the mtd write XXXX command.
Thats fine, but you really have to pray there are no bad blocks.
mts util is not to be used on NAND
I am investigating if speedbin fuse is implemented on IPQ807x so NVMEM cpufreq could be used to not have different OPP points.
Can you please check the bootlog for these:
[ 0.958335] qcom,cpr4-apss-regulator b018000.cpr4-ctrl: CPR valid fuse count: 4
[ 0.958625] cpr4_ipq807x_apss_read_fuse_data: apc_corner: speed bin = 0
[ 0.964491] cpr4_ipq807x_apss_read_fuse_data: apc_corner: CPR fusing revision = 1
[ 0.971078] cpr4_ipq807x_apss_read_fuse_data: apc_corner: CPR misc fuse value = 0
[ 0.978738] cpr4_ipq807x_apss_read_fuse_data: apc_corner: Voltage boost fuse config = 0 boost = disable
And report back with the CPU model used and those values.
Thanks
ipq8070A (cax1800)
[ 1.040626] qcom,cpr4-apss-regulator b018000.cpr4-ctrl: CPR valid fuse count: 4
[ 1.040941] cpr4_ipq807x_apss_read_fuse_data: apc_corner: speed bin = 0
[ 1.046781] cpr4_ipq807x_apss_read_fuse_data: apc_corner: CPR fusing revision = 1
[ 1.053350] cpr4_ipq807x_apss_read_fuse_data: apc_corner: CPR misc fuse value = 0
[ 1.061204] cpr4_ipq807x_apss_read_fuse_data: apc_corner: Voltage boost fuse config = 0 boost = disable
ipq8072A (Dynalink)
[ 0.885659] qcom,cpr4-apss-regulator b018000.cpr4-ctrl: CPR valid fuse count: 4
[ 0.885972] cpr4_ipq807x_apss_read_fuse_data: apc_corner: speed bin = 0
[ 0.891997] cpr4_ipq807x_apss_read_fuse_data: apc_corner: CPR fusing revision = 1
[ 0.898393] cpr4_ipq807x_apss_read_fuse_data: apc_corner: CPR misc fuse value = 0
[ 0.906046] cpr4_ipq807x_apss_read_fuse_data: apc_corner: Voltage boost fuse config = 0 boost = disable
ipq8072A (qnap)
[ 0.967676] qcom,cpr4-apss-regulator b018000.cpr4-ctrl: CPR valid fuse count: 4
[ 0.967967] cpr4_ipq807x_apss_read_fuse_data: apc_corner: speed bin = 0
[ 0.973835] cpr4_ipq807x_apss_read_fuse_data: apc_corner: CPR fusing revision = 1
[ 0.980409] cpr4_ipq807x_apss_read_fuse_data: apc_corner: CPR misc fuse value = 0
[ 0.988073] cpr4_ipq807x_apss_read_fuse_data: apc_corner: Voltage boost fuse config = 0 boost = disable
AX3600 (IPQ8071A):
[ 1.332006] qcom,cpr4-apss-regulator b018000.cpr4-ctrl: CPR valid fuse count: 4
[ 1.332319] cpr4_ipq807x_apss_read_fuse_data: apc_corner: speed bin = 0
[ 1.338133] cpr4_ipq807x_apss_read_fuse_data: apc_corner: CPR fusing revision = 1
[ 1.344754] cpr4_ipq807x_apss_read_fuse_data: apc_corner: CPR misc fuse value = 0
[ 1.352402] cpr4_ipq807x_apss_read_fuse_data: apc_corner: Voltage boost fuse config = 0 boost = disable
Thanks, so they messed it up and put the same values on all CPU-s.
Shame, they actually did it correctly on IPQ60xx so you can use the same OPP table
ath11k mailing list has become very quiet in recent months compared to the time before. Do you think QCA is more or less done working on ath11k?
I dont really know, there were some patches recently but naturally less since they are working on ath12k.
Anyway, finally redid the whole kernel tree for OpenWrt based on upstreamed stuff and pushed it.
It allowed getting rid of address/size-cells and interrupt-parent in each device DTS as well.
So, I would really appreciate testing so any regressions could pop-up.
4 Likes
Looks good after a short test on the Dynalink.
I only spotted that in the kernel log:
[ 0.717511] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xaa
[ 0.719363] nand: Micron MT29F2G08ABBGAH4
[ 0.725980] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 128
[ 0.730083] Error reading partition table header
[ 0.737361] Error reading partition table header
Haven't seen this before (kenel 5.15.62), but nand is still working fine.
A few ms later:
[ 1.011448] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xaa
[ 1.026814] nand: Micron MT29F2G08ABBGAH4
[ 1.033215] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 128
[ 1.037447] 25 qcomsmem partitions found on MTD device qcom_nand.0
[ 1.044593] Creating 25 MTD partitions on "qcom_nand.0":
Message comes from smem parser:
drivers/mtd/parsers/qcomsmempart.c: pr_err("Error reading partition table header\n");
With kernel 5.15.62 it looked like that:
dmesg|grep nand
[ 0.719050] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xaa
[ 0.720871] nand: Micron MT29F2G08ABBGAH4
[ 0.727478] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 128
[ 1.004124] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xaa
[ 1.019520] nand: Micron MT29F2G08ABBGAH4
[ 1.025930] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 128
[ 1.030181] 25 qcomsmem partitions found on MTD device qcom_nand.0
[ 1.037322] Creating 25 MTD partitions on "qcom_nand.0":
Same order (and repeating lines), but without the error message.
No errors in AX3600 or QNAP logs found. (false statement, error vs. Error)
In Ax3600 (latest build 28-1832) I have the same kernel error msg. that kirdes reported:
[ 1.166552] nand: device found, Manufacturer ID: 0xc8, Chip ID: 0xaa
[ 1.168109] nand: ESMT GD9FS2G8F2A
[ 1.174715] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 128
[ 1.178140] Error reading partition table header
[ 1.185489] Error reading partition table header
...
[ 1.459533] nand: device found, Manufacturer ID: 0xc8, Chip ID: 0xaa
[ 1.474605] nand: ESMT GD9FS2G8F2A
[ 1.481008] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 128
[ 1.484515] 16 qcomsmem partitions found on MTD device qcom_nand.0
I can confirn AX3600 and also QNAP , Error vs error. My bad
Probe defer thing? And a log wrongly printed? Need to check the driver
Yeah, its probe defferal, I forgot to include a backport that was previously included and which fixes it.
Will add it tommorow as its pointless to error out if probe defferal is requested.
1 Like
Why they use pr_info instead of dev_ stuff and why the don't use dev_err_probe is against any of my logic... But whatever ahahahah (sometimes I wonder how some code gets accepted)
on this latest build I have now /sys/devices/system/cpu/cpufreq empty and nothing under each of the cpus! does anyone have this issue ? on both the qnap and dynalink thank you
/sys/devices/system/cpu/cpu0# ls -ltr
drwxr-xr-x 2 root root 0 Aug 28 17:41 topology
drwxr-xr-x 5 root root 0 Aug 28 17:41 cache
-rw-r--r-- 1 root root 4096 Aug 29 09:32 uevent
lrwxrwxrwx 1 root root 0 Aug 29 09:32 subsystem -> ../../../../bus/cpu
drwxr-xr-x 3 root root 0 Aug 29 09:32 regs
drwxr-xr-x 2 root root 0 Aug 29 09:32 power
lrwxrwxrwx 1 root root 0 Aug 29 09:32 of_node -> ../../../../firmware/devicetree/base/cpus/cpu@0
-r--r--r-- 1 root root 4096 Aug 29 09:32 cpu_capacity
the other observation related to the qnap is that wifi doesn't start automatically at boot - I need to issue wifi up
I dont have an idea what you did, but cpufreq works as well as WLAN.
To made sure, I even flashed the image from CI.
SMEM parser patch has been backported.
thx ... i did distclean and cpufreq is now working on both devices