I'm trying to diagnose why a board does not appear to be launching U-Boot like all its siblings (turn it on, it just sits there, no activity anywhere). To that end, I got the brainwave of raising a GPIO signal to turn on a LED on the board. This way, even if nothing else worked, if the LED turned on, I'd know that the boot ROM was loading the U-Boot image and trying to do something with it.
To that end, I added the following entries to our board's Device Configuration Data (DCD) block in the U-Boot .cfg file, which is processed very early by the boot ROM (i.MX6DL register map):
/* Try and turn on the LED attached to GPIO_2 */ /* Configure mux GPIO02 to output GPIO1_IO02 */ DATA 4, 0x020E0224, 0x00000005 /* Configure pad GPIO02 to no pullup, no keep, CMOS output, 50MHz, HI-Z, slow slew. */ DATA 4, 0x020E05f4, 0x00000040 /* Configure GPIO1_IO2 as output. */ DATA 4, 0x0209C004, 0x00000004 /* Set GPIO1_IO02 as high */ DATA 4, 0x0209C000, 0x00000004
I then wrote the modified U-Boot to an SD card, put it into a known-working board, turned it on... And it hung.
After a process of elimination, I discovered that the writes to the GPIO registers were causing the hang (writes to 0x0209C000 and 0x0209C004). If either of those entries is present, the system just lies there. If I remove both of those entries, then the system boots normally. (The writes to the IOMUX registers appear to be successful.)
My suspicion is that the GPIO block hasn't been enabled. However, I can't find any evidence that it needs to be; U-Boot makes no special effort to turn it on. GPIO is driven by ipg_clk_s, which is driven by ipg_clk_root. This seems to be running all the time, but the clock tree is very complicated, and I haven't been able to tease it out.
What might I be missing? I have this awful feeling it's something that should be obvious...