Changed the 1st part of the installation instruction into tabs, one for ssh install, one for serial install.
Hope it makes stuff more readable.
4 Likes
It rather bothers me that we don't have a way to use both firmware slots on this.
Does anyone have a list of what's been tried or where we think the interface to that system lies?
Or is it functionally impossible without a way to replace the signed U-Boot since we have to use a bootcmd with the partition hardcoded? (I imagine that's the main issue... I saw the alternate set of uboot configs with a manual bootcounter, but I'd be worried about wearing a bad block into the uboot config if I'm unlucky.)
If you think it's possible I can try to look into it.
I was also seeing what feel like a worrying number of people complaining on these forums about Wi-Fi memory leaks and crashing - is this unstable or was that people testing a beta software? The "new" Wi-Fi capabilities are something I don't know much about yet.
I think that's mostly in the "NSS" thread, which is for enabling the network accelerator hardware, which is needed to get speeds over about 800 Mbps. The NSS builds are starting to come together now and becoming a lot more stable.
I think it would be very helpful to add a warning to "option A" that it is incredibly finnicky and only works if the planets are in perfect alignment. Seems to need the right combination of a USB drive that the bootloader "likes" (possibly excludes USB3?), and being formatted exactly "right", which isn't as simple as msdos partition table + fat32, i.e., only works when formatted with the right tool.
In particular, "option B" w/TFTP seems to be the only really dependable option.
Actually, given the number of people having flashed this router, and the small amount of USB drive complaints, I think that the USB approach A works pretty well.
The other option B requires opening the device and attaching a serial connection, and the connector in the router is abnormally small...
5 Likes
if anything we should probably just keep a record of known bad/known good drives
for instance, i can't get it to recognize my samsung fit right now even with a 4gb fat16 partition and nothing else on the drive. No clue why.
okay i guess my custom initramfs was just bad
My Belkin RT3200 with openwrt is dead after a transient hiccup of the electric grid. I purchased the DL-WRX36 from Amazon, finally got Openwrt 23.05.02 installed on it yesterday. Below are a few points IMHO that are worth being mentioned during my installation process.
Part 1:
- Copy the initramfs image to a FAT32-formatted flash drive and connect it to device USB port.
Pay attention to the FAT32 format. I used 3 different brands of USB drives all formated under Fedora Linux:
sudo mkfs.vfat -F 32 /dev/sda
DL-WRX36 failed to boot with the initramfs image on all 3 USB flash drives, it just boot into OEM firmware (of course with the admint/askeyt1234 SSH enabled). Formatting the same USB flash drive under windows and copy the initramfs file over. Yep, DL-WRX36 boot into it successfully.
Part 2:
- WinSCP & scp now defaults to the SFTP protocol, switch to SCP to transfer the factory image over to the router.
- The default LAN IP of the booted initramfs is 192.168.1.1.
- If you're unable to connect to 192.168.1.1, the initramfs boot have failed, and the router's still running the Dynalink firmware.
This part is not clear to me, especially in the case of boot failure of initramfs on the USB flash drive. I would it to something like:
- After reboot of DL-WRX36, make sure that it successfully booted into the initramfs image on the USB drive. If success DL-WRX36 can be pinged at IP address
192.168.1.1, otherwise DL-WRX36 still boot into OEM firmware and can be pinged at IP address192.168.216.1.
- Connect to device using SSH (on a LAN port)
Adding the command line explicitly here will be helpful. Otherwise some users will get confused here with the previous login/password admin/askey1234.
ssh root@192.168.1.1
Password is empty.
Overall, I have no other problems following the installation insturctions.
3 Likes
Hello, and thanks for all the great info and work on this router!
I'm running stable 23.05.2 by following the guide and I've set up the USB recovery options:
fw_setenv bootcmd 'run openwrtusb; run openwrtboot'
fw_setenv openwrtboot 'setenv bootargs console=ttyMSM0,115200n8 ubi.mtd=rootfs rootfstype=squashfs rootwait; ubi part fs; ubi read 0x44000000 kernel; bootm 0x44000000#config@rt5010w-d350-rev0'
fw_setenv openwrtusb 'usb start && fatload usb 0:1 0x44000000 openwrt-ipq807x-generic-dynalink_dl-wrx36-initramfs-uImage.itb && bootm 0x44000000'
Can I use a usb and configure extroot or overlay with these settings with a separate USB drive without the .ubi file on it to increase my system memory?
I am a bit confused at my routers storage overview
I thought this router had 256MB of storage, but I can configure a usb with extroot to expand that if not.
Thanks in advance!
failure to connect to 192.168.1.1 via ssh would imply the same thing ?
not really, since there's a myriad of applications offering ssh connectivity.
and as @hnyman wrote at Dynalink DL-WRX36 Askey RT5010W IPQ8072A technical discussion - #2688 by hnyman, we don't provide a complete A to Z guide, but the device specific actions required for getting openwrt up and running.
this is openwrt default, a well know fact, if you've dealt with openwrt in the past.
"openwrt root password" @ google solves the problem, just as "how to ssh" would.
the boot loader only accepts FAT, and you probably don't want to use FAT for your extroot.
it does, but it doesn't mean all 256MBs are available for openwrt.
1 Like
Right, I was just wondering if the changes done with
fw_setenv bootcmd 'run openwrtusb; run openwrtboot'
fw_setenv openwrtboot 'setenv bootargs console=ttyMSM0,115200n8 ubi.mtd=rootfs rootfstype=squashfs rootwait; ubi part fs; ubi read 0x44000000 kernel; bootm 0x44000000#config@rt5010w-d350-rev0'
fw_setenv openwrtusb 'usb start && fatload usb 0:1 0x44000000 openwrt-ipq807x-generic-dynalink_dl-wrx36-initramfs-uImage.itb && bootm 0x44000000'
would mess with being able to set up extroot.
I went ahead and configured extroot and it worked fine, but i didnt test to see if the failsafe usb still worked.
This is my config for extroot and I did not use fat, let me know if theres anything i could improve, but as I said, it worked fine.
opkg update
opkg install block-mount kmod-fs-f2fs e2fsprogs f2fs-tools parted kmod-usb-storage kmod-usb2 kmod-usb3
// Verify sda is correct drive and edit DISK parameter.
ls -l /sys/block
// Todo: come up with a way to detect usb devices to assign DISK variable automagically.
DISK="/dev/sda"
parted -s ${DISK} -- mklabel gpt mkpart extroot 2048s -2048s
DEVICE="${DISK}1"
mkfs.f2fs -l extroot ${DEVICE}
// Todo: Confirm this entire block can be input at the same time without errors, cause I don't know. Other wise each command separately cause u skerred.
eval $(block info ${DEVICE} | grep -o -e 'UUID="\S*"')
eval $(block info | grep -o -e 'MOUNT="\S*/overlay"')
uci -q delete fstab.extroot
uci set fstab.extroot="mount"
uci set fstab.extroot.uuid="${UUID}"
uci set fstab.extroot.target="${MOUNT}"
uci commit fstab
mount ${DEVICE} /mnt
tar -C ${MOUNT} -cvf - . | tar -C /mnt -xf -
reboot
I dont understand but fair.
nope, those fw_setenv params are for u-boot, not openwrt.
openwrt tries to retain stock fw layout, to make it easier to return to stock, if needed.
it's probably doable, but someone have to make the changes required - Dynalink DL-WRX36 Askey RT5010W IPQ8072A technical discussion - #2694 by frollic
1 Like
Do you know if there a reason why temp space is 434 MiB and disk space is only 70MiB?
/tmp in an OpenWRT device is a ramdisk. I'm not sure how it works but basically that way all sorts of "files" needed for the router to interact with stuff can be accessed but don't have to be written to flash.
Your persistent storage is the 70 MB, which is what's left after the other partitions and OS have eaten much of the nand. Notably, there's another large partition for the backup firmware which we aren't able to use right now... I'm hoping I can somehow contribute to that effort but I'm not sure what the exact issue is.
I do wish the install instructions featured an example command myself, I'm able to figure this stuff out but it's mostly due to using Linux as a main OS and from past experience with OpenWRT. The password being blank is not something I feel most would know, especially since you really need a router with OpenWRT to gain experience with using it...
The "switch WinSCP/SCP to SCP" line is also incredibly confusing... it sounds like it's saying to use SCP (the command) instead of winSCP, rather than a mode. I previously thought SFTP was the protocol used by SCP.
I understand that experts would probably understand this, but that's also no reason not to help out newbies or even those with some experience but one lacking obscure bit of knowledge. (Still not sure which I am, but that's beside the point.)
1 Like
Sorry, never saw your post.
Okay, so I'm aware of a few interesting options for alternative boot methods... there's the RavPower WD009, the Belkin RT3200, and now this Xiaomi router.
I'll have to explore the exact method by which these work... which means I'll probably have to first find whatever code additions to those images enables the process (as separate from all the other adaptations that just make the device work).
I do suspect a naive overwrite of the partitions (akin to Belkin RT3200 and Xiaomi) may not work, I think some of the partitions somehow firmware for the radios, given the MTD names. So that might mean they are fixed in place. At best they'd need to be moved, which also may not work.
mtd18: 06100000 00020000 "rootfs"<-- OS #1
mtd19: 00900000 00020000 "0:wififw" <-- "probably" firmware for the wi-fi...
mtd20: 06100000 00020000 "rootfs_1" <-- OS #2
mtd21: 00900000 00020000 "0:wififw_1" <-- "probably" firmware for the wi-fi...
mtd22: 01600000 00020000 "ubifs" <-- particularly large but not part of OpenWRT boot?
Plus whatever all the others do... If I understand correctly, the rootfs and rootfs_1 contain the entire OpenWRT image and the others may as well be magic as far as I know. I'm curious if this partition layout is common for this architecture or if it's completely novel...
Anyway, the RavPower design is, um, interesting. Apparently it chain-boots by having u-boot load a second bootloader that then loads the kernel from a new location since the kernel partition size is hardcoded as "tiny."
I feel like that holds promise if it's the original bootloader holding us back from dual-image support, but that still raises the question of where we can stick a second bootloader that isn't inside one of the firmware partitions (unless that would work... We could use the other as a bootloader+internal ramdisk recovery, but that sounds hard to coordinate across two separate UBI partitions and I'm still hoping for full A/B image support).
Anyone got a clue what the other partitions are and if we need them?
Second and more importantly, what methods exist to recover if I somehow break a partition or the bootchain in testing?
I ordered up some SPI flash reader clips and a Pi Pico as an SPI reader, but I'm not sure what software tools would work to read/write a nand and get the ECC correct. In addition, how do I prevent the host from requesting reads/writes while I'm making a dump or restore? These things work for BIOS flashing but I imagine there are hardware differences to the chip's interface. Then there's the chance of getting a bad block if I try to restore a full image... I may need to request help on how to only image/write certain parts using external tools.
For methods that don't need me to open the case (but which won't work if I can't boot something) there's MTD but the wiki says not to use that on flash. That said, perusal of my dump say the OEM firmware just uses MTD during a sysupgrade anyway (I mean, OEMs are usually not respectful of the flash, but it's weird that it works at all). Was MTD patched to work natively with nand (if so, the guide should probably get updated, at least to mention when that was added)?
The wiki and an unanswered forum thread mention the proper nand tools, but I'm not sure exactly how to sub them in for creating the MTD backup. Meanwhile, LuCI has a tool to download the partitions but I'm not sure if it is nand-aware or not.
I also tried accessing the partitions past 24 but neither LuCI nor the command line seem to be able to do anything with them, which is also weird:
cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00020000 "0:SBL1"
mtd1: 00100000 00020000 "0:MIBIB"
mtd2: 00080000 00020000 "0:BOOTCONFIG"
mtd3: 00080000 00020000 "0:BOOTCONFIG1"
mtd4: 00300000 00020000 "0:QSEE"
mtd5: 00300000 00020000 "0:QSEE_1"
mtd6: 00080000 00020000 "0:DEVCFG"
mtd7: 00080000 00020000 "0:DEVCFG_1"
mtd8: 00080000 00020000 "0:APDP"
mtd9: 00080000 00020000 "0:APDP_1"
mtd10: 00080000 00020000 "0:RPM"
mtd11: 00080000 00020000 "0:RPM_1"
mtd12: 00080000 00020000 "0:CDT"
mtd13: 00080000 00020000 "0:CDT_1"
mtd14: 00080000 00020000 "0:APPSBLENV"
mtd15: 00100000 00020000 "0:APPSBL"
mtd16: 00100000 00020000 "0:APPSBL_1"
mtd17: 00080000 00020000 "0:ART"
mtd18: 06100000 00020000 "rootfs_1"
mtd19: 00900000 00020000 "0:WIFIFW_1"
mtd20: 06100000 00020000 "rootfs"
mtd21: 00900000 00020000 "0:WIFIFW"
mtd22: 01600000 00020000 "ubifs"
mtd23: 00080000 00020000 "0:ETHPHYFW"
mtd24: 00280000 00020000 "certificate"
mtd25: 003ff000 0001f000 "kernel"
mtd26: 0218b000 0001f000 "ubi_rootfs"
mtd27: 0331a000 0001f000 "rootfs_data"
mtd28: 00f04000 0001f000 "log"
mtd29: 00516000 0001f000 "vendor"
mtd30: 0001f000 0001f000 "user_data"
mtd31: 0020f000 0001f000 "wifi_fw"
-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
cat /sys/class/mtd/mtd24/offset
262668288
cat /sys/class/mtd/mtd25/offset
cat: can't open '/sys/class/mtd/mtd25/offset': No such file or directory
cat /sys/class/mtd/mtd26/offset
cat: can't open '/sys/class/mtd/mtd26/offset': No such file or directory
cat /sys/class/mtd/mtd27/offset
cat: can't open '/sys/class/mtd/mtd27/offset': No such file or directory
cat /sys/class/mtd/mtd28/offset
cat: can't open '/sys/class/mtd/mtd28/offset': No such file or directory
cat /sys/class/mtd/mtd29/offset
cat: can't open '/sys/class/mtd/mtd29/offset': No such file or directory
cat /sys/class/mtd/mtd30/offset
cat: can't open '/sys/class/mtd/mtd30/offset': No such file or directory
cat /sys/class/mtd/mtd31/offset
cat: can't open '/sys/class/mtd/mtd31/offset': No such file or directory
You should read the discussions around messages 350-400 in this thread, as see the proof-of-concept about dual booting...
1 Like
Thank you.
I saw some of those earlier but couldn't figure out a coherent narrative at the time with all the other stuff I was trying to understand about this device's development at the time. I think I've got a better idea now.
I'm going to see if I can get something working on my device, or debug the OEM system for reverse-engineering purposes.
If you're still working on this I'd be happy to provide files or data from my device if possible. I may also be able to help with code. I would need to read up a bit more if making official commits to OpenWRT itself though - some of the stuff like repacking into single commit or needing to have a real name included is not something I'd know or necessarily be comfortable doing.
I've got a question about this command vs the wiki command - the later ones use
bootm 0x44000000#config@rt5010w-d350-rev0
Where does this #config line come from if it wasn't used earlier, and is that pulled from our image or the OEM config?
Is that going to go out of sync with further updates (due to config vs image actual settings, or the name changing)?
I'm of personal opinion that I'd rather keep the UBI metadata. In addition it has a bad block manager when I'm not sure what their nand write manages to do. We can boot a ramdisk anyway, and then use the full-featured sysupgrade rather than reset to bare iron.
TFTP needs setup on the local network anyway, I would presume physical access to plug in a USB stick would overlap with 90%+ of use cases. If we have it check for USB first, as in the method suggested in the wiki, then run the check for what image to boot, this also lets the user choose when to run recovery - it's when they insert the USB with that image.
If we call the usbboot first, this can be used before the uboot env boot select or the bootipq if we can get the bootconf working.
I'm still a noob for uboot instructions...
The first half of this code is an if condition for the user to check, then the last line is what the user actually enters?
And this will, assuming the condition is true, work for either active partition automagically going forward? Sysupgrade would need to be told which one to write as below, but does it ensure the OS itself directs writes to the active partition just while it's normally running?
I saw in your table that the bootloader normally renames these partitions when it changes boot order. I assume this line is intended to work with a uboot env change to set the active device so the uboot/bootconfig doesn't also swap the partitions?
Okay, so we can identify just off of the MTD name, but the bootloader can change which one has the name. Might be better to use the memory address?
I also see an issue here - if we can't write the bootconfig due to not having that kernel driver and if no one can reverse-engineer, the partition names won't be updated, so it's not enough to check the name but we also need to read something that then tells us which of those is really active. How do we check which image actually got booted?
(all of this assumes we keep the default partition layout, which is a bit verbose but "only" wastes 50 MB or so out of 256... and I'd certainly take this over a few I've seen that write the kernel to raw nand and make you change the buildconfig to move the rootfs partition if there's a bad block!)
I've seen a few possible methods, but I haven't the best idea how to modify the sysupgrade scripts to actually modify where they write (I'd have to find the business end first because this isn't something I've looked into before). Much less how to make that change apply to a specific device.
I'd be interested in knowing more...
Well at least it's not modding the uboot config itself, then.
That would keep the wear out of my precious boot settings. Uboot settings could also cause data loss (power loss at precisely the wrong moment; the grid's kinda poopy in my area). I seem to recall that bootconfig has an alt partition at least.
Were you able to confirm that we can use this "SCM call" on OpenWRT or does that end up going to their kernel driver that we probably can't replicate?
Ugh, of course it does.
I'm going to see if I can pull that partition and read what's in there. With my luck it's going to be more complex than a flag of who's getting booted, but there's a faint chance I can reverse engineer something. Or assuming it doesn't have an integrity hash we could just swap the bins in and out depending what image we want to boot.
Does conv=sync handle bad blocks or is this as brittle as everything else the OEM seems to be doing? It's possible the kernel module dynamically moves the data around errors when generating, but I doubt it. (My relatively short time in enterprise plus hands-on experience = I am already beginning to be pessimistic when dealing with this stuff.)
I'd assume this would then use the bootipq command rather than the bootmem? Would we still need the other bits of the ubootenv config or are those still needed for OpenWRT vs OEM?
(the following bits:)
setenv mtdids nand0=nand0 && setenv mtdparts mtdparts=nand0:0x6100000@0x1000000(fs) && setenv bootargs console=ttyMSM0,115200n8
Of course that only mentions the one partition not both, but that sort of config.
I still need to read this part, I'll edit it in when I have time.
Okay with that assuming we follow the now-default instructions to wipe both firmware partitions on install.
We have a working recovery method if anyone wants to go back to OEM (not sure why, the UI is worse and the feature set isn't great to my knowledge? Only exception might be if OEM has default settings for USB share or web upload because OpenWRT still doesn't do that in a remotely convenient manner, or even have the latter at all).
On that note, I can also host a backup factory image if we're worried about losing access to that. Let me know (assuming that wouldn't violate the "no copyrighted material" rule?).
Sorry, but what is the "only one of two scenarios" part? I don't see a difference between the two other than changing to USB boot, and it seems to check for either flash partition being set.
Good questions for me too - Are these still issues, anyone? I didn't see a reply and despite having read the full thread 1.5x by now it didn't stand out to me.
1 Like
My apologies for the length of the previous - I literally just now got level 2 and learned about/gained this cool new "hide really long posts" option. It's unfortunately been too long since for me to shorten the above, though.
Regarding your gist I said I'd get back to from my above,
I see three parts:
- (I think) boot-success detection, to clear the
owrt_upgrade_availableflag - boot and fail-boot detection in uboot env (notes on possible issues/upgrades later)
- sysupgrade support (this was the part I wasn't sure how to patch)
fw_setenv owrt_bootcount_test_0 'if test $owrt_bootcount = 0; then setenv owrt_bootcount 1 && saveenv; else run owrt_bootcount_test_1; fi'
fw_setenv owrt_bootcount_test_1 'if test $owrt_bootcount = 1; then setenv owrt_bootcount 2 && run owrt_boot_change_slot && saveenv; else run owrt_bootcount_test_2; fi'
fw_setenv owrt_bootcount_test_2 'if test $owrt_bootcount = 2; then setenv owrt_bootcount 3 && setenv owrt_active 0 && saveenv; fi'
In general, I think this gives it 2 tries to boot the selected active partition, then 1 failback to the alt partition, and then just gives up to USB? Any successful boot also disables the bootcounter to avoid excessive writes to uboot env. Convenient.
And, since it's entirely disabled, no need to reset it so it doesn't cause boot reversions if there are future boot failures due to things like power loss.
I also noticed that this only boots to USB if owrt_bootcount is 3.
Suggestion for enhanced USB recovery
While I think it is good to not keep rebooting to a damaged partition, the way the boot counter works means we've also got no way to enter USB if a partition boots at all.
According to the wiki and my own testing, we can try (and fail) to load a USB then continue with other checks. USB boot also sets no envs, so we can safely saveenv even after trying it. So I think there's no harm in trying USB, checking the images, and then maybe just halting if there's no watchdog.
Then all we've got to do is plug in a USB with the file and it'll load safely regardless of any partition issues.
Meanwhile, I see sysupgrade runs the following to switch the image:
fw_setenv owrt_upgrade_available 1
fw_setenv owrt_bootcount 0
fw_setenv owrt_active $active_slot_new
I do wonder if there's a way to write these all at once, though, because I presume each of these is a write to the environment (unless it times out a cache and batch-writes, since I don't see a corresponding save command).
Additional separate suggestion to future-proof the recovery process
Other minor issue, which is probably due to a change since the time you wrote this originally, but I see that the line
fw_setenv owrt_boot_usbinitramfs 'usb start && fatload usb 0:1 0x44000000 openwrt-ipq807x-generic-dynalink_dl-wrx36-initramfs-uImage.itb && bootm 0x44000000'
uses the 23.05 name for the recovery when this name will change in all future releases. Would it be better to use a shorter or truncated name like, for instance, 'dl-wrx36-initramfs-uImage.itb' and just ask the user in the debrick section of the wiki to rename their recovery to that?
(Otherwise the maintainer would have to rewrite platform.sh on multiple lines whenever the name of the file changed, which is going to be at least once. But maybe that's normal?)
I'll post more once I've had a nice hex editor session with the OEM bootconfig partitions. I'm not thoroughly convinced that either method won't wear through the boot select method's flash faster than the firmware partition, but I do know the bootconfig has a backup. There might be some rotation there, in which case it can be brought in line with the firmware usage levels.
Anyone know how far the guaranteed-good/longer endurance blocks of the flash go? Is the uboot env and/or the bootconfig in there or is this risky?
2 Likes
I have been looking for a new router to replace my EA8300 (with OpenWRT) and the WRX36 seems to meet all my needs (including being low cost).
In this post Dynalink DL-WRX36 Askey RT5010W IPQ8072A technical discussion - #1074 by eginnc there seems to be a concern about WiFi performance compared to another option (E8450/RT3200). Has anyone else noticed suboptimal WiFi coverage with the WRX36?
1 Like
I really wanted to like this router. Unfortunately, it is sitting in a drawer until (hopefully) the wifi disconnect issues get resolved. That’s mostly why I am watching this discussion.
I have the RT3200 (AP) and the Redmi ax6000 (Router) and both have given me 0 problems and going strong for 100+ wifi devices.
1 Like