Created attachment 312 [details]
SPI patch

Liming: can you have a look at this ?

Extra info: using poky-git master as of 11th Jan 13:00 GMT.

(In reply to comment #1)
> Created attachment 312 [details]
> SPI patch
When did your booting failure happen? After applied the patch?

(In reply to comment #4)
> (In reply to comment #1)
> > Created attachment 312 [details] [details]
> > SPI patch
> When did your booting failure happen? After applied the patch?

Booting failed from the start. I have just built a completely fresh core-image-minimal and I receive exactly the same results. Will try wiping the sd card and starting from fresh on that too.

OK, I wiped the sd card, re-partioned the lot and tried booting a core-image-minimal image with exactly the same results. Is there a way I can turn off quiet boot to get some feedback on where it is falling over, or to confirm if it isn't getting any further.

Something to note, although I don't know if it matters is that kernel 3.0.14 is being built but the modules being built are 3.0.12?

(In reply to comment #6)
> OK, I wiped the sd card, re-partioned the lot and tried booting a
> core-image-minimal image with exactly the same results. Is there a way I can
> turn off quiet boot to get some feedback on where it is falling over, or to
> confirm if it isn't getting any further.

Could you paste the result of "printenv" command in u-boot cmdline?

> 
> Something to note, although I don't know if it matters is that kernel 3.0.14 is
> being built but the modules being built are 3.0.12?

In our beagleboard C4 board,  there is no such booting issue. We will get xM board later and have a test.

OMAP3 beagleboard.org # printenv
baudrate=115200
bootcmd=if mmc rescan ${mmcdev}; then echo SD/MMC found on device ${mmcdev};if run loadbootenv; then run importbootenv;fi;if test -n $uenvcmd; then echo Running uenvcmd ...;run uenvcmd;fi;if run loaduimage; then run mmcboot;fi;fi;run nandboot;
bootdelay=10
buddy=none
console=ttyS2,115200n8
defaultdisplay=dvi
dieid#=0ed800229ff800000163810c15007017
dvimode=1024x768MR-16@60
importbootenv=echo Importing environment from mmc ...; env import -t $loadaddr $filesize
loadaddr=0x82000000
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt
loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage
mmcargs=setenv bootargs console=${console} mpurate=${mpurate} vram=${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=${mmcroot} rootfstype=${mmcrootfstype}
mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${loadaddr}
mmcdev=0
mmcroot=/dev/mmcblk0p2 rw
mmcrootfstype=ext3 rootwait
mpurate=auto
nandargs=setenv bootargs console=${console} mpurate=${mpurate} vram=${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=${nandroot} rootfstype=${nandrootfstype}
nandboot=echo Booting from nand ...; run nandargs; nand read ${loadaddr} 280000 400000; bootm ${loadaddr}
nandroot=/dev/mtdblock4 rw
nandrootfstype=jffs2
usbtty=cdc_acm
vram=12M

Looking at this:

console=ttyS2,115200n8

should it not be:

console=ttySO2,115200n8

As mentioned here: http://www.yoctoproject.org/download/bsp/texas-instruments-arm-cortex-a8-development-board-beagleboard-0

NOTE:  As of the 2.6.37 linux-yocto kernel recipe, the Beagleboard uses the OMAP_SERIAL device (ttyO2).  If you are using an older kernel, such as the 2.6.34 linux-yocto-stable, be sure to replace ttyO2 with ttyS2 above. You should also override the machine SERIAL_CONSOLE in your local.conf in order to setup the getty on the serial line as follows:

         SERIAL_CONSOLE_beagleboard = "115200 ttyS2"

I take that back, the environment variables are read from uImage which I guess comes from the boot.scr that I created details of which are:

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

With a git clone of the edison branch, my beagle boots no problem. It runs the 2.6 series kernel on this branch, therefore I would imagine that it is 3.0 series kernel related.

Exactly which Beagleboard xM revision are you working with?

Hi Darren,

I can confirm that my BeagleBoard still doesn't boot with the latest git master as of today with a clean build environment.

My board is identified as a BeagleBoard xM Revision C as far as I can tell.

I have attached my latest serial boot log. Again, it gets to uncompressing the kernel, done, booting kernel and then hangs.

Regards,
Jack.

Texas Instruments X-Loader 1.5.0 (Mar 30 2012 - 10:43:11)
Beagle xM
Reading boot sector
Loading u-boot.bin from mmc


U-Boot 2011.06 (Mar 30 2012 - 10:43:18)

OMAP3630/3730-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 #3f4200029ff80000016071640c00e00c
Hit any key to stop autoboot:  0
SD/MMC found on device 0
reading uEnv.txt

** Unable to read "uEnv.txt" from mmc 0:1 **
reading uImage

3110216 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 82000000 ...
   Image Name:   Linux-3.0.23-yocto-standard
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3110152 Bytes = 3 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

Yang: We'll have to work to get access to a beagleboard. The one that
I have isn't functional anymore. The test team @ Wind River has our boards,
so we are going to need to work with them for some sort of access.

Won't have access to my beagleboard till tomorrow, but I believe it's worth commenting here, just after I noticed this bug report. 

While beta testing yocto 1.2, I wasn't able to boot a successfully built core-image-minimal with default configuration. First I had the same effect Jack reported, but correctly setting console variable through uEnv.txt I was able to get boot messages back.

The kernel was failed while trying to get the root filesystem out of the MMC card: I compared the log with an image built out of official edison (1.1), which was booting fine, and noticed that any detection of the MMC card was missing in the the log from 1.2 beta (sorry for lack of detailed error messages here, but I'm commuting now and don't have acces to my full build logs).

One more thing: the kernel built by 1.2 beta was failing to correctly identify my beagleboard as xM: it was giving a "type unknown 0x02". Looking at kernel source in yocto work directory, I noticed the relevant board-omap3beagle.c was somewhat outdated in the relevant bits. 

Also tried another kernel built from recent edison 1.1.1, and this also was failing with the same result. Looks like some something odd happened between 1.1 and 1.1.1.

I'll try to augment this report as soon as I get my logs back.

BTW, I see you are missing a beagleboard xM for tests. I have one and can do some testing as time allows.

(In reply to comment #10)
> I take that back, the environment variables are read from uImage which I guess
> comes from the boot.scr that I created details of which are:
> 
> setenv bootcmd 'mmc init; fatload mmc 0:1 0x80300000 uImage; bootm 0x80300000'
> setenv setenv bootargs 'console=ttyO2,115200n8 root=/dev/mmcblk0p2
> rootwait rootfstype=ext3 rw'
> boot

Hi Jack,
You can try to add "mmc rescan 0" command in u-boot. Like below:

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

This is actually fixed. Looks like we forgot to update the status, Denys sent a config fix that allows boot to proceed. Changing the status now.