Hi-Link HLK-7621a boot issues

I'm trying to use Hi-Link HLK-7621a evaluation board, but having issues with it, tested with 22.03.3 and the current Master.
The error during boot is:

[    0.747188] spi-mt7621 1e000b00.spi: sys_freq: 250000000
[    0.759766] ------------[ cut here ]------------
[    0.769036] WARNING: CPU: 0 PID: 1 at drivers/mtd/spi-nor/core.c:2997 0x8045e66c
[    0.783768] enabling reset hack; may not recover from unexpected reboots
[    0.797106] Modules linked in:
[    0.803200] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.161 #0
[    0.815314] Stack : 00000000 807293a8 809b0000 8171a200 00000000 00000000 00000000 00000000
[    0.831950]         00000000 00000000 00000000 00000000 00000000 00000001 81425960 99aa7727
[    0.848580]         814259f8 00000000 00000000 81425808 00000038 8039a284 ffffffea 00000000
[    0.865211]         81425814 0000005c 807ce868 ffffffff 81425940 806f8134 00000000 80700000
[    0.881843]         00000009 809c0000 80c13538 8171a200 00000018 80403fb8 00000000 80990000
[    0.898474]         ...

I built then my own image with broken-flash-reset statement removed from the DTS, that helped with the above error but created another issue that was discussed in the forum earlier - the board get stuck on reboot.
I see something similar here: Youku YK1 messed up - #52 by mpratt14
and here HLK-7621 doesn't reboot after update to 21.02.0 - #9 by Borromini

In the OEM bootlog I captured the following flash information:

[    2.084000] flash manufacture id: ef, device id 40 19
[    2.092000] W25Q256FV(ef 40190000) (32768 Kbytes)

Not sure if that matters.
One more thing that is probably relevant. I noticed "3-byte and 4-byte address modes" was mentioned on the PR and on the board schema I noticed something similar (after translation from Chinese):
"When the module starts, TXD1 low level will enter 4-byte mode, TXD1 high level will enter 3-byte mode". Not sure it will help though.

@mpratt14 I see you was involved in some earlier discussions on the similar matter, will you be able to help in my case?

I found this patch by @981213 in OpenWrt 21.02 but not in the later versions, does this mean it is not needed anymore?

kernel version?

With my current self-built image from Master it is 5.15.94

so the reason for the stack dump is basically just because a warning was placed in the kernel

the trace is something like this:

dump_stack()
__warn()
warn_slowpath_fmt()
__WARN_printf()
__WARN()
WARN()
WARN_ONCE()

and the WARN_ONCE() is just written into the driver when broken-flash-reset is set

basically it's a side-effect that the user needs to know about, but theres nothing to do about it. You have confirmed the reboot problem and that the broken-flash-reset property fixes it, other than that you would have to change the hardware to get the flash chip's reset pin to actually work.

You can try applying this patch to make the warning into a single line that looks better than a stack dump. However, I'm concerned that this new warning line would be printing a lot, the benefit of WARN_ONCE is that it will only trigger once no matter what... and for that reason I'm not sure if Openwrt members would accept a patch like this.

From 5d09af22fd53bdd05304f6f8a97c89dca763afef
From: Michael Pratt <mcpratt@pm.me>
Date: Wed, 1 Mar 2023 21:09:38 -0500
Subject: [PATCH] kernel: silence stack dump for broken flash reset

Signed-off-by: Michael Pratt <mcpratt@pm.me>
---
 .../490-broken-flash-reset-light-warning.patch     | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 target/linux/generic/hack-5.15/490-broken-flash-reset-light-warning.patch

diff --git a/target/linux/generic/hack-5.15/490-broken-flash-reset-light-warning.patch b/target/linux/generic/hack-5.15/490-broken-flash-reset-light-warning.patch
new file mode 100644
index 0000000000000..13a0e21e45a0b
--- /dev/null
+++ b/target/linux/generic/hack-5.15/490-broken-flash-reset-light-warning.patch
@@ -0,0 +1,14 @@
+--- a/drivers/mtd/spi-nor/core.c
++++ b/drivers/mtd/spi-nor/core.c
+@@ -2849,8 +2849,10 @@ static int spi_nor_init(struct spi_nor *
+ 		 * reboots (e.g., crashes). Warn the user (or hopefully, system
+ 		 * designer) that this is bad.
+ 		 */
+-		WARN_ONCE(nor->flags & SNOR_F_BROKEN_RESET,
++		if (nor->flags & SNOR_F_BROKEN_RESET)
++			dev_warn(nor->dev,
+ 			  "enabling reset hack; may not recover from unexpected reboots\n");
++
+ 		nor->params->set_4byte_addr_mode(nor, true);
+ 	}
+ 
1 Like

Thanks, but that didn't help.

[    1.166730] spi-mt7621 1e000b00.spi: sys_freq: 250000000
[    1.179337] ------------[ cut here ]------------
[    1.188662] WARNING: CPU: 0 PID: 1 at drivers/mtd/spi-nor/core.c:2853 spi_nor_init+0x17c/0x184
[    1.205899] enabling reset hack; may not recover from unexpected reboots
[    1.219242] Modules linked in:
[    1.225336] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.94 #0
[    1.237287] Stack : 80cb3b24 80085c0c 00000000 00000004 00000000 00000000 8142d964 80a30000
[    1.253933]         80870000 8079c918 814483d8 80870e83 00000000 00000001 8142d910 8144d140
[    1.270572]         00000000 00000000 8079c918 8142d7b0 ffffefff 00000000 ffffffea 00000000
[    1.287211]         8142d7bc 0000005d 80876b30 ffffffff 8079c918 00000001 00000000 8047b150
[    1.303851]         00000009 80cb3b24 807f0000 816e0600 00000018 8041fa6c 00000000 80a30000
[    1.320490]         ...
[    1.325347] Call Trace:

I don't fully understand why there was no error with the earlier OpenWrt version like 19.07.

are you sure the patch I pasted applied? did you do make clean

can you show the call trace too?

I will double check everything. I managed to wipe the flash, so I'll need to repair it first.

I re-flashed the bootloader and loaded the image with your patch carefully applied.
I see no errors or crashes, so thank you very much!
I'm going to build a newer image and retest it.

the line

enabling reset hack; may not recover from unexpected reboots

should still be appearing in the kernel log (hopefully just once and not a flood whenever you do a write operation)

This is what I have. Should I be concerned about any messages I see here?

[    1.422890] spi-mt7621 1e000b00.spi: sys_freq: 220000000
[    1.434802] spi-nor spi0.0: enabling reset hack; may not recover from unexpected reboots
[    1.451114] spi-nor spi0.0: w25q256 (32768 Kbytes)
[    1.460783] 4 fixed-partitions partitions found on MTD device spi0.0
[    1.473480] OF: Bad cell count for /palmbus@1e000000/spi@b00/flash@0/partitions
[    1.488085] OF: Bad cell count for /palmbus@1e000000/spi@b00/flash@0/partitions
[    1.503182] OF: Bad cell count for /palmbus@1e000000/spi@b00/flash@0/partitions
[    1.517833] OF: Bad cell count for /palmbus@1e000000/spi@b00/flash@0/partitions
[    1.532659] Creating 4 MTD partitions on "spi0.0":
[    1.542229] 0x000000000000-0x000000030000 : "u-boot"
[    1.553174] 0x000000030000-0x000000040000 : "u-boot-env"
[    1.564759] 0x000000040000-0x000000050000 : "factory"
[    1.575999] 0x000000050000-0x000002000000 : "firmware"
[    1.587357] 2 uimage-fw partitions found on MTD device firmware
[    1.599234] Creating 2 MTD partitions on "firmware":
[    1.609132] 0x000000000000-0x0000002c28ed : "kernel"
[    1.619017] mtd: partition "kernel" doesn't end on an erase/write block -- force read-only
[    1.636513] 0x0000002c28ed-0x000001fb0000 : "rootfs"
[    1.646453] mtd: partition "rootfs" doesn't start on an erase/write block boundary -- force read-only
[    1.665687] mtd: setting mtd5 (rootfs) as root device
[    1.675882] 1 squashfs-split partitions found on MTD device rootfs
[    1.688205] 0x000000710000-0x000001fb0000 : "rootfs_data"

looks completely normal to me

(btw "bad cell count" is also a useless warning that we need to silence)

I just want to know if you do a write operation, like saving a new configuration, if the following line printed again, or only once at boot time

Printed only once. Thanks again.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.