regression tests for am3517-evm machine?

regression tests for am3517-evm machine?

[Troy Benjegerdes]

Are there any regression tests and/or recent builds of a 3.1x or 4.x series
kernel on an am3517 eval board? The original 'supported' TI SDKs were all
of the 2.6.x series, and it seems like somewhere along the way something
broke, and I'm trying to figure out what it was.

-- 
----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  hozer@hozed.org
7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop

      Never pick a fight with someone who buys ink by the barrel,
         nor try buy a hacker who makes money by the megahash

Re: regression tests for am3517-evm machine?

[Denys Dmytriyenko]

On Sat, Jan 16, 2016 at 12:36:31AM -0600, Troy Benjegerdes wrote:
> Are there any regression tests and/or recent builds of a 3.1x or 4.x series
> kernel on an am3517 eval board? The original 'supported' TI SDKs were all
> of the 2.6.x series, and it seems like somewhere along the way something
> broke, and I'm trying to figure out what it was.

Do you have any specifics for the breakage?

-- 
Denys

Re: regression tests for am3517-evm machine?

[Troy Benjegerdes]

On Mon, Jan 18, 2016 at 11:46:15AM -0500, Denys Dmytriyenko wrote:
> On Sat, Jan 16, 2016 at 12:36:31AM -0600, Troy Benjegerdes wrote:
> > Are there any regression tests and/or recent builds of a 3.1x or 4.x series
> > kernel on an am3517 eval board? The original 'supported' TI SDKs were all
> > of the 2.6.x series, and it seems like somewhere along the way something
> > broke, and I'm trying to figure out what it was.
> 
> Do you have any specifics for the breakage?
> 
> -- 
> Denys

The kernel stops after discovering the MMC, but before mounting the 
filesystem:

[    2.446441] Key type dns_resolver registered
[    2.461151] voltdm_scale: No voltage scale API registered for vdd_mpu_iva
[    2.468444] voltdm_scale: No voltage scale API registered for vdd_core
[    2.479156] PM: no software I/O chain control; some wakeups may be lost
[    2.486816] ThumbEE CPU extension supported.
[    2.491363] Registering SWP/SWPB emulation handler
[    2.503784] regulator-dummy: incomplete constraints, leaving on
[    2.516876] davinci_emac davinci_emac.0: using random MAC addr: 9e:53:0c:1a:23:3
[    2.622650] Waiting for root device /dev/mmcblk0p2...
[    2.629638] mmc0: new high speed SDHC card at address aaaa
[    2.641143] mmcblk0: mmc0:aaaa SU04G 3.69 GiB 


Also, is there a bitbake target that makes an image I can write to an SD
card? I got myself all confused trying to convert an SD image for a beaglebone
and apparently replacing MLO was not sufficient.

-- 
----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  hozer@hozed.org
7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop
      Never pick a fight with someone who buys ink by the barrel,
         nor try buy a hacker who makes money by the megahash

Re: regression tests for am3517-evm machine?

[Troy Benjegerdes]

Any suggestions on what branches and/or targets I should be using
that might work better?

On Mon, Jan 18, 2016 at 02:05:07PM -0600, Troy Benjegerdes wrote:
> On Mon, Jan 18, 2016 at 11:46:15AM -0500, Denys Dmytriyenko wrote:
> > On Sat, Jan 16, 2016 at 12:36:31AM -0600, Troy Benjegerdes wrote:
> > > Are there any regression tests and/or recent builds of a 3.1x or 4.x series
> > > kernel on an am3517 eval board? The original 'supported' TI SDKs were all
> > > of the 2.6.x series, and it seems like somewhere along the way something
> > > broke, and I'm trying to figure out what it was.
> > 
> > Do you have any specifics for the breakage?
> > 
> > -- 
> > Denys
> 
> The kernel stops after discovering the MMC, but before mounting the 
> filesystem:
> 
> [    2.446441] Key type dns_resolver registered
> [    2.461151] voltdm_scale: No voltage scale API registered for vdd_mpu_iva
> [    2.468444] voltdm_scale: No voltage scale API registered for vdd_core
> [    2.479156] PM: no software I/O chain control; some wakeups may be lost
> [    2.486816] ThumbEE CPU extension supported.
> [    2.491363] Registering SWP/SWPB emulation handler
> [    2.503784] regulator-dummy: incomplete constraints, leaving on
> [    2.516876] davinci_emac davinci_emac.0: using random MAC addr: 9e:53:0c:1a:23:3
> [    2.622650] Waiting for root device /dev/mmcblk0p2...
> [    2.629638] mmc0: new high speed SDHC card at address aaaa
> [    2.641143] mmcblk0: mmc0:aaaa SU04G 3.69 GiB 
> 
> 
> Also, is there a bitbake target that makes an image I can write to an SD
> card? I got myself all confused trying to convert an SD image for a beaglebone
> and apparently replacing MLO was not sufficient.
> 

-- 
----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  hozer@hozed.org
7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop

      Never pick a fight with someone who buys ink by the barrel,
         nor try buy a hacker who makes money by the megahash

Re: regression tests for am3517-evm machine?

[Denys Dmytriyenko]

On Mon, Jan 18, 2016 at 02:05:07PM -0600, Troy Benjegerdes wrote:
> On Mon, Jan 18, 2016 at 11:46:15AM -0500, Denys Dmytriyenko wrote:
> > On Sat, Jan 16, 2016 at 12:36:31AM -0600, Troy Benjegerdes wrote:
> > > Are there any regression tests and/or recent builds of a 3.1x or 4.x series
> > > kernel on an am3517 eval board? The original 'supported' TI SDKs were all
> > > of the 2.6.x series, and it seems like somewhere along the way something
> > > broke, and I'm trying to figure out what it was.
> > 
> > Do you have any specifics for the breakage?
> > 
> > -- 
> > Denys
> 
> The kernel stops after discovering the MMC, but before mounting the 
> filesystem:
> 
> [    2.446441] Key type dns_resolver registered
> [    2.461151] voltdm_scale: No voltage scale API registered for vdd_mpu_iva
> [    2.468444] voltdm_scale: No voltage scale API registered for vdd_core
> [    2.479156] PM: no software I/O chain control; some wakeups may be lost
> [    2.486816] ThumbEE CPU extension supported.
> [    2.491363] Registering SWP/SWPB emulation handler
> [    2.503784] regulator-dummy: incomplete constraints, leaving on
> [    2.516876] davinci_emac davinci_emac.0: using random MAC addr: 9e:53:0c:1a:23:3
> [    2.622650] Waiting for root device /dev/mmcblk0p2...
> [    2.629638] mmc0: new high speed SDHC card at address aaaa
> [    2.641143] mmcblk0: mmc0:aaaa SU04G 3.69 GiB 

Looks like it did not recognize the partitions on the MMC, hence waiting for 
the second partition /dev/mmcblk0p2 to become available to mount root from.


> Also, is there a bitbake target that makes an image I can write to an SD
> card? I got myself all confused trying to convert an SD image for a beaglebone
> and apparently replacing MLO was not sufficient.

If you are asking about a pre-partitioned SD card image, then there's no 
bitbake target for that, but you can look into 'wic' tool that does it.

-- 
Denys

Re: regression tests for am3517-evm machine?

[Troy Benjegerdes]

On Tue, Jan 19, 2016 at 02:08:08PM -0500, Denys Dmytriyenko wrote:
> On Mon, Jan 18, 2016 at 02:05:07PM -0600, Troy Benjegerdes wrote:
> > On Mon, Jan 18, 2016 at 11:46:15AM -0500, Denys Dmytriyenko wrote:
> > > On Sat, Jan 16, 2016 at 12:36:31AM -0600, Troy Benjegerdes wrote:
> > > > Are there any regression tests and/or recent builds of a 3.1x or 4.x series
> > > > kernel on an am3517 eval board? The original 'supported' TI SDKs were all
> > > > of the 2.6.x series, and it seems like somewhere along the way something
> > > > broke, and I'm trying to figure out what it was.
> > > 
> > > Do you have any specifics for the breakage?
> > > 
> > > -- 
> > > Denys
> > 
> > The kernel stops after discovering the MMC, but before mounting the 
> > filesystem:
> > 
> > [    2.446441] Key type dns_resolver registered
> > [    2.461151] voltdm_scale: No voltage scale API registered for vdd_mpu_iva
> > [    2.468444] voltdm_scale: No voltage scale API registered for vdd_core
> > [    2.479156] PM: no software I/O chain control; some wakeups may be lost
> > [    2.486816] ThumbEE CPU extension supported.
> > [    2.491363] Registering SWP/SWPB emulation handler
> > [    2.503784] regulator-dummy: incomplete constraints, leaving on
> > [    2.516876] davinci_emac davinci_emac.0: using random MAC addr: 9e:53:0c:1a:23:3
> > [    2.622650] Waiting for root device /dev/mmcblk0p2...
> > [    2.629638] mmc0: new high speed SDHC card at address aaaa
> > [    2.641143] mmcblk0: mmc0:aaaa SU04G 3.69 GiB 
> 
> Looks like it did not recognize the partitions on the MMC, hence waiting for 
> the second partition /dev/mmcblk0p2 to become available to mount root from.

Didn't 3.x kernels start requiring a device tree somewhere along the line?

I know the Beaglebone uses a device tree, but I can't seem to manage find
all the right pieces to build a working u-boot for am3517-evm that can 
properly pass it off to the kernel, at least with the Legacy image format(s).

So speaking of which, what prevents us from using the CONFIG_OF_CONTROL
options in u-boot so we could have the same u-boot binary work on both a
beaglebone and an am3517 based platform, provided you have the right device
trees for each board?

Re: regression tests for am3517-evm machine?

[Denys Dmytriyenko]

On Wed, Jan 20, 2016 at 07:58:30PM -0600, Troy Benjegerdes wrote:
> On Tue, Jan 19, 2016 at 02:08:08PM -0500, Denys Dmytriyenko wrote:
> > On Mon, Jan 18, 2016 at 02:05:07PM -0600, Troy Benjegerdes wrote:
> > > On Mon, Jan 18, 2016 at 11:46:15AM -0500, Denys Dmytriyenko wrote:
> > > > On Sat, Jan 16, 2016 at 12:36:31AM -0600, Troy Benjegerdes wrote:
> > > > > Are there any regression tests and/or recent builds of a 3.1x or 4.x series
> > > > > kernel on an am3517 eval board? The original 'supported' TI SDKs were all
> > > > > of the 2.6.x series, and it seems like somewhere along the way something
> > > > > broke, and I'm trying to figure out what it was.
> > > > 
> > > > Do you have any specifics for the breakage?
> > > > 
> > > > -- 
> > > > Denys
> > > 
> > > The kernel stops after discovering the MMC, but before mounting the 
> > > filesystem:
> > > 
> > > [    2.446441] Key type dns_resolver registered
> > > [    2.461151] voltdm_scale: No voltage scale API registered for vdd_mpu_iva
> > > [    2.468444] voltdm_scale: No voltage scale API registered for vdd_core
> > > [    2.479156] PM: no software I/O chain control; some wakeups may be lost
> > > [    2.486816] ThumbEE CPU extension supported.
> > > [    2.491363] Registering SWP/SWPB emulation handler
> > > [    2.503784] regulator-dummy: incomplete constraints, leaving on
> > > [    2.516876] davinci_emac davinci_emac.0: using random MAC addr: 9e:53:0c:1a:23:3
> > > [    2.622650] Waiting for root device /dev/mmcblk0p2...
> > > [    2.629638] mmc0: new high speed SDHC card at address aaaa
> > > [    2.641143] mmcblk0: mmc0:aaaa SU04G 3.69 GiB 
> > 
> > Looks like it did not recognize the partitions on the MMC, hence waiting for 
> > the second partition /dev/mmcblk0p2 to become available to mount root from.
> 
> Didn't 3.x kernels start requiring a device tree somewhere along the line?
> 
> I know the Beaglebone uses a device tree, but I can't seem to manage find
> all the right pieces to build a working u-boot for am3517-evm that can 
> properly pass it off to the kernel, at least with the Legacy image format(s).

Well, am3517 is one of the legacy platforms and I don't believe it was ever 
converted to use device tree...

-- 
Denys


> So speaking of which, what prevents us from using the CONFIG_OF_CONTROL
> options in u-boot so we could have the same u-boot binary work on both a
> beaglebone and an am3517 based platform, provided you have the right device
> trees for each board?

Re: regression tests for am3517-evm machine?

[Robert Nelson]

>> Didn't 3.x kernels start requiring a device tree somewhere along the line?
>>
>> I know the Beaglebone uses a device tree, but I can't seem to manage find
>> all the right pieces to build a working u-boot for am3517-evm that can
>> properly pass it off to the kernel, at least with the Legacy image format(s).
>
> Well, am3517 is one of the legacy platforms and I don't believe it was ever
> converted to use device tree...

Looks like it should atleast boot to mmc rootfs..

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/arch/arm/boot/dts/am3517-evm.dts

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

Re: regression tests for am3517-evm machine?

[Denys Dmytriyenko]

On Thu, Jan 21, 2016 at 04:03:29PM -0600, Robert Nelson wrote:
> >> Didn't 3.x kernels start requiring a device tree somewhere along the line?
> >>
> >> I know the Beaglebone uses a device tree, but I can't seem to manage find
> >> all the right pieces to build a working u-boot for am3517-evm that can
> >> properly pass it off to the kernel, at least with the Legacy image format(s).
> >
> > Well, am3517 is one of the legacy platforms and I don't believe it was ever
> > converted to use device tree...
> 
> Looks like it should atleast boot to mmc rootfs..
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/arch/arm/boot/dts/am3517-evm.dts

Well, I guess my memory is not that great any more... :)

http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=dbdb539e249c3b55ca3dc601c357634a0dbc909e

-- 
Denys

Re: regression tests for am3517-evm machine?

[Troy Benjegerdes]

On Thu, Jan 21, 2016 at 05:07:41PM -0500, Denys Dmytriyenko wrote:
> On Thu, Jan 21, 2016 at 04:03:29PM -0600, Robert Nelson wrote:
> > >> Didn't 3.x kernels start requiring a device tree somewhere along the line?
> > >>
> > >> I know the Beaglebone uses a device tree, but I can't seem to manage find
> > >> all the right pieces to build a working u-boot for am3517-evm that can
> > >> properly pass it off to the kernel, at least with the Legacy image format(s).
> > >
> > > Well, am3517 is one of the legacy platforms and I don't believe it was ever
> > > converted to use device tree...
> > 
> > Looks like it should atleast boot to mmc rootfs..
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/arch/arm/boot/dts/am3517-evm.dts
> 
> Well, I guess my memory is not that great any more... :)
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=dbdb539e249c3b55ca3dc601c357634a0dbc909e
> 

So the first problem seems to be that the 'u-boot' target produces
a build from the 2014.07 version, which does not seem to have any
environment or other setup to load a device tree.

Is there some patch floating around somewhere that updates the
default u-boot environment to work better with new kernels, or do
I need try and merge something in from the beaglebone

Re: regression tests for am3517-evm machine?

[Denys Dmytriyenko]

On Wed, Jan 27, 2016 at 03:56:45PM -0600, Troy Benjegerdes wrote:
> On Thu, Jan 21, 2016 at 05:07:41PM -0500, Denys Dmytriyenko wrote:
> > On Thu, Jan 21, 2016 at 04:03:29PM -0600, Robert Nelson wrote:
> > > >> Didn't 3.x kernels start requiring a device tree somewhere along the line?
> > > >>
> > > >> I know the Beaglebone uses a device tree, but I can't seem to manage find
> > > >> all the right pieces to build a working u-boot for am3517-evm that can
> > > >> properly pass it off to the kernel, at least with the Legacy image format(s).
> > > >
> > > > Well, am3517 is one of the legacy platforms and I don't believe it was ever
> > > > converted to use device tree...
> > > 
> > > Looks like it should atleast boot to mmc rootfs..
> > > 
> > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/arch/arm/boot/dts/am3517-evm.dts
> > 
> > Well, I guess my memory is not that great any more... :)
> > 
> > http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=dbdb539e249c3b55ca3dc601c357634a0dbc909e
> > 
> 
> So the first problem seems to be that the 'u-boot' target produces
> a build from the 2014.07 version, which does not seem to have any
> environment or other setup to load a device tree.
> 
> Is there some patch floating around somewhere that updates the
> default u-boot environment to work better with new kernels, or do
> I need try and merge something in from the beaglebone

Can you try u-boot-ti-staging instead?

-- 
Denys

Re: regression tests for am3517-evm machine?

[Troy Benjegerdes]

> > So the first problem seems to be that the 'u-boot' target produces
> > a build from the 2014.07 version, which does not seem to have any
> > environment or other setup to load a device tree.
> > 
> > Is there some patch floating around somewhere that updates the
> > default u-boot environment to work better with new kernels, or do
> > I need try and merge something in from the beaglebone
> 
> Can you try u-boot-ti-staging instead?

This is from 'pokey' ( yocto-2.0-121-g2fb7ee2 ),
with meta-ti: ( v2012.05-yocto1.2-938-gd397744 )


U-Boot 2015.07 (Jan 27 2016 - 15:32:32 -0600)
...
AM3517_EVM # printenv
baudrate=115200
bootcmd=mmc dev ${mmcdev}; if mmc rescan; then if run loadbootscript; then run bootscript; else if run loaduimai
bootdelay=10
bootfile=uImage
bootscript=echo Running bootscript from mmc ...; source ${loadaddr}
console=ttyO2,115200n8
dieid#=3f42000100000000015da3960e012002
ethact=DaVinci-EMAC
loadaddr=0x82000000
loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr
loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage
mmcargs=setenv bootargs console=${console} root=/dev/mmcblk0p2 rw rootwait
mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${loadaddr}
mmcdev=0
nandargs=setenv bootargs console=${console} root=/dev/mtdblock4 rw rootfstype=jffs2
nandboot=echo Booting from nand ...; run nandargs; nand read ${loadaddr} 280000 400000; bootm ${loadaddr}
stderr=serial
stdin=serial
stdout=serial





-- 
----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  hozer@hozed.org
7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop

      Never pick a fight with someone who buys ink by the barrel,
         nor try buy a hacker who makes money by the megahash

Re: regression tests for am3517-evm machine?

[Denys Dmytriyenko]

On Wed, Jan 27, 2016 at 04:12:03PM -0600, Troy Benjegerdes wrote:
> > > So the first problem seems to be that the 'u-boot' target produces
> > > a build from the 2014.07 version, which does not seem to have any
> > > environment or other setup to load a device tree.
> > > 
> > > Is there some patch floating around somewhere that updates the
> > > default u-boot environment to work better with new kernels, or do
> > > I need try and merge something in from the beaglebone
> > 
> > Can you try u-boot-ti-staging instead?
> 
> This is from 'pokey' ( yocto-2.0-121-g2fb7ee2 ),
> with meta-ti: ( v2012.05-yocto1.2-938-gd397744 )

Strange mix of branches - 2012 was almost 4 years ago... :)

I'd recommend using "fido" branch in all layers, as most tested at the moment. 
Still no guarantees about am3517, as that platform hasn't been officially 
tested for quite some time.


> U-Boot 2015.07 (Jan 27 2016 - 15:32:32 -0600)
> ...
> AM3517_EVM # printenv
> baudrate=115200
> bootcmd=mmc dev ${mmcdev}; if mmc rescan; then if run loadbootscript; then run bootscript; else if run loaduimai
> bootdelay=10
> bootfile=uImage
> bootscript=echo Running bootscript from mmc ...; source ${loadaddr}
> console=ttyO2,115200n8
> dieid#=3f42000100000000015da3960e012002
> ethact=DaVinci-EMAC
> loadaddr=0x82000000
> loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr
> loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage
> mmcargs=setenv bootargs console=${console} root=/dev/mmcblk0p2 rw rootwait
> mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${loadaddr}
> mmcdev=0
> nandargs=setenv bootargs console=${console} root=/dev/mtdblock4 rw rootfstype=jffs2
> nandboot=echo Booting from nand ...; run nandargs; nand read ${loadaddr} 280000 400000; bootm ${loadaddr}
> stderr=serial
> stdin=serial
> stdout=serial
> 
> 
> 
> 
> 
> -- 
> ----------------------------------------------------------------------------
> Troy Benjegerdes                 'da hozer'                  hozer@hozed.org
> 7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop
> 
>       Never pick a fight with someone who buys ink by the barrel,
>          nor try buy a hacker who makes money by the megahash
> 

Re: regression tests for am3517-evm machine?

[Troy Benjegerdes]

On Wed, Jan 27, 2016 at 05:55:29PM -0500, Denys Dmytriyenko wrote:
> On Wed, Jan 27, 2016 at 04:12:03PM -0600, Troy Benjegerdes wrote:
> > > > So the first problem seems to be that the 'u-boot' target produces
> > > > a build from the 2014.07 version, which does not seem to have any
> > > > environment or other setup to load a device tree.
> > > > 
> > > > Is there some patch floating around somewhere that updates the
> > > > default u-boot environment to work better with new kernels, or do
> > > > I need try and merge something in from the beaglebone
> > > 
> > > Can you try u-boot-ti-staging instead?
> > 
> > This is from 'pokey' ( yocto-2.0-121-g2fb7ee2 ),
> > with meta-ti: ( v2012.05-yocto1.2-938-gd397744 )
> 
> Strange mix of branches - 2012 was almost 4 years ago... :)
> 
> I'd recommend using "fido" branch in all layers, as most tested at the moment. 
> Still no guarantees about am3517, as that platform hasn't been officially 
> tested for quite some time.

Ah, I was on master for meta-ti.

FYI, I needed the following hack to build on yocto-2.0:

~/src/poky/meta-ti/recipes-graphics/drm
 % git diff
diff --git a/recipes-graphics/drm/libdrm_2.4.41.bb b/recipes-graphics/drm/libdrm_2.4.41.bb
index 86a660e..6e08b98 100644
--- a/recipes-graphics/drm/libdrm_2.4.41.bb
+++ b/recipes-graphics/drm/libdrm_2.4.41.bb
@@ -1,8 +1,9 @@
-require recipes-graphics/drm/libdrm.inc
+#require recipes-graphics/drm/libdrm.inc
 
 FILESEXTRAPATHS_append := ":${COREBASE}/meta/recipes-graphics/drm/libdrm"
 
 COMPATIBLE_MACHINE = "ti33x|ti43x|omap-a15"
+LICENSE = 'GPL'


After a little more digging around, I find that having:
#define CONFIG_OF_LIBFDT
is required for u-boot to be able to recognize and load a device
tree, but it does not seem to be set in the am3517 build(s). 

If I build a u-boot from source with CONFIG_OF_LIBFDT, I get the
expected output, but now if boot a mainline 3.16 or 3.18 kernel
(which mostly work with no device tree), these kernels fail to
boot with a device tree.

Re: regression tests for am3517-evm machine?

[Denys Dmytriyenko]

On Wed, Jan 27, 2016 at 10:52:55PM -0600, Troy Benjegerdes wrote:
> On Wed, Jan 27, 2016 at 05:55:29PM -0500, Denys Dmytriyenko wrote:
> > On Wed, Jan 27, 2016 at 04:12:03PM -0600, Troy Benjegerdes wrote:
> > > > > So the first problem seems to be that the 'u-boot' target produces
> > > > > a build from the 2014.07 version, which does not seem to have any
> > > > > environment or other setup to load a device tree.
> > > > > 
> > > > > Is there some patch floating around somewhere that updates the
> > > > > default u-boot environment to work better with new kernels, or do
> > > > > I need try and merge something in from the beaglebone
> > > > 
> > > > Can you try u-boot-ti-staging instead?
> > > 
> > > This is from 'pokey' ( yocto-2.0-121-g2fb7ee2 ),
> > > with meta-ti: ( v2012.05-yocto1.2-938-gd397744 )
> > 
> > Strange mix of branches - 2012 was almost 4 years ago... :)
> > 
> > I'd recommend using "fido" branch in all layers, as most tested at the moment. 
> > Still no guarantees about am3517, as that platform hasn't been officially 
> > tested for quite some time.
> 
> Ah, I was on master for meta-ti.
> 
> FYI, I needed the following hack to build on yocto-2.0:

It was fixed in master long ago:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/recipes-graphics/drm/libdrm.inc?id=2d2633227f541395276316a4b45bafa41be94003


> ~/src/poky/meta-ti/recipes-graphics/drm
>  % git diff
> diff --git a/recipes-graphics/drm/libdrm_2.4.41.bb b/recipes-graphics/drm/libdrm_2.4.41.bb
> index 86a660e..6e08b98 100644
> --- a/recipes-graphics/drm/libdrm_2.4.41.bb
> +++ b/recipes-graphics/drm/libdrm_2.4.41.bb
> @@ -1,8 +1,9 @@
> -require recipes-graphics/drm/libdrm.inc
> +#require recipes-graphics/drm/libdrm.inc
>  
>  FILESEXTRAPATHS_append := ":${COREBASE}/meta/recipes-graphics/drm/libdrm"
>  
>  COMPATIBLE_MACHINE = "ti33x|ti43x|omap-a15"
> +LICENSE = 'GPL'
> 
> 
> After a little more digging around, I find that having:
> #define CONFIG_OF_LIBFDT
> is required for u-boot to be able to recognize and load a device
> tree, but it does not seem to be set in the am3517 build(s). 
> 
> If I build a u-boot from source with CONFIG_OF_LIBFDT, I get the
> expected output, but now if boot a mainline 3.16 or 3.18 kernel
> (which mostly work with no device tree), these kernels fail to
> boot with a device tree.

Re: regression tests for am3517-evm machine?

[Troy Benjegerdes]

> > After a little more digging around, I find that having:
> > #define CONFIG_OF_LIBFDT
> > is required for u-boot to be able to recognize and load a device
> > tree, but it does not seem to be set in the am3517 build(s). 
> > 
> > If I build a u-boot from source with CONFIG_OF_LIBFDT, I get the
> > expected output, but now if boot a mainline 3.16 or 3.18 kernel
> > (which mostly work with no device tree), these kernels fail to
> > boot with a device tree.

What is the state of linux-ti-staging and how does it compare to
linux-omap.. it seems like there is some sort of brokenness in
moving the am3517 (omap3) support from the legacy code to device
trees.

Re: regression tests for am3517-evm machine?

[Denys Dmytriyenko]

On Thu, Jan 28, 2016 at 10:33:17AM -0600, Troy Benjegerdes wrote:
> > > After a little more digging around, I find that having:
> > > #define CONFIG_OF_LIBFDT
> > > is required for u-boot to be able to recognize and load a device
> > > tree, but it does not seem to be set in the am3517 build(s). 
> > > 
> > > If I build a u-boot from source with CONFIG_OF_LIBFDT, I get the
> > > expected output, but now if boot a mainline 3.16 or 3.18 kernel
> > > (which mostly work with no device tree), these kernels fail to
> > > boot with a device tree.
> 
> What is the state of linux-ti-staging and how does it compare to
> linux-omap.. it seems like there is some sort of brokenness in
> moving the am3517 (omap3) support from the legacy code to device
> trees.

linux-ti-staging recipe pulls from ti-linux-kernel on git.ti.com, which is 
the latest kernel development and upstreaming effort for all the current TI 
processors. Maintaining legacy parts like am3517 and omap3 in general is a 
best effort.

If by linux-omap you mean the actual kernel tree from Tony Lindgren, then it 
is one of the targets for patches staged in ti-linux-kernel to be upstreamed 
to, among others.

-- 
Denys