ramips: add Netgear EW-7476RPC
SoC: MediaTek MT7620a @ 580MHz
RAM: 64M (Winbond W9751G6KB-25)
FLASH: 8MB (Macronix)
WiFi: SoC-integrated: MediaTek MT76620a bgn
WiFi: MediaTek MT7612EN nac
GBE: RTL8211E
BTN: WPS - RFKILL/RF 50%/RF 100% toggle
LED: - Wifi 5g (blue)
- Wifi 2g
;> implement the phy-reset via GPIO#39.
>> See my comments in the code (I commented the first device only, same
>> applies to the 2nd device as well).
>>
>> On Mon, May 27, 2019 at 05:55:24PM +0200, Birger Koblitz wrote:
>>> ramips: add Netgear EW-7476RPC
This is a t
I managed to get OpenWRT running on the Edimax EW-7476RPC, which is also
sold for great value for money under the name Renkforce RF-WR-1200RF
WLAN Repeater.
AFAIK all the hardware works properly.
The model is also compatible with the newer EW-7478AC, at least the
firmware can be
Hi,
On 26.05.19 19:28, Cezary Jackiewicz wrote:
>> + ucidef_set_led_netdev "lan" "lan" "$boardname:green:internet" "eth0"
>> +;;
> Also working:
>
> ucidef_set_led_switch "lan" "lan" "$boardname:green:lan" "switch0" "0x20"
>
> (if you rename internet to lan)
>
Are you sure
Hi,
I'll work on all the open points and add the device description. Then I'll
submit the next version of the patch.
Birger
On 26 May 2019 19:28:56 CEST, Cezary Jackiewicz
wrote:
>Hi,
>typo:
>
>> ;;
>> +edimax,ew-7476rpc) \
>> +edimax,ew-7478ac)
>
>edimax,ew-7476rpc| \
On 26.05.19 22:46, Cezary Jackiewicz wrote:
> Dnia 2019-05-26, o godz. 22:16:30
> Birger Koblitz napisał(a):
>
>> Hi,
>>
>> On 26.05.19 19:28, Cezary Jackiewicz wrote:
>>>> + ucidef_set_led_netdev "lan" "lan" "$boardname:gree
Hi Daniel,
I have tried in vain to implement your suggestions. I am stuck and need
some help:
On 27.05.19 18:43, Daniel Golle wrote:
>>> +
>>> + {
>>> + state_default: pinctrl0 {
>>> + gpio {
>>> + // might need pin 39: ;
>>> + ralink,group =
on power on and send firmware via tftp to 192.168.1.6
The EW-7478AC is identical to the EW-7476RPC, except instead of 2
internal antennas it has 2 external ones.
Signed-off-by: Birger Koblitz
diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds
b/target/linux/ramips/base-files/etc
on power on and send firmware via tftp to 192.168.1.6
The EW-7478AC is identical to the EW-7476RPC, except instead of 2 internal
antennas it has 2 external ones.
Signed-off-by: Birger Koblitz
diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds
b/target/linux/ramips/base-files/etc
ramips: add Edimax EW-7476RPC
SoC: MediaTek MT7620a @ 580MHz
RAM: 64M (Winbond W9751G6KB-25)
FLASH: 8MB (Macronix)
WiFi: SoC-integrated: MediaTek MT7620a bgn
WiFi: MediaTek MT7612EN nac
GbE: 1x (RTL8211E)
BTN: WPS - RFKILL/RF 50%/RF 100% toggle
LED: - Wifi 5g (blue)
- Wifi
3.3V is the square pad
Installation
Update the factory image via the web-interfaces (by default:
http://edimax.setup)
Signed-off-by: Birger Koblitz
---
diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds
b/target/linux/ramips/base-files/etc/board.d/01_leds
index
3.3V is the square pad
Installation
Update the factory image via the web-interfaces (by default:
http://edimax.setup)
Signed-off-by: Birger Koblitz
---
Corrected formatting as requested by ynezz, changed gpio-export used for
powering USB bus to using gpio-hog.
diff --git a/target
)
The sysupgrade image can be installed via TFTP from
the U-Boot bootloader. Connect ethernet port 2.
Signed-off-by: Birger Koblitz
---
The build was tested and all hardware works as expected.
The original firmware uses the 4 LEDs in sync with different
flashing patterns to signal router state
starts blinking slowly.
Upload factory image via tftp put, the router's ip is 192.168.1.1
and expects the client on 192.168.1.75.
The images also work on the Asus RT-AC65P models as tested by Gabor.
Signed-off-by: Birger Koblitz
Tested-by: Gabor Varga
---
v2: Corrected sorting of entries
#1366 or
https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.
This patch converts all remaining lantiq .dts(i) files which were
using export-gpio, not making use of the change-direction functionality
and not used from user-space to using gpio_hog instead
Signed-off-by: Birger Koblitz
as Kresin wrote:
>> 02/08/2019 11:58, Birger Koblitz:
>>> ramips: use gpio_hog instead of gpio-export
>>>
>>> The `gpio-export` functionality is a hack for
>>> missing kernel functionality, which was rejected in upstream kernel
>>> long
>>> ti
Dear Adrian,
I'll resubmit a patch taking your comments into account. I am using a
script that parses the DTS and I will use more of the original line-name
to name the node, i.e.
"tp-link:power:usb" -> power-usb
"tp-link:reset:sr" -> reset-sr
This should also prevent the double naming of the
Hi Adrian,
On 11.08.19 21:15, m...@adrianschmutzler.de wrote:
>> -Original Message-
>> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
>> On Behalf Of Birger Koblitz
>> Sent: Sonntag, 11. August 2019 13:11
>> To: m...@adrianschmutzler.
Dear Martin and Enrico,
thanks for your comments.
On 11.08.19 13:38, Martin Blumenstingl wrote:
> On Sun, Aug 11, 2019 at 1:00 PM Birger Koblitz wrote:
>> I'll go through the patches and remove anything that sounds like it
>> might need user space configuration (i.e. not po
, Daniel Golle wrote:
> Hi,
>
> I believe the PCI-IDs of the devices in your device tree are wrong,
> see below:
>
> On Sun, Jul 21, 2019 at 07:43:51AM +0200, Birger Koblitz wrote:
>> ramips: add Edimax RG21S
>>
>> SoC: MediaTek MT7621AT dual-core @ 880MHz
>
)
The sysupgrade image can be installed via TFTP from
the U-Boot bootloader. Connect ethernet port 2.
Signed-off-by: Birger Koblitz
---
v3: Update to DEVICE_VENDOR / DEVICE_MODEL in mt7621.mk
renamed .dts according to new conventions
Removed memory node from .dts
Correct image size
Whitespace
press reset button and keep pressed
until power LED starts blinking slowly.
Upload factory image via tftp put, the router's ip is 192.168.1.1
and expects the client on 192.168.1.75.
The images also work on the Asus RT-AC65P models as tested by Gabor.
Signed-off-by: Birger Koblitz
Tested
press reset button and keep pressed
until power LED starts blinking slowly.
Upload factory image via tftp put, the router's ip is 192.168.1.1
and expects the client on 192.168.1.75.
The images also work on the Asus RT-AC65P models as tested by Gabor.
Signed-off-by: Birger Koblitz
Tested
://192.168.1.1)
The sysupgrade image can be installed via TFTP from
the U-Boot bootloader. Connect ethernet port 2.
Signed-off-by: Birger Koblitz
---
v3: Update to DEVICE_VENDOR / DEVICE_MODEL in mt7621.mk
renamed .dts according to new conventions
Removed memory node from .dts
Correct image
Hi,
On 23.08.19 11:04, Gábor Varga wrote:
> Hi!
>
> Although it looks like the Asus RT-AC85P and the Asus RT-AC65P models
> are identical, but I have separated them into two dts and have
> introduced the HW version into the names (for the new versions in the
> future).
Are you sure that is
#1366 or
https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.
This patch converts all ramips .dts(i) files which were
using export-gpio for powering USB/SATA ports to using gpio_hog instead
Signed-off-by: Birger Koblitz
---
v2: Limited conversion to only usb ports/hubs and sata
press reset button and keep pressed
until power LED starts blinking slowly.
Upload factory image via tftp put, the router's ip is 192.168.1.1
and expects the client on 192.168.1.75.
The images also work on the Asus RT-AC65P models as tested by Gabor.
Signed-off-by: Birger Koblitz
Tested
press reset button and keep pressed
until power LED starts blinking slowly.
Upload factory image via tftp put, the router's ip is 192.168.1.1
and expects the client on 192.168.1.75.
The images also work on the Asus RT-AC65P models as tested by Gabor.
Signed-off-by: Birger Koblitz
Tested
press reset button and keep pressed
until power LED starts blinking slowly.
Upload factory image via tftp put, the router's ip is 192.168.1.1
and expects the client on 192.168.1.75.
The images also work on the Asus RT-AC65P models as tested by Gabor.
Signed-off-by: Birger Koblitz
Tested
On 15.09.19 12:31, m...@adrianschmutzler.de wrote:
> Hi,
>
> see additions to the newer-ending-story below.
Well, at least in fiction it made for an excellent book. Not sure in
engineering never-ending stories are so great.
>> + {
>> +wifi0: wifi@0,0 {
>> +compatible =
#1366 or
https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.
This patch converts all remaining ramips .dts(i) files which were
using export-gpio and not making use of the change-direction functionality
to using gpio_hog instead
Signed-off-by: Birger Koblitz
---
diff --git a/target
#1366 or
https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.
This patch converts all remaining lantiq .dts(i) files which were
using export-gpio and not making use of the change-direction functionality
to using gpio_hog instead
Signed-off-by: Birger Koblitz
---
diff --git a/target
#1366 or
https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.
This patch converts all remaining ath79 .dts files which were
using export-gpio to using gpio_hog instead
Signed-off-by: Birger Koblitz
---
diff --git a/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts
b/target
)
The sysupgrade image can be installed via TFTP from
the U-Boot bootloader. Connect ethernet port 2.
Signed-off-by: Birger Koblitz
---
v2: Update to DEVICE_VENDOR / DEVICE_MODEL in mt7621.mk
renamed .dts according to new conventions
diff --git a/target/linux/ramips/base-files/etc/board.d
@lists.openwrt.org]
>> On Behalf Of Birger Koblitz
>> Sent: Samstag, 20. Juli 2019 12:49
>> To: openwrt-devel@lists.openwrt.org
>> Subject: [OpenWrt-Devel] [PATCH v2] ramips: add support for Edimax RG21S
>>
>> ramips: add Edimax RG21S
>>
>
> Some
)
The sysupgrade image can be installed via TFTP from
the U-Boot bootloader. Connect ethernet port 2.
Signed-off-by: Birger Koblitz
---
v3: Update to DEVICE_VENDOR / DEVICE_MODEL in mt7621.mk
renamed .dts according to new conventions
Removed memory node from .dts
Correct image size
button and keep pressed
until power LED starts blinking slowly.
Upload factory image via tftp put, the router's ip is 192.168.1.1
and expects the client on 192.168.1.75.
Signed-off-by: Birger Koblitz
---
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips
Hi,
On 20.07.19 22:15, m...@adrianschmutzler.de wrote:
> Hi,
>
>> -Original Message-
>> MAC: The MAC address on the router-label matches the MAC of
>> the 2.4 GHz WiFi.
>> LAN and WAN MAC are identical: MAC_LABEL+4
>> 5 GHz WiFi MAC: also MAC_LABEL+4
>
> That's a nice
Hi Adrian,
On 20.07.19 21:57, m...@adrianschmutzler.de wrote:
> Hi,
>
> sorry, me again:
>
>> +model = "RG21S";
>
> "Edimax RG21S"
Yes, of course. Will fix.
>
>> +keys {
>> +compatible = "gpio-keys-polled";
>> +poll-interval = <20>;
>
> Interrupt-driven
button and keep pressed
until power LED starts blinking slowly.
Upload factory image via tftp put, the router's ip is 192.168.1.1
and expects the client on 192.168.1.75.
Signed-off-by: Birger Koblitz
---
v2: Corrected sorting of entries in 02_network
Model name corrected in .dts
)
The sysupgrade image can be installed via TFTP from
the U-Boot bootloader. Connect ethernet port 2.
Signed-off-by: Birger Koblitz
---
v3: Update to DEVICE_VENDOR / DEVICE_MODEL in mt7621.mk
renamed .dts according to new conventions
Removed memory node from .dts
Correct image size
://192.168.1.1)
The sysupgrade image can be installed via TFTP from
the U-Boot bootloader. Connect ethernet port 2.
Signed-off-by: Birger Koblitz
---
v3: Update to DEVICE_VENDOR / DEVICE_MODEL in mt7621.mk
renamed .dts according to new conventions
Removed memory node from .dts
Correct image
Thanks Adrian for taking this up again!
Birger
On 5 November 2019 16:12:02 CET, Adrian Schmutzler
wrote:
>From: Birger Koblitz
>
>The gpio-export functionality is a hack for missing kernel
>functionality, which was rejected in upstream kernel long time ago,
>for details see t
19.
>dec.
>10., K, 12:39):
>
>> Hi,
>>
>> have you verified this for both devices (rt-ac65p and rt-ac85p)?
>>
>> I've added Birger Koblitz to recipients (RT-AC85P author).
>>
>> Best
>>
>> Adrian
>>
>> > -Original
:25:00 CET, Birger Koblitz wrote:
>Dear all,
>
>I'll check this this evening. Maybe I got the numbers backwards. The
>router's leds are labelled in the sequence 4 to 1 while the ports are
>numbered 1-4 at the back...
>
>Birger
>
>
>On 10 December 2019 14:16:55 CET,
No. I think this is a bug.
Birger
On 25 October 2019 12:26:34 CEST, Adrian Schmutzler
wrote:
>Hi,
>
>> +led_power: power {
>> +label = "rt-ac85p:blue:power";
>> +gpios = < 4 GPIO_ACTIVE_LOW>;
>> +linux,default-trigger =
Hi,
It is not necessary to enable swconfig for this target. I initially enabled it
because luci was checking for
the swconfig binary in order to show switch information at all. This is no
longer necessary.
Birger
On 20.11.20 06:12, Rosen Penev wrote:
> On Thu, Nov 19, 2020 at 8:37 PM Rosen
This fixes the build problems for the REALTEK target by adding a proper
configuration
option for the phy module.
Signed-off-by: Birger Koblitz https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
> Hi,
>
> Thank you for the links, I was not aware of this strange problem.
>
> Do you have access to a documentation of any of these chips or only some
> source code?
>
> We could add some special handling for these chips in the failsafe mode, let
> me look into this.
>
> Hauke
>
Hi,
> Hi,
>
> the hardware documentation is very poor, not much more than advertisement for
> the SoCs, e.g. for the RTL8380
> https://manualzz.com/doc/31627850/draft-datasheet
> it does not mention these special VLAN properties.
>
> All the code is based on the GPL drops. However, the latest
Hi,
On 19.06.21 14:25, Hauke Mehrtens wrote:
> Hi,
>
> I am unable to send and receive packets directly on the lan1 interface when
> it is not part of a bridge.
>
> In wireshark on a connected host I do not see any packets from this device,
> but the link is up.
>
> When I use OpenWrt's
yes, counters are reset on every read.
I guess I should have learned to do more vlan-testing.
I'll try to figure out what is going on.
Birger
On 08/05/2021 17:39, Bjørn Mork wrote:
Birger Koblitz writes:
I tested the latest master on my 3 Zyxel devices, one for each SoC
generation
Hi,
Actually, you don't have to disable the profile_setups. This change is
sufficient to make VLANs work (at least in the limited testing I've done):
diff --git a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c
realtek: Fix VLAN issues introduced by multicast patches
This adds the CPU port to the unknown multicast flooding port mask,
which fixes the VLAN issues introduced by the multicast group patches
Signed-off-by: Birger Koblitz
---
diff --git a/target/linux/realtek/files-5.4/drivers/net/dsa
by the kernel.
It also fixes detection of the DSA tag for packets on RTL8390
SoCs for ports > 28.
Signed-off-by: Birger Koblitz
---
diff --git a/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c
b/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c
index c5c6e3b
On 08/05/2021 17:39, Bjørn Mork wrote:
But I'm not convinced it works so well for the default either... I see
this received on the native VLAN 1:
canardo:/tmp# tshark -nVi xeth0 -f 'udp port 67'
Running as user "root" and group "root". This could be dangerous.
Capturing on 'xeth0'
Frame 1:
Dear Russel,
depending on how a particular device was configured previously by
u-boot, this commit might have enabled proper vlan-filtering for the
first time on your device. The default vlan-configuration has port 1
configured as management port with vlan-id 100. So your DHCP server
would
realtek: Fix VLAN issues introduced by multicast patches
This adds the CPU port to the unknown multicast flooding port mask,
which fixes the VLAN issues introduced by the multicast group patches
Signed-off-by: Birger Koblitz
---
v2: fixed typo in "unknown"
diff --git a/target/lin
On 11/05/2021 19:51, Rafał Miłecki wrote:
On 11.05.2021 19:46, John Crispin wrote:
On 11.05.21 19:45, Rafał Miłecki wrote:
I'm really tired of dealing with such hacky solutions. Look at netifd,
DSA and LuCI as example. We ended up with something that noone fully
understands. Jo - our UI guru -
he only critical one for the multicast is
the setup of the vlans in the loop below
// Initialize all vlans 0-4095
Birger
||
On 08/05/2021 15:32, Bjørn Mork wrote:
Birger Koblitz writes:
Dear Russel,
depending on how a particular device was configured previously by
u-boot, this commit might
Hi,
I messed up the whitespace, sorry!
Will send v2.
Birger
On 05.06.21 22:14, Hauke Mehrtens wrote:
> On 5/9/21 7:32 PM, Birger Koblitz wrote:
>> realtek: Fix buffer length calculation on RTL8380 with CRC offload
>>
>> Fixes the buffer and packet length calcula
by the kernel.
It also fixes detection of the DSA tag for packets on RTL8390
SoCs for ports > 28.
v2 has correct whitespace
Signed-off-by: Birger Koblitz
---
diff --git a/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c
b/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_et
Hi Hauke,
it looks as if there could be a more elegant solution to this, tomn just posted
this on the forum:
https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875
I did not have time to test it so far, though.
Birger
On 22/06/2021 00:45, Hauke Mehrtens wrote:
The
Tested and is necessary to e.g. read out temperatures from an SFP module.
Please merge,
Birger
On 09/03/2021 22:12, Bjørn Mork wrote:
Signed-off-by: Bjørn Mork
---
target/linux/realtek/config-5.4 | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/linux/realtek/config-5.4
ACK. Please apply.
Birger
On 09/03/2021 22:12, Bjørn Mork wrote:
There is no need to define a static link or a phy for the sfp
ports. Using phy-mode and managed properties to describe the
link to the sfp phy.
We have to keep the now unconnected virtual "phys" because the
switch driver uses
Indeed, this fixes a stupid typo that prevents the IRQ to be correctly
configured.
Please apply.
Birger
On 09/03/2021 22:12, Bjørn Mork wrote:
This bug was the root cause for the failing sfp driver.
Signed-off-by: Bjørn Mork
---
.../realtek/files-5.4/drivers/net/dsa/rtl83xx/common.c |
Tested and it indeed fixes the problem that SFPs report this mode when
configures their serdes.
Please apply,
Birger
On 09/03/2021 22:12, Bjørn Mork wrote:
Signed-off-by: Bjørn Mork
---
target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/dsa.c | 1 +
1 file changed, 1 insertion(+)
ACK, please merge,
Birger
On 09/03/2021 22:12, Bjørn Mork wrote:
This allows copper SFPs to negotiate speeds lower than 1gig.
Signed-off-by: Bjørn Mork
---
.../drivers/net/dsa/rtl83xx/common.c | 4 +-
.../files-5.4/drivers/net/dsa/rtl83xx/dsa.c | 41 ++-
2
Run tested by me on a DGS1210-10P.
Please merge,
Birger
On 09/03/2021 22:18, Bjørn Mork wrote:
From: John Crispin
Signed-off-by: John Crispin
Signed-off-by: Bjørn Mork
---
This is John's simple PoE daemon for the realtek devices, which has been
cycling around in assorted repos since last
Hi,
On 25.02.21 07:56, Stefan Lippers-Hollmann wrote:
> Hi
>
> I'm wondering if this attempt to deal the gs1900 switch family really
> improves the situation for these devices. While IMAGE_SIZE and
> UIMAGE_MAGIC might indeed by rather generic to most (all?) members of
At least for the GS1900-48
This has my full support, even as a developer I had trouble getting Realtek
devices to work in the default configuration.
For OpenWRT users it is very confusing that these devices do not have a
standard setup and the user first has to learn about VLANs to make use of the
devices.
Birger
On
Hi,
I tested this on a Renkforce WS-WN575A2 and it works nicely.
What I looked at was partitioning, GPIOs, WiFi and Switch setup.
Would it be possible to add an ALT1_VENDOR for this Renkforce device?
You may add a "Tested-by".
Cheers,
Birger
On 05/07/2021 18:12, dev.aldr...@gmail.com wrote:
Hi,
On 05/10/2021 22:59, Sander Vanheule wrote:
One alternative could be to create some extra driver(s) in OpenWrt already, to
get rid of
setup.c (and prom.c at some later point) and work towards the upstream base for
RTL838x/RTL839x. Anyone else with an opinion on this?
That's a good idea.
Nice work!
ACK
Birger
On 06/11/2021 15:52, Sander Vanheule wrote:
Backport and enable the Realtek Otto watchdog driver for enhanced system
reliability. The watchdog driver can also be used to restart the system,
but that requires the _machine_restart to be removed.
Removing _machine_restart
Hi Sander,
On 06/11/2021 20:47, Sander Vanheule wrote:
With some extra testing, I have found that the network port that was active
before a
watchdog reset, doesn't do much anymore after restarting. Replugging the cable
into a port
that was not used before the reset works, but that's not
Hi,
thanks for the quick reply.
On 09.12.21 10:38, Sander Vanheule wrote:
> Hi Birger,
>
>>
>> I would suggest to use sub-targets for these platforms with optimized
>> compiler settings and SMP/single processor selected correctly for each,
>> see
Hi,
On 12.12.21 20:51, Sander Vanheule wrote:
> Hi Sebastian,
>
> On Sun, 2021-12-12 at 12:38 +0100, Sebastian Gottschall wrote:
>>
>>> I have not experienced a single lock-up when booting with this patch, but I
>>> also
>>> didn't
>>> stress-test the machine or even used the switch part. Do
Hi,
On 09.12.21 22:26, Sander Vanheule wrote:
> This patch series is intended to reduce the maintenance burden, without
> introducing
> breaking changes to devices already in OpenWrt. No promises are made for
> out-of-tree code.
This patch will unfortunately considerably increase the
Hi Sander and Hiroshi,
great work! A very big step to clean up this platform. Because this changes
the fundamentals of the target I have some suggestions and questions.
There are actually 4 RTL platforms which we now know how to support and you
are taking care of the first 3 in your patch to
behaviour. Maybe the WN578A2 profile would be
better suited?
At least that's my oppinion. If anyone else wants to advise, go ahead.
Regards,
Thomas
On Thu, 2021-07-15 at 10:32 +0200, Birger Koblitz wrote:
Hi,
I tested this on a Renkforce WS-WN575A2 and it works nicely.
What I looked
for 10 seconds. Connect web-browser to 192.168.10.1
and upload sysupgrade image. Flash uploaded image and wait
about 2 minutes for reboot.
Signed-off-by: Birger Koblitz
---
Version v2: The LED visible through the casing window is in fact a bi-
color LED. Support it.
.../dts
Hi,
CONFIG_SFP should only depend on CONFIG_MDIO_SMBUS on the RTL93xx platforms.
This is because only on those platforms there is hardware support for an SMBus
controller which is used for the MDIO of the SFP ports.
If we had known about the worning, then we would have tried to fix it by
making
Hi Bjørn,
On 15.03.22 15:10, Bjørn Mork wrote:
> Bjørn Mork writes:
>
>> Just drop the unnecssary I2C_SMBUS dependency. AFAICS, you're only
>> using i2c_smbus_xfer() which is part of the i2c core.
The reason for the ifdefs were mdio_smbus_alloc().
>
> Looking further at this, I believe there
Hi,
On 14.03.22 23:53, Hauke Mehrtens wrote:
> On 3/14/22 06:56, Birger Koblitz wrote:
>> Hi,
>>
>> CONFIG_SFP should only depend on CONFIG_MDIO_SMBUS on the RTL93xx platforms.
>> This is because only on those platforms there is hardware support for an
>>
Hi,
On 15.03.22 13:32, Bjørn Mork wrote:
> Birger Koblitz writes:
> Yuck!
>
> Why the heck can't this be made generic, auto-configured by DTS props
> and upstreamed? There is a reason for this, you know:
>
> bjorn@miraculix:/usr/local/src/git/linux$ git grep -E '^#ifde
Hi Petr,
there is a v2 of this patch which I sent yesterday at 18:31 to the list.
I applied what I sent then as a patch and it works for me.
It fixes the subject by adding a ramips tag and adds a second LED, which
I did not notice initially.
Cheers,
Birger
On 08.03.22 18:31, Petr Štetiar
Hi,
On 21/02/2022 10:04, Sander Vanheule wrote:
anymore. Even if it would work with the current driver, once the RTL8231 is
controlled through an MDIO bus (from a kernel perspective), things might change.
For me that would be a reason not to do it that way, because we will not be able
to
good reason to believe the 839x platform does not entirely fix this.
So the watchdog should be avoided if there is another way to reset the device.
Cheers,
Birger
On 20/02/2022 21:25, Daniel Golle wrote:
On Sun, Feb 20, 2022 at 09:13:24PM +0100, Birger Koblitz wrote:
Hi,
during development I
Hi,
I just checked with my multimeter, and while the GPIO5 on the RTL8231 does go
high/low
when I set the output high/low from Linux, my device certainly doesn't reset.
The other
GPIO lines on the chip do work, since SFP modules are correctly detected.
Birger, just to be sure, can you
ET_PHY
INT 22 IN 11RST_BTN_OUT
I also tested this in u-boot and toggling that output 21 definitely
only resets the PHYs (port leds turn off), not the entire board.
Cheers,
Birger
On 22/02/2022 23:00, Sander Vanheule wrote:
On Mon, 2022-02-21 at 21:23 +0100, Birger Kob
sue
with lock
contention.
Cheers,
Birger
On 24/02/2022 21:19, Sander Vanheule wrote:
On Tue, 2022-02-22 at 23:39 +0100, Birger Koblitz wrote:
Hi,
the information on the external GPIO resetting the board of
the Zyxel GS1900-48 comes from the hardware configuration
reported by the stock firmw
-by: Bjørn Mork
Signed-off-by: Birger Koblitz
---
.../realtek/files-5.10/drivers/net/ethernet/rtl838x_eth.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/target/linux/realtek/files-5.10/drivers/net/ethernet/rtl838x_eth.c
b/target/linux/realtek/files-5.10/drivers/net
Hi,
On 01/03/2022 22:11, Daniel Golle wrote:
We may need to add a 'switch' DEVICE_TYPE in include/target.mk
selecting packages relevant for this class of devices.
('bridge' or 'ip-full', 'ethtool', ...)Indeed, these devices are really not
routers. Let's have the right
packages for them
seconds. Connect web-browser to 192.168.10.1
and upload sysupgrade image. Flash uploaded image and wait
about 2 minutes for reboot.
Signed-off-by: Birger Koblitz
---
.../dts/mt7621_renkforce_ws-wn530hp3-a.dts| 154 ++
target/linux/ramips/image/mt7621.mk
Hi,
during development I came across situations where the RTL839x
SoC's own reset did not always completely reset its state.
U-Boot was no longer able to boot via tftp afterwards.
This is the same situation we see on the RTL838x.
While users will hopefully never mess up the SoC as during
Hi,
sounds good to me!
Birger
On 25/03/2022 14:38, Hauke Mehrtens wrote:
Based on the discussion on the previews patch set I added a patch to
remove dnsmasq and odhcpd-ipv6only. I hope this is an adaptable middle
ground. I really would like to remove the old firewall3 here.
We should
Hi,
The layer 2 (MAC, VLAN, Ethernet frame contents) offloading in Linux is normally done over tc and not nftabels. With flower you can filter, redirect and modify packets based on VLAN IDs, VLAN PCP, MAC
addresses, .. and so on. qdisc allows to configure traffic schedulers to do advance QoS
Hi,
On 23/03/2022 21:09, Sander Vanheule wrote:
Hi everyone,
One extra argument in favour of keeping the firewall in the default config, is
that the
devices with more advanced stock FW also provide an ACL feature to filter out
traffic
based on MAC, IP, ethernet frame contents, etc.
This fixes a bug where frames sent to the switch itself were
flooded to all ports unless the MAC address of the CPU-port
was learned otherwise.
Tested-by: Wenli Looi
Tested-by: Bjørn Mork
Signed-off-by: Birger Koblitz
---
.../linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c | 6
Oops, I was trying to do too many things at the same time
Please forget that and I shall resend the email properly.
Birger
On 24.04.22 20:30, Bjørn Mork wrote:
> That subject doesn't look quite right?
>
>
> Bjørn
>
___
openwrt-devel mailing
1 - 100 of 121 matches
Mail list logo
