[U-Boot] MIPS (mt7688): EBase change in U-Boot breaks Linux

[Daniel Schwierzeck]

Hi Stefan,

Am 12.12.18 um 09:18 schrieb Stefan Roese:
> Hi!
> 
> I've been hunting for a problem for quite some time, where Linux
> hangs / crashes in userspace at some point on my MT7688 based
> systems. I found that this problem can be avoided (worked around)
> by not giving Linux the full memory (by using DT memory node fixup
> or mem= kernel cmdline). When reducing this memory by the memory
> used by U-Boot (stack pointer minus some KiB value as this is the
> "lowest" memory used by U-Boot), then Linux runs just fine.
> 
> My first idea here was, that this issue is cache related (most
> likely I-cache). But all tests and debugging in this area did not
> fix this issue (even running with caches disabled).
> 
> Finally I found that this line in U-Boot makes Linux break:
> 
> arch/mips/lib/traps.c:
> 
> void trap_init(ulong reloc_addr)
>     unsigned long ebase = gd->irq_sp;
>     ...
>     write_c0_ebase(ebase);
> 
> This sets EBase to something like 0x87e9b000 on my system (128MiB).
> And Linux then re-uses this value and copies the exceptions handlers
> to this address, overwriting random code and leading to an unstable
> system.
> 
> So my questions now is, how should this be handled on the MT7688
> platform instead? One way would be to set EBase back to the
> original value (0x80000000) before booting into Linux. Another
> solution would be to add some Linux code like board_ebase_setup()
> to the MT7688 Linux port.
> 
> Since I'm still no real MIPS expert yet, I would really like to get
> some advise here on how to best solve this issue. Maybe I missed
> something. Comments?
> 
> Thanks,
> Stefan

the relevant code is in arch/mips/kernel/traps.c:trap_init():

Within the branch if (cpu_has_veic || cpu_has_vint) the kernel will
allocate memory for the exception vectors and resets ebase to that memory.

In the else branch ebase is statically assigned to CAC_BASE which should
resolve to 0x80000000 on Ralink platform. The ebase is only read from
CP0 for MIPS r6 CPUs.

So the ebase set by U-Boot shouldn't be relevant for Ralink platform.
More likely some code at 0x80000000 is overwritten when installing the
exception handlers because all Ralink SoCs except MT7621 have
0xffffffff80000000 defined as load address. So adding something like
0x1000 should fix your problem too.

AFAIK the CPU probing should detect and set cpu_has_veic accordingly.
Maybe it's a bug by Ralink to not set this bit. I guess that's why a
platform could provide a cpu-feature-overrides.h. Or you could configure
CPU_MIPSR2_IRQ_VI as Horatio stated in his response.

@Paul regarding MIPS r6, is there some expectation of the bootloader to
set ebase to a reasonable value or to not change the value at all? Maybe
we need to fix U-Boot?

-- 
- Daniel