Re: [LEDE-DEV] pppd does not restart for 3g-wwan
In same context (problem with Huawei modem/pppd) I filed this bug: https://bugs.lede-project.org/index.php?do=details&task_id=115 This bug inhibits setting preferred mode of mobile comms for the Huawei ME909u-521, so factory defaults will be used (auto mode ?). ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] VRV9510KWAC23
Am 27.08.2016 um 19:44 schrieb Juan Rios: Hello, I managed to get this router and want to get lede on it. The hardware is this Lantiq VRX288 500Mhz 2 NANYA NT5TU128M8HE-AC 256MB RAM ZENTEL A501GA31ATS 8G 128MB NAND FLASH. Wireless 2.4Ghz BCM43222KFBG Wireless 5Ghz BCM4360KMLG VDSL/ADSL2+ XWAY VRX208 5 port GB Ethernet I would suggest to check whether the wireless chips are supported by any open source driver and to decide afterwards if it's worth the time to work further on this device. Broadcom and open source (wireless) drivers is usually a story of pain. I already found serial port pins and got the console log. The log is almost silent. I managed to get to the brnboot shell short cutting pins in the flash but cant do a flash dump. Next time please paste the serial logs anyway. Maybe someone else is able to spot something interesting. ERASE Flash --- AreaAddress Length --- [0] Boot0x1024K [1] Image 0 0x0010 10240K [2] Image 1 0x00B0 10240K [3] Configuration 0x01502048K [4] Boot Params 0x01702048K [5] Nvram 0x01901024K [6] Cert0x01A0 32768K [7] EmergencyValue 0x03A06144K [8] Configuration2 0x04002048K [9] All area0x 67584K I wouldn't trust this flash layout. Doesn't look right to me for a 128MB flash chip. If I try to read from above address the router gets locked. I can read from certain area like memory or 0xBC00 or 0xBE00 but others locks the router. You can not access the NAND flash via the system memory addresses. It only works for memory mapped flash like NOR. NAND is I/O mapped. The boot ask for a password and continues booting. The emergency boot kernel is openwrt 10.3 What is a emergency boot kernel? Are you talking about the recovery web interface you get when press and hold the reset button on power on? If they are using OpenWrt, they have to provide the GPL sources. Ask for them! I found out that short cutting R201 I get CFG 07 instead of CFG 06 so maybe UART Mode is R201 + R203 but not sure. Not quite sure to try it... With Lantiq SoCs in NAND boot config it should be enough to bring one of the bootsel pins to GND to force the SoC into UART mode. I can load to memory using xmodem transfer and run but all I tried get locked without any output. What I want is first dump the current content of the flash. Any ideas? You can try to build an ascii (UART) u-boot for this device. But this requires the correct GPIO settings and matching memory parameters for the RAM chip. Usually I'm extracting the RAM chip parameters from the brnboot binary. But this seams to me a "chicken or the egg" problem here. What's more likely to work is to create a second stage (brnboot) u-boot which doesn't have to do the low level chip initialisation and can be started from the brnboot shell [1]. You can use the u-boot for the BT HomeHub 5A [2] as a beginning and add the missing SYS_BOOT_BRN stuff from the VGV7510KW22 [3]. This might allow you to dump the NAND from the second stage u-boot. Mathias [1] https://wiki.openwrt.org/toh/arcadyan/vgv7510kw22#starting_u-boot_from_brnboot [2] https://github.com/danielschwierzeck/u-boot-lantiq/commit/84581834622d6e7e3ceaee08b2ef8bcce3c227f7 [3] https://github.com/danielschwierzeck/u-boot-lantiq/commit/899107f62ad97ba123f74f378179c765f8469e01 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] uap-pro jffs2 error
Just built LEDE from latest source and get a jffs2 error on the Ubiquiti UAP-PRO. The errors continue on down the screen for several pages before the device crashes and reboots again in a loop. Openwrt doesn't have this problem. Gareth [0.00] Linux version 4.4.19 (xxx@xxx) (gcc version 5.4.0 (LEDE GCC 5.4.0 xxx) ) #0 Sun Aug 28 02:04:23 2016 [0.00] bootconsole [early0] enabled [0.00] CPU0 revision is: 0001974c (MIPS 74Kc) [0.00] SoC: Atheros AR9344 rev 3 [0.00] Determined physical RAM map: [0.00] memory: 0800 @ (usable) [0.00] Initrd not found or empty - disabling initrd [0.00] No valid device tree found, continuing without [0.00] Zone ranges: [0.00] Normal [mem 0x-0x07ff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x07ff] [0.00] Initmem setup node 0 [mem 0x-0x07ff] [0.00] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes. [0.00] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 [0.00] Kernel command line: board=UAP-PRO mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,1536k(kernel),14208k(rootfs ),256k(cfg)ro,64k(EEPROM)ro,15744k@0x5(firmware) console=ttyS0,115200 rootfstype=squashfs,jffs2 noinitrd [0.00] PID hash table entries: 512 (order: -1, 2048 bytes) [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Writing ErrCtl register= [0.00] Readback ErrCtl register= [0.00] Memory: 125140K/131072K available (2974K kernel code, 154K rwdata, 748K rodata, 276K init, 200K bss, 5932K reserved, 0K cma-reserved) [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] NR_IRQS:51 [0.00] Clocks: CPU:560.000MHz, DDR:450.000MHz, AHB:225.000MHz, Ref:40.000MHz [0.00] clocksource: MIPS: mask: 0x max_cycles: 0x, max_idle_ns: 6825930166 ns [0.09] sched_clock: 32 bits at 280MHz, resolution 3ns, wraps every 7669584382ns [0.008292] Calibrating delay loop... 278.93 BogoMIPS (lpj=1394688) [0.081138] pid_max: default: 32768 minimum: 301 [0.086170] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.093224] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.103117] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns [0.114303] NET: Registered protocol family 16 [0.120407] MIPS: machine is Ubiquiti UniFi AP Pro [0.128816] registering PCI controller with io_map_base unset [0.354243] PCI host bridge to bus :00 [0.358656] pci_bus :00: root bus resource [mem 0x1000-0x13ff] [0.365972] pci_bus :00: root bus resource [io 0x] [0.371919] pci_bus :00: root bus resource [??? 0x flags 0x0] [0.379144] pci_bus :00: No busn resource found for root bus, will use [bus 00-ff] [0.387662] pci :00:00.0: invalid calibration data [0.393573] pci :00:00.0: BAR 0: assigned [mem 0x1000-0x1001 64bit] [0.401410] pci :00:00.0: BAR 6: assigned [mem 0x1002-0x1002 pref] [0.409107] pci :00:00.0: using irq 40 for pin 1 [0.415233] clocksource: Switched to clocksource MIPS [0.421868] NET: Registered protocol family 2 [0.427353] TCP established hash table entries: 1024 (order: 0, 4096 bytes) [0.434782] TCP bind hash table entries: 1024 (order: 0, 4096 bytes) [0.441590] TCP: Hash tables configured (established 1024 bind 1024) [0.448447] UDP hash table entries: 256 (order: 0, 4096 bytes) [0.454667] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) [0.461622] NET: Registered protocol family 1 [0.470520] futex hash table entries: 256 (order: -1, 3072 bytes) [0.477161] Crashlog allocated RAM at address 0x3f0 [0.496159] squashfs: version 4.0 (2009/01/31) Phillip Lougher [0.502374] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. [0.515344] io scheduler noop registered [0.519526] io scheduler deadline registered (default) [0.525210] Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled [0.532430] console [ttyS0] disabled [0.556327] serial8250.0: ttyS0 at MMIO 0x1802 (irq = 11, base_baud = 250) is a 16550A [0.565519] console [ttyS0] enabled [0.565519] console [ttyS0] enabled [0.572933] bootconsole [early0] disabled [0.572933] bootconsole [early0] disabled [0.584480] m25p80 spi0.0: found mx25l12805d, expected m25p80 [0.590396] m25p80 spi0.0: mx25l12805d (1
Re: [LEDE-DEV] uap-pro jffs2 error
On 08/28/2016 11:51 AM, Gareth Parker wrote: > Just built LEDE from latest source and get a jffs2 error on the Ubiquiti > UAP-PRO. The errors continue on down the screen for several pages before > the device crashes and reboots again in a loop. Openwrt doesn't have this > problem. Hi, What was flash on this device before you flashed LEDE? How did you flash LEDE? Which OpenWrt version worked on this devices and was it an unmodified OpenWrt version? Hauke ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] VRV9510KWAC23
On 08/28/2016 10:31 AM, Mathias Kresin wrote: > Am 27.08.2016 um 19:44 schrieb Juan Rios: >> Hello, >>I managed to get this router and want to get lede on it. The >> hardware is this >> >> Lantiq VRX288 500Mhz >> 2 NANYA NT5TU128M8HE-AC 256MB RAM >> ZENTEL A501GA31ATS 8G 128MB NAND FLASH. >> Wireless 2.4Ghz BCM43222KFBG >> Wireless 5Ghz BCM4360KMLG >> VDSL/ADSL2+ XWAY VRX208 >> 5 port GB Ethernet The SoC including the DSL part is support by LEDE. > I would suggest to check whether the wireless chips are supported by any > open source driver and to decide afterwards if it's worth the time to > work further on this device. Broadcom and open source (wireless) drivers > is usually a story of pain. BCM43222KFBG is supported by b43 with ieee802.11g rates max. BCM4360KMLG is not supported by any driver in LEDE. >> I already found serial port pins and got the console log. The log is >> almost silent. I managed to get to the brnboot shell short cutting >> pins in the flash but cant do a flash dump. > > Next time please paste the serial logs anyway. Maybe someone else is > able to spot something interesting. > >> >> ERASE Flash >> --- >> AreaAddress Length >> --- >> [0] Boot0x1024K >> [1] Image 0 0x0010 10240K >> [2] Image 1 0x00B0 10240K >> [3] Configuration 0x01502048K >> [4] Boot Params 0x01702048K >> [5] Nvram 0x01901024K >> [6] Cert0x01A0 32768K >> [7] EmergencyValue 0x03A06144K >> [8] Configuration2 0x04002048K >> [9] All area0x 67584K > > I wouldn't trust this flash layout. Doesn't look right to me for a 128MB > flash chip. 128MB NAND flash chips are the cheapest NAND chips, using only 64MB is more expensive than using 128MB, 256MB NAND should already have a similar price tag as 128MB. This looks like a dual image configuration with 10MB for each image, there 128MB NAND flash is probably the cheapest solution. >> If I try to read from above address the router gets locked. >> >> I can read from certain area like memory or 0xBC00 or 0xBE00 >> but others locks the router. > > You can not access the NAND flash via the system memory addresses. It > only works for memory mapped flash like NOR. NAND is I/O mapped. > >> The boot ask for a password and continues booting. >> >> The emergency boot kernel is openwrt 10.3 > > What is a emergency boot kernel? Are you talking about the recovery web > interface you get when press and hold the reset button on power on? If > they are using OpenWrt, they have to provide the GPL sources. Ask for them! > >> I found out that short cutting R201 I get CFG 07 instead of CFG 06 so >> maybe UART Mode is R201 + R203 but not sure. Not quite sure to try >> it... > > With Lantiq SoCs in NAND boot config it should be enough to bring one of > the bootsel pins to GND to force the SoC into UART mode. > >> I can load to memory using xmodem transfer and run but all I tried get >> locked without any output. Have you tried the kenrel with both serial interfaces? The SoC supports two and I do not know which on is used on your hardware. @Mathias is it normal that this does not work? >> What I want is first dump the current content of the flash. Any ideas? > > You can try to build an ascii (UART) u-boot for this device. But this > requires the correct GPIO settings and matching memory parameters for > the RAM chip. Usually I'm extracting the RAM chip parameters from the > brnboot binary. But this seams to me a "chicken or the egg" problem here. > > What's more likely to work is to create a second stage (brnboot) u-boot > which doesn't have to do the low level chip initialisation and can be > started from the brnboot shell [1]. You can use the u-boot for the BT > HomeHub 5A [2] as a beginning and add the missing SYS_BOOT_BRN stuff > from the VGV7510KW22 [3]. This might allow you to dump the NAND from the > second stage u-boot. > > Mathias > > > [1] > https://wiki.openwrt.org/toh/arcadyan/vgv7510kw22#starting_u-boot_from_brnboot > > [2] > https://github.com/danielschwierzeck/u-boot-lantiq/commit/84581834622d6e7e3ceaee08b2ef8bcce3c227f7 > > [3] > https://github.com/danielschwierzeck/u-boot-lantiq/commit/899107f62ad97ba123f74f378179c765f8469e01 > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] VRV9510KWAC23
Am 28.08.2016 um 12:15 schrieb Hauke Mehrtens: On 08/28/2016 10:31 AM, Mathias Kresin wrote: Am 27.08.2016 um 19:44 schrieb Juan Rios: I can load to memory using xmodem transfer and run but all I tried get locked without any output. Have you tried the kenrel with both serial interfaces? The SoC supports two and I do not know which on is used on your hardware. @Mathias is it normal that this does not work? Mhh, I've missed that part of Juans mail. It's not clear to me what Juan tried to load and run from ram. Loadx and run the kernel from ram is a brilliant idea. Albeit I've done it dozen times with u-boot, I never considered doing the same with brnboot. I might have some time later the day to give it a try. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 1/3] UBIFS, UBI: move volume string parser from UBIFS to UBI
On Sat, 27 Aug 2016 21:43:53 +0200
Daniel Golle wrote:
No explanation on why you do that. Please make reviewers life easier
and explain what you're trying to achieve.
This patch on its own is not a problem, as long as you have another FS
base on UBI (I'm not talking about ubiblock) that is making use of it
at some point.
But that's not the purpose of this series: you're not adding any FS,
you're just adding ugly hacks in do_mounts.c (patch 3). But I'll
comment directly in there.
> Signed-off-by: Daniel Golle
> ---
> drivers/mtd/ubi/kapi.c | 65
> +
> fs/ubifs/super.c| 64 +---
> include/linux/mtd/ubi.h | 1 +
> 3 files changed, 67 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/mtd/ubi/kapi.c b/drivers/mtd/ubi/kapi.c
> index e844887..3dda9c3 100644
> --- a/drivers/mtd/ubi/kapi.c
> +++ b/drivers/mtd/ubi/kapi.c
> @@ -20,6 +20,7 @@
>
> /* This file mostly implements UBI kernel API functions */
>
> +#include
> #include
> #include
> #include
> @@ -329,6 +330,69 @@ struct ubi_volume_desc *ubi_open_volume_path(const char
> *pathname, int mode)
> EXPORT_SYMBOL_GPL(ubi_open_volume_path);
>
> /**
> + * ubi_open_volume_str - parse UBI device name string and open the UBI
> device.
> + * @name: UBI volume name
> + * @mode: UBI volume open mode
> + *
> + * The primary method of mounting UBIFS is by specifying the UBI volume
> + * character device node path. However, UBIFS may also be mounted withoug any
> + * character device node using one of the following methods:
> + *
> + * o ubiX_Y- mount UBI device number X, volume Y;
> + * o ubiY - mount UBI device number 0, volume Y;
> + * o ubiX:NAME - mount UBI device X, volume with name NAME;
> + * o ubi:NAME - mount UBI device 0, volume with name NAME.
> + *
> + * Alternative '!' separator may be used instead of ':' (because some shells
> + * like busybox may interpret ':' as an NFS host name separator). This
> function
> + * returns UBI volume description object in case of success and a negative
> + * error code in case of failure.
> + */
> +struct ubi_volume_desc *ubi_open_volume_str(const char *name, int mode)
> +{
> + struct ubi_volume_desc *ubi;
> + int dev, vol;
> + char *endptr;
> +
> + /* First, try to open using the device node path method */
> + ubi = ubi_open_volume_path(name, mode);
> + if (!IS_ERR(ubi))
> + return ubi;
> +
> + /* Try the "nodev" method */
> + if (name[0] != 'u' || name[1] != 'b' || name[2] != 'i')
> + return ERR_PTR(-EINVAL);
> +
> + /* ubi:NAME method */
> + if ((name[3] == ':' || name[3] == '!') && name[4] != '\0')
> + return ubi_open_volume_nm(0, name + 4, mode);
> +
> + if (!isdigit(name[3]))
> + return ERR_PTR(-EINVAL);
> +
> + dev = simple_strtoul(name + 3, &endptr, 0);
> +
> + /* ubiY method */
> + if (*endptr == '\0')
> + return ubi_open_volume(0, dev, mode);
> +
> + /* ubiX_Y method */
> + if (*endptr == '_' && isdigit(endptr[1])) {
> + vol = simple_strtoul(endptr + 1, &endptr, 0);
> + if (*endptr != '\0')
> + return ERR_PTR(-EINVAL);
> + return ubi_open_volume(dev, vol, mode);
> + }
> +
> + /* ubiX:NAME method */
> + if ((*endptr == ':' || *endptr == '!') && endptr[1] != '\0')
> + return ubi_open_volume_nm(dev, ++endptr, mode);
> +
> + return ERR_PTR(-EINVAL);
> +}
> +EXPORT_SYMBOL_GPL(ubi_open_volume_str);
> +
> +/**
> * ubi_close_volume - close UBI volume.
> * @desc: volume descriptor
> */
> @@ -365,6 +429,7 @@ void ubi_close_volume(struct ubi_volume_desc *desc)
> }
> EXPORT_SYMBOL_GPL(ubi_close_volume);
>
> +
> /**
> * leb_read_sanity_check - does sanity checks on read requests.
> * @desc: volume descriptor
> diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
> index 1fd90c0..a59fa2f 100644
> --- a/fs/ubifs/super.c
> +++ b/fs/ubifs/super.c
> @@ -1887,68 +1887,6 @@ const struct super_operations ubifs_super_operations =
> {
> .sync_fs = ubifs_sync_fs,
> };
>
> -/**
> - * open_ubi - parse UBI device name string and open the UBI device.
> - * @name: UBI volume name
> - * @mode: UBI volume open mode
> - *
> - * The primary method of mounting UBIFS is by specifying the UBI volume
> - * character device node path. However, UBIFS may also be mounted withoug any
> - * character device node using one of the following methods:
> - *
> - * o ubiX_Y- mount UBI device number X, volume Y;
> - * o ubiY - mount UBI device number 0, volume Y;
> - * o ubiX:NAME - mount UBI device X, volume with name NAME;
> - * o ubi:NAME - mount UBI device 0, volume with name NAME.
> - *
> - * Alternative '!' separator may be used instead of ':' (because some shells
> - * like busybox may interpret ':' as an NFS host name separator). This
> function
> - * returns UBI volume desc
Re: [LEDE-DEV] [PATCH 2/3] mtd: ubiblock: introduce ubiblock_create_dev
On Sat, 27 Aug 2016 21:44:16 +0200
Daniel Golle wrote:
> Define function ubiblock_create_dev(char *name, dev_t *bdev)
> which returns the created device by setting the point bdev.
> This is useful for in-kernel users creating a ubiblock device
> in order to mount the root filesystem.
No specific comment on this one either, since it's only preparing stuff
for the real changes done in patch 3.
>
> Signed-off-by: Daniel Golle
> ---
> drivers/mtd/ubi/block.c | 11 ++-
> drivers/mtd/ubi/ubi.h | 2 ++
> include/linux/mtd/ubi.h | 16
> 3 files changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/ubi/block.c b/drivers/mtd/ubi/block.c
> index ebf46ad..58b818f 100644
> --- a/drivers/mtd/ubi/block.c
> +++ b/drivers/mtd/ubi/block.c
> @@ -49,6 +49,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "ubi-media.h"
> @@ -356,7 +357,11 @@ static struct blk_mq_ops ubiblock_mq_ops = {
>
> static DEFINE_IDR(ubiblock_minor_idr);
>
> -int ubiblock_create(struct ubi_volume_info *vi)
> +int ubiblock_create(struct ubi_volume_info *vi) {
> + return ubiblock_create_dev(vi, NULL);
> +}
> +
> +int ubiblock_create_dev(struct ubi_volume_info *vi, dev_t *bdev)
> {
> struct ubiblock *dev;
> struct gendisk *gd;
> @@ -448,6 +453,10 @@ int ubiblock_create(struct ubi_volume_info *vi)
> add_disk(dev->gd);
> dev_info(disk_to_dev(dev->gd), "created from ubi%d:%d(%s)",
>dev->ubi_num, dev->vol_id, vi->name);
> +
> + if (bdev)
> + *bdev = MKDEV(gd->major, gd->first_minor);
> +
> return 0;
>
> out_free_queue:
> diff --git a/drivers/mtd/ubi/ubi.h b/drivers/mtd/ubi/ubi.h
> index de1ea2e4..7700752 100644
> --- a/drivers/mtd/ubi/ubi.h
> +++ b/drivers/mtd/ubi/ubi.h
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "ubi-media.h"
> @@ -917,6 +918,7 @@ static inline int ubi_update_fastmap(struct ubi_device
> *ubi) { return 0; }
> int ubiblock_init(void);
> void ubiblock_exit(void);
> int ubiblock_create(struct ubi_volume_info *vi);
> +int ubiblock_create_dev(struct ubi_volume_info *vi, dev_t *bdev);
> int ubiblock_remove(struct ubi_volume_info *vi);
> #else
> static inline int ubiblock_init(void) { return 0; }
> diff --git a/include/linux/mtd/ubi.h b/include/linux/mtd/ubi.h
> index 0b92aa5..3d6444f 100644
> --- a/include/linux/mtd/ubi.h
> +++ b/include/linux/mtd/ubi.h
> @@ -21,7 +21,9 @@
> #ifndef __LINUX_UBI_H__
> #define __LINUX_UBI_H__
>
> +#include
> #include
> +#include
> #include
> #include
> #include
> @@ -282,4 +284,18 @@ static inline int ubi_read_sg(struct ubi_volume_desc
> *desc, int lnum,
> {
> return ubi_leb_read_sg(desc, lnum, sgl, offset, len, 0);
> }
> +
> +
> +/*
> + * This function allows in-kernel users to create a ubiblock device and
> + * get to know about the created device.
> + */
> +#ifdef CONFIG_MTD_UBI_BLOCK
> +int ubiblock_create_dev(struct ubi_volume_info *vi, dev_t *bdev);
> +#else
> +int ubiblock_create_dev(struct ubi_volume_info *vi, dev_t *bdev) {
> + return -ENOTSUPP;
> +}
> +#endif
> +
> #endif /* !__LINUX_UBI_H__ */
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 3/3] init: auto-create ubiblock device for non-UBIFS rootfs on UBI
On Sat, 27 Aug 2016 21:44:46 +0200
Daniel Golle wrote:
> Signed-off-by: Daniel Golle
> ---
> init/do_mounts.c | 62
> +---
> 1 file changed, 55 insertions(+), 7 deletions(-)
>
> diff --git a/init/do_mounts.c b/init/do_mounts.c
> index dea5de9..485df12 100644
> --- a/init/do_mounts.c
> +++ b/init/do_mounts.c
> @@ -28,6 +28,7 @@
> #include
> #include
> #include
> +#include
Really??? You include UBI stuff in generic kernel code? Come on. Linux
is defining clear interfaces to be implemented by drivers/FS for a good
reason: the core code should be implementation agnostic, and you're
just breaking this rule.
>
> #include
> #include
> @@ -179,6 +180,47 @@ done:
> }
> #endif
>
> +#if defined(CONFIG_MTD_UBI_BLOCK) && !defined(CONFIG_MTD_UBI_MODULE)
> +#define UBIFS_NODE_MAGIC 0x06101831
> +static inline int ubi_vol_is_ubifs(struct ubi_volume_desc *desc)
> +{
> + int ret;
> + uint32_t magic_of, magic;
> + ret = ubi_read(desc, 0, (char *)&magic_of, 0, 4);
> + if (ret)
> + return 0;
> + magic = le32_to_cpu(magic_of);
> + return magic == UBIFS_NODE_MAGIC;
> +}
This is even worst. Now your parsing data within a specific volume to
determine if the volume is likely to contain a UBIFS FS. And all that
is done in core kernel code.
> +
> +static void ubiblock_create_rootdev(char *name)
> +{
> + int ret, is_ubifs;
> + struct ubi_volume_desc *desc;
> + struct ubi_volume_info vi;
> + dev_t bdev;
> +
> + desc = ubi_open_volume_str(name, UBI_READONLY);
> + if (IS_ERR(desc))
> + return;
> +
> + ubi_get_volume_info(desc, &vi);
> +
> + is_ubifs = ubi_vol_is_ubifs(desc);
> + ubi_close_volume(desc);
> +
> + if (is_ubifs)
> + return;
> +
> + ret = ubiblock_create_dev(&vi, &bdev);
> + if (!ret) {
> + pr_notice("ubiblock%u_%u: '%s' set to be root filesystem\n",
> + vi.ubi_num, vi.vol_id, vi.name);
> + ROOT_DEV = bdev;
> + }
> +}
And it continues here. Now you're automatically creating a ubiblock
device based on the UBIFS detection, and again, this is in core kernel
code.
> +#endif
> +
> /*
> * Convert a name into device number. We accept the following variants:
> *
> @@ -569,14 +611,20 @@ void __init prepare_namespace(void)
>
> if (saved_root_name[0]) {
> root_device_name = saved_root_name;
> - if (!strncmp(root_device_name, "mtd", 3) ||
> - !strncmp(root_device_name, "ubi", 3)) {
> - mount_block_root(root_device_name, root_mountflags);
> - goto out;
> +#if defined(CONFIG_MTD_UBI_BLOCK) && !defined(CONFIG_MTD_UBI_MODULE)
> + if (!strncmp(root_device_name, "ubi", 3))
> + ubiblock_create_rootdev(root_device_name);
> +#endif
> + if (ROOT_DEV == 0) {
> + if (!strncmp(root_device_name, "mtd", 3) ||
> + !strncmp(root_device_name, "ubi", 3)) {
> + mount_block_root(root_device_name,
> root_mountflags);
> + goto out;
> + }
> + ROOT_DEV = name_to_dev_t(root_device_name);
> + if (strncmp(root_device_name, "/dev/", 5) == 0)
> + root_device_name += 5;
> }
> - ROOT_DEV = name_to_dev_t(root_device_name);
> - if (strncmp(root_device_name, "/dev/", 5) == 0)
> - root_device_name += 5;
And the last piece: you're making use of all the hacks you've
introduced earlier to create your blockdevice and pass it to the 'mount
blockdev FS' logic.
I hope you understand why this patch is not acceptable.
> }
>
> if (initrd_load())
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] VRV9510KWAC23
Thanks for your help The oem boot log, oem boot log with uart output enabled in config and the recovery boot is included... I tried several images from ARV7519RW22 because is the previous model but this one is NOR. Also tried with EASY80920NAND and P2812HNUF1 but this ones not tried the initramfs. Now I am compiling the EASY80920NAND to get the initramfs but not sure about what compressions to use. Will try none, gzip and lzma. If there is anything I can try let me know. On Sun, Aug 28, 2016 at 12:24 PM, Mathias Kresin wrote: > Am 28.08.2016 um 12:15 schrieb Hauke Mehrtens: >> >> On 08/28/2016 10:31 AM, Mathias Kresin wrote: >>> >>> Am 27.08.2016 um 19:44 schrieb Juan Rios: I can load to memory using xmodem transfer and run but all I tried get locked without any output. >> >> >> Have you tried the kenrel with both serial interfaces? The SoC supports >> two and I do not know which on is used on your hardware. >> >> @Mathias is it normal that this does not work? > > > Mhh, I've missed that part of Juans mail. It's not clear to me what Juan > tried to load and run from ram. > > Loadx and run the kernel from ram is a brilliant idea. Albeit I've done it > dozen times with u-boot, I never considered doing the same with brnboot. > > I might have some time later the day to give it a try. ROM VER: 1.1.4 CFG 06 NAND NAND Read OK ROM VER: 1.1.4 CFG 06 NAND NAND Read OK DDR PARAM flash addr 170 DDR PARAM: 00142404 00142304 00566504 00566504 0700 Rev 0.3d DDR check ok... start booting... END TUNE DDR Start booting... === Wireless ADSL IAD VR9 Loader v1.00.13 build Apr 25 2014 13:12:00 Arcadyan Technology Corporation === A2x VR9 0xbe22ff1c : e71074ef 0xBf203014 : 7038 EON/Zentel NAND 128MB 3,3V 8-bit found - NAND page size: 2048 NAND oob size : 64 NAND block size : 131072 NAND page/block : 64 NAND block/chip : 1024 NAND chip size: 0x800 NAND page shift : 11 NAND page mask: 0x NAND block shift : 17 - Scan BAD Block ... BAD Block [1023] : 0x07FE data: 0x00 1 Bad Block(s) Copying boot params.DONE Enter command mode ... Get Primary to 1.Image Check from FLASH_AREA_IMAGE_1 : Unzipping firmware at 0x80002000 ... with nAREA[2][ZIP 3] [ZIP 1] done Ready to run firmware Enable UART TX Disable UART TX Enable UART TX Disable UART TX Enable UART TX RFPI before chk 07 07 00 10 10 Disable UART TX Enable UART TX VPE loader: VPE1 running successfully [KERN_ERR]ifx_pcie_wait_phy_link_up timeout ifx_pmu_set: PMU_PWDCR1 = 0x006d module 32 regid 1 regbit 0 ifx_pmu_set: Module PCIE-PHY still is being used 0 times ifx_pmu_set: Actual disabling..2 ifx_pmu_set: Module PCIE-PHY disactivated!!! ifx_pmu_set: PMU_PWDCR1 = 0x006d module 36 regid 1 regbit 4 ifx_pmu_set: Module PDI has been activated 2 times before ifx_pmu_set: PMU_PWDCR1 = 0x006c module 32 regid 1 regbit 0 ifx_pmu_set: Actual enabling.. 1 ifx_pmu_set: Module PCIE-PHY has been activated 1 times before ifx_pmu_set: PMU_PWDCR1 = 0x006c module 33 regid 1 regbit 1 ifx_pmu_set: Module PCIE-CTRL has been activated 2 times before ifx_pmu_set: PMU_PWDCR0 = 0x06110093 module 31 regid 0 regbit 31 ifx_pmu_set: Module PCIE_L0_CLK has been activated 2 times before pciauto_assign_resources : bus 1 Autoconfig PCI channel 0x80D47038 Scanning bus 01, I/O 0x1d80:0x1d90, Mem 0x1c00:0x1d00 (bus:dev:fun)= 01:00.0 Class 0280: VenID 14e4: DevID 4360 (rev 03) ifx_pcie_write_config : bus_number = 0 ifx_pcie_write_config : bus_number = 0 ifx_pcie_write_config : bus_number = 0 Memifx_pcie_write_config : bus_number = 0 ifx_pcie_write_config : bus_number = 0 at 0x1c00 [size=0x8000] ifx_pcie_write_config : bus_number = 0 ifx_pcie_write_config : bus_number = 0 ifx_pcie_write_config : bus_number = 0 ifx_pcie_write_config : bus_number = 0 === Console Debug === (1) Alert Mail Testing (3) Write Web (4) Firmware Upgrage (8) Show B0,B1 Mem pool (9) Toggle AAL5 Frame Dumping (A)ADSL (B)gSetting (c)DHCP Client (d)Dial (e)Ethernet (f)Firewall (F)FTP (g)LED (i)UPnP (l)SSL (n)NetBIOS/Printer (p)PPPoE (q)QoS (r)USB-IF Testing (s)System (t)WSC (u)USB Subsystem (U)UMTS (v)VOIP (w)Wireless (x) Exit (y) Enable SIP Packet Display (Y) Disable SIP Packet Display a(+ 20) / j(+ 10) / b(- 20) Change SIP Bandwidth (20~800) (h) Enable VOIP Bandwidth Management (H) Disable VOIP Bandwidth Management (k) Dump Tel Session Status (K) Dump Voice Session Status (,)DECT (?) Help = [Debug]: after pciauto_assign_resources ??? Scanning bus 00 pc
Re: [LEDE-DEV] [PATCH 3/3] init: auto-create ubiblock device for non-UBIFS rootfs on UBI
Hi Boris,
thanks for the review! This is more helpful and more of the type of
feedback I was hoping for.
On Sun, Aug 28, 2016 at 06:54:15PM +0200, Boris Brezillon wrote:
> On Sat, 27 Aug 2016 21:44:46 +0200
> Daniel Golle wrote:
>
> > Signed-off-by: Daniel Golle
> > ---
> > init/do_mounts.c | 62
> > +---
> > 1 file changed, 55 insertions(+), 7 deletions(-)
> >
> > diff --git a/init/do_mounts.c b/init/do_mounts.c
> > index dea5de9..485df12 100644
> > --- a/init/do_mounts.c
> > +++ b/init/do_mounts.c
> > @@ -28,6 +28,7 @@
> > #include
> > #include
> > #include
> > +#include
>
> Really??? You include UBI stuff in generic kernel code? Come on. Linux
> is defining clear interfaces to be implemented by drivers/FS for a good
> reason: the core code should be implementation agnostic, and you're
> just breaking this rule.
The whole thing could be moved to a new file (similar as done for other
things for specific subsystems, like do_mounts_md.c).
>
> >
> > #include
> > #include
> > @@ -179,6 +180,47 @@ done:
> > }
> > #endif
> >
> > +#if defined(CONFIG_MTD_UBI_BLOCK) && !defined(CONFIG_MTD_UBI_MODULE)
> > +#define UBIFS_NODE_MAGIC 0x06101831
> > +static inline int ubi_vol_is_ubifs(struct ubi_volume_desc *desc)
> > +{
> > + int ret;
> > + uint32_t magic_of, magic;
> > + ret = ubi_read(desc, 0, (char *)&magic_of, 0, 4);
> > + if (ret)
> > + return 0;
> > + magic = le32_to_cpu(magic_of);
> > + return magic == UBIFS_NODE_MAGIC;
> > +}
>
> This is even worst. Now your parsing data within a specific volume to
> determine if the volume is likely to contain a UBIFS FS. And all that
> is done in core kernel code.
I was unsure, however, maybe ubiblock should generally refuse to create
a ubiblock device if an UBIFS signature is found...?
In that case, this function and the logic using it below could be moved
to driver/mtd/ubi/block.c
>
> > +
> > +static void ubiblock_create_rootdev(char *name)
> > +{
> > + int ret, is_ubifs;
> > + struct ubi_volume_desc *desc;
> > + struct ubi_volume_info vi;
> > + dev_t bdev;
> > +
> > + desc = ubi_open_volume_str(name, UBI_READONLY);
> > + if (IS_ERR(desc))
> > + return;
> > +
> > + ubi_get_volume_info(desc, &vi);
> > +
> > + is_ubifs = ubi_vol_is_ubifs(desc);
> > + ubi_close_volume(desc);
> > +
> > + if (is_ubifs)
> > + return;
> > +
> > + ret = ubiblock_create_dev(&vi, &bdev);
> > + if (!ret) {
> > + pr_notice("ubiblock%u_%u: '%s' set to be root filesystem\n",
> > + vi.ubi_num, vi.vol_id, vi.name);
> > + ROOT_DEV = bdev;
> > + }
> > +}
>
> And it continues here. Now you're automatically creating a ubiblock
> device based on the UBIFS detection, and again, this is in core kernel
> code.
This, again, could go into a file of it's own like
init/do_mounts_ubiblock.c
which is just how it's done for ramdisk and mdraid stuff.
>
> > +#endif
> > +
> > /*
> > * Convert a name into device number. We accept the following variants:
> > *
> > @@ -569,14 +611,20 @@ void __init prepare_namespace(void)
> >
> > if (saved_root_name[0]) {
> > root_device_name = saved_root_name;
> > - if (!strncmp(root_device_name, "mtd", 3) ||
> > - !strncmp(root_device_name, "ubi", 3)) {
> > - mount_block_root(root_device_name, root_mountflags);
> > - goto out;
> > +#if defined(CONFIG_MTD_UBI_BLOCK) && !defined(CONFIG_MTD_UBI_MODULE)
> > + if (!strncmp(root_device_name, "ubi", 3))
> > + ubiblock_create_rootdev(root_device_name);
> > +#endif
> > + if (ROOT_DEV == 0) {
> > + if (!strncmp(root_device_name, "mtd", 3) ||
> > + !strncmp(root_device_name, "ubi", 3)) {
> > + mount_block_root(root_device_name,
> > root_mountflags);
> > + goto out;
> > + }
> > + ROOT_DEV = name_to_dev_t(root_device_name);
> > + if (strncmp(root_device_name, "/dev/", 5) == 0)
> > + root_device_name += 5;
> > }
> > - ROOT_DEV = name_to_dev_t(root_device_name);
> > - if (strncmp(root_device_name, "/dev/", 5) == 0)
> > - root_device_name += 5;
>
> And the last piece: you're making use of all the hacks you've
> introduced earlier to create your blockdevice and pass it to the 'mount
> blockdev FS' logic.
This is what is done for all sorts of block devices in that function...
What's wrong with that approach?
>
> I hope you understand why this patch is not acceptable.
I surely do, it was sent in the intention to start a discussion and
collect comments, not with the intention to have it merged at this
stage. I thus really appreciate your detailed review, though I'm aware
that you are opposed to the whole idea of automagica
[LEDE-DEV] [PATCH] add support for the Comfast CF-E380AC
This is a Dual Band PoE AP with gigabit Ethernet, 5ghz is supported with the ath10k driver. Gareth cf-e380ac.patch Description: Binary data ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
