[OpenWrt-Devel] [PATCH] ath79: switch to kernel 5.4
Hauke Mehrtens
hauke at hauke-m.de
Sun Jun 28 18:29:22 EDT 2020
On 6/28/20 2:36 PM, Paul Blazejowski wrote:
>
>
> -------- Original Message --------
> Subject: Re: [OpenWrt-Devel] [PATCH] ath79: switch to kernel 5.4
> From: David Bauer <mail at david-bauer.net>
> To: Paul Blazejowski <paulb at blazebox.homeip.net>
> Date: 6/27/2020, 4:17:41 PM
>
>> Hi all,
>
> Hi David
>
>>
>> On 6/27/20 9:33 PM, Paul Blazejowski wrote:
>>> What worked for me in the initial report to the mailing list was to use
>>> this patch from Kevin's staging tree [1] (modified for kernel 5.4, and
>>> building with any gcc version on a clean checkout).
>>
>> Removing the 308-mips32r2_tune.patch patch is enough.
>> What would be interesting to know is whether or not we run
>> into a similar / more significant issue with that down the road.
>
> I can confirm, dropping this patch and building the image using GCC
> 9.3.0 and kernel 5.4.48 produces working image and the router boots
> properly, working properly for 14 hours now...on my end.
>
> [ 0.000000] Linux version 5.4.48 (diffie at blaze) (gcc version 9.3.0
> (OpenWrt GCC 9.3.0 r13136+1-ad27c133eb)) #0 Sat Jun 27 21:07:58 2020
> [ 0.000000] printk: bootconsole [early0] enabled
> [ 0.000000] CPU0 revision is: 0001974c (MIPS 74Kc)
> [ 0.000000] MIPS: machine is Netgear WNDR3700 v4
>
>>
>> If the issue is due to the optimization being flawed we might be okay
>> with that. But i lack significant knowledge about the inner workings of GCC.
>> So take that with a grain of salt.
>
> I don't know {yet!) of any implications or pitfalls from removal of said
> patch but for now compiled code is working, so optimization may be NOT
> the right thing to *do in this case, just a test case on my part. What
> you say?
>
>>
>> Best wishes
>> David
>>
>
> Thank you,
> -paul
>
Hi,
I debugged this a little further today. With the revert >= 5.4.33 kernel
it boots up fine for me, but I do not think this problem is fixed, we
probably just do not see it any more.
OpenWrt commit d74fb0088c5bc89ba080816921699a980966d015 worked for me.
It looks like the DSP extension is not activated correctly.
This MIPS documentation says in section 3.11 "Software Detection of the
DSP Module" that we should only get this exception in case the DSPEn is
not set.
https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00374-2B-MIPS32DSP-AFP-03.01.pdf
This is set in the configure_status() function:
https://elixir.bootlin.com/linux/v5.4.47/source/arch/mips/kernel/traps.c#L2125
But I think this is not working correctly under some unknown conditions.
I printed the read_c0_status() in the do_dsp() function and when this
exception occurs the DSPEn bit is *not* set.
I used OpenWrt commit 0495324b9bd0b6a976ea731a1b4b77b26df32ee6 to
further debug the root cause.
Removing the static from configure_status() makes no difference and I am
still seeing the problem.
When I add this debug printout ad the end of the function the code
starts working and I also do not see this printout:
if (cpu_has_dsp && !(read_c0_status() & ST0_MX))
printk("%s:%i: ST0_MX not set!\n", __func__, __LINE__);
Here is the ASM of the broken function:
----
00000000 <configure_status>:
0: 3c030000 lui v1,0x0
4: 24630000 addiu v1,v1,0
8: 3c051000 lui a1,0x1000
c: 8c620034 lw v0,52(v1)
10: 8c630008 lw v1,8(v1)
14: 30420004 andi v0,v0,0x4
18: 3c049000 lui a0,0x9000
1c: 00a2200a movz a0,a1,v0
20: 30630010 andi v1,v1,0x10
24: 10600003 beqz v1,34 <configure_status+0x34>
28: 00801025 move v0,a0
2c: 3c030100 lui v1,0x100
30: 00831025 or v0,a0,v1
34: 40046000 mfc0 a0,c0_status
38: 3c03f760 lui v1,0xf760
3c: 00441026 xor v0,v0,a0
40: 246300e0 addiu v1,v1,224
44: 00431024 and v0,v0,v1
48: 00441026 xor v0,v0,a0
4c: 40826000 mtc0 v0,c0_status
50: 03e00008 jr ra
54: 00000000 nop
-----
Here is the ASM of the working function:
-------
00000000 <configure_status>:
0: 3c030000 lui v1,0x0
4: 24630000 addiu v1,v1,0
8: 3c051000 lui a1,0x1000
c: 8c620034 lw v0,52(v1)
10: 8c630008 lw v1,8(v1)
14: 30420004 andi v0,v0,0x4
18: 3c049000 lui a0,0x9000
1c: 00a2200a movz a0,a1,v0
20: 30630010 andi v1,v1,0x10
24: 10600003 beqz v1,34 <configure_status+0x34>
28: 00801025 move v0,a0
2c: 3c040100 lui a0,0x100
30: 00441025 or v0,v0,a0
34: 40056000 mfc0 a1,c0_status
38: 3c04f760 lui a0,0xf760
3c: 00451026 xor v0,v0,a1
40: 248400e0 addiu a0,a0,224
44: 00441024 and v0,v0,a0
48: 00451026 xor v0,v0,a1
4c: 40826000 mtc0 v0,c0_status
50: 10600005 beqz v1,68 <configure_status+0x68>
54: 00000000 nop
58: 40026000 mfc0 v0,c0_status
5c: 7c420600 ext v0,v0,0x18,0x1
60: 10400003 beqz v0,70 <configure_status+0x70>
64: 00000000 nop
68: 03e00008 jr ra
6c: 00000000 nop
70: 3c050000 lui a1,0x0
74: 3c040000 lui a0,0x0
78: 24060853 li a2,2131
7c: 24a50000 addiu a1,a1,0
80: 08000000 j 0 <configure_status>
84: 24840000 addiu a0,a0,0
------
Does someone see a bug in the broken version?
In this line:
4c: 40826000 mtc0 v0,c0_status
in v0 the following bits should be set:
#define ST0_MX 0x01000000
#define ST0_CU0 0x10000000
Hauke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200629/66f43d62/attachment-0001.sig>
More information about the openwrt-devel
mailing list