[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