WA860re v2 Boot


#1

Der erste wa806re v2 ist in der Mülltonne:( (verheizt, gehimmelt, verbraten, unbrauchbar gemacht;)

Zwar mit lede ein factory-image gebaut, das sich im webinterface einspielen liess

und die Modifikation Partitionierung vom wa850re v2 mit :

  • tools/firmware-utils/tplink-safeloader.c -
    576KB were moved from file-system to os-image
    in comparison to the stock image

übernommen, weil das squashfs sonst zu gross war und

  • target/linux/ar71xx/image/tp-link.mk -
    define Device/tl-wa860re-v2
    $(Device/tplink-4mlzma)
    DEVICE_TITLE := TP-LINK TL-WA860RE v2
    DEVICE_PACKAGES := rssileds
    BOARDNAME := TL-WA860RE-V2
    DEVICE_PROFILE := TLWA860
    TPLINK_BOARD_NAME := TLWA860REV2
    TPLINK_HWID := 0x08600002
    KERNEL := kernel-bin | patch-cmdline | lzma | mktplinkfw-kernel
    IMAGE/sysupgrade.bin := append-rootfs | tplink-safeloader sysupgrade
    IMAGE/factory.bin := append-rootfs | tplink-safeloader factory
    MTDPARTS := spi0.0:128k(u-boot)ro,1344k(kernel),2304k(rootfs),256k(config)ro,64k(art)ro,3648k@0x20000(firmware)
    endef

Ohne serielles Terminal bei dem Klotz hatte ich dann einen blinkenden Briefbeschwerer im Bootloop :frowning:

bei original-stock partitionierung würde es so aussehen, aber zu wenig Platz für das squashfs:

 /** Firmware layout for the TL-WA860RE v2 */
    {
            .id     = "TLWA860REV2",
            .vendor = "",
            .support_list =
                    "SupportList:\n"
                    "{product_name:TL-WA860RE,product_ver:2.0.0,special_id:00000000}\n"
                    "{product_name:TL-WA860RE,product_ver:2.0.0,special_id:55530000}\n"
                    "{product_name:TL-WA860RE,product_ver:2.0.0,special_id:45550000}\n"
                    "{product_name:TL-WA860RE,product_ver:2.0.0,special_id:4B520000}\n"
                    "{product_name:TL-WA860RE,product_ver:2.0.0,special_id:42520000}\n"
                    "{product_name:TL-WA860RE,product_ver:2.0.0,special_id:4A500000}\n"
                    "{product_name:TL-WA860RE,product_ver:2.0.0,special_id:43410000}\n",
            .support_trail = '\x00',

        .partitions = {
                    {"fs-uboot", 0x00000, 0x20000},
                    {"os-image", 0x20000, 0x000c0000},
                    {"file-system", 0x0e0000, 0x2d0000},
                    {"partition-table", 0x3b0000, 0x02000},
                    {"product-info", 0x3c1000, 0x01000},
                    {"soft-version", 0x3c2000, 0x00100},
                    {"support-list", 0x3c3000, 0x01000},
                    {"profile", 0x3c4000, 0x08000},
                    {"default-config", 0x3e0000, 0x10000},
                    {NULL, 0, 0}
    },

Hat jemand eine Idee?


#2

Nunja, das msust Du dann mit deinem Gewissen vereinbaren.
Es handelt sich um ein Elektrogerät, welches der WEEE unterliegt, also bei einer Entsorgung in Deutschland dem Recycling (z.B. über einen Teilnehmer bei der EAR) zugeführt werden müsste.

Inzwischen kannst Du die Geräte doch in jedem Elektrofachmarkt (in den größeren) problemlos im Servicebereich abgeben. In Rathäusern/Bürgerämtern gibt es für Kleingeräte auch Sammelcontainer.


#3

Fliegenbeinzähler - es geht nicht um die Entsorgung, sondern um eine Info zum Bootloader und Image.

Hast Du heute 'nen Clown gefrühstückt? :smiley:


#4

Das obendrein!

Ein Gerät wegzuwerfen, nur weil ein Flashen schief gegangen ist. Statt vorher hier einmal anzufragen.
Stattdessen hier posten “Weggeworfen, weil scheisse!”

Das ist mir unbegreiflich!


#5

hast du jetzt eine Idee zum squashfs oder nur gähnende Langeweile . Bei letzterem bitte keine Antwort auf diesen Post.


#6

Die Langeweile hast vermutlich Du, wenn Du -nur weil was nicht auf Anieb funktioniert- ein Gerät zerkloppst und (nicht fachgerecht) entsorgst! (Und nein, ich finde das gar nicht lustig!)


#7

Kein tftp Recovery mehr möglich?

Zur Not kann man doch den Flash Chip neu beschreiben…


#8

Also ich mache im zweifel immer ein Update in der Microwelle.
Dann ist das auf jedenfall gut durch …


#9

es geht NICHT um die Rettung eines geschossenen units - es geht um die Frage, ob jemand eine Idee zur Partitionierung und zum squashfs hat. Lt. Info sollte die Hardware wrt841 v9-11 kompatibel sein .

mit den GPL-Sourcen von tp-link hab ich auch schon sauber images gebaut und geflasht. Allerdings noch auf deren linux-2.63.x Basis und in einer 32bit toolchain Umgebung.

original:
binwalk /usr/src/tp-link/860rev2_gpl_code/images/860rev2/860rev2_eu-flash-ver1-0-0-P1[20170422-rel82675].bin

DECIMAL HEXADECIMAL DESCRIPTION

13936 0x3670 U-Boot version string, "U-Boot 1.1.4 (Apr 22 2017 - 22:37:38)"
13984 0x36A0 CRC32 polynomial table, big endian
15288 0x3BB8 uImage header, header size: 64 bytes, header CRC: 0x77405911, created: 2017-04-22 20:37:40, image size: 33760 bytes, Data Address: 0x80010000, Entry Point: 0x80010000, data CRC: 0xBC7CDB46, OS: Linux, CPU: MIPS, image type: Firmware Image, compression type: lzma, image name: "u-boot image"
131072 0x20000 TP-Link firmware header, firmware version: 0.0.0, image version: “”, product ID: 0x0, product version: 0, kernel load address: 0x0, kernel entry point: 0x80002000, kernel offset: 0, kernel length: 512, rootfs offset: 732529, rootfs length: 0, bootloader offset: 0, bootloader length: 0
131584 0x20200 LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 2093448 bytes
917504 0xE0000 Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 2736524 bytes, 581 inodes, blocksize: 1048576 bytes, created: 2017-04-22 20:57:22

Auswurf mit lede Projekt:
binwalk lede-ar71xx-generic-tl-wa860re-v2-squashfs-factory.bin

DECIMAL HEXADECIMAL DESCRIPTION

9215 0x23FF LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 4263796 bytes
1323651 0x143283 Squashfs filesystem, little endian, version 4.0, compression:xz, size: 1976206 bytes, 710 inodes, blocksize: 262144 bytes, created: 2017-04-23 01:19:34


#10

ich glaube, jetzt sehe ich#s selber - das patch-tool hat nicht den richtigen offset genommen, sondern in den u-boot loader geschrieben - das erklärt den Zonk :frowning:


#11

Nicht dass man nicht das noch retten könnte, wenn auch eventuell die wifi-calibration (also die ART-Partion) ebenfalls platt ist.

Ggf eben mit dem Prommer, der 860REv2 hat afaik kein JTAG, bzw das Einlöten eines Headers dauert länger als das SPI herauszufönen und wieder einzusetzen).
Wenn man dann die Calibration aus einem anderen Gerät nimmt… nungut… solange man drinnen bleibt und nicht auf maximale HF-Performance aus ist, bei so einem Gerät vermutlich sowieso nicht das primäre Ziel, zumal wenn’s das Lab-Gerät is was schon aufgedremelt wurde.


#12

Hab’ gerade den W25Q32FV vom wa860rev2.0 ausgelesen und den Inhalt gesichert.


Leider habe ich kein Backup vom Originalzustand, auf das ich zurückgreifen könnte.

Der 860re v2 ist übrigens sauber verschraubt und der spi flash auf der oberen Platine leicht zu erreichen.


#13

Der 860v2 zeigt sich nicht kooperationsbereit in Sachen seriell - muss also übers direkte spi flash schreiben per Prommer laufen.

Frage:
Reicht es, zur Änderung der Partitionierung (wie beim wa850re v2) ab offset 0x3b0000 die Werte anzupassen und mit kernel und squashfs in den neuen Bereichen zu flashen?


#14

und wieder raus aus der ‘Schrottecke’ - wiederbelebt:


#15

Im GPL Source für den wa860 v2 sind diverse kernel filtermodule nf_ und xt_ aktiviert - dafür wurden die language files aus dem web rausgeworfen - mit binwalk und sysquash aus der 16411er Firmware extrahiert und eingefügt.

Beim Kernel in timeconst.pl Zeile 373 ändern, damit es durchrutscht:

           if (!(@val)) {
           #       if (!defined(@val)) {
            @val = compute_values($hz);
    }

#16

Wie weit bist Du nun gekommen? Könntest Du die Änderungen für das Gerät bitte mit zu LEDE hochladen?! Es sieht ja fast genauso wie der 850v2 aus.

Das Problem mit dem geringen nutzbaren Flash-Speicher durch den TPLINK-Safeloader ist noch ein weiteres “Detail”-Problem. Was hältst Du von einer Intermediate-Firmware und Umpartitionieren des Flash-Chips? Ob man den Safeloader so irgendwie wieder loswerden kann?

Beim Battlemesh in Wien hatte ich neoraider mal gefragt, aber er hat wohl prinzipiell keine Lust mehr, bei 4MB-Flash-Geräten zu helfen.


#17

Bislang war bei jedem lede-Versuch das systemimage zu gross als Ersatz. Ich habe erfolgreich die GPL-Sourcen kompiliert und images gebaut, die aktzeptiert werden, soweit funktionieren, aber die LEDs nicht richtig ansteuern und noch keinen Zugang, um mit einem ‘zwischenflash’-image die Partitionierung zu ändern.
Musste abbrechen, weil ich das Teil als Repeater Funkbrücke für eine Freifunk-Installation eingesetzt habe, bis der Provider die mit LAN instabile Easybox 804 im Vorabtausch genen Fritzbox wechselt. Sobald das Teil wieder hier ist, baue ich weiter an einem Image ohne verbogenen ssh-Server, der nur auf den Tether-APP tunnelt. uboot-loader für 16M flash hatte ich mir schon gebaut - wenn die Aufrüstung auch so geht wie bei den 841n, wäre das Teil noch eine Weile nutzbar. Die bestellten Chips sind aber auch noch nicht aufgeschlagen.