Signed-off-by: Daniel Golle
---
package/kernel/linux/modules/block.mk | 16
target/linux/oxnas/Makefile | 4 ++--
target/linux/oxnas/config-3.14| 2 --
target/linux/oxnas/config-3.18| 2 --
4 files changed, 18 insertions(+), 6 deletions(-)
diff --git
never really sure how to best report sudden build errors like this
-- just ask on the devel list, submit a bug report, what?
building for ar71xx:
$ make V=s IGNORE_ERRORS=m
... snip ...
Set the kernel architecture to mips
configure: error: The lib_ifxos include directory is not valid!
Make
Hi,
Please remove me from spam list. Maybe I send similar mail to offen...
Thank you.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
On 12/12/2014 11:26, yangbo wrote:
> Hi, Please remove me from spam list. Maybe I send similar mail to
> offen... Thank you. ___
> openwrt-devel mailing list openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-
Quoting "Robert P. J. Day":
building for ar71xx:
...
make[2]: *** [package/kernel/lantiq/ltq-tapi/compile] Error 2
...
this build worked fine yesterday, pulled to update to current trunk
and now the above.
You are probably including asterisk in your build, right?
The reason is a change in ast
Y1S has 2 Gigabit LAN.
So I used the following:
y1 |\
y1s)
ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2"
ucidef_add_switch "switch0" "1" "1"
ucidef_add_switch_vlan "switch0" "1" "0 1 2 3 5 6t 7"
ucidef_add_switch_vlan
Quoting Hannu Nyman :
Quoting "Robert P. J. Day":
building for ar71xx:
...
make[2]: *** [package/kernel/lantiq/ltq-tapi/compile] Error 2
...
this build worked fine yesterday, pulled to update to current trunk
and now the above.
You are probably including asterisk in your build, right?
The r
On 2014-12-12 05:16, Yousong Zhou wrote:
> On 12 December 2014 at 00:42, Felix Fietkau wrote:
>> On 2014-11-11 11:34, Yousong Zhou wrote:
>>> ustream_ssl_check_conn() may be called by .notify_write while a previous
>>> SSL_connect() is still in process. This can happen because the
>>> .notify_wri
Michael Heimpold wrote:
Remove 'series' as all other targets do not use this, too. It
should be obviously clear, that this target refer to a
whole CPU family.
Signed-off-by: Michael Heimpold
---
Hi Michael,
Applied most of the series in r43646-43651, r43657, I've put an SOB
where I could
On 12/12/2014 14:46, Zoltan HERPAI wrote:
> Michael Heimpold wrote:
>> Remove 'series' as all other targets do not use this, too. It
>> should be obviously clear, that this target refer to a
>> whole CPU family.
>>
>> Signed-off-by: Michael Heimpold
>> ---
>>
>>
> Hi Michael,
>
> Applied mos
Signed-off-by: Daniel Golle
---
package/kernel/linux/modules/block.mk | 16
target/linux/oxnas/Makefile | 5 +++--
target/linux/oxnas/config-3.14| 2 --
target/linux/oxnas/config-3.18| 2 --
4 files changed, 19 insertions(+), 6 deletions(-)
diff --gi
On 12 December 2014 at 19:36, Felix Fietkau wrote:
> On 2014-12-12 05:16, Yousong Zhou wrote:
>> On 12 December 2014 at 00:42, Felix Fietkau wrote:
>>> On 2014-11-11 11:34, Yousong Zhou wrote:
ustream_ssl_check_conn() may be called by .notify_write while a previous
SSL_connect() is stil
On Thu, Dec 11, 2014 at 12:51 AM, Álvaro Fernández Rojas
wrote:
> Signed-off-by: Álvaro Fernández Rojas
> ---
> diff --git a/target/linux/brcm63xx/config-3.14
> b/target/linux/brcm63xx/config-3.14
> index dd27f47..f94c567 100644
> --- a/target/linux/brcm63xx/config-3.14
> +++ b/target/linux/brcm
On 12/12/2014 15:12, Jonas Gorski wrote:
> or the gpio-base problem, we should be able to register appropriate
> platform data for it as OF_DEV_AUXDATA() in of_platform_populate.
>
> e.g.
>
> struct bgpio_pdata gpio0_pdata = {
> .base = 0,
> };
>
> struct bgpio_pdata gpio1_pdata = {
>
On Thu, Dec 11, 2014 at 12:52 AM, Álvaro Fernández Rojas
wrote:
> Signed-off-by: Álvaro Fernández Rojas
> ---
> diff --git a/target/linux/brcm63xx/patches-3.14/375-GPIO-DT-over-legacy.patch
> b/target/linux/brcm63xx/patches-3.14/375-GPIO-DT-over-legacy.patch
> new file mode 100644
> index 00
On Fri, Dec 12, 2014 at 3:17 PM, John Crispin wrote:
>
>
> On 12/12/2014 15:12, Jonas Gorski wrote:
>> or the gpio-base problem, we should be able to register appropriate
>> platform data for it as OF_DEV_AUXDATA() in of_platform_populate.
>>
>> e.g.
>>
>> struct bgpio_pdata gpio0_pdata = {
>>
On 12/12/2014 15:33, Jonas Gorski wrote:
> On Fri, Dec 12, 2014 at 3:17 PM, John Crispin wrote:
>>
>>
>> On 12/12/2014 15:12, Jonas Gorski wrote:
>>> or the gpio-base problem, we should be able to register appropriate
>>> platform data for it as OF_DEV_AUXDATA() in of_platform_populate.
>>>
>>>
Hi Luis,
i just added a fix to my local tree and will push during the evening.
it fixes the duplicate uartf pinmux problem. please note that when
enabling uart the uartlite used for tty0 gets moved to tty1 so you need
to fix up the cmdline
John
On 02/12/2014 01:50, Luis Soltero wrote:
>
This patch adds soc support for QCA9561 and TP9343.
TP9343 is a reduced version of QCA9561, which can be found in TP-LINK routers
in China.
The qca956x_wmac has not yet been supported by ath9k.
tested on TL-WDR6500 and TL-WR882N v1 (Chinese version)
Signed-off-by: Weijie Gao
---
target/linux/a
The mvebu image Makefile directly calls the padjffs2 utility, while there's an
generic make function to do just that. Switch to it
Signed-off-by: Maxime Ripard
---
target/linux/mvebu/image/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/mvebu/image/Makef
On boards with large page size, the rootfs we generate might end up using less
PEB than the minimum number required by UBI for a dynamic volume.
Change the rootfs to a static volume, which removes such a requirement, and
isn't changing anything, since our rootfs is in read only anyway.
Signed-off
Create a generic board relying on the board mechanism we just introduced.
So far, the behaviour hasn't really changed, the same boards are supported,
with the same options.
Signed-off-by: Maxime Ripard
---
target/linux/mvebu/boards/generic.mk | 18 ++
target/linux/mvebu/image/Ma
Even though we always build all the board images for a given target, some
options widely differ from one board to another when it comes to hardware
configuration.
Such an option for example is the NAND setup, which depends on the NAND chip
itself, that obviously varies from one board to another.
Hi,
This is another attempt at supporting different NAND page options at the same
time, for the same profile, especially on the mvebu platform with the
Globalscale Mirabox.
This is an alternate solution than the previous approach using profiles that
raised some criticism:
https://lists.openwrt.or
The Mirabox has different NAND options than the one used in the generic board,
mostly because of its 512k page size.
Add a new board for it.
Signed-off-by: Maxime Ripard
---
target/linux/mvebu/boards/generic.mk | 1 -
target/linux/mvebu/boards/mirabox.mk | 13 +
2 files changed, 13
This adds a LED trigger for each SATA port if the kernel config option
CONFIG_ATA_LEDS is set.
In order not to cause any oldconfig confusion on targets, the option depends
on CONFIG_ARCH_WANTS_LIBATA_LEDS, so target maintainers have to opt-in in
order to use this (it could e.g. be useful on kirkwoo
Signed-off-by: Daniel Golle
---
target/linux/oxnas/config-3.14| 1 +
target/linux/oxnas/config-3.18| 1 +
target/linux/oxnas/files/arch/arm/boot/dts/ox820-kd20.dts | 2 ++
target/linux/oxnas/files/arch/arm/mach-oxnas/Kconfig | 1 +
4 fi
... and i assume this is already en-route to upstream ?
On 12/12/2014 17:07, Daniel Golle wrote:
> This adds a LED trigger for each SATA port if the kernel config
> option CONFIG_ATA_LEDS is set. In order not to cause any oldconfig
> confusion on targets, the option depends on
> CONFIG_A
On 2014-12-05 15:36, Cristian Morales Vega wrote:
> Avoids flooding the network with multicast data.
>
> Signed-off-by: Cristian Morales Vega
> ---
> Since I guess not all the switches support this... Good idea? Is some OpenWRT
> package expecting to receive the multicast packages?
> At the very
On 12/12/2014 17:07, Daniel Golle wrote:
> ++#ifdef CONFIG_ATA_LEDS
> ++ap->ledtrig = kzalloc(sizeof(struct led_trigger), GFP_KERNEL);
> ++#endif
can you change all of these to the new IS_ENABLED() api
John
___
openwrt-devel mailing list
On 2014-12-11 20:29, Jonathan Thibault wrote:
> This is quite useful when you want to encapsulate l2 into a vpn and
> other things of that nature.
>
> I've called the package containing the 'bridge' command bridge2 (from
> iproute2) to avoid conflicting with old package 'bridge' which should
> rea
On 2014-12-09 11:47, John Szakmeister wrote:
> This fixes an issue where the toolchain/prepare step could run, but some
> of the necessary host tools might be missing.
>
> Signed-off-by: John Szakmeister
> ---
> This is a resend of a patch I sent earlier
> (https://lists.openwrt.org/pipermail/ope
On 2014-12-11 23:36, Dan Staples wrote:
> Currently, the only way for cgi scripts to determine if the request
> was made over SSL seems to be to check if the SERVER_PORT environment
> variable is set to 443, which is less than ideal. This sets the HTTPS
> environment variable, like the first versio
Switch to a dumber implementation that will be easier to maintain in the long
run, with only if statements instead of having nested subst calls.
Signed-off-by: Maxime Ripard
---
include/kernel.mk | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/include/kernel.
x64 is handled by the x86 architecture in Linux, add a case for it in
LINUX_KARCH.
Signed-off-by: Maxime Ripard
---
include/kernel.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/kernel.mk b/include/kernel.mk
index b905cb9e1936..eeb0c3d2bd8e 100644
--- a/include/ke
Hi,
This is the fourth attempt at using the defconfig mechanism for the
kernel configuration instead of having full fledged configuration
written by hand, and very tedious to maintain.
Changes from v3:
- Simplify a bit the LINUX_KARCH logic in order to use findstring
instead of a long list
Rely on the Kconfig defconfig mechanism to fill all the missing options,
instead of needing to set them all in the kernel configurations like what was
previously done.
This will allow to trim down a lot the configuration files, avoid carrying
unused configuration options and preserve the developer
This adds a LED trigger for each SATA port if the kernel config option
CONFIG_ATA_LEDS is set.
In order not to cause any oldconfig confusion on targets, the option depends
on CONFIG_ARCH_WANTS_LIBATA_LEDS, so target maintainers have to opt-in in
order to use this (it could e.g. be useful on kirkwoo
On Fri, Dec 12, 2014 at 5:02 PM, Maxime Ripard
wrote:
> Now that we use the defconfigs, we can remove all the options at their default
> value.
This causes a lot of kernel-config changes for e.g bcm63xx_smp with
3.18, several of which are unwanted (e.g. enabling of the FPU
emulator).
How did you
On 2014-12-12 17:02, Maxime Ripard wrote:
> x64 is handled by the x86 architecture in Linux, add a case for it in
> LINUX_KARCH.
>
> Signed-off-by: Maxime Ripard
Applied the first two patches in this series.
- Felix
___
openwrt-devel mailing list
openw
On Fri, Dec 12, 2014 at 04:21:02PM +0100, Maxime Ripard wrote:
> On boards with large page size, the rootfs we generate might end up using less
> PEB than the minimum number required by UBI for a dynamic volume.
>
> Change the rootfs to a static volume, which removes such a requirement, and
> isn'
cosmetics. clean a style issue introduced by r43674.
Signed-off-by: Daniel Golle
---
target/linux/generic/patches-3.14/834-ledtrig-libata.patch | 2 +-
target/linux/generic/patches-3.18/834-ledtrig-libata.patch | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/linux/g
Hi Zoltan,
Applied most of the series in r43646-43651, r43657, I've put an SOB
where I could test the patch. The whitespace fix doesn't apply
cleanly - would you mind to re-send that please.
no problem, will rebase and resend.
Thanks,
mhei
___
op
Align this file with the style of most other modules.mk.
Signed-off-by: Michael Heimpold
---
This is a rebased version because previous patch do no apply cleanly
anymore. While at, adjust the wording a little bit.
BR, mhei
target/linux/mxs/modules.mk | 74 +-
We've been carrying around that patch for a while now and didn't
ever encounter any problem on non-UBI flashtypes. So I guess the
8kB extra space won't hurt on modern platforms which might even make
use of their U-Boot environment being stored in UBI.
Let me know if there are any targets missing i
From: Gergely Kiss
Fix extroot functionality for devices where rootfs is on a ubifs partition
Signed-off-by: Gergely Kiss
Tested-by: Gergely Kiss
---
Originally created by forum user "Hiro.AK47" for the 14.07 branch.
I've created a new diff to make it work with the master branch.
Tested on a
Actually I don't know what port 7 is.
Port 5 is not required for Y1.
2014-12-12 22:20 GMT+08:00 John Crispin :
>
>
>
> On 12/12/2014 12:21, 郭传鈜 wrote:
> > Y1S has 2 Gigabit LAN. So I used the following: y1 |\ y1s)
> > ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2" ucidef_add_switch
> > "switch0"
Works great to power-off the kd20 ;)
Signed-off-by: Daniel Golle
---
target/linux/oxnas/config-3.14| 4
target/linux/oxnas/config-3.18| 4
target/linux/oxnas/files/arch/arm/boot/dts/ox820-kd20.dts | 5 +
3 files changed, 13 in
Good evening,
I've flashed a Netgear WNDR3400 v1 with final official Barrier
Breaker image.
I've discovered that all mac addresses are the same for lan, wan and
wireless, which I find odd.
My search found this patch:
https://dev.openwrt.org/browser/branches/barrier_breaker/target/lin
Aigale Ai-BR100 is a router with mt7620a soc.
There are only 2 lights on the board (WAN and WLAN) so I used the wlan light as
the status led.
Signed-off-by: 郭传鈜
---
target/linux/ramips/base-files/etc/board.d/01_leds | 4 +
.../linux/ramips/base-files/etc/board.d/02_network | 1 +
target/lin
define speed-map and include kmod-hwmon-gpiofan in kd20 profile
Signed-off-by: Daniel Golle
---
target/linux/oxnas/files/arch/arm/boot/dts/ox820-kd20.dts | 2 ++
target/linux/oxnas/profiles/100-Generic.mk| 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/target
Hi, gch
On 13 December 2014 at 10:41, 郭传鈜 wrote:
> Aigale Ai-BR100 is a router with mt7620a soc.
> There are only 2 lights on the board (WAN and WLAN) so I used the wlan light
> as the status led.
>
IIRC, there are 3 LEDs, but one of them is for power supply indication
and cannot be controlled
It moves firmware patch code behind an extra check on board_name.
Otherwise it will calculate firmware checksum for unaffected boards.
It also reduce boottime by a md5 calculation and removes error message
on boot if firmware not found.
---
.../ar71xx/base-files/lib/preinit/82_patch_ath10k| 20
i think this should the opt-in not opt-out. target maintainers should
set it only if they have boards with the env stored inside ubi.
John
On 12/12/2014 23:59, Daniel Golle wrote:
> We've been carrying around that patch for a while now and didn't
> ever encounter any problem on non-UBI fl
Hi,
thanks for the patch, code looks good however
* the patch is whitespace mangled and line broken.
* this will build always build with ubi support even if the target has
no UBI. please add a config option so that is selectable whether ubi is
enabled.
John
On 13/12/2014 00:43, Gergely
Hi lynxis,
ah the stray ath10k fw warning ... thanks, one todo less on my list :)
John
On 13/12/2014 08:19, Alexander Couzens wrote:
> It moves firmware patch code behind an extra check on board_name.
> Otherwise it will calculate firmware checksum for unaffected boards.
> It also reduce
On 13/12/2014 08:04, Yousong Zhou wrote:
>> +define Profile/AIBR100
>> > + NAME:=Aigale Ai-BR100
>> > + PACKAGES:=\
>> > + kmod-usb-core \
>> > + kmod-usb-ohci \
>> > + kmod-ledtrig-usbdev \
>> > + kmod-usb2
>> > +endef
> kmod-le
57 matches
Mail list logo
