On 02/08/11 13:23, Somebody in the thread at some point said:
Hi -
Would you please take a look at this patch in our internal tree. It seems to be fixing the same issue. I faced exactly same problem on Blaze.
http://dev.omapzoom.org/?p=bootloader/x-loader.git%3Ba=commit%3Bh=7ecbec096c...
Unfortunately the mainline x-loader doesn't seem to have this fix.
Yes, when I moved pcrm_init() up there it moved on further, but there's a second issue on this mainline X-Loader code for Panda.
The DDR code is using shadow update scheme for the DPLL register update, it means you load the register and then when the EMIFs are idle (DDR are not in the middle of something) it will actually apply the change.
However in the mainline tree, there is some commented out code with the comment "No IDLE: BUG in SDC".
Because the EMIFs presumably never became idle, then the clock change for the DPLL never became active, and X-Loader sits there looping waiting for the change to go through.
It sounds like you can check this second issue's meaning via internal data too.
This is where it sits -->
- /*
- if the EMIF never goes idle, and eg, if ROM enabled USB,
- we loop for a very very long time here becuse shadow updates wait
- until EMIF idle
- */
/* Wait for Freq_Update to get cleared: CM_SHADOW_FREQ_CONFIG1 */ while( ( (*(volatile int*)0x4A004260)& 0x1) == 0x1 );
I think it will be better to put the MEMIF clock domain back in HW_AUTO mode after this.
OK.
/* No IDLE: BUG in SDC */
- //sr32(CM_MEMIF_CLKSTCTRL, 0, 32, 0x2);
- //while(((*(volatile int*)CM_MEMIF_CLKSTCTRL)& 0x700) != 0x700);
- sr32(CM_MEMIF_CLKSTCTRL, 0, 32, 0x2);
- while(((*(volatile int*)CM_MEMIF_CLKSTCTRL)& 0x700) != 0x700);
+#endif
- prcm_init();
Are you doing prcm_init() two times. Isn't that unnecessary? Perhaps you could avoid the second one?
I tested it without and it made trouble but that was before I found the IDLE thing, so I will check it again.
Should this go in a different function?
Sure; thanks for the comments.
-Andy