[OpenWrt-Devel] RE??RE: [PATCH] ramips: add support to JS7628 development board
Hi Adrian, Before I did this commit, I referred to "mt7628an_unielec_u7628-01-128m-16m.dts". Yes, I use the memory auto-detected function. Will you help me to modiy information concerning RAM size? Or if you have more advices, you can tell me, so I can modify them in the next commit. Best Robinson wu___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ipq40xx: fails to boot with SMP on Mikrotik hAP ac² / RBD52G-5HacD2HnD (WIP)
https://forum.openwrt.org/t/support-for-mikrotik-rb3011uias-rm/4064/412
I've been working on the hAP AC2 port, and haven't tested with SMP yet.
I posted the DTS files I came up with on the RB3011 thread as we were all
working on Mikrotik IPQ40XX boards.
I'm stuck on decompressing the WiFi radio calibration data , I can't seem
to figure out how to get the LZO / RLE portion to work.
I know exactly where the LZO / RLE data is as well.
If you want, I'll try to enable SMP and see if my board boots.
If you have any insight on WiFi, please let me know.
I'd like to help where I can.
On Mon, Jul 29, 2019 at 4:10 PM Baptiste Jonglez <
bapti...@bitsofnetworks.org> wrote:
> On 29-07-19, Hauke Mehrtens wrote:
> > On 7/29/19 11:25 AM, Baptiste Jonglez wrote:
> > > Is there something obviously wrong in the DTS? As far as I know, other
> > > ipq40xx devices don't have an issue with SMP.
> >
> > Did you try to revert this commit:
> >
> https://github.com/mmaker/openwrt/commit/481615d2f5e4bb053af805dccb901050e1e7a4ed
> >
> > The vendor dts file uses these 3 blocks, I do not know if they are
> > loaded to these regions by some boot loader or later by some driver. If
> > they are loaded there by the boot loader we should probably not use this
> > memory in Linux and let it run there.
>
> Yes, this commit is just a recent attempt to fix a warning during boot.
> The upstream DTS (qcom-ipq4019.dtsi) already reserves a memory region,
> exactly for the reasons you mention:
> https://patchwork.kernel.org/patch/10347459/
>
> This reserved region in the dtsi is overlapping with the one in the DTS,
> and there was a warning during boot ("OVERLAP DETECTED" below). The
> commit did fix the warning, but did not change anything about the initial
> problem with SMP.
>
> > I attached the vendor.dts file we extracted from the flash of the board.
>
> Thanks, could you spot anything interesting in it? It looks very verbose.
>
> Baptiste
>
> > > PS: here is the failing bootlog, getting stuck after "Testing write
> buffer coherency":
> > >
> > > [0.00] Booting Linux on physical CPU 0x0
> > > [0.00] Linux version 4.19.57 (bjonglez@gcc14) (gcc version
> 7.4.0 (OpenWrt GCC 7.4.0 r10506-a0c97101d6)) #0 SMP Mon Jul 29 08:51:07 2019
> > > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7),
> cr=10c5387d
> > > [0.00] CPU: div instructions available: patching division code
> > > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> > > [0.00] OF: fdt: Machine model: Mikrotik RouterBOARD
> RBD52G-5HacD2HnD (hAP ac²)
> > > [0.00] bootconsole [earlycon0] enabled
> > > [0.00] Memory policy: Data cache writealloc
> > > [0.00] OF: reserved mem: OVERLAP DETECTED!
> > > [0.00] rsvd2@87B0 (0x87b0--0x8800) overlaps with
> smem@87e0 (0x87e0--0x87e8)
> > > [0.00] random: get_random_bytes called from
> start_kernel+0x7c/0x438 with crng_init=0
> > > [0.00] percpu: Embedded 15 pages/cpu s29964 r8192 d23284 u61440
> > > [0.00] Built 1 zonelists, mobility grouping on. Total pages:
> 60864
> > > [0.00] Kernel command line: earlyprintk
> > > [0.00] Dentry cache hash table entries: 32768 (order: 5,
> 131072 bytes)
> > > [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536
> bytes)
> > > [0.00] Memory: 232420K/245760K available (4720K kernel code,
> 168K rwdata, 1288K rodata, 3072K init, 231K bss, 13340K reserved, 0K
> cma-reserved, 0K highmem)
> > > [0.00] Virtual kernel memory layout:
> > > [0.00] vector : 0x - 0x1000 ( 4 kB)
> > > [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB)
> > > [0.00] vmalloc : 0xd080 - 0xff80 ( 752 MB)
> > > [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB)
> > > [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB)
> > > [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB)
> > > [0.00] .text : 0x(ptrval) - 0x(ptrval) (5713 kB)
> > > [0.00] .init : 0x(ptrval) - 0x(ptrval) (3072 kB)
> > > [0.00] .data : 0x(ptrval) - 0x(ptrval) ( 168 kB)
> > > [0.00].bss : 0x(ptrval) - 0x(ptrval) ( 232 kB)
> > > [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4,
> Nodes=1
> > > [0.00] rcu: Hierarchical RCU implementation.
> > > [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> > > [0.00] arch_timer: cp15 timer(s) running at 48.00MHz (virt).
> > > [0.00] clocksource: arch_sys_counter: mask: 0xff
> max_cycles: 0xb11fd3bfb, max_idle_ns: 440795203732 ns
> > > [0.07] sched_clock: 56 bits at 48MHz, resolution 20ns, wraps
> every 4398046511096ns
> > > [0.007985] Switching to timer-based delay loop, resolution 20ns
> > > [0.014242] Calibrating delay loop (skipped), value calculated
> using timer frequenc
Re: [OpenWrt-Devel] ipq40xx: fails to boot with SMP on Mikrotik hAP ac² / RBD52G-5HacD2HnD (WIP)
On 29-07-19, Hauke Mehrtens wrote:
> On 7/29/19 11:25 AM, Baptiste Jonglez wrote:
> > Is there something obviously wrong in the DTS? As far as I know, other
> > ipq40xx devices don't have an issue with SMP.
>
> Did you try to revert this commit:
> https://github.com/mmaker/openwrt/commit/481615d2f5e4bb053af805dccb901050e1e7a4ed
>
> The vendor dts file uses these 3 blocks, I do not know if they are
> loaded to these regions by some boot loader or later by some driver. If
> they are loaded there by the boot loader we should probably not use this
> memory in Linux and let it run there.
Yes, this commit is just a recent attempt to fix a warning during boot.
The upstream DTS (qcom-ipq4019.dtsi) already reserves a memory region,
exactly for the reasons you mention:
https://patchwork.kernel.org/patch/10347459/
This reserved region in the dtsi is overlapping with the one in the DTS,
and there was a warning during boot ("OVERLAP DETECTED" below). The
commit did fix the warning, but did not change anything about the initial
problem with SMP.
> I attached the vendor.dts file we extracted from the flash of the board.
Thanks, could you spot anything interesting in it? It looks very verbose.
Baptiste
> > PS: here is the failing bootlog, getting stuck after "Testing write buffer
> > coherency":
> >
> > [0.00] Booting Linux on physical CPU 0x0
> > [0.00] Linux version 4.19.57 (bjonglez@gcc14) (gcc version 7.4.0
> > (OpenWrt GCC 7.4.0 r10506-a0c97101d6)) #0 SMP Mon Jul 29 08:51:07 2019
> > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7),
> > cr=10c5387d
> > [0.00] CPU: div instructions available: patching division code
> > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> > instruction cache
> > [0.00] OF: fdt: Machine model: Mikrotik RouterBOARD
> > RBD52G-5HacD2HnD (hAP ac²)
> > [0.00] bootconsole [earlycon0] enabled
> > [0.00] Memory policy: Data cache writealloc
> > [0.00] OF: reserved mem: OVERLAP DETECTED!
> > [0.00] rsvd2@87B0 (0x87b0--0x8800) overlaps with
> > smem@87e0 (0x87e0--0x87e8)
> > [0.00] random: get_random_bytes called from start_kernel+0x7c/0x438
> > with crng_init=0
> > [0.00] percpu: Embedded 15 pages/cpu s29964 r8192 d23284 u61440
> > [0.00] Built 1 zonelists, mobility grouping on. Total pages: 60864
> > [0.00] Kernel command line: earlyprintk
> > [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072
> > bytes)
> > [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> > [0.00] Memory: 232420K/245760K available (4720K kernel code, 168K
> > rwdata, 1288K rodata, 3072K init, 231K bss, 13340K reserved, 0K
> > cma-reserved, 0K highmem)
> > [0.00] Virtual kernel memory layout:
> > [0.00] vector : 0x - 0x1000 ( 4 kB)
> > [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB)
> > [0.00] vmalloc : 0xd080 - 0xff80 ( 752 MB)
> > [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB)
> > [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB)
> > [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB)
> > [0.00] .text : 0x(ptrval) - 0x(ptrval) (5713 kB)
> > [0.00] .init : 0x(ptrval) - 0x(ptrval) (3072 kB)
> > [0.00] .data : 0x(ptrval) - 0x(ptrval) ( 168 kB)
> > [0.00].bss : 0x(ptrval) - 0x(ptrval) ( 232 kB)
> > [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> > [0.00] rcu: Hierarchical RCU implementation.
> > [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> > [0.00] arch_timer: cp15 timer(s) running at 48.00MHz (virt).
> > [0.00] clocksource: arch_sys_counter: mask: 0xff
> > max_cycles: 0xb11fd3bfb, max_idle_ns: 440795203732 ns
> > [0.07] sched_clock: 56 bits at 48MHz, resolution 20ns, wraps every
> > 4398046511096ns
> > [0.007985] Switching to timer-based delay loop, resolution 20ns
> > [0.014242] Calibrating delay loop (skipped), value calculated using
> > timer frequency.. 96.00 BogoMIPS (lpj=48)
> > [0.024315] pid_max: default: 32768 minimum: 301
> > [0.029081] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
> > [0.035524] Mountpoint-cache hash table entries: 1024 (order: 0, 4096
> > bytes)
> > [0.043539] CPU: Testing write buffer coherency: ok
> >
> >
> > Here is a working bootlog, same image but with "nosmp":
> >
> > [0.00] Booting Linux on physical CPU 0x0
> > [0.00] Linux version 4.19.57 (bjonglez@gcc14) (gcc version 7.4.0
> > (OpenWrt GCC 7.4.0 r10506-a0c97101d6)) #0 SMP Mon Jul 29 08:13:02 2019
> > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7),
> > cr=10c5387d
> > [0.00] CPU: div instructions available: patc
Re: [OpenWrt-Devel] ipq40xx: fails to boot with SMP on Mikrotik hAP ac² / RBD52G-5HacD2HnD (WIP)
On 7/29/19 11:25 AM, Baptiste Jonglez wrote: > Hi, > > I am trying to finish the port of Mikrotik hAP ac², but I still can't get > it to boot properly with SMP. Adding "nosmp" to the cmdline makes the > initramfs boot fine. > > Here is the work-in-progress tree that Hauke based on the RB450Gx4 work: > > https://github.com/mmaker/openwrt/tree/device/hAP-ac%C2%B2 > https://github.com/mmaker/openwrt/blob/device/hAP-ac%C2%B2/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4018-rbd52g-5hacd2hnd.dts > Wiki page: https://openwrt.org/inbox/mikrotik/mikrotik_hap_ac > > I tried Pavel's patch "ipq40xx: add support for secondary cores bringup" > from http://lists.infradead.org/pipermail/openwrt-devel/2019-May/017057.html > but it did not seem to change anything. > > Is there something obviously wrong in the DTS? As far as I know, other > ipq40xx devices don't have an issue with SMP. Did you try to revert this commit: https://github.com/mmaker/openwrt/commit/481615d2f5e4bb053af805dccb901050e1e7a4ed The vendor dts file uses these 3 blocks, I do not know if they are loaded to these regions by some boot loader or later by some driver. If they are loaded there by the boot loader we should probably not use this memory in Linux and let it run there. I attached the vendor.dts file we extracted from the flash of the board. > > Thanks, > Baptiste > > > PS: here is the failing bootlog, getting stuck after "Testing write buffer > coherency": > > [0.00] Booting Linux on physical CPU 0x0 > [0.00] Linux version 4.19.57 (bjonglez@gcc14) (gcc version 7.4.0 > (OpenWrt GCC 7.4.0 r10506-a0c97101d6)) #0 SMP Mon Jul 29 08:51:07 2019 > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d > [0.00] CPU: div instructions available: patching division code > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing > instruction cache > [0.00] OF: fdt: Machine model: Mikrotik RouterBOARD RBD52G-5HacD2HnD > (hAP ac²) > [0.00] bootconsole [earlycon0] enabled > [0.00] Memory policy: Data cache writealloc > [0.00] OF: reserved mem: OVERLAP DETECTED! > [0.00] rsvd2@87B0 (0x87b0--0x8800) overlaps with > smem@87e0 (0x87e0--0x87e8) > [0.00] random: get_random_bytes called from start_kernel+0x7c/0x438 > with crng_init=0 > [0.00] percpu: Embedded 15 pages/cpu s29964 r8192 d23284 u61440 > [0.00] Built 1 zonelists, mobility grouping on. Total pages: 60864 > [0.00] Kernel command line: earlyprintk > [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) > [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) > [0.00] Memory: 232420K/245760K available (4720K kernel code, 168K > rwdata, 1288K rodata, 3072K init, 231K bss, 13340K reserved, 0K cma-reserved, > 0K highmem) > [0.00] Virtual kernel memory layout: > [0.00] vector : 0x - 0x1000 ( 4 kB) > [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) > [0.00] vmalloc : 0xd080 - 0xff80 ( 752 MB) > [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) > [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) > [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) > [0.00] .text : 0x(ptrval) - 0x(ptrval) (5713 kB) > [0.00] .init : 0x(ptrval) - 0x(ptrval) (3072 kB) > [0.00] .data : 0x(ptrval) - 0x(ptrval) ( 168 kB) > [0.00].bss : 0x(ptrval) - 0x(ptrval) ( 232 kB) > [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 > [0.00] rcu: Hierarchical RCU implementation. > [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 > [0.00] arch_timer: cp15 timer(s) running at 48.00MHz (virt). > [0.00] clocksource: arch_sys_counter: mask: 0xff > max_cycles: 0xb11fd3bfb, max_idle_ns: 440795203732 ns > [0.07] sched_clock: 56 bits at 48MHz, resolution 20ns, wraps every > 4398046511096ns > [0.007985] Switching to timer-based delay loop, resolution 20ns > [0.014242] Calibrating delay loop (skipped), value calculated using timer > frequency.. 96.00 BogoMIPS (lpj=48) > [0.024315] pid_max: default: 32768 minimum: 301 > [0.029081] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) > [0.035524] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 > bytes) > [0.043539] CPU: Testing write buffer coherency: ok > > > Here is a working bootlog, same image but with "nosmp": > > [0.00] Booting Linux on physical CPU 0x0 > [0.00] Linux version 4.19.57 (bjonglez@gcc14) (gcc version 7.4.0 > (OpenWrt GCC 7.4.0 r10506-a0c97101d6)) #0 SMP Mon Jul 29 08:13:02 2019 > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d > [0.00] CPU: div instructions
[OpenWrt-Devel] [PATCH] tools/patch: apply upstream patch for CVE-2019-13636
In GNU patch through 2.7.6, the following of symlinks is mishandled in
certain cases other than input files. This affects inp.c and util.c.
https://nvd.nist.gov/vuln/detail/CVE-2019-13636
Signed-off-by: Russell Senior
---
tools/patch/Makefile | 2 +-
tools/patch/patches/050-CVE-2019-13636.patch | 108 +++
2 files changed, 109 insertions(+), 1 deletion(-)
create mode 100644 tools/patch/patches/050-CVE-2019-13636.patch
diff --git a/tools/patch/Makefile b/tools/patch/Makefile
index cab9fee9f6..3bcf668b04 100644
--- a/tools/patch/Makefile
+++ b/tools/patch/Makefile
@@ -8,7 +8,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=patch
PKG_VERSION:=2.7.6
-PKG_RELEASE:=4
+PKG_RELEASE:=5
PKG_CPE_ID:=cpe:/a:gnu:patch
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
diff --git a/tools/patch/patches/050-CVE-2019-13636.patch
b/tools/patch/patches/050-CVE-2019-13636.patch
new file mode 100644
index 00..e62c3d4175
--- /dev/null
+++ b/tools/patch/patches/050-CVE-2019-13636.patch
@@ -0,0 +1,108 @@
+From dce4683cbbe107a95f1f0d45fabc304acfb5d71a Mon Sep 17 00:00:00 2001
+From: Andreas Gruenbacher
+Date: Mon, 15 Jul 2019 16:21:48 +0200
+Subject: Don't follow symlinks unless --follow-symlinks is given
+
+* src/inp.c (plan_a, plan_b), src/util.c (copy_to_fd, copy_file,
+append_to_file): Unless the --follow-symlinks option is given, open files with
+the O_NOFOLLOW flag to avoid following symlinks. So far, we were only doing
+that consistently for input files.
+* src/util.c (create_backup): When creating empty backup files, (re)create them
+with O_CREAT | O_EXCL to avoid following symlinks in that case as well.
+---
+ src/inp.c | 12 ++--
+ src/util.c | 14 +++---
+ 2 files changed, 21 insertions(+), 5 deletions(-)
+
+diff --git a/src/inp.c b/src/inp.c
+index 32d0919..22d7473 100644
+--- a/src/inp.c
b/src/inp.c
+@@ -238,8 +238,13 @@ plan_a (char const *filename)
+ {
+ if (S_ISREG (instat.st_mode))
+ {
+-int ifd = safe_open (filename, O_RDONLY|binary_transput, 0);
++int flags = O_RDONLY | binary_transput;
+ size_t buffered = 0, n;
++int ifd;
++
++if (! follow_symlinks)
++ flags |= O_NOFOLLOW;
++ifd = safe_open (filename, flags, 0);
+ if (ifd < 0)
+ pfatal ("can't open file %s", quotearg (filename));
+
+@@ -340,6 +345,7 @@ plan_a (char const *filename)
+ static void
+ plan_b (char const *filename)
+ {
++ int flags = O_RDONLY | binary_transput;
+ int ifd;
+ FILE *ifp;
+ int c;
+@@ -353,7 +359,9 @@ plan_b (char const *filename)
+
+ if (instat.st_size == 0)
+ filename = NULL_DEVICE;
+- if ((ifd = safe_open (filename, O_RDONLY | binary_transput, 0)) < 0
++ if (! follow_symlinks)
++flags |= O_NOFOLLOW;
++ if ((ifd = safe_open (filename, flags, 0)) < 0
+ || ! (ifp = fdopen (ifd, binary_transput ? "rb" : "r")))
+ pfatal ("Can't open file %s", quotearg (filename));
+ if (TMPINNAME_needs_removal)
+diff --git a/src/util.c b/src/util.c
+index 1cc08ba..fb38307 100644
+--- a/src/util.c
b/src/util.c
+@@ -388,7 +388,7 @@ create_backup (char const *to, const struct stat *to_st,
bool leave_original)
+
+ try_makedirs_errno = ENOENT;
+ safe_unlink (bakname);
+-while ((fd = safe_open (bakname, O_CREAT | O_WRONLY | O_TRUNC, 0666))
< 0)
++while ((fd = safe_open (bakname, O_CREAT | O_EXCL | O_WRONLY |
O_TRUNC, 0666)) < 0)
+ {
+ if (errno != try_makedirs_errno)
+ pfatal ("Can't create file %s", quotearg (bakname));
+@@ -579,10 +579,13 @@ create_file (char const *file, int open_flags, mode_t
mode,
+ static void
+ copy_to_fd (const char *from, int tofd)
+ {
++ int from_flags = O_RDONLY | O_BINARY;
+ int fromfd;
+ ssize_t i;
+
+- if ((fromfd = safe_open (from, O_RDONLY | O_BINARY, 0)) < 0)
++ if (! follow_symlinks)
++from_flags |= O_NOFOLLOW;
++ if ((fromfd = safe_open (from, from_flags, 0)) < 0)
+ pfatal ("Can't reopen file %s", quotearg (from));
+ while ((i = read (fromfd, buf, bufsize)) != 0)
+ {
+@@ -625,6 +628,8 @@ copy_file (char const *from, char const *to, struct stat
*tost,
+ else
+ {
+ assert (S_ISREG (mode));
++ if (! follow_symlinks)
++ to_flags |= O_NOFOLLOW;
+ tofd = create_file (to, O_WRONLY | O_BINARY | to_flags, mode,
+ to_dir_known_to_exist);
+ copy_to_fd (from, tofd);
+@@ -640,9 +645,12 @@ copy_file (char const *from, char const *to, struct stat
*tost,
+ void
+ append_to_file (char const *from, char const *to)
+ {
++ int to_flags = O_WRONLY | O_APPEND | O_BINARY;
+ int tofd;
+
+- if ((tofd = safe_open (to, O_WRONLY | O_BINARY | O_APPEND, 0)) < 0)
++ if (! follow_symlinks)
++to_flags |= O_NOFOLLOW;
++ if ((tofd = safe_open (to, to_flags, 0)) < 0)
+ pfatal ("Can't reopen file %s", quotearg (to));
+ copy_to_fd (from, tofd);
+ if (close (tofd) != 0)
+--
+cgit v1.0-41
Re: [OpenWrt-Devel] Problem reading flash zones in ath79
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 ---
Hi Enrico,
On Mon, Jul 29, 2019 at 3:40 PM Enrico Mioso wrote:
>
> Hello guys!
>
> I experienced an issue where I wasn't able to read all of a flash region on
> an ATH79 device, the Archer C60 V2.
> Taking a look, it seems the MTD layer will return only 512-bytes when reading
> an mtd device via the mtdblock layer.
I believe that this is related to the erase/write size of the flash on
your device (see /sys/class/mtd/*/{erase,write}size).
> So, in the case of my Archer C60 V2:
> - the first partition, "factory-boot" won't be completely readable (256 bytes
> will be missing)
> - sameholds for "mac" partition
> - same holds for the "u-boot" partition
>
> This will prevent users from making proper backups of their devices.
> Should this be fixed on the mtd layer or on thedevicetrees we're using?
> Of course I don't think this is ath79 specific...
I suggest to also ask on the linux-mtd mailing list if you don't get
an answer here or before you spend time coding: [0]
Martin
[0] http://lists.infradead.org/mailman/listinfo/linux-mtd
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why ath79 has been made source-only on 19.07?
On Mon, Jul 29, 2019 at 05:14:09PM +, Sebastian Kemper wrote: > Am July 29, 2019 4:30:33 PM UTC schrieb Dmitry Tunin > : > >There is also a few devices that have been recently added as ath79 > >only. So they won't be supported. > > > >пн, 29 июл. 2019 г. в 19:28, Dmitry Tunin : > >> > >> 2b074654b0f259518aa56e0975ca8e26c0c12bc9 > >> > >> I see no reason why not to build both ar71xx and ath79 for devices > >> that have been ported to ath79 already. Many people already use > >> 19.07 branch and wait for the release. > >> > >> That will require lots of custom builds. What is the point of > >excluding ath79? > > Good points. I'd like to see ath79 builds for 19.07 as well. And even > if that means more stress on the build bots it'd be only every point > release, not constantly. At least that's my understanding. > > Just my opinion. I don't have voting rights :-) > > Kind regards, > Seb Also having ath79 builds would likely result in some additional feedback (about something that doesn't work on ath79 but does work on ar71xx). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why ath79 has been made source-only on 19.07?
Am July 29, 2019 4:30:33 PM UTC schrieb Dmitry Tunin : >There is also a few devices that have been recently added as ath79 >only. So they won't be supported. > >пн, 29 июл. 2019 г. в 19:28, Dmitry Tunin : >> >> 2b074654b0f259518aa56e0975ca8e26c0c12bc9 >> >> I see no reason why not to build both ar71xx and ath79 for devices >> that have been ported to ath79 already. Many people already use 19.07 >> branch and wait for the release. >> >> That will require lots of custom builds. What is the point of >excluding ath79? > >___ >openwrt-devel mailing list >openwrt-devel@lists.openwrt.org >https://lists.openwrt.org/mailman/listinfo/openwrt-devel Good points. I'd like to see ath79 builds for 19.07 as well. And even if that means more stress on the build bots it'd be only every point release, not constantly. At least that's my understanding. Just my opinion. I don't have voting rights :-) Kind regards, Seb ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why ath79 has been made source-only on 19.07?
There is also a few devices that have been recently added as ath79 only. So they won't be supported. пн, 29 июл. 2019 г. в 19:28, Dmitry Tunin : > > 2b074654b0f259518aa56e0975ca8e26c0c12bc9 > > I see no reason why not to build both ar71xx and ath79 for devices > that have been ported to ath79 already. Many people already use 19.07 > branch and wait for the release. > > That will require lots of custom builds. What is the point of excluding ath79? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Why ath79 has been made source-only on 19.07?
2b074654b0f259518aa56e0975ca8e26c0c12bc9 I see no reason why not to build both ar71xx and ath79 for devices that have been ported to ath79 already. Many people already use 19.07 branch and wait for the release. That will require lots of custom builds. What is the point of excluding ath79? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: add support to JS7628 development board
Hi again, > + compatible = "zhuotk,js7628-16m-128m", "zhuotk,js76x8", > "mediatek,mt7628an-soc"; > + model = "ZhuoTK JS7628 (16M flash/128M RAM)"; Is memory auto-detected on this target (to me it looks that)? If yes, I'd remove all information concerning RAM size (except from hardware specs in commit description), meaning - compatible - model - device definition in mt76x8.mk - DEVICE_VARIANT - (name adjustments in other files) Best Adrian Schmutzler openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Problem reading flash zones in ath79
Hello guys! I experienced an issue where I wasn't able to read all of a flash region on an ATH79 device, the Archer C60 V2. Taking a look, it seems the MTD layer will return only 512-bytes when reading an mtd device via the mtdblock layer. So, in the case of my Archer C60 V2: - the first partition, "factory-boot" won't be completely readable (256 bytes will be missing) - sameholds for "mac" partition - same holds for the "u-boot" partition This will prevent users from making proper backups of their devices. Should this be fixed on the mtd layer or on thedevicetrees we're using? Of course I don't think this is ath79 specific... Thanks, Enrico ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ipq40xx: fails to boot with SMP on Mikrotik hAP ac² / RBD52G-5HacD2HnD (WIP)
Hi, I am trying to finish the port of Mikrotik hAP ac², but I still can't get it to boot properly with SMP. Adding "nosmp" to the cmdline makes the initramfs boot fine. Here is the work-in-progress tree that Hauke based on the RB450Gx4 work: https://github.com/mmaker/openwrt/tree/device/hAP-ac%C2%B2 https://github.com/mmaker/openwrt/blob/device/hAP-ac%C2%B2/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4018-rbd52g-5hacd2hnd.dts Wiki page: https://openwrt.org/inbox/mikrotik/mikrotik_hap_ac I tried Pavel's patch "ipq40xx: add support for secondary cores bringup" from http://lists.infradead.org/pipermail/openwrt-devel/2019-May/017057.html but it did not seem to change anything. Is there something obviously wrong in the DTS? As far as I know, other ipq40xx devices don't have an issue with SMP. Thanks, Baptiste PS: here is the failing bootlog, getting stuck after "Testing write buffer coherency": [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.19.57 (bjonglez@gcc14) (gcc version 7.4.0 (OpenWrt GCC 7.4.0 r10506-a0c97101d6)) #0 SMP Mon Jul 29 08:51:07 2019 [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] OF: fdt: Machine model: Mikrotik RouterBOARD RBD52G-5HacD2HnD (hAP ac²) [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: Data cache writealloc [0.00] OF: reserved mem: OVERLAP DETECTED! [0.00] rsvd2@87B0 (0x87b0--0x8800) overlaps with smem@87e0 (0x87e0--0x87e8) [0.00] random: get_random_bytes called from start_kernel+0x7c/0x438 with crng_init=0 [0.00] percpu: Embedded 15 pages/cpu s29964 r8192 d23284 u61440 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 60864 [0.00] Kernel command line: earlyprintk [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Memory: 232420K/245760K available (4720K kernel code, 168K rwdata, 1288K rodata, 3072K init, 231K bss, 13340K reserved, 0K cma-reserved, 0K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) [0.00] vmalloc : 0xd080 - 0xff80 ( 752 MB) [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0x(ptrval) - 0x(ptrval) (5713 kB) [0.00] .init : 0x(ptrval) - 0x(ptrval) (3072 kB) [0.00] .data : 0x(ptrval) - 0x(ptrval) ( 168 kB) [0.00].bss : 0x(ptrval) - 0x(ptrval) ( 232 kB) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [0.00] rcu: Hierarchical RCU implementation. [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [0.00] arch_timer: cp15 timer(s) running at 48.00MHz (virt). [0.00] clocksource: arch_sys_counter: mask: 0xff max_cycles: 0xb11fd3bfb, max_idle_ns: 440795203732 ns [0.07] sched_clock: 56 bits at 48MHz, resolution 20ns, wraps every 4398046511096ns [0.007985] Switching to timer-based delay loop, resolution 20ns [0.014242] Calibrating delay loop (skipped), value calculated using timer frequency.. 96.00 BogoMIPS (lpj=48) [0.024315] pid_max: default: 32768 minimum: 301 [0.029081] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.035524] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.043539] CPU: Testing write buffer coherency: ok Here is a working bootlog, same image but with "nosmp": [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.19.57 (bjonglez@gcc14) (gcc version 7.4.0 (OpenWrt GCC 7.4.0 r10506-a0c97101d6)) #0 SMP Mon Jul 29 08:13:02 2019 [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] OF: fdt: Machine model: Mikrotik RouterBOARD RBD52G-5HacD2HnD (hAP ac²) [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: Data cache writealloc [0.00] OF: reserved mem: OVERLAP DETECTED! [0.00] rsvd2@87B0 (0x87b0--0x8800) overlaps with smem@87e0 (0x87e0--0x87e8) [0.00] random: get_random_bytes called from start_kernel+0x7c/0x438 with crng_init=0 [0.00] percpu: Embedded 15 pages/cpu s29964 r8192 d23284 u61440 [0.00] Built 1 zo
