sng has quit [Read error: Connection reset by peer]
<sjg1>
sng: I replied to it. It looks pretty good. There are some things to tidy up in binman and I am hoping you can drop most of the sandbox tests
umbramalison_alt has quit [Quit: %So long and thanks for all the fish%]
umbramalison has joined #u-boot
tepperson has joined #u-boot
<apalos>
sjg1: We already discussed this publicly with Rob
<apalos>
I mean the node for the public key signature
<apalos>
and we concluded that unless another project needs it, it doesnt make sense to upstrea
<apalos>
and i am not aware of any other open firmware implementations that encode the key in the dts
<apalos>
So there's no gain to standardizing this
<apalos>
We are better of just stripping it
<apalos>
same goes for the nodes in a/b updates
<apalos>
the procedure is described on the spec, anyone can implement that
<apalos>
but the description in the device tree is documented as an internal u-boot binding which is fne
<sjg1>
apalos: I don't recall that conversation and it doesn't make sense to me, to have things in the DT for which we don't have bindings, then starting stripping things out. What is the goal?
<apalos>
get the boards systemready certified
<apalos>
Boards are *already* failing due to existing nonupstreamed node
<apalos>
The signature is just icing o the cake
<sjg1>
So it doesn't matter for now? How long do we have to upstream the bindings?
<apalos>
its failing *now*
<apalos>
and the 2.0 certification test suite has been released for a couple of months
<apalos>
So really we should have code fixing this until we upstream the bindings
<apalos>
but we view thgis differently anyway \
<apalos>
Not all bindings make sense to upstream imho and last time I talked to robher he was on the same page
<sjg1>
Has Linaro upstreamed any U-Boot bindings?
<apalos>
I dont think we havem but I dont see the point here
<apalos>
There's various threads discussing if it should be upstreamed or not and the maintainers shared the same opinion
<apalos>
And the signature node was *not* added by linaro
<apalos>
As i explained on the email, we had none of this problems with the origianl patch version
<apalos>
But what I can do is send you a report of the failed bindings, dm etc
<sjg1>
I'm OK with it so long as we have agreement that the node is adding as a binding at some point.
<apalos>
because I was looking at the dt-schema and the DT repo that they use to verify against, and I only saw some bindings egarding the u-boot env
<apalos>
sjg1: thats the whole point of my email
<sjg1>
But if the intent is to deliberately poison U-Boot's DT so that there is no interest in upstreaming binding, then I am not in favour
<apalos>
We *need* code that strips off bindings until they get upstreamed
<sjg1>
Yes please send the report
<apalos>
but in order to upstream that yuo need the maintainers to agree
sng has joined #u-boot
<apalos>
And i dont see how we can have 100% success
<sjg1>
Your argument would carry more weight if Linaro actually upstreaming *one* binding
<apalos>
anyway, I'll try to run that thing and send you an email
<apalos>
sjg1: the code we need is really 10 lies of code or somethin g
<apalos>
anyway, it's getting late here, we can discuss this on the ML once he sends the patches\
mmu_man has quit [Ping timeout: 260 seconds]
<sjg1>
OK. As I say, pick a binding and upstream it. It would show Linaro's commitment to resolving the binding problem
<apalos>
sjg1: we have shown commitment
<apalos>
there are patches from Jassi on that
monstr has quit [Remote host closed the connection]
<apalos>
They just make little sense to *be* upstreamed
<apalos>
My point is that i dont see this as black and white
<apalos>
Nor I have any will to upstream nodes for the sake ertification
<apalos>
certification*
<apalos>
I am defintely in favor of upstreaming what makes sense. But I am fine having node documented in u-boot as an internal ABI, which we never handover to the next component
<sjg1>
That is the status quo which we are trying to move away from, I thought
goliath has quit [Quit: SIGSEGV]
<marex>
Tartarus: do we want the NEEDS_MANUAL_RELOC gone in 2023.10 ?
mmu_man has joined #u-boot
<sjg1>
apalos: That email thread was not copied to me. Just an oversight?
<NishanthMenon>
pivi: just saw this.. neither Neha nor I were in CC. i will poke neha to do a review, i am a bit tied right now, will try and look on friday. but I think we are in rc1 freeze on next atm, so probably next week sometime is when the freeze lifts
<Tartarus>
pivi: yes, I plan to grab it before -rc2, unless there's some big objection from TI folks, but I suspect there won't be
<Tartarus>
I'll look it over again real quick
LeSpocky has joined #u-boot
<LeSpocky>
hello
<Tartarus>
1/3 is toradex specific , 2/3 has TI comments already, 3/3 seems fine
<Tartarus>
pivi: has someone throw it at the public side of CI, just to make sure there's nothing funny about blobs?
<Tartarus>
That's the only kind of problem that might cause me to get unhappy Friday :)
tepperson has quit [Quit: Client closed]
stefanro has quit [Quit: Leaving.]
prabhakarlad has joined #u-boot
* LeSpocky
just picked up work on sam9x60-curiosity …
<LeSpocky>
problem I face: NAND access is terribly slow, 50 seconds for a single page
tepperson has joined #u-boot
<LeSpocky>
sorry, not for a single page but for 256k which is one block and 64 pages
<LeSpocky>
on linux that block is read in an instant
<marex>
jeeze
<marex>
LeSpocky: out of curiosity (pun intended), are you clock (dividers) configured correctly ?
goliath has joined #u-boot
Eschik1 is now known as Eschik
<pivi>
Tartarus: nope, but we can do it
vagrantc has joined #u-boot
<pivi>
NishanthMenon: yep, I guess Marcel just use patman, and the patches on board/toradex/ does not trigger any ti.com people. In any case, apart from the concern from Tartarus about the blobs, we cannot break anything.
stipa_ has joined #u-boot
stipa has quit [Read error: Connection reset by peer]
stipa_ is now known as stipa
mckoan is now known as mckoan|away
tepperson has quit [Quit: Client closed]
<Tartarus>
pivi: Oh, if Azure fails for non-am62 specific reasons, let me know and I'll hit the "rerun failed jobs" button, which I wish was exposed to everyone :(
<Tartarus>
Or have a few things turned up and I'll see a v5? :)
frieder has quit [Remote host closed the connection]
<pivi>
Tartarus: yep, some issue with the rst files so far
<Tartarus>
and if you're still iterating on those, you can do a python virtual env and pip install -r doc/sphinx/requirements.txt and then make htmldocs and go
mmu_man has joined #u-boot
ezulian has joined #u-boot
Gravis has quit [Ping timeout: 250 seconds]
Gravis has joined #u-boot
redbrain has quit [Read error: Connection reset by peer]
Gravis has quit [Ping timeout: 246 seconds]
Gravis has joined #u-boot
redbrain has joined #u-boot
rvalue has quit [Ping timeout: 246 seconds]
swiftgeek has quit [Ping timeout: 250 seconds]
ezulian has quit [Ping timeout: 246 seconds]
Gravis has quit [Ping timeout: 244 seconds]
Gravis has joined #u-boot
vfazio has quit [Remote host closed the connection]
<LeSpocky>
marex: I'll check that tomorrow, I just copied the dts nodes for nand flash access from sam9x60-ek board
<marex>
LeSpocky: probably just 'md' the clock controller registers
<marex>
LeSpocky: should give you an idea what's up real quick
<marex>
LeSpocky: btw why this old hardware?
<LeSpocky>
and compare with how linux set up those, that's the plan
<LeSpocky>
sam9x60? the soc was just launched two years ago
<LeSpocky>
the idea was to use it for a redesign of a board which currently uses a sam9g20
<LeSpocky>
no need for expensive multi cores
<__ad>
@marex thanks for the job i had to do. It's simple to be tested but give me still some time to understand exactly the relocation thing
<LeSpocky>
but maybe ask Microchip why the made a new SoC with that core
<LeSpocky>
s/the/they/
<marex>
LeSpocky: ahh
<marex>
__ad: no stress, you're welcome
<marex>
__ad: feel free to ask while I still remember what I did there
<marex>
__ad: what worries me is real hardware, it works with qemu, but I have no real hardware to test on
<marex>
LeSpocky: I didn't know that was new :)
<marex>
LeSpocky: as for comparing the registers, yes, either with linux+devmem , or against datasheet
<__ad>
i have 5282, 5307 and 54415
<__ad>
will test on all. But first i need to learn relocation properly
<marex>
__ad: really, ask, I felt like my eyes were each pointing in different direction when I was digging in it
vfazio has joined #u-boot
<__ad>
marex: well, what's the difference from manual reloc and current reloc ?
<__ad>
previously, got table was used, right ?
<__ad>
actually seems the rela tables are used, but still the got seems involved
<__ad>
if you have some basic doc to sudy, welcome
<marex>
__ad: the GOT is still needed, yes
<marex>
__ad: I dont :(
<marex>
__ad: the idea is basically that ... every uh , J and B instruction which is not PC relative has a 32bit word following it
<marex>
that is the jump destination address
<marex>
and uh this dynsym section contains a list of those places in the binary
<marex>
so when you run this relocate-rela tool, the tool patches in the pre-relocation values into those places
<marex>
(before that, those places are just zeroes)
<marex>
during relocation, that stuff in start.S, those places get updated with += relocation offset, and then the code jumps to the relocated u-boot
<marex>
so when relocated u-boot does a jump, that jump destination address is the corrected one
<marex>
that's roughly the gist of it
<__ad>
ok great, reading slowly :)
<marex>
__ad: yeah, I don't want to scare you
<marex>
__ad: also btw the microblaze stuff and how they relocate, that is bonkers
<marex>
__ad: it is too convoluted, so, careful there so you won't get confused
<marex>
__ad: there is also a lot of unneeded fluff in it
<__ad>
how does that -fPIC and got table impact in this ?
<__ad>
before, there was no -fPIC
<marex>
__ad: that generates those dynsym tables , position independent code
<marex>
__ad: and those "patch offset past branch" things
<__ad>
ok. And what is the role of the GOT ?
<__ad>
also GOT was meant for pic
<marex>
__ad: here I am not so sure, it seems GOT pointer is still needed for PC-relative jumps
<marex>
__ad: the other thing is needed for jumps with fixed destination address encoded in code I think
lucascastro has joined #u-boot
<__ad>
ok, thanks a lot for now, elaborating things
<marex>
__ad: note that I am no m68k expert
<marex>
__ad: I literally learnt all that in a few days and I probably screwed up a lot all around
lucascastro has quit [Quit: Leaving]
<__ad>
great :)
<marex>
__ad: I did talk to Geert about it quite a bit
<__ad>
aha ok, i see
<__ad>
why the values in the pre-relocation dynsym are zero and not already the right values ?
<Tartarus>
That's my wrapper called "u-boot-size-test.sh"
<Forty-Bot>
thanks
<Tartarus>
I have another wrapper for global builds
<Tartarus>
(And so yes, the not-obvious thing about buildman for size tests is you build it once, then you run it again to generate the report)
<Forty-Bot>
does it need to be in one run?
<Tartarus>
Or if you can do it in one go, I still have it twice so the report is clear from the build
<Tartarus>
Well, I have wrapper scripts around buildman rather than just using buildman directly, for a few reasons
<Tartarus>
It might be more friendly if you could just tell it what to do once
<Tartarus>
like bloat-o-meter is great, but I think buildman gives more information overall
<Tartarus>
esp since instead of before/after files you can tell it a range of commits and what to build, and let it churn
<Forty-Bot>
yeah, that's nice
<Tartarus>
So sometimes if I'm taking a branch and see a big size increase I'll do a single board and every commit there, to see what change did it
<Forty-Bot>
although surprisingly it does the debian thing and creates stuff in the parent directory
<NishanthMenon>
pivi - i quickly reviewed the dts side of changes - i am hoping neha will check the binman stuff - i suggested a bunch more changes - most of it is exactly the reason why we got the 6.5-rc1 sync in -> cleanups.. the r5.dts should be much more thinner once the changes are done..
<Tartarus>
I think you can tell buildman a default directory to use instead, but, yeah
<Forty-Bot>
did you do a world build? or is it possible to only select boards with CONFIG_SPL set?
<Tartarus>
I did a world build
<Tartarus>
being able to have buildman handle things outside of the scope of the ancient boards.cfg file is on my wishlist :)
<NishanthMenon>
pivi: and suggested some changes to the rst.. i dont think htmldocs ever built on the patch :(
<Tartarus>
Forty-Bot: yeah, we're just limited today to a few options, but at the high level, the "parse all Kconfig, make a db out of it" that moveconfig.py can do could then be used for the "now build me stuff that matches..." part of buildman
<Forty-Bot>
I'd love to have something like that in general
<Forty-Bot>
sometimes I'm working in an unfamiliar area of code and I want to e.g. find a board with CONFIG_FOO enabled, or with CONFIG_FOO but not CONFIG_BAR
<Tartarus>
Right
<Tartarus>
It's just putting all of that together means doing some parsing
<Tartarus>
more than the super quick one we do today :)