<hays>
i will try that.. but I think I need to take a rest.. almost 1am here
<hays>
thanks for digging into it with me
<marex>
hays: well, use the matching DT for your board then
<marex>
the ccpe one
<hays>
yep
<marex>
maybe the SPI NOR pin muxing is different
<marex>
that would explain what you see
<hays>
im not 100% sure which one it is, because the docs kinda suck. but i tried the espressobin-ultra one and kernel modules weren't loading or working like they should
<hays>
so i went back to this (out of tree) dtb
<hays>
anyways good night. i'll probably be back at this
<marex>
yep
adams[1] has quit [Quit: Client closed]
WoC` has quit [Read error: Connection reset by peer]
WoC` has joined #u-boot
guillaume_g has joined #u-boot
sszy has joined #u-boot
ldevulder has joined #u-boot
monstr has joined #u-boot
frieder has joined #u-boot
mckoan|away is now known as mckoan
matthias_bgg has joined #u-boot
guillaume_g has quit [Quit: Konversation terminated!]
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
camus1 has joined #u-boot
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
ikarso has joined #u-boot
tre has joined #u-boot
mmu_man has joined #u-boot
persmule has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
indy has quit [Ping timeout: 264 seconds]
indy has joined #u-boot
jclsn has joined #u-boot
jclsn has quit [Client Quit]
jclsn has joined #u-boot
lucascastro has joined #u-boot
jclsn has quit [Quit: WeeChat 3.6]
jclsn has joined #u-boot
jclsn has quit [Client Quit]
minimal has joined #u-boot
jclsn has joined #u-boot
<hays>
marex: it worked!
<hays>
wait.
<hays>
nevermind. it didn't work
lucas_ has joined #u-boot
lucascastro has quit [Ping timeout: 265 seconds]
<hays>
hexdump looks the same
mmu_man has quit [Quit: reboot]
mmu_man has joined #u-boot
jclsn has quit [Quit: WeeChat 3.6]
lucas_ has quit [Ping timeout: 268 seconds]
tre has quit [Remote host closed the connection]
lucas_ has joined #u-boot
lucas_ has quit [Remote host closed the connection]
davlefou has quit [Ping timeout: 246 seconds]
jclsn has joined #u-boot
davlefou has joined #u-boot
<hays>
ok I think I got it. I was able to take the spi settings from the espressobin-ultra.dts file and stick them in the one I have where everything else works. and its reading the spi now
<xypron>
Tartarus: was there an issue with origin/WIP/07Oct2022 (Pull request for efi-2023-01-rc1)?
<Tartarus>
xypron: no, sorry, I just forgot to push
<Tartarus>
I'll do that shortly
torez has joined #u-boot
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
mmu_man has quit [Ping timeout: 252 seconds]
lucascastro has joined #u-boot
prabhakarlad has joined #u-boot
persmule has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
ikarso has quit [Quit: Connection closed for inactivity]
matthias_bgg has quit [Ping timeout: 265 seconds]
lucascastro has quit [Remote host closed the connection]
matthias_bgg has joined #u-boot
mmu_man has joined #u-boot
umbramalison has quit [Quit: %So long and thanks for all the fish%]
zibolo has quit [Ping timeout: 265 seconds]
<sjg1>
Tartarus: I was looking at the MAINTAINERS N thing...doesn't that mean we need to glob the whole source tree for each occurrence? Is there a more efficient way?
frieder has quit [Remote host closed the connection]
<Tartarus>
sjg1: I was thinking you'd store a list of regexs as well, and then check vs that too when using -R
<Tartarus>
As that's the failure case, I can't take all of those broadcom updates as they use N: to match on files instead of spelling out a bunch of configs, and other things too
<sjg1>
OK, what is -R?
<Tartarus>
What you added to replace running genboardscfg.py and checking for unmaintained defconfigs with
persmule has quit [Quit: Leaving]
persmule has joined #u-boot
faustzero1 has quit [Ping timeout: 268 seconds]
apritzel_ is now known as apritzel
mmu_man has quit [Quit: Reconnecting]
mmu_man has joined #u-boot
JBB[m] has quit [Quit: You have been kicked for being idle]
mmu_man has quit [Ping timeout: 252 seconds]
vagrantc has joined #u-boot
sigmaris has quit [Ping timeout: 265 seconds]
mckoan is now known as mckoan|away
<sjg1>
Tartarus: ah OK, got it. I think understand it have have something working so will send a patch sometime today
<Tartarus>
thanks!
sszy has quit [Ping timeout: 268 seconds]
EdSwarthout has joined #u-boot
sigmaris has joined #u-boot
monstr has quit [Remote host closed the connection]
grgy has joined #u-boot
vagrantc has quit [Quit: leaving]
umbramalison has joined #u-boot
prabhakarlad has joined #u-boot
apritzel has quit [Ping timeout: 252 seconds]
alpernebbi has quit [Ping timeout: 260 seconds]
sigmaris has quit [Ping timeout: 268 seconds]
sigmaris has joined #u-boot
alpernebbi has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
WoC` has quit [Remote host closed the connection]
WoC` has joined #u-boot
<hays>
Are there any guides on how to make sense of dts files? They seem mostly magic
<hays>
I’ve got 2 dts files and both work mostly but are broken in different ways . Trying to see if I can patch one or the other
<milkylainen>
hays: Don't fret. Nobody understands them. They just pretend. ;) It's an art you see. Just start reading a bunch of them and then start pretending you too.
naoki has quit [Quit: naoki]
cottsay has quit [Quit: TTFN]
<hays>
Lol that’s what I was afraid of
cottsay has joined #u-boot
<Tartarus>
Broken in U-Boot, or broken in Linux?
<Tartarus>
But, uh, with my work hat on, we've had more than one customer say "please fix X/Y/Z in the dts file and then teach us how to do that", so don't feel bad about not getting it right away.
<milkylainen>
hays: j/k. You'll get it eventually. Most minor fixes aren't that hard to grasp. :)
<marex>
cambrian_invader: YAML schemas will save us all from writing crappy DTs
<cambrian_invader>
if they don't kill us first
vagrantc has joined #u-boot
<hays>
Marex that’s the board
<hays>
I’ve not seen the lte device. Maybe a SIM is needed for it to come up
<clever>
how does u-boot typically deal with patching DT's for runtime information, like the location of the framebuffer, the ram, and serial#'s?
<marex>
hays: could be optional
<marex>
clever: DT comes in, immutable, possibly another or relocated/duplicated DT is passed to next stage
<marex>
that's kinda the idea of DT -- you can parse it even with no memory
<marex>
if you need to change it, you may have to copy it somewhere, add space, change it, and so on
<marex>
hays: the LTE modem is usually just an USB device
<marex>
hays: well, so what did you change to make SPI NOR work in Linux in the espressobin ultra upstream DT ?
<clever>
marex: but where in the boot process are those changes typically done?
<hays>
Marex it works in the espressobin ultra dt. I copied the spi settings from that to the ccpe dts
<marex>
clever: what do you mean "where", like ... where during u-boot execution or where during the whole boot process (incl. before u-boot and linux and so on)
<clever>
within uboot
<marex>
hays: well, so what is in the diff ?
<clever>
marex: where would i modify uboot to make it apply the right patches before it runs linux
<hays>
One sec I’m on my phone
<marex>
clever: depends on which changes , some of them may be applied via fdt command (like user DT tweaks, DTOs), some might also be applied as part of fitImage, some might come from ft_board_setup and co. where DRAM layout is patched into DT
<cambrian_invader>
clever: image_setup_libfdt
<cambrian_invader>
which calls all the things that want to do fixups
<clever>
cambrian_invader: ah
<clever>
marex: i kinda dont want it in the boot script, because there is a lot of things and it may grow with time, and then the scripts in each distro get out of date
<marex>
clever: ideally whatever is user configurable should be in scripts
<marex>
stuff like DRAM layout patching is around ft_board_setup and similar hooks
<marex>
or what cambrian_invader said
<clever>
marex: but things like the framebuffer address/resolution, are coming from a previous stage, and arent configurable
<marex>
clever: you likely want to pass those through, yes
<cambrian_invader>
that's a pretty depressing authored/committed gap
<cambrian_invader>
sat on the mailing list for 7 months
<marex>
cambrian_invader: shall we open the "some maintainers are slow" support group again ?
<hays>
Marex the problem of WiFi not coming up?
<marex>
hays: the SPI NOR problem, has been fixed in next for months ... try linux-next on the board and see what happens, maybe your wifi would be fixed too
<hays>
That looks like SPI NOR which I think is a similar fix I applied
<cambrian_invader>
6.0 should include that commit fwiw
<cambrian_invader>
unless it somehow missed the merge window
<hays>
Yeah I’m on 6.0
<hays>
I backported that fix to the ccpe dts
<hays>
Which has working WiFi but I think is old in other ways
<marex>
you can check -- dtc -s -I dtb -O dts input.dts | less -> search for flash@ and see if those props are still present