[LEDE-DEV] [PATCH] ar71xx: add support for TP-Link TL-WDR7500v6
Piotr Dymacz
pepe2k at gmail.com
Tue Dec 12 11:49:49 PST 2017
Hello Bill,
On 30.11.2017 22:06, Bill Moffitt wrote:
> Piotr-
>
> Good points all...
[snip]
>>> In general, of course, I agree. However, we are seeing an increasing
>>> number of vendors (TP-Link and Ubiquiti, to name 2) using some form of
>>> locking in the bootloader to prevent loading of third-party firmware.
>>
>> Then buy and use hardware from vendors who are open source friendly
>> and allow users to actually fully own the hardware they paid for! :)
> Hey, THERE'S a good idea!!! Suggestions??? :-D (especially for outdoors
> - that's why I'm working with the Comfast devices...)
There are great people working on the Wiki and table of hardware [1].
The ToH is now mostly driven by information included in commits which
add support for new devices. You can also ask on the forum [2] for
hardware suggestions.
>>> The only option for loading OpenWRT (permanently - not using initramfs)
>>> on these devices will be replacing the bootloader, as Karol does in this
>>> patch.
>>
>> Swapping bootloader isn't the only issue I see here. Moving ART which
>> is essential and unique per device might end up in a data loss which
>> cannot be recovered in any way.
> Yes, that's true. But the only other option is not use the hardware.
I wouldn't be surprised if there is some other way but people usually
prefer "make it working and forget" approach (I follow it very often, too).
[snip]
> But I'd still rather endorse a notation in the ToH and the wiki than
> just prevent the patch from being accepted.
I think it's always up to the person who takes care (and spends time
reviewing, merging and then maintaining related code in future) about
the patch/PR as we don't have any strictly defined rule/s about what
device/platform can be accepted.
If someone else feels that this patch should be included, I won't argue
- I have already pointed out what's in my opinion wrong with it.
> Everything in OpenWRT is pretty much "use at your own risk." Could we
> make a distinction between "Use at your own risk - might cause problems
> that will be hard to get around" and "Use at your own risk - you have a
> pretty good chance of bricking this thing?" Or, put another way, instead
> of just saying "supported" could we have platforms that are "Supported
> and easy" to "Supported, but, hey, this thing is ugly and will hurt you
> if you're not careful?"
I hope some day in future OpenWrt/LEDE will have all the code required
to support every platform from top to bottom, including bootloader/s,
radio firmware, JTAG configs, etc. But we are not there yet.
FWIW, there is an ongoing work on making Barebox bootloader support MIPS
based QCA WiSoCs [3] and a PR with packaging it is under review: [4].
> We should do everything we can to reduce the risk of a repo going away,
> etc., but I'd endorse using some sketchy sources if necessary to gain
> support of a particular device.
I think it's always a trade off and every single person would have
different opinion here.
> It is good and necessary to look out for the naive beginner (as we all
> were at one time). But, at the same time, there is value in supporting
> the wisened and experienced user who can go to some extra effort and
> undertake some risk for a particular purpose.
As Mathias wrote, the patch was sent to a public mailing list and now
any [experienced] user can take it and make use of it... assuming that
(s)he would magically find out where to get, compile and write the
custom bootloader. The patch doesn't include any clue about that.
> That's how I feel about it. As always, FWIW.
Thanks, I appreciate every valuable comment!
[1] https://lede-project.org/toh/start
[2] https://forum.lede-project.org/
[3] https://git.pengutronix.de/cgit/barebox/log/?qt=grep&q=ath79
[4] https://github.com/lede-project/source/pull/1556
--
Cheers,
Piotr
More information about the Lede-dev
mailing list