Buidling for am335x_evm

Buidling for am335x_evm

[Rudolf Streif]

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

I tried to build a system for the AM335x_EVM board using the meta-ti layer
with YP 1.4.2 Dylan. Here are the steps:

   1. Clone meta-ti layer
   2. Check out dylan branch
   3. Set up build environment, add meta-ti layer
   4. Set MACHINE = "am335x_evm"
   5. bitbake -k core-image-minimal

Everything builds, put on target, u-boot comes up, hangs at "Starting Linux
kernel...". Most likely machine type mismatch. Start digging around:

   1. The am335x_evm.conf machine configuration includes the ti33x.inc file.
   2. ti33x.inc sets
   PREFERRED_PROVIDER_virtual/kernel = "linux-ti-staging"
   PREFERRED_PROVIDER_virtual/bootloader = "u-boot-ti-staging"
   PREFERRED_PROVIDER_u-boot = "u-boot-ti-staging"
   3. The build process uses linux-ti-staging_git.bb and configures the
   kernel using the defconfig found in the llnux-ti-staging subdir.
   Content: use-kernel-config=omap2plus_defconfig. Why would I want to
   configure the Sitara SOC with an OMAP defconfig?
   4. Checking kernel build environment
   in tmp/work/am335x_evm-poky-linux-gnueabi/linux-ti-staging/3.11+3.12-rc3-r19a+gitrAUTOINC+f7579525de9f1d6086c407a6980f4f1c1c574256/git.
   From SRCREV it seems to be a 3.11/3.12 kernel:
      1. Check arm/arch/tools/mach-types: found:
      tam335x                 MACH_TAM335X            TAM335X
        4116
      Expected to find
      am335xevm               MACH_AM335XEVM          AM335XEVM
        3589 as it was for the 3.2.32 kernel.
      2. Check arm/arch/configs for am335x_evm_defconfig which does not
      exist. Expected to see an am335x_evm_defconfig as found it in a 3.2.32
      kernel.
   5. Checking u-boot build environment which uses, as expected, the
   am335c_evm configuration which sets the machine type to 3589.

I may be missing something but it looks to me as if the layer is broken for
building for the AM335X_EVM target machine.

Thanks for your help,
Rudi

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

Re: Buidling for am335x_evm

[Denys Dmytriyenko]

Rudi,

On Thu, Oct 03, 2013 at 09:41:38PM -0700, Rudolf Streif wrote:
> I tried to build a system for the AM335x_EVM board using the meta-ti layer
> with YP 1.4.2 Dylan. Here are the steps:
> 
>    1. Clone meta-ti layer
>    2. Check out dylan branch
>    3. Set up build environment, add meta-ti layer
>    4. Set MACHINE = "am335x_evm"

It should be dash in there, not underscore. Although it gets converted 
internally anyway...


>    5. bitbake -k core-image-minimal
> 
> Everything builds, put on target, u-boot comes up, hangs at "Starting Linux
> kernel...". Most likely machine type mismatch. Start digging around:

Most likely u-boot couldn't find your DTB - did you put one in the /boot of 
rootfs? Didn't u-boot complain about it? Should have been an error message.


>    1. The am335x_evm.conf machine configuration includes the ti33x.inc file.
>    2. ti33x.inc sets
>    PREFERRED_PROVIDER_virtual/kernel = "linux-ti-staging"
>    PREFERRED_PROVIDER_virtual/bootloader = "u-boot-ti-staging"
>    PREFERRED_PROVIDER_u-boot = "u-boot-ti-staging"

BTW, if you are not comfortable with 3.12-rc being unstable, you can also add 
to your config:

PREFERRED_VERSION_linux-ti-staging = "3.8%"


>    3. The build process uses linux-ti-staging_git.bb and configures the
>    kernel using the defconfig found in the llnux-ti-staging subdir.
>    Content: use-kernel-config=omap2plus_defconfig. Why would I want to
>    configure the Sitara SOC with an OMAP defconfig?

It's called OMAP2+ and that's how kernel folks decided to call a consolidated 
config for most if not all TI platforms. Gone are the times when each platform 
had it's own config file - kernel folks don't allow that anymore. Anyway, 
omap2plus is the right defconfig.


>    4. Checking kernel build environment
>    in tmp/work/am335x_evm-poky-linux-gnueabi/linux-ti-staging/3.11+3.12-rc3-r19a+gitrAUTOINC+f7579525de9f1d6086c407a6980f4f1c1c574256/git.
>    From SRCREV it seems to be a 3.11/3.12 kernel:

Yes, it's 3.12-rc3


>       1. Check arm/arch/tools/mach-types: found:
>       tam335x                 MACH_TAM335X            TAM335X
>         4116
>       Expected to find
>       am335xevm               MACH_AM335XEVM          AM335XEVM
>         3589 as it was for the 3.2.32 kernel.

I'm not sure what you are looking for, but there are many differences between 
3.2, 3.8 and 3.12


>       2. Check arm/arch/configs for am335x_evm_defconfig which does not
>       exist. Expected to see an am335x_evm_defconfig as found it in a 3.2.32
>       kernel.

See above - you won't find it any more, as it's not allowed any more by kernel 
policies to have million different defconfigs. As you can see, the entire 
arch/arm/configs directory is very scarce these days - all omaps were 
consolidated and new SOCs are added to existing defconfigs, where applicable.


>    5. Checking u-boot build environment which uses, as expected, the
>    am335c_evm configuration which sets the machine type to 3589.
> 
> I may be missing something but it looks to me as if the layer is broken for
> building for the AM335X_EVM target machine.

No, it's not broken, it's just quite different from 3.2 days.

-- 
Denys

Re: Buidling for am335x_evm

[Denys Dmytriyenko]

BTW, here's our latest nightly build and test report:

http://article.gmane.org/gmane.linux.embedded.yocto.meta-arago/1062

It's not exactly the same config, as it has few other layers configured and 
it's Arago distribution, not Poky, but for the most part it's similar and uses 
the same latest meta-ti BSP layer, hence loads the same build of the kernel 
and u-boot...

-- 
Denys


On Fri, Oct 04, 2013 at 01:33:54AM -0400, Denys Dmytriyenko wrote:
> Rudi,
> 
> On Thu, Oct 03, 2013 at 09:41:38PM -0700, Rudolf Streif wrote:
> > I tried to build a system for the AM335x_EVM board using the meta-ti layer
> > with YP 1.4.2 Dylan. Here are the steps:
> > 
> >    1. Clone meta-ti layer
> >    2. Check out dylan branch
> >    3. Set up build environment, add meta-ti layer
> >    4. Set MACHINE = "am335x_evm"
> 
> It should be dash in there, not underscore. Although it gets converted 
> internally anyway...
> 
> 
> >    5. bitbake -k core-image-minimal
> > 
> > Everything builds, put on target, u-boot comes up, hangs at "Starting Linux
> > kernel...". Most likely machine type mismatch. Start digging around:
> 
> Most likely u-boot couldn't find your DTB - did you put one in the /boot of 
> rootfs? Didn't u-boot complain about it? Should have been an error message.
> 
> 
> >    1. The am335x_evm.conf machine configuration includes the ti33x.inc file.
> >    2. ti33x.inc sets
> >    PREFERRED_PROVIDER_virtual/kernel = "linux-ti-staging"
> >    PREFERRED_PROVIDER_virtual/bootloader = "u-boot-ti-staging"
> >    PREFERRED_PROVIDER_u-boot = "u-boot-ti-staging"
> 
> BTW, if you are not comfortable with 3.12-rc being unstable, you can also add 
> to your config:
> 
> PREFERRED_VERSION_linux-ti-staging = "3.8%"
> 
> 
> >    3. The build process uses linux-ti-staging_git.bb and configures the
> >    kernel using the defconfig found in the llnux-ti-staging subdir.
> >    Content: use-kernel-config=omap2plus_defconfig. Why would I want to
> >    configure the Sitara SOC with an OMAP defconfig?
> 
> It's called OMAP2+ and that's how kernel folks decided to call a consolidated 
> config for most if not all TI platforms. Gone are the times when each platform 
> had it's own config file - kernel folks don't allow that anymore. Anyway, 
> omap2plus is the right defconfig.
> 
> 
> >    4. Checking kernel build environment
> >    in tmp/work/am335x_evm-poky-linux-gnueabi/linux-ti-staging/3.11+3.12-rc3-r19a+gitrAUTOINC+f7579525de9f1d6086c407a6980f4f1c1c574256/git.
> >    From SRCREV it seems to be a 3.11/3.12 kernel:
> 
> Yes, it's 3.12-rc3
> 
> 
> >       1. Check arm/arch/tools/mach-types: found:
> >       tam335x                 MACH_TAM335X            TAM335X
> >         4116
> >       Expected to find
> >       am335xevm               MACH_AM335XEVM          AM335XEVM
> >         3589 as it was for the 3.2.32 kernel.
> 
> I'm not sure what you are looking for, but there are many differences between 
> 3.2, 3.8 and 3.12
> 
> 
> >       2. Check arm/arch/configs for am335x_evm_defconfig which does not
> >       exist. Expected to see an am335x_evm_defconfig as found it in a 3.2.32
> >       kernel.
> 
> See above - you won't find it any more, as it's not allowed any more by kernel 
> policies to have million different defconfigs. As you can see, the entire 
> arch/arm/configs directory is very scarce these days - all omaps were 
> consolidated and new SOCs are added to existing defconfigs, where applicable.
> 
> 
> >    5. Checking u-boot build environment which uses, as expected, the
> >    am335c_evm configuration which sets the machine type to 3589.
> > 
> > I may be missing something but it looks to me as if the layer is broken for
> > building for the AM335X_EVM target machine.
> 
> No, it's not broken, it's just quite different from 3.2 days.
> 
> -- 
> Denys
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti
> 

Re: Buidling for am335x_evm

[Rudolf Streif]

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

Hi Denys,

Thanks for your feedback.


It should be dash in there, not underscore. Although it gets converted
> internally anyway...
>
> Yes, of course that was only a typo in the e-mail.


>
> Most likely u-boot couldn't find your DTB - did you put one in the /boot of
> rootfs? Didn't u-boot complain about it? Should have been an error message.
>
> That is a question that I forgot to ask in my first e-mail. With 3.12 I
would have expected a dtb to be built but it did not. The tmp/deploy/images
directory only contains [1] but no dtb. Neither does the tar.gz for the
rootfs but I would not expect it to. And no, u-boot did not complain about
the device tree either. If it had built a dtb I would have put it in the
FAT boot partition and told u-boot to load it in the bootargs.


> BTW, if you are not comfortable with 3.12-rc being unstable, you can also
> add
> to your config:
>
> PREFERRED_VERSION_linux-ti-staging = "3.8%"
>
> Yes, of course. I am ok with 3.12-rc. I was only surprised that the Dylan
branch of the bsp layer would build a 3.12 kernel while the default for
Poky Dylan is 3.8. Or maybe my assumption that a bsp for a particular YP
release would use the same kernel as a default is incorrect.


> It's called OMAP2+ and that's how kernel folks decided to call a
> consolidated
> config for most if not all TI platforms. Gone are the times when each
> platform
> had it's own config file - kernel folks don't allow that anymore. Anyway,
> omap2plus is the right defconfig.
>
> That's actually a great thing. (One of Linus' pet peeves, I suppose.) I
only wish the name of the file would be more intuitive. It's not quite
obvious that a file called omap2plus_defconfig is the correct file to
configure a kernel for an AM335x CPU. A different file name and/or a
comment in the file to what CPU's it applies would have been great.


>
> >       1. Check arm/arch/tools/mach-types: found:
> >       tam335x                 MACH_TAM335X            TAM335X
> >         4116
> >       Expected to find
> >       am335xevm               MACH_AM335XEVM          AM335XEVM
> >         3589 as it was for the 3.2.32 kernel.
>
> I'm not sure what you are looking for, but there are many differences
> between
> 3.2, 3.8 and 3.12
>
> I was looking for matching machine IDs in the u-boot configuration and the
kernel configuration. But that of course does not apply anymore with a
device tree. But I was thrown off by the fact that the kernel recipe did
not create a device tree. And that I still have to debug.


> >       2. Check arm/arch/configs for am335x_evm_defconfig which does not
> >       exist. Expected to see an am335x_evm_defconfig as found it in a
> 3.2.32
> >       kernel.
>
> See above - you won't find it any more, as it's not allowed any more by
> kernel
> policies to have million different defconfigs. As you can see, the entire
> arch/arm/configs directory is very scarce these days - all omaps were
> consolidated and new SOCs are added to existing defconfigs, where
> applicable.
>
> Thanks. I understand that now but a different file name and a comment
would have made it obvious. Yes, the settings are in the file


>
> >    5. Checking u-boot build environment which uses, as expected, the
> >    am335c_evm configuration which sets the machine type to 3589.
> >
> > I may be missing something but it looks to me as if the layer is broken
> for
> > building for the AM335X_EVM target machine.
>
> No, it's not broken, it's just quite different from 3.2 days.
>
>
Probably not in general but maybe on my system because I am missing the DTB
for whatever reason.


Thanks,
Rudi



[1]

core-image-minimal-am335x-evm-20131003152950.rootfs.tar.gz
core-image-minimal-am335x-evm-20131003152950.rootfs.ubi
core-image-minimal-am335x-evm-20131003152950.rootfs.ubifs
core-image-minimal-am335x-evm.tar.gz
core-image-minimal-am335x-evm.ubi
MLO
MLO-am335x-evm
MLO-am335x-evm-2013.07+2013.10-rc2-r0+gitrAUTOINC+fb18fa95a14ae875ef0a5421cd9fecc00c7c3a4c
modules--3.11+3.12-rc3-r19a+gitrAUTOINC+f7579525de9f1d6086c407a6980f4f1c1c574256-am335x-evm-20131003152950.tgz
README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt
rootfs
u-boot-am335x-evm-2013.07+2013.10-rc2-r0+gitrAUTOINC+fb18fa95a14ae875ef0a5421cd9fecc00c7c3a4c.img
u-boot-am335x-evm.img
u-boot.img
u-boot-spl.bin
u-boot-spl.bin-am335x-evm
u-boot-spl.bin-am335x-evm-2013.07+2013.10-rc2-r0+gitrAUTOINC+fb18fa95a14ae875ef0a5421cd9fecc00c7c3a4c
uImage
uImage--3.11+3.12-rc3-r19a+gitrAUTOINC+f7579525de9f1d6086c407a6980f4f1c1c574256-am335x-evm-20131003152950.bin
uImage-am335x-evm.bin

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

Re: Buidling for am335x_evm

[Denys Dmytriyenko]

Rudi,

On Fri, Oct 04, 2013 at 10:29:21AM -0700, Rudolf Streif wrote:
> > Most likely u-boot couldn't find your DTB - did you put one in the /boot of
> > rootfs? Didn't u-boot complain about it? Should have been an error message.
> >
> That is a question that I forgot to ask in my first e-mail. With 3.12 I
> would have expected a dtb to be built but it did not. The tmp/deploy/images
> directory only contains [1] but no dtb. Neither does the tar.gz for the
> rootfs but I would not expect it to. And no, u-boot did not complain about
> the device tree either. If it had built a dtb I would have put it in the
> FAT boot partition and told u-boot to load it in the bootargs.

FAT boot partition is no longer preferred place for kernel images and DTB 
files - U-boot now wants to see them in /boot directory of the rootfs.

Ok, let's debug why you are not getting any DTB files produced. There should 
be at least 3 of them for the case of am335x-evm, as it covers EVM, EVM-SK and 
BeagleBone.

Can you show me your bblayers.conf file, please?


> > BTW, if you are not comfortable with 3.12-rc being unstable, you can also
> > add
> > to your config:
> >
> > PREFERRED_VERSION_linux-ti-staging = "3.8%"
> >
> Yes, of course. I am ok with 3.12-rc. I was only surprised that the Dylan
> branch of the bsp layer would build a 3.12 kernel while the default for
> Poky Dylan is 3.8. Or maybe my assumption that a bsp for a particular YP
> release would use the same kernel as a default is incorrect.

First, Poky != Yocto, so there's no requirement on what kernel version a BSP 
should provide. Second, there are several options available for am335x - 3.2, 
3.8 and 3.12, so anyone can use the version they like.


> > It's called OMAP2+ and that's how kernel folks decided to call a
> > consolidated
> > config for most if not all TI platforms. Gone are the times when each
> > platform
> > had it's own config file - kernel folks don't allow that anymore. Anyway,
> > omap2plus is the right defconfig.
> >
> That's actually a great thing. (One of Linus' pet peeves, I suppose.) I
> only wish the name of the file would be more intuitive. It's not quite
> obvious that a file called omap2plus_defconfig is the correct file to
> configure a kernel for an AM335x CPU. A different file name and/or a
> comment in the file to what CPU's it applies would have been great.

I agree it would have been nice to get a better name, but historically we 
ended up with this one.

-- 
Denys

Re: Buidling for am335x_evm

[Rudolf Streif]

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

Thanks, Denys. I appreciate your help.

FAT boot partition is no longer preferred place for kernel images and DTB
> files - U-boot now wants to see them in /boot directory of the rootfs.
>
> That is actually a good thing. But I assume one will still need the FAT
partition for MLO and u-boot itself. Unfortunately, the do_rootfs task does
not put dtb or kernel into /boot yet.


> Ok, let's debug why you are not getting any DTB files produced. There
> should
> be at least 3 of them for the case of am335x-evm, as it covers EVM, EVM-SK
> and
> BeagleBone.
>
> They are not created. I changed the machine to beaglebone to test. No
dtb's created although the build process finishes without errors.


> Can you show me your bblayers.conf file, please?
>

Of course:

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "6"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  /run/media/rudi/WDPassport-1T/develop/yocto/yocto-dylan/poky/meta \
  /run/media/rudi/WDPassport-1T/develop/yocto/yocto-dylan/poky/meta-yocto \

/run/media/rudi/WDPassport-1T/develop/yocto/yocto-dylan/poky/meta-yocto-bsp
\
  /run/media/rudi/WDPassport-1T/develop/yocto/yocto-dylan/bsp/meta-ti \
  "
BBLAYERS_NON_REMOVABLE ?= " \
  /run/media/rudi/WDPassport-1T/develop/yocto/yocto-dylan/poky/meta \
  /run/media/rudi/WDPassport-1T/develop/yocto/yocto-dylan/poky/meta-yocto \
  "


Cheers,
Rudi

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

Re: Buidling for am335x_evm

[Denys Dmytriyenko]

On Fri, Oct 04, 2013 at 02:00:44PM -0700, Rudolf Streif wrote:
> Thanks, Denys. I appreciate your help.

You are very welcome.


> > FAT boot partition is no longer preferred place for kernel images and DTB
> > files - U-boot now wants to see them in /boot directory of the rootfs.
> >
> That is actually a good thing. But I assume one will still need the FAT
> partition for MLO and u-boot itself.

Correct, you still need FAT boot partition for MLO and u-boot.


> Unfortunately, the do_rootfs task does not put dtb or kernel into /boot yet.

You are just using the wrong image :)
core-image-minimal is not installing any kernel modules, hence no kernel 
image and no kernel device trees.
Kernel image being pulled by default into /boot was there for long time. And I 
pushed the patch earlier today for pulling device trees into /boot. But that 
only happens when your image installs anything from the kernel, which 
core-image-minimal doesn't do. Try core-image-base instead.


> > Ok, let's debug why you are not getting any DTB files produced. There
> > should
> > be at least 3 of them for the case of am335x-evm, as it covers EVM, EVM-SK
> > and
> > BeagleBone.
> >
> They are not created. I changed the machine to beaglebone to test. No
> dtb's created although the build process finishes without errors.

The machine is not the problem - the problem is the layer setup, as I 
suspected... See below.
If you build for beaglebone, you'll only get DTB for beaglebone. If you build 
for am335x-evm, you'll get 3 DTBs for EVM, EVM-SK and beaglebone, as I 
mentioned before.


> > Can you show me your bblayers.conf file, please?
> >
> 
> Of course:
> 
> # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
> # changes incompatibly
> LCONF_VERSION = "6"
> 
> BBPATH = "${TOPDIR}"
> BBFILES ?= ""
> 
> BBLAYERS ?= " \
>   /run/media/rudi/WDPassport-1T/develop/yocto/yocto-dylan/poky/meta \
>   /run/media/rudi/WDPassport-1T/develop/yocto/yocto-dylan/poky/meta-yocto \
> 
> /run/media/rudi/WDPassport-1T/develop/yocto/yocto-dylan/poky/meta-yocto-bsp \
>   /run/media/rudi/WDPassport-1T/develop/yocto/yocto-dylan/bsp/meta-ti \
>   "

So, I see the problem here - you placed meta-ti layer at the very bottom, 
which prevents it from overriding any files in other layers. Specifically, 
meta-ti has a newer linux-dtb.inc to handle in-tree compilation of DTBs and 
the new syntax, which happened recently around 3.10-3.12 timeframe...

The way you set it up, you are not using linux-dtb.inc from meta-ti, but 
instead using an old one from oe-core (poky/meta in your case). This 
particular file has been updated in the master branch of OE-Core and Poky, but 
not in Dylan, because Poky/Dylan was frozen on 3.8, like you said before.
We needed the newer one in Dylan, because we have 3.12 in there as well as in 
the master.

So, the solution is to have meta-ti before meta. I'm also wondering why you 
have meta-yocto and meta-yocto-bsp after meta, but I will leave that to Poky 
maintainers... Also, if you have meta-yocto-bsp before meta-ti, you will have 
issues with beagleboard machine and recipes in meta-ti, as both those BSP 
layers define beagleboard machine. But you don't seem to use beagleboard now. 
BTW, meta-yocto-bsp is a reference BSP, you don't need it if you have real BSP

So, I usually compose layer stack as follows:
* Distro
* Apps
* BSP
* Core

This way you have the most flexibility overriding different things in higher 
layers from their originals in lower core layers.

In your case, Distro = meta-yocto, Apps is empty, BSP is meta-ti _and_ 
meta-yocto-bsp, and Core is meta. Try switching them around.

-- 
Denys

Re: Buidling for am335x_evm

[Rudolf Streif]

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

Thanks, Denys. That did the trick.

Rudi

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

Re: Buidling for am335x_evm

[Rudolf Streif]

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

Hi Denys,

I guess I have to follow up on this. Everything builds now and with
core-image-base the kernel image is installed into /boot. The fdt is not
however. I used the Beaglebone in this case because it's a known board to
me and I have been able to boot it successfully with my own Beaglebone BSP
many time.

This is what I did on a preformatted SD card with partition 0 with FAT and
partition 1 with ext4 with the images built using the meta-ti layer:

   1. sudo cp MLO-beaglebone /run/media/rudi/BEAGBOOT/MLO
   2. sudo cp u-boot-beaglebone.img /run/media/rudi/BEAGBOOT/u-boot.img
   3. sudo tar x -C /run/media/rudi/beagroot1/ -f
   core-image-base-beaglebone.tar.gz
   4. sudo tar x -C /run/media/rudi/beagroot1/ -f
   modules--3.11+3.12-rc3-r19a+gitrAUTOINC+f7579525de9f1d6086c407a6980f4f1c1c574256-beaglebone-20131005020051.tgz
   5. cp uImage-am335x-bone.dtb
   /run/media/rudi/beagroot1/boot/am335x-bone.dtb

For step 5 one of course has to know that the u-boot environment expects an
fdt with the name am335x-bone.dtb in /boot.

The u-boot bootcmd is set to

bootcmd=run findfdt; run mmcboot;setenv mmcdev 1; setenv bootpart 1:2; run
mmcboot;run nandboot;

findfdt finds and sets the fdtfile variable correctly to am335x-bone.dtb.

mmcboot eventually runs mmcloados which is set to:

mmcloados=run mmcargs; if test ${boot_fdt} = yes || test ${boot_fdt} = try;
then if run loadfdt; then bootm ${loadaddr} - ${fdtaddr}; else if test
${boot_fdt} = try; then bootm; else echo WARN: Cannot load the DT; fi; fi;
else bootm; fi;

That's the default. It loads the fdt correctly but it never loads the
kernel image. There is no command that executes loaduimage which is set to:

loaduimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}


Now, I executed all these steps manually and loaded the fdt and the kernel
image, etc and eventually ran bootm. u-boots loads and decompresses the
kernel and then it stops at "Starting kernel..." Probably a device tree
issue.


There are two issues:

   1. u-boot environment does not load the kernel image. I can get around
   that.
   2. Device tree does not seem to match the kernel image but that's only a
   guess at this point.

Thanks,
Rudi

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

Re: Buidling for am335x_evm

[Denys Dmytriyenko]

On Sat, Oct 05, 2013 at 09:46:29AM -0700, Rudolf Streif wrote:
> Hi Denys,
> 
> I guess I have to follow up on this. Everything builds now and with
> core-image-base the kernel image is installed into /boot. The fdt is not
> however.

If you are finally getting the kernel image into /boot directory, but not the 
device trees, then you probably are not using the latest enough snapshot of 
meta-ti...


> I used the Beaglebone in this case because it's a known board to
> me and I have been able to boot it successfully with my own Beaglebone BSP
> many time.
> 
> This is what I did on a preformatted SD card with partition 0 with FAT and
> partition 1 with ext4 with the images built using the meta-ti layer:
> 
>    1. sudo cp MLO-beaglebone /run/media/rudi/BEAGBOOT/MLO
>    2. sudo cp u-boot-beaglebone.img /run/media/rudi/BEAGBOOT/u-boot.img
>    3. sudo tar x -C /run/media/rudi/beagroot1/ -f
>    core-image-base-beaglebone.tar.gz
>    4. sudo tar x -C /run/media/rudi/beagroot1/ -f
>    modules--3.11+3.12-rc3-r19a+gitrAUTOINC+f7579525de9f1d6086c407a6980f4f1c1c574256-beaglebone-20131005020051.tgz
>    5. cp uImage-am335x-bone.dtb
>    /run/media/rudi/beagroot1/boot/am335x-bone.dtb
> 
> For step 5 one of course has to know that the u-boot environment expects an
> fdt with the name am335x-bone.dtb in /boot.
> 
> The u-boot bootcmd is set to
> 
> bootcmd=run findfdt; run mmcboot;setenv mmcdev 1; setenv bootpart 1:2; run
> mmcboot;run nandboot;
> 
> findfdt finds and sets the fdtfile variable correctly to am335x-bone.dtb.
> 
> mmcboot eventually runs mmcloados which is set to:
> 
> mmcloados=run mmcargs; if test ${boot_fdt} = yes || test ${boot_fdt} = try;
> then if run loadfdt; then bootm ${loadaddr} - ${fdtaddr}; else if test
> ${boot_fdt} = try; then bootm; else echo WARN: Cannot load the DT; fi; fi;
> else bootm; fi;
> 
> That's the default. It loads the fdt correctly but it never loads the
> kernel image. There is no command that executes loaduimage which is set to:
> 
> loaduimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}
> 
> 
> Now, I executed all these steps manually and loaded the fdt and the kernel
> image, etc and eventually ran bootm. u-boots loads and decompresses the
> kernel and then it stops at "Starting kernel..." Probably a device tree
> issue.
> 
> 
> There are two issues:
> 
>    1. u-boot environment does not load the kernel image. I can get around
>    that.
>    2. Device tree does not seem to match the kernel image but that's only a
>    guess at this point.
> 
> Thanks,
> Rudi