Access to the MTD devices from disk-based OS’es was blocked in the 0.8.x firmware series, see this post for the reasons.
The 0.9.x series does not have this limitation.
I have also done some work enabling “capsule on disk” updates which means the “standard” distribution mechanisms (like fwupd) will work. I think I’ll wait until U-Boot 2024.10 is out before releasing it.
If you want, you can re-enable this in the earlier U-Boot by deleting the following portion of the setup_distroboot_efi variable:
fdt set "/soc/spi@20c0000" "status" "disabled"
I am concerned about the firmware configuration.
fw_printenv bootcmd
Cannot open /dev/mtd3: No such file or directory
If I understand correctly, two issues with these devices are linked, thus, I can only do modifications from U-boot with a serial converter in the new (non-testing) firmware?
(be careful attempting this remotely, the boot process will get stuck if not edited correctly)
What is the process here? I’d like to avoid bricking the device due to a small typo. I presume I go into the boot sequence and have some access to the configuration there, backup original config, remove the line, save it and hope for the best?
For now, I’ll look into the testing branch. Is there any documentation on switching the MTD configuration to test different SFP types for the testing firmware?
Older versions of some distributions contained a flash driver which was not able to access the NAND chip, and could corrupt it if used incorrectly
I’m curious to know more and wonder if this is documented anywhere.
To clarify, the U-Boot environment is on a MTD device, so on the 0.8.x configuration, it is not possible to modify it (using fw_printenv/setenv) from a EFI-based distro either. You need to do MTD operations from U-Boot, Recovery or OpenWrt-NAND.
In the method mentioned above, the worst that can happen is that the U-Boot ‘distroboot’ no longer works. U-Boot will start, but it won’t be able to handover to an operating system.
You can recover by going to a U-Boot shell and resetting to the ‘default’ environment:
env default -a && saveenv && reset
The newer U-Boot (in Ten64 F/W 0.9.x) uses the much more robust “bootflow” system which doesn’t rely on scripting (and is much harder to damage as a result).
The procedure (for changing the SFP/BL2) is the same on the newer firmware releases, just that you can now access MTD (flash) devices from EFI/disk based operating systems.
Prior to Linux 5.1, the QuadSPI driver for Freescale platforms (Layerscape and i.MX6,7) could not handle SPI-NAND devices, as these have a slightly different command set.
(While Ten64’s started shipping after 5.10 was out, there were a few distributions at the time that were using older kernels like 4.19)
In fact, the QuadSPI hardware block is not really a SPI master, but a “scriptable” bit bang device that has a look up table (LUT) for most common SPI flash commands. It works really nicely for NOR-based flashes (and use cases like XIP) but not as well for NAND.
In 5.1 (and soon after in U-Boot), the driver was changed to dynamically create a LUT entry for each operation (see the intro commit).
On the very first Ten64 boards I spent quite a bit of time trying to hack SPI-NAND into U-Boot and Linux, which thankfully was not needed by the time we started shipping to the public.
I hope that explains why the previous firmware releases were set up in this way. Going forward I encourage distributions to use the standardized mechanisms, so it will be easier to migrate to the next generation of hardware.