Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2025.01 is OUT / Merge Window is OPEN, next branch is CLOSED / Release v2025.04 is scheduled for 07 April 2025 / Channel archives at https://libera.irclog.whitequark.org/u-boot
joeskb7 has quit [Quit: leaving]
joeskb7 has joined #u-boot
vardhan__ has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
ALTracer has quit [Remote host closed the connection]
pgreco has joined #u-boot
qschulz has quit [Remote host closed the connection]
saulosilva has joined #u-boot
qschulz has joined #u-boot
zibolo_ has quit [Ping timeout: 265 seconds]
zibolo has joined #u-boot
vagrantc has quit [Quit: leaving]
saulosilva has quit [Quit: Client closed]
frytaped has joined #u-boot
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #u-boot
mmu_man has quit [Ping timeout: 252 seconds]
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #u-boot
frytaped has quit [Ping timeout: 244 seconds]
ALTracer has joined #u-boot
goliath has joined #u-boot
sjhill has quit [Ping timeout: 252 seconds]
sjhill has joined #u-boot
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 244 seconds]
crb has joined #u-boot
rvalue- is now known as rvalue
monstr has joined #u-boot
RoganDawes has joined #u-boot
<RoganDawes> marex: I appreciate your help. I do think I understand the difference between CST and uuu/mfgtool. I am trying to get a locked down system to boot a "known good" signed image taken from its own NAND flash, and provided to it via uuu/mfgtool over SDP/SDPS, because I can see that there is special cased code in the vendor's copy of u-boot that will
RoganDawes has quit [Quit: Client closed]
RoganDawes has joined #u-boot
<RoganDawes> one reason I can see for this failing is the apparent *recommendation* that the DCD be cleared. But on second/third/fourth reading, I think I understand that the download tool actualy does the clearing of the DCD field while downloading, thereby invalidating the signature. Hmmm, I guess this requires some investigation of the download tools code!
eballetbo has joined #u-boot
pgreco has quit [Ping timeout: 252 seconds]
ldevulder has joined #u-boot
mckoan|away is now known as mckoan
zsoltiv_ has joined #u-boot
RoganDawes has quit [Ping timeout: 240 seconds]
dsimic has quit [Ping timeout: 260 seconds]
dsimic has joined #u-boot
pgreco has joined #u-boot
naoki has quit [Ping timeout: 260 seconds]
sszy has joined #u-boot
naoki has joined #u-boot
naoki has quit [Ping timeout: 252 seconds]
naoki has joined #u-boot
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #u-boot
naoki has quit [Client Quit]
naoki has joined #u-boot
naoki has quit [Read error: Connection reset by peer]
naoki1 has joined #u-boot
naoki1 is now known as naoki
naoki1 has joined #u-boot
naoki has quit [Ping timeout: 265 seconds]
naoki1 is now known as naoki
<calebccff> sjg1: there's never going to be other users of smem, it's highly specific to Qualcomm platforms
<calebccff> sjg1: wdym livetree-only? the of_ api? I would certainly be in favour of aligning with the linux API more on this
mmu_man has joined #u-boot
kilobyte_ch has joined #u-boot
<kilobyte_ch> Hello, I'm trying to implement A/B Partitioning on a Raspberry Pi (rootfs + bootfs). This means, I want to also have A/B separation of the Kernel and the Devicetree overlays. Normally, the Raspberry Pi Firmware loads the Devicetree overlays. But switching between A and B should happen with U-Boot now. As I understand, there is just limited support in U-Boot for Devicetree overlays. Anyone any idea
<kilobyte_ch> how to solve this? Maybe I can compile the Overlays into a normal DTB so U-Boot is able to load it?
Perflosopher05 has joined #u-boot
Perflosopher0 has quit [Ping timeout: 252 seconds]
Perflosopher05 is now known as Perflosopher0
eballetbo has quit [Quit: Connection closed for inactivity]
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
<sigmaris> kilobyte_ch: In addition to the links above, if you use an extlinux.conf type of file to specify the kernel and initrd, it also has an 'fdtoverlays' keyword to specify overlays to apply
frytaped has joined #u-boot
ikarso has joined #u-boot
frytaped has quit [Quit: WeeChat 4.4.2]
frytaped has joined #u-boot
warpme has joined #u-boot
Peng_Fan has quit [Quit: Connection closed for inactivity]
<sjg1> calebccff: The remoteproc uclass is actually quite close. It even includes memory-allocation :-) I'm not suggesting that other vendors would call it 'SMEM', just that people tend to have similar challenges
<sjg1> calebccff: Yes, I mean using the Linux of API. We already have much of it, so it would be a case of calling ofnode_to_np() at the start of the driver, then using the normal Linux API from there
<sjg1> calebccff: This is all in service of trying to avoid so much modification of Linux code ported to U-Boot
naoki has quit [Quit: naoki]
mmu_man has quit [Ping timeout: 245 seconds]
hanetzer has quit [Ping timeout: 252 seconds]
hanetzer has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #u-boot
<calebccff> sjg1: not sure I'd agree with that, there's no remoteproc, just a database populated by prior boot stages with some goodies on top
<calebccff> for sure it makes sense to try and align more with the linux API, we more or less require livetree on Qualcomm anyways, but there is then this weird dependency issue becuase the livetree is created after relocation and we need SMEM to work before relocation
mmu_man has joined #u-boot
<sjg1> calebccff: If it is just a database, does it make sense to support allocating memory? Perhaps the existing method is just badly named
<sjg1> calebccff: Re livetree, yes, you could fix that :-)
<calebccff> database with bonus features
<calebccff> but im not too sure
ALTracer has quit [Read error: Connection reset by peer]
<calebccff> well the allocations is to add items
ALTracer has joined #u-boot
<sjg1> calebccff: Perhaps you should head towards reading what you need and put it in the DT with a proper binding?
<sjg1> calebccff: It looks like that is sort-of what you are doing, so perhaps Qualcomm could use DT?
<calebccff> sjg1: you're more or less asking me to shift mountains here, we can't do-away with smem, no even the Qualcomm chromebooks did away with smem and they replaced most of the boot chain
<sjg1> calebccff: Well yes, but we did cancel the program :-( I'm not referring to your current series...I'm just throwing out ideas in case Qualcomm is interested
<calebccff> a lot of what smem does doesn't really belong in DT anyways
<sjg1> calebccff: I expect that livetree before location is a moderate-sized hill
<sjg1> OK, is there a spec somewhere for it?
<calebccff> heh no it's just another magic proprietary puzzle piece tying qualcomms subsystems together
<sjg1> calebccff: Oh well, something they can perhaps look at in the future as they head more towards open source
<calebccff> Tartarus: do you have any idea how to handle supporting a new board in u-boot where the DT is in linux but hasn't been sync'd yet? would it be possible/sensible to cherry-pick relevant patches into the subtree? Or just wait around for the next DT sync?
<calebccff> Tartarus: ah apparently it is possible to cherry-pick a patch and not conflict with future syncs
totkeks has joined #u-boot
mckoan is now known as mckoan|away
yann-kaelig has joined #u-boot
tlwoerner has quit [Quit: Leaving]
saulosilva has joined #u-boot
tlwoerner has joined #u-boot
monstr has quit [Remote host closed the connection]
RoganDawes has joined #u-boot
guest22 has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
saulosilva has quit [Quit: Client closed]
gsz has joined #u-boot
mmu_man has quit [Ping timeout: 272 seconds]
guest22 has quit [Quit: Client closed]
mmu_man has joined #u-boot
alpernebbi has quit [Ping timeout: 265 seconds]
RoganDawes has quit [Quit: Client closed]
saulosilva has joined #u-boot
gsz has quit [Quit: leaving]
vardhan__ has quit [Ping timeout: 248 seconds]
joeskb7 has quit [Quit: Lost terminal]
joeskb7 has joined #u-boot
<Tartarus> marex: I'm trying to debug if CONFIG_MULTI_DTB_FIT_LZO=y works atm, and with rcar3_ulcb what file should I be mkimage -l'ing
<Tartarus> ?
<Tartarus> Looking at fit-dtb.blob those aren't compressed, sigh
saulosilva has quit [Quit: Client closed]
<Tartarus> Erm, oh, nevermind, it's not about the contents of the FIT being compressed
saulosilva has joined #u-boot
vagrantc has joined #u-boot
alpernebbi has joined #u-boot
totkeks has quit [Ping timeout: 248 seconds]
joeskb7 has quit [Quit: Lost terminal]
joeskb7 has joined #u-boot
pbsds30 has joined #u-boot
pbsds3 has quit [Ping timeout: 260 seconds]
pbsds30 is now known as pbsds3
joeskb7 has quit [Quit: Lost terminal]
joeskb7 has joined #u-boot
ALTracer has quit [Remote host closed the connection]
ALTracer has joined #u-boot
mmu_man has quit [Ping timeout: 272 seconds]
ALTracer has quit [Remote host closed the connection]
joeskb7 has quit [Quit: Lost terminal]
joeskb7 has joined #u-boot
ALTracer has joined #u-boot
ALTracer has quit [Remote host closed the connection]
joeskb7 has quit [Client Quit]
joeskb7 has joined #u-boot
ALTracer has joined #u-boot
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
<marex> Tartarus: indeed, it is the DTs that are compressed and then packed into a fitImage
joeskb7 has quit [Quit: Lost terminal]
joeskb7 has joined #u-boot
joeskb7 has quit [Client Quit]
joeskb7 has joined #u-boot
joeskb7 has quit [Client Quit]
joeskb7 has joined #u-boot
<Tartarus> Not quite what I thought, but OK, good. Lets see if TI can use that for am335x
joeskb7 has quit [Client Quit]
joeskb7 has joined #u-boot
goliath has quit [Quit: SIGSEGV]
prabhakalad has quit [Ping timeout: 248 seconds]
pbsds33 has joined #u-boot
pbsds3 has quit [Ping timeout: 276 seconds]
pbsds33 is now known as pbsds3
<calebccff> oh wouldn't it be more efficient to compress the FIT image itself?
<calebccff> since the DTBs probably have a lot of overlap
naoki has joined #u-boot
lehmanju has quit [Quit: The Lounge - https://thelounge.chat]
lehmanju has joined #u-boot
<marex> calebccff: that's assuming you have enough space to decompress everything ;-)
goliath has joined #u-boot
<Slimey> anyone here open to modifying a copy of u-boot to remove vendor crap ? :D
* shadow :D
* Slimey runs shadow- thu hashcat
<shadow> that has been a motivator for me and the JH7110 CPU target(s)
<Slimey> oh hugs
<Slimey> im messing with p1010 and t1023/4 target boards hehE
<calebccff> marex: yeah i ran into that hiccup before, also that malloc isn't available available during fdtdec_setup()
saulosilva has quit [Quit: Client closed]
ALTracer has quit [Ping timeout: 245 seconds]
ALTracer has joined #u-boot
___nick___ has joined #u-boot
umbramalison has joined #u-boot
umbramalison_alt has quit [Ping timeout: 265 seconds]
___nick___ has quit [Client Quit]
___nick___ has joined #u-boot
ALTracer has quit [Remote host closed the connection]
ALTracer has joined #u-boot
___nick___ has quit [Ping timeout: 244 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
pbsds3 has quit [Quit: The Lounge - https://thelounge.chat]
goliath has quit [Quit: SIGSEGV]
pbsds3 has joined #u-boot
goliath has joined #u-boot
mmu_man has joined #u-boot
ldevulder has quit [Quit: Leaving]
yann-kaelig has quit []
saulosilva has joined #u-boot
yann-kaelig has joined #u-boot
yann-kaelig has quit []
saulosilva has quit [Quit: Client closed]
<marex> Tartarus: uh ... dsb sy ... is stronger than dmb, right ?
<marex> I'm looking at netdev driver and it does dmb and then cache invalidation, but the later already does dsb sy, so the dmb should be redundant
frytaped has quit [Ping timeout: 276 seconds]
saulosilva has joined #u-boot
saulosilva has quit [Quit: Client closed]
goliath has quit [Quit: SIGSEGV]