Date   

Yocto Technical Team Minutes, Engineering Sync, for December 7, 2021

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for December 7, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolley, Jasper Orschulko, Trevor Gamblin,
Steve Sakoman, Philip Balister, Richard Purdie, Randy MacLeod, Peter
Kjellerstedt, Jan-Simon Möller, Scott Murray, Alexandre Belloni, Tim
Orling, Jon Mason, Bruce Ashfield, Ross Burton, Joshua Watt, Michael
Opdenacker

== project status ==
- 3.5-m1 (kirkstone) to be built this week
- 3.4.1 (honister) out of QA and to be released
- changes to check-layer script leads to improvements to layer README files
- thanks to all for YPS last week
- continue to remove local patches by sending upstream
- rising intermittent issues with AB
- SWAT faltering, large backlog of un-triaged issues

== discussion ==
RP: Ross created graphs related to the changing number of patches and their
state (from 2015 to now) http://www.burtonini.com/yoctometrics/ The patch
status is clearly improving over time both in number and that they are
generally moving upstream. 5 years ago we peaked at 1900 patches, today
we’re at 1270-ish. It’s nice to note how much progress we can make
when we put our resources towards it. Sometimes looking at a patch shows
us that it is no longer required. Upstream is usually receptive, sometimes
it’s just a matter of poking again.

JPEW: i was working on meta-phosh and noticed that libsoup is all messed
up now. there are 2 versions (v2 and v3) and you’re not supposed to
mix-and-match. libsoup2 and 3 were both updated so that if they noticed
the other one, they both hard fail (they call abort() on the process to
kill it). previously things wouldn’t function correctly, now things
won’t run at all. biggest offender is webkitgtk was upgraded to use
libsoup3 but nothing else has been upgraded so anything links in webkitgtk
crashes on startup. there are a surprising number of things in gnome that
crash e.g. settings panel.
Ross: probably easiest to add a packageconfig on webkit so distro maintainers
get to pick
JPEW: it looks like most things will probably switch to libsoup3 when they
update to gtk4 (and won’t switch before then), but for now pretty much
everything in meta-gnome is completely broken. currently libsoup3 is not
used by anything other than webkitgtk
Ross: probably should make libsoup2 the default for now to regress the
breakage
RP: sounds reasonable to me

JPEW: at OEDVM we were talking about open-source projects getting Yocto
compliance. i was working on meta-phosh but not sure what to do next.
maybe next thing is to talk to the board?
RP: not the board, talk to Nico. Nico is the gatekeeper for the compatibility
process, and it goes to the TSC if required after. there are forms on the
website, but the website is iffy, so if you fill in the forms and nothing
happens, then reach out to Nico directly. it’s probably best to just
reach out to Nico directly.

RP: something that may be landing in the next few days, Ross is recommending
that we remove libtool prefix. libtool is prefixed with an architecture
prefix. this is something that OE and buildroot did early on and we’ve
been carrying this for decades. there was a time when it looked like
autoconf was going to mandate that build tools had the cross-compiler
triplet prepended, but autotools looks dead now-a-days. ironically libtool
rejected the patches
Ross: everything it was trying to solve is now solved with recipe-specific
sysroots, and host tools, etc. so everything should just work. any recipe
that has to hand-code libtool work-arounds can all be removed now. i
expect the fallout to be substantial, but the fixes will be to just remove
stuff from recipes. does buildroot still do this?
RP: not sure
Ross: i don’t see any patches for libtool at all (in buildroot)
RP: the cross-compile support in upstream libtool is broken; well, not broken
but inefficient. but, as Ross says, it is obsolete now.
Ross: lots of diffstat lines removed, but it will make the AB explode
AlexB: buildroot has patches for libtool, even multiple versions (see
support/libtool, not package/libtool)
Ross: ah, i was looking in the wrong place
RP: is supporting multiple versions of libtool not a path to madness?
supporting one version is bad enough…
Ross: it looks like it’s doing the same as our patches (i.e. fixing the
relink thing)
RP: yes, buildroot is patching for the the relink thing (which is something we
do as well) but the prefix patch isn’t in buildroot
Ross: i’ll clean this up and post it as an RFC at least
RP: sounds good

Ross: going back to the chart thing, there was talk a while ago about the LF
having a centralized git monitoring/metrics thing?
RP: LFX
Ross: ah yes! is it still going? can we add our stuff into it? it would be
nice to inject out patch data stuff there
RP: they are still doing it, and there are developers actively working on it,
but the people working on it have more pressing things to work on. so the
answer is yes, but not now. there are lots of stuff i’d like to do this
with, e.g. CVE metrics is another. it would be nice to find someone who
would be interested in generating dashboard data for the project from what
we’re producing. we have the ability to inject this stuff, we just need
to generate it
TimO: we need a data scientist

Jon: i sent out an email about inclusive language, please read and respond
RP: where?
Jon: main yocto, oe-devel, oe-core. trying to get the ball rolling to see if
it can land this release
MO: i’m interested, it ties in with documentation
RP: me too

RP: Quentin sent a patch to rename… core-image-master (?) to golden instead.
this is part of the QA test framework and was from a time when we had
ideas about test controllers etc. i checked with the QA team and they
aren’t using it. i did a double-take on that name, it’s not something
i’ve used recently and there haven’t been any patches for it in ages.
i had completely forgotten about its existence, despite being listed as
the maintainer! is anyone using this code?
JPEW: core-image-test-master
ScottM: i had never heard of it before
Ross: i almost ripped it out a few weeks back when i was doing a cleanup
of the QA code. there is someone who is either using that code, or a
derivative of it. i’ll copy them in on that thread so they can have an
opinion. but if it’s not being used then it can probably be deleted.
RP: rather than rename, i’m very tempted to just delete it. it’s not used
and likely broken. even if someone is using it, there are probably better
things they should be doing

RP: there’s another breaking change to one of the tunes that we should
probably fix before M1…
Jon: A72?
RP: yes, thanks. the crypto extension is enabled by default in the tune, but
there’s now an rpi4 that has an SoC that doesn’t enable it. there
are 2 ways to fix this: 1) leave the current tune as-is and create a
-nocrypto variant 2) change the current tune to remove the crypto, then
add a -crypto variant. not sure what path to take; i’m leaning towards
the latter since that fits in better with the rest of the framework even
if it is more disruptive. tune stuff is already complicated, i’d rather
we keep the framework consistent. i also would prefer a better commit
comment
Jon: should i respin their patch with the updated wording? or comment on it to
have them updated it?
RP: either way; preferred to have it before -m1
Jon: just to be clear, this won’t break anything, it’ll just make it
slightly less performant
RP: right, and i think that’s reasonable
ScottM: only meta-raspberrypi is affected by this?
Jon: meta-raspberrypi is broken by this
ScottM: oh right, after this change everyone else will have this off
Jon: right. meta-raspberrypi, meta-rockchip, and possibly a freescale layer
will be affected
JPEW: so just manually re-enable it?
Jon+RP: exactly
Jon: yes, change to cortex-a72 + crypto

RP: anyone using SH4? or anyone know of someone using it?
Randy: nobody we know of (WindRiver)
ScottM: nobody that I know of (AGL)
MO: it’s an SoC for settop boxes (?)
ScottM: maybe Khem would know
RP: Khem is the one who patched it in the past, but not sure if he’s doing
it because he’s using it (or knows someone using it) or if he’s just
doing it because he’s aware of the patches
RP: I came across this as part of the patch clean up exercise; there are some
SH4 patches we’re carrying for glibc. we need to decide if we’re going
to support this going forward. i’m under the impression that if someone
wanted to get SH4 working, they would need more than these glibc patches.
it would probably be better as an external architecture port/layer rather
than odd, random hacks in oe-core
ScottM: if Khem signs off on it then it sounds reasonable to me
RP: i’ll talk to Khem

Peter: i’ve noticed a problem with debug packages with honister. in june
there was a change to remove the attempt-only for complimentary packages,
so they are no longer called with skip-broken complimentary packages. this
hid issues in our packaging. in our case we use gstreamer plugins (bad
maybe) for srtp. the thing is we also have our own plugin for srtp. so
we build the gstreamer plugin for srtp both as part of the gstreamer-bad
package and from our own package. this works fine for the product images
(since each plugin is put in its own package) but the debug symbols are
all put in one package. meaning there is a clash for installing the debug
symbols for both gstreamer and our package. is there any support for
splitting the debug packages (similiar to how the main package is split),
or are debug packages expected to all be all in one package?
JPEW: are you asking if you can split? currently there is one debug package
per recipe
Peter: exactly. but because we are mixing plugins between 2 packages, the
debug symbols clash. i would like the debug packages split just like the
plugin packages are split. and i don’t know how the complimentary stuff
works; and how it knows, for each plugin, that it should pick up the
common debug package rather than the debug package that has the same name
as the plugin package
RP: it’s a good question. i’ve wondered about this in the past. yours
isn’t the only scenario where you can hit this problem. the downside
is the extra impact on the build. generating all these extra packages,
and putting these extra packages into the package feed, etc.. will have
an impact on the overall build and i’m not sure it will make anything
more usable. it would fix some things, but cause other things. i also
wouldn’t underestimate the amount of work involved to get this to work.
RP: the easier fix is to make the files non-overlapping (by renaming)
Peter: the problem is that our srtp is a drop-in replacement, so the plugins
(files) are called exactly the same (they have to be) so you get the same
file in both packages
RP: you could make it a symlink (the debug symbols will be based on the
original file, not the symlink), if you rename the file but made a symlink
that might get around the issue
Peter: interesting idea…
RP: we’ve moving the goal-posts, but i think the symlink path would be
easier
TrevorW: honister-specific?
Peter: yes, there was a change (june 28) in the package manager. previously,
the complimentary packages were built attempt-only=true so dnf was called
with the skip-broken option which ended up hiding the issue. it would
ignore installing one of the packages at random. so previously there was
a chance that symbols wouldn’t be there, and nobody would notice unless
they were specifically needing those symbols. the honister change is an
improvement since it makes it obvious when an issue comes up.
ScottM: it would be nice to have the debug packages setup the same way other
distros do, but if it blows up the build times, then that would probably
not be worth it. it would be nice if someone had the cycles to prototype
it so we’d have the data
RP: it’s probably optimizable to some extent. we have some crazy build times
for things like packaging ltp. for ltp it probably doesn’t matter, but
for perl-modules it probably does. if you add more packages the build time
scales badly. one of the implications would be separate debug symbols for
each kernel module, which would at least double the number of packages in
a kernel build
Peter: for us we’d just do it for gstreamer, since that’s the only one
causing us issues. in an ideal world everything would be handled the same
RP: you can do that and the system will let you do that, but that’s not
a change i’d take into core. currently the policy is to have 1 debug
package per recipe, and that’s not something we’re about to change.
separate debug packages will work, but will affect build times
Peter: i could just remove the debug symbols for one of the packages, and hope
nobody ever needs to debug it
RP: separate debug packages will work, but we’re not going to change the
policy
Peter: i also have a similar problem with hardknott (which still has the
keep-broken option enabled) so i can’t figure that out. similar, but not
the same

TrevorW: there was discussion around having more of a presentation +
discussion style meeting each month at the OE happy hour
Jon: possible, we have done it in the past, we’re open to it, but it’s
hard to get people to do it (and having them do the prep). but having
a YPS gives people something to shoot for. lots of work to do a
presentation, OEHH is more informal. it would need someone or something
to drive it and make it more formal. Paul Barker has done a couple
show-and-tells informally at some OEHHs
TimO: i like the spontaneous show-and-tell
Jon: most people are trained to think in terms of conferences and doing
presentations there. trying to do it informally might make it less likely
to happen. we can take it to the board

RP: i’ve been chatting with Khem and he says the SH4 patches are there
because i wanted them in, so i guess i’ll remove them


Re: Using FreeRadius project on Yocto

Khem Raj
 

On Tue, Dec 14, 2021 at 11:34 AM Rakesh Kumar <rakeshkumar0815@...> wrote:



Hi Team,


I am trying to build radius server with the use of Yocto project and looks like freeradius recipe is already included in meta-openembedded/meta-networking/recipes-connectivity/freeradius


I have included meta-openembedded layer in my conf/bblayers.conf file and built core-image-base image.


But I couldn't see anything related to radius server in my <workspace>/tmp directory


"tmp/work/ccimx6ul/core-image-base/1.0-r0/rootfs/etc/init.d"


Could you please let me know do I need to add anything specific to build radius server apart from using meta-openembedded recipe? I apologize if this is the wrong mailing list.
just adding layer is not enough, you have to add it to your image as well via
IMAGE_INSTALL or some other way as indirect dependency

Thanks much!


Best Regards

Rakesh kumar








Re: Yocto BUILD ENV

Monsees, Steven C (US)
 

 

So, I ran SDK build using “bitbake sbcb-defaults-full –k –c populate_sdk_ext”

 

Everthing builds under the SDK except 1 component … the intel-graphics-compiler-native/1.0.11-r0, which fails a few times for the header file reference shown below.

 

It also appears as though :

 

    /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/hosttools/g++ 

 

Is pointer to the correct devtoolset-8 version

 

I feel as though I am missing something with regards to the EXT SDK env, but not sure what,,,

 

I have tried adding the “source /opt/rh/devtoolset-8/enable” to /etc/bashrc, /etc/profile, and have tried running “scl enable devtoolset-8 bash” prior to build… (all of which work correctly building the standard SDK, and my kernel image which are building in the IGC…

 

Sample error output:

 

| [63/565] /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/hosttools/g++  -DCL_KHR_FP64_EXT -DGHAL3D=USC -DICBE_LINUX -DIGC_CMAKE -DIGC_EXPORTS=1 -DIGC_SPIRV_ENABLED -DINSIDE_PLUGIN -DISTDLIB_UMD -DLINUX -DNDEBUG -DNOMINMAX -DSTD_CALL -DUSC_EXPORTS=1 -DUSE_MMX -DUSE_SSE -DUSE_SSE2 -DUSE_SSE3 -DUSE_SSSE3 -D_AMD64_ -D_COMPILER_DLL_ -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D_IGC_ -D_SCL_SECURE_NO_WARNINGS -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/WrapperLLVM/include -IIGC/autogen -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/.. -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../Common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../3d/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler/API -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../visa/include -IIGC/Release -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL/ocl_igc_shared/executable_format -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL/cif/cif/.. -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler -isystem/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/recipe-sysroot-native/usr/include -pipe -fno-exceptions -fdata-sections -ffunction-sections -O2 -fmessage-length=0 -march=corei7 -mstackrealign -fms-extensions -Werror -Wno-unused-parameter -Wno-missing-field-initializers -Wwrite-strings -Wno-long-long -Wswitch -Wno-sign-compare -Wno-unused-result -Wno-enum-compare -Wno-type-limits -Wno-ignored-qualifiers -Wformat -Wformat-security -Wno-extra -Wno-write-strings -finline -fno-strict-aliasing -msse -msse2 -msse3 -mssse3 -msse4 -msse4.1 -msse4.2 -Wno-unknown-pragmas -fPIC -D_FORTIFY_SOURCE=2 -fstack-protector -finline-functions -funswitch-loops -Wno-maybe-uninitialized -lrt -fno-rtti -fvisibility=hidden -fvisibility-inlines-hidden -std=c++14 -DNDEBUG -g   -std=gnu++14 -MD -MT IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o -MF IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o.d -o IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o -c /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/CShader.cpp

| FAILED: IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o

| /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/hosttools/g++  -DCL_KHR_FP64_EXT -DGHAL3D=USC -DICBE_LINUX -DIGC_CMAKE -DIGC_EXPORTS=1 -DIGC_SPIRV_ENABLED -DINSIDE_PLUGIN -DISTDLIB_UMD -DLINUX -DNDEBUG -DNOMINMAX -DSTD_CALL -DUSC_EXPORTS=1 -DUSE_MMX -DUSE_SSE -DUSE_SSE2 -DUSE_SSE3 -DUSE_SSSE3 -D_AMD64_ -D_COMPILER_DLL_ -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D_IGC_ -D_SCL_SECURE_NO_WARNINGS -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/WrapperLLVM/include -IIGC/autogen -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/.. -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../Common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../3d/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler/API -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../visa/include -IIGC/Release -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL/ocl_igc_shared/executable_format -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL/cif/cif/.. -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler -isystem/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/recipe-sysroot-native/usr/include -pipe -fno-exceptions -fdata-sections -ffunction-sections -O2 -fmessage-length=0 -march=corei7 -mstackrealign -fms-extensions -Werror -Wno-unused-parameter -Wno-missing-field-initializers -Wwrite-strings -Wno-long-long -Wswitch -Wno-sign-compare -Wno-unused-result -Wno-enum-compare -Wno-type-limits -Wno-ignored-qualifiers -Wformat -Wformat-security -Wno-extra -Wno-write-strings -finline -fno-strict-aliasing -msse -msse2 -msse3 -mssse3 -msse4 -msse4.1 -msse4.2 -Wno-unknown-pragmas -fPIC -D_FORTIFY_SOURCE=2 -fstack-protector -finline-functions -funswitch-loops -Wno-maybe-uninitialized -lrt -fno-rtti -fvisibility=hidden -fvisibility-inlines-hidden -std=c++14 -DNDEBUG -g   -std=gnu++14 -MD -MT IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o -MF IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o.d -o IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o -c /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/CShader.cpp

| In file included from /usr/include/sys/stat.h:106,

|                  from /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../3d/common/iStdLib/File.h:47,

|                  from /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.hpp:42,

|                  from /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/CShader.cpp:44:

| /usr/include/bits/stat.h:106:31: error: expected unqualified-id before ‘[’ token

|      __syscall_slong_t __unused[3];

|                                ^

| /usr/include/bits/stat.h:164:31: error: expected unqualified-id before ‘[’ token

|      __syscall_slong_t __unused[3];

|                                ^

 

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Tuesday, December 14, 2021 2:23 PM
To: yocto@...
Subject: [yocto] Yocto BUILD ENV

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

 

I am using a pre-installed tools on my linux development box for centos7, that being devtoolset-8…

 

Running “source /opt/rh/devtoolset-8/enable” allows me to build my bootapp, kernel, and the standard SDK without issues…, but there seems to be a problem when I go to build the extended SDK.

 

It appears to end up referencing the wrong/default tool set.

 

Is the something I need to set in my sdk-extra.conf (or one of the vcarious other configuration files)  to make the extended SDK build aware of the environment dependency ?

 

 

/opt/rh/devtoolset-8/enable script does the following:

 

# General environment variables

export PATH=/opt/rh/devtoolset-8/root/usr/bin${PATH:+:${PATH}}

export MANPATH=/opt/rh/devtoolset-8/root/usr/share/man:${MANPATH}

export INFOPATH=/opt/rh/devtoolset-8/root/usr/share/info${INFOPATH:+:${INFOPATH}}

export PCP_DIR=/opt/rh/devtoolset-8/root

# Some perl Ext::MakeMaker versions install things under /usr/lib/perl5

# even though the system otherwise would go to /usr/lib64/perl5.

export PERL5LIB=/opt/rh/devtoolset-8/root//usr/lib64/perl5/vendor_perl:/opt/rh/devtoolset-8/root/usr/lib/perl5:/opt/rh/devtoolset-8/root//usr/share/perl5/vendor_perl${PERL5LIB:+:${PERL5LIB}}

# bz847911 workaround:

# we need to evaluate rpm's installed run-time % { _libdir }, not rpmbuild time

# or else /etc/ld.so.conf.d files?

rpmlibdir=$(rpm --eval "%{_libdir}")

# bz1017604: On 64-bit hosts, we should include also the 32-bit library path.

if [ "$rpmlibdir" != "${rpmlibdir/lib64/}" ]; then

  rpmlibdir32=":/opt/rh/devtoolset-8/root${rpmlibdir/lib64/lib}"

fi

export LD_LIBRARY_PATH=/opt/rh/devtoolset-8/root$rpmlibdir$rpmlibdir32${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}

export LD_LIBRARY_PATH=/opt/rh/devtoolset-8/root$rpmlibdir$rpmlibdir32:/opt/rh/devtoolset-8/root$rpmlibdir/dyninst$rpmlibdir32/dyninst${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}

# duplicate python site.py logic for sitepackages

pythonvers=2.7

export PYTHONPATH=/opt/rh/devtoolset-8/root/usr/lib64/python$pythonvers/site-packages:/opt/rh/devtoolset-8/root/usr/lib/python$pythonvers/site-packages${PYTHONPATH:+:${PYTHONPATH}}

export PKG_CONFIG_PATH=/opt/rh/devtoolset-8/root/usr/lib64/pkgconfig${PKG_CONFIG_PATH:+:${PKG_CONFIG_PATH}}

 


Using FreeRadius project on Yocto

Rakesh Kumar <rakeshkumar0815@...>
 



Hi Team,


I am trying to build radius server with the use of Yocto project and looks like freeradius recipe is already included in meta-openembedded/meta-networking/recipes-connectivity/freeradius 


I have included meta-openembedded layer in my conf/bblayers.conf file and built core-image-base image.


But I couldn't see anything related to radius server in my <workspace>/tmp directory 


"tmp/work/ccimx6ul/core-image-base/1.0-r0/rootfs/etc/init.d"


Could you please let me know do I need to add anything specific to build radius server apart from using meta-openembedded recipe? I apologize if this is the wrong mailing list.


Thanks much!


Best Regards

Rakesh kumar






Yocto BUILD ENV

Monsees, Steven C (US)
 

 

I am using a pre-installed tools on my linux development box for centos7, that being devtoolset-8…

 

Running “source /opt/rh/devtoolset-8/enable” allows me to build my bootapp, kernel, and the standard SDK without issues…, but there seems to be a problem when I go to build the extended SDK.

 

It appears to end up referencing the wrong/default tool set.

 

Is the something I need to set in my sdk-extra.conf (or one of the vcarious other configuration files)  to make the extended SDK build aware of the environment dependency ?

 

 

/opt/rh/devtoolset-8/enable script does the following:

 

# General environment variables

export PATH=/opt/rh/devtoolset-8/root/usr/bin${PATH:+:${PATH}}

export MANPATH=/opt/rh/devtoolset-8/root/usr/share/man:${MANPATH}

export INFOPATH=/opt/rh/devtoolset-8/root/usr/share/info${INFOPATH:+:${INFOPATH}}

export PCP_DIR=/opt/rh/devtoolset-8/root

# Some perl Ext::MakeMaker versions install things under /usr/lib/perl5

# even though the system otherwise would go to /usr/lib64/perl5.

export PERL5LIB=/opt/rh/devtoolset-8/root//usr/lib64/perl5/vendor_perl:/opt/rh/devtoolset-8/root/usr/lib/perl5:/opt/rh/devtoolset-8/root//usr/share/perl5/vendor_perl${PERL5LIB:+:${PERL5LIB}}

# bz847911 workaround:

# we need to evaluate rpm's installed run-time % { _libdir }, not rpmbuild time

# or else /etc/ld.so.conf.d files?

rpmlibdir=$(rpm --eval "%{_libdir}")

# bz1017604: On 64-bit hosts, we should include also the 32-bit library path.

if [ "$rpmlibdir" != "${rpmlibdir/lib64/}" ]; then

  rpmlibdir32=":/opt/rh/devtoolset-8/root${rpmlibdir/lib64/lib}"

fi

export LD_LIBRARY_PATH=/opt/rh/devtoolset-8/root$rpmlibdir$rpmlibdir32${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}

export LD_LIBRARY_PATH=/opt/rh/devtoolset-8/root$rpmlibdir$rpmlibdir32:/opt/rh/devtoolset-8/root$rpmlibdir/dyninst$rpmlibdir32/dyninst${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}

# duplicate python site.py logic for sitepackages

pythonvers=2.7

export PYTHONPATH=/opt/rh/devtoolset-8/root/usr/lib64/python$pythonvers/site-packages:/opt/rh/devtoolset-8/root/usr/lib/python$pythonvers/site-packages${PYTHONPATH:+:${PYTHONPATH}}

export PKG_CONFIG_PATH=/opt/rh/devtoolset-8/root/usr/lib64/pkgconfig${PKG_CONFIG_PATH:+:${PKG_CONFIG_PATH}}

 


Re: [meta-rockchip] [PATCH v2] trusted-firmware-a: replace baudrate with the one specified in machine conf

Khem Raj
 

On Tue, Dec 14, 2021 at 3:39 AM Quentin Schulz
<quentin.schulz@...> wrote:

Not all Rockchip boards have their console running at 1500000 baud in
U-Boot and the kernel. Such is the case for puma-haikou RK3399-based
SoM+Carrierboard.

In order to prepare for the addition of puma-haikou to meta-rockchip,
let's replace the baudrate in TF-A by the one defined in the machine
conf file in the RK_CONSOLE_BAUD variable.

Cc: Quentin Schulz <foss+yocto@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---

v2: use a less restrictive regular expression

.../files/serial-console-baudrate.patch | 36 -------------------
.../trusted-firmware-a_%.bbappend | 6 +++-
2 files changed, 5 insertions(+), 37 deletions(-)
delete mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
deleted file mode 100644
index 2d6e9bf..0000000
--- a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
-From: Yann Dirson <yann@...>
-Date: Tue, 6 Apr 2021 17:28:45 +0200
-Subject: [PATCH] Set serial console baudrate back to 1500000.
-Upstream-Status: Inappropriate[other]
-
-TF-A runs between two u-boot stages which both uses 1500000 baud, it
-just makes no sense to use the same UART at a different rate.
-
-This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
-Main reason for that change stated in https://developer.trustedfirmware.org/T762
-is ChromeOS compatibility.
-
-Looks like this patch may become unnecessary in the future, when
-u-boot and TF-A get to communicate this value.
-
----
- plat/rockchip/rk3399/rk3399_def.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
-index ba83242eb..8d6ecfbe6 100644
---- a/plat/rockchip/rk3399/rk3399_def.h
-+++ b/plat/rockchip/rk3399/rk3399_def.h
-@@ -17,7 +17,7 @@
- /**************************************************************************
- * UART related constants
- **************************************************************************/
--#define RK3399_BAUDRATE 115200
-+#define RK3399_BAUDRATE 1500000
- #define RK3399_UART_CLOCK 24000000
-
- /******************************************************************************
---
-2.30.2
-
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 513cea1..07fae1e 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -7,7 +7,6 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "\
- file://serial-console-baudrate.patch \
file://0001-dram-Fix-build-with-gcc-11.patch \
file://0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch \
file://0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch \
@@ -19,3 +18,8 @@ SRC_URI += "\
# this needs fixing until then use gcc
TOOLCHAIN:rk3399 = "gcc"

+fixup_rk3399_baudrate() {
+ sed -i "s/#define RK3399_BAUDRATE\s\+.*/#define RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3399/rk3399_def.h
+}
+
+do_patch[postfuncs] += "fixup_rk3399_baudrate"
perhaps applying the sed expression via do_configure:prepend() is simple ?
and maybe make it rk3399 specific with do_configure:prepend:rk3399

--
2.33.1




Yocto Project Status WW50`21

Stephen Jolley
 

Current Dev Position: YP 3.5 M1

Next Deadline: 6th Dec. 2021 YP 3.5 M1 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.5 M1 is in QA
  • YP 3.1.13 is due to build this week
  • We have maintenance to the autobuilder planned to fit SSDs to speed up IO and update the host distros to more modern equivalents. If parts arrive as planned, this is scheduled for next week (20th-24th) and the autobuilder will be unavailable during the work. There may be bring up issues with the new distros.
  • There were significant improvements in patch metrics this week with large drops in both patches in the pending state and overlap number of patches. Thanks to everyone who contributed to that!
  • As part of patch cleanup, some changes were made which could impact other layers or our spectrum of support. The libtool prefix patches were dropped as the need was largely obsolete by recipe specific sysroots, hosttools and other developments and this may mean patches in other layers can be dropped too. Some non-upstream invasive mips and sh4 patches were dropped as they were either obsolete or there were less invasive ways to handle them. 
  • CVE metrics improved this week with drops in open CVEs for both dunfull and master.
  • Intermittent issues continue to rise and help is very much welcome on these issues. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

 

Ways to contribute:

 

YP 3.5 Milestone Dates:

  • YP 3.5 M1 in QA
  • YP 3.5 M1 Release date 2021/12/17
  • YP 3.5 M2 build date 2022/01/10
  • YP 3.5 M2 Release date 2022/1/21
  • YP 3.5 M3 build date 2022/2/21
  • YP 3.5 M3 Release date 2022/03/04
  • YP 3.5 M4 build date 2022/04/04
  • YP 3.5 M4 Release date 2022/04/29

 

Upcoming dot releases:

  • YP 3.4.1  is released
  • YP 3.1.13 build date 2021/12/13
  • YP 3.1.13 Release date 2021/12/22
  • YP 3.1.14 build date 2022/01/24
  • YP 3.1.14 Release date 2022/02/04
  • YP 3.4.2 build date 2022/02/07
  • YP 3.4.2 Release date 2022/02/18
  • YP 3.3.5 build date 2022/02/14
  • YP 3.3.5 Release date 2022/02/25
  • YP 3.1.15 build date 2022/03/14
  • YP 3.1.15 Release date 2022/03/25
  • YP 3.4.3 build date 2022/03/21
  • YP 3.4.3 Release date 2022/04/01
  • YP 3.3.6 build date 2022/03/28
  • YP 3.3.6 Release date 2022/04/08
  • YP 3.1.16 build date 2022/04/25
  • YP 3.1.16 Release date 2022/05/06

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.5_M1.rc2)

Teoh, Jay Shen
 

Hi everyone,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.5_M1.rc2. We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. Beaglebone

ETA for completion this Friday, 17th of December.

Thanks,
Jay

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Richard Purdie
Sent: Sunday, 12 December, 2021 6:49 PM
To: <yocto@...> <yocto@...>
Cc: qa-build-notification <qa-build-notification@...>
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.5_M1.rc2)

A build flagged for QA (yocto-3.5_M1.rc2) was completed on the autobuilder and
is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.5_M1.rc2


Build hash information:

bitbake: 1ecc1d9424877df89fcda2f23c306998998a65ff
meta-agl: 6d1ab9f3bb270a773ec5d2f7c8c856796833b559
meta-arm: d446f7f80bf61e9cf05843e8ef4bc5473f936118
meta-aws: 8893e0cd4c0981eeda941eaa9ad2eb9359670502
meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400
meta-intel: aa8482af7b286f8fe8f7aae648938d4ebf0283c5
meta-mingw: 992fb40bdbfe9fe60f815aac46e04c58963918b5
meta-openembedded: ba6a16cdca661b2d5251df243dc19bda0e8db651
oecore: 1a6c2a7345199d77ad5aeac8ad337ed80a8aa39b
poky: 65c94ca3196e5ef3344a469fea8e30444f2e967a



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...







Re: echo and read shell script functions in post install script doesn't display messages

Alexander Kanavin
 

The postinst scriptlets are script fragments and not standalone scripts. Putting an interpreter to their first line will not work. Also, they are not running on an interactive console, but by a helper executor, so they have to be entirely automated.

What is the problem that you would like to solve?

Alex


On Tue, 14 Dec 2021 at 13:01, <sanjaycvr35412@...> wrote:

Hi All,

 

I am trying to execute a script in “pkg_postinst_ontarget_${PN}” to configure the static IP address of the embedded board. The script executes at first boot, but it doesn’t display echo or read messages. These messages are required to improve user experience with the setup process.

 

Script is as below:

pkg_postinst_ontarget_${PN} () {

    #!/bin/sh -e

    # This will run on first boot

    echo "Starting setup script..."

 

    read -p "Enter the IP address: " ipAddress

    read -p "Enter the netmask: " netmask

    read -p "Enter network gateway: " gateway

 

    cat >> /etc/network/interfaces << EOF

 

iface eth0 inet static

    address $ipAddress

    netmask $netmask

    gateway $gateway

EOF

}

 

Please help me to fix the problem in displaying echo and read messages to improve user experience with the setup process.

 

Thanks,

Sanjay Kumar

 





echo and read shell script functions in post install script doesn't display messages

sanjaycvr35412@...
 

Hi All,

 

I am trying to execute a script in “pkg_postinst_ontarget_${PN}” to configure the static IP address of the embedded board. The script executes at first boot, but it doesn’t display echo or read messages. These messages are required to improve user experience with the setup process.

 

Script is as below:

pkg_postinst_ontarget_${PN} () {

    #!/bin/sh -e

    # This will run on first boot

    echo "Starting setup script..."

 

    read -p "Enter the IP address: " ipAddress

    read -p "Enter the netmask: " netmask

    read -p "Enter network gateway: " gateway

 

    cat >> /etc/network/interfaces << EOF

 

iface eth0 inet static

    address $ipAddress

    netmask $netmask

    gateway $gateway

EOF

}

 

Please help me to fix the problem in displaying echo and read messages to improve user experience with the setup process.

 

Thanks,

Sanjay Kumar

 


Re: [PATCH v2] trusted-firmware-a: replace baudrate with the one specified in machine conf

Quentin Schulz
 

Sorry, this was meant for meta-rockchip, sending a new mail with the
proper topic.

Cheers,
Quentin

On Tue, Dec 14, 2021 at 10:50:18AM +0100, Quentin Schulz wrote:
Not all Rockchip boards have their console running at 1500000 baud in
U-Boot and the kernel. Such is the case for puma-haikou RK3399-based
SoM+Carrierboard.

In order to prepare for the addition of puma-haikou to meta-rockchip,
let's replace the baudrate in TF-A by the one defined in the machine
conf file in the RK_CONSOLE_BAUD variable.

Cc: Quentin Schulz <foss+yocto@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---

v2: use a less restrictive regular expression

.../files/serial-console-baudrate.patch | 36 -------------------
.../trusted-firmware-a_%.bbappend | 6 +++-
2 files changed, 5 insertions(+), 37 deletions(-)
delete mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
deleted file mode 100644
index 2d6e9bf..0000000
--- a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
-From: Yann Dirson <yann@...>
-Date: Tue, 6 Apr 2021 17:28:45 +0200
-Subject: [PATCH] Set serial console baudrate back to 1500000.
-Upstream-Status: Inappropriate[other]
-
-TF-A runs between two u-boot stages which both uses 1500000 baud, it
-just makes no sense to use the same UART at a different rate.
-
-This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
-Main reason for that change stated in https://developer.trustedfirmware.org/T762
-is ChromeOS compatibility.
-
-Looks like this patch may become unnecessary in the future, when
-u-boot and TF-A get to communicate this value.
-
----
- plat/rockchip/rk3399/rk3399_def.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
-index ba83242eb..8d6ecfbe6 100644
---- a/plat/rockchip/rk3399/rk3399_def.h
-+++ b/plat/rockchip/rk3399/rk3399_def.h
-@@ -17,7 +17,7 @@
- /**************************************************************************
- * UART related constants
- **************************************************************************/
--#define RK3399_BAUDRATE 115200
-+#define RK3399_BAUDRATE 1500000
- #define RK3399_UART_CLOCK 24000000
-
- /******************************************************************************
---
-2.30.2
-
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 513cea1..07fae1e 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -7,7 +7,6 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "\
- file://serial-console-baudrate.patch \
file://0001-dram-Fix-build-with-gcc-11.patch \
file://0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch \
file://0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch \
@@ -19,3 +18,8 @@ SRC_URI += "\
# this needs fixing until then use gcc
TOOLCHAIN:rk3399 = "gcc"

+fixup_rk3399_baudrate() {
+ sed -i "s/#define RK3399_BAUDRATE\s\+.*/#define RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3399/rk3399_def.h
+}
+
+do_patch[postfuncs] += "fixup_rk3399_baudrate"
--
2.33.1


[meta-rockchip] [PATCH v2] trusted-firmware-a: replace baudrate with the one specified in machine conf

Quentin Schulz
 

Not all Rockchip boards have their console running at 1500000 baud in
U-Boot and the kernel. Such is the case for puma-haikou RK3399-based
SoM+Carrierboard.

In order to prepare for the addition of puma-haikou to meta-rockchip,
let's replace the baudrate in TF-A by the one defined in the machine
conf file in the RK_CONSOLE_BAUD variable.

Cc: Quentin Schulz <foss+yocto@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---

v2: use a less restrictive regular expression

.../files/serial-console-baudrate.patch | 36 -------------------
.../trusted-firmware-a_%.bbappend | 6 +++-
2 files changed, 5 insertions(+), 37 deletions(-)
delete mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
deleted file mode 100644
index 2d6e9bf..0000000
--- a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
-From: Yann Dirson <yann@...>
-Date: Tue, 6 Apr 2021 17:28:45 +0200
-Subject: [PATCH] Set serial console baudrate back to 1500000.
-Upstream-Status: Inappropriate[other]
-
-TF-A runs between two u-boot stages which both uses 1500000 baud, it
-just makes no sense to use the same UART at a different rate.
-
-This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
-Main reason for that change stated in https://developer.trustedfirmware.org/T762
-is ChromeOS compatibility.
-
-Looks like this patch may become unnecessary in the future, when
-u-boot and TF-A get to communicate this value.
-
----
- plat/rockchip/rk3399/rk3399_def.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
-index ba83242eb..8d6ecfbe6 100644
---- a/plat/rockchip/rk3399/rk3399_def.h
-+++ b/plat/rockchip/rk3399/rk3399_def.h
-@@ -17,7 +17,7 @@
- /**************************************************************************
- * UART related constants
- **************************************************************************/
--#define RK3399_BAUDRATE 115200
-+#define RK3399_BAUDRATE 1500000
- #define RK3399_UART_CLOCK 24000000
-
- /******************************************************************************
---
-2.30.2
-
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 513cea1..07fae1e 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -7,7 +7,6 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "\
- file://serial-console-baudrate.patch \
file://0001-dram-Fix-build-with-gcc-11.patch \
file://0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch \
file://0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch \
@@ -19,3 +18,8 @@ SRC_URI += "\
# this needs fixing until then use gcc
TOOLCHAIN:rk3399 = "gcc"

+fixup_rk3399_baudrate() {
+ sed -i "s/#define RK3399_BAUDRATE\s\+.*/#define RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3399/rk3399_def.h
+}
+
+do_patch[postfuncs] += "fixup_rk3399_baudrate"
--
2.33.1


Re: [meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11

Quentin Schulz
 

Hi all,

On Mon, Dec 13, 2021 at 05:30:05PM -0500, Trevor Woerner wrote:
Hi Quentin/Khem,

On Mon 2021-12-13 @ 09:35:53 AM, Khem Raj wrote:
On Mon, Dec 13, 2021 at 9:18 AM Quentin Schulz <foss+yocto@...> wrote:

Hi Khem,

On December 13, 2021 4:04:03 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:
On Mon, Dec 13, 2021 at 1:00 AM Quentin Schulz <
quentin.schulz@...> wrote:

Hi Trevor,

Gentle ping :)

Honister 3.4.1 being out it's less of an issue but the question remains
at least for settling on a policy :)
I apologize for not reviewing this patch in a timely manner; I'm sorry for the
frustration it caused.
No frustration on my side, just a debate/discussion on what we should
do.

Would this have been solved by (me) creating a honister branch? I usually
No, the problem is the same because it is broken only in Honister 3.4.
So if we take this patch in, we basically have some code only for
"patching" honister 3.4 but anything different than that, the patch is
not necessary. So with a honister branch the "problem" stays the same.

The question is more what's the policy with that kind of patch. Would
you be ok taking that kind of patch which applies only to one dot
release of Yocto and nothing else? Or do we just ignore it until the
next dot release so it's fixed? Also do we expect to support honister
3.4 or once 3.4.1 is out (it is), we decide 3.4 is not supported at all?

I'd like at least to mention somewhere that meta-rockchip is supposed to
be used with something different than honister 3.4.

Anyway, it's ok not to answer now and hope a similar issue does not
happen later, or this discussion will be brought up again :)

Cheers,
Quentin


Re: [meta-rockchip][PATCH] trusted-firmware-a: replace baudrate with the one specified in machine conf

Quentin Schulz
 

Hi Trevor,

On Mon, Dec 13, 2021 at 05:37:32PM -0500, Trevor Woerner wrote:
On Fri 2021-12-10 @ 11:15:56 AM, Trevor Woerner via lists.yoctoproject.org wrote:
On Fri 2021-12-10 @ 03:50:19 PM, Quentin Schulz wrote:
Hi Trevor,

On Fri, Dec 10, 2021 at 09:43:39AM -0500, Trevor Woerner wrote:
On Thu 2021-11-11 @ 06:00:02 PM, Quentin Schulz wrote:
Not all Rockchip boards have their console running at 1500000 baud in
U-Boot and the kernel. Such is the case for puma-haikou RK3399-based
SoM+Carrierboard.

In order to prepare for the addition of puma-haikou to meta-rockchip,
let's replace the baudrate in TF-A by the one defined in the machine
conf file in the RK_CONSOLE_BAUD variable.

Cc: Quentin Schulz <foss@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---
.../files/serial-console-baudrate.patch | 36 -------------------
.../trusted-firmware-a_%.bbappend | 7 +++-
2 files changed, 6 insertions(+), 37 deletions(-)
delete mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
deleted file mode 100644
index 2d6e9bf..0000000
--- a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
-From: Yann Dirson <yann@...>
-Date: Tue, 6 Apr 2021 17:28:45 +0200
-Subject: [PATCH] Set serial console baudrate back to 1500000.
-Upstream-Status: Inappropriate[other]
-
-TF-A runs between two u-boot stages which both uses 1500000 baud, it
-just makes no sense to use the same UART at a different rate.
-
-This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
-Main reason for that change stated in https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.trustedfirmware.org_T762&d=DwIBaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=TULURVxAXuoOr1qm-lWPJ4RyXC82jen1-RFqhySvz2ZLazQ8DA84GQ7T4MccEcQp&s=7WhFJXuPJAZq8RxczqF3HrMD5JqRZdJ8MyMU9iEnq44&e=
-is ChromeOS compatibility.
-
-Looks like this patch may become unnecessary in the future, when
-u-boot and TF-A get to communicate this value.
-
----
- plat/rockchip/rk3399/rk3399_def.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
-index ba83242eb..8d6ecfbe6 100644
---- a/plat/rockchip/rk3399/rk3399_def.h
-+++ b/plat/rockchip/rk3399/rk3399_def.h
-@@ -17,7 +17,7 @@
- /**************************************************************************
- * UART related constants
- **************************************************************************/
--#define RK3399_BAUDRATE 115200
-+#define RK3399_BAUDRATE 1500000
- #define RK3399_UART_CLOCK 24000000
-
- /******************************************************************************
---
-2.30.2
-
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index f7777a7..0d06c44 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -7,9 +7,14 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "\
- file://serial-console-baudrate.patch \
file://0001-Fix-build-with-gcc-11.patch \
file://0001-dram-Fix-build-with-gcc-11.patch \
file://0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch \
file://0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch \
"
+
+fixup_rk3399_baudrate() {
+ sed -i "s/#define RK3399_BAUDRATE 115200/#define RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3399/rk3399_def.h
+}
This looks fragile to me, any change in the number of spaces/tabs and this
line will stop working. Thankfully the symbol RK3399_BAUDRATE only appears
once in this file! That will allow us to do something like the following
instead:

sed '/RK3399_BAUDRATE.*/RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/d'
Would
sed -i "s/#define RK3399_BAUDRATE\s\+.*/#define RK3399_BAUDRATE plep/" ${S}/plat/rockchip/rk3399/rk3399_def.h

work for you?
This makes sure that only RK3399_BAUDRATE definition will be changed, no
comment, no RK3399_BAUDRATE_OTHER_VAR or RK3399_BAUDRATE being used in
code/other constant in this file.
Sounds good.
Am I correct in thinking a v2 is coming (or did it get swallowed up by my mail
client)?

Otherwise, I can just fixup your v2 and apply it if you wish?
Yes, sorry just sent it :)

Cheers,
Quentin


[PATCH v2] trusted-firmware-a: replace baudrate with the one specified in machine conf

Quentin Schulz
 

Not all Rockchip boards have their console running at 1500000 baud in
U-Boot and the kernel. Such is the case for puma-haikou RK3399-based
SoM+Carrierboard.

In order to prepare for the addition of puma-haikou to meta-rockchip,
let's replace the baudrate in TF-A by the one defined in the machine
conf file in the RK_CONSOLE_BAUD variable.

Cc: Quentin Schulz <foss+yocto@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---

v2: use a less restrictive regular expression

.../files/serial-console-baudrate.patch | 36 -------------------
.../trusted-firmware-a_%.bbappend | 6 +++-
2 files changed, 5 insertions(+), 37 deletions(-)
delete mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
deleted file mode 100644
index 2d6e9bf..0000000
--- a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
-From: Yann Dirson <yann@...>
-Date: Tue, 6 Apr 2021 17:28:45 +0200
-Subject: [PATCH] Set serial console baudrate back to 1500000.
-Upstream-Status: Inappropriate[other]
-
-TF-A runs between two u-boot stages which both uses 1500000 baud, it
-just makes no sense to use the same UART at a different rate.
-
-This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
-Main reason for that change stated in https://developer.trustedfirmware.org/T762
-is ChromeOS compatibility.
-
-Looks like this patch may become unnecessary in the future, when
-u-boot and TF-A get to communicate this value.
-
----
- plat/rockchip/rk3399/rk3399_def.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
-index ba83242eb..8d6ecfbe6 100644
---- a/plat/rockchip/rk3399/rk3399_def.h
-+++ b/plat/rockchip/rk3399/rk3399_def.h
-@@ -17,7 +17,7 @@
- /**************************************************************************
- * UART related constants
- **************************************************************************/
--#define RK3399_BAUDRATE 115200
-+#define RK3399_BAUDRATE 1500000
- #define RK3399_UART_CLOCK 24000000
-
- /******************************************************************************
---
-2.30.2
-
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 513cea1..07fae1e 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -7,7 +7,6 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "\
- file://serial-console-baudrate.patch \
file://0001-dram-Fix-build-with-gcc-11.patch \
file://0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch \
file://0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch \
@@ -19,3 +18,8 @@ SRC_URI += "\
# this needs fixing until then use gcc
TOOLCHAIN:rk3399 = "gcc"

+fixup_rk3399_baudrate() {
+ sed -i "s/#define RK3399_BAUDRATE\s\+.*/#define RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3399/rk3399_def.h
+}
+
+do_patch[postfuncs] += "fixup_rk3399_baudrate"
--
2.33.1


Re: [meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11

Quentin Schulz
 

Hi Trevor,

Gentle ping :)

Honister 3.4.1 being out it's less of an issue but the question remains
at least for settling on a policy :)

Cheers,
Quentin

On Tue, Nov 16, 2021 at 10:50:13AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 10:03 AM Quentin Schulz <foss@...> wrote:



On November 16, 2021 6:45:05 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:
On Tue, Nov 16, 2021 at 9:12 AM Quentin Schulz <
quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
<quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet
MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because
Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4 and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've seen
people running behind dot releases.
What's bothering you?
once dot release is out then thats whats maintained not the original
release since they are incremental.
the anon python to apply a patch. Can you explain why we want to patch
applied this way ?
I could define a python function and use it like this:
SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"

Would that work better for you?

I am not yet convinced why should we have such version specific patch
If you could explain what's *really* bothering you, I could try to find a proper explanation or agree with you but it's a bit too vague to me right now. Anyway, I'll do some guesses in the next paragraphs.

Because Ethernet does not work for all RK3399-based boards in the latest and only release of Honister?
meta-rockchip does not have honister branch for now. So it expects
master to keep working with honister for now. kernel upgrades are
already committed into honister branch on meta-yocto-bsps so fix it
already available in latest honister
branch and will be in imminent point release soon as well.


meta-rockchip is the BSP layer for Rockchip based devices, if not there, where should I put this patch?

Or are we just going to say "Ethernet does not work, we know" to people asking instead of having this patch in? Obviously you could tell them to upgrade their oe-core/poky git repo to rolling honister or 3.4.1 once it's out but having this patch in avoid those questions.
I would say yes, document it as that of a known issue and possible fix
if someone is using exact point release. They might have snapshotted
meta-rockpi too and in that case it will be easy for them to carry a
local patch if needed.
vesion specific patching would also be setting a not so desired
patching practice, so I am trying to avoid it if we can.

I understand we're talking about policy here. I am not fond of this patch either but Ethernet is quite critical on boards which don't have WiFi for example. I don't have anything better to suggest to fix this in the *latest* release.
Update to latest honister branch or wait for 3.4.1, would be my suggestion.


Cheers
Quentin


Cheers,
Quentin


Re: [meta-rockchip][PATCH] trusted-firmware-a: replace baudrate with the one specified in machine conf

Quentin Schulz
 

Hi Trevor,

On Fri, Dec 10, 2021 at 09:43:39AM -0500, Trevor Woerner wrote:
On Thu 2021-11-11 @ 06:00:02 PM, Quentin Schulz wrote:
Not all Rockchip boards have their console running at 1500000 baud in
U-Boot and the kernel. Such is the case for puma-haikou RK3399-based
SoM+Carrierboard.

In order to prepare for the addition of puma-haikou to meta-rockchip,
let's replace the baudrate in TF-A by the one defined in the machine
conf file in the RK_CONSOLE_BAUD variable.

Cc: Quentin Schulz <foss@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---
.../files/serial-console-baudrate.patch | 36 -------------------
.../trusted-firmware-a_%.bbappend | 7 +++-
2 files changed, 6 insertions(+), 37 deletions(-)
delete mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
deleted file mode 100644
index 2d6e9bf..0000000
--- a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
-From: Yann Dirson <yann@...>
-Date: Tue, 6 Apr 2021 17:28:45 +0200
-Subject: [PATCH] Set serial console baudrate back to 1500000.
-Upstream-Status: Inappropriate[other]
-
-TF-A runs between two u-boot stages which both uses 1500000 baud, it
-just makes no sense to use the same UART at a different rate.
-
-This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
-Main reason for that change stated in https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.trustedfirmware.org_T762&d=DwIBaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=TULURVxAXuoOr1qm-lWPJ4RyXC82jen1-RFqhySvz2ZLazQ8DA84GQ7T4MccEcQp&s=7WhFJXuPJAZq8RxczqF3HrMD5JqRZdJ8MyMU9iEnq44&e=
-is ChromeOS compatibility.
-
-Looks like this patch may become unnecessary in the future, when
-u-boot and TF-A get to communicate this value.
-
----
- plat/rockchip/rk3399/rk3399_def.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
-index ba83242eb..8d6ecfbe6 100644
---- a/plat/rockchip/rk3399/rk3399_def.h
-+++ b/plat/rockchip/rk3399/rk3399_def.h
-@@ -17,7 +17,7 @@
- /**************************************************************************
- * UART related constants
- **************************************************************************/
--#define RK3399_BAUDRATE 115200
-+#define RK3399_BAUDRATE 1500000
- #define RK3399_UART_CLOCK 24000000
-
- /******************************************************************************
---
-2.30.2
-
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index f7777a7..0d06c44 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -7,9 +7,14 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "\
- file://serial-console-baudrate.patch \
file://0001-Fix-build-with-gcc-11.patch \
file://0001-dram-Fix-build-with-gcc-11.patch \
file://0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch \
file://0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch \
"
+
+fixup_rk3399_baudrate() {
+ sed -i "s/#define RK3399_BAUDRATE 115200/#define RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3399/rk3399_def.h
+}
This looks fragile to me, any change in the number of spaces/tabs and this
line will stop working. Thankfully the symbol RK3399_BAUDRATE only appears
once in this file! That will allow us to do something like the following
instead:

sed '/RK3399_BAUDRATE.*/RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/d'
Would
sed -i "s/#define RK3399_BAUDRATE\s\+.*/#define RK3399_BAUDRATE plep/" ${S}/plat/rockchip/rk3399/rk3399_def.h

work for you?
This makes sure that only RK3399_BAUDRATE definition will be changed, no
comment, no RK3399_BAUDRATE_OTHER_VAR or RK3399_BAUDRATE being used in
code/other constant in this file.

Cheers,
Quentin


#dunfell #qt5 #raspberrypi #sdk #linux #dunfell #qt5 #raspberrypi #sdk #linux

arthur.forey@...
 

 
 
 
 
Hello everybody,

I come today to try to solve my problem. I am building a bsp and sdk for a raspberry pi (MACHINE = raspberrypi4-64) in the form of a compute module. I'm trying to compile this app: https://github.com/YvesBas/Tadarida-D/tree/master/sources for the raspberry pi).

I know that in the Libs directory, the libraries are compiled for an x86_64 architecture. This is why I try to integrate them into the sources without this directory. I am also modifying the .pro to match with the correct libs. The integration of these two libs are present in the image of the raspberry pi, but in the sdk I only have the libsndfile1, so the libfftw3.h / .so is missing.

Here are elements for the creation of the bsp and the sdk:
Build Configuration:
BB_VERSION           = "1.46.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "aarch64-poky-linux"
MACHINE              = "raspberrypi4-64"
DISTRO               = "poky"
DISTRO_VERSION       = "3.1.12"
TUNE_FEATURES        = "aarch64 cortexa72 crc crypto"
TARGET_FPU           = ""
meta                
meta-poky           
meta-yocto-bsp       = "dunfell:cf5a00721f721d5077c73d1f4e812e5c79833fba"
meta-oe             
meta-python         
meta-networking     
meta-multimedia      = "dunfell:69f94af4d91215e7d4e225bab54bf3bcfee42f1c"
meta-qt5             = "dunfell:b4d24d70aca75791902df5cd59a4f4a54aa4a125"
meta-raspberrypi     = "dunfell:934064a01903b2ba9a82be93b3f0efdb4543a0e8"

In conf/local.conf :
IMAGE_INSTALL_append = " libfftw libfftwl libfftwf fftw-dev libsndfile1"

When I do bitbake meta-toolchain-qt5, I don't have
libfftw3.h / .so .

What can i do ?

Thanks a lot.

Arthur


libsdl2 virtual/nativesdk-libgles2 issue

sateesh m
 

Hi Team,
 
               I am facing a problem libsdl2 while building the core-image-base. Can anybody know this please suggest me. 

NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'virtual/nativesdk-libgles2' (but virtual:nativesdk:/home/sateesh/sample-kde/openembedded-core/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb DEPENDS on or otherwise requires it). Close matches:
  virtual/nativesdk-libgl
  virtual/nativesdk-libsdl
  virtual/nativesdk-libsdl2
NOTE: Runtime target 'nativesdk-qemu' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['nativesdk-qemu', 'nativesdk-libsdl2', 'virtual/nativesdk-libgles2']
NOTE: Runtime target 'nativesdk-packagegroup-sdk-host' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['nativesdk-packagegroup-sdk-host', 'nativesdk-qemu', 'nativesdk-libsdl2', 'virtual/nativesdk-libgles2']
ERROR: Required build target 'core-image-base' has no buildable providers.
Missing or unbuildable dependency chain was: ['core-image-base', 'nativesdk-packagegroup-sdk-host', 'nativesdk-qemu', 'nativesdk-libsdl2', 'virtual/nativesdk-libgles2']
 
--
Regards,
Sateesh


Re: Running unittests built by SDK

Khem Raj
 

On Mon, Dec 13, 2021 at 6:21 PM Rusty Howell <rustyhowell@...> wrote:

We are building our software with a Yocto SDK we created against our imx8m board. We would like to be able to execute unit tests (C++ tests written in Google Test) quickly without having to copy our unittest binaries over to an actual imx board to execute them. For sanity, we are also building our linux distro for MACHINE=qemux86-64 and beaglebone-yocto. So we have SDKs for imx8m, qemux86-64 and beaglebone-yocto.

Is there a MACHINE type that we could build that would be suitable for executing compiled C++ google test binaries directly on Ubuntu 18.04 or 20.04?
I think using qemux86-64 might be your best bet, its fairly automated
with runqemu script
all you would need to do is package up the gtests as ptest package with a runner

Thanks


1841 - 1860 of 57387