On 21/03/16 19:22, Siarhei Siamashka wrote:
> On Mon, 21 Mar 2016 14:24:14 +0100
> Jens Kuske <jensku...@gmail.com> wrote:
>
>> This workaround is necessary for A80, which sometimes
>> fails at reading DACR.
>>
>> Signed-off-by: Jens Kuske <jensku...@gmail.com>
>> ---
>> 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 <siarhei.siamas...@gmail.com>
>
> 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
>
Hi Siarhei,
the MIDR register reads 0x410fc075, looks like it is a Cortex A7.
I've tried various things like reordering the reads, leaving out some
reads or adding additional ones for random registers, it always fails at
DACR. I have no idea what that means...
Sometimes it randomly works after reset, but not very often (maybe 5%).
I've given up investigating this any further for now, I haven't seen any
problems after this patch anymore.
Regards,
Jens
--
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.
