Need a copy content of full-flash about uap-ac-m

I installed openwrt on uap-ac-m successfully。but after that,I only made a backup of u-boot and eeprom from openwrt web interface,then I replaced the right u-boot to a wrong u-boot which changed other mtdblock content in the flash。Could anyone do me a favor that send me a copy content of the full flash or the specified mtdblock files like u-boot-env,bs,cfg,etc? My email is suhongchao@163.com

could anyone do me a favor

Is this the exact device/firmware you used:
https://downloads.openwrt.org/releases/21.02.5/targets/ath79/generic/openwrt-21.02.5-ath79-generic-ubnt_unifiac-mesh-squashfs-sysupgrade.bin

I used openwrt-22.03.1-ath79-generic-ubnt_unifiac-mesh-squashfs-sysupgrade.bin

Ok so this familiy of devices.

Where does it stop during boot, can you still access tftprecovery / or bootloader with serial or external flash programmer as in how do you plan to restore the mtd partitions?

the wrong u-boot changed other mtdblocks,that makes serial echo error and tftprecovery is failed. only u-boot and eeprom are right.so I plan to use a flash programmer to fix this.The simplest way is that I get a total flash contents and program it to the flash,then replace the eeprom to my own.If you could do me a favor, you can login the openwrt on uap-ac-m and then go to the webpage :system-backup and flash firmware - Save mtdblock contents,and download all the mtdblocks ,then send to me ,that's all

Can you TFTP recover to a stock image? TFTP recovery only works with Ubiquiti stock images because it checks the image signature.

While stock is running, doing a fwupdate to another stock image will replace the bootloader with the one that is part of the new image.

u-boot-env had been changed,ath and serial are all failed and the device cant be in tftp recovery mode.I don't know if it can be fixed only by programing a right u-boot-env mtdblock。so I thought it maybe the simplest way to change the whole content of the flash,because it's not necessary to consider the firmware and version of the backup content from other devices.And there are only u-boot and kernel mtdblocks in the firmwares which I can find.The mtdblocks of u-boot-env,bs,cfg,eeprom only can be find in the device

Could you do me the favor

As you noted, the bootloader is easily cut out of the factory release bin.

The uboot-env is this:

00000000  5c c3 d6 11 62 6f 6f 74  61 72 67 73 3d 63 6f 6e  |\...bootargs=con|
00000010  73 6f 6c 65 3d 74 74 79  30 20 70 61 6e 69 63 3d  |sole=tty0 panic=|
00000020  33 00 62 6f 6f 74 63 6d  64 3d 72 75 6e 20 75 62  |3.bootcmd=run ub|
00000030  6e 74 61 70 70 69 6e 69  74 3b 20 67 6f 20 24 75  |ntappinit; go $u|
00000040  62 6e 74 61 64 64 72 20  75 62 6e 74 62 6f 6f 74  |bntaddr ubntboot|
00000050  3b 62 6f 6f 74 6d 20 24  66 6c 61 73 68 5f 62 6f  |;bootm $flash_bo|
00000060  6f 74 5f 61 64 64 72 00  62 6f 6f 74 64 65 6c 61  |ot_addr.bootdela|
00000070  79 3d 32 00 62 61 75 64  72 61 74 65 3d 31 31 35  |y=2.baudrate=115|
00000080  32 30 30 00 65 74 68 61  64 64 72 3d 30 78 30 30  |200.ethaddr=0x00|
00000090  3a 30 78 61 61 3a 30 78  62 62 3a 30 78 63 63 3a  |:0xaa:0xbb:0xcc:|
000000a0  30 78 64 64 3a 30 78 65  65 00 69 70 61 64 64 72  |0xdd:0xee.ipaddr|
000000b0  3d 31 39 32 2e 31 36 38  2e 31 2e 32 30 00 73 65  |=192.168.1.20.se|
000000c0  72 76 65 72 69 70 3d 31  39 32 2e 31 36 38 2e 31  |rverip=192.168.1|
000000d0  2e 32 35 34 00 75 62 6e  74 61 70 70 69 6e 69 74  |.254.ubntappinit|
000000e0  3d 67 6f 20 24 7b 75 62  6e 74 61 64 64 72 7d 20  |=go ${ubntaddr} |
000000f0  75 61 70 70 69 6e 69 74  3b 67 6f 20 24 7b 75 62  |uappinit;go ${ub|
00000100  6e 74 61 64 64 72 7d 20  75 72 65 73 65 74 5f 62  |ntaddr} ureset_b|
00000110  75 74 74 6f 6e 3b 75 72  65 73 63 75 65 3b 67 6f  |utton;urescue;go|
00000120  20 24 7b 75 62 6e 74 61  64 64 72 7d 20 75 77 72  | ${ubntaddr} uwr|
00000130  69 74 65 00 6d 74 64 70  61 72 74 73 3d 6d 74 64  |ite.mtdparts=mtd|
00000140  70 61 72 74 73 3d 61 74  68 2d 6e 6f 72 30 3a 33  |parts=ath-nor0:3|
00000150  38 34 6b 28 75 2d 62 6f  6f 74 29 2c 36 34 6b 28  |84k(u-boot),64k(|
00000160  75 2d 62 6f 6f 74 2d 65  6e 76 29 2c 37 37 34 34  |u-boot-env),7744|
00000170  6b 28 6b 65 72 6e 65 6c  30 29 2c 37 37 34 34 6b  |k(kernel0),7744k|
00000180  28 6b 65 72 6e 65 6c 31  29 2c 31 32 38 6b 28 62  |(kernel1),128k(b|
00000190  73 29 2c 32 35 36 6b 28  63 66 67 29 2c 36 34 6b  |s),256k(cfg),64k|
000001a0  28 45 45 50 52 4f 4d 29  00 00 00 00 00 00 00 00  |(EEPROM)........|
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00010000

or the above first 512 bytes of mtd1 (u-boot-env) in base64, the rest of the 64k space is zeros:

XMPWEWJvb3RhcmdzPWNvbnNvbGU9dHR5MCBwYW5pYz0zAGJvb3RjbWQ9cnVuIHVibnRhcHBpbml0
OyBnbyAkdWJudGFkZHIgdWJudGJvb3Q7Ym9vdG0gJGZsYXNoX2Jvb3RfYWRkcgBib290ZGVsYXk9
MgBiYXVkcmF0ZT0xMTUyMDAAZXRoYWRkcj0weDAwOjB4YWE6MHhiYjoweGNjOjB4ZGQ6MHhlZQBp
cGFkZHI9MTkyLjE2OC4xLjIwAHNlcnZlcmlwPTE5Mi4xNjguMS4yNTQAdWJudGFwcGluaXQ9Z28g
JHt1Ym50YWRkcn0gdWFwcGluaXQ7Z28gJHt1Ym50YWRkcn0gdXJlc2V0X2J1dHRvbjt1cmVzY3Vl
O2dvICR7dWJudGFkZHJ9IHV3cml0ZQBtdGRwYXJ0cz1tdGRwYXJ0cz1hdGgtbm9yMDozODRrKHUt
Ym9vdCksNjRrKHUtYm9vdC1lbnYpLDc3NDRrKGtlcm5lbDApLDc3NDRrKGtlcm5lbDEpLDEyOGso
YnMpLDI1NmsoY2ZnKSw2NGsoRUVQUk9NKQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=

The bs partition (mtd7) is this:

00000000 00 00 00 00 a3 4d e8 2b 00 00 00 00 00 00 00 00 |.....M.+........| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00020000
or in base64

AAAAAKNN6CsAAAAAAAAAAA==

I don't know what the significance of the 4 bytes are or if they are unit specific. The known use of the bs partition is if the first byte is 0x80 instead of 0, the second firmware partition will be booted.

On my unit the 'cfg' partition is blank (all 0xFF). It would only be used by stock firmware in any case.

And the eeprom is unit specific you must use the data that was loaded at the factory for proper radio operation.

I tried and failed.serial echo "ubnt app magic mismatch "at the end of starting.it may be cause of the mismatched version between my uboot and your u-boot-env,or it may check the uboot-env and eeprom whether belongs to one device,could i got u-boot and eeprom mtdblocks from you?

serial echo "ubnt app magic mismatch,starting application at 0x00000000 "at the end of starting.I think the address should be higher like 0x9fxxxxxx,or 0x87xxxxxx,etc.It seems that the uboot I backup from my device and BZ.qca956x.v3.7.58.6385.170508.0957.bin are both wrong.

could i get your uboot and eeprom?

They are the same for most (all?) Unifi devices. The endianness varies. The partitiion size and whether it is filled with zero bytes also seems to vary. But that doesn't matter since only the first 8 bytes are read or written.

Actually I believe that's a 1. And maybe this is the reason for the magic code - to detect the endianness?

My AP AC Pro's look like your AP AC Mesh:

00000000  00 00 00 00 a3 4d e8 2b  00 00 00 00 00 00 00 00  |.....M.+........|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00020000

and as you noted, when configured to boot from kernel1 thiis looks like

00000000  80 00 00 00 a3 4d e8 2b  00 00 00 00 00 00 00 00  |.....M.+........|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00020000

(Taken from my documentation of the issue a few years ago. Completely outdated now since the installation instructions have been updated, but for reference:[SOLVED] Ubnt Unifi AC Pro partition problems - "kernel0" vs "kernel1" )

The 6 Lite's have opposite byte order, smaller partition and no zero byte padding:

00000000  00 00 00 00 2b e8 4d a3  ff ff ff ff ff ff ff ff  |....+.M.........|
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00010000

I haven't tried to let the OEM firmware configure them for "kernel1" so I don't actually how it will look. But I would not be surprised if the first for bytes were "00 00 00 01".

Doesn't matter to OpenWrt of course, as long as we don't supports dual partitions. Writing 4 zero bytes to the start of the "bs" partition will always DTRT, and is now part if the installation instructions.

I had known about all the content in https://openwrt.org/toh/ubiquiti/unifiac before flashing OEM firmware to openwrt.and tried to combine uboot and eeprom backups 、the mtdblocks which mk24 gave to me 、the uboot and firmware mtdblocks from OEM firmware and openwrt dozens of times.But it is no use.it seems that the uboot check someting mismatched and refuse to work.It may be cause of serious hexes or mtdblocks not from same device.what I confirmed is it has nothing with u-boot-env,bs,cfg,they are same in the same model devices