There are problems with the patches for kernel 2.6.39 and I do not want to support two different sets of patches.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@29573 3c298f89-4303-0410-b956-a3cf2f4a3e73
Hi,
this patch adds the correct vlan definitions for the Siemens SE505v2. It
applies to trunk as well as backfire (please apply here too). On
backfire this also patches brcm-2,4, because brcm47xx base-files is just
symlinked to brcm-2.4.
It also fixes two whitespace issues.
Tested with brcm47xx on both trunk and backfire branch and works as
expected.
Signed-off-by: Manuel Munz <freifunk@somakoma.de>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@28336 3c298f89-4303-0410-b956-a3cf2f4a3e73
As this target changes often these days it is hard to support more kernel versions. Now only kernel 3.0 is supported.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@27906 3c298f89-4303-0410-b956-a3cf2f4a3e73
* this adds sflash support for ssb devices
* the flash is now a platform device
* minor updates
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@27902 3c298f89-4303-0410-b956-a3cf2f4a3e73
ssb_pcicore_fix_sprom_core_index accesses the sprom on the pci bus but
this causes a data bus error (oops) on a SoC.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@27758 3c298f89-4303-0410-b956-a3cf2f4a3e73
Now we can assume that every brcm47xx kernel has the bcma module build
into the kernel. This is not needed for this version as this does not
support bcma as system bus but kernel 3.0 will.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@27733 3c298f89-4303-0410-b956-a3cf2f4a3e73
* add new patches for bcm4716 SoC
* add support for serial flash on bcma bus
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@27723 3c298f89-4303-0410-b956-a3cf2f4a3e73
The image will not boot because serial flash support is missing this is only for experts.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@27302 3c298f89-4303-0410-b956-a3cf2f4a3e73
Ethernet and wifi are not working and this is highly experimental.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@27301 3c298f89-4303-0410-b956-a3cf2f4a3e73
2.4 isn't present anymore, so it will always be 2.6 (or newer). Since the
2.6 check will break with 3.0, remove it alltogether.
Signed-off-by: Jonas Gorski <jonas.gorski+openwrt@gmail.com>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@27185 3c298f89-4303-0410-b956-a3cf2f4a3e73
The flash driver code should be cleaned up and the broad detection code should be placed into arch code and used here.
This fixes#9323
Thank you Will Holmes for the patch.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@27005 3c298f89-4303-0410-b956-a3cf2f4a3e73
If there is no sprom on an ssb based pci device on the brcm47xx
architecture ssb now asks the architecture code to look into the nvram
to get some sprom data for this device. Now we are able to read out
pci/1/1/ foo or pci/1/3/ foo config options.
This will fix some problems where the wireless devices does not got an
mac address and the following message was show:
ssb: WARNING: Invalid SPROM CRC (corrupt SPROM)
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@26801 3c298f89-4303-0410-b956-a3cf2f4a3e73
This package creates some error messages on startup
Thank you russell-- for reporting
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@26240 3c298f89-4303-0410-b956-a3cf2f4a3e73
The Netgear wgt634u uses minus between the hex digest of the mac
address and all other broadcom devices are using colons between the hex
digest. Now the mac address is correctly parsed also when minus is used.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@24749 3c298f89-4303-0410-b956-a3cf2f4a3e73
This fixes a problem with wrt350n.
It boots only if this config option is set, otherwise it reboots after "Switching to clocksource MIPS"
Thank you sn9 for fixing this problem.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@24626 3c298f89-4303-0410-b956-a3cf2f4a3e73
Broadcom removed these pci id, but at least the wrt350n has a Ethernet
controller with a pci id of 14e4:1676
Thank you sn9 for fixing this problem.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@24625 3c298f89-4303-0410-b956-a3cf2f4a3e73
Backport patches from r24162
brcm47xx: reorder patches like they were commitet upstream
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@24266 3c298f89-4303-0410-b956-a3cf2f4a3e73
0x4243) functionality. Revert that patch until we get a proper fix.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@24096 3c298f89-4303-0410-b956-a3cf2f4a3e73
Readd the workarround from the old version again which was removed in r22296 and refresh the patches.
This should close#7874
Thank you Russell Senior for testing.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@23911 3c298f89-4303-0410-b956-a3cf2f4a3e73
Reading the CFE properties causes system hangs on some devices. With
this patch nvram read will be successful very time so cfe will no be
read out. This code is not really correct but it will work around some
problems for some people.
Related ticket: #7693
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@22663 3c298f89-4303-0410-b956-a3cf2f4a3e73
Thank you realopty for the patch.
tools/firmware-utils/src/mkchkimg.c is from http://www.myopenrouter.com/download/10611/mkchkimg/
This closes#7702.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@22516 3c298f89-4303-0410-b956-a3cf2f4a3e73
space is used to store config values. When overwriting it the device
will not start any more.
closes#7630
Thank you realopty for testing.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@22475 3c298f89-4303-0410-b956-a3cf2f4a3e73
* fix return codes of nvram_getenv. Now it behaves like cfe_getenv.
* also check cfe for kernel_args param.
* some style fixes
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@22424 3c298f89-4303-0410-b956-a3cf2f4a3e73
CFE does not boot images generated with these checksums because of
wrong checksum.
After flashing then with tftp to my Asus wl500-GPv1 the following messages
are show:
Null Rescue Flag.
Boot program checksum is invalid
Hello!! Enter Rescue Mode: (Check error)
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@22418 3c298f89-4303-0410-b956-a3cf2f4a3e73
* reduce image size for CRC calculation by fs_mark size
sysupgrade sometimes failed for me and I noticed that it was due
to incorrect CRC values in trx-header after performing it.
It seems that the fs_mark was completely included in the calculation
and that it was nevertheless modified by sysupgrade while appending
the jffs data.
This only occurs for the first boot after sysupgrade as the flashmap
driver recalculates the CRC to an even smaller area when it boots.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@22396 3c298f89-4303-0410-b956-a3cf2f4a3e73
