[LEDE-DEV] [PATCH] ar71xx: add support for TP-Link TL-WDR7500v6

Bill Moffitt bmoffitt at ayrstone.com
Wed Dec 13 11:14:12 PST 2017


Piotr-

Thank you for your time and energy in helping me understand the issues.

First, I strongly agree with your comment about "I think it's always up 
to the person who takes care" of the PRs, etc - it is, and should be, 
entirely your call! I cannot do and do not want the job!!! :-D

Second, Mathias's point "any [experienced] user can take it and make use 
of it" is also very well-taken.

Together, I think these more than adequately answer my concerns - I 
certainly have no objections.

Thank you again,

Bill


On 12/12/2017 11:49 AM, Piotr Dymacz wrote:
> 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
>




More information about the Lede-dev mailing list