Bug 4548

Summary: beagleboard could not startup with 20130521-1 image
Product: [Runtime] General Runtime Reporter: Ning Zhang <ning.zhang>
Component: General RuntimeAssignee: Bruce Ashfield <bruce.ashfield>
Status: RESOLVED DUPLICATE QA Contact:
Severity: major    
Priority: Undecided CC: dvhart, ke.zou, yi.zhao
Version: 1.5   
Target Milestone: ---   
Hardware: Beagleboard   
OS: arm   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: ---

Description Ning Zhang 2013-05-24 05:45:24 UTC 
Branch: poky/master
Git rev: 176a46b088135f2891983bb8540bc45389341d90

steps:
1. download beagleboard images from http://autobuilder.yoctoproject.org/pub/nightly/20130521-1
2. this image could not bootup the beagleboard xM target.

Set below bootup parameters:

setenv bootcmd 'mmc rescan 0; fatload mmc 0:1 0x80300000 uImage; bootm 0x80300000'
setenv bootargs 'console=tty0 console=ttyO2,115200n8 root=/dev/mmcblk0p2 rootwait rootfstype=ext3 ro'

the system hangs at "Uncompressing Linux... done, booting the kernel." 



==================detail serial logs========================
Texas Instruments X-Loader 1.5.0 (May 13 2013 - 09:51:47)
Beagle xM
Reading boot sector
Loading u-boot.bin from mmc


U-Boot 2011.06 (May 13 2013 - 09:51:42)

OMAP36XX/37XX-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  512 MiB
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - readenv() failed, using default environment

In:    serial
Out:   serial
Err:   serial
Beagle unknown 0x02
No EEPROM on expansion board
Die ID #11c400229ff80000016830100e014012
Hit any key to stop autoboot:  0 
OMAP3 beagleboard.org # 
OMAP3 beagleboard.org # 
OMAP3 beagleboard.org # setenv bootcmd 'mmc rescan 0; fatload mmc 0:1 0x80300000 uImage; bootm 0x80300000'
OMAP3 beagleboard.org # setenv bootargs 'console=tty0 console=ttyO2,115200n8 root=/dev/mmcblk0p2 rootwait rootfstype=ext3 ro' 
OMAP3 beagleboard.org # boot
reading uImage

4302416 bytes read
## Booting kernel from Legacy Image at 80300000 ...
   Image Name:   Linux-3.4.36-yocto-standard
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4302352 Bytes = 4.1 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Comment 1 Bruce Ashfield 2013-05-24 05:51:03 UTC 
What's the important change here ? There have been no kernel 
changes at all ? If this using gcc 4.8, then document it.

We haven't fixed ARM boot support for gcc 4.8, so these images
should not be using gcc 4.8 as their default compiler, and we
won't be fixing all of these via defect.

So if this is 4.8, return it to the platform domain and indicate
they should be setting the preferred version of the toolchain to
a version that is known to work for these boards.
Comment 2 Ning Zhang 2013-05-27 07:59:53 UTC 
(In reply to comment #1)
> What's the important change here ? There have been no kernel 
> changes at all ? If this using gcc 4.8, then document it.
> 
> We haven't fixed ARM boot support for gcc 4.8, so these images
> should not be using gcc 4.8 as their default compiler, and we
> won't be fixing all of these via defect.
> 
> So if this is 4.8, return it to the platform domain and indicate
> they should be setting the preferred version of the toolchain to
> a version that is known to work for these boards.

Hi, 

I rebuild a beagleboard image locally (master: 176a46b088135f2891983bb8540bc45389341d90), it could start up well. And i check the gcc version is "gcc-4.7.2-r20".

But i am not sure the gcc version of the http://autobuilder.yoctoproject.org/pub/nightly/20130521-1 images. I only got the image files, but can not check the gcc version with the image.
Comment 3 Yi Zhao 2013-05-30 02:15:03 UTC 
For the new build from http://autobuilder.yoctoproject.org/pub/nightly/20130528-2/ . The system can boot up without problems.
Comment 4 Darren Hart 2013-05-30 14:50:50 UTC 
This was the result of a MUT build pulling in gcc 4.8 into sstate and the AB not rebuilding with 4.7. This is expected behavior as a change in the toolchain is explicitly prevented from triggering a rebuild.

We will track this with the qemuarm kernel boot failure, Bug 4549.

*** This bug has been marked as a duplicate of bug 4549 ***