Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

Hi,

I have a custom TI816x board that uses a modified kernel from the TI PSP.
 Kernel is of the 2.6.37 flavor.  I'm trying to migrate to OE Core
environment and I'm having trouble with getting the kernel to work.

With the toolchain in denzil (gcc version 4.6.4 20120303), kernel will at
least boot but will die with:

Unable to handle kernel NULL pointer dereference at virtual address 00000002
pgd = c0004000
[00000002] *pgd=00000000
Internal error: Oops: 5 [#1]

Any of the more modern toolchains (poky/meta-ti master or Linaro
(gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux) are used, the kernel
won't even make a peep ... nothing is displayed.

I wouldn't think the version of u-boot would matter but in case it does the
one I'm using is 2010.06 that was modified from one of the TI PSP's for our
custom board.

Anyone know what I have to do to get this kernel to build with newer
toolchains?  It builds fine with the Code Sourcery arm-2009q1-203.

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 1263 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Chris Larson]

[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]

On Thu, Aug 15, 2013 at 8:52 AM, Brian Hutchinson <b.hutchman@gmail.com>wrote:

> I have a custom TI816x board that uses a modified kernel from the TI PSP.
>  Kernel is of the 2.6.37 flavor.  I'm trying to migrate to OE Core
> environment and I'm having trouble with getting the kernel to work.
>
> With the toolchain in denzil (gcc version 4.6.4 20120303), kernel will at
> least boot but will die with:
>
> Unable to handle kernel NULL pointer dereference at virtual address
> 00000002
> pgd = c0004000
> [00000002] *pgd=00000000
> Internal error: Oops: 5 [#1]
>
> Any of the more modern toolchains (poky/meta-ti master or Linaro
> (gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux) are used, the kernel
> won't even make a peep ... nothing is displayed.
>

I haven't seen the panic, but I have seen a complete silent boot hang when
moving from 4.6 to 4.7 or 4.8 on my OMAP5 EVM board. The gcc-linaro
toolchain worked, as did a 2012.03 sourcery toolchain, but neither the
2013.05 toolchain nor the internal built yocto toolchain from 1.5/master
resulted in a successful boot. I got past that issue by cherry picking
these two commits from a more recent kernel:

455bd4c430b0c0a361f38e8658a0d6cb469942b5 - ARM: 7668/1: fix memset-related
crashes caused by recent GCC (4.7.2) optimizations
418df63adac56841ef6b0f1fcf435bc64d4ed177 - ARM: 7670/1: fix the memset fix

See also
http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/39864

Presumably you may need more than just that since you're also hitting a
panic with 4.6, but it may be worth trying those as a starting point. Good
luck!
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 2616 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Denys Dmytriyenko]

On Thu, Aug 15, 2013 at 09:25:38AM -0700, Chris Larson wrote:
> On Thu, Aug 15, 2013 at 8:52 AM, Brian Hutchinson <b.hutchman@gmail.com>wrote:
> 
> > I have a custom TI816x board that uses a modified kernel from the TI PSP.
> >  Kernel is of the 2.6.37 flavor.  I'm trying to migrate to OE Core
> > environment and I'm having trouble with getting the kernel to work.
> >
> > With the toolchain in denzil (gcc version 4.6.4 20120303), kernel will at
> > least boot but will die with:
> >
> > Unable to handle kernel NULL pointer dereference at virtual address
> > 00000002
> > pgd = c0004000
> > [00000002] *pgd=00000000
> > Internal error: Oops: 5 [#1]
> >
> > Any of the more modern toolchains (poky/meta-ti master or Linaro
> > (gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux) are used, the kernel
> > won't even make a peep ... nothing is displayed.
> >
> 
> I haven't seen the panic, but I have seen a complete silent boot hang when
> moving from 4.6 to 4.7 or 4.8 on my OMAP5 EVM board. The gcc-linaro
> toolchain worked, as did a 2012.03 sourcery toolchain, but neither the
> 2013.05 toolchain nor the internal built yocto toolchain from 1.5/master
> resulted in a successful boot. I got past that issue by cherry picking
> these two commits from a more recent kernel:
> 
> 455bd4c430b0c0a361f38e8658a0d6cb469942b5 - ARM: 7668/1: fix memset-related
> crashes caused by recent GCC (4.7.2) optimizations
> 418df63adac56841ef6b0f1fcf435bc64d4ed177 - ARM: 7670/1: fix the memset fix
> 
> See also
> http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/39864
> 
> Presumably you may need more than just that since you're also hitting a
> panic with 4.6, but it may be worth trying those as a starting point. Good
> luck!

Yes, it is often a PITA to get old kernels build and work properly with new 
toolchains. E.g. you are aware of the alignment issue with 4.7, right?

http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-kernel/linux/files/0001-arm-fix-builds-with-gcc-4.7.patch

-- 
Denys

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

On Thu, Aug 15, 2013 at 3:06 PM, Denys Dmytriyenko <denys@ti.com> wrote:

>
> Yes, it is often a PITA to get old kernels build and work properly with new
> toolchains. E.g. you are aware of the alignment issue with 4.7, right?
>
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-kernel/linux/files/0001-arm-fix-builds-with-gcc-4.7.patch
>
> --
> Denys
>

No, had not come across that one yet but it sounds like it is on the right
track after having read this thread:
https://lists.yoctoproject.org/pipermail/meta-ti/2012-May/001144.html

I'm trying to make sense of all this ... we need to keep syslink working
too which sounds like it (mailbox) needs kernel options which may cause
problems too.

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 1548 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 298 bytes --]

On Thu, Aug 15, 2013 at 3:06 PM, Denys Dmytriyenko <denys@ti.com> wrote:

>
> Yes, it is often a PITA to get old kernels build ...
>

What do you mean "old kernels"  It is from a TI PSP released not that long
ago! Wink, wink.  I'd love to use a 3+ kernel, know where I can find one ;)

B

[-- Attachment #2: Type: text/html, Size: 698 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Denys Dmytriyenko]

On Thu, Aug 15, 2013 at 03:26:55PM -0400, Brian Hutchinson wrote:
> On Thu, Aug 15, 2013 at 3:06 PM, Denys Dmytriyenko <denys@ti.com> wrote:
> 
> >
> > Yes, it is often a PITA to get old kernels build ...
> >
> 
> What do you mean "old kernels"  It is from a TI PSP released not that long
> ago! Wink, wink.  I'd love to use a 3+ kernel, know where I can find one ;)

So, cross-referencing the 2.6.37 release date of January 4, 2011 against gcc 
releases shows that you can only expect 4.4 or 4.5 to work properly out of 
the box w/o patching... :)

And I have already answered the "newer TI81x kernel" question many times, 
including the last email in this thread :)

-- 
Denys

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

On Thu, Aug 15, 2013 at 3:34 PM, Denys Dmytriyenko <denys@ti.com> wrote:

>
> So, cross-referencing the 2.6.37 release date of January 4, 2011 against
> gcc
> releases shows that you can only expect 4.4 or 4.5 to work properly out of
> the box w/o patching... :)
>
> And I have already answered the "newer TI81x kernel" question many times,
> including the last email in this thread :)
>
>
The horse isn't dead yet!  The beatings will continue until morale
improves. ;)

[-- Attachment #2: Type: text/html, Size: 922 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

On Thu, Aug 15, 2013 at 12:25 PM, Chris Larson <clarson@kergoth.com> wrote:

>
> I haven't seen the panic, but I have seen a complete silent boot hang when
> moving from 4.6 to 4.7 or 4.8 on my OMAP5 EVM board. The gcc-linaro
> toolchain worked, as did a 2012.03 sourcery toolchain, but neither the
> 2013.05 toolchain nor the internal built yocto toolchain from 1.5/master
> resulted in a successful boot. I got past that issue by cherry picking
> these two commits from a more recent kernel:
>
> 455bd4c430b0c0a361f38e8658a0d6cb469942b5 - ARM: 7668/1: fix memset-related
> crashes caused by recent GCC (4.7.2) optimizations
> 418df63adac56841ef6b0f1fcf435bc64d4ed177 - ARM: 7670/1: fix the memset fix
>
> See also
> http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/39864
>
>
>
I found this thread which is bang on with my problem but didn't see a
solution yet:
https://lists.yoctoproject.org/pipermail/meta-ti/2012-May/001144.html

Regards,

Brain

[-- Attachment #2: Type: text/html, Size: 1895 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Denys Dmytriyenko]

On Thu, Aug 15, 2013 at 03:10:24PM -0400, Brian Hutchinson wrote:
> On Thu, Aug 15, 2013 at 12:25 PM, Chris Larson <clarson@kergoth.com> wrote:
> 
> >
> > I haven't seen the panic, but I have seen a complete silent boot hang when
> > moving from 4.6 to 4.7 or 4.8 on my OMAP5 EVM board. The gcc-linaro
> > toolchain worked, as did a 2012.03 sourcery toolchain, but neither the
> > 2013.05 toolchain nor the internal built yocto toolchain from 1.5/master
> > resulted in a successful boot. I got past that issue by cherry picking
> > these two commits from a more recent kernel:
> >
> > 455bd4c430b0c0a361f38e8658a0d6cb469942b5 - ARM: 7668/1: fix memset-related
> > crashes caused by recent GCC (4.7.2) optimizations
> > 418df63adac56841ef6b0f1fcf435bc64d4ed177 - ARM: 7670/1: fix the memset fix
> >
> > See also
> > http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/39864
> >
> I found this thread which is bang on with my problem but didn't see a
> solution yet:
> https://lists.yoctoproject.org/pipermail/meta-ti/2012-May/001144.html

Have you tried poking into the following repositories for a possible fix:

http://arago-project.org/git/projects/?p=linux-omap3.git;a=shortlog;h=refs/heads/ti81xx-master
http://arago-project.org/git/projects/?p=linux-dvr-rdk-dm81xx.git;a=summary
http://arago-project.org/git/projects/?p=linux-ipnc-rdk-dm81xx.git;a=summary

There are some product-specific forks around TI81x which I don't have any 
visibility into and hence I can't support it in meta-ti... :(

-- 
Denys

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]

On Thu, Aug 15, 2013 at 3:22 PM, Denys Dmytriyenko <denys@ti.com> wrote:

>
> Have you tried poking into the following repositories for a possible fix:
>
>
> http://arago-project.org/git/projects/?p=linux-omap3.git;a=shortlog;h=refs/heads/ti81xx-master
> http://arago-project.org/git/projects/?p=linux-dvr-rdk-dm81xx.git;a=summary
>
> http://arago-project.org/git/projects/?p=linux-ipnc-rdk-dm81xx.git;a=summary
>
> There are some product-specific forks around TI81x which I don't have any
> visibility into and hence I can't support it in meta-ti... :(
>
>
No, I've not looked specifically thought those but I did go back and look
through some of my Arago & Angstrom OE Classic builds and log files to see
what switches where being used to build the kernel.  Tried several
combinations but they didn't appear to matter.  Maybe with Steve's fix and
the -mno-unaligned-access option I read about I can get farther.

Thanks for the suggestion.  I'll have to scan those commits to see if
anything jumps out at me.

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 2020 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 149 bytes --]

Update.  Well, adding Sakoman's patch to head.S and compiling with
-mno-unaligned-access
didn't appear to help so far ... :(

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 555 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

On Thu, Aug 15, 2013 at 2:14 PM, Brian Hutchinson <b.hutchman@gmail.com>wrote:

> Update.  Well, adding Sakoman's patch to head.S and compiling with -mno-unaligned-access
> didn't appear to help so far ... :(
>
>
​If its gcc 4.8+ then you also need more patches see my fixes for beagle
e.g.

https://github.com/beagleboard/meta-beagleboard/commit/87efc663c4f76d3051cecf1e2c3e2bbd461d200b
​



> Regards,
>
> Brian
>
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti
>
>

[-- Attachment #2: Type: text/html, Size: 2272 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 786 bytes --]

On Thu, Aug 15, 2013 at 5:32 PM, Khem Raj <raj.khem@gmail.com> wrote:

>
> If its gcc 4.8+ then you also need more patches see my fixes for beagle
> e.g.
>
>
> https://github.com/beagleboard/meta-beagleboard/commit/87efc663c4f76d3051cecf1e2c3e2bbd461d200b
> 
>

Hi Khem,  good to hear from you.

I'll check those out.  On another machine I think I have an older Linaro
4.7 something laying around from last time I built something (well, tried
to.  Wanted DM6446 and learned it was dropped from OE Core) with Arago OE
Core a while ago.  I haven't tried that version on this Cortex A8 part but
I'm guessing I would run into the same issues as the latest (4.8) I
downloaded today???.  I'll apply those and give it a shot and report back.

Thanks!

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 1690 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

On Thu, Aug 15, 2013 at 5:32 PM, Khem Raj <raj.khem@gmail.com> wrote:

>
>
>
> On Thu, Aug 15, 2013 at 2:14 PM, Brian Hutchinson <b.hutchman@gmail.com>wrote:
>
>> Update.  Well, adding Sakoman's patch to head.S and compiling with -mno-unaligned-access
>> didn't appear to help so far ... :(
>>
>>
> If its gcc 4.8+ then you also need more patches see my fixes for beagle
> e.g.
>
>
> https://github.com/beagleboard/meta-beagleboard/commit/87efc663c4f76d3051cecf1e2c3e2bbd461d200b
> 
>
>
After I apply these patches, should I still be passing EXTRA_CFLAGS=
-mno-unaligned-access
to make uImage?

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 2110 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 145 bytes --]

... more evidence at least one other poor soul is having the same problem:

http://comments.gmane.org/gmane.comp.handhelds.openembedded/52259

[-- Attachment #2: Type: text/html, Size: 274 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 19381 bytes --]

Another update (any my feeble cry for ideas is at the very bottom after the
kernel boot dump).  I applied the patches Khem mentioned.  The patch
applied but I studied the code and there are big differences between 2.6.37
for ti816x vs the 3.8 for beagle.  There looked to be more in the patch
than was able to be applied so I didn't have any confidence this would fix
anything after I noticed that and when I tried to boot the kernel the hung
boot confirmed my suspicion.  At this point I'm using the toolchains
outside of OE (meta-toolchain from denzil branch and Linaro 4.8) to make
life a bit simpler.  Here is what my memset.S looks like after applying the
two patches:

/*
 *  linux/arch/arm/lib/memset.S
 *
 *  Copyright (C) 1995-2000 Russell King
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as
 * published by the Free Software Foundation.
 *
 *  ASM optimised string functions
 */
#include <linux/linkage.h>
#include <asm/assembler.h>

.text
.align 5

ENTRY(memset)
ands r3, r0, #3 @ 1 unaligned?
mov ip, r0 @ preserve r0 as return value
bne 6f @ 1
/*
 * we know that the pointer in ip is aligned to a word boundary.
 */
1: orr r1, r1, r1, lsl #8
orr r1, r1, r1, lsl #16
mov r3, r1
cmp r2, #16
blt 4f

#if ! CALGN(1)+0

/*
 * We need 2 extra registers for this loop - use r8 and the LR
 */
stmfd sp!, {r8, lr}
mov r8, r1
mov lr, r1

2: subs r2, r2, #64
stmgeia ip!, {r1, r3, r8, lr} @ 64 bytes at a time.
stmgeia ip!, {r1, r3, r8, lr}
stmgeia ip!, {r1, r3, r8, lr}
stmgeia ip!, {r1, r3, r8, lr}
bgt 2b
ldmeqfd sp!, {r8, pc} @ Now <64 bytes to go.
/*
 * No need to correct the count; we're only testing bits from now on
 */
tst r2, #32
stmneia ip!, {r1, r3, r8, lr}
stmneia ip!, {r1, r3, r8, lr}
tst r2, #16
stmneia ip!, {r1, r3, r8, lr}
ldmfd sp!, {r8, lr}

#else

/*
 * This version aligns the destination pointer in order to write
 * whole cache lines at once.
 */

stmfd sp!, {r4-r8, lr}
mov r4, r1
mov r5, r1
mov r6, r1
mov r7, r1
mov r8, r1
mov lr, r1

cmp r2, #96
tstgt ip, #31
ble 3f

and r8, ip, #31
rsb r8, r8, #32
sub r2, r2, r8
movs r8, r8, lsl #(32 - 4)
stmcsia ip!, {r4, r5, r6, r7}
stmmiia ip!, {r4, r5}
tst r8, #(1 << 30)
mov r8, r1
strne r1, [ip], #4

3: subs r2, r2, #64
stmgeia ip!, {r1, r3-r8, lr}
stmgeia ip!, {r1, r3-r8, lr}
bgt 3b
ldmeqfd sp!, {r4-r8, pc}

tst r2, #32
stmneia ip!, {r1, r3-r8, lr}
tst r2, #16
stmneia ip!, {r4-r7}
ldmfd sp!, {r4-r8, lr}

#endif

4: tst r2, #8
stmneia ip!, {r1, r3}
tst r2, #4
strne r1, [ip], #4
/*
 * When we get here, we've got less than 4 bytes to zero.  We
 * may have an unaligned pointer as well.
 */
5: tst r2, #2
strneb r1, [ip], #1
strneb r1, [ip], #1
tst r2, #1
strneb r1, [ip], #1
mov pc, lr

6: subs r2, r2, #4 @ 1 do we have enough
blt 5b @ 1 bytes to align with?
cmp r3, #2 @ 1
strltb r1, [ip], #1 @ 1
strleb r1, [ip], #1 @ 1
strb r1, [ip], #1 @ 1
add r2, r2, r3 @ 1 (r2 = r2 - (4 - r3))
b 1b
ENDPROC(memset)



So to recap, the TI 2.6.37 kernel freezes after displaying (kernel being
tftp'd in):

Bytes transferred = 2349296 (23d8f0 hex)
## Booting kernel from Legacy Image at 83000000 ...
   Image Name:   Linux-2.6.37+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2349232 Bytes = 2.2 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...


The toolchain built by bitbake meta-toolchain in denzil (doesn't have the
-c populate_sdk feature) boots farther but later dies.  The full dump of
that boot is:


Bytes transferred = 2343056 (23c090 hex)
## Booting kernel from Legacy Image at 83000000 ...
   Image Name:   Linux-2.6.37+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2342992 Bytes = 2.2 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Linux version 2.6.37+ (hutch@Strider) (gcc version 4.6.4 20120303
(prerelease) (GCC) ) #1 Fri Aug 16 10:10:53 EDT 2013
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: ti8168evm
reserved size = 0 at 0x0
Memory policy: ECC disabled, Data cache writeback
OMAP chip is TI8168 2.0
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 42164
Kernel command line: mem=166M console=ttyO2,115200n8 noinitrd
ip=192.168.1.1:192.168.1.5:192.168.1.0:255.255.255.0:255.255.255.1:eth0:off
eth=84:7e:40:d6:a7:5e root=/dev/nfs nfsroot=192.168.1.5:
/home/hutch/ione_wcs_yocto_test/trunk/arm/rootfs
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 166MB = 166MB total
Memory: 163428k/163428k available, 6556k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
    vmalloc : 0xca800000 - 0xf8000000   ( 728 MB)
    lowmem  : 0xc0000000 - 0xca600000   ( 166 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .init : 0xc0008000 - 0xc0037000   ( 188 kB)
      .text : 0xc0037000 - 0xc046a000   (4300 kB)
      .data : 0xc046a000 - 0xc04a6100   ( 241 kB)
SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:407
IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
Total of 128 interrupts on 1 active controller
GPMC revision 6.0
Trying to install interrupt handler for IRQ400
Trying to install interrupt handler for IRQ401
Trying to install interrupt handler for IRQ402
Trying to install interrupt handler for IRQ403
Trying to install interrupt handler for IRQ404
Trying to install interrupt handler for IRQ405
Trying to install interrupt handler for IRQ406
Trying to install type control for IRQ407
Trying to set irq flags for IRQ407
OMAP clockevent source: GPTIMER1 at 27000000 Hz
Console: colour dummy device 80x30
Calibrating delay loop... 986.31 BogoMIPS (lpj=4931584)
pid_max: default: 32768 minimum: 301
Security Framework initialized
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
devtmpfs: initialized
omap_voltage_early_init: voltage driver support not added
regulator: core version 0.5
regulator: dummy:
NET: Registered protocol family 16
omap_voltage_domain_lookup: Voltage driver init not yet happened.Faulting!
omap_voltage_add_dev: VDD specified does not exist!
OMAP GPIO hardware version 0.1
OMAP GPIO hardware version 0.1
configure pinmux for RS485. etc
omap_mux_init: Add partition: #1: core, flags: 0
_omap_mux_get_by_name: Could not find signal i2c2_scl.i2c2_scl
_omap_mux_get_by_name: Could not find signal i2c2_sda.i2c2_sda
registered NOR flash on CS1 (second NOR)
registered ti816x_sram_procfs_bootcount device
dsa:  initialize distributed switch architecture (dsa) marvell (mv)
ethernet switch
dsa:  dsa_on_flag=1
pm_dbg_init: only OMAP3 supported
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
USBSS revision 4ea20809
registerd cppi-dma Intr @ IRQ 17
Cppi41 Init Done
omap_i2c omap_i2c.1: bus 1 rev4.0 at 100 kHz
omap_i2c omap_i2c.2: bus 2 rev4.0 at 100 kHz
i2c i2c-2: Invalid 7-bit I2C address 0x00
i2c i2c-2: Can't create device at 0x00
Switching to clocksource gp timer
musb-hdrc: version 6.0, host, debug=0
musb-hdrc musb-hdrc.0: dma type: dma-cppi41
MUSB controller-0 revision 4ea20800
musb-hdrc musb-hdrc.0: MUSB HDRC host driver
musb-hdrc musb-hdrc.0: new USB bus registered, assigned bus number 1
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: MUSB HDRC host driver
usb usb1: Manufacturer: Linux 2.6.37+ musb-hcd
usb usb1: SerialNumber: musb-hdrc.0
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
musb-hdrc musb-hdrc.0: USB Host mode controller at ca822000 using DMA, IRQ
18
musb-hdrc musb-hdrc.1: dma type: dma-cppi41
MUSB controller-1 revision 4ea20800
musb-hdrc musb-hdrc.1: MUSB HDRC host driver
musb-hdrc musb-hdrc.1: new USB bus registered, assigned bus number 2
usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: MUSB HDRC host driver
usb usb2: Manufacturer: Linux 2.6.37+ musb-hcd
usb usb2: SerialNumber: musb-hdrc.1
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
musb-hdrc musb-hdrc.1: USB Host mode controller at ca826800 using DMA, IRQ
19
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
NetWinder Floating Point Emulator V0.97 (double precision)
omap-iommu omap-iommu.0: ducati registered
omap-iommu omap-iommu.1: sys registered
squashfs: version 4.0 (2009/01/31) Phillip Lougher
JFFS2 version 2.2. (NAND) �© 2001-2006 Red Hat, Inc.
msgmni has been set to 319
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
omap_uart.0: ttyO0 at MMIO 0x48020000 (irq = 72) is a OMAP UART0
omap_uart.1: ttyO1 at MMIO 0x48022000 (irq = 73) is a OMAP UART1
omap_uart.2: ttyO2 at MMIO 0x48024000 (irq = 74) is a OMAP UART2
console [ttyO2] enabled
brd: module loaded
loop: module loaded
physmap platform flash device: 08000000 at 08000000
physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID
0x000001 Chip ID 0x002801
Amd/Fujitsu Extended Query Table at 0x0040
  Amd/Fujitsu Extended Query version 1.5.
Enabling Spansion 65nm mode, writesize = 512 bytes
number of CFI chips: 1
RedBoot partition parsing not available
Using physmap partition information
Creating 8 MTD partitions on "physmap-flash.0":
0x000000000000-0x000000040000 : "u-boot"
0x000000040000-0x000000060000 : "u-boot_env1"
0x000000060000-0x000000080000 : "u-boot_env2"
0x000000080000-0x0000000a0000 : "pad1"
0x0000000a0000-0x0000004a0000 : "kernel_1"
0x0000004a0000-0x0000036a0000 : "rootfs_1"
0x0000036a0000-0x0000068a0000 : "appfs_1"
0x0000068a0000-0x000007b60000 : "overlay_1"
physmap platform flash device: 08000000 at 10000000
physmap-flash.1: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID
0x000001 Chip ID 0x002801
Amd/Fujitsu Extended Query Table at 0x0040
  Amd/Fujitsu Extended Query version 1.5.
Enabling Spansion 65nm mode, writesize = 512 bytes
number of CFI chips: 1
RedBoot partition parsing not available
Using physmap partition information
Creating 8 MTD partitions on "physmap-flash.1":
0x000000000000-0x000000040000 : "u-boot"
0x000000040000-0x000000060000 : "u-boot_env1"
0x000000060000-0x000000080000 : "u-boot_env2"
0x000000080000-0x0000000a0000 : "pad2"
0x0000000a0000-0x0000004a0000 : "kernel_2"
0x0000004a0000-0x0000036a0000 : "rootfs_2"
0x0000036a0000-0x0000068a0000 : "appfs_2"
0x0000068a0000-0x000007b60000 : "overlay_2"
davinci_mdio davinci_mdio.0: davinci mdio revision 1.6
davinci_mdio davinci_mdio.0: detected phy mask fffffffc
davinci_mdio.0: probed
davinci_mdio davinci_mdio.0: phy[0]: device 0:00, driver unknown
davinci_mdio davinci_mdio.0: phy[1]: device 0:01, driver unknown
PPP generic driver version 2.4.2
usbcore: registered new interface driver asix
usbcore: registered new interface driver cdc_ether
usbcore: registered new interface driver dm9601
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
uhci_hcd: USB Universal Host Controller Interface driver
usbcore: registered new interface driver uas
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver ums-alauda
usbcore: registered new interface driver ums-cypress
usbcore: registered new interface driver ums-datafab
usbcore: registered new interface driver ums-freecom
usbcore: registered new interface driver ums-isd200
usbcore: registered new interface driver ums-jumpshot
usbcore: registered new interface driver ums-karma
usbcore: registered new interface driver ums-onetouch
usbcore: registered new interface driver ums-sddr09
usbcore: registered new interface driver ums-sddr55
usbcore: registered new interface driver ums-usbat
mice: PS/2 mouse device common for all mice
usb 1-1: new high speed USB device using musb-hdrc and address 2
rtc-ds1307 1-0068: rtc core: registered ds1337 as rtc0
i2c /dev entries driver
OMAP Watchdog Timer Rev 0x00: initial timeout 60 sec
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
Unable to handle kernel NULL pointer dereference at virtual address 00000002
pgd = c0004000
[00000002] *pgd=00000000
Internal error: Oops: 5 [#1]
last sysfs file:
Modules linked in:
CPU: 0    Not tainted  (2.6.37+ #1)
PC is at strcmp+0xc/0x40
LR is at omap_mbox_get+0x3c/0x1d0
pc : [<c01dfb34>]    lr : [<c0061db8>]    psr: a0000013
sp : ca023f20  ip : ca023f30  fp : ca023f2c
r10: 00000000  r9 : 00000000  r8 : 00000000
r7 : 00000013  r6 : c040ce09  r5 : c04a05d8  r4 : c04815c8
r3 : 00000064  r2 : 00000076  r1 : c040ce09  r0 : 00000002
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387d  Table: 80004019  DAC: 00000017
Process swapper (pid: 1, stack limit = 0xca0222e8)
Stack: (0xca023f20 to 0xca024000)
3f20: ca023f54 ca023f30 c0061db8 c01dfb34 c02ba2ec c01dfb34 00000000
c04a057c
3f40: c04a0578 00000000 ca023f74 ca023f58 c02bde3c c0061d88 00000000
00000000
3f60: c002b480 c00251fc ca023fa4 ca023f78 c0025238 c02bdcb8 ca022000
c002b480
3f80: c00251fc 00000000 00000013 00000000 00000000 00000000 ca023fdc
ca023fa8
3fa0: c00373b8 c0025208 ca023fc4 00000196 c048d6dc c006adfc c002b480
c002b510
3fc0: c006adfc 00000013 00000000 00000000 ca023ff4 ca023fe0 c0008d44
c0037304
3fe0: 00000000 c0008ca4 00000000 ca023ff8 c006adfc c0008cb0 eda485b5
b186e796
Backtrace:
[<c01dfb28>] (strcmp+0x0/0x40) from [<c0061db8>] (omap_mbox_get+0x3c/0x1d0)
[<c0061d7c>] (omap_mbox_get+0x0/0x1d0) from [<c02bde3c>]
(notify_shm_drv_setup+0x190/0x268)
 r6:00000000 r5:c04a0578 r4:c04a057c
[<c02bdcac>] (notify_shm_drv_setup+0x0/0x268) from [<c0025238>]
(notify_init+0x3c/0x2b0)
 r5:c00251fc r4:c002b480
[<c00251fc>] (notify_init+0x0/0x2b0) from [<c00373b8>]
(do_one_initcall+0xc0/0x194)
[<c00372f8>] (do_one_initcall+0x0/0x194) from [<c0008d44>]
(kernel_init+0xa0/0x14c)
 r9:00000000 r8:00000000 r7:00000013 r6:c006adfc r5:c002b510
r4:c002b480
[<c0008ca4>] (kernel_init+0x0/0x14c) from [<c006adfc>] (do_exit+0x0/0x5dc)
 r5:c0008ca4 r4:00000000
Code: e89da800 e1a0c00d e92dd800 e24cb004 (e4d03001)
---[ end trace d65e423459d53e0a ]---
Kernel panic - not syncing: Attempted to kill init!
Backtrace:
[<c0044d10>] (dump_backtrace+0x0/0x110) from [<c03567d8>]
(dump_stack+0x18/0x1c)
 r6:ca022000 r5:0000000b r4:c04a6898 r3:c048329c
[<c03567c0>] (dump_stack+0x0/0x1c) from [<c03569c0>] (panic+0x5c/0x178)
[<c0356964>] (panic+0x0/0x178) from [<c006ae64>] (do_exit+0x68/0x5dc)
 r3:c04848a4 r2:ca023cf8 r1:00000001 r0:c040f24d
 r7:ca020000
[<c006adfc>] (do_exit+0x0/0x5dc) from [<c0045180>] (die+0x2ac/0x2e8)
 r7:00000000
[<c0044ed4>] (die+0x0/0x2e8) from [<c0356838>]
(__do_kernel_fault.part.3+0x5c/0x7c)
[<c03567dc>] (__do_kernel_fault.part.3+0x0/0x7c) from [<c035cf04>]
(do_page_fault+0x1f8/0x214)
 r7:00000000 r3:ca023ed8
[<c035cd0c>] (do_page_fault+0x0/0x214) from [<c035cf44>]
(do_translation_fault+0x24/0xa8)
[<c035cf20>] (do_translation_fault+0x0/0xa8) from [<c00371f4>]
(do_DataAbort+0x3c/0xa0)
 r7:ca023ed8 r6:00000002 r5:c046e560 r4:00000005
[<c00371b8>] (do_DataAbort+0x0/0xa0) from [<c035afec>]
(__dabt_svc+0x4c/0x60)
Exception stack(0xca023ed8 to 0xca023f20)
3ec0:                                                       00000002
c040ce09
3ee0: 00000076 00000064 c04815c8 c04a05d8 c040ce09 00000013 00000000
00000000
3f00: 00000000 ca023f2c ca023f30 ca023f20 c0061db8 c01dfb34 a0000013
ffffffff
 r7:00000013 r6:c040ce09 r5:ca023f0c r4:ffffffff
[<c01dfb28>] (strcmp+0x0/0x40) from [<c0061db8>] (omap_mbox_get+0x3c/0x1d0)
[<c0061d7c>] (omap_mbox_get+0x0/0x1d0) from [<c02bde3c>]
(notify_shm_drv_setup+0x190/0x268)
 r6:00000000 r5:c04a0578 r4:c04a057c
[<c02bdcac>] (notify_shm_drv_setup+0x0/0x268) from [<c0025238>]
(notify_init+0x3c/0x2b0)
 r5:c00251fc r4:c002b480
[<c00251fc>] (notify_init+0x0/0x2b0) from [<c00373b8>]
(do_one_initcall+0xc0/0x194)
[<c00372f8>] (do_one_initcall+0x0/0x194) from [<c0008d44>]
(kernel_init+0xa0/0x14c)
 r9:00000000 r8:00000000 r7:00000013 r6:c006adfc r5:c002b510
r4:c002b480
[<c0008ca4>] (kernel_init+0x0/0x14c) from [<c006adfc>] (do_exit+0x0/0x5dc)
 r5:c0008ca4 r4:00000000


I've read other messages that mailbox (mbox in the trace walk above) could
be a problem but we need to use syslink so I haven't tired turning it off
since that isn't an option.

In thinking of my options, I initially thought I could maybe get by with
continuing to use our u-boot/kernel build with CSL and just use a Cortex A8
based machine with OE Core support (beagleboard or beaglebone) and generate
the rootfs that I need that way since the ABI's should be compatible.  But
with the kernels being so far apart, now I'm thinking that is probably a
bad idea because the new packages are probably using new system calls
(built against new kernel headers) the old kernel doesn't have.  The
core-image-minimal rootfs does come up when I try using a new OE Core
rootfs with my old kernel but I noticed a strange message from udev and
then noticed that it looked like one of my udev rules wasn't working to
mount one of our usb based NAND flashes and I think that is probably
because of the differences in the ABI's I mentioned.

So I really don't know where to go from here.  I can't be stuck with OE
Classic forever.  Our customers are demanding current packages so I need OE
Core.  I guess it is possible to make poky or arago use and old toolchain
to build new OE Core packages so the ABI's all match but I've never tried
to go down that path.  I would also have make the rootfs packages be built
against my old kernel headers and I'm not too sure about how to go about
that either.

Any words of wisdom?

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 38233 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 316 bytes --]

On Fri, Aug 16, 2013 at 8:12 AM, Brian Hutchinson <b.hutchman@gmail.com>wrote:

>  At this point I'm using the toolchains outside of OE (meta-toolchain from
> denzil branch and Linaro 4.8) to make life a bit simpler.



​can you use the the toolchain from OE-Core and see if it happens with that
too ?​

[-- Attachment #2: Type: text/html, Size: 753 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

On Aug 16, 2013 11:37 AM, "Khem Raj" <raj.khem@gmail.com> wrote:
>
>
> On Fri, Aug 16, 2013 at 8:12 AM, Brian Hutchinson <b.hutchman@gmail.com>
wrote:
>>
>>  At this point I'm using the toolchains outside of OE (meta-toolchain
from denzil branch and Linaro 4.8) to make life a bit simpler.
>
>
>
> can you use the the toolchain from OE-Core and see if it happens with
that too ?
>

I've built standalone/external toolchains with poky from both densil and
master branches.  So you want me to try distro-less OE Core toolchain?
Just making sure I'm following you.

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 863 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 15883 bytes --]

On Fri, Aug 16, 2013 at 11:37 AM, Khem Raj <raj.khem@gmail.com> wrote:

>
> On Fri, Aug 16, 2013 at 8:12 AM, Brian Hutchinson <b.hutchman@gmail.com>wrote:
>
>>  At this point I'm using the toolchains outside of OE (meta-toolchain
>> from denzil branch and Linaro 4.8) to make life a bit simpler.
>
>
>
> ​can you use the the toolchain from OE-Core and see if it happens with
> that too ?​
>
>
OK, that kept me busy for a while.  I built core-image-minimal -c
populate_sdk with OE Core + meta-ti and installed that on my application
development machine (bitbake build server is debian 7.1 64bit, app
development machine (behind firewall, slow network connection etc. is
Ubuntu 12.04 LTS 32 bit for running Code Composer etc.)

So after installing oecore-i686-armv7a-vfp-neon-toolchain-oe-core.0.sh (I
know, I went the long way around doing this ... don't ask :) ) I built my
2.6.37 kernel that I patched memset earlier.  Different result this time.
 Looks a bit different.  Boots but dies in the same place but with a
slightly different message (I still see a bunch of mbox stuff in there
hmmm):

## Booting kernel from Legacy Image at 83000000 ...
   Image Name:   Linux-2.6.37+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2348304 Bytes = 2.2 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Linux version 2.6.37+ (hutch@Strider) (gcc version 4.8.1 (GCC) ) #1 Fri Aug
16 16:33:18 EDT 2013
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: ti8168evm
reserved size = 0 at 0x0
Memory policy: ECC disabled, Data cache writeback
OMAP chip is TI8168 2.0
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 42164
Kernel command line: mem=166M console=ttyO2,115200n8 noinitrd
ip=192.168.1.1:192.168.1.5:192.168.1.0:255.255.255.0:255.255.255.1:eth0:off
eth=84:7e:40:d6:a7:5e root=/dev/nfs nfsroot=192.168.1.5:
/home/hutch/ione_wcs_yocto_test/trunk/arm/rootfs
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 166MB = 166MB total
Memory: 163444k/163444k available, 6540k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
    vmalloc : 0xca800000 - 0xf8000000   ( 728 MB)
    lowmem  : 0xc0000000 - 0xca600000   ( 166 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .init : 0xc0008000 - 0xc0037000   ( 188 kB)
      .text : 0xc0037000 - 0xc0466000   (4284 kB)
      .data : 0xc0466000 - 0xc04a20c0   ( 241 kB)
SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:407
IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
Total of 128 interrupts on 1 active controller
GPMC revision 6.0
Trying to install interrupt handler for IRQ400
Trying to install interrupt handler for IRQ401
Trying to install interrupt handler for IRQ402
Trying to install interrupt handler for IRQ403
Trying to install interrupt handler for IRQ404
Trying to install interrupt handler for IRQ405
Trying to install interrupt handler for IRQ406
Trying to install type control for IRQ407
Trying to set irq flags for IRQ407
OMAP clockevent source: GPTIMER1 at 27000000 Hz
Console: colour dummy device 80x30
Calibrating delay loop... 986.31 BogoMIPS (lpj=4931584)
pid_max: default: 32768 minimum: 301
Security Framework initialized
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
devtmpfs: initialized
omap_voltage_early_init: voltage driver support not added
regulator: core version 0.5
regulator: dummy:
NET: Registered protocol family 16
omap_voltage_domain_lookup: Voltage driver init not yet happened.Faulting!
omap_voltage_add_dev: VDD specified does not exist!
OMAP GPIO hardware version 0.1
OMAP GPIO hardware version 0.1
configure pinmux for RS485. etc
omap_mux_init: Add partition: #1: core, flags: 0
_omap_mux_get_by_name: Could not find signal i2c2_scl.i2c2_scl
_omap_mux_get_by_name: Could not find signal i2c2_sda.i2c2_sda
registered NOR flash on CS1 (second NOR)
registered ti816x_sram_procfs_bootcount device
dsa:  initialize distributed switch architecture (dsa) marvell (mv)
ethernet switch
dsa:  dsa_on_flag=1
pm_dbg_init: only OMAP3 supported
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
USBSS revision 4ea20809
registerd cppi-dma Intr @ IRQ 17
Cppi41 Init Done
omap_i2c omap_i2c.1: bus 1 rev4.0 at 100 kHz
omap_i2c omap_i2c.2: bus 2 rev4.0 at 100 kHz
i2c i2c-2: Invalid 7-bit I2C address 0x00
i2c i2c-2: Can't create device at 0x00
Switching to clocksource gp timer
musb-hdrc: version 6.0, host, debug=0
musb-hdrc musb-hdrc.0: dma type: dma-cppi41
MUSB controller-0 revision 4ea20800
musb-hdrc musb-hdrc.0: MUSB HDRC host driver
musb-hdrc musb-hdrc.0: new USB bus registered, assigned bus number 1
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: MUSB HDRC host driver
usb usb1: Manufacturer: Linux 2.6.37+ musb-hcd
usb usb1: SerialNumber: musb-hdrc.0
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
musb-hdrc musb-hdrc.0: USB Host mode controller at ca822000 using DMA, IRQ
18
musb-hdrc musb-hdrc.1: dma type: dma-cppi41
MUSB controller-1 revision 4ea20800
musb-hdrc musb-hdrc.1: MUSB HDRC host driver
musb-hdrc musb-hdrc.1: new USB bus registered, assigned bus number 2
usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: MUSB HDRC host driver
usb usb2: Manufacturer: Linux 2.6.37+ musb-hcd
usb usb2: SerialNumber: musb-hdrc.1
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
musb-hdrc musb-hdrc.1: USB Host mode controller at ca826800 using DMA, IRQ
19
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
NetWinder Floating Point Emulator V0.97 (double precision)
omap-iommu omap-iommu.0: ducati registered
omap-iommu omap-iommu.1: sys registered
squashfs: version 4.0 (2009/01/31) Phillip Lougher
JFFS2 version 2.2. (NAND) �© 2001-2006 Red Hat, Inc.
msgmni has been set to 319
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
omap_uart.0: ttyO0 at MMIO 0x48020000 (irq = 72) is a OMAP UART0
omap_uart.1: ttyO1 at MMIO 0x48022000 (irq = 73) is a OMAP UART1
omap_uart.2: ttyO2 at MMIO 0x48024000 (irq = 74) is a OMAP UART2
console [ttyO2] enabled
brd: module loaded
loop: module loaded
physmap platform flash device: 08000000 at 08000000
physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID
0x000001 Chip ID 0x002801
Amd/Fujitsu Extended Query Table at 0x0040
  Amd/Fujitsu Extended Query version 1.5.
Enabling Spansion 65nm mode, writesize = 512 bytes
number of CFI chips: 1
RedBoot partition parsing not available
Using physmap partition information
Creating 8 MTD partitions on "physmap-flash.0":
0x000000000000-0x000000040000 : "u-boot"
0x000000040000-0x000000060000 : "u-boot_env1"
0x000000060000-0x000000080000 : "u-boot_env2"
0x000000080000-0x0000000a0000 : "pad1"
0x0000000a0000-0x0000004a0000 : "kernel_1"
0x0000004a0000-0x0000036a0000 : "rootfs_1"
0x0000036a0000-0x0000068a0000 : "appfs_1"
0x0000068a0000-0x000007b60000 : "overlay_1"
physmap platform flash device: 08000000 at 10000000
physmap-flash.1: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID
0x000001 Chip ID 0x002801
Amd/Fujitsu Extended Query Table at 0x0040
  Amd/Fujitsu Extended Query version 1.5.
Enabling Spansion 65nm mode, writesize = 512 bytes
number of CFI chips: 1
RedBoot partition parsing not available
Using physmap partition information
Creating 8 MTD partitions on "physmap-flash.1":
0x000000000000-0x000000040000 : "u-boot"
0x000000040000-0x000000060000 : "u-boot_env1"
0x000000060000-0x000000080000 : "u-boot_env2"
0x000000080000-0x0000000a0000 : "pad2"
0x0000000a0000-0x0000004a0000 : "kernel_2"
0x0000004a0000-0x0000036a0000 : "rootfs_2"
0x0000036a0000-0x0000068a0000 : "appfs_2"
0x0000068a0000-0x000007b60000 : "overlay_2"
davinci_mdio davinci_mdio.0: davinci mdio revision 1.6
davinci_mdio davinci_mdio.0: detected phy mask fffffffc
davinci_mdio.0: probed
davinci_mdio davinci_mdio.0: phy[0]: device 0:00, driver unknown
davinci_mdio davinci_mdio.0: phy[1]: device 0:01, driver unknown
PPP generic driver version 2.4.2
usbcore: registered new interface driver asix
usbcore: registered new interface driver cdc_ether
usbcore: registered new interface driver dm9601
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
uhci_hcd: USB Universal Host Controller Interface driver
usbcore: registered new interface driver uas
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver ums-alauda
usbcore: registered new interface driver ums-cypress
usbcore: registered new interface driver ums-datafab
usbcore: registered new interface driver ums-freecom
usbcore: registered new interface driver ums-isd200
usbcore: registered new interface driver ums-jumpshot
usbcore: registered new interface driver ums-karma
usbcore: registered new interface driver ums-onetouch
usbcore: registered new interface driver ums-sddr09
usbcore: registered new interface driver ums-sddr55
usbcore: registered new interface driver ums-usbat
mice: PS/2 mouse device common for all mice
usb 1-1: new high speed USB device using musb-hdrc and address 2
rtc-ds1307 1-0068: rtc core: registered ds1337 as rtc0
i2c /dev entries driver
OMAP Watchdog Timer Rev 0x00: initial timeout 60 sec
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
Unable to handle kernel NULL pointer dereference at virtual address 0000004c
pgd = c0004000
[0000004c] *pgd=00000000
Internal error: Oops: 5 [#1]
last sysfs file:
Modules linked in:
CPU: 0    Not tainted  (2.6.37+ #1)
PC is at strcmp+0x10/0x48
LR is at omap_mbox_get+0x40/0x1cc
pc : [<c01dcd94>]    lr : [<c0061a50>]    psr: a0000013
sp : ca023f10  ip : ca023f20  fp : ca023f1c
r10: ca022018  r9 : 00000000  r8 : c04a20c0
r7 : c049c5c8  r6 : c04a2798  r5 : c0408919  r4 : c047d898
r3 : 00000000  r2 : 00000064  r1 : c0408919  r0 : 0000004c
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387d  Table: 80004019  DAC: 00000017
Process swapper (pid: 1, stack limit = 0xca0222e8)
Stack: (0xca023f10 to 0xca024000)
3f00:                                     ca023f44 ca023f20 c0061a50
c01dcd90
3f20: c02b67c0 c01dcd90 c049c4a0 c049c56c c049c4a0 c0024ec8 ca023f6c
ca023f48
3f40: c02b9fe4 c0061a1c 00000001 00000000 c002b040 c002b040 c04d1f08
c006a954
3f60: ca023f94 ca023f70 c0024f04 c02b9e70 c002b040 c002b0d0 c006a954
c0024ec8
3f80: c04a20c0 00000000 ca023fd4 ca023f98 c00373b8 c0024ed4 00000036
00000000
3fa0: ca023fbc 00000196 c04896cc c002b040 c002b0d0 c006a954 00000013
00000000
3fc0: 00000000 00000000 ca023ff4 ca023fd8 c0008d68 c003730c 00000000
00000000
3fe0: 00000000 c0008cc0 00000000 ca023ff8 c006a954 c0008ccc eda485b5
b186e796
Backtrace:
[<c01dcd84>] (strcmp+0x0/0x48) from [<c0061a50>] (omap_mbox_get+0x40/0x1cc)
[<c0061a10>] (omap_mbox_get+0x0/0x1cc) from [<c02b9fe4>]
(notify_shm_drv_setup+0x180/0x254)
 r7:c0024ec8 r6:c049c4a0 r5:c049c56c r4:c049c4a0
[<c02b9e64>] (notify_shm_drv_setup+0x0/0x254) from [<c0024f04>]
(notify_init+0x3c/0x2a8)
 r6:c006a954 r5:c04d1f08 r4:c002b040
[<c0024ec8>] (notify_init+0x0/0x2a8) from [<c00373b8>]
(do_one_initcall+0xb8/0x180)
 r9:00000000 r8:c04a20c0 r7:c0024ec8 r6:c006a954 r5:c002b0d0
r4:c002b040
[<c0037300>] (do_one_initcall+0x0/0x180) from [<c0008d68>]
(kernel_init+0xa8/0x150)
[<c0008cc0>] (kernel_init+0x0/0x150) from [<c006a954>] (do_exit+0x0/0x5dc)
 r5:c0008cc0 r4:00000000
Code: e1a0c00d e92dd800 e24cb004 e3a03000 (e7d02003)
---[ end trace 599d30e660dbf8fa ]---
Kernel panic - not syncing: Attempted to kill init!
Backtrace:
[<c0044aec>] (dump_backtrace+0x0/0x104) from [<c0351cf0>]
(dump_stack+0x18/0x1c)
 r6:c01dcd96 r5:0000000b r4:c04a2858 r3:ffffffff
[<c0351cd8>] (dump_stack+0x0/0x1c) from [<c0351ee0>] (panic+0x60/0x178)
[<c0351e80>] (panic+0x0/0x178) from [<c006a9c0>] (do_exit+0x6c/0x5dc)
 r3:c0480894 r2:ca020130 r1:00000001 r0:c040ad52
 r7:ca022000
[<c006a954>] (do_exit+0x0/0x5dc) from [<c0044f58>] (die+0x280/0x2bc)
 r7:ca022000
[<c0044cd8>] (die+0x0/0x2bc) from [<c0351d50>]
(__do_kernel_fault.part.4+0x5c/0x7c)
[<c0351cf4>] (__do_kernel_fault.part.4+0x0/0x7c) from [<c035862c>]
(do_page_fault+0x200/0x21c)
 r7:ca020000 r3:ca023ec8
[<c035842c>] (do_page_fault+0x0/0x21c) from [<c035866c>]
(do_translation_fault+0x24/0xa4)
[<c0358648>] (do_translation_fault+0x0/0xa4) from [<c00371f8>]
(do_DataAbort+0x3c/0xa0)
 r7:ca023ec8 r6:0000004c r5:c046a550 r4:00000005
[<c00371bc>] (do_DataAbort+0x0/0xa0) from [<c035672c>]
(__dabt_svc+0x4c/0x60)
Exception stack(0xca023ec8 to 0xca023f10)
3ec0:                   0000004c c0408919 00000064 00000000 c047d898
c0408919
3ee0: c04a2798 c049c5c8 c04a20c0 00000000 ca022018 ca023f1c ca023f20
ca023f10
3f00: c0061a50 c01dcd94 a0000013 ffffffff
 r7:c049c5c8 r6:c04a2798 r5:ca023efc r4:ffffffff
[<c01dcd84>] (strcmp+0x0/0x48) from [<c0061a50>] (omap_mbox_get+0x40/0x1cc)
[<c0061a10>] (omap_mbox_get+0x0/0x1cc) from [<c02b9fe4>]
(notify_shm_drv_setup+0x180/0x254)
 r7:c0024ec8 r6:c049c4a0 r5:c049c56c r4:c049c4a0
[<c02b9e64>] (notify_shm_drv_setup+0x0/0x254) from [<c0024f04>]
(notify_init+0x3c/0x2a8)
 r6:c006a954 r5:c04d1f08 r4:c002b040
[<c0024ec8>] (notify_init+0x0/0x2a8) from [<c00373b8>]
(do_one_initcall+0xb8/0x180)
 r9:00000000 r8:c04a20c0 r7:c0024ec8 r6:c006a954 r5:c002b0d0
r4:c002b040
[<c0037300>] (do_one_initcall+0x0/0x180) from [<c0008d68>]
(kernel_init+0xa8/0x150)
[<c0008cc0>] (kernel_init+0x0/0x150) from [<c006a954>] (do_exit+0x0/0x5dc)
 r5:c0008cc0 r4:00000000

To build the above, I simple sourced the
/usr/local/oecore-i686/environment-setup-armv7a-vfp-neon-oe-linux-gnueabi
script and then unset LDFLAGS.

For kicks, I did a clean build of the kernel again and built with make
EXTRA_CFLAGS=-mno-unaligned-access uImage and that resulted in a hung
kernel:

## Booting kernel from Legacy Image at 83000000 ...
   Image Name:   Linux-2.6.37+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2348876 Bytes = 2.2 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...


Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 20705 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 5943 bytes --]

On Fri, Aug 16, 2013 at 1:58 PM, Brian Hutchinson <b.hutchman@gmail.com>wrote:

> On Fri, Aug 16, 2013 at 11:37 AM, Khem Raj <raj.khem@gmail.com> wrote:
>
>>
>> On Fri, Aug 16, 2013 at 8:12 AM, Brian Hutchinson <b.hutchman@gmail.com>wrote:
>>
>>>  At this point I'm using the toolchains outside of OE (meta-toolchain
>>> from denzil branch and Linaro 4.8) to make life a bit simpler.
>>
>>
>>
>> ​can you use the the toolchain from OE-Core and see if it happens with
>> that too ?​
>>
>>
> OK, that kept me busy for a while.  I built core-image-minimal -c
> populate_sdk with OE Core + meta-ti and installed that on my application
> development machine
>


good. So as I understand now you have a compiler from OE-Core
​​

>
> CPU: 0    Not tainted  (2.6.37+ #1)
> PC is at strcmp+0x10/0x48
> LR is at omap_mbox_get+0x40/0x1cc
> pc : [<c01dcd94>]    lr : [<c0061a50>]    psr: a0000013
> sp : ca023f10  ip : ca023f20  fp : ca023f1c
> r10: ca022018  r9 : 00000000  r8 : c04a20c0
> r7 : c049c5c8  r6 : c04a2798  r5 : c0408919  r4 : c047d898
> r3 : 00000000  r2 : 00000064  r1 : c0408919  r0 : 0000004c
> Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> Control: 10c5387d  Table: 80004019  DAC: 00000017
> Process swapper (pid: 1, stack limit = 0xca0222e8)
> Stack: (0xca023f10 to 0xca024000)
> 3f00:                                     ca023f44 ca023f20 c0061a50
> c01dcd90
> 3f20: c02b67c0 c01dcd90 c049c4a0 c049c56c c049c4a0 c0024ec8 ca023f6c
> ca023f48
> 3f40: c02b9fe4 c0061a1c 00000001 00000000 c002b040 c002b040 c04d1f08
> c006a954
> 3f60: ca023f94 ca023f70 c0024f04 c02b9e70 c002b040 c002b0d0 c006a954
> c0024ec8
> 3f80: c04a20c0 00000000 ca023fd4 ca023f98 c00373b8 c0024ed4 00000036
> 00000000
> 3fa0: ca023fbc 00000196 c04896cc c002b040 c002b0d0 c006a954 00000013
> 00000000
> 3fc0: 00000000 00000000 ca023ff4 ca023fd8 c0008d68 c003730c 00000000
> 00000000
> 3fe0: 00000000 c0008cc0 00000000 ca023ff8 c006a954 c0008ccc eda485b5
> b186e796
> Backtrace:
> [<c01dcd84>] (strcmp+0x0/0x48) from [<c0061a50>] (omap_mbox_get+0x40/0x1cc)
> [<c0061a10>] (omap_mbox_get+0x0/0x1cc) from [<c02b9fe4>]
> (notify_shm_drv_setup+0x180/0x254)
>  r7:c0024ec8 r6:c049c4a0 r5:c049c56c r4:c049c4a0
> [<c02b9e64>] (notify_shm_drv_setup+0x0/0x254) from [<c0024f04>]
> (notify_init+0x3c/0x2a8)
>  r6:c006a954 r5:c04d1f08 r4:c002b040
> [<c0024ec8>] (notify_init+0x0/0x2a8) from [<c00373b8>]
> (do_one_initcall+0xb8/0x180)
>  r9:00000000 r8:c04a20c0 r7:c0024ec8 r6:c006a954 r5:c002b0d0
> r4:c002b040
> [<c0037300>] (do_one_initcall+0x0/0x180) from [<c0008d68>]
> (kernel_init+0xa8/0x150)
> [<c0008cc0>] (kernel_init+0x0/0x150) from [<c006a954>] (do_exit+0x0/0x5dc)
>  r5:c0008cc0 r4:00000000
> Code: e1a0c00d e92dd800 e24cb004 e3a03000 (e7d02003)
> ---[ end trace 599d30e660dbf8fa ]---
> Kernel panic - not syncing: Attempted to kill init!
> Backtrace:
> [<c0044aec>] (dump_backtrace+0x0/0x104) from [<c0351cf0>]
> (dump_stack+0x18/0x1c)
>  r6:c01dcd96 r5:0000000b r4:c04a2858 r3:ffffffff
> [<c0351cd8>] (dump_stack+0x0/0x1c) from [<c0351ee0>] (panic+0x60/0x178)
> [<c0351e80>] (panic+0x0/0x178) from [<c006a9c0>] (do_exit+0x6c/0x5dc)
>  r3:c0480894 r2:ca020130 r1:00000001 r0:c040ad52
>  r7:ca022000
> [<c006a954>] (do_exit+0x0/0x5dc) from [<c0044f58>] (die+0x280/0x2bc)
>  r7:ca022000
> [<c0044cd8>] (die+0x0/0x2bc) from [<c0351d50>]
> (__do_kernel_fault.part.4+0x5c/0x7c)
> [<c0351cf4>] (__do_kernel_fault.part.4+0x0/0x7c) from [<c035862c>]
> (do_page_fault+0x200/0x21c)
>  r7:ca020000 r3:ca023ec8
> [<c035842c>] (do_page_fault+0x0/0x21c) from [<c035866c>]
> (do_translation_fault+0x24/0xa4)
> [<c0358648>] (do_translation_fault+0x0/0xa4) from [<c00371f8>]
> (do_DataAbort+0x3c/0xa0)
>  r7:ca023ec8 r6:0000004c r5:c046a550 r4:00000005
> [<c00371bc>] (do_DataAbort+0x0/0xa0) from [<c035672c>]
> (__dabt_svc+0x4c/0x60)
> Exception stack(0xca023ec8 to 0xca023f10)
> 3ec0:                   0000004c c0408919 00000064 00000000 c047d898
> c0408919
> 3ee0: c04a2798 c049c5c8 c04a20c0 00000000 ca022018 ca023f1c ca023f20
> ca023f10
> 3f00: c0061a50 c01dcd94 a0000013 ffffffff
>  r7:c049c5c8 r6:c04a2798 r5:ca023efc r4:ffffffff
> [<c01dcd84>] (strcmp+0x0/0x48) from [<c0061a50>] (omap_mbox_get+0x40/0x1cc)
> [<c0061a10>] (omap_mbox_get+0x0/0x1cc) from [<c02b9fe4>]
> (notify_shm_drv_setup+0x180/0x254)
>  r7:c0024ec8 r6:c049c4a0 r5:c049c56c r4:c049c4a0
> [<c02b9e64>] (notify_shm_drv_setup+0x0/0x254) from [<c0024f04>]
> (notify_init+0x3c/0x2a8)
>  r6:c006a954 r5:c04d1f08 r4:c002b040
> [<c0024ec8>] (notify_init+0x0/0x2a8) from [<c00373b8>]
> (do_one_initcall+0xb8/0x180)
>  r9:00000000 r8:c04a20c0 r7:c0024ec8 r6:c006a954 r5:c002b0d0
> r4:c002b040
> [<c0037300>] (do_one_initcall+0x0/0x180) from [<c0008d68>]
> (kernel_init+0xa8/0x150)
> [<c0008cc0>] (kernel_init+0x0/0x150) from [<c006a954>] (do_exit+0x0/0x5dc)
>  r5:c0008cc0 r4:00000000
>

​This needs to be debugged. Since 3.x kernels works fine with gcc 4.8.x, I
would assume its something that got fixed in kernel along the way. You have
to hunt
I dont have neither the platform nor another device where I use 2.6.37 so
cant help much with hunt




>
> To build the above, I simple sourced the
> /usr/local/oecore-i686/environment-setup-armv7a-vfp-neon-oe-linux-gnueabi
> script and then unset LDFLAGS.
>
> For kicks, I did a clean build of the kernel again and built with make
> EXTRA_CFLAGS=-mno-unaligned-access uImage and that resulted in a hung
> kernel:
>
> ## Booting kernel from Legacy Image at 83000000 ...
>    Image Name:   Linux-2.6.37+
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    2348876 Bytes = 2.2 MiB
>    Load Address: 80008000
>    Entry Point:  80008000
>    Verifying Checksum ... OK
>    Loading Kernel Image ... OK
> OK
>
> Starting kernel ...
>
>
> Regards,
>
> Brian
>

[-- Attachment #2: Type: text/html, Size: 9528 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 134 bytes --]

... This is smelling like my problem now:
http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/252033/885847.aspx

[-- Attachment #2: Type: text/html, Size: 325 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 421 bytes --]

I can confirm that the Kevin Hilman mailbox patch that I posted the URL to
on the e2e site fixes the mbox problem and my 2.6.37 kernel built with the
OE Core toolchain (gcc 4.8) does in fact boot now!  I have a login prompt!

So to recap.  Sakoman head.S patch, the two memset patches Khem mentioned,
and this Hilman mailbox patch is what I applied.

Thank you guys for putting up with me :)

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 535 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Maupin, Chase]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

Brian,

Great news.  Do you want to post a patch to the kernel recipe to pull those in?

From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti-bounces@yoctoproject.org] On Behalf Of Brian Hutchinson
Sent: Friday, August 16, 2013 4:40 PM
To: meta-ti@yoctoproject.org
Subject: Re: [meta-ti] Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

I can confirm that the Kevin Hilman mailbox patch that I posted the URL to on the e2e site fixes the mbox problem and my 2.6.37 kernel built with the OE Core toolchain (gcc 4.8) does in fact boot now!  I have a login prompt!

So to recap.  Sakoman head.S patch, the two memset patches Khem mentioned, and this Hilman mailbox patch is what I applied.

Thank you guys for putting up with me :)

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 4096 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 368 bytes --]

... and I get a similar udev message that started me down this road in the
first place but at least this time it is a little more helpful.  Looks like
I need to run down inotify support now:

Starting udev
<30>udevd[81]: starting version 182
udevd[81]: inotify_init failed: Function not implemented

udevd[81]: error initializing inotify

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 564 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

On Fri, Aug 16, 2013 at 2:46 PM, Brian Hutchinson <b.hutchman@gmail.com>wrote:

> ... and I get a similar udev message that started me down this road in the
> first place but at least this time it is a little more helpful.  Looks like
> I need to run down inotify support now:
>
> Starting udev
> <30>udevd[81]: starting version 182
> udevd[81]: inotify_init failed: Function not implemented
>
> udevd[81]: error initializing inotify
>
>
​use linux-libc-headers from 2.6.37 as well and not the 3.8 or whatever is
default on OE-Core branch that you are using.​




> Regards,
>
> Brian
>
>
>
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti
>
>

[-- Attachment #2: Type: text/html, Size: 1783 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 3748 bytes --]

On Fri, Aug 16, 2013 at 5:59 PM, Khem Raj <raj.khem@gmail.com> wrote:

>
> use linux-libc-headers from 2.6.37 as well and not the 3.8 or whatever is
> default on OE-Core branch that you are using.
>

OK, I'm in a little new territory here.  I've been attempting to add
machine support to my oe_core + meta-ti master checkout.  I've setup the
machine conf for c6a816x-evm and all the associated files using denzil as a
base.  I modified the 2.6.37 recipe to use my custom boards kernel instead
of the one from git (set SRC_URI to my .tar.bz2).  I stubbed out u-boot for
now as it was giving me problems.

First question.  I looked at my poky/meta/recipes-kernel/linux-libc-headers
dir of a denzil checkout that last had c6a816x-evm support to use as kind
of an example/guide.  I see recipes for linux-libc-headers_3.2.bb and
linux-libc-headers_3.0.8.bb.  Do I need to create a recipe for 2.6.37 and
set the SRC_URI for a 2.6.37 commit so that my rootfs packages will be
built against headers that match the version of the kernel I'm using?  It
looked like linux-libc-headers.inc has some kind of check to decide on
which headers to use (3 or 2.6) but I don't quite follow how it works yet.

Second question.  When I try to bitbake core-image-minimal after adding in
my kernel (a tar.bz2), it builds but the do_package phase gets errors:

Build Configuration:
BB_VERSION        = "1.19.1"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "Debian-7.1"
TARGET_SYS        = "arm-oe-linux-gnueabi"
MACHINE           = "c6a816x-evm"
DISTRO_VERSION    = "oe-core.0"
TUNE_FEATURES     = "armv7a vfp neon"
TARGET_FPU        = "vfp-neon"
meta              = "master:b8952942aed77473d3b44a17112cbf6a9e83eff3"
meta-ti           = "master:ed417f659a24499301eb8e40de06e281462f213a"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: objcopy failed with exit code 256 (cmd was
'arm-oe-linux-gnueabi-objcopy' --only-keep-debug
'/home/hutch/oe_core_beagleboard/oe-core/build/tmp-eglibc/work/c6a816x_evm-oe-linux-gnueabi/linux-ti81xx-psp/2.6.37-r0/package/usr/src/kernel/image/usr/src/kernel/scripts/mod/mk_elfconfig'
'/home/hutch/oe_core_beagleboard/oe-core/build/tmp-eglibc/work/c6a816x_evm-oe-linux-gnueabi/linux-ti81xx-psp/2.6.37-r0/package/usr/src/kernel/image/usr/src/kernel/scripts/mod/.debug/mk_elfconfig'):
arm-oe-linux-gnueabi-objcopy:/home/hutch/oe_core_beagleboard/oe-core/build/tmp-eglibc/work/c6a816x_evm-oe-linux-gnueabi/linux-ti81xx-psp/2.6.37-r0/package/usr/src/kernel/image/usr/src/kernel/scripts/mod/mk_elfconfig:
File format not recognized
ERROR: Function failed: split_and_strip_files
ERROR: Logfile of failure stored in:
/home/hutch/oe_core_beagleboard/oe-core/build/tmp-eglibc/work/c6a816x_evm-oe-linux-gnueabi/linux-ti81xx-psp/2.6.37-r0/temp/log.do_package.25280
ERROR: Task 631
(/home/hutch/oe_core_beagleboard/oe-core/meta-ti/recipes-kernel/linux/
linux-ti81xx-psp_2.6.37.bb, do_package) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1541 tasks of which 1528 didn't need to be
rerun and 1 failed.
Waiting for 0 running tasks to finish:

Summary: 1 task failed:
  /home/hutch/oe_core_beagleboard/oe-core/meta-ti/recipes-kernel/linux/
linux-ti81xx-psp_2.6.37.bb, do_package
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

I did some searches of this kind of error and mostly found noise but also
found some references to  INHIBIT_PACKAGE_STRIP but I'm not sure if that
will fix this problem or not.

So far my deploy dir has a uImage but not the rootfs tar or images. I hope
fixing the above will get me there.

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 5326 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]


> First question.  I looked at my poky/meta/recipes-kernel/linux-libc-headers dir of a denzil checkout that last had c6a816x-evm support to use as kind of an example/guide.  I see recipes for linux-libc-headers_3.2.bb and linux-libc-headers_3.0.8.bb.  Do I need to create a recipe for 2.6.37 and set the SRC_URI for a 2.6.37 commit so that my rootfs packages will be built against headers that match the version of the kernel I'm using?  It looked like linux-libc-headers.inc has some kind of check to decide on which headers to use (3 or 2.6) but I don't quite follow how it works yet.

yes you need to add a recipe for linux-libc-headers_2.6.37….
and also make sure that your distro/machine chooses this for preferred provider for linux-libc-headers

> 
> Second question.  When I try to bitbake core-image-minimal after adding in my kernel (a tar.bz2), it builds but the do_package phase gets errors:

> arm-oe-linux-gnueabi-objcopy:/home/hutch/oe_core_beagleboard/oe-core/build/tmp-eglibc/work/c6a816x_evm-oe-linux-gnueabi/linux-ti81xx-psp/2.6.37-r0/package/usr/src/kernel/image/usr/src/kernel/scripts/mod/mk_elfconfig: File format not recognized

what is that file ? can you run it through file cmd and find out what arch its targeted for ? if its a host tool then remove it from install location


[-- Attachment #2: Type: text/html, Size: 1974 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 1378 bytes --]

On Wed, Aug 21, 2013 at 12:11 AM, Khem Raj <raj.khem@gmail.com> wrote:

>
> Second question.  When I try to bitbake core-image-minimal after adding in
> my kernel (a tar.bz2), it builds but the do_package phase gets errors:
>
>
> arm-oe-linux-gnueabi-objcopy:/home/hutch/oe_core_beagleboard/oe-core/build/tmp-eglibc/work/c6a816x_evm-oe-linux-gnueabi/linux-ti81xx-psp/2.6.37-r0/package/usr/src/kernel/image/usr/src/kernel/scripts/mod/mk_elfconfig:
> File format not recognized
>
>
> what is that file ? can you run it through file cmd and find out what arch
> its targeted for ? if its a host tool then remove it from install location
>
>
I don't know.  I think I'm suffering from this:
https://lists.yoctoproject.org/pipermail/yocto/2012-July/010145.html

... but the commit id doesn't get me anywhere when I try to see what the
fix is.  Looks like when I tared up my kernel the make clean, make
distclean didn't smoke all the bin files in scripts or something and my
bitbake build machine is 64 bit while the machine I originally built the
kernel on is 64 bit but but running 32 bit Ubuntu.  I added the
INHIBIT_PACKAGE_STRIP
= "1" to my .conf and that got me a bit further but then QA gave me a list
of all the things it didn't like so now I'm finding where all of those show
up and deleting them so hopefully that will fix it.

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 2501 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Denys Dmytriyenko]

On Tue, Aug 20, 2013 at 09:11:57PM -0700, Khem Raj wrote:
> 
> > First question.  I looked at my 
> > poky/meta/recipes-kernel/linux-libc-headers dir of a denzil checkout that 
> > last had c6a816x-evm support to use as kind of an example/guide.  I see 
> > recipes for linux-libc-headers_3.2.bb and linux-libc-headers_3.0.8.bb.  Do 
> > I need to create a recipe for 2.6.37 and set the SRC_URI for a 2.6.37 
> > commit so that my rootfs packages will be built against headers that match 
> > the version of the kernel I'm using?  It looked like 
> > linux-libc-headers.inc has some kind of check to decide on which headers 
> > to use (3 or 2.6) but I don't quite follow how it works yet.
> 
> yes you need to add a recipe for linux-libc-headers_2.6.37…. and also make 
> sure that your distro/machine chooses this for preferred provider for 
> linux-libc-headers

Well, if you use Dylan (or even Danny), it has a recipe already available in 
oe-core...


> > Second question.  When I try to bitbake core-image-minimal after adding in 
> > my kernel (a tar.bz2), it builds but the do_package phase gets errors:
> 
> > arm-oe-linux-gnueabi-objcopy:/home/hutch/oe_core_beagleboard/oe-core/build/tmp-eglibc/work/c6a816x_evm-oe-linux-gnueabi/linux-ti81xx-psp/2.6.37-r0/package/usr/src/kernel/image/usr/src/kernel/scripts/mod/mk_elfconfig: 
> > File format not recognized
> 
> what is that file ? can you run it through file cmd and find out what arch 
> its targeted for ? if its a host tool then remove it from install location

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]

On Wed, Aug 21, 2013 at 10:46 PM, Denys Dmytriyenko <denys@ti.com> wrote:

>
>
> Well, if you use Dylan (or even Danny), it has a recipe already available
> in
> oe-core...
>
>
Yes, I found this one that Khem added checksums to and used web git to
cherry pick it out:
http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_2.6.37.2.bb?h=dylan&id=370e082c8bbf14c9b0f54269eb99d291d187cd40

Regards,

Brian

p.s.  Killing all those binaries the QA caught fixed my do_package problem
yesterday.

[-- Attachment #2: Type: text/html, Size: 1291 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Denys Dmytriyenko]

On Thu, Aug 22, 2013 at 11:23:55AM -0400, Brian Hutchinson wrote:
> On Wed, Aug 21, 2013 at 10:46 PM, Denys Dmytriyenko <denys@ti.com> wrote:
> 
> >
> >
> > Well, if you use Dylan (or even Danny), it has a recipe already available
> > in
> > oe-core...
> >
> >
> Yes, I found this one that Khem added checksums to and used web git to
> cherry pick it out:
> http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_2.6.37.2.bb?h=dylan&id=370e082c8bbf14c9b0f54269eb99d291d187cd40

Good, I'll just keep nagging you to abandon Denzil and switch to at least 
Dylan - it's absolutely trivial to restore the machine configs that used to be 
in Denzil - I already gave you the exact command... :)

-- 
Denys

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

On Thu, Aug 22, 2013 at 11:38 AM, Denys Dmytriyenko <denys@ti.com> wrote:

>
> Good, I'll just keep nagging you to abandon Denzil and switch to at least
> Dylan - it's absolutely trivial to restore the machine configs that used
> to be
> in Denzil - I already gave you the exact command... :)
>
> I know, I'm doing it the hard way.  And I appreciate the command (and will
do it eventually) but I'm not a git expert so I'm trying to pick up what
you're laying down :)  I'm trying to understand the mechanics before I get
fancy.

B

[-- Attachment #2: Type: text/html, Size: 981 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]

On Thu, Aug 22, 2013 at 11:23 AM, Brian Hutchinson <b.hutchman@gmail.com>wrote:

> On Wed, Aug 21, 2013 at 10:46 PM, Denys Dmytriyenko <denys@ti.com> wrote:
>
>>
>>
>> Well, if you use Dylan (or even Danny), it has a recipe already available
>> in
>> oe-core...
>>
>>
> Yes, I found this one that Khem added checksums to and used web git to
> cherry pick it out:
>
> http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_2.6.37.2.bb?h=dylan&id=370e082c8bbf14c9b0f54269eb99d291d187cd40
>
>
>
OK, I don't know if I did this right or not but now I have a
linux-libc-headers_2.6.37.2.bb (from the web git link I mentioned before)
file in my meta/recipes-kernel/linux-libc-headers directory.  In my
local.conf I added LINUX_LIBC_HEADERS_VERSION = "2.6.37.2" but when I
bitbake core-image-minimal it doesn't look like it is rebuilding everything
with the headers I specified.  If I look
in build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/linux-libc-headers
all I see is 3.8-r0 so it doesn't look like it grabbed the 2.6.37 headers.

Did I go about this the wrong way?  I tried a bitbake -c cleanall
core-image-minimal and that didn't appear to kick it in the pants and make
it build everything over again with the new headers.

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 2530 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Denys Dmytriyenko]

On Thu, Aug 22, 2013 at 02:41:17PM -0400, Brian Hutchinson wrote:
> On Thu, Aug 22, 2013 at 11:23 AM, Brian Hutchinson <b.hutchman@gmail.com>wrote:
> 
> > On Wed, Aug 21, 2013 at 10:46 PM, Denys Dmytriyenko <denys@ti.com> wrote:
> >
> >>
> >>
> >> Well, if you use Dylan (or even Danny), it has a recipe already available
> >> in
> >> oe-core...
> >>
> >>
> > Yes, I found this one that Khem added checksums to and used web git to
> > cherry pick it out:
> >
> > http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_2.6.37.2.bb?h=dylan&id=370e082c8bbf14c9b0f54269eb99d291d187cd40
> >
> >
> >
> OK, I don't know if I did this right or not but now I have a
> linux-libc-headers_2.6.37.2.bb (from the web git link I mentioned before)
> file in my meta/recipes-kernel/linux-libc-headers directory.  In my
> local.conf I added LINUX_LIBC_HEADERS_VERSION = "2.6.37.2" but when I

You need something like this:

http://arago-project.org/git/?p=meta-arago.git;a=commitdiff;h=61162abba3aa56057dfdfa8ae3a93c281aa2342a

There's no standard variable LINUX_LIBC_HEADERS_VERSION for that, AFAIK.

-- 
Denys


> bitbake core-image-minimal it doesn't look like it is rebuilding everything
> with the headers I specified.  If I look
> in build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/linux-libc-headers
> all I see is 3.8-r0 so it doesn't look like it grabbed the 2.6.37 headers.
> 
> Did I go about this the wrong way?  I tried a bitbake -c cleanall
> core-image-minimal and that didn't appear to kick it in the pants and make
> it build everything over again with the new headers.
> 
> Regards,
> 
> Brian

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]

On Thu, Aug 22, 2013 at 2:54 PM, Denys Dmytriyenko <denys@ti.com> wrote:

>
> > OK, I don't know if I did this right or not but now I have a
> > linux-libc-headers_2.6.37.2.bb (from the web git link I mentioned
> before)
> > file in my meta/recipes-kernel/linux-libc-headers directory.  In my
> > local.conf I added LINUX_LIBC_HEADERS_VERSION = "2.6.37.2" but when I
>
> You need something like this:
>
>
> http://arago-project.org/git/?p=meta-arago.git;a=commitdiff;h=61162abba3aa56057dfdfa8ae3a93c281aa2342a
>
> There's no standard variable LINUX_LIBC_HEADERS_VERSION for that, AFAIK.
>
>
Ah, thanks for the heads up.  I looked at my arago checkout and my
arago-prefs.inc didn't look like that but I see you just did that a few
days ago so I'll do a git pull and update my tree and study that to figure
out how it works.

So for my particular case, I'm guessing I need to do something similar
in oe-core/meta/conf/distro/include/default-providers.inc
& default-versions.inc?

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 1825 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 960 bytes --]

On Thu, Aug 22, 2013 at 3:35 PM, Brian Hutchinson <b.hutchman@gmail.com>wrote:

>
>>
>> You need something like this:
>>
>>
>> http://arago-project.org/git/?p=meta-arago.git;a=commitdiff;h=61162abba3aa56057dfdfa8ae3a93c281aa2342a
>>
>> There's no standard variable LINUX_LIBC_HEADERS_VERSION for that, AFAIK.
>>
>>
> Ah, thanks for the heads up.  I looked at my arago checkout and my
> arago-prefs.inc didn't look like that but I see you just did that a few
> days ago so I'll do a git pull and update my tree and study that to figure
> out how it works.
>
> So for my particular case, I'm guessing I need to do something similar
> in oe-core/meta/conf/distro/include/default-providers.inc
> & default-versions.inc?
>
> Regards,
>
> Brian
>
>
I see said the blind man!  I put PREFERRED_VERSION_linux-libc-headers ?=
"2.6.37.2"  in my default-versions.inc file and I see some action going on
now! :)

Thanks!

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 1990 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

On Fri, Aug 16, 2013 at 2:39 PM, Brian Hutchinson <b.hutchman@gmail.com>wrote:

> I can confirm that the Kevin Hilman mailbox patch that I posted the URL to
> on the e2e site fixes the mbox problem and my 2.6.37 kernel built with the
> OE Core toolchain (gcc 4.8) does in fact boot now!  I have a login prompt!
>
>
​good.​



> So to recap.  Sakoman head.S patch, the two memset patches Khem mentioned,
> and this Hilman mailbox patch is what I applied.
>
> Thank you guys for putting up with me :)
>

​you should post patches to meta-ti​

[-- Attachment #2: Type: text/html, Size: 1359 bytes --]

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Denys Dmytriyenko]

On Fri, Aug 16, 2013 at 05:39:49PM -0400, Brian Hutchinson wrote:
> I can confirm that the Kevin Hilman mailbox patch that I posted the URL to
> on the e2e site fixes the mbox problem and my 2.6.37 kernel built with the
> OE Core toolchain (gcc 4.8) does in fact boot now!  I have a login prompt!

BTW, didn't I tell you to look for a possible fix in one of those TI81x repos 
on arago-project.org? :) It was right there, the third from the top!

http://arago-project.org/git/projects/?p=linux-dvr-rdk-dm81xx.git;a=commitdiff;h=b5c066e7c670e830c322693b2c9da65508c189b2


> So to recap.  Sakoman head.S patch, the two memset patches Khem mentioned,
> and this Hilman mailbox patch is what I applied.
> 
> Thank you guys for putting up with me :)

Congratulations, you persistence has paid off! :)

Looking forward to seeing patches from you, along with taking maintainership 
of TI81x platform in meta-ti... :)

-- 
Denys

Re: Stumped. Can't get 2.6.37 TI kernel to boot when built with toolchain from denzil or Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/

[Brian Hutchinson]

[-- Attachment #1: Type: text/plain, Size: 741 bytes --]

On Aug 17, 2013 5:45 PM, "Denys Dmytriyenko" <denys@ti.com> wrote:
>

> BTW, didn't I tell you to look for a possible fix in one of those TI81x
repos
> on arago-project.org? :) It was right there, the third from the top!
>
>
http://arago-project.org/git/projects/?p=linux-dvr-rdk-dm81xx.git;a=commitdiff;h=b5c066e7c670e830c322693b2c9da65508c189b2

To be honest, I did look at those and did a search for 81x and scanned the
results and didn't see it :-(
>

> Congratulations, you persistence has paid off! :)
>
> Looking forward to seeing patches from you, along with taking
maintainership
> of TI81x platform in meta-ti... :)

Yea, that's what I'm afraid of.  I'll have no problem doing it in my
copious spare time ;-)

[-- Attachment #2: Type: text/html, Size: 1136 bytes --]