Howto implement bootchooser <-> rauc interaction

Howto implement bootchooser <-> rauc interaction

[Konstantin Kletschke]

Hi All,

finally I managed to integrate rauc and barebox-state into my yocto 
build. I am not sure
completely yet if this is done properly, though. I want to make this
bootchoser-alternate-rootfs-switchover-thingy working properly with 
bootchooser detecting
reset cause and additionally rauc/barebox-state marking successful 
boots.

The documentation looks very good and comprehensive overall but may be 
its me not getting
the part how and where the shared data is properly stored.

Please let me briefly explain what I already have (targets mmc1.1 and 
mmc1.2 are bootloader
spec entries):

bootchoser variables defined in barebox (preliminary in nv namespace, 
does it need to go
elsewhere?):

barebox@TI AM335x BeagleBone black:/ nv
   allow_color: true
   autoboot_timeout: 3
   boot.default: bootchooser insidem2m
   bootchooser.last_chosen: 2
   bootchooser.retry: 1
   bootchooser.system1.boot: mmc1.1
   bootchooser.system1.default_attempts: 3
   bootchooser.system1.default_priority: 21
   bootchooser.system1.priority: 21
   bootchooser.system1.remaining_attempts: 0
   bootchooser.system2.boot: mmc1.2
   bootchooser.system2.default_attempts: 3
   bootchooser.system2.default_priority: 20
   bootchooser.system2.priority: 20
   bootchooser.system2.remaining_attempts: 1
   bootchooser.targets: system1 system2
   user: none

barebox@TI AM335x BeagleBone black:/ bootchooser -i
Good targets (first will be booted next):
system2
     id: 2
     priority: 20
     default_priority: 20
     remaining attempts: 1
     default attempts: 3
     boot: 'mmc1.2'

Disabled targets:
system1
     id: 1
     priority: 21
     default_priority: 21
     remaining attempts: 0
     default attempts: 3
     boot: 'mmc1.1'
     disabled due to remaining attempts = 0

last booted target: system2

When linux is booted rauc complains:

(rauc:396): rauc-WARNING **: 08:32:31.311: Failed getting primary slot: 
Failed getting primary slot: No content to read

EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: 
(null)
rauc-Message: 08:32:31.729: rauc status: 
GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code30: 
Failed marking 'rootfs.1' as good: Failed to run barebox-state: Child 
process exited with code 1

# rauc status

(rauc:583): rauc-WARNING **: 08:33:46.622: Failed getting primary slot: 
Failed getting primary slot: No content to read

=== System Info ===
Compatible:  insidem2m-s
Variant:
Booted from: rootfs.1 (system2)

=== Bootloader ===
Activated: (null) ((null))

=== Slot States ===
o [rootfs.1] (/dev/mmcblk0p3, ext4, booted)
	bootname: system2
	mounted: /
	boot status: bad

o [rootfs.0] (/dev/mmcblk0p2, ext4, inactive)
	bootname: system1
	boot status: bad



# barebox-state -d
Neither /aliases/state nor /state found


# cat /proc/cmdline
bootchooser.active=system2 console=ttyO0,115200n8 root=/dev/mmcblk0p3 
rootfstype=ext4 rootwait


This is /etc/rauc/system.conf:

# cat /etc/rauc/system.conf
[system]
compatible=insidem2m-s
bootloader=barebox

[keyring]
path=ca.cert.pem

[slot.rootfs.0]
device=/dev/mmcblk0p2
type=ext4
bootname=system1

[slot.rootfs.1]
device=/dev/mmcblk0p3
type=ext4
bootname=system2





Actually I fully understand that rauc/barebox-state has no info where to 
store its marking to
be read later for barebox. Even /boot/ is not mounted with the barebox 
environment in it
(/dev/mmcblk0p1 vfat carries bootloader images and barebox.env). Is it 
possible to utilize
that for interaction?

Is it a must to utilize the barebox-state framework for this? I read 
very much about this but
everytime it is referenced as a device tree extension which is provided 
as an example in arch/arm/dts/state-example.dtsi. Every doc or walk 
through refers to a device tree.
But - sorry - does this go into the barebox device tree? Or into the 
kernel device tree?
Or both?

Both parts needs to be informed but how does userspace 
rauc/barebox-state access stuff
provided by device tree?
I could easily utilize the I2C EEPROM on my Beaglebone Black for this 
but how should this
look like for barebox and kernel?


Kind Regards
Konstantin










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

Re: Howto implement bootchooser <-> rauc interaction

[Trent Piepho]

On Fri, Dec 3, 2021 at 4:42 AM Konstantin Kletschke
<konstantin.kletschke@inside-m2m.de> wrote:
> The documentation looks very good and comprehensive overall but may be
> its me not getting
> the part how and where the shared data is properly stored.

You should add a node of "barebox,state" to the *Barebox* device tree.
Barebox needs to read state when it boots to determine the partition
to use and set boot attempts.  You also need in aliases { state =
&your_state_node: }: so it knows which state node it should use.

If you want to use state from Linux too, and of course you do so that
you can run rauc commands and update boot success in Linux, then you
must have state node ALSO in the Linux device tree.  But you do not
need to add it manually!  Barebox will automatically inject the state
node into the Linux device tree when it boots the kernel.

For this to work, you need to have Barebox give the kernel the Linux
device tree when booting.  This is the normal way to boot now.  All
current docs tell you to do this.  There was a much older style where
the dtb was appended to the kernel image and the kernel found it
itself without involving the bootloader.  I assume this will not work,
but I think Barebox state did not exist when I last booted a system
this way, so I haven't tried.

>
> When linux is booted rauc complains:
>
> (rauc:396): rauc-WARNING **: 08:32:31.311: Failed getting primary slot:
> Failed getting primary slot: No content to read

Sounds like barebox-state command did not work.

>
> # barebox-state -d
> Neither /aliases/state nor /state found

Yes, not working.  Barebox should put the state node into Linux device
tree.  It should appear under /sys/firmware/devicetree/base.  In
aliases node and also state node.

> I could easily utilize the I2C EEPROM on my Beaglebone Black for this
> but how should this
> look like for barebox and kernel?

Yes you can use your EEPROM to store state and use rauc.  One could
write code that uses one byte to indicate partition to boot and one
byte for attempts left.  Then you write some board code in Barebox to
read these bytes and set variables bootchooser will use.  There is a
script you write that rauc will run in Linux, it should read EEPROM
and return what it means to rauc.  I have done this to use a few bytes
of NVRAM in RTC chip for boot state information.

I think also one could use Barebox state to store data into an EEPROM.
Normally state is stored into a file, partition in eMMC/SD, or NAND
flash.  But I think EEPROM or a partition in an EEPROM would work too.
Haven't tried it myself though.

If you write custom code to store your information, you can easily
pack everything bootchooser and rauc *need* into just one byte.

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

Re: Howto implement bootchooser <-> rauc interaction

[Roland Hieber]

On Fri, Dec 03, 2021 at 09:52:00AM -0800, Trent Piepho wrote:
> On Fri, Dec 3, 2021 at 4:42 AM Konstantin Kletschke
> <konstantin.kletschke@inside-m2m.de> wrote:
> > The documentation looks very good and comprehensive overall but may be
> > its me not getting
> > the part how and where the shared data is properly stored.
> 
> You should add a node of "barebox,state" to the *Barebox* device tree.
> Barebox needs to read state when it boots to determine the partition
> to use and set boot attempts.  You also need in aliases { state =
> &your_state_node: }: so it knows which state node it should use.

FYI, there are a few more pointers in the docs too:
<https://www.barebox.org/doc/latest/user/state.html>

In short:  barebox state is meant to be read (and written) from the
Linux world too, in contrast to the barebox env, which is only meant to
be used by barebox itself.

You probably also want to delete your bootchooser variables from the env
so they don't cause confusion :-) You can inspect the state variables
with 'devinfo state', and set them via 'state.variablename=value'. They
should also show up in 'global'.

 - Roland

-- 
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

Re: Howto implement bootchooser <-> rauc interaction

[Konstantin Kletschke]

On 2021-12-05 23:55, Roland Hieber wrote:

> In short:  barebox state is meant to be read (and written) from the
> Linux world too, in contrast to the barebox env, which is only meant to
> be used by barebox itself.

Thanks for the clear statement, I wont mess with environment for that 
anymore :)

> You probably also want to delete your bootchooser variables from the 
> env
> so they don't cause confusion :-) You can inspect the state variables
> with 'devinfo state', and set them via 'state.variablename=value'. They
> should also show up in 'global'.

I will clear this up, I will check to move this into the state.* 
namespace.

Regards
Konsti

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

Re: Howto implement bootchooser <-> rauc interaction

[Konstantin Kletschke]

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[...]"

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



Kind Regards,
Konsti

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

Re: 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@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
> 
> _______________________________________________
> barebox mailing list
> barebox@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 |

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

Re: Howto implement bootchooser <-> rauc interaction

[Konstantin Kletschke]

On 2021-12-15 11:56, Ahmad Fatoum wrote:

> 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).

Okay, then I got it - the intention of Roland. Compiled default 
environment
is no problem.

But regarding required bootchooser variables: what of those are 
required?
I said I utilised
https://bootlin.com/blog/another-system-update-adventure-with-rauc-barebox-yocto-project/
there is the barebox-state DT tree setup explained (a bit) and then it 
points out
[...]Now we have to add bootchooser variables associated to both targets 
in arch/arm/<board>/env/nv[...]
Which is rather abstract on how to do this, especially, if I have

bootstate.system0.remaining_attempts

in the DT, why should I replicate this in arch/arm/<board>/env/nv?

Or is there a connection needed to be created? Which variables need to 
be specified?
Isn't it already there?

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

> > barebox@TI AM335x BeagleBone black:/ bootchooser
> > ERROR: bootchooser: Target list $global.bootchooser.targets is empty
> > No bootchooser found

May be this is my problem:

> hand is manageable, because you restrict what variables are available
> and how they interact with the rest of the system.

?


What I mixed into my not so elaborated mail is a SIDE QUEST:

I can boot a bootloader spec equipped partitio like this:

barebox@TI AM335x BeagleBone black:/ boot mmc1.2


How do I make a boot entry "system0" a boot.default variable can point 
to and also a member
of bootchooser.targets?

I tried mmc1.2 or "boot mmc1.2" as system0 content but that did not 
work...




Kind Regards
Konsti


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

Re: Howto implement bootchooser <-> rauc interaction

[Ahmad Fatoum]

On 16.12.21 20:35, Konstantin Kletschke wrote:
> On 2021-12-15 11:56, Ahmad Fatoum wrote:
> 
>> 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).
> 
> Okay, then I got it - the intention of Roland. Compiled default environment
> is no problem.
> 
> But regarding required bootchooser variables: what of those are required?
> I said I utilised
> https://bootlin.com/blog/another-system-update-adventure-with-rauc-barebox-yocto-project/
> there is the barebox-state DT tree setup explained (a bit) and then it points out
> [...]Now we have to add bootchooser variables associated to both targets in arch/arm/<board>/env/nv[...]
> Which is rather abstract on how to do this, especially, if I have
> 
> bootstate.system0.remaining_attempts
> 
> in the DT, why should I replicate this in arch/arm/<board>/env/nv?

bootchooser variables are those that start with bootchooser.*. You named
your state bootstate in the device tree, thus the state driver creates
bootstate.* variables, which can be used to read/write the values.

You need to tell bootchooser which state to take via bootchooser.state_prefix,
but that's it. No need to mess direclty with the state variables.


> Or is there a connection needed to be created? Which variables need to be specified?
> Isn't it already there?
> 
>> > 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)

See https://elinux.org/images/9/9d/Barebox-bells-n-whistles.pdf Slide 26 for an example
/env/nv for a redundant boot setup.

> 
>> > Is bootchooser smart enough to gather system0 and system1 as bootable entries/possibilities?

You need to tell it what system0 and system1 are. See example linked above.

> 
>> > barebox@TI AM335x BeagleBone black:/ bootchooser
>> > ERROR: bootchooser: Target list $global.bootchooser.targets is empty
>> > No bootchooser found
> 
> May be this is my problem:

Ye. You need to tell bootchooser what boot targets there are.

>> hand is manageable, because you restrict what variables are available
>> and how they interact with the rest of the system.
> 
> ?
> 
> 
> What I mixed into my not so elaborated mail is a SIDE QUEST:
> 
> I can boot a bootloader spec equipped partitio like this:
> 
> barebox@TI AM335x BeagleBone black:/ boot mmc1.2
> 
> 
> How do I make a boot entry "system0" a boot.default variable can point to and also a member
> of bootchooser.targets?
> 
> I tried mmc1.2 or "boot mmc1.2" as system0 content but that did not work...

It's a two step thing. First you define your targets, e.g. system0 and system1
Then bootchooser knows the name of the state variables to consult and then
basically does boot ${global.bootchooser.system0.boot}.

Cheers,
Ahmad

> 
> 
> 
> 
> Kind Regards
> Konsti
> 
> 


-- 
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 |

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

Re: Howto implement bootchooser <-> rauc interaction

[Konstantin Kletschke]

On Fri, Dec 17, 2021 at 11:00:28AM +0100, Ahmad Fatoum wrote:

> You need to tell bootchooser which state to take via bootchooser.state_prefix,
> but that's it. No need to mess direclty with the state variables.

Okay, this sounds reasonable.

> See https://elinux.org/images/9/9d/Barebox-bells-n-whistles.pdf Slide 26 for an example
> /env/nv for a redundant boot setup.

Thank you, I will investigate.

> It's a two step thing. First you define your targets, e.g. system0 and system1
> Then bootchooser knows the name of the state variables to consult and then
> basically does boot ${global.bootchooser.system0.boot}.

Okay, I need to figure this out.

Thanks again for your patience, I will test out all your hints and
examples and instructios, thank you!

Kind Regards
Konstantin


-- 

INSIDE M2M GmbH
Konstantin Kletschke
Berenbosteler Straße 76 B
30823 Garbsen

Telefon: +49 (0) 5137 90950136
Mobil: +49 (0) 151 15256238
Fax: +49 (0) 5137 9095010

konstantin.kletschke@inside-m2m.de
http://www.inside-m2m.de

Geschäftsführung: Michael Emmert, Ingo Haase, Dr. Fred Könemann, Derek Uhlig
HRB: 111204, AG Hannover


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

Re: Howto implement bootchooser <-> rauc interaction

[Roland Hieber]

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

Re: Howto implement bootchooser <-> rauc interaction

[Konstantin Kletschke]

Dear Trent,

thank you so much for this comprehensive clarification.

On 2021-12-03 18:52, Trent Piepho wrote:

> You should add a node of "barebox,state" to the *Barebox* device tree.

I will try to prepare a proper device tree.
It was this special tiny detail:

> must have state node ALSO in the Linux device tree.  But you do not
> need to add it manually!  Barebox will automatically inject the state

What I was not aware of, yet! I think I got the point now.

> For this to work, you need to have Barebox give the kernel the Linux
> device tree when booting.  This is the normal way to boot now.  All
> current docs tell you to do this.  There was a much older style where
> the dtb was appended to the kernel image and the kernel found it
> itself without involving the bootloader.  I assume this will not work,
> but I think Barebox state did not exist when I last booted a system
> this way, so I haven't tried.

Yes, no problem, I stumpled upon the combined image+dtb thingy once in 
our
but the new stuff I am working upon is barebox passing the dtb to the 
kernel.

Thanks also for explaining the possibilities and requirements,
I will figure a nice way to do this on my Beaglebone Black now.

Kind Regards
Konstantin

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

Re: Howto implement bootchooser <-> rauc interaction

[Konstantin Kletschke]

Dear Trent, dear mailing list people,

I managed to - somehow - utilize an onboard EEPROM for this.

On 2021-12-03 18:52, Trent Piepho wrote:

> Yes you can use your EEPROM to store state and use rauc.  One could

This is barebox devicetree I come up with:

/ {
	aliases {
		state = &state_eeprom;
	};

	state_eeprom: state_eeprom {
		#address-cells = <1>;
		#size-cells = <1>;
		compatible = "barebox,state";
		magic = <0xcafebabe>;
		backend-type = "raw";
		backend = <&backend_state_eeprom>;
		backend-storage-type = "direct";
		backend-stridesize = <54>;
		/* keep-previous-content; */

		bootstate {
			#address-cells = <1>;
			#size-cells = <1>;
			last_chosen {
				reg = <0x0 0x4>;
				type = "uint32";
			};
			system0 {
				#address-cells = <1>;
				#size-cells = <1>;
				remaining_attempts {
					reg = <0x4 0x4>;
					type = "uint32";
					default = <3>;
				};
				priority {
					reg = <0x8 0x4>;
					type = "uint32";
					default = <21>;
				};
				ok {
					reg = <0xc 0x4>;
					type = "uint32";
					default = <0>;
				};
			};
			system1 {
				#address-cells = <1>;
				#size-cells = <1>;
				remaining_attempts {
					reg = <0x10 0x4>;
					type = "uint32";
					default = <3>;
				};
				priority {
					reg = <0x14 0x4>;
					type = "uint32";
					default = <20>;
				};
				ok {
					reg = <0x18 0x4>;
					type = "uint32";
					default = <0>;
				};
			};
		};
	};
};

&i2c0 {
	baseboard_eeprom@50  {
		partitions {
			compatible = "fixed-partitions";
			#size-cells = <1>;
			#address-cells = <1>;
			backend_state_eeprom: state@0 {
				reg = <0x0 0x100>;
				label = "state-eeprom";
			};
		};
	};
};


And this kinda works. And reveals more questions, I am not familiar with
barebox-state and - I admit - devicetree, yet. The problem was for me to 
address
the onboard I2C EEPROM but I managed it by digging with devinfo, this is 
a snippet
from "devinfo i2c0":

         baseboard_eeprom@50 {
                 compatible = "atmel,24c256";
                 reg = <0x50>;
                 #address-cells = <0x1>;
                 #size-cells = <0x1>;
                 baseboard_data@0 {
                         reg = <0x0 0x100>;
                 };
                 partitions {
                         compatible = "fixed-partitions";
                         #size-cells = <0x1>;
                         #address-cells = <0x1>;
                         state@0 {
                                 reg = <0x0 0x100>;
                                 label = "state-eeprom";
                                 phandle = <0x5d>;
                         };
                 };
         };

Does this and wit device tree look reasonable?

barebox, booting, puts out:

state: New state registered 'state'
state: Using bucket 0@0x00000000

What I wonder is, when this works, is in linux for the userspace the 
EEPROM still
write- and readable or blocked? I cant't judge because I suffer from 
this:

When linux boots, this happens:

nvmem 0-00501: nvmem: invalid reg on 
/ocp/interconnect@44c00000/segment@200000/target-module@b000/i2c@0/baseboard_eeprom@50/partitions
at24: probe of 0-0050 failed with error -22

Is this still something like this:

https://lkml.org/lkml/2020/4/28/411

?


What are those reg = < X Y > entries, are those in this use case offset 
+ length?

What me bugs more is, how should a devicetree setup look like (is there 
a reasonable example?)
to make the same in a file in the first FAT partition, is this possible? 
In the state specification
I read it should be able to be done by a file but ... I don't get it.

Alternatively, in the MBR I have on my MMC ther should be plenty of 
bytes be available for this,
can I address areas raw while a partition is over it?
You see, I read much about partitions in MMC being OF partitions, how do 
they live among with
mmcblk0p1 .. mmcblk0p3?

The problem is, my EEPROM aproach is nice to learn but in production it 
is hard write proteccted.
I just realized.

Kind Regards
Konsti















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

Re: Howto implement bootchooser <-> rauc interaction

[Ahmad Fatoum]

Hello Konstantin,

On 14.12.21 22:28, Konstantin Kletschke wrote:
> Dear Trent, dear mailing list people,
> 
> I managed to - somehow - utilize an onboard EEPROM for this.
> 
> On 2021-12-03 18:52, Trent Piepho wrote:
> 
>> Yes you can use your EEPROM to store state and use rauc.  One could
> 
> This is barebox devicetree I come up with:
> 
> / {
>     aliases {
>         state = &state_eeprom;
>     };
> 
>     state_eeprom: state_eeprom {
>         #address-cells = <1>;
>         #size-cells = <1>;
>         compatible = "barebox,state";
>         magic = <0xcafebabe>;
>         backend-type = "raw";
>         backend = <&backend_state_eeprom>;
>         backend-storage-type = "direct";
>         backend-stridesize = <54>;
>         /* keep-previous-content; */
> 
>         bootstate {
>             #address-cells = <1>;
>             #size-cells = <1>;
>             last_chosen {
>                 reg = <0x0 0x4>;
>                 type = "uint32";
>             };
>             system0 {
>                 #address-cells = <1>;
>                 #size-cells = <1>;
>                 remaining_attempts {
>                     reg = <0x4 0x4>;
>                     type = "uint32";
>                     default = <3>;
>                 };
>                 priority {
>                     reg = <0x8 0x4>;
>                     type = "uint32";
>                     default = <21>;
>                 };
>                 ok {
>                     reg = <0xc 0x4>;
>                     type = "uint32";
>                     default = <0>;
>                 };
>             };
>             system1 {
>                 #address-cells = <1>;
>                 #size-cells = <1>;
>                 remaining_attempts {
>                     reg = <0x10 0x4>;
>                     type = "uint32";
>                     default = <3>;
>                 };
>                 priority {
>                     reg = <0x14 0x4>;
>                     type = "uint32";
>                     default = <20>;
>                 };
>                 ok {
>                     reg = <0x18 0x4>;
>                     type = "uint32";
>                     default = <0>;
>                 };
>             };
>         };
>     };
> };
> 
> &i2c0 {
>     baseboard_eeprom@50  {
>         partitions {
>             compatible = "fixed-partitions";
>             #size-cells = <1>;
>             #address-cells = <1>;
>             backend_state_eeprom: state@0 {
>                 reg = <0x0 0x100>;
>                 label = "state-eeprom";
>             };
>         };
>     };
> };
> 
> 
> And this kinda works. And reveals more questions, I am not familiar with
> barebox-state and - I admit - devicetree, yet. The problem was for me to address
> the onboard I2C EEPROM but I managed it by digging with devinfo, this is a snippet
> from "devinfo i2c0":
> 
>         baseboard_eeprom@50 {
>                 compatible = "atmel,24c256";
>                 reg = <0x50>;
>                 #address-cells = <0x1>;
>                 #size-cells = <0x1>;
>                 baseboard_data@0 {
>                         reg = <0x0 0x100>;
>                 };
>                 partitions {
>                         compatible = "fixed-partitions";
>                         #size-cells = <0x1>;
>                         #address-cells = <0x1>;
>                         state@0 {
>                                 reg = <0x0 0x100>;
>                                 label = "state-eeprom";
>                                 phandle = <0x5d>;
>                         };
>                 };
>         };
> 
> Does this and wit device tree look reasonable?

Ye, DT here looks just like arch/arm/dts/imx6qdl-phytec-state.dtsi
and that's ok. You could increase backend-stridesize a bit to
be able to easily add non-bootchooser variables
in future if you like, but you don't have to.

> barebox, booting, puts out:
> 
> state: New state registered 'state'
> state: Using bucket 0@0x00000000
> 
> What I wonder is, when this works, is in linux for the userspace the EEPROM still
> write- and readable or blocked? I cant't judge because I suffer from this:
> 
> When linux boots, this happens:
> 
> nvmem 0-00501: nvmem: invalid reg on /ocp/interconnect@44c00000/segment@200000/target-module@b000/i2c@0/baseboard_eeprom@50/partitions
> at24: probe of 0-0050 failed with error -22
> 
> Is this still something like this:
> 
> https://lkml.org/lkml/2020/4/28/411
> 
> ?

Ye. How device trees should be interpreted is called a binding. The Linux nvmem driver
didn't adhere to the nvmem binding, which caused eeprom probe to fail, as you see.

This is fixed in Linux upstream since 0445efacec75 ("nvmem: core: skip child nodes not
matching binding"), first included with v5.12-rc1. This has been backported to older
kernels as well. You'll need that patch if you have CONFIG_NVMEM enabled in the kernel.

You can work around it in barebox, but the aforementioned kernel patch is the
proper fix.

> What are those reg = < X Y > entries, are those in this use case offset + length?

The parent node has #address-cells and #size-cells, which describe how much 32-bit
cells are offset and length. For #address-cells = 1 and #size-cells = 1, X is offset
and Y is length.

> What me bugs more is, how should a devicetree setup look like (is there a reasonable example?)
> to make the same in a file in the first FAT partition, is this possible? In the state specification
> I read it should be able to be done by a file but ... I don't get it.

I can't follow. What do you want to place in the FAT partition? The state itself?
The DT describing it? What bothers you about the current setup? (DT description
and state in EEPROM).

> Alternatively, in the MBR I have on my MMC ther should be plenty of bytes be available for this,
> can I address areas raw while a partition is over it?

You can place state in EEPROM. It looks very similar to your snippet above,
but your backend partition will be a MMC OF partition.

> You see, I read much about partitions in MMC being OF partitions, how do they live among with
> mmcblk0p1 .. mmcblk0p3?

That's indeed a bit rough around the edges. You can keep unpartitioned space at the start
of the MMC device and partition it with OF and have regular MBR/GPT partition start at
a later offset. barebox will warn you if they overlap.

> The problem is, my EEPROM aproach is nice to learn but in production it is hard write proteccted.
> I just realized.

For devices with an EEPROM, I'd use EEPROM for state over everything else.
If your only issue is the kernel error above, just import the patch
(or update to a newer more shiny Linux release :-)

HTH.

Cheers,
Ahmad

> 
> Kind Regards
> Konsti
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> barebox mailing list
> barebox@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 |

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

Fwd: Re: Howto implement bootchooser <-> rauc interaction

[Konstantin Kletschke]

I forgot to address the ML.
May be somebody else is interested!
:-/


-------- Original Message --------

  		SUBJECT:
  		Re: Howto implement bootchooser <-> rauc interaction

  		DATE:
  		2021-12-16 19:24

  		FROM:
  		Konstantin Kletschke <konstantin.kletschke@inside-m2m.de>

  		TO:
  		Ahmad Fatoum <a.fatoum@pengutronix.de>

On 2021-12-15 11:50, Ahmad Fatoum wrote:

> Ye, DT here looks just like arch/arm/dts/imx6qdl-phytec-state.dtsi

I think you are 100% right. It is borrowed from
https://bootlin.com/blog/another-system-update-adventure-with-rauc-barebox-yocto-project/
and I thing this exact file is displayed as an example there.

> This is fixed in Linux upstream since 0445efacec75 ("nvmem: core: skip 
> child nodes not
> matching binding"), first included with v5.12-rc1. This has been 
> backported to older

Okay, this information is extremely useful. I have seen your intital 
patch series but was
not able yet to gather information what commit in what time relates to 
roughly what
kernel version. So I am involved because I have 5.10.1n here. I will 
check to update
to a newer one but do you have a backport for this available by chance 
for 5.10.1x?

> The parent node has #address-cells and #size-cells, which describe how 
> much 32-bit
> cells are offset and length. For #address-cells = 1 and #size-cells = 
> 1, X is offset
> and Y is length.

So one has to take care of the parent note size being big enough to 
contain the sum of
all length and thse itself must not overlap, right?

>> What me bugs more is, how should a devicetree setup look like (is 
>> there a reasonable example?)
>> to make the same in a file in the first FAT partition, is this 
>> possible? In the state specification
>> I read it should be able to be done by a file but ... I don't get it.
> 
> I can't follow. What do you want to place in the FAT partition? The 
> state itself?
> The DT describing it? What bothers you about the current setup? (DT 
> description
> and state in EEPROM).

I am sorry I did create confusion.
I did a mistake somehow. When I have the EEPROM setup up and running 
(may be tomorrow? Always other
work looks more important) this was only for me to understand 
barebox-state fully to
work with this for production use later upon.

Because the mistake is, I _totally_ forgot when in production the 
Beaglebone Black I2C EEPROM
is write protected. The EEPROM's WP pin is hard pulled up on those 
boards with no chance
other than solder a wire to the pin to ground (against the pullup 
resistor). I forgot,
my daily work golden example has a wire but we sell so much that I must 
avoid using
the EEPROM because I cant solder wires onto every BBB.

I need to put the state somewhere else, into the MBR, before partition 
table (1st partition?)
or I need to find some NVRAM elsewhere on the board (PHY, CPU...).

> You can place state in EEPROM. It looks very similar to your snippet 
> above,
> but your backend partition will be a MMC OF partition.

> That's indeed a bit rough around the edges. You can keep unpartitioned 
> space at the start
> of the MMC device and partition it with OF and have regular MBR/GPT 
> partition start at
> a later offset. barebox will warn you if they overlap.

So state in MMC will be an OF partition which must or be covered or 
overlap with MBR
partitioning, right? What does the "OF" mean?
On the other hand I am shure in MBR the 1st 446 bytes are available 
because the TI am335x
CPU is ignoring it while searching for a bootable flagged FAT and loads 
BL from there...
On the other hand, I could access plenty of space unallocated after the 
MBR if 1st partition
starts at a late sector like 1024 or so.

And what I understood from the examples, documentation is how to access 
exactly what byte
in an EEPROM, but how do I setup and access the bytes at 0x100 to 0x300 
in the MMC at
mmc1 interface or the bytes 0x1000 to 0x2000?

And is doing this state thing in a file (for example on the 1st  FAT 
where barebox.env is)
for barebox and raux/barebox-state possible or not?

> For devices with an EEPROM, I'd use EEPROM for state over everything 
> else.

You are right, I will search for some place rather than the file or MMC 
thingy because
i chose it because it looks most convenient, but as said, Write Only in 
produktion.

> If your only issue is the kernel error above, just import the patch
> (or update to a newer more shiny Linux release :-)

No, no problem with either updating the kernel or patching it, the 
latter is at the project's
state actually more convenient I - admit.

HTH.

Very much, thanks for your friendly elaboration :-)

Regards
Konstantin

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

Re: Fwd: Re: Howto implement bootchooser <-> rauc interaction

[Ahmad Fatoum]

Hi,

On 16.12.21 20:42, Konstantin Kletschke wrote:
> I forgot to address the ML.
> On 2021-12-15 11:50, Ahmad Fatoum wrote:
> 
>> Ye, DT here looks just like arch/arm/dts/imx6qdl-phytec-state.dtsi
> 
> I think you are 100% right. It is borrowed from
> https://bootlin.com/blog/another-system-update-adventure-with-rauc-barebox-yocto-project/
> and I thing this exact file is displayed as an example there.
> 
>> This is fixed in Linux upstream since 0445efacec75 ("nvmem: core: skip child nodes not
>> matching binding"), first included with v5.12-rc1. This has been backported to older
> 
> Okay, this information is extremely useful. I have seen your intital patch series but was
> not able yet to gather information what commit in what time relates to roughly what
> kernel version. So I am involved because I have 5.10.1n here. I will check to update
> to a newer one but do you have a backport for this available by chance for 5.10.1x?

It was backported to stable in v5.10.20. Backport commit is 663a18271.

>> The parent node has #address-cells and #size-cells, which describe how much 32-bit
>> cells are offset and length. For #address-cells = 1 and #size-cells = 1, X is offset
>> and Y is length.
> 
> So one has to take care of the parent note size being big enough to contain the sum of
> all length and thse itself must not overlap, right?

Yes. Device Tree compiler helps here a bit by warning if two nodes on the same bus
have the same base address.

>>> What me bugs more is, how should a devicetree setup look like (is there a reasonable example?)
>>> to make the same in a file in the first FAT partition, is this possible? In the state specification
>>> I read it should be able to be done by a file but ... I don't get it.
>>
>> I can't follow. What do you want to place in the FAT partition? The state itself?
>> The DT describing it? What bothers you about the current setup? (DT description
>> and state in EEPROM).
> 
> I am sorry I did create confusion.
> I did a mistake somehow. When I have the EEPROM setup up and running (may be tomorrow? Always other
> work looks more important) this was only for me to understand barebox-state fully to
> work with this for production use later upon.
> 
> Because the mistake is, I _totally_ forgot when in production the Beaglebone Black I2C EEPROM
> is write protected. The EEPROM's WP pin is hard pulled up on those boards with no chance
> other than solder a wire to the pin to ground (against the pullup resistor). I forgot,
> my daily work golden example has a wire but we sell so much that I must avoid using
> the EEPROM because I cant solder wires onto every BBB.
> 
> I need to put the state somewhere else, into the MBR, before partition table (1st partition?)
> or I need to find some NVRAM elsewhere on the board (PHY, CPU...).
> 
>> You can place state in EEPROM. It looks very similar to your snippet above,
>> but your backend partition will be a MMC OF partition.
> 
>> That's indeed a bit rough around the edges. You can keep unpartitioned space at the start
>> of the MMC device and partition it with OF and have regular MBR/GPT partition start at
>> a later offset. barebox will warn you if they overlap.
> 
> So state in MMC will be an OF partition which must or be covered or overlap with MBR
> partitioning, right? What does the "OF" mean?

Open Firmware. It's the original standard that described device trees.

> On the other hand I am shure in MBR the 1st 446 bytes are available because the TI am335x
> CPU is ignoring it while searching for a bootable flagged FAT and loads BL from there...
> On the other hand, I could access plenty of space unallocated after the MBR if 1st partition
> starts at a late sector like 1024 or so.

Latter is what I usually do.

> And what I understood from the examples, documentation is how to access exactly what byte
> in an EEPROM, but how do I setup and access the bytes at 0x100 to 0x300 in the MMC at
> mmc1 interface or the bytes 0x1000 to 0x2000?

arch/arm/dts/imx6qdl-prti6q-emmc.dtsi places it on eMMC. Check it out.

> And is doing this state thing in a file (for example on the 1st  FAT where barebox.env is)
> for barebox and raux/barebox-state possible or not?

FAT isn't power-fail safe. It's ok for reading or writing stuff during
development (e.g. environment), but you really don't want to use it
for barebox-state that's meant to be power-fail safe.

You can of course use a MBR partition, but raw, without a file system.

>> For devices with an EEPROM, I'd use EEPROM for state over everything else.
> 
> You are right, I will search for some place rather than the file or MMC thingy because
> i chose it because it looks most convenient, but as said, Write Only in produktion.
> 
>> If your only issue is the kernel error above, just import the patch
>> (or update to a newer more shiny Linux release :-)
> 
> No, no problem with either updating the kernel or patching it, the latter is at the project's
> state actually more convenient I - admit.
> 
> HTH.
> 
> Very much, thanks for your friendly elaboration :-)
> 
> Regards
> Konstantin
> 
> _______________________________________________
> barebox mailing list
> barebox@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 |

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

Re: Howto implement bootchooser <-> rauc interaction

[Konstantin Kletschke]

Hi :-)

On Fri, Dec 17, 2021 at 10:46:42AM +0100, Ahmad Fatoum wrote:
 
> It was backported to stable in v5.10.20. Backport commit is 663a18271.

Sorry my git/google-foo is unsufficient, how do I get my hands on this
commit?

> > So one has to take care of the parent note size being big enough to contain the sum of
> > all length and thse itself must not overlap, right?
> 
> Yes. Device Tree compiler helps here a bit by warning if two nodes on the same bus
> have the same base address.

Okay.

> Open Firmware. It's the original standard that described device trees.

Oh, I wasn't aware, thanks for the information.

> > On the other hand, I could access plenty of space unallocated after the MBR if 1st partition
> > starts at a late sector like 1024 or so.
> 
> Latter is what I usually do.

Okay.

> arch/arm/dts/imx6qdl-prti6q-emmc.dtsi places it on eMMC. Check it out.

Yes, I will do, thank you!

> > And is doing this state thing in a file (for example on the 1st  FAT where barebox.env is)
> > for barebox and raux/barebox-state possible or not?
> 
> FAT isn't power-fail safe. It's ok for reading or writing stuff during
> development (e.g. environment), but you really don't want to use it
> for barebox-state that's meant to be power-fail safe.

Okay again, I am convinced about the no-file-in-FAT state.

So, just to be shure for the state OF partition placed after the MBR before 1st
MBR partition:

If I have 1st partition's start sector being 2048 I hafe plenty of room
before this after the MBR.

The barebox state OF partition should be in there and I could place it
at

reg = <0x300 0xfffff>

because the MBR ends at 0x1ff and the 1st partition starts at
sector 2048 ( 2048*512byte=1MB=0x10000), is that correct, is the reg
addressing done this way?

Of course a length of 0xfffff is far too much,
just to get a picture. Also to transfer this to an OF partition in a MBR
partition.

The container partition reg = <0xc0000 0x40000> in imx6qdl-prti6q-emmc.dtsi seems
to be directly going to below a MBR partiton starting at 2048th sector
with size 256kB, correct?  

Thanks for your patience!

Regards
Konstantin

INSIDE M2M GmbH
Konstantin Kletschke
Berenbosteler Straße 76 B
30823 Garbsen

Telefon: +49 (0) 5137 90950136
Mobil: +49 (0) 151 15256238
Fax: +49 (0) 5137 9095010

konstantin.kletschke@inside-m2m.de
http://www.inside-m2m.de

Geschäftsführung: Michael Emmert, Ingo Haase, Dr. Fred Könemann, Derek Uhlig
HRB: 111204, AG Hannover


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

Re: Howto implement bootchooser <-> rauc interaction

[Ahmad Fatoum]

Hi,

On 17.12.21 13:43, Konstantin Kletschke wrote:
> Hi :-)
> 
> On Fri, Dec 17, 2021 at 10:46:42AM +0100, Ahmad Fatoum wrote:
>  
>> It was backported to stable in v5.10.20. Backport commit is 663a18271.
> 
> Sorry my git/google-foo is unsufficient, how do I get my hands on this
> commit?

  git remote add stable git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
  git fetch stable --tags
  git cherry-pick 663a18271

Or just update to a more recent kernel release.

> So, just to be shure for the state OF partition placed after the MBR before 1st
> MBR partition:
> 
> If I have 1st partition's start sector being 2048 I hafe plenty of room
> before this after the MBR.
> 
> The barebox state OF partition should be in there and I could place it
> at
> 
> reg = <0x300 0xfffff>
>
> because the MBR ends at 0x1ff and the 1st partition starts at
> sector 2048 ( 2048*512byte=1MB=0x10000), is that correct, is the reg
> addressing done this way?

Nope. offset(0x300) + size(0xfffff) > 0x10000, so it overlaps MBR partition.

If you really want an OF partition starting at byte offset 0x300 and ending
at 0xffffff includsive, you'd do

  reg = <0x300 0xffd00>;

> Of course a length of 0xfffff is far too much,
> just to get a picture. Also to transfer this to an OF partition in a MBR
> partition.
> 
> The container partition reg = <0xc0000 0x40000> in imx6qdl-prti6q-emmc.dtsi seems
> to be directly going to below a MBR partiton starting at 2048th sector
> with size 256kB, correct?  

Could be. You'd have to know how the on-disk partition table looks like,
but I'd guess that partitions are aligned to 1M boundaries and this is
as you describe directly beneath it.

Cheers,
Ahmad
 
> Thanks for your patience!
> 
> Regards
> Konstantin
> 
> INSIDE M2M GmbH
> Konstantin Kletschke
> Berenbosteler Straße 76 B
> 30823 Garbsen
> 
> Telefon: +49 (0) 5137 90950136
> Mobil: +49 (0) 151 15256238
> Fax: +49 (0) 5137 9095010
> 
> konstantin.kletschke@inside-m2m.de
> http://www.inside-m2m.de
> 
> Geschäftsführung: Michael Emmert, Ingo Haase, Dr. Fred Könemann, Derek Uhlig
> HRB: 111204, AG Hannover
> 
> 


-- 
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 |

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

Re: Howto implement bootchooser <-> rauc interaction

[Konstantin Kletschke]

On Fri, Dec 17, 2021 at 02:08:01PM +0100, Ahmad Fatoum wrote:

>   git remote add stable git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
>   git fetch stable --tags
>   git cherry-pick 663a18271
> 
> Or just update to a more recent kernel release.

I need to figure out how the cherry picking works and for updating the
kernel I need to cope with "my" yocto framework I already deployed here.
The 5.10 branch seems to be the hottest shit, I will figure out how to
implement my own linux based upon the existing build framework...

>   reg = <0x300 0xffd00>;

I forgot to substract 0x300 from the length, of course!
Thanks for clarification.

> Could be. You'd have to know how the on-disk partition table looks like,
> but I'd guess that partitions are aligned to 1M boundaries and this is
> as you describe directly beneath it.

Of course, I do not know their layout neither, just to understand the
addressing/length theme.

Thank You Ahmad!

-- 
INSIDE M2M GmbH
Konstantin Kletschke
Berenbosteler Straße 76 B
30823 Garbsen

Telefon: +49 (0) 5137 90950136
Mobil: +49 (0) 151 15256238
Fax: +49 (0) 5137 9095010

konstantin.kletschke@inside-m2m.de
http://www.inside-m2m.de 

Geschäftsführung: Michael Emmert, Ingo Haase, Dr. Fred Könemann, Derek Uhlig
HRB: 111204, AG Hannover


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

Re: Howto implement bootchooser <-> rauc interaction

[Konstantin Kletschke]

I switched from doing the state in the onboard EEPROM (as said, it
is write protected in production use) to save the state in a dead space
in the onboard eMMC chip between MBR and first partition:

/ {
	aliases {
		state = &state_eeprom;
	};

	state_eeprom: state_eeprom {
		#address-cells = <1>;
		#size-cells = <1>;
		compatible = "barebox,state";
		magic = <0xcafebabe>;
		backend-type = "raw";
		backend = <&backend_state_mmc2>;
		backend-storage-type = "direct";
		backend-stridesize = <54>;
		last_chosen {
			reg = <0x0 0x4>;
			type = "uint32";
		};
		system0 {
			#address-cells = <1>;
			#size-cells = <1>;
			remaining_attempts {
				reg = <0x4 0x4>;
				type = "uint32";
				default = <3>;
			};
			priority {
				reg = <0x8 0x4>;
				type = "uint32";
				default = <21>;
			};
			ok {
				reg = <0xc 0x4>;
				type = "uint32";
				default = <0>;
			};
		};
		system1 {
			#address-cells = <1>;
			#size-cells = <1>;
			remaining_attempts {
				reg = <0x10 0x4>;
				type = "uint32";
				default = <3>;
			};
			priority {
				reg = <0x14 0x4>;
				type = "uint32";
				default = <20>;
			};
			ok {
				reg = <0x18 0x4>;
				type = "uint32";
				default = <0>;
			};
		};
	};
};

&mmc2 {
	backend_state_mmc2: part@1000 {
		label = "state";
		reg = <0x1000 0x1000>;
	};
};

This looks good so far:

barebox boot-up excerpt:

mmc1: detected MMC card version 5.1
mmc1: registered mmc1
state: New state registered 'state'
state: Using bucket 0@0x00000000

devinfo state:

Parameters:
  dirty: 0 (type: bool)
  init_from_defaults: 0 (type: bool)
  last_chosen: 2 (type: uint32)
  save_on_shutdown: 1 (type: bool)
  system0.ok: 0 (type: uint32)
  system0.priority: 21 (type: uint32)
  system0.remaining_attempts: 0 (type: uint32)
  system1.ok: 0 (type: uint32)
  system1.priority: 20 (type: uint32)
  system1.remaining_attempts: 1 (type: uint32)

bootchooser -i:

Good targets (first will be booted next):
system1
    id: 2
    priority: 20
    default_priority: 1
    remaining attempts: 1
    default attempts: 3
    boot: 'system1'

Disabled targets:
system0
    id: 1
    priority: 21
    default_priority: 1
    remaining attempts: 0
    default attempts: 3
    boot: 'system0'
    disabled due to remaining attempts = 0

last booted target: system1

Compiled in (relevant) variables:

* boot.default: bootchooser insidem2m_1 insidem2m_2
  boot.watchdog_timeout: 0
  bootchooser.default_attempts: 3
  bootchooser.default_priority: 1
  bootchooser.disable_on_zero_attempts: 0
  bootchooser.reset_attempts:  (list: "power-on", "all-zero")
  bootchooser.reset_priorities: 
  bootchooser.retry: 0
* bootchooser.state_prefix: state
* bootchooser.targets: system0 system1

devinfo excerpt:

            `-- 481d82fc.target-module@d8000.of
               `-- 481d8000.mmc@0.of
                  `-- mmc1
                     `-- 0x00000000-0xe3ffffff (   3.6 GiB): /dev/mmc1
                     `-- 0x00100000-0x010fffff (    16 MiB): /dev/mmc1.0
                     `-- 0x01100000-0x4ddfffff (   1.2 GiB): /dev/mmc1.1
                     `-- 0x4de00000-0x9aafffff (   1.2 GiB): /dev/mmc1.2
                     `-- 0x9ab00000-0xe3ffffff (   1.1 GiB): /dev/mmc1.3
                     `-- 0x00001000-0x00001fff (     4 KiB): /dev/mmc1.state
                     `-- fat0

boot:

Booting entry 'bootchooser'
Booting entry 'system1'
ext4 ext40: EXT2 rev 1, inode_size 256, descriptor size 64
mounted /dev/mmc1.2 on /mnt/mmc1.2
[...]


The userspace is no amused, however:

rauc status output:

(rauc:583): rauc-WARNING **: 18:51:57.389: Failed getting primary slot: Failed getting primary slot: No content to read

=== System Info ===
Compatible:  insidem2m-s
Variant:
Booted from: rootfs.1 (system1)

=== Bootloader ===
Activated: (null) ((null))

=== Slot States ===
o [rootfs.1] (/dev/mmcblk0p3, ext4, booted)
	bootname: system1
	mounted: /
	boot status: bad

o [rootfs.0] (/dev/mmcblk0p2, ext4, inactive)
	bootname: system0
	boot status: bad


/etc/rauc/system.conf:

[system]
compatible=insidem2m-s
bootloader=barebox

[keyring]
path=ca.cert.pem

[slot.rootfs.0]
device=/dev/mmcblk0p2
type=ext4
bootname=system0

[slot.rootfs.1]
device=/dev/mmcblk0p3
type=ext4
bootname=system1


barebox-state:

last_chosen=2
system0.remaining_attempts=0
system0.priority=21
system0.ok=0
system1.remaining_attempts=2
system1.priority=20
system1.ok=0


So rauc is not happy, is somethong wrong with the system.conf?


################ PLAN B ##################

I had a previous state device tree setup, which made userspace happy,
but not barebox. I had a parent bootstate section containing system0 and
system1:

/ {
	aliases {
		state = &state_eeprom;
	};

	state_eeprom: state_eeprom {
		#address-cells = <1>;
		#size-cells = <1>;
		compatible = "barebox,state";
		magic = <0xcafebabe>;
		backend-type = "raw";
		backend = <&backend_state_mmc2>;
		backend-storage-type = "direct";
		backend-stridesize = <54>;
		bootstate {
			#address-cells = <1>;
			#size-cells = <1>;
			last_chosen {
				reg = <0x0 0x4>;
				type = "uint32";
			};
			system0 {
				#address-cells = <1>;
				#size-cells = <1>;
				remaining_attempts {
					reg = <0x4 0x4>;
					type = "uint32";
					default = <3>;
				};
				priority {
					reg = <0x8 0x4>;
					type = "uint32";
					default = <21>;
				};
				ok {
					reg = <0xc 0x4>;
					type = "uint32";
					default = <0>;
				};
			};
			system1 {
				#address-cells = <1>;
				#size-cells = <1>;
				remaining_attempts {
					reg = <0x10 0x4>;
					type = "uint32";
					default = <3>;
				};
				priority {
					reg = <0x14 0x4>;
					type = "uint32";
					default = <20>;
				};
				ok {
					reg = <0x18 0x4>;
					type = "uint32";
					default = <0>;
				};
			};
		};
	};
};

&mmc2 {
	backend_state_mmc2: part@1000 {
		label = "state";
		reg = <0x1000 0x1000>;
	};
};

With this device tree barebox bootschooser is unhappy:

barebox@TI AM335x BeagleBone black:/ devinfo state
Parameters:
  bootstate.last_chosen: 2 (type: uint32)
  bootstate.system0.ok: 0 (type: uint32)
  bootstate.system0.priority: 21 (type: uint32)
  bootstate.system0.remaining_attempts: 0 (type: uint32)
  bootstate.system1.ok: 0 (type: uint32)
  bootstate.system1.priority: 20 (type: uint32)
  bootstate.system1.remaining_attempts: 2 (type: uint32)
  dirty: 0 (type: bool)
  init_from_defaults: 0 (type: bool)
  save_on_shutdown: 1 (type: bool)
barebox@TI AM335x BeagleBone black:/ boot
WARNING: bootchooser: Cannot read priority for target system0, using default 1
WARNING: bootchooser: Cannot read remaining attempts for target system0, using default 3
WARNING: bootchooser: Cannot read priority for target system1, using default 1
WARNING: bootchooser: Cannot read remaining attempts for target system1, using default 3
Cannot set parameter state.system0.remaining_attempts: No such device
ERROR: bootchooser: Failed to save bootchooser state: No such device
Booting entry 'bootchooser'
WARNING: bootchooser: Cannot read priority for target system0, using default 1
WARNING: bootchooser: Cannot read remaining attempts for target system0, using default 3
WARNING: bootchooser: Cannot read priority for target system1, using default 1
WARNING: bootchooser: Cannot read remaining attempts for target system1, using default 3
Cannot set parameter state.last_chosen: No such device
Cannot set parameter state.system0.remaining_attempts: No such device
Booting entry 'system0'
ext4 ext40: EXT2 rev 1, inode_size 256, descriptor size 64
mounted /dev/mmc1.1 on /mnt/mmc1.1
[...]

But userspace is fine:

rauc-Message: 18:58:50.111: rauc status: marked slot rootfs.0 as good

rauc status:

=== System Info ===
Compatible:  insidem2m
Variant:
Booted from: rootfs.0 (system0)

=== Bootloader ===
Activated: rootfs.0 (system0)

=== Slot States ===
  [bootloader.0] (/dev/mmcblk0p1, vfat, inactive)

o [rootfs.1] (/dev/mmcblk0p3, ext4, inactive)
	bootname: system1
	boot status: good

x [rootfs.0] (/dev/mmcblk0p2, ext4, booted)
	bootname: system0
	mounted: /
	boot status: good


barebox-state -d:

bootstate.last_chosen=2
bootstate.system0.remaining_attempts=3
bootstate.system0.priority=21
bootstate.system0.ok=0
bootstate.system1.remaining_attempts=2
bootstate.system1.priority=20
bootstate.system1.ok=0


I assume this has to do with bootchooser.state_prefix. If I change from
state to bootstate (yes, brute force) I get:

global excerpt:

* bootchooser.state_prefix: bootstate

devinfo state looks the same as previous.

boot:

barebox@TI AM335x BeagleBone black:/ boot
ERROR: bootchooser: Cannot get state 'bootstate'
Nothing bootable found on 'bootchooser'
Booting entry 'insidem2m_1'
ext4 ext40: EXT2 rev 1, inode_size 256, descriptor size 64
mounted /dev/mmc1.1 on /mnt/mmc1.1
[...]



When I set:

* bootchooser.state_prefix: state.bootstate

I get best of both worlds!

"devinfo state" still the same as previous two cases (logical, since DT
setup is the same, only bootchooser.state_prefix changed), "bootchooser
-i" looks sane, booting happens w/o any error, and userspace
(barebox-state -d, rauc status, barebox-state -g bootstate.system0.ok)
too!

Wall of text, two questions:

Is this resulting setup (DT with bootstate parent, state_prefix:
state.bootstate) sane?

Can the variant without the boostate variant work too? If it was the
other way around, userspace working w/o the bootstate variant but bnot
_with_ I would say additional configuration required or something, but
this way... I would like to understand this fully.


Kind Regards
Konstantin


-- 
INSIDE M2M GmbH
Konstantin Kletschke
Berenbosteler Straße 76 B
30823 Garbsen

Telefon: +49 (0) 5137 90950136
Mobil: +49 (0) 151 15256238
Fax: +49 (0) 5137 9095010

konstantin.kletschke@inside-m2m.de
http://www.inside-m2m.de 

Geschäftsführung: Michael Emmert, Ingo Haase, Dr. Fred Könemann, Derek Uhlig
HRB: 111204, AG Hannover


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

Re: Howto implement bootchooser <-> rauc interaction

[Ahmad Fatoum]

Hello Konstantin,

On 22.12.21 15:05, Konstantin Kletschke wrote:
> I switched from doing the state in the onboard EEPROM (as said, it
> is write protected in production use) to save the state in a dead space
> in the onboard eMMC chip between MBR and first partition:
> 
> / {
> 	aliases {
> 		state = &state_eeprom;
> 	};
> 
> 	state_eeprom: state_eeprom {
> 		#address-cells = <1>;
> 		#size-cells = <1>;
> 		compatible = "barebox,state";
> 		magic = <0xcafebabe>;
> 		backend-type = "raw";
> 		backend = <&backend_state_mmc2>;
> 		backend-storage-type = "direct";
> 		backend-stridesize = <54>;
> 		last_chosen {

Here last_chosen is toplevel.


> Compiled in (relevant) variables:
> 
> * boot.default: bootchooser insidem2m_1 insidem2m_2
>   boot.watchdog_timeout: 0
>   bootchooser.default_attempts: 3
>   bootchooser.default_priority: 1
>   bootchooser.disable_on_zero_attempts: 0
>   bootchooser.reset_attempts:  (list: "power-on", "all-zero")
>   bootchooser.reset_priorities: 
>   bootchooser.retry: 0
> * bootchooser.state_prefix: state

Here you say they are inside state.*

> The userspace is no amused, however:
> 
> rauc status output:
> 
> (rauc:583): rauc-WARNING **: 18:51:57.389: Failed getting primary slot: Failed getting primary slot: No content to read

Yes RAUC has:

  #define BOOTSTATE_PREFIX "bootstate"

So that's what you need to use.

> barebox-state:
> 
> last_chosen=2
> system0.remaining_attempts=0
> system0.priority=21
> system0.ok=0
> system1.remaining_attempts=2
> system1.priority=20
> system1.ok=0

But state works correctly regardless, you can place
all sort of stuff there.

> ################ PLAN B ##################
> 
> I had a previous state device tree setup, which made userspace happy,
> but not barebox. I had a parent bootstate section containing system0 and
> system1:
> 
> / {
> 	aliases {
> 		state = &state_eeprom;
> 	};
> 
> 	state_eeprom: state_eeprom {
> 		#address-cells = <1>;
> 		#size-cells = <1>;
> 		compatible = "barebox,state";
> 		magic = <0xcafebabe>;
> 		backend-type = "raw";
> 		backend = <&backend_state_mmc2>;
> 		backend-storage-type = "direct";
> 		backend-stridesize = <54>;
> 		bootstate {

Here you have a correctly named container.

> With this device tree barebox bootschooser is unhappy:

Did you set bootchooser.boot_prefix?

> But userspace is fine:

As expected.

> I assume this has to do with bootchooser.state_prefix. If I change from
> state to bootstate (yes, brute force) I get:
> 
> global excerpt:
> 
> * bootchooser.state_prefix: bootstate
> 
> devinfo state looks the same as previous.
> 
> boot:
> 
> barebox@TI AM335x BeagleBone black:/ boot
> ERROR: bootchooser: Cannot get state 'bootstate'
> Nothing bootable found on 'bootchooser'
> Booting entry 'insidem2m_1'
> ext4 ext40: EXT2 rev 1, inode_size 256, descriptor size 64
> mounted /dev/mmc1.1 on /mnt/mmc1.1
> [...]
> 
> 
> 
> When I set:
> 
> * bootchooser.state_prefix: state.bootstate
> 
> I get best of both worlds!

Exactly. :-)

> Wall of text, two questions:
> 
> Is this resulting setup (DT with bootstate parent, state_prefix:
> state.bootstate) sane?

Ye, the final setup looks good now.

> Can the variant without the boostate variant work too? If it was the
> other way around, userspace working w/o the bootstate variant but bnot
> _with_ I would say additional configuration required or something, but
> this way... I would like to understand this fully.

RAUC hardcodes bootstate, so that's what you need to use, unless you patch
RAUC.

Cheers,
Ahmad

> 
> 
> Kind Regards
> Konstantin
> 
> 


-- 
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 |

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

Re: Howto implement bootchooser <-> rauc interaction

[Konstantin Kletschke]

On Wed, Jan 05, 2022 at 06:50:17PM +0100, Ahmad Fatoum wrote:

> RAUC hardcodes bootstate, so that's what you need to use, unless you patch
> RAUC.

Dear Ahmad, thanks again for your technical advise.
My wall of text indeed was intended to ask for this detail, I realized.
If this "bootstate" id hardcoded (Yes, it is) I understand, what's going
on. Nice!

Kind Regards
Happy new year

Konstantin


-- 
INSIDE M2M GmbH
Konstantin Kletschke
Berenbosteler Straße 76 B
30823 Garbsen

Telefon: +49 (0) 5137 90950136
Mobil: +49 (0) 151 15256238
Fax: +49 (0) 5137 9095010

konstantin.kletschke@inside-m2m.de
http://www.inside-m2m.de 

Geschäftsführung: Michael Emmert, Ingo Haase, Dr. Fred Könemann, Derek Uhlig
HRB: 111204, AG Hannover


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