On Tue, 24 Feb 2015 18:08:55 +0100 Hans de Goede <hdego...@redhat.com> wrote:
> Hi, > > On 02/24/2015 03:18 AM, Siarhei Siamashka wrote: > > The FEL BROM code has the MMU enabled for some reason (while > > I-cache and D-cache are disabled). Most likely the intention was > > to get a somewhat better performance. Everything is mapped as > > TEXCB=00000 (strongly ordered), except for the 0x00000000 (SRAM) > > and 0xFFF00000 (BROM) sections, which are mapped as TEXCB=00100 > > (normal uncached memory). > > > > This becomes a problem for the A13 SoC, because it has less SRAM > > than the other chips. A13 stores the MMU addresses translation > > table at 0x8000 and uses up 16 KiB of the SRAM space there (while > > the A10, A20 and A31s keep the MMU table in the secure SRAM at > > 0x20000). And because the 'spl' command needs space for backing > > up the FEL stacks, it was clashing with the MMU table. > > > > The solution is simple. We just backup the addresses translation > > table and disable the MMU before running the SPL. And then restore > > it back to the original state. This fixes problems on A13. > > > > Re-enabling the MMU in the end is only necessary to avoid performance > > losses. For example, the transfer speed of the 'fel write' command > > on A20 would drop from ~320 KB/s to ~260 KB/s without MMU. > > > > Signed-off-by: Siarhei Siamashka <siarhei.siamas...@gmail.com> > > Hmm, this is not ideal, but seems to be the only way, so: > > Acked-by: Hans de Goede <hdego...@redhat.com> It's not too bad. In fact I was puzzled about the whole purpose of having the MMU enabled in the first place. The only reasonable explanation is that it was a half-baked attempt to do performance tuning by picking somewhat better section attributes (which I'm in fact improving in the patch 3/5 to gain a real performance boost). If the MMU is not enabled, then by default memory is assumed to be cacheable for instruction fetches and strongly ordered for data accesses. And the U-Boot SPL disables the MMU as one of the first steps in start.S anyway. Here it only means a waste of 16 KiB of SRAM for us. So disabling the MMU while the SPL is running is quite reasonable. And this provides a valuable storage space, which guarantees the availability of full 32 KiB of SRAM for the SPL :-) I was even tempted to change the code to always use the MMU area as a backup storage space on all SoC variants. Re-enabling the MMU is still useful after the SPL has finished running, because the 'fel' tool potentially needs to upload large amounts of data to the DRAM at this stage. And here the performance does matter. -- Best regards, Siarhei Siamashka -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
