[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