Tree/branch: stage/master_under_test Commit：f5eb96062f71ff8ccc0e91df6e01aee56b70b0d9 Image location: http://autobuilder.yoctoproject.org/pub/nightly/20120505-1/machines/mpc8315e-rdb/ Mpc8315e-rdb boot failed with 20120505 build. The boot logs like below: ######### U-Boot 2010.09 (Oct 20 2010 - 13:29:02) MPC83XX Reset Status: CPU: e300c3, MPC8315E, Rev: 1.2 at 400 MHz, CSB: 133.333 MHz Board: Freescale MPC8315ERDB Rev 1.0 I2C: ready DRAM: 128 MiB FLASH: 8 MiB NAND: 32 MiB PCIE0: No link PCIE1: No link In: serial Out: serial Err: serial Net: eTSFilename 'vlm-boards/17652/kernel'. Load address: 0x800000 Loading: ################################################################# ################################################################# ################################################################# #### done Bytes transferred = 2916202 (2c7f6a hex) Speed: 100, full duplex Using eTSEC0 device TFTP from server 128.224.165.20; our IP address is 128.224.178.141 Filename 'vlm-boards/17652/dtb'. Load address: 0x780000 Loading: ## done Bytes transferred = 21018 (521a hex) ## Booting kernel from Legacy Image at 00800000 ... Image Name: Linux-3.0.24-yocto-standard Created: 2012-05-02 8:10:20 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) EC0, eTSEC1 Hit any key to stop autoboot: 0 Speed: 100, full duplex Using eTSEC0 device TFTP from server 128.224.165.20; our IP address is 128.224.178.141 Data Size: 2916138 Bytes = 2.8 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 00780000 Booting using the fdt blob at 0x780000 Uncompressing Kernel Image ... OK NOTICE: No or unknown board_type hwconfig specified. Assuming board with TSEC1. ############ This issue doesn't happen with 1.2 denzil. I tried to boot the kernel with the denzil rootfs. It also can not boot.
There's been zero kernel changes merged to the 3.0 tree for several weeks now. Can you confirm the top commit on your last working kernel verses the one that didn't boot. They should be the same. That will show that this lies outside the kernel. We are about to bump this BSP to 3.4, but it's worth finding the root cause.
(In reply to comment #1) > There's been zero kernel changes merged to the 3.0 tree for several > weeks now. Can you confirm the top commit on your last working kernel > verses the one that didn't boot. They should be the same. > > That will show that this lies outside the kernel. > > We are about to bump this BSP to 3.4, but it's worth finding the root cause. gcc has probably changed underneath. Can you compile just the kernel with 4.6 and use the rfs unmodified and see if that helps ?
(In reply to comment #2) > (In reply to comment #1) > > There's been zero kernel changes merged to the 3.0 tree for several > > weeks now. Can you confirm the top commit on your last working kernel > > verses the one that didn't boot. They should be the same. > > > > That will show that this lies outside the kernel. > > > > We are about to bump this BSP to 3.4, but it's worth finding the root cause. > > gcc has probably changed underneath. Can you compile just the kernel with 4.6 > and use the rfs unmodified and see if that helps ? With the 20120510 build. The issue still hapeens. Tree/branch: stage/master_under_test Commit：0ad72a18b5077c3c73ee9ee76ffcd700b14772cf Image location: http://autobuilder.yoctoproject.org/pub/nightly/20120510-2/machines/mpc8315e-rdb/ I re-compiled a kernel with this branch by using gcc 4.6 (Change GCCVERSION ?= "4.7%" to GCCVERSION ?= "4.6%" in meta/conf/distro/include/tcmode-default.inc). The board can boot with this kernel and the original rootfs.
Yang has been building and booting this on 3.2 for some time. We'll bump the version soon, but he may have ideas about the current issue as well.
Can you provide your kernel config here? I have my 3.4 build on linux-yocto-dev (3.4 kernel) boot up a couple of days ago.
Created attachment 506 [details] config kernel config with 3.0.24
Thanks. At least, the kernel config looks fine. As Bruce said, for 1.3 we will uprev it to 3.4 kernel. And, I already had a working 3.4 tree by hand.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > There's been zero kernel changes merged to the 3.0 tree for several > > > weeks now. Can you confirm the top commit on your last working kernel > > > verses the one that didn't boot. They should be the same. > > > > > > That will show that this lies outside the kernel. > > > > > > We are about to bump this BSP to 3.4, but it's worth finding the root cause. > > > > gcc has probably changed underneath. Can you compile just the kernel with 4.6 > > and use the rfs unmodified and see if that helps ? > > With the 20120510 build. The issue still hapeens. > > Tree/branch: stage/master_under_test > Commit：0ad72a18b5077c3c73ee9ee76ffcd700b14772cf > > Image location: > http://autobuilder.yoctoproject.org/pub/nightly/20120510-2/machines/mpc8315e- > rdb/ > > I re-compiled a kernel with this branch by using gcc 4.6 (Change GCCVERSION > ?= "4.7%" to GCCVERSION ?= "4.6%" in > meta/conf/distro/include/tcmode-default.inc). The board can boot with this > kernel and the original rootfs. I rebuilt the kernel with gcc 4.7 again in local and found that the kernel can boot without problem. Here is the boot log: ########## ## Booting kernel from Legacy Image at 00800000 ... Image Name: Linux-3.0.24-yocto-standard Created: 2012-05-14 10:15:33 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 2915906 Bytes = 2.8 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 00780000 Booting using the fdt blob at 0x780000 Uncompressing Kernel Image ... OK NOTICE: No or unknown board_type hwconfig specified. Assuming board with TSEC1. Using MPC831x RDB machine description Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 3.0.24-yocto-standard (builder@pek-yocto-build1) (gcc version 4.7.1 20120421 (prerelease) (GCC) ) #1 PREEMPT Mon May 14 18:14:47 CST 2012 bootconsole [udbg0] enabled setup_arch: bootmem mpc831x_rdb_setup_arch() Found FSL PCI host bridge at 0x00000000e0008500. Firmware bus number: 0->0 PCI host bridge /pci@e0008500 (primary) ranges: MEM 0x0000000090000000..0x000000009fffffff -> 0x0000000090000000 MEM 0x0000000080000000..0x000000008fffffff -> 0x0000000080000000 Prefetch IO 0x00000000e0300000..0x00000000e03fffff -> 0x0000000000000000 No pci config register base in dev tree, using default Found FSL PCI host bridge at 0x00000000e0009000. Firmware bus number: 0->255 PCI host bridge /pcie@e0009000 ranges: MEM 0x00000000a0000000..0x00000000afffffff -> 0x00000000a0000000 IO 0x00000000b1000000..0x00000000b17fffff -> 0x0000000000000000 No pci config register base in dev tree, using default Found FSL PCI host bridge at 0x00000000e000a000. Firmware bus number: 0->255 PCI host bridge /pcie@e000a000 ranges: MEM 0x00000000c0000000..0x00000000cfffffff -> 0x00000000c0000000 IO 0x00000000d1000000..0x00000000d17fffff -> 0x0000000000000000 arch: exit Zone PFN ranges: DMA 0x00000000 -> 0x00008000 Normal empty Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x00000000 -> 0x00008000 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 ... ... ###########
With 20120515 build (gitinfo: master:f3ba3cb6af96aebf5167bb1565edf11cceb7897f)， this issue still happens. But when I changed the load address with kernel and fdt in uboot, it can boot. The default settings in u-boot is like below: ############# tftp 800000 uImage-mpc8315e-rdb.bin tftp 780000 uImage-mpc8315e-rdb.dtb bootm 800000 - 780000 ############# I changed the load address to: ############# tftp 1000000 uImage-mpc8315e-rdb.bin tftp 2000000 uImage-mpc8315e-rdb.dtb bootm 1000000 - 2000000 ############# It could works. I think the reason is: By default, U-boot decompresses kernel image(uImage) to the first 8M memory. The current uImage is larger then before. so we need to load the uImage and dtb file to a higher value in memory.
It should be the cause, in the past years we already met such issues a lot of times. So, changing load address is the right solution for bigger kernel image.
agreed. Changing the load address is the right thing, and it would be the final/correct solution. We should add this to the documentation of the board for the formal bug resolution.
Can we add this information to the README and get this bug closed?
Bruce, Yang - can you get an update to the README per comment 12 and resolve?
I updated the README myself: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=df2aeee419d0a8374f959ff79cb8b7dafcd01d1b