On Mon, 21 Mar 2016 14:24:14 +0100 Jens Kuske <[email protected]> wrote:
> This workaround is necessary for A80, which sometimes > fails at reading DACR. > > Signed-off-by: Jens Kuske <[email protected]> > --- > fel.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/fel.c b/fel.c > index a905ad5..ba58105 100644 > --- a/fel.c > +++ b/fel.c > @@ -767,10 +767,7 @@ uint32_t *aw_backup_and_disable_mmu(libusb_device_handle > *usb, > soc_sram_info *sram_info) > { > uint32_t *tt = NULL; > - uint32_t ttbr0 = aw_get_ttbr0(usb, sram_info); > - uint32_t sctlr = aw_get_sctlr(usb, sram_info); > - uint32_t ttbcr = aw_get_ttbcr(usb, sram_info); > - uint32_t dacr = aw_get_dacr(usb, sram_info); > + uint32_t sctlr, ttbr0, ttbcr, dacr; > uint32_t i; > > uint32_t arm_code[] = { > @@ -796,6 +793,7 @@ uint32_t *aw_backup_and_disable_mmu(libusb_device_handle > *usb, > */ > > /* Basically, ignore M/Z/I bits and expect no TEX remap */ > + sctlr = aw_get_sctlr(usb, sram_info); > if ((sctlr & ~((1 << 12) | (1 << 11) | 1)) != 0x00C52078) { > fprintf(stderr, "Unexpected SCTLR (%08X)\n", sctlr); > exit(1); > @@ -806,16 +804,19 @@ uint32_t > *aw_backup_and_disable_mmu(libusb_device_handle *usb, > return NULL; > } > > + dacr = aw_get_dacr(usb, sram_info); > if (dacr != 0x55555555) { > fprintf(stderr, "Unexpected DACR (%08X)\n", dacr); > exit(1); > } > > + ttbcr = aw_get_ttbcr(usb, sram_info); > if (ttbcr != 0x00000000) { > fprintf(stderr, "Unexpected TTBCR (%08X)\n", ttbcr); > exit(1); > } > > + ttbr0 = aw_get_ttbr0(usb, sram_info); > if (ttbr0 & 0x3FFF) { > fprintf(stderr, "Unexpected TTBR0 (%08X)\n", ttbr0); > exit(1); As we discussed on IRC earlier, having this patch is reasonable as it workarounds A80 problems and makes FEL boot usable on it. So Reviewed-by: Siarhei Siamashka <[email protected]> I have already pushed it to github, thanks! Too bad that we still don't know what's going on. We can probably add a comment to the Notes column in the SoC support status table and warn the users, so that they watch out and report any possible irregularities: https://linux-sunxi.org/FEL/USBBoot#SoC_support_status Can you probably try to read the MIDR register to check if the A80 SoC initially boots on a Cortex A15 or a Cortex A7 core? If it is A7, then something is really odd. But if it is A15, then aggressive instructions reordering may be exposing a missing barrier instruction here or there. There are also some configuration knobs in the A15 too, which allow to partially enforce in-order behaviour: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438i/BABGHIBG.html -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
