<JPEW>
gnutls needs a "doc" PACKAGECONFIG that meta-mingw can _remove (mostly because of the examples, not the documentation but there is no configure option for just that)
<JPEW>
or patch the examples out of the makefile I guess :/
<JPEW>
And I don't know why libidn is installing it's .def file. I think it should not be.
qschulz has quit [Read error: Connection reset by peer]
qschulz has joined #yocto
Vineela has quit [Quit: Leaving.]
robbawebba has quit [Quit: WeeChat 3.0.1]
xmn has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 244 seconds]
camus1 is now known as camus
<JPEW>
ah, khem already added libgnurx. For him "later" apparently meant "may" :)
wmiles has quit [Read error: Connection reset by peer]
wmiles has joined #yocto
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
rcw has quit [Quit: Leaving]
halstead has quit [Quit: Leaving]
Vonter has joined #yocto
x0n^ has quit [Remote host closed the connection]
camus1 has joined #yocto
camus has quit [Ping timeout: 244 seconds]
camus1 is now known as camus
<JPEW>
Ah, looks like it all stems from debuginfod support. Looks easy fix, I should have a patch tomorrow.... bedtime now
x0n^ has joined #yocto
sakoman has quit [Quit: Leaving.]
dev1990 has quit [Ping timeout: 244 seconds]
dev1990_ has joined #yocto
Guest50 has joined #yocto
Guest50 has quit [Client Quit]
goliath has joined #yocto
zpfvo has joined #yocto
camus has quit [Ping timeout: 244 seconds]
camus has joined #yocto
rob_w has joined #yocto
chrfle has joined #yocto
chrfle has quit [Ping timeout: 268 seconds]
mckoan|away is now known as mckoan
<mckoan>
good morning
LetoThe2nd has joined #yocto
chrfle has joined #yocto
roussinm has quit [Quit: WeeChat 3.3-dev]
rob_w has quit [Remote host closed the connection]
<LetoThe2nd>
yo dudX
prabhakarlad has joined #yocto
leon-anavi has joined #yocto
<dvorkindmitry>
could you recomend grsecurity layer for Yocto?
<LetoThe2nd>
dvorkindmitry: gradm is in meta-oe, other than that nothing seems to be out in the wild
zyga-mbp has joined #yocto
<smurray>
dvorkindmitry: I suspect there's nothing useful public given grsecurity releases have been to their paying customers only for over 5 years now
barath has quit [Quit: Bridge terminating on SIGTERM]
shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
khem has quit [Quit: Bridge terminating on SIGTERM]
ejoerns[m] has quit [Quit: Bridge terminating on SIGTERM]
Jari[m] has quit [Quit: Bridge terminating on SIGTERM]
Saur[m] has quit [Quit: Bridge terminating on SIGTERM]
ndec[m] has quit [Quit: Bridge terminating on SIGTERM]
Pierre-jeanTexie has quit [Quit: Bridge terminating on SIGTERM]
janvermaete[m] has quit [Quit: Bridge terminating on SIGTERM]
asus_986_gpu[m] has quit [Quit: Bridge terminating on SIGTERM]
moto_timo[m] has quit [Quit: Bridge terminating on SIGTERM]
jordemort has quit [Quit: Bridge terminating on SIGTERM]
cody has quit [Quit: Bridge terminating on SIGTERM]
Emantor[m] has quit [Quit: Bridge terminating on SIGTERM]
Andrei[m] has quit [Quit: Bridge terminating on SIGTERM]
kayterina[m] has quit [Quit: Bridge terminating on SIGTERM]
fabatera[m] has quit [Quit: Bridge terminating on SIGTERM]
shoragan|m has quit [Quit: Bridge terminating on SIGTERM]
Spectrejan[m] has quit [Quit: Bridge terminating on SIGTERM]
alex88[m] has quit [Quit: Bridge terminating on SIGTERM]
AlessandroTaglia has quit [Quit: Bridge terminating on SIGTERM]
dwagenk has quit [Quit: Bridge terminating on SIGTERM]
Andrei[m] has joined #yocto
kayterina[m] has joined #yocto
sstiller has joined #yocto
jordemort has joined #yocto
janvermaete[m] has joined #yocto
Emantor[m] has joined #yocto
Jari[m] has joined #yocto
Saur[m] has joined #yocto
khem has joined #yocto
shoragan[m] has joined #yocto
Pierre-jeanTexie has joined #yocto
cody has joined #yocto
moto_timo[m] has joined #yocto
ejoerns[m] has joined #yocto
barath has joined #yocto
ndec[m] has joined #yocto
shoragan|m has joined #yocto
Spectrejan[m] has joined #yocto
AlessandroTaglia has joined #yocto
alex88[m] has joined #yocto
asus_986_gpu[m] has joined #yocto
fabatera[m] has joined #yocto
dwagenk has joined #yocto
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
BCMM has joined #yocto
kanavin_ has quit [Quit: Leaving]
kanavin has joined #yocto
mckoan is now known as mckoan|away
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
prabhakarlad has quit [Quit: Client closed]
Cubi_ has joined #yocto
Cubi_ has quit [Remote host closed the connection]
weltling1 has joined #yocto
weltling1 has left #yocto [#yocto]
otavio has quit [Remote host closed the connection]
weltling1 has joined #yocto
prabhakarlad has joined #yocto
weltling1 has left #yocto [#yocto]
goliath has quit [Quit: SIGSEGV]
x0n^ has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
x0n^ has joined #yocto
BCMM has quit [Quit: Konversation terminated!]
tnovotny has quit [Quit: Leaving]
zyga has joined #yocto
chrfle_ has joined #yocto
chrfle has quit [Read error: Connection reset by peer]
zyga-mbp has quit [Ping timeout: 268 seconds]
<Saur>
RP: We upgraded to Hardknott the other day and I have now started to get reports from our developers that they are getting errors due to the change JaMa did to sstatesig.py in Februrary where he changed a warning about missing sstate manifests to an error. Do you know if there is any issue tracking the underlying problem, or if anyone has looked into it?
BCMM has joined #yocto
<RP>
Saur: the issues we knew about were fixed in master as far as I know
<Saur>
RP: Ok. At least I can repeat the error we are seeing easily so hopefully I can find out what is causing it. It may or may not be related to the abuse of native that we do, so I don't know yet if it is due to something in OE-Core, or in our layers...
<RP>
zedd: I was nearly at the point of asking whether your box of shiny perf hammers was available to try and beat it into shape (again) but I think I have a patch instead
<zedd>
RP: oh yah ? I was just looking up my notes on doing the reproducible builds this morning.
<RP>
zedd: I've tested that fixes the issue. I don't know if it breaks anything else as yet :)
sstiller has quit [Quit: Leaving]
roussinm has joined #yocto
goliath has joined #yocto
rob_w has quit [Quit: Leaving]
sakoman has joined #yocto
Alban[m] has joined #yocto
<Alban[m]>
Hi! I have a task that use a script from my layer, how can i add a dependency so that the task is re-run if the script changes?
kxkamil has quit [Quit: Leaving]
<Saur>
RP: It seems it is looking for a manifest called tmp/sstate-control/manifest-x86_64_x86_64-binutils-cross-aarch64.populate_sysroot, however the manifest that exists (assuming that it is the one it is actually looking for) is tmp/sstate-control/manifest-x86_64_aarch64-binutils-cross-aarch64.populate_sysroot. I.e., it is using "${BUILD_ARCH}_${TARGET_ARCH}", but only "${TARGET_ARCH}" exists. I don't know enough about the sstate manifests to
<Saur>
know if the former is supposed to exist, or if it is looking for the wrong one...
<RP>
Saur: cross should have build and target in it fwiw
<Saur>
RP: Does that mean that the tmp/sstate-control/manifest-x86_64_aarch64-binutils-cross-aarch64.populate_sysroot manifest is in the wrong place, or are both supposed to exist?
<zedd>
RP: makes sense to me.
<zedd>
our perf scripting is not really used much, so it is super low risk.
<zedd>
if someone really is using it, it is much easier to just wait for them to complain than to spend cycles thinking about it too much.
<Saur>
RP: Or not. Now I'm confusing myself. :(
<RP>
Saur: with it being cross there would be one per cross architecture you'd built for
<RP>
zedd: cool, I'll try putting it in for testing
<Saur>
RP: Where are the manifests created?
<RP>
Saur: sstate.bbclass
camus has quit [Ping timeout: 268 seconds]
camus has joined #yocto
<JPEW>
What ended up being the crazy qemu/kernel problem? I saw a resolution was found, but I couldn't find what it was
<JPEW>
nm, I found the ML post
<RP>
JPEW: kernel bug with a one line fix, use after free of a dentry
<JPEW>
RP: fun!
<JPEW>
RP: I have the fix for meta-mingw.... does disabling debuginfod for MinGW SDK sound OK?
wesm has joined #yocto
<RP>
JPEW: yes, I confirmed on the AB that reverting the debuginfod patches "solved" the issue too
<JPEW>
RP: Cool. I have the patch to selectively elide it in meta-mingw, it will be available in a few minutes
<JPEW>
RP: On the ML and master-next. I'll be away starting on Friday, so feel free to push to master if it works
xmn has joined #yocto
<RP>
JPEW: thanks!
<RP>
JPEW: happy to have that fixed
<Saur>
RP: Do you think I am on the right track if I ask myself why it is looking for the manifest for the cross compiler when it is a task for a native recipe that is executing?
<RP>
Saur: that does seem a little odd
<RP>
Saur: have you looked at the task graph from -g ?
<Saur>
RP: I think I've found the problem. Definitely in our mess. ;)
<RP>
Saur: that is a relief from my perspective ;-)
<Saur>
We build native variants of some kernel module recipes, which then are expected to only install header files. But it seems there is a case where the dependency on the kernel slips though, which obviously is a bad idea...
kayterina has quit [Remote host closed the connection]
zpfvo has quit [Remote host closed the connection]
Guest2998 has joined #yocto
Vineela has joined #yocto
<Saur>
RP: Yes, that fixed it. Thanks for the help. :)
<Guest2998>
hi. would anyone be able to help me with pam and pwquality? No matter what I do, passwd will not respect my setting. I have tried https://wiki.yoctoproject.org/wiki/PAM_Integration#passwd as well without luck. lastly...the same config I am using on my platform work on ubuntu, just not on my platform
<RP>
Saur: np, glad it wasn't too painful
chrfle_ has quit [Ping timeout: 268 seconds]
<Saur>
Well, it is a lot easier to debug a problem when it is easily repeatable.
<RP>
Saur: I dream of those
<Saur>
I can understand that based on the discussions I've seen here lately...
ilunev has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zibri has joined #yocto
ilunev has joined #yocto
<ecdhe>
I have a TI-based SoC with a vendor uboot+kernel from the 2.6 series; it builds with the am33517-evm defconfig. I want a newer kernel, so I used yocto and got the meta-ti and meta-arm layers. Now I can build a new u-boot+kernel from the 5.10 series.
<ecdhe>
However, the newer kernel doesn't run.
<ecdhe>
By doesn't run, I can't be sure it's not running, but I get no serial output
<ecdhe>
I built it with the exact same defconfig (there's actually a "machine" for it in the meta-ti layer)
<RP>
paulg: what did you make of "As this is unlikely to be a real-world problem both in probability and circumstances" :)
* RP
doesn't live in the real world
<paulg>
RP, I guess he hates LTP more than I do?
<RP>
paulg: probably :)
<paulg>
in any case as far as the bigger picture goes, it will land in mainline.
<ecdhe>
The vendor's 2.6 kernel args in uboot points to ttyO2 as the serial port. The yocto kernel args in uboot point to ttyS2. On a lark, I changed ttyS2 back to ttyO2 just in cast the kernel simply wasn't outputting to my serial console
<RP>
paulg: right, Im just happy its heading in
<paulg>
I'd kinda thought Al would respond/integrate it since it was his commit that introduced it, but whatever.
<paulg>
in any case, it is on an open list with a maintainer ACK, so zedd can plop it down wherever he wants to make the pain go away.
<ecdhe>
But still no output. I've tried compiling with earlyprintk but don't get output. Both vendor uboot and yocto uboot run and give an interactive console, but neither of them can start the yocto kernel.
Guest2998 has quit [Quit: Client closed]
<ecdhe>
What would you do for a next step to get this working?
<ecdhe>
I'm thinking jtag to see if I can see the state of the processor
<zedd>
paulg: I'll grab it now, of if you want to git-send-email me a copy, I can do it that way as well. I'll figure out the version range after that.
<zedd>
I have pending -stable, and other changes, so I'll just drop it onto that queue and send it.
<paulg>
RP, I had to bend over backwards and tie my shoes the same way as you just to reproduce it locally, so I can't really argue with the probability part, but at the same time the Yocto autobuilder is kinda doing its thing out in the open as a fringe member of The Real World.
<ecdhe>
I've heard that dmesg is a circular buffer, I may be able to look at the kernel's linker map, determine its location in memory, and see if any messages are printed there...
<RP>
paulg: I agree, its fine, I'm just bemused :)
<paulg>
zedd, the as-sent thing on lore applies to both v5.10 and v5.13-rc6 as-is, so unless you want a copy on the linux-ycoto list for transparency, I'll just let you ...
<paulg>
I didn't test v5.4 -- in case people are still running autobuilds there and want to accelerate integration vs. wait for gregKH and the cgroups folks (~2 months?)
<paulg>
kernel-source$git am 0001-cgroup1-fix-leaked-context-root-causing-sporadic-NUL.patch
<paulg>
kernel-source$
<RP>
paulg: I now have the dilemma of whether I re-enable some ltp tests which I thought were a hang :/
<paulg>
RP, I now have the dilemma of whether I run screaming the next time you and zedd ask me to help look at a tough issue. :-P
<paulg>
joking aside, any tests that came after that cgroup test easily could have been impacted.
<RP>
paulg: I was wondering what the reaction will be next time I find a "kernel bug" :)
<RP>
paulg: I'll re-enable them and see how things look as it seems likely it was related
<paulg>
RP, well I originally fell into the same trap as everyone else, rewinding to v5.10 vanilla, and then even v5.4 -- it is easy to think "no way this has been floating out there since b4 that - hence it can't be kernel."
<paulg>
On the plus side, I can say I now know how to build qemu, and I even eduma-cated zedd on how to run LTP. :)
<zedd>
I can't even spell ltp
_whitelogger has joined #yocto
<paulg>
Are there a subset of autobuilder issues that are not annoying?
prabhakarlad has quit [Quit: Client closed]
<moto-timo>
FWIW, I have a branch for upgrading Python 3.8.2 in dunfell to 3.8.10 (bug fixes by definition)
* moto-timo
was blind to that commit for some unknown reason
prabhakarlad has quit [Quit: Client closed]
camus1 has joined #yocto
camus has quit [Remote host closed the connection]
camus1 is now known as camus
* RP
wonders if we should get rid of forcevariable by default
* RP
notes there is a use of it in OE-Core which makes me rather unhappy :/
<Saur>
RP: I like Mark's solution with a recipe specific override.
<fray>
I've had to do that more then once, usually for some odd ball situation in bbappends
xtopher has joined #yocto
LetoThe2nd has joined #yocto
<RP>
if we do that everytime we need to do that the metadata will be unreadable
kpo_ has quit [Read error: Connection reset by peer]
kpo_ has joined #yocto
<Saur>
*shrug* I am not sure it would be worse than a new operator when it comes to understanding the metadata, but then I have not fully understood the use case for when it is applicable.
<kergoth>
I kind of feel like we should both add the operator for general usage and also consider pb's approach to separating variables based on usage as well.
zyga has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<moto-timo>
darn, that patch doesn't affect the ptest failure
<RP>
kergoth: there is definitely a case for making better apis for the more complex class code
<fray>
Khem (or anyone else) do we have newlib-nano support at all in our layers? (I'm not overly familiar with the different between newlib and newlib-nano)
<LetoThe2nd>
fray: something baremetal-ish?
<fray>
Ya.. I'm not even sure if newlib-nano is related to newlib..
<LetoThe2nd>
k
<fray>
person asking said they used to get it from ... forgetting the name of the cross-toolchain builder
<fray>
cross-tool-ng?
<LetoThe2nd>
crosstool-ng is a classic, sure
<fray>
we moved a while back to all of our toolchains are built using YP sources, but now they're saying the need newlib-nano for some cortex-R5 work.. but I'm not overly familiar with this stuff
Guest50 has joined #yocto
<fray>
Found some zypher references to newlib-nano.. does look like a different libc sourcebase
<LetoThe2nd>
meh.
<LetoThe2nd>
YALIBC
<fray>
I just can't tell if it really is the same or a differnet source base
prabhakarlad has joined #yocto
<LetoThe2nd>
k
<LetoThe2nd>
(me is mostly afk, but interesting to hear. you crank newlob toolchains out of yp/oe too?)
<RP>
fray: we don't have that but I can't see it being hard to add
<fray>
Ya, I just can't figure out right now if it's purely a configuration switch -- or if it's actually a new code base..
<RP>
fray: you want alejandr1
<fray>
everything I found (quick googling) is many years old
<fray>
like 2013-2014 era.. I wouldn't bring in a libc that old
<LetoThe2nd>
k
* LetoThe2nd
resorts back to family things.
<fray>
to me the value has always been the collection of the components, no individual part of piece has huge value -- but together, it all works and people make it better
<fray>
oops wrong window
sakoman has quit [Quit: Leaving.]
<moto-timo>
adding packagegroup-core-buildessential to python3-ptest RDEPENDS makes those test cases pass...
zyga-mbp has joined #yocto
<RP>
kergoth: I'm reading that older oe-arch thread about variable defaults and thinking we do need to do someting
<RP>
kergoth: making = set a default value and having += and friends stack against it regardless of parse order, then ditching _append and _prepend is kind of getting the best feel of a success rereading it...
<RP>
maybe doing that opens up the door for a clear "reset this variable" operator too
<kergoth>
i've thought about that too, almost making everything lazy, so _append/_prepend becomes redundant
<RP>
kergoth: exactly
<RP>
and maybe even ditch ?= and ??=
<moto-timo>
yocto-4.0
<kergoth>
my only concern with that would be how to override and clear pending +='s, such as in the case where a recipe wants to override/undo something done by a class it inherits without having to use _remove
<LetoThe2nd>
yocto-3.14159
<khem>
fray: its keith's fork, I dont think it is main stream
<khem>
seems some concoction of AVR libc an newlib
<fray>
RP what about dropping .= / += to a single one with.. effectively forcing everyone to add the ' '?
<kergoth>
say a class does a +=, the recipe's = wouldn't undo that regardless of before or after the inherit line. and maybe that's *good*, it becomes less imperative
<RP>
kergoth: clear all or clear some?
<kergoth>
but would still need a way to do it, probably..
<moto-timo>
khem: would python3-ptest RDEPENDS on packagroup-core-buildessential break on musl? brain is slush
<RP>
kergoth: that is where the operator in the second thread may come in
<fray>
khem -- thanks for the input
<kergoth>
RP: could we then implement -= as an order-dependent operation? apply default, apply first +=, apply second +=, apply. first -=, apply another +=, return result
<moto-timo>
khem: or might need to skip the test_ctypes cases that expect/require gcc
<kergoth>
with all being expansion-time steps
<RP>
kergoth: position dependent remove? hmm
<kergoth>
my only concern there would be how expansion is handled, if we need to -= something that came out of a ${@}, then we'd need to run expansion on each *piece* of the variable
<RP>
moto-timo: adding that will destroy people's build performance :(
<kergoth>
i.e. expand the part we're adding with +=, then append it, rinse, repeat
<RP>
kergoth: exactly, which is why we batch the removes last right now
<khem>
new users find assignment operators quite confusing and mixed with append/prepend .= =. this becomes even steeper chase
<kergoth>
yeah, hence rp's desire to simplify by making everything essentially a clear statement of intent, basically. += indicates a desire to append regardless of what the current default assigned value is in what order
<kergoth>
making a position dependent -= would move away from that, though.. but in a way would be less brute force than a 'clear pending operations' operator
* kergoth
shrugs
<RP>
kergoth: I think I'd be in favour of a simple brute force :)
<moto-timo>
RP: given it's only 2 or 3 test cases in the ctypes suite, probably better to just patch them out :/
<RP>
moto-timo: I think so
<kergoth>
but i like the idea of what you're proposing, it'd probably avoid a lot of confusion and would help move away from the mixed order-dependent imperative/declarative situation
<RP>
kergoth: I guess the test is to prototype something and see how it looks/feels
<moto-timo>
I think it's 2 our of 423 test cases, so meh
<kergoth>
for what it's worth, i'd also like to see 'inherit' stop being order dependent. i'd actually like to see a recipe-level INHERIT instead, which always either goes before or after the recipe in parsing, not wherever we happen to shove it
<kergoth>
combined with what you're proposing, i expect its order would be less of an issue than it is now
<ecdhe>
I have kernel built with yocto. It has no console output when I jump to it from U-Boot. My filesystem is core-image-minimal which only logs to /var/volatile/log. Is there an easy way to make the kernel log to /var/log once it's powered up?
<kergoth>
if += always applies, where the class is parsed doesn't matter quite as much
<RP>
kergoth: the hard bit is that some of our classes are very picky about inherit position but yes, it would be a good time to revisit that
<rburton>
ecdhe: does it have no console by design, or do you want it to have a console?
<kergoth>
i think we'd have to verify the behavior of them all after implementing your proposal anyway :) we'd have to audit for changes to the final metadata
<RP>
kergoth: yes, there would be quite some audit needed
tangofoxtrot has joined #yocto
<kergoth>
we should add the ability to have dependencies between our hooks/handlers while we're at it, which might help alleviate the inherit order issues since you'd have more control over when the event handlers are run, in what order :) but could be a later step :)
<RP>
kergoth: I did try and do that at one point, the problem was figuring out the "format" for dependencies and then the need for some kind of graph handling at which point I decided the current approach wasn't so bad ;-)
<ecdhe>
rburton: it has a console, I just have something misconfigured
<kergoth>
hah, yeah, there's something to be said for simplicity, especially when we have so little of it already
<kergoth>
but if you end up working around it with other hacks...
<RP>
kergoth: how often do we really have problems with that though? They also generally people like you/me dealing with them, not end users
<RP>
I do like the idea, I think its an independent problem though (mostly)
<kergoth>
that's true. mostly around annoyances with things like when class processing happens for native/multilib/etc. most don't need to worry about that sort of thing
<kergoth>
agreed
<kergoth>
first step would be to prototype what you proposed for the operator behavior
<RP>
kergoth: I was just thinking about prototyping and validation. Have a few ideas....
<kergoth>
wonder if we couldn't have bitbake perform both sets of logic, stash the old value, and compare the resulting values at expansion time
<RP>
kergoth: I was thinking a quick tinfoil script to write out the bitbake -e output for each recipe at parsing, then you get a directory tree representing the parsed data which you can compare
<kergoth>
ah, not a bad idea. could always do sigdata comparison as well, to limit to the actually used vars
<RP>
kergoth: right, exactly
<ecdhe>
rburton: my working 2.6 kernel can get to the console. My 5.10 kernel cannot. I don't know if that's because the 5.10 is not running, or because it's just misconfigured
<ecdhe>
So I wanted to see if I could get it to write to my SD card
<ecdhe>
But there's no /var/log/kern.log
halstead has joined #yocto
<khem>
moto-timo: it should work fine, why do we need to depend on build-essential meta package, do we know the reason?
<khem>
ecdhe: check console names in kernel cmdline params in 2.6 e.g. TI chips used ttyOx for serial console but then it was changed to use ttySx
<khem>
jumping from 2.6 to 5.10 is almost like an intergalactic flight
<ecdhe>
khem: I have the change you describe!
<ecdhe>
Older U-boot passes in ttyO2, new U-Boot passes ttyS2 -- and inittab etc have to be updated to reflect that or you won't get a shell
<ecdhe>
Unfortunately I don't have ANY serial output from the newer kernel even with this correction
<khem>
also check for load addresses and DTB addresses since kernel size will be different they may need adjustments
<khem>
yeah its perhaps dead before taking first breath
lacouture[m] has joined #yocto
Guest50 has quit [Quit: Client closed]
<NishanthMenon>
ecdhe, most newer kernels do enable earlycon -> so you might want to enable that.. typically if you have trashed dtb with parts of kernel, you should see recognizable earlycon logs..
<ecdhe>
NishanthMenon: the loadaddr from TI's latest U-Boot is 0x8200 0000. The fdt_addr is 0x82C0 0000. TI's latest kernel from meta-ti weighs in at 4.9mb, for a back address of only 0x824B 7200.
<ecdhe>
0x824 is not quite 0x82C, so I don't have a tonne of headroom, but I shouldn't be clobbering my fdt
pidge_ has quit [Remote host closed the connection]
<NishanthMenon>
ecdhe, you should probably checkout earlycon. btw, a few of us ti folks are on #linux-ti if you might want some specific poking :D
<ecdhe>
NishanthMenon: thanks
wesm has joined #yocto
<RP>
zedd: "PaulG tracked down the AB intermittent issues" - all of them?! :)