Project

General

Profile

Yocto in the future?

Added by Michael Karasoff over 11 years ago

Up until a week or so ago, we were developing MityARM-335x code under Angstrom as a holdover from work done on Beaglebone w/ Angstrom. We built the filesystem, kernel, and uboot using recipes posted on the Critical Link Wiki, and - once we got Angstrom working - did not have apparent issues here. Recently, we started working on a GPMC kernel driver and so decided to migrate to Arago as Critical Link appears to support kernel builds under Arago. This migration all went relatively smoothly.

Just for giggles, we tried building the MityARM-335x kernel using Yocto's SDK. After setting LDFLAG="", the kernel compile fine. However, the boot hung at "Uncompressing Linux... done, booting the kernel":
Starting kernel ...
Uncompressing Linux... done, booting the kernel.

We did not have this problem with the same code and .config file under Angstrom or Arago. Any idea why boot might hang up under the Yocto toolchain?

I've got to ask about Yocto, as it seems to be where Open Embedded is heading. I noticed on another forum, it was mentioned that Critical Link was considering a move to Yocto. Has a decision been made here? Is at all worth considering Yocto for the MityARM-335x?


Replies (8)

RE: Yocto in the future? - Added by Michael Williamson over 11 years ago

I don't know why the SDK toolchain isn't working. Are you sure that the .config file was not altered, specifically, the MACHINE type? That would definitely cause problems. Are you using the kernel and u-boot code from our site, or from a Yocto recipe? Support for the MityARM-335x is not in any mainline/yocto tree at the moment, and you need our patches for the board to come up.

What version of gcc is the Yocto SDK providing?

We would like to support Yocto as it seems not too big a stretch from our current angstrom build, but at the moment it is not supported. No decision has been made. We have had a lot of problems with stability with the Angstrom / OE builds in the past on other platforms, and quite frankly are a little concerned about having to officially support it here. When the switch from the "classic" framework to the "core" layered framework (which was desperately needed) happened, many packages which our customers were using didn't get ported right away and put us into a bind as we tried to follow along with the mainline distributions (Angstrom 2012-05 and forward). I know that Yocto has made many advances in this area, and that is why we are still looking at the issue. We also appreciate that it would greatly ease BeagleBone developers to transition to MityARM-335x.

Many of our customers are requiring / using the Timesys distribution & SDK at the moment. They are quite happy with the environment and the support. The baseline images and toolchains are free (and I think you can also get snapshots of all the sources for the OS software in order to easily reproduce a build) and Timesys seems to have a much more controlled build and test environment as well as a path for paid customer support.

-Mike

RE: Yocto in the future? - Added by Michael Karasoff over 11 years ago

Mike,

Thanks again for your quick response.

In Yocto, I've been setting following environment variables in my local.conf:
GCCVERSION = "4.5%"
BINUVERSION = "2.20.1"

I have used pretty much the same BSP in Yocto as for Angstrom. The only difference is that I modified the Yocto recipe so that it was forced using the same .config file generated with the a working build in Angstrom. I verified the .config match post-build.

I tried both the bootloader generated from the Angstrom build and the bootloader generated from the Yocto build. The result is the same - I have not problem booting an Angstrom uImage or the Dev Kit's default Arago uImage with either bootloaders. However the Yocto generated uImage does not boot with either bootloaders.

I hear you on Timesys. It is just that we are a ways down the road with Angstrom, and not looking to change horses now.

Michael

RE: Yocto in the future? - Added by Michael Williamson over 11 years ago

Right,

If I read you correctly, you will need to modify the Yocto recipe to use our kernel URL and not Yocto's. This is because the Yocto kernel sources (or anyone else's at the moment, until we upstream stuff) does not have a MACHINE specification for the MityARM-3359 or the board-mityarm335x.c file needed to initialize the kernel. The u-boot will pass to the kernel our machine code, but the Yocto kernel will not know have to manage it... or am I misunderstanding you?

-Mike

RE: Yocto in the future? - Added by Michael Karasoff over 11 years ago

Mike,

I think the kernel source were coming from Critical Link's git repo - this line is in the linux-mityarm-335x_3.1.bb file:

SRC_URI = "git://support.criticallink.com/home/git/linux-mityarm-335x.git;protocol=git;branch=${BRANCH} "

And it appears the kernel is building out of tmp/work/mityarm335x-poky-linux-gnueabi/linux-mityarm-335x-3.1+gitr1+747d507fba118a7defb8875e76d82be532a94b36-r0 - which looks like the Critical Link Repo hash.

When I get a chance, I will verify. Certainly, I would expect something like your describing to cause the issues I am seeing - so there could be something here I am missing.

Thanks for the tip.

Michael

RE: Yocto in the future? - Added by Michael Karasoff about 11 years ago

3.2 Kernel appears to run fine under Yocto (denzil-9.0.0).

RE: Yocto in the future? - Added by Jonathan Cormier about 11 years ago

Thanks Michael for the update. Would you be willing to share the steps you did to get it working or maybe just the working .bb files?

Thanks
Jonathan

RE: Yocto in the future? - Added by Michael Karasoff about 11 years ago

Sure. First I should make clear the Yocto version - it is dylan-9.0.0 , not denzil. This is also Yocto/Poky... lately Yocto has been claiming Angstrom and Linaro, though I can't say I completly get the nuance here... if anyone can explain this, it would be helpful. I picked this version rather abritrarily, though I also tried a later version - dylan-9.0.2 - which failed to build.

Also, I still haven't been able to build u-boot under Yocto yet - for now I just have Yocto build the beagle-bone bootloader as a placehold and build the CL mityarm bootloard separately with the Arago toolchain as described in the wiki (making sure to set the 4K option for 512).

Here is what I did:

~/yocto$ git clone git://git.yoctoproject.org/poky

~/yocto$ cd poky

~/yocto/poky$ git checkout dylan-9.0.0

~/yocto/poky$ cd ../; source poky/oe-init-build-env mityarm

~/yocto/mityarm/$ yocto-bsp create mityarm arm
<Select "NO" to default kernel, Select Custom Kernel, and then Enter the repo for mityarm kernel source>
<Select default boot address (0x80008000)>
<Select omap3_beagle_config as the boot loader>

~/yocto/mityarm/$ vi ./meta-mityarm/conf/machine/mityarm.conf
<Modify file as needed (eg.  IMAGE_FSTYPES, SERIAL_CONSOLE)>

~/yocto/mityarm/$ bitbake core-image-minimal

From this, I put the RFS, modules, and uImage located in ~/yocto/mityarm/tmp/deploy onto an SDCARD formatted as described in the CL Wiki and then boot.

I'll update the steps for bootloader if/when I get around to that.

RE: Yocto in the future? - Added by Michael Karasoff about 11 years ago

One other thing... you will need to set defconfig to the appropriate config file - it is easiest just to copy this from the repo to meta-mityarm/recipes-kernel/linux/linux-yocto-custom/defconfig .

Also, I set CONFIG_LEGACY_PTYS=y in that defconfig file - yocto like this for bootlogd.

    (1-8/8)
    Go to top
    Add picture from clipboard (Maximum size: 1 GB)