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,

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