Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
Unfortunately, the driver that you provided not able to detect the switch correctly ADM6996FC PHY detected. I have observed the following: eth0: Atheros AG71xx at 0xb900, irq 4* eth0: PHY overlaps ADM6996, providing fixed PHY 14.* eth0: connected to PHY at ag71xx-mdio:14 [uid=1027, driver=Infineon ADM6996] eth1: Atheros AG71xx at 0xba00, irq 5 *eth1: PHY overlaps ADM6996, providing fixed PHY 10.* eth1: connected to PHY at ag71xx-mdio:10 [uid=1027, driver=Infineon ADM6996] eth0: link up (100Mbps/Full duplex) eth0: link down device eth1 entered promiscuous mode eth0: link up (100Mbps/Full duplex) dmesg Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
On 12/04/11 09:15, Yeoh Chun Yeow wrote: Unfortunately, the driver that you provided not able to detect the switch correctly ADM6996FC PHY detected. I have observed the following: eth0: PHY overlaps ADM6996, providing fixed PHY 14. eth1: PHY overlaps ADM6996, providing fixed PHY 10. Okay, I could have seen that one coming. Fortunately, it's not that my detection code does not work. It's that the driver wishes to be addressed as address 0, and I forgot that your WAN_PHYMASK and LAN_PHYMASK are set differently. I should also add 0x before the 14 and 10, I got confused with decimal for a moment :). It's 16 and 20 decimal. David already gave the vital piece of information: eth0 is connected to port 4 of the switch. I'll send you a different driver soon, which hopefully completely fixes the problem. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] RTL8366S/RB: Remove the PHY driver.
2011.04.08. 21:52 keltezéssel, Jonas Gorski írta: Since the PHY driver is only used for the WAN port and there is virtually no difference between it and the generic PHY driver, we can sefely remove it. Signed-off-by: Jonas Gorski jonas.gorski+open...@gmail.com Applied in r26600. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: Add support for WZR-HP-G301NH
2011.04.11. 6:33 keltezéssel, Jonas Gorski írta: Add support for the Buffalo WZR-HP-G301NH. The only difference between it and the WZR-HP-G00NH is that it has a RTL8366RB instead of a RTL8366S. Since we don't do runtime detection of the switch, we need a separate machine definition for it. While we are at it, also rename the profile to reflect that it now is for more than one device. Signed-off-by: Jonas Gorski jonas.gorski+open...@gmail.com --- Applied in r26601. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Debugging OpenWRT ELF image with GDB on host system
Dear Slawomir Cygan, Thank you very much for your infromation. 2011/4/12 Sławomir Cygan slawomir.cy...@gmail.com: Hi, We are unable to debug the OpenWRT image through GDB from a host system. When we try to debug, we are seeing the following error messages on the GDB screen. We are running the GDB from Cygwin on a Windows XP system. Please use cross-compiled version of gdb - the one build by OpenWRT. I am trying to debug the vmlinux OpenWRT image which is build for my target device. The procedure that I am following is as follows. I build the OpenWRT image (vmlinux) on a Linux box in the ELF format for my Samsung MCU. Then, I am trying to load it on to my device's RAM area using a J-Link J-TAG and J-LinkGDBServer tool with a .gdbinit script from a Windows XP system. The .gdbinit script contains the initialization of the address map and CPU registers UART etc. Then, I am running the gdb from Cygwin on Windows XP system. If this is the case, how can I use OpenWRT gdb? Where is OpenWRT gdb available? Is it in staging_dir? Shall we need to be changed CFLAGS in any Makefile for including the -g option? Propably, or modify global CFLAGS setting in OpenWRT. By default all programs are build without debug info (and can be stripped, but I am not sure about this at the moment). Yes. By default all are build without debugging information. I added -g option in the Makefile which is located at the trunk/target/linux/board directory. Any suggestions / ideas / links would be appreciated and help us a lot My own point of view: usually it is better to use printf() instead of gdb and printk() instead of kgdb. I am not able to see any debug messages on the hyper terminal. That is the reason, I want to put some break points in the HAL code and need to check whether it is reaching there or not through gdb. I explained the loading procedure above. Please let me know, if you need any additional information. I will provide. Thanks and Regards, Madhavi M. -- Pozdrawiam, Sławomir Cygan ___ 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] Debugging OpenWRT ELF image with GDB on host system
So now you are using jtag - You mentioned gdbserver in last post, so my last response won't apply to Your problem. Please refer to your jtag hardware and software documentation for more help. You also did not mention in last post that You are trying debug the kernel - if so, build it with debug info (option unser make kernel_menuconfig kernel hacking), no manual CFLAGS modification needed. -- Pozdrawiam, Sławomir Cygan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Debugging OpenWRT ELF image with GDB on host system
Dear Slawomir Cygan, Thanks for your response. 2011/4/12 Sławomir Cygan slawomir.cy...@gmail.com: So now you are using jtag - You mentioned gdbserver in last post, so my last response won't apply to Your problem. Please refer to your jtag hardware and software documentation for more help. You also did not mention in last post that You are trying debug the kernel - if so, build it with debug info (option unser make kernel_menuconfig kernel hacking), no manual CFLAGS modification needed. Sorry. I did not mention the details in my previous email. I will take care from now-on-words. However, I did the same thing what you said like run the make kernel_menuconfig then kernel hacking and enabled the kernel debug. But, when I run make V=99, again, it is not set in the .config file of the kernel. So, I enabled it from trunk/make menuconfig -- Global Build Settings -- Compile the kernel with debug information. Then, I am able to see CONFIG_DEBUG_KERNEL=y in the .config file of the linux kernel. Thanks for your suggestions and information. Thanks and Regards, Madhavi M. -- Pozdrawiam, Sławomir Cygan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] problems with 'powersave' option in 'sta' mode on ath5k
Hi, I am getting the following error when bringing up ath5k: Error for wireless request Set Power Management (8B2C) : SET failed on device wlan0 ; Operation not supported. The patch that follows proposes a potention solution to this. I am assuming the original version uses iwconfig instead of iw for the same reason as stated in the comment. Best regards, Jan Capek ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] /etc/config/wireless - 'powersave' setting optional
- this configuration option seems to be undocumented. Unfortunately,
it tries to disable powersaving by default for all mac80211 based
wifi interfaces that use 'sta' mode. Some drivers (e.g. ath5k) don't
support setting/enabling powersaving mode. The result is an error
message when bringing wifi up. This change makes the setting
optional.
Signed-off-by: Jan Čapek j...@capkovi.eu
---
package/mac80211/files/lib/wifi/mac80211.sh | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/package/mac80211/files/lib/wifi/mac80211.sh
b/package/mac80211/files/lib/wifi/mac80211.sh
index d395db1..113491b 100644
--- a/package/mac80211/files/lib/wifi/mac80211.sh
+++ b/package/mac80211/files/lib/wifi/mac80211.sh
@@ -324,9 +324,15 @@ enable_mac80211() {
[ $wds -gt 0 ] wdsflag=4addr on
iw phy $phy interface add $ifname type
managed $wdsflag
config_get_bool powersave $vif powersave 0
- [ $powersave -gt 0 ] powersave=on ||
powersave=off
- iwconfig $ifname power $powersave
- ;;
+[ -n $powersave ] {
+[ $powersave -gt 0 ] powersave=on
|| powersave=off
+ # TODO: using iw needs to be tested. E.g.
on ath5k which
+ # doesn't seem to support this, calling iw
immediately
+ # after interface addition seems to pass..
+#iw dev $ifname set power_save
$powersave
+ iwconfig $ifname power $powersave
+}
+ ;;
esac
# All interfaces must have unique mac addresses
--
1.6.3.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
Hi, I hopefully have finished the two versions of the driver. One effectively only supports the M model (though it detects and initialises the FC model), and the second experimental one adds VLAN support for the FC model. I don't have the time right now to do the official patch submission. But attached is the diff against backfire for the experimental FC support. It also includes a change to the Ubiquiti RouterStation board support code. Yeoh, please try out the driver. I hope it will completely work for you. It now even includes some documentation. Please note that if you apply my patch to the RouterStation support code, but do not include the ADM6996 driver, you will lose your LAN Ethernet connectivity. The ADM6996 exports Generic PHY compatible, standard PHY register access on PHY addresses 16 through 20 (for ports 0 through 4 of the ADM6996). The WAN Ethernet is correctly wired to address 20. The LAN is somewhat interestingly wired to address 16, port 0. This means the MAC will work as if the PHY on the other side of its MII link is port 0, whereas the MII link connects to the switching fabric of the ADM6996. When using the ADM6996 switch driver, it will always report link up, 100Mbit/s FD for PHY address 0, which is correct. Like I said earlier, it is as if the cable between the Ethernet adapter and the switch is always present. So I changed the PHY mask for the LAN Ethernet to use PHY address 0. But if you do not include the ADM6996 driver, it will use the Generic PHY driver for PHY address 0, and that leads to the special-purpose registers of the ADM6996. This does not work. I'd really like to know if chip detection now finally works! Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt Index: target/linux/generic-2.6/files/Documentation/networking/adm6996.txt === --- target/linux/generic-2.6/files/Documentation/networking/adm6996.txt (revision 0) +++ target/linux/generic-2.6/files/Documentation/networking/adm6996.txt (revision 0) @@ -0,0 +1,120 @@ +--- + +ADM6996FC / ADM6996M switch chip driver + + +1. General information + + This driver supports the FC and M models only. The ADM6996F and L are + completely different chips. + +1.1 VLAN IDs + + It is possible to define 16 different VLANs. Every VLAN has an identifier, its + VLAN ID. It is easiest if you use at most VLAN IDs 0-15. In that case, the + swconfig based configuration is very straightforward. To define two VLANs with + IDs 4 and 5, you can invoke, for example: + + # swconfig dev ethX vlan 4 set ports '0 1t 2 5t' + # swconfig dev ethX vlan 5 set ports '0t 1t 5t' + + The swconfig framework will automatically invoke 'port Y set pvid Z' for every + port that is an untagged member of VLAN Y, setting its Primary VLAN ID. In + this example, ports 0 and 2 would get pvid 4. The Primary VLAN ID of a port + is the VLAN ID associated with untagged packets coming in on that port. + + But if you wish to use VLAN IDs outside the range 0-15, this automatic + behaviour of the swconfig framework becomes a problem. The 16 VLANs that + swconfig can configure on the ADM6996 also have a vid setting. By default, + this is the same as the number of the VLAN entry, to make the simple behaviour + above possible. To still support a VLAN with a VLAN ID higher than 15 + (presumably because you are in a network where such VLAN IDs are already in + use), you can change the vid setting of the VLAN to anything in the range + 0-1023. But suppose you did the following: + + # swconfig dev ethX vlan 0 set vid 998 + # swconfig dev ethX vlan 0 set ports '0 2 5t' + + Now the swconfig framework will issue 'port 0 set pvid 0' and 'port 2 set pvid + 0'. But the pvid should be set to 998, so you are responsible for manually + fixing this! + +1.2 VLAN filtering + + The switch is configured to apply source port filtering. This means that + packets are only accepted when the port the packets came in on is a member of + the VLAN the packet should go to. + + Only membership of a VLAN is tested, it does not matter whether it is a tagged + or untagged membership. + + For untagged packets, the destination VLAN is the Primary VLAN ID of the + incoming port. So if the PVID of a port is 0, but that port is not a member of + the VLAN with ID 0, this means that untagged packets on that port are dropped. + This can be used as a roundabout way of dropping untagged packets from a port, + a mode often referred to as Admit only tagged packets. + +1.3 Reset + + The two supported chip models do not have a sofware-initiated reset. When the + driver is initialised, as well as when the 'reset' swconfig option is invoked, + the driver will set those registers it knows about and supports to the correct +
[OpenWrt-Devel] ext4 errors on virtualbox boot
I'm getting invalid block reference errors when booting the VDI image. Also, / is mounted read-only whereas in backfire it was mounted read-write. I think the 2 might be related. Any ideas? - Ryan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC 1/4] mac80211: b43: Add Firmware 5.10.56.27
On 04/12/2011 12:02 AM, Rafał Miłecki wrote: W dniu 11 kwietnia 2011 00:32 użytkownik Jonas Gorski jonas.gorski+open...@gmail.com napisał: 2011/4/10 Rafał Miłecki zaj...@gmail.com: Versioning of firmware is a little tricky, because version of included firmware does not match version of driver. This way there is not such think as firmware 4.150.10.5. If you want to be strict about that, you can apply my following naming suggestions. I've thought about it; the driver version is probably the one that's visible and easily found; the included firmware version not so much. Also b43-fwcutter and everyone else is using using the driver versions, so suddenly switching to the firmware versions will probably just unnecessarily confuse people. I'll rename the config symbols and work the firmware version into the description/help text, so that it contains both without (hopefully) causing too much confusion. Hm, yes, you're right. I was not sure about names like B43_FW_4_150. Such a name suggests firmware (FW) version 4.150. However using B43_FW_410_2160_FROM_4_150_10_5 on the other hand sounds crappy ;) Maybe B43_FW_FROM_4_150? I guess there is not perfect solution. Hi, nice patches Jonas. I would leave the names of the config options as you suggested so B43_FW_4_150, B43_FW_4_178 and B43_FW_5_10, but the config title should be extended, this should contain Firmware 410.2160 from driver 4.. with the exact version numbers. The experimental and stable should be removed, but B43_FW_4_150 should be the default one. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] add src-cvs to feeds script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, patching file scripts/feeds Hunk #1 FAILED at 106. Hunk #2 FAILED at 283. 2 out of 2 hunks FAILED -- saving rejects to file scripts/feeds.rej Can you rebase your patch? ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2ks18ACgkQdputYINPTPPmQgCeIxbWWe/Pz6IQEsiwWcohDrIt 5t8An2x7DFxFy3lji5l68nJ9OZiCG1oi =6OA/ -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: Make bridge MAC address sticky
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, is this patch still applicable after https://dev.openwrt.org/changeset/26426 ? ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2kti0ACgkQdputYINPTPMj+ACfYfKvrAKRsCDM3oRkxKY+mRlr 6ZIAn2FBtgV94pVXvMa9Lm0sbup2HWvf =xfM8 -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] iftop 1.0pre1 patches - now supporting IPV6
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
can you resend the patches as one big one?
svn diff package/feeds/packages/iftop/{Makefile,patches} \
iftop-update.patch
~ Jow
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk2kuN8ACgkQdputYINPTPPwXwCglWukaFVGda56dEP53/yi/FjR
3+AAn1aMqECM7XzWye/DXCd5wnxkWIMx
=wfB+
-END PGP SIGNATURE-
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Retaining WAN IP addresses across reboots
Please also note that the real time clock is important for knowing if the DHCP lease is still valid. Since most routers don't have a hardware RTC, there is no way to know it the DHCP lease is still valid before you get WAN connectivity to update the time with NTP. Nuno On Tue, Apr 12, 2011 at 05:15, Stefan Monnier monn...@iro.umontreal.ca wrote: I note that the file /tmp/state/network contains the interface, ip address, and expiration time of the WAN DHCP lease... I'm wondering what's involved in writing that information into somewhere persistent where it can be reused on reboot? You may want to start by replacing the /var symlink to /tmp by a real directory. OpenWRT should be using the /var/state/network filename, so after performing the above change, the file will be preserved across reboots. If not, report it as a bug. I'm not sure if OpenWRT will later start udhcpd in such a way as to take advantage of this pre-existing file, but that's a second step. Stefan ___ 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] 802.1Q VLAN support for Infineon ADM6996 switch chip for UBNT RouterStation
Hi, Peter, Thanks for you explanation. I have learned some insights on how the PHY/MAC works and MII. FYI, the patch works. I have tested with following /etc/config/network to send out the tagged packet: config 'switch' option 'name' 'eth1' option 'reset' '1' option 'enable_vlan' '1' option 'enable' '1' config 'switch_vlan' option 'device' 'eth1' option 'vlan' '1' option 'vid' '1' option 'ports' '0t 1t 5t' config 'switch_vlan' option 'device' 'eth1' option 'vlan' '2' option 'vid' '2' option 'ports' '0t 1t 5t' grep dmesg on eth: eth0: Atheros AG71xx at 0xb900, irq 4 eth0: connected to PHY at ag71xx-mdio:14 [uid=03026071, driver=Generic PHY] eth1: Atheros AG71xx at 0xba00, irq 5 *eth1: ADM6996FC model PHY found.* eth1: connected to PHY at ag71xx-mdio:00 [uid=10230007, driver=Infineon ADM6996] eth0: link up (100Mbps/Full duplex) eth0: link down eth0: link up (100Mbps/Full duplex) eth1: link up (100Mbps/Full duplex) Regards, Chun Yeow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
