<kanavin>
(see the exchange with adrianf on the list)
Daanct12 has quit [Ping timeout: 255 seconds]
Daanct12 has joined #yocto
doquiros1 has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
<RP>
kanavin, yocton: I've pushed auh with some further tweaks. If it still has issues we'll fix on the branch
<diecore>
Anyone experienced with AT91SAM mpus? I am having hard time to figure out what's wrong and I get -2 error in the gpiod_get() function to control a gpio pin.
<kanavin>
RP: thanks, it does help to do trial auh runs on any changes to it or its config, as it's a brittle thing
<RP>
kanavin: definitely and this was some fairly big changes
<RP>
good ones but...
<yocton>
RP: yeah... -_-' As kanavin said: thanks for the trial runs. I've tried to test as mush as possible but I could not replicate AB 1:1.
<RP>
yocton: the metrics target is blowing up badly on the AB too with the stable branches. I'm chasing config around there too
rfuentess has quit [Remote host closed the connection]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
xmn has joined #yocto
doquiros1 has quit [Remote host closed the connection]
doquiros has joined #yocto
amitk has quit [Ping timeout: 258 seconds]
amitk has joined #yocto
doquiros has quit [Remote host closed the connection]
doquiros has joined #yocto
amitk has quit [Ping timeout: 240 seconds]
camus has quit [Remote host closed the connection]
alessioigor has quit [Read error: Connection reset by peer]
alessioigor has joined #yocto
doquiros1 has joined #yocto
doquiros has quit [Quit: doquiros]
doquiros1 is now known as doquiros
GParker__ has joined #yocto
doquiros has quit [Remote host closed the connection]
doquiros has joined #yocto
GParker_ has quit [Ping timeout: 255 seconds]
doquiros has quit [Read error: Connection reset by peer]
doquiros1 has joined #yocto
doquiros1 has quit [Read error: Connection reset by peer]
astlep550401 has quit [Ping timeout: 252 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
astlep550401 has joined #yocto
goliath has joined #yocto
rob_w has quit [Remote host closed the connection]
Minvera has joined #yocto
lexano has joined #yocto
taruu has quit [Remote host closed the connection]
vladest has quit [Quit: vladest]
Daanct12 has quit [Quit: WeeChat 4.1.1]
GParker_ has joined #yocto
florian_kc has quit [Ping timeout: 255 seconds]
GParker__ has quit [Ping timeout: 240 seconds]
Danct12 has quit [Read error: Connection reset by peer]
florian_kc has joined #yocto
leon-anavi has joined #yocto
neofutur has quit [Ping timeout: 260 seconds]
neofutur has joined #yocto
vladest has joined #yocto
Xagen has joined #yocto
emdevt__ has quit [Read error: Connection reset by peer]
emdevt has joined #yocto
jmd has joined #yocto
linfax has quit [Ping timeout: 272 seconds]
GParker__ has joined #yocto
Danct12 has joined #yocto
GParker_ has quit [Ping timeout: 258 seconds]
Chaser has quit [Quit: Chaser]
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
Chaser has joined #yocto
perceval has joined #yocto
<perceval>
Hello all, I hope you're well
<perceval>
ll
<perceval>
I have a yocto build running in my CI with GCP cloudbuild. I would like to collect logs in all WORKDIR/tmp and all pseudo.log in case of failure. What is the best approach to do that?
sotaoverride is now known as Guest8643
sotaover1ide is now known as sotaoverride
perceval has quit [Quit: Leaving]
perceval has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
jmd has quit [Remote host closed the connection]
florian_kc has quit [Ping timeout: 260 seconds]
Chaser has quit [Ping timeout: 255 seconds]
zpfvo has quit [Ping timeout: 258 seconds]
Chaser has joined #yocto
zpfvo has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
jmd has joined #yocto
<qschulz>
tlwoerner_: I think we better split rockchip-rkbin into two recipes, one for tf-a (bl31) and one for ddr.bin (TPL)
<qschulz>
then you don't have this issue
<qschulz>
and since rk3588 is about to gain support for upstream tf-a.. i think we should think about this
<qschulz>
this would also allow to have ddr.bin for rk3308 from an older version but tf-a for rk3308 from a newer rockchip-rkbin
GParker_ has joined #yocto
tlwoerner_ has quit [Quit: Leaving]
tlwoerner has joined #yocto
GParker_ has quit [Client Quit]
<tlwoerner>
qschulz: isn't that the whole point of the tf-a vs rkbin split in the first place
<qschulz>
tlwoerner: i am not following
<tlwoerner>
we're either using tf-a or rkbin to supply startup bits
<qschulz>
no no no
GParker__ has quit [Ping timeout: 240 seconds]
<qschulz>
tf-a is NOT providing "startup bits"
<qschulz>
but rkbin has a prebuilt tf-a in its git repo
<tlwoerner>
so "startup bits" (i.e. ddr init) is provided either by rkbin or u-boot?
<tlwoerner>
but, coincidentally, the families that have tf-a support also have u-boot providing the ddr init?
<qschulz>
rkbin repo has the startup bits (DDR init with ddr.bin; also called TPL in U-Boot world), TF-A (bl31.elf) and OP-TEE OS (bl32.bin)
<qschulz>
correct, ddr init is done either with rkbin ddr.bin or through U-Boot TPL
<tlwoerner>
lol
<qschulz>
nope, tf-a support doesn't mean U-Boot TPL support
<qschulz>
and in fact, RK3588 will not have this happen
<qschulz>
we likely will have support for upstream TF-A before DDR init in U-Boot
<tlwoerner>
right, it doesn't mean that, but coincidentally, prior to rk35xx that's been the case
<tlwoerner>
ddr init: rkbin or u-boot
<qschulz>
that I cannot say, I think it's just "luck"?
<qschulz>
yup
<tlwoerner>
tf-a: tf-a or rkbin
<qschulz>
yup
<qschulz>
so, why this is actually different and we cannot expect stuff to happen at the same time:
<tlwoerner>
op-tee: rkbin
<qschulz>
TF-A is open-source, and rockchip just have a downstream tree for which they provide only a binary (allowed by the license)
<qschulz>
so, they just take their time to upstream it (they are based on tf-a 2.2 and we're at 2.9 now, with many years of changes in between
<tlwoerner>
are all 3 required? ddr init definitely is, what about the other 2?
<qschulz>
however, the ddr init code is i think absolutely not based off U-Boot
<qschulz>
and I think it is not even necessarily developed by Rockchip
<tlwoerner>
so we should have 3 virtual providers: ddr init, tf-a, and op-tee
<qschulz>
they probably bought the DDR controller IP from some vendor (e.g. synopsys) and got some code from them they adapt to have the serial output somewhere
<qschulz>
ddr init is absolutely required otherwise no DDR, and no DDR = problems :)
<qschulz>
tf-a is absolutely required for Aarch64 machines, because it is a requirement of the Linux k ernel
amitk has joined #yocto
<qschulz>
op-tee, not a requirement at all and i actually read that rockchip prebuild binary isn't even supported right now in upstream u-boot, because they have done things differently than upstream op-tee for the binary format
<qschulz>
so i think we can just ignore op-tee os from rkbin for now
<tlwoerner>
okay! that's very clear
florian_kc has joined #yocto
<qschulz>
although... i do not know if we really need a virtual provider for ddr.bin
<qschulz>
I mean.... mmmmm maybe
<qschulz>
because at one point someone may want to have a switch between rockchip's ddr.bin or U-Boot's
<qschulz>
but can we have u-boot DEPENDS on itself???
<tlwoerner>
lol, i was just wondering about that
<qschulz>
ah no,that's even worse, we require :do_deploy dependency, so we would need u-boot's configure/compile taskto depend on do_deploy of the same recipe, not possible
<tlwoerner>
in the machine config files we would specify u-boot as the preferred provider of ddrinit instead of rkbin
<tlwoerner>
hmm
<tlwoerner>
ouch, i see
<qschulz>
a knob variable then I guess :/
<qschulz>
because i don't think it's a good idea to check PREFERRED_PROVIDER_ddr.bin against BPN for example
<khem>
rockchip's ddr.bin has all kind of fixes which may not be yer in u-boot also called "workarounds"
<qschulz>
khem: yup that too
<khem>
I am yet to get all features working satisfactorily with all upstream pieces on rockchip SOCs or even on rpi
<khem>
invariably fallback to blobs is necessary, its sad but true
<qschulz>
tf-a you should blame rockchip for not doing their job properly
<qschulz>
ddr.bin... well the vendor who sold the IP to rockchip and doesn't allow to provide the source code for it and prevent people from reverse engineer it
JerryM has quit [Quit: Konversation terminated!]
florian_kc has quit [Ping timeout: 248 seconds]
florian has quit [Quit: Ex-Chat]
GParker_ has joined #yocto
vladest has quit [Quit: vladest]
vladest has joined #yocto
goliath has quit [Quit: SIGSEGV]
ptsneves has quit [Ping timeout: 264 seconds]
leonanavi has joined #yocto
leon-anavi has quit [Ping timeout: 272 seconds]
jmd has quit [Remote host closed the connection]
Vonter has quit [Ping timeout: 245 seconds]
Vonter has joined #yocto
leonanavi has quit [Quit: Leaving]
zwelch has quit [Read error: Connection reset by peer]
zwelch has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
perceval has quit [Remote host closed the connection]
silbe has quit [Ping timeout: 240 seconds]
florian_kc has joined #yocto
<RP>
khem: do we want a run of AH posted to oe-devel?
<RP>
AUH
<khem>
I think yes, it will be good to run it maybe at a bi-weekly frequency
zelgomer has quit [Remote host closed the connection]
zelgomer has joined #yocto
<RP>
khem: for now we'll go with manually triggered
<RP>
khem: I'm a bit worried how people will take the hundreds of emails
<khem>
maybe we can post the results and send a single email like we do for CVEs
silbe has joined #yocto
Vonter has quit [Ping timeout: 258 seconds]
silbe has quit [Ping timeout: 246 seconds]
Vonter has joined #yocto
zpfvo has quit [Remote host closed the connection]
Kubu_work has quit [Quit: Leaving.]
tgamblin has quit [Remote host closed the connection]