Re: BBB doesn't boot

[William Mills <wmills@ti.com>]

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
>>