* BBB doesn't boot
@ 2014-04-13 9:12 Gary Thomas
2014-04-14 2:33 ` Denys Dmytriyenko
2014-04-14 10:35 ` Stanacar, StefanX
0 siblings, 2 replies; 49+ messages in thread
From: Gary Thomas @ 2014-04-13 9:12 UTC (permalink / raw)
To: Yocto Project
I just tried building (core-image-sato) for my BeagleBoneBlack
using the latest Poky/Yocto master:
Build Configuration:
BB_VERSION = "1.23.0"
BUILD_SYS = "i686-linux"
NATIVELSBSTRING = "Fedora-13"
TARGET_SYS = "arm-poky-linux-gnueabi"
MACHINE = "beaglebone"
DISTRO = "poky"
DISTRO_VERSION = "1.6+snapshot-20140411"
TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8"
TARGET_FPU = "vfp-neon"
meta
meta-yocto
meta-yocto-bsp = "master:863cc7483f5ee43189537940de8ee5c0964d24cc"
This built the kernel using SRCREV 928d7b2dda
I followed the bring-up instructions from README.hadware and the
boot failed to even start the kernel. Here's what I see:
=============================== boot log =========================================
U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
I2C: ready
DRAM: 512 MiB
WARNING: Caches not enabled
NAND: 0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net: <ethaddr> not set. Validating first E-fuse MAC
Phy not found
PHY reset timed out
cpsw, usb_ether
Hit any key to stop autoboot: 0
mmc0 is current device
SD/MMC found on device 0
reading uEnv.txt
** Unable to read file uEnv.txt **
4981688 bytes read in 613 ms (7.7 MiB/s)
29192 bytes read in 46 ms (619.1 KiB/s)
Booting from mmc ...
## Booting kernel from Legacy Image at 80200000 ...
Image Name: Linux-3.14.0-yocto-standard
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4981624 Bytes = 4.8 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 80f80000
Booting using the fdt blob at 0x80f80000
Loading Kernel Image ... OK
Using Device Tree in place at 80f80000, end 80f8a207
Starting kernel ...
==================================================================================
Any ideas what I've done wrong?
Thanks
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-13 9:12 BBB doesn't boot Gary Thomas
@ 2014-04-14 2:33 ` Denys Dmytriyenko
2014-04-14 10:25 ` Gary Thomas
2014-04-14 10:35 ` Stanacar, StefanX
1 sibling, 1 reply; 49+ messages in thread
From: Denys Dmytriyenko @ 2014-04-14 2:33 UTC (permalink / raw)
To: Gary Thomas; +Cc: Yocto Project
On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote:
> I just tried building (core-image-sato) for my BeagleBoneBlack
> using the latest Poky/Yocto master:
>
> Build Configuration:
> BB_VERSION = "1.23.0"
> BUILD_SYS = "i686-linux"
> NATIVELSBSTRING = "Fedora-13"
> TARGET_SYS = "arm-poky-linux-gnueabi"
> MACHINE = "beaglebone"
> DISTRO = "poky"
> DISTRO_VERSION = "1.6+snapshot-20140411"
> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8"
> TARGET_FPU = "vfp-neon"
> meta
> meta-yocto
> meta-yocto-bsp = "master:863cc7483f5ee43189537940de8ee5c0964d24cc"
>
> This built the kernel using SRCREV 928d7b2dda
>
> I followed the bring-up instructions from README.hadware and the
> boot failed to even start the kernel. Here's what I see:
>
> =============================== boot log =========================================
> U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
>
> I2C: ready
> DRAM: 512 MiB
> WARNING: Caches not enabled
> NAND: 0 MiB
> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
> *** Warning - readenv() failed, using default environment
>
> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
> musb-hdrc: MHDRC RTL version 2.0
> musb-hdrc: setup fifo_mode 4
> musb-hdrc: 28/31 max ep, 16384/16384 memory
> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
> musb-hdrc: MHDRC RTL version 2.0
> musb-hdrc: setup fifo_mode 4
> musb-hdrc: 28/31 max ep, 16384/16384 memory
> USB Host mode controller at 47401800 using PIO, IRQ 0
> Net: <ethaddr> not set. Validating first E-fuse MAC
> Phy not found
> PHY reset timed out
> cpsw, usb_ether
> Hit any key to stop autoboot: 0
> mmc0 is current device
> SD/MMC found on device 0
> reading uEnv.txt
> ** Unable to read file uEnv.txt **
> 4981688 bytes read in 613 ms (7.7 MiB/s)
> 29192 bytes read in 46 ms (619.1 KiB/s)
> Booting from mmc ...
> ## Booting kernel from Legacy Image at 80200000 ...
> Image Name: Linux-3.14.0-yocto-standard
> Image Type: ARM Linux Kernel Image (uncompressed)
> Data Size: 4981624 Bytes = 4.8 MiB
> Load Address: 80008000
> Entry Point: 80008000
> Verifying Checksum ... OK
> ## Flattened Device Tree blob at 80f80000
> Booting using the fdt blob at 0x80f80000
> Loading Kernel Image ... OK
> Using Device Tree in place at 80f80000, end 80f8a207
>
> Starting kernel ...
> ==================================================================================
>
> Any ideas what I've done wrong?
Hmm, everything looks sane. What revision is your BBB? And did you press
USER/BOOT button or erased eMMC partition per instructions?
--
Denys
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-14 2:33 ` Denys Dmytriyenko
@ 2014-04-14 10:25 ` Gary Thomas
2014-04-14 15:46 ` Denys Dmytriyenko
0 siblings, 1 reply; 49+ messages in thread
From: Gary Thomas @ 2014-04-14 10:25 UTC (permalink / raw)
To: yocto
On 2014-04-13 20:33, Denys Dmytriyenko wrote:
> On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote:
>> I just tried building (core-image-sato) for my BeagleBoneBlack
>> using the latest Poky/Yocto master:
>>
>> Build Configuration:
>> BB_VERSION = "1.23.0"
>> BUILD_SYS = "i686-linux"
>> NATIVELSBSTRING = "Fedora-13"
>> TARGET_SYS = "arm-poky-linux-gnueabi"
>> MACHINE = "beaglebone"
>> DISTRO = "poky"
>> DISTRO_VERSION = "1.6+snapshot-20140411"
>> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8"
>> TARGET_FPU = "vfp-neon"
>> meta
>> meta-yocto
>> meta-yocto-bsp = "master:863cc7483f5ee43189537940de8ee5c0964d24cc"
>>
>> This built the kernel using SRCREV 928d7b2dda
>>
>> I followed the bring-up instructions from README.hadware and the
>> boot failed to even start the kernel. Here's what I see:
>>
>> =============================== boot log =========================================
>> U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
>>
>> I2C: ready
>> DRAM: 512 MiB
>> WARNING: Caches not enabled
>> NAND: 0 MiB
>> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
>> *** Warning - readenv() failed, using default environment
>>
>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
>> musb-hdrc: MHDRC RTL version 2.0
>> musb-hdrc: setup fifo_mode 4
>> musb-hdrc: 28/31 max ep, 16384/16384 memory
>> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
>> musb-hdrc: MHDRC RTL version 2.0
>> musb-hdrc: setup fifo_mode 4
>> musb-hdrc: 28/31 max ep, 16384/16384 memory
>> USB Host mode controller at 47401800 using PIO, IRQ 0
>> Net: <ethaddr> not set. Validating first E-fuse MAC
>> Phy not found
>> PHY reset timed out
>> cpsw, usb_ether
>> Hit any key to stop autoboot: 0
>> mmc0 is current device
>> SD/MMC found on device 0
>> reading uEnv.txt
>> ** Unable to read file uEnv.txt **
>> 4981688 bytes read in 613 ms (7.7 MiB/s)
>> 29192 bytes read in 46 ms (619.1 KiB/s)
>> Booting from mmc ...
>> ## Booting kernel from Legacy Image at 80200000 ...
>> Image Name: Linux-3.14.0-yocto-standard
>> Image Type: ARM Linux Kernel Image (uncompressed)
>> Data Size: 4981624 Bytes = 4.8 MiB
>> Load Address: 80008000
>> Entry Point: 80008000
>> Verifying Checksum ... OK
>> ## Flattened Device Tree blob at 80f80000
>> Booting using the fdt blob at 0x80f80000
>> Loading Kernel Image ... OK
>> Using Device Tree in place at 80f80000, end 80f8a207
>>
>> Starting kernel ...
>> ==================================================================================
>>
>> Any ideas what I've done wrong?
>
> Hmm, everything looks sane. What revision is your BBB? And did you press
> USER/BOOT button or erased eMMC partition per instructions?
>
Revision A5A, with an LCD cape
Yes, I erased the eMMC before trying this.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-13 9:12 BBB doesn't boot Gary Thomas
2014-04-14 2:33 ` Denys Dmytriyenko
@ 2014-04-14 10:35 ` Stanacar, StefanX
2014-04-14 11:38 ` Stanacar, StefanX
1 sibling, 1 reply; 49+ messages in thread
From: Stanacar, StefanX @ 2014-04-14 10:35 UTC (permalink / raw)
To: gary; +Cc: yocto
Hi Gary,
On Sun, 2014-04-13 at 03:12 -0600, Gary Thomas wrote:
> I just tried building (core-image-sato) for my BeagleBoneBlack
> using the latest Poky/Yocto master:
>
> Build Configuration:
> BB_VERSION = "1.23.0"
> BUILD_SYS = "i686-linux"
> NATIVELSBSTRING = "Fedora-13"
> TARGET_SYS = "arm-poky-linux-gnueabi"
> MACHINE = "beaglebone"
> DISTRO = "poky"
> DISTRO_VERSION = "1.6+snapshot-20140411"
> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8"
> TARGET_FPU = "vfp-neon"
> meta
> meta-yocto
> meta-yocto-bsp = "master:863cc7483f5ee43189537940de8ee5c0964d24cc"
>
> This built the kernel using SRCREV 928d7b2dda
>
> I followed the bring-up instructions from README.hadware and the
> boot failed to even start the kernel. Here's what I see:
>
> =============================== boot log =========================================
> U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
>
> I2C: ready
> DRAM: 512 MiB
> WARNING: Caches not enabled
> NAND: 0 MiB
> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
> *** Warning - readenv() failed, using default environment
>
> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
> musb-hdrc: MHDRC RTL version 2.0
> musb-hdrc: setup fifo_mode 4
> musb-hdrc: 28/31 max ep, 16384/16384 memory
> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
> musb-hdrc: MHDRC RTL version 2.0
> musb-hdrc: setup fifo_mode 4
> musb-hdrc: 28/31 max ep, 16384/16384 memory
> USB Host mode controller at 47401800 using PIO, IRQ 0
> Net: <ethaddr> not set. Validating first E-fuse MAC
> Phy not found
> PHY reset timed out
> cpsw, usb_ether
> Hit any key to stop autoboot: 0
> mmc0 is current device
> SD/MMC found on device 0
> reading uEnv.txt
> ** Unable to read file uEnv.txt **
> 4981688 bytes read in 613 ms (7.7 MiB/s)
> 29192 bytes read in 46 ms (619.1 KiB/s)
> Booting from mmc ...
> ## Booting kernel from Legacy Image at 80200000 ...
> Image Name: Linux-3.14.0-yocto-standard
> Image Type: ARM Linux Kernel Image (uncompressed)
> Data Size: 4981624 Bytes = 4.8 MiB
> Load Address: 80008000
> Entry Point: 80008000
> Verifying Checksum ... OK
> ## Flattened Device Tree blob at 80f80000
> Booting using the fdt blob at 0x80f80000
> Loading Kernel Image ... OK
> Using Device Tree in place at 80f80000, end 80f8a207
>
> Starting kernel ...
> ==================================================================================
>
> Any ideas what I've done wrong?
>
This is strange because last week I booted myself a BBB.
This actually looks like the serial doesn't output, perhaps the kernel
does boot. I wonder if console is right for the kernel cmdline.
On Friday I built and booted from
master:db80f796e78746014a0f9497638e5c6fd2953ef0 which is a bit earlier
that what you have but basically the same thing (updates for kernel
which should fix things, I've tested with SRCREV_meta_pn-linux-yocto =
"${AUTOREV}" those before they entered in master because I didn't had
HDMI output on my master commit).
I'm gonna rebuild from daisy tip and see what happens.
Cheers,
Stefan
> Thanks
>
> --
> ------------------------------------------------------------
> Gary Thomas | Consulting for the
> MLB Associates | Embedded world
> ------------------------------------------------------------
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-14 10:35 ` Stanacar, StefanX
@ 2014-04-14 11:38 ` Stanacar, StefanX
2014-04-14 11:44 ` Gary Thomas
0 siblings, 1 reply; 49+ messages in thread
From: Stanacar, StefanX @ 2014-04-14 11:38 UTC (permalink / raw)
To: gary; +Cc: yocto
On Mon, 2014-04-14 at 10:35 +0000, Stanacar, StefanX wrote:
> Hi Gary,
>
> On Sun, 2014-04-13 at 03:12 -0600, Gary Thomas wrote:
> > I just tried building (core-image-sato) for my BeagleBoneBlack
> > using the latest Poky/Yocto master:
> >
> > Build Configuration:
> > BB_VERSION = "1.23.0"
> > BUILD_SYS = "i686-linux"
> > NATIVELSBSTRING = "Fedora-13"
> > TARGET_SYS = "arm-poky-linux-gnueabi"
> > MACHINE = "beaglebone"
> > DISTRO = "poky"
> > DISTRO_VERSION = "1.6+snapshot-20140411"
> > TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8"
> > TARGET_FPU = "vfp-neon"
> > meta
> > meta-yocto
> > meta-yocto-bsp = "master:863cc7483f5ee43189537940de8ee5c0964d24cc"
> >
> > This built the kernel using SRCREV 928d7b2dda
> >
> > I followed the bring-up instructions from README.hadware and the
> > boot failed to even start the kernel. Here's what I see:
> >
> > =============================== boot log =========================================
> > U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
> >
> > I2C: ready
> > DRAM: 512 MiB
> > WARNING: Caches not enabled
> > NAND: 0 MiB
> > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
> > *** Warning - readenv() failed, using default environment
> >
> > musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
> > musb-hdrc: MHDRC RTL version 2.0
> > musb-hdrc: setup fifo_mode 4
> > musb-hdrc: 28/31 max ep, 16384/16384 memory
> > USB Peripheral mode controller at 47401000 using PIO, IRQ 0
> > musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
> > musb-hdrc: MHDRC RTL version 2.0
> > musb-hdrc: setup fifo_mode 4
> > musb-hdrc: 28/31 max ep, 16384/16384 memory
> > USB Host mode controller at 47401800 using PIO, IRQ 0
> > Net: <ethaddr> not set. Validating first E-fuse MAC
> > Phy not found
> > PHY reset timed out
> > cpsw, usb_ether
> > Hit any key to stop autoboot: 0
> > mmc0 is current device
> > SD/MMC found on device 0
> > reading uEnv.txt
> > ** Unable to read file uEnv.txt **
> > 4981688 bytes read in 613 ms (7.7 MiB/s)
> > 29192 bytes read in 46 ms (619.1 KiB/s)
> > Booting from mmc ...
> > ## Booting kernel from Legacy Image at 80200000 ...
> > Image Name: Linux-3.14.0-yocto-standard
> > Image Type: ARM Linux Kernel Image (uncompressed)
> > Data Size: 4981624 Bytes = 4.8 MiB
> > Load Address: 80008000
> > Entry Point: 80008000
> > Verifying Checksum ... OK
> > ## Flattened Device Tree blob at 80f80000
> > Booting using the fdt blob at 0x80f80000
> > Loading Kernel Image ... OK
> > Using Device Tree in place at 80f80000, end 80f8a207
> >
> > Starting kernel ...
> > ==================================================================================
> >
> > Any ideas what I've done wrong?
> >
>
> This is strange because last week I booted myself a BBB.
> This actually looks like the serial doesn't output, perhaps the kernel
> does boot. I wonder if console is right for the kernel cmdline.
> On Friday I built and booted from
> master:db80f796e78746014a0f9497638e5c6fd2953ef0 which is a bit earlier
> that what you have but basically the same thing (updates for kernel
> which should fix things, I've tested with SRCREV_meta_pn-linux-yocto =
> "${AUTOREV}" those before they entered in master because I didn't had
> HDMI output on my master commit).
>
> I'm gonna rebuild from daisy tip and see what happens.
>
I just did a clean build from daisy and it worked fine...
Could you try again? And perhaps -ccleansstate for linux-yocto? I'm
thinking that somehow it didn't picked up the new console= that changed
in the machine definition.
Cheers,
Stefan
> Cheers,
> Stefan
>
>
>
>
>
>
> > Thanks
> >
> > --
> > ------------------------------------------------------------
> > Gary Thomas | Consulting for the
> > MLB Associates | Embedded world
> > ------------------------------------------------------------
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-14 11:38 ` Stanacar, StefanX
@ 2014-04-14 11:44 ` Gary Thomas
2014-04-14 11:51 ` Gary Thomas
0 siblings, 1 reply; 49+ messages in thread
From: Gary Thomas @ 2014-04-14 11:44 UTC (permalink / raw)
To: Stanacar, StefanX; +Cc: yocto
On 2014-04-14 05:38, Stanacar, StefanX wrote:
>
>
>
> On Mon, 2014-04-14 at 10:35 +0000, Stanacar, StefanX wrote:
>> Hi Gary,
>>
>> On Sun, 2014-04-13 at 03:12 -0600, Gary Thomas wrote:
>>> I just tried building (core-image-sato) for my BeagleBoneBlack
>>> using the latest Poky/Yocto master:
>>>
>>> Build Configuration:
>>> BB_VERSION = "1.23.0"
>>> BUILD_SYS = "i686-linux"
>>> NATIVELSBSTRING = "Fedora-13"
>>> TARGET_SYS = "arm-poky-linux-gnueabi"
>>> MACHINE = "beaglebone"
>>> DISTRO = "poky"
>>> DISTRO_VERSION = "1.6+snapshot-20140411"
>>> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8"
>>> TARGET_FPU = "vfp-neon"
>>> meta
>>> meta-yocto
>>> meta-yocto-bsp = "master:863cc7483f5ee43189537940de8ee5c0964d24cc"
>>>
>>> This built the kernel using SRCREV 928d7b2dda
>>>
>>> I followed the bring-up instructions from README.hadware and the
>>> boot failed to even start the kernel. Here's what I see:
>>>
>>> =============================== boot log =========================================
>>> U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
>>>
>>> I2C: ready
>>> DRAM: 512 MiB
>>> WARNING: Caches not enabled
>>> NAND: 0 MiB
>>> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
>>> *** Warning - readenv() failed, using default environment
>>>
>>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
>>> musb-hdrc: MHDRC RTL version 2.0
>>> musb-hdrc: setup fifo_mode 4
>>> musb-hdrc: 28/31 max ep, 16384/16384 memory
>>> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
>>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
>>> musb-hdrc: MHDRC RTL version 2.0
>>> musb-hdrc: setup fifo_mode 4
>>> musb-hdrc: 28/31 max ep, 16384/16384 memory
>>> USB Host mode controller at 47401800 using PIO, IRQ 0
>>> Net: <ethaddr> not set. Validating first E-fuse MAC
>>> Phy not found
>>> PHY reset timed out
>>> cpsw, usb_ether
>>> Hit any key to stop autoboot: 0
>>> mmc0 is current device
>>> SD/MMC found on device 0
>>> reading uEnv.txt
>>> ** Unable to read file uEnv.txt **
>>> 4981688 bytes read in 613 ms (7.7 MiB/s)
>>> 29192 bytes read in 46 ms (619.1 KiB/s)
>>> Booting from mmc ...
>>> ## Booting kernel from Legacy Image at 80200000 ...
>>> Image Name: Linux-3.14.0-yocto-standard
>>> Image Type: ARM Linux Kernel Image (uncompressed)
>>> Data Size: 4981624 Bytes = 4.8 MiB
>>> Load Address: 80008000
>>> Entry Point: 80008000
>>> Verifying Checksum ... OK
>>> ## Flattened Device Tree blob at 80f80000
>>> Booting using the fdt blob at 0x80f80000
>>> Loading Kernel Image ... OK
>>> Using Device Tree in place at 80f80000, end 80f8a207
>>>
>>> Starting kernel ...
>>> ==================================================================================
>>>
>>> Any ideas what I've done wrong?
>>>
>>
>> This is strange because last week I booted myself a BBB.
>> This actually looks like the serial doesn't output, perhaps the kernel
>> does boot. I wonder if console is right for the kernel cmdline.
>> On Friday I built and booted from
>> master:db80f796e78746014a0f9497638e5c6fd2953ef0 which is a bit earlier
>> that what you have but basically the same thing (updates for kernel
>> which should fix things, I've tested with SRCREV_meta_pn-linux-yocto =
>> "${AUTOREV}" those before they entered in master because I didn't had
>> HDMI output on my master commit).
>>
>> I'm gonna rebuild from daisy tip and see what happens.
>>
>
> I just did a clean build from daisy and it worked fine...
> Could you try again? And perhaps -ccleansstate for linux-yocto? I'm
> thinking that somehow it didn't picked up the new console= that changed
> in the machine definition.
I'll try daisy, but my build/test was clean from the mentioned master rev.
I checked the console setup in U-Boot:
console=ttyO0,115200n8
which I think is correct.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-14 11:44 ` Gary Thomas
@ 2014-04-14 11:51 ` Gary Thomas
0 siblings, 0 replies; 49+ messages in thread
From: Gary Thomas @ 2014-04-14 11:51 UTC (permalink / raw)
To: Stanacar, StefanX; +Cc: yocto
On 2014-04-14 05:44, Gary Thomas wrote:
> On 2014-04-14 05:38, Stanacar, StefanX wrote:
>>
>>
>>
>> On Mon, 2014-04-14 at 10:35 +0000, Stanacar, StefanX wrote:
>>> Hi Gary,
>>>
>>> On Sun, 2014-04-13 at 03:12 -0600, Gary Thomas wrote:
>>>> I just tried building (core-image-sato) for my BeagleBoneBlack
>>>> using the latest Poky/Yocto master:
>>>>
>>>> Build Configuration:
>>>> BB_VERSION = "1.23.0"
>>>> BUILD_SYS = "i686-linux"
>>>> NATIVELSBSTRING = "Fedora-13"
>>>> TARGET_SYS = "arm-poky-linux-gnueabi"
>>>> MACHINE = "beaglebone"
>>>> DISTRO = "poky"
>>>> DISTRO_VERSION = "1.6+snapshot-20140411"
>>>> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8"
>>>> TARGET_FPU = "vfp-neon"
>>>> meta
>>>> meta-yocto
>>>> meta-yocto-bsp = "master:863cc7483f5ee43189537940de8ee5c0964d24cc"
>>>>
>>>> This built the kernel using SRCREV 928d7b2dda
>>>>
>>>> I followed the bring-up instructions from README.hadware and the
>>>> boot failed to even start the kernel. Here's what I see:
>>>>
>>>> =============================== boot log =========================================
>>>> U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
>>>>
>>>> I2C: ready
>>>> DRAM: 512 MiB
>>>> WARNING: Caches not enabled
>>>> NAND: 0 MiB
>>>> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
>>>> *** Warning - readenv() failed, using default environment
>>>>
>>>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
>>>> musb-hdrc: MHDRC RTL version 2.0
>>>> musb-hdrc: setup fifo_mode 4
>>>> musb-hdrc: 28/31 max ep, 16384/16384 memory
>>>> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
>>>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
>>>> musb-hdrc: MHDRC RTL version 2.0
>>>> musb-hdrc: setup fifo_mode 4
>>>> musb-hdrc: 28/31 max ep, 16384/16384 memory
>>>> USB Host mode controller at 47401800 using PIO, IRQ 0
>>>> Net: <ethaddr> not set. Validating first E-fuse MAC
>>>> Phy not found
>>>> PHY reset timed out
>>>> cpsw, usb_ether
>>>> Hit any key to stop autoboot: 0
>>>> mmc0 is current device
>>>> SD/MMC found on device 0
>>>> reading uEnv.txt
>>>> ** Unable to read file uEnv.txt **
>>>> 4981688 bytes read in 613 ms (7.7 MiB/s)
>>>> 29192 bytes read in 46 ms (619.1 KiB/s)
>>>> Booting from mmc ...
>>>> ## Booting kernel from Legacy Image at 80200000 ...
>>>> Image Name: Linux-3.14.0-yocto-standard
>>>> Image Type: ARM Linux Kernel Image (uncompressed)
>>>> Data Size: 4981624 Bytes = 4.8 MiB
>>>> Load Address: 80008000
>>>> Entry Point: 80008000
>>>> Verifying Checksum ... OK
>>>> ## Flattened Device Tree blob at 80f80000
>>>> Booting using the fdt blob at 0x80f80000
>>>> Loading Kernel Image ... OK
>>>> Using Device Tree in place at 80f80000, end 80f8a207
>>>>
>>>> Starting kernel ...
>>>> ==================================================================================
>>>>
>>>> Any ideas what I've done wrong?
>>>>
>>>
>>> This is strange because last week I booted myself a BBB.
>>> This actually looks like the serial doesn't output, perhaps the kernel
>>> does boot. I wonder if console is right for the kernel cmdline.
>>> On Friday I built and booted from
>>> master:db80f796e78746014a0f9497638e5c6fd2953ef0 which is a bit earlier
>>> that what you have but basically the same thing (updates for kernel
>>> which should fix things, I've tested with SRCREV_meta_pn-linux-yocto =
>>> "${AUTOREV}" those before they entered in master because I didn't had
>>> HDMI output on my master commit).
>>>
>>> I'm gonna rebuild from daisy tip and see what happens.
>>>
>>
>> I just did a clean build from daisy and it worked fine...
>> Could you try again? And perhaps -ccleansstate for linux-yocto? I'm
>> thinking that somehow it didn't picked up the new console= that changed
>> in the machine definition.
>
> I'll try daisy, but my build/test was clean from the mentioned master rev.
>
> I checked the console setup in U-Boot:
> console=ttyO0,115200n8
> which I think is correct.
>
Actually, I just compared my master tree with the daisy branch and
they are the same, save for the release strings, so there's no need
to rebuild.
Still at a loss though.
StefanX, perhaps you could let me try your exact image on my board?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-14 10:25 ` Gary Thomas
@ 2014-04-14 15:46 ` Denys Dmytriyenko
2014-04-14 15:51 ` Gary Thomas
0 siblings, 1 reply; 49+ messages in thread
From: Denys Dmytriyenko @ 2014-04-14 15:46 UTC (permalink / raw)
To: Gary Thomas; +Cc: yocto
On Mon, Apr 14, 2014 at 04:25:55AM -0600, Gary Thomas wrote:
> On 2014-04-13 20:33, Denys Dmytriyenko wrote:
> > On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote:
> >> I just tried building (core-image-sato) for my BeagleBoneBlack
> >> using the latest Poky/Yocto master:
> >>
> >> Build Configuration:
> >> BB_VERSION = "1.23.0"
> >> BUILD_SYS = "i686-linux"
> >> NATIVELSBSTRING = "Fedora-13"
> >> TARGET_SYS = "arm-poky-linux-gnueabi"
> >> MACHINE = "beaglebone"
> >> DISTRO = "poky"
> >> DISTRO_VERSION = "1.6+snapshot-20140411"
> >> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8"
> >> TARGET_FPU = "vfp-neon"
> >> meta
> >> meta-yocto
> >> meta-yocto-bsp = "master:863cc7483f5ee43189537940de8ee5c0964d24cc"
> >>
> >> This built the kernel using SRCREV 928d7b2dda
> >>
> >> I followed the bring-up instructions from README.hadware and the
> >> boot failed to even start the kernel. Here's what I see:
> >>
> >> =============================== boot log =========================================
> >> U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
> >>
> >> I2C: ready
> >> DRAM: 512 MiB
> >> WARNING: Caches not enabled
> >> NAND: 0 MiB
> >> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
> >> *** Warning - readenv() failed, using default environment
> >>
> >> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
> >> musb-hdrc: MHDRC RTL version 2.0
> >> musb-hdrc: setup fifo_mode 4
> >> musb-hdrc: 28/31 max ep, 16384/16384 memory
> >> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
> >> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
> >> musb-hdrc: MHDRC RTL version 2.0
> >> musb-hdrc: setup fifo_mode 4
> >> musb-hdrc: 28/31 max ep, 16384/16384 memory
> >> USB Host mode controller at 47401800 using PIO, IRQ 0
> >> Net: <ethaddr> not set. Validating first E-fuse MAC
> >> Phy not found
> >> PHY reset timed out
> >> cpsw, usb_ether
> >> Hit any key to stop autoboot: 0
> >> mmc0 is current device
> >> SD/MMC found on device 0
> >> reading uEnv.txt
> >> ** Unable to read file uEnv.txt **
> >> 4981688 bytes read in 613 ms (7.7 MiB/s)
> >> 29192 bytes read in 46 ms (619.1 KiB/s)
> >> Booting from mmc ...
> >> ## Booting kernel from Legacy Image at 80200000 ...
> >> Image Name: Linux-3.14.0-yocto-standard
> >> Image Type: ARM Linux Kernel Image (uncompressed)
> >> Data Size: 4981624 Bytes = 4.8 MiB
> >> Load Address: 80008000
> >> Entry Point: 80008000
> >> Verifying Checksum ... OK
> >> ## Flattened Device Tree blob at 80f80000
> >> Booting using the fdt blob at 0x80f80000
> >> Loading Kernel Image ... OK
> >> Using Device Tree in place at 80f80000, end 80f8a207
> >>
> >> Starting kernel ...
> >> ==================================================================================
> >>
> >> Any ideas what I've done wrong?
> >
> > Hmm, everything looks sane. What revision is your BBB? And did you press
> > USER/BOOT button or erased eMMC partition per instructions?
> >
>
> Revision A5A, with an LCD cape
Hmm, I'm wondering if LCD cape conflicts here - there's no cape support in
this BSP. Can you try w/o it?
As of the board revision - I was testing on different ones from A1 to A6 and
didn't see any major issue...
--
Denys
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-14 15:46 ` Denys Dmytriyenko
@ 2014-04-14 15:51 ` Gary Thomas
2014-04-14 16:00 ` Denys Dmytriyenko
0 siblings, 1 reply; 49+ messages in thread
From: Gary Thomas @ 2014-04-14 15:51 UTC (permalink / raw)
To: Denys Dmytriyenko; +Cc: yocto
On 2014-04-14 09:46, Denys Dmytriyenko wrote:
> On Mon, Apr 14, 2014 at 04:25:55AM -0600, Gary Thomas wrote:
>> On 2014-04-13 20:33, Denys Dmytriyenko wrote:
>>> On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote:
>>>> I just tried building (core-image-sato) for my BeagleBoneBlack
>>>> using the latest Poky/Yocto master:
>>>>
>>>> Build Configuration:
>>>> BB_VERSION = "1.23.0"
>>>> BUILD_SYS = "i686-linux"
>>>> NATIVELSBSTRING = "Fedora-13"
>>>> TARGET_SYS = "arm-poky-linux-gnueabi"
>>>> MACHINE = "beaglebone"
>>>> DISTRO = "poky"
>>>> DISTRO_VERSION = "1.6+snapshot-20140411"
>>>> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8"
>>>> TARGET_FPU = "vfp-neon"
>>>> meta
>>>> meta-yocto
>>>> meta-yocto-bsp = "master:863cc7483f5ee43189537940de8ee5c0964d24cc"
>>>>
>>>> This built the kernel using SRCREV 928d7b2dda
>>>>
>>>> I followed the bring-up instructions from README.hadware and the
>>>> boot failed to even start the kernel. Here's what I see:
>>>>
>>>> =============================== boot log =========================================
>>>> U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
>>>>
>>>> I2C: ready
>>>> DRAM: 512 MiB
>>>> WARNING: Caches not enabled
>>>> NAND: 0 MiB
>>>> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
>>>> *** Warning - readenv() failed, using default environment
>>>>
>>>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
>>>> musb-hdrc: MHDRC RTL version 2.0
>>>> musb-hdrc: setup fifo_mode 4
>>>> musb-hdrc: 28/31 max ep, 16384/16384 memory
>>>> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
>>>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
>>>> musb-hdrc: MHDRC RTL version 2.0
>>>> musb-hdrc: setup fifo_mode 4
>>>> musb-hdrc: 28/31 max ep, 16384/16384 memory
>>>> USB Host mode controller at 47401800 using PIO, IRQ 0
>>>> Net: <ethaddr> not set. Validating first E-fuse MAC
>>>> Phy not found
>>>> PHY reset timed out
>>>> cpsw, usb_ether
>>>> Hit any key to stop autoboot: 0
>>>> mmc0 is current device
>>>> SD/MMC found on device 0
>>>> reading uEnv.txt
>>>> ** Unable to read file uEnv.txt **
>>>> 4981688 bytes read in 613 ms (7.7 MiB/s)
>>>> 29192 bytes read in 46 ms (619.1 KiB/s)
>>>> Booting from mmc ...
>>>> ## Booting kernel from Legacy Image at 80200000 ...
>>>> Image Name: Linux-3.14.0-yocto-standard
>>>> Image Type: ARM Linux Kernel Image (uncompressed)
>>>> Data Size: 4981624 Bytes = 4.8 MiB
>>>> Load Address: 80008000
>>>> Entry Point: 80008000
>>>> Verifying Checksum ... OK
>>>> ## Flattened Device Tree blob at 80f80000
>>>> Booting using the fdt blob at 0x80f80000
>>>> Loading Kernel Image ... OK
>>>> Using Device Tree in place at 80f80000, end 80f8a207
>>>>
>>>> Starting kernel ...
>>>> ==================================================================================
>>>>
>>>> Any ideas what I've done wrong?
>>>
>>> Hmm, everything looks sane. What revision is your BBB? And did you press
>>> USER/BOOT button or erased eMMC partition per instructions?
>>>
>>
>> Revision A5A, with an LCD cape
>
> Hmm, I'm wondering if LCD cape conflicts here - there's no cape support in
> this BSP. Can you try w/o it?
Sure I can try it but I don't think that's it. I got the kernel that StefanX
built and booted and tried it on my board and it came up. No clue why the
kernels are different - ostensibly we both built the same image from the same
meta data, but they are slightly different (only in size - I compared the
System.map files from both builds and they contain exactly the same bits,
just a few changes in memory layout which I can't explain).
I'm trying another build from scratch using a different build host to see
if that makes a difference.
> As of the board revision - I was testing on different ones from A1 to A6 and
> didn't see any major issue...
>
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-14 15:51 ` Gary Thomas
@ 2014-04-14 16:00 ` Denys Dmytriyenko
2014-04-14 16:04 ` Gary Thomas
0 siblings, 1 reply; 49+ messages in thread
From: Denys Dmytriyenko @ 2014-04-14 16:00 UTC (permalink / raw)
To: Gary Thomas; +Cc: yocto
On Mon, Apr 14, 2014 at 09:51:49AM -0600, Gary Thomas wrote:
> On 2014-04-14 09:46, Denys Dmytriyenko wrote:
> > On Mon, Apr 14, 2014 at 04:25:55AM -0600, Gary Thomas wrote:
> >> On 2014-04-13 20:33, Denys Dmytriyenko wrote:
> >>> On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote:
> >>>> I just tried building (core-image-sato) for my BeagleBoneBlack
> >>>> using the latest Poky/Yocto master:
> >>>>
> >>>> Build Configuration:
> >>>> BB_VERSION = "1.23.0"
> >>>> BUILD_SYS = "i686-linux"
> >>>> NATIVELSBSTRING = "Fedora-13"
> >>>> TARGET_SYS = "arm-poky-linux-gnueabi"
> >>>> MACHINE = "beaglebone"
> >>>> DISTRO = "poky"
> >>>> DISTRO_VERSION = "1.6+snapshot-20140411"
> >>>> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8"
> >>>> TARGET_FPU = "vfp-neon"
> >>>> meta
> >>>> meta-yocto
> >>>> meta-yocto-bsp = "master:863cc7483f5ee43189537940de8ee5c0964d24cc"
> >>>>
> >>>> This built the kernel using SRCREV 928d7b2dda
> >>>>
> >>>> I followed the bring-up instructions from README.hadware and the
> >>>> boot failed to even start the kernel. Here's what I see:
> >>>>
> >>>> =============================== boot log =========================================
> >>>> U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
> >>>>
> >>>> I2C: ready
> >>>> DRAM: 512 MiB
> >>>> WARNING: Caches not enabled
> >>>> NAND: 0 MiB
> >>>> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
> >>>> *** Warning - readenv() failed, using default environment
> >>>>
> >>>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
> >>>> musb-hdrc: MHDRC RTL version 2.0
> >>>> musb-hdrc: setup fifo_mode 4
> >>>> musb-hdrc: 28/31 max ep, 16384/16384 memory
> >>>> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
> >>>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
> >>>> musb-hdrc: MHDRC RTL version 2.0
> >>>> musb-hdrc: setup fifo_mode 4
> >>>> musb-hdrc: 28/31 max ep, 16384/16384 memory
> >>>> USB Host mode controller at 47401800 using PIO, IRQ 0
> >>>> Net: <ethaddr> not set. Validating first E-fuse MAC
> >>>> Phy not found
> >>>> PHY reset timed out
> >>>> cpsw, usb_ether
> >>>> Hit any key to stop autoboot: 0
> >>>> mmc0 is current device
> >>>> SD/MMC found on device 0
> >>>> reading uEnv.txt
> >>>> ** Unable to read file uEnv.txt **
> >>>> 4981688 bytes read in 613 ms (7.7 MiB/s)
> >>>> 29192 bytes read in 46 ms (619.1 KiB/s)
> >>>> Booting from mmc ...
> >>>> ## Booting kernel from Legacy Image at 80200000 ...
> >>>> Image Name: Linux-3.14.0-yocto-standard
> >>>> Image Type: ARM Linux Kernel Image (uncompressed)
> >>>> Data Size: 4981624 Bytes = 4.8 MiB
> >>>> Load Address: 80008000
> >>>> Entry Point: 80008000
> >>>> Verifying Checksum ... OK
> >>>> ## Flattened Device Tree blob at 80f80000
> >>>> Booting using the fdt blob at 0x80f80000
> >>>> Loading Kernel Image ... OK
> >>>> Using Device Tree in place at 80f80000, end 80f8a207
> >>>>
> >>>> Starting kernel ...
> >>>> ==================================================================================
> >>>>
> >>>> Any ideas what I've done wrong?
> >>>
> >>> Hmm, everything looks sane. What revision is your BBB? And did you press
> >>> USER/BOOT button or erased eMMC partition per instructions?
> >>>
> >>
> >> Revision A5A, with an LCD cape
> >
> > Hmm, I'm wondering if LCD cape conflicts here - there's no cape support in
> > this BSP. Can you try w/o it?
>
> Sure I can try it but I don't think that's it. I got the kernel that StefanX
> built and booted and tried it on my board and it came up. No clue why the
> kernels are different - ostensibly we both built the same image from the same
> meta data, but they are slightly different (only in size - I compared the
> System.map files from both builds and they contain exactly the same bits,
> just a few changes in memory layout which I can't explain).
Yeah, good point. Doesn't look like your cape causes the issue...
The only other difference is in the host. Do you have access to another Linux
box you can try? FWIW, I'm using 64-bit Gentoo with gcc-4.7.3. Yours is 32-bit
Fedora 13, right?
> I'm trying another build from scratch using a different build host to see
> if that makes a difference.
Do you have any other layers or customizations on top? (the metadata above
suggests you build just pure Poky though)
--
Denys
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-14 16:00 ` Denys Dmytriyenko
@ 2014-04-14 16:04 ` Gary Thomas
2014-04-14 16:08 ` Denys Dmytriyenko
0 siblings, 1 reply; 49+ messages in thread
From: Gary Thomas @ 2014-04-14 16:04 UTC (permalink / raw)
To: Denys Dmytriyenko; +Cc: yocto
On 2014-04-14 10:00, Denys Dmytriyenko wrote:
> On Mon, Apr 14, 2014 at 09:51:49AM -0600, Gary Thomas wrote:
>> On 2014-04-14 09:46, Denys Dmytriyenko wrote:
>>> On Mon, Apr 14, 2014 at 04:25:55AM -0600, Gary Thomas wrote:
>>>> On 2014-04-13 20:33, Denys Dmytriyenko wrote:
>>>>> On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote:
>>>>>> I just tried building (core-image-sato) for my BeagleBoneBlack
>>>>>> using the latest Poky/Yocto master:
>>>>>>
>>>>>> Build Configuration:
>>>>>> BB_VERSION = "1.23.0"
>>>>>> BUILD_SYS = "i686-linux"
>>>>>> NATIVELSBSTRING = "Fedora-13"
>>>>>> TARGET_SYS = "arm-poky-linux-gnueabi"
>>>>>> MACHINE = "beaglebone"
>>>>>> DISTRO = "poky"
>>>>>> DISTRO_VERSION = "1.6+snapshot-20140411"
>>>>>> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8"
>>>>>> TARGET_FPU = "vfp-neon"
>>>>>> meta
>>>>>> meta-yocto
>>>>>> meta-yocto-bsp = "master:863cc7483f5ee43189537940de8ee5c0964d24cc"
>>>>>>
>>>>>> This built the kernel using SRCREV 928d7b2dda
>>>>>>
>>>>>> I followed the bring-up instructions from README.hadware and the
>>>>>> boot failed to even start the kernel. Here's what I see:
>>>>>>
>>>>>> =============================== boot log =========================================
>>>>>> U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
>>>>>>
>>>>>> I2C: ready
>>>>>> DRAM: 512 MiB
>>>>>> WARNING: Caches not enabled
>>>>>> NAND: 0 MiB
>>>>>> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
>>>>>> *** Warning - readenv() failed, using default environment
>>>>>>
>>>>>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
>>>>>> musb-hdrc: MHDRC RTL version 2.0
>>>>>> musb-hdrc: setup fifo_mode 4
>>>>>> musb-hdrc: 28/31 max ep, 16384/16384 memory
>>>>>> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
>>>>>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
>>>>>> musb-hdrc: MHDRC RTL version 2.0
>>>>>> musb-hdrc: setup fifo_mode 4
>>>>>> musb-hdrc: 28/31 max ep, 16384/16384 memory
>>>>>> USB Host mode controller at 47401800 using PIO, IRQ 0
>>>>>> Net: <ethaddr> not set. Validating first E-fuse MAC
>>>>>> Phy not found
>>>>>> PHY reset timed out
>>>>>> cpsw, usb_ether
>>>>>> Hit any key to stop autoboot: 0
>>>>>> mmc0 is current device
>>>>>> SD/MMC found on device 0
>>>>>> reading uEnv.txt
>>>>>> ** Unable to read file uEnv.txt **
>>>>>> 4981688 bytes read in 613 ms (7.7 MiB/s)
>>>>>> 29192 bytes read in 46 ms (619.1 KiB/s)
>>>>>> Booting from mmc ...
>>>>>> ## Booting kernel from Legacy Image at 80200000 ...
>>>>>> Image Name: Linux-3.14.0-yocto-standard
>>>>>> Image Type: ARM Linux Kernel Image (uncompressed)
>>>>>> Data Size: 4981624 Bytes = 4.8 MiB
>>>>>> Load Address: 80008000
>>>>>> Entry Point: 80008000
>>>>>> Verifying Checksum ... OK
>>>>>> ## Flattened Device Tree blob at 80f80000
>>>>>> Booting using the fdt blob at 0x80f80000
>>>>>> Loading Kernel Image ... OK
>>>>>> Using Device Tree in place at 80f80000, end 80f8a207
>>>>>>
>>>>>> Starting kernel ...
>>>>>> ==================================================================================
>>>>>>
>>>>>> Any ideas what I've done wrong?
>>>>>
>>>>> Hmm, everything looks sane. What revision is your BBB? And did you press
>>>>> USER/BOOT button or erased eMMC partition per instructions?
>>>>>
>>>>
>>>> Revision A5A, with an LCD cape
>>>
>>> Hmm, I'm wondering if LCD cape conflicts here - there's no cape support in
>>> this BSP. Can you try w/o it?
>>
>> Sure I can try it but I don't think that's it. I got the kernel that StefanX
>> built and booted and tried it on my board and it came up. No clue why the
>> kernels are different - ostensibly we both built the same image from the same
>> meta data, but they are slightly different (only in size - I compared the
>> System.map files from both builds and they contain exactly the same bits,
>> just a few changes in memory layout which I can't explain).
>
> Yeah, good point. Doesn't look like your cape causes the issue...
> The only other difference is in the host. Do you have access to another Linux
> box you can try? FWIW, I'm using 64-bit Gentoo with gcc-4.7.3. Yours is 32-bit
> Fedora 13, right?
I'll try Fedora 17 and Ubuntu 12.04 (x86_64) and see what happens.
Note: I use the Fedora 13 system *all* the time for my other Poky/Yocto builds.
>
>> I'm trying another build from scratch using a different build host to see
>> if that makes a difference.
>
> Do you have any other layers or customizations on top? (the metadata above
> suggests you build just pure Poky though)
I was trying this on a pure Poky/Yocto build.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-14 16:04 ` Gary Thomas
@ 2014-04-14 16:08 ` Denys Dmytriyenko
2014-04-14 20:11 ` Gary Thomas
0 siblings, 1 reply; 49+ messages in thread
From: Denys Dmytriyenko @ 2014-04-14 16:08 UTC (permalink / raw)
To: Gary Thomas; +Cc: yocto
On Mon, Apr 14, 2014 at 10:04:41AM -0600, Gary Thomas wrote:
> On 2014-04-14 10:00, Denys Dmytriyenko wrote:
> > On Mon, Apr 14, 2014 at 09:51:49AM -0600, Gary Thomas wrote:
> >> On 2014-04-14 09:46, Denys Dmytriyenko wrote:
> >>> On Mon, Apr 14, 2014 at 04:25:55AM -0600, Gary Thomas wrote:
> >>>> On 2014-04-13 20:33, Denys Dmytriyenko wrote:
> >>>>> On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote:
> >>>>>> I just tried building (core-image-sato) for my BeagleBoneBlack
> >>>>>> using the latest Poky/Yocto master:
> >>>>>>
> >>>>>> Build Configuration:
> >>>>>> BB_VERSION = "1.23.0"
> >>>>>> BUILD_SYS = "i686-linux"
> >>>>>> NATIVELSBSTRING = "Fedora-13"
> >>>>>> TARGET_SYS = "arm-poky-linux-gnueabi"
> >>>>>> MACHINE = "beaglebone"
> >>>>>> DISTRO = "poky"
> >>>>>> DISTRO_VERSION = "1.6+snapshot-20140411"
> >>>>>> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8"
> >>>>>> TARGET_FPU = "vfp-neon"
> >>>>>> meta
> >>>>>> meta-yocto
> >>>>>> meta-yocto-bsp = "master:863cc7483f5ee43189537940de8ee5c0964d24cc"
> >>>>>>
> >>>>>> This built the kernel using SRCREV 928d7b2dda
> >>>>>>
> >>>>>> I followed the bring-up instructions from README.hadware and the
> >>>>>> boot failed to even start the kernel. Here's what I see:
> >>>>>>
> >>>>>> =============================== boot log =========================================
> >>>>>> U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
> >>>>>>
> >>>>>> I2C: ready
> >>>>>> DRAM: 512 MiB
> >>>>>> WARNING: Caches not enabled
> >>>>>> NAND: 0 MiB
> >>>>>> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
> >>>>>> *** Warning - readenv() failed, using default environment
> >>>>>>
> >>>>>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
> >>>>>> musb-hdrc: MHDRC RTL version 2.0
> >>>>>> musb-hdrc: setup fifo_mode 4
> >>>>>> musb-hdrc: 28/31 max ep, 16384/16384 memory
> >>>>>> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
> >>>>>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
> >>>>>> musb-hdrc: MHDRC RTL version 2.0
> >>>>>> musb-hdrc: setup fifo_mode 4
> >>>>>> musb-hdrc: 28/31 max ep, 16384/16384 memory
> >>>>>> USB Host mode controller at 47401800 using PIO, IRQ 0
> >>>>>> Net: <ethaddr> not set. Validating first E-fuse MAC
> >>>>>> Phy not found
> >>>>>> PHY reset timed out
> >>>>>> cpsw, usb_ether
> >>>>>> Hit any key to stop autoboot: 0
> >>>>>> mmc0 is current device
> >>>>>> SD/MMC found on device 0
> >>>>>> reading uEnv.txt
> >>>>>> ** Unable to read file uEnv.txt **
> >>>>>> 4981688 bytes read in 613 ms (7.7 MiB/s)
> >>>>>> 29192 bytes read in 46 ms (619.1 KiB/s)
> >>>>>> Booting from mmc ...
> >>>>>> ## Booting kernel from Legacy Image at 80200000 ...
> >>>>>> Image Name: Linux-3.14.0-yocto-standard
> >>>>>> Image Type: ARM Linux Kernel Image (uncompressed)
> >>>>>> Data Size: 4981624 Bytes = 4.8 MiB
> >>>>>> Load Address: 80008000
> >>>>>> Entry Point: 80008000
> >>>>>> Verifying Checksum ... OK
> >>>>>> ## Flattened Device Tree blob at 80f80000
> >>>>>> Booting using the fdt blob at 0x80f80000
> >>>>>> Loading Kernel Image ... OK
> >>>>>> Using Device Tree in place at 80f80000, end 80f8a207
> >>>>>>
> >>>>>> Starting kernel ...
> >>>>>> ==================================================================================
> >>>>>>
> >>>>>> Any ideas what I've done wrong?
> >>>>>
> >>>>> Hmm, everything looks sane. What revision is your BBB? And did you press
> >>>>> USER/BOOT button or erased eMMC partition per instructions?
> >>>>>
> >>>>
> >>>> Revision A5A, with an LCD cape
> >>>
> >>> Hmm, I'm wondering if LCD cape conflicts here - there's no cape support in
> >>> this BSP. Can you try w/o it?
> >>
> >> Sure I can try it but I don't think that's it. I got the kernel that StefanX
> >> built and booted and tried it on my board and it came up. No clue why the
> >> kernels are different - ostensibly we both built the same image from the same
> >> meta data, but they are slightly different (only in size - I compared the
> >> System.map files from both builds and they contain exactly the same bits,
> >> just a few changes in memory layout which I can't explain).
> >
> > Yeah, good point. Doesn't look like your cape causes the issue...
> > The only other difference is in the host. Do you have access to another Linux
> > box you can try? FWIW, I'm using 64-bit Gentoo with gcc-4.7.3. Yours is 32-bit
> > Fedora 13, right?
>
> I'll try Fedora 17 and Ubuntu 12.04 (x86_64) and see what happens.
>
> Note: I use the Fedora 13 system *all* the time for my other Poky/Yocto builds.
Yeah, it usually shouldn't matter, as OE is very good at isolating host
differences. But at this point we need to eliminate every variable...
> >> I'm trying another build from scratch using a different build host to see
> >> if that makes a difference.
> >
> > Do you have any other layers or customizations on top? (the metadata above
> > suggests you build just pure Poky though)
>
> I was trying this on a pure Poky/Yocto build.
>
> --
> ------------------------------------------------------------
> Gary Thomas | Consulting for the
> MLB Associates | Embedded world
> ------------------------------------------------------------
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-14 16:08 ` Denys Dmytriyenko
@ 2014-04-14 20:11 ` Gary Thomas
2014-04-14 22:44 ` Denys Dmytriyenko
0 siblings, 1 reply; 49+ messages in thread
From: Gary Thomas @ 2014-04-14 20:11 UTC (permalink / raw)
To: yocto
On 2014-04-14 10:08, Denys Dmytriyenko wrote:
> On Mon, Apr 14, 2014 at 10:04:41AM -0600, Gary Thomas wrote:
>> On 2014-04-14 10:00, Denys Dmytriyenko wrote:
>>> On Mon, Apr 14, 2014 at 09:51:49AM -0600, Gary Thomas wrote:
>>>> On 2014-04-14 09:46, Denys Dmytriyenko wrote:
>>>>> On Mon, Apr 14, 2014 at 04:25:55AM -0600, Gary Thomas wrote:
>>>>>> On 2014-04-13 20:33, Denys Dmytriyenko wrote:
>>>>>>> On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote:
>>>>>>>> I just tried building (core-image-sato) for my BeagleBoneBlack
>>>>>>>> using the latest Poky/Yocto master:
>>>>>>>>
>>>>>>>> Build Configuration:
>>>>>>>> BB_VERSION = "1.23.0"
>>>>>>>> BUILD_SYS = "i686-linux"
>>>>>>>> NATIVELSBSTRING = "Fedora-13"
>>>>>>>> TARGET_SYS = "arm-poky-linux-gnueabi"
>>>>>>>> MACHINE = "beaglebone"
>>>>>>>> DISTRO = "poky"
>>>>>>>> DISTRO_VERSION = "1.6+snapshot-20140411"
>>>>>>>> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8"
>>>>>>>> TARGET_FPU = "vfp-neon"
>>>>>>>> meta
>>>>>>>> meta-yocto
>>>>>>>> meta-yocto-bsp = "master:863cc7483f5ee43189537940de8ee5c0964d24cc"
>>>>>>>>
>>>>>>>> This built the kernel using SRCREV 928d7b2dda
>>>>>>>>
>>>>>>>> I followed the bring-up instructions from README.hadware and the
>>>>>>>> boot failed to even start the kernel. Here's what I see:
>>>>>>>>
>>>>>>>> =============================== boot log =========================================
>>>>>>>> U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
>>>>>>>>
>>>>>>>> I2C: ready
>>>>>>>> DRAM: 512 MiB
>>>>>>>> WARNING: Caches not enabled
>>>>>>>> NAND: 0 MiB
>>>>>>>> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
>>>>>>>> *** Warning - readenv() failed, using default environment
>>>>>>>>
>>>>>>>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
>>>>>>>> musb-hdrc: MHDRC RTL version 2.0
>>>>>>>> musb-hdrc: setup fifo_mode 4
>>>>>>>> musb-hdrc: 28/31 max ep, 16384/16384 memory
>>>>>>>> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
>>>>>>>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
>>>>>>>> musb-hdrc: MHDRC RTL version 2.0
>>>>>>>> musb-hdrc: setup fifo_mode 4
>>>>>>>> musb-hdrc: 28/31 max ep, 16384/16384 memory
>>>>>>>> USB Host mode controller at 47401800 using PIO, IRQ 0
>>>>>>>> Net: <ethaddr> not set. Validating first E-fuse MAC
>>>>>>>> Phy not found
>>>>>>>> PHY reset timed out
>>>>>>>> cpsw, usb_ether
>>>>>>>> Hit any key to stop autoboot: 0
>>>>>>>> mmc0 is current device
>>>>>>>> SD/MMC found on device 0
>>>>>>>> reading uEnv.txt
>>>>>>>> ** Unable to read file uEnv.txt **
>>>>>>>> 4981688 bytes read in 613 ms (7.7 MiB/s)
>>>>>>>> 29192 bytes read in 46 ms (619.1 KiB/s)
>>>>>>>> Booting from mmc ...
>>>>>>>> ## Booting kernel from Legacy Image at 80200000 ...
>>>>>>>> Image Name: Linux-3.14.0-yocto-standard
>>>>>>>> Image Type: ARM Linux Kernel Image (uncompressed)
>>>>>>>> Data Size: 4981624 Bytes = 4.8 MiB
>>>>>>>> Load Address: 80008000
>>>>>>>> Entry Point: 80008000
>>>>>>>> Verifying Checksum ... OK
>>>>>>>> ## Flattened Device Tree blob at 80f80000
>>>>>>>> Booting using the fdt blob at 0x80f80000
>>>>>>>> Loading Kernel Image ... OK
>>>>>>>> Using Device Tree in place at 80f80000, end 80f8a207
>>>>>>>>
>>>>>>>> Starting kernel ...
>>>>>>>> ==================================================================================
>>>>>>>>
>>>>>>>> Any ideas what I've done wrong?
>>>>>>>
>>>>>>> Hmm, everything looks sane. What revision is your BBB? And did you press
>>>>>>> USER/BOOT button or erased eMMC partition per instructions?
>>>>>>>
>>>>>>
>>>>>> Revision A5A, with an LCD cape
>>>>>
>>>>> Hmm, I'm wondering if LCD cape conflicts here - there's no cape support in
>>>>> this BSP. Can you try w/o it?
>>>>
>>>> Sure I can try it but I don't think that's it. I got the kernel that StefanX
>>>> built and booted and tried it on my board and it came up. No clue why the
>>>> kernels are different - ostensibly we both built the same image from the same
>>>> meta data, but they are slightly different (only in size - I compared the
>>>> System.map files from both builds and they contain exactly the same bits,
>>>> just a few changes in memory layout which I can't explain).
>>>
>>> Yeah, good point. Doesn't look like your cape causes the issue...
>>> The only other difference is in the host. Do you have access to another Linux
>>> box you can try? FWIW, I'm using 64-bit Gentoo with gcc-4.7.3. Yours is 32-bit
>>> Fedora 13, right?
>>
>> I'll try Fedora 17 and Ubuntu 12.04 (x86_64) and see what happens.
>>
>> Note: I use the Fedora 13 system *all* the time for my other Poky/Yocto builds.
>
> Yeah, it usually shouldn't matter, as OE is very good at isolating host
> differences. But at this point we need to eliminate every variable...
>
>
>>>> I'm trying another build from scratch using a different build host to see
>>>> if that makes a difference.
Very interesting results! These are the results from the build hosts I have:
Fedora 13 (i686) - fails
Fedora 17 (i686) - fails
Ubuntu 12.04 (x86_64) - boots
Note that I routinely build for other targets (which does imply other, mostly
older, kernels) using all of these machines with no differences based on the
build host.
I don't know what's unique about an x86_64 host, but it does seem to work.
I was trying this to see how the stock Yocto support for the BBB competes with
building using meta-beaglebone which I've been using successfully. Based on
these results, I'll be sticking with the meta-beaglebone approach for now
(not just for the booting issue, but support for my LCD cape and other things
that aren't there in the Yocto kernel)
>>> Do you have any other layers or customizations on top? (the metadata above
>>> suggests you build just pure Poky though)
>>
>> I was trying this on a pure Poky/Yocto build.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-14 20:11 ` Gary Thomas
@ 2014-04-14 22:44 ` Denys Dmytriyenko
2014-04-15 0:20 ` Richard Purdie
0 siblings, 1 reply; 49+ messages in thread
From: Denys Dmytriyenko @ 2014-04-14 22:44 UTC (permalink / raw)
To: Gary Thomas; +Cc: yocto
On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> Very interesting results! These are the results from the build hosts I have:
> Fedora 13 (i686) - fails
> Fedora 17 (i686) - fails
> Ubuntu 12.04 (x86_64) - boots
Interesting indeed. I have no idea what's so special about Fedora host - this
is the first time I hear about issues with it. I may try experimenting with
different VMs once I have more time...
> Note that I routinely build for other targets (which does imply other, mostly
> older, kernels) using all of these machines with no differences based on the
> build host.
Same here - building for different targets with different kernels from meta-ti
and on 32 and 64 bit hosts and never had an issue like that...
> I don't know what's unique about an x86_64 host, but it does seem to work.
>
> I was trying this to see how the stock Yocto support for the BBB competes with
> building using meta-beaglebone which I've been using successfully. Based on
> these results, I'll be sticking with the meta-beaglebone approach for now
> (not just for the booting issue, but support for my LCD cape and other things
> that aren't there in the Yocto kernel)
This is not a "Yocto" kernel, this is a vanilla mainline 3.14 kernel (as a
successor to 3.12 work done in meta-ti). Indeed, cape support is missing, as
it is still not merged upstream, going through numerous iterations... The
point of meta-beagleboard was to work on cape support and such, with the goal
to upstream it, while meta-ti kept on working on SoC and peripheral support.
Due to different circumstances, meta-beagleboard still uses 3.8 kernel. Once
it is accepted upstream, it will be part of the mainline kernel and one of the
later versions of the Yocto Project reference BSP.
--
Denys
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-14 22:44 ` Denys Dmytriyenko
@ 2014-04-15 0:20 ` Richard Purdie
2014-04-15 1:38 ` Denys Dmytriyenko
0 siblings, 1 reply; 49+ messages in thread
From: Richard Purdie @ 2014-04-15 0:20 UTC (permalink / raw)
To: Denys Dmytriyenko; +Cc: yocto, Gary Thomas
On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> > Very interesting results! These are the results from the build hosts I have:
> > Fedora 13 (i686) - fails
> > Fedora 17 (i686) - fails
> > Ubuntu 12.04 (x86_64) - boots
>
> Interesting indeed. I have no idea what's so special about Fedora host - this
> is the first time I hear about issues with it. I may try experimenting with
> different VMs once I have more time...
I've been having a look at this. The biggest differences I can find
between working and non working builds is the path length to the build
directory for the kernel. This is from comparing vmlinux files from
working and non working builds.
Works:
/home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
Doesn't Work:
/media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
I also have been wondering if the version strings may be making a
difference.
http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build where I
truncated the path length to a "working" build path length and patched
in the same version strings:
const char linux_banner[] =
"Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc
version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014\n";
const char linux_proc_banner[] = "%s version %s (paul@ubuntu-build01)
(gcc version 4.8.2 (GCC) ) %s\n";
to init/version.c.
I don't have hardware and would be interested to know if the kernel
linked to above works or not. If it doesn't, it rules out these path and
string lengths, if it does work, it points to a problem there.
Cheers,
Richard
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 0:20 ` Richard Purdie
@ 2014-04-15 1:38 ` Denys Dmytriyenko
2014-04-15 4:44 ` Richard Purdie
0 siblings, 1 reply; 49+ messages in thread
From: Denys Dmytriyenko @ 2014-04-15 1:38 UTC (permalink / raw)
To: Richard Purdie; +Cc: yocto, Gary Thomas
On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> > > Very interesting results! These are the results from the build hosts I have:
> > > Fedora 13 (i686) - fails
> > > Fedora 17 (i686) - fails
> > > Ubuntu 12.04 (x86_64) - boots
> >
> > Interesting indeed. I have no idea what's so special about Fedora host - this
> > is the first time I hear about issues with it. I may try experimenting with
> > different VMs once I have more time...
>
> I've been having a look at this. The biggest differences I can find
> between working and non working builds is the path length to the build
> directory for the kernel. This is from comparing vmlinux files from
> working and non working builds.
>
> Works:
> /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
>
> Doesn't Work:
> /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
>
> I also have been wondering if the version strings may be making a
> difference.
>
> http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build where I
> truncated the path length to a "working" build path length and patched
> in the same version strings:
>
> const char linux_banner[] =
> "Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc
> version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014\n";
>
> const char linux_proc_banner[] = "%s version %s (paul@ubuntu-build01)
> (gcc version 4.8.2 (GCC) ) %s\n";
>
> to init/version.c.
>
> I don't have hardware and would be interested to know if the kernel
> linked to above works or not. If it doesn't, it rules out these path and
> string lengths, if it does work, it points to a problem there.
Richard,
Good catch! It boots:
U-Boot SPL 2013.07 (Apr 10 2014 - 04:47:32)
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
OMAP SD/MMC: 0
reading args
spl: error reading image args, err - -1
reading u-boot.img
reading u-boot.img
U-Boot 2013.07 (Apr 10 2014 - 04:47:32)
I2C: ready
DRAM: 512 MiB
WARNING: Caches not enabled
NAND: 0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net: <ethaddr> not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot: 0
mmc0 is current device
SD/MMC found on device 0
reading uEnv.txt
** Unable to read file uEnv.txt **
4985376 bytes read in 853 ms (5.6 MiB/s)
29192 bytes read in 28 ms (1017.6 KiB/s)
Booting from mmc ...
## Booting kernel from Legacy Image at 80200000 ...
Image Name: Linux-3.14.0-yocto-standard
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4985312 Bytes = 4.8 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 80f80000
Booting using the fdt blob at 0x80f80000
Loading Kernel Image ... OK
Using Device Tree in place at 80f80000, end 80f8a207
Starting kernel ...
Booting Linux on physical CPU 0x0
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Initializing cgroup subsys cpuacct
Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: TI AM335x BeagleBone
cma: CMA: reserved 16 MiB at 9e800000
Memory policy: Data cache writeback
CPU: All CPU(s) started in SVC mode.
AM335X ES2.0 (sgx neon )
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129792
Kernel command line: console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
allocated 1048576 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory cgroups
Memory: 489452K/523264K available (7491K kernel code, 520K rwdata, 2448K rodata, 488K init, 757K bss, 33812K reserved, 0K highmem)
[snip]
--
Denys
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 1:38 ` Denys Dmytriyenko
@ 2014-04-15 4:44 ` Richard Purdie
2014-04-15 5:07 ` Denys Dmytriyenko
0 siblings, 1 reply; 49+ messages in thread
From: Richard Purdie @ 2014-04-15 4:44 UTC (permalink / raw)
To: Denys Dmytriyenko; +Cc: yocto, Gary Thomas
On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> > > > Very interesting results! These are the results from the build hosts I have:
> > > > Fedora 13 (i686) - fails
> > > > Fedora 17 (i686) - fails
> > > > Ubuntu 12.04 (x86_64) - boots
> > >
> > > Interesting indeed. I have no idea what's so special about Fedora host - this
> > > is the first time I hear about issues with it. I may try experimenting with
> > > different VMs once I have more time...
> >
> > I've been having a look at this. The biggest differences I can find
> > between working and non working builds is the path length to the build
> > directory for the kernel. This is from comparing vmlinux files from
> > working and non working builds.
> >
> > Works:
> > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> >
> > Doesn't Work:
> > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> >
> > I also have been wondering if the version strings may be making a
> > difference.
> >
> > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build where I
> > truncated the path length to a "working" build path length and patched
> > in the same version strings:
> >
> > const char linux_banner[] =
> > "Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc
> > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014\n";
> >
> > const char linux_proc_banner[] = "%s version %s (paul@ubuntu-build01)
> > (gcc version 4.8.2 (GCC) ) %s\n";
> >
> > to init/version.c.
> >
> > I don't have hardware and would be interested to know if the kernel
> > linked to above works or not. If it doesn't, it rules out these path and
> > string lengths, if it does work, it points to a problem there.
>
> Richard,
>
> Good catch! It boots:
Thanks Denys, this helps narrow down the issue. I've shared
http://dan.rpsys.net/uImage-rp3 which is the same as the last one but
with my changes to version.c reverted. The one should tell us if its the
paths or the strings.
I'm guessing the path problem is more likely but anything is possible.
This is starting to look like some kind of compiler or linker issue. If
it is that, it would help to have more data points about what works and
what doesn't. With that in mind could people who have good or bad builds
please share the paths they built the kernels in so we can see if we can
spot some kind of pattern.
Cheers,
Richard
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 4:44 ` Richard Purdie
@ 2014-04-15 5:07 ` Denys Dmytriyenko
2014-04-15 5:17 ` Denys Dmytriyenko
0 siblings, 1 reply; 49+ messages in thread
From: Denys Dmytriyenko @ 2014-04-15 5:07 UTC (permalink / raw)
To: Richard Purdie; +Cc: yocto, Gary Thomas
On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> > > > > Very interesting results! These are the results from the build hosts I have:
> > > > > Fedora 13 (i686) - fails
> > > > > Fedora 17 (i686) - fails
> > > > > Ubuntu 12.04 (x86_64) - boots
> > > >
> > > > Interesting indeed. I have no idea what's so special about Fedora host - this
> > > > is the first time I hear about issues with it. I may try experimenting with
> > > > different VMs once I have more time...
> > >
> > > I've been having a look at this. The biggest differences I can find
> > > between working and non working builds is the path length to the build
> > > directory for the kernel. This is from comparing vmlinux files from
> > > working and non working builds.
> > >
> > > Works:
> > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > >
> > > Doesn't Work:
> > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > >
> > > I also have been wondering if the version strings may be making a
> > > difference.
> > >
> > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build where I
> > > truncated the path length to a "working" build path length and patched
> > > in the same version strings:
> > >
> > > const char linux_banner[] =
> > > "Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc
> > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014\n";
> > >
> > > const char linux_proc_banner[] = "%s version %s (paul@ubuntu-build01)
> > > (gcc version 4.8.2 (GCC) ) %s\n";
> > >
> > > to init/version.c.
> > >
> > > I don't have hardware and would be interested to know if the kernel
> > > linked to above works or not. If it doesn't, it rules out these path and
> > > string lengths, if it does work, it points to a problem there.
> >
> > Richard,
> >
> > Good catch! It boots:
>
> Thanks Denys, this helps narrow down the issue. I've shared
> http://dan.rpsys.net/uImage-rp3 which is the same as the last one but
> with my changes to version.c reverted. The one should tell us if its the
> paths or the strings.
This one also boots for me:
Linux version 3.14.0-yocto-standard (richard@ted) (gcc version 4.8.2 (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014
> I'm guessing the path problem is more likely but anything is possible.
> This is starting to look like some kind of compiler or linker issue. If
> it is that, it would help to have more data points about what works and
> what doesn't. With that in mind could people who have good or bad builds
> please share the paths they built the kernels in so we can see if we can
> spot some kind of pattern.
>
> Cheers,
>
> Richard
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 5:07 ` Denys Dmytriyenko
@ 2014-04-15 5:17 ` Denys Dmytriyenko
2014-04-15 9:03 ` Stanacar, StefanX
0 siblings, 1 reply; 49+ messages in thread
From: Denys Dmytriyenko @ 2014-04-15 5:17 UTC (permalink / raw)
To: Richard Purdie; +Cc: yocto, Gary Thomas
On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> > > > > > Very interesting results! These are the results from the build hosts I have:
> > > > > > Fedora 13 (i686) - fails
> > > > > > Fedora 17 (i686) - fails
> > > > > > Ubuntu 12.04 (x86_64) - boots
> > > > >
> > > > > Interesting indeed. I have no idea what's so special about Fedora host - this
> > > > > is the first time I hear about issues with it. I may try experimenting with
> > > > > different VMs once I have more time...
> > > >
> > > > I've been having a look at this. The biggest differences I can find
> > > > between working and non working builds is the path length to the build
> > > > directory for the kernel. This is from comparing vmlinux files from
> > > > working and non working builds.
> > > >
> > > > Works:
> > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > >
> > > > Doesn't Work:
> > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > >
> > > > I also have been wondering if the version strings may be making a
> > > > difference.
> > > >
> > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build where I
> > > > truncated the path length to a "working" build path length and patched
> > > > in the same version strings:
> > > >
> > > > const char linux_banner[] =
> > > > "Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc
> > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014\n";
> > > >
> > > > const char linux_proc_banner[] = "%s version %s (paul@ubuntu-build01)
> > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > >
> > > > to init/version.c.
> > > >
> > > > I don't have hardware and would be interested to know if the kernel
> > > > linked to above works or not. If it doesn't, it rules out these path and
> > > > string lengths, if it does work, it points to a problem there.
> > >
> > > Richard,
> > >
> > > Good catch! It boots:
> >
> > Thanks Denys, this helps narrow down the issue. I've shared
> > http://dan.rpsys.net/uImage-rp3 which is the same as the last one but
> > with my changes to version.c reverted. The one should tell us if its the
> > paths or the strings.
>
> This one also boots for me:
>
> Linux version 3.14.0-yocto-standard (richard@ted) (gcc version 4.8.2 (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014
>
>
> > I'm guessing the path problem is more likely but anything is possible.
> > This is starting to look like some kind of compiler or linker issue. If
> > it is that, it would help to have more data points about what works and
> > what doesn't. With that in mind could people who have good or bad builds
> > please share the paths they built the kernels in so we can see if we can
> > spot some kind of pattern.
BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi and it
works.
--
Denys
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 5:17 ` Denys Dmytriyenko
@ 2014-04-15 9:03 ` Stanacar, StefanX
2014-04-15 11:52 ` Stanacar, StefanX
2014-04-15 14:41 ` Gary Thomas
0 siblings, 2 replies; 49+ messages in thread
From: Stanacar, StefanX @ 2014-04-15 9:03 UTC (permalink / raw)
To: denis; +Cc: yocto, gary
On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> > > > > > > Very interesting results! These are the results from the build hosts I have:
> > > > > > > Fedora 13 (i686) - fails
> > > > > > > Fedora 17 (i686) - fails
> > > > > > > Ubuntu 12.04 (x86_64) - boots
> > > > > >
> > > > > > Interesting indeed. I have no idea what's so special about Fedora host - this
> > > > > > is the first time I hear about issues with it. I may try experimenting with
> > > > > > different VMs once I have more time...
> > > > >
> > > > > I've been having a look at this. The biggest differences I can find
> > > > > between working and non working builds is the path length to the build
> > > > > directory for the kernel. This is from comparing vmlinux files from
> > > > > working and non working builds.
> > > > >
> > > > > Works:
> > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > >
> > > > > Doesn't Work:
> > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > >
> > > > > I also have been wondering if the version strings may be making a
> > > > > difference.
> > > > >
> > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build where I
> > > > > truncated the path length to a "working" build path length and patched
> > > > > in the same version strings:
> > > > >
> > > > > const char linux_banner[] =
> > > > > "Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc
> > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014\n";
> > > > >
> > > > > const char linux_proc_banner[] = "%s version %s (paul@ubuntu-build01)
> > > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > > >
> > > > > to init/version.c.
> > > > >
> > > > > I don't have hardware and would be interested to know if the kernel
> > > > > linked to above works or not. If it doesn't, it rules out these path and
> > > > > string lengths, if it does work, it points to a problem there.
> > > >
> > > > Richard,
> > > >
> > > > Good catch! It boots:
> > >
> > > Thanks Denys, this helps narrow down the issue. I've shared
> > > http://dan.rpsys.net/uImage-rp3 which is the same as the last one but
> > > with my changes to version.c reverted. The one should tell us if its the
> > > paths or the strings.
> >
> > This one also boots for me:
> >
> > Linux version 3.14.0-yocto-standard (richard@ted) (gcc version 4.8.2 (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014
> >
> >
> > > I'm guessing the path problem is more likely but anything is possible.
> > > This is starting to look like some kind of compiler or linker issue. If
> > > it is that, it would help to have more data points about what works and
> > > what doesn't. With that in mind could people who have good or bad builds
> > > please share the paths they built the kernels in so we can see if we can
> > > spot some kind of pattern.
>
> BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi and it
> works.
>
I can confirm:
build dir in /home/stefans/b1 works,
but /home/stefans/yocto/poky/build doesn't.
Cheers,
Stefan
> --
> Denys
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 9:03 ` Stanacar, StefanX
@ 2014-04-15 11:52 ` Stanacar, StefanX
2014-04-15 14:42 ` Gary Thomas
2014-04-15 14:49 ` Paul Eggleton
2014-04-15 14:41 ` Gary Thomas
1 sibling, 2 replies; 49+ messages in thread
From: Stanacar, StefanX @ 2014-04-15 11:52 UTC (permalink / raw)
To: yocto
On Tue, 2014-04-15 at 09:03 +0000, Stanacar, StefanX wrote:
>
>
> On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> > On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> > > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> > > > > > > > Very interesting results! These are the results from the build hosts I have:
> > > > > > > > Fedora 13 (i686) - fails
> > > > > > > > Fedora 17 (i686) - fails
> > > > > > > > Ubuntu 12.04 (x86_64) - boots
> > > > > > >
> > > > > > > Interesting indeed. I have no idea what's so special about Fedora host - this
> > > > > > > is the first time I hear about issues with it. I may try experimenting with
> > > > > > > different VMs once I have more time...
> > > > > >
> > > > > > I've been having a look at this. The biggest differences I can find
> > > > > > between working and non working builds is the path length to the build
> > > > > > directory for the kernel. This is from comparing vmlinux files from
> > > > > > working and non working builds.
> > > > > >
> > > > > > Works:
> > > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > >
> > > > > > Doesn't Work:
> > > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > >
> > > > > > I also have been wondering if the version strings may be making a
> > > > > > difference.
> > > > > >
> > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build where I
> > > > > > truncated the path length to a "working" build path length and patched
> > > > > > in the same version strings:
> > > > > >
> > > > > > const char linux_banner[] =
> > > > > > "Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc
> > > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014\n";
> > > > > >
> > > > > > const char linux_proc_banner[] = "%s version %s (paul@ubuntu-build01)
> > > > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > > > >
> > > > > > to init/version.c.
> > > > > >
> > > > > > I don't have hardware and would be interested to know if the kernel
> > > > > > linked to above works or not. If it doesn't, it rules out these path and
> > > > > > string lengths, if it does work, it points to a problem there.
> > > > >
> > > > > Richard,
> > > > >
> > > > > Good catch! It boots:
> > > >
> > > > Thanks Denys, this helps narrow down the issue. I've shared
> > > > http://dan.rpsys.net/uImage-rp3 which is the same as the last one but
> > > > with my changes to version.c reverted. The one should tell us if its the
> > > > paths or the strings.
> > >
> > > This one also boots for me:
> > >
> > > Linux version 3.14.0-yocto-standard (richard@ted) (gcc version 4.8.2 (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014
> > >
> > >
> > > > I'm guessing the path problem is more likely but anything is possible.
> > > > This is starting to look like some kind of compiler or linker issue. If
> > > > it is that, it would help to have more data points about what works and
> > > > what doesn't. With that in mind could people who have good or bad builds
> > > > please share the paths they built the kernels in so we can see if we can
> > > > spot some kind of pattern.
> >
> > BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi and it
> > works.
> >
>
> I can confirm:
> build dir in /home/stefans/b1 works,
> but /home/stefans/yocto/poky/build doesn't.
>
But this works
[stefans@firebird bu]$ pwd
/home/stefans/yocto/poky/bu
[stefans@firebird bu]$ echo `pwd`| wc -c
28
But 29 doesn't.
So, what now?
Cheers,
Stefan
> Cheers,
> Stefan
>
> > --
> > Denys
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 9:03 ` Stanacar, StefanX
2014-04-15 11:52 ` Stanacar, StefanX
@ 2014-04-15 14:41 ` Gary Thomas
1 sibling, 0 replies; 49+ messages in thread
From: Gary Thomas @ 2014-04-15 14:41 UTC (permalink / raw)
To: yocto
On 2014-04-15 03:03, Stanacar, StefanX wrote:
>
>
>
> On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
>> On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
>>> On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
>>>> On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
>>>>> On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
>>>>>> On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
>>>>>>> On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
>>>>>>>> Very interesting results! These are the results from the build hosts I have:
>>>>>>>> Fedora 13 (i686) - fails
>>>>>>>> Fedora 17 (i686) - fails
>>>>>>>> Ubuntu 12.04 (x86_64) - boots
>>>>>>>
>>>>>>> Interesting indeed. I have no idea what's so special about Fedora host - this
>>>>>>> is the first time I hear about issues with it. I may try experimenting with
>>>>>>> different VMs once I have more time...
>>>>>>
>>>>>> I've been having a look at this. The biggest differences I can find
>>>>>> between working and non working builds is the path length to the build
>>>>>> directory for the kernel. This is from comparing vmlinux files from
>>>>>> working and non working builds.
>>>>>>
>>>>>> Works:
>>>>>> /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
>>>>>>
>>>>>> Doesn't Work:
>>>>>> /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
>>>>>>
>>>>>> I also have been wondering if the version strings may be making a
>>>>>> difference.
>>>>>>
>>>>>> http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build where I
>>>>>> truncated the path length to a "working" build path length and patched
>>>>>> in the same version strings:
>>>>>>
>>>>>> const char linux_banner[] =
>>>>>> "Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc
>>>>>> version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014\n";
>>>>>>
>>>>>> const char linux_proc_banner[] = "%s version %s (paul@ubuntu-build01)
>>>>>> (gcc version 4.8.2 (GCC) ) %s\n";
>>>>>>
>>>>>> to init/version.c.
>>>>>>
>>>>>> I don't have hardware and would be interested to know if the kernel
>>>>>> linked to above works or not. If it doesn't, it rules out these path and
>>>>>> string lengths, if it does work, it points to a problem there.
>>>>>
>>>>> Richard,
>>>>>
>>>>> Good catch! It boots:
>>>>
>>>> Thanks Denys, this helps narrow down the issue. I've shared
>>>> http://dan.rpsys.net/uImage-rp3 which is the same as the last one but
>>>> with my changes to version.c reverted. The one should tell us if its the
>>>> paths or the strings.
>>>
>>> This one also boots for me:
>>>
>>> Linux version 3.14.0-yocto-standard (richard@ted) (gcc version 4.8.2 (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014
>>>
>>>
>>>> I'm guessing the path problem is more likely but anything is possible.
>>>> This is starting to look like some kind of compiler or linker issue. If
>>>> it is that, it would help to have more data points about what works and
>>>> what doesn't. With that in mind could people who have good or bad builds
>>>> please share the paths they built the kernels in so we can see if we can
>>>> spot some kind of pattern.
>>
>> BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi and it
>> works.
>>
>
> I can confirm:
> build dir in /home/stefans/b1 works,
> but /home/stefans/yocto/poky/build doesn't.
My paths:
/local/bbb_yocto_2014-04-14 - works
/home/local/bbb_yocto_2014-04-14 - fails
/raid/work/tmp/bbb_yocto_2014-04-14 - fails
/tmp/bbb_yocto_2014-04-15 - works
/tmp/work/bbb_yocto_2014-04-15 - fails
/tmp/w2/bbb_yocto_2014-04-15 - fails
/tmp/w/bbb_yocto_2014-04-15 - works
Note: the last 5 were all built on the same host
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 11:52 ` Stanacar, StefanX
@ 2014-04-15 14:42 ` Gary Thomas
2014-04-15 14:49 ` Paul Eggleton
1 sibling, 0 replies; 49+ messages in thread
From: Gary Thomas @ 2014-04-15 14:42 UTC (permalink / raw)
To: yocto
On 2014-04-15 05:52, Stanacar, StefanX wrote:
>
>
>
> On Tue, 2014-04-15 at 09:03 +0000, Stanacar, StefanX wrote:
>>
>>
>> On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
>>> On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
>>>> On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
>>>>> On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
>>>>>> On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
>>>>>>> On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
>>>>>>>> On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
>>>>>>>>> Very interesting results! These are the results from the build hosts I have:
>>>>>>>>> Fedora 13 (i686) - fails
>>>>>>>>> Fedora 17 (i686) - fails
>>>>>>>>> Ubuntu 12.04 (x86_64) - boots
>>>>>>>>
>>>>>>>> Interesting indeed. I have no idea what's so special about Fedora host - this
>>>>>>>> is the first time I hear about issues with it. I may try experimenting with
>>>>>>>> different VMs once I have more time...
>>>>>>>
>>>>>>> I've been having a look at this. The biggest differences I can find
>>>>>>> between working and non working builds is the path length to the build
>>>>>>> directory for the kernel. This is from comparing vmlinux files from
>>>>>>> working and non working builds.
>>>>>>>
>>>>>>> Works:
>>>>>>> /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
>>>>>>>
>>>>>>> Doesn't Work:
>>>>>>> /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
>>>>>>>
>>>>>>> I also have been wondering if the version strings may be making a
>>>>>>> difference.
>>>>>>>
>>>>>>> http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build where I
>>>>>>> truncated the path length to a "working" build path length and patched
>>>>>>> in the same version strings:
>>>>>>>
>>>>>>> const char linux_banner[] =
>>>>>>> "Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc
>>>>>>> version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014\n";
>>>>>>>
>>>>>>> const char linux_proc_banner[] = "%s version %s (paul@ubuntu-build01)
>>>>>>> (gcc version 4.8.2 (GCC) ) %s\n";
>>>>>>>
>>>>>>> to init/version.c.
>>>>>>>
>>>>>>> I don't have hardware and would be interested to know if the kernel
>>>>>>> linked to above works or not. If it doesn't, it rules out these path and
>>>>>>> string lengths, if it does work, it points to a problem there.
>>>>>>
>>>>>> Richard,
>>>>>>
>>>>>> Good catch! It boots:
>>>>>
>>>>> Thanks Denys, this helps narrow down the issue. I've shared
>>>>> http://dan.rpsys.net/uImage-rp3 which is the same as the last one but
>>>>> with my changes to version.c reverted. The one should tell us if its the
>>>>> paths or the strings.
>>>>
>>>> This one also boots for me:
>>>>
>>>> Linux version 3.14.0-yocto-standard (richard@ted) (gcc version 4.8.2 (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014
>>>>
>>>>
>>>>> I'm guessing the path problem is more likely but anything is possible.
>>>>> This is starting to look like some kind of compiler or linker issue. If
>>>>> it is that, it would help to have more data points about what works and
>>>>> what doesn't. With that in mind could people who have good or bad builds
>>>>> please share the paths they built the kernels in so we can see if we can
>>>>> spot some kind of pattern.
>>>
>>> BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi and it
>>> works.
>>>
>>
>> I can confirm:
>> build dir in /home/stefans/b1 works,
>> but /home/stefans/yocto/poky/build doesn't.
>>
>
> But this works
> [stefans@firebird bu]$ pwd
> /home/stefans/yocto/poky/bu
> [stefans@firebird bu]$ echo `pwd`| wc -c
> 28
>
>
> But 29 doesn't.
> So, what now?
Hard to know, it might take debugging via JTAG to find out what's
happening since when it fails, it's so dead that nothing makes it
to the [dmesg] log buffer :-(
Sadly, I can't help much with this as I don't have a JTAG debug
setup for the BBB.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 11:52 ` Stanacar, StefanX
2014-04-15 14:42 ` Gary Thomas
@ 2014-04-15 14:49 ` Paul Eggleton
2014-04-15 15:15 ` Stoicescu, CorneliuX
2014-04-15 16:26 ` Denys Dmytriyenko
1 sibling, 2 replies; 49+ messages in thread
From: Paul Eggleton @ 2014-04-15 14:49 UTC (permalink / raw)
To: yocto
On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
> On Tue, 2014-04-15 at 09:03 +0000, Stanacar, StefanX wrote:
> > On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> > > On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > > > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> > > > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> > > > > > > > > Very interesting results! These are the results from the
build hosts I have:
> > > > > > > > > Fedora 13 (i686) - fails
> > > > > > > > > Fedora 17 (i686) - fails
> > > > > > > > > Ubuntu 12.04 (x86_64) - boots
> > > > > > > >
> > > > > > > > Interesting indeed. I have no idea what's so special about
> > > > > > > > Fedora host - this is the first time I hear about issues with
> > > > > > > > it. I may try experimenting with different VMs once I have
> > > > > > > > more time...
> > > > > > >
> > > > > > > I've been having a look at this. The biggest differences I can
> > > > > > > find
> > > > > > > between working and non working builds is the path length to the
> > > > > > > build
> > > > > > > directory for the kernel. This is from comparing vmlinux files
> > > > > > > from
> > > > > > > working and non working builds.
> > > > > > >
> > > > > > > Works:
> > > > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > > >
> > > > > > > Doesn't Work:
> > > > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gn
> > > > > > > ueabi
> > > > > > >
> > > > > > > I also have been wondering if the version strings may be making
> > > > > > > a
> > > > > > > difference.
> > > > > > >
> > > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build
> > > > > > > where I
> > > > > > > truncated the path length to a "working" build path length and
> > > > > > > patched
> > > > > > > in the same version strings:
> > > > > > >
> > > > > > > const char linux_banner[] =
> > > > > > >
> > > > > > > "Linux version 3.14.0-yocto-standard
> > > > > > > (paul@ubuntu-build01) (gcc
> > > > > > >
> > > > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST
> > > > > > > 2014\n";
> > > > > > >
> > > > > > > const char linux_proc_banner[] = "%s version %s
> > > > > > > (paul@ubuntu-build01)
> > > > > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > > > > >
> > > > > > > to init/version.c.
> > > > > > >
> > > > > > > I don't have hardware and would be interested to know if the
> > > > > > > kernel
> > > > > > > linked to above works or not. If it doesn't, it rules out these
> > > > > > > path and
> > > > > > > string lengths, if it does work, it points to a problem there.
> > > > > >
> > > > > > Richard,
> > > > >
> > > > > > Good catch! It boots:
> > > > > Thanks Denys, this helps narrow down the issue. I've shared
> > > > > http://dan.rpsys.net/uImage-rp3 which is the same as the last one
> > > > > but
> > > > > with my changes to version.c reverted. The one should tell us if its
> > > > > the
> > > > > paths or the strings.
> > > >
> > > > This one also boots for me:
> > > >
> > > > Linux version 3.14.0-yocto-standard (richard@ted) (gcc version 4.8.2
> > > > (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014> > >
> > > > > I'm guessing the path problem is more likely but anything is
> > > > > possible.
> > > > > This is starting to look like some kind of compiler or linker issue.
> > > > > If
> > > > > it is that, it would help to have more data points about what works
> > > > > and
> > > > > what doesn't. With that in mind could people who have good or bad
> > > > > builds
> > > > > please share the paths they built the kernels in so we can see if we
> > > > > can
> > > > > spot some kind of pattern.
> > >
> > > BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi and
> > > it works.
> >
> > I can confirm:
> > build dir in /home/stefans/b1 works,
> >
> > but /home/stefans/yocto/poky/build doesn't.
>
> But this works
> [stefans@firebird bu]$ pwd
> /home/stefans/yocto/poky/bu
> [stefans@firebird bu]$ echo `pwd`| wc -c
> 28
>
>
> But 29 doesn't.
> So, what now?
Some other things I tried with a "long" TMPDIR path (note that it's the TMPDIR
path that makes the difference - in my tests I've been using
/home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
* kernel built with gcc 4.7.2 and binutils 2.23.2
* u-boot built with gcc 4.7.2 and binutils 2.23.2
* u-boot from http://downloads.angstrom-distribution.org/demo/beaglebone/
* earlyprintk and CONFIG_DEBUG_LL - no additional output printed
I think we're now at the point where we'd benefit from someone with better
knowledge debugging the issue.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 14:49 ` Paul Eggleton
@ 2014-04-15 15:15 ` Stoicescu, CorneliuX
2014-04-15 15:37 ` Gary Thomas
2014-04-15 16:26 ` Denys Dmytriyenko
1 sibling, 1 reply; 49+ messages in thread
From: Stoicescu, CorneliuX @ 2014-04-15 15:15 UTC (permalink / raw)
To: Paul Eggleton, yocto
> -----Original Message-----
> From: yocto-bounces@yoctoproject.org [mailto:yocto-
> bounces@yoctoproject.org] On Behalf Of Paul Eggleton
> Sent: Tuesday, April 15, 2014 5:50 PM
> To: yocto@yoctoproject.org
> Subject: Re: [yocto] BBB doesn't boot
>
> On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
> > On Tue, 2014-04-15 at 09:03 +0000, Stanacar, StefanX wrote:
> > > On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> > > > On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > > > > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > > > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> > > > > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas
> wrote:
> > > > > > > > > > Very interesting results! These are the results from
> > > > > > > > > > the
> build hosts I have:
> > > > > > > > > > Fedora 13 (i686) - fails
> > > > > > > > > > Fedora 17 (i686) - fails
> > > > > > > > > > Ubuntu 12.04 (x86_64) - boots
> > > > > > > > >
> > > > > > > > > Interesting indeed. I have no idea what's so special
> > > > > > > > > about Fedora host - this is the first time I hear about
> > > > > > > > > issues with it. I may try experimenting with different
> > > > > > > > > VMs once I have more time...
> > > > > > > >
> > > > > > > > I've been having a look at this. The biggest differences I
> > > > > > > > can find between working and non working builds is the
> > > > > > > > path length to the build directory for the kernel. This is
> > > > > > > > from comparing vmlinux files from working and non working
> > > > > > > > builds.
> > > > > > > >
> > > > > > > > Works:
> > > > > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-
> gnuea
> > > > > > > > bi
> > > > > > > >
> > > > > > > > Doesn't Work:
> > > > > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-li
> > > > > > > > nux-gn
> > > > > > > > ueabi
> > > > > > > >
> > > > > > > > I also have been wondering if the version strings may be
> > > > > > > > making a difference.
> > > > > > > >
> > > > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken
> > > > > > > > build where I truncated the path length to a "working"
> > > > > > > > build path length and patched in the same version strings:
> > > > > > > >
> > > > > > > > const char linux_banner[] =
> > > > > > > >
> > > > > > > > "Linux version 3.14.0-yocto-standard
> > > > > > > > (paul@ubuntu-build01) (gcc
> > > > > > > >
> > > > > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST
> > > > > > > > 2014\n";
> > > > > > > >
> > > > > > > > const char linux_proc_banner[] = "%s version %s
> > > > > > > > (paul@ubuntu-build01)
> > > > > > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > > > > > >
> > > > > > > > to init/version.c.
> > > > > > > >
> > > > > > > > I don't have hardware and would be interested to know if
> > > > > > > > the kernel linked to above works or not. If it doesn't, it
> > > > > > > > rules out these path and string lengths, if it does work,
> > > > > > > > it points to a problem there.
> > > > > > >
> > > > > > > Richard,
> > > > > >
> > > > > > > Good catch! It boots:
> > > > > > Thanks Denys, this helps narrow down the issue. I've shared
> > > > > > http://dan.rpsys.net/uImage-rp3 which is the same as the last
> > > > > > one but with my changes to version.c reverted. The one should
> > > > > > tell us if its the paths or the strings.
> > > > >
> > > > > This one also boots for me:
> > > > >
> > > > > Linux version 3.14.0-yocto-standard (richard@ted) (gcc version
> > > > > 4.8.2
> > > > > (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014> > >
> > > > > > I'm guessing the path problem is more likely but anything is
> > > > > > possible.
> > > > > > This is starting to look like some kind of compiler or linker issue.
> > > > > > If
> > > > > > it is that, it would help to have more data points about what
> > > > > > works and what doesn't. With that in mind could people who
> > > > > > have good or bad builds please share the paths they built the
> > > > > > kernels in so we can see if we can spot some kind of pattern.
> > > >
> > > > BTW, my path is
> > > > /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi and it
> works.
> > >
> > > I can confirm:
> > > build dir in /home/stefans/b1 works,
> > >
> > > but /home/stefans/yocto/poky/build doesn't.
> >
> > But this works
> > [stefans@firebird bu]$ pwd
> > /home/stefans/yocto/poky/bu
> > [stefans@firebird bu]$ echo `pwd`| wc -c
> > 28
> >
> >
> > But 29 doesn't.
> > So, what now?
>
> Some other things I tried with a "long" TMPDIR path (note that it's the
> TMPDIR path that makes the difference - in my tests I've been using
> /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
>
> * kernel built with gcc 4.7.2 and binutils 2.23.2
> * u-boot built with gcc 4.7.2 and binutils 2.23.2
> * u-boot from http://downloads.angstrom-
> distribution.org/demo/beaglebone/
> * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
>
> I think we're now at the point where we'd benefit from someone with better
> knowledge debugging the issue.
>
> Cheers,
> Paul
>
I don't know if this is helpful but this TMPDIR path size issue reminded me of a bug I verified some time ago:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=3989
Regards,
Corneliu
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 15:15 ` Stoicescu, CorneliuX
@ 2014-04-15 15:37 ` Gary Thomas
0 siblings, 0 replies; 49+ messages in thread
From: Gary Thomas @ 2014-04-15 15:37 UTC (permalink / raw)
To: yocto
On 2014-04-15 09:15, Stoicescu, CorneliuX wrote:
>> -----Original Message-----
>> From: yocto-bounces@yoctoproject.org [mailto:yocto-
>> bounces@yoctoproject.org] On Behalf Of Paul Eggleton
>> Sent: Tuesday, April 15, 2014 5:50 PM
>> To: yocto@yoctoproject.org
>> Subject: Re: [yocto] BBB doesn't boot
>>
>> On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
>>> On Tue, 2014-04-15 at 09:03 +0000, Stanacar, StefanX wrote:
>>>> On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
>>>>> On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
>>>>>> On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
>>>>>>> On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
>>>>>>>> On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
>>>>>>>>> On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
>>>>>>>>>> On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas
>> wrote:
>>>>>>>>>>> Very interesting results! These are the results from
>>>>>>>>>>> the
>> build hosts I have:
>>>>>>>>>>> Fedora 13 (i686) - fails
>>>>>>>>>>> Fedora 17 (i686) - fails
>>>>>>>>>>> Ubuntu 12.04 (x86_64) - boots
>>>>>>>>>>
>>>>>>>>>> Interesting indeed. I have no idea what's so special
>>>>>>>>>> about Fedora host - this is the first time I hear about
>>>>>>>>>> issues with it. I may try experimenting with different
>>>>>>>>>> VMs once I have more time...
>>>>>>>>>
>>>>>>>>> I've been having a look at this. The biggest differences I
>>>>>>>>> can find between working and non working builds is the
>>>>>>>>> path length to the build directory for the kernel. This is
>>>>>>>>> from comparing vmlinux files from working and non working
>>>>>>>>> builds.
>>>>>>>>>
>>>>>>>>> Works:
>>>>>>>>> /home/paul/poky/build/tmp/work/beaglebone-poky-linux-
>> gnuea
>>>>>>>>> bi
>>>>>>>>>
>>>>>>>>> Doesn't Work:
>>>>>>>>> /media/data1/build1/poky/build/tmp/work/beaglebone-poky-li
>>>>>>>>> nux-gn
>>>>>>>>> ueabi
>>>>>>>>>
>>>>>>>>> I also have been wondering if the version strings may be
>>>>>>>>> making a difference.
>>>>>>>>>
>>>>>>>>> http://dan.rpsys.net/uImage-rp2 is a uImage from a broken
>>>>>>>>> build where I truncated the path length to a "working"
>>>>>>>>> build path length and patched in the same version strings:
>>>>>>>>>
>>>>>>>>> const char linux_banner[] =
>>>>>>>>>
>>>>>>>>> "Linux version 3.14.0-yocto-standard
>>>>>>>>> (paul@ubuntu-build01) (gcc
>>>>>>>>>
>>>>>>>>> version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST
>>>>>>>>> 2014\n";
>>>>>>>>>
>>>>>>>>> const char linux_proc_banner[] = "%s version %s
>>>>>>>>> (paul@ubuntu-build01)
>>>>>>>>> (gcc version 4.8.2 (GCC) ) %s\n";
>>>>>>>>>
>>>>>>>>> to init/version.c.
>>>>>>>>>
>>>>>>>>> I don't have hardware and would be interested to know if
>>>>>>>>> the kernel linked to above works or not. If it doesn't, it
>>>>>>>>> rules out these path and string lengths, if it does work,
>>>>>>>>> it points to a problem there.
>>>>>>>>
>>>>>>>> Richard,
>>>>>>>
>>>>>>>> Good catch! It boots:
>>>>>>> Thanks Denys, this helps narrow down the issue. I've shared
>>>>>>> http://dan.rpsys.net/uImage-rp3 which is the same as the last
>>>>>>> one but with my changes to version.c reverted. The one should
>>>>>>> tell us if its the paths or the strings.
>>>>>>
>>>>>> This one also boots for me:
>>>>>>
>>>>>> Linux version 3.14.0-yocto-standard (richard@ted) (gcc version
>>>>>> 4.8.2
>>>>>> (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014> > >
>>>>>>> I'm guessing the path problem is more likely but anything is
>>>>>>> possible.
>>>>>>> This is starting to look like some kind of compiler or linker issue.
>>>>>>> If
>>>>>>> it is that, it would help to have more data points about what
>>>>>>> works and what doesn't. With that in mind could people who
>>>>>>> have good or bad builds please share the paths they built the
>>>>>>> kernels in so we can see if we can spot some kind of pattern.
>>>>>
>>>>> BTW, my path is
>>>>> /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi and it
>> works.
>>>>
>>>> I can confirm:
>>>> build dir in /home/stefans/b1 works,
>>>>
>>>> but /home/stefans/yocto/poky/build doesn't.
>>>
>>> But this works
>>> [stefans@firebird bu]$ pwd
>>> /home/stefans/yocto/poky/bu
>>> [stefans@firebird bu]$ echo `pwd`| wc -c
>>> 28
>>>
>>>
>>> But 29 doesn't.
>>> So, what now?
>>
>> Some other things I tried with a "long" TMPDIR path (note that it's the
>> TMPDIR path that makes the difference - in my tests I've been using
>> /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
>>
>> * kernel built with gcc 4.7.2 and binutils 2.23.2
>> * u-boot built with gcc 4.7.2 and binutils 2.23.2
>> * u-boot from http://downloads.angstrom-
>> distribution.org/demo/beaglebone/
>> * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
>>
>> I think we're now at the point where we'd benefit from someone with better
>> knowledge debugging the issue.
>>
>> Cheers,
>> Paul
>>
>
> I don't know if this is helpful but this TMPDIR path size issue reminded me of a bug I verified some time ago:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=3989
Probably not related since the only component which seems
to be having issues is the kernel (you can use a kernel which
boots with any file system, no matter the build path length)
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 14:49 ` Paul Eggleton
2014-04-15 15:15 ` Stoicescu, CorneliuX
@ 2014-04-15 16:26 ` Denys Dmytriyenko
2014-04-15 16:36 ` Paul Eggleton
2014-04-15 17:25 ` Stanacar, StefanX
1 sibling, 2 replies; 49+ messages in thread
From: Denys Dmytriyenko @ 2014-04-15 16:26 UTC (permalink / raw)
To: Paul Eggleton; +Cc: yocto
On Tue, Apr 15, 2014 at 03:49:42PM +0100, Paul Eggleton wrote:
> On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
> > On Tue, 2014-04-15 at 09:03 +0000, Stanacar, StefanX wrote:
> > > On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> > > > On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > > > > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > > > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> > > > > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> > > > > > > > > > Very interesting results! These are the results from the
> build hosts I have:
> > > > > > > > > > Fedora 13 (i686) - fails
> > > > > > > > > > Fedora 17 (i686) - fails
> > > > > > > > > > Ubuntu 12.04 (x86_64) - boots
> > > > > > > > >
> > > > > > > > > Interesting indeed. I have no idea what's so special about
> > > > > > > > > Fedora host - this is the first time I hear about issues with
> > > > > > > > > it. I may try experimenting with different VMs once I have
> > > > > > > > > more time...
> > > > > > > >
> > > > > > > > I've been having a look at this. The biggest differences I can
> > > > > > > > find
> > > > > > > > between working and non working builds is the path length to the
> > > > > > > > build
> > > > > > > > directory for the kernel. This is from comparing vmlinux files
> > > > > > > > from
> > > > > > > > working and non working builds.
> > > > > > > >
> > > > > > > > Works:
> > > > > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > > > >
> > > > > > > > Doesn't Work:
> > > > > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gn
> > > > > > > > ueabi
> > > > > > > >
> > > > > > > > I also have been wondering if the version strings may be making
> > > > > > > > a
> > > > > > > > difference.
> > > > > > > >
> > > > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build
> > > > > > > > where I
> > > > > > > > truncated the path length to a "working" build path length and
> > > > > > > > patched
> > > > > > > > in the same version strings:
> > > > > > > >
> > > > > > > > const char linux_banner[] =
> > > > > > > >
> > > > > > > > "Linux version 3.14.0-yocto-standard
> > > > > > > > (paul@ubuntu-build01) (gcc
> > > > > > > >
> > > > > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST
> > > > > > > > 2014\n";
> > > > > > > >
> > > > > > > > const char linux_proc_banner[] = "%s version %s
> > > > > > > > (paul@ubuntu-build01)
> > > > > > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > > > > > >
> > > > > > > > to init/version.c.
> > > > > > > >
> > > > > > > > I don't have hardware and would be interested to know if the
> > > > > > > > kernel
> > > > > > > > linked to above works or not. If it doesn't, it rules out these
> > > > > > > > path and
> > > > > > > > string lengths, if it does work, it points to a problem there.
> > > > > > >
> > > > > > > Richard,
> > > > > >
> > > > > > > Good catch! It boots:
> > > > > > Thanks Denys, this helps narrow down the issue. I've shared
> > > > > > http://dan.rpsys.net/uImage-rp3 which is the same as the last one
> > > > > > but
> > > > > > with my changes to version.c reverted. The one should tell us if its
> > > > > > the
> > > > > > paths or the strings.
> > > > >
> > > > > This one also boots for me:
> > > > >
> > > > > Linux version 3.14.0-yocto-standard (richard@ted) (gcc version 4.8.2
> > > > > (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014> > >
> > > > > > I'm guessing the path problem is more likely but anything is
> > > > > > possible.
> > > > > > This is starting to look like some kind of compiler or linker issue.
> > > > > > If
> > > > > > it is that, it would help to have more data points about what works
> > > > > > and
> > > > > > what doesn't. With that in mind could people who have good or bad
> > > > > > builds
> > > > > > please share the paths they built the kernels in so we can see if we
> > > > > > can
> > > > > > spot some kind of pattern.
> > > >
> > > > BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi and
> > > > it works.
> > >
> > > I can confirm:
> > > build dir in /home/stefans/b1 works,
> > >
> > > but /home/stefans/yocto/poky/build doesn't.
> >
> > But this works
> > [stefans@firebird bu]$ pwd
> > /home/stefans/yocto/poky/bu
> > [stefans@firebird bu]$ echo `pwd`| wc -c
> > 28
> >
> >
> > But 29 doesn't.
> > So, what now?
>
> Some other things I tried with a "long" TMPDIR path (note that it's the TMPDIR
> path that makes the difference - in my tests I've been using
> /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
>
> * kernel built with gcc 4.7.2 and binutils 2.23.2
> * u-boot built with gcc 4.7.2 and binutils 2.23.2
> * u-boot from http://downloads.angstrom-distribution.org/demo/beaglebone/
> * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
>
> I think we're now at the point where we'd benefit from someone with better
> knowledge debugging the issue.
Ok, should we expand the search area? Since this is supposed to be vanilla
3.14 kernel, can we try other platforms and see if they are similarly
affected? I'll try pinging our kernel guys for any ideas...
--
Denys
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 16:26 ` Denys Dmytriyenko
@ 2014-04-15 16:36 ` Paul Eggleton
2014-04-15 17:16 ` Denys Dmytriyenko
2014-04-15 17:25 ` Stanacar, StefanX
1 sibling, 1 reply; 49+ messages in thread
From: Paul Eggleton @ 2014-04-15 16:36 UTC (permalink / raw)
To: Denys Dmytriyenko; +Cc: yocto
On Tuesday 15 April 2014 12:26:39 Denys Dmytriyenko wrote:
> On Tue, Apr 15, 2014 at 03:49:42PM +0100, Paul Eggleton wrote:
> > On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
> > > On Tue, 2014-04-15 at 09:03 +0000, Stanacar, StefanX wrote:
> > > > On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> > > > > On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > > > > > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > > > > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > > > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie
wrote:
> > > > > > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas
wrote:
> > > > > > > > > > > Very interesting results! These are the results from
> > > > > > > > > > > the
> >
> > build hosts I have:
> > > > > > > > > > > Fedora 13 (i686) - fails
> > > > > > > > > > > Fedora 17 (i686) - fails
> > > > > > > > > > > Ubuntu 12.04 (x86_64) - boots
> > > > > > > > > >
> > > > > > > > > > Interesting indeed. I have no idea what's so special about
> > > > > > > > > > Fedora host - this is the first time I hear about issues
> > > > > > > > > > with
> > > > > > > > > > it. I may try experimenting with different VMs once I have
> > > > > > > > > > more time...
> > > > > > > > >
> > > > > > > > > I've been having a look at this. The biggest differences I
> > > > > > > > > can
> > > > > > > > > find
> > > > > > > > > between working and non working builds is the path length to
> > > > > > > > > the
> > > > > > > > > build
> > > > > > > > > directory for the kernel. This is from comparing vmlinux
> > > > > > > > > files
> > > > > > > > > from
> > > > > > > > > working and non working builds.
> > > > > > > > >
> > > > > > > > > Works:
> > > > > > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > > > > >
> > > > > > > > > Doesn't Work:
> > > > > > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linu
> > > > > > > > > x-gn
> > > > > > > > > ueabi
> > > > > > > > >
> > > > > > > > > I also have been wondering if the version strings may be
> > > > > > > > > making
> > > > > > > > > a
> > > > > > > > > difference.
> > > > > > > > >
> > > > > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken
> > > > > > > > > build
> > > > > > > > > where I
> > > > > > > > > truncated the path length to a "working" build path length
> > > > > > > > > and
> > > > > > > > > patched
> > > > > > > > > in the same version strings:
> > > > > > > > >
> > > > > > > > > const char linux_banner[] =
> > > > > > > > >
> > > > > > > > > "Linux version 3.14.0-yocto-standard
> > > > > > > > > (paul@ubuntu-build01) (gcc
> > > > > > > > >
> > > > > > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST
> > > > > > > > > 2014\n";
> > > > > > > > >
> > > > > > > > > const char linux_proc_banner[] = "%s version %s
> > > > > > > > > (paul@ubuntu-build01)
> > > > > > > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > > > > > > >
> > > > > > > > > to init/version.c.
> > > > > > > > >
> > > > > > > > > I don't have hardware and would be interested to know if the
> > > > > > > > > kernel
> > > > > > > > > linked to above works or not. If it doesn't, it rules out
> > > > > > > > > these
> > > > > > > > > path and
> > > > > > > > > string lengths, if it does work, it points to a problem
> > > > > > > > > there.
> > > > > > > >
> > > > > > > > Richard,
> > > > > > >
> > > > > > > > Good catch! It boots:
> > > > > > > Thanks Denys, this helps narrow down the issue. I've shared
> > > > > > > http://dan.rpsys.net/uImage-rp3 which is the same as the last
> > > > > > > one
> > > > > > > but
> > > > > > > with my changes to version.c reverted. The one should tell us if
> > > > > > > its
> > > > > > > the
> > > > > > > paths or the strings.
> > > > > >
> > > > > > This one also boots for me:
> > > > > >
> > > > > > Linux version 3.14.0-yocto-standard (richard@ted) (gcc version
> > > > > > 4.8.2
> > > > > > (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014> > >
> > > > > >
> > > > > > > I'm guessing the path problem is more likely but anything is
> > > > > > > possible.
> > > > > > > This is starting to look like some kind of compiler or linker
> > > > > > > issue.
> > > > > > > If
> > > > > > > it is that, it would help to have more data points about what
> > > > > > > works
> > > > > > > and
> > > > > > > what doesn't. With that in mind could people who have good or
> > > > > > > bad
> > > > > > > builds
> > > > > > > please share the paths they built the kernels in so we can see
> > > > > > > if we
> > > > > > > can
> > > > > > > spot some kind of pattern.
> > > > >
> > > > > BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > and
> > > > > it works.
> > > >
> > > > I can confirm:
> > > > build dir in /home/stefans/b1 works,
> > > >
> > > > but /home/stefans/yocto/poky/build doesn't.
> > >
> > > But this works
> > > [stefans@firebird bu]$ pwd
> > > /home/stefans/yocto/poky/bu
> > > [stefans@firebird bu]$ echo `pwd`| wc -c
> > > 28
> > >
> > > But 29 doesn't.
> > > So, what now?
> >
> > Some other things I tried with a "long" TMPDIR path (note that it's the
> > TMPDIR path that makes the difference - in my tests I've been using
> > /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
> >
> > * kernel built with gcc 4.7.2 and binutils 2.23.2
> > * u-boot built with gcc 4.7.2 and binutils 2.23.2
> > * u-boot from http://downloads.angstrom-distribution.org/demo/beaglebone/
> > * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
> >
> > I think we're now at the point where we'd benefit from someone with better
> > knowledge debugging the issue.
>
> Ok, should we expand the search area? Since this is supposed to be vanilla
> 3.14 kernel, can we try other platforms and see if they are similarly
> affected? I'll try pinging our kernel guys for any ideas...
As far as I know it has only been observed with beaglebone (both white and
black, if it makes a difference). FWIW, qemuarm images from the autobuilder
boot just fine, and apparently the same is true of edgerouter (different
architecture but also uses u-boot).
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 16:36 ` Paul Eggleton
@ 2014-04-15 17:16 ` Denys Dmytriyenko
2014-04-15 17:41 ` Denys Dmytriyenko
0 siblings, 1 reply; 49+ messages in thread
From: Denys Dmytriyenko @ 2014-04-15 17:16 UTC (permalink / raw)
To: Paul Eggleton; +Cc: yocto
On Tue, Apr 15, 2014 at 05:36:10PM +0100, Paul Eggleton wrote:
> On Tuesday 15 April 2014 12:26:39 Denys Dmytriyenko wrote:
> > On Tue, Apr 15, 2014 at 03:49:42PM +0100, Paul Eggleton wrote:
> > > On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
> > > > On Tue, 2014-04-15 at 09:03 +0000, Stanacar, StefanX wrote:
> > > > > On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> > > > > > On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > > > > > > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > > > > > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > > > > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie
> wrote:
> > > > > > > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > > > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas
> wrote:
> > > > > > > > > > > > Very interesting results! These are the results from
> > > > > > > > > > > > the
> > >
> > > build hosts I have:
> > > > > > > > > > > > Fedora 13 (i686) - fails
> > > > > > > > > > > > Fedora 17 (i686) - fails
> > > > > > > > > > > > Ubuntu 12.04 (x86_64) - boots
> > > > > > > > > > >
> > > > > > > > > > > Interesting indeed. I have no idea what's so special about
> > > > > > > > > > > Fedora host - this is the first time I hear about issues
> > > > > > > > > > > with
> > > > > > > > > > > it. I may try experimenting with different VMs once I have
> > > > > > > > > > > more time...
> > > > > > > > > >
> > > > > > > > > > I've been having a look at this. The biggest differences I
> > > > > > > > > > can
> > > > > > > > > > find
> > > > > > > > > > between working and non working builds is the path length to
> > > > > > > > > > the
> > > > > > > > > > build
> > > > > > > > > > directory for the kernel. This is from comparing vmlinux
> > > > > > > > > > files
> > > > > > > > > > from
> > > > > > > > > > working and non working builds.
> > > > > > > > > >
> > > > > > > > > > Works:
> > > > > > > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > > > > > >
> > > > > > > > > > Doesn't Work:
> > > > > > > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linu
> > > > > > > > > > x-gn
> > > > > > > > > > ueabi
> > > > > > > > > >
> > > > > > > > > > I also have been wondering if the version strings may be
> > > > > > > > > > making
> > > > > > > > > > a
> > > > > > > > > > difference.
> > > > > > > > > >
> > > > > > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken
> > > > > > > > > > build
> > > > > > > > > > where I
> > > > > > > > > > truncated the path length to a "working" build path length
> > > > > > > > > > and
> > > > > > > > > > patched
> > > > > > > > > > in the same version strings:
> > > > > > > > > >
> > > > > > > > > > const char linux_banner[] =
> > > > > > > > > >
> > > > > > > > > > "Linux version 3.14.0-yocto-standard
> > > > > > > > > > (paul@ubuntu-build01) (gcc
> > > > > > > > > >
> > > > > > > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST
> > > > > > > > > > 2014\n";
> > > > > > > > > >
> > > > > > > > > > const char linux_proc_banner[] = "%s version %s
> > > > > > > > > > (paul@ubuntu-build01)
> > > > > > > > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > > > > > > > >
> > > > > > > > > > to init/version.c.
> > > > > > > > > >
> > > > > > > > > > I don't have hardware and would be interested to know if the
> > > > > > > > > > kernel
> > > > > > > > > > linked to above works or not. If it doesn't, it rules out
> > > > > > > > > > these
> > > > > > > > > > path and
> > > > > > > > > > string lengths, if it does work, it points to a problem
> > > > > > > > > > there.
> > > > > > > > >
> > > > > > > > > Richard,
> > > > > > > >
> > > > > > > > > Good catch! It boots:
> > > > > > > > Thanks Denys, this helps narrow down the issue. I've shared
> > > > > > > > http://dan.rpsys.net/uImage-rp3 which is the same as the last
> > > > > > > > one
> > > > > > > > but
> > > > > > > > with my changes to version.c reverted. The one should tell us if
> > > > > > > > its
> > > > > > > > the
> > > > > > > > paths or the strings.
> > > > > > >
> > > > > > > This one also boots for me:
> > > > > > >
> > > > > > > Linux version 3.14.0-yocto-standard (richard@ted) (gcc version
> > > > > > > 4.8.2
> > > > > > > (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014> > >
> > > > > > >
> > > > > > > > I'm guessing the path problem is more likely but anything is
> > > > > > > > possible.
> > > > > > > > This is starting to look like some kind of compiler or linker
> > > > > > > > issue.
> > > > > > > > If
> > > > > > > > it is that, it would help to have more data points about what
> > > > > > > > works
> > > > > > > > and
> > > > > > > > what doesn't. With that in mind could people who have good or
> > > > > > > > bad
> > > > > > > > builds
> > > > > > > > please share the paths they built the kernels in so we can see
> > > > > > > > if we
> > > > > > > > can
> > > > > > > > spot some kind of pattern.
> > > > > >
> > > > > > BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > > and
> > > > > > it works.
> > > > >
> > > > > I can confirm:
> > > > > build dir in /home/stefans/b1 works,
> > > > >
> > > > > but /home/stefans/yocto/poky/build doesn't.
> > > >
> > > > But this works
> > > > [stefans@firebird bu]$ pwd
> > > > /home/stefans/yocto/poky/bu
> > > > [stefans@firebird bu]$ echo `pwd`| wc -c
> > > > 28
> > > >
> > > > But 29 doesn't.
> > > > So, what now?
> > >
> > > Some other things I tried with a "long" TMPDIR path (note that it's the
> > > TMPDIR path that makes the difference - in my tests I've been using
> > > /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
> > >
> > > * kernel built with gcc 4.7.2 and binutils 2.23.2
> > > * u-boot built with gcc 4.7.2 and binutils 2.23.2
> > > * u-boot from http://downloads.angstrom-distribution.org/demo/beaglebone/
> > > * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
> > >
> > > I think we're now at the point where we'd benefit from someone with better
> > > knowledge debugging the issue.
> >
> > Ok, should we expand the search area? Since this is supposed to be vanilla
> > 3.14 kernel, can we try other platforms and see if they are similarly
> > affected? I'll try pinging our kernel guys for any ideas...
>
> As far as I know it has only been observed with beaglebone (both white and
> black, if it makes a difference). FWIW, qemuarm images from the autobuilder
> boot just fine, and apparently the same is true of edgerouter (different
> architecture but also uses u-boot).
But do those other platforms use uImage or zImage?
Anyway, just for testing, I switched to zImage and it seems to boot fine for
me regarldless of the path length...
I just sent 2 patches to test this out - unfortunately booting zImage isntead
of uImage requires fiddling with U-boot variables a bit, when using 2013.07.
So I also provided a quick update patch to get U-boot 2014.01 that has zImage
enabled by default.
Those patches are not yet for merging and they are directly against Poky -
could anyone having issues with booting BBB try them? Place new u-boot.img
into first boot FAT partition and new zImage kernel image to /boot dir of the
rootfs partition. Please let me know if it works for your long paths. Thanks.
--
Denys
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 16:26 ` Denys Dmytriyenko
2014-04-15 16:36 ` Paul Eggleton
@ 2014-04-15 17:25 ` Stanacar, StefanX
1 sibling, 0 replies; 49+ messages in thread
From: Stanacar, StefanX @ 2014-04-15 17:25 UTC (permalink / raw)
To: denis; +Cc: paul.eggleton, yocto
On Tue, 2014-04-15 at 12:26 -0400, Denys Dmytriyenko wrote:
> On Tue, Apr 15, 2014 at 03:49:42PM +0100, Paul Eggleton wrote:
> > On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
> > > On Tue, 2014-04-15 at 09:03 +0000, Stanacar, StefanX wrote:
> > > > On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> > > > > On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > > > > > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > > > > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > > > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> > > > > > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> > > > > > > > > > > Very interesting results! These are the results from the
> > build hosts I have:
> > > > > > > > > > > Fedora 13 (i686) - fails
> > > > > > > > > > > Fedora 17 (i686) - fails
> > > > > > > > > > > Ubuntu 12.04 (x86_64) - boots
> > > > > > > > > >
> > > > > > > > > > Interesting indeed. I have no idea what's so special about
> > > > > > > > > > Fedora host - this is the first time I hear about issues with
> > > > > > > > > > it. I may try experimenting with different VMs once I have
> > > > > > > > > > more time...
> > > > > > > > >
> > > > > > > > > I've been having a look at this. The biggest differences I can
> > > > > > > > > find
> > > > > > > > > between working and non working builds is the path length to the
> > > > > > > > > build
> > > > > > > > > directory for the kernel. This is from comparing vmlinux files
> > > > > > > > > from
> > > > > > > > > working and non working builds.
> > > > > > > > >
> > > > > > > > > Works:
> > > > > > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > > > > >
> > > > > > > > > Doesn't Work:
> > > > > > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gn
> > > > > > > > > ueabi
> > > > > > > > >
> > > > > > > > > I also have been wondering if the version strings may be making
> > > > > > > > > a
> > > > > > > > > difference.
> > > > > > > > >
> > > > > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build
> > > > > > > > > where I
> > > > > > > > > truncated the path length to a "working" build path length and
> > > > > > > > > patched
> > > > > > > > > in the same version strings:
> > > > > > > > >
> > > > > > > > > const char linux_banner[] =
> > > > > > > > >
> > > > > > > > > "Linux version 3.14.0-yocto-standard
> > > > > > > > > (paul@ubuntu-build01) (gcc
> > > > > > > > >
> > > > > > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST
> > > > > > > > > 2014\n";
> > > > > > > > >
> > > > > > > > > const char linux_proc_banner[] = "%s version %s
> > > > > > > > > (paul@ubuntu-build01)
> > > > > > > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > > > > > > >
> > > > > > > > > to init/version.c.
> > > > > > > > >
> > > > > > > > > I don't have hardware and would be interested to know if the
> > > > > > > > > kernel
> > > > > > > > > linked to above works or not. If it doesn't, it rules out these
> > > > > > > > > path and
> > > > > > > > > string lengths, if it does work, it points to a problem there.
> > > > > > > >
> > > > > > > > Richard,
> > > > > > >
> > > > > > > > Good catch! It boots:
> > > > > > > Thanks Denys, this helps narrow down the issue. I've shared
> > > > > > > http://dan.rpsys.net/uImage-rp3 which is the same as the last one
> > > > > > > but
> > > > > > > with my changes to version.c reverted. The one should tell us if its
> > > > > > > the
> > > > > > > paths or the strings.
> > > > > >
> > > > > > This one also boots for me:
> > > > > >
> > > > > > Linux version 3.14.0-yocto-standard (richard@ted) (gcc version 4.8.2
> > > > > > (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014> > >
> > > > > > > I'm guessing the path problem is more likely but anything is
> > > > > > > possible.
> > > > > > > This is starting to look like some kind of compiler or linker issue.
> > > > > > > If
> > > > > > > it is that, it would help to have more data points about what works
> > > > > > > and
> > > > > > > what doesn't. With that in mind could people who have good or bad
> > > > > > > builds
> > > > > > > please share the paths they built the kernels in so we can see if we
> > > > > > > can
> > > > > > > spot some kind of pattern.
> > > > >
> > > > > BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi and
> > > > > it works.
> > > >
> > > > I can confirm:
> > > > build dir in /home/stefans/b1 works,
> > > >
> > > > but /home/stefans/yocto/poky/build doesn't.
> > >
> > > But this works
> > > [stefans@firebird bu]$ pwd
> > > /home/stefans/yocto/poky/bu
> > > [stefans@firebird bu]$ echo `pwd`| wc -c
> > > 28
> > >
> > >
> > > But 29 doesn't.
> > > So, what now?
> >
> > Some other things I tried with a "long" TMPDIR path (note that it's the TMPDIR
> > path that makes the difference - in my tests I've been using
> > /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
> >
> > * kernel built with gcc 4.7.2 and binutils 2.23.2
> > * u-boot built with gcc 4.7.2 and binutils 2.23.2
> > * u-boot from http://downloads.angstrom-distribution.org/demo/beaglebone/
> > * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
> >
> > I think we're now at the point where we'd benefit from someone with better
> > knowledge debugging the issue.
>
> Ok, should we expand the search area? Since this is supposed to be vanilla
> 3.14 kernel, can we try other platforms and see if they are similarly
> affected? I'll try pinging our kernel guys for any ideas...
>
FWIW, I filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=6165
that contains all the info I had.
A link to two of my kernel is there, one working one not.
Cheers,
Stefan
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 17:16 ` Denys Dmytriyenko
@ 2014-04-15 17:41 ` Denys Dmytriyenko
2014-04-15 19:43 ` Denys Dmytriyenko
0 siblings, 1 reply; 49+ messages in thread
From: Denys Dmytriyenko @ 2014-04-15 17:41 UTC (permalink / raw)
To: Paul Eggleton; +Cc: yocto
On Tue, Apr 15, 2014 at 01:16:01PM -0400, Denys Dmytriyenko wrote:
> On Tue, Apr 15, 2014 at 05:36:10PM +0100, Paul Eggleton wrote:
> > On Tuesday 15 April 2014 12:26:39 Denys Dmytriyenko wrote:
> > > On Tue, Apr 15, 2014 at 03:49:42PM +0100, Paul Eggleton wrote:
> > > > On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
> > > > > On Tue, 2014-04-15 at 09:03 +0000, Stanacar, StefanX wrote:
> > > > > > On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> > > > > > > On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > > > > > > > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > > > > > > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > > > > > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie
> > wrote:
> > > > > > > > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > > > > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas
> > wrote:
> > > > > > > > > > > > > Very interesting results! These are the results from
> > > > > > > > > > > > > the
> > > >
> > > > build hosts I have:
> > > > > > > > > > > > > Fedora 13 (i686) - fails
> > > > > > > > > > > > > Fedora 17 (i686) - fails
> > > > > > > > > > > > > Ubuntu 12.04 (x86_64) - boots
> > > > > > > > > > > >
> > > > > > > > > > > > Interesting indeed. I have no idea what's so special about
> > > > > > > > > > > > Fedora host - this is the first time I hear about issues
> > > > > > > > > > > > with
> > > > > > > > > > > > it. I may try experimenting with different VMs once I have
> > > > > > > > > > > > more time...
> > > > > > > > > > >
> > > > > > > > > > > I've been having a look at this. The biggest differences I
> > > > > > > > > > > can
> > > > > > > > > > > find
> > > > > > > > > > > between working and non working builds is the path length to
> > > > > > > > > > > the
> > > > > > > > > > > build
> > > > > > > > > > > directory for the kernel. This is from comparing vmlinux
> > > > > > > > > > > files
> > > > > > > > > > > from
> > > > > > > > > > > working and non working builds.
> > > > > > > > > > >
> > > > > > > > > > > Works:
> > > > > > > > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > > > > > > >
> > > > > > > > > > > Doesn't Work:
> > > > > > > > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linu
> > > > > > > > > > > x-gn
> > > > > > > > > > > ueabi
> > > > > > > > > > >
> > > > > > > > > > > I also have been wondering if the version strings may be
> > > > > > > > > > > making
> > > > > > > > > > > a
> > > > > > > > > > > difference.
> > > > > > > > > > >
> > > > > > > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken
> > > > > > > > > > > build
> > > > > > > > > > > where I
> > > > > > > > > > > truncated the path length to a "working" build path length
> > > > > > > > > > > and
> > > > > > > > > > > patched
> > > > > > > > > > > in the same version strings:
> > > > > > > > > > >
> > > > > > > > > > > const char linux_banner[] =
> > > > > > > > > > >
> > > > > > > > > > > "Linux version 3.14.0-yocto-standard
> > > > > > > > > > > (paul@ubuntu-build01) (gcc
> > > > > > > > > > >
> > > > > > > > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST
> > > > > > > > > > > 2014\n";
> > > > > > > > > > >
> > > > > > > > > > > const char linux_proc_banner[] = "%s version %s
> > > > > > > > > > > (paul@ubuntu-build01)
> > > > > > > > > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > > > > > > > > >
> > > > > > > > > > > to init/version.c.
> > > > > > > > > > >
> > > > > > > > > > > I don't have hardware and would be interested to know if the
> > > > > > > > > > > kernel
> > > > > > > > > > > linked to above works or not. If it doesn't, it rules out
> > > > > > > > > > > these
> > > > > > > > > > > path and
> > > > > > > > > > > string lengths, if it does work, it points to a problem
> > > > > > > > > > > there.
> > > > > > > > > >
> > > > > > > > > > Richard,
> > > > > > > > >
> > > > > > > > > > Good catch! It boots:
> > > > > > > > > Thanks Denys, this helps narrow down the issue. I've shared
> > > > > > > > > http://dan.rpsys.net/uImage-rp3 which is the same as the last
> > > > > > > > > one
> > > > > > > > > but
> > > > > > > > > with my changes to version.c reverted. The one should tell us if
> > > > > > > > > its
> > > > > > > > > the
> > > > > > > > > paths or the strings.
> > > > > > > >
> > > > > > > > This one also boots for me:
> > > > > > > >
> > > > > > > > Linux version 3.14.0-yocto-standard (richard@ted) (gcc version
> > > > > > > > 4.8.2
> > > > > > > > (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014> > >
> > > > > > > >
> > > > > > > > > I'm guessing the path problem is more likely but anything is
> > > > > > > > > possible.
> > > > > > > > > This is starting to look like some kind of compiler or linker
> > > > > > > > > issue.
> > > > > > > > > If
> > > > > > > > > it is that, it would help to have more data points about what
> > > > > > > > > works
> > > > > > > > > and
> > > > > > > > > what doesn't. With that in mind could people who have good or
> > > > > > > > > bad
> > > > > > > > > builds
> > > > > > > > > please share the paths they built the kernels in so we can see
> > > > > > > > > if we
> > > > > > > > > can
> > > > > > > > > spot some kind of pattern.
> > > > > > >
> > > > > > > BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > > > and
> > > > > > > it works.
> > > > > >
> > > > > > I can confirm:
> > > > > > build dir in /home/stefans/b1 works,
> > > > > >
> > > > > > but /home/stefans/yocto/poky/build doesn't.
> > > > >
> > > > > But this works
> > > > > [stefans@firebird bu]$ pwd
> > > > > /home/stefans/yocto/poky/bu
> > > > > [stefans@firebird bu]$ echo `pwd`| wc -c
> > > > > 28
> > > > >
> > > > > But 29 doesn't.
> > > > > So, what now?
> > > >
> > > > Some other things I tried with a "long" TMPDIR path (note that it's the
> > > > TMPDIR path that makes the difference - in my tests I've been using
> > > > /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
> > > >
> > > > * kernel built with gcc 4.7.2 and binutils 2.23.2
> > > > * u-boot built with gcc 4.7.2 and binutils 2.23.2
> > > > * u-boot from http://downloads.angstrom-distribution.org/demo/beaglebone/
> > > > * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
> > > >
> > > > I think we're now at the point where we'd benefit from someone with better
> > > > knowledge debugging the issue.
> > >
> > > Ok, should we expand the search area? Since this is supposed to be vanilla
> > > 3.14 kernel, can we try other platforms and see if they are similarly
> > > affected? I'll try pinging our kernel guys for any ideas...
> >
> > As far as I know it has only been observed with beaglebone (both white and
> > black, if it makes a difference). FWIW, qemuarm images from the autobuilder
> > boot just fine, and apparently the same is true of edgerouter (different
> > architecture but also uses u-boot).
>
> But do those other platforms use uImage or zImage?
>
> Anyway, just for testing, I switched to zImage and it seems to boot fine for
> me regarldless of the path length...
>
> I just sent 2 patches to test this out - unfortunately booting zImage isntead
> of uImage requires fiddling with U-boot variables a bit, when using 2013.07.
> So I also provided a quick update patch to get U-boot 2014.01 that has zImage
> enabled by default.
>
> Those patches are not yet for merging and they are directly against Poky -
> could anyone having issues with booting BBB try them? Place new u-boot.img
> into first boot FAT partition and new zImage kernel image to /boot dir of the
> rootfs partition. Please let me know if it works for your long paths. Thanks.
Ah, never mind, it still doesn't work with zImage - I got fooled by sstate :(
--
Denys
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 17:41 ` Denys Dmytriyenko
@ 2014-04-15 19:43 ` Denys Dmytriyenko
2014-04-15 23:07 ` Gary Thomas
` (2 more replies)
0 siblings, 3 replies; 49+ messages in thread
From: Denys Dmytriyenko @ 2014-04-15 19:43 UTC (permalink / raw)
To: Paul Eggleton; +Cc: yocto
On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:
> > > > > Some other things I tried with a "long" TMPDIR path (note that it's the
> > > > > TMPDIR path that makes the difference - in my tests I've been using
> > > > > /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
> > > > >
> > > > > * kernel built with gcc 4.7.2 and binutils 2.23.2
> > > > > * u-boot built with gcc 4.7.2 and binutils 2.23.2
> > > > > * u-boot from http://downloads.angstrom-distribution.org/demo/beaglebone/
> > > > > * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
> > > > >
> > > > > I think we're now at the point where we'd benefit from someone with better
> > > > > knowledge debugging the issue.
> > > >
> > > > Ok, should we expand the search area? Since this is supposed to be vanilla
> > > > 3.14 kernel, can we try other platforms and see if they are similarly
> > > > affected? I'll try pinging our kernel guys for any ideas...
> > >
> > > As far as I know it has only been observed with beaglebone (both white and
> > > black, if it makes a difference). FWIW, qemuarm images from the autobuilder
> > > boot just fine, and apparently the same is true of edgerouter (different
> > > architecture but also uses u-boot).
> >
> > But do those other platforms use uImage or zImage?
I don't yet know what is going on, but building in the same directory with
sources (B = S) makes it work regarless of the path length:
/OE/RAM/poky-111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111/22222222222222222222222222222222222222222222222222222222222222222222/3333333333333333333333333333333333333333333333333333/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
So, I just commented out setting kernel-specific B in linux-yocto.inc and any
kernel now boots with long path:
#B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
I'm copying Richard and Bruce directly to see if they may have a quick insight
and/or accept it as a workaround for the release. I'll keep digging further,
but if anyone cares to verify the above workaround works for them, I would
appreciate. Thanks!
--
Denys
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 19:43 ` Denys Dmytriyenko
@ 2014-04-15 23:07 ` Gary Thomas
2014-04-17 19:10 ` Denys Dmytriyenko
2014-04-15 23:29 ` Bruce Ashfield
2014-04-15 23:36 ` Richard Purdie
2 siblings, 1 reply; 49+ messages in thread
From: Gary Thomas @ 2014-04-15 23:07 UTC (permalink / raw)
To: yocto
On 2014-04-15 13:43, Denys Dmytriyenko wrote:
> On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:
>>>>>> Some other things I tried with a "long" TMPDIR path (note that it's the
>>>>>> TMPDIR path that makes the difference - in my tests I've been using
>>>>>> /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
>>>>>>
>>>>>> * kernel built with gcc 4.7.2 and binutils 2.23.2
>>>>>> * u-boot built with gcc 4.7.2 and binutils 2.23.2
>>>>>> * u-boot from http://downloads.angstrom-distribution.org/demo/beaglebone/
>>>>>> * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
>>>>>>
>>>>>> I think we're now at the point where we'd benefit from someone with better
>>>>>> knowledge debugging the issue.
>>>>>
>>>>> Ok, should we expand the search area? Since this is supposed to be vanilla
>>>>> 3.14 kernel, can we try other platforms and see if they are similarly
>>>>> affected? I'll try pinging our kernel guys for any ideas...
>>>>
>>>> As far as I know it has only been observed with beaglebone (both white and
>>>> black, if it makes a difference). FWIW, qemuarm images from the autobuilder
>>>> boot just fine, and apparently the same is true of edgerouter (different
>>>> architecture but also uses u-boot).
>>>
>>> But do those other platforms use uImage or zImage?
>
> I don't yet know what is going on, but building in the same directory with
> sources (B = S) makes it work regarless of the path length:
>
> /OE/RAM/poky-111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111/22222222222222222222222222222222222222222222222222222222222222222222/3333333333333333333333333333333333333333333333333333/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
>
> So, I just commented out setting kernel-specific B in linux-yocto.inc and any
> kernel now boots with long path:
>
> #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
>
> I'm copying Richard and Bruce directly to see if they may have a quick insight
> and/or accept it as a workaround for the release. I'll keep digging further,
> but if anyone cares to verify the above workaround works for them, I would
> appreciate. Thanks!
>
Verified - I rebuilt the kernel in a working tree with a longer
path (one in fact that had failed before) and it boots fine.
Wonder what ${B} != ${S} is doing wacky...?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 19:43 ` Denys Dmytriyenko
2014-04-15 23:07 ` Gary Thomas
@ 2014-04-15 23:29 ` Bruce Ashfield
2014-04-15 23:36 ` Richard Purdie
2 siblings, 0 replies; 49+ messages in thread
From: Bruce Ashfield @ 2014-04-15 23:29 UTC (permalink / raw)
To: Denys Dmytriyenko, Paul Eggleton; +Cc: yocto
On 14-04-15 03:43 PM, Denys Dmytriyenko wrote:
> On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:
>>>>>> Some other things I tried with a "long" TMPDIR path (note that it's the
>>>>>> TMPDIR path that makes the difference - in my tests I've been using
>>>>>> /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
>>>>>>
>>>>>> * kernel built with gcc 4.7.2 and binutils 2.23.2
>>>>>> * u-boot built with gcc 4.7.2 and binutils 2.23.2
>>>>>> * u-boot from http://downloads.angstrom-distribution.org/demo/beaglebone/
>>>>>> * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
>>>>>>
>>>>>> I think we're now at the point where we'd benefit from someone with better
>>>>>> knowledge debugging the issue.
>>>>>
>>>>> Ok, should we expand the search area? Since this is supposed to be vanilla
>>>>> 3.14 kernel, can we try other platforms and see if they are similarly
>>>>> affected? I'll try pinging our kernel guys for any ideas...
>>>>
>>>> As far as I know it has only been observed with beaglebone (both white and
>>>> black, if it makes a difference). FWIW, qemuarm images from the autobuilder
>>>> boot just fine, and apparently the same is true of edgerouter (different
>>>> architecture but also uses u-boot).
>>>
>>> But do those other platforms use uImage or zImage?
>
> I don't yet know what is going on, but building in the same directory with
> sources (B = S) makes it work regarless of the path length:
>
> /OE/RAM/poky-111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111/22222222222222222222222222222222222222222222222222222222222222222222/3333333333333333333333333333333333333333333333333333/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
>
> So, I just commented out setting kernel-specific B in linux-yocto.inc and any
> kernel now boots with long path:
>
> #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
>
> I'm copying Richard and Bruce directly to see if they may have a quick insight
> and/or accept it as a workaround for the release. I'll keep digging further,
I've never seen this before, and when I'm back in the office Wed/Thursday
I can have a closer look.
As for the BBB using this in the release, I really don't want to have
one board that breaks the build and source separation, since it has
always been in place to keep things clean (and I know of a few random
scripts, etc, that expect it) .. but more importantly, I want to root
cause this, since it is a lurking problem.
Bruce
> but if anyone cares to verify the above workaround works for them, I would
> appreciate. Thanks!
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 19:43 ` Denys Dmytriyenko
2014-04-15 23:07 ` Gary Thomas
2014-04-15 23:29 ` Bruce Ashfield
@ 2014-04-15 23:36 ` Richard Purdie
2014-04-16 1:12 ` Denys Dmytriyenko
2 siblings, 1 reply; 49+ messages in thread
From: Richard Purdie @ 2014-04-15 23:36 UTC (permalink / raw)
To: Denys Dmytriyenko; +Cc: Paul Eggleton, yocto
On Tue, 2014-04-15 at 15:43 -0400, Denys Dmytriyenko wrote:
> I don't yet know what is going on, but building in the same directory with
> sources (B = S) makes it work regarless of the path length:
>
> /OE/RAM/poky-111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111/22222222222222222222222222222222222222222222222222222222222222222222/3333333333333333333333333333333333333333333333333333/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
>
> So, I just commented out setting kernel-specific B in linux-yocto.inc and any
> kernel now boots with long path:
>
> #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
>
> I'm copying Richard and Bruce directly to see if they may have a quick insight
> and/or accept it as a workaround for the release. I'll keep digging further,
> but if anyone cares to verify the above workaround works for them, I would
> appreciate. Thanks!
I'm travelling and don't have hardware so I'm limited in what I can look
at right now. I suspect this workaround "works" because it makes the
"beaglebone-standard-build" extra characters on the path. I have a
feeling your -1111111 test above may have reused sstate or something
like that and given misleading results. I'd be interested in the vmlinux
file from the build above to see if the poky-111111 pathnames are in
there (they get stripped out when you create the zImage).
Cheers,
Richard
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 23:36 ` Richard Purdie
@ 2014-04-16 1:12 ` Denys Dmytriyenko
2014-04-16 1:20 ` Denys Dmytriyenko
0 siblings, 1 reply; 49+ messages in thread
From: Denys Dmytriyenko @ 2014-04-16 1:12 UTC (permalink / raw)
To: Richard Purdie; +Cc: Paul Eggleton, yocto
On Wed, Apr 16, 2014 at 12:36:58AM +0100, Richard Purdie wrote:
> On Tue, 2014-04-15 at 15:43 -0400, Denys Dmytriyenko wrote:
> > I don't yet know what is going on, but building in the same directory with
> > sources (B = S) makes it work regarless of the path length:
> >
> > /OE/RAM/poky-111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111/22222222222222222222222222222222222222222222222222222222222222222222/3333333333333333333333333333333333333333333333333333/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
> >
> > So, I just commented out setting kernel-specific B in linux-yocto.inc and any
> > kernel now boots with long path:
> >
> > #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
> >
> > I'm copying Richard and Bruce directly to see if they may have a quick insight
> > and/or accept it as a workaround for the release. I'll keep digging further,
> > but if anyone cares to verify the above workaround works for them, I would
> > appreciate. Thanks!
>
> I'm travelling and don't have hardware so I'm limited in what I can look
> at right now. I suspect this workaround "works" because it makes the
> "beaglebone-standard-build" extra characters on the path. I have a
> feeling your -1111111 test above may have reused sstate or something
> like that and given misleading results. I'd be interested in the vmlinux
> file from the build above to see if the poky-111111 pathnames are in
> there (they get stripped out when you create the zImage).
Nope, I was fooled by sstate once, so this time I tested with cleansstate and
compared timestamps of the kernel when it boots - it is definitely the new
one. And to make sure 'beaglebone-standard-build' extra suffix doesn't affect
it, I increased the path length even further - that extra level with 333 is
there to over-compensate, as it was failing before even with just 111 and 222
levels only... Looks like Gary was also able to verify it.
But, you are right about vmlinux - it doesn't have those paths in there any
more! I've seen them there when building with B != S, but they are gone when
building with B = S. Wondering why. You can check it for yourself:
http://arago-project.org/files/short-term/misc/vmlinux-3.14.0-yocto-standard
--
Denys
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-16 1:12 ` Denys Dmytriyenko
@ 2014-04-16 1:20 ` Denys Dmytriyenko
2014-04-16 3:31 ` Khem Raj
2014-04-16 10:20 ` Stanacar, StefanX
0 siblings, 2 replies; 49+ messages in thread
From: Denys Dmytriyenko @ 2014-04-16 1:20 UTC (permalink / raw)
To: Richard Purdie; +Cc: Paul Eggleton, yocto
On Tue, Apr 15, 2014 at 09:12:30PM -0400, Denys Dmytriyenko wrote:
> On Wed, Apr 16, 2014 at 12:36:58AM +0100, Richard Purdie wrote:
> > On Tue, 2014-04-15 at 15:43 -0400, Denys Dmytriyenko wrote:
> > > I don't yet know what is going on, but building in the same directory with
> > > sources (B = S) makes it work regarless of the path length:
> > >
> > > /OE/RAM/poky-111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111/22222222222222222222222222222222222222222222222222222222222222222222/3333333333333333333333333333333333333333333333333333/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
> > >
> > > So, I just commented out setting kernel-specific B in linux-yocto.inc and any
> > > kernel now boots with long path:
> > >
> > > #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
> > >
> > > I'm copying Richard and Bruce directly to see if they may have a quick insight
> > > and/or accept it as a workaround for the release. I'll keep digging further,
> > > but if anyone cares to verify the above workaround works for them, I would
> > > appreciate. Thanks!
> >
> > I'm travelling and don't have hardware so I'm limited in what I can look
> > at right now. I suspect this workaround "works" because it makes the
> > "beaglebone-standard-build" extra characters on the path. I have a
> > feeling your -1111111 test above may have reused sstate or something
> > like that and given misleading results. I'd be interested in the vmlinux
> > file from the build above to see if the poky-111111 pathnames are in
> > there (they get stripped out when you create the zImage).
>
> Nope, I was fooled by sstate once, so this time I tested with cleansstate and
> compared timestamps of the kernel when it boots - it is definitely the new
> one. And to make sure 'beaglebone-standard-build' extra suffix doesn't affect
> it, I increased the path length even further - that extra level with 333 is
> there to over-compensate, as it was failing before even with just 111 and 222
> levels only... Looks like Gary was also able to verify it.
>
> But, you are right about vmlinux - it doesn't have those paths in there any
> more! I've seen them there when building with B != S, but they are gone when
> building with B = S. Wondering why. You can check it for yourself:
>
> http://arago-project.org/files/short-term/misc/vmlinux-3.14.0-yocto-standard
And, as a follow up, all those long paths in vmlinux when built with B != S
point to sources. Here are few examples:
B != S strings:
/OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/init/main.c
earlycon
4Malformed early option '%s'
3Starting init: %s exists but couldn't execute it (error %d)
...
6Trying to unpack rootfs image as initramfs...
/OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/init/initramfs.c
6rootfs image is not initramfs (%s); looks like an initrd
TRAILER!!!
...
%lu.%02lu BogoMIPS (lpj=%lu)
/OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/arch/arm/vfp/vfpmodule.c
6VFP support v0.3:
B = S same strings:
init/main.c
earlycon
4Malformed early option '%s'
3Starting init: %s exists but couldn't execute it (error %d)
...
6Trying to unpack rootfs image as initramfs...
init/initramfs.c
6rootfs image is not initramfs (%s); looks like an initrd
TRAILER!!!
...
%lu.%02lu BogoMIPS (lpj=%lu)
arch/arm/vfp/vfpmodule.c
6VFP support v0.3:
So, that explains why B = S works regardless of the location, as it doesn't
embed full path to source files...
--
Denys
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-16 1:20 ` Denys Dmytriyenko
@ 2014-04-16 3:31 ` Khem Raj
2014-04-16 15:57 ` William Mills
2014-04-16 10:20 ` Stanacar, StefanX
1 sibling, 1 reply; 49+ messages in thread
From: Khem Raj @ 2014-04-16 3:31 UTC (permalink / raw)
To: Denys Dmytriyenko; +Cc: Paul Eggleton, yocto
On Tue, Apr 15, 2014 at 6:20 PM, Denys Dmytriyenko <denis@denix.org> wrote:
> On Tue, Apr 15, 2014 at 09:12:30PM -0400, Denys Dmytriyenko wrote:
>> On Wed, Apr 16, 2014 at 12:36:58AM +0100, Richard Purdie wrote:
>> > On Tue, 2014-04-15 at 15:43 -0400, Denys Dmytriyenko wrote:
>> > > I don't yet know what is going on, but building in the same directory with
>> > > sources (B = S) makes it work regarless of the path length:
>> > >
>> > > /OE/RAM/poky-111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111/22222222222222222222222222222222222222222222222222222222222222222222/3333333333333333333333333333333333333333333333333333/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
>> > >
>> > > So, I just commented out setting kernel-specific B in linux-yocto.inc and any
>> > > kernel now boots with long path:
>> > >
>> > > #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
>> > >
>> > > I'm copying Richard and Bruce directly to see if they may have a quick insight
>> > > and/or accept it as a workaround for the release. I'll keep digging further,
>> > > but if anyone cares to verify the above workaround works for them, I would
>> > > appreciate. Thanks!
>> >
>> > I'm travelling and don't have hardware so I'm limited in what I can look
>> > at right now. I suspect this workaround "works" because it makes the
>> > "beaglebone-standard-build" extra characters on the path. I have a
>> > feeling your -1111111 test above may have reused sstate or something
>> > like that and given misleading results. I'd be interested in the vmlinux
>> > file from the build above to see if the poky-111111 pathnames are in
>> > there (they get stripped out when you create the zImage).
>>
>> Nope, I was fooled by sstate once, so this time I tested with cleansstate and
>> compared timestamps of the kernel when it boots - it is definitely the new
>> one. And to make sure 'beaglebone-standard-build' extra suffix doesn't affect
>> it, I increased the path length even further - that extra level with 333 is
>> there to over-compensate, as it was failing before even with just 111 and 222
>> levels only... Looks like Gary was also able to verify it.
>>
>> But, you are right about vmlinux - it doesn't have those paths in there any
>> more! I've seen them there when building with B != S, but they are gone when
>> building with B = S. Wondering why. You can check it for yourself:
>>
>> http://arago-project.org/files/short-term/misc/vmlinux-3.14.0-yocto-standard
>
> And, as a follow up, all those long paths in vmlinux when built with B != S
> point to sources. Here are few examples:
>
> B != S strings:
>
> /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/init/main.c
> earlycon
> 4Malformed early option '%s'
> 3Starting init: %s exists but couldn't execute it (error %d)
> ...
> 6Trying to unpack rootfs image as initramfs...
> /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/init/initramfs.c
> 6rootfs image is not initramfs (%s); looks like an initrd
> TRAILER!!!
> ...
> %lu.%02lu BogoMIPS (lpj=%lu)
> /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/arch/arm/vfp/vfpmodule.c
> 6VFP support v0.3:
>
>
> B = S same strings:
>
> init/main.c
> earlycon
> 4Malformed early option '%s'
> 3Starting init: %s exists but couldn't execute it (error %d)
> ...
> 6Trying to unpack rootfs image as initramfs...
> init/initramfs.c
> 6rootfs image is not initramfs (%s); looks like an initrd
> TRAILER!!!
> ...
> %lu.%02lu BogoMIPS (lpj=%lu)
> arch/arm/vfp/vfpmodule.c
> 6VFP support v0.3:
>
>
> So, that explains why B = S works regardless of the location, as it doesn't
> embed full path to source files...
>
seemingly there could be rodata segment overflow issue. Can you do the
kernel build with say linker from dora build
and see if it still fails.
> --
> Denys
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-16 1:20 ` Denys Dmytriyenko
2014-04-16 3:31 ` Khem Raj
@ 2014-04-16 10:20 ` Stanacar, StefanX
1 sibling, 0 replies; 49+ messages in thread
From: Stanacar, StefanX @ 2014-04-16 10:20 UTC (permalink / raw)
To: denis; +Cc: paul.eggleton, yocto
On Tue, 2014-04-15 at 21:20 -0400, Denys Dmytriyenko wrote:
> On Tue, Apr 15, 2014 at 09:12:30PM -0400, Denys Dmytriyenko wrote:
> > On Wed, Apr 16, 2014 at 12:36:58AM +0100, Richard Purdie wrote:
> > > On Tue, 2014-04-15 at 15:43 -0400, Denys Dmytriyenko wrote:
> > > > I don't yet know what is going on, but building in the same directory with
> > > > sources (B = S) makes it work regarless of the path length:
> > > >
> > > > /OE/RAM/poky-111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111/22222222222222222222222222222222222222222222222222222222222222222222/3333333333333333333333333333333333333333333333333333/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
> > > >
> > > > So, I just commented out setting kernel-specific B in linux-yocto.inc and any
> > > > kernel now boots with long path:
> > > >
> > > > #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
> > > >
> > > > I'm copying Richard and Bruce directly to see if they may have a quick insight
> > > > and/or accept it as a workaround for the release. I'll keep digging further,
> > > > but if anyone cares to verify the above workaround works for them, I would
> > > > appreciate. Thanks!
> > >
> > > I'm travelling and don't have hardware so I'm limited in what I can look
> > > at right now. I suspect this workaround "works" because it makes the
> > > "beaglebone-standard-build" extra characters on the path. I have a
> > > feeling your -1111111 test above may have reused sstate or something
> > > like that and given misleading results. I'd be interested in the vmlinux
> > > file from the build above to see if the poky-111111 pathnames are in
> > > there (they get stripped out when you create the zImage).
> >
> > Nope, I was fooled by sstate once, so this time I tested with cleansstate and
> > compared timestamps of the kernel when it boots - it is definitely the new
> > one. And to make sure 'beaglebone-standard-build' extra suffix doesn't affect
> > it, I increased the path length even further - that extra level with 333 is
> > there to over-compensate, as it was failing before even with just 111 and 222
> > levels only... Looks like Gary was also able to verify it.
> >
> > But, you are right about vmlinux - it doesn't have those paths in there any
> > more! I've seen them there when building with B != S, but they are gone when
> > building with B = S. Wondering why. You can check it for yourself:
> >
> > http://arago-project.org/files/short-term/misc/vmlinux-3.14.0-yocto-standard
>
> And, as a follow up, all those long paths in vmlinux when built with B != S
> point to sources. Here are few examples:
>
> B != S strings:
>
> /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/init/main.c
> earlycon
> 4Malformed early option '%s'
> 3Starting init: %s exists but couldn't execute it (error %d)
> ...
> 6Trying to unpack rootfs image as initramfs...
> /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/init/initramfs.c
> 6rootfs image is not initramfs (%s); looks like an initrd
> TRAILER!!!
> ...
> %lu.%02lu BogoMIPS (lpj=%lu)
> /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/arch/arm/vfp/vfpmodule.c
> 6VFP support v0.3:
>
>
> B = S same strings:
>
> init/main.c
> earlycon
> 4Malformed early option '%s'
> 3Starting init: %s exists but couldn't execute it (error %d)
> ...
> 6Trying to unpack rootfs image as initramfs...
> init/initramfs.c
> 6rootfs image is not initramfs (%s); looks like an initrd
> TRAILER!!!
> ...
> %lu.%02lu BogoMIPS (lpj=%lu)
> arch/arm/vfp/vfpmodule.c
> 6VFP support v0.3:
>
>
> So, that explains why B = S works regardless of the location, as it doesn't
> embed full path to source files...
>
But qemux86-64 or genericx86-64 or qemuarm kernel has the same strings,
and it boots just fine:
$ strings
yocto-autobuilder/yocto-slave/nightly-x86-64/build/build/tmp/work/qemux86_64-poky-linux/linux-yocto/3.14+gitAUTOINC+fc8c30398d_0143c6ebb4-r0/linux-qemux86_64-standard-build/vmlinux | grep -A 2 -B 2 -E "init/main.c"
4Malformed early option '%s'
3Starting init: %s exists but couldn't execute it (error %d)
/home/stefans/yocto-autobuilder/yocto-slave/nightly-x86-64/build/build/tmp/work/qemux86_64-poky-linux/linux-yocto/3.14+gitAUTOINC+fc8c30398d_0143c6ebb4-r0/linux/init/main.c
4Parameter %s is obsolete, ignored
Interrupts were enabled *very* early, fixing it
qemuarm:
$ strings
yocto-autobuilder/yocto-slave/nightly-arm/build/build/tmp/work/qemuarm-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_c966987f88-r0/linux-qemuarm-standard-build/vmlinux | grep -A 2 -B 2 -E "init/main.c"
tab_
__ks
/home/stefans/yocto-autobuilder/yocto-slave/nightly-arm/build/build/tmp/work/qemuarm-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_c966987f88-r0/linux/init/main.c
earlycon
4Malformed early option '%s'
Cheers,
Stefan
> --
> Denys
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-16 3:31 ` Khem Raj
@ 2014-04-16 15:57 ` William Mills
2014-04-16 19:04 ` Stefan Stanacar
0 siblings, 1 reply; 49+ messages in thread
From: William Mills @ 2014-04-16 15:57 UTC (permalink / raw)
To: Khem Raj; +Cc: Paul Eggleton, yocto
On 04/15/2014 11:31 PM, Khem Raj wrote:
> On Tue, Apr 15, 2014 at 6:20 PM, Denys Dmytriyenko <denis@denix.org> wrote:
>> On Tue, Apr 15, 2014 at 09:12:30PM -0400, Denys Dmytriyenko wrote:
>>> On Wed, Apr 16, 2014 at 12:36:58AM +0100, Richard Purdie wrote:
>>>> On Tue, 2014-04-15 at 15:43 -0400, Denys Dmytriyenko wrote:
>>>>> I don't yet know what is going on, but building in the same directory with
>>>>> sources (B = S) makes it work regarless of the path length:
>>>>>
>>>>> /OE/RAM/poky-111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111/22222222222222222222222222222222222222222222222222222222222222222222/3333333333333333333333333333333333333333333333333333/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
>>>>>
>>>>> So, I just commented out setting kernel-specific B in linux-yocto.inc and any
>>>>> kernel now boots with long path:
>>>>>
>>>>> #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
>>>>>
>>>>> I'm copying Richard and Bruce directly to see if they may have a quick insight
>>>>> and/or accept it as a workaround for the release. I'll keep digging further,
>>>>> but if anyone cares to verify the above workaround works for them, I would
>>>>> appreciate. Thanks!
>>>>
>>>> I'm travelling and don't have hardware so I'm limited in what I can look
>>>> at right now. I suspect this workaround "works" because it makes the
>>>> "beaglebone-standard-build" extra characters on the path. I have a
>>>> feeling your -1111111 test above may have reused sstate or something
>>>> like that and given misleading results. I'd be interested in the vmlinux
>>>> file from the build above to see if the poky-111111 pathnames are in
>>>> there (they get stripped out when you create the zImage).
>>>
>>> Nope, I was fooled by sstate once, so this time I tested with cleansstate and
>>> compared timestamps of the kernel when it boots - it is definitely the new
>>> one. And to make sure 'beaglebone-standard-build' extra suffix doesn't affect
>>> it, I increased the path length even further - that extra level with 333 is
>>> there to over-compensate, as it was failing before even with just 111 and 222
>>> levels only... Looks like Gary was also able to verify it.
>>>
>>> But, you are right about vmlinux - it doesn't have those paths in there any
>>> more! I've seen them there when building with B != S, but they are gone when
>>> building with B = S. Wondering why. You can check it for yourself:
>>>
>>> http://arago-project.org/files/short-term/misc/vmlinux-3.14.0-yocto-standard
>>
>> And, as a follow up, all those long paths in vmlinux when built with B != S
>> point to sources. Here are few examples:
>>
>> B != S strings:
>>
>> /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/init/main.c
>> earlycon
>> 4Malformed early option '%s'
>> 3Starting init: %s exists but couldn't execute it (error %d)
>> ...
>> 6Trying to unpack rootfs image as initramfs...
>> /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/init/initramfs.c
>> 6rootfs image is not initramfs (%s); looks like an initrd
>> TRAILER!!!
>> ...
>> %lu.%02lu BogoMIPS (lpj=%lu)
>> /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/arch/arm/vfp/vfpmodule.c
>> 6VFP support v0.3:
>>
>>
>> B = S same strings:
>>
>> init/main.c
>> earlycon
>> 4Malformed early option '%s'
>> 3Starting init: %s exists but couldn't execute it (error %d)
>> ...
>> 6Trying to unpack rootfs image as initramfs...
>> init/initramfs.c
>> 6rootfs image is not initramfs (%s); looks like an initrd
>> TRAILER!!!
>> ...
>> %lu.%02lu BogoMIPS (lpj=%lu)
>> arch/arm/vfp/vfpmodule.c
>> 6VFP support v0.3:
>>
>>
>> So, that explains why B = S works regardless of the location, as it doesn't
>> embed full path to source files...
>>
>
> seemingly there could be rodata segment overflow issue. Can you do the
> kernel build with say linker from dora build
> and see if it still fails.
>
It would be interesting to see if the rodata segment (or segment it
contributes to) between working and non-working versions were crossing
some magic power of 2 value.
Are there two images published from the same build machines with just
the path difference? I would like to see one that was just under the
wire and one just a bit too long. Denys, you have that?
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-16 15:57 ` William Mills
@ 2014-04-16 19:04 ` Stefan Stanacar
2014-04-16 19:30 ` William Mills
0 siblings, 1 reply; 49+ messages in thread
From: Stefan Stanacar @ 2014-04-16 19:04 UTC (permalink / raw)
To: William Mills; +Cc: Paul Eggleton, yocto
[-- Attachment #1: Type: text/plain, Size: 5287 bytes --]
https://bugzilla.yoctoproject.org/show_bug.cgi?id=6165
Link to the two kernels at the end of the first comment.
On Apr 16, 2014 6:57 PM, "William Mills" <wmills@ti.com> wrote:
>
> On 04/15/2014 11:31 PM, Khem Raj wrote:
>
>> On Tue, Apr 15, 2014 at 6:20 PM, Denys Dmytriyenko <denis@denix.org>
>> wrote:
>>
>>> On Tue, Apr 15, 2014 at 09:12:30PM -0400, Denys Dmytriyenko wrote:
>>>
>>>> On Wed, Apr 16, 2014 at 12:36:58AM +0100, Richard Purdie wrote:
>>>>
>>>>> On Tue, 2014-04-15 at 15:43 -0400, Denys Dmytriyenko wrote:
>>>>>
>>>>>> I don't yet know what is going on, but building in the same directory
>>>>>> with
>>>>>> sources (B = S) makes it work regarless of the path length:
>>>>>>
>>>>>> /OE/RAM/poky-111111111111111111111111111111
>>>>>> 111111111111111111111111111111111111111111111111111111111111
>>>>>> 111111111111111/222222222222222222222222222222
>>>>>> 22222222222222222222222222222222222222/333333333333333333333333333333
>>>>>> 3333333333333333333333/tmp/work/beaglebone-poky-linux-
>>>>>> gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
>>>>>>
>>>>>> So, I just commented out setting kernel-specific B in linux-yocto.inc
>>>>>> and any
>>>>>> kernel now boots with long path:
>>>>>>
>>>>>> #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
>>>>>>
>>>>>> I'm copying Richard and Bruce directly to see if they may have a
>>>>>> quick insight
>>>>>> and/or accept it as a workaround for the release. I'll keep digging
>>>>>> further,
>>>>>> but if anyone cares to verify the above workaround works for them, I
>>>>>> would
>>>>>> appreciate. Thanks!
>>>>>>
>>>>>
>>>>> I'm travelling and don't have hardware so I'm limited in what I can
>>>>> look
>>>>> at right now. I suspect this workaround "works" because it makes the
>>>>> "beaglebone-standard-build" extra characters on the path. I have a
>>>>> feeling your -1111111 test above may have reused sstate or something
>>>>> like that and given misleading results. I'd be interested in the
>>>>> vmlinux
>>>>> file from the build above to see if the poky-111111 pathnames are in
>>>>> there (they get stripped out when you create the zImage).
>>>>>
>>>>
>>>> Nope, I was fooled by sstate once, so this time I tested with
>>>> cleansstate and
>>>> compared timestamps of the kernel when it boots - it is definitely the
>>>> new
>>>> one. And to make sure 'beaglebone-standard-build' extra suffix doesn't
>>>> affect
>>>> it, I increased the path length even further - that extra level with
>>>> 333 is
>>>> there to over-compensate, as it was failing before even with just 111
>>>> and 222
>>>> levels only... Looks like Gary was also able to verify it.
>>>>
>>>> But, you are right about vmlinux - it doesn't have those paths in there
>>>> any
>>>> more! I've seen them there when building with B != S, but they are gone
>>>> when
>>>> building with B = S. Wondering why. You can check it for yourself:
>>>>
>>>> http://arago-project.org/files/short-term/misc/vmlinux-
>>>> 3.14.0-yocto-standard
>>>>
>>>
>>> And, as a follow up, all those long paths in vmlinux when built with B
>>> != S
>>> point to sources. Here are few examples:
>>>
>>> B != S strings:
>>>
>>> /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/
>>> linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/init/main.c
>>> earlycon
>>> 4Malformed early option '%s'
>>> 3Starting init: %s exists but couldn't execute it (error %d)
>>> ...
>>> 6Trying to unpack rootfs image as initramfs...
>>> /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/
>>> linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/
>>> linux/init/initramfs.c
>>> 6rootfs image is not initramfs (%s); looks like an initrd
>>> TRAILER!!!
>>> ...
>>> %lu.%02lu BogoMIPS (lpj=%lu)
>>> /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/
>>> linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/
>>> linux/arch/arm/vfp/vfpmodule.c
>>> 6VFP support v0.3:
>>>
>>>
>>> B = S same strings:
>>>
>>> init/main.c
>>> earlycon
>>> 4Malformed early option '%s'
>>> 3Starting init: %s exists but couldn't execute it (error %d)
>>> ...
>>> 6Trying to unpack rootfs image as initramfs...
>>> init/initramfs.c
>>> 6rootfs image is not initramfs (%s); looks like an initrd
>>> TRAILER!!!
>>> ...
>>> %lu.%02lu BogoMIPS (lpj=%lu)
>>> arch/arm/vfp/vfpmodule.c
>>> 6VFP support v0.3:
>>>
>>>
>>> So, that explains why B = S works regardless of the location, as it
>>> doesn't
>>> embed full path to source files...
>>>
>>>
>> seemingly there could be rodata segment overflow issue. Can you do the
>> kernel build with say linker from dora build
>> and see if it still fails.
>>
>>
> It would be interesting to see if the rodata segment (or segment it
> contributes to) between working and non-working versions were crossing
> some magic power of 2 value.
>
> Are there two images published from the same build machines with just
> the path difference? I would like to see one that was just under the
> wire and one just a bit too long. Denys, you have that?
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
[-- Attachment #2: Type: text/html, Size: 6569 bytes --]
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-16 19:04 ` Stefan Stanacar
@ 2014-04-16 19:30 ` William Mills
0 siblings, 0 replies; 49+ messages in thread
From: William Mills @ 2014-04-16 19:30 UTC (permalink / raw)
To: Stefan Stanacar; +Cc: Paul Eggleton, yocto
On 04/16/2014 03:04 PM, Stefan Stanacar wrote:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=6165
>
> Link to the two kernels at the end of the first comment.
>
Yes, I found that i bit ago. Very helpful, thanks.
I have not run them yet (my only BBB is at home)
but I am comparing the objdumps.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-15 23:07 ` Gary Thomas
@ 2014-04-17 19:10 ` Denys Dmytriyenko
2014-04-17 21:31 ` William Mills
2014-04-17 22:48 ` Gary Thomas
0 siblings, 2 replies; 49+ messages in thread
From: Denys Dmytriyenko @ 2014-04-17 19:10 UTC (permalink / raw)
To: Gary Thomas; +Cc: yocto
On Tue, Apr 15, 2014 at 05:07:10PM -0600, Gary Thomas wrote:
> On 2014-04-15 13:43, Denys Dmytriyenko wrote:
> > On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:
> >>>>>> Some other things I tried with a "long" TMPDIR path (note that it's the
> >>>>>> TMPDIR path that makes the difference - in my tests I've been using
> >>>>>> /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
> >>>>>>
> >>>>>> * kernel built with gcc 4.7.2 and binutils 2.23.2
> >>>>>> * u-boot built with gcc 4.7.2 and binutils 2.23.2
> >>>>>> * u-boot from http://downloads.angstrom-distribution.org/demo/beaglebone/
> >>>>>> * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
> >>>>>>
> >>>>>> I think we're now at the point where we'd benefit from someone with better
> >>>>>> knowledge debugging the issue.
> >>>>>
> >>>>> Ok, should we expand the search area? Since this is supposed to be vanilla
> >>>>> 3.14 kernel, can we try other platforms and see if they are similarly
> >>>>> affected? I'll try pinging our kernel guys for any ideas...
> >>>>
> >>>> As far as I know it has only been observed with beaglebone (both white and
> >>>> black, if it makes a difference). FWIW, qemuarm images from the autobuilder
> >>>> boot just fine, and apparently the same is true of edgerouter (different
> >>>> architecture but also uses u-boot).
> >>>
> >>> But do those other platforms use uImage or zImage?
> >
> > I don't yet know what is going on, but building in the same directory with
> > sources (B = S) makes it work regarless of the path length:
> >
> > /OE/RAM/poky-111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111/22222222222222222222222222222222222222222222222222222222222222222222/3333333333333333333333333333333333333333333333333333/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
> >
> > So, I just commented out setting kernel-specific B in linux-yocto.inc and any
> > kernel now boots with long path:
> >
> > #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
> >
> > I'm copying Richard and Bruce directly to see if they may have a quick insight
> > and/or accept it as a workaround for the release. I'll keep digging further,
> > but if anyone cares to verify the above workaround works for them, I would
> > appreciate. Thanks!
> >
>
> Verified - I rebuilt the kernel in a working tree with a longer
> path (one in fact that had failed before) and it boots fine.
>
> Wonder what ${B} != ${S} is doing wacky...?
Gary, et al,
I've just submitted a patch to oe-core and yocto MLs that fixes this issue -
could you please test it in your setup and confirm? Thanks!
--
Denys
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-17 19:10 ` Denys Dmytriyenko
@ 2014-04-17 21:31 ` William Mills
2014-04-17 23:25 ` Khem Raj
2014-04-17 22:48 ` Gary Thomas
1 sibling, 1 reply; 49+ messages in thread
From: William Mills @ 2014-04-17 21:31 UTC (permalink / raw)
To: Denys Dmytriyenko; +Cc: yocto, Gary Thomas
On 04/17/2014 03:10 PM, Denys Dmytriyenko wrote:
> On Tue, Apr 15, 2014 at 05:07:10PM -0600, Gary Thomas wrote:
>> On 2014-04-15 13:43, Denys Dmytriyenko wrote:
>>> On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:
>>>>>>>> Some other things I tried with a "long" TMPDIR path (note that it's the
>>>>>>>> TMPDIR path that makes the difference - in my tests I've been using
>>>>>>>> /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
>>>>>>>>
>>>>>>>> * kernel built with gcc 4.7.2 and binutils 2.23.2
>>>>>>>> * u-boot built with gcc 4.7.2 and binutils 2.23.2
>>>>>>>> * u-boot from http://downloads.angstrom-distribution.org/demo/beaglebone/
>>>>>>>> * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
>>>>>>>>
>>>>>>>> I think we're now at the point where we'd benefit from someone with better
>>>>>>>> knowledge debugging the issue.
>>>>>>>
>>>>>>> Ok, should we expand the search area? Since this is supposed to be vanilla
>>>>>>> 3.14 kernel, can we try other platforms and see if they are similarly
>>>>>>> affected? I'll try pinging our kernel guys for any ideas...
>>>>>>
>>>>>> As far as I know it has only been observed with beaglebone (both white and
>>>>>> black, if it makes a difference). FWIW, qemuarm images from the autobuilder
>>>>>> boot just fine, and apparently the same is true of edgerouter (different
>>>>>> architecture but also uses u-boot).
>>>>>
>>>>> But do those other platforms use uImage or zImage?
>>>
>>> I don't yet know what is going on, but building in the same directory with
>>> sources (B = S) makes it work regarless of the path length:
>>>
>>> /OE/RAM/poky-111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111/22222222222222222222222222222222222222222222222222222222222222222222/3333333333333333333333333333333333333333333333333333/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
>>>
>>> So, I just commented out setting kernel-specific B in linux-yocto.inc and any
>>> kernel now boots with long path:
>>>
>>> #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
>>>
>>> I'm copying Richard and Bruce directly to see if they may have a quick insight
>>> and/or accept it as a workaround for the release. I'll keep digging further,
>>> but if anyone cares to verify the above workaround works for them, I would
>>> appreciate. Thanks!
>>>
>>
>> Verified - I rebuilt the kernel in a working tree with a longer
>> path (one in fact that had failed before) and it boots fine.
>>
>> Wonder what ${B} != ${S} is doing wacky...?
>
> Gary, et al,
>
> I've just submitted a patch to oe-core and yocto MLs that fixes this issue -
> could you please test it in your setup and confirm? Thanks!
>
I updated Stefan's bug w/ more explanation.
I verified that Stefan's uImage-bad failed for me and then added the
following to uEnv.txt:
fdtaddr=0x88000000
uImage-bad (and uImage-good) worked w/ the above change to uEnv.txt.
Denys' patch fixes all the defaults in u-boot so that no uEnv.txt change
is needed.
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-17 19:10 ` Denys Dmytriyenko
2014-04-17 21:31 ` William Mills
@ 2014-04-17 22:48 ` Gary Thomas
2014-04-17 23:17 ` Denys Dmytriyenko
1 sibling, 1 reply; 49+ messages in thread
From: Gary Thomas @ 2014-04-17 22:48 UTC (permalink / raw)
To: yocto
On 2014-04-17 13:10, Denys Dmytriyenko wrote:
> On Tue, Apr 15, 2014 at 05:07:10PM -0600, Gary Thomas wrote:
>> On 2014-04-15 13:43, Denys Dmytriyenko wrote:
>>> On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:
>>>>>>>> Some other things I tried with a "long" TMPDIR path (note that it's the
>>>>>>>> TMPDIR path that makes the difference - in my tests I've been using
>>>>>>>> /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
>>>>>>>>
>>>>>>>> * kernel built with gcc 4.7.2 and binutils 2.23.2
>>>>>>>> * u-boot built with gcc 4.7.2 and binutils 2.23.2
>>>>>>>> * u-boot from http://downloads.angstrom-distribution.org/demo/beaglebone/
>>>>>>>> * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
>>>>>>>>
>>>>>>>> I think we're now at the point where we'd benefit from someone with better
>>>>>>>> knowledge debugging the issue.
>>>>>>>
>>>>>>> Ok, should we expand the search area? Since this is supposed to be vanilla
>>>>>>> 3.14 kernel, can we try other platforms and see if they are similarly
>>>>>>> affected? I'll try pinging our kernel guys for any ideas...
>>>>>>
>>>>>> As far as I know it has only been observed with beaglebone (both white and
>>>>>> black, if it makes a difference). FWIW, qemuarm images from the autobuilder
>>>>>> boot just fine, and apparently the same is true of edgerouter (different
>>>>>> architecture but also uses u-boot).
>>>>>
>>>>> But do those other platforms use uImage or zImage?
>>>
>>> I don't yet know what is going on, but building in the same directory with
>>> sources (B = S) makes it work regarless of the path length:
>>>
>>> /OE/RAM/poky-111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111/22222222222222222222222222222222222222222222222222222222222222222222/3333333333333333333333333333333333333333333333333333/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
>>>
>>> So, I just commented out setting kernel-specific B in linux-yocto.inc and any
>>> kernel now boots with long path:
>>>
>>> #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
>>>
>>> I'm copying Richard and Bruce directly to see if they may have a quick insight
>>> and/or accept it as a workaround for the release. I'll keep digging further,
>>> but if anyone cares to verify the above workaround works for them, I would
>>> appreciate. Thanks!
>>>
>>
>> Verified - I rebuilt the kernel in a working tree with a longer
>> path (one in fact that had failed before) and it boots fine.
>>
>> Wonder what ${B} != ${S} is doing wacky...?
>
> Gary, et al,
>
> I've just submitted a patch to oe-core and yocto MLs that fixes this issue -
> could you please test it in your setup and confirm? Thanks!
>
Yes, verified it works great! Thanks for figuring this one out.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-17 22:48 ` Gary Thomas
@ 2014-04-17 23:17 ` Denys Dmytriyenko
0 siblings, 0 replies; 49+ messages in thread
From: Denys Dmytriyenko @ 2014-04-17 23:17 UTC (permalink / raw)
To: Gary Thomas; +Cc: yocto
On Thu, Apr 17, 2014 at 04:48:27PM -0600, Gary Thomas wrote:
> On 2014-04-17 13:10, Denys Dmytriyenko wrote:
> > On Tue, Apr 15, 2014 at 05:07:10PM -0600, Gary Thomas wrote:
> >> On 2014-04-15 13:43, Denys Dmytriyenko wrote:
> >>> On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:
> >>>>>>>> Some other things I tried with a "long" TMPDIR path (note that it's the
> >>>>>>>> TMPDIR path that makes the difference - in my tests I've been using
> >>>>>>>> /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
> >>>>>>>>
> >>>>>>>> * kernel built with gcc 4.7.2 and binutils 2.23.2
> >>>>>>>> * u-boot built with gcc 4.7.2 and binutils 2.23.2
> >>>>>>>> * u-boot from http://downloads.angstrom-distribution.org/demo/beaglebone/
> >>>>>>>> * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
> >>>>>>>>
> >>>>>>>> I think we're now at the point where we'd benefit from someone with better
> >>>>>>>> knowledge debugging the issue.
> >>>>>>>
> >>>>>>> Ok, should we expand the search area? Since this is supposed to be vanilla
> >>>>>>> 3.14 kernel, can we try other platforms and see if they are similarly
> >>>>>>> affected? I'll try pinging our kernel guys for any ideas...
> >>>>>>
> >>>>>> As far as I know it has only been observed with beaglebone (both white and
> >>>>>> black, if it makes a difference). FWIW, qemuarm images from the autobuilder
> >>>>>> boot just fine, and apparently the same is true of edgerouter (different
> >>>>>> architecture but also uses u-boot).
> >>>>>
> >>>>> But do those other platforms use uImage or zImage?
> >>>
> >>> I don't yet know what is going on, but building in the same directory with
> >>> sources (B = S) makes it work regarless of the path length:
> >>>
> >>> /OE/RAM/poky-111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111/22222222222222222222222222222222222222222222222222222222222222222222/3333333333333333333333333333333333333333333333333333/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
> >>>
> >>> So, I just commented out setting kernel-specific B in linux-yocto.inc and any
> >>> kernel now boots with long path:
> >>>
> >>> #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
> >>>
> >>> I'm copying Richard and Bruce directly to see if they may have a quick insight
> >>> and/or accept it as a workaround for the release. I'll keep digging further,
> >>> but if anyone cares to verify the above workaround works for them, I would
> >>> appreciate. Thanks!
> >>>
> >>
> >> Verified - I rebuilt the kernel in a working tree with a longer
> >> path (one in fact that had failed before) and it boots fine.
> >>
> >> Wonder what ${B} != ${S} is doing wacky...?
> >
> > Gary, et al,
> >
> > I've just submitted a patch to oe-core and yocto MLs that fixes this issue -
> > could you please test it in your setup and confirm? Thanks!
> >
>
> Yes, verified it works great! Thanks for figuring this one out.
And thank you for stumbling upon it in the first place :) and your continued
help validating it until completion! Thanks Stefan, Bill and everyone else
involed. Now let's hope Richard takes it into the release shortly... :)
--
Denys
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-17 21:31 ` William Mills
@ 2014-04-17 23:25 ` Khem Raj
2014-04-18 0:13 ` Denys Dmytriyenko
0 siblings, 1 reply; 49+ messages in thread
From: Khem Raj @ 2014-04-17 23:25 UTC (permalink / raw)
To: William Mills; +Cc: yocto, Gary Thomas
On Thu, Apr 17, 2014 at 2:31 PM, William Mills <wmills@ti.com> wrote:
> On 04/17/2014 03:10 PM, Denys Dmytriyenko wrote:
>>
>> On Tue, Apr 15, 2014 at 05:07:10PM -0600, Gary Thomas wrote:
>>>
>>> On 2014-04-15 13:43, Denys Dmytriyenko wrote:
>>>>
>>>> On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:
>>>>>>>>>
>>>>>>>>> Some other things I tried with a "long" TMPDIR path (note that it's
>>>>>>>>> the
>>>>>>>>> TMPDIR path that makes the difference - in my tests I've been using
>>>>>>>>> /home/paul/poky/build2/much/longer/path/to/tmp). None of this
>>>>>>>>> helped:
>>>>>>>>>
>>>>>>>>> * kernel built with gcc 4.7.2 and binutils 2.23.2
>>>>>>>>> * u-boot built with gcc 4.7.2 and binutils 2.23.2
>>>>>>>>> * u-boot from
>>>>>>>>> http://downloads.angstrom-distribution.org/demo/beaglebone/
>>>>>>>>> * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
>>>>>>>>>
>>>>>>>>> I think we're now at the point where we'd benefit from someone with
>>>>>>>>> better
>>>>>>>>> knowledge debugging the issue.
>>>>>>>>
>>>>>>>>
>>>>>>>> Ok, should we expand the search area? Since this is supposed to be
>>>>>>>> vanilla
>>>>>>>> 3.14 kernel, can we try other platforms and see if they are
>>>>>>>> similarly
>>>>>>>> affected? I'll try pinging our kernel guys for any ideas...
>>>>>>>
>>>>>>>
>>>>>>> As far as I know it has only been observed with beaglebone (both
>>>>>>> white and
>>>>>>> black, if it makes a difference). FWIW, qemuarm images from the
>>>>>>> autobuilder
>>>>>>> boot just fine, and apparently the same is true of edgerouter
>>>>>>> (different
>>>>>>> architecture but also uses u-boot).
>>>>>>
>>>>>>
>>>>>> But do those other platforms use uImage or zImage?
>>>>
>>>>
>>>> I don't yet know what is going on, but building in the same directory
>>>> with
>>>> sources (B = S) makes it work regarless of the path length:
>>>>
>>>>
>>>> /OE/RAM/poky-111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111/22222222222222222222222222222222222222222222222222222222222222222222/3333333333333333333333333333333333333333333333333333/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
>>>>
>>>> So, I just commented out setting kernel-specific B in linux-yocto.inc
>>>> and any
>>>> kernel now boots with long path:
>>>>
>>>> #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
>>>>
>>>> I'm copying Richard and Bruce directly to see if they may have a quick
>>>> insight
>>>> and/or accept it as a workaround for the release. I'll keep digging
>>>> further,
>>>> but if anyone cares to verify the above workaround works for them, I
>>>> would
>>>> appreciate. Thanks!
>>>>
>>>
>>> Verified - I rebuilt the kernel in a working tree with a longer
>>> path (one in fact that had failed before) and it boots fine.
>>>
>>> Wonder what ${B} != ${S} is doing wacky...?
>>
>>
>> Gary, et al,
>>
>> I've just submitted a patch to oe-core and yocto MLs that fixes this issue
>> -
>> could you please test it in your setup and confirm? Thanks!
>>
>
> I updated Stefan's bug w/ more explanation.
> I verified that Stefan's uImage-bad failed for me and then added the
> following to uEnv.txt:
> fdtaddr=0x88000000
hmmm so it seems kernel size grew enough to overwrite the area where
uboot would put divice tree ?
has happened to me on ppc with kernel+initramfs where initramfs kept growing
>
> uImage-bad (and uImage-good) worked w/ the above change to uEnv.txt.
> Denys' patch fixes all the defaults in u-boot so that no uEnv.txt change is
> needed.
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-17 23:25 ` Khem Raj
@ 2014-04-18 0:13 ` Denys Dmytriyenko
2014-04-18 17:52 ` William Mills
0 siblings, 1 reply; 49+ messages in thread
From: Denys Dmytriyenko @ 2014-04-18 0:13 UTC (permalink / raw)
To: Khem Raj; +Cc: yocto
On Thu, Apr 17, 2014 at 04:25:51PM -0700, Khem Raj wrote:
> On Thu, Apr 17, 2014 at 2:31 PM, William Mills <wmills@ti.com> wrote:
> > On 04/17/2014 03:10 PM, Denys Dmytriyenko wrote:
> >>
> >> On Tue, Apr 15, 2014 at 05:07:10PM -0600, Gary Thomas wrote:
> >>>
> >>> On 2014-04-15 13:43, Denys Dmytriyenko wrote:
> >>>>
> >>>> On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:
> >>>>>>>>>
> >>>>>>>>> Some other things I tried with a "long" TMPDIR path (note that it's
> >>>>>>>>> the
> >>>>>>>>> TMPDIR path that makes the difference - in my tests I've been using
> >>>>>>>>> /home/paul/poky/build2/much/longer/path/to/tmp). None of this
> >>>>>>>>> helped:
> >>>>>>>>>
> >>>>>>>>> * kernel built with gcc 4.7.2 and binutils 2.23.2
> >>>>>>>>> * u-boot built with gcc 4.7.2 and binutils 2.23.2
> >>>>>>>>> * u-boot from
> >>>>>>>>> http://downloads.angstrom-distribution.org/demo/beaglebone/
> >>>>>>>>> * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
> >>>>>>>>>
> >>>>>>>>> I think we're now at the point where we'd benefit from someone with
> >>>>>>>>> better
> >>>>>>>>> knowledge debugging the issue.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Ok, should we expand the search area? Since this is supposed to be
> >>>>>>>> vanilla
> >>>>>>>> 3.14 kernel, can we try other platforms and see if they are
> >>>>>>>> similarly
> >>>>>>>> affected? I'll try pinging our kernel guys for any ideas...
> >>>>>>>
> >>>>>>>
> >>>>>>> As far as I know it has only been observed with beaglebone (both
> >>>>>>> white and
> >>>>>>> black, if it makes a difference). FWIW, qemuarm images from the
> >>>>>>> autobuilder
> >>>>>>> boot just fine, and apparently the same is true of edgerouter
> >>>>>>> (different
> >>>>>>> architecture but also uses u-boot).
> >>>>>>
> >>>>>>
> >>>>>> But do those other platforms use uImage or zImage?
> >>>>
> >>>>
> >>>> I don't yet know what is going on, but building in the same directory
> >>>> with
> >>>> sources (B = S) makes it work regarless of the path length:
> >>>>
> >>>>
> >>>> /OE/RAM/poky-111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111/22222222222222222222222222222222222222222222222222222222222222222222/3333333333333333333333333333333333333333333333333333/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
> >>>>
> >>>> So, I just commented out setting kernel-specific B in linux-yocto.inc
> >>>> and any
> >>>> kernel now boots with long path:
> >>>>
> >>>> #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
> >>>>
> >>>> I'm copying Richard and Bruce directly to see if they may have a quick
> >>>> insight
> >>>> and/or accept it as a workaround for the release. I'll keep digging
> >>>> further,
> >>>> but if anyone cares to verify the above workaround works for them, I
> >>>> would
> >>>> appreciate. Thanks!
> >>>>
> >>>
> >>> Verified - I rebuilt the kernel in a working tree with a longer
> >>> path (one in fact that had failed before) and it boots fine.
> >>>
> >>> Wonder what ${B} != ${S} is doing wacky...?
> >>
> >>
> >> Gary, et al,
> >>
> >> I've just submitted a patch to oe-core and yocto MLs that fixes this issue
> >> -
> >> could you please test it in your setup and confirm? Thanks!
> >>
> >
> > I updated Stefan's bug w/ more explanation.
> > I verified that Stefan's uImage-bad failed for me and then added the
> > following to uEnv.txt:
> > fdtaddr=0x88000000
>
> hmmm so it seems kernel size grew enough to overwrite the area where
> uboot would put divice tree ?
Exactly! The overall kernel size was very close to the limit of previous space
allocation in U-boot and enabling another feature or growing the build path a
bit would overflow into and corrupt the device tree.
> has happened to me on ppc with kernel+initramfs where initramfs kept growing
I was told no other platforms were affected, including qemuarm! :) Yeah, I
know, it can happen to anyone, even though by default it works fine...
> > uImage-bad (and uImage-good) worked w/ the above change to uEnv.txt.
> > Denys' patch fixes all the defaults in u-boot so that no uEnv.txt change is
> > needed.
> >
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: BBB doesn't boot
2014-04-18 0:13 ` Denys Dmytriyenko
@ 2014-04-18 17:52 ` William Mills
0 siblings, 0 replies; 49+ messages in thread
From: William Mills @ 2014-04-18 17:52 UTC (permalink / raw)
To: Denys Dmytriyenko; +Cc: yocto
On 04/17/2014 08:13 PM, Denys Dmytriyenko wrote:
> On Thu, Apr 17, 2014 at 04:25:51PM -0700, Khem Raj wrote:
>> On Thu, Apr 17, 2014 at 2:31 PM, William Mills <wmills@ti.com> wrote:
>>> On 04/17/2014 03:10 PM, Denys Dmytriyenko wrote:
>>>>
>>>> On Tue, Apr 15, 2014 at 05:07:10PM -0600, Gary Thomas wrote:
>>>>>
>>>>> On 2014-04-15 13:43, Denys Dmytriyenko wrote:
>>>>>>
>>>>>> On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:
>>>>>>>>>>>
>>>>>>>>>>> Some other things I tried with a "long" TMPDIR path (note that it's
>>>>>>>>>>> the
>>>>>>>>>>> TMPDIR path that makes the difference - in my tests I've been using
>>>>>>>>>>> /home/paul/poky/build2/much/longer/path/to/tmp). None of this
>>>>>>>>>>> helped:
>>>>>>>>>>>
>>>>>>>>>>> * kernel built with gcc 4.7.2 and binutils 2.23.2
>>>>>>>>>>> * u-boot built with gcc 4.7.2 and binutils 2.23.2
>>>>>>>>>>> * u-boot from
>>>>>>>>>>> http://downloads.angstrom-distribution.org/demo/beaglebone/
>>>>>>>>>>> * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
>>>>>>>>>>>
>>>>>>>>>>> I think we're now at the point where we'd benefit from someone with
>>>>>>>>>>> better
>>>>>>>>>>> knowledge debugging the issue.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ok, should we expand the search area? Since this is supposed to be
>>>>>>>>>> vanilla
>>>>>>>>>> 3.14 kernel, can we try other platforms and see if they are
>>>>>>>>>> similarly
>>>>>>>>>> affected? I'll try pinging our kernel guys for any ideas...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> As far as I know it has only been observed with beaglebone (both
>>>>>>>>> white and
>>>>>>>>> black, if it makes a difference). FWIW, qemuarm images from the
>>>>>>>>> autobuilder
>>>>>>>>> boot just fine, and apparently the same is true of edgerouter
>>>>>>>>> (different
>>>>>>>>> architecture but also uses u-boot).
>>>>>>>>
>>>>>>>>
>>>>>>>> But do those other platforms use uImage or zImage?
>>>>>>
>>>>>>
>>>>>> I don't yet know what is going on, but building in the same directory
>>>>>> with
>>>>>> sources (B = S) makes it work regarless of the path length:
>>>>>>
>>>>>>
>>>>>> /OE/RAM/poky-111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111/22222222222222222222222222222222222222222222222222222222222222222222/3333333333333333333333333333333333333333333333333333/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
>>>>>>
>>>>>> So, I just commented out setting kernel-specific B in linux-yocto.inc
>>>>>> and any
>>>>>> kernel now boots with long path:
>>>>>>
>>>>>> #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
>>>>>>
>>>>>> I'm copying Richard and Bruce directly to see if they may have a quick
>>>>>> insight
>>>>>> and/or accept it as a workaround for the release. I'll keep digging
>>>>>> further,
>>>>>> but if anyone cares to verify the above workaround works for them, I
>>>>>> would
>>>>>> appreciate. Thanks!
>>>>>>
>>>>>
>>>>> Verified - I rebuilt the kernel in a working tree with a longer
>>>>> path (one in fact that had failed before) and it boots fine.
>>>>>
>>>>> Wonder what ${B} != ${S} is doing wacky...?
>>>>
>>>>
>>>> Gary, et al,
>>>>
>>>> I've just submitted a patch to oe-core and yocto MLs that fixes this issue
>>>> -
>>>> could you please test it in your setup and confirm? Thanks!
>>>>
>>>
>>> I updated Stefan's bug w/ more explanation.
>>> I verified that Stefan's uImage-bad failed for me and then added the
>>> following to uEnv.txt:
>>> fdtaddr=0x88000000
>>
>> hmmm so it seems kernel size grew enough to overwrite the area where
>> uboot would put divice tree ?
>
> Exactly! The overall kernel size was very close to the limit of previous space m,
> allocation in U-boot and enabling another feature or growing the build path a
> bit would overflow into and corrupt the device tree.
>
>
>> has happened to me on ppc with kernel+initramfs where initramfs kept growing
>
> I was told no other platforms were affected, including qemuarm! :) Yeah, I
> know, it can happen to anyone, even though by default it works fine...
>
I did not look at qemuarm but I assume it was using different values for
for loadaddr & fdtaddr. (qemuarm is using fdt now right?)
Khem, yes this would have effected initrd also if the kernel was just a
touch bigger. The patch Denys pushed moves the intrd load address as
well. We should be good now.
If initramfs gets trashed you get a message when the kernel tries to
decompresses it that it is invalid. If fdt gets trashed the kernel
does not know how to send messages to uart so you get nothing. I am
not sure but when I was debugging with JTAG, it looked like the kernel
had actually started and was doing _something_. It just had no
hardware to talk to.
If a kernel boots in a forest and has no way to talk, does it have any
bogomips?
>
>>> uImage-bad (and uImage-good) worked w/ the above change to uEnv.txt.
>>> Denys' patch fixes all the defaults in u-boot so that no uEnv.txt change is
>>> needed.
>>>
>>> --
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
^ permalink raw reply [flat|nested] 49+ messages in thread
end of thread, other threads:[~2014-04-18 17:52 UTC | newest]
Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-13 9:12 BBB doesn't boot Gary Thomas
2014-04-14 2:33 ` Denys Dmytriyenko
2014-04-14 10:25 ` Gary Thomas
2014-04-14 15:46 ` Denys Dmytriyenko
2014-04-14 15:51 ` Gary Thomas
2014-04-14 16:00 ` Denys Dmytriyenko
2014-04-14 16:04 ` Gary Thomas
2014-04-14 16:08 ` Denys Dmytriyenko
2014-04-14 20:11 ` Gary Thomas
2014-04-14 22:44 ` Denys Dmytriyenko
2014-04-15 0:20 ` Richard Purdie
2014-04-15 1:38 ` Denys Dmytriyenko
2014-04-15 4:44 ` Richard Purdie
2014-04-15 5:07 ` Denys Dmytriyenko
2014-04-15 5:17 ` Denys Dmytriyenko
2014-04-15 9:03 ` Stanacar, StefanX
2014-04-15 11:52 ` Stanacar, StefanX
2014-04-15 14:42 ` Gary Thomas
2014-04-15 14:49 ` Paul Eggleton
2014-04-15 15:15 ` Stoicescu, CorneliuX
2014-04-15 15:37 ` Gary Thomas
2014-04-15 16:26 ` Denys Dmytriyenko
2014-04-15 16:36 ` Paul Eggleton
2014-04-15 17:16 ` Denys Dmytriyenko
2014-04-15 17:41 ` Denys Dmytriyenko
2014-04-15 19:43 ` Denys Dmytriyenko
2014-04-15 23:07 ` Gary Thomas
2014-04-17 19:10 ` Denys Dmytriyenko
2014-04-17 21:31 ` William Mills
2014-04-17 23:25 ` Khem Raj
2014-04-18 0:13 ` Denys Dmytriyenko
2014-04-18 17:52 ` William Mills
2014-04-17 22:48 ` Gary Thomas
2014-04-17 23:17 ` Denys Dmytriyenko
2014-04-15 23:29 ` Bruce Ashfield
2014-04-15 23:36 ` Richard Purdie
2014-04-16 1:12 ` Denys Dmytriyenko
2014-04-16 1:20 ` Denys Dmytriyenko
2014-04-16 3:31 ` Khem Raj
2014-04-16 15:57 ` William Mills
2014-04-16 19:04 ` Stefan Stanacar
2014-04-16 19:30 ` William Mills
2014-04-16 10:20 ` Stanacar, StefanX
2014-04-15 17:25 ` Stanacar, StefanX
2014-04-15 14:41 ` Gary Thomas
2014-04-14 10:35 ` Stanacar, StefanX
2014-04-14 11:38 ` Stanacar, StefanX
2014-04-14 11:44 ` Gary Thomas
2014-04-14 11:51 ` Gary Thomas
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.