From: Andy Green andy.green@linaro.org
Signed-off-by: Andy Green andy@warmcat.com ---
include/asm/arch-omap4/cpu.h | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/asm/arch-omap4/cpu.h b/include/asm/arch-omap4/cpu.h index 4971ba4..b273356 100644 --- a/include/asm/arch-omap4/cpu.h +++ b/include/asm/arch-omap4/cpu.h @@ -442,6 +442,9 @@ #define I2C_BASE2 (OMAP44XX_L4_PER + 0x72000) #define I2C_BASE3 (OMAP44XX_L4_PER + 0x60000)
+#define O4_GPIO_BASE 0x4a310000 +#define O4_GPIO_BASE2 0x48055000 + #ifdef CONFIG_LCD extern void lcd_disable(void); extern void lcd_panel_disable(void);
From: Andy Green andy.green@linaro.org
When the OMAP 4 on Panda sees that USB OTG external power is present, it changes the boot flow in the ROM to try to boot via that before trying MMC1. If it isn't satisfied, it falls through to try MMC1.
Without this patch, under those conditions X-Loader is unable to update the DPLL as it needs to do during dram initialization, because the EMIF never goes idle allowing the shadow update mechanism to apply the new settings.
It therefore loops for a long period waiting to confirm the settings applied and boot is hung (with LEDs off, so the device looks OFF).
This patch re-enables EMIF idle which was previously commented out with "No IDLE: BUG in SDC" to allow the new DPLL settings to apply.
With the patch against http://gitorious.org/x-loader HEAD the Panda is able to boot from either USB OTG power applied or DC Jack power OK.
Note that I saw peak current during boot of 650mA, higher than the 500mA allowed by USB. It may go higher with other peripherals enabled or trying to use USB host on Panda.
Cc: Menon Nishanth menon.nishanth@gmail.com Signed-off-by: Andy Green andy@warmcat.com ---
board/omap4430panda/clock.c | 6 +++++ board/omap4430panda/omap4430panda.c | 46 +++++++++++++++++++++++++++++++++-- 2 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/board/omap4430panda/clock.c b/board/omap4430panda/clock.c index a83f1c6..c75dff7 100644 --- a/board/omap4430panda/clock.c +++ b/board/omap4430panda/clock.c @@ -538,6 +538,12 @@ void lock_core_dpll_shadow(void) */ *(volatile int*)0x4A004260 = 0x70D | (dpll_param_p->m2 << 11);
+ /* + * 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 );
diff --git a/board/omap4430panda/omap4430panda.c b/board/omap4430panda/omap4430panda.c index a91e2aa..c2fd1f9 100644 --- a/board/omap4430panda/omap4430panda.c +++ b/board/omap4430panda/omap4430panda.c @@ -417,9 +417,21 @@ static void ddr_init(void) */ configure_core_dpll_no_lock();
+ /* + * the following is re-enabled because without the EMIF going idle, + * the shadow DPLL update scheme can delay for minutes until it is + * able to apply the new settings... it waits until EMIF idle. + * + * This is seen in the case the ROM enabled USB boot being tried before + * normal boot over MMC. + */ + +#if 1 /* 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 + *(volatile int*)(EMIF1_BASE + EMIF_PWR_MGMT_CTRL) = 0x0; *(volatile int*)(EMIF2_BASE + EMIF_PWR_MGMT_CTRL) = 0x0;
@@ -623,7 +635,14 @@ void s_init(void) { unsigned int rev = omap_revision();
+ /* + * this is required to survive the muxconf in the case the ROM + * started up USB OTG + */ + prcm_init(); + set_muxconf_regs(); + delay(100);
/* Writing to AuxCR in U-boot using SMI for GP/EMU DEV */ @@ -637,7 +656,7 @@ void s_init(void) /* Set VCORE1 = 1.3 V, VCORE2 = VCORE3 = 1.21V */ #if defined(CONFIG_MPU_600) || defined(CONFIG_MPU_1000) scale_vcores(); -#endif +#endif prcm_init();
if(rev != OMAP4430_ES1_0) { @@ -1203,7 +1222,28 @@ int dram_init(void) *********************************************************/ void set_muxconf_regs(void) { + unsigned int v; + MUX_DEFAULT_OMAP4(); + + /* + * If the ROM has started the OTG stuff, stop it and + * make it look as if uninitialized + */ + + /* hold OTG phy in reset */ + + v = __raw_readl(O4_GPIO_BASE2 + 0x134); + __raw_writel((v & ~(0x01 << 30)), O4_GPIO_BASE2 + 0x134); + + v = __raw_readl(O4_GPIO_BASE2 + 0x13c); + __raw_writel((v & ~(0x01 << 30)), O4_GPIO_BASE2 + 0x13c); + + /* kill USB PLL */ + + v = __raw_readl(0x4a008100 + 0x80); + __raw_writel((v & ~(7 << 0)) | 1, 0x4a008100 + 0x80); + return; }
Hi Andy,
On Tuesday 08 February 2011 03:11 PM, Andy Green wrote:
From: Andy Greenandy.green@linaro.org
When the OMAP 4 on Panda sees that USB OTG external power is present, it changes the boot flow in the ROM to try to boot via that before trying MMC1. If it isn't satisfied, it falls through to try MMC1.
Without this patch, under those conditions X-Loader is unable to update the DPLL as it needs to do during dram initialization, because the EMIF never goes idle allowing the shadow update mechanism to apply the new settings.
There is a specific requirement that MEMIF clock domain should be in SW wakeup mode during this FREQ_UPDATE procedure. It can not be in HW_AUTO either. However, after the sequence it's better to put it in HW_AUTO. This is the recommended sequence. I found this in our functional spec. I am not sure if this is available in the public TRM though.
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.
It therefore loops for a long period waiting to confirm the settings applied and boot is hung (with LEDs off, so the device looks OFF).
This patch re-enables EMIF idle which was previously commented out with "No IDLE: BUG in SDC" to allow the new DPLL settings to apply.
With the patch against http://gitorious.org/x-loader HEAD the Panda is able to boot from either USB OTG power applied or DC Jack power OK.
Note that I saw peak current during boot of 650mA, higher than the 500mA allowed by USB. It may go higher with other peripherals enabled or trying to use USB host on Panda.
Cc: Menon Nishanthmenon.nishanth@gmail.com Signed-off-by: Andy Greenandy@warmcat.com
board/omap4430panda/clock.c | 6 +++++ board/omap4430panda/omap4430panda.c | 46 +++++++++++++++++++++++++++++++++-- 2 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/board/omap4430panda/clock.c b/board/omap4430panda/clock.c index a83f1c6..c75dff7 100644 --- a/board/omap4430panda/clock.c +++ b/board/omap4430panda/clock.c @@ -538,6 +538,12 @@ void lock_core_dpll_shadow(void) */ *(volatile int*)0x4A004260 = 0x70D | (dpll_param_p->m2<< 11);
- /*
* 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.
diff --git a/board/omap4430panda/omap4430panda.c b/board/omap4430panda/omap4430panda.c index a91e2aa..c2fd1f9 100644 --- a/board/omap4430panda/omap4430panda.c +++ b/board/omap4430panda/omap4430panda.c @@ -417,9 +417,21 @@ static void ddr_init(void) */ configure_core_dpll_no_lock();
- /*
* the following is re-enabled because without the EMIF going idle,* the shadow DPLL update scheme can delay for minutes until it is* able to apply the new settings... it waits until EMIF idle.** This is seen in the case the ROM enabled USB boot being tried before* normal boot over MMC.*/+#if 1 /* 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
- *(volatile int*)(EMIF1_BASE + EMIF_PWR_MGMT_CTRL) = 0x0; *(volatile int*)(EMIF2_BASE + EMIF_PWR_MGMT_CTRL) = 0x0;
@@ -623,7 +635,14 @@ void s_init(void) { unsigned int rev = omap_revision();
- /*
* this is required to survive the muxconf in the case the ROM* started up USB OTG*/- prcm_init();
Are you doing prcm_init() two times. Isn't that unnecessary? Perhaps you could avoid the second one?
set_muxconf_regs();
delay(100);
/* Writing to AuxCR in U-boot using SMI for GP/EMU DEV */
@@ -637,7 +656,7 @@ void s_init(void) /* Set VCORE1 = 1.3 V, VCORE2 = VCORE3 = 1.21V */ #if defined(CONFIG_MPU_600) || defined(CONFIG_MPU_1000) scale_vcores(); -#endif +#endif prcm_init();
if(rev != OMAP4430_ES1_0) { @@ -1203,7 +1222,28 @@ int dram_init(void) *********************************************************/ void set_muxconf_regs(void) {
- unsigned int v;
- MUX_DEFAULT_OMAP4();
- /*
* If the ROM has started the OTG stuff, stop it and* make it look as if uninitialized*/- /* hold OTG phy in reset */
- v = __raw_readl(O4_GPIO_BASE2 + 0x134);
- __raw_writel((v& ~(0x01<< 30)), O4_GPIO_BASE2 + 0x134);
- v = __raw_readl(O4_GPIO_BASE2 + 0x13c);
- __raw_writel((v& ~(0x01<< 30)), O4_GPIO_BASE2 + 0x13c);
- /* kill USB PLL */
- v = __raw_readl(0x4a008100 + 0x80);
- __raw_writel((v& ~(7<< 0)) | 1, 0x4a008100 + 0x80);
Should this go in a different function?
- return; }
Best regards, Aneesh
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
Hi Andy,
On Tuesday 08 February 2011 07:12 PM, Andy Green wrote:
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.
Even if the MEMIF module had been in HW_AUTO mode(that allows idling) you would still have the same issue(I faced it:-)) because there is a hard requirement that you should be in SW wakeup mode during this sequence.
I will try to see if I can get this vital information published in the public TRM.
Best regards, Aneesh
Aneesh, looping in x-loader list as well (apologies if cross posting is discouraged in linaro list)..
x-loader list - fyi.. Aneesh V wrote, on 02/08/2011 06:53 PM:
Hi Andy,
On Tuesday 08 February 2011 03:11 PM, Andy Green wrote:
From: Andy Greenandy.green@linaro.org
When the OMAP 4 on Panda sees that USB OTG external power is present, it changes the boot flow in the ROM to try to boot via that before trying MMC1. If it isn't satisfied, it falls through to try MMC1.
Without this patch, under those conditions X-Loader is unable to update the DPLL as it needs to do during dram initialization, because the EMIF never goes idle allowing the shadow update mechanism to apply the new settings.
There is a specific requirement that MEMIF clock domain should be in SW wakeup mode during this FREQ_UPDATE procedure. It can not be in HW_AUTO either. However, after the sequence it's better to put it in HW_AUTO. This is the recommended sequence. I found this in our functional spec. I am not sure if this is available in the public TRM though.
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.
It therefore loops for a long period waiting to confirm the settings applied and boot is hung (with LEDs off, so the device looks OFF).
This patch re-enables EMIF idle which was previously commented out with "No IDLE: BUG in SDC" to allow the new DPLL settings to apply.
With the patch against http://gitorious.org/x-loader HEAD the Panda is able to boot from either USB OTG power applied or DC Jack power OK.
Note that I saw peak current during boot of 650mA, higher than the 500mA allowed by USB. It may go higher with other peripherals enabled or trying to use USB host on Panda.
Cc: Menon Nishanthmenon.nishanth@gmail.com Signed-off-by: Andy Greenandy@warmcat.com
board/omap4430panda/clock.c | 6 +++++ board/omap4430panda/omap4430panda.c | 46 +++++++++++++++++++++++++++++++++-- 2 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/board/omap4430panda/clock.c b/board/omap4430panda/clock.c index a83f1c6..c75dff7 100644 --- a/board/omap4430panda/clock.c +++ b/board/omap4430panda/clock.c @@ -538,6 +538,12 @@ void lock_core_dpll_shadow(void) */ *(volatile int*)0x4A004260 = 0x70D | (dpll_param_p->m2<< 11);
- /*
- 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.
diff --git a/board/omap4430panda/omap4430panda.c b/board/omap4430panda/omap4430panda.c index a91e2aa..c2fd1f9 100644 --- a/board/omap4430panda/omap4430panda.c +++ b/board/omap4430panda/omap4430panda.c @@ -417,9 +417,21 @@ static void ddr_init(void) */ configure_core_dpll_no_lock();
- /*
- the following is re-enabled because without the EMIF going idle,
- the shadow DPLL update scheme can delay for minutes until it is
- able to apply the new settings... it waits until EMIF idle.
- This is seen in the case the ROM enabled USB boot being tried before
- normal boot over MMC.
- */
+#if 1 /* 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
*(volatile int*)(EMIF1_BASE + EMIF_PWR_MGMT_CTRL) = 0x0; *(volatile int*)(EMIF2_BASE + EMIF_PWR_MGMT_CTRL) = 0x0;
@@ -623,7 +635,14 @@ void s_init(void) { unsigned int rev = omap_revision();
- /*
- this is required to survive the muxconf in the case the ROM
- started up USB OTG
- */
- prcm_init();
Are you doing prcm_init() two times. Isn't that unnecessary? Perhaps you could avoid the second one?
set_muxconf_regs();
delay(100);
/* Writing to AuxCR in U-boot using SMI for GP/EMU DEV */ @@ -637,7 +656,7 @@ void s_init(void) /* Set VCORE1 = 1.3 V, VCORE2 = VCORE3 = 1.21V */ #if defined(CONFIG_MPU_600) || defined(CONFIG_MPU_1000) scale_vcores(); -#endif +#endif prcm_init();
if(rev != OMAP4430_ES1_0) { @@ -1203,7 +1222,28 @@ int dram_init(void) *********************************************************/ void set_muxconf_regs(void) {
- unsigned int v;
MUX_DEFAULT_OMAP4();
- /*
- If the ROM has started the OTG stuff, stop it and
- make it look as if uninitialized
- */
- /* hold OTG phy in reset */
- v = __raw_readl(O4_GPIO_BASE2 + 0x134);
- __raw_writel((v& ~(0x01<< 30)), O4_GPIO_BASE2 + 0x134);
- v = __raw_readl(O4_GPIO_BASE2 + 0x13c);
- __raw_writel((v& ~(0x01<< 30)), O4_GPIO_BASE2 + 0x13c);
- /* kill USB PLL */
- v = __raw_readl(0x4a008100 + 0x80);
- __raw_writel((v& ~(7<< 0)) | 1, 0x4a008100 + 0x80);
Should this go in a different function?
return; }
Best regards, Aneesh
From: Andy Green andy.green@linaro.org
I found this useful during debugging failure of xloader before serial had come up on Panda.
Cc: Menon Nishanth menon.nishanth@gmail.com Signed-off-by: Andy Green andy@warmcat.com ---
board/omap4430panda/omap4430panda.c | 21 +++++++++++++++++++++ 1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/board/omap4430panda/omap4430panda.c b/board/omap4430panda/omap4430panda.c index c2fd1f9..b263e50 100644 --- a/board/omap4430panda/omap4430panda.c +++ b/board/omap4430panda/omap4430panda.c @@ -714,6 +714,27 @@ int dram_init(void) return 0; }
+/* this flashes the Panda LEDs forever, if called after muxconf */ + +void spam(void) +{ + volatile int n; + unsigned int v = __raw_readl(O4_GPIO_BASE + 0x134); + __raw_writel((v & ~(0x03 << 7)), O4_GPIO_BASE + 0x134); + + v = __raw_readl(O4_GPIO_BASE + 0x13c); + + while (1) { + __raw_writel((v & ~(0x03 << 7)), O4_GPIO_BASE + 0x13c); + for (n = 0; n< 100000; n++) + ; + + __raw_writel((v | (0x03 << 7)), O4_GPIO_BASE + 0x13c); + for (n = 0; n< 100000; n++) + ; + } +} + #define OMAP44XX_WKUP_CTRL_BASE 0x4A31E000 #if 1 #define M0_SAFE M0
andy, why don't you send this series to the xloader ML instead? is that supposed to be taken upstream or in a linaro version of xloader?
On Tue, Feb 8, 2011 at 10:41 AM, Andy Green andy@warmcat.com wrote:
From: Andy Green andy.green@linaro.org
Signed-off-by: Andy Green andy@warmcat.com
include/asm/arch-omap4/cpu.h | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/asm/arch-omap4/cpu.h b/include/asm/arch-omap4/cpu.h index 4971ba4..b273356 100644 --- a/include/asm/arch-omap4/cpu.h +++ b/include/asm/arch-omap4/cpu.h @@ -442,6 +442,9 @@ #define I2C_BASE2 (OMAP44XX_L4_PER + 0x72000) #define I2C_BASE3 (OMAP44XX_L4_PER + 0x60000)
+#define O4_GPIO_BASE 0x4a310000 +#define O4_GPIO_BASE2 0x48055000
#ifdef CONFIG_LCD extern void lcd_disable(void); extern void lcd_panel_disable(void);
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 02/08/11 10:25, Somebody in the thread at some point said:
andy, why don't you send this series to the xloader ML instead? is that supposed to be taken upstream or in a linaro version of xloader?
Hi Nicolas -
Well, from an outside perspective xloader is a bit difficult to find out how to interact with, I did not succeed to find out about any xloader mailing list (what are the coordinates of it?)
Here is the summary of my efforts to find xloader's home last night:
Its upstream appears to be here
https://gforge.ti.com/gf/project/bootloader/wiki/?pagename=X-Loader
but the latest stuff in the download link there is labelled "MLO-zoom2.v1.1" seemingly from 2009, and the version on my SD Card now reports
Texas Instruments X-Loader 1.41 (Oct 6 2010 - 17:27:48)
Going here in case linaro forked it
and searching for xloader x-loader MLO is dry.
I learn though that xloader sources are a sort of parasite on U-Boot sources. So looking here and searching for xloader
http://git.linaro.org/gitweb?p=boot/u-boot-linaro-next.git%3Ba=summary
there are grep hits on X-loader xloader and MLO but they appear unrelated.
http://pixhawk.ethz.ch/wiki/tutorials/omap/replace_xloader
points to angstrom to get a binary with no sources in sight.
Beagleboard forked it, although the fork seems Omap-3 specific from the name
http://gitorious.org/x-load-omap3
it does have Panda support.
I looked inside the hwpack tarball to see if I could get a clue under which name to find the sources, there is no separate Panda u-boot or X-loader package although u-boot-tools and uboot-mkimage are there.
I used dpkg -c to look in each .deb in the hwpack, but none contain a file called MLO which is the name of X-loader on the SD Card.
In the end I found
which had the advantage of working when I built it and yielding 1.44 version, so I cc'd the guy running that in the patches.
-Andy
Hi Andy,
On Tue, Feb 8, 2011 at 11:37 AM, Andy Green andy@warmcat.com wrote:
On 02/08/11 10:25, Somebody in the thread at some point said:
andy, why don't you send this series to the xloader ML instead? is that supposed to be taken upstream or in a linaro version of xloader?
Hi Nicolas -
Well, from an outside perspective xloader is a bit difficult to find out how to interact with, I did not succeed to find out about any xloader mailing list (what are the coordinates of it?)
yep I agree this is messy... but that's also why Anand G. from TI started an initiative to create a 'real' xloader mainline. see http://groups.google.com/group/beagleboard/browse_thread/thread/ced687ea9f1d... .
i think linaro and ubuntu will use this as their upstream for 11.04 and 11.05.
nicolas
Here is the summary of my efforts to find xloader's home last night:
Its upstream appears to be here
https://gforge.ti.com/gf/project/bootloader/wiki/?pagename=X-Loader
but the latest stuff in the download link there is labelled "MLO-zoom2.v1.1" seemingly from 2009, and the version on my SD Card now reports
Texas Instruments X-Loader 1.41 (Oct 6 2010 - 17:27:48)
Going here in case linaro forked it
and searching for xloader x-loader MLO is dry.
I learn though that xloader sources are a sort of parasite on U-Boot sources. So looking here and searching for xloader
http://git.linaro.org/gitweb?p=boot/u-boot-linaro-next.git%3Ba=summary
there are grep hits on X-loader xloader and MLO but they appear unrelated.
http://pixhawk.ethz.ch/wiki/tutorials/omap/replace_xloader
points to angstrom to get a binary with no sources in sight.
Beagleboard forked it, although the fork seems Omap-3 specific from the name
http://gitorious.org/x-load-omap3
it does have Panda support.
I looked inside the hwpack tarball to see if I could get a clue under which name to find the sources, there is no separate Panda u-boot or X-loader package although u-boot-tools and uboot-mkimage are there.
I used dpkg -c to look in each .deb in the hwpack, but none contain a file called MLO which is the name of X-loader on the SD Card.
In the end I found
which had the advantage of working when I built it and yielding 1.44 version, so I cc'd the guy running that in the patches.
-Andy
On 02/08/11 10:59, Somebody in the thread at some point said:
Hi -
yep I agree this is messy... but that's also why Anand G. from TI started an initiative to create a 'real' xloader mainline. see http://groups.google.com/group/beagleboard/browse_thread/thread/ced687ea9f1d....
In the end I found http://gitorious.org/x-loader which had the advantage of working when I built it and yielding 1.44 version, so I cc'd the guy running that in the patches.
As much by luck as judgement I did in fact pick their 'real' upstream to patch against and I cc'd the founder of their mailing list in the patches already.
I have sent the patches to x-loader@googlegroups.com as well; thanks for the advice.
-Andy
Andy Green wrote:
On 02/08/11 10:25, Somebody in the thread at some point said:
andy, why don't you send this series to the xloader ML instead? is
that
supposed to be taken upstream or in a linaro version of xloader?
Hi Nicolas -
Well, from an outside perspective xloader is a bit difficult to find out how to interact with, I did not succeed to find out about any xloader mailing list (what are the coordinates of it?)
Here is the summary of my efforts to find xloader's home last night:
Its upstream appears to be here
https://gforge.ti.com/gf/project/bootloader/wiki/?pagename=X-Loader
but the latest stuff in the download link there is labelled "MLO-zoom2.v1.1" seemingly from 2009, and the version on my SD Card now reports
Texas Instruments X-Loader 1.41 (Oct 6 2010 - 17:27:48)
Going here in case linaro forked it
and searching for xloader x-loader MLO is dry.
I learn though that xloader sources are a sort of parasite on U-Boot sources. So looking here and searching for xloader
http://git.linaro.org/gitweb?p=boot/u-boot-linaro-next.git%3Ba=summary
there are grep hits on X-loader xloader and MLO but they appear unrelated.
http://pixhawk.ethz.ch/wiki/tutorials/omap/replace_xloader
points to angstrom to get a binary with no sources in sight.
Beagleboard forked it, although the fork seems Omap-3 specific from the name
http://gitorious.org/x-load-omap3
it does have Panda support.
I looked inside the hwpack tarball to see if I could get a clue under which name to find the sources, there is no separate Panda u-boot or X-loader package although u-boot-tools and uboot-mkimage are there.
I used dpkg -c to look in each .deb in the hwpack, but none contain a file called MLO which is the name of X-loader on the SD Card.
In the end I found
which had the advantage of working when I built it and yielding 1.44 version, so I cc'd the guy running that in the patches.
I'm sorry about the mess - I tried to unify all of this and started yet another fork that I'm hoping gets to be called as the mainline x-loader. ;)
This is the one - I've just received your patches on the x-loader mailing list, and will go apply them in a bit. I'm maintaining the tree in my spare time, and I usually wait a few days for people to comment first.
Here's the history and the current state:
- x-loader forked out of u-boot several years ago. It was supposed to be used as a minimal first-stage loader for some OMAP boot modes (NAND boot for instance), where we had a limit on the size of the binary that could execute from SRAM. - It was maintained internally for several years - with the beagleboard came several forks of the TI-released x-loader. - There was no effort to unify these, until recently.
- Currently supported boards are: - OMAP3 EVM - Beagle and BeagleXM - Overo (35xx and 37xx) - Pandaboard - OMAP4 Blaze (currently, Pandaboard MLO works, but I need to push explicit support for Blaze out) - Unsupported boards which I would like to support are - Zoom2, Zoom3, 3430 SDP, 3630 SDP, 3430 Zoom1 - Unsupported boards which have remnants of original code - 2420 h4, 2430 SDP, 3430 SDP, 3630 SDP, 3430 Zoom1
There are several forks out there - I'd love to gather up changes from the several different trees and merge them into the one I maintain. All I need is that someone sends a patch against the above tree (and if it's support for a new board, offers to help test patches for/maintain that board).
The roadmap for x-loader is this:
- There is ongoing work (from Aneesh and others) to build an x-loader equivalent out of u-boot. --- This is currently done for OMAP4 alone, but OMAP3 and others will take quite a while to get there. --- The size of the resultant binary is still quite big - there is ongoing work to cut this down. So there's still some way to go before we can get rid of x-loader completely
- I will maintain the x-loader tree as long as it is felt to be useful - The intent is to allow x-loader to boot up u-boot on as many platforms and in as many boot modes as people find useful. - New boards will be supported as long as someone helps verify the state of the x-loader tree on those boards from time to time --- (Existing board support files from other trees are also welcome. I would like to treat them the same way as new board files).
I haven't promoted the new x-loader much - I suppose most wiki pages including omappedia don't point to the new tree and mailing list. So far, we only did an announcement on linux-omap, beagle, panda, and u-boot mailing lists.
I'll go update a few obvious places (elinux.org, omappedia) where people look for info on x-loader, but feel free to suggest other places, or update wikis directly.
- Anand
On Tue, Feb 08, 2011, Anand Gadiyar wrote:
- Currently supported boards are:
- OMAP3 EVM
- Beagle and BeagleXM
- Overo (35xx and 37xx)
- Pandaboard
- OMAP4 Blaze (currently, Pandaboard MLO works, but I need to push explicit support for Blaze out)
IGEP? I thought this was sent to x-loader list a while ago, and was ok to go in
Loďc Minier wrote:
On Tue, Feb 08, 2011, Anand Gadiyar wrote:
- Currently supported boards are:
- OMAP3 EVM
- Beagle and BeagleXM
- Overo (35xx and 37xx)
- Pandaboard
- OMAP4 Blaze (currently, Pandaboard MLO works, but I need to push explicit support for Blaze out)
IGEP? I thought this was sent to x-loader list a while ago, and was ok to go in
My bad - I meant to add it to the list above. Of course it's supported!
- Anand
On 02/08/11 11:50, Somebody in the thread at some point said:
Hi -
I'm sorry about the mess - I tried to unify all of this and started yet another fork that I'm hoping gets to be called as the mainline x-loader. ;)
This is the one - I've just received your patches on the x-loader mailing list, and will go apply them in a bit. I'm maintaining the tree in my spare time, and I usually wait a few days for people to comment first.
Sure, thanks. I guess we help make it the upstream the more we keep feeding google links to your repo ^^
Here's the history and the current state:
- x-loader forked out of u-boot several years ago. It was supposed to be used as a minimal first-stage loader for some OMAP boot modes (NAND boot for instance), where we had a limit on the size of the binary that could execute from SRAM.
What we did for Qi was order the code carefully via linkerscript so that the steppingstone / SRAM part was at the start of a single image, which went on to have the remainder. Since where the ROM got the first part is mandated by the ROM specific to the CPU, Qi for that CPU knows where to go to get the rest of itself into SDRAM. So, it's the equivalent of a single-image xloader + U-Boot. Typical Qi is only 28KBytes including SD / Ext2 / VFAT.
It was maintained internally for several years - with the beagleboard came several forks of the TI-released x-loader.
There was no effort to unify these, until recently.
Currently supported boards are:
- OMAP3 EVM
- Beagle and BeagleXM
- Overo (35xx and 37xx)
- Pandaboard
- OMAP4 Blaze (currently, Pandaboard MLO works, but I need to push explicit support for Blaze out)
Unsupported boards which I would like to support are
- Zoom2, Zoom3, 3430 SDP, 3630 SDP, 3430 Zoom1
Unsupported boards which have remnants of original code
- 2420 h4, 2430 SDP, 3430 SDP, 3630 SDP, 3430 Zoom1
Another difference with Qi is that we got rid of compile-time config. There is a single Qi image built per CPU, and it detects at runtime which device it is running on.
- The intent is to allow x-loader to boot up u-boot on as many platforms and in as many boot modes as people find useful.
I can really recommend booting Linux directly as does Qi. In the context that U-Boot is "the OS", albeit temporarily, it only has disadvantages compared to Linux except the size (and they're working on that ^^) That also goes for "backup" / "debrick" scenarios.
I'll go update a few obvious places (elinux.org, omappedia) where people look for info on x-loader, but feel free to suggest other places, or update wikis directly.
Well I turned to Google so I guess feeding that from a few different directions will help.
TI also need to nuke or redirect that gforge.ti.com page, it obviously was official but is now dead.
-Andy
Hi Anand,
On Tuesday 08 February 2011 05:20 PM, Anand Gadiyar wrote: [snip..]
The roadmap for x-loader is this:
- There is ongoing work (from Aneesh and others) to build an x-loader equivalent out of u-boot.
--- This is currently done for OMAP4 alone, but OMAP3 and others will take quite a while to get there.
John Rigby's patch set has NAND support for OMAP3. My work in progress has support for MMC on OMAP4. If we put them together we should have NAND and MMC support on both OMAP3 and OMAP4(NAND is not needed on OMAP4 though).
Best regards, Aneesh
Hey
Nicolas already pointed the recently created x-loader mailing-list and the common x-loader repository, but I was wondering whether we could just use jcrigby's u-boot SPL work on Panda and just avoid x-loader altogether
@John: do you think this would be possible/hard on panda?
@Andy: see http://www.mail-archive.com/u-boot@lists.denx.de/msg44916.html
Cheers
On 02/08/11 11:46, Somebody in the thread at some point said:
HeyNicolas already pointed the recently created x-loader mailing-list and the common x-loader repository, but I was wondering whether we could just use jcrigby's u-boot SPL work on Panda and just avoid x-loader altogether
@John: do you think this would be possible/hard on panda?
@Andy: see http://www.mail-archive.com/u-boot@lists.denx.de/msg44916.html
Hi -
Actually FWIW I was talking to my friend Matt Hsu at 0xlabs yesterday, he did an Omap 3 port of Qi bootloader and told he is working on a Pandaboard / OMAP 4 port this week.
To the extent that the bootloader is just there to load and boot Linux the current system of xloader and U-Boot is wasteful in several domains at once but most especially boot time when combined with a big initrd like it is at the moment.
A chip as powerful as this should be in Linux off SD in 3 - 4 seconds from cold.
If I can't sell Qi ^^ then certainly extending xloader to just take Linux and eliminating U-Boot will be the next best thing.
-Andy
On Tue, Feb 08, 2011, Andy Green wrote:
Actually FWIW I was talking to my friend Matt Hsu at 0xlabs yesterday, he did an Omap 3 port of Qi bootloader and told he is working on a Pandaboard / OMAP 4 port this week.
cool!
To the extent that the bootloader is just there to load and boot Linux the current system of xloader and U-Boot is wasteful in several domains at once but most especially boot time when combined with a big initrd like it is at the moment.
This is certainly an interesting perspective for production images; for Linaro, I think we're exclusively using u-boot for now, which allows for some simplifications and gives developers a rather featureful bootloader which is suitable for the development stage (and granted, might not always be small or fast enough for production). Consider for instance DeviceTree support: it's available in u-boot, and I'd be surprized if it was also available in Qi.
Maybe a lightweight BSD-licensed bootloader will be on our agenda in future cycles, but it's not a priority right now
That said, if it's available and working, we could offer if as an alternative for interested people (I would guess on a best effort basis, non-official etc.)
Do you have pointers to the source and usage instructions? :-) maybe a Linaro wiki page might make sense
On 02/08/11 12:48, Somebody in the thread at some point said:
Hi -
This is certainly an interesting perspective for production images; for Linaro, I think we're exclusively using u-boot for now, which allows for some simplifications and gives developers a rather featureful bootloader which is suitable for the development stage (and granted, might not always be small or fast enough for production). Consider for instance DeviceTree support: it's available in u-boot, and I'd be surprized if it was also available in Qi.
That's correct, but Qi has full ATAGS and initrd support, it won't be difficult to take or rework U-Boot's devicetree in as well. The bootloader side will be a lot simpler than the kernel side since it's just passing the right blob along.
U-Boot has traditionally been used "in development" but especially on boards with SD Boot there are limited scenarios where its "more than load and boot" features, like shells and 5 second delays on every boot are actually useful.
Maybe a lightweight BSD-licensed bootloader will be on our agenda in future cycles, but it's not a priority right now
That said, if it's available and working, we could offer if as an alternative for interested people (I would guess on a best effort basis, non-official etc.)
Do you have pointers to the source and usage instructions? :-) maybe a Linaro wiki page might make sense
http://git.warmcat.com/cgi-bin/cgit/qi/
Currently the lpc branch is most up to date but Matt also proposed merging all the support back into our master when he has done Panda, so I will wait to move it on until that is done.
-Andy
On Tue, Feb 08, 2011, Andy Green wrote:
http://git.warmcat.com/cgi-bin/cgit/qi/ Currently the lpc branch is most up to date but Matt also proposed merging all the support back into our master when he has done Panda, so I will wait to move it on until that is done.
omap3430/3530 seem to be the only supported ARMv7 CPUs in an omap3530 branch, and it seems the only supported board is beagle. It didn't build for me since my cross toolchain has FORTIFY_SOURCE and defaults to Thumb and because I'm using a French locale, I've sent a patch series to Matt Hsu since he seems to be the one committing to this branch. Overall, many things seem hardcoded like the cmdline args which include the rootfstype. In past discussions around detecting the board with John Rigby and Steve Sakoman, it wasn't entirely clear how one would actually detect the board one is running on, so I'm not sure how Qi would deal with this.
In terms of licensing, many files lack a header, and there is no top-level COPYING, but it seems to be mostly GPL v2.
The result (image/qi-omap3530-beagle-fixes_14ef8c447f592dcd.bin) wasn't recognized by QEMU whem I copied it as MLO on an otherwise working image; I guess I'm missing some required step, but I didn't find any new tool or target while reviewing the diff from the master branch to the omap3530 one.
On 02/08/11 14:06, Somebody in the thread at some point said:
Hi -
omap3430/3530 seem to be the only supported ARMv7 CPUs in an omap3530 branch, and it seems the only supported board is beagle. It didn't build for me since my cross toolchain has FORTIFY_SOURCE and defaults to Thumb and because I'm using a French locale, I've sent a patch series to Matt Hsu since he seems to be the one committing to this branch. Overall, many things seem hardcoded like the cmdline args
Hey nice job!
which include the rootfstype. In past discussions around detecting the
Yes, to eliminate any state held by the bootloader it defines the boot scenarios that are possible sources of the kernel image per board. However those listed are tried in order and the ones with the wrong filesystem or absent file fail immediately so the next can be tried. There's also support for generic input and indicators allowing the user to change boot path to a backup kernel + initrd for example by holding a button.
What you can do about boot configuration is allow one of these "append" files in the per-board structure. These can only append to the kernel commandline that is defined for the board, but since the last version of most tokens is actually used it allows override of loglevel and so on from the filesystem.
board with John Rigby and Steve Sakoman, it wasn't entirely clear how one would actually detect the board one is running on, so I'm not sure how Qi would deal with this.
What has worked for other boards is fingerprinting by JEDEC ID, but depending on the board other peripheral ID registers, serial EEPROM, or tied IO can help. If you need board "identity" data, eg, MAC addresses that don't live on your SD Card, you will need an identity serial EEPROM anyway.
In terms of licensing, many files lack a header, and there is no top-level COPYING, but it seems to be mostly GPL v2.
It's GPL2.
The result (image/qi-omap3530-beagle-fixes_14ef8c447f592dcd.bin) wasn't recognized by QEMU whem I copied it as MLO on an otherwise working image; I guess I'm missing some required step, but I didn't find any new tool or target while reviewing the diff from the master branch to the omap3530 one.
MLO needs one of two flavours of TI magic header, I don't know what Matt did about it since there are (two) TI tools floating about for that, but for uImage I wrote a shell script to replace mkimage and integrated it into Qi and that'd be the best approach.
-Andy
-
Anand Gadiyar -
Andy Green -
Aneesh V -
Dechesne, Nicolas -
Loïc Minier -
Nishanth Menon