After installing the new mainline OpenWRT build onto my eMMC partition (following the instructions here), I am no longer able to boot into NAND. I did not touch any of the NAND devices, only writing to the devices listed in the instructions.
(for reference, from the out-of-the-box NAND boot:)
3. Write bootloader and OpenWrt images
Move files to the device /tmp using scp:
- openwrt-*-bananapi_bpi-r3-mini-emmc-preloader.bin
- openwrt-*-bananapi_bpi-r3-mini-emmc-bl31-uboot.fip
- openwrt-*-bananapi_bpi-r3-mini-initramfs-recovery.itb
- openwrt-*-bananapi_bpi-r3-mini-squashfs-sysupgrade.itb
Write them to the appropriate partitions:
echo 0 > /sys/block/mmcblk0boot0/force_ro
dd if=/tmp/openwrt-*-bananapi_bpi-r3-mini-emmc-preloader.bin of=/dev/mmcblk0boot0
dd if=/tmp/openwrt-*-bananapi_bpi-r3-mini-emmc-bl31-uboot.fip of=/dev/mmcblk0p3
dd if=/tmp/openwrt-*-bananapi_bpi-r3-mini-initramfs-recovery.itb of=/dev/mmcblk0p4
dd if=/tmp/openwrt-*-bananapi_bpi-r3-mini-squashfs-sysupgrade.itb of=/dev/mmcblk0p5
sync
F0: 102B 0000
FA: 1040 0000
FA: 1040 0000 [0200]
F9: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 2400 0041 [0000]
G0: 1190 0000
EC: 0000 0000 [1000]
T0: 0000 021E [010F]
Jump to BL
NOTICE: BL2: v2.6(release):
NOTICE: BL2: Built : 20:18:14, May 7 2023
NOTICE: WDT: disabled
NOTICE: CPU: MT7986 (2000MHz)
NOTICE: EMI: Using DDR4 settings
NOTICE: EMI: Detected DRAM size: 2048MB
NOTICE: EMI: complex R/W mem test passed
NOTICE: SPI_NAND parses attributes from parameter page.
NOTICE: SPI_NAND Detected ID 0xef
NOTICE: Page size 2048, Block size 131072, size 134217728
NOTICE: Initializing NMBM ...
NOTICE: Signature found at block 1023 [0x07fe0000]
NOTICE: First info table with writecount 0 found in block 960
NOTICE: Second info table with writecount 0 found in block 963
NOTICE: NMBM has been successfully attached in read-only mode
ERROR: BL2: Failed to load image id 3 (-2)
Per other threads I’ve seen looking around, it may have been as simple as an incomplete write that caused the eMMC images to be corrupt, however I am surprised by the information that the NAND boot that was previously working is now also unavailable. Given that both partitions now immediately go into the above failure state, is there any way to recover the NAND partition, or at least get uboot or the like running long enough to attempt to recover the eMMC partition?
Please give more detail what exactly was done and correct me if I get something wrong.
So you were booting stock firmware on the BPI-R3 mini from SPI-NAND and used that to write OpenWrt snapshot images to the eMMC. And now you can’t boot from either SPI-NAND nor eMMC?
So this looks like the (unfortunately not too uncommon) NAND corruption issue I’ve seen before.
Storing this image id 3 (fip) in UBI should prevent that in future, but now you are in the mess already before having had a chance to even install OpenWrt.
Please post the output when putting the boot switch into eMMC position.
Edit: I assume you were booting from NAND while writing the images to eMMC, right?
You didn’t replace preloader on eMMC (v2.6 is stock, v2.9 would be from OpenWrt snapshot), and this is why it cannot work. Did you ever successfully boot OpenWrt snapshot from the eMMC? Because that (booting with OpenWrt on eMMC) could partially explain the corruption you see on the SPI-NAND now.
Ok, then probably something went wrong with writing the file to the eMMC. Because obviously the bl2 image in /dev/mmcblk0boot0 has never been touched, it’s still the one which belongs (and only works with) the stock firmware.
Anytime please confirm that one EMMC or Nand device include one bootable image, it’s very important!!
I had booted to NAND successfully in order to flash EMMC, and left it untouched for exactly that reason, however it seems that once I wrote to EMMC something the NAND boot required was damaged and would no longer boot, which is not something that I had expected would happen.
Is there anyway to perform the factory flash process at home? Otherwise, what is the process to send it back for repair?
… except for the top one which has to go to /dev/mmcblk0boot0 and apparently has not been written there (as the log shows that the old content of /dev/mmcblk0boot0 still seems to be in place).
You can recover the device using
All you need is the serial console connected and a custom build of TF-A BL2.
Let me know if you need any help doing so.
maybe openwrt uses different offset for fip? or as far as i remember…daniel changed to fip in ubifs (not sure if for r3mini too), so flashing to existing partitions may not work.
what needs to be changed for bl2? is the img (with brom header) right here (looks like they use a bin file which should be bl2.bin)?
imho you need fip too to allow reflashing anything. i guess you need to set loadaddress to the fip-offset in bl2…am i right? readme says fip needs the download-mode support…many question marks for the binaries and options in my case
Needs more time than I have available right now, but I do at least see hope. I tried a few different combinations of stock/new/modified bl2/bl31.fip etc, baud, arch, with/wo fip, and all seemed to send fine, but none seemed to survive long enough to send anything back over tty after they JMP’d. I’m going to guess that Frank is right, and I need to be sending some subset of the actual bl2 file; I made some educated guesses based on the hexdump and the abundance of 0x00 and 0xff at the start, but I doubt I was right.
one example:
$ ./mtk_uartboot --aarch64 --brom-load-baudrate 115200 --bl2-load-baudrate 115200 --payload ../openwrt-mediatek-filogic-bananapi_bpi-r3-mini-snand-preloader.bin --fip ../openwrt-mediatek-filogic-bananapi_bpi-r3-mini-snand-bl31-uboot.fip
mtk_uartboot - 0.1.0
Using serial port: /dev/ttyUSB0
Handshake...
hw code: 0x7986
hw sub code: 0x8a00
hw ver: 0xca01
sw ver: 0x1
Baud rate set to 115200
sending payload to 0x201000...
Checksum: 0x154d
Setting baudrate back to 115200
Jumping to 0x201000 in aarch64...
Waiting for BL2. Message below:
==================================
==================================
Timeout waiting for specified message.
