BCM6328 support is in a usable state, with the following issues
* internal switch port not configurable
* external phys not supported
* broadcom wifis will probably not work correctly
* and all other generic bcm63xx issues (so yes, still no ADSL)
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@31883 3c298f89-4303-0410-b956-a3cf2f4a3e73
bcm_enetsw_probe did not properly reset port states, resulting in
connected ports staying disabled after bringing up the interface the
second time.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@31881 3c298f89-4303-0410-b956-a3cf2f4a3e73
Add support for the HSSPI controller found on bcm6328 and SPI attached
flash.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@31879 3c298f89-4303-0410-b956-a3cf2f4a3e73
Prevents CFE from flashing to the second image offset. Fix up the rootfs
length on first boot else CFE will complain.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@31876 3c298f89-4303-0410-b956-a3cf2f4a3e73
Allow images to be padded to a certain size. This prevents CFE from
flashing them to the second image offset.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@31875 3c298f89-4303-0410-b956-a3cf2f4a3e73
No need to keep the bcm63xx/ at the start or the chipid info at the end.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@31871 3c298f89-4303-0410-b956-a3cf2f4a3e73
Support for TP-Link TL-MR3040. Power LED not working - always on red, after
start should be green.
Signed-off-by: Cezary Jackiewicz <cezary.jackiewicz@gmail.com>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@31845 3c298f89-4303-0410-b956-a3cf2f4a3e73
Add byte queue limits support to net/ethernet/ramips_main.c
"Byte queue limits are a mechanism to limit the size of the transmit
hardware queue on a NIC by number of bytes. The goal of these byte
limits is too reduce latency (HOL blocking) caused by excessive
queuing in hardware (aka buffer bloat) without sacrificing
throughput."
Signed-off-by: Tobias Diedrich <ranma+openwrt@tdiedrich.de>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@31844 3c298f89-4303-0410-b956-a3cf2f4a3e73
Sysupgrade works just fine on my Sitecom WL-351 after adding this
oneliner.
Signed-off-by: Tobias Diedrich <ranma+openwrt@tdiedrich.de>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@31843 3c298f89-4303-0410-b956-a3cf2f4a3e73
Should fix#11513. Tested with the x86/generic squashfs image within a VM.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@31841 3c298f89-4303-0410-b956-a3cf2f4a3e73
The option 'force' when set to '1' will transform a dhcp-option to dhcp-option-force instead in the config.
This is useful for forcing options to be sent back to a client (even options it didn't ask for).
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@31816 3c298f89-4303-0410-b956-a3cf2f4a3e73
On my network, I have a variety of machines and appliances, some of which need different configuration issues than the default options.
For example:
config host
option name 'client'
option mac '00:01:02:03:04:05'
option ip '192.168.1.20'
option tag 'acme'
config tag acme
option force '1'
list dhcp_option 'option:router,192.168.1.253'
list dhcp_option 'option:domain-name,acme.com'
list dhcp_option 'option:domain-search,acme.com,redfish-solutions.com'
which allows me to override the default router for my client's host, as well as its domain-name, and its domain-search.
this causes the following config lines:
dhcp-host=00:01:02:03:04:05,set:acme,192.168.1.20,client
dhcp-option-force=tag:acme,option:router,192.168.1.253
dhcp-option-force=tag:acme,option:domain-name,acme.com
dhcp-option-force=tag:acme,option:domain-search:acme.com,redfish-solutions.com
This could be useful elsewhere, for instance, if you have an IP CCTV that you don't want to have a default-route, etc.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@31815 3c298f89-4303-0410-b956-a3cf2f4a3e73
