Re: OEM supplied yocto image is impossible to work with
Josef Holzmayr <holzmayr@...>
Sorry to hear that your presumably first contact with Yocto respectively
OpenEmbedded technology is being so painful. Please find some thought
and comments inline.
On Fri, Dec 27, 2019 at 12:00:13PM -0500, Kent Dorfman wrote:
Oh, and this is the THIRD time I've tried posting this...you certainlyWe have, by now.
I've been doing embedded system design since the beginning of the"close" is really somewhat relative here. The words that trigger my
alarm here are "mission critical" and "aerospace". Anything that I will
write below is no legal advice, and not fit for any form of
certification or audit. If these are your requirements, then there are
companies in the Yocto ecosystem that are willing to offer their
Anyway, the OEM for our boards was chosen before I came on board andBSPs are a constant cause of pain for us giving Yocto support too. If
a board vendor screws up, we get to pick up the pieces too many times.
Like most OEMs, their prefered model is to give the customer justLittle to add, besides... that it might have been a bad choice or
negotiation, if you're only now learning that they want to charge you
additionally. Thats something we obviously can't help you with.
Their minimal yocto based SDK and reference implementation:If they are not willing to hand out all sources plus metadata layers,
then thats a total red flag. Yet again, not something we could change.
2) has many closed source packages in it that will only build fromRed flag. Once again.
3) isn't documented at all, and they will only answer direct, wellAnd another one.
4) them being a multinational company causes additional legal,Sorry, I mean... didn't you request at least some form of eval kit? Demo
boards? To actually understand what you are buying?
Up to this point, yes, I can feel your frustration, but there's little
to say other than that you probably have a bad partnership by now.
So now, on to things that I can hopefully say more positive things.
Questions/problems in yocto where the documentation kind of sucks, are:The cleanest without throwing away the whole build that you can do is
remove everything in the build directory besides "conf". Yet there are
probably two sides to your actual question. a "bitbake -c clean
$YOURRECIPE" is the perfect equivalent to make clean, "bitbake
$YOURRECIPE" equivalates to "make". Wiping tmp and sstate cache is
pretty close to a full clean rebuild of the whole system, and no, it
shall not break. If it does, there is either something wrong with your
build setup (can happen) or you hit a bug (happens less often, but
happens too). The second side is actually running a full system rebuild,
which includes the complete build setup. Actually there is no
Yocto-inhernt way to do it, as different people have different needs -
and nobody managed a one size fits all solution until now. You can look
at the autobuilder as provided by the Yocto Project, and at the various
approaches here ;
2) related to above, yocto needs a much better description of theWithin a project? Could you please elaborate?
3) the relationship between bitbake and devtool needs to be betterbitbake and devtool can and should be used side by side. Running bitbake
manually, as you put it, is the definitively primary way of doing
things. So if that eeks out for, there is probably something strange
with your setup. If you can provide a more extensive log or error
message, we will happily...erm, at least honestly try to help.
4) yocto documentation fails in presenting a good explanation of theI tend to agree on the mapping part.
5) a big area that seems to be lacking is the ability to inquire in aNow this is certainly not true. Even in the utmost default setup, a
manifest file will be created along the image which tells you which
packages including version and license that went into it.
bitbake -g $TARGETOFYOURCHOICE will give you a dot file to inspect the
complete dependency graph of your chosen target. This is a bit too much
in-depth at times, but extremely powerful.
And last but not least, its a good practise to have buildhistory enabled
. This offers extremely detailed information about each and every
package and dependency that went into your build, down to each single
file, package size,...
6) the seeming inability of yocto to build reproducable binary imagesThere is work being done on reproductible builds, but we're not there
yet. Might not be the answer you want or need, but the honest state of
7) a large part of me wants to throw away the OEM build and start fromIncluding pre-produced blobs in a Yocto build is not pretty, but often
handy or impossible to avoid. Please see  for the documentation on
Anyway, yes, I've read what docs I can find on yocto, and aside fromIn a nutshell: whenever somebody hands you a binary build, without the
corresponding set of sources and metadata, then you are out of luck and
in for a lot of pain. That exactly the way of how to NOT use yocto when
selling hardware. Some do, and unfortunately we, as the Yocto community
can't do much about it, other than try and help the folks who struggle
with it. And go buy our hardware in another place.
Having said all this. Yes, we know that we have a very steep learning
curve and lots of places to go wrong - yet on the other hand if you make
it through *AND* if it fits your needs, then you are awarded with an
amount of power that is beyond comparison to about any other build
system. But those are two big ifs, yes, and the latter we cannot answer
for you. Only help in the first one.
This might not be the best time of the year as most of us are on
vacation, but feel free to head into #yocto on the freenode network,
where you can easily get in touch with us directly, and we really try to
offer good help and advice. Starting from Jan 7th, you can also expect
better response times :)
And while maybe not an exact fit for you, there still might be
interesting sessions in this playlist for you .
With that, I hope I could give a somewhat helpful but certainly
Software Developer Embedded Systems
Tel: +49 8444 9204-48
Fax: +49 8444 9204-50
R-S-I Elektrotechnik GmbH & Co. KG
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548