Hello, 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. 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. Thanks, Paul
