Re: [OpenWrt-Devel] Interest in a openwrt router database to partially replace TOH?
> What I really wish the TOH listing had is some indication of whether > the hardware is known to be out of production. Looking for > hardware to buy to run OpenWRT is... less than straightforward. This is so absolutely true. I have gone as far as to create a snippet (link included, please don't click, it's horrible) that I run from Chrome's DevTools in order to hide all the routers that have less than certain amounts of flash and ram (https://gist.github.com/Zsub/7868748), but more comprehensive filtering would be very welcome! Joris___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Interest in a openwrt router database to partially replace TOH?
* Joris de Vries [09.12.2013 09:52]: > > the hardware is known to be out of production. Looking for > > hardware to buy to run OpenWRT is... less than straightforward. > > This is so absolutely true. I have gone as far as to create a snippet (link > included, please don't click, it's horrible) that I run from Chrome's > DevTools in order to hide all the routers that have less than certain amounts > of flash and ram (https://gist.github.com/Zsub/7868748), but more > comprehensive filtering would be very welcome! > so this leads to some new fields we should take for the upcoming(tm) template: RAM = e.g. '64' FLASH = e.g. '8' and i propose WIFI = '2.4' or '2.4 + 5' or '2.4/5' which means: 1 x 2.4 ghz, 1 x 2.4 and 1 x 5 ghz (sumultan), 1 x 2.4 or 5ghz (either or) bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Quick hack for kernel entropy problem on MIPS
On Monday 18 November 2013 19:29:17 mancha wrote:
> Hauke Mehrtens hauke-m.de> writes:
> > On 10/17/2013 05:40 PM, chrono wrote:
> > > Ahoi everyone,
> > >
> > > it was requested on IRC that I send my solution to the entropy problem
> > > with the current
> > > kernel (e.g. having 0 available entropy):
> > >
> > > root OpenWrt:/# cat /proc/sys/kernel/random/entropy_avail
> > > 0
> >
> > A similar patch was applied to trunk in r38834.
> >
> > Hauke
>
> I provided this backport patch to #openwrt on freenode last week. I am
> glad it was included in trunk.
>
> Two important clarifications:
>
> 1. The original poster applies his patch to kernel 3.3.8 (it seems) yet
>the interface that makes use of get_cycles() in seeding the random
>pool wasn't introduced until 3.6. The patch on pre-3.6 kernels
>effectively does nothing entropy-wise. Without more comprehensive
>backports, there is no similar simple solution for Attitude.
This seems not entirely accurate, as AA has a backport patch for the generic
3.3.8 kernel to add 'add_device_randomness', see
target/linux/generic/patches-3.3/050-rng_git_backport.patch
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -125,21 +125,26 @@
* The current exported interfaces for gathering environmental noise
* from the devices are:
*
+ * void add_device_randomness(const void *buf, unsigned int size);
* void add_input_randomness(unsigned int type, unsigned int code,
*unsigned int value);
- * void add_interrupt_randomness(int irq);
+ * void add_interrupt_randomness(int irq, int irq_flags);
...
+/*
+ * Add device- or boot-specific data to the input and nonblocking
+ * pools to help initialize them to unique values.
+ *
+ * None of this adds any entropy, it is meant to avoid the
+ * problem of the nonblocking pool having similar initial state
+ * across largely identical devices.
+ */
+void add_device_randomness(const void *buf, unsigned int size)
+{
+ unsigned long time = get_cycles() ^ jiffies;
+
+ mix_pool_bytes(&input_pool, buf, size, NULL);
...
Would there be anything else needed?
> 2. You aren't going to see /proc/sys/kernel/random/entropy_avail
>affected by this patch because the machine/boot specific seeding
>does not credit the entropy count.
>
> --mancha
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Tijs
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: module updates for 3.12
On Fri, Dec 06, 2013 at 01:03:17AM -0800, Tim Harvey wrote: > Signed-off-by: Tim Harvey > --- > package/kernel/linux/modules/sound.mk | 13 + > package/kernel/linux/modules/usb.mk | 6 ++ > 2 files changed, 19 insertions(+) Applied with 'imx6: usb module update for 3.12' in r39008. Thanks! Luka ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: added defines for 3.12
On Fri, Dec 06, 2013 at 01:02:33AM -0800, Tim Harvey wrote: > Signed-off-by: Tim Harvey > --- > target/linux/generic/config-3.12 | 6 ++ > 1 file changed, 6 insertions(+) Applied in r39009. Thanks! Luka ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] imx6: add support for GW53xx
On Fri, Dec 06, 2013 at 01:08:56AM -0800, Tim Harvey wrote: > The Gateworks GW53xx family of products is based on the Freescale > i.MX6DL SoC and offers a small form-factor with peripherals such as: Applied in r39012. Thanks! Luka ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Unable to Compile Kernel Header ar71xx
If I start from a clean setup with "make -j" e.g. a new clone of the trunk, the patch seems to work. Otherwise it still fails. If someone can confirm this we should close the ticket. Otherwise we should take a look at Thomas patch. Thanks Philipp On 06.12.2013 17:29, thomas.lan...@lantiq.com wrote: > Hello Jow, > > your fix will not work with "make -j"! > > Please see the attached patch for an alternate implementation, which is > successfully in use here. > > Jo-Philipp Wich wrote on 2013-12-06: >> >>> Could someone more familiar with the build process have a look? >> >> Should be fixed with https://dev.openwrt.org/changeset/38998 - please >> test. >> >> ~ Jow > > Best Regards, > Thomas > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ixp4xx: upgrade: don't copy extra binaries
hexdump is already added to new temporary file system while less is not used at
all. While at it, remove some trailing whitespaces.
Signed-off-by: Luka Perkov
CC: Imre Kaloz
---
target/linux/ixp4xx/base-files/lib/upgrade/platform.sh | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/target/linux/ixp4xx/base-files/lib/upgrade/platform.sh
b/target/linux/ixp4xx/base-files/lib/upgrade/platform.sh
index 63be293..d10d934 100644
--- a/target/linux/ixp4xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ixp4xx/base-files/lib/upgrade/platform.sh
@@ -2,9 +2,6 @@
RAMFS_COPY_DATA="/lib/ixp4xx.sh"
-# testing
-RAMFS_COPY_BIN="/usr/bin/less /usr/bin/hexdump"
-
CI_BLKSZ=65536
CI_LDADR=0x0080
@@ -64,7 +61,7 @@ platform_do_upgrade_combined() {
v "kernel_part_size=$kern_part_size"
v "kernel_part_blocks=$kern_part_blocks"
v "kern_length=$kern_length"
- v "erase_size=$erase_size"
+ v "erase_size=$erase_size"
v "kern_blocks=$kern_blocks"
v "root_blocks=$root_blocks"
v "kern_pad_blocks=$(($kern_part_blocks-$kern_blocks))"
@@ -110,7 +107,7 @@ platform_check_image() {
if [ $kern_length_b -gt $kern_part_size_b ]; then
echo "Invalid image. Kernel size ($kern_length) exceeds
kernel partition ($kern_part_size)"
return 1
- fi
+ fi
local md5_img=$(dd if="$1" bs=2 skip=9 count=16 2>/dev/null)
local md5_chk=$(dd if="$1" bs=$CI_BLKSZ skip=1 2>/dev/null |
md5sum -); md5_chk="${md5_chk%% *}"
--
1.8.4.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Interest in a openwrt router database to partially replace TOH?
Thanks for all your comments, there was some valuable input and things worth considering: * i like the idea to give start of sale and EOL dates * Integrating more information directly into the build system also sounds like a good idea, though i'm not really sure how that would be done on a per model basis. And then the question is how much information would we want to add there and if devs also think some model specific info should go directly in the repository. Might need some more thinking about it. But i still think the best way would be to have a database like the prototype i made which can be easily filled by (registered) contributors. That way we can ensure things are named consistently which is needed for good searchability. Then on the other side the most important thing is the api which can output results in json format. It wouldn't be too hard to populate some fields in the wiki which are stored in the database from ajax calls. The bad site about this is of course that it would require javascript (problems for some user groups and especially search engines). So one might think about dynamically creating static pages from the database once a day or so. So in short: Have some fields in the wiki that are populated from the db and at the same time keep it a wiki, so it is still possible to add a lot more info for each model. web2py (which i used for my prototype) could even provide a wiki - but its probably not as good/feature rich as the DokuWiki which is used now. But thats just my very own idea. Generally i would be happy with any solution that makes TOH better searchable and machine readable. Regards, Manuel signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Repair rp-pppoe build failure
Hello,
The rp-pppoe package from the packages feed, section net fails to build.
There are two problems:
1) rp-pppoe.so not built
2) spurious dependency on libevent missing
1) The resulting error message is:
cp: cannot stat `xxx/rp-pppoe-3.11/ipkg-install/etc/ppp/plugins/rp-pppoe.so':
No such file or directory
What happens is that configure has a test to decide if the plugin is to be built. The test compiles a test file containing
the linux/if_pppox.h header file. It fails because the header needs an additional include beforehand (i.e. linux/in6.h,
because of ipv6 support). Thus the plugin won't be built.
2) The resulting error message is:
Package rp-pppoe-server is missing dependencies for the following libraries:
libevent-2.0.so.5
What happens is, that the target may contain the libevent library as well, and rp-pppoe-server gets (superflously) linked
against that library. The fix is to drop the "-Llibevent -levent" linking flags. They are superflous anyway, because
libevent.a (the rp-pppoe one, in the rp-pppoe subdir src/libevent) is already part of rp-pppoe-server's dependencies. (Here
we talk about Makefile dependencies, not opkg dependencies)
I hope, thunderbird won't whitespace damage the following patch:
Best regards, Nils Rennebarth
diff --git a/net/rp-pppoe/patches/100-configure.patch
b/net/rp-pppoe/patches/100-configure.patch
index 62e9222..d45593a 100644
--- a/net/rp-pppoe/patches/100-configure.patch
+++ b/net/rp-pppoe/patches/100-configure.patch
@@ -9,7 +9,7 @@
"
if test "x$ac_cv_header_linux_if_h" = x""yes; then :
cat >>confdefs.h <<_ACEOF
-@@ -3675,10 +3675,10 @@ done
+@@ -3675,10 +3675,11 @@ done
for ac_header in linux/if_pppox.h
do :
ac_fn_c_check_header_compile "$LINENO" "linux/if_pppox.h"
"ac_cv_header_linux_if_pppox_h" "
@@ -21,10 +21,11 @@
+#include
+#include
+#include
++#include
"
if test "x$ac_cv_header_linux_if_pppox_h" = x""yes; then :
-@@ -4611,7 +4611,7 @@ esac
+@@ -4611,7 +4612,7 @@ esac
$as_echo_n "checking packing order of bit fields... " >&6; }
if test "${rpppoe_cv_pack_bitfields+set}" != set ; then
if test "$cross_compiling" = yes; then :
diff --git a/net/rp-pppoe/patches/110-Makefile.patch
b/net/rp-pppoe/patches/110-Makefile.patch
new file mode 100644
index 000..9dc1c72
--- /dev/null
+++ b/net/rp-pppoe/patches/110-Makefile.patch
@@ -0,0 +1,11 @@
+--- a/src/Makefile.in
b/src/Makefile.in
+@@ -71,7 +71,7 @@ pppoe-sniff: pppoe-sniff.o if.o common.o
+ @CC@ -o $@ $^ $(LDFLAGS)
+
+ pppoe-server: pppoe-server.o if.o debug.o common.o md5.o libevent/libevent.a
@PPPOE_SERVER_DEPS@
+- @CC@ -o $@ @RDYNAMIC@ $^ $(LDFLAGS) $(PPPOE_SERVER_LIBS) -Llibevent
-levent
++ @CC@ -o $@ @RDYNAMIC@ $^ $(LDFLAGS) $(PPPOE_SERVER_LIBS)
+
+ pppoe: pppoe.o if.o debug.o common.o ppp.o discovery.o
+ @CC@ -o $@ $^ $(LDFLAGS)
--
Nils Rennebarth
Software Developer
Teldat packetalarm logo
Teldat Security GmbH
Moenchhaldenstr. 28
D-70191 Stuttgart
Tel: +49 711 900300 - 62
Fax: +49 711 900300 - 90
E-Mail: nils.renneba...@teldat.de
Location: GmbH Nuernberg, Local Court Nuernberg, HRB 25481 Managing Director:
Bernd Buettner
Teldat packetalarm banner
The information contained in this e-mail has been carefully researched, but the
possibility of it being inapplicable in
individual cases cannot be ruled out. We therefore regret that we cannot accept
responsibility or liability of any kind
whatsoever for the correctness of the information given. Please notify us if
you discover that information is inapplicable.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Interest in a openwrt router database to partially replace TOH?
On 12/09/2013 08:52 AM, Bastian Bittorf wrote:
> * Joshua Judson Rosen [09.12.2013 08:38]:
>>> what is missing then is the router name, e.g.
>>> VENDOR and MODEL -> e.g. 'TP-LINK TL-WR1043ND'
>>
>> What I really wish the TOH listing had is some indication of whether
>> the hardware is known to be out of production. Looking for
>> hardware to buy to run OpenWRT is... less than straightforward.
>
> good idea! but must be human and machine readable
> that it not easy in a wiki, because everybody has to
> use the exact same syntax.
>
>> Maybe I should just go add a TOH field
>
> so a template should contain:
>
> VENDOR - e.g. 'TP-LINK'
> MODEL - e.g. 'TL-WR1043ND'
> VERSION - e.g. empty or 'v2' ?
> SALE_START - e.g. '2013-05'
> SALE_STOP - e.g. empty or '2014-08'
> STATUS - e.g. 'broken' or 'r12345' or 'WIP'
what about devices which work in old (brcm-2.4) builds but are no longer
supported in recent builds? I we should reference a per-version status (e.g.
10.03 'not supported', 12.09 'supported', trunk confirmed to work with/since
r). Ideally, openwrt-specific details of the device should thus also be
referenced per openwrt build/release, e.g.:
* openwrt version (e.g. git tag or revision)
* openwrt target arch (e.g. 'ar71xx')
* openwrt target flavor (e.g. 'generic')
* openwrt profile (e.g. 'TLWR1043')
* openwrt boardname (e.g. 'tl-wr1043nd-v1')
> other ideas?
* EAN/barcode (image the "can this box run openwrt" bar-code-scanner android app
which can eventually become a mobile installer tool to flash openwrt via the
stock firmware web-interface after scanning barcode on the package..)
* links (e.g. wikidevi record, vendor product page, stock firmware/dumps, ...)
* target market ('ETSI', 'FCC', 'China', 'World', ...)
* some way to add aliases for OEM products sold by multiple brands
* maybe we should use a more atomic approach instead of a table with a lot of
rows?
i.e. have 4 tables, "attributes", "components" and n-to-n mappings for
attributes<->components and components<->components
components can then be ip/core (e.g. MIPS24Kc), silicon (e.g. AR7240), boards,
products, variants, ... which can inherit attributes.
the advantage of such an approach is that new attributes can easily be added
without modifying the database.
changes (such as added VLAN driver support for a switch IC) automatically
propagate down to the product/marketing-name level...
and well, on platforms with device-tree support it then also should not be
difficult to populate the database...
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Interest in a openwrt router database to partially replace TOH?
* Manuel Munz [09.12.2013 14:16]: > * Integrating more information directly into the build system also > sounds like a good idea, though i'm not really sure how that would be > done on a per model basis. And then the question is how much information > would we want to add there and if devs also think some model specific > info should go directly in the repository. Might need some more thinking > about it. IMHO it is OK to just use the wiki for everything. We already have user/password/tracking there and as far as i understand, it should be possible to use this: http://www.mediawiki.org/wiki/Extension:Semantic_Forms/Defining_forms (the openwrt-wiki is mediawiki - isnt'it?) so you can have such forms via a template: http://discoursedb.org/wiki/Special:FormEdit/Item/Some_new_opinion_item so we have all in one place and it gets backupped... (and is machine and user readable) bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] AR71xx question: Writing to MDIO bus before mdio_register to power up PHYs
Hi there,
I'm currently trying to figure out a way how to solve the following
issue elegantly (i.e. from the mach file):
Target Device: WD My Net N750 (AR9344 based, with AR8327N switch)
Problem:
The device powers down all the PHYs from within the bootloader (possibly
to prevent early LAN <-> WAN leakage, as the ports are on the same
switch and separated by VLANs only).
The PHYs are powered down by writing 0x800 (Set Bit 11 (POWER_DOWN) to
1) to register 0x0 of each PHY from within the bootloader.
The PHYs cannot be read while powered down (but can be written). This
results in mdiobus_scan (drivers/net/phy/mdio_bus.c) reading bogus PHY IDs.
Solution:
Power all PHYs back up by writing 0x1000 (Set Bit 12 (AUTO_
NEGOTIATION) to 1) to register 0x0 of each PHY _before_ scanning the
MDIO bus for PHY IDs but _after_ resetting/initializing the bus.
I have attached a patch that works (but is a nasty hack).
So now I have the question how to handle this in a way that would also
be acceptable for upstream.
I was hoping for some input from the ar71xx gurus on how to do this :)
Thanks,
Felix
--- drivers/net/phy/mdio_bus.c.orig 2013-12-09 14:11:13.693202164 +0100
+++ drivers/net/phy/mdio_bus.c 2013-12-09 14:12:23.922744357 +0100
@@ -164,6 +164,10 @@
if (bus->reset)
bus->reset(bus);
+ for (i = 0; i < PHY_MAX_ADDR; i++)
+ mdiobus_write(bus, i, MII_BMCR, BMCR_RESET | BMCR_ANENABLE);
+ msleep(1000);
+
for (i = 0; i < PHY_MAX_ADDR; i++) {
if ((bus->phy_mask & (1 << i)) == 0) {
struct phy_device *phydev;
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] firewall rules and BARRIER BREAKER (Bleeding Edge, r38994)
Hi, I am using a script that uses uci to add firewall zones and rules. With this script i also want to remove these firewall rules again if needed. Can i add a label to these zone/rules so that i can use this to remove these rules. Greeting from Amsterdam, Perry ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Interest in a openwrt router database to partially replace TOH?
* Daniel Golle [09.12.2013 14:35]: > > VENDOR - e.g. 'TP-LINK' > > MODEL - e.g. 'TL-WR1043ND' > > VERSION - e.g. empty or 'v2' ? > > SALE_START - e.g. '2013-05' > > SALE_STOP - e.g. empty or '2014-08' > > STATUS - e.g. 'broken' or 'r12345' or 'WIP' > what about devices which work in old (brcm-2.4) builds but are no longer > supported in recent builds? I we should reference a per-version status (e.g. > 10.03 'not supported', 12.09 'supported', trunk confirmed to work with/since > r). Ideally, openwrt-specific details of the device should thus also be > referenced per openwrt build/release, e.g.: > * openwrt version (e.g. git tag or revision) > * openwrt target arch (e.g. 'ar71xx') > * openwrt target flavor (e.g. 'generic') > * openwrt profile (e.g. 'TLWR1043') > * openwrt boardname (e.g. 'tl-wr1043nd-v1') [...and many other ideas...] hh stop! this is all possible and sounds good, but it drives in a direction where nobody can maintain this. IMHO for further reference the user can just read the wikipage. dont take me wrong. all your ideas are good and helpful to build something really good, but...it's just too much. e.g.: if a target does work anymore: if somebody is interested in getting this to work, he will take a look into git/svn or the wikipage e.g. if a target has multiple brands with the same hardware: just make several wikipages and fillout the template. e.g. if we try to categorize all chips in a router it never ends. so there is a need for such a database (otherwise there would'nt be a discussion), but for which needs? for me: - having a possibility to find firmware-files for the enduser (so we need a table with vendor/model -> openwrt-filename) - searching a router which fits XY conditions, e.g. 5ghz (the question again, how far will you go? e.g.: 5ghz + 2.4ghz + 100mbit 5port switch + 64mb ram + not EOL) and you? bye, bastian. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Interest in a openwrt router database to partially replace TOH?
On 09.12.2013 14:18, Daniel Golle wrote:
> what about devices which work in old (brcm-2.4) builds but are no longer
> supported in recent builds? I we should reference a per-version status (e.g.
> 10.03 'not supported', 12.09 'supported', trunk confirmed to work with/since
> r). Ideally, openwrt-specific details of the device should thus also be
> referenced per openwrt build/release, e.g.:
> * openwrt version (e.g. git tag or revision)
> * openwrt target arch (e.g. 'ar71xx')
> * openwrt target flavor (e.g. 'generic')
> * openwrt profile (e.g. 'TLWR1043')
> * openwrt boardname (e.g. 'tl-wr1043nd-v1')
>
Thats is almost like i proposed in my database schema, so i agree. We
need to have these things on a per-release basis (target name or profile
etc might change between releases). If a device does not have an entry
for firmware x then we can suppose the device is not supported by that
firmware. trunk will be a bit special and should indeed contain a
"supported since rev" field.
>
>> other ideas?
> * EAN/barcode (image the "can this box run openwrt" bar-code-scanner android
> app
> which can eventually become a mobile installer tool to flash openwrt via the
> stock firmware web-interface after scanning barcode on the package..)
yes, should be easy to build things upon such a database
> * links (e.g. wikidevi record, vendor product page, stock firmware/dumps, ...)
i also implemented this partially, would be easy to add more links.
> * target market ('ETSI', 'FCC', 'China', 'World', ...)
good idea, didn't think of that yet
> * some way to add aliases for OEM products sold by multiple brands
i like that too
> * maybe we should use a more atomic approach instead of a table with a lot of
> rows?
> i.e. have 4 tables, "attributes", "components" and n-to-n mappings for
> attributes<->components and components<->components
>
i tried to do it similar but with more tables because it also appears
most reasonable to me. e.g. specify which and how many chips
(flash/ram/wifi etc) are in the device and have infos for these in
seperate tables.
Regards, Manuel
signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] libevent2: Configure with --disable-debug-mode
Saves around 10K. Signed-off-by: Helmut Schaa --- package/libs/libevent2/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/package/libs/libevent2/Makefile b/package/libs/libevent2/Makefile index e260e12..42ec94d 100644 --- a/package/libs/libevent2/Makefile +++ b/package/libs/libevent2/Makefile @@ -109,7 +109,8 @@ TARGET_CFLAGS += $(FPIC) CONFIGURE_ARGS += \ --enable-shared \ - --enable-static + --enable-static \ + --disable-debug-mode MAKE_FLAGS += \ CFLAGS="$(TARGET_CFLAGS)" -- 1.8.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] AR71xx question: Writing to MDIO bus before mdio_register to power up PHYs
2013/12/9 Felix Kaechele : > Hi there, > > I'm currently trying to figure out a way how to solve the following issue > elegantly (i.e. from the mach file): > > Target Device: WD My Net N750 (AR9344 based, with AR8327N switch) > > Problem: > The device powers down all the PHYs from within the bootloader (possibly to > prevent early LAN <-> WAN leakage, as the ports are on the same switch and > separated by VLANs only). > The PHYs are powered down by writing 0x800 (Set Bit 11 (POWER_DOWN) to 1) to > register 0x0 of each PHY from within the bootloader. > The PHYs cannot be read while powered down (but can be written). This > results in mdiobus_scan (drivers/net/phy/mdio_bus.c) reading bogus PHY IDs. > > Solution: > Power all PHYs back up by writing 0x1000 (Set Bit 12 (AUTO_ > NEGOTIATION) to 1) to register 0x0 of each PHY _before_ scanning the MDIO > bus for PHY IDs but _after_ resetting/initializing the bus. I would believe that attempting a PHY reset through BMCR_RESET should bring us back into a state where the PHYs will be responding again. It does not look like there are other platforms upstream having this problem, but this does sound like we should be handling this. I just sent some patches upstream which attempt to consolidate the PHY reset: http://patchwork.ozlabs.org/patch/298274/ maybe you could use this, you would need to slightly relax the constraints in phy_init_hw(), basically issuing the reset through BMCR_RESET and then using phy_poll_reset(). > > I have attached a patch that works (but is a nasty hack). > > So now I have the question how to handle this in a way that would also be > acceptable for upstream. > I was hoping for some input from the ar71xx gurus on how to do this :) -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] AR71xx question: Writing to MDIO bus before mdio_register to power up PHYs
2013/12/9 Florian Fainelli : > 2013/12/9 Felix Kaechele : >> Hi there, >> >> I'm currently trying to figure out a way how to solve the following issue >> elegantly (i.e. from the mach file): >> >> Target Device: WD My Net N750 (AR9344 based, with AR8327N switch) >> >> Problem: >> The device powers down all the PHYs from within the bootloader (possibly to >> prevent early LAN <-> WAN leakage, as the ports are on the same switch and >> separated by VLANs only). >> The PHYs are powered down by writing 0x800 (Set Bit 11 (POWER_DOWN) to 1) to >> register 0x0 of each PHY from within the bootloader. >> The PHYs cannot be read while powered down (but can be written). This >> results in mdiobus_scan (drivers/net/phy/mdio_bus.c) reading bogus PHY IDs. I just re-read the 802.3 clause 22 standard, and this sounds non-compliant: "While in the power-down state, the PHY shall respond to management transactions." the standard does not define though whether the PHY should respond correctly though. Did you confirm that it does not respond with its correct PHY ID1&ID3 values? Is this a real PHY or is this a specific port from a switch? -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] modprobe ignoring parameters in /etc/modules.d/files?
Hi, I just installed latest trunk snapshot (r38999) and some i2c/hwmon-packages on my 1043nd and issued an insmod i2c-gpio-custom bus0=0,20,0 which worked properly. So I created the file /etc/modules.d/66-i2c-gpio-custom with the content: i2c-gpio-custom bus0=0,20,0 but after reboot I get like 7 times the following message in dmesg: [7.16] Custom GPIO-based I2C driver version 0.1.1 [7.17] i2c-gpio-custom: no bus parameter(s) specified This is not happening on a different router running still r37855. So it seems to me, that during the conversion from insmod to modprobe either the syntax for module parameter under /etc/modules.d/ has changed, or module parameters are ignored at the moment. Can somebody help? Thanks. Hartmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] AR71xx question: Writing to MDIO bus before mdio_register to power up PHYs
Florian Fainelli wrote:
Did you confirm that it does not respond with its
correct PHY ID1&ID3 values?
This is the output I get for the PHY IDs on the mdio bus when the PHYs
are in power down state (this is the default state in which the device
comes up):
root@OpenWrt:/sys/devices/platform/ag71xx-mdio.0# for phy in
ag71xx-mdio.0\:*; do echo -n "${phy}: "; cat ${phy}/phy_id; done
ag71xx-mdio.0:10: 0x0760
ag71xx-mdio.0:11: 0x
ag71xx-mdio.0:12: 0x1280
ag71xx-mdio.0:13: 0x
ag71xx-mdio.0:14: 0x
ag71xx-mdio.0:15: 0x
ag71xx-mdio.0:16: 0x
ag71xx-mdio.0:17: 0x
ag71xx-mdio.0:18: 0x0760
This results in: ag71xx.0: no PHY found with phy_mask=0001
And this is the output for powered up PHYs (powered up in the bootloader
by interrupting automatic booting):
root@OpenWrt:/sys/devices/platform/ag71xx-mdio.0# for phy in
ag71xx-mdio.0\:*; do echo -n "${phy}: "; cat ${phy}/phy_id; done
ag71xx-mdio.0:00: 0x004dd033
ag71xx-mdio.0:01: 0x004dd033
ag71xx-mdio.0:02: 0x004dd033
ag71xx-mdio.0:03: 0x004dd033
ag71xx-mdio.0:04: 0x004dd033
ag71xx-mdio.0:10: 0x
ag71xx-mdio.0:11: 0x10411084
ag71xx-mdio.0:12: 0x
ag71xx-mdio.0:13: 0x7fff7fff
ag71xx-mdio.0:14: 0x7fff7fff
ag71xx-mdio.0:15: 0x7fff7fff
ag71xx-mdio.0:16: 0x00c2
ag71xx-mdio.0:17: 0x004a003a
ag71xx-mdio.0:18: 0x
This results in: ag71xx.0: connected to PHY at ag71xx-mdio.0:00
[uid=004dd033, driver=Atheros AR8216/AR8236/AR8316]
Is this a real PHY or is this a specific
port from a switch?
These are the 5 Ports of the AR8327N switch which is connected to GMAC0
of the AR9344 in RGMII mode.
Obviously the PHYs cannot be found when in powered down state. This is
the reason why the probing of the switch fails. All the mdio bus scan
sees is PHY ID garbage because the relevant PHYs aren't responding.
This is why I'm trying to perform a PHY reset / auto negotiation start
even before having the mdiobus_register function perform the mdio bus scan.
You can find the files/patches I use for this board here:
http://heffer.fedorapeople.org/openwrt/mynet-n750/
Thanks for your help so far!
Regards,
Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [Fwd: ubox allow module options in /etc/modules.d/]
Hi Hartmut,
I have the same problem and have a patch to fix it. Although it needs to
be improved by me or John Crispin, it works for me using the i2c-gpio
module with options in /etc/modules.d
Regards,
Simon.
Original Message
Subject: ubox allow module options in /etc/modules.d/
From:"Simon G"
Date:Sun, November 3, 2013 14:27
To: n...@openwrt.org
--
Hi Felix,
I'm using OpenWRT trunk with i2c-gpio-custom which requires a kernel
module parameter to work. Using the usual method of creating a file in
/etc/modules.d/ dosn't work anymore with ubox kmodloader
I have patched ubox to try the insert_module function with options if the
load_modprobe function fails.
This seems to work nicely for me.
I wasn't sure if I should send a patch to you with a diff against your git
repo or an OpenWRT patch.
I have attached a patch file I put in OpenWRT
package/system/ubox/patches/001-allow_module_options_on_autoload.patch
It's inline here too ...
--- a/kmodloader.c 2013-11-02 16:33:12.0 +0100
+++ b/kmodloader.c 2013-11-03 14:14:43.177708160 +0100
@@ -697,6 +697,7 @@
char *nl = strchr(mod, '\n');
struct module *m;
char *opts;
+ char *name;
if (nl)
*nl = '\0';
@@ -705,14 +706,24 @@
if (opts)
*opts++ = '\0';
- m = find_module(get_module_name(mod));
+ name = get_module_name(mod);
+ m = find_module(name);
if (!m || (m->state == LOADED))
continue;
m->state = PROBE;
if (basename(gl.gl_pathv[j])[0] - '0' <= 9)
- load_modprobe();
-
+ {
+ /* 1st try modprobe. If that fails try insmod
with options from line */
+ if (load_modprobe())
+ {
+ if
(!insert_module(get_module_path(name),opts))
+ {
+ m->state = LOADED;
+ m->error = 0;
+ }
+ }
+ }
}
free(mod);
fclose(fp);
Let me know what you think.
Regards,
Simon Gaynor.
--- a/kmodloader.c 2013-11-02 16:33:12.0 +0100
+++ b/kmodloader.c 2013-11-03 14:14:43.177708160 +0100
@@ -697,6 +697,7 @@
char *nl = strchr(mod, '\n');
struct module *m;
char *opts;
+ char *name;
if (nl)
*nl = '\0';
@@ -705,14 +706,24 @@
if (opts)
*opts++ = '\0';
- m = find_module(get_module_name(mod));
+ name = get_module_name(mod);
+ m = find_module(name);
if (!m || (m->state == LOADED))
continue;
m->state = PROBE;
if (basename(gl.gl_pathv[j])[0] - '0' <= 9)
-load_modprobe();
-
+ {
+/* 1st try modprobe. If that fails try insmod with options from line */
+if (load_modprobe())
+{
+ if (!insert_module(get_module_path(name),opts))
+ {
+ m->state = LOADED;
+ m->error = 0;
+ }
+}
+ }
}
free(mod);
fclose(fp);___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
