Re: [OpenWrt-Devel] Duplicate netifd protocol for l2tp
On 19.07.2014 08:48, Baptiste Jonglez wrote: > Hi, > > Two packages provide the "proto l2tp" netifd protocol: xl2tpd [1] in the > new packages feed, and l2tpv3tun [2] in oldpackages. > > The config are totally different, the problem is really a name clash. It seems they are doing things differently xl2tpd is RFC2661 (https://github.com/xelerance/xl2tpd/blob/master/README.xl2tpd) l2tpv3 is RFC5641 (http://tools.ietf.org/html/rfc5641) changes are in: http://tools.ietf.org/html/rfc3931#section-1.1 > What is the recommended way to deal with name clashes in netifd protocols, > without breaking existing user configuration? > > In this case, using "proto l2tpv2" for xl2tpd and "proto l2tpv3" for > l2tpv3tun would probably be the cleanest, but it would break configuration > for anyone using one or the other :) > clean versions leads to less confusion > Note that only the l2tpv3tun configuration is documented right now [3]. > > Thanks, > Baptiste > > [1] https://github.com/openwrt/packages/tree/master/net/xl2tpd > [2] http://git.openwrt.org/?p=packages.git;a=tree;f=net/l2tpv3tun > [3] > http://wiki.openwrt.org/doc/uci/network#protocol.l2tp.l2tp.pseudowire.tunnel > I wrote something about l2tpv3tun earlier,see : http://patchwork.openwrt.org/patch/4891/ Arguments for using iproute2 instead of l2tpv3tun might still apply ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] uClibc-ng
On Sun, Jul 20, 2014 at 9:13 PM, Waldemar Brodkorb wrote: > Hello Embedded Linux Hackers, > > it seems there is no plan to release a new uClibc version. > The current maintainer does not response on any public or private mails > about a plan to do a needed release. Therefore most of you carrying a lot > of patches against uClibc 0.9.33.2 to make it work in your project. > A really ugly situation. > I have seen some patches got in uClibc upstream some weeks ago (-> inactivity). But anyway, a 1st try... Look at OpenSSL and LibreSSL... Might be we see some competition or rebirth starting here, too? My POV (from my experiences) is most embedded projects are not really interested in upstream work or keep their own patches (this seems to be easier). An example: Recently, I pointed to [0], but the maintainer of the project did not give any feedback to Bernd (requested a simple S-o-b). What I want to say it is not only a problem of the uClibc maintainer :-). >From my experiences successful projects do regular releases (6 months or a year). What are your plans? > To get out of this situation I started a spin-off called uClibc-ng. > The website for the project is here: http://www.uclibc-ng.org > Beta 3 is tagged and downloadable via > http://downloads.uclibc-ng.org/uClibc-ng-1.0.0beta3.tar.xz > Do you plan a browsable Git website, where someone can look at the source via webbrowser? OK, you have now an infrastructure... Do you have people (developers, users) behind you :-)? > If you want a 1.0 in the near future please test and report back any > issues. You can use the bug tracker, the mailing list or dicussion forum > to report back. To prevent spam you need to be subscribed or registered. > > I have added most of the patches from your projects on top of uClibc > master. > Did you look also at the patches [1] from the Freetz project? Thanks for your initial work! - Sedat - [0] http://freetz.org/browser/trunk/toolchain/make/target/uclibc/0.9.32.1/100-fix_hosttools.patch [1] http://freetz.org/browser/trunk/toolchain/make/target/uclibc ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 00/17] atheros: checkpatch fixes
On Jul 20, 2014 11:27 AM, "Daniel Gimpelevich" < dan...@gimpelevich.san-francisco.ca.us> wrote: > > On Tue, 2014-06-24 at 13:51 -0700, Florian Fainelli wrote: > > 2014-06-24 13:30 GMT-07:00 Daniel Gimpelevich > > : > > > On Tue, 2014-06-24 at 12:38 -0700, Florian Fainelli wrote: > > >> I think AR231x has none of those, it's an End of Life platform, the > > >> code base has been mostly static and well know for a while, so I would > > >> argue that Device Tree should not be made a requirement here as it > > >> will just delay Sergey's upstreaming effort even more. > > >> > > > Very valuable input. Still, there is no way for software to determine > > > which AR231x board it's running on, and they all have different uses of > > > GPIO, plus the AR2317 watchdog operates completely differently from the > > > AR2315 one. What solution do you propose? Some earlier discussion: > > > http://patchwork.openwrt.org/patch/4351/ > > > > For GPIOs, since the way they are used most likely varies on a > > per-board basis, we could probably come up with the same mechanism as > > used on ath79 where we end-up patching the kernel command-line to > > insert a MIPS machine id for instance. > > > > For the watchdog driver, if we have access to a revision register we > > can read at runtime, then we could use a separate platform driver name > > (e.g: ar2315-wdt vs ar2317-wdt) that would lead to either two separate > > drivers to get registered, or have different code-paths being used in > > the same ar231x driver. In case we do not have that revision register, > > we can leverage solution 1) for GPIOs. > > Wait, what is this "ath79" target? Meant to write ar71xx, the upstream Linux name for it is ath79 from arch/mips/ > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar71xx: Register reset button on UBNT AirGW
The airGateway has a reset button connected to GPIO 12, so we should use it.
Signed-off-by: Matthew Reeve
diff --git
a/target/linux/ar71xx/patches-3.10/722-MIPS-ath79-add-airGateway-support.patch
b/target/linux/ar71xx/patches-3.10/722-MIPS-ath79-add-airGateway-support.patch
index d64007d..0fe62d9 100644
---
a/target/linux/ar71xx/patches-3.10/722-MIPS-ath79-add-airGateway-support.patch
+++
b/target/linux/ar71xx/patches-3.10/722-MIPS-ath79-add-airGateway-support.patch
@@ -12,7 +12,7 @@
#include "dev-ap9x-pci.h"
#include "dev-eth.h"
#include "dev-gpio-buttons.h"
-@@ -389,3 +391,50 @@ static void __init ubnt_nano_m_xw_setup(
+@@ -389,3 +391,65 @@ static void __init ubnt_nano_m_xw_setup(
MIPS_MACHINE(ATH79_MACH_UBNT_NANO_M_XW, "UBNT-NM-XW", "Ubiquiti Nanostation M
XW",
ubnt_nano_m_xw_setup);
@@ -27,6 +27,17 @@
+ },
+};
+
++static struct gpio_keys_button airgateway_gpio_keys[] __initdata = {
++ {
++ .desc = "reset",
++ .type = EV_KEY,
++ .code = KEY_RESTART,
++ .debounce_interval = UBNT_XM_KEYS_DEBOUNCE_INTERVAL,
++ .gpio = 12,
++ .active_low = 1,
++ }
++};
++
+static void __init ubnt_airgateway_setup(void)
+{
+ u32 t;
@@ -49,6 +60,10 @@
+ ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_airgateway_gpio_leds),
+ ubnt_airgateway_gpio_leds);
+
++ ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
++ ARRAY_SIZE(airgateway_gpio_keys),
++ airgateway_gpio_keys);
++
+ ath79_init_mac(ath79_eth1_data.mac_addr, mac0, 0);
+ ath79_init_mac(ath79_eth0_data.mac_addr, mac1, 0);
+
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT IPv6 firewall
On Sat, 19 Jul 2014, Gert Doering wrote: On Fri, Jul 18, 2014 at 04:08:02PM -0700, David Lang wrote: go do a tcpdump of your WAN interface some time, look at all the attacks that are going on there (especially with an ISP that's not blocking it for you) I'm well aware of all the bullshit that is knocking on my doors all day. Point is, firewalls on the *routers* are not goint to help the laptop that moves around, attaches to a Wifi Hotspot, is hacked there, gets moved back behind your firewall, and starts hacking others from there. And it doesn't help the desktop PC that neglected to do any updates, gets infected by flash/pdf/word exploit, and starts scanning your network, behind the firewall. The problem here isn't with laptops, it's with TVs, light Bulbs, Thermostats, digital picture frames, etc. These are the types of devices that I'm worried about protecting. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [project/ucwmp.git][PATCH] session: check for uclient_connect return value
uclient_connect may return an error and calling uclient_write will cause
a crash
Signed-off-by: Rafał Miłecki
---
session/main.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/session/main.c b/session/main.c
index 147c949..e35cd5b 100644
--- a/session/main.c
+++ b/session/main.c
@@ -139,9 +139,16 @@ static void cwmp_dump_message(const char *msg, const char
*data)
static void __cwmp_send_request(struct uloop_timeout *t)
{
int len = 0;
+ int err;
+
cwmp_dump_message("Send CPE data", cur_request);
- uclient_connect(uc);
+ err = uclient_connect(uc);
+ if (err) {
+ fprintf(stderr, "Failed to connect to the server: %d\n", err);
+ return;
+ }
+
uclient_http_set_request_type(uc, "POST");
cwmp_add_cookies(uc);
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] uClibc-ng
Hello Embedded Linux Hackers, it seems there is no plan to release a new uClibc version. The current maintainer does not response on any public or private mails about a plan to do a needed release. Therefore most of you carrying a lot of patches against uClibc 0.9.33.2 to make it work in your project. A really ugly situation. To get out of this situation I started a spin-off called uClibc-ng. The website for the project is here: http://www.uclibc-ng.org Beta 3 is tagged and downloadable via http://downloads.uclibc-ng.org/uClibc-ng-1.0.0beta3.tar.xz If you want a 1.0 in the near future please test and report back any issues. You can use the bug tracker, the mailing list or dicussion forum to report back. To prevent spam you need to be subscribed or registered. I have added most of the patches from your projects on top of uClibc master. Thanks Waldemar ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 00/17] atheros: checkpatch fixes
On Tue, 2014-06-24 at 13:51 -0700, Florian Fainelli wrote: > 2014-06-24 13:30 GMT-07:00 Daniel Gimpelevich > : > > On Tue, 2014-06-24 at 12:38 -0700, Florian Fainelli wrote: > >> I think AR231x has none of those, it's an End of Life platform, the > >> code base has been mostly static and well know for a while, so I would > >> argue that Device Tree should not be made a requirement here as it > >> will just delay Sergey's upstreaming effort even more. > >> > > Very valuable input. Still, there is no way for software to determine > > which AR231x board it's running on, and they all have different uses of > > GPIO, plus the AR2317 watchdog operates completely differently from the > > AR2315 one. What solution do you propose? Some earlier discussion: > > http://patchwork.openwrt.org/patch/4351/ > > For GPIOs, since the way they are used most likely varies on a > per-board basis, we could probably come up with the same mechanism as > used on ath79 where we end-up patching the kernel command-line to > insert a MIPS machine id for instance. > > For the watchdog driver, if we have access to a revision register we > can read at runtime, then we could use a separate platform driver name > (e.g: ar2315-wdt vs ar2317-wdt) that would lead to either two separate > drivers to get registered, or have different code-paths being used in > the same ar231x driver. In case we do not have that revision register, > we can leverage solution 1) for GPIOs. Wait, what is this "ath79" target? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Current state of 802.11h
Hi, what's the current state of 802.11h (Transmit Power Control and Dynamic Frequency Selection)? -- Best regards, Renne ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [patch] [package] ca-certificates: create symbolic link for certificate hashes
Am 20.07.2014 09:06, schrieb Felix Fietkau: > On 2014-07-19 12:16, Christian Schoenebeck wrote: >> From: Christian Schoenebeck >> Date: Sat, 19 Jul 2014 11:14:01 +0200 >> Subject: ca-certificates: create symbolic link for certificate hashes >> >> Implementing "add-cert.sh" functionality discribed at >> http://wiki.openwrt.org/doc/howto/wget-ssl-certs into Makefile >> otherwise you need to create symbolic links for certificate hashes yourself. >> >> Signed-off-by: Christian Schoenebeck >> --- >> package/system/ca-certificates/Makefile | 13 + >> 1 file changed, 13 insertions(+) >> >> diff --git a/package/system/ca-certificates/Makefile >> b/package/system/ca-certificates/Makefile >> index 7f38c86..534c38b 100644 >> --- a/package/system/ca-certificates/Makefile >> +++ b/package/system/ca-certificates/Makefile >> @@ -34,6 +34,19 @@ endef >> define Package/ca-certificates/install >> $(INSTALL_DIR) $(1)/etc/ssl/certs >> $(INSTALL_DATA) $(PKG_INSTALL_DIR)/usr/share/ca-certificates/*/*.crt >> $(1)/etc/ssl/certs/ >> + >> +OPENSSL=/usr/bin/openssl ; \ >> +CERTDIR=$(1)/etc/ssl/certs ; \ > The use of shell variables here is unnecessary. make variables are more > convenient because you don't need . > Also, please don't hardcode the openssl path. OpenWrt build prereq > checks already test if OpenSSL is installed, so you can safely assume > that it is available. Just call 'openssl' without specifying a path. > > - Felix > Patch rebuilded and tested on WNDR3800 and VirtualBox x86 - Christian From: Christian Schoenebeck Date: Sun, 20 Jul 2014 10:48:50 +0200 Subject: [PATCH] [package] ca-certificates: create symbolic link for certificate hashes Implementing "add-cert.sh" functionality described at http://wiki.openwrt.org/doc/howto/wget-ssl-certs into Makefile otherwise you need to create symbolic links for certificate hashes yourself. Signed-off-by: Christian Schoenebeck --- package/system/ca-certificates/Makefile | 9 + 1 file changed, 9 insertions(+) diff --git a/package/system/ca-certificates/Makefile b/package/system/ca-certificates/Makefile index 7f38c86..08a853f 100644 --- a/package/system/ca-certificates/Makefile +++ b/package/system/ca-certificates/Makefile @@ -34,6 +34,15 @@ endef define Package/ca-certificates/install $(INSTALL_DIR) $(1)/etc/ssl/certs $(INSTALL_DATA) $(PKG_INSTALL_DIR)/usr/share/ca-certificates/*/*.crt $(1)/etc/ssl/certs/ + + for CERTFILE in `ls -1 $(1)/etc/ssl/certs`; do \ + HASH=`openssl x509 -hash -noout -in $(1)/etc/ssl/certs/CERTFILE` ; \ + SUFFIX=0 ; \ + while [ -h "$(1)/etc/ssl/certs/HASH.SUFFIX" ]; do \ + let "SUFFIX += 1" ; \ + done ; \ + ln -s "CERTFILE" "$(1)/etc/ssl/certs/HASH.SUFFIX" ; \ + done endef $(eval $(call BuildPackage,ca-certificates)) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.
Hi, sorry your email got lost somehow on my end... And the machine hosting mailing list is down at the moment it seems. here is the info: root@router:~# cat /tmp/sysinfo/* wndr4300 NETGEAR WNDR3700v4/WNDR4300 thanks, -paul On Sat, 2014-07-19 at 14:52 -0400, Paul Blazejowski wrote: > John, > > any update on this issue? i strongly believe that the hard-coded > wndr4300 string somewhere in the source is the culprit of the problem > since the wndr3700v4 board_detection is identified as wndr4300 thus the > sysupgrade works for 4300 but not for 3700v4. > > Regards, > -paul > > On Tue, 2014-06-24 at 23:15 +0200, John Crispin wrote: > > > > On 24/06/2014 22:43, Paul Blazejowski wrote: > > > i get "The uploaded image file does not contain a supported format. > > > Make sure that you choose the generic image format for your > > > platform." from web interface. > > > > > > this is what i have: > > > > > > -rw-r--r-- 1 diffie diffie 8919040 2014-06-24 15:58 > > > bin/ar71xx/openwrt-ar71xx-nand-wndr3700v4-squashfs-sysupgrade.tar > > > > > > should i push it from shell using sysupgrade script? > > > > > > > it will work from shell, i will look into why it fails via webui. > > > > > > > > > > > > > thanks! > > > > > > > > > On Tue, 2014-06-24 at 22:32 +0200, John Crispin wrote: > > >> > > >> On 24/06/2014 22:25, Paul Blazejowski wrote: > > >>> Hi again, > > >>> > > >>> thanks for the tftp fix, flushing just became so much faster > > >>> and easier. > > >>> > > >>> Tested trunk r41336 after your jffs2 fix and the image boots > > >>> fine, restored my configuration changes, rebooted the router > > >>> and all changes are saved now. I will post the working dmesg to > > >>> the ticket at https://dev.openwrt.org/ticket/16840 but it is > > >>> safe to say that you can close it ;-) now. > > >>> > > >>> Sysupgrade image(s) for 3700v4 and 4300 do not work now, guess > > >>> this is next on the list... > > >>> > > >> > > >> i tested 4300 and it works. you need to use the > > >> *-ubi-sysupgrade.tar file. > > >> > > >> > > >> > > >> > > >>> Thank you, -paul > > >>> > > >>> On Tue, 2014-06-24 at 20:18 +0200, John Crispin wrote: > > > > On 24/06/2014 19:05, Paul Blazejowski wrote: > > > John, > > > > > > Yes i use the reset with pin and from there i tftp the > > > original firmware from netgear after that i go to the gui > > > and upload the open-wrt image because the router will not > > > accept the wndr3700v4 image (there's a cosmetic fix for > > > that, i created a patch that someone from the forums has > > > sent months ago to this list but it was never accepted...) > > > https://dev.openwrt.org/ticket/16840 > > > > > > With that patch tftp'ing the > > > openwrt-ar71xx-nand-wndr3700v4-ubi-factory.img works > > > without need to flash the original firmware. > > > > > > If there's another method that can be used to flash the > > > image(s) please let me know i would want to try any > > > alternative ways of flashing and could learn a thing or two > > > in the process as well ;-) > > > > > > Thank you, -paul > > > > > > Hi, > > > > i just pushed the V vs v fix and another fix that removes > > the jffs2 magic. i think this might have been the cause of > > the problems. please retry with current trunk and let me know > > if the problem is gone or still there > > > > John ___ > > openwrt-devel mailing list openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > > > > > > > > > ___ openwrt-devel > > mailing list openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > >> > > > > ___ > > >> openwrt-devel mailing list openwrt-devel@lists.openwrt.org > > >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [orion] Update kernel to 3.10.44
On Sunday 20 July 2014 13:56:30 Felix Fietkau wrote:
> On 2014-07-20 11:20, Hauke Mehrtens wrote:
> > Hi,
> >
> > I am getting an error when compiling:
> >
> > /home/hauke/openwrt/git/staging_dir/host/bin/mkfs.jffs2
> > --compression-mode=none --pad --little-endian --squash -e 64KiB -o
> > '/home/hauke/openwrt/git/build_dir/target-arm_xscale_uClibc-0.9.33.2_eabi/
> > linux-orion_generic/wn802t-uImage.jffs2' -d
> > '/home/hauke/openwrt/git/tmp/wn802t_jffs2_uimage'
> > rm -rf '/home/hauke/openwrt/git/tmp/wn802t_jffs2_uimage'
> > [ `stat -c %s
> > '/home/hauke/openwrt/git/build_dir/target-arm_xscale_uClibc-0.9.33.2_eabi/
> > linux-orion_generic/wn802t-uImage.jffs2'` -le 1048576 ] || { echo '
> > ERROR:
> > /home/hauke/openwrt/git/build_dir/target-arm_xscale_uClibc-0.9.33.2_eabi/l
> > inux-orion_generic/wn802t-uImage.jffs2 too big (> 1048576 bytes)'; exit 1;
> > }
> >
> >ERROR:
> > /home/hauke/openwrt/git/build_dir/target-arm_xscale_uClibc-0.9.33.2_eabi/l
> > inux-orion_generic/wn802t-uImage.jffs2 too big (> 1048576 bytes)
> > make[5]: *** [install] Error 1
> >
> > You could try to move the ethernet controller and switch driver into a
> > kernel module to make the kernel image smaller.
>
> That's not useful as a long term solution, as 3.14 will likely get even
> bigger. Can we maybe make the partition size dynamic here?
Hm, I get the same error now (clean rebuild). Earlier (last week) it was
working (building and running on my router). I guess something got added that
increased the size..?
I'll await further discussion on whether to make the partition size dynamic,
as I agree with Felix that removing drivers from the kernel (into modules) is
not a viable solution for the long(er) term.
Regards,
Maarten
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [orion] Update kernel to 3.10.44
On 2014-07-20 11:20, Hauke Mehrtens wrote:
> Hi,
>
> I am getting an error when compiling:
>
> /home/hauke/openwrt/git/staging_dir/host/bin/mkfs.jffs2
> --compression-mode=none --pad --little-endian --squash -e 64KiB -o
> '/home/hauke/openwrt/git/build_dir/target-arm_xscale_uClibc-0.9.33.2_eabi/linux-orion_generic/wn802t-uImage.jffs2'
> -d '/home/hauke/openwrt/git/tmp/wn802t_jffs2_uimage'
> rm -rf '/home/hauke/openwrt/git/tmp/wn802t_jffs2_uimage'
> [ `stat -c %s
> '/home/hauke/openwrt/git/build_dir/target-arm_xscale_uClibc-0.9.33.2_eabi/linux-orion_generic/wn802t-uImage.jffs2'`
> -le 1048576 ] || { echo ' ERROR:
> /home/hauke/openwrt/git/build_dir/target-arm_xscale_uClibc-0.9.33.2_eabi/linux-orion_generic/wn802t-uImage.jffs2
> too big (> 1048576 bytes)'; exit 1; }
>ERROR:
> /home/hauke/openwrt/git/build_dir/target-arm_xscale_uClibc-0.9.33.2_eabi/linux-orion_generic/wn802t-uImage.jffs2
> too big (> 1048576 bytes)
> make[5]: *** [install] Error 1
>
> You could try to move the ethernet controller and switch driver into a
> kernel module to make the kernel image smaller.
That's not useful as a long term solution, as 3.14 will likely get even
bigger. Can we maybe make the partition size dynamic here?
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [ar71xx] fix WAN MAC setup on dir-825-c1
Changeset 38690 broke the WAN MAC setup. Here's the fix. Signed-off-by: Sebastian Kemper gmx.net> --- diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network index 481d458..cee1328 100755 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network @@ -240,7 +240,7 @@ dir-825-c1) ucidef_add_switch "switch0" "1" "1" ucidef_add_switch_vlan "switch0" "1" "0t 1 2 3 4" ucidef_add_switch_vlan "switch0" "2" "0t 5" - mac=$(mtd_get_mac_ascii nvram "^wan_mac") + mac=$(mtd_get_mac_ascii nvram "wan_mac") [ -n "$mac" ] && ucidef_set_interface_macaddr "wan" "$mac" ;; ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH]ramips: Add Ralink RT3XXX USB OHCI driver
On 20 July 2014 12:15, John Crispin wrote: > > > On 20/07/2014 10:36, 郭传鈜 wrote: >> I think I should reply to the mail list right ... I can't use my >> USB Modem with "ohci-platform" in current kernel…only "USB is >> connected(disconnected)"in kernel log and no /dev/ttyUSB is added… >> So I tried to use the driver from Ralink and my modem works well >> after I added this. EHCI driver works well so I did nothing with >> it. > > Hi Roman, > > do you have this board ? could you see if it also fails for you ? i > don't actually have any mt7620n hw with usb exported i think... > I remember using ohci/ehci drivers for mt7620n boards (because otg driver didn't work at all) but not sure if I tried any usb 1.1 devices. Unfortunately I can't test it right now, maybe 2-3 days later. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [orion] Update kernel to 3.10.44
On 07/20/2014 10:58 AM, Maarten Bezemer wrote:
> Update the kernel of the orion target to version 3.10.44.
> Refresh orion config and patches to match the changes in the kernel
>
> Tested on WRT350N-v2 device.
>
> Signed-off-by: Maarten Bezemer
> ---
> Makefile|2 +-
> config-default |2 ++
> files/arch/arm/mach-orion5x/dt2-setup.c |2 +-
> patches/200-dt2_board_support.patch |4 ++--
> patches/210-wn802t_support.patch| 10 +-
> patches/400-fix-section-mismatch-warnings.patch | 22 +-
> patches/a01-dt2-fixes-for-3.3.patch |2 +-
> 7 files changed, 13 insertions(+), 31 deletions(-)
>
Hi,
I am getting an error when compiling:
/home/hauke/openwrt/git/staging_dir/host/bin/mkfs.jffs2
--compression-mode=none --pad --little-endian --squash -e 64KiB -o
'/home/hauke/openwrt/git/build_dir/target-arm_xscale_uClibc-0.9.33.2_eabi/linux-orion_generic/wn802t-uImage.jffs2'
-d '/home/hauke/openwrt/git/tmp/wn802t_jffs2_uimage'
rm -rf '/home/hauke/openwrt/git/tmp/wn802t_jffs2_uimage'
[ `stat -c %s
'/home/hauke/openwrt/git/build_dir/target-arm_xscale_uClibc-0.9.33.2_eabi/linux-orion_generic/wn802t-uImage.jffs2'`
-le 1048576 ] || { echo ' ERROR:
/home/hauke/openwrt/git/build_dir/target-arm_xscale_uClibc-0.9.33.2_eabi/linux-orion_generic/wn802t-uImage.jffs2
too big (> 1048576 bytes)'; exit 1; }
ERROR:
/home/hauke/openwrt/git/build_dir/target-arm_xscale_uClibc-0.9.33.2_eabi/linux-orion_generic/wn802t-uImage.jffs2
too big (> 1048576 bytes)
make[5]: *** [install] Error 1
You could try to move the ethernet controller and switch driver into a
kernel module to make the kernel image smaller.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq xway: generate ramdisk image by default
i can build a ramdisk for the board for the reelase if it is needed to install. we do the same for the mikrotik boards. John On 20/07/2014 10:03, Ben Mulvihill wrote: > No problem. I'll try to make sure there is a link to a non-official > ramdisk image on the wiki. (Along with some installation > instructions, which at the moment are lacking!) > > Ben > > On Sun, 2014-07-20 at 08:54 +0200, John Crispin wrote: >> technically correct. however there is a dependency bug left over >> from some cargo cult cleanups. this causes the image builder to >> not build when ramdisk is enabled. i plan to clean this up post >> BB. i will ignore this patch until said time. >> >> John >> >> On 19/07/2014 15:13, Ben Mulvihill wrote: >>> The installation process on nand-based boards using ubi like >>> the BTHOMEHUBV2B makes use of a ramdisk image, so it makes >>> sense to generate this by default. >>> >>> Signed-off-by: Ben Mulvihill --- --- >>> a/target/linux/lantiq/xway/target.mk 2014-07-19 >>> 14:59:39.691201637 +0200 +++ >>> b/target/linux/lantiq/xway/target.mk2014-07-19 >>> 12:40:06.101871732 +0200 @@ -1,7 +1,7 @@ ARCH:=mips >>> SUBTARGET:=xway BOARDNAME:=XWAY -FEATURES:=squashfs atm mips16 >>> nand ubifs +FEATURES:=squashfs atm mips16 nand ubifs ramdisk >>> CPU_TYPE:=34kc CPU_SUBTYPE:=dsp >>> >>> ___ openwrt-devel >>> mailing list openwrt-devel@lists.openwrt.org >>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >>> >> >>> ___ >> openwrt-devel mailing list openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel > mailing list openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [orion] Update kernel to 3.10.44
Update the kernel of the orion target to version 3.10.44.
Refresh orion config and patches to match the changes in the kernel
Tested on WRT350N-v2 device.
Signed-off-by: Maarten Bezemer
---
Makefile|2 +-
config-default |2 ++
files/arch/arm/mach-orion5x/dt2-setup.c |2 +-
patches/200-dt2_board_support.patch |4 ++--
patches/210-wn802t_support.patch| 10 +-
patches/400-fix-section-mismatch-warnings.patch | 22 +-
patches/a01-dt2-fixes-for-3.3.patch |2 +-
7 files changed, 13 insertions(+), 31 deletions(-)
Index: target/linux/orion/Makefile
===
diff --git a/trunk/target/linux/orion/Makefile
b/trunk/target/linux/orion/Makefile
--- a/trunk/target/linux/orion/Makefile (revision 41762)
+++ b/trunk/target/linux/orion/Makefile (working copy)
@@ -12,7 +12,7 @@
SUBTARGETS:=generic harddisk
MAINTAINER:=Imre Kaloz
-LINUX_VERSION:=3.3.8
+LINUX_VERSION:=3.10.44
include $(INCLUDE_DIR)/target.mk
Index: target/linux/orion/config-default
===
diff --git a/trunk/target/linux/orion/config-default
b/trunk/target/linux/orion/config-default
--- a/trunk/target/linux/orion/config-default (revision 41762)
+++ b/trunk/target/linux/orion/config-default (working copy)
@@ -3,6 +3,7 @@
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_ARCH_NR_GPIO=0
CONFIG_ARCH_ORION5X=y
+# CONFIG_ARCH_ORION5X_DT is not set
CONFIG_ARCH_REQUIRE_GPIOLIB=y
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
@@ -92,6 +93,7 @@
# CONFIG_LZO_COMPRESS is not set
# CONFIG_LZO_DECOMPRESS is not set
# CONFIG_MACH_BIGDISK is not set
+# CONFIG_MACH_EDMINI_V2_DT is not set
# CONFIG_MACH_D2NET is not set
# CONFIG_MACH_DB88F5281 is not set
# CONFIG_MACH_DNS323 is not set
Index: target/linux/orion/files/arch/arm/mach-orion5x/dt2-setup.c
===
diff --git a/trunk/target/linux/orion/files/arch/arm/mach-orion5x/dt2-setup.c
b/trunk/target/linux/orion/files/arch/arm/mach-orion5x/dt2-setup.c
--- a/trunk/target/linux/orion/files/arch/arm/mach-orion5x/dt2-setup.c
(revision 41762)
+++ b/trunk/target/linux/orion/files/arch/arm/mach-orion5x/dt2-setup.c
(working copy)
@@ -441,6 +441,6 @@
.init_machine = dt2_init,
.map_io = orion5x_map_io,
.init_irq = orion5x_init_irq,
- .timer = &orion5x_timer,
+ .init_time = orion5x_timer_init,
.fixup = openwrt_fixup, //tag_fixup_mem32,
MACHINE_END
Index: target/linux/orion/patches/200-dt2_board_support.patch
===
diff --git a/trunk/target/linux/orion/patches/200-dt2_board_support.patch
b/trunk/target/linux/orion/patches/200-dt2_board_support.patch
--- a/trunk/target/linux/orion/patches/200-dt2_board_support.patch
(revision
41762)
+++ b/trunk/target/linux/orion/patches/200-dt2_board_support.patch
(working
copy)
@@ -1,6 +1,6 @@
--- a/arch/arm/mach-orion5x/Kconfig
+++ b/arch/arm/mach-orion5x/Kconfig
-@@ -16,6 +16,13 @@ config MACH_RD88F5182
+@@ -23,6 +23,13 @@ config MACH_RD88F5182
Say 'Y' here if you want your kernel to support the
Marvell Orion-NAS (88F5182) RD2
@@ -16,7 +16,7 @@
select I2C_BOARDINFO
--- a/arch/arm/mach-orion5x/Makefile
+++ b/arch/arm/mach-orion5x/Makefile
-@@ -18,6 +18,7 @@ obj-$(CONFIG_MACH_BIGDISK) += d2net-setu
+@@ -17,6 +17,7 @@ obj-$(CONFIG_MACH_BIGDISK) += d2net-setu
obj-$(CONFIG_MACH_NET2BIG)+= net2big-setup.o
obj-$(CONFIG_MACH_MSS2) += mss2-setup.o
obj-$(CONFIG_MACH_WNR854T)+= wnr854t-setup.o
Index: target/linux/orion/patches/210-wn802t_support.patch
===
diff --git a/trunk/target/linux/orion/patches/210-wn802t_support.patch
b/trunk/target/linux/orion/patches/210-wn802t_support.patch
--- a/trunk/target/linux/orion/patches/210-wn802t_support.patch (revision
41762)
+++ b/trunk/target/linux/orion/patches/210-wn802t_support.patch (working
copy)
@@ -1,6 +1,6 @@
--- a/arch/arm/mach-orion5x/Kconfig
+++ b/arch/arm/mach-orion5x/Kconfig
-@@ -139,10 +139,13 @@ config MACH_MSS2
+@@ -146,10 +146,13 @@ config MACH_MSS2
Maxtor Shared Storage II platform.
config MACH_WNR854T
@@ -47,8 +47,8 @@
+
orion5x_uart0_init();
- orion5x_setup_dev_boot_win(WNR854T_NOR_BOOT_BASE,
-@@ -167,7 +181,7 @@ static struct hw_pci wnr854t_pci __initd
+ mvebu_mbus_add_window("devbus-boot", WNR854T_NOR_BOOT_BASE,
+@@ -166,7 +180,7 @@ static struct hw_pci wnr854t_pci __initd
static int __init wnr854t_pci_init(void)
{
@@ -57,7 +57,7 @@
pci_common_init(&wnr854t_pci);
return 0;
-@@ -178
Re: [OpenWrt-Devel] [PATCH] [orion] Update kernel to 3.14.12
On Sunday 20 July 2014 10:46:28 Hauke Mehrtens wrote: > On 07/20/2014 10:39 AM, Maarten Bezemer wrote: > > Update the kernel of the orion target to version 3.14.12. > > Refresh orion config and patches to match the changes in the kernel > > > > Tested on WRT350N-v2 device. > > > > Signed-off-by: Maarten Bezemer > > --- > > > > Makefile|2 > > config-default | 177 > > +--- files/arch/arm/mach-orion5x/dt2-setup.c > > |2 > > patches/200-dt2_board_support.patch |4 > > patches/210-wn802t_support.patch| 10 - > > patches/400-fix-section-mismatch-warnings.patch | 31 <-- Empty > > now, please delete patches/a01-dt2-fixes-for-3.3.patch | > > 2 > > 7 files changed, 167 insertions(+), 61 deletions(-) > > Hi, > > We use Kernel 3.10 for OpenWrt BB release, so if you want this in BB you > should update the kernel to version 3.10. > > I would suggest you send a patch for kernel 3.10 and then this could > probably be added to BB. I do not have such a device, so you have to run > test this also. > > Hauke I have the patches for 3.10.44 as well, just before sending them I thought that you guys would like to have the target updated to a more recent kernel. I'll send the 3.10.44 patch in a moment Regards, Maarten ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [orion] Update kernel to 3.14.12
On 07/20/2014 10:39 AM, Maarten Bezemer wrote: > Update the kernel of the orion target to version 3.14.12. > Refresh orion config and patches to match the changes in the kernel > > Tested on WRT350N-v2 device. > > Signed-off-by: Maarten Bezemer > --- > Makefile|2 > config-default | 177 > +--- > files/arch/arm/mach-orion5x/dt2-setup.c |2 > patches/200-dt2_board_support.patch |4 > patches/210-wn802t_support.patch| 10 - > patches/400-fix-section-mismatch-warnings.patch | 31 <-- Empty now, > please delete > patches/a01-dt2-fixes-for-3.3.patch |2 > 7 files changed, 167 insertions(+), 61 deletions(-) > Hi, We use Kernel 3.10 for OpenWrt BB release, so if you want this in BB you should update the kernel to version 3.10. I would suggest you send a patch for kernel 3.10 and then this could probably be added to BB. I do not have such a device, so you have to run test this also. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [orion] Update kernel to 3.14.12
Update the kernel of the orion target to version 3.14.12. Refresh orion config and patches to match the changes in the kernel Tested on WRT350N-v2 device. Signed-off-by: Maarten Bezemer --- Makefile|2 config-default | 177 +--- files/arch/arm/mach-orion5x/dt2-setup.c |2 patches/200-dt2_board_support.patch |4 patches/210-wn802t_support.patch| 10 - patches/400-fix-section-mismatch-warnings.patch | 31 <-- Empty now, please delete patches/a01-dt2-fixes-for-3.3.patch |2 7 files changed, 167 insertions(+), 61 deletions(-) Index: target/linux/orion/Makefile === --- target/linux/orion/Makefile (revision 41762) +++ target/linux/orion/Makefile (working copy) @@ -12,7 +12,7 @@ SUBTARGETS:=generic harddisk MAINTAINER:=Imre Kaloz -LINUX_VERSION:=3.3.8 +LINUX_VERSION:=3.14.12 include $(INCLUDE_DIR)/target.mk Index: target/linux/orion/config-default === --- target/linux/orion/config-default (revision 41762) +++ target/linux/orion/config-default (working copy) @@ -1,12 +1,21 @@ +# CONFIG_AIO is not set CONFIG_ALIGNMENT_TRAP=y CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y -CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y +CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y +CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y +CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y +# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set CONFIG_ARCH_NR_GPIO=0 CONFIG_ARCH_ORION5X=y +# CONFIG_ARCH_ORION5X_DT is not set CONFIG_ARCH_REQUIRE_GPIOLIB=y # CONFIG_ARCH_SELECT_MEMORY_MODEL is not set # CONFIG_ARCH_SPARSEMEM_DEFAULT is not set -# CONFIG_ARCH_USES_GETTIMEOFFSET is not set +CONFIG_ARCH_SUSPEND_POSSIBLE=y +CONFIG_ARCH_USE_BUILTIN_BSWAP=y +CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y +CONFIG_ARCH_WANT_GENERAL_HUGETLB=y +CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_ARM=y # CONFIG_ARM_CPU_SUSPEND is not set CONFIG_ARM_L1_CACHE_SHIFT=5 @@ -13,12 +22,19 @@ CONFIG_ARM_NR_BANKS=8 CONFIG_ARM_PATCH_PHYS_VIRT=y # CONFIG_ARM_THUMB is not set -# CONFIG_ARPD is not set +CONFIG_ATAGS=y CONFIG_AUTO_ZRELADDR=y +CONFIG_AVERAGE=y +CONFIG_BLK_DEV_SD=m # CONFIG_CACHE_L2X0 is not set +CONFIG_CHR_DEV_SG=m +CONFIG_CLKDEV_LOOKUP=y CONFIG_CLKSRC_MMIO=y +CONFIG_CLONE_BACKWARDS=y CONFIG_CMDLINE="rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200" CONFIG_CMDLINE_FORCE=y +CONFIG_COMMON_CLK=y +CONFIG_COREDUMP=y CONFIG_CPU_32v5=y CONFIG_CPU_ABRT_EV5T=y CONFIG_CPU_CACHE_VIVT=y @@ -31,29 +47,52 @@ CONFIG_CPU_PABRT_LEGACY=y CONFIG_CPU_TLB_FEROCEON=y CONFIG_CPU_USE_DOMAINS=y -CONFIG_CRYPTO_AES=y -CONFIG_CRYPTO_ALGAPI=y -CONFIG_CRYPTO_ALGAPI2=y +CONFIG_CRC16=m +CONFIG_CRYPTO_AEAD=m +CONFIG_CRYPTO_AEAD2=m +CONFIG_CRYPTO_ARC4=m +CONFIG_CRYPTO_BLKCIPHER=m CONFIG_CRYPTO_BLKCIPHER2=y +CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_DEV_MV_CESA=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_HW=y +CONFIG_CRYPTO_MANAGER=m +CONFIG_CRYPTO_MANAGER2=y CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_WORKQUEUE=y +CONFIG_DEBUG_LL_INCLUDE="debug/8250.S" +CONFIG_DEBUG_UART_8250=y +# CONFIG_DEBUG_UART_8250_FLOW_CONTROL is not set +CONFIG_DEBUG_UART_8250_SHIFT=2 +# CONFIG_DEBUG_UART_8250_WORD is not set +CONFIG_DEBUG_UART_PHYS=0xf1012000 +# CONFIG_DEBUG_UART_PL01X is not set +CONFIG_DEBUG_UART_VIRT=0xfe012000 # CONFIG_DEBUG_USER is not set -CONFIG_DECOMPRESS_LZMA=y CONFIG_DNOTIFY=y +CONFIG_ELF_CORE=y +CONFIG_EXPORTFS=m +CONFIG_EXT4_FS=m CONFIG_FRAME_POINTER=y +CONFIG_FS_MBCACHE=m CONFIG_GENERIC_ATOMIC64=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y -CONFIG_GENERIC_GPIO=y +CONFIG_GENERIC_IDLE_POLL_SETUP=y +CONFIG_GENERIC_IO=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_GENERIC_IRQ_SHOW=y +CONFIG_GENERIC_NET_UTILS=y CONFIG_GENERIC_PCI_IOMAP=y +CONFIG_GENERIC_SCHED_CLOCK=y +CONFIG_GENERIC_SMP_IDLE_THREAD=y +CONFIG_GENERIC_STRNCPY_FROM_USER=y +CONFIG_GENERIC_STRNLEN_USER=y CONFIG_GPIOLIB=y +CONFIG_GPIO_DEVRES=y CONFIG_GPIO_SYSFS=y # CONFIG_HAMRADIO is not set CONFIG_HARDIRQS_SW_RESEND=y @@ -60,43 +99,84 @@ CONFIG_HAS_DMA=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y -CONFIG_HAVE_AOUT=y +# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set +CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_HAVE_ARCH_KGDB=y CONFIG_HAVE_ARCH_PFN_VALID=y +CONFIG_HAVE_ARCH_SECCOMP_FILTER=y +CONFIG_HAVE_ARCH_TRACEHOOK=y +# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set +CONFIG_HAVE_BPF_JIT=y +CONFIG_HAVE_CC_STACKPROTECTOR=y +CONFIG_HAVE_CLK=y +CONFIG_HAVE_CLK_PREPARE=y +CONFIG_HAVE_CONTEXT_TRACKING=y CONFIG_HAVE_C_RECORDMCOUNT=y +CONFIG_HAVE_DEBUG_KMEMLEAK=y CONFIG_HAVE_DMA_API_DEBUG=y +CONFIG_HAVE_DMA_ATTRS=y +CONFIG_HAVE_DMA_CONTIGUOUS=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_GENERIC_DMA_COHERENT=y -CONFIG_HAVE_GENERIC_H
Re: [OpenWrt-Devel] [PATCH] lantiq xway: generate ramdisk image by default
No problem. I'll try to make sure there is a link to a non-official ramdisk image on the wiki. (Along with some installation instructions, which at the moment are lacking!) Ben On Sun, 2014-07-20 at 08:54 +0200, John Crispin wrote: > technically correct. however there is a dependency bug left over from > some cargo cult cleanups. this causes the image builder to not build > when ramdisk is enabled. i plan to clean this up post BB. i will > ignore this patch until said time. > > John > > On 19/07/2014 15:13, Ben Mulvihill wrote: > > The installation process on nand-based boards using ubi like the > > BTHOMEHUBV2B makes use of a ramdisk image, so it makes sense to > > generate this by default. > > > > Signed-off-by: Ben Mulvihill --- --- > > a/target/linux/lantiq/xway/target.mk2014-07-19 14:59:39.691201637 > > +0200 +++ b/target/linux/lantiq/xway/target.mk 2014-07-19 > > 12:40:06.101871732 +0200 @@ -1,7 +1,7 @@ ARCH:=mips SUBTARGET:=xway > > BOARDNAME:=XWAY -FEATURES:=squashfs atm mips16 nand ubifs > > +FEATURES:=squashfs atm mips16 nand ubifs ramdisk CPU_TYPE:=34kc > > CPU_SUBTYPE:=dsp > > > > ___ openwrt-devel > > mailing list openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [patch] [package] ca-certificates: create symbolic link for certificate hashes
On 2014-07-19 12:16, Christian Schoenebeck wrote: > From: Christian Schoenebeck > Date: Sat, 19 Jul 2014 11:14:01 +0200 > Subject: ca-certificates: create symbolic link for certificate hashes > > Implementing "add-cert.sh" functionality discribed at > http://wiki.openwrt.org/doc/howto/wget-ssl-certs into Makefile > otherwise you need to create symbolic links for certificate hashes yourself. > > Signed-off-by: Christian Schoenebeck > --- > package/system/ca-certificates/Makefile | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/package/system/ca-certificates/Makefile > b/package/system/ca-certificates/Makefile > index 7f38c86..534c38b 100644 > --- a/package/system/ca-certificates/Makefile > +++ b/package/system/ca-certificates/Makefile > @@ -34,6 +34,19 @@ endef > define Package/ca-certificates/install > $(INSTALL_DIR) $(1)/etc/ssl/certs > $(INSTALL_DATA) $(PKG_INSTALL_DIR)/usr/share/ca-certificates/*/*.crt > $(1)/etc/ssl/certs/ > + > + OPENSSL=/usr/bin/openssl ; \ > + CERTDIR=$(1)/etc/ssl/certs ; \ The use of shell variables here is unnecessary. make variables are more convenient because you don't need . Also, please don't hardcode the openssl path. OpenWrt build prereq checks already test if OpenSSL is installed, so you can safely assume that it is available. Just call 'openssl' without specifying a path. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
