I would like to add that it helps enormously if you introduce yourself to the community properly. When you do not state what your company is, who is your OEM, and write from a gmail account using what looks like a pseudonym, I personally wasn’t entirely sure if you honestly are seeking help or just aiming to start a flame war, and so abstained from answering. Just my two euro cents. Alex On Fri, 27 Dec 2019 at 20.00, Kent Dorfman wrote: > Oh, and this is the THIRD time I've tried posting this...you certainly > don't make the yocto mailing lists easy to subscribe to. > > Lemme appologize in avance because parts of this are going to come > across as rants directed at both our OEM and yocto. Hopefully "yinz" > have thick skins. > > I've been doing embedded system design since the beginning of the > millenium (mostly VXworks, with some linux intel embedded, PPC > cross-dev chain stuff, and bare metal C/C++ microcontrollers) and now > I'm tasked with implementing a very mission critical set of embedded > processors in an aerospace project. I've not used yocto before. The > closest thing being buildroot. > > Anyway, the OEM for our boards was chosen before I came on board and > while I can find no fault with the zynq based hardware, their software > SDK and support is fracking terrible. > > Like most OEMs, their prefered model is to give the customer just > enough information to try and force us to pay them to build a turnkey > solution on our behalf, which is not an option in our enterprise. > > Their minimal yocto based SDK and reference implementation: > > 1) as is, isn't suitable for our mission needs, where we must make > changes to the base image, kernel, and initramfs. They seem to > expect customers to only add on apps to the UBI rootfs and not screw > with anything else. > > 2) has many closed source packages in it that will only build from > source when in their local intranet. Deleting the cache and > attempting a complete source level rebuild consistently fails. > > 3) isn't documented at all, and they will only answer direct, well > phrased questions, instead of volunteering information that meets our > stated goals. > > 4) them being a multinational company causes additional legal, > information sharing, and logistical problems > > Questions/problems in yocto where the documentation kind of sucks, are: > > 1) the necessity to "clean build" is inherent in any software > endeavour, yet the simple equivalent of "make clean && make image" is > nowhere to be easily found in yocto. It is implied that deleting the > tmp/ and sstate_cache/ directories should have the same affect, but is > that safe? What will it break? I need to be confident in the process > when I go scream at the OEM, telling them that their build tool is > incomplete for our air-gapped environment. > > 2) related to above, yocto needs a much better description of the > expected directory tree within a project. > > 3) the relationship between bitbake and devtool needs to be better > documented and both utilities need to be better documented themselves. > trying to run bitbake manually causes path errors (null entry in path) > when in fact, bitbake itself is setting a path somewhere incorrectly. > my path has no null entries or "." in it. > > 4) yocto documentation fails in presenting a good explanation of the > difference between packages, layers, recipes, and images. Also, I've > seen cases where virtual/kernel is used to check-out the kernel to > work on it, yet no virtual/kernel directory exists in the layers > directory tree, so a better explanation of the mapping between real > directories and virtual names is warranted. ... and yes, I know what > BB files are for. > > 5) a big area that seems to be lacking is the ability to inquire in a > yocto build as to what is included in it. This is especially > important if the responsible party didn't actually create the build, > as is our case. We're left with trying to guess what the OEM did, and > why. > > 6) the seeming inability of yocto to build reproducable binary images > is a serious shortcoming in IA environments. The first step in > development for us is to baseline the reference build provided by the > OEM and then make incremental changes to it, but yocto doesn't seem to > have a way to validate that the build done in-house is identical to > the pre-built images supplied on the board. Is there a way to "forced > sequentialize" the yocto process so that images can be reproducable? > > 7) a large part of me wants to throw away the OEM build and start from > scratch, but I have no information about how to correctly import their > "blob only" packages into a separate yocto project. Hell, I am not > convinced that their blobs will remain persistent if I delete the > cache because I don't know whether they were created in their network > and expected to always live in the cache, thus negating the ability > of a customer to do a "clean build" > > Anyway, yes, I've read what docs I can find on yocto, and aside from > falling asleep several times in the process, the docs really are not > helping me with the problem at hand: using an existing yocto build > provided by a possibly unscrupulous vendor. > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#47824): > https://lists.yoctoproject.org/g/yocto/message/47824 > Mute This Topic: https://lists.yoctoproject.org/mt/69288358/1686489 > Group Owner: yocto+owner@lists.yoctoproject.org > Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [ > alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >