Re: Comfast CF-E110n

[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

[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

[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: ath79: mikrotik mac issue

[Roger Pueyo Centelles]

Hi,

I gave it a try with OpenWrt SNAPSHOT, r16574-f7e00d81bc and Linux
OpenWrt 5.10.31 #0 Sun Apr 18 14:14:52 2021 mips GNU/Linux. The MAC
addresses are correct too.

Do we have the same file and drivers?

root@OpenWrt:/# md5sum /etc/*/02_network*
02ddf92ac3486bc00a25e0fa436bbba6  /etc/board.d/02_network

root@OpenWrt:/# dmesg | grep -i mikrotik | grep -i driver
[    1.369453] MikroTik RouterBOARD hardware configuration sysfs driver
v0.06
[    1.378313] MikroTik RouterBOARD software configuration sysfs driver
v0.03

Roger

El 20/4/21 a les 10:45, Koen Vandeputte ha escrit:
> Hi Roger,
>
> An important detail:
> I'm testing using kernel 5.10 :-)
>
> Regards,
>
> Koen
>

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

Re: ath79: mikrotik mac issue

[Roger Pueyo Centelles]

Hi,

Sorry, no clue. I am getting MAC addresses correctly assigned on a
MikroTik RB922UAGS-5HPacD running OpenWrt SNAPSHOT, r16574-f7e00d81bc.

As expected, random MAC addresses appear for both eth0 and eth1 on a
fresh boot after flashing with "sysupgrade -v -n. At around ~40 seconds
uptime, the network is activated with the correct MAC addresses enabled
(same as in /etc/config/network):

eth1: /sys/firmware/mikrotik/hard_config/mac_base
eth0: /sys/firmware/mikrotik/hard_config/mac_base+1
wlan0: /sys/firmware/mikrotik/hard_config/mac_base+2

The behaviour is correct on rebooting or reflashing.

Roger

El 16/4/21 a les 17:04, Koen Vandeputte ha escrit:
> Hi all,
>
> I found another interesting issue testing on a rb922
> The board gets a random mac on each boot.
>
> This is normal and should be automatically corrected by 02_network
> afterwards when hard_config is available, but it seems it's not
> getting applied correctly.
> Debugging the 02_network script shows that the actual value is
> properly fetched from hard_config, but it's not getting applied for
> some reason ..
> /etc/board.json shows the correct ones, but the interfaces still carry
> the random MAC.
>
> Judging by the flow in the script, I guess this issue will be present
> on all ath79 Mikrotik targets.
>
> Anyone got a clue?
>
> Regards,
>
> Koen
>

___
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?

[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 (?)

[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 (?)

[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

[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

[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

[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

[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

[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

[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

[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 equivalent of disable_smarteee

[Roger Pueyo Centelles]

Hi Martin, Adrian,

Thanks for the info. The device is advertising EEE capabilities, and so
is the adapter on my computer it is connected to:

root@computer:~# ethtool --show-eee eth2
EEE Settings for eth2:
    EEE status: enabled - active
    Tx LPI: disabled
    Supported EEE link modes:  100baseT/Full
       1000baseT/Full
    Advertised EEE link modes:  10baseT/Full
    100baseT/Half
    Link partner advertised EEE link modes:  100baseT/Full
     1000baseT/Full

The eee-broken-100tx/eee-broken-1000t options are not yet set in the
DTS, but I am not seeing any EEE-related messages on the router (nor on
my computer) --or I'm not looking at the right place--. Is it just a
matter of time (i.e., they will eventually appear)? In other words,
should I add them to the DTS?

Regards,

Roger

El 1/2/20 a les 19:07, Martin Blumenstingl ha escrit:
> Hi Adrian,
>
> On Sat, Feb 1, 2020 at 6:50 PM  wrote:
>> Hi,
>>
>> in the device support PR for MikroTik RouterBOARD 922UAGS-5HPacD [1] for 
>> ath79, we have the following in ar71xx mach files [2]:
>>
>> static struct at803x_platform_data rb922gs_at803x_data = {
>> .disable_smarteee = 1,
>> };
>>
>> Is there an ath79 equivalent available and necessary?
> upstream has the following two properties (which need to be added
> inside the Ethernet PHY devicetree node):
> - eee-broken-100tx
> - eee-broken-1000t
> - (there are more, see 
> Documentation/devicetree/bindings/net/ethernet-phy.yaml)
>
> set them and EEE will not be advertised anymore.
>
> there's some additional, AT803X PHY specific register write inside
> at803x_disable_smarteee from
> target/linux/generic/pending-4.14/734-net-phy-at803x-allow-to-configure-via-pdata.patch
> This modifies the AT803X_PCS_SMART_EEE_CTRL3 register. I don't know
> whether this is necessary when EEE is not advertised
>
>
> Martin
>

___
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

[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

[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

[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

[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)

[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

[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

[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

[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

[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

[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

[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

[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]
<https://github.com/openwrt/openwrt/pull/1942/commits/9028a627bb9eb39ba74c9273cdf393bcd12c30cb#diff-8c41cbed377d406698f49b82d78a2057>)

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] <https://github.com/openwrt/openwrt/pull/1942>) 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" "wlan

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

[Roger Pueyo Centelles]

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
+++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -162,6 +162,13 @@ case "$FIRMWARE" in
;;
 "ath10k/pre-cal-pci-:00:00.0.bin")
case $board in
+   comfast,cf-e313ac)
+   ath10kcal_extract "art" 20480 12064
+   ath10kcal_patch_mac_crc $(mtd_get_mac_binary art 4098)
+   ln -sf /lib/firmware/ath10k/pre-cal-pci-\:00\:00.0.bin \
+   /lib/firmware/ath10k/QCA9888/hw2.0/board.bin
+   rm /lib/firmware/ath10k/QCA9888/hw2.0/board-2.bin
+   ;;
phicomm,k2t)
ath10kcal_extract "art" 20480 12064
ath10kcal_patch_mac_crc $(k2t_get_mac "5g_mac")
diff --git a/target/linux/ath79/dts/qca9531_comfast_cf-e313ac.dts 
b/target/linux/ath79/dts/qca9531_comfast_cf-e313ac.dts
new file mode 100644
index 00..cf6587b615
--- /dev/null
+++ b/target/linux/ath79/dts/qca9531_comfast_cf-e313ac.dts
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include 
+#include 
+
+#include "qca953x.dtsi"
+
+/ {
+   compatible = "comfast,cf-e313ac", "qca,qca9531";
+   model = "COMFAST CF-E313AC";
+
+   aliases {
+   serial0 = 
+   led-boot = 
+   led-failsafe = 

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

[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?

[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?

[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

[OpenWrt-Devel] Help with sysupgrade/factory images for YunCore CPE-880 (ar71xx)

[Roger Pueyo Centelles]

Hi,

Some days ago I received a YunCore CPE-880 router. It's an AR9344-based 
outdoor 5 GHz CPE. You can read more about it at 
https://wiki.openwrt.org/toh/yuncore/cpe-880.


Up to now I've succeeded in adding OpenWrt support for this device (see 
attached patch) with:


 - Ethernet+switch working (LAN & WAN ports)
 - Wireless working
 - Leds and button working
 - MAC addresses read from EEPROM

From U-boot I can boot the initramfs image (see attached file 
uboot-initramfs.log) and all the features above are working.


I can also flash the kernel and the rootfs to the flash and boot OpenWrt 
successfully (see attached file uboot-rootfs-kernel.log) with the 
following commands:


lf=tftp 0x8006 ${dir}wnc83${bc}-jffs2& 0x9f02 
+0x65& $fileaddr 0x9f02 $filesize
lk=tftp 0x8006 ${dir}vmlinux${bc}.lzma.uImage& 0x9f38 
+$filesize& $fileaddr 0x9f38 $filesize


However, I am not able to generate a proper sysupgrade image. Either 
when booting from the initramfs or from lf+lk, performing a sysupgrade 
turns into mtd/jffs errors on next boot (see attached file 
sysupgrade.log).


Finally, I have no clue on how to generate a factory image that I can 
flash to the stock firmware from the web interface (I get an "Invalid 
image" error). Apparently, the stock firmware is [based on] the Atheros 
SDK.


Any help to fix the image generation issues will be very appreciated.

Kind regards,

Rogerroot@OpenWrt:/# sysupgrade -v -n /tmp/openwrt-ar71xx-generic-cpe-880-squashfs-sy
supgrade.bin 
killall: watchdog: no process killed
Sending TERM to remaining processes ... udhcpc odhcp6c ntpd dnsmasq ubusd logd 
netifd odhcpd 
Sending KILL to remaining processes ... 
Switching to ramdisk...
Performing system upgrade...
Unlocking firmware ...

Writing from  to firmware ... 
Upgrade completed
Rebooting system...
[  129.398163] Removing MTD device #3 (rootfs_data) with use count 1
[  129.429310] reboot: Restarting system


U-Boot 1.1.4 (Nov 18 2015 - 16:33:47)

U-boot AP123


DRAM:  64 MB
Flash:  8 MB
In:serial
Out:   serial
Err:   serial
Net:   
Fetching MAC Address from 0x83ff2ac8
Fetching MAC Address from 0x83ff2ac8
eth0: de:ad:be:ef:00:00
eth0 up
eth1: de:ad:be:ef:00:01
eth1 up
eth0, eth1
Hit any key to stop autoboot:  0 
## Booting image at 9f38 ...
   Image Name:   MIPS OpenWrt Linux-4.1.13
   Created:  2016-01-09  19:52:32 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:1257823 Bytes =  1.2 MB
   Load Address: 8006
   Entry Point:  8006
   Verifying Checksum at 0x9f380040 ...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 4.1.13 (me@xeon) (gcc version 5.2.0 (OpenWrt GCC 
5.2.0 r48014) ) #1 Sat Jan 9 20:52:14 CET 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: 0400 @  (usable)
[0.00] Initrd not found or empty - disabling initrd
[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] 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: 16256
[0.00] Kernel command line:  board=CPE-880 console=ttyS0,115200 
mtdparts=spi0.0:64k(u-boot)ro,64k(u-boot-env)ro,3456k(rootfs),1024k(kernel),3456k(rootfs1),64k(nvram),64k(ART)ro,7936k@0x2(firmware)
 rootfstype=squashfs,jffs2 noinitrd
[0.00] PID hash table entries: 256 (order: -2, 1024 bytes)
[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: 60556K/65536K available (2799K kernel code, 140K rwdata, 
572K rodata, 252K init, 195K bss, 4980K reserved, 0K cma-reserved)
[0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] NR_IRQS:83
[0.00] Clocks: CPU:535.000MHz, DDR:400.000MHz, AHB:200.000MHz, 
Ref:40.000MHz
[0.00] clocksource MIPS: mask: 0x max_cycles: 0x, 
max_idle_ns: 7144898866 ns
[0.10] sched_clock: 32 bits at 267MHz, resolution 3ns, wraps every 
8027976190ns
[0.007510] Calibrating delay loop... 266.64 BogoMIPS (lpj=1333248)
[0.090022] pid_max: default: 32768 minimum: 301
[0.094608] 

Re: [OpenWrt-Devel] Ath10k mesh with OpenWRT question

[Roger Pueyo Centelles]

Hi,

At some point I was able to get IBSS running with an ath10k radio (QCA988X)
using firmware-2.bin_999.999.0.636 [1]. I couldn't test it thoroughly, but
it ran for some days in a production BMX6 mesh. I also tried Ben Greear's
CT firmware, with no success.

If you are starting a network from scratch, however, go for 802.11s instead
of IBSS, as Sven said.

Kind regards,

Roger

[1] https://github.com/kvalo/ath10k-firmware/tree/master/QCA988X/main

2015-12-19 10:26 GMT+01:00 Sven Eckelmann :

> On Friday 18 December 2015 14:14:38 Zach Sherin wrote:
> > I'm trying to use bmx6 to mesh together some routers but keep coming up
> > against roadblocks trying to get the wireless chipsets into IBSS mode. Do
> > you have any suggestions or places to start? If not, no worries. Thank
> you
> > very much for your time, and I hope to hear from you soon.
>
> My suggestion is to use 802.11s (load ath10k_core with rawmode=1 - for
> example
> add it as parameter for ath10k_core to in the *ath10k file in
> /etc/modules.d/)
> instead of adhoc/ibss when using a recent QCA988* firmware. You have to set
> the mesh_ttl=1 and mesh_fwding=0 when you want to use bmx instead of the
> 802.11s mesh protocol(s). The wireless configuration could for example look
> like this:
>
> config wifi-iface 'wmesh0'
> option device 'radio0'
> option ifname 'mesh0'
> option network 'mesh'
> option mode 'mesh'
> option mesh_id 'myownmesh' # change this
> option disabled '0'
> option mcast_rate '18000'
> option macaddr '02:11:22:33:44:55' # change this
> option mesh_ttl 1
> option mesh_fwding 0
> option encryption 'none'
>
> But don't expect encryption to work with authsae/wpa_supplicant. I also
> heard
> that IBSS should work with the qca6174 (TLV) firmware but I never tested it
> and therefore cannot confirm it.
>
> If you really want IBSS with QCA988x then you have to try the firmware
> fork of
> Ben Greear [1]. But it was never really working for me and also still had
> bugs
> in AP mode which were only fixed in the official firmware from QCA. Don't
> forget that you still need the driver patches from Ben Greear.
>
> Kind regards,
> Sven
>
> [1] http://www.candelatech.com/ath10k.php
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ar71xx: Add pll_1000 value for eth0

[Roger Pueyo Centelles]

This patch adds the pll_1000 value for eth0 interface. This makes the Rocket M
XW image compatible with other Ubiquiti devices with similar hardware with a
Gigabit Ethernet port.
---
 .../ar71xx/patches-3.18/903-MIPS-ath79-ubnt-rocket-m-xw-support.patch  | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/target/linux/ar71xx/patches-3.18/903-MIPS-ath79-ubnt-rocket-m-xw-support.patch
 
b/target/linux/ar71xx/patches-3.18/903-MIPS-ath79-ubnt-rocket-m-xw-support.patch
index 056a690..ccc752e 100644
--- 
a/target/linux/ar71xx/patches-3.18/903-MIPS-ath79-ubnt-rocket-m-xw-support.patch
+++ 
b/target/linux/ar71xx/patches-3.18/903-MIPS-ath79-ubnt-rocket-m-xw-support.patch
@@ -10,7 +10,7 @@
ATH79_MACH_UBNT_UAP_PRO,/* Ubiquiti UniFi AP Pro */
 --- a/arch/mips/ath79/mach-ubnt-xm.c
 +++ b/arch/mips/ath79/mach-ubnt-xm.c
-@@ -449,12 +449,42 @@
+@@ -449,12 +449,43 @@
ath79_register_eth(0);
  }
  
@@ -38,6 +38,7 @@
 +  
 +  ath79_register_mdio(0, ~BIT(4));
 +  ath79_eth0_data.phy_mask = BIT(4);
++  ath79_eth0_pll_data.pll_1000 = 0x0600;
 +  ath79_register_eth(0);
 +}
 +
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ar71xx: Add pll_1000 value for eth0 to Ubiquiti Rocket M XW

[Roger Pueyo Centelles]

This patch adds the pll_1000 value for eth0 interface. This makes the Rocket M
XW image compatible with other Ubiquiti devices with similar hardware with a
Gigabit Ethernet port.

Signed-off-by: Roger Pueyo Centelles roger.pu...@guifi.net
---
 .../ar71xx/patches-3.18/903-MIPS-ath79-ubnt-rocket-m-xw-support.patch  | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/target/linux/ar71xx/patches-3.18/903-MIPS-ath79-ubnt-rocket-m-xw-support.patch
 
b/target/linux/ar71xx/patches-3.18/903-MIPS-ath79-ubnt-rocket-m-xw-support.patch
index 056a690..ccc752e 100644
--- 
a/target/linux/ar71xx/patches-3.18/903-MIPS-ath79-ubnt-rocket-m-xw-support.patch
+++ 
b/target/linux/ar71xx/patches-3.18/903-MIPS-ath79-ubnt-rocket-m-xw-support.patch
@@ -10,7 +10,7 @@
ATH79_MACH_UBNT_UAP_PRO,/* Ubiquiti UniFi AP Pro */
 --- a/arch/mips/ath79/mach-ubnt-xm.c
 +++ b/arch/mips/ath79/mach-ubnt-xm.c
-@@ -449,12 +449,42 @@
+@@ -449,12 +449,43 @@
ath79_register_eth(0);
  }
  
@@ -38,6 +38,7 @@
 +  
 +  ath79_register_mdio(0, ~BIT(4));
 +  ath79_eth0_data.phy_mask = BIT(4);
++  ath79_eth0_pll_data.pll_1000 = 0x0600;
 +  ath79_register_eth(0);
 +}
 +
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] [ramips] Add support for Comfast CF-WR800N

[Roger Pueyo Centelles]

This patch adds support for Comfast CF-WR800N, a wall-plug wireless router
based on the MT7620N SoC with one Ethernet port and a 802.11n 2.4 GHz radio.

Signed-off-by: Roger Pueyo Centelles roger.pu...@guifi.net
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   4 +
 .../linux/ramips/base-files/etc/board.d/02_network |   6 ++
 target/linux/ramips/base-files/etc/diag.sh |   3 +
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/CF-WR800N.dts  | 114 +
 target/linux/ramips/image/Makefile |   2 +
 7 files changed, 133 insertions(+)
 create mode 100644 target/linux/ramips/dts/CF-WR800N.dts

diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
b/target/linux/ramips/base-files/etc/board.d/01_leds
index 56ba3b7..80623f4 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -73,6 +73,10 @@ case $board in
br6524n)
set_wifi_led edimax:blue:wlan
;;
+   cf-wr800n)
+   ucidef_set_led_netdev lan lan comfast:white:ethernet 
eth0.1
+   set_wifi_led comfast:white:wifi
+   ;;
cy-swr1100)
ucidef_set_led_default wps WPS samsung:blue:wps 0
set_usb_led samsung:blue:usb
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 24e1ba8..c8ef69f 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -108,6 +108,12 @@ ramips_setup_interfaces()
ucidef_add_switch_vlan switch0 1 1 2 3 4 6t
;;
 
+   cf-wr800n)
+   ucidef_set_interface_lan eth0.1
+   ucidef_add_switch switch0 1 1
+   ucidef_add_switch_vlan switch0 1 4 6t
+   ;;
+
cy-swr1100)
ucidef_set_interfaces_lan_wan eth0.1 eth0.2
ucidef_add_switch switch0 1 1
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 5301593..caede7b 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -36,6 +36,9 @@ get_status_led() {
br6425 | br-6475nd)
status_led=edimax:green:power
;;
+   cf-wr800n)
+   status_led=comfast:white:wps
+   ;;
cy-swr1100)
status_led=samsung:blue:wps
;;
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 616f4a1..5769d26 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -91,6 +91,9 @@ ramips_board_detect() {
*Buffalo WSR-1166DHP)
name=wsr-1166
;;
+   *Comfast CF-WR800N)
+   name=cf-wr800n
+   ;;
*Firefly FireWRT)
name=firewrt
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 17b456b..4ecf331 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -33,6 +33,7 @@ platform_check_image() {
bc2 | \
broadway | \
carambola | \
+   cf-wr800n | \
d105 | \
dap-1350 | \
dcs-930 | \
diff --git a/target/linux/ramips/dts/CF-WR800N.dts 
b/target/linux/ramips/dts/CF-WR800N.dts
new file mode 100644
index 000..5db6c83
--- /dev/null
+++ b/target/linux/ramips/dts/CF-WR800N.dts
@@ -0,0 +1,114 @@
+/dts-v1/;
+
+/include/ mt7620n.dtsi
+
+/ {
+   compatible = cf-wr800n, ralink,mt7620n-soc;
+   model = Comfast CF-WR800N;
+
+   chosen {
+   bootargs = console=ttyS0,115200;
+};
+
+   palmbus@1000 {
+   gpio0: gpio@600 {
+   status = okay;
+   };
+
+   gpio1: gpio@638 {
+   status = okay;
+   };
+
+   gpio2: gpio@660 {
+   status = okay;
+   };
+
+   gpio3: gpio@688 {
+   status = okay;
+   };
+
+   spi@b00 {
+   status = okay;
+
+   m25p80@0 {
+   #address-cells = 1;
+   #size-cells = 1;
+   compatible = mx25l6405d;
+   reg = 0 0;
+   linux,modalias = m25p80, w25q64;
+   spi-max-frequency = 1000;
+
+   partition@0 {
+   label = u-boot

Re: [OpenWrt-Devel] [ar71xx] Help with Ubiquiti Rocket M5 XW support patch

[Roger Pueyo Centelles]

Hi lynxis,

Just one port, but without switch.

The init is correct now and the Ethernet port works. I was using the wrong
mask, I thought it would be BIT(2) but I was wrong.

I'll be submitting the patch in a while. Thank you very much!

Roger

2015-04-16 0:15 GMT+02:00 Alexander Couzens lyn...@fe80.eu:

 Hi Roger,

 how many ethernet ports does this product has? 1 or 2?
 Ubiquity add a switch chip to it's new nanostation m (xw).

 I would say this product has only one port.
 Can you try this init please?

 static void __init ubnt_rocket_m_xw_setup(void)
 {
   ubnt_xw_init();

   ath79_register_mdio(0, ~BIT(4));
   ath79_eth0_data.phy_mask = BIT(4);
   ath79_register_eth(0);
 }

 Best Regards,
 lynxis

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


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

Re: [OpenWrt-Devel] [PATCH] [ar71xx] Add support for Ubiquiti Rocket M XW devices

[Roger Pueyo Centelles]

Hi,

Just setting the mask with BIT(4) does not work. The Rocket needs this line:

   ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII;

for the RGMII AR8035 Ethernet controller, while the Nano/Loco use the MII
mode:

   ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_MII;

Therefore the ubnt_xw_init() function does not apply for the Rocket.
Anyway, there are some common lines, so probably the three devices could be
merged somehow, I guess.

Roger

2015-04-16 14:29 GMT+02:00 Alexander Couzens lyn...@fe80.eu:

 Hi Roger,

 the loco xw seems to be very similiar to the rocket xw.
 Have you tried the init code from my last mail?
 If it works I would prefer it, because it's reusing existent code and it's
 a
 lot less code.

 Best,
 lynxis
 --
 Alexander Couzens

 mail: lyn...@fe80.eu
 jabber: lyn...@jabber.ccc.de
 mobile: +4915123277221

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


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

[OpenWrt-Devel] [ar71xx] Help with Ubiquiti Rocket M5 XW support patch

[Roger Pueyo Centelles]

Hi,

I've been working on supporting the new XW version of Ubiquiti's Rocket M5
devices. The hardware is very similar to the NanoStation [Loco] M5 XW, so
the images for these devices work on the Rocket *except* for the Ethernet
interface. I posted some information about the device in the forum
https://forum.openwrt.org/viewtopic.php?id=56830 [1].

So far I've been able to make the Ethernet port work (see attached patch
http://pastebin.com/aZTgZtzB [2]) *but* I need to specify the port speed
ther as 100 Mbps FD. If I don't, the driver is not loaded.

Any ideas on how to proceed?

Thanks!

Roger

[1] https://forum.openwrt.org/viewtopic.php?id=56830
[2] http://pastebin.com/aZTgZtzB
From 56e0fd19d8976e11fd4bd1a0b0e8d962cedf4d4c Mon Sep 17 00:00:00 2001
From: Roger Pueyo Centelles roger.pu...@guifi.net
Date: Wed, 15 Apr 2015 11:19:28 +0200
Subject: [PATCH] [RFC] [ar71xx] Add support for Ubiquiti Rocket M5 XW

---
 target/linux/ar71xx/base-files/etc/diag.sh |  2 +-
 .../ar71xx/base-files/etc/uci-defaults/01_leds |  1 +
 .../ar71xx/base-files/etc/uci-defaults/02_network  |  1 +
 target/linux/ar71xx/base-files/lib/ar71xx.sh   |  3 ++
 .../ar71xx/base-files/lib/upgrade/platform.sh  |  1 +
 .../linux/ar71xx/files/arch/mips/ath79/mach-ubnt.c |  1 +
 target/linux/ar71xx/image/Makefile |  3 +-
 .../610-MIPS-ath79-openwrt-machines.patch  |  3 +-
 ...3-MIPS-ath79-add-ubnt-rocket-m-xw-support.patch | 56 ++
 9 files changed, 68 insertions(+), 3 deletions(-)
 create mode 100644 target/linux/ar71xx/patches-3.18/903-MIPS-ath79-add-ubnt-rocket-m-xw-support.patch

diff --git a/target/linux/ar71xx/base-files/etc/diag.sh b/target/linux/ar71xx/base-files/etc/diag.sh
index 52a73ee..f4f5190 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -34,7 +34,7 @@ get_status_led() {
 	aw-nr580)
 		status_led=aw-nr580:green:ready
 		;;
-	bullet-m | rocket-m | nano-m | nanostation-m | nanostation-m-xw | loco-m-xw)
+	bullet-m | rocket-m | rocket-m-xw | nano-m | nanostation-m | nanostation-m-xw | loco-m-xw)
 		status_led=ubnt:green:link4
 		;;
 	bxu2000n-2-a1)
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
index 787523a..0a9a285 100644
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
@@ -38,6 +38,7 @@ ap113)
 bullet-m | \
 nanostation-m | \
 rocket-m | \
+rocket-m-xw | \
 nanostation-m-xw | \
 loco-m-xw)
 	ucidef_set_led_rssi rssilow RSSILOW ubnt:red:link1 wlan0 1 100 0 13
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
index 9789834..af7930a 100644
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
@@ -318,6 +318,7 @@ rb-912uag-2hpnd |\
 rb-912uag-5hpnd |\
 rb-sxt2n |\
 rb-sxt5n |\
+rocket-m-xw |\
 tl-mr10u |\
 tl-mr11u |\
 tl-mr12u |\
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index b3dbcf5..c6aa81e 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -621,6 +621,9 @@ ar71xx_board_detect() {
 	*Rocket M)
 		name=rocket-m
 		;;
+	*Rocket M XW)
+		name=rocket-m-xw
+		;;
 	*RouterStation)
 		name=routerstation
 		;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 0cbee1d..d349133 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -224,6 +224,7 @@ platform_check_image() {
 	loco-m-xw | \
 	nanostation-m | \
 	rocket-m | \
+	rocket-m-xw | \
 	nanostation-m-xw | \
 	rw2458n | \
 	wndap360 | \
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt.c
index e49ac23..a7bb7e7 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt.c
@@ -10,6 +10,7 @@
  *  by the Free Software Foundation.
  */

+#include linux/platform_data/phy-at803x.h
 #include asm/mach-ath79/ath79.h

 #include dev-eth.h
diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile
index 8766756..b35bd56 100644
--- a/target/linux/ar71xx/image/Makefile
+++ b/target/linux/ar71xx/image/Makefile
@@ -1523,6 +1523,7 @@ $(eval $(call SingleProfile,UBNTXM,64kraw,UBNTUNIFI,ubnt-unifi,UBNT-UF,ttyS0,115
 $(eval $(call SingleProfile,UBNTXM,64kraw,UBNTUNIFIOUTDOOR,ubnt-unifi-outdoor,UBNT-U20,ttyS0,115200,XM,BZ,ar7240))
 $(eval $(call SingleProfile,UBNTXM,64kraw,UBNTNANOMXW,ubnt-nano-m-xw,UBNT-NM-XW,ttyS0,115200,XM,XW,ar934x))
 $(eval $(call SingleProfile,UBNTXM,64kraw,UBNTLOCOXW,ubnt-loco-m-xw,UBNT-LOCO-XW,ttyS0,115200,XM,XW,ar934x

Re: [OpenWrt-Devel] lantiq v3.18

[Roger Pueyo Centelles]

Hi John,

I tested Linux 3.18.7 on three different lantiq boards (ARV4518PW,
ARV7518PW, ARV7159RW22). Here are the results:

*ARV4518PW*
Boot: Yes (Linux OpenWrt 3.18.7 #1 Sun Feb 22 09:51:57 CET 2015 mips
GNU/Linux)
Ethernet: Yes
Switch: Yes
Wireless: Probably yes¹²
ADSL: Not tested, but interface is shown
USB: Yes
Sysupgrade: Yes


*ARV7518PW*
Boot: Yes (Linux OpenWrt 3.18.7 #1 Sun Feb 22 10:38:15 CET 2015 mips
GNU/Linux)
Ethernet: Yes
Switch: Yes
Wireless: Yes
ADSL:
USB: Yes
Sysupgrade: Yes


*ARV7519RW22*
Boot: No (kernel panic, see ³ and attached dmesg)
Works with 14.07 image.


== 1 ==
[   16.116000] PCI: Enabling device :00:0e.0 ( - 0002)
[   16.12] ath5k :00:0e.0: registered as 'phy0'
[   16.344000] random: nonblocking pool is initialized
[   17.192000] ath5k: phy0: unable to init EEPROM
[   17.196000] ath5k: probe of :00:0e.0 failed with error -5

== 2 ==
mtd6 partition (boardconfig) was blank (0xFF), probably because of an
accidental erase in the past :(

== 3 ==
[0.904000] 8021q: 802.1Q VLAN Support v1.8
[0.908000] UBIFS error (pid 1): ubifs_mount: cannot open ubi0:rootfs,
error -19
[0.916000] VFS: Cannot open root device (null) or unknown-block(0,0):
error -6
[0.924000] Please append a correct root= boot option; here are the
available partitions:
[0.932000] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
[0.932000] ---[ end Kernel panic - not syncing: VFS: Unable to mount
root fs on unknown-block(0,0)
[   33.092000] random: nonblocking pool is initialized


By the way, there are no binary images in snapshots for any of the three
devices.

Roger


2015-02-09 13:30 GMT+01:00 John Crispin blo...@openwrt.org:

 Hi,

 i bumped the lantiq support to v3.18 and tested it on 6 different
 boards. I have not tested vdsl support due to lack of a vdsl line.
 could someone please do so.

 @antii: can you rebase/resnd the dwc2 series ? it does not apply to
 the v3.18 patches

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

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

Re: [OpenWrt-Devel] lantiq v3.18

[Roger Pueyo Centelles]

Sure.

U-Boot 2013.10-openwrt5-00014-g0b78b5c-dirty (Mar 11 2014 - 22:56:27) arv7519rw

Board: Lantiq ARV7519RW VRX200 Family Board
SoC:   Lantiq VRX288 v1.1
CPU:   500 MHz
IO:250 MHz
BUS:   250 MHz
BOOT:  NOR
DRAM:  128 MiB
Flash: 32 MiB
In:serial
Out:   serial
Err:   serial
Net:   ltq-eth
Hit any key to stop autoboot:  0
## Booting kernel from Legacy Image at b008 ...
   Image Name:   MIPS OpenWrt Linux-3.18.7
   Created:  2015-02-22  11:56:23 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:1546993 Bytes = 1.5 MiB
   Load Address: 80002000
   Entry Point:  80002000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel ...

[0.00] Linux version 3.18.7 (lordroger@xeon) (gcc version
4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 r44507) ) #1 Sun Feb 22 12:56:14
CET 2015
[0.00] SoC: VR9 rev 1.1
[0.00] bootconsole [early0] enabled
[0.00] CPU0 revision is: 00019555 (MIPS 34Kc)
[0.00] MIPS: machine is ARV7519RW22 - Astoria Networks ARV7519RW22-A-LT
[0.00] Determined physical RAM map:
[0.00]  memory: 0800 @  (usable)
[0.00] Initrd not found or empty - disabling initrd
[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 32kB, 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: console=ttyLTQ0,115200 init=/etc/preinit
[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=00044751
[0.00] Readback ErrCtl register=00044751
[0.00] Memory: 125044K/131072K available (3312K kernel code,
147K rwdata, 932K rodata, 196K init, 205K bss, 6028K reserved)
[0.00] NR_IRQS:256
[0.00] CPU Clock: 500MHz
[0.00] Calibrating delay loop... 332.54 BogoMIPS (lpj=665088)
[0.032000] pid_max: default: 32768 minimum: 301
[0.036000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.04] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.044000] pinctrl core: initialized pinctrl subsystem
[0.048000] NET: Registered protocol family 16
[0.056000] pinctrl-xway 1e100b10.pinmux: Init done
[0.06] dma-xway 1e104100.dma: Init done - hw rev: 7, ports: 7,
channels: 28
[0.064000] dcdc-xrx200 1f106a00.dcdc: Core Voltage : 1016 mV
[0.088000] usbcore: registered new interface driver usbfs
[0.092000] usbcore: registered new interface driver hub
[0.096000] usbcore: registered new device driver usb
[0.10] Switched to clocksource MIPS
[0.104000] NET: Registered protocol family 2
[0.108000] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[0.116000] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[0.124000] TCP: Hash tables configured (established 1024 bind 1024)
[0.128000] TCP: reno registered
[0.132000] UDP hash table entries: 256 (order: 0, 4096 bytes)
[0.136000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[0.144000] NET: Registered protocol family 1
[0.148000] gptu: totally 6 16-bit timers/counters
[0.152000] gptu: misc_register on minor 63
[0.156000] gptu: succeeded to request irq 126
[0.164000] gptu: succeeded to request irq 127
[0.168000] gptu: succeeded to request irq 128
[0.172000] gptu: succeeded to request irq 129
[0.176000] gptu: succeeded to request irq 130
[0.18] gptu: succeeded to request irq 131
[0.184000] phy-xrx200 gphy-xrx200: requesting lantiq/vr9_phy22f_a1x.bin
[0.192000] phy-xrx200 gphy-xrx200: booting GPHY0 firmware at 790
[0.20] phy-xrx200 gphy-xrx200: booting GPHY1 firmware at 790
[0.308000] futex hash table entries: 256 (order: -1, 3072 bytes)
[0.316000] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[0.32] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME)
(CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[0.332000] msgmni has been set to 244
[0.336000] io scheduler noop registered
[0.34] io scheduler deadline registered (default)
[0.344000] 1e100c00.serial: ttyLTQ0 at MMIO 0x1e100c00 (irq = 112,
base_baud = 0) is a lantiq,asc
[0.352000] console [ttyLTQ0] enabled
[0.352000] console [ttyLTQ0] enabled
[0.36] bootconsole [early0] disabled
[0.36] bootconsole [early0] disabled
[0.368000] lantiq nor flash device: 0200 at 

[OpenWrt-Devel] [PATCH] ar71xx: add mc-mac1200r to do_load_ath10k_board_bin()

[Roger Pueyo Centelles]

This patch adds the mc-mac1200r target to do_load_ath10k_board_bin() in
target/linux/ar71xx/base-files/lib/preinit/81_load_ath10k_board_bin to load the
ath10k radio MAC address from the EEPROM in MERCURY MAC1200R devices

Signed-off-by: Roger Pueyo Centelles roger.pu...@guifi.net
---
 .../ar71xx/base-files/lib/preinit/81_load_ath10k_board_bin| 11 +++
 1 file changed, 11 insertions(+)

diff --git 
a/target/linux/ar71xx/base-files/lib/preinit/81_load_ath10k_board_bin 
b/target/linux/ar71xx/base-files/lib/preinit/81_load_ath10k_board_bin
index 7190820..9a32dfc 100644
--- a/target/linux/ar71xx/base-files/lib/preinit/81_load_ath10k_board_bin
+++ b/target/linux/ar71xx/base-files/lib/preinit/81_load_ath10k_board_bin
@@ -23,6 +23,17 @@ do_load_ath10k_board_bin() {
dd if=/dev/mtdblock4 \
bs=1 skip=20492 count=2104  
/tmp/ath10k-board.bin
;;
+   mc-mac1200r)
+   local mac
+   mac=$(macaddr_add $(cat /sys/class/net/eth1/address) -1)
+
+   dd if=/dev/mtdblock4 \
+   bs=1 skip=20480 count=6 \
+   of=/tmp/ath10k-board.bin
+   macaddr_2bin $mac  /tmp/ath10k-board.bin
+   dd if=/dev/mtdblock4 \
+   bs=1 skip=20492 count=2104  
/tmp/ath10k-board.bin
+   ;;
r6100)
local mac
mac=$(macaddr_add $(cat /sys/class/net/eth1/address) +2)
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ar71xx: Add support for MERCURY MAC1200R

[Roger Pueyo Centelles]

This patch adds support for MERCURY MAC1200R, a dual band 802.11bgn + 802.11ac
router based on the AR9344, with QCA988x ath10k radio and 5 Fast Ethernet ports

Signed-off-by: Roger Pueyo Centelles roger.pu...@guifi.net
---
 target/linux/ar71xx/base-files/etc/diag.sh |   3 +
 .../ar71xx/base-files/etc/uci-defaults/01_leds |   5 +
 .../ar71xx/base-files/etc/uci-defaults/02_network  |   1 +
 target/linux/ar71xx/base-files/lib/ar71xx.sh   |   6 +
 .../ar71xx/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ar71xx/config-3.14|   1 +
 .../files/arch/mips/ath79/mach-mc-mac1200r.c   | 155 +
 target/linux/ar71xx/generic/profiles/mercury.mk|  17 +++
 target/linux/ar71xx/image/Makefile |   1 +
 .../736-MIPS-ath79-add-MC-MAC1200R-support.patch   |  39 ++
 10 files changed, 229 insertions(+)
 create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-mc-mac1200r.c
 create mode 100644 target/linux/ar71xx/generic/profiles/mercury.mk
 create mode 100644 
target/linux/ar71xx/patches-3.14/736-MIPS-ath79-add-MC-MAC1200R-support.patch

diff --git a/target/linux/ar71xx/base-files/etc/diag.sh 
b/target/linux/ar71xx/base-files/etc/diag.sh
index 03ca864..47d99fa 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -105,6 +105,9 @@ get_status_led() {
ls-sr71)
status_led=ubnt:green:d22
;;
+   mc-mac1200r)
+   status_led=mercury:green:system
+   ;;
mr600)
status_led=mr600:orange:power
;;
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds 
b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
index 61d0314..69e8daa 100644
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
@@ -171,6 +171,11 @@ hornet-ub)
ucidef_set_led_usbdev usb USB alfa:blue:usb 1-1
;;
 
+mc-mac1200r)
+   ucidef_set_led_wlan wlan2g WLAN2G mercury:green:wlan2g phy1tpt
+   ucidef_set_led_wlan wlan5g WLAN5G mercury:green:wlan5g phy0tpt
+   ;;
+
 mr600)
ucidef_set_led_wlan wlan58 WLAN58 mr600:green:wlan58 phy0tpt
;;
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network 
b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
index 144fd28..706cb7f 100644
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
@@ -367,6 +367,7 @@ dir-615-e1 |\
 dir-615-e4 |\
 hiwifi-hc6361 |\
 ja76pf |\
+mc-mac1200r|\
 mynet-n600 |\
 oolite |\
 qihoo-c301 |\
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index b5224ae..99e4467 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -97,6 +97,9 @@ tplink_board_detect() {
015300*)
model=EasyLink EL-MINI
;;
+   12*)
+   model=MERCURY MAC1200R
+   ;;
3C0001*)
model=OOLITE
;;
@@ -435,6 +438,9 @@ ar71xx_board_detect() {
*LS-SR71)
name=ls-sr71
;;
+   *MAC1200R)
+   name=mc-mac1200r
+   ;;
*MR600v2)
name=mr600v2
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 576ce56..d2a7d8e 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -297,6 +297,7 @@ platform_check_image() {
el-m150 | \
el-mini | \
gl-inet | \
+   mc-mac1200r | \
oolite | \
smart-300 | \
tl-mr10u | \
diff --git a/target/linux/ar71xx/config-3.14 b/target/linux/ar71xx/config-3.14
index 82b2d13..b78d4d2 100644
--- a/target/linux/ar71xx/config-3.14
+++ b/target/linux/ar71xx/config-3.14
@@ -64,6 +64,7 @@ CONFIG_ATH79_MACH_HIWIFI_HC6361=y
 CONFIG_ATH79_MACH_HORNET_UB=y
 CONFIG_ATH79_MACH_JA76PF=y
 CONFIG_ATH79_MACH_JWAP003=y
+CONFIG_ATH79_MACH_MC_MAC1200R=y
 CONFIG_ATH79_MACH_MR600=y
 CONFIG_ATH79_MACH_MR900=y
 CONFIG_ATH79_MACH_MYNET_N600=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mc-mac1200r.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-mc-mac1200r.c
new file mode 100644
index 000..70051cf
--- /dev/null
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mc-mac1200r.c
@@ -0,0 +1,155 @@
+/*
+ *  MERCURY MAC1200R board support
+ *
+ *  Copyright (C) 2012 Gabor Juhos juh...@openwrt.org
+ *  Copyright (C) 2013 Gui Iribarren g...@altermundi.net
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License version 2 as published
+ *  by the Free Software

Re: [OpenWrt-Devel] [PATCH] ar71xx: Add support for MERCURY MAC1200R

[Roger Pueyo Centelles]

Fine. Resending... :)

2015-02-08 16:21 GMT+01:00 郭传鈜 gch981...@gmail.com:

 Ah…Someone added an LED trigger for ath10k serveral days ago…So phy0tpt is
 able to use now:D
 2015年2月8日 下午10:25于 roger.pu...@guifi.net写道：

 From: Roger Pueyo Centelles roger.pu...@guifi.net

 This patch adds support for MERCURY MAC1200R, a dual band 802.11bgn +
 802.11ac
 router based on the AR9344, with QCA988x ath10k radio and 5 Fast Ethernet
 ports

 Signed-off-by: Roger Pueyo Centelles roger.pu...@guifi.net
 ---
  target/linux/ar71xx/base-files/etc/diag.sh |   3 +
  .../ar71xx/base-files/etc/uci-defaults/01_leds |   5 +
  .../ar71xx/base-files/etc/uci-defaults/02_network  |   1 +
  target/linux/ar71xx/base-files/lib/ar71xx.sh   |   6 +
  .../ar71xx/base-files/lib/upgrade/platform.sh  |   1 +
  target/linux/ar71xx/config-3.14|   1 +
  .../files/arch/mips/ath79/mach-mc-mac1200r.c   | 155
 +
  target/linux/ar71xx/generic/profiles/mercury.mk|  17 +++
  target/linux/ar71xx/image/Makefile |   1 +
  .../736-MIPS-ath79-add-MC-MAC1200R-support.patch   |  39 ++
  10 files changed, 229 insertions(+)
  create mode 100644
 target/linux/ar71xx/files/arch/mips/ath79/mach-mc-mac1200r.c
  create mode 100644 target/linux/ar71xx/generic/profiles/mercury.mk
  create mode 100644
 target/linux/ar71xx/patches-3.14/736-MIPS-ath79-add-MC-MAC1200R-support.patch

 diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
 b/target/linux/ar71xx/base-files/etc/diag.sh
 index 03ca864..47d99fa 100644
 --- a/target/linux/ar71xx/base-files/etc/diag.sh
 +++ b/target/linux/ar71xx/base-files/etc/diag.sh
 @@ -105,6 +105,9 @@ get_status_led() {
 ls-sr71)
 status_led=ubnt:green:d22
 ;;
 +   mc-mac1200r)
 +   status_led=mercury:green:system
 +   ;;
 mr600)
 status_led=mr600:orange:power
 ;;
 diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
 b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
 index 61d0314..4d7a4a3 100644
 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
 +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
 @@ -171,6 +171,11 @@ hornet-ub)
 ucidef_set_led_usbdev usb USB alfa:blue:usb 1-1
 ;;

 +mc-mac1200r)
 +   ucidef_set_led_wlan wlan2g WLAN2G mercury:green:wlan2g
 phy1tpt
 +   ucidef_set_led_netdev wlan5g WLAN5G mercury:green:wlan5g
 wlan0
 +   ;;
 +
  mr600)
 ucidef_set_led_wlan wlan58 WLAN58 mr600:green:wlan58
 phy0tpt
 ;;
 diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 index 144fd28..706cb7f 100644
 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
 @@ -367,6 +367,7 @@ dir-615-e1 |\
  dir-615-e4 |\
  hiwifi-hc6361 |\
  ja76pf |\
 +mc-mac1200r|\
  mynet-n600 |\
  oolite |\
  qihoo-c301 |\
 diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
 b/target/linux/ar71xx/base-files/lib/ar71xx.sh
 index b5224ae..99e4467 100755
 --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
 +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
 @@ -97,6 +97,9 @@ tplink_board_detect() {
 015300*)
 model=EasyLink EL-MINI
 ;;
 +   12*)
 +   model=MERCURY MAC1200R
 +   ;;
 3C0001*)
 model=OOLITE
 ;;
 @@ -435,6 +438,9 @@ ar71xx_board_detect() {
 *LS-SR71)
 name=ls-sr71
 ;;
 +   *MAC1200R)
 +   name=mc-mac1200r
 +   ;;
 *MR600v2)
 name=mr600v2
 ;;
 diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 index 576ce56..d2a7d8e 100755
 --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
 @@ -297,6 +297,7 @@ platform_check_image() {
 el-m150 | \
 el-mini | \
 gl-inet | \
 +   mc-mac1200r | \
 oolite | \
 smart-300 | \
 tl-mr10u | \
 diff --git a/target/linux/ar71xx/config-3.14
 b/target/linux/ar71xx/config-3.14
 index 82b2d13..b78d4d2 100644
 --- a/target/linux/ar71xx/config-3.14
 +++ b/target/linux/ar71xx/config-3.14
 @@ -64,6 +64,7 @@ CONFIG_ATH79_MACH_HIWIFI_HC6361=y
  CONFIG_ATH79_MACH_HORNET_UB=y
  CONFIG_ATH79_MACH_JA76PF=y
  CONFIG_ATH79_MACH_JWAP003=y
 +CONFIG_ATH79_MACH_MC_MAC1200R=y
  CONFIG_ATH79_MACH_MR600=y
  CONFIG_ATH79_MACH_MR900=y
  CONFIG_ATH79_MACH_MYNET_N600=y
 diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mc-mac1200r.c
 b/target/linux/ar71xx/files/arch/mips/ath79/mach-mc-mac1200r.c
 new file mode 100644
 index 000..70051cf
 --- /dev/null
 +++ b/target/linux/ar71xx/files/arch

Re: [OpenWrt-Devel] [PATCH] ramips:Fix mt7612 support for Xiaomi Mini.

[Roger Pueyo Centelles]

Hi,

I added some prints to the eeprom.c file and saw that in function:

static int mt76_get_of_eeprom(struct mt76_dev *dev, int len)
{
int ret = -ENOENT;
#ifdef CONFIG_OF
struct device_node *np = dev-dev-of_node;
struct mtd_info *mtd;
const __be32 *list;
const char *part;
phandle phandle;
int offset = 0;
int size;
size_t retlen;

dev_printk(KERN_INFO, dev-dev, mt76_get_of_eeprom. Step 0 (before
!np));

if (!np)
return -ENOENT;

dev_printk(KERN_INFO, dev-dev, mt76_get_of_eeprom. Step 0 (after
!np));
[...]

if does not go further than (   if (!np)   ).

Any ideas?



2015-02-04 23:13 GMT+01:00 John Crispin blo...@openwrt.org:



 On 04/02/2015 22:11, Roger Pueyo Centelles wrote:
  root@OpenWrt:/# hexdump -C /dev/mtd2
    20 76 05 01 64 09 80 01  66 5d ff ff ff ff ff ff  |
  v..d...f]..|
  0010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
  ||
  0020  ff ff ff ff ff ff ff ff  64 09 80 01 66 5c 00 d0
  |d...f\..|
  0030  59 60 00 04 22 0c 04 04  ff ff 15 01 55 77 a8 aa
  |Y`.Uw..|
  0040  8c 88 ff ff 0d 00 00 00  00 00 00 00 00 00 ff ff
  ||
  0050  ff ff 10 10 10 10 10 10  11 11 11 11 11 11 12 12
  ||
  0060  12 12 12 12 12 12 13 13  13 14 14 14 15 15 80 ff
  ||
  0070  ff ff 80 ff ff ff 00 f4  ff ff ff ff ff ff ff ff
  ||
  0080  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
  ||
  *
  00d0  1e 00 ff ff ff ff ff ff  ff ff ff ff ff ff 08 08
  ||
  00e0  06 06 04 00 06 06 04 00  06 06 04 00 06 06 04 00
  ||
  00f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
  ||
  *
  8000  62 76 00 00 64 09 80 01  66 5e 62 76 c3 14 00 00

  ^^ that is the mac at 0x8004





  |bv..d...f^bv|
  8010  00 00 62 76 c3 14 00 00  00 00 ff ff ff ff ff ff
  |..bv|
  8020  ff ff 37 d8 9d 00 60 7f  fd 9b ff ff ff ff ff ff
  |..7...`.|
  8030  ff ff ff ff 22 ff 00 20  ff ff 9b 01 00 00 00 00  |..
  |
  8040  00 00 ff df 00 82 00 00  00 81 00 00 00 00 e0 01
  ||
  8050  00 00 00 00 00 00 84 0a  1a 00 00 00 83 0b 1a 00
  ||
  8060  00 00 7a 06 22 82 82 7a  06 22 82 82 78 08 22 82
  |..z...z...x..|
  8070  82 7e 02 22 82 82 76 16  22 82 82 75 1c 22 82 82
  |.~...v...u...|
  8080  79 0a 22 82 82 79 0a 22  82 82 7b 06 22 82 82 77
  |y...y...{...w|
  8090  14 22 82 82 7e 05 22 82  82 79 11 22 82 82 00 1b
  |...~...y.|
  80a0  c3 c3 c3 c3 00 00 c4 c4  c2 82 c4 c4 c2 82 00 00
  ||
  80b0  00 00 c4 c4 c2 00 00 00  00 00 c2 c2 82 82 86 00
  ||
  80c0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
  ||
  *
  80f0  ff ff ff ff ff ff ff ff  22 ff ff ff ff ff ff ff
  |...|
  8100  0f ca 74 c5 e8 07 30 3d  01 b0 08 26 00 0e 04 15
  |..t...0=...|
  8110  00 8a 00 40 00 00 00 08  00 9d 08 00 12 c0 00 00
  |...@|
  8120  08 20 04 2a 90 00 00 24  01 04 54 08 d0 a0 28 20  |.
  .*...$..T...( |
  8130  ff ff ff ff ff ff ff 08  ff ff ff ff ff ff 00 00
  ||
  8140  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
  ||
  *
  81e0  c0 81 82 c3 04 45 46 07  08 09 ff ff ff ff ff ff
  |.EF.|
  81f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
  ||
  *
  0001
 
  The MACs are there, at 0x4, 0x28 and 0x8004.
 
  2015-02-04 20:29 GMT+01:00 John Crispin blo...@openwrt.org
  mailto:blo...@openwrt.org:
 
 
 
  On 04/02/2015 20:18, Roger Pueyo Centelles wrote:
   Hi,
  
   I tried with 0x8004 and I also got a random IP address. Actually,
   I changed this block in in eeprom.c (line 571) [1]:
 
  can you do a hexdump -C /dev/mtd2 and paste the output please ?
 
 

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

Re: [OpenWrt-Devel] [PATCH] ramips:Fix mt7612 support for Xiaomi Mini.

[Roger Pueyo Centelles]

It works! I'm sending the patch right now! :)

2015-02-06 14:06 GMT+01:00 郭传鈜 gch981...@gmail.com:

 Sorry I forget another thing.
 It should be :
   pcie-bridge {
 mt76@0,0 {

 instead of:
  pcie0 {
 mt76@0,0 {

 I'll send another patch later

 2015-02-06 20:22 GMT+08:00 Roger Pueyo Centelles 
 rogerpu...@rogerpueyo.com:

 Hi,

 I added some prints to the eeprom.c file and saw that in function:

 static int mt76_get_of_eeprom(struct mt76_dev *dev, int len)
 {
 int ret = -ENOENT;
 #ifdef CONFIG_OF
 struct device_node *np = dev-dev-of_node;
 struct mtd_info *mtd;
 const __be32 *list;
 const char *part;
 phandle phandle;
 int offset = 0;
 int size;
 size_t retlen;

 dev_printk(KERN_INFO, dev-dev, mt76_get_of_eeprom. Step 0 (before
 !np));

 if (!np)
 return -ENOENT;

 dev_printk(KERN_INFO, dev-dev, mt76_get_of_eeprom. Step 0 (after
 !np));
 [...]

 if does not go further than (   if (!np)   ).

 Any ideas?



 2015-02-04 23:13 GMT+01:00 John Crispin blo...@openwrt.org:



 On 04/02/2015 22:11, Roger Pueyo Centelles wrote:
  root@OpenWrt:/# hexdump -C /dev/mtd2
    20 76 05 01 64 09 80 01  66 5d ff ff ff ff ff ff  |
  v..d...f]..|
  0010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
  ||
  0020  ff ff ff ff ff ff ff ff  64 09 80 01 66 5c 00 d0
  |d...f\..|
  0030  59 60 00 04 22 0c 04 04  ff ff 15 01 55 77 a8 aa
  |Y`.Uw..|
  0040  8c 88 ff ff 0d 00 00 00  00 00 00 00 00 00 ff ff
  ||
  0050  ff ff 10 10 10 10 10 10  11 11 11 11 11 11 12 12
  ||
  0060  12 12 12 12 12 12 13 13  13 14 14 14 15 15 80 ff
  ||
  0070  ff ff 80 ff ff ff 00 f4  ff ff ff ff ff ff ff ff
  ||
  0080  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
  ||
  *
  00d0  1e 00 ff ff ff ff ff ff  ff ff ff ff ff ff 08 08
  ||
  00e0  06 06 04 00 06 06 04 00  06 06 04 00 06 06 04 00
  ||
  00f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
  ||
  *
  8000  62 76 00 00 64 09 80 01  66 5e 62 76 c3 14 00 00

  ^^ that is the mac at 0x8004





  |bv..d...f^bv|
  8010  00 00 62 76 c3 14 00 00  00 00 ff ff ff ff ff ff
  |..bv|
  8020  ff ff 37 d8 9d 00 60 7f  fd 9b ff ff ff ff ff ff
  |..7...`.|
  8030  ff ff ff ff 22 ff 00 20  ff ff 9b 01 00 00 00 00  |..
  |
  8040  00 00 ff df 00 82 00 00  00 81 00 00 00 00 e0 01
  ||
  8050  00 00 00 00 00 00 84 0a  1a 00 00 00 83 0b 1a 00
  ||
  8060  00 00 7a 06 22 82 82 7a  06 22 82 82 78 08 22 82
  |..z...z...x..|
  8070  82 7e 02 22 82 82 76 16  22 82 82 75 1c 22 82 82
  |.~...v...u...|
  8080  79 0a 22 82 82 79 0a 22  82 82 7b 06 22 82 82 77
  |y...y...{...w|
  8090  14 22 82 82 7e 05 22 82  82 79 11 22 82 82 00 1b
  |...~...y.|
  80a0  c3 c3 c3 c3 00 00 c4 c4  c2 82 c4 c4 c2 82 00 00
  ||
  80b0  00 00 c4 c4 c2 00 00 00  00 00 c2 c2 82 82 86 00
  ||
  80c0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
  ||
  *
  80f0  ff ff ff ff ff ff ff ff  22 ff ff ff ff ff ff ff
  |...|
  8100  0f ca 74 c5 e8 07 30 3d  01 b0 08 26 00 0e 04 15
  |..t...0=...|
  8110  00 8a 00 40 00 00 00 08  00 9d 08 00 12 c0 00 00
  |...@|
  8120  08 20 04 2a 90 00 00 24  01 04 54 08 d0 a0 28 20  |.
  .*...$..T...( |
  8130  ff ff ff ff ff ff ff 08  ff ff ff ff ff ff 00 00
  ||
  8140  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
  ||
  *
  81e0  c0 81 82 c3 04 45 46 07  08 09 ff ff ff ff ff ff
  |.EF.|
  81f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
  ||
  *
  0001
 
  The MACs are there, at 0x4, 0x28 and 0x8004.
 
  2015-02-04 20:29 GMT+01:00 John Crispin blo...@openwrt.org
  mailto:blo...@openwrt.org:
 
 
 
  On 04/02/2015 20:18, Roger Pueyo Centelles wrote:
   Hi,
  
   I tried with 0x8004 and I also got a random IP address. Actually,
   I changed this block in in eeprom.c (line 571) [1]:
 
  can you do a hexdump -C /dev/mtd2 and paste the output please ?
 
 




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


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

Re: [OpenWrt-Devel] [PATCH] ramips:Fix mt7612 support for Xiaomi Mini.

[Roger Pueyo Centelles]

Hi,



2015-02-04 12:44 GMT+01:00 Chuanhong Guo gch981...@gmail.com:

 From: 郭传鈜 gch981...@gmail.com

 2ghz should be disabled on this router.


You're right. This should be patched.


 And I think 'mediatek,mtd-eeprom' should be defined asfactory 32768
 instead of factory 0x8000 according to WHR-1166D.dts
 Actually I didn't have this router.But I think this is the reason that the
 MT7612E radio always gets a random MAC address on this router.


Both definitions are the same, since 0x8000 hex == 32768 dec.



 BTW,Roger,could you please test if this patch can fix the MAC address
 problem you told in your mail?


I tried both, with equal results.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ramips:Fix mt7612 support for Xiaomi Mini.

[Roger Pueyo Centelles]

Hi,

I tried with 0x8004 and I also got a random IP address. Actually, I changed
this block in in eeprom.c (line 571) [1]:

if (!is_valid_ether_addr(dev-macaddr)) {
eth_random_addr(dev-macaddr);
dev_printk(KERN_INFO, dev-dev,
Invalid MAC address, using random address %pM\n,
dev-macaddr);
}

to:

if (!is_valid_ether_addr(dev-macaddr)) {
dev_printk(KERN_INFO, dev-dev,
Invalid MAC address %pM\n,
dev-macaddr);
eth_random_addr(dev-macaddr);
dev_printk(KERN_INFO, dev-dev,
Using random address %pM\n,
dev-macaddr);
}

and I see this message:

[   15.00] ASIC revision: 76120044
[   15.00] mt76pci :01:00.0: Invalid MAC address ff:ff:ff:ff:ff:ff
[   15.00] mt76pci :01:00.0: Using random address ca:a8:87:d8:65:45
[   15.32] ROM patch already applied
[   15.33] Firmware Version: 0.0.00
[   15.33] Build: 1
[   15.33] Build Time: 201406241830
[   15.36] Firmware running!
[   15.37] pci device driver attached


[1] https://github.com/openwrt/mt76/blob/master/eeprom.c

2015-02-04 17:56 GMT+01:00 John Crispin blo...@openwrt.org:



 On 04/02/2015 17:08, Roger Pueyo Centelles wrote:
  Hi,
 
 
 
  2015-02-04 12:44 GMT+01:00 Chuanhong Guo gch981...@gmail.com
  mailto:gch981...@gmail.com:
 
  From: 郭传鈜 gch981...@gmail.com mailto:gch981...@gmail.com
 
  2ghz should be disabled on this router.
 
 
  You're right. This should be patched.
 
 
  And I think 'mediatek,mtd-eeprom' should be defined asfactory
  32768 instead of factory 0x8000 according to WHR-1166D.dts
  Actually I didn't have this router.But I think this is the reason
  that the MT7612E radio always gets a random MAC address on this
 router.
 
 
  Both definitions are the same, since 0x8000 hex == 32768 dec.
 

 try 0x8004 as 0x8000 holds the chip id and right after that is where the
 mac is located




 
 
  BTW,Roger,could you please test if this patch can fix the MAC
  address problem you told in your mail?
 
 
  I tried both, with equal results.
 
 
 
 
  ___
  openwrt-devel mailing list
  openwrt-devel@lists.openwrt.org
  https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
 
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] [PATCH] ramips:Fix mt7612 support for Xiaomi Mini.

[Roger Pueyo Centelles]

root@OpenWrt:/# hexdump -C /dev/mtd2
  20 76 05 01 64 09 80 01  66 5d ff ff ff ff ff ff  |
v..d...f]..|
0010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
||
0020  ff ff ff ff ff ff ff ff  64 09 80 01 66 5c 00 d0
|d...f\..|
0030  59 60 00 04 22 0c 04 04  ff ff 15 01 55 77 a8 aa
|Y`.Uw..|
0040  8c 88 ff ff 0d 00 00 00  00 00 00 00 00 00 ff ff
||
0050  ff ff 10 10 10 10 10 10  11 11 11 11 11 11 12 12
||
0060  12 12 12 12 12 12 13 13  13 14 14 14 15 15 80 ff
||
0070  ff ff 80 ff ff ff 00 f4  ff ff ff ff ff ff ff ff
||
0080  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
||
*
00d0  1e 00 ff ff ff ff ff ff  ff ff ff ff ff ff 08 08
||
00e0  06 06 04 00 06 06 04 00  06 06 04 00 06 06 04 00
||
00f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
||
*
8000  62 76 00 00 64 09 80 01  66 5e 62 76 c3 14 00 00
|bv..d...f^bv|
8010  00 00 62 76 c3 14 00 00  00 00 ff ff ff ff ff ff
|..bv|
8020  ff ff 37 d8 9d 00 60 7f  fd 9b ff ff ff ff ff ff
|..7...`.|
8030  ff ff ff ff 22 ff 00 20  ff ff 9b 01 00 00 00 00  |..
|
8040  00 00 ff df 00 82 00 00  00 81 00 00 00 00 e0 01
||
8050  00 00 00 00 00 00 84 0a  1a 00 00 00 83 0b 1a 00
||
8060  00 00 7a 06 22 82 82 7a  06 22 82 82 78 08 22 82
|..z...z...x..|
8070  82 7e 02 22 82 82 76 16  22 82 82 75 1c 22 82 82
|.~...v...u...|
8080  79 0a 22 82 82 79 0a 22  82 82 7b 06 22 82 82 77
|y...y...{...w|
8090  14 22 82 82 7e 05 22 82  82 79 11 22 82 82 00 1b
|...~...y.|
80a0  c3 c3 c3 c3 00 00 c4 c4  c2 82 c4 c4 c2 82 00 00
||
80b0  00 00 c4 c4 c2 00 00 00  00 00 c2 c2 82 82 86 00
||
80c0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
||
*
80f0  ff ff ff ff ff ff ff ff  22 ff ff ff ff ff ff ff
|...|
8100  0f ca 74 c5 e8 07 30 3d  01 b0 08 26 00 0e 04 15
|..t...0=...|
8110  00 8a 00 40 00 00 00 08  00 9d 08 00 12 c0 00 00
|...@|
8120  08 20 04 2a 90 00 00 24  01 04 54 08 d0 a0 28 20  |.
.*...$..T...( |
8130  ff ff ff ff ff ff ff 08  ff ff ff ff ff ff 00 00
||
8140  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
||
*
81e0  c0 81 82 c3 04 45 46 07  08 09 ff ff ff ff ff ff
|.EF.|
81f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
||
*
0001

The MACs are there, at 0x4, 0x28 and 0x8004.

2015-02-04 20:29 GMT+01:00 John Crispin blo...@openwrt.org:



 On 04/02/2015 20:18, Roger Pueyo Centelles wrote:
  Hi,
 
  I tried with 0x8004 and I also got a random IP address. Actually,
  I changed this block in in eeprom.c (line 571) [1]:

 can you do a hexdump -C /dev/mtd2 and paste the output please ?

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

Re: [OpenWrt-Devel] [PATCH] ramips:Fix mt7612 support for Xiaomi Mini.

[Roger Pueyo Centelles]

Yes, the MAC is where expected. I've tried unloading and reloading the
mt76pci module; the second line of the log passed unnoticed for me before.

root@OpenWrt:/# rmmod mt76pci  modprobe mt76pci  dmesg
[...]
[   73.62] pci device driver detached
[   73.63] mt76pci :01:00.0: no of_node; not parsing pinctrl DT
[   73.63] ASIC revision: 76120044
[   73.64] mt76pci :01:00.0: Invalid MAC address ff:ff:ff:ff:ff:ff
[   73.64] mt76pci :01:00.0: Using random address f6:27:92:58:3a:fd
[   73.68] ROM patch already applied
[   73.68] Firmware Version: 0.0.00
[   73.68] Build: 1
[   73.68] Build Time: 201406241830
[   73.71] Firmware running!
[   73.72] ieee80211 phy2: Selected rate control algorithm 'minstrel_ht'
[   73.74] pci device driver attached

Does no of_node have something to do with the issue?



 ||
  00f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
  ||
  *
  8000  62 76 00 00 64 09 80 01  66 5e 62 76 c3 14 00 00

  ^^ that is the mac at 0x8004





  |bv..d...f^bv|
  8010  00 00 62 76 c3 14 00 00  00 00 ff ff ff ff ff ff
  |..bv|

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

Re: [OpenWrt-Devel] [ramips] Help supporting Xiaomi MiWiFi Mini (.dts file)

[Roger Pueyo Centelles]

Hi,

Nice, leds and button are working. I see what I was missing! Thanks :)

Setting mtd-mac-address = factory 0x4 makes eth0 and wlan1 have the same
address, but using 0x28 makes them consecutive (MAC and MAC+1). Doesn't it
make more sense? The mt76pci radio still is getting a random MAC, though.

The dts in the patch above extends the firmware partition further,
overlapping with the last three small partitions of the original firmware.
Maybe it'd be interesting to keep them, in case anybody wants to flash the
factory firmware back?

Regards,

Roger


2015-01-29 0:47 GMT+01:00 郭传鈜 gch981...@gmail.com:

 Sorry I haven't read your mail correctly.I pointed to the ethernet MAC
 address.

 2015-01-29 7:42 GMT+08:00, 郭传鈜 gch981...@gmail.com:
  Someone have posted a good patch for that device:
  http://www.right.com.cn/forum/thread-157588-1-1.html
  The dts above works fine.
  After applying the patch above,you need to edit the following:
reset {
label = reset;
gpios = gpio1 6 0;
linux,code = 0x198;
};
  change 0x198 to 0x100
  and add the mt76 section in
pcie@1014 {
status = okay;
};
 
 
  BTW ,the mac address is defined here:
ethernet@1010 {
pinctrl-names = default;
pinctrl-0 = ephy_pins;
mtd-mac-address = factory 0x4;   --
ralink,port-map = w;
};
 
  2015-01-29 7:29 GMT+08:00, Roger Pueyo Centelles open...@rogerpueyo.com
 :
  Hi,
 
  Some days ago I received a Xiaomi MiWiFi Mini and I've managed to run
  OpenWrt on it [1] (i.e. trunk OpenWrt, not the very modified stuff the
  vendor provides). I started with this initial patch [2] and I got the
  firmware running, but a couple of things are missing. I need some help
  with
  the .dts file (attached). The current status is:
 
  Working: Ethernet, switch, SoC 802.11gbn radio, USB, TTL and sysupgrade
 
  Partially working: MT7612E 802.11ac
 
  Not working: LEDs and button
 
  The problem with the 802.11ac radio is that I can not read the MAC from
  the
  flash. I always get this message at boot time (with different MACs, of
  course):
 
  [   14.56] mt76pci :01:00.0: Invalid MAC address, using random
  address 96:a3:a5:fa:a9:2b
 
  So far I've tried this:
 
  pcie0 {
  mt76@0,0 {
  reg = 0x 0 0 0 0;
  device_type = pci;
  mediatek,mtd-eeprom = factory 0x8000;
  };
  };
 
  and also factory 0x but the result is the same. I would say the
  location is correct, because I see three consecutive MAC addresses in
 the
  factory partition:
 
  0x0004: 64:09:80:01:66:5D
  0x0028: 64:09:80:01:66:5C
  0x8004: 64:09:80:01:66:5E
 
  that correspond respectively to SoC_radio, Ethernet and pcie_radio. The
  question is, what is the way to make the mt76 driver use the MAC address
  written in the flash?
 
  Then, regarding the LEDs, I have tried enabling gpio chips 0, 1, 2 and
 3,
  exporting all the gpio numbers, setting the direction to out in all of
  them and switching the values between 0, 1 and 255, but I can not
 control
  any of the three leds (which are always on). The same problem for the
  reset
  button, I can not find it anywhere. What else should I try?
 
  Thank you very much!
 
  Roger
 
  [1] http://wiki.openwrt.org/toh/xiaomi/mini
  [2]
 
 https://github.com/rssnsj/openwrt-xiaomi-mini/blob/master/patches/01-xiaomi-mini.patch
 
 

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

Re: [OpenWrt-Devel] [PATCH] [ar71xx] Add support for MERCURY MAC1200R

[Roger Pueyo Centelles]

Hi,

@Hartmut
Ok, now I see. Thanks!

@郭传鈜

Acoording to mach-archer-c7.c ,I think we should use ath79_register_pci();
 here and use /lib/preinit/81_load_ath10k_board_bin to load calibration
 data for ath10k.


So, I understand I have to remove this line from
target/linux/ar71xx/files/arch/mips/ath79/mach-mc-mac1200r.c

ap91_pci_init(art + MAC1200R_PCIE_CALDATA_OFFSET, tmpmac);

Then, the MACs in my router end in:
- eth0=47
- eth1=49
- wlan1=4A

so it makes sense to have wlan0 ending in 48 (i.e. eth1 minus 1). In
target/linux/ar71xx/base-files/lib/preinit/81_load_ath10k_board_bin (art
partition is mtd4):

dd if=/dev/mtdblock4 \
bs=1 skip=20492 count=2104 
/tmp/ath10k-board.bin
;;
mc-mac1200r)
local mac
mac=$(macaddr_add $(cat
/sys/class/net/eth1/address) -1)

dd if=/dev/mtdblock4 \
bs=1 skip=20480 count=6 \
of=/tmp/ath10k-board.bin
macaddr_2bin $mac  /tmp/ath10k-board.bin
dd if=/dev/mtdblock4 \
bs=1 skip=20492 count=2104 
/tmp/ath10k-board.bin
;;
r6100)
local mac
mac=$(macaddr_add $(cat
/sys/class/net/eth1/address) +2)

dd if=/dev/mtdblock2 \

 +$(eval $(call
 SingleProfile,TPLINK-LZMA,64kraw,MAC1200R,mc-mac1200r,MC-MAC1200R,ttyS0,115200,0x1201,1,8Mlzma))
 The factory image is broken since TP-LINK started to use a new firmware
 format with RSA signature in China.This should be introduced in the TOH
 wiki I think:)


Besides adding this to the wiki, what should I change so that the factory
firmware is not generated?

Thanks!

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

Re: [OpenWrt-Devel] [PATCH] [ar71xx] Add support for MERCURY MAC1200R

[Roger Pueyo Centelles]

Hi,

Thank you both for your comments.

@郭传鈜:

 +   ucidef_set_led_wlan wlan2g WLAN2G mercury:green:wlan2g
phy1tpt
 I think the following line is incorrect:
 +   ucidef_set_led_wlan wlan5g WLAN5G mercury:green:wlan5g
phy0tpt
 There is no LED trigger called 'phy0tpt' so I think we should use netdev
trigger like this:
 ucidef_set_led_netdev wlan5g WLAN5G mercury:green:wlan5g wlan0

Ok!


 +static struct gpio_keys_button mac1200r_gpio_keys[] __initdata = {
 +   {
 +   .desc   = WPS button,
 +   .type   = EV_KEY,
 +   .code   = KEY_WPS_BUTTON,
 +   .debounce_interval = MAC1200R_KEYS_DEBOUNCE_INTERVAL,
 +   .gpio   = MAC1200R_GPIO_BTN_WPS,
 +   .active_low = 1,
 +   },
 +};
 Although the key is called WPS/RESET , I think a reset button is more
important than a WPS button.That's just my personal opinion :)

I think you are right.


 +   ap91_pci_init(art + MAC1200R_PCIE_CALDATA_OFFSET, tmpmac);
 What? I think this function is only able to load CALDATA for ath9k
devices.Maybe I'm wrong:)

The router has two radios, one ath9k and one ath10k. Isn't it needed for
the ath9k calibration data? Or this radio is already covered by
ath79_register_wmac(art + MAC1200R_WMAC_CALDATA_OFFSET, tmpmac); ...?


 +$(eval $(call
SingleProfile,TPLINK-LZMA,64kraw,MAC1200R,mc-mac1200r,MC-MAC1200R,ttyS0,115200,0x1201,1,8Mlzma))
The factory image is broken since TP-LINK started to use a new firmware
format with RSA signature in China.This should be introduced in the TOH
wiki I think:)

Done!



@John:

Sorry. Do you mean a description for the patch? I am not aware of what SoB
means.


Thanks!

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

Re: [OpenWrt-Devel] [PATCH] [ar71xx] Add support for MERCURY MAC1200R

[Roger Pueyo Centelles]

Hi,

Please check http://wiki.openwrt.org/toh/mercury/mac1200r

Regards,

Roger

2015-01-12 0:21 GMT+01:00 Bruno Randolf b...@einfach.org:

 On 01/11/2015 09:25 PM, Gioacchino Mazzurco wrote:
  The device has two radios:
   - 802.11abgn AR9344 SoC, ath9k, working OK
   - 802.11ac QCA988x, ath10k, working in AP and STA modes

 Interesting device. Can you post more specs, or add to the TOH wiki?

 Thanks,
 bruno


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

Re: [OpenWrt-Devel] [PATCH] [ar71xx] Add support for MERCURY MAC1200R

[Roger Pueyo Centelles]

No adhoc nor 802.11s with the current ath10k firmware. Actually, that's
what I want it for. It's a pity the driver is not fully open source.

I've tried with firmware 999.999.0.x (
http://wireless.kernel.org/en/users/Drivers/ath10k/firmware) but it the
wireless interface is not operational and I get a bunch of kernel errors.

I agree, it doesn't make much sense to put a 10/100 switch, but it must be
cheaper than a Gb one.

Cheers,

2015-01-11 22:25 GMT+01:00 Gioacchino Mazzurco g...@eigenlab.org:

 On Sunday, January 11, 2015 09:30:34 PM Roger Pueyo Centelles wrote:
  Apparently it does :)

 Cool!


  The device has two radios:
   - 802.11abgn AR9344 SoC, ath9k, working OK
   - 802.11ac QCA988x, ath10k, working in AP and STA modes

 Doesn't support adhoc nor 802.11s with the 802.11ac :( , does it?


  Ethernet ports are 10/100 :(

 It make no sense :(
 Why did they do such a stupid design?
 Moreover they advertise it as 1200Mbis lan -_-

 Thanks!!

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

[OpenWrt-Devel] [PATCH] ramips: add support for Nexx WT1520

[Roger Pueyo Centelles]

This patch adds support for Nexx WT1520 devices.

Signed-off-by: Roger Pueyo Centelles open...@rogerpueyo.com
---
diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds
b/target/linux/ramips/base-files/etc/board.d/01_leds
index 01e2363..1806ff2 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -112,6 +112,9 @@ case $board in
 hlk-rm04)
 set_wifi_led rt2800pci-phy0::radio
 ;;
+nexx-wt1520)
+set_wifi_led rt2800pci-phy0::radio
+;;
 all0239-3g|\
 hw550-3g)
 set_usb_led hw550-3g:green:usb
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index e027b3b..765d398 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -103,6 +103,7 @@ ramips_setup_interfaces()
 dir-320-b1 | \
 dir-615-h1 | \
 hlk-rm04 | \
+nexx-wt1520 | \
 mzk-w300nh2 | \
 mzk-750dhp)
 ucidef_set_interfaces_lan_wan eth0.1 eth0.2
diff --git a/target/linux/ramips/base-files/etc/diag.sh
b/target/linux/ramips/base-files/etc/diag.sh
index 9ad7ccb..472da4b 100755
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -63,6 +63,9 @@ get_status_led() {
 hlk-rm04)
 status_led=hlk-rm04:red:power
 ;;
+nexx-wt1520)
+status_led=nexx-wt1520:white:power
+;;
 all0239-3g|\
 hw550-3g)
 status_led=hw550-3g:green:status
diff --git a/target/linux/ramips/base-files/lib/ramips.sh
b/target/linux/ramips/base-files/lib/ramips.sh
index bb42ace..0a09225 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -157,6 +157,9 @@ ramips_board_detect() {
 *HILINK HLK-RM04)
 name=hlk-rm04
 ;;
+*Nexx WT1520)
+name=nexx-wt1520
+;;
 *HAME MPR-A1)
  name=mpr-a1
  ;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 407c218..8ff2da6 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -52,6 +52,7 @@ platform_check_image() {
 hw550-3g | \
 hg255d | \
 hlk-rm04 | \
+nexx-wt1520 | \
 ip2202 | \
 m3 | \
 m4 | \
diff --git a/target/linux/ramips/dts/NEXXWT1520.dts
b/target/linux/ramips/dts/NEXXWT1520.dts
new file mode 100644
index 000..c89bea1
--- /dev/null
+++ b/target/linux/ramips/dts/NEXXWT1520.dts
@@ -0,0 +1,108 @@
+/dts-v1/;
+
+/include/ rt5350.dtsi
+
+/ {
+compatible = NEXXWT1520, ralink,rt5350-soc;
+model = Nexx WT1520;
+
+memory@0 {
+device_type = memory;
+reg = 0x0 0x200;
+};
+
+chosen {
+bootargs = console=ttyS1,57600;
+};
+
+palmbus@1000 {
+uart@500 {
+status = okay;
+};
+
+spi@b00 {
+status = okay;
+m25p80@0 {
+#address-cells = 1;
+#size-cells = 1;
+compatible = w25q32;
+reg = 0 0;
+linux,modalias = m25p80, s25fl064k;
+spi-max-frequency = 1000;
+
+partition@0 {
+label = u-boot;
+reg = 0x0 0x3;
+read-only;
+};
+
+partition@3 {
+label = u-boot-env;
+reg = 0x3 0x1;
+read-only;
+};
+
+factory: partition@4 {
+label = factory;
+reg = 0x4 0x1;
+read-only;
+};
+
+partition@5 {
+label = firmware;
+reg = 0x5 0x3b;
+};
+};
+};
+};
+
+pinctrl {
+state_default: pinctrl0 {
+gpio {
+ralink,group = jtag;
+ralink,function = gpio;
+};
+};
+};
+
+ethernet@1010 {
+mtd-mac-address = factory 0x4;
+};
+
+wmac@1018 {
+ralink,mtd-eeprom = factory 0;
+};
+
+ehci@101c {
+status = okay;
+};
+
+ohci@101c1000 {
+status = okay;
+};
+
+gpio-keys-polled {
+compatible = gpio-keys-polled;
+#address-cells = 1;
+#size-cells = 0;
+poll-interval = 20;
+};
+
+gpio-leds {
+compatible = gpio-leds;
+power {
+label = nexx-wt1520:white:power;
+gpios = gpio0 0 1;
+};
+};
+
+gpio_export {
+compatible = gpio-export;
+#size-cells = 0;
+usb-mode {
+gpio-export,name