[OpenWrt-Devel] [PATCH 1/1] ramips: remove RB750GR3 support
Denis Periša
darkman.hr at gmail.com
Sat Jul 21 12:20:31 EDT 2018
I use this on two devices. Flashed by changing bootloader from tftpd image.
Works like a charm. I don't agree with removal.
On Sat, Jul 21, 2018 at 4:42 PM, Sylwester Petela <sscapi at gmail.com> wrote:
> W dniu 21.07.2018 o 10:43, Thibaut pisze:
>
>>
>>> Le 21 juil. 2018 à 10:17, John Crispin <john at phrozen.org> a écrit :
>>>
>>>
>>>
>>> On 21/07/18 09:44, Thibaut wrote:
>>>>>
>>>>> Le 21 juil. 2018 à 09:24, John Crispin <john at phrozen.org> a écrit :
>>>>>
>>>>>
>>>>>
>>>>> On 19/07/18 20:08, Thibaut wrote:
>>>>>>>
>>>>>>> On 19 Jul 2018, at 19:52, Mathias Kresin <dev at kresin.me> wrote:
>>>>>>>
>>>>>>> 2018-07-19 19:26 GMT+02:00 Thibaut VARÈNE <hacks at slashdirt.org>:
>>>>>>>>
>>>>>>>> faf94d926e2810f895f2a98d4a49ee2fe8f673e8 added "support" for a
>>>>>>>> hacked
>>>>>>>> device where the original boot loader (routerboot) has been replaced
>>>>>>>> by u-boot.
>>>>>>>>
>>>>>>>> Support for this device with stock bootloader is possible (as
>>>>>>>> evidenced
>>>>>>>> by support for the RBM33G), and conflicts with this code.
>>>>>>>>
>>>>>>>> Remove code before release.
>>>>>>>>
>>>>>>>> Signed-off-by: Thibaut VARÈNE <hacks at slashdirt.org>
>>>>>>>
>>>>>>> FYI, I already NAK'ed the very same patch on github.
>>>>>>>
>>>>>>> I do agree that it can be done better by not requiring the
>>>>>>> replacement
>>>>>>> of the bootloader. Nevertheless, support for this board is already
>>>>>>> shipped since LEDE-17.01 and I don't agree to drop support for a
>>>>>>> board
>>>>>>> without providing an alternative/fixed/better image.
>>>>>>
>>>>>> Just to clarify: this is not “support”. This is a user created custom
>>>>>> hack that applies only to their modified board.
>>>>>>
>>>>>> T.
>>>>>> _______________________________________________
>>>>>> openwrt-devel mailing list
>>>>>> openwrt-devel at lists.openwrt.org
>>>>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>>>>
>>>>> Hi,
>>>>> I agree that proper support for none modified boards is far better and
>>>>> I am always for having such support in tree. what i am failing to understand
>>>>> here is why it is so important to remove this support or none-support patch
>>>>> from the tree ? in general our stance was that if there is at least one user
>>>>> we'll try to carry the functionality as long as we can. So why not remove
>>>>> this when a better replacement is in place ?
>>>>
>>>> Because there will be no replacement and I certainly don’t want to
>>>> confuse the end users into thinking there will be one.
>>>>
>>>> I don’t know yet another way to say this more clearly: this patch
>>>> doesn’t “drop support”: support was _never there_. There will be no
>>>> “replacement”: there is no upgrade path.
>>>>
>>>> What this patch does is dropping bad code. What there will be is proper,
>>>> correct NEW support for the hardware this code /pretends/ to offer support
>>>> for but doesn’t.
>>>>
>>>> At the end of the day the device covered by this code is a /different/
>>>> device than the one support will be provided for. It’s A Frankendevice, that
>>>> by the way doesn’t even pass the “hardware available?” question. The
>>>> installation instructions on the wiki do not even provision a way to revert
>>>> the hack.
>>>>
>>>> On a side note, if it’s a policy to support every user hack and
>>>> bastardized hardware for which there is only one user _in tree_, then we
>>>> have a fundamental difference in opinion and I’m afraid openwrt is then
>>>> inflicting on itself a maintenance nightmare it can’t afford.
>>>>
>>>> My 2c,
>>>> T
>>>
>>> well, that certainly killed the discussion ....
>>
>> Trying hard to explain my reasoning kills the discussion? I’m frankly
>> baffled.
>
> What John and others probably meant is that killing device support
> (replacing u-boot IMHO isn't "hardware mod" as You described(look at lantiq
> devices)) isn't best approach, instead if You have hardware in discussion
> You can help develop better support for questioned device and REPLACE/FIX
> it's implementation in OpenWRT.
>
> Every device hack/introduction to OpenWRT has to began somewhere.
>
>>
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list