[U-Boot] i.MX8MM mapped register access causes crashes
Hi Peng,
I'm still trying to get my i.MX8MM board running with mainline U-Boot. I'm using your patches and added some modifications, so I'm now able to run SPL and U-Boot proper.
One problem I have is, that accessing some regions in the memory map for peripheral register access, U-Boot crashes or hangs.
Example:
=> md 0x302d0000 302d0000: 00000743 0000e031 00000000 00000000 C...1........... 302d0010: ffffffff ffffffff ffffffff 00000000 ................ 302d0020: 00000000 001012ec"Synchronous Abort" handler, esr 0x96000210 elr: 0000000040251b84 lr : 0000000040251ba0 (reloc) elr: 00000000bffa3b84 lr : 00000000bffa3ba0 x0 : 00000000bffb9000 x1 : 00000000308800b4 x2 : 00000000bff6e9b4 x3 : 00000000302d0028 x4 : 0000000000000000 x5 : 00000000bffb96a2 x6 : 0000000000000004 x7 : 00000000bbf3c330 x8 : 00000000bbf3c2f0 x9 : 000000000000000c x10: 00000000ffffffd8 x11: 0000000000000006 x12: 000000000001869f x13: 0000000000004238 x14: 00000000bbf3c59c x15: 0000000000000008 x16: 000000000000b900 x17: 000000000000ae80 x18: 00000000bbf41d70 x19: 0000000000000038 x20: 00000000302d0020 x21: 00000000302d0020 x22: 00000000bffb8e5f x23: 0000000000000008 x24: 0000000000000004 x25: 0000000000000004 x26: 0000000000000004 x27: 00000000bbf3c3b8 x28: 0000000000000002 x29: 00000000bbf3c330
Do you have any idea what might be wrong or how I could debug this issue?
Thanks, Frieder
Subject: i.MX8MM mapped register access causes crashes
Hi Peng,
I'm still trying to get my i.MX8MM board running with mainline U-Boot. I'm using your patches and added some modifications, so I'm now able to run SPL and U-Boot proper.
One problem I have is, that accessing some regions in the memory map for peripheral register access, U-Boot crashes or hangs.
Example:
=> md 0x302d0000
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.
Regards, Peng
302d0000: 00000743 0000e031 00000000 00000000 C...1........... 302d0010: ffffffff ffffffff ffffffff 00000000 ................ 302d0020: 00000000 001012ec"Synchronous Abort" handler, esr 0x96000210 elr: 0000000040251b84 lr : 0000000040251ba0 (reloc) elr: 00000000bffa3b84 lr : 00000000bffa3ba0 x0 : 00000000bffb9000 x1 : 00000000308800b4 x2 : 00000000bff6e9b4 x3 : 00000000302d0028 x4 : 0000000000000000 x5 : 00000000bffb96a2 x6 : 0000000000000004 x7 : 00000000bbf3c330 x8 : 00000000bbf3c2f0 x9 : 000000000000000c x10: 00000000ffffffd8 x11: 0000000000000006 x12: 000000000001869f x13: 0000000000004238 x14: 00000000bbf3c59c x15: 0000000000000008 x16: 000000000000b900 x17: 000000000000ae80 x18: 00000000bbf41d70 x19: 0000000000000038 x20: 00000000302d0020 x21: 00000000302d0020 x22: 00000000bffb8e5f x23: 0000000000000008 x24: 0000000000000004 x25: 0000000000000004 x26: 0000000000000004 x27: 00000000bbf3c3b8 x28: 0000000000000002 x29: 00000000bbf3c330
Do you have any idea what might be wrong or how I could debug this issue?
Thanks, Frieder
On Wed, Jun 5, 2019 at 10:52 PM Peng Fan peng.fan@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.
Subject: Re: [U-Boot] i.MX8MM mapped register access causes crashes
On Wed, Jun 5, 2019 at 10:52 PM Peng Fan peng.fan@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.
Regards, Peng
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@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.
Thanks, Frieder
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@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
participants (3)
-
Fabio Estevam -
Peng Fan -
Schrempf Frieder