Howto implement bootchooser <-> rauc interaction

[Ahmad Fatoum]

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.
 
> When I utilize "devinfo state" (with all global/nv bootchoser variables removed) I get
> 
> barebox at 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 at 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
> 
> _______________________________________________
> barebox mailing list
> barebox at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
> 


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