On 7/23/22 22:53, Jan Hoffmann wrote:
Move RTL8214FC power configuration to newly created suspend and resume
methods. A media change now only results in power configuration if the
PHY is not suspended, to avoid powering up a port when the interface is
currently not up.
While at it, remove the
On 7/23/22 22:53, Jan Hoffmann wrote:
Don't use udelay to allow other kernel tasks to execute if the kernel
has been built without preemption. Also determine the timeout based on
jiffies instead of loop iterations.
Tested on a D-Link DGS-1210-16.
On 7/23/22 22:53, Jan Hoffmann wrote:
Probe the SFP module during PHY initialization and implement
insertion/removal handlers to automatically configure the media type
of the respective port.
Tested on a D-Link DGS-1210-16, which however needs updated .dts to make
use of this feature.
Hi Sander,
On 7/17/22 15:37, Sander Vanheule wrote:
On Sat, 2022-07-16 at 23:09 +0200, Birger Koblitz wrote:
Hi,
On 7/16/22 21:31, Sander Vanheule wrote:
On Sat, 2022-07-16 at 21:09 +0200, Sander Vanheule wrote:
This RFC series introduces a new MFD device for the switch core found
Hi,
On 7/17/22 11:55, Paul Fertser wrote:
On Sat, Jul 16, 2022 at 11:32:52PM -0300, Luiz Angelo Daros de Luca wrote:
It uses SOC := rtl8380 while all existing dgs-1210 F1 variants use
rtl8382 (except for the pending -52 variant). The commit didn't
mention why that happened.
It's just
Hi,
On 7/16/22 21:31, Sander Vanheule wrote:
On Sat, 2022-07-16 at 21:09 +0200, Sander Vanheule wrote:
This RFC series introduces a new MFD device for the switch core found
in the Realtek SoCs. Currently only an implementation is provided for
RTL8380, but it written with the register structure
On 19/06/2022 13:46, Sander Vanheule wrote:
Priority values passed to the egress (TX) frame header initialiser are
invalid when smaller than 0, and should not be assigned to the frame.
Queue assignment is then left to the switch core logic.
Current code for RTL83xx forces the passed priority
Hi,
On 19.06.22 10:56, Sander Vanheule wrote:
> - h->cpu_tag[1] = h->cpu_tag[2] = 0;
> - if (prio >= 0)
> - h->cpu_tag[2] = BIT(13) | prio << 8; // Enable and set Priority
> Queue
> + h->cpu_tag[1] = 0;
> + /* Enable (AS_QID) and set Priority Queue (QID) */
> +
Hi,
dest_port -1 means flood all ports with a broadcast packet in the tx routine,
the tag functions can only be called with dest_port >= 0, however.
In the case of broadcast packets there should not be a CPU-tag with a
destination port,
or all bits in the destination port mask would need to be
Hi Arinc,
yes, this would be what I suggest.
Cheers,
Birger
On 13.06.22 13:32, Arinc UNAL (Xeront) wrote:
> Hey Birger,
>
> On 09/06/2022 14:30, Birger Koblitz wrote:
>> Hi Arinc,
>>
>> very well spotted! If I could make a suggestion, the RTL93xx tag generation
>
Hi Arinc,
very well spotted! If I could make a suggestion, the RTL93xx tag generation
functions have the opposite problem, i.e. rtl930x_decode_tag() and
rtl931x_decode_tag() do not do the check for the destination port being >= 0,
i.e. defined and the packet not being a broadcast packet.
So I
Hi,
On 07.06.22 11:10, Sander Vanheule wrote:
> On Tue, 2022-06-07 at 10:24 +0200, Birger Koblitz wrote:
>> Hi,
>>
>> at least for the RTL931x, removing the rtl931x_setup() is not a good idea as
>> the WDT reset does
>> not work for that architecture.
>&
Hi,
On 07.06.22 11:04, Sander Vanheule wrote:
> On Tue, 2022-06-07 at 10:15 +0200, Birger Koblitz wrote:
>> Hi,
>>
>> has anyone tested that???
>
> I don't have any 931x hardware, but it is based on what you put into setup.c.
What is in the setup.c makes the System L
Hi,
at least for the RTL931x, removing the rtl931x_setup() is not a good idea as
the WDT reset does not work for that architecture.
The only way to get a working reset is via registering a reset handler:
static void __init rtl931x_setup(void)
{
pr_info("Registering _machine_restart\n");
Hi,
has anyone tested that??? This does not make sense at all, there is no LED
disable
in the LED_GLB_CTRL register. Instead one needs to use
RTL9310_MAC_L2_GLOBAL_CTRL2
The following works nicely on the XS1930 and Edgecore:
pinmux: pinmux@1b001358 {
compatible =
Hi,
the TLS certificate expired on the forum
Valid: Not After Thu, 12 May 2022 04:05:04 GMT
Cheers,
Birger
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Thanks a lot Sander, helpful and efficient!
Cheers,
Birger
On 11.05.22 22:26, Sander Vanheule wrote:
> Hi Birger,
>
> On Sun, 2022-05-08 at 16:53 +0200, Birger Koblitz wrote:
>> Hi,
>>
>> On 08.05.22 13:11, Sander Vanheule wrote:
>>> Hi,
>>>
&
Hi,
On 08.05.22 13:11, Sander Vanheule wrote:
> Hi,
>
> Sorry I didn't get back to this any sooner.
>
> On Wed, 2022-04-27 at 20:16 +0200, Birger Koblitz wrote:
>> Hi,
> It's still not clear to me what issue or issues you are fixing exactly with
> this patch,
> an
, Sander Vanheule wrote:
> Hi Birger,
>
> On Sun, 2022-04-24 at 22:01 +0200, Birger Koblitz wrote:
>> Do not reset the RTL930x SerDes on link changes, instead set up
>> the SDS with internal PHYs for the SFP+ ports only.
>> This fixes the 8 1GBit ports on the Zyxel X
Do not reset the RTL930x SerDes on link changes, instead set up
the SDS with internal PHYs for the SFP+ ports only.
This fixes the 8 1GBit ports on the Zyxel XGS1250 which
do not work without this patch.
Tested-by: Stijn Segers
Signed-off-by: Birger Koblitz
---
v2: A different patch
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
---
This was previously sent as a patch with a wrong subject
"[
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
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
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.
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 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,
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,
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 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
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
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,
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
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
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
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
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,
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
-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 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,
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 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
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
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,
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.
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
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 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
> 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,
>
> 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,
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
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,
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
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 -
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:
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
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
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
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
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
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
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 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
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(+)
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
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 |
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 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,
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
: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,
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
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
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 =
://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
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 =
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
#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
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
://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
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
)
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
, 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
>
#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
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
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
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
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 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
1 - 100 of 121 matches
Mail list logo
