GPIO numbering and ucidef_add_gpio_switch in kernel 6.6

[Mathew McBride]

Hi all,

A change in kernel 6.2 ("gpio: Get rid of ARCH_NR_GPIOS (v2)") [1] resulted in 
the GPIO chip base numbers changing on some architectures (x86, arm and arm64 
were directly modified in that series).

This may cause issues with /etc/board.d/03_gpio_switches scripts as the GPIO 
numbers will change when moving to the 6.6 kernel.

For example, on our (Traverse Ten64) board, the I2C GPIO expander (PCA953x) 
used to be numbered from 368, now it is numbered from 640:

# Old
cat /sys/kernel/debug/gpio:
gpiochip4: GPIOs 368-383, parent: i2c/0-0076, 0-0076, can sleep:
gpiochip3: GPIOs 384-415, parent: platform/233.gpio, 233.gpio:
gpiochip2: GPIOs 416-447, parent: platform/232.gpio, 232.gpio:
gpiochip1: GPIOs 448-479, parent: platform/231.gpio, 231.gpio:
gpiochip0: GPIOs 480-511, parent: platform/230.gpio, 230.gpio:

# New
gpiochip0: GPIOs 512-543, parent: platform/230.gpio, 230.gpio:
gpiochip1: GPIOs 544-575, parent: platform/231.gpio, 231.gpio:
gpiochip2: GPIOs 576-607, parent: platform/232.gpio, 232.gpio:
gpiochip3: GPIOs 608-639, parent: platform/233.gpio, 233.gpio:
gpiochip4: GPIOs 640-655, parent: i2c/0-0076, 0-0076, can sleep:

I have tried to address this in my armsr/6.6 pull request, but I don't think 
the solution is very elegant:
https://github.com/openwrt/openwrt/pull/14896/commits/b74da3cd82d69e99dda357e61cae9b32072bca80

(I still need to figure out uci migration of these settings between 6.1 and 6.6 
systems)

sysfs GPIOs have also been deprecated for a while now, but from the mailing 
list and GitHub archives, my understanding is that everyone was waiting for 
libgpiod v2 to come out before migrating. (libgpiod v2 was released in August 
2023).

I think kernel 6.6 may force this issue to be addressed. Should we try to 
migrate to a new system (e.g libgpiod) or work out a more agnostic way to 
discover GPIOs (sysfs, DTB etc.)?

Best Regards,
Matt

[1] 
https://lore.kernel.org/lkml/cover.1662116601.git.christophe.le...@csgroup.eu/T/

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Adding a new platform: renesas rz

[Mathew McBride]

Hi Michele,

On Mon, Oct 30, 2023, at 8:39 PM, Michele Bisogno wrote:
> Hi,
> 
> I've been a happy OpenWRT user for many years now, always buying
> routers that could allow me to run it easily.
> 
> I've been working (actually only in my free time as a hobby) on
> porting OpenWRT onto this Renesas board:
> https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/rz
> -mpus/rzg2l-evkit-rzg2l-evaluation-board-kit
> which features this Arm Cortex-A55 based device:
> https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/rz
> -mpus/rzg2l-general-purpose-microprocessors-dual-core-arm-cortex-a55-12-gh
> z-cpus-and-single-core-arm-cortex-m33
> 
> I guess this is a new platform, since it does not really fit in any of
> the already supported ones.

Does the Renesas/RZ U-boot have EFI support enabled ('bootefi' command)?
Could you try an armsr/armv8 image and see if it boots?

(You will need to start U-Boot from qspi or sd card and OpenWrt from a USB or 
different sd card)

If that works, or if we can figure out the necessary changes, a new top level 
target may not be needed.

I understand Renesas has developed a standard firmware for another CPU in the 
series (/G2M), but not sure about the /G2L
https://www.renesas.com/us/en/blogs/renesas-rzg2m-awarded-arm-systemready-ir-11-certification

> I got it working and I am polishing the patch before submitting it.
> The support of this device is already mainlined in the Linux kernel,
> so I am using 6.1 as is with the appropriate config.
> Arm Trusted Firmware and u-boot are instead taken from the respective
> Renesas forks, available on github.
At the moment armsr does not have support for building whole machine firmware 
images with ATF and U-Boot but we could figure out some way to do that if 
needed.

Best Regards,
Matt


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Bringing up new hardware, and GPIO definitions

[Mathew McBride]

Hi Philip,

On Tue, Aug 22, 2023, at 5:49 AM, Philip Prindeville wrote:
> On a somewhat related note, I got into my /etc/board.d/02_network file and 
> made this change:
> [snip]
> board_config_update
> 
> +logger -p daemon.info  "board_name: $(board_name)"
> 
> case "$(board_name)" in
> 
> But best as I can tell that line isn't being hit... or rather, the whole 
> file isn't.

IIRC the board.d files are run well before a syslogd is started (which only 
happens after preinit is done), so any syslog calls (from userspace) just get 
lost.

The best way to do debug logging from them is to append to a file (e.g echo 
$(board_name) >> /tmp/board_d_debug) and view that later.

Cheers,
Matt

> What would prevent that from happening?  I'm not very familiar with the 
> preinit logic.
> 
> Thanks
> 
> 
> 
> > On Aug 21, 2023, at 11:34 AM, Philip Prindeville 
> >  wrote:
> >
> > I have a new x86 prototype box I'm working with, and it doesn't have a 
> > DTSI file (obviously) or a platform driver... and given my experiences 
> > with getting APU platform drivers upstream last time, I'm hesitant to do 
> > that all over again.
> >
> > Anyway, is there an easy way to do GPIO assignments for LEDs and switches 
> > if the kernel isn't doing this for me?
> >
> > Thanks


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH fstools] block: autofs: do not generate events for the root partition

[Mathew McBride]

This resolves an issue that occurs (mostly) when OpenWrt is booted
directly from a mass storage device (e.g x86 or ARM EFI, SATA, NVMe etc.)
and results in the system becoming unusable (everything but / is unmounted).

When "block autofs start" is called (e.g by LuCI when editing system mounts),
it was generating a "remove" hotplug event for the root device,
causing the system to try to unmount the root partition.

To resolve this issue, ensure no hotplug events are generated for
the "/", just as we don't for the extroot usecases.

Signed-off-by: Mathew McBride 
Link: https://forum.traverse.com.au/t/no-proc-mounts/209
Fixes: https://github.com/openwrt/openwrt/issues/12791
---
 block.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/block.c b/block.c
index 9b7c49c..8aa31a4 100644
--- a/block.c
+++ b/block.c
@@ -1295,11 +1295,18 @@ static int main_autofs(int argc, char **argv)
if (m && m->extroot)
continue;
 
+   mp = find_mount_point(pr->dev);
+   if (mp && !strcmp(mp,"/")) {
+   free(mp);
+   continue;
+   }
+
blockd_notify("hotplug", pr->dev, m, pr);
-   if ((!m || !m->autofs) && (mp = 
find_mount_point(pr->dev))) {
+   if ((!m || !m->autofs) && mp) {
blockd_notify("mount", pr->dev, NULL, NULL);
-   free(mp);
}
+   if (mp)
+   free(mp);
}
} else {
if (argc < 4)
-- 
2.30.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

EFI / SystemReady support for OpenWrt on arm64

[Mathew McBride]

Hi all,

For some time now I have had a pull request open to add EFI boot support
to the armvirt target:
https://github.com/openwrt/openwrt/pull/4996

I recently did some revision to ensure sysupgrade does not affect any system 
firmware, files (e.g U-Boot ubootefi.var) and/or partitions already residing on 
the storage medium.

https://github.com/openwrt/openwrt/pull/4996#issuecomment-1524683095

I am just wondering if anyone has any significant objections that would
stop this pull from being merged? (after I fix any current conflicts)

23.05 has branched and there is already a pull request for kernel 6.1 on
master ( https://github.com/openwrt/openwrt/pull/12705 ), which will force
a revision of this pull request.

I am willing to do the work for both branches but would like some
indication of any required changes first.

Updating to 6.1 might take a few days of effort.

Some of our users (Ten64) would really love it to get merged in so they
can use buildbot images and packages for their hardware.

As the topic of UEFI on Arm64 also came up tangentially recently[1], I
thought I would provide a reason why this is happening and the benefits of
doing so.

Why EFI boot?
Firstly, this discussion only concerns boards with some kind of mass
storage (eMMC, SATA or NVMe). It is not a replacement for boards purely
booting out of NOR or NAND.

EFI is the main boot method for Arm SoCs complying with the "SystemReady"
specifications.
As new Arm platforms come closer to the capabilities of conventional
compute platforms, it provides a more standard way of booting operating
systems using familiar components (e.g GRUB, EDKII or U-Boot).

While the higher-end specifications (SR) resemble conventional x86 servers
(e.g must use ACPI), the lower end specification (IR) has relaxed
requirements allowing Device Tree etc and providing facilities for devices
that work entirely on a single eMMC/SD.

See more here:
https://www.arm.com/architecture/system-architectures/systemready-certific
ation-program

The current pull request happily works on boards ranging from imx8 up to
hyper-scale Arm servers (Ampere Altera, AWS Graviton).
The embedded levels (ES and IR) already have hardware based on various
vendors (Marvell, NXP, Raspberry Pi, Rockchip, Socionext, Xilinx)
certified.

The newer version of the IR Spec (2.0) facilities firmware updates /
capsules, secure boot and an alternative mechanism to update EFI variables
when the firmware is unable to do so (e.g U-Boot currently does not
provide SetVariable services).

This also ties in with a recent development in U-Boot called "Standard
Boot"[2] which provides a more 'solidified' boot process vs the script
driven 'distroboot'. EFI boot is supported out of the box with Standard
Boot.

(As a vendor who has shipped U-Boot with distroboot for a while now, I can
say that Standard Boot is quite an improvement. I spent a lot of time
trying to smooth over bumps in the distroboot system)

We (Traverse) have been 'shipping' this OpenWrt port on our Ten64 target
for quite a while now, and are now working with others to expand the hardware
support to as many devices as possible.

There are vendors interested in switching to this as their 'reference'
OpenWrt solution but need to see this merged and in the main tree first
before putting resources into it.

[1] -
http://lists.openwrt.org/pipermail/openwrt-devel/2023-March/040790.html
[2] - https://u-boot.readthedocs.io/en/latest/usage/cmd/bootdev.html

Best Regards,
Matt

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Best VSDL modem-router to target?

[Mathew McBride]

(resend as plain text)

Hi Philip,

On Sat, Jul 30, 2022, at 5:24 AM, Philip Prindeville wrote:
> [snip]
> 
> What was the conclusion about VDSL2 PCIe cards?  I'm looking for a VDSL/2
> card that does bonding/vectoring for use with CenturyLink DSLAM's...

Unfortunately our (Traverse) card is "on ice" at the moment. We need a big 
enough order to be able to build the PCIe version. I can't say with certainty 
if/when that would happen though there is more than enough ADSL/VDSL2 still out 
there to make it a possibility.

Due to the component shortages it would likely need a design revision as well 
to replace some hard to get parts.

> Looking for something to work with regular size PCIe, not mini-PCIe.
I'm told the Draytek one (132) is now EOL, at least that is what I've heard 
from someone who has a few of them and tried to get more.
> Thanks,
> 
> -Philip
> 
Cheers,
Matt
(Been on vacation so sorry for the late reply)

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH procd] utils: fix get_active_console when kernel returns multiple values

[Mathew McBride]

Hi Daniel,
On Mon, Jan 31, 2022, at 10:58 AM, Daniel Golle wrote:
> Hi Mathew,
> 
> On Tue, Jan 25, 2022 at 03:12:08AM +0000, Mathew McBride wrote:
> > /sys/class/tty/console/active may return multiple values on
> > kernels where framebuffer support is enabled but the system
> > is supposed to be using a serial console.
> > e.g
> > $ cat /sys/class/tty/console/active
> > tty0 ttyS0
> 
> On BPi-R2 (which got HDMI with console) I'm seeing this:
> root@OpenWrt:~# cat /sys/class/tty/console/active
> ttyS2 tty1
Doh! Thanks for letting me know. That ruins my assumptions.

So this issue appears to be confined to platforms where the dummy 
framebuffer/console is loaded in the absence of a graphical console.
[snip]
> 
> While I agree that we need to somehow unify and solve this, just
> changing the current behavior will break serial console access at least
> on the targets listed above.
Fair enough, I will see if I can come up with another solution.

> 
> So either you should suggest to change the affected target to ship
> /etc/inittab or supply console= kernel parameter, or we change all the
> other targets above (and maybe more where console= parameter originates
> from existing non-OpenWrt-built bootchain).

> Does our current behaviour (using first active console) violate any
> universal convention we should obey?

The motivation for this is to successfully detect the console(s) on systems 
using EFI to boot (so we don't need to create separate images just to specify a 
different console= and/or inittab). The original console detection patch came 
from this but broke certain boards when graphical support was enabled.

Systemd manages to set up consoles correctly on these systems (without 
console=) so it would be nice for OpenWrt/procd to do the same.

(Specifically, "standards compliant" ARM boards, see this pull that adds EFI to 
armvirt: https://github.com/openwrt/openwrt/pull/4996 )

I guess the best approach now may be to generate (or act as if) an inittab 
based on /sys/class/tty/console/active? When inittab is not present and no 
console= is specified, of course.

(If there was a way to detect if tty0 was a dummy from sysfs I would do that 
instead, but there does not appear to be)

Cheers,
Matt

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH procd] utils: fix get_active_console when kernel returns multiple values

[Mathew McBride]

/sys/class/tty/console/active may return multiple values on
kernels where framebuffer support is enabled but the system
is supposed to be using a serial console.
e.g
$ cat /sys/class/tty/console/active
tty0 ttyS0

On such systems, tty0 is a dummy console:
[0.008273] Console: colour dummy device 80x25
[0.012742] printk: console [tty0] enabled

The serial console doesn't appear until much later:
[0.092468] 21c0500.serial: ttyS0 at MMIO 0x21c0500
[1.713893] printk: console [ttyS0] enabled

So far this only appears to happen on systems using
device tree.

In these circumstances, use the last console device
shown in the sysfs active file.

Fixes: 2cfc26f ("inittab: detect active console from kernel if no console= 
specified")
Signed-off-by: Mathew McBride 
---
 utils/utils.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/utils/utils.c b/utils/utils.c
index f0c4a90..43b24c6 100644
--- a/utils/utils.c
+++ b/utils/utils.c
@@ -138,6 +138,10 @@ blobmsg_list_equal(struct blobmsg_list *l1, struct 
blobmsg_list *l2)
 char *get_active_console(char *out, int len)
 {
char line[CMDLINE_SIZE + 1];
+   char *sptr, *token;
+   char *console = NULL;
+
+   memset(line, 0, sizeof(line));
int fd = open("/sys/class/tty/console/active", O_RDONLY);
ssize_t r;
 
@@ -152,15 +156,22 @@ char *get_active_console(char *out, int len)
if (r <= 0)
return NULL;
 
-   /* The active file is terminated by a newline which we need to strip */
-   char *newline = strtok(line, "\n");
-
-   if (newline != NULL) {
-   strncpy(out, newline, len);
-   return out;
+   /* There may be multiple 'active' consoles.
+* On kernels that support both graphical and
+* serial consoles, Linux may create a 'dummy'
+* framebuffer console on tty0 if no other console
+* device has been probed yet. Often a serial
+* driver (e.g ttyS0) might only be probed later
+* in the boot process.
+*/
+   for (token = strtok_r(line, " \t\n", ); token;
+token = strtok_r(NULL, " \t\n", )) {
+   strncpy(out, token, len);
+   console = out;
}
+   out[len-1] = '\0';
 
-   return NULL;
+   return console;
 }
 
 char* get_cmdline_val(const char* name, char* out, int len)
-- 
2.30.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Best VSDL modem-router to target?

[Mathew McBride]

Hi David,

On Mon, Jan 10, 2022, at 11:46 AM, David Woodhouse wrote:
[snip]
> > Our VDSL card is just a Lantiq/MaxLinear GRX gateway with an Ethernet
> > uplink to host. 
> 
> Is that a GRX300, with VRX318?
It's a GRX300 + VRX518.

> Wonder what it would take to get OpenWrt running directly on it :)
Probably not very hard to get something more recent on it, especially with DSA 
now supporting the ethernet switch/GSWIP.

> > It's not possible to construct a something that functions like the
> > Solos/Geos with modern DSL chipsets.
> 
> Is it not possible to have a VRX518 transceiver alone on a PCIe card?
> Is it that you can't *get* them as discrete PCIe devices, or that they
> wouldn't work like that?
A VRX518 connected directly to the host is the "dream", but we couldn't justify 
the effort (yet) to figure out how to get it working on a non-GRX platform.

(We also have to be careful, when VDSL vectoring is involved then CPE's need to 
be "well behaved" or the operator might block your device. At least when it's 
running the same code as the reference design, I can escalate back to the 
vendor)

It won't be as nice as the Solos where we could use the FPGA and firmware to 
hide the ugly parts of the vendors DSL stack.

> > (Except maybe if you can get the VRX PCIe phys working on plain
> > OpenWrt. I believe others have tried and not succeeded yet)
> 
> We do have native VRX200 support, and there's progress on VRX518 too,
> which looks like it's working for many users although it isn't merged
> yet.
> 
> While we dream about that, though, having the VDSL bridged to Ethernet
> by an internal "black box" PCIe device instead of having to use an
> external modem is still a big win.
> 
> Are your VDSL cards available for purchase? I'm tempted to go buy a
> Ten64 right now and see if I can help with upstreaming the OpenWrt
> support, if I can get a VDSL card too. 
There are two variants of our VDSL card: one with an RGMII uplink (proprietary) 
for our older LS1043 board, and one with a PCIe (Intel i210) uplink. The PCIe 
one isn't in production yet, though might be later this year.

Officially we don't sell them to the public as xDSL hardware tends to require a 
lot of integration support from our side, but if you ask very nicely we 
occasionally make exceptions.

Upstream OpenWrt for Ten64 isn't far away, I just need to respin our current 
tree and hopefully I'll do a pull request this week.
https://gitlab.com/traversetech/ls1088firmware/openwrt/-/commits/owrt_master_2021-12-10
This in the form of a generic "arm64" target which will work on other modern 
ARM machines with EFI support.

Regards,
Matt

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Best VSDL modem-router to target?

[Mathew McBride]

On Mon, Jan 10, 2022, at 10:14 AM, David Woodhouse wrote:
> On Wed, 2022-01-05 at 18:05 -0700, Philip Prindeville wrote:
> > Have you looked at the Traverse Geos2?
> 
> That's kind of dated now (ADSL2+ only) but Traverse seem to have a
> new toy now:
> 
> https://traverse.com.au/products/ten64-networking-platform/
> And it has an external VDSL board: 
> https://traverse.com.au/hardware-4.html
> 
> Looks like the VDSL is a standalone device much like the Solos card
> which they integrated into the Geos.
Indeed, the Geos has been out of production for several years now.

We don't have a dual DSL product anymore as most of the use cases for dual-DSL 
have shifted to DSL+5G or even dual-5G instead.

Our VDSL card is just a Lantiq/MaxLinear GRX gateway with an Ethernet uplink to 
host. It's not possible to construct a something that functions like the 
Solos/Geos with modern DSL chipsets. 

(Except maybe if you can get the VRX PCIe phys working on plain OpenWrt. I 
believe others have tried and not succeeded yet)

Cheers,
Matt

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: ath11k - pci - backports/.config issue

[Mathew McBride]

Hello Janusz,
On Fri, Oct 22, 2021, at 1:39 AM, Janusz Dziedzic wrote:
> Hello,
> 
> Hit some issue with my ath11k card,  so maybe someone already fix
> it/know what I missed?
> 
> My card (pcie):
> root@OpenWrt:~# lspci
> :00:00.0 PCI bridge: MEDIATEK Corp. Device 3258
> :01:00.0 Unassigned class [ff00]: Qualcomm QCA6390 Wireless
> Network Adapter [AX500-DBS (2x2)]
> 
> I have this card in my banana-pi-r64 board in pcie slot.
> 
> Checked with current/latest backports (v5.10/v5.15)
> On top added patch (added some changes, attached) based on:
> https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=commit;h=0b115adb1b0cc9c19c7c780f3a9e6437fa0398a5
> Simple choose kmod-ath11k from menuconfig.
> 
> 
Getting PCIe (QCA6390, QCN9074) ath11k cards working under kernel 5.10 takes a 
bit more work than the versions in the IPQ platforms.

I have a tree here which I have used successfully with the QCA6390 and QCN9074 
cards (in our NXP LS1088/Ten64 platform). There are still quite a few bugs with 
QCN (e.g no MAC address read from the card, reboot issues) but the QCA6390 is 
working well.

https://gitlab.com/traversetech/ls1088firmware/openwrt/-/commits/arm64_2102_11ax

This tree is actually based on 21.02 with a backported kernel 5.10 (5.4 is too 
old for our hardware). If you pick most of changes to the master branch it 
should work.

The backports of MHI bus and ath11k changes are quite large - there are over 
200 patches I cherry picked back onto 5.10 to make this work!

You can see the full patch set here:
https://gitlab.com/matt_traverse/ath11k-qcn9074-backport/-/commits/ath11k_5_10_20210909
In the OpenWrt tree above, I squashed these patches into one each for MHI, QRTR 
 and ath11k (grafting this onto backports)

(There are also patches related to Qualcomm PCIe cellular modems which also use 
the MHI infrastructure, and which I also want to use under OpenWrt)

Because of that, I haven't made any attempts to upstream this.

Moving to backports-5.15.x should make the situation more bearable, it would 
also help if drivers/bus/mhi and drivers/net/wwan (for the PCIe modems) is 
taken from backports as well.

Best Regards,
Matt

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH procd] inittab: detect active console from kernel if no console= specified

[Mathew McBride]

The default serial console can be set in the device tree
using the linux,stdout-path parameter (or equivalent from ACPI).

This is important for universal booting (EFI/EBBR) on ARM platforms
where the default console can be different (e.g ttyS0 vs ttyAMA0).

Signed-off-by: Mathew McBride 
---
 inittab.c |  8 
 utils/utils.c | 22 ++
 utils/utils.h |  1 +
 3 files changed, 31 insertions(+)

diff --git a/inittab.c b/inittab.c
index 45118f4..2c2270c 100644
--- a/inittab.c
+++ b/inittab.c
@@ -183,7 +183,15 @@ static void askconsole(struct init_action *a)
char line[256], *tty, *split;
int i;
 
+   /* First, try console= on the kernel command line,
+* then fallback to /sys/class/tty/console/active,
+* which should work when linux,stdout-path (or equivalent)
+* is in the device tree
+*/
tty = get_cmdline_val("console", line, sizeof(line));
+   if (tty == NULL) {
+   tty = get_active_console(line, sizeof(line));
+   }
if (tty != NULL) {
split = strchr(tty, ',');
if (split != NULL)
diff --git a/utils/utils.c b/utils/utils.c
index 8d76129..e90feec 100644
--- a/utils/utils.c
+++ b/utils/utils.c
@@ -135,6 +135,28 @@ blobmsg_list_equal(struct blobmsg_list *l1, struct 
blobmsg_list *l2)
return true;
 }
 
+char *get_active_console(char *out, int len)
+{
+   char line[CMDLINE_SIZE + 1];
+   int fd = open("/sys/class/tty/console/active", O_RDONLY);
+   ssize_t r = read(fd, line, sizeof(line) - 1);
+
+   close(fd);
+
+   if (r <= 0)
+   return NULL;
+
+   /* The active file is terminated by a newline which we need to strip */
+   char *newline = strtok(line, "\n");
+
+   if (newline != NULL) {
+   strncpy(out, newline, len);
+   return out;
+   }
+
+   return NULL;
+}
+
 char* get_cmdline_val(const char* name, char* out, int len)
 {
char line[CMDLINE_SIZE + 1], *c, *sptr;
diff --git a/utils/utils.h b/utils/utils.h
index 908c314..216323e 100644
--- a/utils/utils.h
+++ b/utils/utils.h
@@ -52,6 +52,7 @@ void blobmsg_list_free(struct blobmsg_list *list);
 bool blobmsg_list_equal(struct blobmsg_list *l1, struct blobmsg_list *l2);
 void blobmsg_list_move(struct blobmsg_list *list, struct blobmsg_list *src);
 char* get_cmdline_val(const char* name, char* out, int len);
+char *get_active_console(char *out, int len);
 
 int patch_fd(const char *device, int fd, int flags);
 int patch_stdio(const char *device);
-- 
2.30.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: New layerscape/aarch64 board

[Mathew McBride]

On Sat, Feb 13, 2021, at 2:13 AM, Michael Walle wrote:
> Hi,
> 
> I am looking into how to bring openwrt support for my board
> (Kontron sl28) upstream. The board has upstream support in
> both vanilla linux (since 5.8) and vanilla u-boot. Someone
> in IRC told me there will be a new release based on 5.10 after
> the 21.02 branch is created. So that would be a nice fit.
> 
> I'd have thought the board will fit it linux/layerscape but that
> is the vanilla kernel with all the NXP lsdk patches on top of it,
> which my board doesn't need and frankly speaking I don't want. The
> same is true for the uboot-layerscape package. Thats the LSDK
> version.

Hi Michael,
I/we (Traverse) also have layerscape boards that run OpenWrt.

When the layerscape target was first introduced (~2017), most of the drivers 
for these SoCs were not in mainline linux yet.

Since then, the situation has changed, the newer SoCs (e.g DPAA2/LS1088/LS2088) 
are very much complete (and in some ways, better) in >=5.10 and the others are 
not far behind.

I understand there are some edge cases, such as the DPAA1 (LS1043/LS1046) 
Ethernet drivers in mainline were a 'clean' rewrite of NXP/Freescale's long 
standing 'Netcomm' driver  and have different performance and features to 
mainline.

I would put forward the following options:

1. For future OpenWrt releases with kernel >=5.10, stop using LSDK patches, or 
only pick the required patchset for SoCs not in upstream (e.g any new 
Layerscape SoCs that are introduced)

I suspect the size of the NXP LSDK patchset will decrease signifcantly when 
rebased onto >=5.10 so this problem may solve itself.

and/or

2. Introduce a generic 'armv8' target for systems that have 'block storage' 
(SATA/MMC/NVMe), targetting U-Boot distroboot and ARM EBBR(EFI), which would 
look a lot like the existing x86 target.

I did have a go myself at introducing an 'armserver' target for EFI boot a 
while ago, this was before x86-64 EFI support was introduced.
There were suggestions that it should go into 'armvirt', though the existing 
armvirt/32 target may not share the same goals.

Boards that boot from flash (ubifs) or have special requirements (such as 
bundling the RCW/ATF) could continue using the individual targets.

Regards,
Matt


> 
> Thus, does anyone have an idea where I should put my board. It
> really looks like the "layerscape" is tailored to the NXP eval
> boards.
> 
> It should really have been a layerscape-lsdk in the first place.
> 
> Any thoughts?
> 
> In theory it should be possible to have a generic armv8 board.
> Which only differs in the device trees. But that would mean
> the kernel image will bloat over time. I don't know if that is
> a major issue, given that most aarch64 boards should have
> enough storage and memory.
> 
> -michael
> 
> ___
> 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

Re: [OpenWrt-Devel] Understanding Ethernet Architecture (I/O --> MDIO --> MII vs I/O --> MAC) for mt7620 (OpenWRT)

[Mathew McBride]

Hi Daniel,
MDIO is a low-speed management bus to talk between the CPU and the Ethernet 
PHY's, it's best thought of as "I2C for Ethernet PHYs" (the concepts between 
the two are similar). 
Like I2C there can be multiple devices on the MDIO bus so each PHY needs an 
address, and in cases where multiple MACs and MDIO controllers exist on a 
system you don't necessarily have to use one MDIO controller for a particular 
MAC.

This is only for reporting things like the current link speed and setting some 
PHY registers (like what LEDs to drive and if you want to force 10/100/1000 
instead of autoneg) - if you have a connection whose electrical characteristics 
never change (e.g between a SoC<->Switch/xDSL/WiFi/Cable PHY on the same board) 
then there might be _no_ MDIO communication between them.
(In these cases one might have to force certain link parameters in the MAC 
registers, the 'fixed-link' driver in the kernel can be used to do this)

The actual Ethernet traffic is passed over the R(G)MII/SGMII/etc. which is 
point to point (not a "bus") between the MAC and the link-partner.
Note that if you have a Ethernet switch (either as a separate chip or buit-in 
to the SoC), your "link-partner" is the switch fabric, not any ports downstream.
So if you manipulate the MAC registers for the SoC<->Switch you are only 
manipulating the connection between the two.

I can't comment on the MT7620 specifically, but its quite likely there is no 
MDIO between the CPU MAC and the switch, and that the switch is configured 
"out-of-band" by another method - and this would include any ethernet PHYs that 
are part of the switch.

Hope this helps,
Matt


-Original Message-
From: openwrt-devel  On Behalf Of 
Daniel Santos
Sent: Saturday, 15 June 2019 8:53 AM
To: Daniel Golle ; Felix Fietkau ; 
openwrt-devel ; John Crispin 
; Michael Lee ; net...@vger.kernel.org
Subject: [OpenWrt-Devel] Understanding Ethernet Architecture (I/O --> MDIO --> 
MII vs I/O --> MAC) for mt7620 (OpenWRT)

Hello,

I'm still fairly new to Ethernet drivers and there are a lot of interesting 
pieces.  What I need help with is understanding MDIO --> (R)MII vs direct I/O 
to the MAC (e.g., via ioread32, iowrite32).  Why is there not always a struct 
mii_bus to talk to this hardware?  Is it because the PHY and/or MAC hardware 
sometimes attached via an MDIO device and sometimes directly to the I/O bus?  
Or does some type of "indirect access" need to be enabled for that to work?

I might be trying to do something that's unnecessary however, I'm not sure yet. 
 I need to add functionality to change a port's auto-negotiate, duplex, etc.  
I'm adding it to the swconfig first and then will look at adding it for DSA 
afterwards.  When I run "swconfig dev switch0 port 0 show", the current mt7530 
/ mt7620 driver is querying the MAC status register (at base + 0x3008 + 0x100 * 
port, described on pages 323-324 of the MT7620 Programming Guide), so I 
implemented the "set" functionality by modifying the MAC's control register 
(offset
0x3000 on page 321), but it doesn't seem to change anything.  So I figured 
maybe I need to modify the MII interface's control register for the port (page 
350), but upon debugging I can see that the struct mii_bus *bus member is NULL.

So should I be able to change it via the MAC's control register and something 
else is wrong?  Why is there no struct mii_bus?  Can I talk to the MII hardware 
in some other way?

Thanks,
Daniel

https://download.villagetelco.org/hardware/MT7620/MT7620_ProgrammingGuide.pdf

___
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