* [U-Boot] mx28: booting u-boot via USB
2012-01-31 14:03 [U-Boot] mx28: booting u-boot via USB Matthias Fuchs
@ 2012-01-31 14:25 ` Sergey Lapin
2012-01-31 15:19 ` Matthias Fuchs
2012-01-31 14:53 ` Fabio Estevam
2012-02-03 11:23 ` Matthias Fuchs
2 siblings, 1 reply; 7+ messages in thread
From: Sergey Lapin @ 2012-01-31 14:25 UTC (permalink / raw)
To: u-boot
On Tue, Jan 31, 2012 at 03:03:55PM +0100, Matthias Fuchs wrote:
> Hi,
>
> I have a problem booting the current u-boot-imx version
> on a MX28EVK via USB. The i.MX28 CPU supports a special boot mode
> where the image (sb boot stream) is downloaded via USB device
> (all DIP switches in position 'off' on the EVK). The
> CPU's internal bootrom implements a HID device in this mode.
> Freescale provides a download tool "sb_loader" for this purpose.
> There is also a GPL'd implementation based on libusb.
Could you please provide link to GPL tool?
>
> So back to my problem:
>
> I build u-boot from the u-boot-imx repository. This runs fine
> when booting from SD/MMC or SPI-flash. But the console stays dark
> when using the USB download mode. USB download works fine with the
> Freescale provided U-Boot sources together with the imx-bootlets
> SPL code.
>
> Now I digged a little bit deeper to find out the cause:
>
> When downloading via USB I saw the SPL running correctly.
> board_init_ll() (arch/arm/cpu/arm926ejs/mx28/start.S) runs through
> correctly. Then control is passed back to the bootrom. That's
> where things end as far as I can see.
>
> The 2nd stage of u-boot is not started.
>
> The USB boot mechanism is not documented that detailed.
> Is it possible that the SPL code overwrites the bootroms ivt and
> in consequence crashes the bootrom's USB code? Any further ideas?
I'd look at difference in linking scripts and addresses in
freescale u-boot and new u-boot.
This might be some memory addressing issues. Had some of this with
i.MX23. Also, some hardware might be not powered on or is powered
off by SPL.
S.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] mx28: booting u-boot via USB
2012-01-31 14:25 ` Sergey Lapin
@ 2012-01-31 15:19 ` Matthias Fuchs
0 siblings, 0 replies; 7+ messages in thread
From: Matthias Fuchs @ 2012-01-31 15:19 UTC (permalink / raw)
To: u-boot
On 31.01.2012 15:25, Sergey Lapin wrote:
> On Tue, Jan 31, 2012 at 03:03:55PM +0100, Matthias Fuchs wrote:
>> Hi,
>>
>> I have a problem booting the current u-boot-imx version
>> on a MX28EVK via USB. The i.MX28 CPU supports a special boot mode
>> where the image (sb boot stream) is downloaded via USB device
>> (all DIP switches in position 'off' on the EVK). The
>> CPU's internal bootrom implements a HID device in this mode.
>> Freescale provides a download tool "sb_loader" for this purpose.
>> There is also a GPL'd implementation based on libusb.
> Could you please provide link to GPL tool?
check http://svn.rockbox.org/viewvc.cgi/trunk/utils/imxtools/
The code builds fine against a recent version of libusb. I tested it
against the mx28evk.
>>
>> So back to my problem:
>>
>> I build u-boot from the u-boot-imx repository. This runs fine
>> when booting from SD/MMC or SPI-flash. But the console stays dark
>> when using the USB download mode. USB download works fine with the
>> Freescale provided U-Boot sources together with the imx-bootlets
>> SPL code.
>>
>> Now I digged a little bit deeper to find out the cause:
>>
>> When downloading via USB I saw the SPL running correctly.
>> board_init_ll() (arch/arm/cpu/arm926ejs/mx28/start.S) runs through
>> correctly. Then control is passed back to the bootrom. That's
>> where things end as far as I can see.
>>
>> The 2nd stage of u-boot is not started.
>>
>> The USB boot mechanism is not documented that detailed.
>> Is it possible that the SPL code overwrites the bootroms ivt and
>> in consequence crashes the bootrom's USB code? Any further ideas?
> I'd look at difference in linking scripts and addresses in
> freescale u-boot and new u-boot.
> This might be some memory addressing issues. Had some of this with
> i.MX23. Also, some hardware might be not powered on or is powered
> off by SPL.
That's a good catch. I will check Fabio's idea in just a minute.
Matthias
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] mx28: booting u-boot via USB
2012-01-31 14:03 [U-Boot] mx28: booting u-boot via USB Matthias Fuchs
2012-01-31 14:25 ` Sergey Lapin
@ 2012-01-31 14:53 ` Fabio Estevam
2012-01-31 15:34 ` Matthias Fuchs
2012-02-03 11:23 ` Matthias Fuchs
2 siblings, 1 reply; 7+ messages in thread
From: Fabio Estevam @ 2012-01-31 14:53 UTC (permalink / raw)
To: u-boot
On 1/31/12, Matthias Fuchs <matthias.fuchs@esd.eu> wrote:
> The USB boot mechanism is not documented that detailed.
> Is it possible that the SPL code overwrites the bootroms ivt and
> in consequence crashes the bootrom's USB code? Any further ideas?
Completely untested, but please give it a try:
diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
index 00493b8..313b5c7 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
@@ -201,8 +201,8 @@ void mx28_mem_init(void)
writel(PINCTRL_EMI_DS_CTRL_DDR_MODE_DDR2,
&pinctrl_regs->hw_pinctrl_emi_ds_ctrl_set);
- /* Power up PLL0 */
- writel(CLKCTRL_PLL0CTRL0_POWER,
+ /* Power up PLL0 and USB clocks */
+ writel(CLKCTRL_PLL0CTRL0_EN_USB_CLKS | CLKCTRL_PLL0CTRL0_POWER,
&clkctrl_regs->hw_clkctrl_pll0ctrl0_set);
early_delay(11000);
diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
index 380b120..e55f552 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
@@ -45,7 +45,7 @@ void mx28_power_clock2pll(void)
struct mx28_clkctrl_regs *clkctrl_regs =
(struct mx28_clkctrl_regs *)MXS_CLKCTRL_BASE;
- writel(CLKCTRL_PLL0CTRL0_POWER,
+ writel(CLKCTRL_PLL0CTRL0_EN_USB_CLKS | CLKCTRL_PLL0CTRL0_POWER,
&clkctrl_regs->hw_clkctrl_pll0ctrl0_set);
early_delay(100);
writel(CLKCTRL_CLKSEQ_BYPASS_CPU,
^ permalink raw reply related [flat|nested] 7+ messages in thread* [U-Boot] mx28: booting u-boot via USB
2012-01-31 14:53 ` Fabio Estevam
@ 2012-01-31 15:34 ` Matthias Fuchs
0 siblings, 0 replies; 7+ messages in thread
From: Matthias Fuchs @ 2012-01-31 15:34 UTC (permalink / raw)
To: u-boot
Hi Fabio,
On 31.01.2012 15:53, Fabio Estevam wrote:
> On 1/31/12, Matthias Fuchs <matthias.fuchs@esd.eu> wrote:
>
>> The USB boot mechanism is not documented that detailed.
>> Is it possible that the SPL code overwrites the bootroms ivt and
>> in consequence crashes the bootrom's USB code? Any further ideas?
>
> Completely untested, but please give it a try:
Good idea. But it does not help. I expect, that the bootrom enables
all required clocks. As long as the SPL does not turn them of they
should stay enabled because of the set/clear-register pairs.
Matthias
>
> diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
> b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
> index 00493b8..313b5c7 100644
> --- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
> +++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
> @@ -201,8 +201,8 @@ void mx28_mem_init(void)
> writel(PINCTRL_EMI_DS_CTRL_DDR_MODE_DDR2,
> &pinctrl_regs->hw_pinctrl_emi_ds_ctrl_set);
>
> - /* Power up PLL0 */
> - writel(CLKCTRL_PLL0CTRL0_POWER,
> + /* Power up PLL0 and USB clocks */
> + writel(CLKCTRL_PLL0CTRL0_EN_USB_CLKS | CLKCTRL_PLL0CTRL0_POWER,
> &clkctrl_regs->hw_clkctrl_pll0ctrl0_set);
>
> early_delay(11000);
> diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
> b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
> index 380b120..e55f552 100644
> --- a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
> +++ b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
> @@ -45,7 +45,7 @@ void mx28_power_clock2pll(void)
> struct mx28_clkctrl_regs *clkctrl_regs =
> (struct mx28_clkctrl_regs *)MXS_CLKCTRL_BASE;
>
> - writel(CLKCTRL_PLL0CTRL0_POWER,
> + writel(CLKCTRL_PLL0CTRL0_EN_USB_CLKS | CLKCTRL_PLL0CTRL0_POWER,
> &clkctrl_regs->hw_clkctrl_pll0ctrl0_set);
> early_delay(100);
> writel(CLKCTRL_CLKSEQ_BYPASS_CPU,
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] mx28: booting u-boot via USB
2012-01-31 14:03 [U-Boot] mx28: booting u-boot via USB Matthias Fuchs
2012-01-31 14:25 ` Sergey Lapin
2012-01-31 14:53 ` Fabio Estevam
@ 2012-02-03 11:23 ` Matthias Fuchs
2012-02-03 12:52 ` Matthias Fuchs
2 siblings, 1 reply; 7+ messages in thread
From: Matthias Fuchs @ 2012-02-03 11:23 UTC (permalink / raw)
To: u-boot
On 31.01.2012 15:03, Matthias Fuchs wrote:
> Hi,
>
> I have a problem booting the current u-boot-imx version
> on a MX28EVK via USB. The i.MX28 CPU supports a special boot mode
> where the image (sb boot stream) is downloaded via USB device
> (all DIP switches in position 'off' on the EVK). The
> CPU's internal bootrom implements a HID device in this mode.
> Freescale provides a download tool "sb_loader" for this purpose.
> There is also a GPL'd implementation based on libusb.
>
> So back to my problem:
>
> I build u-boot from the u-boot-imx repository. This runs fine
> when booting from SD/MMC or SPI-flash. But the console stays dark
> when using the USB download mode. USB download works fine with the
> Freescale provided U-Boot sources together with the imx-bootlets
> SPL code.
>
> Now I digged a little bit deeper to find out the cause:
>
> When downloading via USB I saw the SPL running correctly.
> board_init_ll() (arch/arm/cpu/arm926ejs/mx28/start.S) runs through
> correctly. Then control is passed back to the bootrom. That's
> where things end as far as I can see.
>
> The 2nd stage of u-boot is not started.
>
> The USB boot mechanism is not documented that detailed.
> Is it possible that the SPL code overwrites the bootroms ivt and
> in consequence crashes the bootrom's USB code? Any further ideas?
It figured out a (dirty) fix for my issue.
It really seems that the mx28 bootrom is unhappy with the state
of the CPU after the SPL code ran through. There are two things that
make the bootrom more happy and finally start u-boot from RAM:
1) cpu_init_crit() from arch/arm/cpu/arm926ejs/mx28/start.S
must not be called.
2) The ARMs fast interrupt mode must not be enabled when passing control
back to the bootrom.
The latter is easy to fix. Either we turn it off at the end
of _reset or we do not even turn it on when switching to SVC32 mode.
BTW, the bootrom calls _reset already in SVC32 mode, so we could
kick those lines away.
Disabling cpu_init_crit() has a sideeffect on get_ram_size()
in mx28_mem_get_size(). Without disabling caches get_ram_size()
freezes. Using a fixed RAM size works. Also calling get_ram_size
with a max. of 0x20000000 (instead of the default 1GB) works. Hmm.
Idea ideas how to fix this? Best things would be to revert
the changes cpu_init_crit() does. Or we could move the
get_ram_size() call to the 2nd stage when U-Boot is started
in RAM from bootrom (before relocation). In this case we must
modfiy get_Ram_size to start just behind u-boot code in RAM.
Here are my current modifications:
diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
index 00493b8..257db6b 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
@@ -182,7 +182,11 @@ void mx28_mem_get_size(void)
da = vt[4];
vt[4] = (uint32_t)&data_abort_memdetect_handler;
- sz = get_ram_size((long *)PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE);
+ /*
+ * without start.S:cpu_init_crit() get_ram_size does not work
+ * with PHYS_SDRAM_1_SIZE = 0x40000000
+ */
+ sz = get_ram_size((long *)PHYS_SDRAM_1, 0x20000000); /* PHYS_SDRAM_1_SIZE);*/
writel(sz, HW_DIGCTRL_SCRATCH0);
writel(sz, HW_DIGCTRL_SCRATCH1);
diff --git a/arch/arm/cpu/arm926ejs/mx28/start.S b/arch/arm/cpu/arm926ejs/mx28/start.S
index 2cd4d73..ba48fed 100644
--- a/arch/arm/cpu/arm926ejs/mx28/start.S
+++ b/arch/arm/cpu/arm926ejs/mx28/start.S
@@ -180,11 +180,26 @@ _reset:
* not when booting from ram!
*/
#ifndef CONFIG_SKIP_LOWLEVEL_INIT
- bl cpu_init_crit
+/*
+ * not fine for bootrom in USB mode mode but required for get_mem_size()
+ * in mx28_mem_init()
+ */
+/* bl cpu_init_crit */
#endif
bl board_init_ll
+ /*
+ * turn of fast interrupt mode
+ * TODO: alternatively we can disable the code above (set cpu to
+ * SVC32 mode) because the bootrom already setup cpsr to 0x53
+ * I don't expect that the SPL code requires the fast interrupt
+ * mode at all.
+ */
+ mrs r0,cpsr
+ bic r0,r0,#0x80
+ msr cpsr,r0
+
pop {r0-r12,r14}
bx lr
Matthias
^ permalink raw reply related [flat|nested] 7+ messages in thread