From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: From: Martin Hollingsworth Date: Thu, 26 Nov 2020 12:18:33 +0000 Message-ID: <5e21b35b921c448d8c2181a9584007fc@itk-engineering.de> References: <20201126112001.GD9315@pengutronix.de> In-Reply-To: <20201126112001.GD9315@pengutronix.de> Content-Language: de-DE MIME-Version: 1.0 Subject: Re: [RAUC] boot-mbr-switch from u-boot List-Id: RAUC Project - Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: rauc-bounces@pengutronix.de Sender: "RAUC" To: Michael Tretter Cc: "rauc@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