This commit adds the split-uboot partition layout used by the
Archer C50 v4 to mktplinkfw2.
Signed-off-by: David Bauer
---
tools/firmware-utils/src/mktplinkfw2.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/firmware-utils/src/mktplinkfw2.c
This adds support for the TP-Link Archer C50 v4.
It uses the same hardware as the v3 variant, sharing the same FCC-ID.
CPU: MediaTek MT7628 (580MHz)
RAM: 64M DDR2
FLASH: 8M SPI
WiFi: 2.4GHz 2x2 MT7628 b/g/n integrated
WiFI: 5GHz 2x2 MT7612 a/n/ac
ETH: 1x WAN 4x LAN
LED: Power, WiFi2,
John Crispin wrote:
>
> On 03/12/2018 19:04, Henrique de Moraes Holschuh wrote:
> > (openwrt-adm dropped from this subthread)
> >
> > Em 03/12/2018 15:29, Stijn Segers escreveu:
> >> Op ma, 3 dec 2018 om 5:51 , schreef John Crispin :
> >>> The idea was to fade out ar71xx after the next release
Hello Henrique,
On 03.12.18 19:04, Henrique de Moraes Holschuh wrote:
> Is there a viable way to "sysupgrade" from ar71xx to ath79?
>
> Even if it would require a model-by-model "update map" for the
> lower-level stuff (LEDs, switch ports?, etc), that would be valuable.
> Otherwise, it will be
On 03/12/2018 23:56, Daniel Santos wrote:
On 11/24/18 8:05 AM, Hauke Mehrtens wrote:
On 10/19/18 10:59 AM, Daniel Santos wrote:
[snip]
We would like to reduce the number of patches we ship in OpenWrt on top
of the mainline Linux kernel.
Please send this to the upstream Maintainer of the jffs
On 11/24/18 8:05 AM, Hauke Mehrtens wrote:
> On 10/19/18 10:59 AM, Daniel Santos wrote:
> [snip]
> We would like to reduce the number of patches we ship in OpenWrt on top
> of the mainline Linux kernel.
>
> Please send this to the upstream Maintainer of the jffs driver in the
> mainline Linux
On 2018-12-03 23:05, Paul Oranje wrote:
Op 3 dec. 2018, om 10:57 heeft Daniel Engberg
het volgende geschreven:
Hi,
Perhaps its worth considering adding bsdtar / libarchive
(https://www.libarchive.org/) instead which handles various formats
including zip (via zlib) and is still active?
> Op 3 dec. 2018, om 10:57 heeft Daniel Engberg
> het volgende geschreven:
>
> Hi,
>
> Perhaps its worth considering adding bsdtar / libarchive
> (https://www.libarchive.org/) instead which handles various formats including
> zip (via zlib) and is still active? Another possible benefit would
> On 3 Dec 2018, at 18:23, Petr Štetiar wrote:
>
> On December 3, 2018 6:04:28 PM UTC, Henrique de Moraes Holschuh
> wrote:
>> (openwrt-adm dropped from this subthread)
>>
>> Is there a viable way to "sysupgrade" from ar71xx to ath79?
>
> Have you tried it? It didn't work for you?
>
>>
On 03/12/2018 19:50, Henrique de Moraes Holschuh wrote:
Apparently I was working on outdated information (likely from the
early days of ath79). Likely I got it from the ML archive or an older
forum post. Sorry about the noise (and happy it is supposed to just
work!).
all cool, this is
Em 03/12/2018 16:23, Petr Štetiar escreveu:
On December 3, 2018 6:04:28 PM UTC, Henrique de Moraes Holschuh
wrote:
(openwrt-adm dropped from this subthread)
Is there a viable way to "sysupgrade" from ar71xx to ath79?
Have you tried it? It didn't work for you?
Even if it would require a
Hello John,
> The idea was to fade out ar71xx after the next release and only accept
> new boards for ath79. However i'd been fine taking that step as of now.
> i have noticed that the ath79 patches far out number the ar71xx ones. we
> have lots of patches that migrate boards and i have seen a
On December 3, 2018 6:04:28 PM UTC, Henrique de Moraes Holschuh
wrote:
>(openwrt-adm dropped from this subthread)
>
>Is there a viable way to "sysupgrade" from ar71xx to ath79?
Have you tried it? It didn't work for you?
>Even if it would require a model-by-model "update map" for the
On 03/12/2018 19:04, Henrique de Moraes Holschuh wrote:
(openwrt-adm dropped from this subthread)
Em 03/12/2018 15:29, Stijn Segers escreveu:
Op ma, 3 dec 2018 om 5:51 , schreef John Crispin :
The idea was to fade out ar71xx after the next release and only accept
new boards for ath79.
(openwrt-adm dropped from this subthread)
Em 03/12/2018 15:29, Stijn Segers escreveu:
Op ma, 3 dec 2018 om 5:51 , schreef John Crispin :
The idea was to fade out ar71xx after the next release and only accept
new boards for ath79. However i'd been fine taking that step as of now.
i have noticed
Op ma, 3 dec 2018 om 5:51 , schreef John Crispin :
On 03/12/2018 16:56, Petr Štetiar wrote:
> Hi,
>
> I'm just going through the oldest PRs on GitHub, and I've noticed,
that ath79
> submissions are being more preferred between maintainers and that
ar71xx PRs
> are basically stalled, there
Has this discussion gone anywhere ?
Are we keeping LEDE 17.01 for a little while under these conditions or not ?
Regards
Fernando
On 12/11/2018 18:57, Fernando Frediani wrote:
Totally agree with Luiz. That was the idea behind this proposal and
you managed to even easier words.
Alberto, the
On 03/12/2018 16:56, Petr Štetiar wrote:
Hi,
I'm just going through the oldest PRs on GitHub, and I've noticed, that ath79
submissions are being more preferred between maintainers and that ar71xx PRs
are basically stalled, there are 24 open PRs for ar71xx Vs 14 open PRs for
ath79. So I'm
Petr Štetiar kirjoitti 3.12.2018 klo 17:56:
I'm just going through the oldest PRs on GitHub, and I've noticed, that ath79
submissions are being more preferred between maintainers and that ar71xx PRs
are basically stalled, there are 24 open PRs for ar71xx Vs 14 open PRs for
ath79. So I'm
Hi,
I'm just going through the oldest PRs on GitHub, and I've noticed, that ath79
submissions are being more preferred between maintainers and that ar71xx PRs
are basically stalled, there are 24 open PRs for ar71xx Vs 14 open PRs for
ath79. So I'm wondering, what's the plan, is ar71xx being
Currently after pivot to the USB disk (extroot),
configuration and data from original root overlay are gone.
Still accessible, but all previous configuration steps must be repeated
(or data from original root overlay must be copied to new USB disk overlay).
The idea is to "merge" original root
Hello John,
On 03.12.18 07:24, John Crispin wrote:
@@ -79,9 +80,19 @@ static int mtdsplit_parse_eva(struct mtd_info *master,
return EVA_NR_PARTS;
}
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 9, 0)
Hi,
the kernel version check is not required and can be dropped i believe
John
On 03/12/2018 09:37, Florian Eckert wrote:
Hello John
this is a very specific feature and I dont see any devices in tree
using the driver. it'll increase the image size and we have several
small flashed units in the target. cant you simplly make it AutoProbe
during preinit ? there is next to
Hello John
this is a very specific feature and I dont see any devices in tree
using the driver.
It is also correct that no image use this trigger per default.
But it is still possible for someone to put this trigger on a user
defined LED if he wants.
it'll increase the image size and we
Hi Hauke!
First of all, great work and also thanks to the others who contributed!
I gave this a try on my Orange Pi PC (Allwinner H3) and it seems to run
fine overall. Ethernet TX is a bit slow (~65mbit using iperf3) while RX
does full line speed (~94mbit) more or less and USB also seems to
Hi,
Perhaps its worth considering adding bsdtar / libarchive
(https://www.libarchive.org/) instead which handles various formats
including zip (via zlib) and is still active? Another possible benefit
would be that you would consolidate a few more tools into one.
Best regards,
Daniel
Hello John
this is a very specific feature and I dont see any devices in tree
using the driver. it'll increase the image size and we have several
small flashed units in the target. cant you simplly make it AutoProbe
during preinit ? there is next to no flash activity until preinit
anyway.
27 matches
Mail list logo
