In most cases it allows reverting back to the vendor firmware (as they
usually don't use UBI). If users wants to do that we can't do anything
anyway. Erease counters will be just lost. The only thing we do is warn:
"Flashing firmware without UBI for rootfs. All erase counters will be
lost."
It still requires forcing sysupgrade.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 45392
We can now detect that provided firmware contains kernel and UBI image
partitions. Flashing it in a sane way (keeping erase counters) still
needs to be implemented.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 45391
With previous version of patch info about need of erasing blocks was
stored once per boot. It was breaking in following scenario:
1) First boot after installation (erasing blocks after 0xdeadc0de)
2) Doing sysupgrade (with ubidetach & ubiformat)
3) Attaching UBI again (it caused all blocks to be erased)
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 45387
It currently does not seem to make a difference anymore, except by
increasing compressed kernel image size
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45385
Two errors "netifd: radio0: sh: bad number" have recently surfaced in system
log in trunk when wifi interfaces come up. I tracked the errors to checking
numerical values of some config options without ensuring that the option has
any value.
The errors I see have apparently been introduced by r45051 (ieee80211r in
hostapd) and r45326 (start_disabled in mac80211). My patches fix two
instances of "bad number", but there may be a third one, as the original
report in bug 19345 pre-dates r45326 and already has two "bad number" errors
for radio0.
https://dev.openwrt.org/ticket/19345
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
SVN-Revision: 45380
Two errors "netifd: radio0: sh: bad number" have recently surfaced in system
log in trunk when wifi interfaces come up. I tracked the errors to checking
numerical values of some config options without ensuring that the option has
any value.
The errors I see have apparently been introduced by r45051 (ieee80211r in
hostapd) and r45326 (start_disabled in mac80211). My patches fix two
instances of "bad number", but there may be a third one, as the original
report in bug 19345 pre-dates r45326 and already has two "bad number" errors
for radio0.
https://dev.openwrt.org/ticket/19345
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
SVN-Revision: 45379
Fixes build failure caught by buildbot:
IEEE Std 802.15.4 Low-Rate Wireless Personal Area Networks support (IEEE802154) [M/n/y/?] m
6lowpan support over IEEE 802.15.4 (IEEE802154_6LOWPAN) [N/m/?] (NEW) aborted!
Console input/output is redirected. Run 'make oldconfig' to update configuration.
make[6]: *** [silentoldconfig] Error 1
make[5]: *** [silentoldconfig] Error 2
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
SVN-Revision: 45357
* properly enclose macro arguments in paranthesis on use
* remove trailing white space
* convert C99 // comments
* add missing blank lines after declaration
* remove braces from single statement blocks
* split lines > 80 chars (except for one)
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
SVN-Revision: 45356
r45270 removed ieee80211n=%d from the format string but didn't remove
the parameter itself. Though this probably doesn't cause any harm, it's
quite confusing and unneeded.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
SVN-Revision: 45351
it causes problems with newer iptables when ipv6 is disabled as iptc uncoditionally links ip6tc
Signed-off-by: John Crispin <blogic@openwrt.org>
SVN-Revision: 45350
This patch adds the wpan-tools (iwpan) utility to OpenWRT
build system. This utility required to manage IEE-802.15.4
devices.
Signed-off-by: Varka Bhadram <varkab@cdac.in>
SVN-Revision: 45349
