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

[Matthias Fuchs <matthias.fuchs@esd.eu>]

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