Crash on initramfs boot on the XX530v #1
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: airoha_en7523/builds#1
Reference in New Issue
Block a user
Hi!
I'm trying to use this initramfs to boot on my router to try to get a linux shell on this thing and dump the full firmware (it's a custom ISP Aginet version, better safe than sorry). As the wiki mentioned the hardware on this is the exact same other than the wifi chip, I imagined this would work, but the initramfs crashes on boot.
What are the wireless chips? Also, what is the ISP? Algar? Because @kvn193 has both devices and they are the same as the xx230v, only the wireless chips are different
If your xx530v is having the same problem, then we have a problem with the Ethernet driver. It's strange that I'm not having problems with the Ethernet driver on the xx230v or the Mikrotik hEX S 2025
@Guilherme-Bember-Duarte check with this file, check if you'll have the same problem
Hi! The ISP is indeed Algar (color me impressed! How did you guess?). I just tried "openwrt-airoha-an7523-tplink_ex530v_v1-initramfs-kernel.bin" from the latest release on this repo, I'll try that binary and give you feedback, one moment please. I will also test out the XX230v initramfs from the release again, maybe that crash was a fluke. I just noticed I didn't mention i was using the XX230v initram, sorry about that.
As for what wireless chip mine uses, no clue, I just know that's the only different piece of hardware from the XX230v because the wiki says so lol
sou brasileiro e o @kvn193 também, mas manteremos o inglêsSo the xx530v was merged into the xx230v because they are the same device, just with different wireless chips, and I also forgot to mention this on the Wiki, in addition to the Algar devices as well
Just
triestried out those builds, the one for the XX230v available on the releases still crashes, the same way as I reported at the start of this issue, not a fluke. The one you just sent here fails at the decompression of the kernel image "ERROR: new format image overwritten - must RESET the board to recover" and it just reboots to uboot again and goes to the stock firmware if not interrupted.What I don't understand is, do those builds work on off the shelf XX530v's and this weird errors just happen on ISP units? Or all tested XX530v were affected? I think there are some TP Link Archer routers based on the XX530v and XX230v, the difference being they don't have the GPON port, if memory serves me right it was the AX23 and AX53, they look the same from the pictures at least.
boot with this command:
tftpboot 0x86a00000 <file> && bootm 0x86a00000or change loadaddr to 0x86a00000 (
setenv loadaddr 0x86a00000 && saveenv)These are xPON devices, but one is an ax1800 (xx230v) and the other an ax3000 (xx530v v1). They are essentially the same device, only differing in their wireless chips, NAND, and RAM. The only difference is that the devices from the Algar ISP have more RAM (256MB -> 512MB) and the ART (
misc) has some differences, but maintains some offsets (MAC, wireless EEPROM, and PON BOB). They also have different firmware than the retail versionAnd if I'm not mistaken, the NAND memory is also model is different, but it maintains the same size as the xx230v and xx530v retail versions
Oh wow, they have more RAM and still manages to drop packets lol. The stock firmware is a joke, but it would be good practice to keep a backup of it. The EX530 initramfs maps the flash different than the stock, but I dumped all 6 partitions, 0 through 5, and concatenated 0 to 3 (3 seems to be just 4+5 stitched together), I think I got everything, or so I hope.
I'll try that other initramfs in a sec.
The original firmware is based about 80%~90% on the Airoha SDK, and most of the packets in the SDK don't even pass through the CPU. The new driver also has packet loss, but I don't know how much compared to the SDK because I've never been able to make that comparison. In this kernel pr (airoha_an7523/kernel#9) you can compare it with some tests we did during the Ethernet development.
With this old chainload I made for the xx230v, you can perform the dump via u-boot and then send the dump via
tftpput, which I included in the buildSorry for the wait, here's the log of that other initramfs that wasnt booting, now with the fixed address, fails anyway, but a filesystem issue now it seems.
By the way, that chainloaded u-boot worked perfectly, I managed to dump the whole
ramNAND and the result matches against whatever i came up with while using that initramfs with the wrong mappings, the resulting file is a complete 128MiB instead of 80 something Mib, the rest was just FF, but everything else matches perfectly. Many thanks!Not sure what to do with it, but I'm glad this worked out.
If the migration to the new uBoot fails, you have a backup that you can use to rewrite directly to the NAND using a programmer
I confirmed the same problem on the xx530v, I'll revert the SPI driver patches to see if that's the problem, because if it is, I'll have to remove them. There's also another device with the same issue
Alright! Any testing needed you can count on me!
I'll be doing some things outside of OpenWRT today, so I won't pay much attention to it right now, but I intend to revert the SPI patches to see if it goes back to normal
I just tested out the v60 build of the XX230v initramfs on my XX530v, boot still fails.
If you can rewrite the NAND, you can migrate to the new partition schema,
as it may be related to the MAC address
Since the UBI partition with the migrated art(misc) file is missing
Something in the kernel shouldn't have caused the boot process to freeze
like this
I'm using the ISP Firmware layout, so yeah, that might be the issue. Although I managed to boot the initramfs fine with v59 of the EX530v.
Here's the output of /proc/mtd from the original firmware.
And binwalk of the nand dump
And weirdly enough, the EX530v version still works on v60
The ex530v will be migrated to the new partition schema, as it is, it's in
the stock firmware layout we were using before needing to change u-boot
Ah, I misunderstood the situation, for some reason I was expecting it to be agnostic in relation to the installed system, even though it's the part that boots the installed OpenWRT system...
So all those issues are due to the mismatch of partition layout?
I'll see how feasible it is to install the proper OpenWRT layout and files while still being able to revert to the stock FW afterwards
Probably because it doesn't have the UBI partition, it tries to load the
MAC address and freezes the boot process. In theory, it should return a
random MAC address if the file system hasn't started, But that's not
happening, and it's working on the entire startup process
Just to confirm something. Is the current build of uboot functional and already tested on the XX530v? I really can't find an easy way to solder wires to the nand chip to recover it, if things go bad.....
And I also noticed the provided binary also overwrites some parts of other partitions, including the one where ART data is stored; Because my firware is not the stock one, how can I check if ART data is still preserved before pulling the trigger?
If you have the CH341, you can perform a memory dump using this clip with the type
WSON8/QFN8/DFN88x6furthermore, if you haven't written anything to the NAND, it remains intact without any modifications.
the u-boot is functional at the moment; I already replaced it on my XX230V, but I still have some things to finish. You can replace the stock u-boot, but I don't recommend doing that until I declare some things stable. However, migrating the u-boot will be mandatory in the future.
That's why I asked you to dump the NAND using u-boot chain, so that if you lose the boot structure you can revert it. But I also recommend doing the dump using CH341 and then checking if the data matches to avoid writing anything corrupted to the NAND, especially the ART (misc).
During my tests, replacing the u-boot required me to rewrite it several times and then migrate the ART to the new ubi layout. This is why I recommend dumping the NAND before flashing anything. In terms of stability, it's somewhat acceptable, but we still don't have packet acceleration on the wireless, and we won't have xPON until we have a good driver for it
Ah, right. I think I'll hold this off for a while then.
And by re writing several times, do you mean re-flashing the same version or a bunch of try and error from different versions? Because my only way of flashing is through UART, and if the bootloader gets borked somehow, I'm not sure I can solder leads to reprogram the chip.
Edit: I didn't see the earlier message, I'll see what I can do in relation to the clamp, hardware flashing and direct dumping.
Thanks again!
In my tests, when I tried to update uboot to a new build, it would kill the initialization and give me some ATF errors. However, if I update using the stock uboot, it works fine. That's why I'm not yet recommending replacing uboot with the openwrt version until I fix this, and it will still take some time, we still have a lot to do on this platform
We'll continue the rest of the conversation in another issue: airoha_en7523/openwrt#7