Reading from the flash chip on the TL-WR2543ND seems buggy.
If the SPI flash driver tries to read too much data in one
SPI transfer, the flash chip returns bogus values. This can
be caused by a buggy flash chip on my board, or it can
be a bug in our SPI driver.
Add a workaround to the m25p80 driver until I find out the
root cause of the problem. The patch allows to specify the
maximum numner of bytes which can be read safely withint
one SPI transfer.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@29679 3c298f89-4303-0410-b956-a3cf2f4a3e73
The patch taken from the linux-mips mailing list.
The Kernel hangs occasionally during boot after
"Calibrating delay loop..". This is caused by the
c0_compare_int_usable() routine in cevt-r4k.c
returning false which causes the system to disable
the timer and hang later. The false return happens
because the routine is using a series of four calls
to irq_disable_hazard() as a delay while it waits
for the timer changes to propagate to the cp0 cause
register. On newer MIPS cores, like the 74K, the
series of irq_disable_hazard() calls turn into ehb
instructions and can take as little as a few clock
ticks for all 4 instructions. This is not enough of
a delay, so the routine thinks the timer is not
working.
This fix uses up to a max number of cycle counter
ticks for the delay and uses back_to_back_c0_hazard()
instead of irq_disable_hazard() to handle the hazard
condition between cp0 writes and cp0 reads.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@29009 3c298f89-4303-0410-b956-a3cf2f4a3e73
AR8316 behind a GPIO bitbanged MDIO bus fails to drive the turnaround bit
to low despite returning a valid value. Ignore it and just use the
returned value anyway.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@28422 3c298f89-4303-0410-b956-a3cf2f4a3e73
decreases CPU load with the default firewall for routing 95 mbit/s from 78% to 55%
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@27878 3c298f89-4303-0410-b956-a3cf2f4a3e73
