On Sun, Nov 07, 2021 at 10:25:48PM -0800, Rosen Penev wrote:
> > > Should we consider building it as a toolchain tool or should we migrate to
> > > command -v ?
> > https://github.com/openwrt/openwrt/commit/1f5e7224868109a170a9248d18f8d2b6124e9c5a
> Wonder if switching command -v to type -a -p make
On Sun, Nov 7, 2021 at 10:14 PM Rosen Penev wrote:
>
> On Sun, Nov 7, 2021 at 12:32 PM Ansuel Smith wrote:
> >
> > Il giorno dom 7 nov 2021 alle ore 19:18 Bjørn Mork ha
> > scritto:
> > >
> > > Ansuel Smith writes:
> > >
> > > > Updating to latest ubuntu devel this now comes up
> > > > /home/a
On Sun, Nov 7, 2021 at 12:32 PM Ansuel Smith wrote:
>
> Il giorno dom 7 nov 2021 alle ore 19:18 Bjørn Mork ha scritto:
> >
> > Ansuel Smith writes:
> >
> > > Updating to latest ubuntu devel this now comes up
> > > /home/ansuel/openwrt/staging_dir/host/bin/which: this version of
> > > `which' is
Openwrt Github commit notes, Forum posts, and Documentation, refer to:
"The mtd partitions layout for XM-type devices changed from AirOS v5.5
to AirOS v5.6. Before installing OpenWrt, downgrade first to AirOS
5.5."
reference: https://openwrt.org/toh/ubiquiti/common
While the documentation is a
from https://git.kernel.org/pub/scm/network/iproute2/iproute2.git
changes since 5.14.0:
ad3a118f rdma: Fix SRQ resource tracking information json
7a235a10 man: devlink-port: fix pfnum for devlink port add
229eaba5 uapi: pickup fix for xfrm ABI breakage
a500c5ac lib/bpf: fix map-in-map creation wi
On 11/3/21 12:10 AM, Mathias Kresin wrote:
11/2/21 11:52 PM, Hauke Mehrtens:
On 11/2/21 11:35 PM, Mathias Kresin wrote:
At least since gcc 7.3.0 (OpenWrt 18.06) lwr/lwl are used in the
assembly of LzmaProps_Decode. The instructions are using unaligned
access, which locks up danube boards using
From: Oleksandr Hnatiuk
Signed-off-by: Oleksandr Hnatiuk
Wrote incomplete device tree. Added new device to the build system.
---
Hi! I'm trying to add support for a new board based on QCN5502 SoC and I'm
unsure about how to proceed with my device tree. Below are the information
about hardware on
Il giorno dom 7 nov 2021 alle ore 19:18 Bjørn Mork ha scritto:
>
> Ansuel Smith writes:
>
> > Updating to latest ubuntu devel this now comes up
> > /home/ansuel/openwrt/staging_dir/host/bin/which: this version of
> > `which' is deprecated; use `command -v' in scripts instead.
> >
> > I think we h
https://lwn.net/Articles/874333/ ?!?
On 07.11.21 19:05, Ansuel Smith wrote:
Updating to latest ubuntu devel this now comes up
/home/ansuel/openwrt/staging_dir/host/bin/which: this version of
`which' is deprecated; use `command -v' in scripts instead.
I think we have to update something?
__
Ansuel Smith writes:
> Updating to latest ubuntu devel this now comes up
> /home/ansuel/openwrt/staging_dir/host/bin/which: this version of
> `which' is deprecated; use `command -v' in scripts instead.
>
> I think we have to update something?
See https://lwn.net/SubscriberLink/874049/b563dc08d4e
Updating to latest ubuntu devel this now comes up
/home/ansuel/openwrt/staging_dir/host/bin/which: this version of
`which' is deprecated; use `command -v' in scripts instead.
I think we have to update something?
___
openwrt-devel mailing list
openwrt-de
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Branch: refs/heads/master
Home
On 11/3/21 7:08 PM, Stijn Tintel wrote:
Enabling KERNEL_KASAN exposes several missing symbols. As KASAN_SW_TAGS
is only implemented for arm64 CPUs and requires clang, it doesn't make
sense to make this a build option so just default to KASAN_GENERIC and
disable KASAN_SW_TAGS.
While at it, disabl
On 11/3/21 7:08 PM, Stijn Tintel wrote:
Enabling KERNEL_UBSAN exposes several missing symbols. Add new kernel
build options for UBSAN_BOUNDS and UBSAN_TRAP, disable CONFIG_TEST_UBSAN
in the generic kernel configs and enable CONFIG_UBSAN_MISC in generic
5.10 config. The latter symbol was removed i
When restarting the device using a CPU reset, the networking part of the
SoC is not reset. This leads to unresponsive network after the (warm)
restart. By resetting both the switch NIC and queues (SW_NIC_RST and
SW_Q_RST bits), networking always comes up reliably.
Tested on a Zyxel GS1900-8 (RTL83
From: Rafał Miłecki
Kernel 5.10 grew bigger than 5.4 so we need to bump BZ_TEXT_START to
allow lzma loader hanel its size.
At the same time BZ_STACK_START needs to be increased to avoid
overwriting the stack.
For a reference see:
d5cf4a5aa4a3 ("brcm47xx: relocate loader to higher address")
2909
On 11/6/21 10:27 PM, John Thomson wrote:
Hi Hauke,
On Mon, 1 Nov 2021, at 16:54, Hauke Mehrtens wrote:
PKG_NAME:=binutils
-PKG_VERSION:=2.35.2
+PKG_VERSION:=2.37
I am seeing a problem compiling package/devel/binutils 2.37
This is not showing on the buildbots, so not urgent.
I opened an upst
On 11/7/21 10:37 AM, Rafał Miłecki wrote:
From: Rafał Miłecki
This allows loader to handle kernel 5.10 that grew bigger than 5.4.
Variations tested on BCM4706:
BAD:
BZ_TEXT_START := 0x8060
BZ_STACK_START := 0x8070
GOOD:
BZ_TEXT_START := 0x8070
BZ_STACK_START := 0x8070
BA
From: Rafał Miłecki
This allows loader to handle kernel 5.10 that grew bigger than 5.4.
Variations tested on BCM4706:
BAD:
BZ_TEXT_START := 0x8060
BZ_STACK_START := 0x8070
GOOD:
BZ_TEXT_START := 0x8070
BZ_STACK_START := 0x8070
BAD:
BZ_TEXT_START := 0x8060
BZ_STACK_ST
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 really
20 matches
Mail list logo
