On Mi, 2020-02-19 at 09:27 +0100, Sascha Hauer wrote: > On Wed, Feb 19, 2020 at 07:23:09AM +0100, Oleksij Rempel wrote: > > Am 18.02.20 um 16:37 schrieb Sascha Hauer: > > > It seems running from the NFC SRAM doesn't work with the instruction > > > cache enabled, it leads to corruptions on the i.MX27. We stumbled upon > > > this earlier and the solution at that time was to disable the > > > instruction cache in the NAND boot code. It is, however, more reliable > > > to just not enable the instruction cache in the first place. > > > This is not particularly nice as we have to ifdef this in generic code, > > > duplicate arm_cpu_lowlevel_init(), or call arm_cpu_lowlevel_init() later > > > when we are out of NFC SRAM. From the different bad solutions I chose > > > to ifdef the instruction cache away. It will be enabled later in the > > > common cache functions. > > > > Hm... is it possible that we have similar speculation issues as on i.MX6UL? The CPU was speculating > > in to IOMEM, caused cache poisoning/corruption and executed corrupted cache. > > I don't know how much speculation an ARM9 processor does, but the end > result looks very similar. via JTAG I can see that the memory matches > my disassembly, just the CPU does something completely different. Processors from this generation don't do much speculation at all. They have a simple branch predictor, but wrong predictions are resolved via a simple pipeline flush. I wouldn't expect a misspeculated instruction to reach the load/store units on those simple cores. It's much more likely that the I-cache simply issues AXI transactions (most likely WRAP ones to implement critical word first) which the NAND controller slave can't handle properly. In that case there is nothing much we can do besides keeping the I$ disabled while we are running from the NAND SRAM region. Regards, Lucas _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
