Re: [yocto] Virtual machine images from yocto developer day

[William Mills]

On 11/15/2012 01:50 PM, Jeff Osier-Mixon wrote:

On Thu, Nov 15, 2012 at 10:24 AM, Scott Garman  wrote:

On 11/15/2012 04:05 AM, Fredrik Hugosson wrote:

Hi!

Thanks for a great developer day in Barcelona!

Is it possible to get the vdi-files or appliances (which ever it was)
used for the labs? It would save some valuable time when doing labs with
beginners here at work.

Best regards
/Fredrik Hugosson


Which labs? For the intro labs, the computers were running Linux natively. I
took some notes on how I set up those machines I can send you off-list if
you'd like - let me know.

Things *should* just work if you're using a recent release of Ubuntu,
Fedora, or OpenSUSE and follow the setup instructions in our Quick Start
Guide:

https://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html

Just a side note that I should have materials available on the website
by the end of this week


I would encourage the presenters to share the setup instructions also so 
that some one can follow the course ware.  Some of the steps in the labs 
assume setup has been done.

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what's the situation with MIPS support/BSPs/dev kits in yocto?

[William Mills]

On 04/09/2013 07:27 AM, Robert P. J. Day wrote:

On Mon, 8 Apr 2013, Bruce Ashfield wrote:


On 13-04-08 5:59 PM, Robert P. J. Day wrote:


other than the canonical routerstation pro in the meta-yocto-bsp
layer, is there any serious work being put into MIPS machines?  a
quick google didn't seem to find anything, and the rs pro itself was
end-of-lifed a while back (as i recall), so is there something else if
one wants to use yocto on a MIPS dev kit?


From: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2444

MIPS suggested refresh: http://www.ubnt.com/edgemax

.. but I've yet to complete the due diligence on seeing if I can
actually purchase one :) That's going to happen shortly after yocto
1.4 completes.


   i ordered one last night -- total $159.79 (CAD), including
shipping. it took a couple minutes to understand what i was reading
here:


I ordered one just now from the N.C. distributor.  They did not say 
anything about back order so I expect it in a couple of days.


(And no this does not mean anything wrt TI.  It is for my own 
intellectual curiosity.)




http://ubnt.ca/en/8-edgemax

   "edgemax" is simply the generic name for the "platform" -- the
product itself is the edgerouter lite 3 (or "erlite3" as they like to
abbreviate it):

http://ubnt.ca/en/edgemax/61-edgemax.html

so the next shipment comes in on friday to ubnt.ca, at which point
they'll ship one to me.  the admin claims that they're getting in only
a "very limited" number of them on friday, so you can take that with
whatever grain of salt you feel is appropriate, but i wanted one.

rday

p.s. i was interested in a newer MIPS box as a former student of mine
dropped me a note and told me his corp was planning a new product
based on the MIPS SEAD-3:

http://www.mips.com/products/development-kits/mips-sead-3/

but that thing is crazy expensive ($2K USD).


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [ANNOUNCEMENT] Yocto Project 1.4 "dylan" Released.

[William Mills]

On 04/26/2013 06:49 PM, Flanagan, Elizabeth wrote:

All,

I am pleased to announce the availability of the latest major release
of the Yocto Project, "dylan".
gpg signed release notes are available at:

http://downloads.yoctoproject.org/releases/yocto/yocto-1.4/RELEASENOTES.txt


So, I must admit I am slow to actually read the release notes.
However, I am very excited about the availability of the 
meta-yocto-classic layer.
I have my 38 floppy disks ready (37 saved from AOL junk mail offers, and 
1 from Prodigy).

However ftp.cdrom.com does not seem to respond.
How else can I get this great layer?

(I was a little surprised to see mc in the classic list.  I still use it 
everyday and is the first thing I install on any system.)


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Need clarification on some terms

[William Mills]

On 06/12/2013 03:51 PM, Paul D. DeRocco wrote:

For now, I really just need to know if I'm interested in the SDK, since I
have no intention of ever running compilations on my target system.



Trevor's answer has a lot of great background.

My short answer is gcc-cross is for use inside bitbake (in the host) and 
gcc-crosssdk is for use outside of bitbake (still on the host).  This 
outside bitbake use case is the SDK Trevor described.


Why does gcc need to get built differently between these two use cases? 
 I gave up asking this many years ago and accepted it as "something I 
can not change" for my own serenity.  I am sure Paul or Khem could give 
the detail.  The sdk version does have extra stuff to make it 
relocatable etc that is not needed inside of bitbake.  However I don't 
know why we don't always build the sdk-able version.


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] RFC: User configurable recipe features

[William Mills]

On 10/12/2011 12:59 PM, Darren Hart wrote:



On 10/11/2011 04:49 PM, Tim Bird wrote:

On 10/10/2011 11:41 AM, Darren Hart wrote:

As part of working on meta-tiny, I've come across a need (want?) to
present users with the ability to select some set of features in a local
configuration file that will impact the build of the image and a set of
recipes.


Can you tell me more about meta-tiny?  this is the first I've heard
about this (sorry if discussion went by on the mailing list and I
missed it), and I'm very interested.

I'm currently doing some size-related work for Sony (including
some work to support 4K stacks).



Perhaps while I have the attention of a few interested parties, it would
be a good time for a poll. I'm interested in your motivation for smaller
images.


I am not on the front line but here is my take.



Are you building SoC's with memory on die and needing to keep the memory
footprint down to save precious die real-estate?


no.

However we sometimes run the full fileystem from DDR so there is no 
flash per say.  (Full filesystem image gets transfered at boot time). 
Board with N devices, all with DDR and ethernet and nothing else.  Don't 
use NFS for latency/performance consistency issues.




Are you looking at creating mass-market products and saving a few
pennies on the flash storage translates to real money, so you want to
minimize the physical size?


Yes.

We still see flash size == to RAM size or 1/2 RAM.
32 MB RAM, 16 MB Flash
64 MB RAM, 32 MB flash

We had one EVM w/ 8 MB SPI flash and we fit a fairly decent headless 
system into that.  Not sure if that was customer driven or bad EVM 
definition.  Fortunity that EVM also had a MMC/SD card reader for the > 
8MB use case.


Of course once you go above a certain size (128/256 MB), people go 
MMC/SD and then minimums go way up.  1 GB is probably as cheap as 512MB.


We have not seen the situation Tim talked about with RAM < NVMEM (at 
least not for several years)


If you start getting into the oversize microcontroller area then you 
start getting very small.  However you are also probably only a kernel, 
uclibc, a very cut down busybox and one or two custom apps.




Are you concerned with boot time, and have connected larger image sizes
with longer boot times?



That is a nice benefit but not the main objective.

Better use case for seep cases is a partitioned NVMEM configuration with 
small faster flash (32MB-256MB parallel NAND) and slower larger storage 
(1+ GB SD Card etc).


With this config do you:
* treat the NAND as a dynamic FS cache
* use it to store the "core" os (/ but not /usr or /opt)
* use it to store only readahead like data


Is there another motivating factor for your interest in small images?

Thanks,


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] RFC: User configurable recipe features

[William Mills]

On 10/13/2011 04:30 AM, Jack Mitchell wrote:

On 12/10/2011 17:59, Darren Hart wrote:


On 10/11/2011 04:49 PM, Tim Bird wrote:

On 10/10/2011 11:41 AM, Darren Hart wrote:

As part of working on meta-tiny, I've come across a need (want?) to
present users with the ability to select some set of features in a 
local
configuration file that will impact the build of the image and a 
set of

recipes.

Can you tell me more about meta-tiny?  this is the first I've heard
about this (sorry if discussion went by on the mailing list and I
missed it), and I'm very interested.

I'm currently doing some size-related work for Sony (including
some work to support 4K stacks).


Perhaps while I have the attention of a few interested parties, it would
be a good time for a poll. I'm interested in your motivation for smaller
images.

Are you building SoC's with memory on die and needing to keep the memory
footprint down to save precious die real-estate?


no



Are you looking at creating mass-market products and saving a few
pennies on the flash storage translates to real money, so you want to
minimize the physical size?


no



Are you concerned with boot time, and have connected larger image sizes
with longer boot times?


I am concerned with boot time, but don't believe it is image size that 
ramps it up.




Is there another motivating factor for your interest in small images?


Yes, a smaller system which is easier to check, build and maintain. In 
my office I am the leading driver for using linux in a team of 3 (two 
software, one fpga developer) so the less time I spend building, 
rebuilding and checking features I don't need, to ensure they don't 
comprimise the stability of the system, the more faith they have in 
the system I'm putting forward.




Ahhh, nice one Jack.

I had a similar thought this morning.  As the target system gets smaller 
the tolerance for spending X amount of time building non-target code 
goes down and the expectation of being able to use a "modest machine" 
goes up.


What is a modest machine?  Yocto quotes build times for a "refernce 
machine" that is pretty up to date and not on the low end.  To me, a 
modest machine is the laptop Mom & Dad bought "Stacy" when she graduated 
from High School and went off to College.  Stacy is now a junior and is 
exploring embedded Linux.  This might be an i3 2 GB machine.  A China 
based startup may also give its engineers modest machines.  I think many 
TI'ers would claim they have been stuck on modest machines for long periods.


So If a sato image takes 1 hour to build on the reference machine it may 
take 4 hours to build on a modest machine.  Of that time perhaps 1 hr is 
spent building host side stuff.


If your image is just kernel, busybox, and uclibc you probably only 
spend 1/2 hour building that on a modest machine.  Question is does 
oe-core/poky still make you build 1 hr worth of host stuff?


I know Richard's answer will be shared state but I want to see how that 
really works out.  This is an area we plan on playing with over the next 
release cycle.




Thanks,


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Questions from a greenhorn about build problems

[William Mills]

On 10/19/2011 08:43 AM, Rainer Koenig wrote:

Hi all,

I'm using yoctoproject since one week now and got the latest
yocto-1.1/edison-6.0 git tree. I have been able to build core-image-sato
for the Beagleboard xM rev. A and the image works fine.

Now my next goal is to build an image for the TI 8148 EVM board. Since
Yocto is based on OE-core I thought it was a good idea to get the
meta-texasinstruments layer that is listed in the OE wiki:
http://www.openembedded.org/wiki/LayerIndex

So I cloned my git tree for meta-texasinstruments from
git://git.angstrom-distribution.org/meta-texasinstruments

and looked a bit around in that. conf/machine shows a conf for
c6a814x-evm so I replaced the machine "beagleboard" with "c6a814x-evm"
in my local conf.


Rainer:

I think your probably running a bit ahead of us.

Keep in mind that at this point meta-texasinstruments has not been 
tested with the poky layer stack.  It is a work in progress and is being 
tested with a layer stack that includes oe-core + meta-oe + meta-angstrom.


It is certainly in scope for meta-ti (new name) to work w/ a stock poky 
release or snapshot, were just not verified that yet.  As of now our 
plan includes building and testing the following layer combinations:


oe-core + meta-ti
oe-core + meta-ti + meta-openembedded + meta-angstrom
poky + meta-ti
oe-core + meta-ti + meta-openembedded + meta-arago <= TI SDKs

[layer names and order not to scale]

We will keep a mirror of meta-ti active at the angstrom URL are using so 
no worries.  We are also working to publish a mirror on yoctoproject.org.


I would encourage you to subscribe to our brand spanking new meta-ti 
mailing list to discuss, monitor and prod.


https://lists.yoctoproject.org/listinfo/

I don't think any of this explains why you are having proxy issues and 
we will let the rest of the thread play out for that.  I just wanted to 
set your expectations.




I started `bitbake -k core-image-sato` and after builing around 4100 of
the 4221 recipes I got an error on a kernel tree from the arago-project
and from the u-boot compilation. I guess the second error occurs because
of the first error, so I had a better look at the first error.

The buildstats for this packet show, that fetch failed. I tried to fetch
the SRC_URL by hand and it worked without any problem. Note: I'm behind
a firewall, so to clone git://... I need to go over a SOCKS proxy.
Therefore I created an /etc/gitconfig that works fine and the downloads
show, that lots of git-repos from the yocto recipes worked without any
probem, but now those from the meta-texasinstruments layer seem not to
work. I tried a bit around with bitbake -b -D and saw long commandlines
with lots of export before.

It exports a GIT_CONFIG which points to
poky/tmp/sysroots/x86_64linux/usr/etc/gitconfig.

First I replaced this gitconfig with my own gitconfig from /etc, but
that didn't work. Looking at the file structure there it seems that
../sysroots/x86_64linux/ is chroot'ed somehow so I put gitconfig under
that chroot's /etc and now it seems that fetch is working.

So stupid question: Is there a documentation that explains how that
build process is working on the machine/script level and why are the
recipes from yocto behaving different than to the ones that I imported
with the meta-texasinstruments layer?

Best regards
Rainer

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Questions from a greenhorn about build problems

[William Mills]

On 10/20/2011 03:15 AM, Rainer Koenig wrote:

Hi William,


I think your probably running a bit ahead of us.


Yes, looks like. :-) Well, my goal is to be able to build a small
embedded Linux distribution for ARM based SoC boards. Currently we have
the Beagleboard and the TI 8148 EVM to test, but sooner or later there
will be another board available.


Keep in mind that at this point meta-texasinstruments has not been
tested with the poky layer stack.  It is a work in progress and is being
tested with a layer stack that includes oe-core + meta-oe + meta-angstrom.


Yes. I just tried out and ran into problems, that's what makes a
developers life challenging. ;-) I really don't mind about problems as
long as I have hope to fix them.


It is certainly in scope for meta-ti (new name) to work w/ a stock poky
release or snapshot, were just not verified that yet.  As of now our
plan includes building and testing the following layer combinations:

oe-core + meta-ti
oe-core + meta-ti + meta-openembedded + meta-angstrom
poky + meta-ti
oe-core + meta-ti + meta-openembedded + meta-arago<= TI SDKs


Looks good, even that I faild in playing around with oe-core. One thing
that made me fail could be the SOCKS problem that I solved now. Maybe I
give it another test run. Anyway, yocto seems to fit perfectly for my
needs since its well documented and gave me some success events.


For you or any one else listing I should mention that TI SDKs today are 
still based on oe classic.  The layers we use for these are always 
publicly available at http://arago-project.org


If you need something that has been tested by TI today, you may want to 
look there.  If your willing to work through a few bumps and want to 
start on the new baseline then we would be happy to work with you on 
poky/oe-core + meta-ti.


We expect meta-ti to have some boards tested to the above layer stacks 
in November and most/all boards working by the end of the year.  The 
first TI SDKs built from the new structure will be in Q1 2012.





I would encourage you to subscribe to our brand spanking new meta-ti
mailing list to discuss, monitor and prod.


Ok, I subscribed to that list too.


I don't think any of this explains why you are having proxy issues and
we will let the rest of the thread play out for that.  I just wanted to
set your expectations.


That's ok. Looks like the proxy issue is solved and my next obstacle in
the way to success is called u-boot_git.bb. So far I see that this
recipe fails during configure because it wants to make with a rule
"ti8148_evm_config_nand" that is not available in the u-boot sources
that we currently get from git.denx.de.



Humm,  I need to be careful or I may sound like I know what I am doing. 
 However, a quick look[1] makes me think that AM8148 should be using 
u-boot_2010.06-psp.


[1] 
http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/tree/recipes-bsp/u-boot/u-boot_2010.06-psp.bb


There are few things that could be going wrong.  Why don't you move this 
thread to meta-ti and Denys and Koen should be able to help you.



On the other hand I have the TI EZSDK kit available and there is an
u-boot version shipped that covers the TI8148 EVM board, so I guess all
I have to do is to include those sources in the meta-ti layer so that
u-boot will also build for my TI8148 EVM.

Well, I keep on testing and trying things out. Still new to the embedded
world after many years of desktop Linux.

Regards
Rainer

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] couple questions about cleaning up the Quick Start Guide

[William Mills]

On 10/31/2011 11:47 AM, Robert P. J. Day wrote:

On Mon, 31 Oct 2011, Rifenbark, Scott M wrote:


Robert,

Thanks for the stuff and the look here.  Regarding your first point
- I don't have a problem using the real link over the redirect.
The only things that come to mind are if they work why change them?
But, if the community wants the downloads.yoctoproject.org/releases
URL in there I can certainly go in and make changes to master.


   yes, that's a judgment call, someone else can make that decision.
obviously, not a critical change.



I think someone tried to "fix" the quick start based on Robert's input 
and it got broken instead.


The quick start I downloaded on Oct 21 was fine and said:

$ wget http://www.yoctoproject.org/downloads/poky/poky-edison-6.0.tar.bz2

The one I get today from
http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html 


does not work and says:

$ wget 
http://www.downloads.yoctoproject.org/releases/yocto/yocto-1.1/poky-edison-6.0.tar.bz2


If you lose the "www." it should work.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Integrating 3rd Party BSP Layers

[William Mills]

On 01/05/2012 06:44 AM, Jack Mitchell wrote:

Good morning everyone,

I am currently trying to figure out the best way to integrate the
meta-texasinstruments layer with the Yocto provided layers. According to
the meta-texasinstruments readme, it requires the meta-oe, meta-angstrom
and meta-oe-core. Now Yocto provides the stable meta-oe-core (correct?),
so I would clone the meta-oe and meta-angstrom, add them and the
meta-texasinstruments layer to my bblayers.conf then build away, yes?

However, what implications does adding these new layers bring when using
them in the Yocto environment?

Any thoughts would be greatly appreciated on the consequences and/or my
methodology!

The main aim of the game is trying to build an image for the beagleboard
using the meta-texasinstruments layer as to get the latest and greatest
support - with the possibility of using it later in the day when the
beaglebones start appearing but with the stability and additional
support that is acquired through the Yocto umbrella.


Yes, all good goals and within the scope of the plans for meta-ti (aka 
meta-texasinstruments).  However meta-ti is still a work in progress.


By the yocto 1.2 release time frame we plan to support and show the 
following layer combinations:


core stack: oe-core + meta-ti
yocto stack: poky layer set + meta-ti
angstrom stack: oe-core + meta-oe + meta-ti + meta-angstrom
arago stack: oe-core + meta-oe + meta-ti + meta-arago

However at this time the only stack being built is the angstrom 
configuration.

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] build failure on ubuntu 64bits development system

[William Mills]

On 01/18/2012 09:51 AM, Gary Thomas wrote:

On 2012-01-18 07:42, James Abernathy wrote:



On Wed, Jan 18, 2012 at 9:30 AM, James Abernathy 
mailto:jfaberna...@gmail.com>> wrote:




On Wed, Jan 18, 2012 at 7:55 AM, James Abernathy 
mailto:jfaberna...@gmail.com>> wrote:


I just built a new development pc and installed Ubuntu 11.10 
x64.  I wonder if there are any new requirements to building Yocto in 
that environment?  I got an error right
off, but then it complete the first 63 task and stopped 
successfully.  error below:


jim@ubuntu:~/poky/build-cdv$ bitbake core-image-sato
Pseudo is not present but is required, building this first 
before the main build
Parsing recipes: 100% 
|#| Time: 00:00:25
Parsing of 797 .bb files complete (0 cached, 797 parsed). 
1037 targets, 22 skipped, 0 masked, 0 errors.

ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
   File "run_buildstats(e)", line 18, in 
run_buildstats(e=)
   File "buildstats.bbclass", line 21, in 
set_device(e=)
UnboundLocalError: local variable 'rdev' referenced before 
assignment



Any ideas?

JIm A


I went back and tried using the tarballs for poky edison and 
cedartrail bsp and the errors don't occur.  So I'm guessing the issue 
isn't related to Ubuntu 32 vs. 64 bit.



I spoke too soon. Same error in edison tarballs.  I looked at the 
code and I can see an place were rdev could go un assigned. If you 
fell out of the for loop without passing any of
the if conditions, rdev would be unassigned.  That must be what is 
happening in Ubuntu 11.10 x64


Anybody building with Ubuntu 11.10 x64?  This doesn't happen on x32

Jim A


def set_device(e):
 tmpdir = bb.data.getVar('TMPDIR', e.data, True)
 try:
 os.remove(bb.data.getVar('DEVFILE', e.data, True))
 except:
 pass
 

 # We look for the volume TMPDIR lives on. To do all disks would 
make little
 # sense and not give us any particularly useful data. In theory 
we could do
 # something like stick DL_DIR on a different partition and this 
would
 # throw stats gathering off. The same goes with SSTATE_DIR. 
However, let's

 # get the basics in here and work on the cornercases later.
 


 device=os.stat(tmpdir)
 majordev=os.major(device.st_dev)
 minordev=os.minor(device.st_dev)
 for line in open("/proc/diskstats", "r"):
 if majordev == int(line.split()[0]) and minordev == 
int(line.split()[1]):

rdev=line.split()[2]
 file = open(bb.data.getVar('DEVFILE', e.data, True), "w")
 file.write(rdev)
 file.close()


Can you show what the differences are between /proc/diskstats
on the two systems?  That's obviously what's causing the error.



If your build dir is encyptfs or a fuse device or anything that is not a 
direct block device you will get this error.  This is to be fixed in 
1.1.1 but encyptfs will still have other problems.



___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Fwd: build failure on ubuntu 64bits development system

[William Mills]

On 01/18/2012 10:04 AM, James Abernathy wrote:



-- Forwarded message --
From: *William Mills* mailto:wmi...@ti.com>>
Date: Wed, Jan 18, 2012 at 9:57 AM
Subject: Re: [yocto] build failure on ubuntu 64bits development system
To: Gary Thomas mailto:g...@mlbassoc.com>>
Cc: yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>




On 01/18/2012 09:51 AM, Gary Thomas wrote:

On 2012-01-18 07 :42, James Abernathy wrote:



On Wed, Jan 18, 2012 at 9:30 AM, James Abernathy
mailto:jfaberna...@gmail.com>
<mailto:jfaberna...@gmail.com <mailto:jfaberna...@gmail.com>>__>
wrote:



On Wed, Jan 18, 2012 at 7:55 AM, James Abernathy
mailto:jfaberna...@gmail.com>
<mailto:jfaberna...@gmail.com <mailto:jfaberna...@gmail.com>>__>
wrote:

I just built a new development pc and installed Ubuntu 11.10
x64. I wonder if there are any new requirements to building
Yocto in that environment? I got an error right
off, but then it complete the first 63 task and stopped
successfully. error below:

jim@ubuntu:~/poky/build-cdv$ bitbake core-image-sato
Pseudo is not present but is required, building this first
before the main build
Parsing recipes: 100%
|#__| Time: 00:00:25
Parsing of 797 .bb files complete (0 cached, 797 parsed). 1037
targets, 22 skipped, 0 masked, 0 errors.
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File "run_buildstats(e)", line 18, in
run_buildstats(e=)
File "buildstats.bbclass", line 21, in
set_device(e=)
UnboundLocalError: local variable 'rdev' referenced before
assignment


Any ideas?

JIm A


I went back and tried using the tarballs for poky edison and
cedartrail bsp and the errors don't occur. So I'm guessing the
issue isn't related to Ubuntu 32 vs. 64 bit.


I spoke too soon. Same error in edison tarballs. I looked at the
code and I can see an place were rdev could go un assigned. If
you fell out of the for loop without passing any of
the if conditions, rdev would be unassigned. That must be what
is happening in Ubuntu 11.10 x64

Anybody building with Ubuntu 11.10 x64? This doesn't happen on x32

Jim A


def set_device(e):
tmpdir = bb.data.getVar('TMPDIR', e.data, True)
try:
os.remove(bb.data.getVar('__DEVFILE', e.data, True))
except:
pass

##__##__
# We look for the volume TMPDIR lives on. To do all disks would
make little
# sense and not give us any particularly useful data. In theory
we could do
# something like stick DL_DIR on a different partition and this
would
# throw stats gathering off. The same goes with SSTATE_DIR.
However, let's
# get the basics in here and work on the cornercases later.

##__##__
device=os.stat(tmpdir)
majordev=os.major(device.st___dev)
minordev=os.minor(device.st___dev)
for line in open("/proc/diskstats", "r"):
if majordev == int(line.split()[0]) and minordev ==
int(line.split()[1]):
rdev=line.split()[2]
file = open(bb.data.getVar('DEVFILE', e.data, True), "w")
file.write(rdev)
file.close()


Can you show what the differences are between /proc/diskstats
on the two systems? That's obviously what's causing the error.


If your build dir is encyptfs or a fuse device or anything that is not a
direct block device you will get this error. This is to be fixed in
1.1.1 but encyptfs will still have other problems.

I build the Ubuntu 11.10 x64 system with 2 drives setup as Soft RAID 0.
I picked btrfs as the file system for no particular reason. Should I go
back to ext4 or is RAID 0 the problem?


No, I would not do that yet.  I would think software RAID would present 
a block device so would not trigger this error.


>  9   0 md0 133691 0 2218832 0 67133 0 5629616 0 0 0 0
>   9   1 md1 235 0 1880 0 0 0 0 0 0 0 0

Your build dir is in md0 or md1 (wrt your other post)



JIm A

_
yocto mailing list
yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.__org/listinfo/yocto
<https://lists.yoctoproject.org/listinfo/yocto>



___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Fwd: build failure on ubuntu 64bits development system

[William Mills]

On 01/18/2012 10:25 AM, James Abernathy wrote:



On Wed, Jan 18, 2012 at 10:15 AM, William Mills mailto:wmi...@ti.com>> wrote:



On 01/18/2012 10:04 AM, James Abernathy wrote:



-- Forwarded message --
From: *William Mills* mailto:wmi...@ti.com>
<mailto:wmi...@ti.com <mailto:wmi...@ti.com>>>
Date: Wed, Jan 18, 2012 at 9:57 AM
Subject: Re: [yocto] build failure on ubuntu 64bits development
system
To: Gary Thomas mailto:g...@mlbassoc.com>
<mailto:g...@mlbassoc.com <mailto:g...@mlbassoc.com>>>
Cc: yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
<mailto:yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>__>




On 01/18/2012 09:51 AM, Gary Thomas wrote:

On 2012-01-18 07  :42,
James Abernathy wrote:



On Wed, Jan 18, 2012 at 9:30 AM, James Abernathy
mailto:jfaberna...@gmail.com>
<mailto:jfaberna...@gmail.com <mailto:jfaberna...@gmail.com>>
<mailto:jfaberna...@gmail.com <mailto:jfaberna...@gmail.com>
<mailto:jfaberna...@gmail.com <mailto:jfaberna...@gmail.com>>__>__>

wrote:



On Wed, Jan 18, 2012 at 7:55 AM, James Abernathy
mailto:jfaberna...@gmail.com>
<mailto:jfaberna...@gmail.com <mailto:jfaberna...@gmail.com>>
<mailto:jfaberna...@gmail.com <mailto:jfaberna...@gmail.com>
<mailto:jfaberna...@gmail.com <mailto:jfaberna...@gmail.com>>__>__>

wrote:

I just built a new development pc and installed Ubuntu 11.10
x64. I wonder if there are any new requirements to building
Yocto in that environment? I got an error right
off, but then it complete the first 63 task and stopped
successfully. error below:

jim@ubuntu:~/poky/build-cdv$ bitbake core-image-sato
Pseudo is not present but is required, building this first
before the main build
Parsing recipes: 100%
|#| Time:
00:00:25

Parsing of 797 .bb files complete (0 cached, 797 parsed). 1037
targets, 22 skipped, 0 masked, 0 errors.
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File "run_buildstats(e)", line 18, in
run_buildstats(e=)

File "buildstats.bbclass", line 21, in
set_device(e=)

UnboundLocalError: local variable 'rdev' referenced before
assignment


Any ideas?

JIm A


I went back and tried using the tarballs for poky edison and
cedartrail bsp and the errors don't occur. So I'm guessing the
issue isn't related to Ubuntu 32 vs. 64 bit.


I spoke too soon. Same error in edison tarballs. I looked at the
code and I can see an place were rdev could go un assigned. If
you fell out of the for loop without passing any of
the if conditions, rdev would be unassigned. That must be what
is happening in Ubuntu 11.10 x64

Anybody building with Ubuntu 11.10 x64? This doesn't happen on x32

Jim A


def set_device(e):
tmpdir = bb.data.getVar('TMPDIR', e.data, True)
try:
os.remove(bb.data.getVar('DEVFILE', e.data, True))
except:
pass

##__##__

# We look for the volume TMPDIR lives on. To do all disks would
make little
# sense and not give us any particularly useful data. In theory
we could do
# something like stick DL_DIR on a different partition and this
would
# throw stats gathering off. The same goes with SSTATE_DIR.
However, let's
# get the basics in here and work on the cornercases later.

##__##__
device=os.stat(tmpdir)
majordev=os.major(device.st_dev)
minordev=os.minor(device.st_dev)

for line in open("/proc/diskstats", "r"):
if majordev == int(line.split()[0]) and minordev ==
int(line.split()[1]):
rdev=line.split()[2]
file = open(bb.data.getVar('DEVFILE', e.data, True), "w")
file.write(rdev)
file.close()


Can you show what the differences are between /proc/diskstats
on the two systems? That's obviously what's causing the error.


If your build dir is encyptfs or a fuse device or anything that
is not a
direct block device you will get this error. This is to be fixed in
1.1.1 but encyptf

Re: [yocto] Fwd: build failure on ubuntu 64bits development system

[William Mills]

On 01/19/2012 08:55 AM, Jim Abernathy wrote:

On 01/18/2012 04:34 PM, Darren Hart wrote:


On 01/18/2012 09:05 AM, Jim Abernathy wrote:


FYI for those wanting to use Soft RAID, make sure you create one very
small primary partition for GRUB2 to put the second part of the
boot-loader in.  Can't use the old process.

I strongly recommend using a separate DISK for your OS installation.
Yocto builds are hard on disks, and RAID 0 increases your risk of
failure in exchange for the added performance. I use a small SSD for my
OS disk and a large RAID0 array of spinning disks for /build and another
array for /virt (where my VM images live - easily recreated).


Learned a few things in this process. I appreciate all the help and advice.

   1. So we know that at least with Edison, btrfs does not work with
  bitbake.


This looks pretty important to me.  Can you create a bug report for this 
Jim?  It may be decided that it is a dup of the one Darren already 
pointed to but I would like to see someone prove that.  It is not clear 
to me why the blockstats feature could not be supported on btrfs so 
could justify seperate tracking anyway.  (The resolution of the one 
Darren pointed to will be to just disable blockstats for filesystem that 
don't have block devices.)



   2. When I rebuilt the system, this time I put the Linux root
  directory on an 80GB SSD. That is where I also have my clone of
  Linux-Yocto repository, poky, and download directory , DL_DIR.
   3. I have create /build with EXT4 format on a Software RAID 0
  (striped) partition, using 2 separate hard drives, to use as the
  working build directory for bitbake. I have a striped swap file on
  the same two drives. But with 8GB or RAM, I shouldn't be using
  that much.

My build times for some of the basic meta-intel BSPs is around 103 minutes.

Jim A




___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] creating global variables in a recipes

[William Mills]

On 02/01/2012 10:49 AM, Joshua Immanuel wrote:

Hello all,

On Wed, 2012-02-01 at 12:07 +0530, Joshua Immanuel wrote:

At present in my custom image recipe I've added the following
lines

 SOME_VARIABLE = "Blah"
 do_bootimg[depends] += "base-files:do_install"

But the contents of ${SOME_VARIABLE} is not available in the
'base-files' recipe. Even

 export SOME_VARIABLE = "Blah"

doesn't solve the problem.


 $ bitbake custom-image -c devshell

In the above devshell I can find the contents of ${SOME_VARIABLE}
available but the content of it is empty in 'base-files' recipe.


In other words, I need to define global variables in a package which can
be used across multiple packages. At present the only option I have is
to export the variable in build/conf/local.conf. IMHO, this doesn't feel
like a proper solution (as the variable is my layer specific). Moreover,
I can't change the value of it in one package to be used in other
package(s).

Is there any other way to do this? Please guide me.



I am not sure I can give you a better option that local.conf but I can 
explain why what your doing does not work.


It may feel from your usage that the image recipe is the ancestor of all 
the recipes but this is really not true.  The settings in a image recipe 
effect the assembly of that image and not the packages that they depend 
on.  An image could be assembled from packages that were built long ago 
or inherited via shared state.


settings in local,conf on the other hand affect all recipes.  If you add 
something there it will be seen by all recipes.  Unfortunately this 
means that all recipes are dependent on the settings and everything will 
need to be rebuilt in case the new setting effects them.  I believe this 
also means you will not be able to used share state with someone with a 
different setting of (or unset) SOME_VARIABLE.  (Well you can but you 
will both be rebuild everything.)


Alternatives to the whole approach are to make alternative packages for 
the various cases (busybox-minimal vs busybox-full) or use an image task 
to create an asset in the file system that then makes a difference at 
run time.



Regards
Joshua



___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [pull-sys940x 3/4] genmac: Replace RANDOM_MAC in network/interfaces with a randomly generated MAC

[William Mills]

On 02/01/2012 05:26 PM, Darren Hart wrote:

For machines that do not have a MAC in hardware and with drivers that don't
generate a random one in the kernel, this init script will replace the string
RANDOM_MAC in the network/interfaces file with one generated with "ranpwd -m".
Care is taken to ensure multiple interfaces can use RANDOM_MAC and receive
unique addresses. ranpwd generates MACs with the locally administered bit set
and the multicast bit disabled.

Signed-off-by: Darren Hart
---
  meta-sys940x/recipes-bsp/genmac/files/genmac |   46 ++
  meta-sys940x/recipes-bsp/genmac/genmac.bb|   30 +
  2 files changed, 76 insertions(+), 0 deletions(-)
  create mode 100644 meta-sys940x/recipes-bsp/genmac/files/genmac
  create mode 100644 meta-sys940x/recipes-bsp/genmac/genmac.bb

diff --git a/meta-sys940x/recipes-bsp/genmac/files/genmac 
b/meta-sys940x/recipes-bsp/genmac/files/genmac
new file mode 100644
index 000..6ca069c
--- /dev/null
+++ b/meta-sys940x/recipes-bsp/genmac/files/genmac
@@ -0,0 +1,46 @@
+#!/bin/sh
+### BEGIN INIT INFO
+# Provides:  Random MAC address generator
+# Required-Start:$syslog
+# Required-Stop: $syslog
+# Default-Start: 2 3 4 5
+# Default-Stop:  0 1 6
+# Short-Description: Set a random MAC for tagged interfaces
+# Description:   Set a random MAC for interfaces with RANDOM_MAC
+### END INIT INFO
+
+# Author: Darren Hart
+# Based on /etc/init.d/skeleton
+
+PATH=/sbin:/usr/sbin:/bin:/usr/bin
+DESC="Set a random MAC for tagged interfaces"
+NAME=genmac
+RANPWD=`which ranpwd`
+SCRIPTNAME=/etc/init.d/$NAME
+
+# Exit if amixer is not installed
+[ -x "$RANPWD" ] || exit 0
+
+do_start() {
+   # Replace every occurance of RANDOM_MAC with a unique locally
+   # administered, unicast, randomly generated MAC address.
+   while grep -q RANDOM_MAC /etc/network/interfaces; do
+   sed -i "1,/RANDOM_MAC/s/RANDOM_MAC/$($RANPWD -m)/" 
/etc/network/interfaces
+   done
+}


So on a non-volatile r/w filesystem this will assign a new random mac to 
each interface on the first boot and reuse that MAC on each subsquent boot.


On a volatile r/w filesystem this will use a new MAC addr for each 
boot.  I guess thats better than nothing and not much to do on a 
volatile system.


What does this do on a ro filesystem?  No network?  network with 
0:0:0:0:0:0 MAC addr? (horror! but I suspect the kernel won't allow 
that).  Certainly this script failing should not cause the rest of boot 
to fail.


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [pull-sys940x 3/4] genmac: Replace RANDOM_MAC in network/interfaces with a randomly generated MAC

[William Mills]

On 02/02/2012 12:19 PM, Darren Hart wrote:

On 02/02/2012 06:09 AM, William Mills wrote:

So on a non-volatile r/w filesystem this will assign a new random mac to
each interface on the first boot and reuse that MAC on each subsquent boot.

Correct.


On a volatile r/w filesystem this will use a new MAC addr for each
boot.  I guess thats better than nothing and not much to do on a
volatile system.

Correct. The alternative would be to try and sort out some kind of hash
based on unique data, maybe dmidecode data - but that's not very
consistent across platforms. I think there is something like this
available for the Beagleboard.



What does this do on a ro filesystem?  No network?  network with
0:0:0:0:0:0 MAC addr? (horror! but I suspect the kernel won't allow
that).  Certainly this script failing should not cause the rest of boot
to fail.

On a read only filesystem with genmac installed and RANDOM_MAC in the
interfaces file, genmac will run and NOT update interfaces. This was
written with the pch_gbe driver in mind. If no MAC is in the EEPROM, the
pch_gbe driver leaves the MAC as 00:00:00:00:00:00 and leaves the
interface down. It will fail any up command until the MAC has been set.
So the subsequent networking script will fail to bring up the relevant
interface. ifconfig -a will list the interface as down and with a MAC of
00:00:00:00:00:00.

Other drivers will assign a random MAC within the kernel, making this
all unnecessary, but David Miller refused this patch for this driver
(despite the precedent).

If you want to use a RO image on a platform with a pch_gbe nic and no
EEPROM, you need to hardcode the generated MAC in the interfaces file.

The alternative would be for me to call this pch_gbe_genmac and have it
call ifconfig directly instead of delegating it to the interfaces file.
But then I would still want to use a config file to store the
first-boot-generated MAC so it was the same across boots. Once I have to
generate a config file, I felt it made more sense to just use
interfaces, and then it makes sense to make it generic (not pch_gbe
specific), and that led me to this implementation.

Seem reasonable?



Yes I think so.  Just wanted to make sure it failed gracefully.   I 
think your doing the best that can be expected.


Thanks for the detail.

[I'm interested as I have a board that might need this.  Not in OE yet, 
but someday ...]


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] creating global variables in a recipes

[William Mills]

On 02/02/2012 05:27 PM, Richard Purdie wrote:

Just a small clarification:


Thanks Richard.  I wondered about that but figured you would jump in if 
I over simplified.


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto Project Quick Start Feedback

[William Mills]

Scott, Darren & All,

First I want to say I am very excited to see this deep and targeted 
discussion on the docs.  I think it says very good things about where 
yocto is as a project.


Just a thought:  Something that often works well in both teaching and 
movies is to start the story right at some action and then go and 
explain how you got there. (No I am not talking about Memento.)


That said, when I first tried Yocto/Poky I was not new to embedded or OE 
and just wanted the meat of how poky expected me to do this.  I really 
did not have an issue skimming and finding what I was looking for and 
the background information aclimated me to some "Yocto-speak" and customs.


I read through the notes & tips.  I thought they were all important and 
I have seen a number of people get caught on each of them.


The only exception I found was the tip of rm_work.  I think this should 
be removed.  We have seen rm_work interfere with sstate and I have not 
seen it decrease the peak disk space needed, just the end state. 
Perhaps this is better than when I last tested.  At any rate I don't 
think we run any automated builds with rm_work enabled so should we 
really be encouraging the new user to try this out?


I don't think we should delete a lot from the QS and any reorder is 
probably fine tunning.


Bill

On 02/24/2012 10:43 AM, Rifenbark, Scott M wrote:

Darren and all,

Good feedback on the YP QS.  Here are my thoughts...

It seems that both Inaky and Mohamed are experienced embedded developers.  From reading 
the thread "New User feedback from Inaky and Mohamed" it was obvious that you 
two know what you are doing in the embedded world.  You guys represent one type of user 
YP needs to address.  Your feedback points out that you are probably finding it tedious 
to wade through a bunch of introductory stuff before getting to a point where you 
actually use something. That is good feedback.

Other users that the YP QS must address consist of people investigating embedded 
development for the first time, non-Linux people, people unfamiliar with open source 
development in general, etc.  Because the target audience of the YP QS is broad, it needs 
to fundamentally flow to satisfy the lowest common denominator - thus, its current flow 
and level of information.  To date, yours is the first feedback that has indicated the QS 
needed to "cut to the chase" so to speak.  This type of feedback is valid and 
would be expected from advanced users such as you.

I can make some changes to the QS structure to better address the advanced 
user.  I can disrupt the advanced user's reading right up front and point them 
off to a section in the QS that essentially does what Darren is proposing as a 
flow here.  The section can be a single page targeted for the advanced user 
that is not interested in introductory material but just wants the nuts and 
bolts.

I will also play around with the color scheme for the Notes and Tips in the QS. 
 This type of feedback is highly subjective.  What one person feels is 
distracting might not be distracting for another.  That said, however, it is 
valid feedback and I will see about toning down the note boxes.  I don't like 
footnotes for the type of information I am using for Notes and Tips.  Footnotes 
tend to get lost and are best suited for anecdotal information that a reader 
could do without but for which might be curious.

Thanks for great feedback on the YP documentation.  It is input like this that 
will continue to make YP and its documentation better.

Best,
Scott



-Original Message-
From: Darren Hart [mailto:dvh...@linux.intel.com]
Sent: Thursday, February 23, 2012 6:41 PM
To: Yocto Project
Cc: Rifenbark, Scott M; Perez-Gonzalez, Inaky; Abbas, Mohamed
Subject: Yocto Project Quick Start Feedback

Scott,

I received from first-time-user feedback regarding the quick start page.
I thought it was good stuff that you should here and consider
incorporating into the document.

1) There is too much introduction, education, and Note blocks before
we get the user going. The quick start is really about getting them
going as quickly as possible:

o Package install
o Download
o Build

There are four "pages" of detail before we get to installing
packages. 6 before we run any Yocto specific commands.

2) It can be confusing about what to download, since we mention the
Yocto Project Download page (which has a ton of stuff on it) before
we tell them to download edison with wget.

3) The Note blocks are huge and distracting for the content. Notes
should probably be light gray on white in a smaller font, rather
than white on dark gray. They distract from the primary content.

4) There probably is no need to separate "The Linux Distribution" from
"The Packages". These convey similar information, and consume a lot
of space doing so.

5) All the information is good, but it would be good to rearrange things
such that a new user can act

Re: [yocto] Yocto Project Quick Start Feedback

[William Mills]

On 02/24/2012 01:05 PM, Rifenbark, Scott M wrote:

The "movie" angle is interesting.  Picture this... the opening 1/2 page sets up the packages 
for Ubuntu, downloads files, builds core-image-sata, and runs qemu.  All this done without even telling 
anyone what YP is.  Follow that by "what just happened... we just built and ran an image using the 
Yocto Project.  Then the QS launches into the "Welcome" stuff and flows on as normal.  That 
would be a unique beginning for a technical manual.


I sense some derision in your word "unique"?  Thats fine, your doing 
most of the work and you have to be happy with it.


However I don't think it is unique.  Yes it would be a bad approuch to 
use in a reference manual but I have found a number of  intros/tutorials 
start this way and I always enjoy the approuch.  Perhaps the QS at only 
9 printed pages is too short to be structured this way.  The QS guide 
itself is just this "taste of the bigger picture" for the full doc set.


As I said, just some thoughts.

Bill
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] proper recipe for building for beagle xM? meta-ti?

[William Mills]

On 02/28/2012 05:28 PM, Robert P. J. Day wrote:

On Tue, 28 Feb 2012, Koen Kooi wrote:


Op 28 feb. 2012, om 22:55 heeft Robert P. J. Day het volgende geschreven:


On Tue, 28 Feb 2012, Bruce Ashfield wrote:


It is true that the beagleboard is a hardware reference board in the
yocto consolidated kernel tree and meta-yocto layers. That means
that it gets the yocto standard QA builds and boot testing.

That being said, if you are looking for the latest + specific
features then you've been pointed in a good direction .. meta-ti
will meet your needs.

As for disentangling and reducing questions in this area .. rest
assured, we are working on it.

  ok, that's perfectly reasonable -- meta-yocto provides a generic,
well-tested product, while the meta-ti layer provides more
leading-edge content, correct?

No, the amount of testing is not the difference, the amount of
support for the board is. Meta-ti supports the camera interfaces, 3d
engine, dsp, crypto engines, expansion boards, etc. Meta-yocto lacks
all that for beagleboard.

   i understand that reasonably well, and i'll make one more
observation, then i'll shut up.

   i cloned the meta-ti layer into my yocto clone, and here's the
majority of the meta-ti README:

= start

This layer depends on:

URI: git://git.openembedded.org/openembedded-core
branch: master
revision: HEAD

URI: git://git.openembedded.org/meta-openembedded
branch: master
revision: HEAD

URI: git://git.angstrom-distribution.org/meta-angstrom
branch: master
revision: HEAD

Currently meta-ti only works with the Angstrom distribution and hence
requires the meta-angstrom layer. There are known issues when using
gcc-4.6 based toolchain from OpenEmbedded-Core, thus gcc-4.5
toolchain, provided by meta-openembedded, is needed. It is planned to
fix these shortcomings in the near future and allow building the base
BSP part of meta-ti with different distributions and layer stacks,
such as: distro-less (only with OE-Core), with Yocto/Poky, with
Angstrom or Arago.

Due to the above, it is now recommended to follow the instructions at
http://www.angstrom-distribution.org/building-angstrom

This will set it up for the OpenEmbedded-core layout instead of the
old "Classic" OpenEmbedded-dev layout. You can optionally tweak
sources/layers.txt and conf/bblayers.conf to (de)select BSP layers.

= end

   by the time i'm done reading that, i'm not sure whether i've been
told i can use yocto as long as i do the necessary prep first, or that
i should give up on yocto and just use angstrom directly.  i'm fine
with either approach, but the README seems to just waffle *totally* on
which strategy to use.

   quite simply, that README seems to provide nothing but more
confusion than anything else.


Congratulations you are the first beta tester for the new README.txt 
language :) (patched two days ago).


Denys: I suggest

change:

"Due to the above, it is now recommended to follow the instructions at
http://www.angstrom-distribution.org/building-angstrom";

to:

"When the other layer combinations are supported instructions will be supplied 
here.
Until that time please see the Angstrom setup instructions below.

*** Angstrom w/ meta-ti Layer Stack setup: ***
Please follow the instructions at
http://www.angstrom-distribution.org/building-angstrom";

etc.


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] proper recipe for building for beagle xM? meta-ti?

[William Mills]

On 03/02/2012 05:33 PM, Robert P. J. Day wrote:

On Fri, 2 Mar 2012, William Mills wrote:

... snip ...


Congratulations you are the first beta tester for the new README.txt
language :) (patched two days ago).

Denys: I suggest

change:

"Due to the above, it is now recommended to follow the instructions
at http://www.angstrom-distribution.org/building-angstrom";

to:

"When the other layer combinations are supported instructions will
be supplied here. Until that time please see the Angstrom setup
instructions below.

*** Angstrom w/ meta-ti Layer Stack setup: ***
Please follow the instructions at
http://www.angstrom-distribution.org/building-angstrom";


   i might try something a bit different.  given that angstrom is the
tested way to go, by all means, point that out and *strongly*
recommend that approach.

   on the other hand, what is the current issue with the yocto/meta-ti
combo?  is it *known* to be broken?  or is it simply not sufficiently
tested?  in cases like that, i see no problem in cautioning people
about it, but telling them that if they're feeling adventurous,
they're welcome to give it a shot but if it breaks, as they say, they
get to keep all the pieces.

   don't discourage people from trying it, but make sure you give
proper instructions for how to use it, that's all.  unless, as i said,
it's really and truly unusable.


We will update the README when it is merely in need of testing.
Today, we know there is code that does not work with GCC 4.6.
Today, we know there are features in the recipes that do not work w/o 
Angstrom.


As soon as we remove the above for even one platform we will update the 
README to reflect an Alpha state for oc-core &| poky layer stack for 
that platform(s).


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] proper recipe for building for beagle xM? meta-ti?

[William Mills]

On 03/02/2012 06:18 PM, Gary Thomas wrote:

On 2012-03-02 15:50, William Mills wrote:



On 03/02/2012 05:33 PM, Robert P. J. Day wrote:

On Fri, 2 Mar 2012, William Mills wrote:

... snip ...


Congratulations you are the first beta tester for the new README.txt
language :) (patched two days ago).

Denys: I suggest

change:

"Due to the above, it is now recommended to follow the instructions
at http://www.angstrom-distribution.org/building-angstrom";

to:

"When the other layer combinations are supported instructions will
be supplied here. Until that time please see the Angstrom setup
instructions below.

*** Angstrom w/ meta-ti Layer Stack setup: ***
Please follow the instructions at
http://www.angstrom-distribution.org/building-angstrom";


i might try something a bit different. given that angstrom is the
tested way to go, by all means, point that out and *strongly*
recommend that approach.

on the other hand, what is the current issue with the yocto/meta-ti
combo? is it *known* to be broken? or is it simply not sufficiently
tested? in cases like that, i see no problem in cautioning people
about it, but telling them that if they're feeling adventurous,
they're welcome to give it a shot but if it breaks, as they say, they
get to keep all the pieces.

don't discourage people from trying it, but make sure you give
proper instructions for how to use it, that's all. unless, as i said,
it's really and truly unusable.


We will update the README when it is merely in need of testing.
Today, we know there is code that does not work with GCC 4.6.
Today, we know there are features in the recipes that do not work w/o
Angstrom.


Can you elaborate on the above? I have been [I think] successfully using
poky+meta-ti
to support internal platform based on DM8148 and DM3730 - meta-ti is the
best choice
for a kernel "jumping off point" for these platforms. So far, I've only
had to make a scant few tweaks to get this combo to work, in particular:


If we can make some simple changes (or document workarounds) that enable 
bare bones support for poky/oe-core that does not break full support in 
Angstrom, I'm all for it.  Even if we have to limit it to a subset of 
boards.


I'll try to give you a better answer Monday.


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SPL_IMAGE, SPL_BINARY, and SPL_SYMLINK definitions

[William Mills]

On 11/25/2013 09:06 AM, Rifenbark, Scott M wrote:

Anyone have descriptions for these three variables?  I would like to document 
them and am wondering if anyone has used them or knows how they work.



SPL is the preloader for U-boot required on some platforms.

The base include for u-boot defines the SPL_IMAGE and SPL_SYMLINK
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-bsp/u-boot/u-boot.inc

One example of use of SPL_BINARY is here:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-bsp/u-boot/u-boot_2011.12.bb

So the SPL_BINARY defines the name of the file in the filesystem image.
The SPL_IMAGE and SPL_SYMLINK appear to specific the long version 
specific image file produced by the build and the somewhat shorter 
symlink that points to it.  These will be in a machine specific dir on 
the build machine; the same place the kernel is found.
(The kernel also gets a very long name and a symlink  you can reuse 
wording from the description if you have that already.)


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

[William Mills]

On 04/15/2014 11:31 PM, Khem Raj wrote:

On Tue, Apr 15, 2014 at 6:20 PM, Denys Dmytriyenko  wrote:

On Tue, Apr 15, 2014 at 09:12:30PM -0400, Denys Dmytriyenko wrote:

On Wed, Apr 16, 2014 at 12:36:58AM +0100, Richard Purdie wrote:

On Tue, 2014-04-15 at 15:43 -0400, Denys Dmytriyenko wrote:

I don't yet know what is going on, but building in the same directory with
sources (B = S) makes it work regarless of the path length:

/OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux

So, I just commented out setting kernel-specific B in linux-yocto.inc and any
kernel now boots with long path:

#B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"

I'm copying Richard and Bruce directly to see if they may have a quick insight
and/or accept it as a workaround for the release. I'll keep digging further,
but if anyone cares to verify the above workaround works for them, I would
appreciate. Thanks!


I'm travelling and don't have hardware so I'm limited in what I can look
at right now. I suspect this workaround "works" because it makes the
"beaglebone-standard-build" extra characters on the path. I have a
feeling your -111 test above may have reused sstate or something
like that and given misleading results. I'd be interested in the vmlinux
file from the build above to see if the poky-11 pathnames are in
there (they get stripped out when you create the zImage).


Nope, I was fooled by sstate once, so this time I tested with cleansstate and
compared timestamps of the kernel when it boots - it is definitely the new
one. And to make sure 'beaglebone-standard-build' extra suffix doesn't affect
it, I increased the path length even further - that extra level with 333 is
there to over-compensate, as it was failing before even with just 111 and 222
levels only... Looks like Gary was also able to verify it.

But, you are right about vmlinux - it doesn't have those paths in there any
more! I've seen them there when building with B != S, but they are gone when
building with B = S. Wondering why. You can check it for yourself:

http://arago-project.org/files/short-term/misc/vmlinux-3.14.0-yocto-standard


And, as a follow up, all those long paths in vmlinux when built with B != S
point to sources. Here are few examples:

B != S strings:

/OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/init/main.c
earlycon
4Malformed early option '%s'
3Starting init: %s exists but couldn't execute it (error %d)
...
6Trying to unpack rootfs image as initramfs...
/OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/init/initramfs.c
6rootfs image is not initramfs (%s); looks like an initrd
TRAILER!!!
...
%lu.%02lu BogoMIPS (lpj=%lu)
/OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/arch/arm/vfp/vfpmodule.c
6VFP support v0.3:


B = S same strings:

init/main.c
earlycon
4Malformed early option '%s'
3Starting init: %s exists but couldn't execute it (error %d)
...
6Trying to unpack rootfs image as initramfs...
init/initramfs.c
6rootfs image is not initramfs (%s); looks like an initrd
TRAILER!!!
...
%lu.%02lu BogoMIPS (lpj=%lu)
arch/arm/vfp/vfpmodule.c
6VFP support v0.3:


So, that explains why B = S works regardless of the location, as it doesn't
embed full path to source files...



seemingly there could be rodata segment overflow issue. Can you do the
kernel build with say linker from dora build
and see if it still fails.



It would be interesting to see if the rodata segment (or segment it 
contributes to) between working and non-working versions were crossing

some magic power of 2 value.

Are there two images published from the same build machines with just
the path difference?  I would like to see one that was just under the
wire and one just a bit too long.  Denys, you have that?
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

[William Mills]

On 04/16/2014 03:04 PM, Stefan Stanacar wrote:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=6165

Link to the two kernels at the end of the first comment.



Yes, I found that i bit ago.  Very helpful, thanks.

I have not run them yet (my only BBB is at home)
but I am comparing the objdumps.

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

[William Mills]

On 04/17/2014 03:10 PM, Denys Dmytriyenko wrote:

On Tue, Apr 15, 2014 at 05:07:10PM -0600, Gary Thomas wrote:

On 2014-04-15 13:43, Denys Dmytriyenko wrote:

On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:

Some other things I tried with a "long" TMPDIR path (note that it's the
TMPDIR path that makes the difference - in my tests I've been using
/home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:

* kernel built with gcc 4.7.2 and binutils 2.23.2
* u-boot built with gcc 4.7.2 and binutils 2.23.2
* u-boot from http://downloads.angstrom-distribution.org/demo/beaglebone/
* earlyprintk and CONFIG_DEBUG_LL - no additional output printed

I think we're now at the point where we'd benefit from someone with better
knowledge debugging the issue.


Ok, should we expand the search area? Since this is supposed to be vanilla
3.14 kernel, can we try other platforms and see if they are similarly
affected? I'll try pinging our kernel guys for any ideas...


As far as I know it has only been observed with beaglebone (both white and
black, if it makes a difference). FWIW, qemuarm images from the autobuilder
boot just fine, and apparently the same is true of edgerouter (different
architecture but also uses u-boot).


But do those other platforms use uImage or zImage?


I don't yet know what is going on, but building in the same directory with
sources (B = S) makes it work regarless of the path length:

/OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux

So, I just commented out setting kernel-specific B in linux-yocto.inc and any
kernel now boots with long path:

#B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"

I'm copying Richard and Bruce directly to see if they may have a quick insight
and/or accept it as a workaround for the release. I'll keep digging further,
but if anyone cares to verify the above workaround works for them, I would
appreciate. Thanks!



Verified - I rebuilt the kernel in a working tree with a longer
path (one in fact that had failed before) and it boots fine.

Wonder what ${B} != ${S} is doing wacky...?


Gary, et al,

I've just submitted a patch to oe-core and yocto MLs that fixes this issue -
could you please test it in your setup and confirm? Thanks!



I updated Stefan's bug w/ more explanation.
I verified that Stefan's uImage-bad failed for me and then added the 
following to uEnv.txt:

fdtaddr=0x8800

uImage-bad (and uImage-good) worked w/ the above change to uEnv.txt.
Denys' patch fixes all the defaults in u-boot so that no uEnv.txt change 
is needed.

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

[William Mills]

On 04/17/2014 08:13 PM, Denys Dmytriyenko wrote:
> On Thu, Apr 17, 2014 at 04:25:51PM -0700, Khem Raj wrote:
>> On Thu, Apr 17, 2014 at 2:31 PM, William Mills  wrote:
>>> On 04/17/2014 03:10 PM, Denys Dmytriyenko wrote:
>>>>
>>>> On Tue, Apr 15, 2014 at 05:07:10PM -0600, Gary Thomas wrote:
>>>>>
>>>>> On 2014-04-15 13:43, Denys Dmytriyenko wrote:
>>>>>>
>>>>>> On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:
>>>>>>>>>>>
>>>>>>>>>>> Some other things I tried with a "long" TMPDIR path (note that it's
>>>>>>>>>>> the
>>>>>>>>>>> TMPDIR path that makes the difference - in my tests I've been using
>>>>>>>>>>> /home/paul/poky/build2/much/longer/path/to/tmp). None of this
>>>>>>>>>>> helped:
>>>>>>>>>>>
>>>>>>>>>>> * kernel built with gcc 4.7.2 and binutils 2.23.2
>>>>>>>>>>> * u-boot built with gcc 4.7.2 and binutils 2.23.2
>>>>>>>>>>> * u-boot from
>>>>>>>>>>> http://downloads.angstrom-distribution.org/demo/beaglebone/
>>>>>>>>>>> * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
>>>>>>>>>>>
>>>>>>>>>>> I think we're now at the point where we'd benefit from someone with
>>>>>>>>>>> better
>>>>>>>>>>> knowledge debugging the issue.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ok, should we expand the search area? Since this is supposed to be
>>>>>>>>>> vanilla
>>>>>>>>>> 3.14 kernel, can we try other platforms and see if they are
>>>>>>>>>> similarly
>>>>>>>>>> affected? I'll try pinging our kernel guys for any ideas...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> As far as I know it has only been observed with beaglebone (both
>>>>>>>>> white and
>>>>>>>>> black, if it makes a difference). FWIW, qemuarm images from the
>>>>>>>>> autobuilder
>>>>>>>>> boot just fine, and apparently the same is true of edgerouter
>>>>>>>>> (different
>>>>>>>>> architecture but also uses u-boot).
>>>>>>>>
>>>>>>>>
>>>>>>>> But do those other platforms use uImage or zImage?
>>>>>>
>>>>>>
>>>>>> I don't yet know what is going on, but building in the same directory
>>>>>> with
>>>>>> sources (B = S) makes it work regarless of the path length:
>>>>>>
>>>>>>
>>>>>> /OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
>>>>>>
>>>>>> So, I just commented out setting kernel-specific B in linux-yocto.inc
>>>>>> and any
>>>>>> kernel now boots with long path:
>>>>>>
>>>>>> #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
>>>>>>
>>>>>> I'm copying Richard and Bruce directly to see if they may have a quick
>>>>>> insight
>>>>>> and/or accept it as a workaround for the release. I'll keep digging
>>>>>> further,
>>>>>> but if anyone cares to verify the above workaround works for them, I
>>>>>> would
>>>>>> appreciate. Thanks!
>>>>>>
>>>>>
>>>>> Verified - I rebuilt the kernel in a working tree with a longer
>>>>> path (one in fact that had failed before) and it boots fine.
>>>>>
>>>>> Wonder what ${B} != ${S} is doing wacky...?
>>>>
>>>>
>>>> Gary, et al,
>>>>
>>>> I've just submitted a patch to oe

Re: [yocto] [PATCH 2/2] yocto-bsp: clarify help with reference to meta-intel

[William Mills]

nit of nit

On 04/27/2012 08:01 PM, Darren Hart wrote:

On 04/27/2012 12:00 PM, tom.zanu...@intel.com wrote:

From: Tom Zanussi

+ NOTE for x86- and x86_64-based BSPs: The generated BSP assumes the
+ presence of the of the meta-intel layer, so you should also have a
+ meta-intel layer present and added to your bblayers.conf as well.

Consider:

+ NOTE: For x86- and x86_64-based BSPs, the generated BSP assumes the
+ presence of the of the meta-intel layer. Ensure the meta-intel layer
+ is present and added to bblayers.conf.



Unless I am really mis-reading this I think "presence of the of the" 
should just be "presence of the"

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building linux-yocto kernel for BeagleBone

[William Mills]

On 05/29/2012 12:11 PM, Rudolf Streif wrote:

KMACHINE_beaglebone = "yocto/standard/beagleboard"


Sorry, they are not _that_ close.


Any suggestions would be appreciated.


meta-ti has support for DM37x and for AM335x.  You can observe the 
differences there.



On Sun, May 27, 2012 at 12:34 PM, Sanyaade Adekoya mailto:sanya...@gmail.com>> wrote:

Hi,
According to Ti, BeagleBone is just a small BeagleBoard in a small
factor so a common base like a bare build for BeagleBoard should run
on BeagleBone. I think the is same for OMAP family.




Yes, an AM335x uses the base OMAP family mach-omap2 but a binary kernel 
for the AM/DM35/37 won't work on it.

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to include libstdc++ in an image?

[William Mills]

On 06/30/2012 06:29 PM, Paul Eggleton wrote:

On Saturday 30 June 2012 23:56:18 Koen Kooi wrote:

But do note that if you ship libstdc++ without anything linking to it you
forego on the linking exception to the GPL. That is general is a Very Bad
Thing(TM), so ship a helloword.cpp binary to keep the fsf happy. As an
added bonus the helloworld will drag in the lib automatically.


[citation needed]



I agree with Koen.

I have had discussion with the FSF and others in the open source 
compliance arena.  The first sentence appears to be the prevailing 
interpretation.  I have asked the FSF to clarify its position on the FAQ 
but no luck so far.


Bill
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] edison/denzil patches (post-1.1.2 and 1.2.1)

[William Mills]

On 07/17/2012 04:43 PM, McClintock Matthew-B29882 wrote:

On Tue, Jul 17, 2012 at 3:18 PM, Stewart, David C
  wrote:

Hey Matthew -


From: yocto-boun...@yoctoproject.org [mailto:yocto-
boun...@yoctoproject.org] On Behalf Of McClintock Matthew-B29882
Sent: Monday, July 16, 2012 9:01 AM
I understand. I'm fine with adding stuff to the edison branch for now
and we can worry about another official release sometime in the future
(or never). I'm mostly wanting a place I can tell people to get the
(working) code from for our targets. And ideally it's on
yoctoproject.org and not github.com or git.fsl.com

This comes down to a resource trade-off, which is why I'm replying. :-)

As an open source project and not a product, we have to set some boundaries on how long 
we will put effort on a given release. It also seems prudent to treat our release 
branches consistently as well. Besides tagging branches when we release them, I think we 
want to leave the head of the release branches in some known good state. That known good 
state has always been "passed our release criteria" which includes QA, release 
notes, etc.

This is coming up on a year old, and we released our SDK based off
edison late too so that eats up some of the time that this release was
officially supported. But I would encourage us to support releases for
more than 1 year given the typical embedded product development life
cycle - and support can be arbitrary, I'm not 100% sure it should mean
it's been through a full QA process... but maybe it does too. Maybe we
should time the releases too so they are 4 and 8 months after the
release to get max overlap for that full year.


So what if we create a separate branch off of edison, something like 
edison-fsl? Then you could base your patches against it, but we leave edison in 
the known good state?

That's perfectly fine with me. See my other suggestion below too.


Each company/group still using an old release could create its own 
branch as you suggest.  However, it might make sense to create a generic 
branch of branch so any remaining stranglers could attempt to cooperate 
even w/o official yocto-project resources.


e.g. edison-community-maint



Just for some more context, we just release our SDK off of edison and
I expect plenty of activity around bugfixes and back porting commits.
I would like this work to be available to all attempting to build
edison as well.

I know... I'm in agony that we have run out of resources to continue to put effort into 
edison (or "Eddie" as I call him now). Hopefully the above compromise serves 
your needs and keeps our resource commitment and known good state assumptions in check.

Whatcha think?

I know resources are tight, I also see the appeal of having the head
of edison point at the last release, but... edison proper will miss
out on all our fixes we backport over the next few months as this is
our primary SDK until our next release based off denzil. This does not
seem to be as big as an issue for edison since I don't think many
(any?) others have based an SDK/BSP off this release.

It may become more prudent for denzil if we have multiple interested
parties in maintaining these older releases for longer... I know I
would like to pull in others fixes for denzil for as long as possible.
But how do these other interested parties initiate a QA cycle within
Yocto? Obviously having done their own QA for their own stuff and the
other interested parties did more QA on the others work but never the
full official Yocto QA cycle?

Maybe an official strategy for a staging to release branches is in order?

edison-{staging,experimental,next}



This is another good approach.  However I think after yp has moved on, I 
doubt there is any resources to promote from the last stage to the 
"official".



Then folks can possibly see some potential fixes for their issues in
the experimental branch?

Just sharing my thoughts, I'm not insisting on any particular method
but I would like my edison fixes available somehow on yp.org.

-M


I think Matthew's current need will not be unique.  It would be good to 
think this through and have a published stand-down policy.


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what's the state of building for a (OMAP4460) pandaboard ES?

[William Mills]

On 07/31/2012 11:06 AM, Paul Eggleton wrote:

On Tuesday 31 July 2012 06:43:17 Robert P. J. Day wrote:

   i notice that the current meta-ti layer has a pandaboard.conf file
that refers specifically to the OMAP 4430 -- the original panda.
this weekend, i'd like to build, say, a core-image-minimal for my ES.
is there a writeup anywhere that documents what issues i might run
into regarding the panda versus the panda ES?  thanks.


I'm not sure but I think you probably need to direct this question to the
meta-ti mailing list.

https://lists.yoctoproject.org/listinfo/meta-ti



I did see this question, I just don't have an answer.  We are seeing if 
we can get a part time maintainer for panda lined up.  Right now it is 
just something a few volunteers did a few months ago.  There are no 
product level plans for panda and Yocto.


I hope to get panda on the list of platforms for nightly (or at least 
weekly) builds.  That way the status will be visible.


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] build error pandaboard on master

[William Mills]

On 07/31/2012 09:33 AM, Jim Abernathy wrote:

On 07/31/2012 08:14 AM, Gary Thomas wrote:

On 2012-07-31 06:00, Jim Abernathy wrote:

On 07/31/2012 07:53 AM, Gary Thomas wrote:

On 2012-07-31 05:49, Martin Jansa wrote:

On Tue, Jul 31, 2012 at 07:47:34AM -0400, Jim Abernathy wrote:

On 07/31/2012 07:25 AM, Gary Thomas wrote:

On 2012-07-30 13:11, Gary Thomas wrote:

On 2012-07-30 12:49, Jim Abernathy wrote:

On 07/30/2012 01:16 PM, Gary Thomas wrote:

On 2012-07-30 11:09, Jim Abernathy wrote:

On 07/30/2012 12:57 PM, Gary Thomas wrote:

On 2012-07-30 10:50, Jim Abernathy wrote:

On 07/30/2012 10:21 AM, Gary Thomas wrote:

On 2012-07-30 08:11, Jim Abernathy wrote:

On 07/30/2012 09:56 AM, Gary Thomas wrote:

On 2012-07-30 07:48, Jim Abernathy wrote:

On 07/30/2012 09:15 AM, Gary Thomas wrote:

On 2012-07-30 06:53, Jim Abernathy wrote:

I'm on master branch trying to build core-image-minimal
for the machine "pandaboard". Besides the basics, I
put in
a license statement for cloud9 into local.conf.

My bblayer.conf is as follows:

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

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

BBLAYERS ?= " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/meta-openembedded/meta-oe \
/home/jim/meta-ti \
"

The error I'm getting is:

ERROR: ParseError at
/home/jim/meta-ti/recipes-misc/payload/bonescript.bb:5:
Could not inherit file classes/systemd.bbclass

Build Configuration:
BB_VERSION = "1.15.3"
TARGET_ARCH = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE = "pandaboard"
DISTRO = "poky"
DISTRO_VERSION = "1.2+snapshot-20120730"
TUNE_FEATURES = "armv7a vfp neon cortexa9"
TARGET_FPU = "vfp-neon"
meta
meta-yocto =
"master:7411158e1f980cd71c432026fa2f68ab80e3541e"
meta-oe =
"master:9afc488a1b97bfc5378f139ba04a7a5297b15fdb"
meta-ti =
"master:9bc77dff5f84578e259f8225bfa0656d94a2a60a"

ERROR: Nothing PROVIDES 'pseudo-native'


Try adding this in local.conf:
BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"


BBMASK by itself didn't solve my particular problem. I'll
try the other suggestions and report back.


What other problem do you have? That BBMASK should keep
bitbake from
trying to parse the recipe mentioned above.

Note: I use these layers with Yocto all the time with that
mask...



When I just used the statement:

BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

I got the same error as my original post.


The only way you could get that same error is if you already
have a BBMASK
statement somewhere and this one is being ignored because of
the ?= assignment.


So I started with a clean build again. This time I only added
the BBMASK statement you suggested. I got the following error:

ERROR: No recipes available for:
/home/jim/meta-openembedded/meta-systemd/meta-gnome/recipes-gnome/gdm/gdm_2.32.2.bbappend


/home/jim/meta-openembedded/meta-systemd/meta-efl/recipes-efl/efl/elsa_svn.bbappend


ERROR: Command execution failed: Exited with 1

I'm guessing the BBMASK needs to call out
meta-openembedded/meta-systemd/meta-gnome and meta-efl?


Or don't include those layers - meta-systemd isn't needed by
your
yocto build.


Thanks, that makes more sense now. I removed the layer
meta-systemd from bblayers.conf and used the

BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

statement in local.conf to solves the problem.

What is really causing the problem? Without it dependencies on
meta-systemd are there, but the mask removes that?? Why can you
remove a dependency?


The dependency on systemd comes from this recipe:
meta-ti/recipes-misc/payload/bonescript.bb
The BBMASK is making bitbake ignore that recipe (you don't need
it), hence no dependency.


I got core-image-minimal built without errors, Thanks, now I
need to
ask some questions about booting that image. I'm assuming that I
can follow the instructions on pandaboard.org
for creating the SD card format and just copy the deploy/image/
u-boot, MLO, uImage, and rootfs to the right places and boot the
sdcard in the pandaboard. Anyway, that's what I
tried. I'm connected to the panadboard via serial port and the
U-Boot works and the uImage seems to be found, but I don't get a
login console on the serial port:

U-Boot SPL 2011.12-dirty (Jul 30 2012 - 13:44:03)
Texas Instruments OMAP4430 ES2.1
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img


U-Boot 2011.12-dirty (Jul 30 2012 - 13:44:03)

CPU : OMAP4430 ES2.1
Board: OMAP4 Panda
I2C: ready
DRAM: 1 GiB
MMC: OMAP SD/MMC: 0
Using default environment

In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
reading boot.scr

** Unable to read "boot.scr" from mmc 0:1 **
reading uImage

4176404 bytes read
Booting from mmc0 ...
## Booting kernel from Legacy Image at 8200 ...
Image Name: Linux-3.1.0
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4176340 Bytes = 4 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK

Starting kernel ...

Unco

Re: [yocto] yocto beagleboard.conf -- should it not go away?

[William Mills]

On 09/04/2012 01:18 PM, Darren Hart wrote:



On 09/04/2012 05:20 AM, Bruce Ashfield wrote:

On Tue, Sep 4, 2012 at 4:58 AM, Tomas Frydrych
  wrote:

Hi Bruce,

On 03/09/12 22:08, Bruce Ashfield wrote:

That being said, taking a step back, what are you trying to get out of
meta-yocto in this scenario ?


a) I am targeting multiple chips, including TI Omap and Intel Atom.
meta-yocto is a prerequisite for the various machines in meta-intel, so
I have to include meta-yocto if I want to build images for an Intel
chip. Nothing unusual here.

b) meta-yocto is the Poky distro layer; if you want to use Poky, then
you need meta-yocto.


see above. I misspoke. I don't think there's an intent to make meta-yocto
and meta-ti work together, but oe-core + meta-ti, that's the combo that
makes sense.


oe-core + meta-ti should work or it needs to get fixed.
poky + meta-ti should work or it needs to get fixed.

However I suspect the 2nd is not in the nightly builds yet.

Denys is out for the next few days.  He can comment more when he gets back.

It has been our assumption that there is enough functionality in the 
layer mechanisms that any of the "light weight" BSPs in yocto layer 
could be completely overridden by a more complete layer (meta-ti in this 
example).  In addition the end system integrator should be able to 
override definitions in any BSP layer.


I suspect the current issue is just growing pains for a case that has 
not been tested.  Lets prove that false before taking more drastic action.




The basic problem with meta-yocto is that it combines BSP stuff
(meta-intel prerequisite, Atom&  Beagle config) with distro stuff (Poky,
Yocto branding). That's convenient for doing QA on a limited set of HW,
but suboptimal for real use; BSP layers simply should not be dependent
on distro layers, it largely defeats the purpose of having layers.


Darren: Is it true you can't get @ the Intel BSP's w/o also getting the 
poky distro defs?  That does seem to mixing things a bit.  (I am not 
claiming meta-ti is clean yet but I want to understand the Intel examples.)


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] yocto beagleboard.conf -- should it not go away?

[William Mills]

On 09/04/2012 07:23 PM, Darren Hart wrote:



On 09/04/2012 01:25 PM, William Mills wrote:


Darren: Is it true you can't get @ the Intel BSP's w/o also getting the
poky distro defs?  That does seem to mixing things a bit.  (I am not
claiming meta-ti is clean yet but I want to understand the Intel examples.)



It isn't something we test as part of the QA that we perform. I mostly
expect people building meta-intel to be building with meta-yocto
(although I wouldn't take a hard line on requiring it). That said, I
removed meta-yocto from a meta-intel/meta-fri2 build and removed
DISTRO=poky from my local.conf and successfully built and booted a
core-image-minimal build on an FRI2 this afternoon without any changes.



Thanks!  My confidence is restored.

As long as including meta-yocto does not interfere with other BSPs or 
distros etc then there should be no harm in your assumption.


I would be interested to know what Mentor Graphics and Wind River do on 
their products.  Do they include meta-yocto? (YP is not all about 
comercial OS support but I know these orginatations have done the due 
diligence on layer compatibility for a non-poky distro.)


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] yocto beagleboard.conf -- should it not go away?

[William Mills]

On 09/05/2012 08:48 AM, Richard Purdie wrote:

On Wed, 2012-09-05 at 10:43 +0100, Tomas Frydrych wrote:

On 05/09/12 10:15, Paul Eggleton wrote:

On Wednesday 05 September 2012 09:49:11 Tomas Frydrych wrote:
It has been considered witin OE to be best practice to append to BBPATH and
not prepend, the thinking being that then the search path matches the order of
the layers listed in bblayers.conf rather than the reverse.


Then meta-yocto should follow that convention ... and it needs to be
well documented, with the consequence of breaking that convention
explained, and the terrible punishments to come described in great and
sordid detail. Because this needs to be more than a convention, it needs
to be an article of faith.


I just want to clarify something here.

Its accepted that most layers will append to BBPATH. I do think its
acceptable for a distro policy layer to prepend though and this is why
meta-yocto does this. I don't remember the exact reason right now but
the principle stands.


So how should we resolve the issue in meta-ti for the denzil/1.2 branch?

I think the expediency of prepending sounds right to me.  We can shoot 
for a better fix in 1.3.




The root of the problem is that meta-yocto mixes up policy and hardware
support which is bad. It also means its not compliant with the new Yocto
Project compliance criteria and hence is not Yocto Project Compatible.

Now we've got the compliance criteria sorted out there are some
adjustments that need to be made and I will shortly be cleaving
meta-yocto into two pieces to resolve this. I hadn't looked at this
until now mainly in case there were changes to the criteria.

FWIW I think this shows the strength of those criteria as by following
them, we'd avoid a real world problem here.


I'm glad you are thinking of doing this.  I think it sets a good example 
and is cleaner.


However we will still need priority or namespace to override the 
beagleboard definition in the meta-yocto-bsp (or whatever) layer if it 
contains both the beagleboard reference and the atom-pc.

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd

[William Mills]

On 09/20/2012 04:08 PM, Evade Flow wrote:

To bring this full circle... if you want to build behind a restrictive
firewall using pre-mirrored sources and BB_NO_NETWORK, be aware that
recipes which:

   1. Specify a git repo as the source, and,

   2. Specify the revision to be built using a tag name


will cause your build to abort when bitbake tries to run 'git ls-remote'
to resolve the tag name.  So don't specify SRC_URI like this:


   SRC_URI = 
"git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=v${PV}"

Instead, use:

   SRC_URI = 
"git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=8885ced062131214448fae056ef453f094303805;branch=master"


I added a note about this to the Wiki:

   - 
http://wiki.yoctoproject.org/wiki/How_do_I#Non-networked_Builds_and_Cached_Git_Respositories

I'm still new to Yocto, so someone please chime in if any of this
information is incorrect...



If true, this seems very unfortunate.  This seems to push people in the 
wrong direction.  Is there a reason the fetchers don't pull down the 
tags when they mirror in the first place?


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] I hate busybox!

[William Mills]

On 09/15/2015 10:53 AM, Trevor Woerner wrote:
> On 09/15/15 10:47, Trevor Woerner wrote:
>> The only place busybox (and
>> toybox) are needed today are in the MMU-less-type systems, such as
>> Cortex-Ms etc.
> 
> Actually, the presence or lack of MMU is irrelevant, I meant to single
> out those systems with limited on-SoC flash.
> 

OE-core is capable of building a system that has no GPLv3.
This capability is still important to some users and busybox is needed
for that as I understand.

(Other users want the capability to build a system w/o proprietary code.
 OE serves both needs.)


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Custom kernel headers and SDK

[William Mills]

On 12/10/2015 09:40 AM, Vuille, Martin (Martin) wrote:
> Hi Valentin,
> 
> When we first encountered the need for custom kernel headers, I asked
> a similar question to yours on this list. And what I learned from some of the
> responses was that modifying the standard headers was fraught with
> problems, including the issue that you raise.
> 
> Fortunately, we got away without having to modify and export any standard
> headers, so I dodged that bullet.
> 
> Some ideas that come to mind:
> 
> - Can you install your customized version in ${includedir}/XXX and use the
>   include path search order to make sure the compiler sees it first?

This was the approach we used in a Debian based system.  Applications
that needed to be dependent on the custom capabilities of our kernel
depended on our XXX-kernel-header package and adjusted their include
path to use it first.  All other apps continue to use the standard
kernel headers.  (busybox or tar does not really care about our new
wizbang feature and the Debian distro sure was not going to rebuild them
just for us.)

I see no reason this could not work as well in an OE based distro.

> 
> - Can you include the standard header in a "wrapper" header and make your
>   customizations in the wrapper instead?
> 
> Regards,
> MV
> 
>> -Original Message-
>> From: Longchamp, Valentin [mailto:valentin.longch...@keymile.com]
>> Sent: December 10, 2015 4:47 AM
>> To: Vuille, Martin (Martin); yocto@yoctoproject.org
>> Cc: Brunck, Holger
>> Subject: RE: Custom kernel headers and SDK
>>
>> Hi Martin,
>>
>> Thanks a lot for the suggestion. I had in the meantime come to a simliar
>> solution: define a linux-XXX-headers recipe in our own meta layer where I
>> install the missing kernel headers and then I add this linux-XXX-headers-dev
>> package to our SDK's sysroot thanks to TARGET_TOOLCHAIN_TASK.
>> Your implementation looks fine and I am going to pick some ideas from it.
>>
>> However, I have stumbled upon another problem with this approach: it
>> works well if you add new files to the kernel headers. We unforntunately
>> have at least one uapi file (i2c.h to name it) that is present in the 
>> standard
>> kernel headers where we have our own version with some
>> additions/extensions. If I install our version from ou linux-XXX-headers
>> recipe, bitbake (correctly) complains that this file is provided by 2 
>> packages
>> (linux-libc-headers and linux-XXX-headers). And here I really don't know how
>> to solve this issue. Any ideas/suggestions ?
>>
>> Thanks
>>
>> Valentin
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Bash parser

[William Mills]

On 07/16/2014 06:32 AM, Isak Lichtenstein wrote:

Hi Olof,

Thank you very much for your prompt answer


On 14-07-16 11:36 +0200, Isak Lichtenstein wrote:

In this method I'm using the bash syntax. But a lot of time the parser
doesn't manage to parse my file properly. Examples:

TMP="file1 file2"
read -a scripts <<< $tmp
generates
ShellSyntaxError: expecting here-document name, got '<'

Or

TMP="file1 file2"
scripts=(${TMP})
generate
ShellSyntaxError: LexToken(TOKEN,'${TMP}',0,0)


Other bash commands are parsed properly, but generate an error while
executing them. Example:
TMP="file1, file2"
tmp=${TMP//,/ }
generates
Bad substitution
| WARNING: exit code 2 from a shell command.


Note that these features you describe here are all bash extensions. For Debian
users (and I think Ubuntu users as well?), the default /bin/sh is dash and does 
not
support either of these extensions. There are cases where the bitbake parser 
will
refuse valid portable shell script features as well though, like shell 
arithmetics, e.g.:


Ubuntu default is actually bash.


Ubuntu default login shell is bash.
Default for /bin/sh is to link to dash.
So shell scripts that use
#!/bin/sh
will execute with dash.

You may have changed this on your machine and don't remember.
Many developers do.
I just checked a fresh 14.04 to make sure my knowledge is up to date.
ls -l /bin/sh



  n=$((n+1))


Does a page exist somewhere describing the bash features supported by
the parser and also the execution environment?
Are arrays supported at all?


I don't know of any such documentation, but if you stick to portable shell 
script
features, you should be mostly fine.


Thanks for the advice. Will try to stick to it.

Isak


--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] My config got stuck in the toaster

[William Mills]

On 12/27/2014 10:40 AM, Mills, William wrote:

OK, you are not going to believe me but I swear this really happened ...

I have been playing with YP 1.7 over the break.
I thought I would give toaster a try so I had it running in the background as I 
tried various builds.
Somehow I got into a state where changes to my conf/local.conf file were being 
ignored.
I fixed it by stopping toaster.

Here is the sequence as I remember:

I was doing builds for qemuarm.
At some point I started toaster "source toaster start"
It could have been from a clean build dir but probably I had done a couple of 
test builds first.
For qemuarm I built:
 core-image-minimal, meta-toolchain, core-image-sato, core-image-sato-sdk, 
world
I definitely poked around the toaster UI at some of those builds.
Next in the same build dir (and the same screen session) I edited 
conf/local.conf to
MACHINE = qemux86
I then did core-image-sato again
It built for qemuarm
I double check conf/* and ENV settings.
I rm -rf cache
still builds for qemuarm
I stopped toaster with "source toaster stop"
I rm -rf cache again for safe keeping
I tried core-image-sato again and it started building for qemux86.

I tried to reproduce this with a clean build dir and a trivial target "bitbake -c 
clean ed"
With or without toaster running it always detects the config change and 
rebuilds the cache.
In the process I have now learned that removing the cache dir does not cause a 
reparse as I expected.
However a config change does.

I thought I had a theory w/ persistent bitbake process and files being kept open
but I can't connect the dots and I can't reproduce it.



Actually it is easy to reproduce.

The first time I tried I don't think toaster was starting as port 8000
was busy. I thought I had stopped the other instance but I guess not.

To reproduce this I did this:

yocto$ $ . poky/oe-init-build-env toasted-build
yocto/toasted-build$ source toaster start
yocto/toasted-build$ bitbake -c clean ed
runs with MACHINE = "qemux86"
yocto/toasted-build$ mcedit conf/local.conf
change to MACHINE ??= "qemuarm"
yocto/toasted-build$ bitbake -c clean ed
still runs for qemux86
yocto/toasted-build$ source toaster stop
yocto/toasted-build$ bitbake -c clean ed
runs for qemuarm

Am I starting toaster in the wrong way to be just an observer?
I learned how to start toaster this way from:
https://www.yoctoproject.org/documentation/toaster-manual-17  ->
First link is "How to install and run Toaster locally" ->
https://wiki.yoctoproject.org/wiki/Setting_up_a_local_instance_of_Toaster

The Yocto Project Dev guide say the same thing:
https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#examining-builds-using-toaster


Any Ideas?

BTW: Building "world" does not look nice in toaster.  It list 100s of build targets 
instead of just "world".

Thanks,
Bill


--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] My config got stuck in the toaster

[William Mills]

On 01/05/2015 06:59 AM, Barros Pena, Belen wrote:

On 28/12/2014 00:18, "William Mills"  wrote:



On 12/27/2014 10:40 AM, Mills, William wrote:

OK, you are not going to believe me but I swear this really happened ...


We do believe you :)

https://bugzilla.yoctoproject.org/show_bug.cgi?id=6935



Yep that sounds like another symptom of the same issue.
Thanks.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] My config got stuck in the toaster

[William Mills]

On 12/28/2014 02:16 AM, Barros Pena, Belen wrote:

On 28/12/2014 00:18, "William Mills"  wrote:


BTW: Building "world" does not look nice in toaster.  It list 100s of
build targets instead of just "world".


Anything with "does not look nice in toaster" is probably my problem.

Can I ask you to open an issue in Bugzilla for this, so that we can put
some thought into how to present 'world' builds?



Done.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7110

Thanks.

I also noticed that the "toaster manual" link in the upper corner of the 
UI links to the Hob manual not the toaster manual.


I am running 1.7 code but the URL in templates/base.html looks OK to me.
The website seems to be redirecting this to the hob manual.

I filed the following bug against infrastructure with you in CC.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7111

-- Bill


--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto Realtime tests on beaglebone black

[William Mills]

+ meta-ti
Please keep meta-ti in the loop.

[Sorry for the shorting.  Thunderbird keep locking up when I tried 
replay all in plain text to this message.]


~ 15-02-11, Stephen Flowers wrote:
> Thanks for your input.  Here are results of 1000 samples over a
> 10 second period:
>
> Interrupt response (microseconds)
> standard: min: 81, max:118, average: 84
> rt: min: 224, max: 289, average: 231
>
>Will share the .config later once I get on that machine.

Steve I agree the numbers look strange.
There may well be something funny for RT going on for BBB.
TI is just starting to look into RT for BBB.

I would like to see the cyclictest results under heavy system load for
standard and RT kernels.  The whole point of RT is to limit the max
latency when the system is doing *anything*.

I am not surprised that the standard kernel has good latency when idle.
As you add load (filessystem is usually a good load) you should see that 
max goes up a lot.


Also, as Bruce says, some degradation of min and average and also
general system throughput is expected for RT.  That is the trade-off.
I still think the number you are getting for RT seem high but I don't
know what your test is doing in detail.  (I did read your explanation.)
cyclictest should give us a standard baseline.


On 02/11/2015 10:25 AM, Bruce Ashfield wrote:

On 15-02-11 03:50 AM, Stephen Flowers wrote:


my bad, here is the patch set.
As for load, only system idle load for the results I posted previously.
Will run some cyclic test next.


One thing that did jump out was the difference in config_hz, you
are taking a lot more ticks in the preempt-rt configuration. If
you run both at the same hz, or with no_hz enabled, it would be
interesting to see if there's a difference.

Bruce

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto Realtime tests on beaglebone black

[William Mills]

On 02/12/2015 05:05 PM, Stephen Flowers wrote:


So I ran cyclictest with an idle system and loaded with multiple
instances of cat /dev/zero > /dev/null &



When I suggested filesystem activity I was suggesting getting a kernel
filesystem and a physical I/O device to be active.
The load above is just two character devices so not a ton of kernel
code is active.

If you are interested in pursuing this further I would write a script
that writes multiple files to MMC and then deletes them and do this in
a loop.

Perhaps Bruce knows if there is already a test like this in the
rt-tests.


#cyclictest -a 0 -p 99 -m -n -l 10 -q

I ran this command as shown by Toyoka at the 2014 Linuxcon Japan
[http://events.linuxfoundation.org/sites/events/files/slides/toyooka_LCJ2014_v10.pdf]

to compare against his results for the BBB.  I also threw in xenomai
with kernel 3.8 for comparison.  For the standard kernel HR timers were
disabled.


I believe cyclictest requires HR timers for proper operation.
This may explain the very strange numbers for standard kernel below.



[idle]
preempt_rt: min 12 avg: 20 max: 59
standard: min: 8005 avg: 309985,955 max: 619963985
xenomai: min: 8 avg: 16: max 803

[loaded]
preempt_rt: min 16 avg: 21 max: 47
standard: min: 15059 avg: 67769851 max: 135530885
xenomai: min: 10 avg: 15: max 839



Yes, the RT numbers now look reasonable.

The standard kernel numbers are way out.  I can't believe the average
latency on an idle system was 5 minutes. Perhaps the dependency on HR
timers is more than I expect and without it the numbers are just
bonkers. I would have expected the numbers to have a floor near the tick 
rate w/o HR.

Bruce: Is that really what that number means??

The loaded numbers are smaller for RT and std.  Strange.
It might be that the "load" is not very significant.
Its not really the CPU load that were after.  Instead we are trying to 
activate code paths that have premtption disabled due to critical

sections and locks.

I don't know if your are interested in taking this to ground, but if so 
I would enable HR in std and try a load as I suggest above or is

already included in the rt-tests.
Bruce certainly knows more about this than I do and might suggest a
load script.


Actually the preempt_rt results tie up pretty well with Toyooka above,
leading me to conclude theres something off in my code that could be
optimised - what do you guys think.


Is your test code userspace or kernel space?
You can look at cyclictest to see if you missed something.
The RT wiki also has some examples for RT apps.

https://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-application


Also, I ran a test with preempt_rt at 100Hz and there was maybe 10%
improvement in latency.


That sounds reasonable to me.



Steve

On 12/02/2015 00:35, William Mills wrote:

+ meta-ti
Please keep meta-ti in the loop.

[Sorry for the shorting.  Thunderbird keep locking up when I tried
replay all in plain text to this message.]

~ 15-02-11, Stephen Flowers wrote:
> Thanks for your input.  Here are results of 1000 samples over a
> 10 second period:
>
> Interrupt response (microseconds)
> standard: min: 81, max:118, average: 84
> rt: min: 224, max: 289, average: 231
>
>Will share the .config later once I get on that machine.

Steve I agree the numbers look strange.
There may well be something funny for RT going on for BBB.
TI is just starting to look into RT for BBB.

I would like to see the cyclictest results under heavy system load for
standard and RT kernels.  The whole point of RT is to limit the max
latency when the system is doing *anything*.

I am not surprised that the standard kernel has good latency when idle.
As you add load (filessystem is usually a good load) you should see
that max goes up a lot.

Also, as Bruce says, some degradation of min and average and also
general system throughput is expected for RT.  That is the trade-off.
I still think the number you are getting for RT seem high but I don't
know what your test is doing in detail.  (I did read your explanation.)
cyclictest should give us a standard baseline.


On 02/11/2015 10:25 AM, Bruce Ashfield wrote:

On 15-02-11 03:50 AM, Stephen Flowers wrote:


my bad, here is the patch set.
As for load, only system idle load for the results I posted previously.
Will run some cyclic test next.


One thing that did jump out was the difference in config_hz, you
are taking a lot more ticks in the preempt-rt configuration. If
you run both at the same hz, or with no_hz enabled, it would be
interesting to see if there's a difference.

Bruce



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [xcursor-transparent-theme][Patch] Add several cursors

[William Mills]

On 03/02/2016 07:48 AM, Burton, Ross wrote:
> 
> On 2 March 2016 at 12:45, Johannes Pointner  > wrote:
> 
> I didn't know this option.
> But I think there is still a use case for the
> xcursor-transparent-theme. Because the cursor theme can be set before
> starting a new application without restarting X11.
> 
> 
> How do you handle users switching between applications in that case? Or
> the application crashing and leaving you without a cursor?  If a
> particular application should hide the cursor them it should just hide
> the cursor, if the entire UI shouldn't have a cursor then use -nocursor.
>

How about transparent when last user input was touch-screen but normal
when last input was mouse/touchpad?

This would be done on a per DISPLAY basis not a per app basis.

Of course I don't know where to put that code and if I were doing it
today I would put it into a wayland based arch but ...

> Don't worry, I won't be deleting the transparent theme just yet, but I
> do think it's a hack.
> 
> Ross
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Subjects for YP Developer Day at ELCE

[William Mills]

On 09/09/2016 11:51 AM, Jeff Osier-Mixon wrote:

Hi all - we are in the planning stages for DevDay at ELCE right now,
particularly the advanced track. This track changes every session,
usually to cover the things we are working on hardest - for example,
in San Diego we covered CROPS, devtool, the latest Toaster features,
and much more.

Whether you are able to attend DevDay or not, we would be grateful to
hear your suggestions for subjects to cover in the advanced track. We
are currently planning talks about CROPS, devtool and the ESDK,
Toaster, wic, smack, security, and a few other things. If you have a
burning desire to hear about something specific, please let us know.



*** Status and state of the art for read-only root filesystems.
1) r/o root + tmpfs only for ephemeral systems
2) r/o root + select r/w points (bind-volatile?)
3) r/o root + unionfs r/w

My interest would be in #1 & #2 as it is security related.
r/w mount would be nosuid, nodev, etc and perhaps noexec
A survey of the space should include #3 however.

I know there is a section in the developer manual for the basic 
mechanisms of r/o root but it appears a lot is left as an excrice for 
the user.  Are the full demo images etc?


*** What is the OE/YP response to Ubuntu-core?
4) Can Yocto build transactionally updated-able bundles for kernel and 
core-os/root-fs?

5) Can Yocto [cross-]build snaps or flatpaks?
6) Will snapd (or whatever flatpak needs) become 1st class ecosystem 
components?

Ex: meta-snappy has a lot of good work but is early days
Currently meta-snappy disables AppArmor & seccomp
snapd does only light ns & cgroup control and relies on
  AppArmor to do most of the containment
so snapd w/o AppArmor is a demo
[Arch is no better BTW]

Bill
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Linux Files needed for PXE network boot

[William Mills]

Robert,

I assume no one responded to you because you did not supply enough
information to understand your situation.  (You don't specify what HW
you are using, version of Yocto Project, what DHCP server, etc.)

>From the second message I can tell you are using a X86_64 based
platform.  Is this a commercial PC or a developer board (Minnow etc)?

If I were you I would focus on the UEFI mode as you are closer there.

I am not an X86 UEFI expect but ...


On 04/18/2018 09:38 PM, Raymond Yeung wrote:
> Another thing I haven't tried is to set up NFS.  Can we simply specify
> ONE file (similar to .hddimg) that could be tftp over to target, and
> expect it to boot up?  Could this be the cause of my problem?
>

Yes, Grub should be able to go back to the TFTP server to get more files.

Alternatively, yes, it is possible (but a bit ugly) to create one file
for the TFTP server that has everything.

It has been 4 years ago now but I did play with Minnow board UEFI and
GRUB via netboot.

What I got working was a single fat Grub binary with kernel and initram
disk included.  I did this because the UEFI on minnow at that time had
trouble using the ethernet from grub but could reliably transfer a large
file before the handoff.  I would hope this is now fixed on minnow and
commercial PCs would not have this issue.

Anyway if you want to see what I did the files are here:
http://arago-project.org/files/short-term/misc/make-netbootia32.tar.bz2

I would not recommend using these binaries (They are 32bit UEFI and old)
but you can see what I did looking at the README.txt file.

> 
> 
> 
> *From:* Raymond Yeung 
> *Sent:* Wednesday, April 18, 2018 6:33 PM
> *To:* yocto@yoctoproject.org
> *Subject:* Re: Linux Files needed for PXE network boot
>  
> 
> I've yet to receive any response to my post below.  I've gone through
> fair amount of experimentation to get my board downloaded successfully
> the first-stage boot loader.  I'd tried pxelinux.0 for legacy BIOS and
> bootx64.efi (also generated in build process) to work with UEFI on
> client side.  However, no luck going any further so far.  Debugging the
> client side is rather cryptic (black box).
> 
> 
> I'm just wondering if it's because of a missing kick-start file
> (ks.conf)?  I've tried "kernel images/.hddimg" (was careful in
> specifying the path relative /tftpboot root directory), also
> bzImage.bin, and the combo of vmlinuz + initrd files.  Neither one of
> the works so far.  When I tried UEFI with bootx64.efi, the client side
> stops at GRUB, complaining "error: no such device:
> ()/EFI/BOOT/grub.cfg."  When I tried legacy BIOS with pxelinux.0, I got
> "PXE-E16: No offer received.  ERROR: Boot option loading failed".
> 
> 
> Any idea anyone?
> 
> 

I believe the () in ()/EFI/BOOT/grub.cfg should have been (tftp) to make
grub go back to the TFTP server for the config file.  Something is not
right in your setup or UEFI to Grub hand-off.  Can you get a Grub shell
prompt?  If so you should be able to debug from there.

Again see the README.txt in the file I referenced above.  It shows how I
configured grub.

> 
> 
> *From:* Raymond Yeung 
> *Sent:* Monday, April 16, 2018 12:42 PM
> *To:* yocto@yoctoproject.org
> *Subject:* Linux Files needed for PXE network boot
>  
> I've a .hddimg image bootable from USB thumb drive.  As part of the
> boot-up, I also could invoke "Serial Install" to transfer such an image
> to SSD, such that in the next round, I could boot from SSD instead.
> 
> What are the files and where do I get them (relative to where I find
> .hddimg) from the build tree, and install them on the tftp server, in
> order to support PXE network booting?  Also, what mechanism do people
> use to transfer this after PXE boot into the SSD, making it bootable?
> 
> Raymond
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] YP sstate example conf file

[William Mills]

Hello,

>From poky warrior tip, file meta-poky/conf/local.conf.sample
"""
#
#SSTATE_MIRRORS ?= "file://.*
http://sstate.yoctoproject.org/2.5/PATH;downloadfilename=PATH";
"""

Should that be 2.7??  Or are you relying on the intelligence of the user
to fix this up?

If the former then it needs to go on a checklist.
If the later then perhaps it would be better to use X.Y or something
that does not appear to work.  Some verbage to suggest the edit would
probably be good as well.

(and no, I did not run it like that. I'm slightly smarted than that.)

https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/local.conf.sample?h=warrior#n235

Thanks,
Bill


William A. Mills
Chief Technologist, Open Solutions, SDO
Texas Instruments, Inc.
20450 Century Blvd
Germantown MD 20878
240-643-0836
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build

[William Mills]

Hi Richard,

On 10/24/19 7:01 AM, richard.pur...@linuxfoundation.org wrote:
> On Thu, 2019-10-24 at 10:03 +, Westermann, Oliver wrote:
>>> On Wed, 2019-10-23 at 15:34 +, Richard Purdie wrote:
 On Wed, 2019-10-23 at 11:23 +, Westermann, Oliver wrote:
 Hey,
 [...]
 Any suggestions on what I'm doing wrong or how to debug this
 further?
>>> Sounds like the sysroot filtering code doesn't know about this
>>> directory and therefore doesn't pass it through to the recipe
>>> sysroot?
>>
>> Sorry to ask dumb questions, but what do you mean by "this
>> directory"?
>> The toolchain directory created by the TI recipe? Shouldn't that be
>> handled by FILES_${PN}?
> 
> If its a target recipe, FILES makes sense.
> 
> If its a native recipe, there are no packages and therefore FILES
> doesn't make sense.
> 
>>> The recipe you link to is for an on target compiler, not one in the
>>> sysroot.
>>
>> Again, might be a stupid missunderstanding on my side: The recipe I
>> linked extracts a precompiled toolchain that is suitable only for
>> x86_64 systems and  allows a "native" package. From my current
>> understanding, a native package is to be used on the build host,
>> which is what I'm intending to do here.
> 
> You are correct, that recipe disables the target version and appears to
> provide a native binary. I can't actually see how it can work though.
> Can you confirm that recipe does work?
> 

Denys can you confirm or add context?

>> I managed to sucessfully add a native recipe for the NXP code signing
>> tool (which is only provided as a precompiled binary as well) which
>> works as expected.
> 
> If you install the binaries into ${bindir} they will. If you place them
> somewhere else which the system doesn't know about, they probably
> won't.
> 
> There are ways to make alternative locations work but I don't see any
> of that in the above recipe.
> 
>>> I'm actually a little surprised you can't use our standard cross
>>> compiler assuming this M4 core is on an ARM chip? It should be a
>>> case
>>> of passing the right options to the compiler to target the M4?
>>
>> I'm totally up for any infos on how to do this! I did google around
>> for recipes for examples that build a non-linux binary using yocto,
>> but I couldn't really find anything or any documentation. But maybe
>> my searchterms (along "build baremetal  arm binary using yocto") were
>> off target. Can you point me at documentation, examples,
>> searchterms..?

I started looking at this thread because I had the same questions.  Is
it possible to make a recipe depend on another version of GCC and
restart the whole GCC build process again with a different config.

Or does this need multi-config?

This is the question I was trying to ask the other day.

> 
> I'm saying I don't think you need a second toolchain. I think you could
> use your existing arm toolchain with the right compiler options.
> 
> See 
> https://stackoverflow.com/questions/28514507/what-makes-bare-metal-tool-chains-special
> 
> So you'd just add the right flags to the compiler, something like:
> 
> XXX-gcc -mcpu=cortex-m4 -march=armv7e-m -ffreestanding -nostdlib -nostdinc
> 
> i.e. tell it which processor to target and not to use standard
> libraries/includes.
> 
> There isn't anything that special about a baremetal compiler except it
> sets some different default flags and is missing the library support.
> 

Really??

Lets start with the fact that the ARM binary toolchain has been tested
with M4 cores.

Then understand that you will need to supply your own gcc compiler
helpers and all stdc functions even the ones that port well like strlen
and memcpy.  (Because everyone should embedded their own unoptimized
memcpy in their projects.)

This works for the kernel and u-boot but they were designed for this and
have many eyes on their version of memcpy etc.  They are also running on
the same CPU core as the Linux user space.

Given this I can believe this would work for CLang/LLVM if M4 support
was enabled at build time.  I am not convinced for GCC.

If the above really works then why does gcc insist on being compiled
again after the c library has been compiled?  I have asked and never got
an answer that I understood.  I have been told that it looks at the c
library headers and changes what it builds into the compiler.  Does all
that magic go away with just -nostdinc and -nostdlib?

I know this works for the kernel but targeting an RTOS or bare-metal for
a very different core would make me nervous.  Especially true if the M4
would need to link libraries that were built outside of OE.

I know I am pushing back hard but I am also hoping you will convince me
I am wrong.

Thanks,
Bill
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build

[William Mills]

On 10/24/19 10:02 AM, richard.pur...@linuxfoundation.org wrote:
> Hi Bill,
> 
> On Thu, 2019-10-24 at 09:43 -0400, William Mills wrote:
>> I started looking at this thread because I had the same
>> questions.  Is it possible to make a recipe depend on another version
>> of GCC and restart the whole GCC build process again with a different
>> config.
>>
>> Or does this need multi-config?
> 
> A different version of gcc would be most easily handled with
> multiconfig, yes.
> 
>> This is the question I was trying to ask the other day.
>>
>>> I'm saying I don't think you need a second toolchain. I think you
>>> could
>>> use your existing arm toolchain with the right compiler options.
>>>
>>> See 
>>> https://stackoverflow.com/questions/28514507/what-makes-bare-metal-tool-chains-special
>>>
>>> So you'd just add the right flags to the compiler, something like:
>>>
>>> XXX-gcc -mcpu=cortex-m4 -march=armv7e-m -ffreestanding -nostdlib
>>> -nostdinc
>>>
>>> i.e. tell it which processor to target and not to use standard
>>> libraries/includes.
>>>
>>> There isn't anything that special about a baremetal compiler except
>>> it
>>> sets some different default flags and is missing the library
>>> support.
>>>
>>
>> Really??
> 
> As I understand it. I'm by no means an expert but I do my best with the
> OE toolchain recipes.
> 
>> Lets start with the fact that the ARM binary toolchain has been
>> tested with M4 cores.
> 
> Sure, I'm not claiming this is a well travelled path. I don't see why
> it shouldn't work though, or why it makes much difference with the
> right compiler options.
> 
>> Then understand that you will need to supply your own gcc compiler
>> helpers and all stdc functions even the ones that port well like
>> strlen and memcpy.  (Because everyone should embedded their own
>> unoptimized memcpy in their projects.)
> 
> Right, that is by definition baremetal.
> 

Well not really.  All the "bare-metal" toolchains I have used come with
a proper libgcc and some conig of newlib that at least gets you usable
strlen and memcpy etc.  How much of the rest of it is usable on your
platform is variable.

This is true of the toolchain Oliver is pointing at and has been true
back to 2007 when I was using codesourcery releases.

>> This works for the kernel and u-boot but they were designed for this
>> and have many eyes on their version of memcpy etc.  They are also
>> running on the same CPU core as the Linux user space.
>>
>> Given this I can believe this would work for CLang/LLVM if M4 support
>> was enabled at build time.  I am not convinced for GCC.
>>
>> If the above really works then why does gcc insist on being compiled
>> again after the c library has been compiled?  I have asked and never
>> got an answer that I understood.  I have been told that it looks at
>> the c library headers and changes what it builds into the compiler.
> 
> I've never understood that either and looked into it. Back in December
> last year, we dropped gcc-cross-initial:
> 
> http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/recipes-devtools/gcc?id=0afd3ac3ada35dd986aaf3be41d7177dc6b71ade
> 

Cool, good to know.

> After that, YP does no longer rebuild gcc after building the c library,
> there is one cross toolchain. That one toolchain is used for all
> different arm targets, its only architecture specific.
> 
> The only thing we do rebuild is libgcc, which is why there is still a
> libgcc-initial and a libgcc, the latter being built after libc. That
> much kind of makes sense.
> 
>>   Does all that magic go away with just -nostdinc and -nostdlib?
> 
> I believe so, yes.
> 
>> I know this works for the kernel but targeting an RTOS or bare-metal
>> for a very different core would make me nervous.  Especially true if
>> the M4 would need to link libraries that were built outside of OE.
>>
>> I know I am pushing back hard but I am also hoping you will convince
>> me I am wrong.
> 
> You're probably right to have some concerns in that its not a well
> travelled path. There are libc specifics encoded into libgcc but I
> can't quite see where they change how gcc behaves other that the
> default option selection.
> 
> Equally there may be something I'm missing.
> 
> For full disclosure, gcc is built against linux-libc-headers wherease
> with baremetal it would be built without headers. I believe that
> changes the default options gcc uses for compiling but not the way the
> compiler itself works.

"baremetal" would be compiled against some config of newlib headers.
newlib has its own issues and many config choices (you get to pick your
threading model: none, bad, or hacky).  For TI-RTOS I think we rebuild
it with a different thread model.

Thanks,
Bill
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto