Open eNBeWe opened 2 weeks ago
After booting Module 2 the web interface is broken
Partition data:
# cat /proc/mtd
dev: size erasesize name
mtd0: 01000000 00010000 "ALL"
mtd1: 00030000 00010000 "Bootloader"
mtd2: 00010000 00010000 "Config"
mtd3: 00010000 00010000 "Factory"
mtd4: 00200000 00010000 "bkKernel"
mtd5: 0012027d 00010000 "Kernel"
mtd6: 00a0fd83 00010000 "RootFS"
mtd7: 00b30000 00010000 "Kernel_RootFS"
mtd8: 00080000 00010000 "user"
mtd9: 00200000 00010000 "user2"
Board 1
Even after soldering to the trace on the board I can't get any serial output from the module. I THINK I should get data, but there seems to be nothing ...
There is no obvious difference between the two boards (and also my board: https://github.com/hn/linkplay-a31/blob/main/linkplay-a31-pcb-front.jpg).
I think you fried board 1 somehow, maybe one can check later to revive it.
Board 2 has the same CPU (even the same revision) as mine:
THIS IS ASIC
Linux version 2.6.36+ (wiimu@wiimu-build-1) (gcc version 3.4.2) #1 Sun Feb 5 10:24:56 CST 2017
The CPU feqenuce set to 575 MHz
MIPS CPU sleep mode enabled.
CPU revision is: 00019655 (MIPS 24Kc)
The flash chip is the same as well.
The module should be compatible with this project. The (slight) difference in the partition table does not matter.
You need to get into the bootloader which looks like this
U-Boot 1.1.3 (Feb 5 2017 - 10:24:17)
Board: Ralink APSoC DRAM: 64 MB
relocate_code Pointer at: 83fb4000
******************************
Software System Reset Occurred
******************************
flash manufacture id: ef, device id 40 18
find flash: W25Q128BV
TOTAL_FLASH_SIZE: 16 MBytes
*** Warning - bad CRC, using default environment
============================================
Ralink UBoot Version: 4.3.0.0
--------------------------------------------
ASIC 7628_MP (Port5<->None)
DRAM component: 512 Mbits DDR, width 16
DRAM bus: 16 bit
Total memory: 64 MBytes
Flash component: SPI Flash
[...]
Please choose the operation:
0: Boot system code via Flash (default).
1: Entr boot command line interface.
2: Load Boot Loader code then write to Flash via TFTP.
3: Load backup system code then write to Flash via TFTP.
4: Load system code then write to Flash via TFTP.
5: Load system code to SDRAM via TFTP.
6: Load user1 code then write to Flash via TFTP.
7: Load user2 code then write to Flash via TFTP.
Check:
printenv
(shows U-Boot args) from within the running vendor systemThe board 1 boots fine and works without issue with the default firmware. Just the serial won't play ball.
I tried all usual baud rates with board 2 without any result. I can see that the console output takes some time until it starts, so I guess u-boot is doing something. I will try printenv next.
Edit: There is no printenv
in the image available
mtd2
. Try cat /dev/mtdblock2 > /tmp/mtd2.bin
and look for strings (probably starting at 0x2000 within the (binary) file). But that probably won't help much. It seems they locked down U-Boot. Hrmmm.mtd1
(U-Boot binary), e.g. baudrate
.I just tried pin 24/25 but there is nothing interesting there, just some strings that look like some internal protocol
Currently I am a bit stuck trying to get the partition data off the device. I can cat
the partitions to tmp but I don't have a good way to get these files out for analysis.
Just a thought ... Could I flash the software through mtd from the running system?
but I don't have a good way to get these files out for analysis.
Configure WiFi and use curl (LD_LIBRARY_PATH=/system/workdir/lib /system/workdir/bin/curl --upload-file
in this case).
Since there is no uuencode/base64 on the system, the only other (painful) way would be something like this.
Just a thought ... Could I flash the software through mtd from the running system?
It probably should work (mtd_write
to mtd7
, see /system/workdir/script/burnrootImage.sh
). If anything goes wrong, your're lost. Better try and think about other options before doing that.
Module 2: If you have access to an oscilloscope or logic analyzer, I would double-check again if any level change occurs on the serial TX pin before the kernel starts. An ESP8266 can also be used as a cheap replacement
Module 1: If you have access to a microscope and probe needles you might check for serial activity directly at the MT7688 UART pins.
New findings: Module 1 is actually a different chip. It seems to be a MT7628Nn, not a MT7688. At least that is what the package marking says under the sticker. With my equipment I can't reliably probe the chip precisely enough.
Module 2 shows no activity on the TX pin before the linux kernel log (at least nothing shown on the oscilloscope).
I flashed, I rebooted, I bricked ... I tried the image on module 2. Now it looks like I am stuck in the bootloader that I can't access. No serial output on the console and no wifi rescue point coming up. Well, I bought it so I can test stuff with it without breaking the "working" module 1.
Module 1: If I remember correctly, these MCUs are pin- and software-compatible and differ only in WiFi capabilites:
The difference between MT7688 and MT7628: MT7688 WIFI 2.4G bgn theoretical maximum rate 150Mbps 1T1R single antenna mode MT7628 WIFI 2.4G bgn theoretical maximum rate 300Mbps 2T2R dual antenna mode
Module 2: What MCU label is under the sticker? The SPI-NOR flash probably can be read/flashed with a SOIC-8 clip (similiar to https://github.com/hn/linkplay-a31/tree/main?tab=readme-ov-file#series-2-cap806405-amplifier-board). You might be able to restore the backup of partition mtd7 (you made a backup, right?) this way. I wonder why module 2 does not boot the OpenWrt firmware (assuming you flashed it successfully). Maybe the obscure bootloader does some extra checksumming or some other magic.
Module 2 is a MT7688AN. I might have just YOLOed it without taking a backup before. The mtd_write at least went through to 100%, so my guess would be, that it flashed.
I went through the datasheet and there doesn't seem to be a way to configure the behavior of UART0 through some of the other pins. I kind of suspected the carrier-board to do something weird, so the bootloader won't output. But I don't see any plausible pin that could cause that.
I could have checked the registers of the MCU for UART0_MODE, but since it works later in the process, I don't see how that could have changed anything.
Module 2: U-Boot output has been silenced in code (they have intentionally removed the call to the initialization function for UART0). You can work around this by changing bytes c400
to 5c01
at offset 0x1190
of your mtd1.bin
. This is just a dirty fix (it changes an offset to a jump table), but it works:
U-Boot 1.1.3 (Sep 25 2019 - 16:59:36)
Board: Ralink APSoC DRAM: 256 MB
relocate_code Pointer at: 8ffb4000
flash manufacture id: 0, device id 0 0
Warning: un-recognized chip ID, please update bootloader!
TOTAL_FLASH_SIZE: 4 MBytes
*** Warning - bad CRC, using default environment
============================================
Ralink UBoot Version: 4.3.0.0
--------------------------------------------
ASIC 7628_MP (Port5<->None)
DRAM component: 512 Mbits DDR, width 16
DRAM bus: 16 bit
Total memory: 64 MBytes
Flash component: SPI Flash
Date:Sep 25 2019 Time:16:59:36
============================================
(this is your mtd1.bin
running in an emulator)
Can I do that change through writing to the memory chip with a SOIC-8 clip? I bought one, but never used it. Can you walk me through that or should I just google it? ;)
You'll find lots of howtos on the web with helpful pictures. In the end it comes down to something like this:
After some probing around (and learning how to use a RasPi for SPI interface) I was able to write a new rom (and read the "original" rom before).
I read the written data back and it matched the patched image.
Sadly, I STILL don't get U-Boot to speak to me.
That's strange. Can you please check (e.g. with a scope) that there is really 'nothing' -- maybe the baud rate is wrong, I would not see that in the emulator.
I have two Linkplay A31 modules that differ in their behaviour. I try to document these modules here and maybe get some more info in the process.
Module 1 - Originally installed on Arylic Up2Stream Amp 2.1
(https://www.arylic.com/products/up2stream-amp-2-1-amp-board)
Module 2 - Sourced through AliExpress