Re: [OpenWrt-Devel] [PATCH] ramips: Rework ramips_eth to not require irqsave locking anymore
On 22/01/12 02:45, Roman Yeryomin wrote:
On 17 January 2012 11:42, Helmut Schaa helmut.sc...@googlemail.com wrote:
@@ -313,6 +312,7 @@ ramips_eth_tx_housekeeping(unsigned long ptr)
struct net_device *dev = (struct net_device*)ptr;
struct raeth_priv *priv = netdev_priv(dev);
+ spin_lock(priv-page_lock);
while ((priv-tx[priv-skb_free_idx].txd2 TX_DMA_DONE)
(priv-tx_skb[priv-skb_free_idx])) {
dev_kfree_skb_irq(priv-tx_skb[priv-skb_free_idx]);
@@ -321,6 +321,7 @@ ramips_eth_tx_housekeeping(unsigned long ptr)
if (priv-skb_free_idx = NUM_TX_DESC)
priv-skb_free_idx = 0;
}
+ spin_unlock(priv-page_lock);
ramips_fe_int_enable(RAMIPS_TX_DLY_INT);
}
Seems that spinlock here introduces performance hit in wifi-eth path.
Are you sure it's needed? Seems that it works fine also without this spinlock.
helmut,
can you verify this ?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DWC OTG USB, round 3
Hello,
22.01.2012 1:40, I wrote:
[...]
if matters). Without that, controller starts raising IN Token Received
with EP mismatch instead of normal Transfer complete bit. If I
understand it correctly, this means that Tx FIFO happened to be filled
in some particular order that controller disliked (and refused). I've
also found a fragment of code with possibly relevant comment (quoted
below). Indeed, apparently this EP mismatch event is not handled
anywhere in the driver (other than providing a line for dmesg). If it
should, then I'd guess it means the driver is just plain unfininshed and
I have no idea if it can even be fixed with a reasonable effort. Not
Nevermind. I've meanwhile found some code crafted by Amlogic (or whoever
it was) addressing exactly this problem. It does not work well because
it is buggy, however the idea is simple enough: do not push data to Tx
FIFO if it still holds some previous unsent data for another EP. I think
I can fix this workaround to actually do what it tries to.
(This somewhat reduces the whole usefullness of EPs probably, but at
least the damned thing stops throwing EP mismatch, I've checked)
Thank you.
NIkolai
sure what was meant exactly by one endpoint at once though.. Of course
usefull gadget drivers would probably employ 1 EPs, even
g_file_storage does so? Strange thing.
Thank you.
Nikolai
/* Reactive the EP */
dwc_otg_ep_activate(GET_CORE_IF(pcd), ep-dwc_ep);
if (ep-stopped) {
ep-stopped = 0;
/* If there is a request in the EP queue start it */
/** @todo FIXME: this causes an EP mismatch in DMA mode.
* epmismatch not yet implemented. */
/*
* Above fixme is solved by implmenting a tasklet to call the
* start_next_request(), outside of interrupt context at some
* time after the current time, after a clear-halt setup packet.
* Still need to implement ep mismatch in the future if a gadget
* ever uses more than one endpoint at once
*/
ep-queue_sof = 1;
tasklet_schedule (pcd-start_xfer_tasklet);
}
/* Start Control Status Phase */
do_setup_in_status_phase(pcd);
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH V2] ar71xx: support for kernel 3.1
On Wed, Jan 18, 2012 at 10:24 AM, Florian Fainelli flor...@openwrt.org wrote: Hello, On 01/18/12 08:47, Dave Taht wrote: On Wed, Jan 18, 2012 at 4:42 AM, Otto Solares Cabreraso...@guug.org wrote: On Thu, Dec 08, 2011 at 11:57:46PM +0100, Hartmut Knaack wrote: juhosg was working quite hard to get us out of sync, with decent support of nbd ;-) It took me a while, but we're finally back on the track. Minimum kernel version is probably still 3.1.1. Successfully tested with kernel 3.1.4 on a WR1043ND. Kernel version in the Makefile still needs to be adjusted manually. Any comments appreciated. Enjoy. Hi Harmut, do you have something for 3.2? I don't want to duplicate efforts :=) Personally I feel that skipping 3.2 entirely and going to 3.3 is the right course, as that has byte queue limits, a fixed implementation of RED, aRED, multiple improvements to SFQ that make it scale up much better, and behave better in the general case, and a new combination of SFQ and RED that looks very promising. Well sure these are interesting features to pull from an updated kernel version, but it is not a reason for skipping 3.2 entirely, especially if we feel like making this the base kernel version for releasing Attitude Adjustement at some point. Well, it's quite a long list (do a git log net/sched to see just the packet scheduling related fixes) and I wouldn't call the RED fixe(s) a 'feature', as red is part of openwrt's current qos system and has been broken for ~3 years. The SFQ head of line fix is a nice improvement on SFQ, too. As are the the additional abilities and extensions added in the 3.3 series. disregarding BQL for the nonce, these were helpful. they are mostly trivial to backport. d47a0ac7b66883987275598d6039f902f4410ca9 225d9b89c937633dfeec502741a174fe0bab5b9f 1ee5fa1e9970a16036e37c7b9d5ce81c778252fc ea6a5d3b97b768561db6358f15e4c84ced0f4f7e Tons more, but I understand that you have your own schedules to keep. http://linuxplumbersconf.org/2011/ocw/proposals/171 -- Florian -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add mostly complete support for Sitecom WL-341 v3 and other Sercomm IP1006RRv2 based boards
On Sat, Jan 21, 2012 at 6:36 PM, Roman Yeryomin leroi.li...@gmail.com wrote: On 21 January 2012 00:53, Marco Antonio Mauro marcu...@gmail.com wrote: This patch adds support for the Sitecom WL-341 v3 and other Sercomm IP1006RRv2 based boards for sysupgrade support and for the initial flash through pushbutton initiated recovery mode with the special partition table and fixes for the quirks and things required by the modified bootloader. There are two known bugs: 1. The LED configuration is broken -- only one led is working, an amber led, as I found no way to know which GPIOs were used for those. The board has 6 unlabeled leds, of which 1 is blue only and 5 are amber/blue. If I understand which GPIOs go to which leds I'll submit a patch later. I had this problem too and wrote a script to test gpios for leds and buttons (see attachment). Hope it'll help you (and maybe someone else). Note that it will not help if your leds are connected via shift registers (as on Belkin boards). Your script helped me (but I had to modify it slightly, the ls had to be ls -d else it wouldn't work) I found out 4 more leds, but I still miss 7 leds. Also, your script errors out on some pins: this is the log. Here the pins that return 0s are leds. root@OpenWrt:/tmp# ./blinker.bin /sys/class/gpio/gpiochip0 Testing pins from 0 to 23 pin 0 sh: write error: Device or resource busy output mode qbreaking input mode 1 1 1 breaking pin 1 sh: write error: Device or resource busy pin 2 sh: write error: Device or resource busy pin 3 sh: write error: Device or resource busy pin 4 sh: write error: Device or resource busy pin 5 sh: write error: Device or resource busy pin 6 sh: write error: Device or resource busy output mode qbreaking input mode 1 1 1 breaking pin 7 sh: write error: Device or resource busy pin 8 sh: write error: Device or resource busy pin 9 sh: write error: Device or resource busy pin 10 sh: write error: Device or resource busy output mode qbreaking input mode 0 0 0 qbreaking pin 11 sh: write error: Device or resource busy output mode qbreaking input mode 0 0 0 qbreaking pin 12 sh: write error: Device or resource busy output mode breaking input mode 0 0 0 breaking pin 13 sh: write error: Device or resource busy pin 14 sh: write error: Device or resource busy output mode breaking input mode 0 0 0 breaking pin 15 sh: write error: Device or resource busy pin 16 sh: write error: Device or resource busy pin 17 sh: write error: Device or resource busy pin 18 sh: write error: Device or resource busy pin 19 sh: write error: Device or resource busy output mode qbreaking input mode 1 1 1 breaking pin 20 sh: write error: Device or resource busy output mode qbreaking input mode 1 q1 1 breaking pin 21 sh: write error: Device or resource busy output mode qbreaking input mode 1 1 1 breaking pin 22 sh: write error: Device or resource busy pin 23 sh: write error: Device or resource busy /sys/class/gpio/gpiochip24 Testing pins from 24 to 39 pin 24 sh: write error: Device or resource busy pin 25 sh: write error: Device or resource busy pin 26 sh: write error: Device or resource busy pin 27 sh: write error: Device or resource busy pin 28 sh: write error: Device or resource busy pin 29 sh: write error: Device or resource busy pin 30 sh: write error: Device or resource busy pin 31 sh: write error: Device or resource busy pin 32 sh: write error: Device or resource busy pin 33 sh: write error: Device or resource busy pin 34 sh: write error: Device or resource busy pin 35 sh: write error: Device or resource busy pin 36 sh: write error: Device or resource busy pin 37 sh: write error: Device or resource busy pin 38 sh: write error: Device or resource busy pin 39 sh: write error: Device or resource busy /sys/class/gpio/gpiochip40 Testing pins from 40 to 51 pin 40 sh: write error: Device or resource busy pin 41 sh: write error: Device or resource busy pin 42 sh: write error: Device or resource busy pin 43 sh: write error: Device or resource busy pin 44 sh: write error: Device or resource busy pin 45 sh: write error: Device or resource busy pin 46 sh: write error: Device or resource busy pin 47 sh: write error: Device or resource busy pin 48 sh: write error: Device or resource busy pin 49 sh: write error: Device or resource busy pin 50 sh: write error: Device or resource busy pin 51 sh: write error: Device or resource busy 2. Wi-Fi is not working on my board probably because of the lack of RAM (the board only has 16MiB ram, but there is an empty slot for another ram chip,) but I don't know for sure. The driver loads but hostapd fails to load so I think it's not related to the specific device except for the lack of RAM. That's very strange, I don't have such problem with my 4/16 MB Sparklan WCR-150GN. I don't quite understand how it could be that it's low RAM problem if all kernel modules are loaded _before_ everything else? It's hostapd that fails executing, not the .kos that fail loading. -- Marcus905 GPG pubkey:
Re: [OpenWrt-Devel] [OpenWrt-Hackers] brcm63xx new boards support
Hello, On Sunday 22 January 2012 13:19:28 Álvaro Fernández Rojas wrote: Hi guys, There are some open tickets that contain patches which add support for new brcm63xx boards. These tickets are #10732 https://dev.openwrt.org/ticket/10732 and #10764 https://dev.openwrt.org/ticket/10764. In #10732 https://dev.openwrt.org/ticket/10732 you only need to replace the files that I provide. In this files I have also patched the number of buttons as suggested in #10717 https://dev.openwrt.org/ticket/10717. Once support has been added for this board, I can make the same set of patches for #10764 https://dev.openwrt.org/ticket/10764. Please submit the final patch to openwrt-devel following the documentation here: https://dev.openwrt.org/wiki/SubmittingPatches Greetings and thanks for your time ;). -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Users] Linksys WRT150N wireless supported in 10.03.1?
Hi Aaron, On 01/22/2012 04:54 AM, Aaron Z wrote: Resending as I used the wrong from address last time and it bounced. hmm at least I got your mails. It loaded and booted, but I am seeing some oddities. Not sure if these are related to being bleeding edge or what, but they are noticeable: The patch did what it was supposed to and I will merge it into trunk and Backfire branch. The other problems seam to be related to some other problems with trunk or with the wifi never used before. 1. luci (the web interface) times out and never loads The image I gave you did not contain luci so it will not load. 2. Installing packages does not seem to be working. When I run opkg update it gets to Inflating http://downloads.openwrt.org/snapshots/trunk/brcm47xx/packages/Packages.gz; then locks up my SSH session and I have to reconnect The image is a self build from trunk so with installing packages you could run into problems. But this problem is strange. 3. The reboot command does not seem to do anything (as determined by watching the LEDs and the response to ping). Did this work with 10.03.1? 4. It seems that ssh and scp lock up and force me to re-login frequently. No idea what it is related to, but it seems to do it every few minutes. Did this work with 10.03.1? 5. I see the OpenWrt wireless network after enabling the wireless, but I cannot connect to it (fails right away). When I run connection diagnostics, Windows 7 tells me Wireless association to this network failed. Windows did not receive any response from the wireless router or accesspoint Do you see anything interesting in the log regarding wifi while trying to connect? 6. The Wireless LED on the WAP does not turn on Probably something is wrong in the wireless driver. There is a know issue with the wireless chip used in your device, but I do not know, if you are seeing this issue or if it is already fixed: BCM4321: some cards do not work in DMA mode (PIO is needed). Attached are: 1. dmesg2.txt (15.5 KB, the output of dmesg) The log looks good to me at least OpenWrt finds your wifi and does not panic. ;-) 2. nvram2.txt (11.8 KB, the output of nvram show) 3. wireless2.txt (330 B, the contents of /var/config/wireless) Aaron Z I asked for the serial in the case the changes in the patch are causing a kernel panic and the device does not boot any more, so that you were able to recover or debug the issue, but it looks like it is not needed. But be aware that the normal serial port of a PC uses 12V and the serial TTL port of most embedded devices are using 3.3V Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] brcm63xx 96348A-122 board support (Comtrend 5365)
This adds support for Comtrend 5365. Open commits are
https://dev.openwrt.org/ticket/10732 and https://dev.openwrt.org/ticket/10717.
Also modifies increases the number of buttons supported by brcm63xx boards.
Directory to apply patch is: target/linux/brcm63xx
Signed-off-by: Álvaro Fernández Rojas nolt...@gmail.com
Index: patches-2.6.39/200-extended-platform-devices.patch
===
--- patches-2.6.39/200-extended-platform-devices.patch (revisión: 29846)
+++ patches-2.6.39/200-extended-platform-devices.patch (copia de trabajo)
@@ -15,7 +15,7 @@
@@ -61,6 +61,10 @@ struct board_info {
/* Buttons */
- struct gpio_button buttons[2];
+ struct gpio_button buttons[4];
+
+ /* Additional platform devices */
+ struct platform_device **devs;
Index: patches-2.6.39/457-board_96348A-122.patch
===
--- patches-2.6.39/457-board_96348A-122.patch (revisión: 0)
+++ patches-2.6.39/457-board_96348A-122.patch (revisión: 0)
@@ -0,0 +1,78 @@
+--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
b/arch/mips/bcm63xx/boards/board_bcm963xx.c
+@@ -1009,6 +1009,67 @@
+ },
+ };
+
++static struct board_info __initdata board_96348A_122 = {
++ .name = 96348A-122,
++ .expected_cpu_id= 0x6348,
++
++ .has_uart0 = 1,
++ .has_enet1 = 1,
++ .has_pci= 1,
++
++ .enet1 = {
++ .force_speed_100= 1,
++ .force_duplex_full = 1,
++ },
++
++ .has_ohci0 = 1,
++
++ .leds = {
++ {
++ .name = power,
++ .gpio = 0,
++ .active_low = 1,
++ .default_trigger = default-on,
++ },
++ {
++ .name = alarm,
++ .gpio = 2,
++ .active_low = 1,
++ },
++ {
++ .name = wps,
++ .gpio = 6,
++ .active_low = 1,
++ },
++ },
++ .buttons = {
++ {
++ .desc = reset,
++ .gpio = 33,
++ .active_low = 1,
++ .type = EV_KEY,
++ .code = KEY_RESTART,
++ .threshold = 3,
++ },
++ {
++ .desc = wifi,
++ .gpio = 34,
++ .active_low = 1,
++ .type = EV_KEY,
++ .code = BTN_0,
++ .threshold = 3,
++ },
++ {
++ .desc = wps,
++ .gpio = 35,
++ .active_low = 1,
++ .type = EV_KEY,
++ .code = KEY_WPS_BUTTON,
++ .threshold = 3,
++ },
++ },
++};
++
+ #endif
+
+ /*
+@@ -2068,6 +2129,7 @@
+ board_V2500V_BB,
+ board_V2110,
+ board_ct536_ct5621,
++ board_96348A_122,
+ #endif
+
+ #ifdef CONFIG_BCM63XX_CPU_6358
\ No newline at end of file
Cambios de propiedades en patches-2.6.39/457-board_96348A-122.patch
___
Añadido: svn:executable
+ *
Index: patches-2.6.39/500-ssb-add-callback-for-sprom.patch
===
--- patches-2.6.39/500-ssb-add-callback-for-sprom.patch (revisión: 29846)
+++ patches-2.6.39/500-ssb-add-callback-for-sprom.patch (copia de trabajo)
@@ -1,6 +1,6 @@
--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
+++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
-@@ -2128,6 +2128,17 @@ static struct ssb_sprom bcm63xx_sprom =
+@@ -2190,6 +2190,17 @@ static struct ssb_sprom bcm63xx_sprom =
.boardflags_lo = 0x2848,
.boardflags_hi = 0x,
};
@@ -18,7 +18,7 @@
#endif
/*
-@@ -2397,8 +2408,9 @@ int __init board_register_devices(void)
+@@ -2459,8 +2470,9 @@ int __init board_register_devices(void)
if (!board_get_mac_address(bcm63xx_sprom.il0mac)) {
memcpy(bcm63xx_sprom.et0mac, bcm63xx_sprom.il0mac, ETH_ALEN);
memcpy(bcm63xx_sprom.et1mac, bcm63xx_sprom.il0mac, ETH_ALEN);
Index: patches-2.6.39/100-reset_buttons.patch
===
--- patches-2.6.39/100-reset_buttons.patch (revisión: 29846)
+++ patches-2.6.39/100-reset_buttons.patch (copia de trabajo)
@@ -92,7 +92,7 @@
struct gpio_led leds[5];
+
+ /*
Re: [OpenWrt-Devel] brcm63xx 96348A-122 board support (Comtrend 5365)
On Sunday 22 January 2012 14:45:45 Álvaro Fernández Rojas wrote:
This adds support for Comtrend 5365. Open commits are
https://dev.openwrt.org/ticket/10732 and
https://dev.openwrt.org/ticket/10717. Also modifies increases the number
of buttons supported by brcm63xx boards. Directory to apply patch is:
target/linux/brcm63xx
Signed-off-by: Álvaro Fernández Rojas nolt...@gmail.com
Looks good, except that you missed updating the 3.0, 3.1 and 3.2 patches, can
you resubmit with these patches updated as well?
Thanks.
Index: patches-2.6.39/200-extended-platform-devices.patch
===
--- patches-2.6.39/200-extended-platform-devices.patch(revisión:
29846)
+++ patches-2.6.39/200-extended-platform-devices.patch(copia de
trabajo)
@@ -15,7 +15,7 @@
@@ -61,6 +61,10 @@ struct board_info {
/* Buttons */
- struct gpio_button buttons[2];
+ struct gpio_button buttons[4];
+
+/* Additional platform devices */
+struct platform_device **devs;
Index: patches-2.6.39/457-board_96348A-122.patch
===
--- patches-2.6.39/457-board_96348A-122.patch (revisión: 0)
+++ patches-2.6.39/457-board_96348A-122.patch (revisión: 0)
@@ -0,0 +1,78 @@
+--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
b/arch/mips/bcm63xx/boards/board_bcm963xx.c
+@@ -1009,6 +1009,67 @@
+ },
+ };
+
++static struct board_info __initdata board_96348A_122 = {
++.name = 96348A-122,
++.expected_cpu_id= 0x6348,
++
++.has_uart0 = 1,
++.has_enet1 = 1,
++.has_pci= 1,
++
++.enet1 = {
++.force_speed_100= 1,
++.force_duplex_full = 1,
++},
++
++.has_ohci0 = 1,
++
++.leds = {
++{
++.name = power,
++.gpio = 0,
++.active_low = 1,
++.default_trigger = default-on,
++},
++{
++.name = alarm,
++.gpio = 2,
++.active_low = 1,
++},
++{
++.name = wps,
++.gpio = 6,
++.active_low = 1,
++},
++},
++.buttons = {
++{
++.desc = reset,
++.gpio = 33,
++.active_low = 1,
++.type = EV_KEY,
++.code = KEY_RESTART,
++.threshold = 3,
++},
++{
++.desc = wifi,
++.gpio = 34,
++.active_low = 1,
++.type = EV_KEY,
++.code = BTN_0,
++.threshold = 3,
++},
++{
++.desc = wps,
++.gpio = 35,
++.active_low = 1,
++.type = EV_KEY,
++.code = KEY_WPS_BUTTON,
++.threshold = 3,
++},
++},
++};
++
+ #endif
+
+ /*
+@@ -2068,6 +2129,7 @@
+ board_V2500V_BB,
+ board_V2110,
+ board_ct536_ct5621,
++board_96348A_122,
+ #endif
+
+ #ifdef CONFIG_BCM63XX_CPU_6358
\ No newline at end of file
Cambios de propiedades en patches-2.6.39/457-board_96348A-122.patch
___
Añadido: svn:executable
+ *
Index: patches-2.6.39/500-ssb-add-callback-for-sprom.patch
===
--- patches-2.6.39/500-ssb-add-callback-for-sprom.patch (revisión:
29846)
+++ patches-2.6.39/500-ssb-add-callback-for-sprom.patch (copia de
trabajo)
@@ -1,6 +1,6 @@
--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
+++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
-@@ -2128,6 +2128,17 @@ static struct ssb_sprom bcm63xx_sprom =
+@@ -2190,6 +2190,17 @@ static struct ssb_sprom bcm63xx_sprom =
.boardflags_lo = 0x2848,
.boardflags_hi = 0x,
};
@@ -18,7 +18,7 @@
#endif
/*
-@@ -2397,8 +2408,9 @@ int __init board_register_devices(void)
+@@ -2459,8 +2470,9 @@ int __init board_register_devices(void)
if (!board_get_mac_address(bcm63xx_sprom.il0mac)) {
memcpy(bcm63xx_sprom.et0mac, bcm63xx_sprom.il0mac, ETH_ALEN);
memcpy(bcm63xx_sprom.et1mac, bcm63xx_sprom.il0mac, ETH_ALEN);
Index: patches-2.6.39/100-reset_buttons.patch
Re: [OpenWrt-Devel] brcm63xx 96348A-122 board support (Comtrend 5365)
On Sunday 22 January 2012 14:45:45 Álvaro Fernández Rojas wrote:
This adds support for Comtrend 5365. Open commits are
https://dev.openwrt.org/ticket/10732 and
https://dev.openwrt.org/ticket/10717. Also modifies increases the number
of buttons supported by brcm63xx boards. Directory to apply patch is:
target/linux/brcm63xx
Signed-off-by: Álvaro Fernández Rojas nolt...@gmail.com
I spoke too soon, nevermind :)
Index: patches-2.6.39/200-extended-platform-devices.patch
===
--- patches-2.6.39/200-extended-platform-devices.patch(revisión:
29846)
+++ patches-2.6.39/200-extended-platform-devices.patch(copia de
trabajo)
@@ -15,7 +15,7 @@
@@ -61,6 +61,10 @@ struct board_info {
/* Buttons */
- struct gpio_button buttons[2];
+ struct gpio_button buttons[4];
+
+/* Additional platform devices */
+struct platform_device **devs;
Index: patches-2.6.39/457-board_96348A-122.patch
===
--- patches-2.6.39/457-board_96348A-122.patch (revisión: 0)
+++ patches-2.6.39/457-board_96348A-122.patch (revisión: 0)
@@ -0,0 +1,78 @@
+--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
b/arch/mips/bcm63xx/boards/board_bcm963xx.c
+@@ -1009,6 +1009,67 @@
+ },
+ };
+
++static struct board_info __initdata board_96348A_122 = {
++.name = 96348A-122,
++.expected_cpu_id= 0x6348,
++
++.has_uart0 = 1,
++.has_enet1 = 1,
++.has_pci= 1,
++
++.enet1 = {
++.force_speed_100= 1,
++.force_duplex_full = 1,
++},
++
++.has_ohci0 = 1,
++
++.leds = {
++{
++.name = power,
++.gpio = 0,
++.active_low = 1,
++.default_trigger = default-on,
++},
++{
++.name = alarm,
++.gpio = 2,
++.active_low = 1,
++},
++{
++.name = wps,
++.gpio = 6,
++.active_low = 1,
++},
++},
++.buttons = {
++{
++.desc = reset,
++.gpio = 33,
++.active_low = 1,
++.type = EV_KEY,
++.code = KEY_RESTART,
++.threshold = 3,
++},
++{
++.desc = wifi,
++.gpio = 34,
++.active_low = 1,
++.type = EV_KEY,
++.code = BTN_0,
++.threshold = 3,
++},
++{
++.desc = wps,
++.gpio = 35,
++.active_low = 1,
++.type = EV_KEY,
++.code = KEY_WPS_BUTTON,
++.threshold = 3,
++},
++},
++};
++
+ #endif
+
+ /*
+@@ -2068,6 +2129,7 @@
+ board_V2500V_BB,
+ board_V2110,
+ board_ct536_ct5621,
++board_96348A_122,
+ #endif
+
+ #ifdef CONFIG_BCM63XX_CPU_6358
\ No newline at end of file
Cambios de propiedades en patches-2.6.39/457-board_96348A-122.patch
___
Añadido: svn:executable
+ *
Index: patches-2.6.39/500-ssb-add-callback-for-sprom.patch
===
--- patches-2.6.39/500-ssb-add-callback-for-sprom.patch (revisión:
29846)
+++ patches-2.6.39/500-ssb-add-callback-for-sprom.patch (copia de
trabajo)
@@ -1,6 +1,6 @@
--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
+++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
-@@ -2128,6 +2128,17 @@ static struct ssb_sprom bcm63xx_sprom =
+@@ -2190,6 +2190,17 @@ static struct ssb_sprom bcm63xx_sprom =
.boardflags_lo = 0x2848,
.boardflags_hi = 0x,
};
@@ -18,7 +18,7 @@
#endif
/*
-@@ -2397,8 +2408,9 @@ int __init board_register_devices(void)
+@@ -2459,8 +2470,9 @@ int __init board_register_devices(void)
if (!board_get_mac_address(bcm63xx_sprom.il0mac)) {
memcpy(bcm63xx_sprom.et0mac, bcm63xx_sprom.il0mac, ETH_ALEN);
memcpy(bcm63xx_sprom.et1mac, bcm63xx_sprom.il0mac, ETH_ALEN);
Index: patches-2.6.39/100-reset_buttons.patch
===
--- patches-2.6.39/100-reset_buttons.patch(revisión: 29846)
+++
Re: [OpenWrt-Devel] DSL support and luci integration
Ok, with a bit of further investigation, netlink doesn't actually seem too difficult … is there a process for registering new support (i.e. NETLINK_DSL) or is there some other way to do this? Could something else be re-used? I'm happy to have a go at a sample implementation, but I'm completely new to netlink, so a little help and a few pointers would be great. Cheers, Lee. On 20 Jan 2012, at 23:47, Philip Prindeville wrote: I'd sure like to see netlink being used to communicate speed/carrier changes up into userspace. On 1/20/12 12:20 AM, Lee Essen wrote: On 19 Jan 2012, at 22:17, John Crispin wrote: Anyway ... just a few ideas, interested in thoughts, I can post the current patches if there's interest, or happy to explore other ideas if I'm way off the mark. sure, show us your patch please ;) ___ Ok, these aren't in the right format for a couple of reasons (namely that I haven't got a LuCI tree checked out yet, and that I'm still working on the main script and haven't put it back into the main tree), but hopefully this will give you a feel for what I'm talking about…. Firstly the main dsl_control script (/etc/init.d/dsl_control) … used to stop/start and provide hardware specific stats, this is still work in progress, I'll tidy it up and add more functionality (and error checking) over the next couple of days, and build a proper patch... [snip] ___ 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
[OpenWrt-Devel] HELP : Can't patch config.sub in a package
Hello,
I'm trying to add a new processor type (lexra), but having
trouble patching the config.sub, that checks for recognizable
cpu-os-kernel identifier, used in some packages.
More specifically, I want the config.sub in iptables-1.4.10 to
recognize the 'lexra-openwrt-linux'.
I'm working on the trunk r29839.
In the first place, I thought I can do this as a piece of cake
by adding a patch file that adds couple of lines to the config.sub,
in ${BUILDROOT}/package/iptables/patches.
Then, after few attempts, I found out that the autoreconf or a similar
mechanism replaces
${BUILDROOT}/build_dir/${TARGETSPEC}/iptables-1.4.10/config.sub
during the build process so that it points (symlinks) to
${BUILDROOT}/staging_dir/host/share/automake-1.11/config.sub.
At this point, I turned around and added a similar patch to
${BUILDROOT}/tools/automake/patches.
I checked my result immediately after the automake build,
and confirmed that the config.sub was patched appropriately.
But, ...the next make V=99 only revealed that the
${BUILDROOT}/staging_dir/host/share/automake-1.11/config.sub
was magically overwritten to the original unpatched state.
Here's my question:
I'm not an expert on OpenWrt build system, and therefore
I believe this is some kind of magic, and I also believe that
I need a same kind of magic to overcome this problem.
Is there any?
Thanks in advance,
--- shinoda
P.S.
Here's some discussion:
Is the behavior of Modifying a generic build tool during a build
process for a single target considered legitimate?
Wouldn't it introduce some unexpected side effects?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] HELP : Can't patch config.sub in a package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I need a same kind of magic to overcome this problem. Is there any? Yes, patch scripts/config.sub - that is whats fored upon each package. Is the behavior of Modifying a generic build tool during a build process for a single target considered legitimate? Modifying the generic build tool to accept a new platform is certainly legitimate, nobody wants to patch a new CPU definition into each single package. Wouldn't it introduce some unexpected side effects? Its autohell so nobody can tell :) ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8cVnkACgkQdputYINPTPOmHQCeK+HDFGdXAfX8QjM4trm9B1uM RDoAoIB1Gu3rRoaRs3OVkviYxsET6qLx =7I17 -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Users] Linksys WRT150N wireless supported in 10.03.1?
Got the wireless to work today. I followed the directions at http://wiki.openwrt.org/doc/devel/debugging and ran killall -9 hostapd; /usr/sbin/hostapd -dd /var/run/hostapd-phy0.conf /tmp/hostapd.log from a SSH session, then tried to connect. Before I ran it, I would get a connection failed message as soon as I tried to connect. After I ran the above command, it failed once, then connected on the 2nd try. That log is attatched as WiFiLog1.txt. I rebooted by pulling the power cable (I am fairly certain that the reboot command worked in 10.03.1, but cannot say for certain) and I tried connecting to the wifi again. I got a connection failed message as soon as I tried to connect. After I ran the aforementioned command, I was able to connect immediately on the first try. That log is attached as WiFiLog2.txt. Is there a more effective and/or less intrusive way to log this data? I looked in /tmp/log, but the only things I see are lastlog and wtmp both of which are 0 byte files that claim to have been created on 1/1/1970. SSH and SCP both worked fine under 10.03.1. No lockups or reconnects that I remember. Package installation also worked. I was able to install the pciutils package without any drama. Let me know if I can provide any more data to help. Thanks Aaron Z - Original Message - From: Hauke Mehrtens ha...@hauke-m.de To: Aaron Z aar...@pls-net.org Cc: OpenWrt Development List openwrt-devel@lists.openwrt.org Sent: Sunday, January 22, 2012 8:16:52 AM Subject: Re: [OpenWrt-Users] Linksys WRT150N wireless supported in 10.03.1? Hi Aaron, On 01/22/2012 04:54 AM, Aaron Z wrote: Resending as I used the wrong from address last time and it bounced. hmm at least I got your mails. It loaded and booted, but I am seeing some oddities. Not sure if these are related to being bleeding edge or what, but they are noticeable: The patch did what it was supposed to and I will merge it into trunk and Backfire branch. The other problems seam to be related to some other problems with trunk or with the wifi never used before. 1. luci (the web interface) times out and never loads The image I gave you did not contain luci so it will not load. 2. Installing packages does not seem to be working. When I run opkg update it gets to Inflating http://downloads.openwrt.org/snapshots/trunk/brcm47xx/packages/Packages.gz; then locks up my SSH session and I have to reconnect The image is a self build from trunk so with installing packages you could run into problems. But this problem is strange. 3. The reboot command does not seem to do anything (as determined by watching the LEDs and the response to ping). Did this work with 10.03.1? 4. It seems that ssh and scp lock up and force me to re-login frequently. No idea what it is related to, but it seems to do it every few minutes. Did this work with 10.03.1? 5. I see the OpenWrt wireless network after enabling the wireless, but I cannot connect to it (fails right away). When I run connection diagnostics, Windows 7 tells me Wireless association to this network failed. Windows did not receive any response from the wireless router or accesspoint Do you see anything interesting in the log regarding wifi while trying to connect? 6. The Wireless LED on the WAP does not turn on Probably something is wrong in the wireless driver. There is a know issue with the wireless chip used in your device, but I do not know, if you are seeing this issue or if it is already fixed: BCM4321: some cards do not work in DMA mode (PIO is needed). Attached are: 1. dmesg2.txt (15.5 KB, the output of dmesg) The log looks good to me at least OpenWrt finds your wifi and does not panic. ;-) 2. nvram2.txt (11.8 KB, the output of nvram show) 3. wireless2.txt (330 B, the contents of /var/config/wireless) Aaron Z I asked for the serial in the case the changes in the patch are causing a kernel panic and the device does not boot any more, so that you were able to recover or debug the issue, but it looks like it is not needed. But be aware that the normal serial port of a PC uses 12V and the serial TTL port of most embedded devices are using 3.3V Hauke root@OpenWrt:~# killall -9 hostapd; /usr/sbin/hostapd -dd /var/run/hostapd-phy0.conf /tmp/hostapd.log #/tmp/hostapd.log random: Trying to read entropy from /dev/random Configuration file: /var/run/hostapd-phy0.conf nl80211: interface wlan0 in phy phy0 nl80211: Set mode ifindex 6 iftype 2 (STATION) nl80211: Failed to set interface 6 to mode 2: -16 (Device or resource busy) nl80211: Interface already in requested mode - ignore error netlink: Operstate: linkmode=1, operstate=5 nl80211: Using driver-based off-channel TX nl80211: Interface wlan0 is in bridge br-lan nl80211: Add own interface ifindex 5 nl80211: Add own interface ifindex 6 nl80211: Set mode ifindex 6 iftype 3 (AP) nl80211: Create interface iftype 6 (MONITOR) Failed to create interface
Re: [OpenWrt-Devel] HELP : Can't patch config.sub in a package
Jow, Yes, patch scripts/config.sub - that is whats fored upon each package. Yikes!!! Thanks a billion!!! I've been caught in this trap for half a day. Packages were built flawlessly. Is the behavior of Modifying a generic build tool during a build process for a single target considered legitimate? Modifying the generic build tool to accept a new platform is certainly legitimate, nobody wants to patch a new CPU definition into each single package. Ah, then, automake's config.sub should be patched once when it is built? :-) (There's no argument, just my personal thoughts.) --- shinoda On 2012/01/23, at 3:33, Jo-Philipp Wich wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I need a same kind of magic to overcome this problem. Is there any? Yes, patch scripts/config.sub - that is whats fored upon each package. Is the behavior of Modifying a generic build tool during a build process for a single target considered legitimate? Modifying the generic build tool to accept a new platform is certainly legitimate, nobody wants to patch a new CPU definition into each single package. Wouldn't it introduce some unexpected side effects? Its autohell so nobody can tell :) ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8cVnkACgkQdputYINPTPOmHQCeK+HDFGdXAfX8QjM4trm9B1uM RDoAoIB1Gu3rRoaRs3OVkviYxsET6qLx =7I17 -END PGP SIGNATURE- ___ 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] HELP : Can't patch config.sub in a package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. Modifying the generic build tool to accept a new platform is certainly legitimate, nobody wants to patch a new CPU definition into each single package. In general yes, in practice it should be unneeded though since we're forced to replace config.sub anyway in each package since all ship different versions of config.sub and not all of them are autoreconfigurable. See Build/configure/Default in include/package-defaults.mk, thats where we replace config.sub with our central scripts/ version in each package. ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8cXk4ACgkQdputYINPTPM3WgCfdVgW0f3ac8SKo/gmMKuFw87R RgUAoIbQj3NaCsR4m1dgpT85uOTh5w4/ =dQWJ -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add mostly complete support for Sitecom WL-341 v3 and other Sercomm IP1006RRv2 based boards
On 22 January 2012 14:13, Marco Antonio Mauro marcu...@gmail.com wrote: On Sat, Jan 21, 2012 at 6:36 PM, Roman Yeryomin leroi.li...@gmail.com wrote: On 21 January 2012 00:53, Marco Antonio Mauro marcu...@gmail.com wrote: This patch adds support for the Sitecom WL-341 v3 and other Sercomm IP1006RRv2 based boards for sysupgrade support and for the initial flash through pushbutton initiated recovery mode with the special partition table and fixes for the quirks and things required by the modified bootloader. There are two known bugs: 1. The LED configuration is broken -- only one led is working, an amber led, as I found no way to know which GPIOs were used for those. The board has 6 unlabeled leds, of which 1 is blue only and 5 are amber/blue. If I understand which GPIOs go to which leds I'll submit a patch later. I had this problem too and wrote a script to test gpios for leds and buttons (see attachment). Hope it'll help you (and maybe someone else). Note that it will not help if your leds are connected via shift registers (as on Belkin boards). Your script helped me (but I had to modify it slightly, the ls had to be ls -d else it wouldn't work) you are right, it should be with '-d' I found out 4 more leds, but I still miss 7 leds. Also, your script errors out on some pins: this is the log. sure, it returns error for those pins which are occupied by other modules Here the pins that return 0s are leds. Leds are tested in output mode which you are skipping. If you are testing leds only you should be skipping input mode, not output, and see which led blinks (it should blink 3 times if you don't interrupt it). Testing for buttons you should press it, while in input mode, and see if pin state changes. 2. Wi-Fi is not working on my board probably because of the lack of RAM (the board only has 16MiB ram, but there is an empty slot for another ram chip,) but I don't know for sure. The driver loads but hostapd fails to load so I think it's not related to the specific device except for the lack of RAM. That's very strange, I don't have such problem with my 4/16 MB Sparklan WCR-150GN. I don't quite understand how it could be that it's low RAM problem if all kernel modules are loaded _before_ everything else? It's hostapd that fails executing, not the .kos that fail loading. ah.. well, no problem with that anyway.. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips scripts updates
In this patch:
* rename Argus leds to avoid underscores
* rename Belkin F5D8235 v1 leds from f5d8234 to f5d8235
* remove Belkin F5D8235 v1 status led defined as storage led (it was
defined as usb led earlier, just in wrong place) - it should have
router led as in v2
* add Argus, Sparklan and Belkin F5D8235 v2 status leds
* add Belkin F5D8235 v1 and v2 usb leds
* fix Belkin F5D8235 v2 network config generation and mac address axtraction
* fix Sparklan board identification
* add Sparklan usb led (this board doesn't have usb connector by
default and the led is hidden also but if you are going to solder the
connector then you'll see the led too)
* add Sparklan network config generation and mac address extraction
* fix empty string test in network script and...
* ...sort case entries by the first board in the list
Adding an attachment too in case inline version is mangled.
Signed-off-by: Roman Yeryomin ro...@advem.lv
Index: target/linux/ramips/files/arch/mips/ralink/rt288x/mach-f5d8235-v1.c
===
--- a/target/linux/ramips/files/arch/mips/ralink/rt288x/mach-f5d8235-v1.c
(revision
29868)
+++ b/target/linux/ramips/files/arch/mips/ralink/rt288x/mach-f5d8235-v1.c
(working
copy)
@@ -86,11 +86,11 @@
static struct gpio_led f5d8235_leds_gpio[] __initdata = {
{
- .name = f5d8234-v1:blue:storage,
+ .name = f5d8235-v1:blue:storage,
.gpio = F5D8235_GPIO_LED_USB_BLUE,
.active_low = 1,
},{
- .name = f5d8234-v1:orange:storage,
+ .name = f5d8235-v1:orange:storage,
.gpio = F5D8235_GPIO_LED_USB_ORANGE,
.active_low = 1,
}
Index: target/linux/ramips/files/arch/mips/ralink/rt305x/mach-argus-atp52b.c
===
--- a/target/linux/ramips/files/arch/mips/ralink/rt305x/mach-argus-atp52b.c
(revision
29868)
+++ b/target/linux/ramips/files/arch/mips/ralink/rt305x/mach-argus-atp52b.c
(working
copy)
@@ -31,12 +31,12 @@
static struct gpio_led argus_atp52b_leds_gpio[] __initdata = {
{
- .name = argus_atp52b:green:run,
+ .name = argus-atp52b:green:run,
.gpio = ARGUS_ATP52B_GPIO_LED_RUN,
.active_low = 1,
},
{
- .name = argus_atp52b:amber:net,
+ .name = argus-atp52b:amber:net,
.gpio = ARGUS_ATP52B_GPIO_LED_NET,
.active_low = 1,
}
Index: target/linux/ramips/base-files/lib/ramips.sh
===
--- a/target/linux/ramips/base-files/lib/ramips.sh (revision 29868)
+++ b/target/linux/ramips/base-files/lib/ramips.sh (working copy)
@@ -98,7 +98,7 @@
*RT-N15)
name=rt-n15
;;
- *WCR-150GN)
+ *Sparklan WCR-150GN)
name=wcr-150gn
;;
*V22RW-2X2)
Index: target/linux/ramips/base-files/etc/uci-defaults/leds
===
--- a/target/linux/ramips/base-files/etc/uci-defaults/leds (revision 29868)
+++ b/target/linux/ramips/base-files/etc/uci-defaults/leds (working copy)
@@ -39,6 +39,12 @@
esr-9753)
set_wifi_led rt2800pci-phy0::radio
;;
+ f5d8235-v1)
+ set_usb_led f5d8235-v1:blue:storage
+ ;;
+ f5d8235-v2)
+ set_usb_led f5d8235v2:blue:storage
+ ;;
fonera20n)
set_usb_led fonera20n:amber:usb
;;
@@ -55,4 +61,7 @@
set_usb_led alfa:blue:usb
set_wifi_led rt2800pci-phy0::radio
;;
+ wcr-150gn)
+ set_usb_led wcr150gn:amber:user
+ ;;
esac
Index: target/linux/ramips/base-files/etc/uci-defaults/network
===
--- a/target/linux/ramips/base-files/etc/uci-defaults/network (revision 29868)
+++ b/target/linux/ramips/base-files/etc/uci-defaults/network (working copy)
@@ -18,12 +18,20 @@
case $board in
argus-atp52b | \
b2c | \
- f5d8235-v2 | \
nw718 | \
w502u)
ucidef_set_interfaces_lan_wan eth0.1 eth0.2
;;
+ f5d8235-v1 | \
+ rt-n15)
+ ucidef_set_interfaces_lan_wan eth0.1 eth0.2
+ ucidef_add_switch rtl8366s 1 1
+ ucidef_add_switch_vlan rtl8366s 1 1 2 3 4 5t
+ ucidef_add_switch_vlan rtl8366s 2 0 5t
+ ;;
+
+ f5d8235-v2 | \
wl-351)
ucidef_set_interfaces_lan_wan eth0.1 eth0.2
ucidef_add_switch rtl8366rb 1 1
@@ -31,18 +39,14 @@
Re: [OpenWrt-Devel] DSL support and luci integration
On 1/21/12 1:18 AM, Lee Essen wrote: On 20 Jan 2012, at 23:47, Philip Prindeville wrote: I'd sure like to see netlink being used to communicate speed/carrier changes up into userspace. Unfortunately there's absolutely no netlink support in the lantiq driver and I don't think any of that info is available elsewhere, I would have thought trying to add a netlink capability would be a bit extreme? (and probably well outside my capability) … and that would then need to be done for every subsequent DSL driver to maintain standardisation. There is an ioctl interface, which also works without the daemon running, which I did consider, but my thought was that this would require an extra binary to maintain (unless there's a simple lua ioctl interface, but I couldn't find one) and would have a lot less transparency than a script -- but I'm happy to knock something up to make use of this if it's considered a better approach. Regards, Lee. There aren't that many DSL flavors out there... Danube, Solos, Viking... that's probably 90% of the market I'm guessing. Once it gets done for one architecture, I'm sure someone on the linux-atm mailing list would port it to others. I might do it for the Solos if I have a working example of the netlink portion, then I can figure out how to interrogate the hardware for link quality changes. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DSL support and luci integration
You probably want to go through 'netdev' (net...@vger.kernel.org) for changes to Netlink. On 1/22/12 10:35 AM, Lee Essen wrote: Ok, with a bit of further investigation, netlink doesn't actually seem too difficult … is there a process for registering new support (i.e. NETLINK_DSL) or is there some other way to do this? Could something else be re-used? I'm happy to have a go at a sample implementation, but I'm completely new to netlink, so a little help and a few pointers would be great. Cheers, Lee. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Users] Linksys WRT150N wireless supported in 10.03.1?
2012/1/22 Hauke Mehrtens ha...@hauke-m.de: 6. The Wireless LED on the WAP does not turn on Probably something is wrong in the wireless driver. There is a know issue with the wireless chip used in your device, but I do not know, if you are seeing this issue or if it is already fixed: BCM4321: some cards do not work in DMA mode (PIO is needed). It was fixed almost half a year ago by: ssb: fix DMA translation for some specific boards b43: fix DMA on some bugged hardware Not sure about the LED problem. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] x86 sysupgrade
For those of us using x86-based platforms we'd like to have a way to do in-place upgrades without losing configuration state. I understand that (a) we are a smaller community, and (b) the sizing constraints of x86 platforms is very different than (say) a WRT54G-L... memory on a Alix or Geos is usually 128MB or better, and 256MB flash or better. Would anyone be willing to work on this? I might have a platform (like an Alix 2D13) I can contribute to the effort. I'd work on it, but don't know a lot about MTD, etc. But if someone is willing to walk me through it, I can make an attempt. Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Users] Serious business hardware
On 22/01/12 02:04 AM, cptsp...@gmx.de wrote: Hi! Maybe you want to look at the ALIX boards by PC Engines. They fulfill most of your requirements, but they one have 100 Mbit/s LAN. Ingwer On 2012-01-18 19:24, Weedy wrote: Requirements: - 500mhz or more - 128mb ram+, DDR+ - 32mb flash - 2 gigabit ports (but I would like 4) - 1 minipci, bonus points for more - cf/sd card slot - available enclosure that isn't more then 75% the cost of the board Thank you. I check them and ruled them out already. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
