First of all you need to connect RX to TX and TX to RX, so data can pass. Also make sure to turn off flow control (both RTS/CTS and XON/XOFF).
And most important: This is NOT RS-232!!! It’s a 3.3V TTL-level UART. So make sure to use a serial adapter which matches this low signal voltage, otherwise you will ruin the board.
Aaand we’ve got data! This was the most valuable thing I learned today. Thanks @dangowrt 
I thankfully managed to ordered a full BPI.R3 kit with case and an USB to TTL dongle. About writing to NOR, do you happen to know if it possible to write from NAND to NOR. I find it quite useful to have a backup if that is possible to mirror.
you cannot write from nand to nor as you can only select 1 SPI device (like mmc either sd or emmc). but of course you can bootup from a mmc-device backup nand to a file, powerdown, switch to nor and write backup to nor…if size is enough (i guess openwrt is smaller than 32MB)…nor is smaller than nand (32M vs. 128M) and booting from it requires different boot-chain.
Thanks @frank-w. I checked the memory usage before starting this journey. OpenWRT + all packages should consume less than the 32 MB of NOR memory and I should still ahve plenty of space left. I currently use OpenWRT on a +10 years old NetGear with less than half the NOR capacity.
Do you know a tutorial or docs with instructions on how to backup one boot medium to a file and recover to another one?
imho it makes more sense to use nand/nor as recovery (and so bootable) and have complete system only on sd/emmc + data on m.2 nvme…but i know daniel has other preferences…backing up nand to nor “as is” makes not much sense to me if not bootable
Yes, you are right, 32 MB of NOR is plenty and more than enough for all the usual tasks of a router, and even enough to also store another image with initramfs for recovery, so you don’t even need to touch any other storage device for that. All bootable storage options have enough space for a recovery image as well as production firmware.
I wrote a summary about the different storage options available here:
If you still want to use different storage for backup, you can use the SD card to install the same bootloader and firmware images to both, NAND and NOR flash, depending on the position of the dip switches. You can then regularly backup your configuration and restore it on the image booted from another storage option.
I will first attempt, but also to familiarize properly with BananaPi, to restore the damage I did to the installation in NOR.
SF: Detected w25q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB
Reading from 0x180000 to 0x46000000, size 0x100 ... OK
Reading from 0x180000 to 0x46000000, size 0x1000 ... OK
## Loading kernel from FIT Image at 46000000 ...
Using 'config-mt7986a-bananapi-bpi-r3' configuration
Trying 'kernel-1' kernel subimage
Description: ARM64 OpenWrt Linux-5.15.94
Type: Kernel Image
Compression: gzip compressed
Data Start: 0x46001000
Data Size: 5361746 Bytes = 5.1 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x44000000
Entry Point: 0x44000000
Hash algo: crc32
Hash value: fdb1b69e
Hash algo: sha1
Hash value: 8ea26aafb64c66688584f5035ad676ae53a48cf5
Verifying Hash Integrity ... crc32 error!
Bad hash value for 'hash@1' hash node in 'kernel-1' image node
Bad Data Hash
ERROR: can't get kernel image!
When booting from SD and selecting “7. Install bootloader, recovery and production to NOR.” I get:
jedec_spi_nor spi_nor@0: unrecognized JEDEC id bytes: ff, ef, aa
Failed to initialize SPI flash at 0:0 (error 0)
NOR not detected
Press ENTER to return to menu
I assume this is because I boot from SD but that would make little sense for me at present. If there would be an option to backup from NAND and overwrite NOR, that certainly would be a sustainable approach since I kill three birds with one stone (learn to backuo & restore + fix NOR).
Any advice or source I could use to work things through is highly appreciated.
This is a quite clear indicator that the dip switch C selecting other NAND or NOR flash is in the position selecting the NAND flash. Make sure switch C is in position 0 before trying to install to NOR flash.
Argh … i thought dip C is ignored when booting form SD as indicated here:
https://wiki.banana-pi.org/Getting_Started_with_BPI-R3
Anyways, that let me proceed. Though, restoring NOR and rebooting still results in the system getting stuck.
Certainly my mistake and I don’t want to waste you your Friday evening with rookie stuff like mine. The post you shared before about installation of the latest OpenWRT works from within a running system. Do you happen to know the steps or a link to a documentation which would help me with the installation via UART?
Well, that’s true when it comes to booting. But it still selects the active device, which is then the only accessible one. You can only access either SPI-NAND or SPI-NOR at the same time, depending on the position of switch C. The same applies to eMMC vs. microSD card which is controlled by switch D.
There isn’t much more to it than selecting the right item in the boot menu and waiting long enough. At least that has always worked for me. If it doesn’t it sounds more like you are stumbling upon a bug. Maybe some timeout hits us here before writing completed?
Interesting detail about the jumpers. Wonder how you obtained that kind of tribal knowledge as it’s very very specific. Respect!
About the halted boot sequence, I start to feel the same but I might have a suspicion. When I booted the last time successfully I used your command to set the bootcmd
fw_setenv bootcmd "run nor_init ; env default bootcmd ; saveenv ; reset"
reboot
But then decided, as on second thought a few questions came up, to “revert” by typing:
fw_setenv bootcmd
If that is not the cause, then I’d say yes … we found a possible bug.
PS: Booting with NAND works like a charm. I also completely erased the SD and burnt the image again.
In v1.0 the last 2 switches are labeled nand/nor and sd/emmc…and it is written down in shematics 
Apparently, those who can read, are at an advantage … silly me. The boot was successful, though, and falsely made the impression it came to a halt. The message “Please press Enter to activate this console.” was not displayed.
I will continue tomorrow with a fresh head. Thanks guys for your support!
PS: Restore and booting into of NOR was also successful. I will continue tomorrow with trying to figure how to connect the router to the internet to install packages.
Something is not quite right with the latest snapshot respectively when installing packages. I installed the latest OpenWrt Snapshot into NOR via " 7. Install bootloader, recovery and production to NOR." from:
https://downloads.openwrt.org/snapshots/targets/mediatek/filogic/
Then I proceeded installing some basic packages for luci interface and USB Support:
opkg update && opkg install luci luci-ssl block-mount e2fsprogs kmod-fs-ext4 kmod-usb-storage kmod-usb2 kmod-usb3
However, after reboot I just get:
F0: 102B 0000
FA: 5100 0000
FA: 5100 0000 [0200]
F9: 103F 0000
F3: 1001 0000 [0200]
F3: 1001 0000
F6: 102C 0000
F5: 1026 0000
00: 1005 0000
FA: 5100 0000
FA: 5100 0000 [0200]
F9: 103F 0000
F3: 1001 0000 [0200]
F3: 1001 0000
F6: 102C 0000
01: 102A 0001
02: 1005 0000
BP: 2000 00C0 [0001]
EC: 0000 0000 [0000]
T0: 0000 00DC [010F]
System halt!
F0: 102B 0000
FA: 5100 0000
FA: 5100 0000 [0200]
F9: 103F 0000
F3: 1001 0000 [0200]
F3: 1001 0000
F6: 102C 0000
F5: 1026 0000
00: 1005 0000
FA: 5100 0000
FA: 5100 0000 [0200]
F9: 103F 0000
F3: 1001 0000 [0200]
F3: 1001 0000
F6: 102C 0000
01: 102A 0001
02: 1005 0000
BP: 2000 00C0 [0001]
EC: 0000 0000 [0000]
T0: 0000 00DC [010F]
System halt!
F0: 102B 0000
FA: 5100 0000
FA: 5100 0000 [0200]
F9: 103F 0000
F3: 1001 0000 [0200]
F3: 1001 0000
F6: 102C 0000
F5: 1026 0000
00: 1005 0000
FA: 5100 0000
FA: 5100 0000 [0200]
F9: 103F 0000
F3: 1001 0000 [0200]
F3: 1001 0000
F6: 102C 0000
01: 102A 0001
02: 1005 0000
BP: 2000 00C0 [0001]
EC: 0000 0000 [0000]
T0: 0000 00DC [010F]
System halt!
Any idea?
Seems this install function does not install the right bl2 to nor
Have you booted the nor before installing the additional packages?
Yes, I booted NOR before installation. I have now, since I familiarized more with the issue around not saved settings and the “overlay” system more (this article helped), started to:
Quite a steep learning curve as I formerly just flashed the OpenWRT firmware via GUI. Despite not being a shell rookie, there are still quite some interesting things to catch up to.
Update That is quite frustrating. Burning the image on the SD card creates many partitions which seems nowhere to be explained. The errors thrown cause more confusion.
root@OpenWrt:/# lsblk -o PATH,SIZE,PARTUUID
PATH SIZE PARTUUID
/dev/mtdblock0 20M
/dev/mtdblock1 9.9M
/dev/mtdblock2 10.5M
/dev/mtdblock3 512K
/dev/mtdblock4 512K
/dev/mtdblock5 256K
/dev/mtdblock6 256K
/dev/mmcblk0 238.3G
/dev/mmcblk0p1 4M 5452574f-2211-4433-5566-778899aabb01
/dev/mmcblk0p2 512K 5452574f-2211-4433-5566-778899aabb02
/dev/mmcblk0p3 2M 5452574f-2211-4433-5566-778899aabb03
/dev/mmcblk0p4 4M 5452574f-2211-4433-5566-778899aabb04
/dev/mmcblk0p5 32M 5452574f-2211-4433-5566-778899aabb05
/dev/mmcblk0p6 20M 5452574f-2211-4433-5566-778899aabb06
/dev/mmcblk0p7 104M 5452574f-2211-4433-5566-778899aabb07
/dev/mtdblock0p1 4.8M
/dev/mmcblk0p65 4.8M
/dev/mmcblk0p66 93.9M
root@OpenWrt:/# echo fix | parted -l ---pretend-input-tty
Error: /dev/mtdblock6: unrecognised disk label
Model: Unknown (unknown)
Disk /dev/mtdblock6: 262kB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
Error: /dev/mtdblock4: unrecognised disk label
Model: Unknown (unknown)
Disk /dev/mtdblock4: 524kB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used.
OK/Cancel? fix
parted: invalid token: fix
OK/Cancel? Warning: Not all of the space available to /dev/mmcblk0 appears to be used, you can fix the GPT to use all of the space (an extra 499400671 blocks) or continue with the current setting?
Fix/Ignore? Model: SD SC256 (sd/mmc)
Disk /dev/mmcblk0: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 17.4kB 4194kB 4177kB bl2 hidden, legacy_boot
2 4194kB 4719kB 524kB ubootenv hidden
3 4719kB 6816kB 2097kB factory hidden
4 6816kB 11.0MB 4194kB fip boot, hidden, esp
5 12.6MB 46.1MB 33.6MB recovery boot, hidden, esp
6 46.1MB 67.1MB 21.0MB install boot, hidden, esp
7 67.1MB 176MB 109MB production
I then used this approach to expand the partition named “production” as anything else would cause an overlap but that threw another error.
parted -s /dev/mmcblk0p7 resizepart 2 100%
Error: /dev/mmcblk0p7: unrecognised disk label
Why can’t this as normal as setting up like any other OS via terminal when partitions are created? Suing a USB drive as extroot make this. I start to believe I need a totally different approach burning the image. I currently use balanaEtcher …
Anyone got any thoughts on this?
Your parted command shows a partition name
bl2 is second stage bootloader after bootrom, ubootenv is for storing environment of uboot,factory is openwrt specific,fip is uboot itself (with bl3x atf),recovery is openwrt specific, install same and production is working system
I used the official OpenWRT tutorial that uses the dev-path. Another one for SD cards, the section about ext4 image, doesn’t work or is incomplete but the actual command points to x86. Not to speak about the grub file i cannot locate in case of UUID changes.
Embedded systems (arm,arm64) normally use uboot instead of grub
For resizing rootfs daniel wrote some tutorials i have linked in my wiki
Thanks @frank-w. What bugs and likely hinders me to succeed is that the partitions on the SD cart seems to have no properly file system and the many partitions are nowhere explained. Though, @VA1DER posted about this:
I get:
resize2fs /dev/mmcblk0p5
resize2fs 1.47.0 (5-Feb-2023)
resize2fs: Bad magic number in super-block while trying to open /dev/mmcblk0p5
Couldn't find valid filesystem superblock.
Is my approach using balanaEtcher maybe less desirable?