<RP>
rburton: thanks. Grumbling that scripts/contrib/patchreview.py meta/recipes-devtools/gcc doesn't work ;-)
<rburton>
heh
<rburton>
patchreview.y meta|grep gcc isn't too hard right?
zpfvo has quit [Ping timeout: 240 seconds]
<RP>
rburton: I wanted a stats summary
zpfvo has joined #yocto
<rburton>
hm i wonder why glib install is rebuilding api docs
<rburton>
noticed when do_install was up to 5 minutes
<RP>
rburton: that sounds like something it'd be nice to fix
<RP>
at least a bug opened if you aren't able to do it now
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
<rburton>
i'll replicate first in case it wasn't a weird build mess thing
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
tnovotny has joined #yocto
kayterina has quit [Ping timeout: 252 seconds]
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
kayterina has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
kroon has joined #yocto
dti is now known as dtometzki
<coldspark29[m]>
How to narrow down an error in the U-Boot configuration that results in the kernel freezing while booting?
<coldspark29[m]>
The kernel definitely works, but the Yocto bootloader somehow can't boot it. Tried to check the defconfigs of Android and Yocto with a difftool, but no luck so far
<qschulz>
coldspark29[m]: figure out if there's an overlap in RAM when loading your images, that will corrupt them
<qschulz>
coldspark29[m]: enable earlyprintk and configure it so you can see as much as possible during the boot
<coldspark29[m]>
@qschulz Will earlyprintk help in cases in which I already see output? It doesn print some boot messages but then suddenly stops. Sounds like earlyprintk is only for cases in which it doesn't print at boot messages yet
<coldspark29[m]>
s/doesn/does/
<qschulz>
coldspark29[m]: I bet 5¢ that the watchdog is enabled in U-boot but not disabled soon enough
<qschulz>
coldspark29[m]: earlyprintk is useful when you have nothing after "Starting kernel..."
<coldspark29[m]>
qschulz: Is it enabled by default? I have no CONFIG_IMX_WATCHDOG set
<qschulz>
coldspark29[m]: usually not no, it's a config option you enable once you've a product ready, so for eval board or sent by the BSP vendor, probably not
<coldspark29[m]>
Okay thanks
F_Adrian has joined #yocto
<RP>
kanavin: I just sent an upgrade for minicom. It is interesting the .gz -> .bz2 compression change may have let AUH miss it :/
<RP>
kanavin: I also got rid of six more pendings :)
<kroon>
"Removing 266 stale sstate objects for arch i686"
<kroon>
But all I did was add a patch that modifies the commit message in a gcc patch
<kroon>
Then a couple of the target recipes got rebuilt
<kroon>
What decides what is a "stale" sstate object ?
<RP>
kanavin: I mailed the puzzles patches to the author, will see what he says
<RP>
kroon: hash changes
<RP>
kroon: hashequiv may bring them back later
<kroon>
RP, so no risk of pre-early sstate object cleanup ?
tre has quit [Remote host closed the connection]
<kroon>
In case the hash changes didn't actually cause any changes in the output
MauroAnjo has joined #yocto
<RP>
kroon: the pre build cleanup was added as we just hit too many issues doing it later in the build (think of someone reusing the same TMPDIR switching sysvinit to systemd)
<RP>
kroon: we can't defer it until after the hashequiv returns, that is rather hard to arrange dependency wise. The sstate cleanup is also rather fast
michalkotyla has joined #yocto
<kanavin>
RP: right, let me look if AUH wasn't picking up the new version
<MauroAnjo>
agherzan Hello! I'm finishing the changes you've asked, but hit a problem when trying to add specific instructions for raspberrypi3 and 4 in 32 bits
<MauroAnjo>
agherzan When I use for instance EXTRA_OECMAKE:append:raspberrypi3 = " -DENABLE_COMPILE_FLAGS_FOR_TARGET=armv8-neon" and build for pizero2w in 64, it appends
akiCA has joined #yocto
<kroon>
RP, would it make sense to make it possible to disable this pre-build sstate cleanup ? I regularly cleanup my sstate cache in other ways
<RP>
kroon: it isn't cleaning up the sstate directory. It is removing those sstate artefacts from the build directory
zpfvo has quit [Ping timeout: 265 seconds]
<RP>
kroon: i.e. the expanded output of them
<kroon>
RP, aha ok I see
zpfvo has joined #yocto
vm1 has quit [Ping timeout: 256 seconds]
zpfvo has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
sakoman has joined #yocto
codavi has joined #yocto
akiCA has quit [Ping timeout: 256 seconds]
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 252 seconds]
pgowda_ has quit [Quit: Connection closed for inactivity]
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
<RP>
kanavin: also wondering about apt 2.3.13 vs our 2.2.4
<RP>
ah, the even version check
* RP
looked for that and didn't see it several times :/
maoti__ has joined #yocto
jpuhlman_ has quit [Ping timeout: 252 seconds]
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
vm1 has joined #yocto
<qschulz>
RP: just a heads up but the OE-Core patches I just send for replacing some problematic words have been tested but the changes do make sense to me
florian_kc has joined #yocto
ar__ has joined #yocto
codavi has quit [Remote host closed the connection]
camus has quit [Ping timeout: 268 seconds]
camus has joined #yocto
<vm1>
Hi all! I'm having bitbake stuck 44% at Initializing tasks. occurs on any target. looks similar to this:
<vm1>
in ps output I see 3 python bitbake processes,
<vm1>
cooker log ends with saving uninative tar
<vm1>
Is there any way to determine where bitbake hangs?
<rburton>
vm1: have you set up a sstate mirror?
<vm1>
nope
<vm1>
it is default poky from scratch
<vm1>
running dunfell, latest
<vm1>
it only fails in vmware, runs fine in virtualbox and natively
<rburton>
then i blame vmware :)
<rburton>
maybe its trying to hit the network and failing
<vm1>
the previous dunfell release works
<vm1>
I doubt it is network, I left it overnight, still was hanging
<rburton>
ps to see if anything is hanging, and netstat to see if there are any in progress network ops
<rburton>
we don't check the virtualisation tech, so there's a difference in your vmware vs virtualbox config
<JPEW>
qschulz: I think "testmaster" should "testcontroller" or similar. "golden" doesn't have quite the same meaning in that context. Left a comment on the ML
<JPEW>
qschulz: Unless I'm wrong about what that test is doing which is possible
rob_w has quit [Quit: Leaving]
<qschulz>
JPEW: "This module adds support to testimage.bbclass to deploy images and run tests using a "master image" - this is a "known good" image that is..."
<qschulz>
For me that matched the definition of golden but I might have read too quickly and not checked the rest too
marc2 has quit [Ping timeout: 256 seconds]
<JPEW>
qschulz: Ah, I think you are correct then. The "testing other images" confused me. Nevermind!
<jonmason>
RP: it does appear that the crypto unit is optional. The docs in this area are vague, but I'm seeing other, newer chips saying it is optional for them. I'll do a clean-up
<jonmason>
but for a72, it should be fine
<jonmason>
want me to ack the patch?
<agherzan>
MauroAnjo: The compile flags should come directly from machine configuration. I don't think they apply in this case.
<RP>
jonmason: the question is whether to change the existing tune or not. I'm in favour of changing it
GNUmoon has quit [Ping timeout: 276 seconds]
kayterina has quit [Read error: Connection reset by peer]
vd has joined #yocto
GNUmoon has joined #yocto
<jonmason>
RP: honestly, the whole tunes intra for arm needs another pass. There is too muany redundant entries. I'm just thinking if I need to revisit everything for this crypto thing, if now is the right time
<jonmason>
I think I'll take a stab at it after lunch
<RP>
jonmason: I'm open to proposals, we may still want to fix this in isolation
florian_kc is now known as florian
zpfvo has quit [Ping timeout: 240 seconds]
geoffhp has quit [Remote host closed the connection]
zpfvo has joined #yocto
manuel1985 has joined #yocto
manuel1985 has quit [Client Quit]
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
rfuentess has quit [Remote host closed the connection]
<MauroAnjo>
agherzan Yeap, i did another approach, already pushed it
MauroAnjo56 has joined #yocto
MauroAnjo56 has quit [Client Quit]
<khem>
jonmason: RP I think 'elegant' fix is to rename existing cortexta72 as cortexa72-crypto and mark cortexta72 as nocrypto but this will require other cortexa72 machines to change otherwise they see a regression in performance. There is another patch which does it more or less how it is for other arm tunes. the fix is needed for rpi4 alone AFAIK and I am also inclined to push it into meta-rpi since it seems to be needing it. but there might be more
<khem>
broadcom SOCs needing it as well, Either way I am fine as long as we have a way to disable crypto for meta-rpi and I will adjust other machines in meta-rockchip to use new tunes if needed
kroon has quit [Quit: Leaving]
<jonmason>
khem: why not just make an entry for non-crypto and make it the not-default
<jonmason>
then its all in the same file, others can get it, but it has to be asked for specifically
<khem>
thats what my patch does exactly 🙂
<jonmason>
ok, need to look at patches now :)
<khem>
but I guess RP is not happy calling 'nocrypto' I think its better to call out anamolies rather than decorate defaults unnecessarily
<khem>
jonmason: you might have better view of Silicon partners who are not licencing ARM's crypto AES other than BCOM for this SOC
<khem>
if there are many we might want to accomodate
<khem>
if its one off then I would say nocrypto is better
zpfvo has quit [Ping timeout: 240 seconds]
creich has quit [Remote host closed the connection]
creich has joined #yocto
<jonmason>
asking now
<jonmason>
the NXP lx2k does have it
<khem>
limited view I have so far I see rpi4 only
creich has quit [Remote host closed the connection]
creich has joined #yocto
creich has quit [Remote host closed the connection]
<smurray>
heh, crypto acceleration seems like something you'd want in a STB chip ;)
<jonmason>
rockchip 3399 has it
<jonmason>
smurray: the raspi4 is a braodcom stb chip.....
<khem>
yes, although they might have saved some money to produce a cheaper SOC for rpi
<smurray>
jonmason: heh, yes, hence my ;)
<khem>
jonmason: its not used in STBs
<jonmason>
khem: yell at florian on your next call
fray has quit [Ping timeout: 245 seconds]
<khem>
🙂
<jonmason>
he's not responding to my shaming for not having it
<smurray>
khem: heh, if Broadcom have moved on from STBs with that line, perhaps they could think about not booting the GPU first ;)
<jonmason>
probably save a penny, x1 million chips
<khem>
heh cost cutting measures, I thought ARM will not allow such tweaks but here we are
<jonmason>
more and more are part of the "standard". crc is standard in v8.1
florian has quit [Ping timeout: 240 seconds]
<khem>
so in theory calling cortexta72 defaulttune with crypto enabled infact is a false assumption
<khem>
but in practice ?
<khem>
how many v8.1 based SOCs are without crypto
<khem>
if we can answer that we can pick one patch or other
<jonmason>
still no response from internal query. So the question is is the raspi more popular than nxp and rockchip stuff
<rburton>
my hunch would be in yocto, no.
<jonmason>
it probably is
<rburton>
why oh why did we not add a phone home to the login prompt
<jonmason>
its never too late
<jonmason>
make it the default for poky, then you can see who also is lazy
<rburton>
just send uname -a to phonehome.yocto.io
<vd>
the problem with multiconfig is that the sstate isn't shared, correct? This means that if I have two multiconfigs for the same config, qtwebengine will be compiled twice for example, right?
<rburton>
they are share sstate
<rburton>
erm
<rburton>
they can share sstate
<vd>
I recall there was a caveat with using multiconfig to explicit your build variants, but I can't recall what was it
<rburton>
if you have two multiconfigs that are identical, the problem you have is racing (two threads both with different routes to the same hash, so they both decide to build the same thing)
<vd>
rburton hum ok, so while you can, it's not ideal to use multiconfigs to explicit e.g. a "production" and "development" build with you simply set a custom OVERRIDES to tweak the software stack. Am I correct?
<khem>
multiconfig makes sense when your product has n different SOCs running different OSes
<vd>
s/with/where/
<khem>
everything else is stretching it too far
<vd>
khem by production you mean having binaries built for different architectures without the same image, correct?
camus has quit [Ping timeout: 240 seconds]
<vd>
by product*
camus has joined #yocto
<khem>
right e.g. say you have a baseband running cortex-r another DSP like chip running cortex-m and cortex-a for main CPU
<khem>
or more like backplace running a x86_64 and line cards running some mips and some ppc and control plane running arm
<vd>
and you need to package all that in the same .wic image for example
<khem>
correct
<vd>
I see, that was my understanding. I just wanted to make sure before going too far with local.conf tweaks
<vd>
multiconfigs seemed idea but are clearly not the expected usage.
<khem>
you could be creative but know that there might be cracks
<vd>
khem I understand. I clearly want to avoid any potential cracks and keep it simple. I guess I have no choice but to have tooling (like a custom script or kas config fragments) to compose a build and its variants (prod, dev, etc.)
<khem>
prod/dev/ etc are either images or distro configs depending upon what you are doing in them
<vd>
khem yes they are indeed distro configs. But would you go as far as defining <distro>.conf, <distro>-devel.conf, <distro>-prod.conf, etc.? That's where I'm struggling
<khem>
yes
<khem>
you can still share sstate
<vd>
I guess a simple compromise is having distro include files conditionally included with e.g. config/distro/includes/${PROFILE}.inc
<vd>
so that I explicit the variant in a config file but I enable it via setting a variable in local.conf
dj has joined #yocto
dj is now known as Guest9356
<Guest9356>
for `oe-run-native` how can I run a program as root?
<khem>
perhaps use 'sudo ' its a wild guess, but it perhaps will already run under pseudo tool from OE so explicit sudo may not be needed
<Guest9356>
my programs needs sudo access for sockets and network interfaces
<vd>
khem: I'm assuming that you meant that building different distros can share sstate
<khem>
yes right
<Guest9356>
khem, says command isn't found when i put sudo before oe-run-native as well as after the recipe and before the command
<vd>
I was discussing about organizing the distro files without ending with dozen of distros, but I think I figured out with the include files trick.
marc1 has quit [Read error: Connection reset by peer]
<kanavin>
they're having merge conflicts all over the place, so it'd be better to land them upstream first
<vd>
can two distros share the same DEPLOY_DIR?
camus has quit [Ping timeout: 252 seconds]
camus has joined #yocto
<kanavin>
vd, what's the use case?
<rfs613>
hmm, I'm able to run "bitbake -c cleansstate $PKG; bitbake $PKG", but for the same PKG, running "devtool modify $PKG" fails while applying patches, and no workspace is produced.
<vd>
kanavin: I am building a generic distro and few variants for it (for dev tweaks, hardened for prod, branding, ...) and I wanted all the builds to deploy the same directory to ease development and archiving in CI.
<kanavin>
vd, I'm afraid those builds will step on each other
johntoomey has quit [Ping timeout: 256 seconds]
<vd>
kanavin: bad practice, I see. I wanted to avoid an additional copy step outside of bitbake, but that will be tricky. Unless maybe with DEPLOY_DIR .= "/${DISTRO}" in the distro conf and DEPLOY_DIR = "/srv/deploy" in local.conf?
<kanavin>
vd, I don't think it's a good idea to make bitbake deploy directly somewhere public to be honest. I'd rather do any needed copying after bitbake is done.
<vd>
kanavin it isn't public, it's the "staging" place after build where jenkins will pick and copy them somewhere else
marc1 has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
<vd>
DEPLOY_DIR .= "/${DISTRO}" should avoid conflicts...
<vd>
do you guys end up with many distros in your projects?
florian has quit [Ping timeout: 240 seconds]
MauroAnjo has quit [Ping timeout: 256 seconds]
otavio has quit [Read error: Connection reset by peer]
otavio has joined #yocto
GNUmoon has joined #yocto
<khem>
kanavin: I think its ok perhaps I will move that patch to meta-riscv
<kanavin>
khem, thanks, I thought seccomp isn't a particularly critical feature
<khem>
it is a distro feature so someone can disable it for rv32
goliath has quit [Quit: SIGSEGV]
kiran_ has quit [Ping timeout: 252 seconds]
goliath has joined #yocto
NishanthMenon has quit [Ping timeout: 245 seconds]
NishanthMenon has joined #yocto
florian has joined #yocto
F_Adrian has quit [Ping timeout: 265 seconds]
<RP>
jonmason: I'm basically asking if you have a preference on direction. My preference is not the "-nocrypto" variant but to add a "-crypto" one
mvlad has quit [Quit: Leaving]
<RP>
I've not seen a patch with the right description yet :/
<jonmason>
Sorry, been running around all afternoon.
<jonmason>
Here is my fundamental question. Do we care about good performance for the majority or everything working by default?
<jonmason>
I think we care about everything working by default, which means that -nocrypto should be the default
<jonmason>
and those with the crypto offload will need to add a new DEFAULTUNE
<RP>
jonmason: which matches what I'm thinking
<RP>
jonmason: there is a patch which does this but it needs a better description
<RP>
i.e. acknowledges it is a breaking change and what someone needs to do if they have the version of the hardware with offload
<jonmason>
I need to tweak my lei search parameters
<jonmason>
RP: should I comment with a recommended description?
<RP>
jonmason: I just somehow need a patch I can queue :)
<jonmason>
RP: I see khem and Jagadeesh's, but neither is setting the default
<RP>
jonmason: I thought Jagadeesh added a -crypto and changed the default current one to drop the extension ?
<RP>
jonmason: which I think does what we're meaning?
<jonmason>
yes, looking at them better now
<jonmason>
I think Jagadeesh's is more inline with what we want
<jonmason>
and I think adding makes more sense than subtracting
* RP
agrees
<jonmason>
base plus feature, which is how everything else is
<jonmason>
there is a "hole" though
<jonmason>
it is possible to have crc without crypto
<jonmason>
and this doesn't cover that
<RP>
jonmason: worry about it if anyone ever finds that hardware?
<jonmason>
yeah
<RP>
I think we just have to focus on the things which actually exist
<jonmason>
I'm just thinking about making this more modular to cover every crazy permutation, which probably doesn't even exist in the wild
<jonmason>
exactly
<RP>
jonmason: I think we shouldn't do that, that path contains madness
<RP>
we have enough madness
* jonmason
agrees
<jonmason>
silver lining of tonight is that I can work until 9pm without distraction
<RP>
jonmason: we have the option of adding combinations which I think is the important thing
<jonmason>
yes, it can be extended if some random person needs it
goliath has quit [Quit: SIGSEGV]
<jonmason>
now to write an email asking who wants to join me in making YP/Oe more inclusive, in the language way
<jonmason>
speaking of madness, rburton said I was entering into it by running builds on an old atom setup
<jonmason>
after running lots of builds today, I have to say he was right
<RP>
jonmason: atom systems don't make good build machines. At least it wasn't quark I guess :)
<jonmason>
RP: my thought was since it should be mostly sstate, it wouldn't matter too much. very wrong. even building only 900 packages took over 4h (which was the upper limit in CI)
<RP>
jonmason: atom isn't so good with IO :(
<RP>
(and sstate is mostly IO)
<jonmason>
that seems like a fatal flaw, as the whole point for a low power system should be IO driven
<jonmason>
I need to get rid of all my old HW that's not capable of being either a build or testbed, thus my looking at this old atom system
<RP>
jonmason: I wondered what to do with that quark after it took a couple of minutes to boot up
<jonmason>
wow that sounds as bad as booting on an emulator
<jonmason>
I did board bringup on an a57 bases SoC, and it literally took 30mins to boot the kernel. 1 sec per char to the terminal adds up really fast
<RP>
jonmason: it was painful. I remember why I don't use that hardware now
<RP>
jonmason: to be fair that board did have some weird stuff on it (mcafee and more)
* RP
didn't look too hard
dev1990 has quit [Quit: Konversation terminated!]
<jonmason>
I hope this was after you left intel, and thus weren't obligated to like the board