Hi Stefan, The 12/12/2018 12:41, Stefan Roese wrote: > Hi Horatiu Vultur, > > On 12.12.18 12:21, Horatiu Vultur wrote: > > Is your Linux Kernel compile with CONFIG_CPU_MIPSR2_IRQ_VI? Because we > > had similar issue with two of our boards(Ocelot and Luton). > > No, its not configured for this MT7688 / RAMIPS SoC. Enabling this > option does fix this issue. Many thanks for the suggestion.
I am glad that it worked. > > BTW: Should CPU_MIPSR2_IRQ_EI probably also be set? Well, it depends on the interrupt controller that you have. In our case we didn't set it. But I am not an MIPS expert, so I may be wrong. > > In our case the problem was that that Linux Kernel didn't reserve memory > > for the addresses pointed by ebase register and then later the kernel > > used this address overwriting the interupt vector, that lead to random > > crash. > > Exactly what we've observed here. It took quite some debugging to > finally find the root-cause for this. > > Thanks, > Stefan > > The 12/12/2018 09:18, Stefan Roese wrote: > > > 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 > > > _______________________________________________ > > > U-Boot mailing list > > > U-Boot@lists.denx.de > > > https://lists.denx.de/listinfo/u-boot > > > > Viele Grüße, > Stefan > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de -- /Horatiu _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
