Re: Howto implement bootchooser <-> rauc interaction

[Roland Hieber <rhi@pengutronix.de>]

On Wed, Dec 15, 2021 at 11:56:21AM +0100, Ahmad Fatoum wrote:
> On 14.12.21 22:40, Konstantin Kletschke wrote:
> > On 2021-12-05 23:55, Roland Hieber wrote:
> > 
> >> You probably also want to delete your bootchooser variables from the env
> > 
> > Are you shure about that? I read some example/documentation at bootlin.com
> > doing/presenting a nice phytec device tree for EEPROM state but later on it points out to
> > "[...]add bootchooser variables associated to both targets in arch/arm/<board>/env/nv[...]"
> 
> I think Roland meant that you shouldn't rely on the _mutable_ environment
> for production. It's nice to test out stuff, but once you have figured
> out what you need, add it to the built-in environment (e.g.
> arch/arm/<board/myenv or CONFIG_DEFAULT_ENVIRONMENT_PATH).
> 
> Mutating the environment is mostly a development convenience.

No, I was confusing the "bootchooser" variables with "bootstate"
variables, which should come from state, not from nv. But generally what
Ahmad writes sounds reasonable to me :-) Sorry for the confusion!

 - Roland

>  
> > When I utilize "devinfo state" (with all global/nv bootchoser variables removed) I get
> > 
> > barebox@TI AM335x BeagleBone black:/ devinfo state
> > Parameters:
> >   bootstate.last_chosen: 0 (type: uint32)
> >   bootstate.system0.ok: 0 (type: uint32)
> >   bootstate.system0.priority: 21 (type: uint32)
> >   bootstate.system0.remaining_attempts: 3 (type: uint32)
> >   bootstate.system1.ok: 0 (type: uint32)
> >   bootstate.system1.priority: 20 (type: uint32)
> >   bootstate.system1.remaining_attempts: 3 (type: uint32)
> >   dirty: 0 (type: bool)
> >   init_from_defaults: 0 (type: bool)
> >   save_on_shutdown: 1 (type: bool)
> > 
> > 
> > Is bootchooser smart enough to gather system0 and system1 as bootable entries/possibilities?
> > For bootchooser.targets...
> > 
> > My system is not proven to work (I just sent a different mail with my other issues to this thread)
> > yet, may be there are other issues hidden, but I do not get this part.
> > 
> > I created two boot entries system0 and system1 in /env/boot/ with content mmc1.1 (for system0) and
> > mmc1.2 (for system1.2). Both are bootloader-spec-enabled partitions. What me bothers is, "boot mmc1.1" works,
> > "boot system0" not. How do I properly make a bootchoser entry for mmc1.1?
> > 
> > If no variables are required, where could be the cuplrit for this:
> > 
> > barebox@TI AM335x BeagleBone black:/ bootchooser
> > ERROR: bootchooser: Target list $global.bootchooser.targets is empty
> > No bootchooser found
> 
> Doing it in the environment is how it's meant to be used.
> Just do it at compile-time. Having devices in the field with differing
> mutated environments is a lot of headache. Differing barebox-state on the other
> hand is manageable, because you restrict what variables are available
> and how they interact with the rest of the system.
> 
> Cheers,
> Ahmad
> 
> > 
> > 
> > 
> > Kind Regards,
> > Konsti

-- 
Roland Hieber, Pengutronix e.K.          | r.hieber@pengutronix.de     |
Steuerwalder Str. 21                     | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686         | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox