Banana Pi BPI-R64: Trying to bump OpenWrt Kernel to 6.1

Banana Pi Router design BPI-R64(MT7622)
1

Hey, I am currently trying to port the 6.1 to the OpenWrt Banana Pi R64 Image:

However, when trying to boot it, it fails with:

[    1.055565] ------------[ cut here ]------------
[    1.060204] Kernel BUG at regulator_check_voltage+0xb0/0xf0 [verbose debug info unavailable]
[    1.062418] mtk-pcie 1a143000.pcie: host bridge /pcie@1a143000 ranges:
[    1.068656] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
[    1.075248] mtk-pcie 1a143000.pcie: Parsing ranges property...
[    1.081257] Modules linked in:
[    1.081264] CPU: 1 PID: 328 Comm: kworker/1:7 Tainted: G S                 6.1-rc2 #0
[    1.087088] mtk-pcie 1a143000.pcie:      MEM 0x0020000000..0x0027ffffff -> 0x0020000000
[    1.090126] Hardware name: Bananapi BPI-R64 (DT)
[    1.110541] Workqueue: events dbs_work_handler
[    1.114988] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    1.121944] pc : regulator_check_voltage+0xb0/0xf0
[    1.126728] lr : regulator_set_voltage_unlocked+0x88/0x110
[    1.129638] mmc1: host does not support reading read-only switch, assuming write-enable
[    1.132207] sp : ffffffc00956bb30
[    1.132209] x29: ffffffc00956bb30 x28: ffffff8000efb400 x27: 0000000000000024
[    1.132219] x26: 00000000001312d0 x25: 0000000000118c30 x24: 00000000001312d0
[    1.132227] x23: 0000000000149970
[    1.146036] mmc1: new high speed SDHC card at address e624
[    1.150642]  x22: ffffff800038f800
[    1.159192] mmcblk1: mmc1:e624 SL16G 14.8 GiB 
[    1.161068]  x21: ffffff8000efb100
[    1.161072] x20: 00000000001312d0
[    1.175424] GPT:partition_entry_array_crc32 values don't match: 0xa0b5ce6d != 0xab54d286
[    1.177757]  x19: 0000000000000000 x18: 00000000799b2550
[    1.181067] GPT:Primary header thinks Alt. header is not at the end of the disk.
[    1.189143] x17: 0000000000000003 x16: 0000000000000001 x15: 0000000000000000
[    1.189151] x14: 0000000000000000 x13: 0000000000000146 x12: 00000000fa83b2da
[    1.189159] x11: 000000000000013d x10: 0000000000000850
[    1.194472] GPT:305184 != 31116287
[    1.201842]  x9 : ffffffc00956b910
[    1.201846] x8 : ffffff8000b9edf0 x7 : 0000000000000001
[    1.208970] GPT:Alternate GPT header not at the end of the disk.
[    1.216092]  x6 : 00000000001312d0
[    1.216095] x5 : 0000000000118c30 x4 : 0000000000000000 x3 : 0000000000000000
[    1.216103] x2 : ffffffc00956bb68 x1 : ffffffc00956bb6c
[    1.221321] GPT:305184 != 31116287
[    1.224706]  x0 : ffffff800038f800
[    1.228095] GPT: Use GNU Parted to correct GPT errors.
[    1.233307] 
[    1.233309] Call trace:
[    1.233312]  regulator_check_voltage+0xb0/0xf0
[    1.242680] FIT: Selected configuration: "config-mt7622-bananapi-bpi-r64-pcie1" (OpenWrt bananapi_bpi-r64 with mt7622-bananapi-bpi-r64-pcie1)
[    1.242694]  regulator_set_voltage+0x3c/0x64
[    1.249831] FIT:           kernel sub-image 0x00001000..0x0052fd0a "kernel-1" (ARM64 OpenWrt Linux-6.1-rc2) 
[    1.255030]  mtk_cpufreq_voltage_tracking+0x11c/0x26c
[    1.255039]  mtk_cpufreq_set_target+0x1c4/0x350
[    1.258444] FIT:          flat_dt sub-image 0x00530000..0x005380c5 "fdt-1" (ARM64 OpenWrt bananapi_bpi-r64 device tree blob) 
[    1.261820]  __cpufreq_driver_target+0x2f4/0x674
[    1.261826]  od_dbs_update+0xb8/0x19c
[    1.266969] FIT:          flat_dt sub-image 0x00539000..0x0053911a "fdt-mt7622-bananapi-bpi-r64-pcie1" (ARM64 OpenWrt bananapi_bpi-r64 device tree overlay mt7622-bananapi-bpi-r64-pcie1) 
[    1.268431]  dbs_work_handler+0x3c/0x7c
[    1.270883] FIT:          flat_dt sub-image 0x0053a000..0x0053a20f "fdt-mt7622-bananapi-bpi-r64-sata" (ARM64 OpenWrt bananapi_bpi-r64 device tree overlay mt7622-bananapi-bpi-r64-sata) 
[    1.275297]  process_one_work+0x200/0x3a0
[    1.287998] FIT:       filesystem sub-image 0x0053b000..0x00859fff "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r64 rootfs) 
[    1.292237]  worker_thread+0x170/0x4c0
[    1.292244]  kthread+0xd4/0xe0
[    1.302066] FIT: selecting configured loadable "rootfs-1" to be root filesystem
[    1.307092]  ret_from_fork+0x10/0x20
[    1.311631]  mmcblk1: p1 p2 p3 p4 p5 p6 p65(rootfs-1) p66(rootfs_data) p128
[    1.322903] Code: 6b04001f 54fffe6b 2a0003e4 17fffff3 (d4210000) 
[    1.413322] ---[ end trace 0000000000000000 ]---

The complete log can be found here:

Anyone any idea?

2

I see on gist you have found the breaking commit :slight_smile:

You should send a bug report to mailinglist (scripts/get_maintainer.pl)+ author of this commit with board+stacktrace and pointing to the commit.

3

Already did that. :slight_smile: http://lists.infradead.org/pipermail/linux-arm-kernel/2022-November/788416.html

4

Yes i saw it on mailinglist,but seems no answer yet to pure mainline test as far as i see.

5

Have you got any response from patch author? I guess it is still broken…wonder why it affects only r64,so it seems to some soc-specific code which triggers this.

Could you try to find position where regulator_check_voltage is called and which values are passed?

It looks like it is triggered while pcie-probe (before hostbridge is created).

Imho mtk regulators are only dummy ones (fixed to a software value and not adjustable in hardware). These can have only value defined in dts or NULL (e.g. if disabled)

Maybe it is similar to this:

https://discuss.96boards.org/t/kernel-panic-on-drivers-regulator-core-c/10660

As far as i see bug_on is called when min voltage is larger than maximum. You could try printing these values together with the regulator itself to know which setting is wrong.

https://elixir.bootlin.com/linux/latest/source/drivers/regulator/core.c#L424

You should do something like this there

dev_err(rdev->dev,"min:%d max:%d",*min_uV,*max_uV);
6

Reverted

[    0.969537] vcore1: min:1150000 max:1160000
[    0.974922] vm: min:1150000 max:1150000
[    0.986928] vcore1: min:1100000 max:1110000
[    0.999054] vcore1: min:1200000 max:1210000
[    1.003809] vcore1: min:1150000 max:1160000
[    1.020147] vcore1: min:1200000 max:1210000
[    1.024794] vcore1: min:1050000 max:1060000
[    1.050438] vcore1: min:1200000 max:1210000
[    1.069050] vcore1: min:1250000 max:1260000
[    1.166036] vcore1: min:1310000 max:1320000
[    1.167463] vcore1: min:1050000 max:1060000
[    1.209071] vcore1: min:1200000 max:1210000
[    1.213883] vcore1: min:1000000 max:1010000
[    1.223359] vm: min:1100000 max:1110000

Crashing

[    0.939804] vcore1: min:1250000 max:1150000

Used

rdev_err(rdev,"min:%d max:%d",*min_uV,*max_uV);
7

A patch reverting the changes was sent to mailinglist: https://lore.kernel.org/all/18947e09733a17935af9a123ccf9b6e92faeaf9b.1669958641.git.viresh.kumar@linaro.org/#t