Because I still did not manage to write the bootloader to flash so I have to use mtk_uartboot and it takes a while for putty to open so I can't catch the beginning of the log
At least in Windows, that is not possible, as the COM port can only be used by one application at a time. I would have to use some kind of third party port sniffer.
Try transfer the uboot.bin image via TFTP to RAM and from the address 0x???? (RAM) write a 4MB block to the beginning of the NAND flash drive.
I can't tell you the exact commands now. Try to figure it out yourself (it's not difficult).
I feel like there is an issue with the SPI communication between CPU and flash as whenever I try to write something to flash, no matter which address, I just get a bad block error.
Please choose the operation:
1: Load System code to SDRAM via TFTP.
2: Load System code then write to Flash via TFTP.
3: Boot System code via Flash (default).
4: Entr boot command line interface.
7: Load Boot Loader code then write to Flash via Serial.
9: Load Boot Loader code then write to Flash via TFTP.
You choosed 9
9: Load Boot Loader code then write to Flash via TFTP.
Warning!! Erase Boot Loader code in Flash then burn new one. Are you sure?(Y/N)
Please Input new ones /or Ctrl-C to discard
Input device IP (192.168.1.1) ==:
Input server IP (192.168.1.70) ==:
Input Uboot filename (u-boot_nand.img) ==:
switch prereq:0
Using ethernet0@15100000 device
TFTP from server 192.168.1.70; our IP address is 192.168.1.1
Filename 'u-boot_nand.img'.
Load address: 0x46000000
Loading: Got ARP REPLY, set eth addr (98:29:a6:9a:1e:df)
#################################################################
##
3.5 MiB/s
done
Bytes transferred = 970727 (ecfe7 hex)
## Checking hash(es) for FIT Image at 46000000 ...
Hash(es) for Image 0 (kernel-1): sha1+
Hash(es) for Image 1 (kernel-2): sha1+
ubi0: detaching mtd4
ubi0: mtd4 is detached
'spi-nand0' is now active device
Erasing from 0x0 to 0x3ffff, size 0x40000 ...
Bad block at 0x0 ... aborted
Writing from 0x0 to 0x3226f, size 0x32270 ...
Bad block at 0x0 ... aborted
Erasing from 0x180000 to 0x23ffff, size 0xc0000 ...
Succeeded
Writing from 0x180000 to 0x23a788, size 0xba789 ...
Succeeded
resetting ...
F0: 102B 0000
FA: 1040 0000
FA: 1040 0000 [0200]
F9: 0000 0000
L0: 8005 0000 [0001]
00: 1012 0000
F9: 0000 0000
L0: 8005 0000 [0001]
01: 102A 0001
02: 1012 0000
BP: 2000 00C0 [0001]
EC: 0000 0000 [1000]
T0: 0000 00B9 [010F]
System halt!
I might buy a new flash chip to test but I suspect there is some other hardware issue as the chip works just fine with an external programmer
Yes. It is very likely.
Apparently, you can't do without soldering here.
Maybe your device has already been repaired by an unskilled specialist and he only made it worse.
0 ... 0x40000 = 256k - BL2 image (not written, because the very first block is BAD)
0x180000 ... 0x240000 = 768k - BL3 (UBOOT) image (succesfully written)
I read that MTK chips can load the BL2 not only from the very first NAND block!
There are 3 more available addresses reserved for loading the bootloader.
UPD:
It is worth trying to write the BL2 image to addresses 0x40000, 0x80000 and 0xC0000.
This will take up exactly 1 MB, which is allocated for BL2 copies.
This operation must be done exactly as I indicated above: transfer the image to RAM, and from there to the required address in NAND.
This may be a silly question, but why is there no "factory" image for TUF AX4200 as there is for many other Asus routers? Initial installation is (mostly) quite easy that way on older Asus routers and works without complicated processes requiring 3rd party images (or alternatively minor hardware reworks).
Very often, to create a "factory" image, you need to write a special utility that converts standard images into specific ones (depending on the manufacturer).
All such utilities are presented here: https://github.com/openwrt/firmware-utils/tree/master/src
There was no such utility for new Asus routers, as Asus programmers changed the format of factory images.
I had to write such a utility myself (Nov 2023).
I immediately tried to add this utility to the official repository, but encountered a surprising misunderstanding: https://github.com/openwrt/firmware-utils/pull/19
And only recently this utility was added to the official repository. Therefore, there is a small probability that there will be official TRX-initramfs images.
Let me remind you that you can't do without an initramfs image, since the markups inside the UBIFS are incompatible. And therefore an intermediate step is required to bring the UBIFS to a working state.
Why do you think there is a small chance for official TRX-initramfs images?
If they added your utility to the official repo, would it not make sense to build official TRX-initramfs images for new users, this would be a win for everyone and the OpenWRT project.
It's very hard to get maintainers to do useful things.
Here's a simple example.
In October 2023, I reported this issue: Asus TUF AX4200 support - #198 by remittor
At the same time, I duplicated this error twice in the official repository (issues).
And this error is still present during building (this error is not critical).
I was thinking of something that could be written to flash using mtd-write (by connecting to the router by ssh), perhaps, not necessarily vendor firmware web UI. Sometimes of the time the two images are the same, tooling just different, although Asus appears to have their own trx format.
Hi everyone,
Does the bootloop problem still persist in 24.10.0-rc4?
It's strange that such an issue was not mentioned on the 24.10 and device pages (although it was mentioned for the Linksys E8450/Belkin 3200, for example).
