Can someone say where is u-boot starts and ends in flash in Archer A6 v3 or C6U ?
This is from the C6U vendor firmware:
| dev: | size | erasesize | name | offset |
|---|---|---|---|---|
| mtd0: | 00040000 | 00010000 | "uboot" | 00000000 |
| mtd1: | 00200000 | 00010000 | "uImage" | 00040000 |
| mtd2: | 00db0000 | 00010000 | "rootfs" | 00240000 |
| mtd3: | 00010000 | 00010000 | "ART" | 00ff0000 |
1 Like
Thanks a lot!! So it looks like there is no dedicated partition for preloader being the part of u-boot. What "erasesize" stands for ? Also found these lines at the end of my C6U flash:
partition fs-uboot base 0x00000 size 0x40000
partition os-image base 0x40000 size 0x200000
partition file-system base 0x240000 size 0xd60000
partition default-mac base 0xfa0000 size 0x00200
partition pin base 0xfa0200 size 0x00100
partition device-id base 0xfa0300 size 0x00100
partition product-info base 0xfa0400 size 0x0fc00
partition default-config base 0xfb0000 size 0x08000
partition ap-def-config base 0xfb8000 size 0x08000
partition user-config base 0xfc0000 size 0x0c000
partition certificate base 0xfcc000 size 0x04000
partition ap-config base 0xfd0000 size 0x08000
partition router-config base 0xfd8000 size 0x08000
partition partition-table base 0xfe0000 size 0x00800
partition soft-version base 0xfe0800 size 0x00100
partition support-list base 0xfe0900 size 0x00200
partition profile base 0xfe0b00 size 0x03000
partition extra-para base 0xfe3b00 size 0x00100
partition radio base 0xff0000 size 0x10000
Flash chips only erase 1 block at a time
(whole chip erase command is not used for obvious reasons)
erasesize is the size of the block that gets erased by an erase instruction in the SPI standard
basically, a flash chip receives a "command" just like a computer with a command line, but it is all in binary
the command for erasing a block for SPI nor flash is something like
0xd8 0x040000
where 0xd8 is the binary command that tells it to erase a 64k size block
and 0x040000 is the address of the block to be erased
for SPI serial interface:
first the Chip Select pin is latched to LOW
on the next clock phase, this data is sent in binary to the chip
this data is the command + address, and it is in sync with the clock
after this is sent to the chip, on the next clock phase, the Chip Select pin is latched HIGH
at this point the chip does all the work to erase the block
during a write or erase, there is a command to return the status which has a BUSY bit
when the BUSY bit is cleared, the chip is ready to receive another command
some flash chips support multiple erase commands, for different sizes...
like 4k, 32k, 64k
most of the time, erasesize will be 64k or 4k
the kernel knows which one is supported based on the chip ID
when the SPI driver is started
2 Likes
The SPI NOR flash block erase size as reported by the kernel's mtd subsystem. You can ignore it.
root@Akronite:/# cat /proc/mtd
dev: size erasesize name offset
mtd0: 00040000 00010000 "uboot" 00000000
mtd1: 00200000 00010000 "uImage" 00040000
mtd2: 00db0000 00010000 "rootfs" 00240000
mtd3: 00010000 00010000 "ART" 00ff0000
root@Akronite:/#
That's the TP-Link vendor firmware partition table. It's written on the flash at this offset:
partition partition-table base 0xfe0000 size 0x00800
OpenWrt is flashed on the os-image + file-system partitions as in most of the cases with similar routers.
2 Likes
Thanks to @vrpatil support has been merged into master, but we need testing on 21.02 if we want this device available in 21.02. I have created builds based on 21.02 HEAD (they will be almost identical to RC2).
Images can be found here. Please test (do not keep settings when flashing from master) and report back if everything works. At this point the difference between master and 21.02 is rather small, so I don't expect there to be any issues (other than those that might exist on master already).
I'll add your forum names to the patch for 21.02 - if you want to be mentioned in a 'formal' Tested-by, you can provide your real name and e-mail address through PM, but that should not be necessary.
I'm asking since the developer who merged support into master would like actual testing before backporting it to 21.02 (which makes sense).
Thank you!
Edit: image is reported to be broken so link removed until I can check.
5 Likes
Thanks @Borromini . I've been using this PR merged with Main for the past month or so and the one thing I've found is that 5ghz wireless will drop after a period of time. 2.4 wireless seems to work okay. I wasn't sure if it's my router or a driver/openwrt issue. I"ve been meaning to flash back to stock to see if it was a hardware problem but I haven't had the time since this seems to require serial access to return to stock. I'd be interested to hear what others find. I will flash your versions and see if I have similar outcome.
Thanks. I have three devices with the same MT7613 5 GHz radio, and I am seeing occasional dropouts on one. Bought them at the same time, serial numbers follow one another rather closely, so maybe one of them just has a bad radio. Hence my interest in getting some more devices with MT7613 in 21.02.
So far, for me the MT7613 radio has been more stable than with earlier mt76 versions. At this point they're still identical between master and 21.02 (2021-05-15).
I downloaded your 21.02 version and used it for a few days and it seems to work and solved my 5 ghz wireless dropping. In vrpatil'ds PR thread on github, someone mentioned an issue with pppoe. My internet doesn't use pppoe, so i can't test.
One thing I did notice is that the MAC address assigned by Vrpatil's PR are not quite the same as the OEM version.
His PR assigns tham as:
LAN xx:xx:xx:xx:xx:41 (label)
WAN xx:xx:xx:xx:xx:41 (label)
2 ghz xx:xx:xx:xx:xx:42 (+1)
5 ghz xx:xx:xx:xx:xx:43 (+2)
and
stock does so as:
LAN xx:xx:xx:xx:xx:41 (label)
WAN xx:xx:xx:xx:xx:42 (+1)
2 ghz xx:xx:xx:xx:xx:41 (label)
5 ghz xx:xx:xx:xx:xx:40 (-1)
It's not a big difference and works okay nonetheless. Not sure if using the same MAC label for LAN and WAN would cause the issues with pppoe.
1 Like
I don't think that would, and I've had problems with PPPoE myself on 21.02 and an x86_64 box. Then again, on my own router, PPPoE works fine (both are with different ISPs). So I think it's safe to say this is not a device specific issue.
Thanks for checking the MACs, I'll see if I can send in a patch to address that. And I'll shoot in a backport request for this device as a tested-by.
Is it possible to boot into the rescue firmware partition without opening up the router? https://gist.github.com/sandmail32/67d9f5c64a8979a4035278ef320a08a8#file-0001-ramips-add-support-for-tp-link-archer-a6-v3-patch-L45 This says you can only activate TFTP with serial console but does not mention the rescue partition (or if there is one at all).
@frankis I have uploaded a build with the modified addresses. They should now match the OEM layout. Can you install it and report back? Files are at the same location.
Thank you!
@borromini Ok, I took a look but the Archer a6 v3 images seem too small. They are only 3.3 MB in size whereas the C6 one is double that.
Update: well I flashed it against my better judgement and it bricked. Oh well, if anyone else has figured out how to access the recovery page or launch the tftp without soldering pins, pleaes share.
Sorry for that. I will check what went wrong with the build, the configuration might be different but it's just that single DTS patch on top of what was used for the previous build (and 21.02 HEAD).
@frankis There is no need to solder, you can wedge male pins into the holes and ply them underneath the board so they keep themselves in place, then connect a serial cable to them. I do it all the time (I haven't soldered a single thing up till now).
The black bars can often be moved up or down, you can do that in addition to bending the pins on the back of the board so they are kept in place. Make sure not to get short headers though, there's long and short versions apparently.
1 Like
I've done that in the past too but I figure if I'm going to the trouble of opening it up, I might as well just solder the pins in there permanently. Anyhow, I did open it up and flashed back to stock. I'm going to let this run over the weekend to check to see if the 5g drops to confirm I don't have a hardware issue.
Since I had the serial console open, I did try the obvious things to see if I could activate the TFTP recovery or web recovery pages using the button pushes, but no luck. It seems the only way to access them is through sending key strokes to the serial console as vrpatil indicated.
As for anyone else looking for an image, the snapshot images seems to work okay. Don't use the june 2 images 21.02 of Borromini for the Archer a6 v3 as it will brick your router and the only way to recover is to open it up and access the serial console to activate recovery mode.
1 Like
Hey guys, there is a broader backport effort going on, with the A6 v3 amongs the devices. See this mailing list post.
Please test those, @ynezz has built 21.02 images for testing.
Is there any sort of formal testing procedure or set of criteria that would be helpful for me to test against? Or is this more of a works-for-me thing? I've got six of these coming Thursday hoping they'll be ideal for "tactical deployments" (i.e. vacation homes our family rents) so I've got an interest in getting support into 21.02.
in terms of testing, focus on the hardware
does it flash
does it boot
does it reboot
ethernet good
wireless good
etc
Got it, appreciate the list, thanks. Will do.
I assume I should go through the "Reporting bugs" process on the website for specific issues, but what would be the most useful way of reporting success? Replying here? Posting on openwrt-devel? Opening a "bug"?
Sorry for all the questions -- I've been a happy user for many years but this is the first time interacting with the project.