MCF54455, M54455EVB. U-Boot can't boot Linux.

[Claude_Sylvain]

Hello,

We are trying to boot Linux from a brand new M54455EVB (Rev.2) box.
After setting SW1-3 to OFF, and not ON as stated in some documents, U-Boot get alive through the UART0 RS-232 DB9 communication port.

Remark:  The RS-232 female to female cable included with the EVB have not the correct pinout to connect the EVB box directly to a PC COMx port.  In other words, this cable is not a Null Modem cable.  So, we have to modify it, before being able to communicate with a terminal emulator (on the PC).

U-Boot display the following message:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
U-Boot 1.2.0-g20da9684-dirty (Aug 17 2007 - 15:10:26)

CPU:   Freescale MCF54455 (Mask:48 Version:1)
       CPU CLK 266 Mhz BUS CLK 133 Mhz FLB CLK 33 Mhz
       INP CLK 33 Mhz VCO CLK 533 Mhz
Board: Freescale M54455 EVB
I2C:   ready
DRAM:  256 MB
FLASH: 16.5 MB
In:    serial
Out:   serial
Err:   serial
Net:   FEC0 [PRIME], FEC1
IDE:   Bus 0: not available
->
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


When trying to boot Linux with the "bootm" command, U-Boot display an error and boot process is aborted.  The error message displayed by U-Boot is the following:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-> bootm
## Booting image at 40010000 ...
Bad Magic Number
->
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


Is this error come from a bad dipswitch configuration on the EVB?

Can we resolve this problem by flashing a more recent release of Linux on the EVB?


Regards,

Claude Sylvain
Electro-Technica inc.

[simath]

CAVEAT:  I haven't verified all of what I'm about to write so...

OK, here goes:

From what you wrote before, U-Boot seems to have been programmed into the Intel Flash (flash 1).

SW1-3 goes to the CPLD, which simply "swaps" the connection of the MCU CS0 and CS1 lines to the two flash devices.  When SW1-3 = ON (Default), then CS0 => Flash 0 (smaller Atmel Flash), and CS1 => Flash 1 (bigger Intel Flash).  When SW1-3 = OFF (which works for you), these are swapped, and CS0 => Flash 1.

The MCU (on reset) boots from CS0, and loads its reset vector from 0x4 (OK, you knew that already, sorry!).

I believe that U-Boot "copies" itself into SDRAM and executes there, rather than from flash.  The SDRAM is mapped to 0x4000_0000.  I don't know this for sure, but this is usually what happens.

The BSP manual states that U-Boot maps CS0 to 0x0400_0000.  The upper address lines don't go to the (512k) Atmel flash anyway, so this looks like 0x0 to the flash.  If CS0 is connected to Flash 1 (Intel), same thing - 0x0400_0000 looks to the flash like 0x0.  But, after booting, U-Boot maps CS0 to 0x0400_0000 and CS1 to 0x0 (from the comments in 3.2 of the BSP guide).  That is valid for the default SW1-3 setting.  If it's swapped, then the CS0/CS1 address mappings are the same, but they'd go to the opposite flash devices, unless U-Boot is smart enough to read the CPLD switch register to detect this change.  U-Boot must at least be smart enough to know what type of flash it's talking to (for the cp.b command to work), since they require different command sets for programming.

Bottom line:  Since you have CF Flasher working, why not set SW1-3 ON (normal CS mapping), and program the flash (at 0x0400_0000) with the U-Boot image (which shows as 0xFF now)?  Then, BOTH flash devices should have a U-Boot image at 0x0.  Hopefully then U-Boot will run with the default switch settings.  This should get you back to the default configuration.  Then you can use the BSP instructions to program flash 1 with the kernel image.

[Claude_Sylvain]

I understand now.

The thing I was not understanding is the initial CS0 behavior (before chip select configuration) that make U-Boot (normally mapped at 0x04000000) appearing also at 0x00000000.

I just finished to Flash U-Boot at 0x04000000 with SW1-3 set to ON.

Now, U-Boot come alive with SW1-3 set to ON  :smileyhappy:

I am ready to flash the kernel.  I will do like you suggest to me (using U-Boot).  I have tried with CF-Flasher, but it is not working.


Thank you very much simath.

Claude.

[mnorman]

I realize I'm a little late to the party here, but I would like to add a few points here.   It really sounds like you received one of the early prototype boards due to both the switch settings and the serial cable (the kits do ship with null modem cables today, the first few proto's did not).

The default switch settings are:

    SW1:   SW3:
1 - ON     OFF
2 - OFF    ON
3 - ON     OFF
4 - OFF    ON
5 - OFF    OFF
6 - OFF    ON
7 - OFF    ON
8 - OFF    ON

The latest Linux BSP can be found here:
http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=0127260061033202A9

This includes a the U-Boot source and a pre-built image in the /images directory on the Linux ISO.  As you know, CF Flasher can be used to program this image into the boot flash.  Just make sure the SW1-3 switch is in the ON position first.  If using the binary image, the base address should be set to 0x04000000.

After U-Boot is running, it can be used to program the Linux kernal and root file system into the code flash (CF Flasher will work too, but it is slower).  There are pre-built versions of these in the kernel and rootfs in the /image directory also.   A TFTP server is required for this method:

-> set ipaddr x.x.x.x
-> set serverip x.x.x.x
-> set gatewayip x.x.x.x
-> set netmaskk x.x.x.x
-> save
-> erase bank 2
-> t 40010000 rootfs.jffs2
-> cp.b 40010000 500000 ${filesize}
-> t 40010000 uImage
-> cp.b 40010000 0 ${filesize}
-> bootm 0

-mnorman

[Claude_Sylvain]

Hello mnorman,


Thank you for the additionnal information and advice.


Claude.

[simath]

YIKES - I think we can now see what you're problem is - but you might need one of the BSP experts to confirm this.

The idea of two flash parts (kudos to Freescale designers for this) is that the U-Boot image is in the smaller part, which you'd never need to over-write, thus there would never be any possibility of corrupting it (and loosing TFTP image load capability).  So, even if you totally screw up the Linux image (which goes in the larger Intel flash), you'd be able to recover your board.

Somehow (???) it appears that the U-Boot image for your board was written into the Intel flash (thus it comes alive when SW1-3 is OFF = Boot from Flash 1).  The DEFAULT configuration (look in the printed fold-out that came with the board) is to boot from Flash 0 (SW1-3 is ON).

As for the LEDs - some of that behaviour is controlled by the FPGA which is independent of the firmware running.  The flashing does sound suspicious though (i.e. that it works with SW1-3 = ON, but U-Boot won't run).  I don't know how FS does the initial image load when producing these boards (if they pre-program the flash parts prior to stuffing, or use BDM to load).  It's possible (if they use BDM to load blank parts) that SW1-3 was set wrong and U-Boot got programmed to the wrong place from the factory?!?

So... To fix this (you'll probably need K. Mahan or somebody in the know to confirm this):

I think you should use the U-Boot cp function to write the working U-Boot image into Flash 0, change SW1-3 back to the default setting (to map CS0 to Flash 0), and follow the BSP instructions to load the kernel and file system images.

See Table 7 (4.6) in the EVM manual - but your working configuration swaps CS0 and CS1 to the two flash devices.  Note that flash 0 isn't big enough to hold the kernel image.

You COULD, alternatively, continue to boot from flash 1 AND copy the kernel image there too (just to get Linux running).

[Claude_Sylvain]

Hello simath,

- After reading your response, I have done some hours of exploration on
  the M54455EVB, here is the results:


- When I put SW1-3 to OFF (for booting the Kernel in Flash 1):

    - U-Boot come alive.

    - From U-Boot, if I type "md 0x00000000", the displayed memory content
      is all set to 0xFF.  The content of Flash 1 I erased accidentally
      yesterday.

    - From U-Boot, if I type "md 0x04000000", the displayed memory match
      the one contained in the ISO disk file "/images/u-boot.bin".

    - After launching CF Flasher 3.1, and configuring it properly, if I
      click on "Memory Window" button, and type "0x00000000" in
      "Address 0x" field, I have the same result as with "md 0x00000000"
      in U-Boot.

    - Still from CF Flasher 3.1, if I type "0x04000000" in "Address 0x"
      field, I have the same result as with "md 0x04000000" in U-Boot.


- When I put SW1-3 to ON (for booting U-Boot in Flash 0):

    - U-Boot DO NOT come alive.

    - After launching CF Flasher 3.1, and configuring it properly, if I
      click on "Memory Window" button, and type "0x00000000" in
      "Address 0x" field, the displayed memory match the one contained
      in the ISO disk file "/images/u-boot.bin".

    - Still from CF Flasher 3.1, if I type "0x04000000" in "Address 0x"
      field, the displayed memory content is all set to 0xFF.  The content
      of Flash 1 I erased.


- This is really strange !!!

- How come U-Boot can come alive when U-Boot "md" command and CF-Flasher
  "Memory Window" show that U-Boot is mapped at 0x04000000 ???


Claude.

[simath]

That looks like the vector table, but it shouldn't be there.  Make sure to check the SW1[3] setting to ensure that Flash0 is the boot device.  There was something mentioned in the BSP release notes about some boards being shipped with incorrect switch settings.  Anyway, if this were wrong you shouldn't see U-Boot start...

Check all the switch settings (also for Boot Mode) before you try to program Flash1

[Claude_Sylvain]

When I set SW1-3 to OFF, U-Boot come alive.
When I set SW1-3 to ON, U-Boot do not come alive.

Note that EVB board behaviour is the same for both case (SW1-3=OFF and SW1-3=ON).  i.e.: 1 orange LED and 1 green LED are flashing, and the seven-segment display display "00".

Ok, I check switch settings.


Claude.

[Claude_Sylvain]

In the document, I do not find the default configuration for SW1, SW3 and SW5.

Here is my EVB SW1, SW3 and SW5 configuration:

            1       2          3         4          5         6         7          8
SW1   ON    OFF    OFF    OFF    OFF    OFF    OFF    OFF
SW3   OFF  ON      OFF    ON      OFF    ON      ON      ON
SW5   OFF  OFF    OFF    OFF

Is this configuration is correct ?

Claude.

[simath]

Indeed the EVM User's Manual is not a good reference (use the BSP guide instead).

I've re-flashed the Linux image several times (with my own custom builds) with no issues.  I'd suggest you do this anyway, even if you get the board to boot.  The image burned by the production guys is probably NOT the latest from kmahan (14-Dec.-2007 I think).  He's fixed several things in this build.

As a quick check, do the following:

In the U-Boot menu, type:

->md 0x0

You should see something like the following, if there is indeed an image in the Intel flash chip:

00000000: 27051956 39aa1a6e 4761e897 002ce000    '..V9..nGa...,..
00000010: 40020000 40020000 0d1e9eba 050c0200    @...@...........
00000020: 4c696e75 78204b65 726e656c 20496d61    Linux Kernel Ima
00000030: 67650000 00000000 00000000 00000000    ge..............
00000040: 60084249 561a0000 00004ef9 402d8000    `.BIV.....N.@-..

[Claude_Sylvain]

Hello simath,

I have the following:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-> md 0x0
00000000: 400049c0 00000400 04017a46 04017a46    @.I.......zF..zF
00000010: 04017a46 04017a46 04017a46 04017a46    ..zF..zF..zF..zF
00000020: 04017a46 04017a46 04017a46 04017a46    ..zF..zF..zF..zF
00000030: 04017a46 04017a46 04017a46 04017a46    ..zF..zF..zF..zF
00000040: 04017a46 04017a46 04017a46 04017a46    ..zF..zF..zF..zF
00000050: 04017a46 04017a46 04017a46 04017a46    ..zF..zF..zF..zF
00000060: 04017a46 04017b6c 04017b6c 04017b6c    ..zF..{l..{l..{l
00000070: 04017b6c 04017b6c 04017b6c 04017b6c    ..{l..{l..{l..{l
00000080: 04017a46 04017a46 04017a46 04017a46    ..zF..zF..zF..zF
00000090: 04017a46 04017a46 04017a46 04017a46    ..zF..zF..zF..zF
000000a0: 04017a46 04017a46 04017a46 04017a46    ..zF..zF..zF..zF
000000b0: 04017a46 04017a46 04017a46 0401f4aa    ..zF..zF..zF....
000000c0: 04017a46 04017a46 04017a46 04017a46    ..zF..zF..zF..zF
000000d0: 04017a46 04017a46 04017a46 04017a46    ..zF..zF..zF..zF
000000e0: 04017a46 04017a46 04017a46 04017a46    ..zF..zF..zF..zF
000000f0: 04017a46 04017a46 04017a46 04017a46    ..zF..zF..zF..zF
->
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


So, it is clear now, that Linux have not been flashed on that EVB.


Claude.

[simath]

You need to type "bootm 0".  The U-Boot image and kernel image are stored in two different flash devices (two different chip select addresses).  This is all described in the BSP user's manual:

6. Boot the kernel

-> bootm 0x0000000

[Claude_Sylvain]

Hello simath,

Just to mention that in the M54455EVB user manual (M54455EVBUM.pdf) the only place that refer to "bootm" is in chapter 3, step 8 of "The basic installation steps are as follows:", where it is write to simply type "bootm"!?

Your are right, there is a boot procedure in the BSP user manual ("/Help/software/User_Manual.pdf") on the ISO disk.

But unfortunatly, typing "bootm 0" or "bootm 0x0000000" do not solve my problem.  I get the same result as typing "bootm" (without parameter).

Is it possible that Linux was flashed in another "non-standard" location on the M54455EVB we have?
Or, is it possible that the production guy have forgot to flash Linux on that EVB?

I think I will have no choice to flash Linux by myself if I want to get it running.


Thank you for your help.

Claude.