[U-Boot] mx28: booting u-boot via USB

[U-Boot] mx28: booting u-boot via USB

[Matthias Fuchs]

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?

Matthias

[U-Boot] mx28: booting u-boot via USB

[Sergey Lapin]

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.

[U-Boot] mx28: booting u-boot via USB

[Fabio Estevam]

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,

[U-Boot] mx28: booting u-boot via USB

[Matthias Fuchs]

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

[U-Boot] mx28: booting u-boot via USB

[Matthias Fuchs]

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,
> 

[U-Boot] mx28: booting u-boot via USB

[Matthias Fuchs]

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

[U-Boot] mx28: booting u-boot via USB

[Matthias Fuchs]

Fixed! Patch follows.