[U-Boot] i.MX8MM mapped register access causes crashes

[Peng Fan]

> Subject: Re: [U-Boot] i.MX8MM mapped register access causes crashes
> 
> On 06.06.19 03:58, Peng Fan wrote:
> >
> >> Subject: Re: [U-Boot] i.MX8MM mapped register access causes crashes
> >>
> >> On Wed, Jun 5, 2019 at 10:52 PM Peng Fan <peng.fan at nxp.com> wrote:
> >>
> >>> You need to pass an arg after `md 0x302d0000`. Default it will dump
> >>> a lot registers, might 40 registers. It surely will crash, because
> >>> there are only a few registers in GPT1 which is the address you are
> dumping.
> >>
> >> Other suggestion is to make sure that the clock for the peripheral
> >> you are trying to access is turned on.
> >
> > Dump `md 0x302d0000 1` will surely work, but dump `md 0x302d0000 100`
> > will surely crash. The clock already on. It is that GPT1 does not have
> > 100 registers, and trigger error when dumping non-existed registers.
> 
> Thanks for your suggestions. I just used GPT1 as an example. As you can see
> GPT1 registers can be dumped, but at the start of GPT2 it crashes.
> 
> I have the same problem for all kinds of other peripherals. For example I tried
> to enable I2C1, but the driver hangs in probe when it accesses an I2C1
> register for the first time.
> 
> I suspect that this is either, as Fabio said, caused by clocks that are turned off,
> or because of trustzone settings. I'm not loading any ATF at the moment, so
> I'm booting from SPL directly to U-Boot proper and I'm not sure if the
> trustzone settings restrict access to the peripherals in this case.

Ok, clock might be an issue, you could check CCM and LPCG, default it will source
24M and enabled.
You might need check CSU, if GPT1 is ok, GPT2 is bad.

Regards,
Peng.

> 
> Thanks,
> Frieder