Hi Adrian,
On Fri, 2020-07-17 at 15:01 +0200, m...@adrianschmutzler.de wrote:
> Hi,
>
> > diff --git a/target/linux/ath79/dts/qca9563_tplink_eap225od-v1.dts
> > b/target/linux/ath79/dts/qca9563_tplink_eap225od-v1.dts
> > new file mode 100644
> > index 00..dcfdb7e524
> > --- /dev/null
> >
Hi Adrian,
On Fri, 2020-07-17 at 14:54 +0200, m...@adrianschmutzler.de wrote:
> Hi,
>
> > diff --git a/target/linux/ath79/dts/qca9563_tplink_eap245-v1.dts
> > b/target/linux/ath79/dts/qca9563_tplink_eap245-v1.dts
> > new file mode 100644
> > index 00..8a11d2e469
> > --- /dev/null
> > +++
On Fri, 2020-07-17 at 14:49 +0200, m...@adrianschmutzler.de wrote:
> Hi,
Hi Adrian,
Thanks for the quick feedback.
> > diff --git
> > a/target/linux/ath79/dts/qca9563_tplink_eap2x5_1port.dtsi
> > b/target/linux/ath79/dts/qca9563_tplink_eap2x5_1port.dtsi
> > new file mode 100644
> > index 000
> I tried 80MHz and 65MHz, but that didn't result in proper reads. 50MHz,
> 55MHz, and 60MHz do appear to work on my eap245-v1, so I really wouldn't
> risk going above 50MHz.
If you've taken the 25 MHz somewhere reasonable, as you stated, I'd also be
fine with that.
My motivation is mainly to pr
The DEVICE_DTS variable always matches the device definition name,
just with "_" replaced by "-". Thus, create a DEVICE_DTS definition
in Device/Default and drop all the individual statements.
If necessary in the future, local DEVICE_DTS will still overwrite
that default.
Signed-off-by: Adrian Sc
In most cases the DEVICE_DTS name can be derived easily from the
node name, so let's do this to enforce harmonized names where
possible.
Signed-off-by: Adrian Schmutzler
---
target/linux/omap/image/Makefile | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/target/linux/omap/
Most newer targets have been converted to consistently use
vendor_model scheme for device definitions/image names, ox820 is
using it as well, so let's just convert ox810se for consistency.
Signed-off-by: Adrian Schmutzler
---
target/linux/oxnas/image/ox810se.mk | 4 ++--
1 file changed, 2 insert
On Sat, 2020-07-18 at 13:03 +0200, m...@adrianschmutzler.de wrote:
> > I tried 80MHz and 65MHz, but that didn't result in proper reads.
> > 50MHz,
> > 55MHz, and 60MHz do appear to work on my eap245-v1, so I really
> > wouldn't
> > risk going above 50MHz.
>
> If you've taken the 25 MHz somewhere r
Hi,
> Where? I don't see a merge request on the git link referenced in the Makefile.
sent a patch to the author using git send-email. Couldn't figure out how
to open a MR on that Gitlab thing after looking for 30 seconds.
~ Jo
___
openwrt-devel mailin
Specifications:
- MT7628NN @ 580 MHz
- 32 MB RAM
- 8 MB Flash
- 5x 10/100 Mbps Ethernet (built-in switch)
- 2.4 GHz WLAN
- 2x external, non-detachable antennas (1x for RT-N10P V3)
Flash instructions:
1. Set PC network interface to 192.168.1.75/24.
2. Connect PC to the router via LAN.
3. Turn rou
Hi,
On 26-06-20, Baptiste Jonglez wrote:
> The student project of Biyun and Zhao has just finished.
>
> The goal was to develop a simplified web interface for OpenWrt, integrated
> in LuCI and complementary to the current LuCI interface.
>
> Feedback on the results of the project is welcome, pre
Hi Michael,
Thanks for your feedback.
On 26-06-20, Michael Richardson wrote:
> From watching the video the two tasks that you were attempting to improve
> were (in laymens terms):
> 1) changing the WIFI password
> 2) creating a port-forward
>
> I think that this could be just a bit easier t
Currently archs38 sets a board name from compatible for no apparent
reason. Just use the compatible directly instead.
This theoretically removes a board name "generic" when no compatible
was present, however, there is no case where this "generic" board
name was actually used.
This also fixes an i
On 6/8/20 4:14 PM, Johannes Kimmel wrote:
> Similar to wireguard, vxlan can configure multiple peers or add specific
> entries to the fdb for a single mac address.
>
> While you can still use peeraddr/peer6addr option within the proto
> vxlan/vxlan6 section to not break existing configurations, th
On 6/8/20 4:14 PM, Johannes Kimmel wrote:
> vxlan can be configured without a peer address. This is used to prepare
> an interface and add peers later.
>
> Signed-off-by: Johannes Kimmel
Acked-by: Matthias Schiffer
> ---
> package/network/config/vxlan/files/vxlan.sh | 12
> 1 fil
If you resend this with adjustments, please also bump PKG_RELEASE then as well.
Since both patches received positive feedback, I think it should be enough to
bump it once for the 3/3 patch.
Best
Adrian
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openw
The reimplementation of signify called usign is used for both opkg
package list and sysupgrade verification.
Currently usign support all features per default, including key
generation and signing of of mesages.
Inspired by Petrs work on the signify port[0] I tried to add similar
ifndef conditions
Hi Sander,
On 7/17/20 1:37 PM, Sander Vanheule wrote:
> TP-Link has developed a number of access points based on the AP152
> reference board. In the EAP-series of 802.11ac access points, this
> includes the following devices with one ethernet port:
> * EAP225 v1/v2
> * EAP225 v3
> * EAP225-Outdoor
Hi David,
On Sat, 2020-07-18 at 21:45 +0200, David Bauer wrote:
> > + gmac-config {
> > + device = <&gmac>;
> > +
> > + rgmii-ge0 = <1>;
> > + ge0-sgmii = <1>;
> > + rxdv-delay = <3>;
> > + rxd-delay = <3>;
>
> This does not make a lot of sense
See the previous patches, which implemented the cros-vbutil
verified-boot payload-packing tool, and extended ptgen for the CrOS
kernel partition type. With these, it's now possible to package kernel +
rootfs to make disk images that can boot a Chrome OS-based system (e.g.,
Chromebooks, or even a fe
Hi,
This series adds support for both Chromium OS (or particularly, its
kernel-payload signing and disk layout) and for a device using it (the
first generation Google WiFi).
Google WiFi (code-named "Gale") is an IPQ4019-based AP. Its hardware is
decently supported by the existing ipq40xx target -
Google WiFi (codename: Gale) is an IPQ4019-based AP, with 2 Ethernet
ports, 2x2 2.4+5GHz WiFi, 512 MB RAM, 4 GB eMMC, and a USB type C port.
In its stock configuration, it runs a Chromium OS-based system, but you
wouldn't know it, since you can only manage it via a "cloud" +
mobile-app system.
The
Chrom{ium,e} OS (shortened as "CrOS") bootloaders use a custom GPT
partition type to locate their kernel(s), with custom attributes for
noting properties around which partition(s) should be active and how
many times they've been tried as part of their A/B in-place upgrade
system.
OpenWRT doesn't u
Submitted upstream. Shouldn't affect existing devices, but enables new
device support.
https://lore.kernel.org/linux-gpio/20200703080646.23233-1-computersforpe...@gmail.com/
Currently queued for-next:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next&id=1
Chrom{ium,e} OS based devices use a Coreboot+Depthcharge-based firmware,
which verifies and loads a kernel packed in a verified-boot payload. The
verification tooling (both for creating and verifying payloads) is
implemented here:
https://chromium.googlesource.com/chromiumos/platform/vboot_referen
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Brian Norris
> Sent: Samstag, 18. Juli 2020 22:52
> To: openwrt-devel@lists.openwrt.org
> Cc: Brian Norris
> Subject: [RFC PATCH 3/5] image-commands: support Chromium OS image-
>
Hi,
just some formal stuff below.
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Brian Norris
> Sent: Samstag, 18. Juli 2020 22:52
> To: openwrt-devel@lists.openwrt.org
> Cc: Brian Norris
> Subject: [RFC PATCH 5/5] ipq40xx: add
Hi Adrian,
On Sat, Jul 18, 2020 at 2:14 PM wrote:
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Brian Norris
> > Sent: Samstag, 18. Juli 2020 22:52
> > To: openwrt-devel@lists.openwrt.org
> > Cc: Brian Norris
> > Subject:
> I am very interested in Thomas Petazzoni's work to add SELinux
> support to OpenWrt. I spent some time today trying to reproduce his
> build. I found a few things needed updating, so I wanted to share my
> results here.
I updated Thomas' work, and I made my updates available at:
https://github.
This allows the user to disable the RSA algorithm in Dropbear, if not required.
(RSA is still enabled by default, of course, due to its ubiquity.)
Size comparison of the dropbear executable (cortex-a9+neon):
RSA + Ed25519: 182804 bytes
RSA only: 170496 bytes
Ed25519 only: 166356 bytes
S
The ssh and scp symlinks were still being created even when dbclient was
disabled in the build configuration. Fix this annoyance.
Signed-off-by: Rui Salvaterra
---
package/network/services/dropbear/Makefile | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/package/network
This will be replaced with the driver found in newer kernels.
Signed-off-by: Rosen Penev
---
package/kernel/linux/modules/fs.mk | 24
1 file changed, 24 deletions(-)
diff --git a/package/kernel/linux/modules/fs.mk
b/package/kernel/linux/modules/fs.mk
index 82f8685111..
>From an email conversation with the person responsible for upstreaming
the exFAT driver, it seems the staging one in kernel 5.4 is not so
good. Excerpts below.
Namjae Jeon:
Hm... exfat in 5.4 kernel that we did crap shit long time ago is
contributed by someone who we don't know.
This version is
33 matches
Mail list logo
