Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2025.01, v2025.04-rc3 are OUT / Merge Window is CLOSED, next branch is OPEN / Release v2025.04 is scheduled for 07 April 2025 / Channel archives at https://libera.irclog.whitequark.org/u-boot
mmu_man has quit [Ping timeout: 245 seconds]
mmu_man has joined #u-boot
enok has quit [Remote host closed the connection]
bradfa has quit [Read error: Connection reset by peer]
bradfa has joined #u-boot
manchaw has quit [Read error: Connection reset by peer]
umbramalison has quit [Ping timeout: 260 seconds]
manchaw has joined #u-boot
Perflosopher03 has quit [Quit: The Lounge - https://thelounge.chat]
Perflosopher03 has joined #u-boot
enok has joined #u-boot
Perflosopher03 has quit [Quit: The Lounge - https://thelounge.chat]
enok has quit [Ping timeout: 245 seconds]
enok has joined #u-boot
umbramalison has joined #u-boot
mrnuke has quit [Ping timeout: 244 seconds]
mrnuke has joined #u-boot
naoki has joined #u-boot
vardhan has joined #u-boot
Jones42 has quit [Ping timeout: 252 seconds]
Jones42 has joined #u-boot
Daanct12 has joined #u-boot
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #u-boot
persmule has joined #u-boot
sukrutb has quit [Ping timeout: 252 seconds]
Perflosopher03 has joined #u-boot
sukrutb has joined #u-boot
mmu_man has quit [Ping timeout: 265 seconds]
dsimic has quit [Ping timeout: 260 seconds]
dsimic has joined #u-boot
enok has quit [Ping timeout: 245 seconds]
enok has joined #u-boot
enok has quit [Remote host closed the connection]
vardhan has quit [Ping timeout: 252 seconds]
Daanct12 has quit [Quit: WeeChat 4.5.2]
clamor has joined #u-boot
Daanct12 has joined #u-boot
goliath has joined #u-boot
rber|res has joined #u-boot
alexeymin has quit [Ping timeout: 252 seconds]
monstr has joined #u-boot
alexeymin has joined #u-boot
retr0id0 has joined #u-boot
retr0id has quit [Ping timeout: 244 seconds]
retr0id0 is now known as retr0id
monstr has quit [Ping timeout: 252 seconds]
mckoan|away is now known as mckoan
gsz has joined #u-boot
frieder has joined #u-boot
gsz has quit [Ping timeout: 246 seconds]
flyback has quit [Ping timeout: 260 seconds]
flyback has joined #u-boot
sszy has joined #u-boot
Jones42 has quit [Ping timeout: 244 seconds]
Jones42 has joined #u-boot
mmu_man has joined #u-boot
mripard has joined #u-boot
vardhan has joined #u-boot
mmu_man has quit [Ping timeout: 246 seconds]
<pivi> Hello all, with the current OF upstream support (coming from Linux), what would be the best way to add a new board that is not supported yet in the linux kernel?
<pivi> Initially add with a DT copy, and once the DT is merged in Linux, update it to use that one ?
vardhan has quit [Ping timeout: 248 seconds]
vardhan has joined #u-boot
clamor has quit [Ping timeout: 268 seconds]
clamor has joined #u-boot
vardhan has quit [Ping timeout: 252 seconds]
vardhan has joined #u-boot
drmpeg has left #u-boot [#u-boot]
mmu_man has joined #u-boot
drmpeg has joined #u-boot
<calebccff> pivi: if patches are sent to Linux already, you can apply them (im sure there's a way to cherry-pick into a subdir or something?) and send them to u-boot, just note where they came from
<calebccff> pivi: then when they eventually trickle down they'll be replaced with the upstream version
<calebccff> (that is, apply them to dts/upstream/... in u-boot)
vardhan has quit [Ping timeout: 260 seconds]
enok has joined #u-boot
alexxy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
ikarso has quit [Quit: Connection closed for inactivity]
ikarso has joined #u-boot
clamor has quit [Read error: Connection reset by peer]
clamor has joined #u-boot
warpme has joined #u-boot
warpme has quit [Ping timeout: 245 seconds]
<qschulz> pivi: do not apply manually! use tools/update-subtree.sh pick for that
<qschulz> pivi: the commit needs to be merged into devicetree-rebasing git repo, and that happens shortly after -rcX from the kernel
naoki has quit [Quit: naoki]
<qschulz> marex: I think I may have found out why I started to receive so many mails I had absolutely no interest in from U-Boot... Received some patches from calebccff like 10min ago, and it seems like there is one (1) commit touching this file where I have a Reviewed-by
<calebccff> qschulz: uhh sorry, i actually added your cc manually since i hoped you'd maybe be able to test or have some insight. scsi doesn't see much activity XD
<calebccff> i do believe many people misuse get_maintainer.pl though, thankfully the b4 configuration doesn't pull contributors in, but i notice that patches from sjg1 often CC me just because I contributed to a file
<sjg1> I use patman and stopped using the -m option since Tom said I was missing people. So I effectively cc all people mentioned by get_maintainer.pl now, for every series version
<qschulz> calebccff: ah, then it's a different issue than with marex's patches where I'm often in Cc and he doesn't add me manually IIRC
<qschulz> calebccff: no worries, you couldn't have known :)
<qschulz> the scsi Reviewed-by was a drive-by review, don't know much about it :/
enok has quit [Ping timeout: 246 seconds]
<calebccff> sjg1: what about using --git-min-signatures 3 or something? then at least you would only CC people who have contributed at least 3 patches to the file
<pivi> qschulz: my question is different. what to do before the DT is merged into mainline.
<pivi> qschulz: option 1, do it in 2 steps. first copy the DT, second convert to use OF_UPSTREAM
<qschulz> pivi: you have two choices: 1) wait for it to be merged, 2) don't use OF_UPSTREAM
<pivi> qschulz: is there any option 2? or option 1 is the only way
<pivi> ok
<pivi> that's ok
<pivi> so we start without OF_UPSTREAM, and after that we move to it
<pivi> easy, thanks :-)
<qschulz> pivi: we typically don't like new additions without OF_UPSTREAM (at least Rockchip-based boards)
<qschulz> we've had new Nvidia-based boards that don't use OF_UPSTREAM, so it's not a blocker per-se
<qschulz> well, it depends on the maintainer of course :)
<qschulz> pivi: are there patches on the Linux ML already?
<qschulz> this makes it a bit more acceptable IMO
<qschulz> pivi: also, I am not a maintainer, so take this with a grain of salt :)
enok has joined #u-boot
<marex> if the DT patches are already in next, I would say cherry-pick them
<marex> into dts/upstream/ that is
enok has quit [Client Quit]
enok has joined #u-boot
<marex> if this is entirely new DT, hum ...
<marex> my take on it is, if it is posted to the ML and reasonably likely to be applied, add it to dts/upstream/ , otherwise arch/*/dts without OF_UPSTREAM for starters
<clamor> marex: based
<qschulz> marex: you can only cherry-pick patches if they are in devicetree-rebasing
<qschulz> please, please do not apply patches to dts/upstream if not using the tools
<sjg1> calebccff: Patman doesn't have a way to set get_maintainers.pl params. What does b4 do?
<qschulz> sjg1: https://b4.docs.kernel.org/en/latest/config.html b4.send-auto-to-cmd and b4.send-auto-cc-cmd sections
<clamor> Imho, absence of linux support should not be a blocker to upstreaming in u-boot
Peng_Fan has joined #u-boot
<clamor> Btw, does anyone know how to hang actions into keyboard keys, just like calebccff did with buttons?
<sjg1> clamor: I agree. Normally the bootloader is working long before the OS
<clamor> sjg1: exactly, I have got some devices into upstream linux recently, while uboot supported them for like 3 yeard
<clamor> *years
<sjg1> qschulz: OK, I suppose I could add those arguments to patman too
<calebccff> clamor: there's an autoboot key thing but that's probably not what you want. tbh i regret using buttons, i should have done it with keycodes instead (the values before REMAP_PHONE_KEYS even), since uhh it turns out boards don't all name the volume down button "Volume Down", some use a lowercase d in down
<calebccff> clamor: ack, i should clarify, button_cmd should use the keycode rather than the button label
<clamor> calebccff: I use per board env so your patch is perfectly suitable for me, but using keycodes might be a good idea
<calebccff> doing it at the UCLASS_KEYBOARD level would be harder since it doesn't keep track of what keys are pressed (i don't think?)
<calebccff> hooking input_getc() would be an option
<calebccff> only downside to keycodes is we'd have to use numbers directly in the .env file (or pre-process them lol)
<clamor> Well, the existing button system is already extremely helpful
<calebccff> glad you're making use of it :D
<clamor> Extensively
<calebccff> oh? I'd love to know more
<clamor> I use button actions you added on all devices I support which iirc is more then 20
<calebccff> oh damn i didn't realise just how many boards are using them, that's awesome
<clamor> Yep
<pivi> clamor: I agree with you.
* calebccff never grep'd button_cmd recently
<calebccff> for the lid switch too is neat
<clamor> Yep
<clamor> I use it for lid too
<clamor> Super useful on convertible tablets
<calebccff> i think an API for mapping keycodes to specific actions whenever they occur rather than just polling once would be good
<calebccff> then the lid switch could always trigger poweroff
<clamor> Not good
<calebccff> hmm
<pivi> qschulz: we are going to send patches to both U-Boot/Linux, planning to start with Linux and shortly afterward U-Boot. But it always takes some time, no matter what.
* calebccff probably shouldn't ruin a good thing
rvalue has quit [Read error: Connection reset by peer]
<marex> calebccff: have you considered adding eBPF support for handling keys into U-Boot ?
<clamor> Lid is nice if the device is accidentally turned on with a closed lid, but not when you are actively trying to boot
rvalue has joined #u-boot
<clamor> Currently buttons remap after action stage
<clamor> So they can be used for navigation for example
<calebccff> pivi: since you're undoubtebly going to have some review rounds on the kernel lists which are stricter than U-Boot, I'd propose posting everything you can for u-boot without sending the DTS (or send it only as a reference and in a separate patch series) if that's ok with the relevant platform maintainer
<calebccff> pivi: then add the DTS to arch/... in U-Boot and pinky promise to send a follow up switching to OF_UPSTREAM later
<calebccff> that's how I'd like it done for Qualcomm anyways
<calebccff> marex: lol, maybe lua? :D
<qschulz> ideally with a link to the patch series on the linux kernel mailing list :)
<calebccff> ^^
<clamor> It depends on maintainer
<clamor> Sometimes the stripped device tree is even better then upstream
<marex> stripped DT can be done automatically using u-boot.dtsi and bootph tags
<marex> DT is hardware description, like a schematic, it should be complete at least on the input side
<marex> its not like you can scissor out a piece of your board (at least it is not recommended)
<marex> calebccff: hmmm, last time I looked at lua was some 3.5 to 3.6 update and it fell apart horribly due to incompatible language changes
<marex> calebccff: I am not sure I would opt for that one anymore
<marex> (I might have the two version wrong, one was in OE dunfell, the other in I think kirkstone)
<clamor> marex: true, but that will involve same or more efforts to maintain than a local stripped device tree.
<calebccff> marex: oh yeahhh, i wonder what the Tangara project are doing, they use lua for their entire UI framework
Daanct12 has quit [Quit: WeeChat 4.5.2]
joeskb7 has joined #u-boot
Jones42 has quit [Ping timeout: 246 seconds]
Jones42 has joined #u-boot
clamor has quit [Ping timeout: 244 seconds]
clamor has joined #u-boot
goliath has quit [Quit: SIGSEGV]
K900 has joined #u-boot
<K900> Hey folks, I've got an Orange Pi 5 Max here and an u-boot patched to run on it, and I'd like to get this upstreamed, but it needs dts/upstream to be updated to 6.14 and I think that needs someone with actual push access
<K900> Can someone help with that?
<K900> It's tiny if you ignore the upstream DTs
gsz has joined #u-boot
gsz has quit [Ping timeout: 260 seconds]
LainExperiments has joined #u-boot
clamor has quit [Ping timeout: 245 seconds]
clamor has joined #u-boot
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
goliath has joined #u-boot
LainExperiments has quit [Ping timeout: 240 seconds]
mckoan is now known as mckoan|away
mmu_man has quit [Ping timeout: 246 seconds]
warpme has joined #u-boot
mmu_man has joined #u-boot
warpme has quit [Ping timeout: 245 seconds]
enok has quit [Ping timeout: 265 seconds]
frieder has quit [Remote host closed the connection]
rockosov has quit [Ping timeout: 260 seconds]
vagrantc has joined #u-boot
goliath has quit [Quit: SIGSEGV]
<marex> K900: wait for Tartarus to sync the DTs
<K900> Is that, like, a scheduled thing?
<K900> Because just looking at the commits there, there was no 6.13 import either?
<Tartarus> We're on 6.13
<Tartarus> And you can use the cherry-pick script
<marex> K900: are you on u-boot/next ?
<K900> Oh no sorry I was looking at the wrong thing
<K900> Tartarus: It's a bunch of commits, it'll probably be easier to pull 6.14
<K900> If that's something that's planne
<K900> * planned
<Tartarus> K900: Yes, it's planned
<Tartarus> I see v6.14 was this weekend
<K900> Yeah
<Tartarus> and I dunno if devicetree-rebasing is there yet
<K900> It is
<Tartarus> But it's for -next and not -master
<K900> I did just check
<Tartarus> OK
<Tartarus> Then yeah, wait please, it'll get done soon'ish
<K900> All right, thanks
<K900> If you could ping me when you do that, it would be great
<K900> If not, I'll probably just check again on the weekend when I have time
clamor has quit [Ping timeout: 248 seconds]
clamor has joined #u-boot
<sjg1> calebccff: We can't reasonably require SCSI to be inited in board init
<calebccff> sjg1: why not?
<sjg1> Well it is possible to do another 'scsi scan'
<calebccff> it just has to be done before capsule updates start
<calebccff> i mean, the only current user of dfu_scsi is qualcomm, and we have to call scsci_scan() in order to find the partition with u-boot on it to build the dfu string
<calebccff> so removing the call from dfu_scsi is a nop still i think, if someone has a different usecase they can handle it themselves i'd figure?
<calebccff> i so wonder though why we cant init scsi the same way we do for mmc
<calebccff> s/so/do
enok has joined #u-boot
rockosov has joined #u-boot
<sjg1> We shouldn't actually init devices on startup. The MMC init should really go away
<sjg1> calebccff: It's a hangover from the pre-DM days
clamor has quit [Ping timeout: 265 seconds]
clamor has joined #u-boot
mmu_man has quit [Ping timeout: 272 seconds]
mmu_man has joined #u-boot
mrnuke has quit [Ping timeout: 244 seconds]
mrnuke has joined #u-boot
clamor has quit [Read error: Connection reset by peer]
prabhakalad has quit [Ping timeout: 248 seconds]
prabhakalad has joined #u-boot
gsz has joined #u-boot
enok has quit [Ping timeout: 245 seconds]
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #u-boot
gsz has quit [Ping timeout: 245 seconds]
helene has quit [Remote host closed the connection]
helene has joined #u-boot
helene has quit [Remote host closed the connection]
helene has joined #u-boot