Mity CPU Platforms » MitySOM-335x (ARM Cortex-A8 Based Products)

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

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

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

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

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

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

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.

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.