If you can't find the firmware for you board, send proper patches.
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@45413 3c298f89-4303-0410-b956-a3cf2f4a3e73
This has been done without having a board, but should work.
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@45412 3c298f89-4303-0410-b956-a3cf2f4a3e73
left "broken" as I'm not sure if my only board is to blame.. testers welcomed
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@45406 3c298f89-4303-0410-b956-a3cf2f4a3e73
To prevent future confusion around '/overlay' vs. 'overlay' simply reject
relative path specifications as mount points since such paths result in
undefined behaviour anyway.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@45404 3c298f89-4303-0410-b956-a3cf2f4a3e73
It seems to have few ports connected to CPU (only for CPU sending data?)
as part of "SMP dual core 3 GMAC setup" feature.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@45403 3c298f89-4303-0410-b956-a3cf2f4a3e73
On BCM5301X there are two different cases to handle: CPU port 8 vs. any
other one. Support for CPU port 8 was already partially implemented but
it lacked setting some extra bit for 2G speed. It also will need to be
extended to implement "SMP dual core 3 GMAC setup". That's the reason
for handling it in separated code block.
This patch also adds overriding CPU port state for port other than 8. It
requires using recently defined GMII_PORT registers.
It was tested for regressions on BCM53011 revs 2 & 3. It was also
confirmed to fix switch on some internal Broadcom board.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Acked-by: Jonas Gorski <jogo@openwrt.org>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@45402 3c298f89-4303-0410-b956-a3cf2f4a3e73
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>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@45392 3c298f89-4303-0410-b956-a3cf2f4a3e73
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>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@45391 3c298f89-4303-0410-b956-a3cf2f4a3e73
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>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@45387 3c298f89-4303-0410-b956-a3cf2f4a3e73
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>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@45385 3c298f89-4303-0410-b956-a3cf2f4a3e73
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>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@45380 3c298f89-4303-0410-b956-a3cf2f4a3e73
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>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@45379 3c298f89-4303-0410-b956-a3cf2f4a3e73
Felix Fietkau
Imre Kaloz
Steven Barth
Luka Perkov
Jo-Philipp Wich
Rafał Miłecki
John Crispin