I agree, it would be much better to do the job without touching CFE. In fact after changing those bits in CFE to boot always the core0 as the main thread, if one wants to return to the OEM firmware it turns out that the board hangs when loading VoIP stuff. Probably VoIP stuff is hardcoded in some way that wants the core0 for exclusive use.
BTW, shouldn't be easier to do the job into the kernel rather than the lzma-loader?. And without worrying which boards are affected, just do it for all BCM6358 boards (if they booted the core1 as the main thread). I can't imagine any user wanting to run Openwrt with half icache. Regards. 2016-01-18 14:15 GMT+01:00 Jonas Gorski <[email protected]>: > Hi, > > On Wed, Dec 2, 2015 at 9:37 PM, dani <[email protected]> wrote: > > In the HG556a router the partition mtd0, where CFE lives, is read only. > > This patch allows this partition to be writeable. > > > > The BCM6358 SoC has two cores, but they are not identical. The second > core has > > half icache. > > core0: icache=32kB > > core1: icache=16kB > > > > As default the HG556a uses the second core as the main one (configured > by CFE). > > Since currently there isn't SMP support for using both cores, we want to > use the > > one with the best performance. > > > > For using the core0 as the main one, we need to write some bytes at the > offset > > 0x014 of mtd0 (CFE). Therefore we need the mtd0 partition to be > writeable. > > > > After setting the core0 as the main one, the performance can increase up > to > > +20% (tested). The performance gain isn't marginal. > > > > For setting the core0 as the main one in an easy way I wrote a very > simple utility: > > https://wiki.openwrt.org/_media/media/huawei/tp0set.tar.gz > > It can switch from core0 to core1 or vice versa in OpenWrt writing > proper bytes > > into bcm6358 CFE (fully tested in the HG556a, no bricks). > > To be honest, I'm not very comfortable with making the CFE partition > writable, and rather add code to lzma-loader that switches back to > thread 0, then add lzma-loader for the affected devices. > > > Jonas >
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
