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

Hi Ali,

I suspect that someone copied the wiki page over from our ARM A9 products page (MityDSP-L138) which does do a native OE build using the "core" angstrom tree. Sorry about the confusion. We need to clean that page up (well, finish it really). Certainly you'll need to tune your filesystem up for your needs.

For the AM3359, we are currently using the root filesystem from the TI PSP package mention (an arago build, derived from OE classic last time I checked). We have modified the kernel and u-boot to support boot up (git trees are published) with our DevKit, but the main filesystem is the one TI supplies with the Sitara PSP. There were a couple of modifications (mainly script modifications and some small utility programs for DevKit demonstration) laid on top of that, but that is all.

We have been debating over the "value add" of Critical Link making a custom OE rootfs/overlay build for the AM3359, when for the most part the filesystem from the AM3359 devkits provided by TI (their EVM or even the BeagleBone) or images from the Angstrom Narcissus stuff would likely work with little modification other than configuring opkg and adding packages. I have been experimenting with an OE core angstrom build for AM3359, but we haven't released it. I suspect you would want to make your own overlay to merge in your application specific stuff. It's actually not too complicated, though the initial build time is pretty time consuming. You might be able to use a narcissus build for a Cortex-A8 processor as a starting point if you want to bypass (initially) building a full angstrom distro from scratch. My meta overlay area for both the MityDSP-L138 and MityARM-3359 is available if you want to poke around. It's a work in progress though, and some of the recipes for a couple utility programs point to an internal server at the moment.

Typically, customers add .ipk packages onto a base filesystem (you can update the /etc/opkg configuration area to add the Angstrom sites back in to TI's reference file system) and then image that off for configuration management. Of course, you'll need to be able to generate manifests, etc., depending on your your pulling in.

Again, sorry for the confusion. The OE/root filesystem approach for AM3359 is under some discussion, as we may be engaging a third party vendor (e.g., Timesys or Ridgerun or someone like that) to provide OS level support. We are still early in the project for this device in terms of software solutions.

-Mike

As always Mike your timely response is greatly appreciated.

Thanks for the link to the meta overlay, I will definitely take a look at it. We have a couple beaglebones for prototyping and I've been successful in getting custom angstrom images up and running there. I tried using a custom PSP kernel there with stock Angstrom and it wouldn't boot. The same image works perfectly with TI SDK. I didn't think it was worth the time investment to figure out why just yet.

Have you had good luck with starting from a TI SDK base and then migrating to Angstrom via opkg? This may be an approach we try.

One reason I wanted to try Angstrom 2012.05 is because it is really easy to build Qt5/QPA with GPU acceleration against the Angstrom sysroot (http://qt-project.org/wiki/TIBeagleBoard). I tried to do the same following the TI wiki tutorial and have had no luck so far. A prebuilt version of Qt5 in the SDK/image for the MityARM would go a long way towards helping our development efforts.

I think it might also be easier to track upstream PSP progress if the MityARM kernel was simply a set of patches on top of the meta-ti linux kernel recipe patches. For example if you build Angstrom 2012.05 it pulls 3.2.18 straight from TI's git repo and adds a bunch of patches to it. Building through OE may make it easier to check out a new TI kernel and see if the Critical Link patches still apply cleanly.

Again, thanks for the info.

-Ali

Hi Ali,

We've taken the TI SDK base filesystem, tweaked the opkg configuration files to point back at the angstrom feeds and have added stuff to our filesystems. It has worked fairly well, but we haven't made a lot of different projects yet with the MityARM-3359 processor. Primarily just the demo and some factory test images.

As far as tracking the arago kernel, we have tried that with some Davinci stuff, but TI does not treat their PSP kernels as "upstream" repositories but really more like sandboxes. We had hoped to simply provide a series of patches onto the PSPs. In the past, however, TI has frequently rewritten history on their branches with

git push -f ...

We actually need to go back and sort out how to advance the kernel going forward. I had hoped to start tracking the mainline kernel (and submitting support for the MityARM-3359 upstream) or at least the omap2 opensource guys, but that doesn't appear very stable (yet) for AM335x, and it looks like Russel King/TI/etc is requiring device tree submissions now instead of more platform file implementations to cut down the ARM churn. We haven't tackled that either, though for SOM systems device tree is very attractive. The code base seems much different than the PSP after a cursory comparison.

Like I mentioned, I have started to get a 2012.05 build going with qte (4.8, not 5), and the only thing I am stuck on is getting the overlays to recognize our u-Boot recipe (instead of trying to build TI's which doesn't have our configuration in it). Why the root-file system images require a virtual/bootloader to build has always confused me. As soon as I get back to that, I'll let you know. I should be able to push Qt5/QPA once I get over this issue.

-Mike

Hey Mike,

That is unfortunate, I had assumed TI managed their PSP kernel like a normal upstream project. Here's hoping that they get the AM335X with device tree support in mainline stable soon. I'm not sure if you've looked at the recent arago board-am335xevm.c file, but it is a mess trying to support umpteen different cape boards for the beaglebones. Device tree sure would be nice.

Please do let me know when you get to play with Qt5, I know it's still early with only the Alpha being released so far.

Thanks,

Ali

Hello Mike,

I've been poking around some more with Angstrom 2012.05 and Qt5 on our Beaglebone development systems.

It looks like the arago kernel actually has a v3.2-staging branch for integrating AM33X support into the upstream kernel. The Angstrom kernel takes this staging branch and applies a ton of patches (including 80 beaglebone specific patches) to bring the branch from 3.2.0 up to 3.2.23. This might be a reasonable kernel to track, especially if it does eventually move upstream.

It looks like the TI PSP 04.06.00.08 kernel in the 5.05 SDK will be based off a tag of the 3.2 staging branch with some patches: http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/791/p/198179/725858.aspx

Has there been any significant progress on the mainline AM335X support?

My main concern is that we would like to be able to get "upstream" bug fixes and added features (for example crypto acceleration) in a timely manner.

Regards,
Ali

Hello Ali,

I've been watching TI and other folks working against the mainline kernel with AM335x, and it looks far from stable as compared PSP stuff -- though there is a lot of work going on in this area. This is primarily due to the requirement the DT has to work and all the platform glue in the current PSP releases has to be stripped out before making into the mainline. So a bunch of bindings need to be added to pre-existing drivers that are in the mainline. See an example of some of the progress here:

https://mail.google.com/mail/u/0/?shva=1#label/linux%2Fomap/137dae206f380162

They don't have a lot of stuff working in mainline (most storage devices, etc.) for AM335X as compared to the PSP, and we are waiting for that activity to settle down a bit before attempting running mainline linux on MityARM-335x.

We will likely make a MityARM-3359 support branch off of TI's latest PSP (though 4.06.00.08 branch on arago does not appear to have crypto in it yet), but that hasn't happened yet. It should be fairly trivial, as that PSP branch still leverages non-DT bindings and you should be able to just lift our board-mityarm335x and baseboard-mityarm335x-devkit.c files over and build it up. I appreciate your concern, but best I can tell there is still a pretty wide gap between the PSP (3.2 stuff) and the mainline (DT, at 3.5 or 3.6-rcX). I doubt most of the patches to support the AM335x from the PSP branches won't make it to mainline without a fair amount of rework once posted for reviews.

Keep in mind that the TI PSP branches are "branches" that pull in mainline code but don't necessarily have code that will migrate upstream. TI releases these as "production stable" software sets and puts whatever code they feel necessary to make their EVM hardware work correctly. A lot of the code doesn't get "mainlined" because it won't be accepted upstream for one reason or another (e.g., the board-am335x.c file won't get accepted as is because it should be using device tree and not all those arrays of board personality files, USB CPPI 4.1 DMA drivers for MUSB won't get pulled in because the drivers guys want the CPPI 4.1 interface to be refactored as a general DMA driver, not a MUSB specific driver, etc.). I suspect that is why there are 80+ patches in the arago kernel setup for beagle bone. Someone (probably from TI) identified all the PSP patches required for beagle bone and pulled them into the angstrom build. Can't really track that setup too well, and we may need other stuff that is part of the AM335X EVM device set rather than beagle bone.

We want to get the MityARM-3359 to boot from mainline linux kerenl, but I don't think that baseline (3.6-RC) is ready for prime time quite yet. Am I wrong?

-Mike

Mike,

Thanks for the explanation and fast reply as usual. I think you're probably right that the mainline kernel isn't ready for prime-time. I guess the staging branch I found is going to stay in staging for quite some time until TI can resolve all the issues you listed.

I also noticed that you posted Angstrom 2012.05 images for the devkit, I will definitely be checking that out.

Thanks,
Ali

Hey Mike,

I tried to follow your tutorial on building Angstrom here:
http://support.criticallink.com/redmine/projects/armc8-platforms/wiki/Installing_Open_Embedded

And I ran into some snags. I think it fails because the svn repos are pointing to your internal "wanda" server in include/mitydsp-preferred-revs.inc but I can't be sure.

My main interest here is to try and build Qt5 using the instructions here:
http://qt-project.org/wiki/TIBeagleBoard

I've tried building out of tree following TI's instructions/tools from the Graphics SDK and have ended up with nothing but pain. Angstrom seems like the quickest path to a minimal filesystem with Qt5 for embedded support.

Ali Asgar Sohanghpurwala wrote:

Hey Mike,

I tried to follow your tutorial on building Angstrom here:
http://support.criticallink.com/redmine/projects/armc8-platforms/wiki/Installing_Open_Embedded

And I ran into some snags. I think it fails because the svn repos are pointing to your internal "wanda" server in include/mitydsp-preferred-revs.inc but I can't be sure.

My main interest here is to try and build Qt5 using the instructions here:
http://qt-project.org/wiki/TIBeagleBoard

I've tried building out of tree following TI's instructions/tools from the Graphics SDK and have ended up with nothing but pain. Angstrom seems like the quickest path to a minimal filesystem with Qt5 for embedded support.

Sorry, I forgot to include the error message:
ERROR: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Fetch command export HOME="/home/asohangh"; export SSH_AGENT_PID="11488"; export SSH_AUTH_SOCK="/tmp/keyring-a6pzAh/ssh"; export GIT_CONFIG="/local/scratch/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/x86_64-linux/etc/gitconfig"; export PATH="/local/scratch/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/x86_64-linux/usr/bin/armv7a-angstrom-linux-gnueabi:/local/scratch/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/mityarm335x/usr/bin/crossscripts:/local/scratch/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/x86_64-linux/usr/sbin:/local/scratch/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/x86_64-linux/usr/bin:/local/scratch/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/x86_64-linux/sbin:/local/scratch/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/x86_64-linux//bin:/local/scratch/setup-scripts/sources/bitbake/bin:/home/asohangh/nobackup/trunk_bazaar/gizmo/architecture/xilinx/:/usr/local/bin:/usr/bin:/bin:/usr/games:/local/scratch/setup-scripts/sources/openembedded-core/scripts"; LANG=C LC_ALL=C /usr/bin/env svn info http://wanda/svn/mityomap/mityomapl138/trunk/sw/ARM/linux/fbfill/ could not be run:
None
ERROR: Command execution failed: Exited with 1

Regards,
Ali

So the simplest solution would be to build a "stock" image (minimal console image or something). That will at least get you a basic toolchain, bootable kernel and filesystem, and the open source software. Then you can add your own packages.

The SVN stuff that our images pull in is primarily utilities (fbfill, factoryconfig, a couple of other libraries which are not needed to boot and run your application).

We need to extract the source for this out of an SVN repository that unfortunately includes proprietary data to reshare it. It's on the list to do, but not done yet.

Sorry for the inconvenience.

-Mike

Hello,

I am also trying to build Angstrom according to the tutorial on the wiki: http://support.criticallink.com/redmine/projects/armc8-platforms/wiki/Installing_Open_Embedded

I've been successful in the past building and Angstrom for the BeagleBone and BeagleBoard Machines. With the MityArm I am also getting the same error Ali reported. However, prior to the SRCPV error, I'm also getting this error: NOTE: Error expanding variable S | ETA: --:--:--

Worse, after following the wiki instructions, I can no longer perform Angstrom builds for the BeagleBone and BeagleBoard: I now get the "Error expanding variable S" error when attempting to build the BeagleBone and BeagleBoard machines!

Any guidance here would be appreciated. Right now my Angstrom system is hosed.

Thanks,
Michael Karasoff

I was able to recover my BeagleBone and BeagleBoard build environments by removing restoring the EXTRALAYERS ?= "" entry in conf/bblayers.conf. Yay! I suppose there is something in the MityArm layer that is causing this trouble.

Mike,
Can you elaborate on your previous comment regarding building a "stock" image? Would this be building the OE meta-arago-distro, or perhaps some other TI machine in Angstrom?

Thanks,
Michael

I was suggesting to build the mityarm335x machine, or else you won't pick up the u-Boot and Kernel from our git repository that has the needed mods to support the module. What I was suggesting is to build a standard filesystem image, such as the console-image, instead of the mity* images.

e.g.:

MACHINE=mityarm335x bitbake console-image

-Mike

Mike,

Thanks for your quick reply!

Unfortunately, when I run MACHINE=mityarm335x bitbake console-image I still get the errors during the Angstrom parse. I've replicated this on a fresh Ubuntu 12.04 install and on the 10.04 Virtual Box system that CriticalLink ships with its MityARM335x Dev Kit.

I ran the bitbake with additional debug MACHINE=beaglebone bitbake -v -D -D -D -D console-image

With debug, I am seeing errors that point to issues with some of Critical Link's other DSP modules. For instance:
DEBUG: LOAD /home/mike/angstrom/setup-scripts/sources/meta-mitydsp/recipes-bsp/fpga-drivers/../../include/mitydsp-preferred-revs.inc
NOTE: Error expanding variable S
NOTE: Error during finalise of /home/mike/angstrom/setup-scripts/sources/meta-mitydsp/recipes-bsp/fpga-drivers/fpga-driver-modules.bb

and


DEBUG: Cache: /home/mike/angstrom/setup-scripts/sources/meta-mitydsp/recipes-kernel/linux/linux-mitydsp_3.2.bb is not cached
ERROR: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Fetch command export HOME="/home/mike"; export SSH_AGENT_PID="2183"; export SSH_AUTH_SOCK="/tmp/keyring-BIAVQt/ssh"; export GIT_CONFIG="/home/mike/angstrom/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/i686-linux/etc/gitconfig"; export PATH="/home/mike/angstrom/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/i686-linux/usr/bin/armv7a-angstrom-linux-gnueabi:/home/mike/angstrom/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/mityarm335x/usr/bin/crossscripts:/home/mike/angstrom/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/i686-linux/usr/sbin:/home/mike/angstrom/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/i686-linux/usr/bin:/home/mike/angstrom/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/i686-linux/sbin:/home/mike/angstrom/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/i686-linux//bin:/home/mike/angstrom/setup-scripts/sources/bitbake/bin:/home/mike/bin:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/Xilinx/14.4/ISE_DS/ISE/bin/lin:/home/mike/angstrom/setup-scripts/sources/openembedded-core/scripts"; LANG=C LC_ALL=C /usr/bin/env svn info *http://wanda/svn/mityomap/mityomapl138/trunk/sw/ARM/linux/drivers/fpga/* could not be run:

Is it possible that master/HEAD is not the best place to pull the MityDSP mityarm335x Layer from? Do you have any pointers on how to disable the other mitydsp layers from Angstrom's parse?

Thanks,
Michael

Correction:

I ran the bitbake with additional debug MACHINE=mityarm335x bitbake -v -D -D -D -D console-image

I run MACHINE=beaglebone bitbake -v -D -D -D -D console-image prior to adding the meta-mitydsp layer as a baseline.

-Michael

Hi Mike,

I just did an update on the Angstrom git tree and I am getting this error as well. Something has changed on the Angstrom side since I last did the build and clearly there is a problem with our overlay. I will look into it.

Sorry. The penalty with working against a living build system I suppose. Have you considered / looked at TimeSys at all?

-Mike

Mike,

Thanks for looking into this.

Could I solve my problems by referencing the commit where the Angstrom overlay worked in layers.txt?

RE TimeSys - we already have a prototype system and software up and running with Angstrom on a BeagleBone. Ideally I'd be able to migrate the software without changing the base filesystem or toolchain. If TimeSys is my only option, then I'll have to review my development plan. But right now, with the timeframe we are looking at, TimeSys seems like a big change.

Michael

OK [edit] Michael [sorry]. The Git commit levels for all of the builds are included somewhere in the reference filesystems on our files download tab, as I recall. I don't have them handy at the moment, but yes, that should in theory work.

I understand your goal, now. I will see what I can do to help. I will poke around this weekend and see if I can sort this out.

-Mike

Mike,

Thanks much!

For what its worth, we aren't looking for long term support on this. If we can just get a working Angstrom baseline from CriticalLink, we can manage the layer internally moving forward.

Thanks again,
Michael

Mike,

Thanks for the tip on checking the git commits. I was able to build the Angstrom console image.

Here is how I got there:

rm -rf setup-scripts/sources/meta-mitydsp

Changed layers.txt line to this:
meta-mitydsp,git://support.criticallink.com/home/git/meta-mitydsp.git,master,4fa5668f41b8fe8f5160a737f7d2083fd3b0e571


Reconfigured the machine:
MACHINE=mityarm335x ./oebb.sh config mityarm335x

Removed trouble making files:
rm -rf setup-scripts/sources/meta-mitydsp/recipes-bsp/utils
rm -rf setup-scripts/sources/meta-mitydsp/recipes-bsp/fpga-drivers
rm -rf setup-scripts/sources/meta-mitydsp/recipes-bsp/cl-dsplink
rm setup-scripts/sources/meta-mitydsp/include/mitydsp-preferred-revs.inc


Then built the console image:
MACHINE=mityarm335x bitbake console-image

Good to go. Thanks for all of your help!

Michael

After the latest angstrom update, building the console-image program no longer works, but the systemd-image works fine.

Also, I still can't figure out how to get the MLO to build. Using the one shipped with the dev kit seems to work fine.

I take back the comment about console-image build not working. I can build it just fine, and the issue is most certainly user error on my part.