Re: [OpenWrt-Devel] [RFC] Lantiq subtargets based in SoC.
As Felix and John said, probably the best choice will be leave the Lantiq subtargets with the current structure. Additionally could be a good idea tuning the XWAY subtarget to 34kc and enable dsp extensions to achieve better performance in the Danube, AR9 and VR9 boards. This diff is an example of how it could be done: Index: trunk/target/linux/lantiq/svip_be/target.mk === --- trunk/target/linux/lantiq/svip_be/target.mk (revisión: 36545) +++ trunk/target/linux/lantiq/svip_be/target.mk (copia de trabajo) @@ -3,6 +3,7 @@ BOARDNAME:=SVIP Big Endian FEATURES:=squashfs jffs2 DEVICE_TYPE:=other +CFLAGS=-mtune=mips32r2 DEFAULT_PACKAGES+= uboot-svip hostapd-mini Index: trunk/target/linux/lantiq/xway/target.mk === --- trunk/target/linux/lantiq/xway/target.mk(revisión: 36545) +++ trunk/target/linux/lantiq/xway/target.mk(copia de trabajo) @@ -2,6 +2,7 @@ SUBTARGET:=xway BOARDNAME:=XWAY FEATURES:=squashfs jffs2 atm +CFLAGS=-mtune=34kc -mdsp DEFAULT_PACKAGES+=kmod-leds-gpio kmod-gpio-button-hotplug Index: trunk/target/linux/lantiq/svip_le/target.mk === --- trunk/target/linux/lantiq/svip_le/target.mk (revisión: 36545) +++ trunk/target/linux/lantiq/svip_le/target.mk (copia de trabajo) @@ -3,6 +3,7 @@ BOARDNAME:=SVIP Little Endian FEATURES:=squashfs jffs2 DEVICE_TYPE:=other +CFLAGS=-mtune=mips32r2 DEFAULT_PACKAGES+= uboot-svip hostapd-mini Index: trunk/target/linux/lantiq/falcon/target.mk === --- trunk/target/linux/lantiq/falcon/target.mk (revisión: 36545) +++ trunk/target/linux/lantiq/falcon/target.mk (copia de trabajo) @@ -3,6 +3,7 @@ BOARDNAME:=Falcon FEATURES:=squashfs jffs2 DEVICE_TYPE:=other +CFLAGS=-mtune=mips32r2 DEFAULT_PACKAGES+= kmod-ifxos gpon-base-files kmod-leds-gpio kmod-ledtrig-heartbeat \ kmod-gpon-optic-drv gpon-optic-drv kmod-gpon-onu-drv gpon-onu-drv \ Index: trunk/target/linux/lantiq/ase/target.mk === --- trunk/target/linux/lantiq/ase/target.mk (revisión: 36545) +++ trunk/target/linux/lantiq/ase/target.mk (copia de trabajo) @@ -2,6 +2,7 @@ SUBTARGET:=ase BOARDNAME:=Amazon-SE FEATURES:=squashfs jffs2 atm +CFLAGS=-mtune=mips32r2 DEFAULT_PACKAGES+=kmod-pppoa ppp-mod-pppoa linux-atm atm-tools br2684ctl kmod-ltq-dsl-ase ltq-dsl-app Index: trunk/target/linux/lantiq/Makefile === --- trunk/target/linux/lantiq/Makefile (revisión: 36545) +++ trunk/target/linux/lantiq/Makefile (copia de trabajo) @@ -13,7 +13,7 @@ LINUX_VERSION:=3.8.11 -CFLAGS=-Os -pipe -mips32r2 -mtune=mips32r2 -fno-caller-saves -mno-branch-likely +CFLAGS=-Os -pipe -mips32r2 -fno-caller-saves -mno-branch-likely define Target/Description Build firmware images for Lantiq SoC More aggressive optimizations, like -mt, must be selected by the user. Finally, i've tested a Danube board with -mtune=34kc and strangely there is no difference than selecting -mtune=24kec José Vázquez ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] Lantiq subtargets based in SoC.
As have been done preciously in the ramips target the Lantiq target could be divided in subtargets based in the SoC (ase, danube, svip, ar9, vr9, ...) or the mips core (4k, 24k, 34k, ...), but the second option might be very confusing. The benefits will be the same as in ramips: better organization based in SoC instead of board, and the specific optimizations for each mips core might be easily managed, like dsp extensions, multithreading and some others. The idea is split the subtargets in this way: - XWAY Danube. - XWAY AR9. - XWAY VR9. - ASE or XWAY ASE. - Falcon. - SVIP-le. - SVIP-be. For more information: - http://www.mips.com/media/files/white-papers/24ke.pdf - http://www.mips.com/media/files/MIPS32_34K_US.PDF - http://electronicsandbooks.com/eab1/manual/Electronic%20Component% 20Databook%20Datasheet/Brand/MIPS/MD00445-2B-24KEC-DTS-01.02% 20c20051220%20%5B61%5D.pdf - http://gcc.gnu.org/onlinedocs/gcc/MIPS-Options.html Regards: José Vázquez ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] Lantiq subtargets based in SoC.
On 2013-05-03 4:17 PM, José Vázquez Fernández wrote: As have been done preciously in the ramips target the Lantiq target could be divided in subtargets based in the SoC (ase, danube, svip, ar9, vr9, ...) or the mips core (4k, 24k, 34k, ...), but the second option might be very confusing. The benefits will be the same as in ramips: better organization based in SoC instead of board, and the specific optimizations for each mips core might be easily managed, like dsp extensions, multithreading and some others. The idea is split the subtargets in this way: - XWAY Danube. - XWAY AR9. - XWAY VR9. - ASE or XWAY ASE. - Falcon. - SVIP-le. - SVIP-be. Simply making a somewhat arbitrary split of SoC types into subtargets the way you're describing is a bad idea - it wastes lots of extra CPU cycles for building all images. As for ramips: at least rt28xx and rt30xx support cannot coexist in the same kernel image due to memory layout changes - not sure about rt3883, but there's probably a good reason for that one too. You're not giving any proper justification for your proposed subtarget split (which is overkill anyway). - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] Lantiq subtargets based in SoC.
On 03/05/13 16:56, Felix Fietkau wrote: On 2013-05-03 4:17 PM, José Vázquez Fernández wrote: As have been done preciously in the ramips target the Lantiq target could be divided in subtargets based in the SoC (ase, danube, svip, ar9, vr9, ...) or the mips core (4k, 24k, 34k, ...), but the second option might be very confusing. The benefits will be the same as in ramips: better organization based in SoC instead of board, and the specific optimizations for each mips core might be easily managed, like dsp extensions, multithreading and some others. The idea is split the subtargets in this way: - XWAY Danube. - XWAY AR9. - XWAY VR9. - ASE or XWAY ASE. - Falcon. - SVIP-le. - SVIP-be. Simply making a somewhat arbitrary split of SoC types into subtargets the way you're describing is a bad idea - it wastes lots of extra CPU cycles for building all images. As for ramips: at least rt28xx and rt30xx support cannot coexist in the same kernel image due to memory layout changes - not sure about rt3883, rt3883 has pci but there's probably a good reason for that one too. You're not giving any proper justification for your proposed subtarget split (which is overkill anyway). - Felix i agree with felix, we used to have per soc subtargets and dropped them as there is no point in splitting things. ase needs a seperate subtarget as it has no pci, falcon / svip need their own subtarget, as they are are SoC variants of their own with different pinctrl and so forth. however for xway i see no reason to split up the support to a soc based approach. what we should add is a xway-vsmp subtarget for the 74k based SoC (xrx200) on boards where the vpe0 is not used for voice. John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] Lantiq subtargets based in SoC.
2013/5/3, John Crispin j...@phrozen.org: On 03/05/13 16:56, Felix Fietkau wrote: On 2013-05-03 4:17 PM, José Vázquez Fernández wrote: As have been done previously in the ramips target the Lantiq target could be divided in subtargets based in the SoC (ase, danube, svip, ar9, vr9, ...). The benefits will be the same as in ramips: better organization based in SoC instead of board, and the specific optimizations for each mips core might be easily managed, like dsp extensions, multithreading and some others. The idea is split the subtargets in this way: - XWAY Danube. - XWAY AR9. - XWAY VR9. - ASE or XWAY ASE. - Falcon. - SVIP-le. - SVIP-be. Simply making a somewhat arbitrary split of SoC types into subtargets the way you're describing is a bad idea - it wastes lots of extra CPU cycles for building all images. In the Lantiq target fortunately only compiles for the target board; the problem comes building the snapshots. You're not giving any proper justification for your proposed subtarget split (which is overkill anyway). - Felix i agree with felix, we used to have per soc subtargets and dropped them as there is no point in splitting things. ase needs a seperate subtarget as it has no pci, falcon / svip need their own subtarget, as they are are SoC variants of their own with different pinctrl and so forth. however for xway i see no reason to split up the support to a soc based approach. John With the split of the subtargets the optimizations for each SoC can be implemented easily, because the 34Kc cores have support for multithreading afaik, and for the danube based boards some kernel drivers can be disabled in order to make the kernel smaller. To summarize, the benefits are that optimizations for the different cpus can be easily implemented, but the side effect is that the compiling time will be higher. As Felix said, maybe the best choice, in order to keep it simple, will be tune all the boards to 34kc and enable the dsp extensions if they improve the overall performance of this processors . Benchmarking the danube 1.3 with dsp ase enabled and tuning to mips 24kec helps slightly, but would be very interesting to see the ar9 and vr9 performance increase. Attached there is a some kind of diff that shows the possible reorganization of the lantiq target. Regards: José lantiq_subtargets.diff.tar.bz2 Description: BZip2 compressed data bench.txt.tar.bz2 Description: BZip2 compressed data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
