Thomas Albers [2019-11-12 00:02:37]:
Hi,
> Since the purpose of the previous patch is to use host pkg-config
> instead of toolchain pkg-config, wouldn't the more correct be to also
> use host bison?
as you can see, relying on anything from the host is very fragile, but in this
limited
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 ---
Hello!
Since the purpose of the
SPI frequency?
> Il giorno 11 nov 2019, alle ore 23:02, Kryma ha scritto:
>
> Hi,
>
>> That's wrong. You have 0x7d, not 0xfd ...
>
> There seems to be some discrepancy, possibly v1 vs v2. The specifications on
> the website and the partitioning seem to imply a 8MB image size -
Hi,
That's wrong. You have 0x7d, not 0xfd ...
There seems to be some discrepancy, possibly v1 vs v2. The
specifications on the website and the partitioning seem to imply a 8MB
image size - however, U-boot bootloader and the sum of MTD block sizes
gives us 16MB. Unsure, I tried both
Hi,
In addition to Adrian's comments, could it be that the device was a
802.11bgn router?
www.comfast.com.cn/index.php?m=content=index=show=19=23
Cheers,
Roger
El 11/11/19 a les 10:09, Adrian Schmutzler ha escrit:
> Hi,
>
>> +aliases {
>> +serial0 =
>> +led-boot =
Those symbols were removed in kernel 4.16:
commit 4670d610d59233b017a6ea1fa25bbf06dabbff42
Author: Rob Herring
PCI: Move OF-related PCI functions into PCI core
Fixes: FS#2588
Signed-off-by: Petr Štetiar
---
target/linux/ath79/config-4.19 | 3 ---
1 file changed, 3 deletions(-)
Hi Petr, "mailing list admins",
Le dim. 10 nov. 2019 à 10:05, Petr Štetiar a écrit :
>
> In order to avoid DMARC plague in the commit messages:
I saw this some days ago:
http://arc-spec.org/
Haven't had time to look at it, but it's supposed to be a solution to
the DMARC + mailing list mess
Commit 965f341aa9fd ("build: fix host menu config targets using
ncurses") has moved host's path with pkg-config (usually /usr/bin) at
the first place in PATH variable, which is now causing issues with bison
as BISON_PKGDATADIR points into STAGING_DIR_HOST, but the actual bison
used is the one
TL;DR
NAND-resident kernels seem likely to have bad blocks in the partition.
`KERNEL_SIZE := 2048k` seems likely to overflow a 2 MB partition
that has even a single bad block
The ath79-nand kernel is already over 1,900,000 bytes
What should the bad-block reservation be for a 2-MB
Hi,
On 11-11-19, Piotr Dymacz wrote:
> On 11.11.2019 20:33, Ivan Baktsheev wrote:
> > How to put this configuration into device? This is not a question for
> > OpenWrt developers, but for people, who build customized OpenWrt firmware.
> > It’s definitely better to customise build using
Hi Ivan,
On 11.11.2019 20:33, Ivan Baktsheev wrote:
Piotr,
On 11 Nov 2019, at 21:35, Piotr Dymacz wrote:
Hi Ivan,
On 11.11.2019 19:09, Ivan Baktsheev wrote:
Hi,
I want to add new device, but as of now I can upload firmware wirelessly and
then I need to connect using wired connection,
Piotr,
> On 11 Nov 2019, at 21:35, Piotr Dymacz wrote:
>
> Hi Ivan,
>
> On 11.11.2019 19:09, Ivan Baktsheev wrote:
>> Hi,
>> I want to add new device, but as of now I can upload firmware wirelessly and
>> then I need to connect using wired connection, because in stock OpenWrt
>> image
On Sat, Nov 9, 2019 at 6:53 AM Hauke Mehrtens wrote:
> On 11/7/19 2:31 PM, Florian Eckert wrote:
> > The rpcd service is an important service, but if the service stops
> > working for any reason, no one will ever respawn that service. With this
> > commit, the procd service will monitor if the
Hi Ivan,
On 11.11.2019 19:09, Ivan Baktsheev wrote:
Hi,
I want to add new device, but as of now I can upload firmware wirelessly and
then I need to connect using wired connection, because in stock OpenWrt image
wireless is disabled.
For my router (and probably many others) default WiFi SSID
I saw an notice for an update to the OpenWrt wiki:
Announcement for 19.07-rc1: https://openwrt.org/releases/start
Release Notes: https://openwrt.org/releases/19.07/notes-19.07.0-rc1
Thanks to all who helped to move us off top-dead-center.
Rich
___
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> Behalf Of Ivan Baktsheev
> Sent: Montag, 11. November 2019 19:10
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] wlan factory defaults
>
> Hi,
>
> I want to add new
Hi,
I want to add new device, but as of now I can upload firmware wirelessly and
then I need to connect using wired connection, because in stock OpenWrt image
wireless is disabled.
For my router (and probably many others) default WiFi SSID stored in factory
partition and it’s quite easy to
Hi,
> + aliases {
> + serial0 =
> + led-boot =
> + led-failsafe =
> + led-upgrade =
Please don't use LAN here, as it will be ambiguous.
For TP-Link CPE devices, we relied on rssi_high for this task, so either use
this one or choose
From: Pavel Balan
This patch adds support for the COMFAST CF-E130N v2, an outdoor wireless
CPE with a single Ethernet port and a 802.11an radio.
Specifications:
- QCA9531 SoC
- 1x 10/100 Mbps Ethernet, both with PoE-in support
- 64 MB of RAM (DDR2)
- 16 MB of FLASH
- 5 dBi built-in
This splits some base-files across subtargets, as done previously
on ath79 and ramips and also introduced for mt7629 subtarget here
already.
While at it, apply the following fixes:
- Remove lots of trailing whitespaces
- Remove wildcard on unielec,u7623-02-emmc-512m
- Remove inconsistent
On Mon, Nov 11, 2019 at 01:53:10PM +0100, Adrian Schmutzler wrote:
> > I've made specific effort to flash vendor firmware and confirmed by
> > testing on hardware that the vendor firmware doesn't need those
> > partitions. Isn't that enough? What important aspects did I not check?
>
> I haven't
Hi,
> > > + label = "dir-615-e4:green:power";
> >
> > Sorry for causing confusion here. I have had a look into ar71xx mach
> > files and they consistent use "d-link" as vendor for the led
> > labels. Thus, I think it makes more sense to revert that to the
> > previous version
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 ---
Signed-off-by: Kyle Copperfield
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 ---
Adds failsafe support to the
Hello Adrian,
Thank you very much for the review.
On Mon, Nov 11, 2019 at 12:12:47PM +0100, Adrian Schmutzler wrote:
> > + power_green: power_green {
>
> As stated above, change the _label_ to include a "led_" prefix, so
> this becomes "led_power_green: power_green {". Same for
Hi again,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> Behalf Of Paul Fertser
> Sent: Samstag, 9. November 2019 14:53
> To: openwrt-devel@lists.openwrt.org
> Cc: Paul Fertser ; Adrian Schmutzler
> ; tm...@gmx.de
> Subject:
Hi,
> > > + label = "dir-615-e4:green:power";
> >
> > Sorry for causing confusion here. I have had a look into ar71xx
> > mach files and they consistent use "d-link" as vendor for the
> > led labels. Thus, I think it makes more sense to revert that to
> > the previous
Hi Karl,
> Adrian Schmutzler wrote:
> > This provides a uci system config setting that will be set only
> > during initial setup. This can be used by uci-defaults script
> > to determine whether they are run during initial setup or after
> > a sysupgrade.
> Given that it will be set again
Hi Paul,
[...]
> + aliases {
> + led-boot = _amber;
Please include "led_" prefix for the labels, so _power_amber in this case.
> + led-failsafe = _amber;
> + led-running = _green;
> + led-upgrade = _amber;
> + };
> +
[...]
> + leds
29 matches
Mail list logo
