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
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
