| Message ID | 20180719172618.43863-2-hacks@slashdirt.org |
|---|---|
| State | Changes Requested |
| Delegated to: | John Crispin |
| Headers | show |
| Series | ramips: remove RB750GR3 support | expand |
2018-07-19 19:26 GMT+02:00 Thibaut VARÈNE <hacks@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@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. Same as with Thibauts other patches, this time I'll leave it up to someone else to make a call. Mathias
> On 19 Jul 2018, at 19:52, Mathias Kresin <dev@kresin.me> wrote: > > 2018-07-19 19:26 GMT+02:00 Thibaut VARÈNE <hacks@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@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.
On 19/07/18 20:08, Thibaut wrote: >> On 19 Jul 2018, at 19:52, Mathias Kresin <dev@kresin.me> wrote: >> >> 2018-07-19 19:26 GMT+02:00 Thibaut VARÈNE <hacks@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@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@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 ? John
> Le 21 juil. 2018 à 09:24, John Crispin <john@phrozen.org> a écrit : > > > > On 19/07/18 20:08, Thibaut wrote: >>> On 19 Jul 2018, at 19:52, Mathias Kresin <dev@kresin.me> wrote: >>> >>> 2018-07-19 19:26 GMT+02:00 Thibaut VARÈNE <hacks@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@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@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
On 21/07/18 09:44, Thibaut wrote: >> Le 21 juil. 2018 à 09:24, John Crispin <john@phrozen.org> a écrit : >> >> >> >> On 19/07/18 20:08, Thibaut wrote: >>>> On 19 Jul 2018, at 19:52, Mathias Kresin <dev@kresin.me> wrote: >>>> >>>> 2018-07-19 19:26 GMT+02:00 Thibaut VARÈNE <hacks@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@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@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 ....
> Le 21 juil. 2018 à 10:17, John Crispin <john@phrozen.org> a écrit : > > > > On 21/07/18 09:44, Thibaut wrote: >>> Le 21 juil. 2018 à 09:24, John Crispin <john@phrozen.org> a écrit : >>> >>> >>> >>> On 19/07/18 20:08, Thibaut wrote: >>>>> On 19 Jul 2018, at 19:52, Mathias Kresin <dev@kresin.me> wrote: >>>>> >>>>> 2018-07-19 19:26 GMT+02:00 Thibaut VARÈNE <hacks@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@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@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.
W dniu 21.07.2018 o 10:43, Thibaut pisze: > >> Le 21 juil. 2018 à 10:17, John Crispin <john@phrozen.org> a écrit : >> >> >> >> On 21/07/18 09:44, Thibaut wrote: >>>> Le 21 juil. 2018 à 09:24, John Crispin <john@phrozen.org> a écrit : >>>> >>>> >>>> >>>> On 19/07/18 20:08, Thibaut wrote: >>>>>> On 19 Jul 2018, at 19:52, Mathias Kresin <dev@kresin.me> wrote: >>>>>> >>>>>> 2018-07-19 19:26 GMT+02:00 Thibaut VARÈNE <hacks@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@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@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@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
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@gmail.com> wrote: > W dniu 21.07.2018 o 10:43, Thibaut pisze: > >> >>> Le 21 juil. 2018 à 10:17, John Crispin <john@phrozen.org> a écrit : >>> >>> >>> >>> On 21/07/18 09:44, Thibaut wrote: >>>>> >>>>> Le 21 juil. 2018 à 09:24, John Crispin <john@phrozen.org> a écrit : >>>>> >>>>> >>>>> >>>>> On 19/07/18 20:08, Thibaut wrote: >>>>>>> >>>>>>> On 19 Jul 2018, at 19:52, Mathias Kresin <dev@kresin.me> wrote: >>>>>>> >>>>>>> 2018-07-19 19:26 GMT+02:00 Thibaut VARÈNE <hacks@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@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@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@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
On 2018-07-19 19:52, Mathias Kresin wrote: > 2018-07-19 19:26 GMT+02:00 Thibaut VARÈNE <hacks@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@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. > > Same as with Thibauts other patches, this time I'll leave it up to > someone else to make a call. > > Mathias Indeed, a "Flash-and-Play" solution would be fine. But as replacing the bootloader and the uboot-config is a thing you think of twice. If you really want to change the software on this level. I did it on some devices an all running fine. Of course I copied the flash, via the mtd-device, on my hdd, to have a way back. Even this might require an external SPI-writer. As of the "advanced" installation-steps (in contrast to just uploading a factory.bin), I would leave it up to the user if he accepts the risk of a broken / incompatible board and to take the option to use this board by dropping support. Sven
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network b/target/linux/ramips/base-files/etc/board.d/02_network index 76b6fe9f50..981e001f64 100755 --- a/target/linux/ramips/base-files/etc/board.d/02_network +++ b/target/linux/ramips/base-files/etc/board.d/02_network @@ -200,7 +200,6 @@ ramips_setup_interfaces() jhr-n926r|\ mikrotik,rbm33g|\ mzk-wdpr|\ - rb750gr3|\ rt-n14u|\ tplink,c20-v4|\ tplink,c50-v3|\ diff --git a/target/linux/ramips/base-files/lib/ramips.sh b/target/linux/ramips/base-files/lib/ramips.sh index 5741cbd2ee..2dd0388426 100755 --- a/target/linux/ramips/base-files/lib/ramips.sh +++ b/target/linux/ramips/base-files/lib/ramips.sh @@ -418,9 +418,6 @@ ramips_board_detect() { *"R6220") name="r6220" ;; - *"RB750Gr3") - name="rb750gr3" - ;; *"RE350 v1") name="re350-v1" ;; diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh b/target/linux/ramips/base-files/lib/upgrade/platform.sh index ffdc5e73e0..59aca60ad0 100755 --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh @@ -129,7 +129,6 @@ platform_check_image() { psr-680w|\ px-4885-4M|\ px-4885-8M|\ - rb750gr3|\ re6500|\ rp-n53|\ rt5350f-olinuxino|\ diff --git a/target/linux/ramips/dts/RB750Gr3.dts b/target/linux/ramips/dts/RB750Gr3.dts deleted file mode 100644 index dc359b10bb..0000000000 --- a/target/linux/ramips/dts/RB750Gr3.dts +++ /dev/null @@ -1,125 +0,0 @@ -/dts-v1/; - -#include "mt7621.dtsi" - -#include <dt-bindings/input/input.h> -#include <dt-bindings/gpio/gpio.h> - -/ { - compatible = "mikrotik,rb750gr3", "mediatek,mt7621-soc"; - model = "MikroTik RB750Gr3"; - - memory@0 { - device_type = "memory"; - reg = <0x0 0x10000000>; - }; - - chosen { - bootargs = "console=ttyS0,57600"; - }; - - gpio-leds { - compatible = "gpio-leds"; - - pwr { - label = "rb750gr3:blue:pwr"; - gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>; - }; - - usr { - label = "rb750gr3:green:usr"; - gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>; - }; - }; - - gpio-keys-polled { - compatible = "gpio-keys-polled"; - #address-cells = <1>; - #size-cells = <0>; - poll-interval = <20>; - - mode { - label = "mode"; - gpios = <&gpio0 13 GPIO_ACTIVE_LOW>; - linux,code = <KEY_RFKILL>; - }; - - res { - label = "res"; - gpios = <&gpio0 18 GPIO_ACTIVE_LOW>; - linux,code = <KEY_RESTART>; - }; - }; - - gpio_export { - compatible = "gpio-export"; - #size-cells = <0>; - - buzzer { - gpio-export,name = "buzzer"; - gpio-export,output = <0>; - gpios = <&gpio0 15 GPIO_ACTIVE_HIGH>; - }; - - usb { - gpio-export,name = "usb"; - gpio-export,output = <1>; - gpios = <&gpio0 12 GPIO_ACTIVE_HIGH>; - }; - }; -}; - -&spi0 { - status = "okay"; - - m25p80@0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "jedec,spi-nor"; - reg = <0>; - spi-max-frequency = <10000000>; - m25p,chunked-io = <32>; - - partition@0 { - label = "u-boot"; - reg = <0x0 0x30000>; - read-only; - }; - - partition@30000 { - label = "u-boot-env"; - reg = <0x30000 0x10000>; - read-only; - }; - - factory: partition@40000 { - label = "factory"; - reg = <0x40000 0x10000>; - read-only; - }; - - partition@50000 { - label = "firmware"; - reg = <0x50000 0xfb0000>; - }; - - }; -}; - -ðernet { - mtd-mac-address = <&factory 0xe000>; - mtd-mac-address-increment = <1>; -}; - -&pinctrl { - state_default: pinctrl0 { - gpio { - ralink,group = "i2c", "uart2", "uart3", "pcie", "rgmii2", "jtag"; - ralink,function = "gpio"; - }; - }; -}; - -&sdhci { - status = "okay"; -}; diff --git a/target/linux/ramips/image/mt7621.mk b/target/linux/ramips/image/mt7621.mk index e9e2d3ecef..3d1a26e00c 100644 --- a/target/linux/ramips/image/mt7621.mk +++ b/target/linux/ramips/image/mt7621.mk @@ -225,14 +225,6 @@ define Device/r6220 endef TARGET_DEVICES += r6220 -define Device/rb750gr3 - DTS := RB750Gr3 - IMAGE_SIZE := $(ralink_default_fw_size_16M) - DEVICE_TITLE := MikroTik RB750Gr3 - DEVICE_PACKAGES := kmod-usb3 uboot-envtools -endef -TARGET_DEVICES += rb750gr3 - define Device/mikrotik_rbm33g DTS := RBM33G BLOCKSIZE := 64k
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@slashdirt.org> --- .../linux/ramips/base-files/etc/board.d/02_network | 1 - target/linux/ramips/base-files/lib/ramips.sh | 3 - .../ramips/base-files/lib/upgrade/platform.sh | 1 - target/linux/ramips/dts/RB750Gr3.dts | 125 --------------------- target/linux/ramips/image/mt7621.mk | 8 -- 5 files changed, 138 deletions(-) delete mode 100644 target/linux/ramips/dts/RB750Gr3.dts