- Apr 13, 2015
-
-
Felix Fietkau authored
Signed-off-by:Felix Fietkau <nbd@openwrt.org> SVN-Revision: 45424
-
Felix Fietkau authored
it has been non-functional for years and caused numerous memleaks and crashes for people that tried to enable it. it has no maintained upstream source, and it does not look like it's going to be fixed any time soon Signed-off-by: -
Felix Fietkau authored
Signed-off-by: -
Imre Kaloz authored
Signed-off-by:Imre Kaloz <kaloz@openwrt.org> SVN-Revision: 45421
-
Felix Fietkau authored
Signed-off-by: -
Felix Fietkau authored
Signed-off-by: -
Felix Fietkau authored
Signed-off-by: -
Felix Fietkau authored
Signed-off-by: -
Felix Fietkau authored
Signed-off-by: -
Imre Kaloz authored
Signed-off-by: -
Imre Kaloz authored
Signed-off-by: -
Imre Kaloz authored
If you can't find the firmware for you board, send proper patches. Signed-off-by: -
Imre Kaloz authored
This has been done without having a board, but should work. Signed-off-by: -
Imre Kaloz authored
Signed-off-by: -
Steven Barth authored
Signed-off-by:Steven Barth <steven@midlink.org> SVN-Revision: 45410
-
Luka Perkov authored
Signed-off-by:Varka Bhadram <varkab@cdac.in> SVN-Revision: 45409
-
- Apr 12, 2015
-
-
Felix Fietkau authored
Signed-off-by: -
Felix Fietkau authored
Signed-off-by: -
Imre Kaloz authored
left "broken" as I'm not sure if my only board is to blame.. testers welcomed Signed-off-by: -
Imre Kaloz authored
Signed-off-by: -
Jo-Philipp Wich authored
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> SVN-Revision: 45404
-
Rafał Miłecki authored
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> SVN-Revision: 45403
-
Rafał Miłecki authored
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:
Jonas Gorski <jogo@openwrt.org> SVN-Revision: 45402
-
Imre Kaloz authored
Signed-off-by: -
Imre Kaloz authored
Signed-off-by: -
Felix Fietkau authored
Signed-off-by: -
Felix Fietkau authored
Signed-off-by: -
John Crispin authored
Signed-off-by:John Crispin <blogic@openwrt.org> SVN-Revision: 45397
-
Imre Kaloz authored
Signed-off-by: -
Imre Kaloz authored
Signed-off-by: -
Imre Kaloz authored
Signed-off-by: -
Imre Kaloz authored
Signed-off-by: -
Rafał Miłecki authored
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 authored
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 authored
Signed-off-by: -
Rafał Miłecki authored
Signed-off-by: -
Felix Fietkau authored
Signed-off-by: -
Rafał Miłecki authored
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: -
Imre Kaloz authored
Signed-off-by:
-
- Apr 11, 2015
-
-
Felix Fietkau authored
It currently does not seem to make a difference anymore, except by increasing compressed kernel image size Signed-off-by:
-
