Help with serial boot on 54455EVB (loading U-boot from SPI flash)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Help with serial boot on 54455EVB (loading U-boot from SPI flash)

Jump to solution
3,395 Views
lmhdoms
Contributor III

Hello All,

 

I am trying to boot the 54455EVB from the SPI flash, but I am having some problems. Problem description and my setup:

 

54455EVB board

Freescale BSP: MCFV4M_20090729_ltib

Application note: AN3514, Rev 0

 

First I build a preloader based on AN3514, programmed the SPI flash using the tools included in the U-Boot and booted. This worked without problems.

 

Next exercise is to place U-Boot in SPI flash, and let the boot loader copy it to SDRAM and execute it from there. So I extracted the U-Boot source code from the BSP. Then I build U-Boot using the configuration: M54455EVB_stm33_config. This configuration is provided on the BSP and should support serial boot. The serial boot flash header is however not provided on the BSP for 54455EVB so I made it myself based on the AN3514. Basically I set the length of the bootloader code to 0x312. This is the size of the code needed to boot, init SDRAM, copy U-Boot to SDRAM and transfer execution.

 

When the system is booted, the process stops at different times. Sometimes nothing happens, other times I can boot U-Boot until:

 

U-Boot 2008.10 (Mar 19 2010 - 14:05:58)

 

CPU:   Freescale MCF54455 (Mask:48 Version:1)

       CPU CLK 116 Mhz BUS CLK 58 Mhz FLB CLK 29 Mhz

       INP CLK 33 Mhz VCO CLK 233 Mhz

Board: Freescale M54455 EVB

I2C:      ready

SPI:   ready

DRAM:  256 MB

 

Then the system halts and I don’t know why. I notice two things. First the CPU clocks are much lower than when the board is booted normally (from NOR flash). Could this cause the system to hang? How to change the clocks? Second, using CF Flasher utility I can read the on-chip SRAM. It shows that much more than 0x312 bytes are loaded from the SPI flash. I would expect only 0x312 to be loaded according to the CPU reference manual. Loading two much should however not be a problem, as execution is transferred to SDRAM. I expect that the above dump comes from booting from SDRAM, but I can not check it as the CF Flasher util does not support reading SDRAM.

 

I can attach source code, hex dumps.. whatever could be usefull, just let me know.

 

Any comments or help on how to complete the boot is much appreciated.

Labels (1)
0 Kudos
1 Solution
1,049 Views
lmhdoms
Contributor III

Hi Wolfgang,

 

Just to finish my initial posting: My problem was a too low PLL multiplier in the sbfheader. Now my header looks like this:

 

 

03 12 03 34 12 78 56 00 00 80 06 57 19 07 58 FF 00 10 98

 A memory read of SBFSR and SBFCR returns:

 

 

fc0a0018: 03120003

which is as expected. If your resulting BLDIV differs from the one set in the sbfhdr, I guess it is because the SBF shift clock adjustment decided to use another divider.

 

One more change I made is that executing the inital code from the serial flash did not start when SP was set to 0. Instead I set the SP (and PC):

 

 

80000000: 80007f60 8000008c

Sorry, I don't have suggestions for your other issues at this moment.

 

Best regards,

- Lars

 

 

 

View solution in original post

0 Kudos
9 Replies
1,049 Views
w_wegner
Contributor III

Hi,

 

I am not sure which problem you are hitting, there might be several... It seems your U-Boot is stuck at the stage where it tries to access the flash. Is there still a parallel flash present on any chip select?

 

I am trying to use/using SBF on a custom board with MCF5445x, and ran into several problems with this.

 

First, one has to program the PLL configuration manually, this is not done from the standard code - at least this is how I understand the badly messed up stuff in cpu/mcf5445x/speed.c.

Second, for some reason I don't understand, I had to set up the CS0 configuration in the first assembler lines to prevent the CPU from getting stuck somewhere very early in the code. (I am using CS0 for accessing an FPGA, which is never accessed in U-Boot, but still this was necessary.)

Third, in case you really want to disable any parallel flash, you might have to set these in the board config:

 

#define CONFIG_SERIAL_FLASH#define CONFIG_SYS_NO_FLASH

 

As for the PLL setup, my first assembly lines look like this:

 

 

asm_dram_init: move.w #0x2700,%sr  /* Mask off Interrupt */ move.l #0xfc0c4000, %a0 move.l #0x0a770F31, (%a0) move.l #0xfc008004, %a0 move.l #0x1fff0001, (%a0)

I am using an external 50MHz oscillator, 250MHz core, 125MHz DDR2 and FlexBus at 31.25 MHz. Maybe you also need to completely set up CS0 for your parallel flash, I really don't know.

 

Hope it helps!

 

Regards,

Wolfgang

 

0 Kudos
1,049 Views
lmhdoms
Contributor III

Hi Wolfgang,

 

Thanks for your comments, they help. I will check the flash chip selects (I have actually two flash chips) and you pointed me in the direction of the speed.c and setting up the PLL. Here the explanation could be for my low clock speeds.

 

Since my board boots perfectly from parallel NOR flash but not from serial flash, I assume that I need to setup all chip selects, clocks etc. identically. Is this a correct assumption? If not, what could be different in the two boot modes? (apart for the initial serial flash reads).

 

My boot stops at random places, I guess it could be caused by having some bad timings setup for the SDRAM. Again, the board works with parallel boot, so I will check what SDRAM timings it uses. If the SDRAM timings are derived from the CPU clock, then no wonder why the SDRAM has problems.

 

In start.S I notice that interrupts are not initially disabled, they are disabled much later - when the execution jumps to SDRAM. Any reason not to disable interrupts during boot load?

 

Regards,

- Lars

 

0 Kudos
1,049 Views
w_wegner
Contributor III

Hi Lars,

 

sorry I can not comment on all of your questions...

I still have some problems getting SBF to boot reliably - and I have no other chance, as there is no parallel flash on my board. :smileywink:

 

SDRAM timing is indeed derived from CPU clock, so if CPU clock is too low, your SDRAM timing will be too low, too. I have no experience what this may cause, in some circumstances I was surprised how well SDRAM behaves when used way out of spec, in other cases I was surprised that a seemingly not so important parameter made SDRAM unaccessible at all.

 

However, SDRAM setup is done dfferently for SBF and parallel boot. For SBF, the SDRAM init is done in start.S, for parallel boot it is done in the board.c file (in your case board/freescale/m54455evb/m54455evb.c) - maybe something got lost when translating initdram() to assembly?

 

Concerning the interrupts, I would say they are in fact disabled at the very beginning of code execution. For SBF, this is right after the label asm_dram_init (which is the first code executed for SBF), for parallel mode this is after the label _start.

 

Regards,

Wolfgang

 

0 Kudos
1,049 Views
lmhdoms
Contributor III

Hi Wolfgang,

 

Thanks for your comments, I did not expect you to comment on all my thoughts. Well I think you are right, but as for the interrupts, I don't see they are disabled. After the label asm_dram_init in \mcf5445x\start.S the RAMBAR and SP is initialized, then CS0 is setup.

 

Now the good news is that I got the clock up and now I can get U-Boot to run from SBF. My PLL multiplier in the SBFHDR was too low, so the vco clock was too low.

 

What reliability problem are you facing?

 

Regards,

- Lars

0 Kudos
1,049 Views
w_wegner
Contributor III

Hi Lars,

 

which U-Boot version are you using? I used the latest git version, maybe not disabling the interrupts is in fact an error of the much older U-Boot from the LTIB? I did not have a look into that one...

 

My reliability problem is that U-Boot sometimes does not start from SBF after power-up. It simply sits there and does nothing, it seems. (I set some LEDs from the first lines of assembler code, and so I can see that not even the first stages are executed. I did not hook up a logic analyzer to monitor the SBF hardware yet.)

 

Another problem is that sometimes after re-compiling U-Boot, it locks up at some place and I have to change code (especially, add or remove various printf's at the beginning of console.c/console_setfile()) to make it run again. The problem is reproducible with several startups, it is only depending on the code compilation/linking. Unfortunately my debugger refuses to correctly stop at breakpoints after relocation, so I can't even check with the debugger what is going wrong.

 

The last ugly thing is that I learnt from the revised errata sheet that the internal watchdog should not be used in SBF mode, so we have to design in an external one.

 

But I guess this is just the normal things that happen when using a new processor in a design...

 

Regards,

Wolfgang

0 Kudos
1,049 Views
lmhdoms
Contributor III

Hi Wolfgang,

 

I am using U-Boot 2008.10, it came with the Freescale BSP (see my first post).

 

About your startup problems. What comes to my mind is; are the boot mode pins set correct? Is the SPI flash clock set correct (in the sbfhdr), it should start out at the lowest clock. Do you use the fast read feature? Are you able to attach a BDM module and read the on-chip SRAM to see if the code is loaded?

 

The compilation problems are weird. Could it somehow be connected with the boot problem, when loading data from the serial flash? By the way, which SDRAM and SPI flash devices do you use?

 

Best regards,

- Lars

 

 

0 Kudos
1,049 Views
w_wegner
Contributor III

Hi Lars,

 

thank you for the hints.

 

The Flash is a MX25L6405MI-20G, we are using DDR2 SDRAM 2 pcs. of MT47H32M16HR-3 IT.

 

This is my SBF header - as far as I remember, there were strange things concerning BLDIV anyways:

 

0000000 03 ff 03 00 00 00 00 00 00 00 00 00 00 00 00 000000020 64 0a 20

(See my older posting here concerning BLDIV - sorry for the bad formatting there)

 

BOOTMOD is set correctly, I have both pins shorted and a pullup to 3,3V with a jumper to GND to allow programming the serial flash via BDM - yes, it is quite annoying but with BOOTMOD=11 and an empty serial flash, you can not connect to the CPU via BDM!

 

Connecting to the board via BDM in case of boot failure is also quite difficult, because my BDM pod (PEEDI) always forces a reset and stops the CPU after the target powers up (which is the same condition as when I plug in the BDM connector), so I can not debug this without intrusion.

 

The compilation problem is definitely not related to the boot problem because it also happens when I start U-Boot entirely from RAM via the debugger.

 

Regards,

Wolfgang

 

 

0 Kudos
1,050 Views
lmhdoms
Contributor III

Hi Wolfgang,

 

Just to finish my initial posting: My problem was a too low PLL multiplier in the sbfheader. Now my header looks like this:

 

 

03 12 03 34 12 78 56 00 00 80 06 57 19 07 58 FF 00 10 98

 A memory read of SBFSR and SBFCR returns:

 

 

fc0a0018: 03120003

which is as expected. If your resulting BLDIV differs from the one set in the sbfhdr, I guess it is because the SBF shift clock adjustment decided to use another divider.

 

One more change I made is that executing the inital code from the serial flash did not start when SP was set to 0. Instead I set the SP (and PC):

 

 

80000000: 80007f60 8000008c

Sorry, I don't have suggestions for your other issues at this moment.

 

Best regards,

- Lars

 

 

 

0 Kudos
1,049 Views
w_wegner
Contributor III

Hi Lars,

 

thank you for the hint with PC/SP setting. I will try this and see if startup is more reliable then.

 

I am not too concerned about the other problems as I have found a way to work around the lockup (inserting some printf()) and I don't mind if the SBF clock is slightly lower - there are other things delaying my boot process, so some milliseconds in this early stage are completely neglectible.

 

The real pity is the unusable watchdog, as an external watchdog is always less comfortable to use, IMHO.

 

Best regards,

Wolfgang

 

0 Kudos