Hi again Icenowy,
On 6/6/23 17:09, Sam Edwards wrote:
Still, I believe it's sensible that, when we know for sure we're coming from SPI-NAND (because it's a newer sunxi that reports 0x04, or we know from the suniv stack-checking hack), we should call that its own SPL load method, which does not fall back to SPI-NOR. The SPI(-NOR) load method naturally has to implement the try-NAND-first logic for some of these SoCs, but perhaps we could call it a "quirk" and only do that for chips that aren't known to report SPI-NAND directly?
Since other methods that care about flash type (e.g. env_get_location) don't understand BOOT_DEVICE_SPI to mean "SPI, but the actual flash type is ambiguous," I'm starting to think we need to resolve the ambiguity *before* the load method runs.
What are your thoughts on this: 1. Introduce SUNXI_BOOTED_FROM_SPI_NAND, value 4 (matching the value used by Allwinner's newer BROMs). 2. Map SUNIV_BOOTED_FROM_NAND to SUNXI_BOOTED_FROM_SPI_NAND. 3. Map SUNXI_BOOTED_FROM_SPI_NAND to BOOT_DEVICE_NAND (and not _SPI). 4. Implement the SPI-NAND stuff to provide `nand_spl_load_image` (so that the common SPL framework's NAND loader can take care of it). Possibly go even further and implement the methods needed by the UBI loader too. 5. On sunxis (e.g. V3s) which are known to report SUNXI_BOOTED_FROM_SPI for SPI-NAND, add a small check to sunxi_get_boot_device() which disambiguates this situation by probing for SPI-NAND.
If #4 isn't really feasible, we might instead want to introduce a BOOT_DEVICE_SPI_NAND, but I don't know if adding sunxi to the list of platforms that have their own BOOT_DEVICE_ names is a great call.
In any case, I'd hope also to see some kind of bad block handling in here -- a simple check for a bad block each time we get to page 0 (which skips to the next block) should be pretty easy, don't you think?
Any thoughts? Any other way I can be of service? (Feel free to delegate some of these ideas to me if you think they're good but don't have the time to execute them!)
Warm regards, Sam