mx51evk01 won't boot

Bug #812555 reported by Paul Larson
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
LAVA Validation Lab
Triaged
Medium
Dave Pigott
Linaro Linux
New
Undecided
Unassigned

Bug Description

U-Boot 2011.03-rc1 (Feb 09 2011 - 01:27:08)

CPU: Freescale i.MX51 family rev3.0 at 800 MHz
Board: MX51EVK 1.0 [POR]
DRAM: 512 MiB
MMC: FSL_ESDHC: 0, FSL_ESDHC: 1
In: serial
Out: serial
Err: serial
Net: got MAC address from fuse: 00:04:9f:01:2b:37
FEC
Hit any key to stop autoboot: 0
reading boot.scr

** Unable to read "boot.scr" from mmc 0:2 **
reading uImage

** Unable to read "uImage" from mmc 0:2 **
Booting from net ...
BOOTP broadcast 1
BOOTP broadcast 2
DHCP client bound to address 192.168.1.108
Using FEC device
TFTP from server 0.0.0.0; our IP address is 192.168.1.108; sending through gateway 192.168.1.1
Filename 'uImage'.
Load address: 0x90800000
Loading: *
TFTP error: 'File not found' (1)
Not retrying...
Wrong Image Format for bootm command
ERROR: can't get kernel image!

Paul Larson (pwlars)
Changed in lava-lab:
status: New → Triaged
importance: Undecided → Medium
assignee: nobody → Dave Pigott (dpigott)
Revision history for this message
Dave Pigott (dpigott) wrote :

The image as it stood seemed to have got corrupted - possibly the SD card has burned out. I've built a new image on a 16GB SDHC and it now seems to be ok.

Revision history for this message
Paul Larson (pwlars) wrote :

It needs fixing still, hostname on master image is still set to linaro, not master, and the partitioning seems to be off. It looks like there's a boot and rootfs, but no test partitions. Also, fdisk -l reports strangeness:
root@linaro:~# fdisk -l /dev/mmcblk1

Disk /dev/mmcblk1: 3965 MB, 3965190144 bytes
255 heads, 63 sectors/track, 482 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

        Device Boot Start End Blocks Id System
/dev/mmcblk1p1 1 7 53216 b W95 FAT32
Partition 1 has different physical/logical beginnings (non-Linux?):
     phys=(1023, 254, 63) logical=(0, 0, 2)
Partition 1 has different physical/logical endings:
     phys=(1023, 254, 63) logical=(6, 159, 26)

Revision history for this message
Dave Pigott (dpigott) wrote :

I didn't repartition or make the usual, because I wasn't sure quite what I was looking at because the whole thing looks weird, along with my head being a bit weird yesterday. Didn't want to do anything that might come back and bite me.

However, if you do fidisk -lc /dev/mmcblk1 (I always do the 'c' option because you then don't get all the non-dos compliant compaints) you get:

Disk /dev/mmcblk1: 3965 MB, 3965190144 bytes
255 heads, 63 sectors/track, 482 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

        Device Boot Start End Blocks Id System
/dev/mmcblk1p1 1 7 53216 b W95 FAT32

I'll look into fixing this this morning.

Revision history for this message
Dave Pigott (dpigott) wrote :

Ah. A little more investigation:

root@linaro:~# ls -l /dev/disk/by-label/
total 0
lrwxrwxrwx 1 root root 15 Jan 1 00:00 boot -> ../../mmcblk1p1
lrwxrwxrwx 1 root root 15 Jan 1 00:00 rootfs -> ../../mmcblk0p3
root@linaro:~#

There are two SDHC cards in the mx51. The boot is coming off the lower one (mmcblk1) and the fs is on the upper one (mmcblk0) so I'm assuming that it's mmcblk0 that I need to amend the partitioning on.

Revision history for this message
Spring Zhang (qzhang) wrote :

yes, it's wrong to put boot to upper SD card, why the partition made to upper SD card, is there two partitions labeled boot? You can clean the upper SD card partition table.

Revision history for this message
Dave Pigott (dpigott) wrote :

OK. All reconfigured. The card in mmcblk1 is only there to enable system to boot. However, there is a problem with the board in that during initial boot, we get:

Net: got MAC address from fuse: 00:04:9f:01:2b:37
FECWarning: failed to set MAC address

 To get round this, once the board is booted, I had to do:

ifconfig eth0 hw ether 00049f012b37

springz is looking into why this might be.

Revision history for this message
Spring Zhang (qzhang) wrote :

The board got right MAC addr. but failed to set MAC address which was read, I think it's a kernel bug.
I'll confirm with a mx51 board, feedback later.

Revision history for this message
Spring Zhang (qzhang) wrote :

It caused by new uboot issue not kernel, in the first comment you post, there is no error about MAC addr. uboot version is U-Boot 2011.03-rc1 (Feb 09 2011 - 01:27:08). Now the July.20 image uboot version is U-Boot 2011.06 (Jul 15 2011 - 08:05:56).

Revision history for this message
Spring Zhang (qzhang) wrote :

I think it should be introduced by: a8834193c3ff7b731599e4e4544fe01600e75e42,
Add Ethernet hardware MAC address framework to usbnet. http://git.linaro.org/gitweb?p=boot/u-boot-linaro-stable.git;a=commit;h=a8834193c3ff7b731599e4e4544fe01600e75e42

Revision history for this message
Spring Zhang (qzhang) wrote :

Complete log:
U-Boot 2011.06 (Jul 15 2011 - 08:05:56)

CPU: Freescale i.MX51 family rev3.0 at 800 MHz
Reset cause: POR
Board: MX51EVK
DRAM: 512 MiB
MMC: FSL_ESDHC: 0, FSL_ESDHC: 1
In: serial
Out: serial
Err: serial
Net: got MAC address from fuse: 00:04:9f:01:06:9f
FECWarning: failed to set MAC address

Hit any key to stop autoboot: 0

Revision history for this message
Spring Zhang (qzhang) wrote :

An ugly workaround is adding the following line to /etc/rc.local:
ifconfig eth0 hw ether 00049f012b37
dhclient eth0

Another one is update an old uboot.

Revision history for this message
Dave Pigott (dpigott) wrote :

For the moment I've added the change to rc.local and it brings the interface up. When uboot is fixed we'll update to that, rather than downgrading to an older uboot.

Revision history for this message
Jason Liu (r64343) wrote :

Add some more comments about the fec issue met by recently upstream uboot:
please be noted that currently u-boot upstream introduce the following commit:

commit c2dd0d45540397704de9b13287417d21049d34c6

armv7: integrate cache maintenance support

- Enable I-cache on bootup
- Enable MMU and D-cache immediately after relocation
- Do necessary initialization before enabling d-cache and MMU
- Changes to cleanup_before_linux()
- Make changes according to the new framework

which will enable dcache by default if the board config file does not define CONFIG_SYS_DCACHE_OFF explicitly.
currently, all the i.mx board config file does not define CONFIG_SYS_DCACHE_OFF, so
This commit will cause fec does not work correctly since the fec_mxc driver is not cache aware driver. To resolve
the fec issue under uboot, we have two ways:

1. Explicitly define CONFIG_SYS_DCACHE_OFF in board config file
2. Fix the fec_mxc driver to make it cache aware

[1]: maybe easy to do but may not be accepted by upstream (wolfgang)
[2]: need resolve the cache coherency to update fec_mxc to be cache safe driver.

Revision history for this message
Jason Liu (r64343) wrote :

Linaro commit:
a8834193c3ff7b731599e4e4544fe01600e75e42
Add Ethernet hardware MAC address framework to usbnet

There is something wrong with this patch:

+if (eth_write_hwaddr(dev, NULL, eth_number))
+ puts("Warning: failed to set MAC address\n");

Here the NULL for base_name will result in the error: failed to set MAC address
for other than usbnet. Need fix it up

Revision history for this message
Eric Miao (eric.y.miao) wrote :

As spring pointed out, this is affected by a8834193c3ff7b731599e4e4544fe01600e75e42,
Add Ethernet hardware MAC address framework to usbnet. http://git.linaro.org/gitweb?p=boot/u-boot-linaro-stable.git;a=commit;h=a8834193c3ff7b731599e4e4544fe01600e75e42.

Simply ignore the return value of eth_getenv_enetaddr_by_index() would fix this issue, and it looks like a right fix to me. Attached is the patch.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.