Add note for boot.frm about plutosdr-fw HOT 3 OPEN

Just inform that building process without Vivado doesn't produce boot.frm.

This is known. The current README says:

To build the FPGA bitstream, Vivado 2021.2 is required.

Maybe we can add a sentence after this "The boot.frm file includes the FPGA bitstream, so Vivado is also required to build it."?

On this note, the ADI Makefile for the stock firmware includes a feature to detect whether Vivado is not present and if it isn't it will download the XSA from Github instead of building it. I never made sure that this works with the Maia SDR firmware, but it could be done if there is enough interest.

Installation described in readme to set environment could be done alternatively by using uboot-env.dfu.

Indeed. The uboot-env.dfu that is built with the Maia SDR firmware already contains the correct settings. The reason that the installation instructions do not mention this is that it is safer to use a couple of fw_setenv commands than to update all the uboot environment. Breaking uboot would break the DFU capability, leaving a Pluto that can only be recovered by JTAG (effectively bricking it for most people), and I want to steer clear of those problems as much as possible.

from plutosdr-fw.

This is known. The current README says: To build the FPGA bitstream, Vivado 2021.2 is required.

I assume building FPGA bistream is xsa, but boot.frm use a tool from the Xilink sdk.

it will download the XSA

Confirm it is working

Breaking uboot would break the DFU capability

By default , uboot could not be updated (so not break)... boot.frm which includes boot and env has only effect on env.

https://ez.analog.com/adieducation/university-program/f/q-a/114236/can-we-really-update-u-boot
https://ez.analog.com/adieducation/university-program/f/q-a/562284/update-u-boot-failed

from plutosdr-fw.

Oh, I had a mixup in my head between boot.frm (which is the boot.bin containing the FSBL and uboot, and the uboot env), and pluto.frm (the uImage containing the bitstream, kernel and rootfs). Indeed making boot.bin requires Xilinx's mkimage. This is the same as with the stock ADI firmware.

By default , uboot could not be updated (so not break)... boot.frm which includes boot and env has only effect on env.

Interesting. I didn't know that the boot.bin QSPI partition was locked. At some point I updated this partition in one of my Plutos. I don't remember how I did it. Maybe it was from uboot, by using sf protect unlock.

In any case, although rare, I still think that a bad uboot env could prevent the device from entering DFU correctly, so I'd rather have users update the couple parameters that are needed using fw_setenv (which is also recommended by ADI to update other parameters such as the ad9361 compat, and thus somewhat familiar to users), instead of updating the whole env by flashing boot.frm. This has the additional advantage of not overwriting other parameters that the user might have set, such as the IP address or USB Ethernet driver mode.

from plutosdr-fw.