On Fri, Nov 1, 2019 at 11:29 AM Chuanhong Guo wrote:
>
> This patchset adds support for mt7629 and its rfb from mediatek.
> Currently, the secondary CPU doesn't bootup even if I backported
> the related commit, and wifi isn't available due to lack of driver.
> But beside those, everything else
This patch did the following things:
1. rename device compatible string
2. add earlycon into cmdline
3. add mac address location according to mt7629 eeprom layout
4. rename mtd partitions
Signed-off-by: Chuanhong Guo
---
.../files-4.19/arch/arm/boot/dts/mt7629-lynx-rfb.dts | 9 ++---
1
This patchset adds support for mt7629 and its rfb from mediatek.
Currently, the secondary CPU doesn't bootup even if I backported
the related commit, and wifi isn't available due to lack of driver.
But beside those, everything else seems to work just fine.
Chuanhong Guo (4):
mediatek: fix
base-files are added into subtarget directory like what's done
recently in ath79. For this subtarget, metadata checks are enforced
and a SUPPORTED_DEVICE is added to generate proper metadata.
Since we only have mt7629 support in 4.19, override KERNEL_PATCHVER
in target.mk for now.
Signed-off-by:
remove duplicated pinctrl nodes.
Signed-off-by: Chuanhong Guo
---
.../0227-arm-dts-Add-Unielec-U7623-DTS.patch | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git
a/target/linux/mediatek/patches-4.19/0227-arm-dts-Add-Unielec-U7623-DTS.patch
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 ---
Enables radio resource management
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 ---
Enables radio resource management
> Op 30 okt. 2019, om 22:16 heeft Stefan Lippers-Hollmann het
> volgende geschreven:
>
> Hi
>
> On 2019-10-30, Adrian Schmutzler wrote:
>> 1. We currently have work-in-progress 4.19 support PRs for ramips,
>> ipq806x and bcm63xx, still with considerable work to do at least for
>> the first
This patch adds ath79 support for Netgear WNDR4300.
Router was previously supported by ar71xx target only.
Note: device requires 'ar934x-nand' driver in kernel.
Specification
=
* Description: Netgear WNDR4300
* Loader: U-boot
* SOC: Atheros AR9344 (560 MHz)
* RAM: 128 MiB
*
Hello,
Changelog from v2:
* nand-netgear.mk file merged into main nand.mk makefile
* image filenames (factory and sysupgrade) changed to standard ones
('ubi-' prefix removed)
IMHO 'caldata' and 'caldata_backup' partitions should retain their names
to match both vendor and ar71xx labels, so
On 10/31/19 5:50 AM, Petr Štetiar wrote:
Ben Greear [2019-10-29 06:23:52]:
The original SO_BINDTODEVICE patches were offered upstream
and there is no interest.
It seems like there's finally some interest[1] and you do a good job over there.
Someone asked me to create a different branch,
the upstream kernel. the function mtk_napi_rx always be called if it have
packet to receive. it doesn't check status register.
but on openwrt code. check the status register first. then call fe_poll_rx.
if you clear status register. fe_poll_rx will will not be called next time.
Rosen Penev 於
Thank you for your answer.___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
> Hi,
> sorry for the foo, patch fails to apply, kindly rebase/resend it
> John
>
Hello John,
That's strange... Anyway, I rebased it again for master (fresh commit
df60a0852caf21de6684d38107f32a4eebc4579b) but it produces exactly the
same patch as v2. Tested and applied without
Hi all,
On Wed, Aug 28, 2019 at 7:37 PM Kristian Evensen
wrote:
>
> firewall3 currently creates one rule for each interface that is a member of a
> zone. On for example devices with multiple interfaces, the current firewall3
> behavior quickly leads to a lot of rules. In order to reduce the
*hello there.Dear friends!Thank you very much for checking my email, I am
very happy!I hope that you can spend a minute to see the whole email.I
believe it will be of great help to your business.We are a professional
watch trading company.Production of Michael Kors watches, Armani
watches,
Hello,
The following patch (submitted by you) has been updated in Patchwork:
* openwrt: [OpenWrt-Devel] hostapd: add IEEE 802.11k support
- http://patchwork.ozlabs.org/patch/1187244/
- for: OpenWrt development
was: New
now: Changes Requested
This email is a notification only
Kyle Copperfield via openwrt-devel
[2019-10-31 06:50:55]:
Hi,
you should fix your mail setup:
> 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
It turned out that the wifi wasn't working because of a missmatch in the mtd
"art" partition naming. The ath10k caldata hotplug script was expecting it named
"0:ART" instead of "art".
Wifi seems to work fine now.
I will drop those files in the next PR.
On 10/31/19 1:12 PM, Robert Marko wrote:
>
> Indeed, GitHub is just a mirror, so it won't work and disabling it makes
> sense.
"You must select at least one option."
So, I left "Allow rebase merging".
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
Adrian Schmutzler [2019-10-31 13:54:26]:
Hi,
welcome to the team! :-)
> does not seem to use Merge commits (which I'm glad about).
Same here.
> In case that a merge via GitHub won't be accepted at all (as it's just a
> mirror), I'd like to disable the merge button at all by the same set of
>
Hi,
GitHub features the "Merge Pull Request" button, which will add a Pull Request
to master with Merge commit.
OpenWrt master does not seem to use Merge commits (which I'm glad about).
I'd like to disable this option in the projects GitHub options, so if someone
clicks on that button (by
Ben Greear [2019-10-29 06:23:52]:
> The original SO_BINDTODEVICE patches were offered upstream
> and there is no interest.
It seems like there's finally some interest[1] and you do a good job over there.
> My recent changes would need rebasing to clean them up before upstreaming,
> and I am
On 30/10/2019 10:07, Michal Cieslakiewicz wrote:
This patch adds ath79 support for Netgear WNR2200.
Router was previously supported by ar71xx target only (8 MiB variant).
Netgear WNR2200 has two flash versions - 8MiB sold in EU, US etc. and
16 MiB for Russia and China markets. Apart from flash
On Thu, Oct 24, 2019 at 11:24 PM Karl Palsson wrote:
>
>
> Alin Nastac wrote:
> > From: Alin Nastac
> >
> > Scripts located in the directory /etc/mount_root.d will be
> > executed before mounting the overlay. It can be used to
> > implement configuration merges between old & new setup after
> >
On Thu, 31 Oct 2019 at 13:10, Daniel Danzberger wrote:
>
> Hi Jeff,
> >
> > .../arch/arm/boot/dts/qcom-ipq4019-bus.dtsi | 1142 +
> > .../include/dt-bindings/msm/msm-bus-ids.h | 869 +
> >
> > The sudden appearance of a need the MSM bus and its IDs worries me.
>
Hi Jeff,
>
> .../arch/arm/boot/dts/qcom-ipq4019-bus.dtsi | 1142 +
> .../include/dt-bindings/msm/msm-bus-ids.h | 869 +
>
> The sudden appearance of a need the MSM bus and its IDs worries me.
>
> With 25 devices already on the ipq40xx platform without them, it
For several devices, wmac MAC address is set from art 0x1002
explicitly by using mtd-mac-address although mtd-cal-data is
pulled from art 0x1000.
With the MAC address in 0x1002, the driver should automatically
use it when reading caldata from 0x1000. Thus, remove the
redundant mtd-mac-address for
On 31/10/2019, Bjørn Mork wrote:
> John Crispin writes:
>
>> Hi,
>> should we use v5.4 as our next kernel ?
>
> Hello John!
>
> I am still struggling to understand how the project makes release
> decisions. I don't think your question makes sense without considering
> target release dates, at
Because of old MT29F driver, it was basically a hack just to get
SPI-NANDs working.
On Thu, 31 Oct 2019 at 11:34, Daniel Danzberger wrote:
>
> Well, that makes sense and now it works :)
> I am just wondering why it has been working before with the other driver.
>
> On 10/31/19 11:30 AM, Robert
Well, that makes sense and now it works :)
I am just wondering why it has been working before with the other driver.
On 10/31/19 11:30 AM, Robert Marko wrote:
> On Thu, 31 Oct 2019 at 11:30, Daniel Danzberger wrote:
>>
>> I am already using 'ubi.mtd=rootfs root=/dev/ubiblock0_1', which has
On Thu, 31 Oct 2019 at 11:30, Daniel Danzberger wrote:
>
> I am already using 'ubi.mtd=rootfs root=/dev/ubiblock0_1', which has worked
> before
Well this is the issue, your ubi.mtd needs to be ubi.mtd=ubi
>
> On 10/31/19 11:26 AM, Robert Marko wrote:
> > On Thu, 31 Oct 2019 at 11:25, Daniel
I am already using 'ubi.mtd=rootfs root=/dev/ubiblock0_1', which has worked
before
On 10/31/19 11:26 AM, Robert Marko wrote:
> On Thu, 31 Oct 2019 at 11:25, Daniel Danzberger wrote:
>>
>> On the deprecated staging driver, it somehow directly came up as "rootfs" and
>> not "ubi". Even though it
On Thu, 31 Oct 2019 at 11:25, Daniel Danzberger wrote:
>
> On the deprecated staging driver, it somehow directly came up as "rootfs" and
> not "ubi". Even though it has been named "ubi" in the dts.
> Now the image won't boot because no rootfs is detected:
>
>
> [1.919001] Creating 1 MTD
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 ---
On 31/10/2019 10:00, 大雄 wrote:
On the deprecated staging driver, it somehow directly came up as "rootfs" and
not "ubi". Even though it has been named "ubi" in the dts.
Now the image won't boot because no rootfs is detected:
[1.919001] Creating 1 MTD partitions on "spi0.1":
[1.925399] 0x-0x0800
On 29.10.19 06:37, John Crispin wrote:
Hi,
should we use v5.4 as our next kernel ?
John
From my point of view: yes
I also really like the cadence of just following LTS release schedule
which doesn't enforce a hard deadline to do major bumps or risking
drying up of fixes from Stable
On Thu, 31 Oct 2019 at 11:17, Daniel Danzberger wrote:
>
> Using 'compatible = "spi-nand"' worked and the device got detected by the
> driver. However it won't create and "rootfs" partition like it did before.
>
> ---
> [1.901930] spi-nand spi0.1: GigaDevice SPI NAND was found.
> [
Using 'compatible = "spi-nand"' worked and the device got detected by the
driver. However it won't create and "rootfs" partition like it did before.
---
[1.901930] spi-nand spi0.1: GigaDevice SPI NAND was found.
[1.905266] spi-nand spi0.1: 128 MiB, block size: 128 KiB, page size: 2048,
Hi,
I think what you said is right.
But, logic is not the same with openwrt 15.05
From: Felix Fietkau
Date: 2019-10-31 17:50
To: 大雄; Hauke Mehrtens; openwrt-devel
Subject: Re: [OpenWrt-Devel] [PATCH-19.07] build: fix module strip invalid
On 2019-10-31 10:43, 大雄 wrote:
> Hi,
>
>
On 2019-10-31 10:43, 大雄 wrote:
> Hi,
>
> But sometimes, .ko not in menuconfig option.
> It's in the kernel_menuconfig option.
> So is no through ipk processing.
In that case the solution is to add a package for it.
- Felix
___
Hi,
But sometimes, .ko not in menuconfig option.
It's in the kernel_menuconfig option.
So is no through ipk processing.
There is no such problem in OpenWRT 15.05
From: Felix Fietkau
Date: 2019-10-31 17:24
To: 大雄; Hauke Mehrtens; openwrt-devel
Subject: Re: [OpenWrt-Devel]
John Crispin writes:
> Hi,
> should we use v5.4 as our next kernel ?
Hello John!
I am still struggling to understand how the project makes release
decisions. I don't think your question makes sense without considering
target release dates, at least in a yearly resolution, given the massive
On 2019-10-31 09:19, 大雄 wrote:
> Hi,
>
> I compile the kernel options, without any special open the DEBUG
> options.
> But the compiled KO module size is very big.
debug symbols are enabled by default. The .ko in the kernel tree is
quite big, but the one that ends up in the .ipk or on the
Hi,
I compile the kernel options, without any special open the DEBUG options.
But the compiled KO module size is very big.
From: Felix Fietkau
Date: 2019-10-31 15:31
To: 大雄; Hauke Mehrtens; openwrt-devel
Subject: Re: [OpenWrt-Devel] [PATCH-19.07] build: fix module strip invalid
Hi,
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 ---
Add IEEE802.11k neighbor and
Hi,
I don't think this patch is correct. The purpose of the existing
204-module_strip.patch is completely different from the stripping
behavior that you introduce, and you haven't described what issues you
have with the existing code.
Also, running strip inside the kernel build system is a bad
47 matches
Mail list logo
