[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Troubleshooting Data Abort Error While Debugging U-Boot on mcimx6ul-
From: |
Peter Maydell |
Subject: |
Re: Troubleshooting Data Abort Error While Debugging U-Boot on mcimx6ul-evk in QEMU |
Date: |
Mon, 2 Sep 2024 10:12:43 +0100 |
On Mon, 2 Sept 2024 at 07:10, Guy <guyqqcom@qq.com> wrote:
>
> When I attempt to run U-Boot and debug it with GDB, I encounter an issue in
> the get_cpu_rev function:
>
> struct scu_regs *scu = (struct scu_regs *)SCU_BASE_ADDR;
> cfg = readl(&scu->config) & 3;
>
> This triggers a data_abort error. The log displays
>
> ----------------
> IN: get_cpu_rev
> 0x87802786:
> OBJD-T: 5968
> Invalid read at addr 0xA00004, size 4, region '(null)', reason: rejected
> ----------------
The problem here is that the guest code thinks it can read
from this address, and QEMU thinks there is no device there.
To figure out which one is wrong, you need to look at the
data sheet for the SoC to see whether it says there's
anything at that address.
> Furthermore, I also tested a precompiled qemu-system-arm.exe in windows (the
> -version command shows the same 7.2.0 version of QEMU, although I'm not sure
> if there were any differences in the compilation process) to debug the same
> U-Boot code, and I did not encounter the data_abort error at the get_cpu_rev
> step. The log displays
>
> ----------------
> IN: get_cpu_rev
> 0x87802786:
> OBJD-T: 5968
> scu: unimplemented device read (size 4, offset 0x0004)
> ----------------
I think these can't be the same versions of QEMU. This second
one seems to have been patched to treat this area of memory
as "there should be a device here, but we don't implement it,
so warn about it but return 0". Where does this one come from?
thanks
-- PMM