[LEDE-DEV] [PATCH] linux/archs38: Add wireless AP capabilities similarly to axs101
Now when ath9k-htc USB dongle works with axs103 in OHCI mode quite fine adding corresponding features to default configuration. Signed-off-by: Alexey Brodkin --- target/linux/archs38/generic/profiles/00-default.mk | 2 +- target/linux/archs38/generic/profiles/02-axs103.mk | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/archs38/generic/profiles/00-default.mk b/target/linux/archs38/generic/profiles/00-default.mk index fe8f49b..b097108 100644 --- a/target/linux/archs38/generic/profiles/00-default.mk +++ b/target/linux/archs38/generic/profiles/00-default.mk @@ -7,7 +7,7 @@ define Profile/Default NAME:=Default Profile (all drivers) - PACKAGES:= kmod-usb-core kmod-usb-ohci kmod-mmc kmod-sdhci + PACKAGES:= kmod-usb-core kmod-usb-ohci kmod-mmc kmod-sdhci kmod-ath9k-htc wpad-mini endef define Profile/Default/Description diff --git a/target/linux/archs38/generic/profiles/02-axs103.mk b/target/linux/archs38/generic/profiles/02-axs103.mk index 1461697..156bef7 100644 --- a/target/linux/archs38/generic/profiles/02-axs103.mk +++ b/target/linux/archs38/generic/profiles/02-axs103.mk @@ -7,7 +7,7 @@ define Profile/axs103 NAME:=Synopsys DesignWare AXS103 - PACKAGES:= kmod-usb-core kmod-usb-ohci kmod-mmc kmod-sdhci + PACKAGES:= kmod-usb-core kmod-usb-ohci kmod-mmc kmod-sdhci kmod-ath9k-htc wpad-mini endef define Profile/axs103/Description -- 2.5.5 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 1/2] Revert "linux: arc: disable kernel unwinding to fix modules loading"
This reverts commit acd41539d630688e9891003c9b51cace3e113316. There's a fix in upstream that will at some point land in 4.4 stable as well so we'll get rid of this hack and with the next commit will apply upstream fix. Signed-off-by: Alexey Brodkin --- target/linux/arc770/config-4.4 | 3 ++- target/linux/archs38/config-4.4 | 4 +++- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/target/linux/arc770/config-4.4 b/target/linux/arc770/config-4.4 index d6905d7..87fd7e3 100644 --- a/target/linux/arc770/config-4.4 +++ b/target/linux/arc770/config-4.4 @@ -18,7 +18,7 @@ CONFIG_ARC_CURR_IN_REG=y CONFIG_ARC_DBG=y # CONFIG_ARC_DBG_TLB_MISS_COUNT is not set # CONFIG_ARC_DBG_TLB_PARANOIA is not set -# CONFIG_ARC_DW2_UNWIND is not set +CONFIG_ARC_DW2_UNWIND=y CONFIG_ARC_EMUL_UNALIGNED=y # CONFIG_ARC_FPU_SAVE_RESTORE is not set CONFIG_ARC_HAS_DCACHE=y @@ -78,6 +78,7 @@ CONFIG_HAVE_FUTEX_CMPXCHG=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_HAVE_MEMBLOCK=y +CONFIG_HAVE_MOD_ARCH_SPECIFIC=y CONFIG_HAVE_NET_DSA=y CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_PERF_EVENTS=y diff --git a/target/linux/archs38/config-4.4 b/target/linux/archs38/config-4.4 index c7dc264..9ea33c6 100644 --- a/target/linux/archs38/config-4.4 +++ b/target/linux/archs38/config-4.4 @@ -15,7 +15,7 @@ CONFIG_ARC_CURR_IN_REG=y CONFIG_ARC_DBG=y # CONFIG_ARC_DBG_TLB_MISS_COUNT is not set # CONFIG_ARC_DBG_TLB_PARANOIA is not set -# CONFIG_ARC_DW2_UNWIND is not set +CONFIG_ARC_DW2_UNWIND=y CONFIG_ARC_HAS_COH_CACHES=y CONFIG_ARC_HAS_DCACHE=y # CONFIG_ARC_HAS_DCCM is not set @@ -85,6 +85,7 @@ CONFIG_HAVE_FUTEX_CMPXCHG=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_HAVE_MEMBLOCK=y +CONFIG_HAVE_MOD_ARCH_SPECIFIC=y CONFIG_HAVE_NET_DSA=y CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_PERF_EVENTS=y @@ -174,6 +175,7 @@ CONFIG_SRCU=y CONFIG_STACKTRACE=y CONFIG_STMMAC_ETH=y CONFIG_STMMAC_PLATFORM=y +# CONFIG_SUNXI_SRAM is not set CONFIG_TICK_CPU_ACCOUNTING=y CONFIG_UNINLINE_SPIN_UNLOCK=y CONFIG_USB_SUPPORT=y -- 2.5.5 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 2/2] kernel: Add upstream fix for module loading
Instead of disabling unwinding entirely this upstream patch just disables generation of async unwind tables. Once the patch in question lands in stable 4.4 tree this change essentially must be removed (otherwise patch application will fail). Reference to upstream commit: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arc?id=f52e126cc7476196f44f3c313b7d9f0699a881fc Signed-off-by: Alexey Brodkin --- ...ensure-that-.debug_frame-is-generated-vs..patch | 46 ++ 1 file changed, 46 insertions(+) create mode 100644 target/linux/generic/patches-4.4/334-ARC-unwind-ensure-that-.debug_frame-is-generated-vs..patch diff --git a/target/linux/generic/patches-4.4/334-ARC-unwind-ensure-that-.debug_frame-is-generated-vs..patch b/target/linux/generic/patches-4.4/334-ARC-unwind-ensure-that-.debug_frame-is-generated-vs..patch new file mode 100644 index 000..a1e287c --- /dev/null +++ b/target/linux/generic/patches-4.4/334-ARC-unwind-ensure-that-.debug_frame-is-generated-vs..patch @@ -0,0 +1,46 @@ +From 23cd0de28cc7978130b770dd59b18ac143253351 Mon Sep 17 00:00:00 2001 +From: Vineet Gupta +Date: Tue, 28 Jun 2016 09:42:25 +0530 +Subject: [PATCH] ARC: unwind: ensure that .debug_frame is generated (vs. + .eh_frame) + +With recent binutils update to support dwarf CFI pseudo-ops in gas, we +now get .eh_frame vs. .debug_frame. Although the call frame info is +exactly the same in both, the CIE differs, which the current kernel +unwinder can't cope with. + +This broke both the kernel unwinder as well as loadable modules (latter +because of a new unhandled relo R_ARC_32_PCREL from .rela.eh_frame in +the module loader) + +The ideal solution would be to switch unwinder to .eh_frame. +For now however we can make do by just ensureing .debug_frame is +generated by removing -fasynchronous-unwind-tables + + .eh_framegenerated with -gdwarf-2 -fasynchronous-unwind-tables + .debug_frame generated with -gdwarf-2 + +Fixes STAR 9001058196 + +Cc: sta...@vger.kernel.org +Signed-off-by: Vineet Gupta +--- + arch/arc/Makefile | 2 -- + 1 file changed, 2 deletions(-) + +diff --git a/arch/arc/Makefile b/arch/arc/Makefile +index aeb1902..209d845 100644 +--- a/arch/arc/Makefile b/arch/arc/Makefile +@@ -48,8 +48,6 @@ endif + + endif + +-cflags-$(CONFIG_ARC_DW2_UNWIND) += -fasynchronous-unwind-tables +- + # By default gcc 4.8 generates dwarf4 which kernel unwinder can't grok + ifeq ($(atleast_gcc48),y) + cflags-$(CONFIG_ARC_DW2_UNWIND) += -gdwarf-2 +-- +2.5.5 + -- 2.5.5 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 1/2] Revert "linux: arc: disable kernel unwinding to fix modules loading"
This reverts commit acd41539d630688e9891003c9b51cace3e113316. There's a fix in upstream that will at some point land in 4.4 stable as well so we'll get rid of this hack and with the next commit will apply upstream fix. Signed-off-by: Alexey Brodkin --- target/linux/arc770/config-4.4 | 3 ++- target/linux/archs38/config-4.4 | 4 +++- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/target/linux/arc770/config-4.4 b/target/linux/arc770/config-4.4 index d6905d7..87fd7e3 100644 --- a/target/linux/arc770/config-4.4 +++ b/target/linux/arc770/config-4.4 @@ -18,7 +18,7 @@ CONFIG_ARC_CURR_IN_REG=y CONFIG_ARC_DBG=y # CONFIG_ARC_DBG_TLB_MISS_COUNT is not set # CONFIG_ARC_DBG_TLB_PARANOIA is not set -# CONFIG_ARC_DW2_UNWIND is not set +CONFIG_ARC_DW2_UNWIND=y CONFIG_ARC_EMUL_UNALIGNED=y # CONFIG_ARC_FPU_SAVE_RESTORE is not set CONFIG_ARC_HAS_DCACHE=y @@ -78,6 +78,7 @@ CONFIG_HAVE_FUTEX_CMPXCHG=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_HAVE_MEMBLOCK=y +CONFIG_HAVE_MOD_ARCH_SPECIFIC=y CONFIG_HAVE_NET_DSA=y CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_PERF_EVENTS=y diff --git a/target/linux/archs38/config-4.4 b/target/linux/archs38/config-4.4 index c7dc264..9ea33c6 100644 --- a/target/linux/archs38/config-4.4 +++ b/target/linux/archs38/config-4.4 @@ -15,7 +15,7 @@ CONFIG_ARC_CURR_IN_REG=y CONFIG_ARC_DBG=y # CONFIG_ARC_DBG_TLB_MISS_COUNT is not set # CONFIG_ARC_DBG_TLB_PARANOIA is not set -# CONFIG_ARC_DW2_UNWIND is not set +CONFIG_ARC_DW2_UNWIND=y CONFIG_ARC_HAS_COH_CACHES=y CONFIG_ARC_HAS_DCACHE=y # CONFIG_ARC_HAS_DCCM is not set @@ -85,6 +85,7 @@ CONFIG_HAVE_FUTEX_CMPXCHG=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_HAVE_MEMBLOCK=y +CONFIG_HAVE_MOD_ARCH_SPECIFIC=y CONFIG_HAVE_NET_DSA=y CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_PERF_EVENTS=y @@ -174,6 +175,7 @@ CONFIG_SRCU=y CONFIG_STACKTRACE=y CONFIG_STMMAC_ETH=y CONFIG_STMMAC_PLATFORM=y +# CONFIG_SUNXI_SRAM is not set CONFIG_TICK_CPU_ACCOUNTING=y CONFIG_UNINLINE_SPIN_UNLOCK=y CONFIG_USB_SUPPORT=y -- 2.5.5 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 0/2] kernel: arc: Better fix for modules loading
Current fix in Lede/OpenWRT was done when upstream kernel had no similar fix. Now when upstream fix is available let's take it. Alexey Brodkin (2): Revert "linux: arc: disable kernel unwinding to fix modules loading" kernel: Add upstream fix for module loading target/linux/arc770/config-4.4 | 3 +- target/linux/archs38/config-4.4| 4 +- ...ensure-that-.debug_frame-is-generated-vs..patch | 46 ++ 3 files changed, 51 insertions(+), 2 deletions(-) create mode 100644 target/linux/generic/patches-4.4/334-ARC-unwind-ensure-that-.debug_frame-is-generated-vs..patch -- 2.5.5 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/2] kernel: Add upstream fix for module loading
On 7 July 2016 at 12:37, Alexey Brodkin wrote: > Instead of disabling unwinding entirely this upstream patch > just disables generation of async unwind tables. > > Once the patch in question lands in stable 4.4 tree this change > essentially must be removed (otherwise patch application will fail). > > Reference to upstream commit: > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arc?id=f52e126cc7476196f44f3c313b7d9f0699a881fc > > Signed-off-by: Alexey Brodkin > --- > ...ensure-that-.debug_frame-is-generated-vs..patch | 46 > ++ > 1 file changed, 46 insertions(+) > create mode 100644 > target/linux/generic/patches-4.4/334-ARC-unwind-ensure-that-.debug_frame-is-generated-vs..patch As this is backport, please use 0xx prefix instead of 3xx. For more details see target/linux/generic/PATCHES ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] Mountd: Add sysupgrade functionality.
Hey,
thanks for all your answers!
On 07/07/2016 07:52 AM, Olivier Hardouin wrote:
> Though I like the idea of being able to upgrade using a usb stick, I
> wonder if mountd is the correct place to implement this.
> Indeed mountd is sending events via hotplug, so some other subsystems
> could listen to these ones and decide whether the upgrade should be
> based on some file of an attached usb disk or some other place (in the
> network).
> I think mountd should only do what it is good at, meaning detecting
> disk, finding partition, mounting filesystem and inform other
> subsystems.
Yes, good point. But then we should rewrite/redesign the whole update
process
including the sysupgrade binary in my opinion. For example writing a
small library and a daemon
which does the updates for us. A daemon which executes a sysupgrade tool
doesn't
make more sense for me as the mountd solution.
>
> On Wed, Jul 6, 2016 at 12:34 PM, Wang Linetkux wrote:
>> Another possible solution is to record the HASH of system image after
>> system upgrade is done. Next time when we try to do the system
>> upgrade, we can compare the recorded HASH value and the compute value
>> from system upgrade file?
Also a good idea but normally this should be done by the sysupgrade util
itself.
Building upgrade logic into the mountd is not the way we should go. See
above.
>>
>> 2016-07-06 18:18 GMT+08:00 Bruno Randolf :
>>> On 06/07/16 06:58, John Crispin wrote:
Hi Philipp
the thing that i am worried about is this process
1) plug a stick
2) mountd detects the upgrade file
3) mountd triggers sysupgrade
4) system reboots
5) goto 1)
there is no way to know at what point between 3 and 4 we need to unplug
the usb stick
Yep, I totally agree. A better solution based on this patch would be
copying the update to tmp
and execute it after the storage device is removed.
>>> One possible solution is to write a file, something like
>>> ".sysupgrade-applied" or remove the upgrade file before actually doing
>>> the upgrade, or during first boot.
>>>
>>> bruno
I think this solution is lacking the feature "batch update" on for
example 20 devices in row.
John
On 04/07/2016 18:56, Philipp Deppenwiese wrote:
> Extend the mountd with the ability to apply sysupgrades from mounted
> devices.
> Upgrade files are identified by filename and executed through the
> commandline sysupgrade utility of LEDE.
>
> Option List:
>
> config mountd 'sysupgrade'
> option check_filename firmware.bin (required)
> option save_config 1 (optional, default disabled)
> option delay 10 (optional, default disabled)
> option preserve_part 1 (optional, default disabled)
> option enabled 1
>
> The so called "filesearch" is done only in the root of a mounted
> devices.
>
> Signed-off-by: Philipp Deppenwiese
> ---
> CMakeLists.txt| 2 +-
> autofs.c | 19 ++-
> include/upgrade.h | 6 ++
> mount.c | 2 +
> upgrade.c | 162
> ++
> 5 files changed, 189 insertions(+), 2 deletions(-)
> create mode 100644 include/upgrade.h
> create mode 100644 upgrade.c
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 2e712cd..ed3602e 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -5,7 +5,7 @@ ADD_DEFINITIONS(-Os -ggdb -Wall -Werror --std=gnu99
> -Wmissing-declarations)
>
> SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "")
>
> -ADD_EXECUTABLE(mountd main.c log.c sys.c autofs.c mount.c timer.c
> signal.c ucix.c led.c fs.c ucix.c)
> +ADD_EXECUTABLE(mountd main.c log.c sys.c autofs.c mount.c timer.c
> signal.c ucix.c led.c fs.c ucix.c upgrade.c)
> TARGET_LINK_LIBRARIES(mountd uci ubox)
>
> INSTALL(TARGETS mountd
> diff --git a/autofs.c b/autofs.c
> index 4ad782d..79a3e97 100644
> --- a/autofs.c
> +++ b/autofs.c
> @@ -37,6 +37,13 @@ dev_t dev;
> time_t uci_timeout;
> char uci_path[32];
>
> +// Sysupgrade uci options
> +char uci_upgrade_filename[255];
> +int uci_upgrade_backup;
> +int uci_upgrade_delay;
> +int uci_upgrade_enabled;
> +int uci_upgrade_preserve_partition;
> +
> static void umount_autofs(void)
> {
> system_printf("umount %s 2> /dev/null", "/tmp/run/mountd/");
> @@ -186,18 +193,28 @@ static void autofs_cleanup_handler(void)
> static void autofs_init(void)
> {
> int kproto_version;
> -char *p;
> +char *p, *filename = NULL;
> struct uci_context *ctx;
> signal_init(autofs_cleanup_handler);
> ctx = ucix_init("mountd");
> uci_timeout = ucix_get_option_int(ctx, "mountd", "mountd",
> "timeout", 60);
> p = ucix_get_opt
Re: [LEDE-DEV] fstools testing help
Hi John, Could you please point me at where you merged my 2 patches? I want to ensure I am testing the same code that was causing segfaults. br Josua Mayer Am 05.07.2016 um 14:33 schrieb Álvaro Fernández Rojas: > Hi Josua > > Not mounted rw. > Unfortunately I didn't have time to check it thoroughly and I didn't see any > remarkable messages. > > – Álvaro. > > El 5/7/16 a las 14:31, Josua Mayer escribió: >> Hi Álvaro, >> >> Am 05.07.2016 um 14:17 schrieb Álvaro Fernández Rojas: >>> It fails when trying to boot a Raspberry Pi, and then it segfaults when >>> calling mount_root without any parameters.\ >> How do you see it fail when it boots? Messages? / not mounted rw? >>> >>> – Álvaro >>> >>> El 5/7/16 a las 14:14, Josua Mayer escribió: Hi John, Am 05.07.2016 um 09:44 schrieb John Crispin: > On 30/06/2016 09:23, Álvaro Fernández Rojas wrote: >> I will try to test it on RPi tonight. >> >> Regards, >> Álvaro. >> >> El 30/6/16 a las 9:21, John Crispin escribió: >>> Hi, >>> >>> i have just merged to fstools patches into my staging tree that address >>> a double mount issue and add back ext4 support. the ext4 patch >>> previously broke rPi and other ext4 targets, but i thini with josua's >>> patch applied it should work. i have done some basic testing already my >>> end but would like further etst coverage to make sure there are no >>> hidden regressions >>> >>> things that should be tested are >>> >>> * does ext4 mount work on eMMC >>> * does rootfs mount work on rPi >>> * does extroot still work with flat mounts >>> * does extroot still work with flat overlay mounts >>> >>> i have only tested the last one so far. >>> >>> John >>> > Hi Josua, > > after applying your patches, users of flat ext4 are seeing segfaults > when calling mount_root when manually calling mount_root? With which parameters? I will certainly look into it though. > John >> ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH mt76] tx: remove spurious semicolon
Remove spurious semicolon resulting in ieee80211_sta_set_buffered()
being always called independent from the result of the expression
evaluated by the preceding if-clause.
Spotted by gcc-6 while attempting to build the driver outside of the
buildroot.
Signed-off-by: Daniel Golle
---
tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tx.c b/tx.c
index 05313b6..f13afa2 100644
--- a/tx.c
+++ b/tx.c
@@ -198,7 +198,7 @@ mt76_txq_dequeue(struct mt76_dev *dev, struct mt76_txq
*mtxq, bool ps)
if (skb) {
u8 tid = skb->priority & IEEE80211_QOS_CTL_TID_MASK;
- if (ps && skb_queue_empty(&mtxq->retry_q));
+ if (ps && skb_queue_empty(&mtxq->retry_q))
ieee80211_sta_set_buffered(txq->sta, tid, false);
return skb;
--
2.9.0
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] LEDE & IPv6
Dear Devs, Congratulations on the fork of OpenWRT. I look forward to the new LEDE releases. I am writing here because I am not a committer, but would like to communicate with the Devs. I am a professional software tester, with extensive IPv6 experience. I have been working with IPv6 and OpenWRT specifically for the past year, and have found a few things lacking. I see in the TODO list, review IPv6 changes. I too would like to see what you have on the horizon for IPv6. I _can_ tell you that systemd is _not_ ready for IPv6, and have raised a few issues with the systemd team. Here are some of the investigations I have done with OpenWRT, systemd and IPv6. http://ipv6-net.blogspot.ca/2016/02/nat-tiness-and-v6brouter.html http://ipv6-net.blogspot.ca/2016/03/v6brouter-part-2-v6bridge-firewall.html http://ipv6-net.blogspot.ca/2016/04/systemd-oh-you-wanted-to-run-ipv6.html Although I am not a c-coder, I have been writing software for the past 30 years. And would be happy to contribute, especially in the area of IPv6. thanks, Craig... -- IPv6 is the future! http://ipv6-net.blogspot.ca/ ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] fstools testing help
On 07/07/2016 21:36, Josua Mayer wrote: > Hi John, > > Could you please point me at where you merged my 2 patches? I want to > ensure I am testing the same code that was causing segfaults. > > br > Josua Mayer > I already dropped them. John > Am 05.07.2016 um 14:33 schrieb Álvaro Fernández Rojas: >> Hi Josua >> >> Not mounted rw. >> Unfortunately I didn't have time to check it thoroughly and I didn't see any >> remarkable messages. >> >> – Álvaro. >> >> El 5/7/16 a las 14:31, Josua Mayer escribió: >>> Hi Álvaro, >>> >>> Am 05.07.2016 um 14:17 schrieb Álvaro Fernández Rojas: It fails when trying to boot a Raspberry Pi, and then it segfaults when calling mount_root without any parameters.\ >>> How do you see it fail when it boots? Messages? / not mounted rw? – Álvaro El 5/7/16 a las 14:14, Josua Mayer escribió: > Hi John, > > Am 05.07.2016 um 09:44 schrieb John Crispin: >> On 30/06/2016 09:23, Álvaro Fernández Rojas wrote: >>> I will try to test it on RPi tonight. >>> >>> Regards, >>> Álvaro. >>> >>> El 30/6/16 a las 9:21, John Crispin escribió: Hi, i have just merged to fstools patches into my staging tree that address a double mount issue and add back ext4 support. the ext4 patch previously broke rPi and other ext4 targets, but i thini with josua's patch applied it should work. i have done some basic testing already my end but would like further etst coverage to make sure there are no hidden regressions things that should be tested are * does ext4 mount work on eMMC * does rootfs mount work on rPi * does extroot still work with flat mounts * does extroot still work with flat overlay mounts i have only tested the last one so far. John >> Hi Josua, >> >> after applying your patches, users of flat ext4 are seeing segfaults >> when calling mount_root > when manually calling mount_root? With which parameters? > I will certainly look into it though. >> John >>> > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
