Hi Paul,
On 13.12.18 20:47, Paul Burton wrote:
On Thu, Dec 13, 2018 at 03:23:39PM +0100, Daniel Schwierzeck wrote:
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.
%
I could also prepare a U-Boot patch to restore the original ebase value before
handing the control over to the OS.
I'm not so sure, if overwriting 0x80000000 (default value of EBase on
this SoC) with the exception handler is allowed. Is this address "zero"
handled somewhat specific in MIPS Linux? AFAICT, the complete DDR
area on my platform (0x8000.0000 - 0x87ff.ffff) is available for Linux.
So allocating some memory for this exception handler seems the right
way to go to me.
maybe that's why some platforms define a load address of 0x80002000 or similar
to protect this area somehow.
Does this Linux patch help by any chance?
https://git.linux-mips.org/cgit/linux-mti.git/commit/?h=eng-v4.20&id=39e4d339a4540b66e9d9a8ea0da9ee41a21473b4
I'm not sure I remember why I didn't get that upstreamed yet, I probably
wanted to research what other systems were doing... Speaking for Malta,
the kernel's board support has reserved the start of kseg0 for longer
than I've been involved.
No, this patch does not solve this issue (bootup still hangs or crashes
while mounting the rootfs). I can only assume that its too late to try
to reserve this memory region as the memblock_reserve() call returns 0
(no error).
An alternative would be for Linux to allocate a page for use with the
exception vectors using memblock, and ignore the EBase value U-Boot left
us with. But just marking the area U-Boot used as reserved ought to do
the trick, and has the advantage of ensuring U-Boot's vectors don't get
overwritten before Linux sets up its own which sometimes allows U-Boot
to provide some useful output.
I agree that re-using the U-Boot value would be optimal for boot-time
error printing. But this does not seem to work on our platform AFAICT.
So how to proceed? Should I enable CONFIG_CPU_MIPSR2_IRQ_VI or #define
"cpu_has_veic" to 1 as Lantiq does?
Thanks,
Stefan
