Piotr-
Good points all...
On 11/29/2017 12:03 PM, Piotr Dymacz wrote:
Hello Bill,
On 29.11.2017 20:17, Bill Moffitt wrote:
Hello Piotr and Karol,
[snip]
Please, include in commit message how to install LEDE on this
device as
described under "commit description" section on [1].
Ok, will prepare manual how to change bootloader to non-RSA one,
move art and
install LEDE.
I'm sorry but I'm against accepting support for devices which
requires such invasive modifications. We always try to make it
possible for users to get back to the stock firmware which wouldn't
be easy (or possible at all) with your changes in mtd layout and
after bootloader swap.
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...)
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.
If the only objection is that it involves invasive modifications that
may not (probably won't) allow the device to be re-flashed to stock, I
would prefer we accept the patch and make a very strongly-worded note in
the ToH and the device's wiki page explaining the situation.
This is not the only one objection. Personally I don't have problems
with swapping bootloader and for ar71xx target we already have a
dedicated package with old U-Boot sources: [1]
The problem here is that the bootloader the user has to use for this
device comes from some random GitHub repository which exist today but
may disappear tomorrow. Who will make sure that the bootloader image
the author of the support mentions in his patch will be still
available in next years and is correct and won't break users device?
If the bootloader code was in our repository or in upstream, I would
be first one accepting support for this device.
Good point.
What's also important to notice here, devices with QCA WiSoCs and SPI
NOR flash chips aren't easy to recover from a failed bootloader flash.
If there is no JTAG on the board the only way to bring device back to
life is to use flash chip programmer.
Very good point.
[1]
https://github.com/lede-project/source/tree/master/package/boot/uboot-ar71xx
But I'd still rather endorse a notation in the ToH and the wiki than
just prevent the patch from being accepted.
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?"
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.
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.
That's how I feel about it. As always, FWIW.
-Bill
--
Bill Moffitt
Ayrstone Productivity
http://ayrstone.com
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
