Re: [LEDE-DEV] pppd does not restart for 3g-wwan

2016-08-28 Thread Reiner Karlsberg

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

2016-08-28 Thread Mathias Kresin

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

2016-08-28 Thread Gareth Parker
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

2016-08-28 Thread Hauke Mehrtens
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

2016-08-28 Thread Hauke Mehrtens
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

2016-08-28 Thread Mathias Kresin

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

2016-08-28 Thread Boris Brezillon
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

2016-08-28 Thread Boris Brezillon
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

2016-08-28 Thread Boris Brezillon
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

2016-08-28 Thread Juan Rios
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

2016-08-28 Thread Daniel Golle
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

2016-08-28 Thread Gareth Parker
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