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 |................|
*
00010000or 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