<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)
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?
<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>
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]