* [U-Boot] i.MX8MM mapped register access causes crashes @ 2019-06-05 9:15 Schrempf Frieder 2019-06-06 1:51 ` Peng Fan 0 siblings, 1 reply; 6+ messages in thread From: Schrempf Frieder @ 2019-06-05 9:15 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] i.MX8MM mapped register access causes crashes 2019-06-05 9:15 [U-Boot] i.MX8MM mapped register access causes crashes Schrempf Frieder @ 2019-06-06 1:51 ` Peng Fan 2019-06-06 1:55 ` Fabio Estevam 0 siblings, 1 reply; 6+ messages in thread From: Peng Fan @ 2019-06-06 1:51 UTC (permalink / raw) To: u-boot > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] i.MX8MM mapped register access causes crashes 2019-06-06 1:51 ` Peng Fan @ 2019-06-06 1:55 ` Fabio Estevam 2019-06-06 1:58 ` Peng Fan 0 siblings, 1 reply; 6+ messages in thread From: Fabio Estevam @ 2019-06-06 1:55 UTC (permalink / raw) To: u-boot 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] i.MX8MM mapped register access causes crashes 2019-06-06 1:55 ` Fabio Estevam @ 2019-06-06 1:58 ` Peng Fan 2019-06-06 6:47 ` Schrempf Frieder 0 siblings, 1 reply; 6+ messages in thread From: Peng Fan @ 2019-06-06 1:58 UTC (permalink / raw) To: u-boot > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] i.MX8MM mapped register access causes crashes 2019-06-06 1:58 ` Peng Fan @ 2019-06-06 6:47 ` Schrempf Frieder 2019-06-06 7:26 ` Peng Fan 0 siblings, 1 reply; 6+ messages in thread From: Schrempf Frieder @ 2019-06-06 6:47 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] i.MX8MM mapped register access causes crashes 2019-06-06 6:47 ` Schrempf Frieder @ 2019-06-06 7:26 ` Peng Fan 0 siblings, 0 replies; 6+ messages in thread From: Peng Fan @ 2019-06-06 7:26 UTC (permalink / raw) To: u-boot > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-06-06 7:26 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-06-05 9:15 [U-Boot] i.MX8MM mapped register access causes crashes Schrempf Frieder 2019-06-06 1:51 ` Peng Fan 2019-06-06 1:55 ` Fabio Estevam 2019-06-06 1:58 ` Peng Fan 2019-06-06 6:47 ` Schrempf Frieder 2019-06-06 7:26 ` Peng Fan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.