Re: [VOTE] New member proposal: Robimarko (Robert Marko)
I know I don't have a vote, but he helped me personally port the Mikrotik hAP AC2 ( IPQ40xx based ) platform to OpenWRT and was a huge help in unravelling this platform. If I could +1, I would!! Having him on the team and adding IPQ60xx support would be amazing! There are several platforms I'd immediately start helping port if IPQ60xx and IPQ50xx were merged upstream!! Awesome work Robimarko!! On Tue, Jan 30, 2024 at 11:16 AM Christian Marangi (Ansuel) wrote: > > Robert is active in OpenWrt since 2017 and with some recent stats, he > has more than 310 commits merged in OpenWrt. > He also have uncounted Reviewed-by tag on various PR and merged commits > and generally helps in everything related to IPQ (ipq806x, ipq40xx and > ipq807x) and some mvebu targets. > > He did the conversion of ipq40xx target to DSA and made possible the > introduction of the ipq807x target by sorting all the QSDK downstream > patch and pushing them upstream. > > With his help, also the ipq60xx is very close on getting merged and > actually used permitting support of even more device for OpenWrt. > > Also he is almost always reachable on IRC openwrt-devel and never had > a problem in coordinating and collaborating with him. > > I think Robert is a good addition to our team and would massively help > me (Ansuel) in maintaining each IPQ target and review all the related > PR on github and patchwork. > I would like to add Robert to the OpenWrt committers team. > > The vote shall be concluded within 14 days. (13/02/2024) > > ___ > 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] ipq40xx: fails to boot with SMP on Mikrotik hAP ac² / RBD52G-5HacD2HnD (WIP)
https://forum.openwrt.org/t/support-for-mikrotik-rb3011uias-rm/4064/412
I've been working on the hAP AC2 port, and haven't tested with SMP yet.
I posted the DTS files I came up with on the RB3011 thread as we were all
working on Mikrotik IPQ40XX boards.
I'm stuck on decompressing the WiFi radio calibration data , I can't seem
to figure out how to get the LZO / RLE portion to work.
I know exactly where the LZO / RLE data is as well.
If you want, I'll try to enable SMP and see if my board boots.
If you have any insight on WiFi, please let me know.
I'd like to help where I can.
On Mon, Jul 29, 2019 at 4:10 PM Baptiste Jonglez <
bapti...@bitsofnetworks.org> wrote:
> On 29-07-19, Hauke Mehrtens wrote:
> > On 7/29/19 11:25 AM, Baptiste Jonglez wrote:
> > > Is there something obviously wrong in the DTS? As far as I know, other
> > > ipq40xx devices don't have an issue with SMP.
> >
> > Did you try to revert this commit:
> >
> https://github.com/mmaker/openwrt/commit/481615d2f5e4bb053af805dccb901050e1e7a4ed
> >
> > The vendor dts file uses these 3 blocks, I do not know if they are
> > loaded to these regions by some boot loader or later by some driver. If
> > they are loaded there by the boot loader we should probably not use this
> > memory in Linux and let it run there.
>
> Yes, this commit is just a recent attempt to fix a warning during boot.
> The upstream DTS (qcom-ipq4019.dtsi) already reserves a memory region,
> exactly for the reasons you mention:
> https://patchwork.kernel.org/patch/10347459/
>
> This reserved region in the dtsi is overlapping with the one in the DTS,
> and there was a warning during boot ("OVERLAP DETECTED" below). The
> commit did fix the warning, but did not change anything about the initial
> problem with SMP.
>
> > I attached the vendor.dts file we extracted from the flash of the board.
>
> Thanks, could you spot anything interesting in it? It looks very verbose.
>
> Baptiste
>
> > > PS: here is the failing bootlog, getting stuck after "Testing write
> buffer coherency":
> > >
> > > [0.00] Booting Linux on physical CPU 0x0
> > > [0.00] Linux version 4.19.57 (bjonglez@gcc14) (gcc version
> 7.4.0 (OpenWrt GCC 7.4.0 r10506-a0c97101d6)) #0 SMP Mon Jul 29 08:51:07 2019
> > > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7),
> cr=10c5387d
> > > [0.00] CPU: div instructions available: patching division code
> > > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> > > [0.00] OF: fdt: Machine model: Mikrotik RouterBOARD
> RBD52G-5HacD2HnD (hAP ac²)
> > > [0.00] bootconsole [earlycon0] enabled
> > > [0.00] Memory policy: Data cache writealloc
> > > [0.00] OF: reserved mem: OVERLAP DETECTED!
> > > [0.00] rsvd2@87B0 (0x87b0--0x8800) overlaps with
> smem@87e0 (0x87e0--0x87e8)
> > > [0.00] random: get_random_bytes called from
> start_kernel+0x7c/0x438 with crng_init=0
> > > [0.00] percpu: Embedded 15 pages/cpu s29964 r8192 d23284 u61440
> > > [0.00] Built 1 zonelists, mobility grouping on. Total pages:
> 60864
> > > [0.00] Kernel command line: earlyprintk
> > > [0.00] Dentry cache hash table entries: 32768 (order: 5,
> 131072 bytes)
> > > [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536
> bytes)
> > > [0.00] Memory: 232420K/245760K available (4720K kernel code,
> 168K rwdata, 1288K rodata, 3072K init, 231K bss, 13340K reserved, 0K
> cma-reserved, 0K highmem)
> > > [0.00] Virtual kernel memory layout:
> > > [0.00] vector : 0x - 0x1000 ( 4 kB)
> > > [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB)
> > > [0.00] vmalloc : 0xd080 - 0xff80 ( 752 MB)
> > > [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB)
> > > [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB)
> > > [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB)
> > > [0.00] .text : 0x(ptrval) - 0x(ptrval) (5713 kB)
> > > [0.00] .init : 0x(ptrval) - 0x(ptrval) (3072 kB)
> > > [0.00] .data : 0x(ptrval) - 0x(ptrval) ( 168 kB)
> > > [0.00].bss : 0x(ptrval) - 0x(ptrval) ( 232 kB)
> > > [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4,
> Nodes=1
> > > [0.00] rcu: Hierarchical RCU implementation.
> > > [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> > > [0.00] arch_timer: cp15 timer(s) running at 48.00MHz (virt).
> > > [0.00] clocksource: arch_sys_counter: mask: 0xff
> max_cycles: 0xb11fd3bfb, max_idle_ns: 440795203732 ns
> > > [0.07] sched_clock: 56 bits at 48MHz, resolution 20ns, wraps
> every 4398046511096ns
> > > [0.007985] Switching to timer-based delay loop, resolution 20ns
> > > [0.014242] Calibrating delay loop (skipped), value calculated
> using timer frequenc
Re: [OpenWrt-Devel] How to initialize multiple phy radios
Scanning appears to work ( iw dev wlan1 scan ) , As soon as I try to use hostapd to run as an AP I get: [20475.14] ath10k_pci :00:00.0: firmware crashed! (uuid b826d45e-e51f-4beb-a489-6b7a4d5c6f76) [20475.15] ath10k_pci :00:00.0: qca988x hw2.0 (0x4100016d, 0x004000ff sub :) fw 10.2.3.31.7-1 fwapi 5 bdapi 1 htt-ver 2.1 wmi-op 5 htt-op 2 cal file max-sta 1p [20475.17] ath10k_pci :00:00.0: debug 1 debugfs 1 tracing 0 dfs 0 testmode 1 [20475.18] ath10k_pci :00:00.0: firmware register dump: [20475.18] ath10k_pci :00:00.0: [00]: 0x4100016D 0x 0x004146C8 0x004146C8 [20475.19] ath10k_pci :00:00.0: [04]: 0x004146C8 0x00060530 0x001F 0x00955A00 [20475.20] ath10k_pci :00:00.0: [08]: 0x0040AE04 0x0040 0x0007 0x [20475.21] ath10k_pci :00:00.0: [12]: 0x0002 0x 0x00958360 0x0095836B [20475.21] ath10k_pci :00:00.0: [16]: 0x809ACDE0 0x0040AD94 0x0040AE04 0x0040 [20475.22] ath10k_pci :00:00.0: [20]: 0x 0x 0x 0x0040E830 [20475.23] ath10k_pci :00:00.0: [24]: 0x809AC4E2 0x0040ADC4 0x0001 0x0040AE04 [20475.24] ath10k_pci :00:00.0: [28]: 0x004133E0 0x0001 0x0040AE08 0x [20475.25] ath10k_pci :00:00.0: [32]: 0x0007 0x 0x 0x004133C8 [20475.26] ath10k_pci :00:00.0: [36]: 0x809B9C49 0x0040ADE4 0x00411568 0x0041158C [20475.26] ath10k_pci :00:00.0: [40]: 0x0001 0x 0x00955A00 0x0040E840 [20475.27] ath10k_pci :00:00.0: [44]: 0x809B944C 0x0040AE04 0x0001 0x [20475.28] ath10k_pci :00:00.0: [48]: 0x0040AE04 0x0001 0x004133C8 0x004117AC [20475.29] ath10k_pci :00:00.0: [52]: 0x809B9263 0x0040AEA4 0x0041ECF8 0x00411BC8 [20475.30] ath10k_pci :00:00.0: [56]: 0x004133C8 0x0040AE34 0x00411F08 0x00411F08 [20475.41] ieee80211 phy1: Hardware restart was requested -- Davey On Mon, Apr 25, 2016 at 1:01 PM, Christian Lamparter wrote: > Hello, > > On Monday, April 25, 2016 10:53:41 AM David Hutchison wrote: >> So with some modifications to pci.c, hw.h and core.c I was able to get >> the radio initialized! :) > > Hey, that's nice! Can you make and post a patch for that? > I'm sure if it's just a matter of adding the new pci and chip > ids to the tables. You could just go ahead and post it, so it > will be picked up. > >> pci.c: added QCA9887_DEVICE_ID, modified ath10k_pci_id_table and >> ath10k_pci_supp_chips >> core.c: Duplicated QCA988X entry in ath10k_hw_params_list and passed >> 0x4100016d as the ID ( left everything else the same ) >> hw.h: added definitions for QCA9887 >> >> I found >> "https://github.com/kvalo/ath10k-firmware/blob/master/QCA9887/firmware-5.bin_10.2.3.31.7-1"; >> on your github and replaced >> /lib/firmware/ath10k/QCA988X/hw2.0/firmware-5.bin on my board. >> hotplug.d then loaded QCA9887 firmware on next boot. >> >> Of course my approach was very much a hack. If there is anything I can >> contribute to creating a patch for ath10k, please let me know. I would >> love to help! >> >> dmesg >> [ 18.92] ath10k_pci :00:00.0: pci irq legacy interrupts 0 >> irq_mode 0 reset_mode 0 >> [ 19.03] rev_id QCA9887 >> [ 19.03] dev_id 0050 QCA9887 >> [ 20.46] ath10k_pci :00:00.0: qca988x hw2.0 (0x4100016d, >> 0x004000ff sub :) fw 10.2.3.31.7-1 fwapi 5 bdapi 1 htt-ver 2.1 >> wmi-op 5 htt-op 2 cal file max-sta 1p >> [ 20.48] ath10k_pci :00:00.0: debug 1 debugfs 1 tracing 0 >> dfs 0 testmode 1 >> > ... > > Does the device work? Can you scan for networks, connect to networks > and create networks? That would be good to know. > > Regards, > Christian > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] How to initialize multiple phy radios
detection)
DFS state: usable (for 39 sec)
DFS CAC time: 6 ms
* 5560 MHz [112] (23.0 dBm) (no IR, radar detection)
DFS state: usable (for 39 sec)
DFS CAC time: 6 ms
* 5580 MHz [116] (23.0 dBm) (no IR, radar detection)
DFS state: usable (for 39 sec)
DFS CAC time: 6 ms
* 5600 MHz [120] (23.0 dBm) (no IR, radar detection)
DFS state: usable (for 39 sec)
DFS CAC time: 6 ms
* 5620 MHz [124] (23.0 dBm) (no IR, radar detection)
DFS state: usable (for 39 sec)
DFS CAC time: 6 ms
* 5640 MHz [128] (23.0 dBm) (no IR, radar detection)
DFS state: usable (for 39 sec)
DFS CAC time: 6 ms
* 5660 MHz [132] (23.0 dBm) (no IR, radar detection)
DFS state: usable (for 39 sec)
DFS CAC time: 6 ms
* 5680 MHz [136] (23.0 dBm) (no IR, radar detection)
DFS state: usable (for 39 sec)
DFS CAC time: 6 ms
* 5700 MHz [140] (23.0 dBm) (no IR, radar detection)
DFS state: usable (for 39 sec)
DFS CAC time: 6 ms
* 5720 MHz [144] (23.0 dBm) (radar detection)
DFS state: usable (for 39 sec)
DFS CAC time: 6 ms
* 5745 MHz [149] (30.0 dBm)
* 5765 MHz [153] (30.0 dBm)
* 5785 MHz [157] (30.0 dBm)
* 5805 MHz [161] (30.0 dBm)
* 5825 MHz [165] (30.0 dBm)
valid interface combinations:
* #{ AP, mesh point } <= 8,
total <= 8, #channels <= 1, STA/AP BI must match
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
-- Davey
On Mon, Apr 25, 2016 at 9:21 AM, Valo, Kalle wrote:
> Christian Lamparter writes:
>
>> On Sunday, April 24, 2016 01:16:11 AM David Hutchison wrote:
>>> I spoke too soon:
>>> https://pci-ids.ucw.cz/read/PC/168c/0050
>>>
>>> It is the QCA9887, so it's definitely on the PCIe bus and is being
>>> seen.
>>
>> Does ath10k support the QCA9887? I see no entry for this pci-id (168c:0050)
>> in ath10k's pci table [0] and there's no definition of it in the hardware
>> header either [1]. The chip-id is also not present. I CC'ed ath10k, since
>> this seems to be a new chip that might be easy to add.
>
> Currently ath10k does not support QCA9887.
>
> --
> Kalle Valo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] How to initialize multiple phy radios
I spoke too soon: https://pci-ids.ucw.cz/read/PC/168c/0050 It is the QCA9887, so it's definitely on the PCIe bus and is being seen. -- Davey On Sun, Apr 24, 2016 at 1:13 AM, David Hutchison wrote: > Thank you for the response Christian! > > Here is the PCI noise is in the kernel log from ath79_register_pci(): > > [0.51] PCI host bridge to bus :00 > [0.51] pci_bus :00: root bus resource [mem 0x1000-0x11ff] > [0.52] pci_bus :00: root bus resource [io 0x] > [0.52] pci_bus :00: No busn resource found for root bus, > will use [bus 00-ff] > [0.53] pci :00:00.0: [168c:0050] type 00 class 0x028000 > [0.53] pci :00:00.0: reg 10: [mem 0x1000-0x101f 64bit] > [0.53] pci :00:00.0: reg 30: [mem 0x-0x pref] > [0.53] pci :00:00.0: supports D1 > [0.53] pci :00:00.0: PME# supported from D0 D1 D3hot > [0.53] pci_bus :00: busn_res: [bus 00-ff] end is updated to 00 > [0.53] pci :00:00.0: BAR 0: assigned [mem > 0x1000-0x101f 64bit] > [0.53] pci :00:00.0: BAR 6: assigned [mem > 0x1020-0x1020 pref] > [0.54] pci :00:00.0: using irq 40 for pin 1 > > I compiled lspci in and it reports: > 00:00.0 Class 0280: 168c:0050 > > As far as I know that's just a vendor/product ID, I tried looking it > up to verify that it was indeed the atheros qca988x but couldn't find > anything for certain. > > I verified ath10k is loaded: > ath10k_pci 27629 0 > ath10k_core 247226 1 ath10k_pci > ath18726 4 ath10k_core,ath9k,ath9k_common,ath9k_hw > mac80211 389729 2 ath10k_core,ath9k > cfg80211 217396 5 ath10k_core,ath9k,ath9k_common,ath,mac80211 > compat 19304 7 > ath10k_pci,ath10k_core,ath9k,ath9k_common,ath9k_hw,mac80211,cfg80211 > > -- Davey > > On Fri, Apr 22, 2016 at 4:32 AM, Christian Lamparter > wrote: >> Hello, >> >> On Friday, April 22, 2016 02:03:01 AM David Hutchison wrote: >>> I have been working on a board port and have everything working except >>> for the 2nd radio. This board has a QCA9531 CPU and 2 WiFi Radios: >>> AR9531 and a QCA9887 ( http://routerboard.com/RB952Ui-5ac2nD for more >>> details ). >>> [snip] >>> >>> Anyway, the Mikrotik hAP only has one radio and is 100% working. >>> However the hAP AC Lite has an additional radio ( QCA988X )... I've >>> compiled in ath10k, and added "ath79_register_pci()" but it doesn't >>> find the radio. I've looked at ap91_pci_init() as well as >>> ap94_pci_init() and haven't had any luck. >> >> Does ath79_register_pci actually register the pci bus (there should >> be some noise in the kernel log when it registers the pci bus)? Or >> does it return an error -ENODEV? >> >> This is what it looks like on a Archer C7: (Has a QCA9880) >> [0.129096] ar724x-pci ar724x-pci.0: PCIe link is down >> [0.133988] registering PCI controller with io_map_base unset >> [0.139678] registering PCI controller with io_map_base unset >> [0.586626] PCI host bridge to bus :00 >> [0.590553] pci_bus :00: root bus resource [mem 0x1000-0x11ff] >> [0.597148] pci_bus :00: root bus resource [io 0x] >> [0.602534] pci_bus :00: root bus resource [??? 0x flags 0x0] >> ... >> >> I looked at ath79_register_pci, it is located in /arch/mips/ath79/pci.c. >> On the first look, it doesn't look like your SoC is present there. >> However soc_is_qca953x is just testing soc_is_qca9533. Can you verify >> that this is indeed correct and the function actually calls >> ath79_register_pci_ar724x? >> >>> What is the normal way for initializing a platform with multiple >>> radio's? Of course I don't know the exact wiring with this board, but >>> I believe the QCA988X 802.11ac radio is on a PCI bus of some sort. I'm >>> not entirely sure, but every example I have seen it appears to be. >> Hm, I don't know much about your device. If it's a proper QCA988X mini-pcie >> radio and has the calibration data on a chip on its minipcie board, then >> you don't need to setup anything else. Having select kmod-ath10k >> (which AFAIK includes the firmware as well) is enough. >> >> But if the calibration data for ath10k is part of the routerboard's caldata >> partition, you need to extracted by the userspace. This is currently done >> by a script: >> target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata >> >> So you will need to add your device there with the right extraction >> code. >> >> Regards, >> Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] How to initialize multiple phy radios
Thank you for the response Christian! Here is the PCI noise is in the kernel log from ath79_register_pci(): [0.51] PCI host bridge to bus :00 [0.51] pci_bus :00: root bus resource [mem 0x1000-0x11ff] [0.52] pci_bus :00: root bus resource [io 0x] [0.52] pci_bus :00: No busn resource found for root bus, will use [bus 00-ff] [0.53] pci :00:00.0: [168c:0050] type 00 class 0x028000 [0.53] pci :00:00.0: reg 10: [mem 0x1000-0x101f 64bit] [0.53] pci :00:00.0: reg 30: [mem 0x-0x pref] [0.53] pci :00:00.0: supports D1 [0.53] pci :00:00.0: PME# supported from D0 D1 D3hot [0.53] pci_bus :00: busn_res: [bus 00-ff] end is updated to 00 [0.53] pci :00:00.0: BAR 0: assigned [mem 0x1000-0x101f 64bit] [0.53] pci :00:00.0: BAR 6: assigned [mem 0x1020-0x1020 pref] [0.54] pci :00:00.0: using irq 40 for pin 1 I compiled lspci in and it reports: 00:00.0 Class 0280: 168c:0050 As far as I know that's just a vendor/product ID, I tried looking it up to verify that it was indeed the atheros qca988x but couldn't find anything for certain. I verified ath10k is loaded: ath10k_pci 27629 0 ath10k_core 247226 1 ath10k_pci ath18726 4 ath10k_core,ath9k,ath9k_common,ath9k_hw mac80211 389729 2 ath10k_core,ath9k cfg80211 217396 5 ath10k_core,ath9k,ath9k_common,ath,mac80211 compat 19304 7 ath10k_pci,ath10k_core,ath9k,ath9k_common,ath9k_hw,mac80211,cfg80211 -- Davey On Fri, Apr 22, 2016 at 4:32 AM, Christian Lamparter wrote: > Hello, > > On Friday, April 22, 2016 02:03:01 AM David Hutchison wrote: >> I have been working on a board port and have everything working except >> for the 2nd radio. This board has a QCA9531 CPU and 2 WiFi Radios: >> AR9531 and a QCA9887 ( http://routerboard.com/RB952Ui-5ac2nD for more >> details ). >> [snip] >> >> Anyway, the Mikrotik hAP only has one radio and is 100% working. >> However the hAP AC Lite has an additional radio ( QCA988X )... I've >> compiled in ath10k, and added "ath79_register_pci()" but it doesn't >> find the radio. I've looked at ap91_pci_init() as well as >> ap94_pci_init() and haven't had any luck. > > Does ath79_register_pci actually register the pci bus (there should > be some noise in the kernel log when it registers the pci bus)? Or > does it return an error -ENODEV? > > This is what it looks like on a Archer C7: (Has a QCA9880) > [0.129096] ar724x-pci ar724x-pci.0: PCIe link is down > [0.133988] registering PCI controller with io_map_base unset > [0.139678] registering PCI controller with io_map_base unset > [0.586626] PCI host bridge to bus :00 > [0.590553] pci_bus :00: root bus resource [mem 0x1000-0x11ff] > [0.597148] pci_bus :00: root bus resource [io 0x] > [0.602534] pci_bus :00: root bus resource [??? 0x flags 0x0] > ... > > I looked at ath79_register_pci, it is located in /arch/mips/ath79/pci.c. > On the first look, it doesn't look like your SoC is present there. > However soc_is_qca953x is just testing soc_is_qca9533. Can you verify > that this is indeed correct and the function actually calls > ath79_register_pci_ar724x? > >> What is the normal way for initializing a platform with multiple >> radio's? Of course I don't know the exact wiring with this board, but >> I believe the QCA988X 802.11ac radio is on a PCI bus of some sort. I'm >> not entirely sure, but every example I have seen it appears to be. > Hm, I don't know much about your device. If it's a proper QCA988X mini-pcie > radio and has the calibration data on a chip on its minipcie board, then > you don't need to setup anything else. Having select kmod-ath10k > (which AFAIK includes the firmware as well) is enough. > > But if the calibration data for ath10k is part of the routerboard's caldata > partition, you need to extracted by the userspace. This is currently done > by a script: > target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata > > So you will need to add your device there with the right extraction > code. > > Regards, > Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] How to initialize multiple phy radios
Hello,
I have been working on a board port and have everything working except
for the 2nd radio. This board has a QCA9531 CPU and 2 WiFi Radios:
AR9531 and a QCA9887 ( http://routerboard.com/RB952Ui-5ac2nD for more
details ).
The 2.4GHz radio works great, and I have acquired the correct calibration data:
[ 23.44] ath: EEPROM regdomain: 0x0
[ 23.44] ath: EEPROM indicates default country code should be used
[ 23.44] ath: doing EEPROM country->regdmn map search
[ 23.44] ath: country maps to regdmn code: 0x3a
[ 23.44] ath: Country alpha2 being used: US
[ 23.44] ath: Regpair used: 0x3a
[ 23.45] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[ 23.45] Registered led device: ath9k-phy0
[ 23.46] ieee80211 phy0: Atheros AR9531 Rev:0 mem=0xb810, irq=47
[ 23.63] cfg80211: Regulatory domain changed to country: US
[ 23.63] cfg80211: DFS Master region: FCC
[ 23.64] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp), (dfs_cac_time)
[ 23.65] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz),
(N/A, 3000 mBm), (N/A)
[ 23.65] cfg80211: (517 KHz - 525 KHz @ 8 KHz,
16 KHz AUTO), (N/A, 2300 mBm), (N/A)
[ 23.66] cfg80211: (525 KHz - 533 KHz @ 8 KHz,
16 KHz AUTO), (N/A, 2300 mBm), (0 s)
[ 23.67] cfg80211: (549 KHz - 573 KHz @ 16 KHz),
(N/A, 2300 mBm), (0 s)
[ 23.68] cfg80211: (5735000 KHz - 5835000 KHz @ 8 KHz),
(N/A, 3000 mBm), (N/A)
[ 23.69] cfg80211: (5724 KHz - 6372 KHz @ 216
KHz), (N/A, 4000 mBm), (N/A)
That is being done with the following code snippet:
void __init rbhap_wlan_init(u16 id)
{
char *caldata;
u8 wlan_mac[ETH_ALEN];
caldata = rb_get_ext_wlan_data(id);
if (caldata == NULL) {
pr_err("caldata is NULL\n");
return;
}
ath79_init_mac(wlan_mac, ath79_mac_base, 2);
ath79_register_wmac(caldata + 0x1000, wlan_mac);
kfree(caldata);
}
This particular architecture i'm working on adds kernel support for
the hAP as well as the hAP AC Lite. I'm passing "1" or "0" to
rbhap_wlan_init() based on the board:
flags = rbhap_get_flags(info);
if (flags & RB95X_FLAG_80211AC) {
rbhap_wlan_init(1);
ath79_register_pci();
} else {
rbhap_wlan_init(0);
}
I saw the "get_flags" example from mach-rb91x.c as the "board=" in the
bootloader were the same for both the Mikrotik hAP and Mikrotik hAP AC
Lite.
Anyway, the Mikrotik hAP only has one radio and is 100% working.
However the hAP AC Lite has an additional radio ( QCA988X )... I've
compiled in ath10k, and added "ath79_register_pci()" but it doesn't
find the radio. I've looked at ap91_pci_init() as well as
ap94_pci_init() and haven't had any luck.
What is the normal way for initializing a platform with multiple
radio's? Of course I don't know the exact wiring with this board, but
I believe the QCA988X 802.11ac radio is on a PCI bus of some sort. I'm
not entirely sure, but every example I have seen it appears to be.
Any insight as to what to try, to initialize this 2nd radio would be
much appreciated!
QCA9531 + AR9531 + QCA988x
Thank you!!
-- Davey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][ar71xx] Routerboard 951G Switch Fix
Hello John, Of course this has been over a year since I submitted ( http://patchwork.ozlabs.org/patch/419857/ ); however I remember in one of our e-mail threads that you ( or Felix? ) thought it was possible to pull the correct pll_1000 value from the bootloader? Is that still a possibility? If you could somehow acquire the correct value directly from the boot args; that would seem ideal. -- Davey On Wed, Jan 27, 2016 at 9:27 AM, John Crispin wrote: > > > On 27/01/2016 17:03, Anton Kalmykov wrote: >> >> Hi, 951G owners! >> I have RB951G-2HnD device with AR9344 rev 3. It is configured like that: >> - Balanced 2 WAN ports (mwan3) >> - ipsec LAN-to-LAN >> - OpenVPN server >> - about 30 clients (wi-fi, lan) >> >> My results for different ath79_eth0_pll_data.pll_1000 values: >> >> 0x3e00 - it worked fine with Barrier Breaker, but sometimes (one or >> two times per day) it was restarting suddenly. It was happening after I >> have configured mwan3. >> 0x0600 - it works wonderful with Chaos Calmer. The configuration is > > so the conensus is that 0x0600 is correct ? > > John > > > >> the same. No problem with reboot. So, I would recommend this value. >> unpatched - of course it doesn't work. :-) >> >> If it's useful, please add this information to wiki-page: >> https://wiki.openwrt.org/toh/mikrotik/rb2011uias#tracking_reported_experience_with_suggested_patch_for_the_5_gige_ports >> >> >> -- >> Anton >> ___ >> 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] Ubiquiti UniFI AC Lite
I have one as well torn apart on hooked to serial; I started a port
but couldn't figure out how to get the bootloader to write my image
via tftp to flash. I tricked it by modifying the magic header, so the
tftp portion would happen but then It looked like it ran a ubnt script
within their custom u-boot build; which did some sort of RSA check and
failed.
I ended up using dd on the stock UniFi firmware and just forcing it to
write to the kernel0 partition; Even with boot ${address_of_kernel}; I
would get an error and it would automatically boot into the backup
partition.
I didn't want to brick my board completely; so I left kernel1 in-tact
so I could always have a way to revert it.
Let me know if you find any information; :-) I can't wait to help.
-- Davey
On Thu, Dec 10, 2015 at 10:14 AM, Andrew Margarit | Cucumber WiFI
wrote:
> I'm digging for the same info :)
> Have one near me so can give a hand out with the profile.
>
> Andrew
>
>
> On 10/12/15 17:06, David Hutchison wrote:
>>
>> I would like to know as well,
>>
>> It looks like they made a lot of progress; are patchsets available to
>> build the "openwrt-ar71xx-generic-ubnt-unifiac-squashfs-sysupgrade.bin"
>> ?
>>
>> Any information would be much appreciated.
>>
>> -- Davey
>>
>> On Wed, Dec 9, 2015 at 9:33 AM, Andrew Margarit | Cucumber WiFI
>> wrote:
>>>
>>> Does anyone know who's maintaining this page?
>>>
>>> https://wiki.openwrt.org/toh/ubiquiti/unifiac
>>>
>>> Want to give out a hand with that porting.
>>>
>>> Cheers,
>>> A
>>> ___
>>> 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] Ubiquiti UniFI AC Lite
I would like to know as well, It looks like they made a lot of progress; are patchsets available to build the "openwrt-ar71xx-generic-ubnt-unifiac-squashfs-sysupgrade.bin" ? Any information would be much appreciated. -- Davey On Wed, Dec 9, 2015 at 9:33 AM, Andrew Margarit | Cucumber WiFI wrote: > Does anyone know who's maintaining this page? > > https://wiki.openwrt.org/toh/ubiquiti/unifiac > > Want to give out a hand with that porting. > > Cheers, > A > ___ > 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] UniFi-AC-LR ( or UniFi-AC-LITE )
They must have some sort of protection in there bootloader,
immediately after OpenWRT is put onto the device via TFTP the error
"Application terminated, rc=0x" shows up.
I wonder what it's expecting?
Interestingly enough, there is a 2nd kernel partition ( kernel0 and
kernel1 ) It boots into kernel1 if kernel0 fails.
Receiving file from 192.168.1.25:53844
Received 3539292 bytes
TFTP Transfer Complete.
Bytes transferred = 3539292 (36015c hex)
## Starting application at 0x80200020 ...
Firmware Version: BZ.qca956x.v6.0.0-OpenWrt-r47065
## Application terminated, rc = 0x
## Starting application at 0x80200020 ...
Number of boot partitions = 2
get_mtd_params: name=bs
ubnt_flash_read: addr=8023b480, sa=9ff9, sz=131072
ubnt_get_bootsel: Boot partition selected = 1
Loading Kernel Image @ 8100, size = 7929856
Verifying 'kernel1' parition:OK
## Application terminated, rc = 0x0
## Booting image at 9f80 ...
Image Name: MIPS OpenWrt Linux-3.3.8
Created: 2015-09-12 0:03:12 UTC
Image Type: MIPS Linux Multi-File Image (lzma compressed)
Data Size:6877256 Bytes = 6.6 MB
Load Address: 8006
Entry Point: 8006
Contents:
Image 0: 6877248 Bytes = 6.6 MB
Verifying Checksum at 0x9f800040 ...OK
Uncompressing Multi-File Image ... OK
No initrd
## Transferring control to Linux (at address 8006) ...
## Giving linux memsize in bytes, 134217728
Starting kernel ...
-- Davey
On Tue, Oct 27, 2015 at 4:27 PM, David Hutchison
wrote:
> Thank you,
>
> That indeed helps, I was able to find the header in the UniFi
> Controller ( There is a "dl" directory ). TFTP accepts
> "BZ.qca956x.v6.0.0-OpenWrt-r47065"
> I still haven't had luck getting it to boot yet; definitely getting closer.
>
> -- Davey
>
> On Tue, Oct 27, 2015 at 4:20 PM, Jonathan Bither wrote:
>> Hello Davey,
>>
>> I haven't gotten a chance to mess with one of these yet due to availability,
>> but I placed a copy of the binary image for the AP on my web-server for you.
>> This came from a 4.7.5 install.
>> https://jonbither.com/unifi/firmware/U7PG2/3.4.7.3284/firmware.bin
>>
>> According to the bundles file both the UAP-AC-LITE and the UAP-AC-LR use the
>> same image file.
>> 'cat /usr/lib/unifi/dl/firmware/bundles.json | python -m json.tool'
>> {
>> "U7LR": {
>> "display": "UniFi AP-AC-LR",
>> "path": "U7PG2/3.4.7.3284/firmware.bin",
>> "version": "3.4.7.3284"
>> },
>> "U7LT": {
>> "display": "UniFi AP-AC-Lite",
>> "path": "U7PG2/3.4.7.3284/firmware.bin",
>> "version": "3.4.7.3284"
>> },
>> }
>>
>> Hopefully the header will be similar.
>> `strings /usr/lib/unifi/dl/firmware/U7PG2/3.4.7.3284/firmware.bin | head
>> -n1`
>> UBNTBZ.qca956x.v3.4.7.3284.150911.1650
>>
>>
>> Hope any of this helps.
>> -Jonathan
>>
>>
>>
>> On 10/26/2015 06:16 PM, David Hutchison wrote:
>>>
>>> I just got this board and I am looking to port OpenWRT to it. I have
>>> taken this board apart and can receive serial, however TX doesn't
>>> appear to work ( Maybe there is a GPIO, I need to toggle? ). These two
>>> new UniFi-AC boards have the new QCA953x processor in them ( LITE and
>>> LR ). This is not the Broadcom 48V UniFi that is already supported;
>>> these just came out.
>>>
>>> I was hoping to reach out to the group who have experience building
>>> the image with the proper "MAGIC HEADER". TFTP will not accept the
>>> image and think the image is invalid unless the proper header exists.
>>> With other board ports I have grabbed the original AirOS firmware, and
>>> you could see the header at the top of the .bin. However with UniFi
>>> they don't seem to have the image easily downloadable.
>>>
>>> I am hoping if anyone would have any insight to finding this? Once I
>>> can TFTP an image onto it; I can try making an architecture patch for
>>> it.
>>>
>>> Thanks,
>>> -- Davey
>>> ___
>>> 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] UniFi-AC-LR ( or UniFi-AC-LITE )
Thank you,
That indeed helps, I was able to find the header in the UniFi
Controller ( There is a "dl" directory ). TFTP accepts
"BZ.qca956x.v6.0.0-OpenWrt-r47065"
I still haven't had luck getting it to boot yet; definitely getting closer.
-- Davey
On Tue, Oct 27, 2015 at 4:20 PM, Jonathan Bither wrote:
> Hello Davey,
>
> I haven't gotten a chance to mess with one of these yet due to availability,
> but I placed a copy of the binary image for the AP on my web-server for you.
> This came from a 4.7.5 install.
> https://jonbither.com/unifi/firmware/U7PG2/3.4.7.3284/firmware.bin
>
> According to the bundles file both the UAP-AC-LITE and the UAP-AC-LR use the
> same image file.
> 'cat /usr/lib/unifi/dl/firmware/bundles.json | python -m json.tool'
> {
> "U7LR": {
> "display": "UniFi AP-AC-LR",
> "path": "U7PG2/3.4.7.3284/firmware.bin",
> "version": "3.4.7.3284"
> },
> "U7LT": {
> "display": "UniFi AP-AC-Lite",
> "path": "U7PG2/3.4.7.3284/firmware.bin",
> "version": "3.4.7.3284"
> },
> }
>
> Hopefully the header will be similar.
> `strings /usr/lib/unifi/dl/firmware/U7PG2/3.4.7.3284/firmware.bin | head
> -n1`
> UBNTBZ.qca956x.v3.4.7.3284.150911.1650
>
>
> Hope any of this helps.
> -Jonathan
>
>
>
> On 10/26/2015 06:16 PM, David Hutchison wrote:
>>
>> I just got this board and I am looking to port OpenWRT to it. I have
>> taken this board apart and can receive serial, however TX doesn't
>> appear to work ( Maybe there is a GPIO, I need to toggle? ). These two
>> new UniFi-AC boards have the new QCA953x processor in them ( LITE and
>> LR ). This is not the Broadcom 48V UniFi that is already supported;
>> these just came out.
>>
>> I was hoping to reach out to the group who have experience building
>> the image with the proper "MAGIC HEADER". TFTP will not accept the
>> image and think the image is invalid unless the proper header exists.
>> With other board ports I have grabbed the original AirOS firmware, and
>> you could see the header at the top of the .bin. However with UniFi
>> they don't seem to have the image easily downloadable.
>>
>> I am hoping if anyone would have any insight to finding this? Once I
>> can TFTP an image onto it; I can try making an architecture patch for
>> it.
>>
>> Thanks,
>> -- Davey
>> ___
>> 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] UniFi-AC-LR ( or UniFi-AC-LITE )
I just got this board and I am looking to port OpenWRT to it. I have taken this board apart and can receive serial, however TX doesn't appear to work ( Maybe there is a GPIO, I need to toggle? ). These two new UniFi-AC boards have the new QCA953x processor in them ( LITE and LR ). This is not the Broadcom 48V UniFi that is already supported; these just came out. I was hoping to reach out to the group who have experience building the image with the proper "MAGIC HEADER". TFTP will not accept the image and think the image is invalid unless the proper header exists. With other board ports I have grabbed the original AirOS firmware, and you could see the header at the top of the .bin. However with UniFi they don't seem to have the image easily downloadable. I am hoping if anyone would have any insight to finding this? Once I can TFTP an image onto it; I can try making an architecture patch for it. Thanks, -- Davey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Firmware Upgrade - Mikrotik - ar71xx
I think sysupgrade now works with the rb951ui; however I haven't tested it.
I wrote my own upgrade process before sysupgrade was available for the
rb95x series:
- Create a sysupgrade.tgz; this is the kept files you want (
configurations; scripts; etc. )
tar -czf /tmp/sysupgrade.tgz /etc/dropbear /etc/passwd /etc/group
/etc/rc.local ${upgrade_dirs} &> /dev/null
- Make a new root directory in /tmp ( /tmp/root/* )
mkdir -p /tmp/root/dev /tmp/root/sbin /tmp/root/bin /tmp/root/proc
/tmp/root/tmp /tmp/root/mnt /tmp/root/lib
mkdir -p /tmp/root/etc /tmp/root/root /tmp/root/var/log
/tmp/root/usr/bin /tmp/root/usr/sbin /tmp/root/oldroot
- Copy over sbin/* necessary bins
cd /sbin
cp -rp `ls -A /sbin | grep -vE
"mount.nfs|hotplug2|hotplug-call|udevd|swconfig|uci"` /tmp/root/sbin/.
cd /bin
cp -rp `ls -A /bin | grep -v bash` /tmp/root/bin/.
cd /
cp -p /lib/* /tmp/root/lib/. &> /dev/null
cp -rp /usr/bin/wget /usr/bin/md5sum /usr/bin/killall /usr/bin/awk
/usr/bin/hexdump /usr/bin/bzcat /usr/bin/printf /usr/bin/wc
/usr/bin/passwd /usr/bin/ssh /usr/bin/scp /tmp/root/usr/bin/.
cp -rp /etc/passwd /etc/group /etc/dropbear /etc/inittab /etc/shells
/etc/rc.local /tmp/root/etc/.
- Pivot the root filesystem into the memory
mount -o bind /tmp/root /tmp/root
mount -o move /proc /tmp/root/proc
pivot_root /tmp/root /tmp/root/oldroot
mount -o move /oldroot/dev /dev
mount -o move /oldroot/tmp /tmp
- Now you can write your kernel / rootfs partitions
mkdir -p /mnt/kernel; mount -t yaffs2 /dev/${kernel_mtdblock} /mnt/kernel;
gunzip -c /tmp/OpenWRT.kernel.gz > /mnt/kernel/kernel; # Note, this
is only a .gz because I gzipped it prior to SCP. I have low bandwidth
deployments.. Just put the kernel file in /mnt/kernel/kernel and
ensure executable
chmod +x /mnt/kernel/kernel;
umount /mnt/kernel;
echo 'Kernel Flashed';
umount /oldroot/sys/kernel/debug;
umount /oldroot/sys;
rm -rf /oldroot/*;
ls -la /oldroot;
cd /oldroot;
tar -xzf /tmp/OpenWRT.rootfs;
echo 'Rootfs Flashed';
echo 'Overlay /tmp/sysupgrade.tgz';
tar -xzf /tmp/sysupgrade.tgz;
echo 'Overlay completed!';
sync;
echo 'Upgrade Complete';
reboot;
I of course scripted it. * HOWEVER IF SYSUPGRADE IS CONFIRMED WORKING
WITH THE RB951Ui, USE THAT !!!*
My way is not very well vetted; while I use I have a *very* custom
rb951ui OpenWRT build. I can't emphasis that enough, test sysupgrade
*FIRST!*
-- Davey
On Tue, Oct 20, 2015 at 1:28 AM, Nishant Sharma wrote:
> Hi,
>
> I have around 50 boxes (ar71xx Mikrotik RB951Ui-2HnD) in the field, running
> AA or BB (custom compiled).
>
> I have checked through the documentation, but could not find any way to
> upgrade the firmware.
>
> Is there a way, that I could upgrade them to the newly compiled firmware
> remotely or only option I have is to recall the boxes back and re-flash
> them?
>
> Thanks in advance.
>
> Regards,
> Nishant
> ___
> 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 the UniFi AP Outdoor Plus
You can revert back to UniFi via TFTP, I haven't been able to get the reset button on boot to work for UniFi. I use UART to pull up the boot-loader. Then use "urescue" to tftp the UniFi image back on. -- Davey On Fri, May 22, 2015 at 1:41 PM, Stefan Rompf wrote: > Hi, > >> Updated version is in the attachment. I tried it on a real device, but I >> can't say that the problem was solved, but something is definitely happens. > > related question: After installing OpenWRT on the access point, do you know > whether I can revert using the instructions from: > > https://community.ubnt.com/t5/UniFi-Troubleshooting/UniFi-TFTP-soft-recovery-for-bricked-access-point/ta-p/607605 > > ? > > Stefan > ___ > 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] Designated Driver
+1 On Wed, Apr 8, 2015 at 9:24 AM, Oleg Titov wrote: > +1 > ___ > 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] mbim / Sierra Wireless AirCard 340U
Hello John, One of our customers use the 340U, and the latest firmware revision that fixes Windows 8 support.. broke linux support ( http://mtekk.us/archives/guides/netgear-aircard-340u-linux/ ) We had to downgrade the firmware on the 340u itself. I don't think they have released a firmware fix with both windows 8 support + linux support. ( This has been a couple months, but when we asked they told us to downgrade the firmware ). Our 340u's running the *working* linux support firmware are running great in OpenWRT. I would start there, insure the firmware on the 340u is running a version that has linux support working. Downgrade if necessary. -- Davey On Wed, Apr 1, 2015 at 8:19 AM, John Crispin wrote: > Hi, > > it seems that umbim has problems talking to this device. without > hardware to test on it will be hard to figure out what is wrong. > > does anyone have a spare/unlocked Sierra Wireless AirCard 340U ? > > 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] [PATCH] ar71xx: add support for the UniFi AP Outdoor Plus
Hello, It's probably driven by a GPIO on the radio itself. Possibly monitor /sys/kernel/debug/ieee80211/phy[0-9]/ath9k/regidx and /sys/kernel/debug/ieee80211/phy[0-9]/ath9k/regval. Perhaps someone with a datasheet might be able to tell you which register(s) it *could* be tied to, then take Sergey's strategy and watch changes to those registers. * Just a thought, I could be completely wrong :) * -- Davey On Mon, Mar 16, 2015 at 6:37 PM, Sergey Ryazanov wrote: > Hello Stefan, > > 2015-03-16 23:36 GMT+03:00 Stefan Rompf : >> However, independant of the channel selected the ports are always set to >> 0x00081405 (or 0x00081404 or 0x00081406 depending on the LED setting): >> >> BZ.v3.2.7# /tmp/io -4 -r 0x18040004 >> 18040004: 00081405 >> >> If anyone has ideas where else to look, please share. Meanwhile let's see >> what >> I can do with strace ;-) >> > If they built SPIoverGPIO or I2CoverGPIO or some other serial bus over > GPIO, then you do not see any changes between channel switches. Or > they could use some non GPIO interface to communicate with external > filter (embedded SPI, I2C or even USB or PCI of SoC). > > Possibly, you could see some changes during change. Try check GPIO > pins with oscillograph during channel change. > > Or you could put device in continuous scan (e.g. use STA mode and > enter some not available SSID to put device for infinite AP search) > and then read GPIO register state in circle. That trick does not > reveal actual protocol, but shows GPIO lines in use, if any. > > -- > Sergey > ___ > 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] Initial support for Mikrotik mAP2n and Mikrotik cAP2n
I just got the mAP2n and cAP2n to boot from the flash chip into OpenWRT :-)
I need some assistance generating an official patch. You have to make
some changes to yaffs and I don't know if this is an acceptable
approach. This is however the only way I could get RouterBOOT to find
the kernel.
RouterBOOT seems to require the kernel partition near the bottom of
the flash chip ( or it will get stuck while trying to search for the
kernel ). When using binwalk and looking at RouterOS, Mikrotik has the
bootloader first, rootfs, and the kernel is directly after the
squashfs filesystem. Is there a way to dynamically set a partition to
start where the previous partition ended? I took the approach of
allocating ~6mb at the bottom of the flash for the kernel and the
rootfs is between the bootloader and the kernel. This works, however
the boot process is kind of slow ( Probably because it has to search
the entire 16mb flash chip for the kernel ). If I could raise the
position of the kernel, that may speed things up. The goal would be:
start of spi flash ==> bootloader, rootfs ( squashfs ), kernel,
rootfs_data ( jffs2 ) ==> end of spi flash. I don't know if this would
make it boot faster or not, i figured it would be worth a try.
Everything in the mAP2n seems to work.
The cAP2n is missing the LEDs
First you have to patch yaffs, so it can support a NOR flash chip.
Here are changes I made:
Modifications to yaffs_vfs_glue.c
--- $(kernel)/fs/yaffs2/yaffs_vfs_glue.c
+++ $(kernel)/fs/yaffs2/yaffs_vfs_glue.c
@@ -171,6 +171,7 @@
#include "yaffs_mtdif.h"
#include "yaffs_mtdif1.h"
#include "yaffs_mtdif2.h"
+#include "yaffs_mtdif2_nor.h"
unsigned int yaffs_trace_mask = YAFFS_TRACE_BAD_BLOCKS | YAFFS_TRACE_ALWAYS;
unsigned int yaffs_wr_attempts = YAFFS_WR_ATTEMPTS;
@@ -2913,7 +2914,8 @@
return NULL;
}
/* Check it's NAND */
-if (mtd->type != MTD_NANDFLASH) {
+if (mtd->type != MTD_NANDFLASH && mtd->type != MTD_NORFLASH) {
T(YAFFS_TRACE_ALWAYS,
(TSTR("yaffs: MTD device is not NAND it's type %d\n"),
mtd->type));
@@ -2954,6 +2956,11 @@
yaffs_version = 2;
}
+if (mtd->type == MTD_NORFLASH) {
+yaffs_version = 2;
+}
+
/* Added NCB 26/5/2006 for completeness */
if (yaffs_version == 2 && !options.inband_tags && WRITE_SIZE(mtd) == 512) {
T(YAFFS_TRACE_ALWAYS,
@@ -2963,7 +2970,18 @@
#endif
-if (yaffs_version == 2) {
+if (yaffs_version == 2 && mtd->type == MTD_NORFLASH) {
+/* Check for version 2 style functions */
+if (!mtd->_erase ||
+!mtd->_read ||
+!mtd->_write) {
+T(YAFFS_TRACE_ALWAYS,
+ ("yaffs: MTD device does not support required "
+ "functions\n"));;
+return NULL;
+}
+} else if (yaffs_version == 2) {
/* Check for version 2 style functions */
#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3, 4, 0))
if (!mtd->_erase ||
@@ -3137,7 +3155,26 @@
param->empty_lost_n_found = options.empty_lost_and_found;
/* ... and the functions. */
-if (yaffs_version == 2) {
+if (yaffs_version == 2 && mtd->type == MTD_NORFLASH) {
+param->write_chunk_tags_fn =
+normtd2_WriteChunkWithTagsToNAND;
+param->read_chunk_tags_fn =
+normtd2_ReadChunkWithTagsFromNAND;
+param->bad_block_fn = normtd2_MarkNANDBlockBad;
+param->query_block_fn = normtd2_QueryNANDBlock;
+param->erase_fn = normtd_EraseBlockInNAND;
+param->initialise_flash_fn = normtd_InitialiseNAND;
+
+param->is_yaffs2 = 1;
+param->total_bytes_per_chunk = 1024;
+param->chunks_per_block = mtd->erasesize /
(param->total_bytes_per_chunk + 16);
+nBlocks = (uint32_t) mtd->size / mtd->erasesize;
+yaffs_dev_to_lc(dev)->spareBuffer = YMALLOC(16);
+
+param->start_block = 0;
+param->end_block = nBlocks - 1;
+} else if (yaffs_version == 2) {
param->write_chunk_tags_fn =
nandmtd2_WriteChunkWithTagsToNAND;
param->read_chunk_tags_fn =
@@ -3173,8 +3210,11 @@
param->is_yaffs2 = 0;
}
/* ... and common functions */
-param->erase_fn = nandmtd_EraseBlockInNAND;
-param->initialise_flash_fn = nandmtd_InitialiseNAND;
+if(mtd->type != MTD_NORFLASH) {
+param->erase_fn = nandmtd_EraseBlockInNAND;
+param->initialise_flash_fn = nandmtd_InitialiseNAND;
+}
yaffs_dev_to_lc(dev)->putSuperFunc = yaffs_MTDPutSuper;
added file yaffs_mtdif2_nor.c
--- /dev/null
+++ $(kernel)/fs/yaffs2/yaffs_mtdif2_nor.c
@@ -0,0 +1,172 @@
+#include "yportenv.h"
+#include "yaffs_trace.h"
+
+
+#include "yaffs_mtdif2_nor.h"
+
+#include "linux/mtd/mtd.h"
+#include "linux/types.h"
+#include "linux/time.h"
+
+#include "yaffs_packedtags2.h"
+#include "yaffs_linux.h"
+
+#define NOR_OOB_SIZE 1
Re: [OpenWrt-Devel] Anyone familiar with RouterBoot? Trying to port board.
The problem is there is no yaffs2 filesystem like typical RouterBOARD's, it's all one 16mb SPI flash chip. If it expects kernel, would renaming the .elf file to just "kernel" be sufficient? I suppose I could give that a try. -- Davey On Tue, Jan 27, 2015 at 5:38 PM, Soren Harward wrote: > On Tue, Jan 27, 2015 at 12:56 PM, David Hutchison > wrote: >> The problem is when I write the kernel to flash I cannot for the life >> of me get RouterBOOT to recognize the kernel. > > What is the filename of the kernel on the yaffs2 filesystem on the > kernel MTD partition? AFAIK, RouterBoot expects it to be called > "kernel". Not "vmlinux" or "vmlinuz" or > "openwrt-ar71xx-generic-vmlinux.elf" or anything else. > > -- > Soren Harward ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Anyone familiar with RouterBoot? Trying to port board.
I have everything working on the Mikrotik mAP2n within initramfs.
WLAN, LAN, USB, LEDs, and even the flash chip.
The problem is when I write the kernel to flash I cannot for the life
of me get RouterBOOT to recognize the kernel. My partition layout
looks like this:
static struct mtd_partition rbmap_spi_partitions[] = {
{
.name = "kernel",
.offset = 128 * 1024,
.size = 0x60
},
{
.name = "rootfs",
.offset = 0x62,
.size = MTDPART_SIZ_FULL
},
{
.name = "firmware",
.offset = 128 * 1024,
.size = MTDPART_SIZ_FULL
},
{
.name = "RouterBoot",
.offset = 0,
.size = 128 * 1024,
.mask_flags = MTD_WRITEABLE,
},
};
[3.70] 0x0002-0x0100 : "firmware"
[3.71] 0x0013-0x0100 : "rootfs"
[3.71] mtd: partition "rootfs" set to be root filesystem
[3.72] split_squashfs: no squashfs found in "spi0.0"
[3.72] 0x0002-0x0062 : "kernel"
[3.73] 0x0062-0x0100 : "rootfs"
[3.74] 0x-0x0002 : "RouterBoot"
I know for sure that RouterBoot is 0x2 in size. RouterOS starts at
0x2 and is the only partition, it's size is MTDPART_SIZ_FULL. (
Without trying to get OpenWRT on )
I tried to define a kernel and rootfs partition, but that didn't seem
to work either.
Every other RouterBOARD I have ported too the kernel partition had to
be in YAFFS. However the mAP2n is a SPI flash. The partitions are not
passed by the bootloader, so they have to be defined somehow.
Is there anyone familiar with routerboot that could help point me in
the right direction? I was trying to mtdwrite vmlinux ( I even tried
dd ) to the kernel partition ( which would put it at 0x2, where it
*should* be ).
The files I tried to write were:
openwrt-ar71xx-generic-vmlinux.bin
openwrt-ar71xx-generic-vmlinux.elf
no go, routerboot would output:
---
RouterBOOT backup booter 3.17
RouterBOARD mAP 2n
CPU frequency: 400 MHz
Memory size: 64 MiB
Storage size: 16 MiB
Press any key within 2 seconds to enter setup
loading kernel from nand... kernel not found
trying bootp protocol OK
---
Previous RouterBOARDS would not support compressed kernels, I tried
them anyway as this SPI flash seems new for Mikrotik... Still a no-go.
Here is the kernel cmdline within initramfs:
Kernel command line: bootimage=1 no-uart no-nand parts=1
boot_part_size=16777216 gpio=822077383 HZ=2 mem=64M
kmac=4C:5E:0C:CA:27:0E board=mAP boot=0 mlc=6
I'm not familiar with OpenWRT's image builder, so i'm not sure how I
could create an image for it. I'm not at this point yet, just trying
to get RouterBOOT to execute my kernel.
---
I have UART working but the RX on the board does not seem to see ANY
of my INPUT at the boot-loader level. I can see output, but cannot
provide input... I can't really look at the boot-loader directly :-/
Any ideas?
Here is my mach-rbmap.c thus far:
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include "common.h"
#include "dev-ap9x-pci.h"
#include "dev-eth.h"
#include "dev-spi.h"
#include "dev-gpio-buttons.h"
#include "dev-leds-gpio.h"
#include "dev-m25p80.h"
#include "dev-usb.h"
#include "dev-wmac.h"
#include "machtypes.h"
#include "routerboot.h"
#define RB_ROUTERBOOT_OFFSET0x
#define RB_ROUTERBOOT_SIZE 0xe000
#define RB_HARD_CFG_OFFSET 0xe000
#define RB_HARD_CFG_SIZE0x1000
#define RB_ART_SIZE 0x1
static struct mtd_partition rbmap_spi_partitions[] = {
{
.name = "kernel",
.offset = 128 * 1024,
.size = 0x60
},
{
.name = "rootfs",
.offset = 0x62,
.size = MTDPART_SIZ_FULL
},
{
.name = "firmware",
.offset = 128 * 1024,
.size = MTDPART_SIZ_FULL
},
{
.name = "RouterBoot",
.offset = 0,
.size = 128 * 1024,
.mask_flags = MTD_WRITEABLE,
},
};
static struct flash_platform_data rbmap_spi_flash_data = {
.parts = rbmap_spi_partitions,
.nr_parts = ARRAY_SIZE(rbmap_spi_partitions),
};
static void __init rbmap_wlan_init(void)
{
u8 *hard_cfg = (u8 *) KSEG1ADDR(0x1f00 + RB_HARD_CFG_OFFSET);
u16 tag_len;
u8 *tag;
char *art_buf;
u8 wlan_mac[ETH_ALEN];
int err;
err = routerboot_find_tag(hard_cfg, RB_HARD_CFG_SIZE, RB_ID_WLAN_DATA,
&tag, &tag_len);
if (err) {
pr_err("no calibration data found\n
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for the UniFi AP Outdoor Plus
Does the new kernel / ath9k address the RF Filter on this board? I
came up with an old patch for this board, but whenever I changed the
channel inside OpenWRT the signal would just disappear. The RF Filter
has to be toggled somehow ( I assume it's a GPIO of some sort ). I am
just curious on how it was fixed, or if it's still an issue.
-- Davey
On Mon, Dec 29, 2014 at 8:01 PM, Matthias Schiffer
wrote:
> Signed-off-by: Matthias Schiffer
> ---
> target/linux/ar71xx/base-files/etc/diag.sh | 3 ++
> target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 ++
> .../ar71xx/base-files/lib/upgrade/platform.sh | 2 +
> target/linux/ar71xx/image/Makefile | 3 +-
> .../610-MIPS-ath79-openwrt-machines.patch | 3 +-
> .../patches-3.14/616-MIPS-ath79-ubnt-xw.patch | 61
> +-
> 6 files changed, 72 insertions(+), 3 deletions(-)
>
> diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
> b/target/linux/ar71xx/base-files/etc/diag.sh
> index 06b96a3..30e4aeb 100755
> --- a/target/linux/ar71xx/base-files/etc/diag.sh
> +++ b/target/linux/ar71xx/base-files/etc/diag.sh
> @@ -254,6 +254,9 @@ get_status_led() {
> uap-pro)
> status_led="ubnt:white:dome"
> ;;
> + unifi-outdoor-plus)
> + status_led="ubnt:white:front"
> + ;;
> airgateway)
> status_led="ubnt:white:status"
> ;;
> diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
> b/target/linux/ar71xx/base-files/lib/ar71xx.sh
> index 9b056e9..a12101a 100755
> --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
> +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
> @@ -732,6 +732,9 @@ ar71xx_board_detect() {
> *"UniFiAP Outdoor")
> name="unifi-outdoor"
> ;;
> + *"UniFiAP Outdoor+")
> + name="unifi-outdoor-plus"
> + ;;
> *WP543)
> name="wp543"
> ;;
> diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> index 6dabf4e..2752729 100755
> --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> @@ -368,6 +368,7 @@ platform_check_image() {
> return 1
> ;;
>
> + unifi-outdoor-plus | \
> uap-pro)
> [ "$magic_long" != "19852003" ] && {
> echo "Invalid image type."
> @@ -483,6 +484,7 @@ platform_do_upgrade() {
> om5p)
> platform_do_upgrade_openmesh "$ARGV"
> ;;
> + unifi-outdoor-plus | \
> uap-pro)
> MTD_CONFIG_ARGS="-s 0x18"
> default_do_upgrade "$ARGV"
> diff --git a/target/linux/ar71xx/image/Makefile
> b/target/linux/ar71xx/image/Makefile
> index 18c9637..3eb2f07 100644
> --- a/target/linux/ar71xx/image/Makefile
> +++ b/target/linux/ar71xx/image/Makefile
> @@ -1333,6 +1333,7 @@ $(eval $(call
> SingleProfile,TPLINK-LZMA,64kraw,SMART-300,smart-300,SMART-300,tty
> $(eval $(call
> SingleProfile,TPLINK-LZMA,64kraw,OOLITE,oolite,GS-OOLITE,ttyATH0,115200,0x3C000101,1,16Mlzma))
>
> $(eval $(call
> SingleProfile,UAPPRO,64k,UAPPRO,ubnt-uap-pro,UAP-PRO,ttyS0,115200,BZ,BZ,ar934x))
> +$(eval $(call
> SingleProfile,UAPPRO,64k,UBNTUNIFIOUTDOORPLUS,ubnt-unifi-outdoor-plus,UBNT-UOP,ttyS0,115200,BZ,BZ,ar7240))
>
> $(eval $(call
> SingleProfile,UBDEV,64kraw,UBDEV01,ubdev01,UBNT-UF,ttyS0,115200,XM,XM,ar7240))
>
> @@ -1396,7 +1397,7 @@ $(eval $(call MultiProfile,TLWR941,TLWR941NV2
> TLWR941NV3 TLWR941NV4 TLWR941NV6))
> $(eval $(call MultiProfile,TLWR1043,TLWR1043V1 TLWR1043V2))
> $(eval $(call MultiProfile,TLWDR4300,TLWDR3500V1 TLWDR3600V1 TLWDR4300V1
> TLWDR4300V1IL TLWDR4310V1 MW4530RV1))
> $(eval $(call MultiProfile,TUBE2H,TUBE2H8M TUBE2H16M))
> -$(eval $(call MultiProfile,UBNT,UBNTAIRROUTER UBNTRS UBNTRSPRO UBNTLSSR71
> UBNTBULLETM UBNTROCKETM UBNTNANOM UBNTNANOMXW UBNTLOCOXW UBNTUNIFI
> UBNTUNIFIOUTDOOR UAPPRO UBNTAIRGW))
> +$(eval $(call MultiProfile,UBNT,UBNTAIRROUTER UBNTRS UBNTRSPRO UBNTLSSR71
> UBNTBULLETM UBNTROCKETM UBNTNANOM UBNTNANOMXW UBNTLOCOXW UBNTUNIFI
> UBNTUNIFIOUTDOOR UBNTUNIFIOUTDOORPLUS UAPPRO UBNTAIRGW))
> $(eval $(call MultiProfile,WNDR3700,WNDR3700V1 WNDR3700V2 WNDR3800
> WNDR3800CH WNDRMAC WNDRMACV2))
> $(eval $(call MultiProfile,WNR612V2,REALWNR612V2 N150R))
> $(eval $(call MultiProfile,WP543,WP543_2M WP543_4M WP543_8M WP543_16M))
> diff --git
> a/target/linux/ar71xx/patches-3.14/610-MIPS-ath79-openwrt-machines.patch
> b/target/linux/ar71xx/patches-3.14/610-MIPS-ath79-openwrt-machines.patch
> index 4ce9268..b01c5de 100644
> --- a/target/linux/ar71xx/patches-3.14/610-MIPS-ath79-openwrt-machines.patch
> +++ b/target/linux/ar71xx/patches-3.14/610-MIPS-ath79-openwrt-machines.patch
> @@ -1,6 +1,6 @@
> --- a/arch/mips/ath79/machtypes.h
> +++ b/arc
Re: [OpenWrt-Devel] [PATCH][ar71xx] Mikrotik Routerboard RB2011 switch fix
Hello, Can you try: ath79_eth0_pll_data.pll_1000 = 0x6f000; This is the value I originally found on the 951G, I tried to toggle as many bits as possible and narrow down from there. John Crispin found some documentation and we narrowed it down to 0x3e00 for the 951G. He is actually working on a patch that will grab the correct ath79_eth0_pll_data.pll_1000 value from the bootloader. That way this becomes dynamic. I do not know the progress he has made on it. http://comments.gmane.org/gmane.comp.embedded.openwrt.devel/28589 Here is our original thread, where John posted the relevant datasheet. You can take the same approach we did, and narrow down to find your correct bits. It may also be easier to wait for his patch where he will dynamically set it. Hope this helps, -- Davey On Tue, Dec 23, 2014 at 11:23 AM, Matt Lee wrote: > Hi Chris, > >>This patch is the same as the Routerboard 951G fix, I've built this >>and tested it on my rb-2011uias-2hnd. However we should check that it >>also works on other/older RB2011 routers which did work OK with the >>unpatched code. >> >>diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-rb2011.c >>b/target/linux/ar71xx/files/arch/mips/ath79/mach-rb2011.c >>index b73fae6..951ab94 100644 >>--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-rb2011.c >>+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-rb2011.c >>@@ -270,6 +270,7 @@ static int __init rb2011_setup(u32 flags) >>rb2011_nand_init(); >> >>ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | >>+ AR934X_ETH_CFG_RXD_DELAY | >> AR934X_ETH_CFG_SW_ONLY_MODE); >> >>ath79_register_mdio(1, 0x0); >>@@ -283,7 +284,7 @@ static int __init rb2011_setup(u32 flags) >>ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII; >>ath79_eth0_data.phy_mask = BIT(0); >>ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev; >>- ath79_eth0_pll_data.pll_1000 = 0x0600; >>+ ath79_eth0_pll_data.pll_1000 = 0x3e00; >> >>ath79_register_eth(0); >> >>-- >>Chris Green > This patch is not working correctly for me on the 2011UiAS-2HnD. Many > packets are dropped, and I can see many FCS Errors and RxBadByte. > > root@OpenWrt:/# swconfig dev ag71xx-mdio.0 port 0 show > Port 0: > mib: Port 0 MIB counters > RxBroad : 8 > RxPause : 0 > RxMulti : 15 > RxFcsErr: 800 > RxAlignErr : 0 > RxRunt : 0 > RxFragment : 0 > Rx64Byte: 7 > Rx128Byte : 17323 > Rx256Byte : 6 > Rx512Byte : 9 > Rx1024Byte : 0 > Rx1518Byte : 0 > RxMaxByte : 0 > RxTooLong : 0 > RxGoodByte : 1145334 > RxBadByte : 65266 > RxOverFlow : 0 > Filtered: 11 > TxBroad : 244 > TxPause : 0 > TxMulti : 170 > TxUnderRun : 0 > Tx64Byte: 21 > Tx128Byte : 360 > Tx256Byte : 20 > Tx512Byte : 44 > Tx1024Byte : 14459 > Tx1518Byte : 3 > TxMaxByte : 5683 > TxOverSize : 0 > TxByte : 16836688 > TxCollision : 0 > TxAbortCol : 0 > TxMultiCol : 0 > TxSingleCol : 0 > TxExcDefer : 0 > TxDefer : 0 > TxLateCol : 0 > pvid: 0 > link: port:0 link:up speed:1000baseT full-duplex txflow rxflow > > How can we determine the right value for the ath79_eth0_pll_data.pll_1000 ? > > -matt > > > ___ > 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] Routerboard 951G Switch Fix
Hello, I don't think this is related to the kernel. This issue was also in Barrier Breaker ( 3.10 ). The CPU was changed in the Routerboard 951G's from an ar9344 rev. 2 to a ar9344 rev. 3. I am wondering if the processor revision change had anything to do with it. Here is the OpenWRT Bug confirming the issue was in Barrier Breaker ( https://dev.openwrt.org/ticket/18433#comment:6 ). Hope this bit of information helps. -- Davey On Sun, Dec 14, 2014 at 11:58 AM, John Crispin wrote: > Hi, > > thanks for the info, i found my poe injector, a cisco cable and my > keyspan. i will look into this during the coming days. sorry for the > delay, i want to double check that the fix is correct. what strikes me > as odd is that this used to work on older kernels. it might be related > to the enforced phy reset patch that was merged upstream for 3.14. i > had a look and some phys allow setting the delay. maybe the routerboot > does this and the forced reset kills those settings requiring the mac > to have a different setting than before or the phy needing the delay > setting to be applied again. > > John > > On 14/12/2014 10:31, Chris Green wrote: >> On Sat, Dec 13, 2014 at 04:42:03PM -0700, Davey Hutchison wrote: >>> The boot loader on these boards is routerboot. I do not know if >>> routerboot provides a md like command or not. >>> >> Here's the RouterBOOT menu on my RB2011:- >> >> >> RouterBOOT booter 3.18 >> >> RouterBoard 2011UiAS-2HnD >> >> CPU frequency: 600 MHz Memory speed: 200 MHz Memory size: 128 MiB >> NAND size: 128 MiB >> >> Press any key within 9 seconds to enter setup >> >> RouterBOOT-3.18 What do you want to configure? d - boot delay k - >> boot key s - serial console n - silent boot o - boot device f - cpu >> frequency r - reset booter configuration e - format nand w - >> repartition nand g - upgrade firmware i - board info p - boot >> protocol b - booter options t - do memory testing x - exit setup >> your choice: >> > ___ > 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] ar934x+ar8327v4
That sounds like the way to go, if we can grab that information from boot. I can't wait to see how this is done! -- Davey On Wed, Dec 10, 2014 at 1:06 PM, John Crispin wrote: > Hi, > > felix just pointed out that we could simply read the settings inside the > kernel head after boot and see what the bootloader used. > > i'll try to cook a patch tomorrow that you can use to test this. > > John > > On 10/12/2014 20:06, John Crispin wrote: >> >> >> On 10/12/2014 20:02, David Hutchison wrote: >>> I confirmed 0x3e00 works, we can toggle bit 25 as well :) >>> >>> I left in the AR934X_ETH_CFG_RXD_DELAY >>> >>> However ar71xx_regs.h does not contain AR934X_ETH_CFG_TXD_DELAY >>> definition. AR934X_ETH_CFG_RXD_DELAY is set to BIT(14). I can add the >>> AR934X_ETH_CFG_TXD_DELAY definition to the ar71xx_regs.h file if you >>> know what BIT() value that would be. I am guessing it would be >>> BIT(15), I definitely want to confirm :) >>> >>> Do you think that is necessary, or should we leave it with >>> AR934X_ETH_CFG_RXD_DELAY only? >> >> >> it is bit 18, however it is not used anywhere and it is a shot into the >> dark. lets only use RXD for now and i will ping QCA and ask them to tell >> me what the bit actually does. >> >> do you feel like sending a patch with your fixes ? :-D >> >> John >> >> >>> >>> -- Davey >>> >>> On Wed, Dec 10, 2014 at 11:36 AM, John Crispin wrote: >>>> >>>> >>>> On 10/12/2014 18:27, David Hutchison wrote: >>>>> Hello John, >>>>> >>>>> Thank you for the prompt response. It looks like it works with >>>>> 29:26 set: >>>>> >>>>> ath79_eth0_pll_data.pll_1000 = 0x3c00; >>>>> >>>>> I think we found a solution :) >>>>> >>>> >>>> looking at the other routerboards bit 25 is always set does 0x3e00 >>>> work ? >>>> >>>> >>>>> Since we are now toggling RX/TX Delays. Should we also change >>>>> >>>>> ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | >>>>> AR934X_ETH_CFG_SW_ONLY_MODE); >>>>> >>>>> to >>>>> >>>>> ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | >>>>> AR934X_ETH_CFG_RXD_DELAY | AR934X_ETH_CFG_SW_ONLY_MODE); >>>>> >>>> >>>> i would even go for TX_DELAY and RX_DELAY >>>> >>>> not sure though, the datasheet says "enable delay" as a description :) >>>> >>>> i think setting 0x3e00 and adding AR934X_ETH_CFG_RXD_DELAY | >>>> AR934X_ETH_CFG_TXD_DELAY looks right. please see if the ethernet work >>>> with those 2 fixes applied >>>> >>>> John >>>> >>>> >>>> >>>> >>>> >>>>> It seems to work in both modes ( the pll_1000 was the real problem >>>>> ). I just want to insure consistency. Thanks again for the >>>>> information from the datasheet. >>>>> >>>>> -- Davey >>>>> >>>>> On Wed, Dec 10, 2014 at 8:25 AM, John Crispin >>>>> wrote: >>>>>> >>>>>> >>>>>> On 10/12/2014 14:44, Chris Green wrote: >>>>>>> On Wed, Dec 10, 2014 at 10:23:12AM +, Chris Green wrote: >>>>>>>> On Wed, Dec 10, 2014 at 09:59:29AM +0100, John Crispin >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/12/2014 09:29, David Hutchison wrote: >>>>>>>>>> I am once again just guessing with 0x6f00, so I am >>>>>>>>>> sure this is wrong. I would love to learn if you could >>>>>>>>>> give me insight :-) >>>>>>>>>> >>>>>>>>>> I would also love to make a patch for both the 951G and >>>>>>>>>> the rb2011 (gigabit switch version). I don't have packet >>>>>>>>>> loss anymore! :-) >>>>>>>>> >>>>>>>>> nice work ! >>>>>>>>> >>>>>>>>> i will track down someone with a datasheet today so that >>>>>>>>> we
Re: [OpenWrt-Devel] ar934x+ar8327v4
I confirmed 0x3e00 works, we can toggle bit 25 as well :) I left in the AR934X_ETH_CFG_RXD_DELAY However ar71xx_regs.h does not contain AR934X_ETH_CFG_TXD_DELAY definition. AR934X_ETH_CFG_RXD_DELAY is set to BIT(14). I can add the AR934X_ETH_CFG_TXD_DELAY definition to the ar71xx_regs.h file if you know what BIT() value that would be. I am guessing it would be BIT(15), I definitely want to confirm :) Do you think that is necessary, or should we leave it with AR934X_ETH_CFG_RXD_DELAY only? -- Davey On Wed, Dec 10, 2014 at 11:36 AM, John Crispin wrote: > > > On 10/12/2014 18:27, David Hutchison wrote: >> Hello John, >> >> Thank you for the prompt response. It looks like it works with >> 29:26 set: >> >> ath79_eth0_pll_data.pll_1000 = 0x3c00; >> >> I think we found a solution :) >> > > looking at the other routerboards bit 25 is always set does 0x3e00 > work ? > > >> Since we are now toggling RX/TX Delays. Should we also change >> >> ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | >> AR934X_ETH_CFG_SW_ONLY_MODE); >> >> to >> >> ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | >> AR934X_ETH_CFG_RXD_DELAY | AR934X_ETH_CFG_SW_ONLY_MODE); >> > > i would even go for TX_DELAY and RX_DELAY > > not sure though, the datasheet says "enable delay" as a description :) > > i think setting 0x3e00 and adding AR934X_ETH_CFG_RXD_DELAY | > AR934X_ETH_CFG_TXD_DELAY looks right. please see if the ethernet work > with those 2 fixes applied > > John > > > > > >> It seems to work in both modes ( the pll_1000 was the real problem >> ). I just want to insure consistency. Thanks again for the >> information from the datasheet. >> >> -- Davey >> >> On Wed, Dec 10, 2014 at 8:25 AM, John Crispin >> wrote: >>> >>> >>> On 10/12/2014 14:44, Chris Green wrote: >>>> On Wed, Dec 10, 2014 at 10:23:12AM +, Chris Green wrote: >>>>> On Wed, Dec 10, 2014 at 09:59:29AM +0100, John Crispin >>>>> wrote: >>>>>> >>>>>> >>>>>> On 10/12/2014 09:29, David Hutchison wrote: >>>>>>> I am once again just guessing with 0x6f00, so I am >>>>>>> sure this is wrong. I would love to learn if you could >>>>>>> give me insight :-) >>>>>>> >>>>>>> I would also love to make a patch for both the 951G and >>>>>>> the rb2011 (gigabit switch version). I don't have packet >>>>>>> loss anymore! :-) >>>>>> >>>>>> nice work ! >>>>>> >>>>>> i will track down someone with a datasheet today so that >>>>>> we know what the register actually does :) >>>>>> >>>>> Excellent, I will try patching this on my RB2011 (to >>>>> 0x6f00) and see if it works for me too. >>>>> >>>> Eureka! :-) >>>> >>>> Changing the line in mach-rb2011.c from:- >>>> >>>> ath79_eth0_pll_data.pll_1000 = 0x0600; >>>> >>>> to:- >>>> >>>> ath79_eth0_pll_data.pll_1000 = 0x6f00; >>>> >>>> Fixes my rb-2011uias-2hnd as well. I now have all ten >>>> ethernet ports working, the 5 x 10/100 *and* the 5 x Gigabit. >>>> >>>> Thanks very much David. >>>> >>>> ... and I look forward to a patch with the proper value. >>>> >>>> Can test etc. as needed. I even have a faster machine I'm >>>> just starting to configure as my desktop Linux box (where I do >>>> the build) so it won't take me so long to build. >>>> >>> >>> >>> the register layout is as follows for the top 8 bit >>> >>> 31 TX_INVERT - Decides whether to select the inversion of >>> the GTX clock after the delay line 30 GIGE_QUAD - Decides >>> whether to allow a 2 ns shift (clock in the middle of a data >>> transfer) to the GTX clock. This bit is only effective when bit >>> 25 is set. 29:28 RX_DELAY - The delay buffers in the Rx clock >>> path to adjust against the edge/middle- aligned RGMII inputs >>> 27:26 TX_DELAY - Delay line for the GTX clock that goes along >>> with the data 25 GIGE- Set only after a 1000 Mbps >>> connection has been negotiated 24 OFFSET_PHASE - Used to >>> select if the start is from the positive or negative phase (or >>> whether to have a 180 degree change in addition to the >>> phase-delay in [11:8]. >>> >>> can you try to see if only setting the bits 29:26 is enough or if >>> any of the other bits need to be set ? if that does not work it >>> has to be 30, 25 or 24 >>> >>> 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 >> > ___ > 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] ar934x+ar8327v4
Hello John, Thank you for the prompt response. It looks like it works with 29:26 set: ath79_eth0_pll_data.pll_1000 = 0x3c00; I think we found a solution :) Since we are now toggling RX/TX Delays. Should we also change ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | AR934X_ETH_CFG_SW_ONLY_MODE); to ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | AR934X_ETH_CFG_RXD_DELAY | AR934X_ETH_CFG_SW_ONLY_MODE); It seems to work in both modes ( the pll_1000 was the real problem ). I just want to insure consistency. Thanks again for the information from the datasheet. -- Davey On Wed, Dec 10, 2014 at 8:25 AM, John Crispin wrote: > > > On 10/12/2014 14:44, Chris Green wrote: >> On Wed, Dec 10, 2014 at 10:23:12AM +, Chris Green wrote: >>> On Wed, Dec 10, 2014 at 09:59:29AM +0100, John Crispin wrote: >>>> >>>> >>>> On 10/12/2014 09:29, David Hutchison wrote: >>>>> I am once again just guessing with 0x6f00, so I am sure >>>>> this is wrong. I would love to learn if you could give me >>>>> insight :-) >>>>> >>>>> I would also love to make a patch for both the 951G and the >>>>> rb2011 (gigabit switch version). I don't have packet loss >>>>> anymore! :-) >>>> >>>> nice work ! >>>> >>>> i will track down someone with a datasheet today so that we >>>> know what the register actually does :) >>>> >>> Excellent, I will try patching this on my RB2011 (to 0x6f00) >>> and see if it works for me too. >>> >> Eureka! :-) >> >> Changing the line in mach-rb2011.c from:- >> >> ath79_eth0_pll_data.pll_1000 = 0x0600; >> >> to:- >> >> ath79_eth0_pll_data.pll_1000 = 0x6f00; >> >> Fixes my rb-2011uias-2hnd as well. I now have all ten ethernet >> ports working, the 5 x 10/100 *and* the 5 x Gigabit. >> >> Thanks very much David. >> >> ... and I look forward to a patch with the proper value. >> >> Can test etc. as needed. I even have a faster machine I'm just >> starting to configure as my desktop Linux box (where I do the >> build) so it won't take me so long to build. >> > > > the register layout is as follows for the top 8 bit > > 31 TX_INVERT - Decides whether to select the inversion of the GTX > clock after the delay line > 30 GIGE_QUAD - Decides whether to allow a 2 ns shift (clock in the > middle of a data transfer) to the GTX clock. This bit is only > effective when bit 25 is set. > 29:28 RX_DELAY - The delay buffers in the Rx clock path to adjust > against the edge/middle- aligned RGMII inputs > 27:26 TX_DELAY - Delay line for the GTX clock that goes along with the > data > 25 GIGE- Set only after a 1000 Mbps connection has been negotiated > 24 OFFSET_PHASE - Used to select if the start is from the positive or > negative phase (or whether to have a 180 degree change in addition to > the phase-delay in [11:8]. > > can you try to see if only setting the bits 29:26 is enough or if any > of the other bits need to be set ? if that does not work it has to be > 30, 25 or 24 > > 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] ar934x+ar8327v4
I decided to try and toggle all of the bits by setting ath79_eth0_pll_data.pll_1000=0x6f00 and it seems to be flowing Ok: root@OpenWrt:/# arp -n IP address HW type Flags HW addressMask Device root@OpenWrt:/# brctl delif br-lan eth0 [ 30.20] device eth0 left promiscuous mode [ 30.20] br-lan: port 1(eth0) entered disabled state root@OpenWrt:/# ifconfig eth0 10.128.41.249 netmask 255.255.255.0 up root@OpenWrt:/# ping 10.128.41.1 PING 10.128.41.1 (10.128.41.1): 56 data bytes 64 bytes from 10.128.41.1: seq=0 ttl=64 time=1.596 ms 64 bytes from 10.128.41.1: seq=1 ttl=64 time=0.673 ms 64 bytes from 10.128.41.1: seq=2 ttl=64 time=0.603 ms 64 bytes from 10.128.41.1: seq=3 ttl=64 time=0.595 ms 64 bytes from 10.128.41.1: seq=4 ttl=64 time=0.610 ms 64 bytes from 10.128.41.1: seq=5 ttl=64 time=0.606 ms 64 bytes from 10.128.41.1: seq=6 ttl=64 time=0.628 ms 64 bytes from 10.128.41.1: seq=7 ttl=64 time=0.559 ms 64 bytes from 10.128.41.1: seq=8 ttl=64 time=0.641 ms 64 bytes from 10.128.41.1: seq=9 ttl=64 time=0.593 ms 64 bytes from 10.128.41.1: seq=10 ttl=64 time=0.603 ms 64 bytes from 10.128.41.1: seq=11 ttl=64 time=0.596 ms 64 bytes from 10.128.41.1: seq=12 ttl=64 time=0.596 ms 64 bytes from 10.128.41.1: seq=13 ttl=64 time=0.596 ms 64 bytes from 10.128.41.1: seq=14 ttl=64 time=0.642 ms 64 bytes from 10.128.41.1: seq=15 ttl=64 time=0.590 ms 64 bytes from 10.128.41.1: seq=16 ttl=64 time=0.836 ms ^C --- 10.128.41.1 ping statistics --- 17 packets transmitted, 17 packets received, 0% packet loss round-trip min/avg/max = 0.559/0.680/1.596 ms root@OpenWrt:/# arp -n IP address HW type Flags HW addressMask Device 10.128.41.1 0x1 0x2 d4:ca:6d:77:2b:3d *eth0 I am once again just guessing with 0x6f00, so I am sure this is wrong. I would love to learn if you could give me insight :-) I would also love to make a patch for both the 951G and the rb2011 (gigabit switch version). I don't have packet loss anymore! :-) -- Davey On Wed, Dec 10, 2014 at 1:00 AM, David Hutchison wrote: > Hello, > > I have made some progress narrowing down the issue. It seems the > ath79_eth0_pll_data.pll_1000 is not configured correctly. I do not > understand how to determine what the correct value should be. > Originally the mach-rb95x.c did not have any definition for this > variable. I looked at other Mikrotik architectures and found the > 750Gr3 utilized this and set it to 0x6200. When I compiled this I > noticed differences in the amount of packets I was receiving via eth0. > > Looking at more architectures it appears that other devices with an > ar8327 use 0x0600. I tried that and saw 100% packet loss, and arp > was not responding. I went ahead and *guessed* and tried 0x6600. > Now pings sporadically began to respond: > > root@OpenWrt:/# arp -n > IP address HW type Flags HW addressMask Device > 10.128.41.1 0x1 0x2 d4:ca:6d:77:2b:3d *eth0 > root@OpenWrt:/# ifconfig eth0 10.128.41.2 netmask 255.255.255.0 up > root@OpenWrt:/# ifconfig eth0 > eth0 Link encap:Ethernet HWaddr 4C:5E:0C:6D:24:43 > inet addr:10.128.41.248 Bcast:10.128.41.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:187 errors:0 dropped:0 overruns:0 frame:0 > TX packets:20 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:14785 (14.4 KiB) TX bytes:2180 (2.1 KiB) > Interrupt:4 > > root@OpenWrt:/# ping 10.128.41.1 > PING 10.128.41.1 (10.128.41.1): 56 data bytes > 64 bytes from 10.128.41.1: seq=3 ttl=64 time=1.169 ms > 64 bytes from 10.128.41.1: seq=10 ttl=64 time=0.663 ms > 64 bytes from 10.128.41.1: seq=12 ttl=64 time=1992.529 ms > 64 bytes from 10.128.41.1: seq=17 ttl=64 time=0.660 ms > 64 bytes from 10.128.41.1: seq=20 ttl=64 time=0.610 ms > 64 bytes from 10.128.41.1: seq=23 ttl=64 time=0.612 ms > 64 bytes from 10.128.41.1: seq=27 ttl=64 time=0.634 ms > 64 bytes from 10.128.41.1: seq=31 ttl=64 time=0.631 ms > 64 bytes from 10.128.41.1: seq=39 ttl=64 time=0.583 ms > ^C > --- 10.128.41.1 ping statistics --- > 40 packets transmitted, 9 packets received, 77% packet loss > round-trip min/avg/max = 0.583/222.010/1992.529 ms > > I have about 77% packet loss. > > This is improvement as originally we saw 100% packet loss and no arp. > > I looked at a patch by Gabor Juhosg ( > https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ath79/mach-rb91x.c?rev=39642 > ) and he set the RB91x to 0x0200 > I think if we correctly configure it in mach-rb95x.c, we may solve the > problem :-) > > Could someone help me determine what the correct > ath79_eth0_pll_data.pll_100
Re: [OpenWrt-Devel] ar934x+ar8327v4
Hello, I have made some progress narrowing down the issue. It seems the ath79_eth0_pll_data.pll_1000 is not configured correctly. I do not understand how to determine what the correct value should be. Originally the mach-rb95x.c did not have any definition for this variable. I looked at other Mikrotik architectures and found the 750Gr3 utilized this and set it to 0x6200. When I compiled this I noticed differences in the amount of packets I was receiving via eth0. Looking at more architectures it appears that other devices with an ar8327 use 0x0600. I tried that and saw 100% packet loss, and arp was not responding. I went ahead and *guessed* and tried 0x6600. Now pings sporadically began to respond: root@OpenWrt:/# arp -n IP address HW type Flags HW addressMask Device 10.128.41.1 0x1 0x2 d4:ca:6d:77:2b:3d *eth0 root@OpenWrt:/# ifconfig eth0 10.128.41.2 netmask 255.255.255.0 up root@OpenWrt:/# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 4C:5E:0C:6D:24:43 inet addr:10.128.41.248 Bcast:10.128.41.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:187 errors:0 dropped:0 overruns:0 frame:0 TX packets:20 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:14785 (14.4 KiB) TX bytes:2180 (2.1 KiB) Interrupt:4 root@OpenWrt:/# ping 10.128.41.1 PING 10.128.41.1 (10.128.41.1): 56 data bytes 64 bytes from 10.128.41.1: seq=3 ttl=64 time=1.169 ms 64 bytes from 10.128.41.1: seq=10 ttl=64 time=0.663 ms 64 bytes from 10.128.41.1: seq=12 ttl=64 time=1992.529 ms 64 bytes from 10.128.41.1: seq=17 ttl=64 time=0.660 ms 64 bytes from 10.128.41.1: seq=20 ttl=64 time=0.610 ms 64 bytes from 10.128.41.1: seq=23 ttl=64 time=0.612 ms 64 bytes from 10.128.41.1: seq=27 ttl=64 time=0.634 ms 64 bytes from 10.128.41.1: seq=31 ttl=64 time=0.631 ms 64 bytes from 10.128.41.1: seq=39 ttl=64 time=0.583 ms ^C --- 10.128.41.1 ping statistics --- 40 packets transmitted, 9 packets received, 77% packet loss round-trip min/avg/max = 0.583/222.010/1992.529 ms I have about 77% packet loss. This is improvement as originally we saw 100% packet loss and no arp. I looked at a patch by Gabor Juhosg ( https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ath79/mach-rb91x.c?rev=39642 ) and he set the RB91x to 0x0200 I think if we correctly configure it in mach-rb95x.c, we may solve the problem :-) Could someone help me determine what the correct ath79_eth0_pll_data.pll_1000 should be configured to? -- Davey On Mon, Dec 8, 2014 at 3:20 PM, Chris Green wrote: > On Mon, Dec 08, 2014 at 11:13:07AM -0700, David Hutchison wrote: >> >> root@OpenWrt:/dev# ifconfig eth0 >> eth0 Link encap:Ethernet HWaddr 4C:5E:0C:6D:24:43 >> inet addr:10.128.41.249 Bcast:10.128.41.255 Mask:255.255.255.0 >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >> RX packets:144 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:1000 >> RX bytes:8996 (8.7 KiB) TX bytes:1292 (1.2 KiB) >> Interrupt:4 >> > If it's of any use/interest my rb-2011uias-2hnd gives the following > MAC addresses:- > > br-lanLink encap:Ethernet HWaddr 4C:5E:0C:73:87:3E > eth0 Link encap:Ethernet HWaddr 4C:5E:0C:73:87:3E > eth0.1Link encap:Ethernet HWaddr 4C:5E:0C:73:87:3E > eth0.2Link encap:Ethernet HWaddr 4C:5E:0C:73:87:3E > eth0.3Link encap:Ethernet HWaddr 4C:5E:0C:73:87:3E > eth1 Link encap:Ethernet HWaddr 4C:5E:0C:73:87:43 > > Oddly it's eth1, the 10/100 fast ethernet switch built into the > processor that works and eth0 the Gigabit switch that doesn't work. > > Running an ARP scan from another computer on the LAN shows the > mikrotik (192.168.1.40) as follows:- > > 192.168.1.40 mikrotik4C:5E:0C:73:87:3E (Unknown) > > > -- > Chris Green > ___ > 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] ar934x+ar8327v4
Hello, I did some more poking around. I don't know if I am way off course or not, but I hope these findings trigger some ideas. Firstly, I contacted Mikrotik and actually received a response: "Hello, that patch will not help you much. However, you can try to debug your FW on RB2011 as it uses same CPU and same Gbit switch chip as RB951G-2HPnD. You have to correctly initialize MAC address of switch chip to make it work. You have to do that via driver so that switch is not forwarding packets when OS is still booting. Regards, Janis K." -- Mikrotik Support I requested access to there kernel patches, instead they gave me something to look into. Since the Routerboard 2011 and the RB951G use the same processor, I took code to expose the SPI config partitions. This way I could confirm the MAC Address was indeed the same that was inside "hard_config": Looking at "routerboot.h" I saw the "4" id inside hard_config is the RB_ID_MAC_ADDRESS_PACK. root@OpenWrt:/dev# cat /dev/mtd1 | hexdump -C 64 72 61 48 00 04 00 1a 00 00 00 00 00 08 00 04 |draH| 0010 4c 5e 0c 6d 24 43 00 00 00 04 00 0e 00 00 00 06 |L^.m$C..| That is the same MAC that is written on the board ( The bottom of the 951G has "4c 5e 0c 6d 24 43" ... "4c 5e 0c 6d 24 48" ). I then checked that MAC against eth0: root@OpenWrt:/dev# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 4C:5E:0C:6D:24:43 inet addr:10.128.41.249 Bcast:10.128.41.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:144 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:8996 (8.7 KiB) TX bytes:1292 (1.2 KiB) Interrupt:4 It all lines up. It's obviously not a MAC initialization problem. The ag71xx driver must be working correctly since RX/TX packets are showing. Since eth0 see's packets, that must mean communication between the ar8327 + ar934x is somewhat working. I'm wondering what we are missing... -- Davey On Fri, Dec 5, 2014 at 12:39 PM, David Hutchison wrote: > Here is a test I did by setting up swconfig manually. As you can see I > put ports 1 and 2 into vlangroup 1. Traffic from port 2 can ping > 10.128.41.1 which is a device on port 1. However eth0.1 which as > address 10.128.41.249 cannot ping 10.128.41.1 device on port 1. > Attached is the swconfig setup, and a dmesg. > > Here is the arp result as well: > root@OpenWrt:/# arp -n > IP address HW type Flags HW addressMask Device > 10.128.41.1 0x1 0x0 00:00:00:00:00:00 *eth0.1 > > I used to be able to do: > root@OpenWrt:/# swconfig dev eth0 show > Failed to connect to the switch > root@OpenWrt:/# swconfig list > Found: switch0 - ag71xx-mdio.0 > > Do you not think this is an issue with ag71xx? Do you it is something > in user-space? > > On Fri, Dec 5, 2014 at 12:18 PM, David Hutchison > wrote: >> I am using a very simple test setup with no vlans for now: >> >> root@OpenWrt:/# cat /etc/config/network >> >> config interface 'loopback' >> option ifname 'lo' >> option proto 'static' >> option ipaddr '127.0.0.1' >> option netmask '255.0.0.0' >> >> config globals 'globals' >> option ula_prefix 'fd26:7dae:48cb::/48' >> >> config interface 'lan' >> option ifname 'eth0' >> option type 'bridge' >> option proto 'static' >> option ipaddr '192.168.1.1' >> option netmask '255.255.255.0' >> option ip6assign '60' >> >> root@OpenWrt:/# swconfig dev switch0 show >> Global attributes: >> enable_vlan: 0 >> enable_mirror_rx: 0 >> enable_mirror_tx: 0 >> mirror_monitor_port: 0 >> mirror_source_port: 0 >> Port 0: >> mib: Port 0 MIB counters >> RxBroad : 5 >> RxPause : 0 >> RxMulti : 6 >> RxFcsErr: 0 >> RxAlignErr : 0 >> RxRunt : 0 >> RxFragment : 0 >> Rx64Byte: 0 >> Rx128Byte : 3252 >> Rx256Byte : 3 >> Rx512Byte : 4 >> Rx1024Byte : 0 >> Rx1518Byte : 0 >> RxMaxByte : 0 >> RxTooLong : 0 >> RxGoodByte : 223169 >> RxBadByte : 0 >> RxOverFlow : 0 >> Filtered: 0 >> TxBroad : 151 >> TxPause : 0 >> TxMulti : 324 >> TxUnderRun : 0 >> Tx64Byte: 208 >> Tx128Byte
Re: [OpenWrt-Devel] ar934x+ar8327v4
Here is a test I did by setting up swconfig manually. As you can see I put ports 1 and 2 into vlangroup 1. Traffic from port 2 can ping 10.128.41.1 which is a device on port 1. However eth0.1 which as address 10.128.41.249 cannot ping 10.128.41.1 device on port 1. Attached is the swconfig setup, and a dmesg. Here is the arp result as well: root@OpenWrt:/# arp -n IP address HW type Flags HW addressMask Device 10.128.41.1 0x1 0x0 00:00:00:00:00:00 *eth0.1 I used to be able to do: root@OpenWrt:/# swconfig dev eth0 show Failed to connect to the switch root@OpenWrt:/# swconfig list Found: switch0 - ag71xx-mdio.0 Do you not think this is an issue with ag71xx? Do you it is something in user-space? On Fri, Dec 5, 2014 at 12:18 PM, David Hutchison wrote: > I am using a very simple test setup with no vlans for now: > > root@OpenWrt:/# cat /etc/config/network > > config interface 'loopback' > option ifname 'lo' > option proto 'static' > option ipaddr '127.0.0.1' > option netmask '255.0.0.0' > > config globals 'globals' > option ula_prefix 'fd26:7dae:48cb::/48' > > config interface 'lan' > option ifname 'eth0' > option type 'bridge' > option proto 'static' > option ipaddr '192.168.1.1' > option netmask '255.255.255.0' > option ip6assign '60' > > root@OpenWrt:/# swconfig dev switch0 show > Global attributes: > enable_vlan: 0 > enable_mirror_rx: 0 > enable_mirror_tx: 0 > mirror_monitor_port: 0 > mirror_source_port: 0 > Port 0: > mib: Port 0 MIB counters > RxBroad : 5 > RxPause : 0 > RxMulti : 6 > RxFcsErr: 0 > RxAlignErr : 0 > RxRunt : 0 > RxFragment : 0 > Rx64Byte: 0 > Rx128Byte : 3252 > Rx256Byte : 3 > Rx512Byte : 4 > Rx1024Byte : 0 > Rx1518Byte : 0 > RxMaxByte : 0 > RxTooLong : 0 > RxGoodByte : 223169 > RxBadByte : 0 > RxOverFlow : 0 > Filtered: 0 > TxBroad : 151 > TxPause : 0 > TxMulti : 324 > TxUnderRun : 0 > Tx64Byte: 208 > Tx128Byte : 93 > Tx256Byte : 99 > Tx512Byte : 57 > Tx1024Byte : 12 > Tx1518Byte : 3260 > TxMaxByte : 0 > TxOverSize : 0 > TxByte : 4960741 > TxCollision : 0 > TxAbortCol : 0 > TxMultiCol : 0 > TxSingleCol : 0 > TxExcDefer : 0 > TxDefer : 0 > TxLateCol : 0 > > pvid: 0 > link: port:0 link:up speed:1000baseT full-duplex txflow rxflow > Port 1: > mib: Port 1 MIB counters > RxBroad : 151 > RxPause : 0 > RxMulti : 324 > RxFcsErr: 0 > RxAlignErr : 0 > RxRunt : 0 > RxFragment : 0 > Rx64Byte: 208 > Rx128Byte : 93 > Rx256Byte : 99 > Rx512Byte : 57 > Rx1024Byte : 12 > Rx1518Byte : 3260 > RxMaxByte : 0 > RxTooLong : 0 > RxGoodByte : 4960741 > RxBadByte : 0 > RxOverFlow : 0 > Filtered: 0 > TxBroad : 5 > TxPause : 0 > TxMulti : 6 > TxUnderRun : 0 > Tx64Byte: 0 > Tx128Byte : 3252 > Tx256Byte : 3 > Tx512Byte : 4 > Tx1024Byte : 0 > Tx1518Byte : 0 > TxMaxByte : 0 > TxOverSize : 0 > TxByte : 223169 > TxCollision : 0 > TxAbortCol : 0 > TxMultiCol : 0 > TxSingleCol : 0 > TxExcDefer : 0 > TxDefer : 0 > TxLateCol : 0 > > pvid: 0 > link: port:1 link:up speed:1000baseT full-duplex auto > Port 2: > mib: Port 2 MIB counters > RxBroad : 0 > RxPause : 0 > RxMulti : 0 > RxFcsErr: 0 > RxAlignErr : 0 > RxRunt : 0 > RxFragment : 0 > Rx64Byte: 0 > Rx128Byte : 0 > Rx256Byte : 0 > Rx512Byte : 0 > Rx1024Byte : 0 > Rx1518Byte : 0 > RxMaxByte : 0 > RxTooLong : 0 > RxGoodByte : 0 > RxBadByte : 0 > RxOverFlow : 0 > Filtered: 0 > TxBroad : 0 > TxPause : 0 > TxMulti : 0 > TxUnderRun : 0 > Tx64Byte: 0 > Tx128Byte : 0 > Tx256Byte : 0 > Tx512Byte : 0 > Tx1024Byte : 0 > Tx1518Byte : 0 > TxMaxByte : 0 > TxOverSize : 0 > TxByte : 0 > TxCollision : 0 > TxAbortCol : 0 > TxMultiCol : 0 > TxSingleCol : 0 > TxExcDefer : 0 > TxDefer : 0 > TxLateCol : 0 > > pvid: 0 > link: port:2 link:down > Port 3: > mib: Port 3 MIB counters > RxBroad : 0 > RxPause : 0 > RxMulti : 0 > RxFcsErr: 0 > RxAlignErr : 0 > RxRunt : 0 > RxFragment : 0 > Rx64Byte: 0 >
Re: [OpenWrt-Devel] ar934x+ar8327v4
4Byte: 0 Tx128Byte : 0 Tx256Byte : 0 Tx512Byte : 0 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 0 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 0 link: port:5 link:down Port 6: mib: Port 6 MIB counters RxBroad : 0 RxPause : 0 RxMulti : 0 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 0 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 0 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 0 TxPause : 0 TxMulti : 0 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 0 Tx256Byte : 0 Tx512Byte : 0 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 0 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 0 link: port:6 link:down On Fri, Dec 5, 2014 at 9:37 AM, Felix Fietkau wrote: > On 2014-12-05 17:15, David Hutchison wrote: >> Hello, >> >> Yes the problem remains when enable_vlan is set to 0 >> >> I don't think it's related to your changes either. I synced with trunk >> in hope that your changes made a difference with my problem. However >> that does not seem to be the case. >> >> I was hoping someone could point me in the right direction. Does this >> sound more like an issue with ag71xx since that is what exposes the >> "eth0" interface? Could it be as simple as the switch just isn't >> recognized? Perhaps the switch interconnect is no longer RGMII and >> should be GMII? >> >> If I knew where in those drivers to start looking, I could probably >> help fix this problem. I enjoy tinkering with the drivers, and >> learning how to fix them :) >> >> I was hoping you had some knowledge about how the interface becomes >> tied with the switch itself, and if there were any specifics for the >> ar8327 that must be set before the communication between the CPU + >> Switch Chip can happen. >> >> Felix, would you by chance have any ideas as to what to check next? >> The switch0 interface works fine, the eth0 interface tied to the >> switch. Does not. >> >> The other thing to note ( and i'm not sure if this is by design ).. I >> used to be able to do "swconfig dev eth0 show" and show the switch the >> eth0 was connected to. Now I must use "swconfig dev switch0 show" to >> configure the switch. When you do "swconfig dev eth0 show" it says it >> Failed to connect to the switch. In the past, I have always used eth0 >> to configure the switch however that may have been incorrect. > Please post your network/switch configuration, and the output of > swconfig dev switch0 show > > - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
I meant to say Could it be as simple as the switch just isn't fully initialized? instead of *recognized*... the ar8216 driver definitely recognizes it properly, and exposes the switch0 interface. I was thinking perhaps something else had to happen during init for the "eth0" interface. -- Davey On Fri, Dec 5, 2014 at 9:15 AM, David Hutchison wrote: > Hello, > > Yes the problem remains when enable_vlan is set to 0 > > I don't think it's related to your changes either. I synced with trunk > in hope that your changes made a difference with my problem. However > that does not seem to be the case. > > I was hoping someone could point me in the right direction. Does this > sound more like an issue with ag71xx since that is what exposes the > "eth0" interface? Could it be as simple as the switch just isn't > recognized? Perhaps the switch interconnect is no longer RGMII and > should be GMII? > > If I knew where in those drivers to start looking, I could probably > help fix this problem. I enjoy tinkering with the drivers, and > learning how to fix them :) > > I was hoping you had some knowledge about how the interface becomes > tied with the switch itself, and if there were any specifics for the > ar8327 that must be set before the communication between the CPU + > Switch Chip can happen. > > Felix, would you by chance have any ideas as to what to check next? > The switch0 interface works fine, the eth0 interface tied to the > switch. Does not. > > The other thing to note ( and i'm not sure if this is by design ).. I > used to be able to do "swconfig dev eth0 show" and show the switch the > eth0 was connected to. Now I must use "swconfig dev switch0 show" to > configure the switch. When you do "swconfig dev eth0 show" it says it > Failed to connect to the switch. In the past, I have always used eth0 > to configure the switch however that may have been incorrect. > > -- Davey > > On Thu, Dec 4, 2014 at 11:57 PM, Heiner Kallweit wrote: >> Am 05.12.2014 um 06:13 schrieb David Hutchison: >>> Hi, >>> >>> I ran into an issue with the Mikrotik Routerboard 951G's switch chip. >>> The new batch that we received use an updated ar8327 switch chip. The >>> switch chip would not function properly so I decided to load trunk and >>> utilize your patches. >>> >>> dmesg shows the following: >>> >>> switch0: Atheros AR8327 rev. 4 switch registered on ag71xx-mdio.0 >>> libphy: ag71xx_mdio: probed >>> eth0: Atheros AG71xx at 0xb900, irq 4, mode:RGMII >>> ag71xx ag71xx.0 eth0: connected to PHY at ag71xx-mdio.0:00 >>> [uid=004dd034, driver=Atheros AR8216/AR8236/AR8316] >>> >>> It appears the updated ar8216.c with your changes have successfully >>> initialized the chip. In fact I can even use "swconfig dev switch0" to >>> create vlans etc. >>> >>> If I create a port vlan ( eg. put ports 1 - 2 in vlan 1 ). I can plug >>> ethernet cables into each port and push data from port 1 to port 2 >>> etc. It appears the switch driver is working correctly. >>> >>> What is broken is the interface handle "eth0". It exposes eth0 and >>> ties it to the switch correctly ( as you can see from the above dmesg >>> output ). I then assign an IP address to eth0, however when I try to >>> ping a device connected to the switch. I get no response. There is no >>> arp traffic either. It's like data from the "eth0" handle doesn't know >>> how to route through the switch. >>> >>> It appears like the switch hardware is working ( since port 1 can >>> communicate to port 2 ). However when "eth0" attempts to communicate >>> to a device on port 1, it doesn't work. The device on port 1 cannot >>> communicate with the "eth0" interface either. >>> >>> I think your patches are specifically for the switch only. If that's >>> the case, then they are working. However, with your knowledge of >>> ar8327 could you point me into the direction of fixing the "eth0" >>> interface communicating to the ar8327 switch properly? Is there >>> something in ag71xx that I should be looking at? Could the ar8327 >>> switch not be initializing properly? The probe is definitely finding >>> *AR8327* so that seems to be OK. I am guessing this is something >>> specific with the ar924x CPU + ar8327 switch chip. I'm open to any >>> suggestions :-) >>> >>> -- Davey >> The recent changes to the AR8216 driver are mainly cleanups with >> no functional change. Also your dmesg output looks good. >> So at a first glance I don't think it's something with the driver. >> >> At first your /etc/config/network would be helpful. >> >> Does your problem also happen if vlans are switched off >> (enable_vlan set to 0) ? >> >> Heiner >> ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
Hello, Yes the problem remains when enable_vlan is set to 0 I don't think it's related to your changes either. I synced with trunk in hope that your changes made a difference with my problem. However that does not seem to be the case. I was hoping someone could point me in the right direction. Does this sound more like an issue with ag71xx since that is what exposes the "eth0" interface? Could it be as simple as the switch just isn't recognized? Perhaps the switch interconnect is no longer RGMII and should be GMII? If I knew where in those drivers to start looking, I could probably help fix this problem. I enjoy tinkering with the drivers, and learning how to fix them :) I was hoping you had some knowledge about how the interface becomes tied with the switch itself, and if there were any specifics for the ar8327 that must be set before the communication between the CPU + Switch Chip can happen. Felix, would you by chance have any ideas as to what to check next? The switch0 interface works fine, the eth0 interface tied to the switch. Does not. The other thing to note ( and i'm not sure if this is by design ).. I used to be able to do "swconfig dev eth0 show" and show the switch the eth0 was connected to. Now I must use "swconfig dev switch0 show" to configure the switch. When you do "swconfig dev eth0 show" it says it Failed to connect to the switch. In the past, I have always used eth0 to configure the switch however that may have been incorrect. -- Davey On Thu, Dec 4, 2014 at 11:57 PM, Heiner Kallweit wrote: > Am 05.12.2014 um 06:13 schrieb David Hutchison: >> Hi, >> >> I ran into an issue with the Mikrotik Routerboard 951G's switch chip. >> The new batch that we received use an updated ar8327 switch chip. The >> switch chip would not function properly so I decided to load trunk and >> utilize your patches. >> >> dmesg shows the following: >> >> switch0: Atheros AR8327 rev. 4 switch registered on ag71xx-mdio.0 >> libphy: ag71xx_mdio: probed >> eth0: Atheros AG71xx at 0xb900, irq 4, mode:RGMII >> ag71xx ag71xx.0 eth0: connected to PHY at ag71xx-mdio.0:00 >> [uid=004dd034, driver=Atheros AR8216/AR8236/AR8316] >> >> It appears the updated ar8216.c with your changes have successfully >> initialized the chip. In fact I can even use "swconfig dev switch0" to >> create vlans etc. >> >> If I create a port vlan ( eg. put ports 1 - 2 in vlan 1 ). I can plug >> ethernet cables into each port and push data from port 1 to port 2 >> etc. It appears the switch driver is working correctly. >> >> What is broken is the interface handle "eth0". It exposes eth0 and >> ties it to the switch correctly ( as you can see from the above dmesg >> output ). I then assign an IP address to eth0, however when I try to >> ping a device connected to the switch. I get no response. There is no >> arp traffic either. It's like data from the "eth0" handle doesn't know >> how to route through the switch. >> >> It appears like the switch hardware is working ( since port 1 can >> communicate to port 2 ). However when "eth0" attempts to communicate >> to a device on port 1, it doesn't work. The device on port 1 cannot >> communicate with the "eth0" interface either. >> >> I think your patches are specifically for the switch only. If that's >> the case, then they are working. However, with your knowledge of >> ar8327 could you point me into the direction of fixing the "eth0" >> interface communicating to the ar8327 switch properly? Is there >> something in ag71xx that I should be looking at? Could the ar8327 >> switch not be initializing properly? The probe is definitely finding >> *AR8327* so that seems to be OK. I am guessing this is something >> specific with the ar924x CPU + ar8327 switch chip. I'm open to any >> suggestions :-) >> >> -- Davey > The recent changes to the AR8216 driver are mainly cleanups with > no functional change. Also your dmesg output looks good. > So at a first glance I don't think it's something with the driver. > > At first your /etc/config/network would be helpful. > > Does your problem also happen if vlans are switched off > (enable_vlan set to 0) ? > > Heiner > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ar934x+ar8327v4
Hi, I ran into an issue with the Mikrotik Routerboard 951G's switch chip. The new batch that we received use an updated ar8327 switch chip. The switch chip would not function properly so I decided to load trunk and utilize your patches. dmesg shows the following: switch0: Atheros AR8327 rev. 4 switch registered on ag71xx-mdio.0 libphy: ag71xx_mdio: probed eth0: Atheros AG71xx at 0xb900, irq 4, mode:RGMII ag71xx ag71xx.0 eth0: connected to PHY at ag71xx-mdio.0:00 [uid=004dd034, driver=Atheros AR8216/AR8236/AR8316] It appears the updated ar8216.c with your changes have successfully initialized the chip. In fact I can even use "swconfig dev switch0" to create vlans etc. If I create a port vlan ( eg. put ports 1 - 2 in vlan 1 ). I can plug ethernet cables into each port and push data from port 1 to port 2 etc. It appears the switch driver is working correctly. What is broken is the interface handle "eth0". It exposes eth0 and ties it to the switch correctly ( as you can see from the above dmesg output ). I then assign an IP address to eth0, however when I try to ping a device connected to the switch. I get no response. There is no arp traffic either. It's like data from the "eth0" handle doesn't know how to route through the switch. It appears like the switch hardware is working ( since port 1 can communicate to port 2 ). However when "eth0" attempts to communicate to a device on port 1, it doesn't work. The device on port 1 cannot communicate with the "eth0" interface either. I think your patches are specifically for the switch only. If that's the case, then they are working. However, with your knowledge of ar8327 could you point me into the direction of fixing the "eth0" interface communicating to the ar8327 switch properly? Is there something in ag71xx that I should be looking at? Could the ar8327 switch not be initializing properly? The probe is definitely finding *AR8327* so that seems to be OK. I am guessing this is something specific with the ar924x CPU + ar8327 switch chip. I'm open to any suggestions :-) -- Davey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Support for Ubnt UniFi Outdoor Plus
It's to do with the RF Filter. Ath9k needs to be aware that it exists.. I see logic within ath9k that drives RF filters, I just don't know how to make ath9k aware of the RF Filter. Are there some EEPROM bits that can be toggled to enable this too? If these bits exist, could they be toggled via regidx/regval? I have no experience with RF Filters, Ubiquiti decided to put them on the Outdoor+ :-) Dmesg shows the radio as an ar928x, perhaps we should drop the question to Adrian or Felix in the ath9k mailing list? -- Davey On Fri, Sep 19, 2014 at 6:26 PM, Birger Brunswiek wrote: > On 14/09/14 16:43, Birger Brunswiek wrote: > > I applied some patches I found in this list to my checkout to get > OpenWRT running on my Ubnt UniFi Outdoor Plus (OD+). I was wondering if > others working on this unit have seen problems with its wireless range. > Mine cannot hear anything that's more than 5m away. Signals are shown to > be very weak. Other devices on the other hand see the OD+ with the > expected signal strength. So something's broken with the reception. It > was working normally using the original firmware. > > I would also like to know if anyone has been able to restore the > original firmware after installing OpenWRT. > > > With the help of firmware-mod-kit I was able to modify the firmware in the > UniFi controller so I could restore the OD+. After restoring the Unit > reception was back to as expected. Reverting to OpenWRT again the reception > also was OK until I did a power cycle. I suspect that their driver does > something that properly enables reception. Any pointers where I can continue > to investigate this? > > Cheers, > Birger > > ___ > 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] Initial Support for Ubiquiti UniFi Outdoor Plus
It's running well in OpenWRT, I just need some guidance on how to go about patching the "m25p80.c" file. Nobody responded about the Makefile change, if it was proper to use the "UAPPRO" profile, since it matches the UniFi+. If you manually apply those changes to your tree, it will work. -- Davey On Thu, May 22, 2014 at 3:20 AM, valent.turko...@gmail.com < valent.turko...@gmail.com> wrote: > On Sat, Apr 5, 2014 at 2:33 AM, David Hutchison > wrote: > >> I was able to get the Ubiquiti UniFi Outdoor Plus to boot into OpenWRT >> today, however I need some assistance writing a patch for it. There >> are two things that need to happen: >> >> First of all, this is how I got it to work: >> >> Modify target/linux/ar71xx/image/Makefile: >> >> > --- Makefile.bak2014-04-04 17:01:40.929134535 -0700 >> > > >> >> > > >> I would like some help testing and creating a valid patch. 1.) I don't >> know if you need to modify the flash driver in the newer kernel, can >> someone confirm trunk has support for the en25qh128 flash chip? 2.) >> Should we use "UAPPRO" since the flash layout seems to be the same on >> both the PRO and UBNT Outdoor Unifi Plus? Is that a valid approach as >> far as the Makefile is concerned? 3.) If the flash chip change is not >> needed in the latest trunk, is the first patch I provided sufficient >> for Initial UniFi Outdoor Plus support? >> >> -- Davey >> > > Has there been any progress? I'm considering getting one UAP-Outdoor+ but > it is not cheap, so it is not an impulse decision. I would like to help and > test and get this hardware supported under OpenWrt, if anybody has means to > send at least two devices for testing I'll work on getting them supported > under OpenWrt. > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Initial Support for Ubiquiti UniFi Outdoor Plus
I was able to get the Ubiquiti UniFi Outdoor Plus to boot into OpenWRT
today, however I need some assistance writing a patch for it. There
are two things that need to happen:
First of all, this is how I got it to work:
Modify target/linux/ar71xx/image/Makefile:
--- Makefile.bak2014-04-04 17:01:40.929134535 -0700
+++ Makefile2014-04-04 17:03:40.763628013 -0700
@@ -1055,6 +1055,7 @@
$(eval $(call
SingleProfile,TPLINK-LZMA,64kraw,MW4530RV1,mw4530r-v1,TL-WDR4300,ttyS0,115200,0x4531,1,8Mlzma))
$(eval $(call
SingleProfile,UAPPRO,64k,UAPPRO,ubnt-uap-pro,UAP-PRO,ttyS0,115200,BZ,BZ,ar934x))
+$(eval $(call
SingleProfile,UAPPRO,64k,UBNTUNIFIOUTDOORPLUS,ubnt-unifi-outdoor-plus,UBNT-U20,ttyS0,115200,BZ,BZ,ar7240))
$(eval $(call
SingleProfile,UBDEV,64kraw,UBDEV01,ubdev01,UBNT-UF,ttyS0,115200,XM,XM,ar7240))
@@ -1110,7 +,7 @@
$(eval $(call MultiProfile,TLWR941,TLWR941NV2 TLWR941NV3 TLWR941NV4
TLWR941NV6))
$(eval $(call MultiProfile,TLWR1043,TLWR1043V1 TLWR1043V2))
$(eval $(call MultiProfile,TLWDR4300,TLWDR3500V1 TLWDR3600V1
TLWDR4300V1 TLWDR4310V1 MW4530RV1))
-$(eval $(call MultiProfile,UBNT,UBNTAIRROUTER UBNTRS UBNTRSPRO
UBNTLSSR71 UBNTBULLETM UBNTROCKETM UBNTNANOM UBNTUNIFI
UBNTUNIFIOUTDOOR UAPPRO))
+$(eval $(call MultiProfile,UBNT,UBNTAIRROUTER UBNTRS UBNTRSPRO
UBNTLSSR71 UBNTBULLETM UBNTROCKETM UBNTNANOM UBNTUNIFI
UBNTUNIFIOUTDOOR UBNTUNIFIOUTDOORPLUS UAPPRO))
$(eval $(call MultiProfile,WNDR3700,WNDR3700V1 WNDR3700V2 WNDR3800
WNDRMAC WNDRMACV2))
$(eval $(call MultiProfile,WNR612V2,REALWNR612V2 N150R))
$(eval $(call MultiProfile,WP543,WP543_2M WP543_4M WP543_8M WP543_16M))
There was a flash driver modification I had to make to get it working,
however I'm not sure how to incorporate it in the patch. Here is the
2nd change I had to make to get the 16M flash chip to work:
Modify m25p80.c:
( I have an older kernel, so I modified it in the build directory
directly for testing purposes, it's in
linux-3.7.4/drivers/mtd/devices/m25p80.c in my particular dev
environment )
+++ m25p80.c2014-04-05 00:27:58.0 +
@@ -677,6 +677,8 @@
{ "en25q32b", INFO(0x1c3016, 0, 64 * 1024, 64, 0) },
{ "en25p64", INFO(0x1c2017, 0, 64 * 1024, 128, 0) },
{ "en25q64", INFO(0x1c3017, 0, 64 * 1024, 128, SECT_4K) },
+{ "en25qh128", INFO(0x1c7018, 0, 64 * 1024, 256, 0) },
/* Everspin */
{ "mr25h256", CAT25_INFO( 32 * 1024, 1, 256, 2) },
I would like some help testing and creating a valid patch. 1.) I don't
know if you need to modify the flash driver in the newer kernel, can
someone confirm trunk has support for the en25qh128 flash chip? 2.)
Should we use "UAPPRO" since the flash layout seems to be the same on
both the PRO and UBNT Outdoor Unifi Plus? Is that a valid approach as
far as the Makefile is concerned? 3.) If the flash chip change is not
needed in the latest trunk, is the first patch I provided sufficient
for Initial UniFi Outdoor Plus support?
-- Davey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Mikrotik RB951Ui-2HnD - further results
You can toggle the leds in /sys/class/leds or /sys/devices/platform/leds-gpio/leds, example: echo 1 > /sys/devices/platform/leds-gpio/leds/rb951ui:lan:port2/brightness I just noticed that patch has a typo for the LED's.. rb951ui:lan:port5 should be GPIO 16 not 21, you will need to update your mach-rb95x.c and make that change. -- Davey On Fri, Feb 7, 2014 at 4:01 PM, Robin Gilham wrote: > It turns out that I needed to do the following > > opkg update > opkg install kmod-usb2 > insmod ehci-hcd > > because the kernel did not have it built in. Can't believe I have been at this > for a week, I can finally get the USB to work. Still not certain on the LEDs > > Robin > ___ > 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 support for Mikrotik Groove 52HPn
Support for the Mikrotik Groove 52HPn. GPIO 17 appears to be the
buzzer. GPIO 14 is a test point to the right of the ethernet port.
Everything works except UART, I can receive output from the groove but
when i try to transmit keystrokes it seems to struggle on receiving
them. I'm guessing there is another driver attempting to use the UART
pins? Perhaps they need to be disabled to get proper UART usage? I'm
also not sure how to unlock the bottom 2 LED's from the hardware. It
appears that the second to last LED is ethernet link, and the last LED
is ethernet netdev. Everything else seems to work networking,
wireless, etc.
Signed-off-by: Davey Hutchison
--- target/linux/ar71xx/files/arch/mips/ath79/mach-rb91x.c
2013-12-16 18:08:51.0 +
+++ target/linux/ar71xx/files/arch/mips/ath79/mach-rb91x.c
2014-01-25 04:40:49.0 +
@@ -174,3 +174,49 @@
}
MIPS_MACHINE_NONAME(ATH79_MACH_RB_711GR100, "711Gr100", rb711gr100_setup);
+
+static struct gpio_led rbgroove_leds_gpio[] __initdata = {
+ {
+ .name = "rbgroove:wlan:1",
+ .gpio = 0,
+ .active_low = 0,
+ }, {
+ .name = "rbgroove:wlan:2",
+ .gpio = 1,
+ .active_low = 0,
+ }, {
+ .name = "rbgroove:wlan:3",
+ .gpio = 2,
+ .active_low = 0,
+ }
+};
+
+static void __init rbgroove_setup(void)
+{
+ const struct rb_info *info;
+
+ info = rb_init_info((void *) KSEG1ADDR(0x1f00), 0x1);
+ if (!info)
+ return;
+
+ rb711gr100_init_partitions(info);
+
+ ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_MII_GMAC0);
+
+ ath79_register_mdio(0, 0x0);
+
+ ath79_init_mac(ath79_eth0_data.mac_addr, ath79_mac_base, 0);
+ ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_MII;
+ ath79_eth0_data.phy_mask = BIT(0);
+
+ ath79_register_eth(0);
+ rb711gr100_wlan_init();
+
+ platform_device_register_simple("rb91x-nand", -1, NULL, 0);
+
+ ath79_register_leds_gpio(-1, ARRAY_SIZE(rbgroove_leds_gpio),
+rbgroove_leds_gpio);
+}
+
+MIPS_MACHINE(ATH79_MACH_RB_GROOVE, "groove-52", "MikroTik 52HPn",
+ rbgroove_setup);
--- target/linux/ar71xx/patches-3.10/703-MIPS-ath79-add-RB91x-support.patch
2013-12-16 18:08:51.0 +
+++ target/linux/ar71xx/patches-3.10/703-MIPS-ath79-add-RB91x-support.patch
2014-01-25 05:02:47.0 +
@@ -5,6 +5,7 @@
ATH79_MACH_RB_493, /* Mikrotik RouterBOARD 493/493AH */
ATH79_MACH_RB_493G, /* Mikrotik RouterBOARD 493G */
+ ATH79_MACH_RB_711GR100, /* Mikrotik RouterBOARD
911/912 boards */
++ ATH79_MACH_RB_GROOVE, /* Mikrotik Groove 52HPn */
ATH79_MACH_RB_750, /* MikroTik RouterBOARD 750 */
ATH79_MACH_RB_750G_R3, /* MikroTik RouterBOARD 750GL */
ATH79_MACH_RB_751, /* MikroTik RouterBOARD 751 */
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT on the Ubiquiti airGateway
I'm glad someone else is looking at the air-gateway as well. Here was
my approach:
I added the following to the bottom of mach-ubnt-xm.c
#define AIRGW_MAC0_OFFSET 0x
#define AIRGW_MAC1_OFFSET 0x0006
#define AIRGW_CALDATA_OFFSET0x1000
static struct gpio_led ubnt_airgateway_gpio_leds[] __initdata = {
{
.name = "ubnt:blue",
.gpio = 0,
}, {
.name = "ubnt:white",
.gpio = 1,
},
};
static void __init ubnt_airgateway_setup(void)
{
u32 t;
u8 *art = (u8 *) KSEG1ADDR(0x1fff);
ath79_gpio_function_disable(AR933X_GPIO_FUNC_ETH_SWITCH_LED0_EN |
AR933X_GPIO_FUNC_ETH_SWITCH_LED1_EN |
AR933X_GPIO_FUNC_ETH_SWITCH_LED2_EN |
AR933X_GPIO_FUNC_ETH_SWITCH_LED3_EN |
AR933X_GPIO_FUNC_ETH_SWITCH_LED4_EN);
t = ath79_reset_rr(AR933X_RESET_REG_BOOTSTRAP);
t |= AR933X_BOOTSTRAP_MDIO_GPIO_EN;
ath79_reset_wr(AR933X_RESET_REG_BOOTSTRAP, t);
ath79_register_m25p80(NULL);
ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_airgateway_gpio_leds),
ubnt_airgateway_gpio_leds);
ath79_init_mac(ath79_eth1_data.mac_addr,
art + AIRGW_MAC0_OFFSET, 0);
ath79_init_mac(ath79_eth0_data.mac_addr,
art + AIRGW_MAC1_OFFSET, 0);
ath79_register_mdio(0, 0x0);
ath79_register_eth(1);
ath79_register_eth(0);
ath79_register_wmac(art + AIRGW_CALDATA_OFFSET, NULL);
ath79_register_usb();
}
MIPS_MACHINE(ATH79_MACH_UBNT_AIRGW, "UBNT-AGW", "Ubiquiti AirGateway",
ubnt_airgateway_setup);
Add an entry to machtypes.h
ATH79_MACH_UBNT_AIRGW, /* Ubiquiti AirGateway */
Add the target/linux/ar71xx/image/Makefile:
$(eval $(call
SingleProfile,UBNTXM,$(fs_64k),UBNTAIRGW,ubnt-air-gateway,UBNT-AGW,ttyATH0,115200,XM,UBNTAirGW,ar933x))
This also builds a separate image, for the air-gateway..
My only problem is that the watchdog isn't working correctly. I get
random reboots on it, i tried applying Felix's ar933x watchdog timer
fix ( i thought that may have been causing it, but didn't seem to help
). Anyway, that's my start, I was able to atleast get it running. The
architecture needs to get cleaned up a bit, hence why I haven't built
any patches and attempted to submit them ( haven't had enough time :-/
)
-- Davey
On Sat, Dec 21, 2013 at 1:58 PM, Federico Lorenzi wrote:
> Hi all,
>
> The Ubiquiti airGateway [1] is a tiny "POE" (not 802.11af,
> unfortunately) powered AP that clips on to the end of Ubiquiti's POE
> adapters. They intend it to be used as a local repeater for an AP
> mounted off on a pole off on the roof, and as such has dual Ethernet
> ports - one with POE passthrough.
>
> It's based around the AR9280 chipset, just like quite a few TP-LINK
> devices already supported by OpenWRT. Out of the box, if you try to
> flash the firmware for the Ubiquiti AirRouter, it fails.
>
> This is due to a simple magic string mismatch. It expects something
> along the lines of: "UBNTAirGW.ar933x.v6.0.0-OpenWrt-r39036"
>
> After changing the magic string, OpenWRT boots fine, but the WiFi
> doesn't work. As a quick hack (and since I'm currently unfamiliar with
> the correct way of doing things) I went about modifying the existing
> entry for the AirRouter in arch/mips/ath79/mach-ubnt-xm.c
>
> All that needed to be done was for the line "ap91_pci_init(ee, NULL);"
> to be commented out, and for "ath79_register_wmac(ee, mac1);" to be
> added at the end of the function ubnt_airrouter_setup.
>
> With this, the compiled image booted and ran perfectly on the
> airGateway, with WiFi. I haven't tested much beyond basic AP
> functionality, but it seems stable enough. If you manage to open the
> device (for which I had to use a dremel to cut it open...) you'll see
> an unsoldered 3.3V serial port that can be used for debugging.
>
> Cheers,
> Federico
>
> [1] http://dl.ubnt.com/datasheets/airgateway/airGateway_DS.pdf
> ___
> 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] Add RouterBOARD 951Ui-2HnD Support
This patch enables OpenWRT to be ran on the RouterBOARD 951Ui-2HnD.
GPIO 2 enables or disables the POE on port 5. By default we enable
GPIO2. GPIO 20 controls the USB Power, by default it enables the USB
port.
Attached is 624-MIPS-ath79-RB951u-support.patch
Signed-off-by: Davey Hutchison
--- target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c
+++ target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c
@@ -37,6 +37,7 @@
#include "dev-wmac.h"
#include "machtypes.h"
#include "routerboot.h"
+#include "dev-leds-gpio.h"
#define RB95X_GPIO_NAND_NCE14
@@ -89,6 +90,38 @@
}
};
+static struct gpio_led rb951ui_leds_gpio[] __initdata = {
+{
+.name= "rb951ui:wlan",
+.gpio= 11,
+.active_low= 1,
+}, {
+.name= "rb951ui:act",
+.gpio= 3,
+.active_low= 1,
+}, {
+.name= "rb951ui:lan:port1",
+.gpio= 13,
+.active_low= 1,
+}, {
+.name= "rb951ui:lan:port2",
+.gpio= 12,
+.active_low= 1,
+}, {
+.name= "rb951ui:lan:port3",
+.gpio= 4,
+.active_low= 1,
+}, {
+.name= "rb951ui:lan:port4",
+.gpio= 21,
+.active_low= 1,
+}, {
+.name= "rb951ui:lan:port5",
+.gpio= 16,
+.active_low= 1,
+}
+};
+
static struct mdio_board_info rb95x_mdio0_info[] = {
{
.bus_id = "ag71xx-mdio.0",
@@ -212,3 +245,43 @@
MIPS_MACHINE(ATH79_MACH_RB_951G, "951G", "MikroTik RouterBOARD 951G-2HnD",
rb951g_setup);
+
+static void __init rb951ui_setup(void)
+{
+rb95x_gpio_init();
+rb95x_nand_init();
+
+ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_SW_ONLY_MODE);
+
+ath79_register_mdio(1, 0x0);
+
+ath79_init_mac(ath79_eth0_data.mac_addr, ath79_mac_base, 0);
+ath79_init_mac(ath79_eth1_data.mac_addr, ath79_mac_base, 1);
+
+ath79_switch_data.phy4_mii_en = 1;
+ath79_switch_data.phy_poll_mask = BIT(4);
+ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_MII;
+ath79_eth0_data.phy_mask = BIT(4);
+ath79_eth0_data.mii_bus_dev = &ath79_mdio1_device.dev;
+ath79_register_eth(0);
+
+ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_GMII;
+ath79_register_eth(1);
+
+gpio_request_one(20,
+GPIOF_OUT_INIT_HIGH | GPIOF_EXPORT_DIR_CHANGEABLE,
+"USB power");
+
+gpio_request_one(2,
+GPIOF_OUT_INIT_HIGH | GPIOF_EXPORT_DIR_CHANGEABLE,
+"POE power");
+
+rb95x_wlan_init();
+ath79_register_usb();
+
+ath79_register_leds_gpio(-1, ARRAY_SIZE(rb951ui_leds_gpio),
+rb951ui_leds_gpio);
+}
+
+MIPS_MACHINE(ATH79_MACH_RB_951U, "951HnD", "MikroTik RouterBOARD 951Ui-2HnD",
+ rb951ui_setup);
On Wed, Aug 28, 2013 at 2:19 AM, Gabor Juhos wrote:
> 2013.08.28. 7:46 keltezéssel, Вячеслав Адаманов írta:
>> Gabor Juhos,
>> tell me, is it possible to port RB / SXT 2nDr2 Lite 2? Or are have any of the
>> nuances for which it can not or imposible.
>
> Although I don't know the hardware details of the SXT Lite boards but it
> should
> be possible.
>
> -Gabor
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
624-MIPS-ath79-RB951U-support.patch
Description: Binary data
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Add RouterBOARD 951Ui-2HnD Support
This patch enables OpenWRT to be ran on the RouterBOARD 951Ui-2HnD.
GPIO 2 enables or disables the POE on port 5. By default we enable
GPIO2. GPIO 20 controls the USB Power, by default it enables the USB
port.
GPIO 20 is also exposed on the RouterBOARD 951G if anyone was curious.
I did not include that in this patch.
I need some assistance creating a proper patch for the RouterBOARD
951U. I have the RouterBOARD 951U working, and will include all of the
code necessary.
First the architecture:
--- target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c
+++ target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c
@@ -37,6 +37,7 @@
#include "dev-wmac.h"
#include "machtypes.h"
#include "routerboot.h"
+#include "dev-leds-gpio.h"
#define RB95X_GPIO_NAND_NCE14
@@ -86,6 +95,39 @@
+
+static struct gpio_led rb951ui_leds_gpio[] __initdata = {
+{
+.name= "rb951ui:wlan",
+.gpio= 11,
+.active_low= 1,
+}, {
+.name= "rb951ui:act",
+.gpio= 3,
+.active_low= 1,
+}, {
+.name= "rb951ui:lan:port1",
+.gpio= 13,
+.active_low= 1,
+}, {
+.name= "rb951ui:lan:port2",
+.gpio= 12,
+.active_low= 1,
+}, {
+.name= "rb951ui:lan:port3",
+.gpio= 4,
+.active_low= 1,
+}, {
+.name= "rb951ui:lan:port4",
+.gpio= 21,
+.active_low= 1,
+}, {
+.name= "rb951ui:lan:port5",
+.gpio= 16,
+.active_low= 1,
}
};
@@ -212,3 +254,35 @@
MIPS_MACHINE(ATH79_MACH_RB_951G, "951G", "MikroTik RouterBOARD 951G-2HnD",
rb951g_setup);
+
+static void __init rb951ui_setup(void)
+{
+rb95x_gpio_init();
+rb95x_nand_init();
+
+ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_SW_ONLY_MODE);
+
+ath79_register_mdio(1, 0x0);
+
+ath79_init_mac(ath79_eth0_data.mac_addr, ath79_mac_base, 0);
+ath79_init_mac(ath79_eth1_data.mac_addr, ath79_mac_base, 1);
+
+ath79_switch_data.phy4_mii_en = 1;
+ath79_switch_data.phy_poll_mask = BIT(4);
+ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_MII;
+ath79_eth0_data.phy_mask = BIT(4);
+ath79_eth0_data.mii_bus_dev = &ath79_mdio1_device.dev;
+ath79_register_eth(0);
+
+ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_GMII;
+ath79_register_eth(1);
+
+gpio_request_one(20,
+ GPIOF_OUT_INIT_HIGH | GPIOF_EXPORT_DIR_CHANGEABLE,
+ "USB power");
+
+gpio_request_one(2,
+GPIOF_OUT_INIT_HIGH | GPIOF_EXPORT_DIR_CHANGEABLE,
+"POE power");
+
+rb95x_wlan_init();
+ath79_register_usb();
+
+ath79_register_leds_gpio(-1, ARRAY_SIZE(rb951ui_leds_gpio),
+ rb951ui_leds_gpio);
+}
+
+MIPS_MACHINE(ATH79_MACH_RB_951U, "951HnD", "MikroTik RouterBOARD 951Ui-2HnD",
+ rb951ui_setup);
Here is the part I am confused on. There are two files "machtypes.h"
and "prom.c". We need to add "ATH79_MACH_RB_951U" to "machtypes.h".
I'm not sure where in the target directory "machtypes.h" is. It
appears that both files are managed by a *.patch file in the patches
directory. Does the PATCH submitted need to be a patch of a patch
file? or a new patch? Should
target/linux/ar71xx/ath79/patches/610-MIPS-ath79-openwrt-machines.patch
be modified, or add a 612-MIPS-ath79-openwrt-rb951u.patch ?
Here are the changes that need to happen:
+++ machtypes.h
@@ -74,6 +74,7 @@
ATH79_MACH_RB_751,/* MikroTik RouterBOARD 751 */
ATH79_MACH_RB_751G,/* Mikrotik RouterBOARD 751G */
ATH79_MACH_RB_951G,/* Mikrotik RouterBOARD 951G */
+ATH79_MACH_RB_951U,/* Mikrotik RouterBOARD 951U */
ATH79_MACH_RB_2011G,/* Mikrotik RouterBOARD 2011UAS-2HnD */
ATH79_MACH_RB_2011L,/* Mikrotik RouterBOARD 2011L */
ATH79_MACH_RB_2011US,/* Mikrotik RouterBOARD 2011UAS */
Now to enable serial:
+++ prom.c
@@ -183,6 +183,7 @@
if (strstr(arcs_cmdline, "board=750Gr3") ||
strstr(arcs_cmdline, "board=951G") ||
+strstr(arcs_cmdline, "board=951HnD") ||
strstr(arcs_cmdline, "board=2011L"))
ath79_prom_append_cmdline("console", "ttyS0,115200");
}
Signed-off-by: Davey Hutchison
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] RouterBoard 951G LED's
Hey,
I'm trying to get the RB951G's LED's to work. The User led and wlan
led is connected to ethernet switch chip (pins LED_LINK10n_4 and
LED_LINK10n_0) - ethernet switch chip driver has to provide those led devices.
I have tried exposing them in the architecture like so:
#define RB_USER_LED 4
#define RB_WLAN_LED 0
#define RB_USB_POWER20
static struct gpio_led rb95x_leds_gpio[] __initdata = {
{
.name = "user-led",
.gpio = RB_USER_LED,
.active_low = 0,
}, {
.name = "wlan-led",
.gpio = RB_WLAN_LED,
.active_low = 0,
}, {
.name = "usb-power-off",
.gpio = RB_USB_POWER,
.active_low = 0,
}
};
//and adding to __init rb95x_setup(void)
ath79_register_leds_gpio(-1, ARRAY_SIZE(rb95x_leds_gpio),
rb95x_leds_gpio);
Mikrotik has provided me with the following LED Map:
static int rb951g_led_map[] = {
PLD(4,15), 0, 0, 0, 0, 0, PLDI(20, 0), 0, PLD(0,15), PLEND
};
static struct platform_device rb951g_led_device = {
.name= "rb400-led",
.id= -1,
.dev= {
.platform_data = rb951g_led_map,
},
};
I have tried compiling in the rb400-led driver, and it still does not
expose the LED's. I have a feeling that the ar8327 switch driver needs
to allow the LED's to be exposed, however i'm unsure of how to do
that.
I was looking inside of "linux-3.7.4/drivers/net/phy/ar8216.c" where I found:
led_cfg = pdata->led_cfg;
if (led_cfg) {
if (led_cfg->open_drain)
new_pos |= AR8327_POWER_ON_STRIP_LED_OPEN_EN;
else
new_pos &= ~AR8327_POWER_ON_STRIP_LED_OPEN_EN;
priv->write(priv, AR8327_REG_LED_CTRL0, led_cfg->led_ctrl0);
priv->write(priv, AR8327_REG_LED_CTRL1, led_cfg->led_ctrl1);
priv->write(priv, AR8327_REG_LED_CTRL2, led_cfg->led_ctrl2);
priv->write(priv, AR8327_REG_LED_CTRL3, led_cfg->led_ctrl3);
}
Does something in that stanza need to be added to allow exposure of
LED_LINK10n_4 and
LED_LINK10n_0? Perhaps I read the LED Map incorrectly and do not have
the LED GPIO's defined right?
Any help is much appreciated :-)
-- Davey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [ar71xx] Routerboard 751 Mac Address Offset Fix
We utilize many Routerboard 751's and discovered that our latest batch
of RB751's would not initialize the wireless radio. We have determined
Mikrotik has changed where the mac address was located inside
hardconfig. As such we utilize "routerboot_find_tag" to find the
location of the mac address. We should remove
"RB751_MAC_ADDRESS_OFFSET" as it is ambiguous by machine manufacturing
date. The newer batch of RB751's that we received had a
RB751_MAC_ADDRESS_OFFSET 0x10.
Signed-off-by: Davey Hutchison
--- target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c
+++ target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c
@@ -282,7 +282,6 @@
#define RB751_HARDCONFIG 0x1f00b000
#define RB751_HARDCONFIG_SIZE 0x1000
-#define RB751_MAC_ADDRESS_OFFSET 0xE80
static void __init rb751_wlan_setup(void)
{
@@ -290,6 +289,8 @@
struct ath9k_platform_data *wmac_data;
u16 tag_len;
u8 *tag;
+ u16 mac_len;
+ u8 *mac;
int err;
wmac_data = ap9x_pci_get_wmac_data(0);
@@ -313,8 +314,15 @@
pr_err("rb75x: unable to decode wlan eeprom data\n");
return;
}
+
+ err = routerboot_find_tag(hardconfig, RB751_HARDCONFIG_SIZE,
+ RB_ID_MAC_ADDRESS_PACK, &mac, &mac_len);
+ if (err) {
+ pr_err("rb75x: no mac address found\n");
+ return;
+ }
- ap91_pci_init(NULL, hardconfig + RB751_MAC_ADDRESS_OFFSET);
+ ap91_pci_init(NULL, mac);
}
static void __init rb751_setup(void)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
