duing

No, same error. We prefer to see the replicateable changes instead of running a wild binary. Does it work for you on real Odroid-HC4 hardware? U-Boot prints (use CONFIG_DISPLAY_BOARDINFO_LATE): SoC: Amlogic Meson SM1 (S905X3) Revision 2b:c (10:2)

I followed your link and tried your build, nice menu but same error: jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 00, 00, 00 Failed to initialize SPI flash at 0:0 (error -2) This error is from U-Boot and Linux gives the same, my first post shows the error in Linux with debugging turned on and a reduced frequency (and vcc-supply) set in device tree source. It works with Hardkernel's firmware, thus is not a faulty hardware and nothing new.

ok, me too is not booting its first. is my hc4 flash chip newer? i think i tried all, mine is not initialized (petitboot said xt25f128b). you said just `run mmc-to-sf`, that is not a mainline v2026-04 standard set variable, brother. Thank you for your answer. I cannot access flash from mainline U-Boot nor Linux.

You're using Hardkernel's U-Boot. Yes, it's probably more importent to read from flash memory early, at boot. Using the manufactors bootloader is the only option until the chip or whatever is supported "mainline". If one doesn't care about flash, but doesn't want to depend on SD card to boot from e.g. SATA, an option is to run Hardkernel's Linux, once to write U-Boot to NOR flash . kexec seems to need CONFIG_PROC_KCORE, but Armbian as many others doesn't. Mainline U-Boot doesn't load Hardkernel's Linux. Perhaps just boot the spiupdate.img without spiboot.img and run. (sounds strange I know, but better than cross-cross-compile out-of-date) Any news on mainline (patched) support for SPI NOR flash on Odroid-HC4? Perhaps I miss just a simple thing?

How do you write U-Boot to SPI NOR flash? Without a working driver upstream, the best I can think of now is just using the shipped U-Boot/Linux (Petitboot from the manufactor). If you want to make it from source, use the shipped cross-compiler on 64 bit PC, perhaps on an archived OS, or rewrite Makefiles. But that leaves the (for some tiny) 16 MB just for the bootloader, which doesn't even knows it's own bootdev. It seems the beforehand bootloader-loader doesn't look after SATA HDD, only SPI NOR or MMC SD. After all, just press a button to alternately load from removable card if one installed and failed to run from NOR. Did I miss a thing in device-tree? The regulator.patch is upstream, which keeps the drives spun-up while boot (at least MMC is powered). Thanks, yours duing.

I wanted to play with: kernel on ubifs or perhaps DAX on erofs. The bootloader must be signed differently for SD and NOR flash with some kind of arm-trusted-firmware, a PC binary that can be started as binmisc under qemu in Linux on ARM.

I tried different overlays, reduced max-frequency, set rx-(-tx)-bus-width and different mode settings indepently. Is it perhaps driven by gpio regulator instead of fixed 3v3? With a vcc-supply property one line (warning) goes away.

How can we acces the SPI NOR Flash on Odroid HC4? The usual error seems to be the driver, not a thing we can overlay device tree? Id for xt25f128b is implemented. meson-spifc ffd14000.spi: registered host spi0 spi spi0.0: setup mode 0, 8 bits/w, 1000000 Hz max --> 0 spi-nor spi0.0: supply vcc not found, using dummy regulator spi-nor spi0.0: error -95 reading JEDEC ID spi-nor spi0.0: probe with driver spi-nor failed with error -95 meson-spifc ffd14000.spi: registered child spi0.0