Hi Andre,
On Tue, Apr 7, 2020 at 9:28 PM Andre Valentin wrote:
>
> Am 07.04.20 um 20:05 schrieb Sergio Paracuellos:
> > Hi,
> >
> > On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo wrote:
> >>
> >> [CC Sergio who worked on upstream PCIE driver]
> >>
> >> On Tue, Apr 7, 2020 at 4:45 PM Andre
The script allows to run a OpenWrt x86/64 rootfs in no time. It is
possible to access the web interface and SSH via 192.168.1.1.
By using docker volume mounts you can easily share files/folders between
container and host, allowing ot use hosts tools to work on files
deployed in a running OpenWrt
Hi everybody,
sometime ago I sent github PR[1] with support for D-Link DWR-960.
I prepared patch for mt7620, which add rgmii delays setting
possibility. Could someone take a look at this and review it?
[1] https://github.com/openwrt/openwrt/pull/2857
Regards,
Pawel Dembicki
Instead of passing pkg-config location through a variable when building
qconf (make xconfig), prepend its parent directory to the PATH, as it is
being done for other conf targets.
Use a Makefile pattern rule to group all 'scripts/config/%onf'
(currently conf, mconf, qconf) targets in a single
Currently, RTC_SUPPORT is defined as a tristate, with 'depends on m',
which is supposed to only let it be set to 'm' or 'n'. However,
scripts/target-metadata.pl will 'select' it, or setting it to 'y', which
defeats it's 'depends on m' restriction. The users of the symbol are
not expecting it to
This addes the option to treat recursive dependencies as warnings
instead of errors, by running make with WARN_RECURSIVE_DEP=1.
Note that the script/config targets will not get rebuilt when you add or
remove WARN_RECURSIVE_DEP while running make. One must run
'make config-clean' before building
Newer versions of the kconfig program requires quoting the arguments of
the 'source' directive. These are the last ones not using them.
Signed-off-by: Eneas U de Queiroz
---
package/utils/busybox/config/Config.in| 44 +--
.../utils/busybox/config/networking/Config.in |
IPv6 modules should all depend on @IPV6, to avoid circular dependencies
problems, especially if they select a module that depends on IPV6 as
well. In theory, if a package A depends on IPV6, any package doing
'select A' (DEPENDS+= A) should also depend on IPV6; otherwise selecting
A will fail.
The full cover-letter is in the original series. V2 is about shipping
pre-generated c/h files to avoid depending on bison & flex.
The _shipped files are gone upstream, so I did not use the previous
scheme, of copying *_shipped files. Instead, I'm shipping the *.[ch]
files directly.
I've made it
Am 07.04.20 um 20:05 schrieb Sergio Paracuellos:
> Hi,
>
> On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo wrote:
>>
>> [CC Sergio who worked on upstream PCIE driver]
>>
>> On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin wrote:
>>>
>>> Hi!
>>>
>>> Currently I'm having some serious problems with the
Hi,
> -Original Message-
> From: Alexey Dobrovolskiy [mailto:dobrovolskiy.ale...@gmail.com]
> Sent: Dienstag, 7. April 2020 20:51
> To: m...@adrianschmutzler.de
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [PATCH] ramips: use full 8MB flash on ZyXEL Keenetic
>
> Hi Adrian,
>
>
Hi Adrian,
thanks for you review.
> But I still wonder how this device is now supported for almost three years
> now and nobody mentioned that so far?
The problem has already been described in bugreport FS#2487 [1].
So i should also add
Fixes: FS#2487
> Do you have further evidence?
WikiDevi
Am 07.04.20 um 12:16 schrieb Chuanhong Guo:
> [CC Sergio who worked on upstream PCIE driver]
>
> On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin wrote:
>>
>> Hi!
>>
>> Currently I'm having some serious problems with the new 5.4 port.
>> 1) PCIe
>> I'm developing on the ZyXEL LTE3301-PLUS. It has
Hi!
Am 07.04.20 um 17:49 schrieb Bjørn Mork:
> Just remembered an issue on my todo list: There have been some MTU
> handling changes in the kernel networking API. This affected the
> qmi_wwan QMAP handling. I am not sure about the current status. Will
> have to dig a bit more. But this might
Hi,
On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo wrote:
>
> [CC Sergio who worked on upstream PCIE driver]
>
> On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin wrote:
> >
> > Hi!
> >
> > Currently I'm having some serious problems with the new 5.4 port.
> > 1) PCIe
> > I'm developing on the ZyXEL
Hi,
since a few days I get following Kernel Oops. The Omega2+ board doesn't
get any ethernet connection. Any hints ?
[0.00] Linux version 4.14.172 (gerd@nizza) (gcc version 8.4.0
(OpenWrt GCC 8.4.0 r12649-ecef29b294)) #0 PREEMPT Mon Apr 6 18:42:45
2020
[0.00] Board has DDR2
Just remembered an issue on my todo list: There have been some MTU
handling changes in the kernel networking API. This affected the
qmi_wwan QMAP handling. I am not sure about the current status. Will
have to dig a bit more. But this might be your problem.
Bjørn
Andre Valentin writes:
>> Is your modem connected by USB3 or USB2? Any of
>
> The modem is an integrated USB3 LTE modem. As said, without qmap it
> works stable.
ah, missed that important point.
There were a few qmap fixes between v4.14 and v5.4, but I guess we can
rule out those since you
Hi Bjørn.
W dniu 07.04.2020 o 16:50, Bjørn Mork pisze:
> Hannu Nyman writes:
>
>> I do not think that there is a nice clean solution, as I do not
>> remember seeing a solution of different packages for iniramfs, factory
>> and sysupgrade images.
>>
>> I would approach that with a two-step build
Hi!
Am 07.04.20 um 16:33 schrieb Bjørn Mork:
> Andre Valentin writes:
>
>> 3) Problems with QMI Interfaces
>> QMI is used for mobile phones and interact with the qmi_wwan driver in the
>> kernel. I had transmit issues,
>> switched the driver back to the 4.14 while still on 5.4. But the same
Hannu Nyman writes:
> I do not think that there is a nice clean solution, as I do not
> remember seeing a solution of different packages for iniramfs, factory
> and sysupgrade images.
>
> I would approach that with a two-step build process, using two .config
> recipes:
>
> * First a build with
Andre Valentin writes:
> 3) Problems with QMI Interfaces
> QMI is used for mobile phones and interact with the qmi_wwan driver in the
> kernel. I had transmit issues,
> switched the driver back to the 4.14 while still on 5.4. But the same problem
> happens again.
> Under 4.14 this was not a
I do not think that there is a nice clean solution, as I do not remember
seeing a solution of different packages for iniramfs, factory and sysupgrade
images.
I would approach that with a two-step build process, using two .config recipes:
* First a build with a smaller .config recipe without
On 07.04.2020 01:14, Dan Haab wrote:
@@ -87,20 +96,28 @@ bcm53xx_setup_macs()
case "$board" in
asus,rt-ac87u)
etXmacaddr=$(nvram get et1macaddr)
+ offset=1
;;
dlink,dir-885l | \
netgear,r7900 | \
netgear,r8000
The device I am playing with (ZyXEL WAP6805) can be upgraded to OpenWrt
by tftp'ing an OpenWrt initramfs image to it. But the image *must* be
less than 6815744 bytes, which is a hard coded limit in the OEM tftp
server.
The device also includes a Quantenna module, which needs a rather large
Buffalo LinkStation LS421DE is a dual bay NAS, based on Marvell Armada 370
Hardware:
SoC: Marvell Armada 88F6707-A1
CPU: Cortex-A9 1200 MHz, 1 core
Flash: SPI-NOR 1 MiB, NAND 512 MiB
RAM: DDR3 512 MiB
Ethernet:1x 10/100/1000 Mbps
USB: 1x
Add missing enbaled command help output.
Signed-off-by: Florian Eckert
---
package/base-files/Makefile| 2 +-
package/base-files/files/etc/rc.common | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/package/base-files/Makefile b/package/base-files/Makefile
index
Eneas Queiroz [2020-04-07 08:20:44]:
> I'm in the dark here with exactly what went wrong
I've made the build step more verbose[1]:
make[2]: Entering directory '/builds/ynezz/openwrt/scripts/config'
cc -O2-c -o conf.o conf.c
cc -O2-c -o confdata.o confdata.c
cc -O2-c -o expr.o
On Tue, Apr 7, 2020 at 5:19 AM Petr Štetiar wrote:
>
> Eneas U de Queiroz [2020-04-06 17:10:30]:
>
> Hi,
>
> > TLDR: You can't review this by only looking at the patches.
>
> Just tried to build[1] test it on x86/64 sunxi/a53 imx6 ipq40xx and it fails
> to build:
>
> make -s -C scripts/config
[CC Sergio who worked on upstream PCIE driver]
On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin wrote:
>
> Hi!
>
> Currently I'm having some serious problems with the new 5.4 port.
> 1) PCIe
> I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e connected
> to second bus on the
The "proper" vendor prefix for Ubiquiti is "ubnt", this is used in
all targets except ramips and also recommended by the kernel.
This patch adjusts the various board/image/device name variables
accordingly. Since we touch it anyway, this also adds the space
in "EdgeRouter X" as a hyphen to those
Hi!
Currently I'm having some serious problems with the new 5.4 port.
1) PCIe
I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e connected
to second bus on the first phy.
If booting the device, kernel hangs with a RST message, telling the device is
not detected. It seems the
This commit adds support for the Jotale JS76x8 series development boards.
These devices have the following specifications:
- SOC: MT7628AN/NN, MT7688AN, MT7628DAN
- RAM of MT7628AN/NN and MT7688AN: 64/128/256 MB (DDR2)
- RAM of MT7628DAN: 64 MB (DDR2)
- FLASH:8/16/32 MB (SPI NOR)
- Ethernet:3x
So far, image/device/board names for Mikrotik devices in mt7621 have
been used quite inconsistently.
This patch harmonizes the naming scheme by applying the same style
as used lately in ath79, i.e. using "RouterBOARD" as separate word
in the model name (instead of RB prefix for the number) and
Eneas U de Queiroz [2020-04-06 17:10:30]:
Hi,
> TLDR: You can't review this by only looking at the patches.
Just tried to build[1] test it on x86/64 sunxi/a53 imx6 ipq40xx and it fails
to build:
make -s -C scripts/config conf CC=cc: build failed.
1.
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Chuanhong Guo
> Sent: Dienstag, 7. April 2020 04:27
> To: openwrt-devel@lists.openwrt.org
> Cc: Chuanhong Guo
> Subject: [OpenWrt-Devel] [PATCH][RFC] Revert "ramips: mt7621:
36 matches
Mail list logo
