mail archive of the rauc mailing list
 help / color / mirror / Atom feed
From: Martin Hollingsworth <Martin.Hollingsworth@itk-engineering.de>
To: Michael Tretter <m.tretter@pengutronix.de>
Cc: "rauc@pengutronix.de" <rauc@pengutronix.de>
Subject: Re: [RAUC] boot-mbr-switch from u-boot
Date: Thu, 26 Nov 2020 12:18:33 +0000	[thread overview]
Message-ID: <5e21b35b921c448d8c2181a9584007fc@itk-engineering.de> (raw)
In-Reply-To: <20201126112001.GD9315@pengutronix.de>

Hello Michael,
thanks for the quick response.

>How do you tell Linux, what is contained in the FPGA firmware? Linux should
>not make any assumptions about the loaded FPGA firmware.

Through dtb entries the FPGA IP cores are registered as hardware, the kernel loads the appropriate drivers. On Xilinx ZynqMP platform using the Xilinx default boot procedure the dtb is part of the Xilinx bootbin file (the FSBL file on boot partition). The fsbl loads the dtb into memory because u-boot is dtb aware (since ~Xilinx v2020.1). The Kernel Image is default also part of the boot partition, but maybe this could be moved to the rootFS partition.

>> Does anyone have a solution for this problem?
>
>There are a few solutions:
>
>You could use a different mechanism to load the firmware. Instead of the
>boot.bin, put the bitstream into the rootfs (or another partition) and load it
>from the bootloader (I'm not sure, if U-Boot supports this, but Barebox does.)
>or from Linux.
>
>If it is mandatory to load the firmware from the FSBL (or the bootloader
>partition in general), you would need a means to tell Linux, which firmware
>was loaded. That information has to be stored in the updated bootloader
>partition.

The second is the case for my platform.

Assuming the old Linux system can boot with the updated boot partition and the userspace can detect the firmware mismatch: can RAUC manually switch the boot partition via MBR without switching the rootFS slot? Currently I would say no, because bootloader and rootFS slots are grouped together.
Assuming the old Linux system cannot boot, we have just bricked the Linux system via the Slot switch. Hence we loose the RAUC "fallback to last installed system" feature whenever u-boot does the slot switch (instead of rauc-mark-bad).

In addition I could see the following solution:

Implement boot-mbr-switch inside u-boot whenever BOOT_ORDER  must be rearranged. My first guess would be to add this to the RAUC boot script by manipulating the boot partition table (boot partition start offset?).

Cheers, Martin

_______________________________________________
RAUC mailing list

  reply	other threads:[~2020-11-26 12:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-26  8:57 Martin Hollingsworth
2020-11-26 11:20 ` Michael Tretter
2020-11-26 12:18   ` Martin Hollingsworth [this message]
2020-11-26 14:00     ` Jan Lübbe
2020-11-27 15:21       ` Martin Hollingsworth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5e21b35b921c448d8c2181a9584007fc@itk-engineering.de \
    --to=martin.hollingsworth@itk-engineering.de \
    --cc=m.tretter@pengutronix.de \
    --cc=rauc@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox