<JPEW>
Does anyone do A/B updates with u-boot on SoCs that boot from a "boot" partitions? I was thinking I needed u-boot to switch the "active" flag on the partition table between an boot_a and boot_b partition, but this doesn't seem to be something u-boot can do so I'm wondering if there is a different method
<Sout_>
I do sort of. we do it with the fsbl and +memory register + eeprom to record the booted firmware.
<Sout_>
essentially fsbl reads eeprom. determines which slot to boot. set's a value in memory, then uboot reads the memory and determines which offset of the fit to boot.
<JPEW>
Sout_: Ah, so you just moved the decision to the FSBL then?
<JPEW>
Right. I want to actually A/B u-boot itself. One option is to make the FSBL choose between 2 u-boots, but this isn't always easy
<Sout_>
just different hand off address no?
<Sout_>
I think start link actually has two u-boot actually (randomly reading about that)
<JPEW>
Sout_: Fair. I was hoping to avoid modifying the FSBL if possible and having the two u-boots switch between themselves by setting the active flag on their boot parititons
<JPEW>
On a related note, would anyone be opposed if I added a command to modify just the partition boot flags in GPT? I was thinking something like `gpt set-bootable <interface> <num> <name list>`
<Tartarus>
JPEW: So, what SoC are you talking about, or are you talking about generically? If the latter, sjg1 has things to say/suggest :)
<JPEW>
Tartarus: Generically mostly. We don't really like to modify FSBLs/SPLs but it would be nice to A/B u-boot. We've seen some SoCs do this with a ping-pong method where a bootloader script can be used to modify the partition boot flags based on which one should be used
<JPEW>
I'm trying to prototype this on a raspberry pi
<Tartarus>
JPEW: Can I assume that this is for YP/OE autobuilder stuff? Or something else entirely?
<JPEW>
Tartarus: It's for my day job. We use YP, but the project proper won't care about this I suspect
<Tartarus>
OK
<Tartarus>
Well, the whole VBE thing can also do what you're wanting, I believe and sjg1 can chime in
* JPEW
looks up VBE
<Tartarus>
But there's probably some plumbing that should happen such that if your SoC has some native support for figuring out what to boot from, that also gets set properly and used
tepperson has joined #u-boot
<JPEW>
Hmm... ya. I think we're still a few years behind in boot technology... most of our SoCs just boot u-boot from a FAT partition, and we haven't gotten around to verified boot yet
<Tartarus>
There's verified parts to it too, but I'd swear you can also use it for update/fallback
<JPEW>
Ah, I see there is a VPL that can do that
<JPEW>
Ok, so it's basically the "do it before u-boot runs" approach :)
<sjg1>
JPEW: So far no A/B boot (just a 'simple' implementation), but there is a VPL where it could be added. I just haven't got to it. Also the fwupd part only supports 'simple'
sng has joined #u-boot
sng has quit [Ping timeout: 246 seconds]
<JPEW>
sjg1: Sure makes sense; I think the thing I'm missing (and apologies, I don't normally do stuff pre-u-boot) is how do you get a given SoC to _use_ something like that. For example, I'm prototyping on a raspberry pi, which seems to just load a bootloader from FAT
sng has joined #u-boot
<Tartarus>
Pi is a bad example here in that we don't even bother with SPL since we're just pretending to be the linux kernel, to the proprietary bootloader
sng has quit [Remote host closed the connection]
sng has joined #u-boot
<Tartarus>
Once you get over that tho, loading "image-a" and "image-b" as files vs locations on device should be abstracted away
ikarso has quit [Quit: Connection closed for inactivity]
<JPEW>
Tartarus: That is fair; I'm trying to sell A/B updates (including u-boot). Ya, just to do it in SPL/VBL is ideal for sure, but rpi isn't alone in not being flexible about how it can boot.... so I sort of need to prove it can work there as a "not best, but better than nothing" option
<JPEW>
.... so how would you A/B u-boot if all you can do is run u-boot :D
lucascastro has quit [Quit: Leaving]
<Tartarus>
Well, I mean Pi can do it, you just need to start by implementing SPL :)
<Tartarus>
There's a handful of other platforms too where since we pretend to be the linux kernel, for a previous stage bootloader, where it too would have that first hurdle
<Tartarus>
but everything else semi-modern tends to need SPL, unless it's got a relatively huge SRAM or similar
<Tartarus>
Even if they load from FAT first, like TI platforms
<Tartarus>
My point I guess is just that Pi's not a great prototype platform here not because it's FAT but because it's not using SPL today and so you'd need to add that in first just to prototype
<Tartarus>
vs random rockchip or whatever platform where that's already in there
<JPEW>
Right, TI is doable because you can make a hybrid MBR/GPT partition table and re-write the MBR part to control which partition it loads from, but the rest of the system uses GPT so it doesn't care
<JPEW>
I suppose their probably aren't systems that only load from FAT, don't have an SPL, and support GPT :)
<Tartarus>
I do not know if K3-based platforms are happy with hybrid, off-hand
<Tartarus>
I feel like omap2plus is not
<Tartarus>
Do you have a rockchip handy? That might be a good place to start, honestly
<Tartarus>
er
<Tartarus>
Can you share what the real SoC is? :)
<JPEW>
It's TI
<Tartarus>
32bit or 64bit
<Tartarus>
?
<JPEW>
32
<Tartarus>
OK
<JPEW>
Moreso, I'm trying to sell the "idea" of A/B updates, and there is concern that if we don't at least have the option of doing something that only requires u-boot on _any_ platform, it's not a good idea
<Tartarus>
Did you already confirm it's actually happy with hybrid? I maybe just tried only GPT or something
<JPEW>
Yes, we should totally do it in SPL.... but it's not a good show if I _can't_ get the rpi to work (TBH)
<JPEW>
Sorry, I know that's annoying
<Tartarus>
Yeah, humm
<Tartarus>
I'm not sure how unrealistic that is, I guess given *SPI options and larger SRAM
<JPEW>
Ya. The ping-pong method is adopted by another Soc we use, so there is a lot of attraction to that; It would make management happy, but I _really_ want to figure out a way to do it with upstream u-boot
<JPEW>
Which is basically just changing the bootable flags on partitions
<JPEW>
ATM anyway
<Tartarus>
Yeah, I mean if you have something that obeys bootable flag, upstreaming those changes is reasonable, and a path forward
<Tartarus>
I think sjg1 has explained now that what I was thinking is a goal not a feature right now
sng has quit [Remote host closed the connection]
<JPEW>
Ya, we'll for sure keep an eye on it
<Tartarus>
And then it's the usual "use A/B solution X from group Y or DIY it"
<JPEW>
Right.... if you can't upstream it, it doens't count in my book :)
<Tartarus>
I was asking about YP/OE autobuilder because I do think long term it would be good if (esp with the update/fallback part implemented) that was in upstream YP/OE and used
<Tartarus>
That'd make it a compelling feature for everyone
<JPEW>
Ya. YP is pretty careful not to endorse any specific update method ATM
<JPEW>
A lot of the 3rd party layers make it pretty easy though
sng has joined #u-boot
<JPEW>
Any suggestions on what a command to manipulate the bootable flags would look like (or the one proposed above is acceptable)?
<Tartarus>
hm
<Tartarus>
CONFIG'd under the gpt command, yeah
<JPEW>
Right
* JPEW
works on a patch
sng has quit [Read error: Connection reset by peer]
Kwiboo has joined #u-boot
vagrantc has joined #u-boot
prabhakarlad has joined #u-boot
tlwoerner has quit [Read error: Connection reset by peer]
tlwoerner has joined #u-boot
Guest4494 has joined #u-boot
sng has joined #u-boot
sng has quit [Remote host closed the connection]
sng has joined #u-boot
hanetzer has joined #u-boot
sng has quit [Ping timeout: 246 seconds]
mmu_man has quit [Ping timeout: 246 seconds]
<sjg1>
JPEW: Also see the 'cgpt' utility which has a lot of useful options. You could port some of that code to U-Boot perhaps
mmu_man has joined #u-boot
sng has joined #u-boot
<JPEW>
Heh, googling for cgpt mostly brings up "ChainGPT (CGPT) is an advanced AI model designed for the blockchain and cryptocurrency industry" ... I'm not sure I want to live on this planet anymore
<mps>
heh, maybe search for 'vboot-utils' will be better
goliath has quit [Quit: SIGSEGV]
prabhakarlad has quit [Quit: Client closed]
gsz has quit [Ping timeout: 245 seconds]
ikarso has joined #u-boot
sng_ has joined #u-boot
sng has quit [Read error: Connection reset by peer]