summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorRafał Miłecki <rafal@milecki.pl>2016-10-24 17:03:48 +0200
committerRafał Miłecki <rafal@milecki.pl>2016-10-24 17:22:23 +0200
commit06405df7a8da24b7d735b32454c7d3b1f2ebaabc (patch)
tree18c6e1d13fa94f49713269317e0a7febfd4867b3 /include
parent6e64a38b0099d50d3ec98a3ab04a2a2cd19500e4 (diff)
downloadmtk-20170518-06405df7a8da24b7d735b32454c7d3b1f2ebaabc.zip
mtk-20170518-06405df7a8da24b7d735b32454c7d3b1f2ebaabc.tar.gz
mtk-20170518-06405df7a8da24b7d735b32454c7d3b1f2ebaabc.tar.bz2
brcm47xx: bump kernel to 4.4
Kernel 4.4 was ready for brcm47xx for almost a year now but I kept postponing the bump due to problems with Linksys WRT300N v1.0. OpenWrt and LEDE with 4.4 were hanging at the booting with the: > Starting program at 0x80001000 (the last CFE message). This was a permanent state, "make distclean" wasn't helping, I spent hours debugging this and I was reliably reproducing the issue every time. I also reported it on linux-mips ML in the thread: > BCM4704 stopped booting with 4.4 (due to vmlinux size?) After ~month I started working on WRT300N again. I got hangs as expected every time I switched from 4.1 to 4.4. I started experimenting with: 1) TRX content (I tried dropping rootfs partition) 2) BZ_TEXT_START of lzma-loader 3) Flashing other variants of image: lzma compressed kernel (without a loader), gzip compressed one, uncompressed one. At some point I got rootfs-less image booting and after that I couldn't reproduce problem anymore, even with a complete firmware. It seems like hardware was in some locked/unstable state that got magically fixed. I have LEDE working now, tested it even with "make distclean", it seems we can bump kernel now. I'll keep testing it on WRT300N for some time. Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions