[OpenWrt-Devel] [PATCH] Provide SPROM for WRT54G3GV2
Hello This patch creates and fills a fallback SPROM for broadcom devices with a wireless nic connected via pci. It also reads a few more parameters from nvram. Bernhard 970-WRT54G3GV2-wireless.patch Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] different mtd erase size for a specific partion possible?
There is already a patch for this in openwrt, so it should work (in theory).
Do you use trunk or backfire or something older?
2010/5/25 Matthias Buecher / Germany m...@maddes.net:
Today I checked out how to access the U-Boot variables of my WRT350N v2
(Orion) from Linux.
Installed uboot-envtools and created a fitting /etc/fw_env.config:
# WRT350N v2
# MTD device name Device offset Env. size Flash sector size
/dev/mtd5 0x0003c000 0x2000 0x1000
I can read all U-Boot env vars, but not change any.
This seems to be a problem of the huge erase site 0x0001 of mtd.
Can I specify a separate erase size for the U-Boot partition?
static struct mtd_partition wrt350n_v2_nor_flash_partitions[] = {
{
...
}, {
.name = u-boot,
.offset = 0x007c,
.size = 0x0004,
}, {
...
},
};
linux: arch/arm/mach-orion5x/wrt350n-v2-setup.c
OpenWrt: target/linux/orion/patches/100-openwrt_partition_map.patch
Maddes
--
http://www.maddes.net/
Home: Earth / Germany / Ruhr-Area
___
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] different mtd erase size for a specific partion possible?
https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/patches-2.6.32/222-partial_eraseblock_write.patch
2010/5/25 Matthias Buecher / Germany m...@maddes.net:
Both, backfire and latest trunk.
Can you hint me where this patch is?
Maddes
On 25.05.2010 21:59, Bernhard Loos wrote:
There is already a patch for this in openwrt, so it should work (in theory).
Do you use trunk or backfire or something older?
2010/5/25 Matthias Buecher / Germany m...@maddes.net:
Today I checked out how to access the U-Boot variables of my WRT350N v2
(Orion) from Linux.
Installed uboot-envtools and created a fitting /etc/fw_env.config:
# WRT350N v2
# MTD device name Device offset Env. size Flash sector size
/dev/mtd5 0x0003c000 0x2000 0x1000
I can read all U-Boot env vars, but not change any.
This seems to be a problem of the huge erase site 0x0001 of mtd.
Can I specify a separate erase size for the U-Boot partition?
static struct mtd_partition wrt350n_v2_nor_flash_partitions[] = {
{
...
}, {
.name = u-boot,
.offset = 0x007c,
.size = 0x0004,
}, {
...
},
};
linux: arch/arm/mach-orion5x/wrt350n-v2-setup.c
OpenWrt: target/linux/orion/patches/100-openwrt_partition_map.patch
Maddes
--
http://www.maddes.net/
Home: Earth / Germany / Ruhr-Area
___
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 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] different mtd erase size for a specific partion possible?
It should work out of the box with the patch.
It will (should) set the erase size to the right value.
2010/5/26 Matthias Buecher / Germany m...@maddes.net:
So I can mark the partition with MTD_ERASE_PARTIAL, but I can not see
how I can limit erase size to 0x1000 so that only mtd offsets 0x3c000 to
0x3dfff gets erased.
The last 128 bytes (0x3ff80 - 3) of the mtd partition on WRT350N v2
are very important and shouldn't be touched.
Or should this work out of the box with uboot-envtools?
Maddes
On 25.05.2010 23:14, Bernhard Loos wrote:
https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/patches-2.6.32/222-partial_eraseblock_write.patch
2010/5/25 Matthias Buecher / Germany m...@maddes.net:
Both, backfire and latest trunk.
Can you hint me where this patch is?
Maddes
On 25.05.2010 21:59, Bernhard Loos wrote:
There is already a patch for this in openwrt, so it should work (in
theory).
Do you use trunk or backfire or something older?
2010/5/25 Matthias Buecher / Germany m...@maddes.net:
Today I checked out how to access the U-Boot variables of my WRT350N v2
(Orion) from Linux.
Installed uboot-envtools and created a fitting /etc/fw_env.config:
# WRT350N v2
# MTD device name Device offset Env. size Flash sector size
/dev/mtd5 0x0003c000 0x2000 0x1000
I can read all U-Boot env vars, but not change any.
This seems to be a problem of the huge erase site 0x0001 of mtd.
Can I specify a separate erase size for the U-Boot partition?
static struct mtd_partition wrt350n_v2_nor_flash_partitions[] = {
{
...
}, {
.name = u-boot,
.offset = 0x007c,
.size = 0x0004,
}, {
...
},
};
linux: arch/arm/mach-orion5x/wrt350n-v2-setup.c
OpenWrt: target/linux/orion/patches/100-openwrt_partition_map.patch
Maddes
--
http://www.maddes.net/
Home: Earth / Germany / Ruhr-Area
___
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 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 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] failed to install feed oprofile
You also have to enable it in menuconfig. 2010/5/24 oii...@aol.com: $ find packages/ -name oprofile package/feeds/packages/oprofile I don't quite understant that but there's no opcontrol related programs after the system is running. am I doing anything incorrectly? -Original Message- From: oiioeu oii...@aol.com To: openwrt-devel openwrt-devel@lists.openwrt.org Sent: Mon, May 24, 2010 4:27 pm Subject: [OpenWrt-Devel] failed to install feed oprofile in r21560 I couldn't find oprofile option in menuconfig, what I did was $ ./scripts/feeds update $ ./scripts/feeds install -d y oprofile anyone ever successfully installed oprofile? Thanks! ___ 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 mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Kernel patch in trunk (version 21251) to support Netgear WNR3500L
Your patch contains a driver for the serial flash chip on the wnr3500l, but it's kinda ugly (excessive ioremaps, duplicated defines, global statics, ...). If you could clean this up, it would have a chance of getting accepted. Bernhard 2010/5/20 Tathagata Das tathag...@alumnux.com: What do you mean to say clean up the flash driver you have ? Regards, Tathagata Bernhard Loos wrote: 2010/5/17 Tathagata Das tathag...@alumnux.com: Okay, so I will start working on those drivers (serial and wired). Does current version of OpenWRT trunk supports WNR3500L ? Otherwise I need to download latest trunk, modify it to run on WNR3500L and then concentrate on drivers. I doesn't but the difference from your version to latest trunk is pretty small. If you elaborate the idea of spi master driver then it would help me to proceed faster. I checked out the flash controller code and it isn't plain spi, the chipcommon core seems to have some control logic for the flash. So if you clean up the flash driver you have, it should be enough. Having a proper bus driver for the serial flash code would be nice, but it's probably overkill. Regards, Tathagata Bernhard Loos wrote: 2010/5/17 Tathagata Das tathag...@alumnux.com: Hi, I have used source code of version 21251. It might be possible that some fixes has been made after that version which is not reflected in my code. So if I use latest code then that issue will be resolved. The bugs are in the patch, not in the code already in openwrt, so it won't. You said that kernel patch should not contain any code under #ifdef. But it may happen that those changes are specific to WNR3500L. Then what should be the porting process ? Something like this isn't wnr3500l speific: +#ifndef CONFIG_WNR3500L void plat_irq_dispatch(void) +#else +void asmlinkage plat_irq_dispatch(void) +#endif If there is stuff specific to the wnr, you should wrap it in an #ifdef-#endif, not #ifdef-#else-#endif, because it has to be possible to build a kernel which supports both the old and socs. If you tell how to move this patch into a proper form, I can do this. However I have also one WNR3500L, nothing else. Those are the worst problems, but you will spend a lot of time and effort duplicating work I already did. I really suggest you spend your time on some other area, as for example proper serial flash support (a spi master driver) or network (both wired and wireless). Regards, Tathagata Bernhard Loos wrote: Hello Thanks for you work, but as I already told you in the mail for your last patch, this is not really useable as it is right now. You can't simply go around and wrap everything you want to add in an #ifdef, especially not things like that: +#ifndef CONFIG_WNR3500L void plat_irq_dispatch(void) +#else +void asmlinkage plat_irq_dispatch(void) +#endif This is ugly as hell and unneeded. Such a thing will never get accepted into mainline. Those ifdefs also make it impossible to build a kernel supporting both the new and the old bus type. And this is even besides all the bugs still present in this code. I am working on getting this patch into a proper form, but it's a slow process, partly because I don't have that much time and partially because I only have an 4716 device and nothing older. If you could turn you serial driver into a proper spi master driver and hook the flash up to, this would be very helpful. Changing the flash map shouldn't be necessary, the rootfs_data partition is created automatically. Bernhard 2010/5/14 Tathagata Das tathag...@alumnux.com: Hi, Attached is the kernel patch to support Netgear WNR3500L. All changes are made under CONFIG_WNR3500L. I have used trunk source code of version number 21251 to create this kernel patch. Regards, Tathagata tathag...@alumnux.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Kernel patch in trunk (version 21251) to support Netgear WNR3500L
2010/5/17 Tathagata Das tathag...@alumnux.com: Okay, so I will start working on those drivers (serial and wired). Does current version of OpenWRT trunk supports WNR3500L ? Otherwise I need to download latest trunk, modify it to run on WNR3500L and then concentrate on drivers. I doesn't but the difference from your version to latest trunk is pretty small. If you elaborate the idea of spi master driver then it would help me to proceed faster. I checked out the flash controller code and it isn't plain spi, the chipcommon core seems to have some control logic for the flash. So if you clean up the flash driver you have, it should be enough. Having a proper bus driver for the serial flash code would be nice, but it's probably overkill. Regards, Tathagata Bernhard Loos wrote: 2010/5/17 Tathagata Das tathag...@alumnux.com: Hi, I have used source code of version 21251. It might be possible that some fixes has been made after that version which is not reflected in my code. So if I use latest code then that issue will be resolved. The bugs are in the patch, not in the code already in openwrt, so it won't. You said that kernel patch should not contain any code under #ifdef. But it may happen that those changes are specific to WNR3500L. Then what should be the porting process ? Something like this isn't wnr3500l speific: +#ifndef CONFIG_WNR3500L void plat_irq_dispatch(void) +#else +void asmlinkage plat_irq_dispatch(void) +#endif If there is stuff specific to the wnr, you should wrap it in an #ifdef-#endif, not #ifdef-#else-#endif, because it has to be possible to build a kernel which supports both the old and socs. If you tell how to move this patch into a proper form, I can do this. However I have also one WNR3500L, nothing else. Those are the worst problems, but you will spend a lot of time and effort duplicating work I already did. I really suggest you spend your time on some other area, as for example proper serial flash support (a spi master driver) or network (both wired and wireless). Regards, Tathagata Bernhard Loos wrote: Hello Thanks for you work, but as I already told you in the mail for your last patch, this is not really useable as it is right now. You can't simply go around and wrap everything you want to add in an #ifdef, especially not things like that: +#ifndef CONFIG_WNR3500L void plat_irq_dispatch(void) +#else +void asmlinkage plat_irq_dispatch(void) +#endif This is ugly as hell and unneeded. Such a thing will never get accepted into mainline. Those ifdefs also make it impossible to build a kernel supporting both the new and the old bus type. And this is even besides all the bugs still present in this code. I am working on getting this patch into a proper form, but it's a slow process, partly because I don't have that much time and partially because I only have an 4716 device and nothing older. If you could turn you serial driver into a proper spi master driver and hook the flash up to, this would be very helpful. Changing the flash map shouldn't be necessary, the rootfs_data partition is created automatically. Bernhard 2010/5/14 Tathagata Das tathag...@alumnux.com: Hi, Attached is the kernel patch to support Netgear WNR3500L. All changes are made under CONFIG_WNR3500L. I have used trunk source code of version number 21251 to create this kernel patch. Regards, Tathagata tathag...@alumnux.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Kernel patch in trunk (version 21251) to support Netgear WNR3500L
2010/5/17 Tathagata Das tathag...@alumnux.com: Hi, I have used source code of version 21251. It might be possible that some fixes has been made after that version which is not reflected in my code. So if I use latest code then that issue will be resolved. The bugs are in the patch, not in the code already in openwrt, so it won't. You said that kernel patch should not contain any code under #ifdef. But it may happen that those changes are specific to WNR3500L. Then what should be the porting process ? Something like this isn't wnr3500l speific: +#ifndef CONFIG_WNR3500L void plat_irq_dispatch(void) +#else +void asmlinkage plat_irq_dispatch(void) +#endif If there is stuff specific to the wnr, you should wrap it in an #ifdef-#endif, not #ifdef-#else-#endif, because it has to be possible to build a kernel which supports both the old and socs. If you tell how to move this patch into a proper form, I can do this. However I have also one WNR3500L, nothing else. Those are the worst problems, but you will spend a lot of time and effort duplicating work I already did. I really suggest you spend your time on some other area, as for example proper serial flash support (a spi master driver) or network (both wired and wireless). Regards, Tathagata Bernhard Loos wrote: Hello Thanks for you work, but as I already told you in the mail for your last patch, this is not really useable as it is right now. You can't simply go around and wrap everything you want to add in an #ifdef, especially not things like that: +#ifndef CONFIG_WNR3500L void plat_irq_dispatch(void) +#else +void asmlinkage plat_irq_dispatch(void) +#endif This is ugly as hell and unneeded. Such a thing will never get accepted into mainline. Those ifdefs also make it impossible to build a kernel supporting both the new and the old bus type. And this is even besides all the bugs still present in this code. I am working on getting this patch into a proper form, but it's a slow process, partly because I don't have that much time and partially because I only have an 4716 device and nothing older. If you could turn you serial driver into a proper spi master driver and hook the flash up to, this would be very helpful. Changing the flash map shouldn't be necessary, the rootfs_data partition is created automatically. Bernhard 2010/5/14 Tathagata Das tathag...@alumnux.com: Hi, Attached is the kernel patch to support Netgear WNR3500L. All changes are made under CONFIG_WNR3500L. I have used trunk source code of version number 21251 to create this kernel patch. Regards, Tathagata tathag...@alumnux.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BRCM4716 support part 4
Hello
Thank you for tracking this down.
Here are two new patches for the scan stuff, hopefully working now.
Bernhard Loos
2010/5/15 Hauke Mehrtens ha...@hauke-m.de:
Am 14.05.2010 00:25, schrieb Bernhard Loos:
Hello
Do you have any clue, what could produce b43? Because, after looking
at the code, I'm kinda at a loss, where this comes from. And do you
know, which patch exactly produces the problem?
I will split the patch up, but it may take a day or two, until I have
the time. Some of the other patches are possible also mixed up.
Your patch unfortunetly doesn't work as a general solution, because
the 4716 hangs, if any of the id registers is accessed.
Thanks again, for looking at this.
Bernhard
2010/5/13 Hauke Mehrtens ha...@hauke-m.de:
Am 13.05.2010 20:54, schrieb Hauke Mehrtens:
Hi Bernhard,
I have changed the code to do the same things it did before your changes
at that position. My patch is attached.
With this patch all ssb Cores are found, but I get a oops in b43 driver
now. Reserved instruction in kernel code
I have not activated symbols will do now. Here is the log for now:
http://hauke-m.de/fileadmin/openwrt/brcm47xx-log/boot-not-working2.log
Could you please split 952-ai-scan.patch into two patches. One just
reorganizing the existing code without changing any functionality and
one adding the ai scan.
Hauke
Hi Bernhard,
I get the following kernel oops with your patches:
Reserved instruction in kernel code[#1]:
...
Call Trace:
[80cc4908] b43info+0x560/0x2754 [b43]
[8018a27c] ssb_device_probe+0x44/0x80
[80167d24] driver_probe_device+0x13c/0x28c
[800e78ec] sysfs_create_dir+0x44/0x68
[8012b83c] kobject_get+0x1c/0x30
[80167e74] __driver_attach+0x0/0xa4
[80167ee0] __driver_attach+0x6c/0xa4
[8012bf2c] kobject_add_varg+0x28/0x78
[801673dc] bus_for_each_dev+0x64/0xb4
[8012bfbc] kobject_init_and_add+0x40/0x58
[80166b2c] bus_add_driver+0xd0/0x274
[80056d20] load_module+0x1980/0x1b4c
[80168290] driver_register+0xe0/0x19c
[80ce8000] init_module+0x0/0x70 [b43]
[80ce8020] init_module+0x20/0x70 [b43]
[8000d650] do_one_initcall+0x70/0x1f4
[800437f0] blocking_notifier_call_chain+0x14/0x20
[80057408] sys_init_module+0xe0/0x224
[80092924] sys_close+0x9c/0xe4
[80003230] stack_done+0x20/0x3c
Full log:
http://hauke-m.de/fileadmin/openwrt/brcm47xx-log/boot-not-working3.log
Hauke
Hi Bernhard,
I found the cause of the problem. It was not in your patch series, but
the some other openwrt parts. While building b43 from compat-wireless
CONFIG_SSB_BLOCKIO was activated, when building ssb in the kernel is was
deactivated. This causes the struct ssb_bus_ops to be different in ssb
and b43. The Pointers to device_enable and so on are wrong. When they
were called it jumped to somewhere else in the code.
This problem is fixed in r21449 https://dev.openwrt.org/changeset/21449
Now everything works for me like before with your patches when also
adding the attached patch.
In function ssb_bus_scan rev is not the same as bus-chip_rev.
Hauke
Index: target/linux/brcm47xx/patches-2.6.32/952-ssb-scan_rework.patch
===
--- target/linux/brcm47xx/patches-2.6.32/952-ssb-scan_rework.patch (revision 0)
+++ target/linux/brcm47xx/patches-2.6.32/952-ssb-scan_rework.patch (revision 0)
@@ -0,0 +1,305 @@
+Index: linux-2.6.32.12/drivers/ssb/scan.c
+===
+--- linux-2.6.32.12.orig/drivers/ssb/scan.c 2010-05-11 18:04:00.0 +0200
linux-2.6.32.12/drivers/ssb/scan.c 2010-05-11 18:14:32.810514610 +0200
+@@ -2,6 +2,7 @@
+ * Sonics Silicon Backplane
+ * Bus scanning
+ *
++ * Copyright (C) 2010 Bernhard Loos bernhardl...@googlemail.com
+ * Copyright (C) 2005-2007 Michael Buesch m...@bu3sch.de
+ * Copyright (C) 2005 Martin Langer martin-lan...@gmx.de
+ * Copyright (C) 2005 Stefano Brivio s...@riseup.net
+@@ -17,11 +18,6 @@
+ #include linux/pci.h
+ #include linux/io.h
+
+-#include pcmcia/cs_types.h
+-#include pcmcia/cs.h
+-#include pcmcia/cistpl.h
+-#include pcmcia/ds.h
+-
+ #include ssb_private.h
+
+
+@@ -276,15 +272,126 @@
+ return 0;
+ }
+
++/* returns 0 if the core is ok and -1 if the core should be ignored */
++static int ssb_bus_check_core(struct ssb_device *dev, int *nr_80211_cores, int corenum)
++{
++ struct ssb_bus *bus = dev-bus;
++
++ printk(KERN_INFO PFX
++ Core %d found: %s
++ (cc 0x%03X, rev 0x%02X, vendor 0x%04X)\n,
++ corenum, ssb_core_name(dev-id.coreid),
++ dev-id.coreid, dev-id.revision, dev-id.vendor);
++
++ switch (dev-id.coreid) {
++ case SSB_DEV_80211:
++ (*nr_80211_cores)++;
++ if (*nr_80211_cores 1) {
++ if (!we_support_multiple_80211_cores(bus)) {
++ssb_dprintk(KERN_INFO PFX Ignoring additional
++ 802.11 core\n);
++return -1;
++ }
++ }
++ break;
++ case SSB_DEV_EXTIF:
++#ifdef CONFIG_SSB_DRIVER_EXTIF
++ if (bus-extif.dev) {
++ ssb_printk
[OpenWrt-Devel] State of the sdhc package
Hello As nobody seems to care very much about this package and not many people if any can test it, I would suggest moving it out of trunk and to packages and then trying to find a maintainer for it. And maybe commit the patches provided for it. Bernhard ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] PHP5.2.6 ipk form AR71XX (Ubiquiti RouterStation)
The ar71xx is a mips. But make sure you get the right version of the package, trunk snapshots won't work with 8.09. 2010/5/13 Andres Duran du...@invernadero.net: Hello, sorry for my bad english. I'm a student of IT from spain. I have an aplication written in PHP5 of my university that require PHP5.2.X, this application not run under PHP5.3.X. I buy a Ubiquiti RouterStation, and I can not found in google the compiled version of PHP5.2, I found two links that are older and now not found. These links had the ipkg version 5.2.6 of php5. The links are: http://webcache.googleusercontent.com/search?q=cache:Ro6vj-cGbNQJ:stasoft.net/files/openwrt/ar71xx/Packages+%22Architecture:+ar71xx%22+php5+5.2cd=1hl=enct=clnkclient=safari and http://downloads-openwrt-org.bugaco.com/snapshots/trunk/ar71xx/packages/Packages Also I was tried to install this ipkg: http://downloads.openwrt.org/kamikaze/8.09/ar71xx/packages/php5_5.2.6-2_mips.ipk but the Architecture of this package is: mips and my Ubiquiti RouterStation has OpenWRT and this version require architecture: ar71xx ¿Please could you tell me where I can find an ipkg package of PHP 5.2.X for my Ubiquiti RouterStation? Thanks in advice! Andrés. ___ 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] PHP5.2.6 ipk form AR71XX (Ubiquiti RouterStation)
You can flash the the kernel only by using mtd directly, but you may need the lzma compressed one. Make also sure to update the rootfs at the same time. If you want to use the webinterface or sysupgrade, you need the *-sysupgrade.bin image. 2010/5/13 Andres Duran du...@invernadero.net: Thanks for the fast response. But I was try to load http://downloads.openwrt.org/kamikaze/8.09/ar71xx/openwrt-ar71xx-vmlinux.bin in my RouterStation using the web interface and the RouterStation said that wrong binary file. ¿Can I load this binary to my RouterStation with some way? I'm actually using this binary for my RouterStation: http://downloads.openwrt.org/snapshots/trunk/ar71xx/openwrt-ar71xx-ubnt-rs-squashfs-factory.bin Thanks! Andrés 2010/5/13 Bernhard Loos bernhardl...@googlemail.com: The ar71xx is a mips. But make sure you get the right version of the package, trunk snapshots won't work with 8.09. 2010/5/13 Andres Duran du...@invernadero.net: Hello, sorry for my bad english. I'm a student of IT from spain. I have an aplication written in PHP5 of my university that require PHP5.2.X, this application not run under PHP5.3.X. I buy a Ubiquiti RouterStation, and I can not found in google the compiled version of PHP5.2, I found two links that are older and now not found. These links had the ipkg version 5.2.6 of php5. The links are: http://webcache.googleusercontent.com/search?q=cache:Ro6vj-cGbNQJ:stasoft.net/files/openwrt/ar71xx/Packages+%22Architecture:+ar71xx%22+php5+5.2cd=1hl=enct=clnkclient=safari and http://downloads-openwrt-org.bugaco.com/snapshots/trunk/ar71xx/packages/Packages Also I was tried to install this ipkg: http://downloads.openwrt.org/kamikaze/8.09/ar71xx/packages/php5_5.2.6-2_mips.ipk but the Architecture of this package is: mips and my Ubiquiti RouterStation has OpenWRT and this version require architecture: ar71xx ¿Please could you tell me where I can find an ipkg package of PHP 5.2.X for my Ubiquiti RouterStation? Thanks in advice! Andrés. ___ 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 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] BRCM4716 support part 4
Hello Around line 583 in drivers/sbb/scan.c, there should be an if (bus-chip_rev =4). Could you remove the if and always execute the code which assigns bus-nr_devices? This shouldn't be a problem, because the bits for the device number should be zero on cores which don't support it. I can also provide a new patch, if you like it better. Bernhard 2010/5/13 Hauke Mehrtens ha...@hauke-m.de: Am 13.05.2010 01:08, schrieb Bernhard Loos: Sorry, I goofed up while porting the patch to latest trunk, as I did develop this on an older svn revision. The line should be ssb_chipco_pll_write(cc, 0xa, 0x380005C0); Bernhard Hi Bernhard, Now it compiles for me. I have just installed it on my Asus WL-500GP v1 and it boots and Ethernet is working, but wireless is not working any more. I found some differences in the dmesg output: Without your patches (working): PCI: Setting latency timer of device :00:02.0 to 64 ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243) ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09, vendor 0x4243) ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243) ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243) ssb: SPROM revision 2 detected. ssb: Sonics Silicon Backplane found on PCI device :00:02.0 NET: Registered protocol family 2 With your patches (not working): PCI: Setting latency timer of device :00:02.0 to 64 ssb: CHIPID not in nrcores fallback list ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243) ssb: SPROM revision 2 detected. ssb: Sonics Silicon Backplane found on PCI device :00:02.0 NET: Registered protocol family 2 The full dmesg output can be found here: http://hauke-m.de/fileadmin/openwrt/brcm47xx-log/boot-working.log http://hauke-m.de/fileadmin/openwrt/brcm47xx-log/boot-not-working.log Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BRCM4716 support part 4
Hello Do you have any clue, what could produce b43? Because, after looking at the code, I'm kinda at a loss, where this comes from. And do you know, which patch exactly produces the problem? I will split the patch up, but it may take a day or two, until I have the time. Some of the other patches are possible also mixed up. Your patch unfortunetly doesn't work as a general solution, because the 4716 hangs, if any of the id registers is accessed. Thanks again, for looking at this. Bernhard 2010/5/13 Hauke Mehrtens ha...@hauke-m.de: Am 13.05.2010 20:54, schrieb Hauke Mehrtens: Am 13.05.2010 18:52, schrieb Bernhard Loos: Hello Around line 583 in drivers/sbb/scan.c, there should be an if (bus-chip_rev =4). Could you remove the if and always execute the code which assigns bus-nr_devices? This shouldn't be a problem, because the bits for the device number should be zero on cores which don't support it. I can also provide a new patch, if you like it better. Bernhard Hi Bernhard, I have changed the code to do the same things it did before your changes at that position. My patch is attached. With this patch all ssb Cores are found, but I get a oops in b43 driver now. Reserved instruction in kernel code I have not activated symbols will do now. Here is the log for now: http://hauke-m.de/fileadmin/openwrt/brcm47xx-log/boot-not-working2.log Could you please split 952-ai-scan.patch into two patches. One just reorganizing the existing code without changing any functionality and one adding the ai scan. Hauke Hi Bernhard, I get the following kernel oops with your patches: Reserved instruction in kernel code[#1]: ... Call Trace: [80cc4908] b43info+0x560/0x2754 [b43] [8018a27c] ssb_device_probe+0x44/0x80 [80167d24] driver_probe_device+0x13c/0x28c [800e78ec] sysfs_create_dir+0x44/0x68 [8012b83c] kobject_get+0x1c/0x30 [80167e74] __driver_attach+0x0/0xa4 [80167ee0] __driver_attach+0x6c/0xa4 [8012bf2c] kobject_add_varg+0x28/0x78 [801673dc] bus_for_each_dev+0x64/0xb4 [8012bfbc] kobject_init_and_add+0x40/0x58 [80166b2c] bus_add_driver+0xd0/0x274 [80056d20] load_module+0x1980/0x1b4c [80168290] driver_register+0xe0/0x19c [80ce8000] init_module+0x0/0x70 [b43] [80ce8020] init_module+0x20/0x70 [b43] [8000d650] do_one_initcall+0x70/0x1f4 [800437f0] blocking_notifier_call_chain+0x14/0x20 [80057408] sys_init_module+0xe0/0x224 [80092924] sys_close+0x9c/0xe4 [80003230] stack_done+0x20/0x3c Full log: http://hauke-m.de/fileadmin/openwrt/brcm47xx-log/boot-not-working3.log Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] BRCM4716 support part 4
Sorry, I goofed up while porting the patch to latest trunk, as I did develop this on an older svn revision. The line should be ssb_chipco_pll_write(cc, 0xa, 0x380005C0); Bernhard 2010/5/12 Hauke Mehrtens ha...@hauke-m.de: Am 07.05.2010 22:38, schrieb Bernhard Loos: Hello This is another patch for the 4716. This replaces patch #3, as it had a bunch of problems. With this patch the device boots and works reasonable well - considering the missing drivers, but I have already an idea for those. Serial init complains, but this is not critical. One of the patches disables the support for pci-e host mode, because I kinda doubt this ever worked. If anybody has informations about ssb devices with an pci-e controller, please tell me. Hi Bernhard, I have tried your patch but I get an compile error: CC drivers/ssb/driver_chipcommon_pmu.o drivers/ssb/driver_chipcommon_pmu.c: In function 'ssb_pmu_pll_init': drivers/ssb/driver_chipcommon_pmu.c:327: warning: passing argument 1 of 'ssb_chipco_pll_write' makes pointer from integer without a cast drivers/ssb/driver_chipcommon_pmu.c:327: error: too few arguments to function 'ssb_chipco_pll_write' After removing the bad change in 957-brcm4716-pmu.patch it compiles for me. I renamed some patches as they should end with .patch Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [backfire] WRT54G flash space problem
2010/5/10 Matthias Buecher / Germany m...@maddes.net: The linux partition spans over the kernel and the complete rootfs for flashing. The maximum kernel size is 0x000bc000 (begin of rootfs) minus 0x0004 (begin of linux) equals 0x0007c000 (496KB). Maddes This is not the maximum kernel size, it's only the current kernel size. You could probably get a few kb more flash space (32 at average) by changing the aligment of the rootfs, squashfs is read only, so it doesn't have to start at an erase block boundary. On 10.05.2010 23:34, edgar.sol...@web.de wrote: are these sizes fixed or calculated according the space requirement? Looks like the linux size is fixed, what is the maximum size for a kernel on wrt54g? .. ede On 10.05.2010 23:28, Matthias Buecher / Germany wrote: Kernel and rootfs are in two different mtd partitions on the WRT54G: # dmesg ... Creating 5 MTD partitions on Physically mapped flash: 0x-0x0004 : cfe 0x0004-0x003f : linux 0x000bc000-0x0021 : rootfs mtd: partition rootfs doesn't start on an erase block boundary -- force read-only 0x003f-0x0040 : nvram 0x0021-0x003f : rootfs_data ... So it is moved from rootfs to linux in this case. Maddes On 10.05.2010 22:53, edgar.sol...@web.de wrote: but wouldn't the increase in the kernel image actually equal the decrease in the squash image and therefore the size of the rootfs_data stay the same? Both are lzma compressed. ..ede On 10.05.2010 19:16, Matthias Buecher / Germany wrote: It may not downsize the packages themselves, but moving kernel mods from rootfs to the kernel image will reduce the rootfs size. Leaving more space for JFFS2 rootfs_data. Having a K setting for kernel options would be great. Will try to have a look at it during the next weeks. Thanks for all your help Maddes On 10.05.2010 17:20, edgar.sol...@web.de wrote: there is partly in https://dev.openwrt.org/browser/trunk/include/kernel-defaults.mk line 101 you can actually add CONFIG_KERNEL_* entries to your .config and they are copied over as CONFIG_* to the kernel config. All that's missing is a menuconfig interface for that. But at least for routers using lzma squashfs for the initial image this will probably not downsize anything. .. ede On 10.05.2010 16:19, Stefan Monnier wrote: In 'make menuconfig' I included them with 'Y' instead of 'M'. According to my (newbie) knowledge that adds them to the kernel image. Can somebody please confirm my understanding? Or at least prove me wrong? :D Damn! I thought you had found a clever way to get them compiled into the kernel. I still hope some day someone will write the extra code needed so that make menuconfig can be told to build some modules right into the kernel. 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 ___ 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 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] [backfire] WRT54G flash space problem
2010/5/10 Bernhard Loos bernhardl...@googlemail.com: 2010/5/10 Matthias Buecher / Germany m...@maddes.net: The linux partition spans over the kernel and the complete rootfs for flashing. The maximum kernel size is 0x000bc000 (begin of rootfs) minus 0x0004 (begin of linux) equals 0x0007c000 (496KB). Maddes This is not the maximum kernel size, it's only the current kernel size. You could probably get a few kb more flash space (32 at average) by changing the aligment of the rootfs, squashfs is read only, so it doesn't have to start at an erase block boundary. To clarify myself, the size is calculated dynamically, so compiling stuff into the kernel doesn't gain much. On 10.05.2010 23:34, edgar.sol...@web.de wrote: are these sizes fixed or calculated according the space requirement? Looks like the linux size is fixed, what is the maximum size for a kernel on wrt54g? .. ede On 10.05.2010 23:28, Matthias Buecher / Germany wrote: Kernel and rootfs are in two different mtd partitions on the WRT54G: # dmesg ... Creating 5 MTD partitions on Physically mapped flash: 0x-0x0004 : cfe 0x0004-0x003f : linux 0x000bc000-0x0021 : rootfs mtd: partition rootfs doesn't start on an erase block boundary -- force read-only 0x003f-0x0040 : nvram 0x0021-0x003f : rootfs_data ... So it is moved from rootfs to linux in this case. Maddes On 10.05.2010 22:53, edgar.sol...@web.de wrote: but wouldn't the increase in the kernel image actually equal the decrease in the squash image and therefore the size of the rootfs_data stay the same? Both are lzma compressed. ..ede On 10.05.2010 19:16, Matthias Buecher / Germany wrote: It may not downsize the packages themselves, but moving kernel mods from rootfs to the kernel image will reduce the rootfs size. Leaving more space for JFFS2 rootfs_data. Having a K setting for kernel options would be great. Will try to have a look at it during the next weeks. Thanks for all your help Maddes On 10.05.2010 17:20, edgar.sol...@web.de wrote: there is partly in https://dev.openwrt.org/browser/trunk/include/kernel-defaults.mk line 101 you can actually add CONFIG_KERNEL_* entries to your .config and they are copied over as CONFIG_* to the kernel config. All that's missing is a menuconfig interface for that. But at least for routers using lzma squashfs for the initial image this will probably not downsize anything. .. ede On 10.05.2010 16:19, Stefan Monnier wrote: In 'make menuconfig' I included them with 'Y' instead of 'M'. According to my (newbie) knowledge that adds them to the kernel image. Can somebody please confirm my understanding? Or at least prove me wrong? :D Damn! I thought you had found a clever way to get them compiled into the kernel. I still hope some day someone will write the extra code needed so that make menuconfig can be told to build some modules right into the kernel. 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 ___ 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 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] [backfire] WRT54G flash space problem
Actually, Y in menuconfig doesn't add the modules into the kernel, they will still be kernel modules. It only places the modules directly in the image and is in no way different from Y for programs. M creates packages for the modules/program without placing it in the image. If you want to compile a module into the kernel, you have to choose Y in kernel_menuconfig. Bernhard 2010/5/9 edgar.sol...@web.de: That's how it works. Y adds kernel modules to the kernel, and programs to the image. ..ede On 09.05.2010 18:10, Matthias Buecher / Germany wrote: In 'make menuconfig' I included them with 'Y' instead of 'M'. According to my (newbie) knowledge that adds them to the kernel image. Can somebody please confirm my understanding? Or at least prove me wrong? :D Maddes On 09.05.2010 17:56, Stefan Monnier wrote: Put all kmods (2) I needed into the kernel. How? 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [backfire] WRT54G flash space problem
If you are really bored, you could use gcc 4.5 and link time optimization. Support for it is already enabled in the openwrt gcc, but you have to add the compiler flags to use it to packages and/or the kernel. In theory, it could reduce the binary size, but I have no idea how well this will work in practice or if it works at all. Bernhard 2010/5/9 Matthias Buecher / Germany m...@maddes.net: I could finally install everything onto my 4MB WRT54g v2.2. Avoided ntpclient plus dependencies with the patch from #7316. Added BusyBox's ether-wake to the build. Put all kmods (2) I needed into the kernel. This freed up enough JFFS2 space to normally install OpenVPN and a web-interface (here webif). Would be great if #7316 and its dependency #7312 could be committed to trunk and backfire. After this I would also update the ntpclient package to reduce flash mem usage for it too, Kind regards Maddes P.S.: Thanks Bastian for all the quick infos. On 04.05.2010 16:27, Matthias Buecher / Germany wrote: Can I save space in the flash mem when I add all needed packages directly to the image? Or is the JFFS2 compression as good as the compression of the read-only squashfs? I'm also going to replace ntpclient with rdate. As the clock of the WRT54G is very inaccurate it will not be sufficient to update the clock every 24h when my provider restarts the connection. Will have to add a cron job for rdate. Maddes On 30.04.2010 22:23, Matthias Buecher / Germany wrote: I wanted to upgrade my mom's WRT54G v2.2 from WR 0.9 to Backfire 10.03. But during installation the flash space got full and OpenVPN couldn't be installed. First I built an image without luci, then all packages fit into the flash mem. But when installing webif I got the same disk full error for it. Putting all needed kmods directly into the kernel didn't free enough space. Then I checked the sizes and dependencies of the needed packages between WR and Backfire. It turned out that OpenVPN installation grew by 148KB, and that BF had some more dependencies than WR. What is the smallest version of Luci possible? (luci-admin-mini + ???) Can OpenVPN be compiled to a smaller size? Is there a reason why OpenVPN grew so much, besides being a newer version? Is there a reason why OpenVPN needs zlib, besides being a newer version? Any help greatly appreciated Maddes Here is the list of the packages I need, plus a size comparison between WR 0.9 - Backfire. iptables-mod-[conntrack-]extra 8603 - 15081 kmod-ipt-[conntrack-]extra 14188 - 10446 ntpclient 11397 - 17461 librt n/a - 1102 ddns-scripts (ez-ipudate) 26368 - 6570 openvpn 137843 - 195446 (+58KB, 2.0.8 - 2.1.1) kmod-tun 4944 - 4860 libopenssl 445303 - 500879 (+55KB, 0.9.8d - 0.9.8m) liblzo 29113 - 28782 zlib n/a - 35023 (+35KB) sslh n/a - 7333 etherwake (ether-wake) 4799 - 6078 webif 155712 - 168862 webif-theme-xwrt 3765 - n/a haserl 8210 - 12277 uhttpd (in busybox?) - 22110 ___ 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 mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] patchwork for openwrt
Hello Is there any chance we could set up a patchwork server like the one the kernel has? I'm not sure, how much work this will be, but there are a significant number of patches send to openwrt-devel, which are more or less silently ignored, which is not very nice to the authors and probably even worse for the openwrt project itself. Having an easy way to list patches and thier status could help with that. Bernhard ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Force 3G/GRPS with Huawei dongle
Hello Here is a list of the most useful commands. For details, refert to http://www.3gpp.org/ftp/Specs/html-info/27007.htm Bernhard AT+WS46 #service, ro AT+CBST #serielle baudrate? AT+CRLP #radio link control, (retry attemps) AT+CR #transmit connect intermediate result (not too useful?) AT+CEER #last error AT+CRC #extended format for incoming calls AT+CHSN #HSCSD non-transparent call configuration AT+CV120 #V.120 rate adaption protocol (not useful) AT+CREG #network registration AT+COPS #network selection AT+CSQ #show signal quality AT+CMEE #report verbose errors AT+CGDCONT #pdp context AT+CGTFT #Traffic Flow Template (could be useful) AT+CGQREQ #qos request AT+CGQMIN #qos min AT+CGEQREQ #qos request (3g) AT+CGEQMIN #qos min (3g) AT+CGEQNEG #qos negoiated (3g) AT+CGATT #attach to packat domain service AT+CGACT #pdp context activate AT+CGCMOD #applay modified qos/tft values to pdp during data state AT+CGDATA #Enter data state AT+CGPADDR #Show PDP address AT+CGCLASS #device class AT+CGREG #GPRS network registration status (same as +CREG?) AT+CGDSCONT #secondary pdp context AT^SYSCFG #huawei junk 2010/5/6 yann lopez yann.lo...@gmail.com: On Thu, May 6, 2010 at 1:41 PM, Bas Mevissen ab...@basmevissen.nl wrote: On 05/06/2010 11:14 AM, yann lopez wrote: After googling, I've found the AT command, and I've made the corresponding patch. Where did you find that? I'm looking for info to see signal strengths and connection type (GPRS,UMTS,HSDPA,..) Can you please pass me the URL of the info you found? Tia, Bas. Sorry I have not kept the link. In order to get the signal strengh this command seems to work well with my E160 gcom -s /etc/gcom/getstrength.gcom -d /dev/ttyUSB2 Yann PS: I cc ML as they will probably have more accurate responses ___ 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] patchwork for openwrt
From: Bernhard Loos bernhardl...@googlemail.com Date: 2010/5/6 Subject: Re: [OpenWrt-Devel] patchwork for openwrt To: Outback Dingo outbackdi...@gmail.com well, there is this: https://lists.openwrt.org/pipermail/openwrt-devel/2010-May/007019.html then this: https://lists.openwrt.org/pipermail/openwrt-devel/2010-April/006960.html https://lists.openwrt.org/pipermail/openwrt-devel/2010-April/006934.html There aren't that many, but still ... Maybe it would be better to have some script open trac tickets for patches send to the mailinglist, I'm not sure. Bernhard 2010/5/6 Outback Dingo outbackdi...@gmail.com: what patches specifically are you referrng On Thu, May 6, 2010 at 6:19 AM, Bernhard Loos bernhardl...@googlemail.com wrote: Hello Is there any chance we could set up a patchwork server like the one the kernel has? I'm not sure, how much work this will be, but there are a significant number of patches send to openwrt-devel, which are more or less silently ignored, which is not very nice to the authors and probably even worse for the openwrt project itself. Having an easy way to list patches and thier status could help with that. Bernhard ___ 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] MTD rework
Olmari from irc tested it, but I don't remember, which device he had. But I don't see, how this could be a problem. The bootloader only calculates the crc over trx-len, which gets also fixed up. I don't think he runs any additional checks or uses the value in some way The only place I know of, where len actually matters is during flashing with the original firmware, which complains if the filesize and the trx len values are different. Bernhard 2010/5/3 Felix Fietkau n...@openwrt.org: On 2010-05-03 1:27 AM, Bernhard Loos wrote: Ok, I did split the patch in two parts. The first one introduces libmtd.c and moves the mtd open/close functions there and the second one contains the rest of the rework. The second patch is still rather big, but it's not so easy to separate it further, so I would like to avoid it, if possible. This also fixes a small problem on the wrt160nl. Haven't reviewed all of it yet, but I did notice something in the first patch. You add the following line to trx_fixup(): + trx-len = block-info.erasesize; Wouldn't this break broadcom? Where has this been tested? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] acx-m80211 update
Hello This patch updates the mac80211 version of the acx driver to the latest git commit. I removed most of the patches, as they were either merged or didn't apply any more. Client mode works reasonable well, I tested it under load for about 3h without any problems. The really brave can enable ap mode by adding BIT(NL80211_IFTYPE_AP) to the new vlynq patch, but the results aren't very pretty. Bernhard acx.diff Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] MTD rework
Hello While trying to add a crc fixup similiar to the one for the wrt160nl to the ar525w, I stumbled over a number of problems in the mtd code. Primarily, the current system will not work with sysupgrade. Also, it's pretty hard to add new fixups and there are a number of devices which could use them, for example some brcm63xx devices. I created an easy-to-extend system for the fixups and and did a general cleanup of the mtd code, removing a lot of code duplication in the process. The functions, that operate on the actual mtd device are now in their own file and have a reasonable clean interface. Bernhard mtd.diff Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] MTD rework
I tried to, but it didn't work out very well in the first version of the patch. It should be easier in the current version, but I kinda forgot about it, sorry. Bernhard 2010/4/30 Felix Fietkau n...@openwrt.org: On 2010-04-30 6:45 PM, Bernhard Loos wrote: Hello While trying to add a crc fixup similiar to the one for the wrt160nl to the ar525w, I stumbled over a number of problems in the mtd code. Primarily, the current system will not work with sysupgrade. Also, it's pretty hard to add new fixups and there are a number of devices which could use them, for example some brcm63xx devices. I created an easy-to-extend system for the fixups and and did a general cleanup of the mtd code, removing a lot of code duplication in the process. The functions, that operate on the actual mtd device are now in their own file and have a reasonable clean interface. I'll take a look at this soon-ish. It would be very helpful to the review process, if you could split up your patches in the future, instead of mashing together a large chunk of different changes into one single patch. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Kernel patch in Kamikaze-8.09.2 to support Netgear WNR3500L
2010/4/29 Tathagata Das tathag...@alumnux.com: Hi, This is my first kernel patch submission. Please let me know if I do any mistake. All changes are made either under CONFIG_WNR3500L tag or Tatha tag. Regards, Tathagata tathag...@alumnux.com Hello Thanks for the patch, but there are a number of problems with it: Firstly, 8.09 is eol, so if you submit patches, do it agains trunk. Then, this #ifdef mess is really ugly. It's ok to create a config symbol for the wnr3500l support, but the number of #ifdefs should be kept to the absolutely needed minimum and it should be possible to build a kernel which supports both the older broadcom socs and the new one. Also, it would have been nice to mention the source for this patch and keep the copyright notice intact. There is already work underway to add basic platform support for this soc into openwrt, it would be really helpful, if you could find the wired network driver and get it up and running. Bernhard ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] BRCM4716 support part 3
Hello This includes 2 patches to add the actual scan method for the ai type bus and implementations for enalbe/disable device. The ai scan patch is a bit difficult, because I more or less assumes that the first core is a chipcommon core, which is at least for the 4710 soc not the case. I'm not completly sure, how this patch behaves on those devices. Unfortunetly, it's hard to avoid this problem, because I can't scan the ssb without knowing the scan method to use, and without scanning the ssb, I don't know the type of the first core. For the enable/disable functions I introduced 3 function pointers in struct ssb_bus. Bernhard n16_3.diff Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Kernel patch in Kamikaze-8.09.2 to support Netgear WNR3500L
This was actually supposed to go to openwrt-devel. Anyway, there are already parts of the patch in openwrt trunk. I didn't get around to submit the MIPS74k and pmu support patches yet, but I hope to get this done in the next few days. Bernhard 2010/4/29 tathagata tathag...@alumnux.com: Hi, Thanks for the clarification. Once I add support of WNR3500L into trunk I will send you the patch. Regards, Tathagata On Thu, 29 Apr 2010 19:28:55 +0200, Bernhard Loos bernhardl...@googlemail.com wrote: 2010/4/29 Tathagata Das tathag...@alumnux.com: Hi, Sorry I do not understand the meaning of eol. I think you mean to say no further development is going on with 8.09. End of life, so you guessed right. I can create patch against trunk. I do not know but if linux code is getting changed continuously in trunk then I am afraid we need to apply this patch manually. Is it okay ? I mean a patch against openwrt trunk. It doesn't change the kernel that often. And the changes in this area aren't usually very big. Also, it would have been nice to mention the source for this patch and keep the copyright notice intact. -- Do you mean to say that next time when I submit this patch I should mention the code version against which I prepare the patch ? I have introduced copyright in one file only, sflash.c. Please let me know what would be the Copyright content. I will put that into that file. Well, you didn't write most of the ssb support code yourself and there was a copyright in scan.c, which is now missing. I don't know, who managed to loose it, or how, but it doesn't really matter. Thank you for showing interest in my kernel patch. I would definitely try to find out the corresponding wired driver. If you manage to find the file, where the driver code is located in the braodcom sources, it would already be a great help. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Option modem GTM382 and HSO
You don't need rfkill afaik. 2010/4/26 Janno Sannik ja...@foor.ee: Yeah, I of course forgot to specify that I have gemini build. Seems to be problem is related to arch. Well, I'm kinda slow, because I found out that I needed to add DEPENDS:=...@target_x86||TARGET_s3c24xx||TARGET_brcm47xx||TARGET_ar71xx||TARGET_gemini to rfkill packages, but in the meantime somebody updated the trunk and DEPENDS: is removed alltogether and $(call SetDepends/rfkill) has been added: --- a/other.mk +++ b/other.mk @@ -65,6 +65,7 @@ KCONFIG:=CONFIG_CRC16 FILES:=$(LINUX_DIR)/lib/crc16.$(LINUX_KMOD_SUFFIX) AUTOLOAD:=$(call AutoLoad,20,crc16,1) + $(call SetDepends/crc16) endef define KernelPackage/crc16/description @@ -261,8 +262,7 @@ define KernelPackage/bluetooth SUBMENU:=$(OTHER_MENU) TITLE:=Bluetooth support - DEPENDS:=...@usb_support +kmod-crc16 +kmod-usb-core +!TARGET_x86:kmod-hid \ - +(TARGET_x86||TARGET_s3c24xx||TARGET_brcm47xx||TARGET_ar71xx):kmod-rfkill + DEPENDS:=...@usb_support +kmod-usb-core +!TARGET_x86:kmod-hid KCONFIG:= \ CONFIG_BLUEZ \ CONFIG_BLUEZ_L2CAP \ @@ -281,6 +281,8 @@ CONFIG_BT_HCIUSB \ CONFIG_BT_HCIUART \ CONFIG_BT_HIDP + $(call AddDepends/crc16) + $(call AddDepends/rfkill) endef define KernelPackage/bluetooth/2.4 @@ -852,7 +854,6 @@ define KernelPackage/rfkill SUBMENU:=$(OTHER_MENU) TITLE:=RF switch subsystem support - DEPENDS:=...@target_x86||TARGET_s3c24xx||TARGET_brcm47xx||TARGET_ar71xx KCONFIG:= \ CONFIG_RFKILL \ CONFIG_RFKILL_INPUT=y \ @@ -867,6 +868,7 @@ $(LINUX_DIR)/net/rfkill/rfkill-input.$(LINUX_KMOD_SUFFIX) AUTOLOAD:=$(call AutoLoad,20,rfkill rfkill-input) endif + $(call SetDepends/rfkill) endef define KernelPackage/rfkill/description If I selecet brcm47xx as target then I can select rfswitch from menuconfig. Then I switchi to gemini (cortina systems) then I can't. If I comment out $(call SetDepends/rfkill) then I can select rfswitch with gemini build. Any hint where dependencies are stored? I'm still very new to building and makefiles, so be gentle with me :-). I could just build it as as, but I would like to know how the right way to do it. On 23.04.2010 11:25, Bernhard Loos wrote: The option was there in 8.09, not sure why it vanished in the meantime. You will have to edit the Makefile to bring it back. But HSO modems aren't supported out ouf the box in openwrt, you will have to play with the network and dialup scripts. Search trac, there was a ticket with some patches for it. Bernhard 2010/4/20 Janno Sannik ja...@foor.ee: Well, hit the wall at this point: https://forum.openwrt.org/viewtopic.php?id=22301 There IS no kmod-usb-net module in the section allthou it's suppose to be in kernel. * kmod-usb-core Support for USB │ │ │ │ kmod-usb-acm. Support for modems/isdn controllers │ │ │ │ kmod-usb-atm.. Support for ATM on USB bus │ │ │ │ kmod-usb-audio. Support for USB audio devices │ │ │ │ kmod-usb-cm109.. Support for CM109 device │ │ │ │ kmod-usb-hid. Support for USB Human Input Devices │ │ │ │ M kmod-usb-net... Kernel modules for USB-to-Ethernet convertors │ │ │ │ kmod-usb-net-asix.. Kernel module for USB-to-Ethernet Asix convertors (NEW) │ │ │ │ kmod-usb-net-cdc-ether.. Support for cdc ethernet connections (NEW) │ │ │ │ kmod-usb-net-dm9601-ether Support for DM9601 ethernet connections (NEW) │ │ │ │ kmod-usb-net-kaweth.. Kernel module for USB-to-Ethernet Kaweth convertors (NEW) │ │ │ │ kmod-usb-net-mcs7830 (NEW) │ │ │ │ kmod-usb-net-pegasus (NEW) │ │ │ │ kmod-usb-net-rndis. Support for RNDIS connections (NEW) │ │ │ │ kmod-usb-ohci... Support for OHCI controllers │ │ │ │ kmod-usb-phidget.. USB Phidget Driver │ │ │ │ kmod-usb-printer Support for printers │ │ │ │ kmod-usb-serial. Support for USB-to-Serial converters │ │ │ │ M kmod-usb-storage. USB Storage support │ │ │ │ kmod-usb-storage-extras Extra drivers for usb-storage │ │ │ │ kmod-usb-uhci... Support for UHCI controllers │ │ │ │ kmod-usb-video. Support for USB video devices │ │ │ │ kmod-usb-yealink.. USB Yealink VOIP phone │ │ │ │ * kmod-usb2... Support for USB2 controllers │ │ │ │ kmod-usbip.. USB-over-IP (kernel support) │ │ │ │ kmod-usbip-client. USB-over-IP (kernel client
Re: [OpenWrt-Devel] Option modem GTM382 and HSO
The option was there in 8.09, not sure why it vanished in the meantime. You will have to edit the Makefile to bring it back. But HSO modems aren't supported out ouf the box in openwrt, you will have to play with the network and dialup scripts. Search trac, there was a ticket with some patches for it. Bernhard 2010/4/20 Janno Sannik ja...@foor.ee: Well, hit the wall at this point: https://forum.openwrt.org/viewtopic.php?id=22301 There IS no kmod-usb-net module in the section allthou it's suppose to be in kernel. * kmod-usb-core Support for USB │ │ │ │ kmod-usb-acm. Support for modems/isdn controllers │ │ │ │ kmod-usb-atm.. Support for ATM on USB bus │ │ │ │ kmod-usb-audio. Support for USB audio devices │ │ │ │ kmod-usb-cm109.. Support for CM109 device │ │ │ │ kmod-usb-hid. Support for USB Human Input Devices │ │ │ │ M kmod-usb-net... Kernel modules for USB-to-Ethernet convertors │ │ │ │ kmod-usb-net-asix.. Kernel module for USB-to-Ethernet Asix convertors (NEW) │ │ │ │ kmod-usb-net-cdc-ether.. Support for cdc ethernet connections (NEW) │ │ │ │ kmod-usb-net-dm9601-ether Support for DM9601 ethernet connections (NEW) │ │ │ │ kmod-usb-net-kaweth.. Kernel module for USB-to-Ethernet Kaweth convertors (NEW) │ │ │ │ kmod-usb-net-mcs7830 (NEW) │ │ │ │ kmod-usb-net-pegasus (NEW) │ │ │ │ kmod-usb-net-rndis. Support for RNDIS connections (NEW) │ │ │ │ kmod-usb-ohci... Support for OHCI controllers │ │ │ │ kmod-usb-phidget.. USB Phidget Driver │ │ │ │ kmod-usb-printer Support for printers │ │ │ │ kmod-usb-serial. Support for USB-to-Serial converters │ │ │ │ M kmod-usb-storage. USB Storage support │ │ │ │ kmod-usb-storage-extras Extra drivers for usb-storage │ │ │ │ kmod-usb-uhci... Support for UHCI controllers │ │ │ │ kmod-usb-video. Support for USB video devices │ │ │ │ kmod-usb-yealink.. USB Yealink VOIP phone │ │ │ │ * kmod-usb2... Support for USB2 controllers │ │ │ │ kmod-usbip.. USB-over-IP (kernel support) │ │ │ │ kmod-usbip-client. USB-over-IP (kernel client driver) │ │ │ │ kmod-usbip-server... USB-over-IP (kernel host driver) │ │ │ │ On 20.04.2010 22:18, Bernhard Loos wrote: 2010/4/20 Janno Sannikja...@foor.ee: I'm kinda new to openwrt dependency and bulding. I have set the required modules (RFKILL, CONFIG_USB_HSO) in kernel_menuconfig as described in ticket: https://dev.openwrt.org/ticket/6998 . make kernel_menuconfig shows it, but after exiting looking at build_dir/linux-gemini/linux-2.6.32.10/.config it still is unset. That's because of the way openwrt handles modules. Don't touch kernel_menuconfig unless you know, what you are doing. Enable instead the packages in normal openwrt menuconfig. It will still build kernel modules. Procedure is as follows: get latest svn make symlinks/packages make menuconfig (configure for gemini and kmod-usb2) make (for some reason if make kernel_menuconfig was called before building kernel first time, it gives error. Sorry, didn't note it down, but probably can be reproduced) That's normal, because the tools (quilt is needed) are not yet build. make kernel_menuconfig make ___ 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 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] Option modem GTM382 and HSO
2010/4/20 Janno Sannik ja...@foor.ee: I'm kinda new to openwrt dependency and bulding. I have set the required modules (RFKILL, CONFIG_USB_HSO) in kernel_menuconfig as described in ticket: https://dev.openwrt.org/ticket/6998 . make kernel_menuconfig shows it, but after exiting looking at build_dir/linux-gemini/linux-2.6.32.10/.config it still is unset. That's because of the way openwrt handles modules. Don't touch kernel_menuconfig unless you know, what you are doing. Enable instead the packages in normal openwrt menuconfig. It will still build kernel modules. Procedure is as follows: get latest svn make symlinks/packages make menuconfig (configure for gemini and kmod-usb2) make (for some reason if make kernel_menuconfig was called before building kernel first time, it gives error. Sorry, didn't note it down, but probably can be reproduced) That's normal, because the tools (quilt is needed) are not yet build. make kernel_menuconfig make ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: adding support for zyxel nbg460n/550n/550nh boards
Hello
Firstly, mask_flags in struct mtd_partition disables the given funtion
afaik, so you made everyting but the CalibData partition read only.
Also, don't you need to add a section to the image generation Makefile?
Bernhard
2010/4/18 Michael Kurz michi.k...@googlemail.com:
This patch adds support for the zyxel nbg460n/550n/550nh routers.
Currently this only works if a second stage bootloader is also flashed,
as the used switch needs extra initialization.
Signed-off-by: Michael Kurz michi.k...@googlemail.com
---
linux/ar71xx/config-2.6.32 | 1
linux/ar71xx/config-2.6.33 | 1
linux/ar71xx/config-2.6.34 | 1
linux/ar71xx/files/arch/mips/ar71xx/Kconfig | 8
linux/ar71xx/files/arch/mips/ar71xx/Makefile | 1
linux/ar71xx/files/arch/mips/ar71xx/mach-nbg460n.c | 215 +++
linux/ar71xx/files/arch/mips/ar71xx/machtype.h | 1
linux/ar71xx/profiles/zyxel.mk | 17
8 files changed, 245 insertions(+)
Index: target/linux/ar71xx/files/arch/mips/ar71xx/Kconfig
===
--- target/linux/ar71xx/files/arch/mips/ar71xx/Kconfig (revision 20954)
+++ target/linux/ar71xx/files/arch/mips/ar71xx/Kconfig (working copy)
@@ -160,6 +160,14 @@ config AR71XX_MACH_MZK_W300NH
select AR71XX_DEV_LEDS_GPIO
default n
+config AR71XX_MACH_NBG460N
+ bool Zyxel NBG460N/550N/550NH board support
+ select AR71XX_DEV_M25P80
+ select AR71XX_DEV_AR913X_WMAC
+ select AR71XX_DEV_GPIO_BUTTONS
+ select AR71XX_DEV_LEDS_GPIO
+ default n
+
config AR71XX_MACH_TL_WR741ND
bool TP-LINK TL-WR741ND support
select AR71XX_DEV_M25P80
Index: target/linux/ar71xx/files/arch/mips/ar71xx/Makefile
===
--- target/linux/ar71xx/files/arch/mips/ar71xx/Makefile (revision 20954)
+++ target/linux/ar71xx/files/arch/mips/ar71xx/Makefile (working copy)
@@ -35,6 +35,7 @@ obj-$(CONFIG_AR71XX_MACH_DIR_615_C1) += mach-dir-6
obj-$(CONFIG_AR71XX_MACH_DIR_825_B1) += mach-dir-825-b1.o
obj-$(CONFIG_AR71XX_MACH_MZK_W04NU) += mach-mzk-w04nu.o
obj-$(CONFIG_AR71XX_MACH_MZK_W300NH) += mach-mzk-w300nh.o
+obj-$(CONFIG_AR71XX_MACH_NBG460N) += mach-nbg460n.o
obj-$(CONFIG_AR71XX_MACH_PB42) += mach-pb42.o
obj-$(CONFIG_AR71XX_MACH_PB44) += mach-pb44.o
obj-$(CONFIG_AR71XX_MACH_PB92) += mach-pb92.o
Index: target/linux/ar71xx/files/arch/mips/ar71xx/machtype.h
===
--- target/linux/ar71xx/files/arch/mips/ar71xx/machtype.h (revision
20954)
+++ target/linux/ar71xx/files/arch/mips/ar71xx/machtype.h (working copy)
@@ -35,6 +35,7 @@ enum ar71xx_mach_type {
AR71XX_MACH_PB92, /* Atheros PB92 */
AR71XX_MACH_MZK_W04NU, /* Planex MZK-W04NU */
AR71XX_MACH_MZK_W300NH, /* Planex MZK-W300NH */
+ AR71XX_MACH_NBG460N, /* Zyxel NBG460N/550N/550NH */
AR71XX_MACH_TEW_632BRP, /* TRENDnet TEW-632BRP */
AR71XX_MACH_TL_WR741ND, /* TP-LINK TL-WR741ND */
AR71XX_MACH_TL_WR841N_V1, /* TP-LINK TL-WR841N v1 */
Index: target/linux/ar71xx/files/arch/mips/ar71xx/mach-nbg460n.c
===
--- target/linux/ar71xx/files/arch/mips/ar71xx/mach-nbg460n.c (revision 0)
+++ target/linux/ar71xx/files/arch/mips/ar71xx/mach-nbg460n.c (revision 0)
@@ -0,0 +1,215 @@
+/*
+ * Zyxel NBG 460N/550N/550NH board support
+ *
+ * Copyright (C) 2010 Michael Kurz michi.k...@googlemail.com
+ *
+ * based on mach-tl-wr1043nd.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include linux/platform_device.h
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+#include linux/delay.h
+#include linux/rtl8366s.h
+
+#include linux/i2c.h
+#include linux/i2c-algo-bit.h
+#include linux/i2c-gpio.h
+
+#include asm/mach-ar71xx/ar71xx.h
+
+#include machtype.h
+#include devices.h
+#include dev-m25p80.h
+#include dev-ar913x-wmac.h
+#include dev-gpio-buttons.h
+#include dev-leds-gpio.h
+
+/* LEDs */
+#define NBG460N_GPIO_LED_WPS 3
+#define NBG460N_GPIO_LED_WAN 6
+#define NBG460N_GPIO_LED_POWER 14
+#define NBG460N_GPIO_LED_WLAN 15
+
+/* Buttons */
+#define NBG460N_GPIO_BTN_WPS 12
+#define NBG460N_GPIO_BTN_RESET 21
+#define NBG460N_BUTTONS_POLL_INTERVAL 20
+
+/* RTC chip PCF8563 I2C interface */
+#define NBG460N_GPIO_PCF8563_SDA 8
+#define NBG460N_GPIO_PCF8563_SCK 7
+
+/* Switch configuration I2C interface */
+#define NBG460N_GPIO_RTL8366_SDA 16
+#define
[OpenWrt-Devel] BRCM4716 support part 2
Hello This adds two patches to brcm47xx. 950-sbb-sysfs-files.patch is not 4716 specific and adds a bunch of sysfs attributes to ssb devices, similiar to pci devices. 951-brcm4716-defines.patch contains defines for registers and device ids used on th brcm4716 Bernhard ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BRCM4716 support part 2
And I forgot the actual patch again, sorry. 2010/4/15 Bernhard Loos bernhardl...@googlemail.com: Hello This adds two patches to brcm47xx. 950-sbb-sysfs-files.patch is not 4716 specific and adds a bunch of sysfs attributes to ssb devices, similiar to pci devices. 951-brcm4716-defines.patch contains defines for registers and device ids used on th brcm4716 Bernhard n16_2.diff Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] tune lzma options for kernel compression
Will do, thanks for testing this. 2010/4/11 Felix Fietkau n...@openwrt.org: On 2010-04-11 3:45 AM, Bernhard Loos wrote: Hello I don't know, if there is some non-obvious reason for the lzma kernel compression option, but I run a few tests and found a set of options, that produce a smaller kernel (from 777376 to 761786 bytes for a rdc vmlinux kernel). These changes need to be made RDC or x86 specific. RISC architectures typically need completely different LZMA options compared to x86, because of patterns in fixed vs variable instruction length code. I just compared your parameters with the default ones on a mips kernel binary, and here's the difference: default: 923668 bytes yours: 939529 bytes - Felix ___ 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] fix up gcc 4.4 graphite option
Hello This patch propagates the CONFIG_GCC_USE_GRAPHITE option to gcc configure and also adds an option to use the system versions of ppl and cloog (disabled by default). Bernhard graphite.diff Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] tools updates needed for gcc 4.5
Hello This patches updates some libraries to the versions needed for gcc 4.5 and adds the mpc library. Once this is commited, I also have a patch for the gcc 4.5 RC. I already tried it on rdc and it works pretty well there. Bernhard gcc45tools.diff Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] tune lzma options for kernel compression
Hello I don't know, if there is some non-obvious reason for the lzma kernel compression option, but I run a few tests and found a set of options, that produce a smaller kernel (from 777376 to 761786 bytes for a rdc vmlinux kernel). Bernhard better_lzma.diff Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] BRCM4716 support
Hello I did work on adding support for the BRCM4716 to openwrt after getting an ASUS RT-N16 from glp. The main problem is, that the sonics silicon backplane is completly different especially the registers of the actual backplane. Also, it uses a different MIPS core and also a different ethernet mac then the other models. I did manage to get a booting kernel which seems to run fine, but pretty much everything useful is missing (including ethernet) I would like to split the patch into smaller chunks and send them here as I have time. The complete patch is here (minus the part in this mail): https://dev.openwrt.org/attachment/ticket/6580/asus.diff The first patch adjusts the caching code, because it reads a backplane register, which isn't there on the 4716. I'm not completly sure, how this code works, but it only seems to be a dummy read, so I used register 0 instead. Bernhard n16_1.diff Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WRT160NL new bootloader fix
Hello This is the final patch with the uci-default script from Otto Solares. Would be nice, if somebody could commit this. Bernhard wrt160nl-fixtrx.diff Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WRT160NL new bootloader fix
Seems a bit like overkill to me, but I guess that's not my call to make. Thanks for your patch and your tests. Bernhard 2010/3/24 Otto Solares so...@guug.org: On Wed, Mar 24, 2010 at 02:39:51PM +0100, Bernhard Loos wrote: After a suggestion from xMff, I dedicded to use a uci-defaults script, as this should fit the needs. Use it instead of the firstboot script in the original patch. I can't test it, as I don't have the device with me right now, but it's trivial. Based on others ar71xx uci-defaults scripts and yours I think the attached patch is a little better. Tested successfully with your original patch in both pure jffs2 and squashfs and it works fine. - Otto ___ 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] mjpg-streamer and kernel crash again
2010/3/22 Kövesdi György k...@teledigit.hu:
Where is the output of mjpg-streamer written to? It looks like it is
using ram disk or (slow) flash memory. Make sure it is on the hard disk.
Sorry, i forgot to mention that there is a link:
/data - /mnt/xxx/
which point to the HD.
What is the rate of data being written? If, for some reason, the disk
(flash?) is too slow, you run out of memory due to the block layer
buffering.
The measured maximum recorded rate is ~23 fps. My very first try was recording
one picture in every 15 second, which is very slow, and it also leaded to
crash in 3 days. Faster recording crashes sooner.
--
I checked some out-of-memory situations, and found strange things. You can
easily try it (i would like to hear if it works on your system or not): create
a big directory (~50k...100k files) and give a simple 'ls' command:
$ ls /my/big/directory
No swap is in use, my physical memory is 32M.
The 'ls' allocates very much memory, which leads to out-of-memory. AFAIK, the
kernel calls the oom-killer, which should kill the biggest process ('ls' in
this case). It happens, but the system hangs. Some seconds later the following
message appears on the console:
This could be your actual problem, but it's kinda hard to fix. You
could try a 2.6 kernel, if you are still on 2.4 or trunk if you still
use 8.09, maybe those parts changed in the meantime.
Besides that, I would suggest to kill mjpg-streamer from time to time
and restart it with a different output directory.
bcm47xx_wdtWatchdog will fire soon!!!
This is the very last message, the system does not respond any more.
I think this situation should be handled correctly.
Thanx
K. Gy.
___
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] WRT160NL new bootloader fix
After a suggestion from xMff, I dedicded to use a uci-defaults script, as this should fit the needs. Use it instead of the firstboot script in the original patch. I can't test it, as I don't have the device with me right now, but it's trivial. Bernhard 2010/3/22 Otto Solares so...@guug.org: On Sat, Mar 20, 2010 at 06:14:08PM +0100, Jo-Philipp Wich wrote: I think the real issue is that the preinit hook used by the fix script is not executed on jffs2-only images. Exactly, this script is added to the switch2jffs hooks which aren't executed on a pure jffs2 image. It seems there are just 2 hooks: switch2jffs and jffs2reset, neither seems appropiate for this kind of scripts. It would be nice to have another independent of filesystems hook but I'm not a preinit expert as it seems to me a little overcomplicated, hopefully someone who knows can give the OP advice as his fix is necesary. Thank you! - Otto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel fixtrx.diff Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mjpg-streamer and kernel crash again
Well, if you can reproduce the problem with ls, you can start debugging the kernel and figure out, what exactly allocates that much memory and maybe prevent it in some way. 2010/3/24 Kövesdi György k...@teledigit.hu: Besides that, I would suggest to kill mjpg-streamer from time to time and restart it with a different output directory. I tried it but the time of the crash is not determined exactly: sometimes it occures sooner. So, the system will crash for sure, sooner or later. I want to participate in resolving this problem, as far as i can. Regards K. Gy. ___ 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] broadcom-sdhc package 2.0.2 revision 2 patch
It would be nice, to have better integration into the openwrt infrastructure. For example using uci for the config file and integrating with the firstboot and mount_root systems. Bernhard 2010/3/20 budd...@gmx.net: after coordination with the original author this includes the whole source and maintenance will be done in openwrt trunk after inclusion. Changes are - prepared source/files version 2.0.1 for complete inclusion in openwrt buildrootng - Bug Fix: start script choked when dbg was not set or 0 - moved Usage/Release Notes in this Readme from sdhc.c header - Bug Fix: inserted default values for gpio's in init script - init script: load the debug module by default, load debug disabled only if existing and debug is off - init script: new option overlay_root, documentation with the help option - conf file: added fsmodules parameter, necessary kernel modules for a successful mount please use patch -p1 . bud ___ 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] WRT160NL new bootloader fix
Does this happen directly after flashing or only after a reboot? If openwrt does come up at least once, could you run mtd -o 32 fixtrx firmware and give me the output? 2010/3/19 Otto Solares so...@guug.org: On Wed, Mar 17, 2010 at 05:34:33PM +0100, Bernhard Loos wrote: Hello I forgot to svn add the firstboot script, that actually calls mtd to fix the trx, sorry about that. Here is the complete patch again. Bernhard Hello Bernhard, FYI I try your patch on my newer WRT160NL but it lost again the new firmware on boot and just sits waiting for a TFTP put from the network. - Otto ___ 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] WRT160NL new bootloader fix
2010/3/19 W. Michael Petullo m...@flyn.org: The WRT160NL gets shipped with a new bootloader since some time, which actually checks the checksum in the trx image header. As the checksummed area includes the jffs2 start marker, this will blow up after first boot. This patch fixes this by adding a new funktion to mtd (fixtrx) which is called in firstboot. Nice patch. I was waiting for something like this since months. Some brcm63xx devices like Pirelli Alice Business Gate 2 Plus (1) and Alice Gate W2+ (2) has the same problem. Can this patch be extended to support this router's CFE bootloader? I'm a WRT160NL user, but I do not have this new hardware revision. However, I am working on some documentation that I hope will be applicable to the new hardware revision. Can anyone comment on when this should make it to subversion (I don't see the patch in Trac yet)? Could someone provide the symptoms of using the new hardware without this change? I understand this as the system will not boot the flash image. Is this correct? You can boot openwrt only once after flashing. On the second boot, the bootloader will throw a checksum mismatched error (if you have a serial cable attached to see it). Could anyone provide any different markings that identify the new hardware revision from older revisions? Not sure about serial numbers, the only but the bootloader version is different. Are the changes made transparent to the older hardware revision? That is, will a new build continue to work on the old hardware with no configuration change? It shouldn't affect older hardware. Thanks! -- Mike :wq ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Support for Alice Gate W2+ (aka AliceV3-S1 or Vela) bcm63xx-based routers
I admit, that's may be a pretty hard problem. I would suggest you start with exactly pinpointing the place, where it goes wrong. Enable kernel symbols and such stuff. Maybe you get lucky and it's something simple. Otherwise you would have to compare with the datasheet of the flashchip. Bernhard 2010/3/17 Gianfranco Bauco de_gianfranc...@hotmail.com: @Bernhard Loos The problem is described here https://forum.openwrt.org/viewtopic.php?id=17370p=12 on post #279 I don't know hot to fix it, but at least in this way is easy to circumvent. Ciao. Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Sign up now. ___ 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] WRT160NL new bootloader fix
I'm not sure about things like the flashlayout and the position of the trx header for those board, but it should be pretty easy to extend. You simply have to adapt the prinit script, the rest should be the same. 2010/3/16 Mattia Aracne arac...@hotmail.com: Hello The WRT160NL gets shipped with a new bootloader since some time, which actually checks the checksum in the trx image header. As the checksummed area includes the jffs2 start marker, this will blow up after first boot. This patch fixes this by adding a new funktion to mtd (fixtrx) which is called in firstboot. Nice patch. I was waiting for something like this since months. Some brcm63xx devices like Pirelli Alice Business Gate 2 Plus (1) and Alice Gate W2+ (2) has the same problem. Can this patch be extended to support this router's CFE bootloader? (1) https://forum.openwrt.org/viewtopic.php?id=21087 (2) https://lists.openwrt.org/pipermail/openwrt-devel/2010-March/006265.html ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Support for Alice Gate W2+ (aka AliceV3-S1 or Vela) bcm63xx-based routers
You did understand correctly, I didn't know there were a problem with flash detection. But wouldn't it be better to fix the flash detection instead of simply disabling it? What exactly is the problem, why does it fail? 2010/3/17 Gianfranco Bauco de_gianfranc...@hotmail.com: @Bernhard Loos Actually, as far as I understand, your patch addresses a problem occurring after the first boot with bad CRC detected by bootloader. My patch instead is to skip a routine that makes the flash detected uncorrectly, causing a kernel panic. I modified it today and should not break any other platform, as long as the specific switch is set during compilation (not set by default). But if I misunderstood or you can help me in making something nicer, that would be of course appreciated. Of course your patch about the bad CRC will be a good start for what we will need in order to make AG3 and AGA work as well. Ciao. Hotmail: Trusted email with powerful SPAM protection. Sign up now. ___ 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] WRT160NL new bootloader fix
Hello The WRT160NL gets shipped with a new bootloader since some time, which actually checks the checksum in the trx image header. As the checksummed area includes the jffs2 start marker, this will blow up after first boot. This patch fixes this by adding a new funktion to mtd (fixtrx) which is called in firstboot. It also gets rid of the unneeded padding of 65kB. Bernhard ar71xx.diff Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] new rdc board detection system and other things
Hello This is primarily for Florian, so he can keep track of things This patch contains an unload fix for the wdt timer, and a new board detection system based on magic strings in the flash. It's working for Sitecom but the magic strings for the bifferboard and the r8610 are missing. The AR525W is a bigger problem. The header of image contains a checksum over the whole image, which will changes du to the jffs2 partition. I tried to avoid this by including only the kernel in the checksummed part and simply appending the rootfs to it, but now the length in the header is too short and the webinterface and/or the bootloader may trunkate the image during flashing, so this needs some testing. Bernhard rdc.diff Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mjpg-streamer on Asus WL500gP V2
Actually this should only matter for dma buffers on kernel side and for userspace not at all. A region of continous virtual memory can consists of physically scattered memory without problems. That's what the page table is for. Bernhard 2010/3/10 Fabrizio Bertocci fabrizioberto...@gmail.com: Well, Im not an expert of the kernel, but if I remember correctly, when the system runs low in memory, the kernel doesn't necessarily kill the process with higher memory use... and if fragmentation is really the problem, the mjpg-streamer may have very little memory allocated anyway... I've seen those kind of behavior on 2.4 kernels... Going back to the mjpg-streamer, if the mjpg-streamer is designed to do a malloc...free for every processed frame, I'm sure that is the possible cause of your problem. Eventually the memory has a lot of holes here and there, and there is not a single block that is large enough to accommodate a new request. If you can modify the code (I'm not familiar with mjpg-streamer), you should review the memory allocation policy, and use for example a fast buffer pool that preallocate a chunk of memory at startup and never call free anymore... then you can manage this memory by yourself in a more optimized way (i.e. get a buffer of the same size from this pool). Well, hopefully somebody else with more experience with the kernel can give you more hints about the kernel problem. Fab 2010/3/10 Kövesdi György k...@teledigit.hu: Although there is still enough free memory, probably the memory is entirely fragmented and it cannot allocate a large block? What size of block does it need? I think it cannot be larger than one file (~30...80k). I cannot imagine that it cannot be allocated. Or, if it occures, only the mjpg-streamer is killed. In my case, _all_ processes are killed, that's why I think there can be a bug somewhere in the kernel. (in the UVC driver?) Does this problem occur regularly after about 300k frames? I tried with different resolution and speed, it is within 290k...310k frames. In this case why don't you try to stop and restart mjpg-streamer right before that just to see if the system stays up for a longer time? I will try it, but I would like to catch the problem in the kernel. Unfortunately, I don't know too much about the memory handling within the kernel. At least the source is available (it is my own compilation), so I will try to do something. Any help would be appreciated. Thanx K. Gy. ___ 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 mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Problem with c and sqlite3
Without the source, how should we know?
You will have to start debugging it yourself. Besides good old printf
debugging, there is also remote gdb you can use.
2010/3/3 Jesus arteche chechu.li...@gmail.com:
Hi,
I'm compiling a c program that uses sqlite3 libraries...when I execute the
program in my pc it works right...later I make a cross compile using fon
version of OpenWRT (SDK)...and when I execute in openWRT (fonera) it
hangs...dont do anything here is the trace (I did with strace):
execve(/mnt/usb/pruebasql, [/mnt/usb/pruebasql], [/* 8 vars */]) = 0
svr4_syscall() = -1 ERRNO_4090 (Unknown error 4090)
stat(/etc/ld.so.cache, 0x7fb88a60) = -1 ENOENT (No such file or
directory)
open(/lib/libsqlite3.so.0, O_RDONLY) = -1 ENOENT (No such file or
directory)
open(/lib/libsqlite3.so.0, O_RDONLY) = -1 ENOENT (No such file or
directory)
open(/usr/lib/libsqlite3.so.0, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=436063, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2aaae000
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0\0\216\0\0004\0\0\0...,
4096) = 4096
old_mmap(NULL, 700416, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2aaee000
old_mmap(0x2aaee000, 431612, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3,
0) = 0x2aaee000
old_mmap(0x2ab97000, 5983, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x69000) = 0x2ab97000
close(3) = 0
munmap(0x2aaae000, 4096) = 0
open(/lib/libgcc_s.so.1, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=60806, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2aaae000
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0\240\31\0\0004\0\0\0...,
4096) = 4096
old_mmap(NULL, 323584, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2ab99000
old_mmap(0x2ab99000, 58700, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3,
0) = 0x2ab99000
old_mmap(0x2abe7000, 3462, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0xe000) = 0x2abe7000
close(3) = 0
munmap(0x2aaae000, 4096) = 0
open(/lib/libc.so.0, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=397215, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2aaae000
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0`\250\0\0004\0\0\0...,
4096) = 4096
old_mmap(NULL, 679936, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2abe8000
old_mmap(0x2abe8000, 388676, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3,
0) = 0x2abe8000
old_mmap(0x2ac87000, 8095, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x5f000) = 0x2ac87000
old_mmap(0x2ac89000, 19456, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ac89000
close(3) = 0
munmap(0x2aaae000, 4096) = 0
open(/lib/libpthread.so.0, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=71594, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2aaae000
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0\0205\0\0004\0\0\0...,
4096) = 4096
old_mmap(NULL, 344064, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2ac8e000
old_mmap(0x2ac8e000, 49960, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3,
0) = 0x2ac8e000
old_mmap(0x2acda000, 22442, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0xc000) = 0x2acda000
old_mmap(0x2ace, 6816, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ace
close(3) = 0
munmap(0x2aaae000, 4096) = 0
open(/lib/libgcc_s.so.1, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=60806, ...}) = 0
close(3) = 0
open(/lib/libc.so.0, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=397215, ...}) = 0
close(3) = 0
open(/lib/libc.so.0, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=397215, ...}) = 0
close(3) = 0
open(/lib/libc.so.0, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=397215, ...}) = 0
close(3) = 0
stat(/lib/ld-uClibc.so.0, {st_mode=S_IFREG|0755, st_size=20694, ...}) = 0
mprotect(0x2ac87000, 4096, PROT_READ) = 0
mprotect(0x2acda000, 4096, PROT_READ) = 0
mprotect(0x2aaec000, 4096, PROT_READ) = 0
ioctl(0, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
getpid() = 4628
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
setrlimit(RLIMIT_STACK, {rlim_cur=2040*1024, rlim_max=RLIM_INFINITY}) = 0
rt_sigaction(SIGRT_0, {SIG_DFL}, NULL, 16) = 0
rt_sigaction(SIGRT_1, {SIG_DFL}, NULL, 16) = 0
rt_sigaction(SIGRT_2, {SIG_DFL}, NULL, 16) = 0
Re: [OpenWrt-Devel] Redboot job, supporting a mini router
Yes, but there are lots of testpoints around the cpu, I bet some of them are from a jtag port. Without those pins, the only possibility would be an to attach an in-ciruit programmer to the flash chip, but this will be really difficult and the success probability not very high. 2010/3/2 jason duhamell ps2chi...@gmail.com: The router does not have jtag pins. it only has a ttl port. On Wed, Mar 3, 2010 at 6:55 AM, Bernhard Loos bernhardl...@googlemail.com wrote: Do you at least now the positions of the jtag test points? 2010/3/2 jason duhamell ps2chi...@gmail.com: On Tue, Mar 2, 2010 at 8:04 AM, jason duhamell ps2chi...@gmail.com wrote: I can not access a command prompt. I believe the only way to flash it is from a test clip programmer. Jason On Tue, Mar 2, 2010 at 7:51 AM, Bernhard Loos bernhardl...@googlemail.com wrote: Did you try to flash an ar71xx image? For example the fon one? If the kernel at least starts to boot, I can do the rest. Otherwise, I'm not so sure. Bernhard 2010/3/1 jason duhamell ps2chi...@gmail.com: Ok, I decided I will start the Job offer at 100 dollars and the board. dont worry about the chip sizes, I control that from the factory side. On Mon, Mar 1, 2010 at 7:07 AM, jason duhamell ps2chi...@gmail.com wrote: Actually it is this. http://www.jcg.com.cn/en/display.asp?id=1312idd=Wireless%20Products And I can order it wit 4 mb flash or 8mb flash, but i need to fix the software on it. On Sun, Feb 28, 2010 at 7:46 PM, ulf kypke u.ky...@gmail.com wrote: hi jason, this device looks like an accton oem device similar to the smc webt-g. it has only 2 mb of flash and 8 mb or ram, this is too less for running openwrt. an other thing is the dc power design, it does not have a dc/dc converter, so it will burn the rest of power while dropping the voltage from 5 volt to 3.3 volt. this is overall not the best design. cheers ulf 2010/2/28 jason duhamell ps2chi...@gmail.com: Hello everyone. I have a new product that needs support. It is a ar2317 mini router similar to the fon 2200. When I started it up, It seemed to be running vxworks. I have a job for someone that is expereienced with redboot to help get this device supported for openwrt. Dont worry about the flash and ram, we will upgrade them to 4/16 to support openwrt. Then if someone wants to work on this hardware in person they will need a test clip and soldering skills as this device does not have a jtag. Please email me back and I will discuss the payment. ___ 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 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 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 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] Redboot job, supporting a mini router
2010/3/3 jason duhamell ps2chi...@gmail.com: I will see what i can do. Maybe you can get the datasheet for the ar2317 chip. I doubt it. They all seem to require a nda, I already checked. Besides, this is BGA chip, so there is now way to see how stuff is connected to the cpu. On Wed, Mar 3, 2010 at 7:18 AM, Bernhard Loos bernhardl...@googlemail.com wrote: Yes, but there are lots of testpoints around the cpu, I bet some of them are from a jtag port. Without those pins, the only possibility would be an to attach an in-ciruit programmer to the flash chip, but this will be really difficult and the success probability not very high. 2010/3/2 jason duhamell ps2chi...@gmail.com: The router does not have jtag pins. it only has a ttl port. On Wed, Mar 3, 2010 at 6:55 AM, Bernhard Loos bernhardl...@googlemail.com wrote: Do you at least now the positions of the jtag test points? 2010/3/2 jason duhamell ps2chi...@gmail.com: On Tue, Mar 2, 2010 at 8:04 AM, jason duhamell ps2chi...@gmail.com wrote: I can not access a command prompt. I believe the only way to flash it is from a test clip programmer. Jason On Tue, Mar 2, 2010 at 7:51 AM, Bernhard Loos bernhardl...@googlemail.com wrote: Did you try to flash an ar71xx image? For example the fon one? If the kernel at least starts to boot, I can do the rest. Otherwise, I'm not so sure. Bernhard 2010/3/1 jason duhamell ps2chi...@gmail.com: Ok, I decided I will start the Job offer at 100 dollars and the board. dont worry about the chip sizes, I control that from the factory side. On Mon, Mar 1, 2010 at 7:07 AM, jason duhamell ps2chi...@gmail.com wrote: Actually it is this. http://www.jcg.com.cn/en/display.asp?id=1312idd=Wireless%20Products And I can order it wit 4 mb flash or 8mb flash, but i need to fix the software on it. On Sun, Feb 28, 2010 at 7:46 PM, ulf kypke u.ky...@gmail.com wrote: hi jason, this device looks like an accton oem device similar to the smc webt-g. it has only 2 mb of flash and 8 mb or ram, this is too less for running openwrt. an other thing is the dc power design, it does not have a dc/dc converter, so it will burn the rest of power while dropping the voltage from 5 volt to 3.3 volt. this is overall not the best design. cheers ulf 2010/2/28 jason duhamell ps2chi...@gmail.com: Hello everyone. I have a new product that needs support. It is a ar2317 mini router similar to the fon 2200. When I started it up, It seemed to be running vxworks. I have a job for someone that is expereienced with redboot to help get this device supported for openwrt. Dont worry about the flash and ram, we will upgrade them to 4/16 to support openwrt. Then if someone wants to work on this hardware in person they will need a test clip and soldering skills as this device does not have a jtag. Please email me back and I will discuss the payment. ___ 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 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 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 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 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
Re: [OpenWrt-Devel] usb driver for openrb board
Well, you could always look at some packages for exisiting kernel modules for blueprints. If you have some specific questions, you can ask them here or in #openwrt on freenode. But please try to figure out how to do this by yourself first, too general questions will only get general and not very helpful answers. 2010/2/28 Martin Haag mar...@fa-haag.de: Hi, a friend of mine made the usb driver for the board working but he has some problems to integrade it into the openwrt buildsystem. He had to adjust some things in the kernelconfig but the buildssytem ignores the changes . So he build the kernel with his own scripts outside by his own. Now its working the driver in principal good enough for a unstabil version. There are a few descriptitions about how to do this in openwrt but they are wrong or to old and so they dident work. It would be good if the usb feature of the board could be oficial be added to the openwrt buildsystem and switched on by make menuconfig Is there anybody out there who could asist how to add stuff to openwrt so that on make menuconfig the usb could be switched on ? best regards Martin ___ 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] Redboot job, supporting a mini router
Did you try to flash an ar71xx image? For example the fon one? If the kernel at least starts to boot, I can do the rest. Otherwise, I'm not so sure. Bernhard 2010/3/1 jason duhamell ps2chi...@gmail.com: Ok, I decided I will start the Job offer at 100 dollars and the board. dont worry about the chip sizes, I control that from the factory side. On Mon, Mar 1, 2010 at 7:07 AM, jason duhamell ps2chi...@gmail.com wrote: Actually it is this. http://www.jcg.com.cn/en/display.asp?id=1312idd=Wireless%20Products And I can order it wit 4 mb flash or 8mb flash, but i need to fix the software on it. On Sun, Feb 28, 2010 at 7:46 PM, ulf kypke u.ky...@gmail.com wrote: hi jason, this device looks like an accton oem device similar to the smc webt-g. it has only 2 mb of flash and 8 mb or ram, this is too less for running openwrt. an other thing is the dc power design, it does not have a dc/dc converter, so it will burn the rest of power while dropping the voltage from 5 volt to 3.3 volt. this is overall not the best design. cheers ulf 2010/2/28 jason duhamell ps2chi...@gmail.com: Hello everyone. I have a new product that needs support. It is a ar2317 mini router similar to the fon 2200. When I started it up, It seemed to be running vxworks. I have a job for someone that is expereienced with redboot to help get this device supported for openwrt. Dont worry about the flash and ram, we will upgrade them to 4/16 to support openwrt. Then if someone wants to work on this hardware in person they will need a test clip and soldering skills as this device does not have a jtag. Please email me back and I will discuss the payment. ___ 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 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] 2.6 kernel crash on Asus WL500gP_V2
Compile a kernel with debugging enabled, this is pretty much worthless 2010/2/27 Kövesdi György k...@teledigit.hu: Hi, I have Asus WL500gP V2 hardware. I compiled the latest kernel (svn rev. #19881) and find that at first boot the kernel always crashes. After the second boot it is running well. I have a lot of modules compiled in, but removing them seems not resolve the problem. A simple configuration also triggers it. My current config is attached (kernel version 2.6.32.8). If it happens then usually it does not work, only the power-off helps. The console output is the following: Unhandled kernel unaligned access[#1]: Cpu 0 $ 0 : 0001 0001 fffe $ 4 : 0001 81883d28 81c01720 818fbe54 $ 8 : 0001 0001 802bd880 746b3933 $12 : 000a 4b890896 4b890896 $16 : 8025 818fbe54 8183e094 80288640 $20 : 80eef000 818fbd54 0041c100 $24 : 0018 $28 : 80fb8000 80fb9da0 80fb9eb0 800fa8f8 Hi : ed45a1c5 Lo : 6c089487 epc : 800fa8fc 0x800fa8fc Not tainted ra : 800fa8f8 0x800fa8f8 Status: 1000d803 KERNEL EXL IE Cause : 00800010 BadVA : 000a PrId : 00029029 (Broadcom BCM3302) Modules linked in: uvcvideo gspca_zc3xx gspca_vc032x gspca_tv8532 gspca_t613 gspca_sunplus gspca_stv06xx gspca_stk014 gspca_sq905c gspcag Process mount (pid: 1136, threadinfo=80fb8000, task=81e39a38, tls=) Stack : 8182c160 80288640 81883cb8 818fbd54 81e27280 800fff88 80cee400 fffe 8024254 800b4f84 80cee400 8183e094 80288640 80eef000 0041c100 80fb9eb0 80100394 802d9168 81c0c320 801001b0 80eef000 80cee400 80eef000 801001b0 800a2bd0 80fb9eb0 800a1afc 802892c0 81c0c320 81dffc80 802892c0 ... Call Trace:[800fff88] 0x800fff88 [800b4f84] 0x800b4f84 [80100394] 0x80100394 [801001b0] 0x801001b0 [801001b0] 0x801001b0 [800a2bd0] 0x800a2bd0 [800a1afc] 0x800a1afc [800a17f8] 0x800a17f8 [800b89f0] 0x800b89f0 [800a18f0] 0x800a18f0 [800bc664] 0x800bc664 [800ba378] 0x800ba378 [80237e64] 0x80237e64 [800bc7b4] 0x800bc7b4 [8003c954] 0x8003c954 [800a4124] 0x800a4124 [80003630] 0x80003630 Code: 0c002f65 24840070 8fa3001c 8c62000c 1445 0c02cd14 00602021 0803eaf6 Disabling lock debugging due to kernel taint ___ 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] WL500GPv2 USB and 2.6 kernel
2010/2/23 Michael Conrad open...@aprs4r.org: Hi, I have a Asus WL500GPv2 and i would like to use its USB with 2.6 kernel. I had the same problem last November and sent a mail to the platform maintainers. No helpful response received Maybe this time we will find a solution. Regards Micha You could start with providing some more informations. like: dmesg output, lsmod output, /proc/bus/pci, logread and whatever else seems useful. If you have a working revision, you can also bisect the problem. Bernhard ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] rdc gpio and watchdog driver
2010/2/21 Florian Fainelli flor...@openwrt.org: Hi Bernhard, Le jeudi 18 février 2010 12:54:28, Bernhard Loos a écrit : Hello This patch adds an pci driver for the rdc southbridge, where the gpio and wdt config registers are located. The custom reboot function is needed, beacuse the wdt works by creating a nmi interrupt, and the normal reboot fixups don't work in irq context. So we still need the reboot fixup if I understand correctly? No, only the code in reboot.c. Which I forgot to add to svn ... I attached a new patch including it. The code in platfrom.c is rather messed up at the moment, I plan to clean this up later. Yes, we will need to clean that up. There are also some kernel patches missing, one that removes the original wdt driver, and something that removes the rdc reboot fixup and removes the dependencie of rdc from the x86 reboot fixups in the Kconfig file, but the patch should work just fine without those. I have tested your patch but the watchdog driver did not trigger a reboot on my AR525W. Do you have a patch to get watchdog working yet? With the reboot.c file, it should work. -- Best regards, Florian Fainelli Email: flor...@openwrt.org Web: http://openwrt.org IRC: [florian] on irc.freenode.net --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] rdc gpio and watchdog driver
Annnd, I forgot to add the patch :/ Sorry about all the noise. Bernhard rdc.diff Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] rdc gpio and watchdog driver
Hello This patch adds an pci driver for the rdc southbridge, where the gpio and wdt config registers are located. The custom reboot function is needed, beacuse the wdt works by creating a nmi interrupt, and the normal reboot fixups don't work in irq context. The code in platfrom.c is rather messed up at the moment, I plan to clean this up later. There are also some kernel patches missing, one that removes the original wdt driver, and something that removes the rdc reboot fixup and removes the dependencie of rdc from the x86 reboot fixups in the Kconfig file, but the patch should work just fine without those. Bernhard rdc.diff Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
