[OpenWrt-Devel] [RFC 0/2]

[Matthias Schiffer]

On 11/24/2014 08:49 PM, John Crispin wrote:
> 
> 
> On 21/11/2014 09:41, Matthias Schiffer wrote:
>> Hi, this adds support for the new TP-LINK outdoor series
>> CPE210/220/510/520 ("Pharos"). I'm sending this as a RFC as there
>> is a still a number of open questions:
>>
>> eth0 configuration ================== Looking at the log output of
>> the stock firmware, it seems like the to ethernet ports both have
>> their own MAC.
>>
>> After booting OpenWrt, both ethernet ports are connected to the
>> internal switch, which is connected to the CPUs GMAC1; I haven't
>> been able to get a link on GMAC0 at all, so the current code of
>> these patches only initializes GMAC1. I don't know if using both
>> GMACs would be preferable, but it seems a bit strange like this, so
>> maybe someone with some more insight into the Atheros SoCs could
>> look at it or give me some hints?
> 
> if you connect tot he switch with 2 macs then you can do the lan/wan
> segmenting via vlan'ing inside the swith without the need for a trunk
> port and the matching vlan1/2 inside the network config. it would be
> preferable to have both working. its not a reason to not merge though
Okay.

> 
> 
> 
> 
> 
>> LED configuration ================= The CPEs have 6 controllable
>> LEDs: LAN0, LAN1 and four WLAN signal indicators. Currently my
>> patches configure all signal indicators using rssileds, but no 
>> status or WLAN activity LEDs are left like this.
>>
>>
>> Image generation ================ The new TP-LINK bootloader
>> ("TP-LINK Safeloader") expects the kernel image in ELF format. I've
>> tried building the ELF LZMA loader via Image/BuildLoader, but as
>> soon as I added a kernel command line there, the image wouldn't
>> boot at all. As a workaround, I'm using PatchKernelLzma and then
>> build the LZMA loader using the patched kernel as LOADER_DATA.
>>
>> Also, there's no initramfs support so far. (I've never used
>> initramfs with OpenWrt, but it seems like all other image types
>> support it?)
>>
> 
> initramfs is a ram boot image. the kernel has a rootfs inside and most
> bootloader will allow you to boot hese without the need to actually
> flash the image.
As the Safeloader doesn't allow booting from RAM, is there any reason to
have the initramfs images?

> 
> 
> 
>>
>> Apart from these issues, everything seems to work fine. I've only
>> tested this on the CPE510 so far, but I don't see why it shouldn't
>> work the same on the CPE210 (the stock firmware, "PharOS", also
>> uses just one image for both devices). The CPE220 and CPE520
>> variants aren't available yet, but as far as I can tell from the
>> information in the manual book, the only difference is the antenna
>> (lower angle, higher gain), so I've included them as supported
>> devices as well.
>>
>>
> 
> looks good, i saw 2-3 mini details int he firmware tool which i will
> fix up while merging.
I just noticed that there is actually another "v3" image format from
TP-Link, with 0x03000000 magic, used on Archer C2. I think it would make
sense to reserve the name mktplinkfw3 for a firmware tool for that
format, so I'll send an updated series which renames the tool for the
Safeloader to something like tplink-safeloader?

> 
> one question, why the mach file and the leds named cpe501 and not say
> cpe201 ? (just curious)
Two reasons:

1. The test device I got is a CPE510
2. The string CPE510 appears in the vendor string of the stock image
used for both CPE210 and CPE510

> 
> 	John
> 
> 
> 
>>
>> Matthias Schiffer (2): firmware-utils: add new tool mktplinkfw3 for
>> the new TP-LINK Pharos devices (CPE210/220/510/520) ar71xx: add
>> support for TP-LINK CPE210/220/510/520
>>
>> target/linux/ar71xx/base-files/etc/diag.sh         |   3 + 
>> .../ar71xx/base-files/etc/uci-defaults/01_leds     |  10 + 
>> .../ar71xx/base-files/etc/uci-defaults/02_network  |   7 + 
>> target/linux/ar71xx/base-files/lib/ar71xx.sh       |  40 +- 
>> .../ar71xx/base-files/lib/upgrade/platform.sh      |  32 ++ 
>> target/linux/ar71xx/config-3.10                    |   1 + 
>> .../ar71xx/files/arch/mips/ath79/mach-cpe510.c     | 107 +++++ 
>> target/linux/ar71xx/generic/profiles/tp-link.mk    |  11 + 
>> target/linux/ar71xx/image/Makefile                 |  27 ++ 
>> .../610-MIPS-ath79-openwrt-machines.patch          |  23 +- 
>> tools/firmware-utils/Makefile                      |   1 + 
>> tools/firmware-utils/src/mktplinkfw3.c             | 469
>> +++++++++++++++++++++ 12 files changed, 724 insertions(+), 7
>> deletions(-) create mode 100644
>> target/linux/ar71xx/files/arch/mips/ath79/mach-cpe510.c create mode
>> 100644 tools/firmware-utils/src/mktplinkfw3.c
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20141125/7e78f007/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel