Cannot flash new .jic file after U-boot start

RocketBoards General
1

My problem is with an Agilex design, but I expect it will be the same with Stratix10.

I have copied a HPS First design to the QSPI flash. It contains U-Boot as FSBL and SSBL, where SSBL is in SD-card.
U-boot starts fine, and I can use many commands, e.g. fatls, fatload, mii, md.
When I want to write a new design to the QSPI flash (with changed FSBL), I get this error in Quartus Programmer:
Info (209060): Started Programmer operation at Mon Jun 29 15:13:04 2020
Error (20194): Access to flash interface is denied. Potential errors: The flash interface that you are trying to access is currently open in another application.
Error (209012): Operation failed
Info (209061): Ended Programmer operation at Mon Jun 29 15:13:09 2020

I have tried to erase the QSPI flash with these u-boot commands:
SOCFPGA_AGILEX # sf probe
SF: Detected mt25qu02g with page size 256 Bytes, erase size 4 KiB, total 256 MiB
SOCFPGA_AGILEX # sf erase 0 80000
SF: 524288 bytes @ 0x0 Erased: OK
SOCFPGA_AGILEX #

but it doesn’t help. After a power-cycle U-Boot was still started.
The only thing that I have found working is to load an .rbs file with the same contents (logically) as the .jic file into memory and then write it to the QSPI flash:
SOCFPGA_AGILEX # fatload mmc 0:1 1000 fpga158.hps.rbf
430080 bytes read in 45 ms (9.1 MiB/s)
SOCFPGA_AGILEX # sf update 1000 0 ${filesize}
device 0 offset 0x0, size 0x69000
430080 bytes written, 0 bytes skipped in 0.854s, speed 513887 B/s
SOCFPGA_AGILEX #

After a power-cycle the SDM cannot start the HPS, so U-Boot never gets to blocking the QSPI access (my guess), and now Quartus Programmer can write the new .jic file to QSPI.
I do not find this workaround sufficient. It should be enough to write the QSPI with either Quartus or U-Boot.

2

A small simplification (but in my opinion still not a solution):
I learned the the first 0x200000 bytes of the QSPI is something called BOOT_INFO, so erasing 0x80000 bytes was too little. The real FPGA image starts at 0x200000, and erasing a single page (0x10000) there will also disable the HPS. And it is not necessary to power-cycle, the U-Boot command “reset” is enough.

3

I found a solution, sort of.
It appears that U-Boot reserves the QSPI for HPS access with the function mbox_qspi_open() in mailbox_s10.c.
So I added a U-Boot command that calls mbox_qspi_close(), and now Quartus Programmer can access/reprogram the QSPI flash without any reset or power-cycle.
I find it a little better than the “sf probe; sf erase 200000 10000; reset” command sequence, but it does of course require a little U-Boot programming. I added these lines in the bottom of clock_manager_agilex.c and clock_manager_s10.c:

#include <asm/arch/mailbox_s10.h>

#ifndef CONFIG_SPL_BUILD
#ifdef CONFIG_CADENCE_QSPI
static int do_cadence_qspi(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
	if (argc != 2)
		return CMD_RET_USAGE;

	switch (argv[1][2]) {
	case 's':	/* Reserve */
		mbox_qspi_open();
		break;
	case 'l':	/* Release */
		mbox_qspi_close();
		break;
	default:
		return CMD_RET_USAGE;
	}

	return 0;
}

U_BOOT_CMD(cqspi, 2, 1, do_cadence_qspi,
	   "SoCFPGA QSPI control",
	         "reserve - Reserve QSPI for U-Boot usage\n"
	   "cqspi release - Release QSPI from U-Boot usage (so Quartus Programmer can use it)\n"
	   ""
);

#endif
#endif