Hi, Some comments about current hardfp RPM optflags has been that we have -mno-thumb . And some vendors might want to optimize some things for thumb in terms of memory size. So I'd like to preempt this issue before we run into it in deployment by vendors - and help by having a standard set of optimized packages.
Thumb2 is problematic on some silicons, due to http://cateee.net/lkddb/web-lkddb/ARM_ERRATA_430973.html - and this includes Nokia N900 and possibly other boards. But it is also very useful when it comes to memory and cache size of the running system. My proposal is to add on top of the 2 (armv7nhl, armv7hl) hardfp architectures, RPM these definitions: armv7thl: -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb armv7tnhl: -march=armv7-a -mfloat-abi=hard -mfpu=neon -mthumb armv7thl would be install compatible with armv7hl armv7tnhl would be install compatible with armv7thl, armv7nhl The argument against just flicking armv7hl from -mno-thumb to -mthumb is that we lose the current ARM reference device (N900) and possibly make MeeGo ARM undeployable on other boards. As well as potential bugs from compiling entire system for thumb (as Ubuntu had done, with a lot of effort) This will not require an additional OBS scheduler on top of the hardfp one, as we intend to generate these packages using same way we generate armv7nhl packages, by selecting some packages that benefit from the optimization(s) and generate additional packages for the targeted architectures. Package management & Image creation will then take the proper package matching the architecture, allowing for an optimized experience for target boards. The baseline for applications is -still- armv7hl and should be the primary target for SDKs and OBS. These additional flags allow flexibility. If there's no objections, I'll submit this towards the various places the archs needs to be supported in. BR Carsten Munk _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
