Re: Comfast CF-E110n

2023-10-24 Thread Roger Pueyo Centelles | Guifi.net via openwrt-devel 
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, Bill,

I have a couple of them, but they're in a remote location I can't access 
right now. However, on one of them, I recently upgraded from OpenWrt 
22.03.X to 23.05.0 and I did not experience such issues.


In order to narrow down the issue, you may want to try flashing this 
older OpenWrt version (which one was it? CF-E110N is supported since 
19.07...), then upgrade one major release at a time (first 21.02, then 
22.03, until 23.05). When does this issue appear, if it does?


Best,

Roger

El 23/10/23 a les 23:54, Bill Moffitt ha escrit:

I have been using an older version of OpenWRT on my E110Ns; I loaded up
the latest release to see if it would fix some "LOST BEACON" problems.

Unfortunately, it didn't even boot (went into a bootloop), so I broke
out the serial cable,
busted open the radio, and connected it. Here's what I captured:


U-Boot 1.1.4-ge619c187-dirty (Apr 12 2017 - 18:52:08)

ap143 - Honey Bee 2.0

DRAM:  64 MB
Flash: 16 MB

dup 1 speed 100
Using eth0 device
ping failed; host 192.168.1.10 is not alive
Unknown command 'ERROR!' - try 'help'
Hit any key to stop autoboot:  1 0
## Booting image at 9f02 ...
Image Name:   MIPS OpenWrt Linux-5.15.134
Created:  2023-10-09  21:45:35 UTC
Image Type:   MIPS Linux Kernel Image (lzma compressed)
Data Size:2328775 Bytes =  2.2 MB
Load Address: 8006
Entry Point:  8006
Verifying Checksum at 0x9f020040 ...OK
Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 8006) ...
## Giving linux memsize in bytes, 67108864

Starting kernel ...

[0.00] Linux version 5.15.134 (builder@buildhost)
(mips-openwrt-linux-musl-gcc (OpenWrt GCC 12.3.0 r23497-6637af95aa)
12.3.0, GNU ld (GNU Binutils) 2.40.0) #0 Mon Oct 9 21:45:35 2023
[0.00] printk: bootconsole [early0] enabled
[0.00] CPU0 revision is: 00019374 (MIPS 24Kc)
[0.00] MIPS: machine is COMFAST CF-E110N v2
[0.00] SoC: Qualcomm Atheros QCA9533 ver 2 rev 0
[0.00] Initrd not found or empty - disabling initrd
[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] Zone ranges:
[0.00]   Normal   [mem 0x-0x03ff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x03ff]
[0.00] Initmem setup node 0 [mem 0x-0x03ff]
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 16240
[0.00] Kernel command line: console=ttyS0,115200n8
rootfstype=squashfs,jffs2
[0.00] Dentry cache hash table entries: 8192 (order: 3, 32768
bytes, linear)
[0.00] Inode-cache hash table entries: 4096 (order: 2, 16384
bytes, linear)
[0.00] Writing ErrCtl register=
[0.00] Readback ErrCtl register=
[0.00] mem auto-init: stack:off, heap alloc:off, heap free:off
[0.00] Memory: 55972K/65536K available (6077K kernel code,
591K rwdata, 780K rodata, 1184K init, 217K bss, 9564K 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] CPU clock: 650.000 MHz
[0.00] clocksource: MIPS: mask: 0x max_cycles:
0x, max_idle_ns: 5880801374 ns
[0.02] sched_clock: 32 bits at 325MHz, resolution 3ns, wraps
every 6607641598ns
[0.008370] Calibrating delay loop... 432.53 BogoMIPS (lpj=2162688)
[0.074950] pid_max: default: 32768 minimum: 301
[0.080919] Mount-cache hash table entries: 1024 (order: 0, 4096
bytes, linear)
[0.088644] Mountpoint-cache hash table entries: 1024 (order: 0,
4096 bytes, linear)
[0.105660] clocksource: jiffies: mask: 0x max_cycles:
0x, max_idle_ns: 1911260446275 ns
[0.116125] futex hash table entries: 256 (order: -1, 3072 bytes, linear)
[0.123566] pinctrl core: initialized pinctrl subsystem
[0.131441] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[0.138492] thermal_sys: Registered thermal governor 'step_wise'
[0.153766] clocksource: Switched to clocksource MIPS
[0.167301] NET: Registered PF_INET protocol family
[0.172759] IP idents hash table entries: 2048 (order: 2, 16384
bytes, linear)
[0.181676] tcp_listen_portaddr_hash hash table entries: 512
(order: 0, 4096 bytes, linear)
[0.190630] Table-perturb hash table entries: 65536 (order: 6,
262144 bytes, linear)
[0.198823] TCP established hash table entries: 1024 (order: 0,
4096 bytes, linear)
[0.206939] TCP bind hash table

Re: OpenWrt 19.07.10 service release

2022-04-22 Thread Roger Pueyo Centelles | Guifi.net via openwrt-devel 
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,

Congratulations for this service release! Could it be that the index
page at https://downloads.openwrt.org hadn't been updated to show
19.07.10? The same goes for 21.02.3.

Thanks,

Roger

El 21/4/22 a les 0:21, Hauke Mehrtens ha escrit:
> Hi,
>
> The OpenWrt community is proud to announce the newest service release
> of OpenWrt 19.07. It fixes security issues, improves device support,
> and brings a few bug fixes.
>
> OpenWrt 19.07.10 is the final release of the 19.07 release branch,
> this branch is now end of life and we will not fix problems on this
> branch any more, not even severe security problems. We encourage all
> users still using OpenWrt 19.07 to upgrade to OpenWrt 21.02 or more
> recent OpenWrt versions.
>
> We recently moved our bugs to GitHub, please report issues over there
> (after checking that nobody else posted the same issue before).
> https://github.com/openwrt/openwrt/issues/
>
> Download firmware images via the Firmware Selector or directly from
> our download servers:
>  * https://firmware-selector.openwrt.org
>  * https://downloads.openwrt.org/releases/19.07.10/
>
> The main changes from OpenWrt 19.07.9 are:
>
> Security fixes
> ==
>
>  * wolfssl: Fix multiple security problems
>    (CVE-2022-25638, CVE-2022-25640)
>  * openssl: Fix security problem (CVE-2022-0778)
>  * zlib: Backport security fix for a reproducible crash in compressor
>
> Device support
> ==
>
>  * OCEDO Raccoon: Fix link for long cables with
>  * MikroTik wAP: Fix device detection
>
> Various fixes and improvements
> ==
>
>  * imagebuilder: Fix broken image generation with external targets
>  * imagebuilder: Fix partition signature
>  * patchelf: Backport fix for rpath endianness
>  * base-files: Call “sync” after initial setup
>  * ubus: backport Fixes for UAF and other issues
>
> Core components
> ===
>
>  * Update Linux kernel from 4.14.167 to 4.14.275
>  * Update mac80211 from 4.19.221-1 to 4.19.237-1
>  * Update openssl from 1.1.1m to 1.1.1n
>  * Update wolfssl from 4.7.0 to 5.2.0
>
> Regressions
> ===
>
>  * at91 images are not created any more because the build needs Python.h
>    which is not installed on the build bots.
>    * To fix this issue export the missing environmental variable before
>  using the ImageBuilder: export SOURCE_DATE_EPOCH=1
>  * oxnas/ox820 images are not created any more because of a
>    build problem
>
> Full release notes and upgrade instructions are available at
> https://openwrt.org/releases/19.07/notes-19.07.10
>
> In particular, make sure to read the regressions and known issues before
> upgrading:
> https://openwrt.org/releases/19.07/notes-19.07.10#regressions
>
> For a very detailed list of all changes since 19.07.9, refer to
> https://openwrt.org/releases/19.07/changelog-19.07.10
>
> For latest information about the 19.07 series, refer to the wiki at:
> https://openwrt.org/releases/19.07/
>
> To download a OpenWrt 19.07.10 firmware image for your device, head to
> the Table of Hardware:
> https://openwrt.org/toh/start
>
> Or use the new firmware selector:
> https://firmware-selector.openwrt.org/
>
> You can also navigate directly in the list of firmware images:
> https://downloads.openwrt.org/releases/19.07.10/targets/
>
> As always, a big thank you goes to all our active package maintainers,
> testers, documenters, and supporters.
>
> Have fun!
>
> The OpenWrt Community
>
> ---
>
> To stay informed of new OpenWrt releases and security advisories, there
> are new channels available:
>
>  * a low-volume mailing list for important announcements:
> https://lists.openwrt.org/mailman/listinfo/openwrt-announce
>
>  * a dedicated "announcements" section in the forum:
> https://forum.openwrt.org/c/announcements/14
>
>  * other announcement channels (such as RSS feeds) might be added in the
>    future, they will be listed at https://openwrt.org/contact
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 1/3] generic: platform/mikrotik: make soft_config writable without 4K sectors

2022-01-11 Thread Roger Pueyo Centelles | Guifi.net via openwrt-devel 
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, Oskari,

I could successfully test your patch on a
mikrotik,routerboard-wap-g-5hact2hnd.

Previously:

root@OpenWrt:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 0002 0001 "RouterBoot"
mtd1: e000 0001 "bootloader1"
mtd2: 1000 0001 "hard_config"
mtd3: 1000 0001 "bios"
mtd4: f000 0001 "bootloader2"
mtd5: 1000 0001 "soft_config"
[...]

Your patch:

root@OpenWrt:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 0002 0001 "RouterBoot"
mtd1: e000 0001 "bootloader1"
mtd2: 1000 0001 "hard_config"
mtd3: 1000 0001 "bios"
mtd4: f000 0001 "bootloader2"
mtd5: 1000 1000 "soft_config"
[...]

Then, under /sys/firmware/mikrotik/soft_config, I could configure
cpufreq_index to run at 720, 600 or 500 MHz.

Thanks for your patch!

Roger

El 9/1/22 a les 14:57, Sven Roederer ha escrit:
> Am Dienstag, 21. Dezember 2021, 08:45:59 CET schrieb Oskari Lemmela:
>> Make soft_config writable in all cases. Performing soft_config commit
>> will fail if mtd partition is not writable.
>>
>> Signed-off-by: Oskari Lemmela 
>> ---
>>  .../drivers/platform/mikrotik/rb_softconfig.c   | 17 +++--
>>  1 file changed, 3 insertions(+), 14 deletions(-)
>>
>> diff --git
>> a/target/linux/generic/files/drivers/platform/mikrotik/rb_softconfig.c
>> b/target/linux/generic/files/drivers/platform/mikrotik/rb_softconfig.c
>> index 070bd32d5a..31d06c423a 100644
>> --- a/target/linux/generic/files/drivers/platform/mikrotik/rb_softconfig.c
>> +++ b/target/linux/generic/files/drivers/platform/mikrotik/rb_softconfig.c
>> @@ -59,20 +59,9 @@
>>  #define RB_SOFTCONFIG_VER  "0.03"
>>  #define RB_SC_PR_PFX   "[rb_softconfig] "
> Oskari,
>
> maybe also good to bump version to 0.04 .
>
> Sven
>
>
>
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] newer mikrotik boards not booting?

2020-06-14 Thread Roger Pueyo Centelles | Guifi.net via openwrt-devel 
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 Joe,

El 13/6/20 a les 21:00, Joe Ayers ha escrit:
> Anyone else seeing this on recently purchased  Mikrotik models?
> Installing openwrt 19.07.03 on a Mikrotik LHG 5 boots, initfs and
> appears to succeed with sysupgrade.  Then the device is in an infinite
> boot loop.   It appears there's no console configured in routerboot to
> see what it is doing.  Any pointers to turn on?
Is it the same with 19.07.2 or 19.07.1? Just to make sure it's not a
regression in OpenWrt.
> Note, I'm working with another individual seeing this on a new LHG 5
> model device.  I have reproduced and tested on a newly purchased SXTsq
> 5HPnD, which has a motherboard labeled "LHG 5HPnD".   Prior SXTsq
> 5HPnD  and LHG 5HPnD models  have been working fine.

When you boot via TFTP, can you check whether the dmesg lines "Kernel
command line" are the same on older and newer devices?

> sysupgrade log:
>
> Commencing upgrade. Closing all shell sessions.
> Watchdog handover: fd=3
> - watchdog -
> Sending TERM to remaining processes ... crond uhttpd xinetd sh dnsmasq
> sh ntpd netifd hostapd [  146.589174] device wlan0 left promiscuouse
> [  146.593957] br-lan: port 2(wlan0) entered disabled state
> sleep sleep ubusd urngd logd rpcd
> Sending KILL to remaining processes ...
> /lib/upgrade/stage2: line 126: [-x: not found

This last line does not look good, but I can't locate it in the source
code :(

Cheers!

> Performing system upgrade...
> Unlocking firmware ...
>
> Writing from  to firmware ...
> Upgrade completed
> Rebooting system...
> umount: can't unmount /dev: Resource busy
> umount: can't unmount /tmp: Resource busy
> umount: can't unmount /: Invalid argument
> [  185.682795] Removing MTD device #1 (hard_config) with use count 1
> [  185.690133] reboot: Restarting system
>
> regards,
> Joe AE6XE
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Multicast issue in 19.07.x release and master, fix it in 19.07.3 (?)

2020-05-05 Thread Roger Pueyo Centelles | Guifi.net via openwrt-devel 
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,

Thanks Chuanghong, I was unaware of it.

I could verify the commit to work in master and 19.07, for both ath79
and ar71xx.

Best,

Roger

El 5/5/20 a les 13:16, pedrowrt ha escrit:
> We discussed a bit in IRC, Chuanhong coded a new patch and suggested me
> to try it
>
> https://git.openwrt.org/?p=openwrt/staging/981213.git;a=commit;h=b34165fd386158cbb4d8c09e2c5127b3dee3219a


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Multicast issue in 19.07.x release and master, fix it in 19.07.3 (?)

2020-05-05 Thread Roger Pueyo Centelles | Guifi.net via openwrt-devel 
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,

You're right, it's a bug and not a patch which we've been able to
identify it's caused by commit
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c8c2ef1d495dd3fd3096ac508e91a02f9c583ea8


As you can see, it's just a two-lines commit that resets the AR8216
switch during initialization, but it's part of a longer series of
AR8216-related commits. Reverting it makes IPv6 multicast work again on
the NanoStation XW, and probably others, but it could also break other
devices' switched networking (e.g., those QCA9558+AR8326 ones).

I understand it can't go wildly into 19.07.3 but, now that we're
discussing it, maybe the author of the patch can shed some light on the
issue.

Best,

Roger

El 5/5/20 a les 11:44, m...@adrianschmutzler.de ha escrit:
> Hi,
>
>> -Original Message-
>> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
>> On Behalf Of pedrowrt
>> Sent: Dienstag, 5. Mai 2020 10:36
>> To: openwrt-devel@lists.openwrt.org
>> Cc: yn...@true.cz
>> Subject: [OpenWrt-Devel] Multicast issue in 19.07.x release and master, fix 
>> it
>> in 19.07.3 (?)
>>
>> ff02::2 multicast is not working in nanostation xw, but roger pueyo find a 
>> way
>> to solve it: revert commit
>> c8c2ef1d495dd3fd3096ac508e91a02f9c583ea8 (which is very short)
>>
>> I don't know the implications of doing it. But it fixes a bug that affects 
>> us a lot
>> (we have lots of these devices and they do routing through cable)
>>
>> https://bugs.openwrt.org/index.php?do=details_id=2848
> if I checked correctly, this is not applied to master or even proposed as 
> patch?
>
> Then, you might be too late for this stable release. Normally, stuff should 
> stay in master for a few days before being backported.
>
> Best
>
> Adrian
>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ar71xx: add support for RB SXTsq 2nD

2020-03-15 Thread Roger Pueyo Centelles | Guifi.net via openwrt-devel 
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,

> I believe this is a waste of resources and a very suboptimal approach.
> I’m not sure I’m interested in spending time on this :P
Probably it is. How would you approach it? Some devices that are the
same hardware with just a different name are already supported like
this:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=ac36cca012dd1bbeea0fc4c2dc7a00941de34b52
>
> Some devices share the exact same hardware and differ only in
> (marketing) name, as evidenced by:
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=5ac974f2145c770431a6eb7e006dd086b70224b1
>
> (this device uses the 911L platform)
>
>> Just have a look at how the few ath79 devices are implemented, but
>> note that they will be moved to a mikrotik subtarget soon as
>> indicated by Roger already.
>
> I’ve offered in this thread a couple patches to align the ath79
> implementation on the existing ramips one wrt mtd partitioning and naming.

To me they're OK, I have no preference for having the partitions nested
or not. What are the benefits and drawbacks?

Cheers!

>
> Best,
> Thibaut
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ar71xx: add support for RB SXTsq 2nD

2020-03-15 Thread Roger Pueyo Centelles | Guifi.net via openwrt-devel 
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 Thibaut,

We're actually working on the ath79/mikrotik subtarget, to deal with the
particularities of MikroTik devices and migrate the two currently
supported. You may want to base your commit on the code at
https://github.com/openwrt/openwrt/pull/2811 .

Regards,

Roger

El 15/3/20 a les 13:05, m...@adrianschmutzler.de ha escrit:
> Hi,
>
>> -Original Message-
>> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
>> On Behalf Of Thibaut VARÈNE
>> Sent: Sonntag, 15. März 2020 11:35
>> To: openwrt-devel@lists.openwrt.org
>> Cc: Thibaut VARÈNE 
>> Subject: [OpenWrt-Devel] [PATCH v2] ar71xx: add support for RB SXTsq 2nD
> the ar71xx target will only be supported in already released 19.07 branch and 
> be removed afterwards.
>
> Consequently, we do not accept any device support for this target anymore.
>
> Please work with the ath79 target instead, which is meant to replace ar71xx 
> and is also already included in 19.07.x (though Mikrotik devices have only 
> been added in master).
>
> Best
>
> Adrian 
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] ramips: fix and tidy up DTS for D-Link DIR-810L

2020-03-03 Thread Roger Pueyo Centelles | Guifi.net via openwrt-devel 
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,

El 3/3/20 a les 19:14, Adrian Schmutzler ha escrit:
> Why 33 MHz and not 50 MHz, where the duration drops again? I do not get you 
> argumentation here ...

I checked again, 50 MHz corresponds to 2READ (2 I/O), not to FAST_READ.
So, yes, 50 MHz should be the maximum, not 33 MHz.

Roger

>
> Best
>
> Adrian
>


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] ramips: fix and tidy up DTS for D-Link DIR-810L

2020-03-03 Thread Roger Pueyo Centelles | Guifi.net via openwrt-devel 
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 ---
Ah, sorry, I also tested the spi-max-frequency.

The device reports a mx25l6405d flash chip. I tried all the maximum
values in the devices' datasheet (Table 10. AC CHARACTERISTICS). All of
them worked with and without "m25p,fast-read":

# 10 MHz
root@OpenWrt:~# time cat /dev/mtd* > /dev/null
real    1m 33.00s
user    0m 0.01s
sys    1m 7.56s

# 25 MHz
root@OpenWrt:~# time cat /dev/mtd* > /dev/null
real    0m 34.42s
user    0m 0.02s
sys    0m 23.58s

# 25 MHz, fast read
root@OpenWrt:~# time cat /dev/mtd* > /dev/null
real    0m 34.45s
user    0m 0.02s
sys    0m 23.59s

# 33 MHz
root@OpenWrt:~# time cat /dev/mtd* > /dev/null
real    0m 34.39s
user    0m 0.00s
sys    0m 23.60s

# 33 MHz, fast read
root@OpenWrt:~# time cat /dev/mtd* > /dev/null
real    0m 34.46s
user    0m 0.01s
sys    0m 23.62s

# 50 MHz
root@OpenWrt:~# time cat /dev/mtd* > /dev/null
real    0m 26.81s
user    0m 0.01s
sys    0m 18.25s

# 50 MHz, fast read
root@OpenWrt:~# time cat /dev/mtd* > /dev/null
real    0m 26.84s
user    0m 0.00s
sys    0m 18.25s

# 66 MHz
root@OpenWrt:~# time cat /dev/mtd* > /dev/null
real    0m 26.80s
user    0m 0.01s
sys    0m 18.23s

# 66 MHz, fast read
root@OpenWrt:~# time cat /dev/mtd* > /dev/null
real    0m 26.80s
user    0m 0.02s
sys    0m 18.23s

# 86 MHz
root@OpenWrt:~# time cat /dev/mtd* > /dev/null
real    0m 26.84s
user    0m 0.01s
sys    0m 18.24s

# 86 MHz, fast read
root@OpenWrt:~# time cat /dev/mtd* > /dev/null
real    0m 26.80s
user    0m 0.02s
sys    0m 18.23s

It seems that fast read has no effect --or is always enabled, regardless
of the DTS--. I also went for 100 MHz and the device failed to boot
(both with and without fast read).

You can safely use 33 MHz. I don't know, however, it 50 MHz + fast read
is actually working or something else is hindering the max. frequency
from being achieved.

Roger

El 28/2/20 a les 13:33, Roger Pueyo Centelles | Guifi.net ha escrit:
> Hi Adrian,
>
> I tested the patches on the device. I sysupgraded from the current
> master and everything seems OK.
>
> - Partitions
>
> root@OpenWrt:~# cat /proc/mtd
> dev:    size   erasesize  name
> mtd0: 0003 1000 "u-boot"
> mtd1: 0001 1000 "u-boot-env"
> mtd2: 0001 1000 "factory"
> mtd3: 0001 1000 "factory5g"
> mtd4: 0001 1000 "Wolf_Config"
> mtd5: 0008 1000 "MyDlink"
> mtd6: 0008 1000 "Jffs2"
> mtd7: 0069 1000 "firmware"
> mtd8: 00198a90 1000 "kernel"
> mtd9: 004f7570 1000 "rootfs"
> mtd10: 001d4000 1000 "rootfs_data"
>
> - Button codes OK both
>
> - No missing functionalities
>
> I noticed, however, that the green "Internet" LED blinks to the LAN4
> port, while -I guess- it should blink to the INTERNET (wan/eth0.2) port.
> But this was already happening before, it's not related to your patch.
>
> Roger
>
> El 27/2/20 a les 14:46, Adrian Schmutzler ha escrit:
>> This patch addresses several issues for D-Link DIR-810L:
>>
>> - add correct button codes
>> - harmonize button node names
>> - use generic flash@0
>> - remove unused pin groups from state_default
>> - improve sorting of properties
>>
>> The patch is only build-tested.
>>
>> Signed-off-by: Adrian Schmutzler 
>>
>> ---
>>
>> If somebody owns this device, I'd be delighted about a test of both patches
>> in general as well as if somebody would test if higher SPI frequency is
>> possible.
>>
>> ---
>>  .../ramips/dts/mt7620a_dlink_dir-810l.dts  | 18 ++
>>  1 file changed, 10 insertions(+), 8 deletions(-)
>>
>> diff --git a/target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts 
>> b/target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts
>> index 0b1ca26ba4..514e9cc354 100644
>> --- a/target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts
>> +++ b/target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts
>> @@ -23,20 +23,20 @@
>>  reset {
>>  label = "reset";
>>  gpios = < 1 GPIO_ACTIVE_LOW>;
>> -linux,code = ;
>> +linux,code = ;
>>  };
>>  
>>  wps {
>>  label = "wps";
>>  gpios = < 2 GPIO_ACTIVE_LOW>;
>> -linux,code = ;
>> +

Re: [OpenWrt-Devel] [PATCH 2/2] ramips: fix and tidy up DTS for D-Link DIR-810L

2020-02-28 Thread Roger Pueyo Centelles | Guifi.net via openwrt-devel 
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 Adrian,

I tested the patches on the device. I sysupgraded from the current
master and everything seems OK.

- Partitions

root@OpenWrt:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 0003 1000 "u-boot"
mtd1: 0001 1000 "u-boot-env"
mtd2: 0001 1000 "factory"
mtd3: 0001 1000 "factory5g"
mtd4: 0001 1000 "Wolf_Config"
mtd5: 0008 1000 "MyDlink"
mtd6: 0008 1000 "Jffs2"
mtd7: 0069 1000 "firmware"
mtd8: 00198a90 1000 "kernel"
mtd9: 004f7570 1000 "rootfs"
mtd10: 001d4000 1000 "rootfs_data"

- Button codes OK both

- No missing functionalities

I noticed, however, that the green "Internet" LED blinks to the LAN4
port, while -I guess- it should blink to the INTERNET (wan/eth0.2) port.
But this was already happening before, it's not related to your patch.

Roger

El 27/2/20 a les 14:46, Adrian Schmutzler ha escrit:
> This patch addresses several issues for D-Link DIR-810L:
>
> - add correct button codes
> - harmonize button node names
> - use generic flash@0
> - remove unused pin groups from state_default
> - improve sorting of properties
>
> The patch is only build-tested.
>
> Signed-off-by: Adrian Schmutzler 
>
> ---
>
> If somebody owns this device, I'd be delighted about a test of both patches
> in general as well as if somebody would test if higher SPI frequency is
> possible.
>
> ---
>  .../ramips/dts/mt7620a_dlink_dir-810l.dts  | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts 
> b/target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts
> index 0b1ca26ba4..514e9cc354 100644
> --- a/target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts
> +++ b/target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts
> @@ -23,20 +23,20 @@
>   reset {
>   label = "reset";
>   gpios = < 1 GPIO_ACTIVE_LOW>;
> - linux,code = ;
> + linux,code = ;
>   };
>  
>   wps {
>   label = "wps";
>   gpios = < 2 GPIO_ACTIVE_LOW>;
> - linux,code = ;
> + linux,code = ;
>   };
>   };
>  
>   leds {
>   compatible = "gpio-leds";
>  
> - led_power_green: power {
> + led_power_green: power_green {
>   label = "dir-810l:green:power";
>   gpios = < 9 GPIO_ACTIVE_HIGH>;
>   };
> @@ -46,7 +46,7 @@
>   gpios = < 12 GPIO_ACTIVE_HIGH>;
>   };
>  
> - power2 {
> + power_orange {
>   label = "dir-810l:orange:power";
>   gpios = < 13 GPIO_ACTIVE_HIGH>;
>   };
> @@ -56,7 +56,7 @@
>   {
>   status = "okay";
>  
> - m25p80@0 {
> + flash@0 {
>   compatible = "jedec,spi-nor";
>   reg = <0>;
>   spi-max-frequency = <1000>;
> @@ -119,7 +119,7 @@
>  
>  _default {
>   gpio {
> - ralink,group = "mdio", "rgmii1", "i2c", "wled", "uartf";
> + ralink,group = "i2c", "uartf";
>   ralink,function = "gpio";
>   };
>  };
> @@ -130,9 +130,10 @@
>  };
>  
>   {
> - mediatek,port4 = "ephy";
>   pinctrl-names = "default";
>   pinctrl-0 = <_pins>;
> +
> + mediatek,port4 = "ephy";
>  };
>  
>   {
> @@ -140,9 +141,10 @@
>  };
>  
>   {
> - ralink,mtd-eeprom = < 0x0>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_pins>;
> +
> + ralink,mtd-eeprom = < 0x0>;
>   mtd-mac-address = < 0x28>;
>  };
>  


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] 4k sectors in ath79's SPI NOR for MikroTik devices

2020-02-27 Thread Roger Pueyo Centelles | Guifi.net via openwrt-devel 
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,

Recently, a couple of MikroTik devices have been ported from the ar71xx
target to the ath79 one (the ath79/generic RB wAP G-5HacT2HnD (wAP AC)

[1] and the ath79/nand RB 922UAGS-5HPacD

[2]).

Only after the commits were merged upstream I realised that, since some
of the partitions on the SPI NOR storage are sized 4 kB, the
CONFIG_MTD_SPI_NOR_USE_4K_SECTORS kernel configuration item is needed.
Otherwise, the soft_config partition (it contains the bootloader's
settings) can't be modified or, in the worse case, other partitions are
accidentally erased when modifying it (you can see the discussion at
GitHub's pull request #2791
 [3]).

CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not enabled by default on
ath79/generic or ath79/nand, but used to be in ar71xx/mikrotik and is
also in ath79/tiny

[4] (there was discussion on the mailing list

also [5]).

In order to allow these MikroTik devices correctly write to the
partitions (reading works OK right now), as far as I know, there would
be three options:

1- Adding the CONFIG_MTD_SPI_NOR_USE_4K_SECTORS to ath79/generic and
ath79/nand (i.e., to the whole ath79 target)
 · PROS: it works
 · CONS: probably breaks sysupgrade for other devices (?)

2- Forcing conflicting small partitions as read-only
 · PROS: nothing can be broken
 · CONS: bootloader settings won't be modifiable (e.g., with rbcfg
 [6])

3- Creating a new ath79/mikrotik subtarget
 · PROS: it works, and all MikroTik-specific features and tweaks are
concentrated there, no technical problems or missing features should arise
 · CONS: mostly looks like a manufacturer-specific subtarget...


Therefore, I would like to ask for your advice, so we can together
decide on how to proceed:

Q1- Does adding CONFIG_MTD_SPI_NOR_USE_4K_SECTORS now to ath79/generic
and ath79/nand break sysupgrade?

Q2- Which option among the three ones, or any other, is the best?


Thanks,

Roger

--

[1]
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=6aaa5ce2c5138877e0f0504c3bd536b40e9af928

[2]
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=8f93c05a591bd68e4d8eaa0a8468ce2263762004

[3] https://github.com/openwrt/openwrt/pull/2791

[4]
http://lists.infradead.org/pipermail/openwrt-devel/2019-November/020358.html

[5]
http://lists.infradead.org/pipermail/openwrt-devel/2019-December/020864.html

[6] https://openwrt.org/packages/pkgdata/rbcfg



signature.asc
Description: OpenPGP digital signature
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Mikrotik ar71xx -> ath79 port

2020-02-19 Thread Roger Pueyo Centelles | Guifi.net via openwrt-devel 
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 Christopher,

Congratulations on your progress! :)

Besides the RB922, I've got a couple more MikroTik devices in the
process of being supported: RouterBOARD 750GL
 [1]
and OmniTIK UPA-H5nD

[2]. They're not ready yet (I can't make the NAND memory work) but you
may want to take a look at them for inspiration.

Cheers!

Roger

[1] https://github.com/rogerpueyo/openwrt/tree/ath79-mikrotik-rb-750gl

[2]
https://github.com/rogerpueyo/openwrt/tree/ath79-mikrotik-routerboard-omnitik-upa-5hnd

El 19/2/20 a les 4:41, Christopher Hill ha escrit:
> On 2/17/20 2:30 PM, Adrian Schmutzler wrote:
>>> -Original Message-
>>> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
>>> Behalf Of Christopher Hill
>>> Sent: Montag, 17. Februar 2020 16:03
>>> To: openwrt-devel@lists.openwrt.org
>>> Subject: [OpenWrt-Devel] Mikrotik ar71xx -> ath79 port
>>>
>>> Hi,
>>>
>>> New here, and am looking for some advice on porting an existing device
>>> to ath79 - specifically a Mikrotik RB493G (which is NAND).
>>>
>>> The area I'm looking for guidance / tips on is getting the lzma-loader
>>> to boot the new kernel. I have compiled a new image* and I can tftp boot
>>> this and see on the serial console the lzma-loader running and
>>> decompressing the kernel and then starting it... but then nothing
>>> happens next.
>> Have a look at the annotations I put into your repo. It looks like you have 
>> mistaken size for partition endings in the DTS.
>> I remember @rogerpueyo also had problems booting his device due to a wrong 
>> partition setup. Maybe fixing the partitions will be enough ...
>>
>> Best
>>
>> Adrian
>>
> Thanks for pointing out the address vs. size confusion I had run into. I
> fixed them up and re-built, but still nothing.
>
> However after fiddling with the build options and turning on lzma
> compression for the "ramdisk", output has now started to appear on the
> serial console.
>
> I wonder if this is something I should/could set in the Makefile?
>
>
> [0.00] Linux version 4.19.101 (open...@home.lan) (gcc version
> 8.3.0 (OpenWrt GCC 8.3.0 r12212-39a49c2d6a)) #0 Wed Feb 19 02:56:24 2020
> [0.00] bootconsole [early0] enabled
> [0.00] CPU0 revision is: 00019374 (MIPS 24Kc)
> [0.00] MIPS: machine is MikroTik RouterBOARD RB493G
> [0.00] SoC: Atheros AR7161 rev 2
> [0.00] Determined physical RAM map:
> [0.00]  memory: 1000 @  (usable)
> [0.00] Initrd not found or empty - disabling initrd
>
> 
>
> [3.748527] Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled
> [3.755514] console [ttyS0] disabled
> [3.759186] 1802.uart: ttyS0 at MMIO 0x1802 (irq = 10,
> base_baud = 10625000) is a 16550A
> [3.767997] console [ttyS0] enabled
> [3.767997] console [ttyS0] enabled
> [3.774948] bootconsole [early0] disabled
> [3.774948] bootconsole [early0] disabled
> [3.789083] m25p80 spi0.0: unrecognized JEDEC id bytes: 00, 00, 00
> [3.795286] m25p80: probe of spi0.0 failed with error -2
>
>
> Then it halts. However this is good progress!
>
>
> Regards,
> Chris
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ath79: NAND bad eraseblocks in MikroTik RouterBOARD 922UAGS-5HPacD

2020-01-30 Thread Roger Pueyo Centelles | Guifi.net via openwrt-devel 
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 Michal,

El 29/1/20 a les 20:07, Michal Cieslakiewicz ha escrit:
> Please try adding 'qca,nand-swap-dma;' to '' section in
> router dts file. This in theory should fix endianness problem.
Yes, that worked! I also had to set nand-ecc-mode = "soft";, as two-byte
blocks were still swapped.
> By looking at C file, I have also found that this router uses
> model-specific ath79_nfc_set_scan_fixup() routine - a functionality
> that is not implemented in ath79, because there was no need for such
> quirks, at least not until now.

Could this be related to the fact that the detected chip has 128 MiB,
but it is only usable up to 64 MiB?

[    0.774760] nand: Samsung NAND 128MiB 3,3V 8-bit
[    0.779480] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048,
OOB size: 64
[    0.787178] Scanning device for bad blocks
[    0.797061] random: fast init done
[    0.927117] 3 fixed-partitions partitions found on MTD device ar934x-nand
[    0.934024] Creating 3 MTD partitions on "ar934x-nand":
[    0.939338] 0x-0x0004 : "booter"
[    0.945095] 0x0004-0x0040 : "kernel"
[    0.950898] 0x0400-0x0bc0 : "ubi"
[    0.955673] mtd: partition "ubi" extends beyond the end of device
"ar934x-nand" -- size truncated to 0x400

Kind regards,

Roger



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ath79: NAND bad eraseblocks in MikroTik RouterBOARD 922UAGS-5HPacD

2020-01-29 Thread Roger Pueyo Centelles | Guifi.net via openwrt-devel 
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 all,

It seems like the NAND flash is read with different endiannesses:

root@ar71xx# hexdump /dev/mtd4 | head -n 2

000 3530 3935 f451 53ce  64a6 2e36 3234
010 312e 0032      

root@ath79# hexdump /dev/mtd4 | head -n 2

000 3539 3035 ce53 51f4 a664  3432 362e
010 3200 2e31      

I wonder, though, which is the "correct" one --or how to change ath79's,
so that it is coherent with the previous target--.

Roger

El 27/1/20 a les 18:17, Roger Pueyo Centelles | Guifi.net ha escrit:
> Hi Koen,
>
> Please find the bootlogs at:
>
> https://pastebin.com/PD5Lfx3p (ath79)
>
> https://pastebin.com/j1jBauQE (ar71xx)
>
> Cheers!
>
> El 27/1/20 a les 17:31, Koen Vandeputte ha escrit:
>> Hi Roger,
>>
>> Can you send me full bootlogs please from both?
>>
>> I have RB922-5HPnD, not the AC version over here, but I guess the
>> issue will also be present over there.
>>
>> Thanks again,
>>
>> Koen
>>
>> On 27.01.20 15:16, Roger Pueyo Centelles | Guifi.net via openwrt-devel
>> wrote:
>>> 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.
>>>
>>> ___
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>


0x5AF48A37E35766B1.asc
Description: application/pgp-keys
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ath79: NAND bad eraseblocks in MikroTik RouterBOARD 922UAGS-5HPacD

2020-01-27 Thread Roger Pueyo Centelles | Guifi.net via openwrt-devel 
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 Koen,

Please find the bootlogs at:

https://pastebin.com/PD5Lfx3p (ath79)

https://pastebin.com/j1jBauQE (ar71xx)

Cheers!

El 27/1/20 a les 17:31, Koen Vandeputte ha escrit:
> Hi Roger,
>
> Can you send me full bootlogs please from both?
>
> I have RB922-5HPnD, not the AC version over here, but I guess the
> issue will also be present over there.
>
> Thanks again,
>
> Koen
>
> On 27.01.20 15:16, Roger Pueyo Centelles | Guifi.net via openwrt-devel
> wrote:
>> 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.
>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] ath79: NAND bad eraseblocks in MikroTik RouterBOARD 922UAGS-5HPacD

2020-01-27 Thread Roger Pueyo Centelles | Guifi.net via openwrt-devel 
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,

I'm working on porting a second MikroTik device, the RouterBOARD
922UAGS-5HPacD, from ar71xx to ath79 and I'm having trouble with the
NAND storage. The chip is detected, but bad eraseblocks are reported
when booting an initramfs image via TFTP (haven't tried sysupgrade yet):

[    0.791848] Creating 4 MTD partitions on "spi0.0":
[    0.796717] 0x-0xc000 : "routerboot"
[    0.802857] 0xc000-0xd000 : "art"
[    0.808379] 0xd000-0xe000 : "bios"
[    0.813924] 0xe000-0xf000 : "soft_config"
[    0.823549] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xf1
[    0.830034] nand: Samsung NAND 128MiB 3,3V 8-bit
[    0.834717] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048,
OOB size: 64
[    0.842435] Scanning device for bad blocks
[    0.846909] Bad eraseblock 2 at 0x0004
[    0.851500] Bad eraseblock 3 at 0x0006
    [...] eraseblocks continue on all blocks, from 4 to 15
[    0.911492] Bad eraseblock 16 at 0x0020
[    1.036624] 3 fixed-partitions partitions found on MTD device ar934x-nand
[    1.043531] Creating 3 MTD partitions on "ar934x-nand":
[    1.048844] 0x-0x0004 : "booter"
[    1.054605] 0x0004-0x0040 : "kernel"
[    1.060369] 0x0040-0x0080 : "ubi"
[    1.477206] UBI error: unable to read from mtd6

The current 19.07.0 or snapshot ar71xx initramfs images do not complain
about any bad eraseblocks, and can properly managa the UBI fs at mtd6:

[    3.402365] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xf1
[    3.408818] nand: Samsung NAND 128MiB 3,3V 8-bit
[    3.413534] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048,
OOB size: 64
[    3.421239] Scanning device for bad blocks
[    3.579454] Creating 3 MTD partitions on "ar934x-nfc":
[    3.584716] 0x-0x0004 : "booter"
[    3.607604] 0x0004-0x0040 : "kernel"
[    3.630593] 0x0040-0x0800 : "ubi"

It looks like the NAND chip is correctly detected, but I don't know what
I'm missing that causes the [wrong] bad eraseblocks to appear. Any
suggestions? The tree with the commit adding support is at
https://github.com/rogerpueyo/openwrt/tree/ath79-mikrotik-rb-922uags-5hpacd_badblocks

Thanks!

Roger



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] (no subject)

2019-12-11 Thread Roger Pueyo Centelles | Guifi.net 
Hi,

Have you checked https://openwrt.org/trademark ?

Cheers!

El 11/12/19 a les 20:43, sagar jain ha escrit:
>
> Can i sell OpenWRT based router ?
>
>  
>
> Sent from Mail  for
> Windows 10
>
>  
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ath79: add support for COMFAST CF-E130N v2

2019-11-13 Thread Roger Pueyo Centelles | Guifi.net 
Hi Pavel,

> Specifications:
>
>  - QCA9531 SoC
>  - 1x 10/100 Mbps Ethernet, both with PoE-in support

If it has one Ethernet, then there's only one PoE-in.

Cheers!




signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: add support for COMFAST CF-E130N v2

2019-11-13 Thread Roger Pueyo Centelles | Guifi.net 
Well, rather than looking at the specifications, I'd check if the actual
hardware is 802.11bgn. :)

You could try the "iw list" command to see if the available channels
match the 802.11bgn band or not.

Cheers!

El 13/11/19 a les 11:33, Kryma ha escrit:
> Hi,
>
>> In addition to Adrian's comments, could it be that the device was a
>> 802.11bgn router?
>>
> Looking at the specifications, it seems to be one indeed. Should I
> make any changes regarding that?



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: add support for COMFAST CF-E130N v2

2019-11-11 Thread Roger Pueyo Centelles | Guifi.net 
Hi,

In addition to Adrian's comments, could it be that the device was a
802.11bgn router?
www.comfast.com.cn/index.php?m=content=index=show=19=23

Cheers,

Roger

El 11/11/19 a les 10:09, Adrian Schmutzler ha escrit:
> Hi,
>
>> +aliases {
>> +serial0 = 
>> +led-boot = 
>> +led-failsafe = 
>> +led-upgrade = 
> Please don't use LAN here, as it will be ambiguous.
> For TP-Link CPE devices, we relied on rssi_high for this task, so either use 
> this one or choose "unused".
> Please prefix the led label (but not the node name) with "led_", so either 
> led_rssihigh or led_unused ...
>
>> +label-mac-device = 
>> +};
>> +
>> +leds {
>> +compatible = "gpio-leds";
>> +
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_rssimediumhigh_pin>;
>> +
>> +wlan {
>> +label = "cf-e130n-v2:green:wlan";
>> +gpios = < 0 GPIO_ACTIVE_LOW>;
>> +linux,default-trigger = "phy0tpt";
>> +};
>> +
>> +lan: lan {
>> +label = "cf-e130n-v2:green:lan";
>> +gpios = < 2 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> +unused {
>> +label = "cf-e130n-v2:green:unused";
>> +gpios = < 3 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> +rssilow {
>> +label = "cf-e130n-v2:red:rssilow";
>> +gpios = < 11 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> +rssimediumlow {
>> +label = "cf-e130n-v2:red:rssimediumlow";
>> +gpios = < 12 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> +rssimediumhigh {
>> +label = "cf-e130n-v2:green:rssimediumhigh";
>> +// No individual GPIOs matched this LED!
>> +};
>> +
>> +rssihigh {
>> +label = "cf-e130n-v2:green:rssihigh";
>> +gpios = < 16 GPIO_ACTIVE_LOW>;
>> +};
>> +};
>> +
>> +keys {
>> +compatible = "gpio-keys";
>> +
>> +reset {
>> +label = "reset";
>> +linux,code = ;
>> +gpios = < 17 GPIO_ACTIVE_LOW>;
>> +debounce-interval = <60>;
>> +};
>> +};
>> +};
>> +
>> + {
>> +led_rssimediumhigh_pin: pinmux_rssimediumhigh_pin {
>> +pinctrl-single,bits = <0x10 0x0 0xff>;
>> +};
> Single tab indent.
>
>> +};
>> +
>> + {
>> +status = "okay";
>> +num-cs = <1>;
> Add empty line after status.
>
>> +
>> +flash@0 {
>> +compatible = "jedec,spi-nor";
>> +reg = <0>;
>> +spi-max-frequency = <2500>;
>> +
>> +partitions {
>> +compatible = "fixed-partitions";
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +
>> +uboot:  partition@0 {
>> +label = "u-boot";
>> +reg = <0x00 0x01>;
>> +read-only;
>> +};
>> +
>> +art: partition@1 {
>> +label = "art";
>> +reg = <0x01 0x01>;
>> +read-only;
>> +};
>> +
>> +firmware: partition@2 {
>> +compatible = "denx,uimage";
>> +label = "firmware";
>> +reg = <0x02 0x7d>;
>> +};
>> +
>> +nvram: partition@7f {
>> +label = "nvram";
>> +reg = <0x7f 0x01>;
>> +read-only;
>> +};
> We typically only add node labels when they are required, so here we would 
> only need "art:". Keep the label properties, though ...
>
>> +};
>> +};
>> +};
>> +
>> + {
>> +status = "okay";
>> +};
>> +
>> + {
>> +status = "okay";
>> +phy-handle = <>;
>> +mtd-mac-address = < 0x0>;
> Add empty lines after status and after phy-handle.
>
>> +
>> +gmac-config {
>> +device = <>;
>> +switch-phy-swap = <1>;
>> +};
>> +};
>> +
>> + {
>> +status = "okay";
> Add empty line after status.
>
>> +mtd-cal-data = < 0x1000>;
>> +};
>> +
>> diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
>> b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
>> index fbb0d0ea03..3046d34605 100755
>> --- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
>> +++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
>> @@ -47,6 +47,14 @@ comfast,cf-e120a-v3)
>>  ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH"
>>

Re: [OpenWrt-Devel] [PATCH v3] ramips: add support for Xiaomi Mi Wi-Fi Router 3G v2

2019-10-21 Thread Roger Pueyo Centelles | Guifi.net 
Hi,

Mine were just suggestions; feel free to do it or not! :)

Roger

El 21/10/19 a les 14:53, John Crispin ha escrit:
> On 31/08/2019 23:32, m...@adrianschmutzler.de wrote:
>> "6t@eth0" and "6@eth0" should be the same, so this can be merged with
>> cudy,wr1000.
>
> I meant that part, sorry the mail was sitting in my draft folder
> John
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [RFC] ath79: support for MikroTik wAP AC: vmlinux.elf + DTB file

2019-10-17 Thread Roger Pueyo Centelles | Guifi.net 
Hi,

I am trying to port the "MikroTik RouterBOARD wAP G-5HacT2HnD", also
known as "wAP AC" to ath79 (it's already supported in ar71xx) and I got
stuck. I think I can't add the corresponding DTB to the kernel image,
which has to be in ELF format so that the bootloader accepts it.

So far, I get the device to boot the vmlinux.elf or the
vmlinux-initramfs.elf images and show some output on the console, but it
stops immediately. From what I have been able to find around, I suspect
that the line:

[    0.00] OF: fdt: No valid device tree found, continuing without

suggests that the DTB was not appended to the kernel, so it can not be
parsed and the device ends up stopping at:

[    0.00] Failed to get CPU node
[    0.00] sched_clock: 32 bits at 100 Hz, resolution 1000ns,
wraps every 2147483647500ns


I would like to ask you for your advice on how to generate the ELF
images so that they include the dtb, since I am not able to make it and
I can't go beyond that on supporting the device.

Please find attached the complete boot log (28 lines) and the patch I
have been working on (also at
https://github.com/rogerpueyo/openwrt/tree/ath79-mikrotik-rb-wapg-5hact2hnd_wip).

Thank you very much,

Roger



[0.00] Linux version 4.19.79 (le@builder) (gcc version 8.3.0 (OpenWrt 
GCC 8.3.0 r11237-d1072096f4)) #0 Tue Oct 15 21:31:13 2019
[0.00] bootconsole [early0] enabled
[0.00] CPU0 revision is: 00019750 (MIPS 74Kc)
[0.00] SoC: Qualcomm Atheros QCA9556 ver 1 rev 0
[0.00] Determined physical RAM map:
[0.00]  memory: 0400 @  (usable)
[0.00] Initrd not found or empty - disabling initrd
[0.00] OF: fdt: No valid device tree found, continuing without
[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] Zone ranges:
[0.00]   Normal   [mem 0x-0x03ff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x03ff]
[0.00] Initmem setup node 0 [mem 0x-0x03ff]
[0.00] random: get_random_bytes called from start_kernel+0x98/0x4a8 
with crng_init=0
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 16240
[0.00] Kernel command line:   rootfstype=squashfs,jffs2
[0.00] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.00] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Writing ErrCtl register=
[0.00] Readback ErrCtl register=
[0.00] Memory: 50756K/65536K available (4273K kernel code, 178K rwdata, 
1008K rodata, 8036K init, 206K bss, 14780K 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] Failed to get CPU node
[0.00] sched_clock: 32 bits at 100 Hz, resolution 1000ns, wraps 
every 2147483647500nsdiff --git a/target/linux/ath79/dts/qca9556_mikrotik_rb-wapg-5hact2hnd.dts b/target/linux/ath79/dts/qca9556_mikrotik_rb-wapg-5hact2hnd.dts
new file mode 100644
index 00..9c86bd33c6
--- /dev/null
+++ b/target/linux/ath79/dts/qca9556_mikrotik_rb-wapg-5hact2hnd.dts
@@ -0,0 +1,110 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include 
+#include 
+
+#include "qca9557.dtsi"
+
+/ {
+	compatible = "mikrotik,rb-wapg-5hact2hnd", "qca,qca9556";
+	model = "MikroTik RouterBOARD wAP G-5HacT2HnD";
+
+	aliases {
+		serial0 = 
+	};
+
+	chosen {
+		bootargs = "console=ttyS0,115200n8";
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+	};
+
+	keys {
+		compatible = "gpio-keys";
+
+		reset {
+			label = "reset";
+			linux,code = ;
+			gpios = < 1 GPIO_ACTIVE_LOW>;
+			debounce-interval = <60>;
+		};
+	};
+};
+
+ {
+	status = "okay";
+	num-cs = <1>;
+
+	flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <2500>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition@0 {
+label = "routerboot";
+reg = <0x00 0x00e000>;
+read-only;
+			};
+
+			partition@e000 {
+label = "hard_config";
+reg = <0x000e000 0x00f000>;
+read-only;
+			};
+
+			partition@f000 {
+label = "bios";
+reg = <0x000f000 0x01>;
+read-only;
+			};
+
+			partition@1 {
+label = "routerboot2";
+reg = <0x01 0x01f000>;
+read-only;
+			};
+
+			partition@1f000 {
+label = "soft_config";
+reg = <0x001f000 0x02>;
+read-only;
+			};
+
+			partition@2 {
+compatible = "denx,uimage";
+label = "firmware";
+reg = <0x02 0x100>;
+			};
+		};
+	};
+};
+
+ {
+	status = "okay";
+};
+
+ {
+	status = "okay";
+
+	wifi@0,0 {
+		compatible = "qcom,ath10k";
+		reg

Re: [OpenWrt-Devel] [PATCH v3] ramips: add support for Xiaomi Mi Wi-Fi Router 3G v2

2019-10-11 Thread Roger Pueyo Centelles | Guifi.net 
Hi Paul,

I opened a pull request on GitHub to support the Mi Router 4A Gigabit
Edition, which is essentially the same device. You can find it at
https://github.com/openwrt/openwrt/pull/2486

There are a few differences you may want to address:

>>> +   xiaomi,mir3g-v2)
>>> +   wan_mac=$(mtd_get_mac_binary factory 0xe006)
>>> +   ;;

You may want to add "label_mac=$wan_mac" there, if the MAC address on
the back label matches the WAN interface (on the R4G it does).

Also, it looks like a newline should be added at the end of the .dts file.

>>> +define Device/xiaomi_mir3g-v2
>>> + MTK_SOC := mt7621
>>> + IMAGE_SIZE := 14848k
>>> + DEVICE_VENDOR := Xiaomi
>>> + DEVICE_MODEL := Mi Router 3G
>>> + DEVICE_VARIANT := v2
>>> + DEVICE_ALT0_VENDOR := Xiaomi
>>> + DEVICE_ALT0_MODEL := Mi Router 4A Gigabit Edition
>>> + DEVICE_PACKAGES := kmod-mt7603 kmod-mt76x2 wpad-basic
>>> +endef
>>> +TARGET_DEVICES += xiaomi_mir3g-v2

Since there are two Xiaomi Router 4A variants, the 100m and the Gigabit
Edition, you may want to use:

+ DEVICE_ALT0_VENDOR := Xiaomi
+ DEVICE_ALT0_MODEL := Mi Router 4A + DEVICE_ALT0_VARIANT := Gigabit Edition


Last, I added the device to uboot-envtools. Feel free to copy it:
https://github.com/openwrt/openwrt/pull/2486/commits/2625499ca554449e7a19bb5f6f61acdefb5a69e1

Best,

Roger

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC] ath79: add support for COMFAST CF-E313AC

2019-04-02 Thread Roger Pueyo Centelles | Guifi.net 
Hi,

Sorry for the inconvenience, but I'd like to insist on this topic since
it didn't get much traction on the first attempt.

I mostly succeeded in adding support for the COMFAST CF-E313AC devices,
but I ran into a couple of issues:

1) I need to remove the board-2.bin file shipped with the
ath10k-firmware-qca9888-ct so that the driver uses the actual
calibration data from the flash, dumped to board.bin (see [1]
)

2) the device has a 16MB SPI flash chip, but the stock firmware only
uses the first 8 MB, so I'm wasting the remaining 8 MB


I'd appreciate any comment on the topic. I also opened a pull request
(see [2] ) at GitHub,
where you're also very welcome to share your thoughts.

Thanks,

Roger


[1]
https://github.com/openwrt/openwrt/pull/1942/commits/9028a627bb9eb39ba74c9273cdf393bcd12c30cb#diff-8c41cbed377d406698f49b82d78a2057

[2] https://github.com/openwrt/openwrt/pull/1942

El 19/3/19 a les 13:33, Roger Pueyo Centelles ha escrit:
> Hi,
>
> I've just added support for the COMFAST CF-E313AC, an  outdoor wireless
> CPE with two Ethernet ports and a 802.11ac radio (see patch below).
>
> Everything is working fine but I've got two issues for which I'd like to
> get some advise:
>
> 1) target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
>
>I had to add "rm /lib/firmware/ath10k/QCA9888/hw2.0/board-2.bin", since
>the driver tries to board-2.bin (the default calibration data from the
>firmware package) first and, when that file is not found, falls back to
>board.bin (the calibration data read from the flash).
>
>I haven't seen this on any other device, so I guess there must be a more
>elegant way to deal with it. Any idea?
>
> 2) target/linux/ath79/dts/qca9531_comfast_cf-e313ac.dts
>
>The device is equipped with a "w25q128" flash chip (16384 Kbytes) but the
>stock firmware image only used half of it (nvram partition finishes at
>0x0080, i.e., 8192 Kbytes):
>
>*** stock firmware bootlog ***
> [...]
>[0.73] 0x-0x0001 : "u-boot"
>[0.74] 0x0001-0x0002 : "art"
>[0.74] 0x0002-0x001a : "kernel"
>[0.75] 0x001a-0x007e : "rootfs"
>[0.76] mtd: device 3 (rootfs) set to be root filesystem
>[0.76] 1 squashfs-split partitions found on MTD device rootfs
>[0.77] 0x006c-0x007e : "rootfs_data"
>[0.78] 0x007e-0x007f : "configs"
>[0.78] 0x007f-0x0080 : "nvram"
>[0.79] 0x0002-0x007e : "firmware"
> [...]
>
>Is there a way to use the remaining half of the flash?
>
>
> Any comments regarding these or other issues will be highly appreciated.
>
> Thanks!
>
>
>
> ---
>  .../ath79/base-files/etc/board.d/01_leds  |   9 ++
>  .../etc/hotplug.d/firmware/11-ath10k-caldata  |   7 +
>  .../ath79/dts/qca9531_comfast_cf-e313ac.dts   | 143 ++
>  target/linux/ath79/image/generic.mk   |   8 +
>  4 files changed, 167 insertions(+)
>  create mode 100644 target/linux/ath79/dts/qca9531_comfast_cf-e313ac.dts
>
> diff --git a/target/linux/ath79/base-files/etc/board.d/01_leds 
> b/target/linux/ath79/base-files/etc/board.d/01_leds
> index db5a6a4578..50c9ca2a8d 100755
> --- a/target/linux/ath79/base-files/etc/board.d/01_leds
> +++ b/target/linux/ath79/base-files/etc/board.d/01_leds
> @@ -47,6 +47,15 @@ comfast,cf-e120a-v3)
>   ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH" 
> "$boardname:green:rssimediumhigh" "wlan0" "51" "100"
>   ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "$boardname:green:rssihigh" 
> "wlan0" "76" "100"
>   ;;
> +comfast,cf-e313ac)
> + ucidef_set_led_netdev "lan" "LAN" "$boardname:green:lan" "eth0"
> + ucidef_set_led_switch "wan" "WAN" "$boardname:green:wan" "switch0" 
> "0x02"
> + ucidef_set_rssimon "wlan0" "20" "1"
> + ucidef_set_led_rssi "rssilow" "RSSILOW" "$boardname:red:rssilow" 
> "wlan0" "1" "100"
> + ucidef_set_led_rssi "rssimediumlow" "RSSIMEDIUMLOW" 
> "$boardname:red:rssimediumlow" "wlan0" "26" "100"
> + ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH" 
> "$boardname:green:rssimediumhigh" "wlan0" "51" "100"
> + ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "$boardname:green:rssihigh" 
> "wlan0" "76" "100"
> + ;;
>  dlink,dir-859-a1)
>   ucidef_set_led_switch "internet" "WAN" "$boardname:green:internet" 
> "switch0" "0x20"
>   ;;
> diff --git 
> a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
> b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> index 8651c97099..3096c4e1e8 100644
> --- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> +++

Re: [OpenWrt-Devel] ath79: seting GPIO registers to specific values via DTS?

2018-12-17 Thread Roger Pueyo Centelles | Guifi.net 
Hi,

Thank you very much for clarifying that. :)

After looking a little bit into other devices' configurations, this line
in etc/board.d/01_leds will do the trick:

    ucidef_set_led_switch "wan" "WAN" "$boardname:green:wan" "switch0"
"0x02"


Last thing, I managed to get inside the stock firmware (a customized
OpenWrt version, by the way) and I saw that:

   - the port labeled "LAN", in U-Boot is eth0, in the stock firmware is
eth1
   - the port labeled "WAN", in U-Boot is eth1, in the stock firmware is
eth0

Should I be coherent to U-Boot and use the more common
LAN-eth0//WAN-eth1 assignation, or do it the other way round
(LAN-eth1//WAN-eth0) as in the stock firmware?


Thanks for your comments,

Roger


El 17/12/18 a les 5:50, Chuanhong Guo ha escrit:
> Hi!
>
> On Mon, Dec 17, 2018 at 7:43 AM Roger Pueyo Centelles | Guifi.net
>  wrote:
>> Hi Seb,
>>
>> You nailed it! :-)
>>
>> I was missing the ' "pinctrl-names = "default"; ' line. I must have
>> removed it from the .dts file I used as the source for mine at some
>> point. Then I just sorted the pinctrl-0/1 issue, which I had already
>> tried in any possible combination.
>>
>> After fixing this, I have detected another issue that had passed
>> unnoticed to me before. The eth1 interface always appears as UP (i.e.,
>> having link), even if I unplug the cable.
> This is expected. gmac1 is connected to builtin switch, which means
> this link is always up. Link changes happen in builtin switch, not
> gmac.
> ar71xx mixed switch and gmac driver together and it uses switch port
> status for gmac link. These two drivers are separated in ath79.
>> According to the datasheet, GMAC1 (eth1 here) is internally connected to
>> the integrated switch. The "swconfig dev switch0 show" command gives:
>>
>> Port 0:
>> enable_mirror_rx: 0
>> enable_mirror_tx: 0
>> pvid: 0
>> link: port:0 link:up speed:1000baseT full-duplex txflow rxflow
>> Port 1:
>> enable_mirror_rx: 0
>> enable_mirror_tx: 0
>> pvid: 1
>>     link: port:1 link:up speed:100baseT full-duplex auto
>>
>> How should I manage this?
>>
>> Thank you very much for your support.
>>
>> Best,
>>
>> Roger
>>
>> El 16/12/18 a les 19:07, Sebastian Kemper ha escrit:
>>> On Sun, Dec 16, 2018 at 06:23:53PM +0100, Roger Pueyo Centelles | Guifi.net 
>>> wrote:
>>>> Hi,
>>> Hello Roger!
>>>
>>>> [...]
>>>>
>>>> leds {
>>>> compatible = "gpio-leds";
>>>> pinctrl-1 = <_rssilow_pin _rssimediumhigh_pin
>>>> _rssihigh_pin>;
>>>>
>>>> [...]
>>>>
>>>>  {
>>>> led_rssilow_pin: pinmux_rssilow_pin {
>>>> pinctrl-single,bits = <0x8 0x0 0xff00>;
>>>> };
>>>>
>>>> led_rssimediumhigh_pin: pinmux_rssimediumhigh_pin {
>>>> pinctrl-single,bits = <0xc 0x0 0x00ff>;
>>>> };
>>>>
>>>> led_rssihigh_pin: pinmux_rssihigh_pin {
>>>> pinctrl-single,bits = <0x10 0x0 0x00ff>;
>>>> };
>>>> };
>>>>
>>>> [...]
>>> The pinmux part looks OK to me. Could you change the leds part to the
>>> below and try again?
>>>
>>>   leds {
>>>   compatible = "gpio-leds";
>>>
>>>   pinctrl-names = "default";
>>>   pinctrl-0 = <_disable_pins _rssilow_pin 
>>> _rssimediumhigh_pin _rssihigh_pin>;
>>>
>>>   [...]
>>>
>>> I added the jtag bit because I saw that you use it under keys. You have
>>> to remove
>>>
>>> pinctrl-0 = <_disable_pins>;
>>>
>>> under keys. Just put them all in one place.
>>>
>>> From my testing, when defining pinctrl-0 and pinctrl-1, the second one
>>> doesn't do anything. For example:
>>>
>>> pinctrl-0 = <_disable_pins>; // works
>>> pinctrl-1 = <_gpio_11>; // nothing happens
>>>
>>> But
>>>
>>> pinctrl-0 = <_disable_pins _gpio_11>; // both are applied - 
>>> works
>>>
>>>
>>> Kind regards,
>>> Seb
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ath79: seting GPIO registers to specific values via DTS?

2018-12-16 Thread Roger Pueyo Centelles | Guifi.net 
Hi Seb,

You nailed it! :-)

I was missing the ' "pinctrl-names = "default"; ' line. I must have
removed it from the .dts file I used as the source for mine at some
point. Then I just sorted the pinctrl-0/1 issue, which I had already
tried in any possible combination.

After fixing this, I have detected another issue that had passed
unnoticed to me before. The eth1 interface always appears as UP (i.e.,
having link), even if I unplug the cable.

According to the datasheet, GMAC1 (eth1 here) is internally connected to
the integrated switch. The "swconfig dev switch0 show" command gives:

Port 0:
    enable_mirror_rx: 0
    enable_mirror_tx: 0
    pvid: 0
    link: port:0 link:up speed:1000baseT full-duplex txflow rxflow
Port 1:
    enable_mirror_rx: 0
    enable_mirror_tx: 0
    pvid: 1
    link: port:1 link:up speed:100baseT full-duplex auto

How should I manage this?

Thank you very much for your support.

Best,

Roger

El 16/12/18 a les 19:07, Sebastian Kemper ha escrit:
> On Sun, Dec 16, 2018 at 06:23:53PM +0100, Roger Pueyo Centelles | Guifi.net 
> wrote:
>>
>> Hi,
> Hello Roger!
>
>> [...]
>>
>>     leds {
>>     compatible = "gpio-leds";
>>     pinctrl-1 = <_rssilow_pin _rssimediumhigh_pin
>> _rssihigh_pin>;
>>
>> [...]
>>
>>  {
>>     led_rssilow_pin: pinmux_rssilow_pin {
>>     pinctrl-single,bits = <0x8 0x0 0xff00>;
>>     };
>>
>>     led_rssimediumhigh_pin: pinmux_rssimediumhigh_pin {
>>     pinctrl-single,bits = <0xc 0x0 0x00ff>;
>>     };
>>
>>     led_rssihigh_pin: pinmux_rssihigh_pin {
>>     pinctrl-single,bits = <0x10 0x0 0x00ff>;
>>     };
>> };
>>
>> [...]
> The pinmux part looks OK to me. Could you change the leds part to the
> below and try again?
>
>   leds {
>   compatible = "gpio-leds";
>
>   pinctrl-names = "default";
>   pinctrl-0 = <_disable_pins _rssilow_pin 
> _rssimediumhigh_pin _rssihigh_pin>;
>
>   [...]
>
> I added the jtag bit because I saw that you use it under keys. You have
> to remove
>
> pinctrl-0 = <_disable_pins>;
>
> under keys. Just put them all in one place.
>
> From my testing, when defining pinctrl-0 and pinctrl-1, the second one
> doesn't do anything. For example:
>
> pinctrl-0 = <_disable_pins>; // works
> pinctrl-1 = <_gpio_11>; // nothing happens
>
> But
>
> pinctrl-0 = <_disable_pins _gpio_11>; // both are applied - works
>
>
> Kind regards,
> Seb
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] ath79: seting GPIO registers to specific values via DTS?

2018-12-16 Thread Roger Pueyo Centelles | Guifi.net 


Hi,

Some weeks ago I sent a PR adding ar71xx support for the Comfast
CF-E110N [1], an outdoor 2,4 GHz router. Everything was working fine. A
few days later I started working on adding ath79 support for the same
device [2]. Almost everything worked, except for three GPIOs which I was
not able to properly configure.

Thanks to the help from @ynezz we traced the issue until we could narrow
the problem: the bootloader (U-Boot) configures the GPIOs with some
specific values (e.g., so that LEDs blink to the Ethernet ports
activity, firmware recovery, etc.). With the ar71xx code I was able to
reset the GPIOs configuration; with the ath79 code I am not. You can
read the full discussion at the GitHub pull request page [2], but here
is the summary.

    The GPIOs I need to properly configure are GPIO11, GPIO14 and
GPIO16, which drive three RSSI LEDs. According to the SoC's datasheet
[3], they are configured through registers 0x18040034, 0x18040038 and
0x1804003c.

    Using U-Boot's memory dump and memory write functions I could read
their values and set them to zero. This way, instead of (e.g.) blinking
to the Ethernet port activity, they did work as they were told by OpenWrt:

    ath> md 0x18040034 1; md 0x18040038 1; md 0x1804003c 1
    18040034: 2c16    ,...
    18040038: 2a2b    *+..
    1804003c: 0129    ...)

    ath> mw 0x18040034 0016; mw 0x18040038 2a00; mw 0x1804003c
0100

    ath> md 0x18040034 1; md 0x18040038 1; md 0x1804003c 1
    18040034: 0016    
    18040038: 2a00    *...
    1804003c: 0100    

This way I made sure I needed to write zeros to the specific bits in the
three different addresses.

So, following @ynezz suggestions I added the following code to the
device dts file:

[...]

    leds {
    compatible = "gpio-leds";
    pinctrl-1 = <_rssilow_pin _rssimediumhigh_pin
_rssihigh_pin>;

[...]

 {
    led_rssilow_pin: pinmux_rssilow_pin {
    pinctrl-single,bits = <0x8 0x0 0xff00>;
    };

    led_rssimediumhigh_pin: pinmux_rssimediumhigh_pin {
    pinctrl-single,bits = <0xc 0x0 0x00ff>;
    };

    led_rssihigh_pin: pinmux_rssihigh_pin {
    pinctrl-single,bits = <0x10 0x0 0x00ff>;
    };
};

[...]

Where 0x8, 0xc and 0x10 are the distances from the starting address of
pinmux to the registers, 0x0 is the value I want to write, and
0xff00, 0x00ff and 0x00ff are the submasks to apply (it's a
32 bits register, right?), so that I change only the wanted bits and not
the rest of the register. However, nothing happened.

I also got more suggestions from @ynezz, which I tried, as well as tons
of other combinations, values, masks, using pinctrl-single,pins, etc.,
with no success at all.

So, the question is, what do I have to add to the device's DTS file so
can I write these 0s to the registers?

Thank you very much for your help, and my gratitude to @ynezz for his
contributions so far. :)

Roger

[1] https://github.com/openwrt/openwrt/pull/1531

[2] https://github.com/openwrt/openwrt/pull/1623

[3]
https://github.com/Deoptim/atheros/blob/master/QCA9531_V2.0_nowatermark.pdf


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel