==== Activity Summary ====
* Completed "runtime size" data gathering across Vexpress-QEMU, i.MX
and U8500 platforms
* 3.7 is the kernel version verified across the said platforms
* Thanks to Shawn Guo for providing statistics on i.MX platform
* Google doc has been created and shared across relevant members
* Looking into adding Multiplatform Config support for U8500 platform
* Support for Rajagopal on Snowball board setup with tiny rootfs for
his testing/verification.
==== Plan ====
* Collect inputs from linusw on MultiPlatform work done so far and
continue to work
==== Issues ====
--- NA---
Hi everyone,
When building a kernel with the Linaro ARM toolchain I have two
seemingly simple questions, however I have been getting some very
different advice depending on who I talk to and what I read online,
study in gits etc. Hardware specific optimizations are confusing and
hard to test in a kernel since it such a multi-purpose conglomeration of
code. I just want to make sure I am using the correct general approach
before moving forward with trying things and testing. Our project is all
about testing and researching ways to increase kernel/Android
performance, so please don't reply with "just use an -O2 compilation and
forget about it" unless you have data you can provide that suggest that
this will give better performance than adding specific hardware
compilation flags.
Hopefully this is the right crowd to ask, wasn't sure if I should try
the kernel or Android list. I posted in the NEON list, but my message is
the only one from December! That leaves me with little hope there, so
we'll see how it goes here. If anyone can help me with part 1 or part 2,
I would be delighted!
Background:
* 3.4.x Android kernel
* Qualcomm APQ8064 quad core CPU (Cortex A15-like SoC with NEON/vfpv4
per core support).
* We are using the Linaro ARM toolchain 4.7.3 release 2012.11 on Linux
(arm-linux-gnueabihf).
Part 1) Which hardware and floating point compiler flags are
recommended/applicable for the above mentioned SoC when building kernel
itself?
-mtune=cortex-a15 (is this really doing anything for us in the
tool-chain's current state?)
Which -mfpu flag and other associated flags should we use in the Linaro
12.11 toolchain?
-mfpu=-neon-vfpv4
-mfpu=-vfpv4
-mfpu=-neon
-mvectorize-with-neon-quad
-funsafe-math-optimizations (is this required for -neon-vfpv4 and
-vfpv4 like we would use it for plain old -neon?)
Part 2) Next, which kernel Makefiles should be optimized using the
hardware specific flags from Q1? From my research thus far, this is our
current setup and we currently doing an -O2 build.
/Makefile:
KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -fno-common \
-Werror-implicit-function-declaration \
-Wno-format-security \
-fno-delete-null-pointer-checks -mno-unaligned-access \
-march=armv7-a -mtune=cortex-a15 \
-fpredictive-commoning -fgcse-after-reload -ftree-vectorize \
-fipa-cp-clone -fsingle-precision-constant -pipe \
-funswitch-loops -floop-interchange \
-floop-strip-mine -floop-block
CFLAGS_MODULE = (BLANK, but some say we should have flags here)
AFLAGS_MODULE = (BLANK, but some say we should have flags here)
LDFLAGS_MODULE =
CFLAGS_KERNEL = (BLANK, but some say we should have flags here)
AFLAGS_KERNEL = (BLANK, but some say we should have flags here)
/arch/arm/Makefile
arch-$(CONFIG_CPU_32v7) :=-D__LINUX_ARM_ARCH__=7 $(call
cc-option,-mtune=cortex-a15 -march=armv7-a -mfpu=neon-vfpv4
-ftree-vectorize -funsafe-math-optimizations,-march=armv7-a
-Wa$(comma)-march=armv7-a)
/arch/arm/vfp/Makefile
KBUILD_AFLAGS :=$(KBUILD_AFLAGS:-msoft-float=-Wa,-mfpu=neon-vfpv4
-ftree-vectorize -funsafe-math-optimizations)
If you can give any advice, it would be greatly appreciated.
Thanks and have a Happy New Year!
hi Nico & all,
For in my previous email, i get to know if we want to boot up
successfully with Nico's latest big.LITTLE SMP related patches (these
patches can get from landing team's tracking-armlt-tc2-pm branch), we
need update VE's firmware, otherwise the system ONLY can boot up the
first one core.
For VE DVD v5.0 has updated the firmware files, we tried it but still
cannot bootup successfully, below are the firmware infos now we are using:
V2P-CA15_A7 DCC bios: dbb_v107.ebf;
V2M-P1 MCC bios: mbb_v311.ebf;
V2M-P1 Bootmonoitor: bm_v517r.axf;
so i want to confirm which firmwares' version can match with Nico's
patches? Or there have special setting/configuration for the boot monitor?
Any suggestion is welcome and appreciate.
--
Thx,
Leo Yan
=== Highlights ===
* More discussions w/ Zach kernel tree mgmt stuff
* Minchan sent v4 of his volatile anon vma patch, and I took an initial
look.
* Worked with Dmitry's ashmem unit test, researched ioctl numbering issue.
* Reviewed Serban's patch and provided feedback
* Updated linaro.android tree w/ fixes required for Tushar as well as
cpufreq updates
=== Plans ===
* Holiday break. Hope everyone has a happy new year!
=== Issues ===
* NA
=== Issues ===
* Took the whole week leave to take of my family in hospital.
Backed to work today and then possibly will take leave on 12/20 and
12/21 again
since my sister has a surgical operation on that day.
<http://dict.baidu.com/s?wd=surgical%20operation>
==== Activity Summary ====
* Discussion with ShawnGuo regarding runtime size verification on i.MX
platform.
ShawnGuo communicated first cut "size data" information about modules,
however
"change in procedure" and verification on 3.7 kernel needs to be carried
out.
I have communicated the same.
* Finalized runtime data size information on vexpress platform, will be
updating in google docs.
* OMAP Setup is made ready to verify runtime size information however
multiplatform config is not supported and verification on OMAP is
currently pushed down in the priority, updated the blueprint accordingly.
* Runtime size information on Snowball/U8500: setup to verify runtime sze
information is ready, verifying on 3.7 kernel
==== Plan ====
* continue to work on runtime size information across I.MX and u8500
platform
* root cause Ethernet issue
==== Issues ====
0.5 day leave
=== Highlights ===
* Lots of discussions w/ Zach/Deepak on kernel tree mgmt stuff
* Minchan sent v3 of his volatile anon vma patch, and I reviewed and
pointed out hole in the semantics
* Started working on integrating the ashmem driver with the volatile
anon vma patch, but its ending up being not as trivial as I hoped.
* Community discussions about RTCs and persistent_clock interfaces
=== Plans ===
* Continue hacking on the vma/madvise approach to volatile ranges.
* Likely more talks w/ Zach :)
* Prep for holiday break
=== Issues ===
* NA
== Ulf Hansson ==
=== Highlights ===
Storage:
* Acked patches on mmc-list related to SDIO suspend/resume issues.
* Reviewed patches on mmc-list for Idle time BKOPS.
* Acked patches on mmc-list for fixing signal voltage switch procedure
for UHS mode.
* Co-operated with Lee Jones to help out in move away from using the
mmci host driver "ios_handler" (ux500 platform callback).
* Sent patches for discussion for mmci host driver, especially with
regards to power management.
Clk:
* Acked patches from Mike Turquette on clk framework.
=== Plans ===
Storage:
* Push patches for mmci host driver to support for UHS cards.
* Push patches for mmci host driver to further extend the power
management support.
* Push patches for mmci host driver to add new features like CMD23
support and more.
* Follow up on Idle time BKOPS patches on mmc list.
Clk:
* Send patch/rfc for clk framework, to make an unsued clk unprepared
at late_init.
* Add support for new clk-types in abx500 clock driver for the ux500 platform.
=== Issues ===
* Been trying for several month to get a hold of eMMC 4.5 device with
an SD-card adapter. Extremely important for the storage work in Linaro
to fully test eMMC4.5 features. It seems almost impossible.
Kind regards
Ulf Hansson
hi,
i saw Nico's git for the developing the big.LITTLE's cluster power
control for MP. In the kernel code. the cluster's first man need enable
the CCI's port and snooping for the cluster in non-secure world; In
CCI-400's spec, it says need to set the Secure Access Register (0x90008)
bit 0 so that we can enable non-secure access to CCI-400 registers.
On fast model, i added the code in boot-wrapper to set bit_0 for CCI's
Secure Access Register; but after set this bit, the boot-wrapper code
cannot change to hypervisor mode successfully.
On fast model, can we use CCI's secure access register? Current i use
the fast model version is: FE000-KT-00002-r7p1-80rel0.tgz, so if it's
related with the fast model's version?
Also, could u kindly point out there have boot-swapper's git for reference?
--
Thx,
Leo Yan
