linaro-dev April 2016

linaro-dev@lists.linaro.org

22 participants
16 discussions

by Maxim Kuvyrkov

This is a summary of discussions we had on IRC between kernel and toolchain engineers regarding support for JITs and 52-bit virtual address space (mostly in the context of LuaJIT, but this concerns other JITs too). The summary is that we need to consider ways of reducing the size of VA for a given process or container on a Linux system. The high-level problem is that JITs tend to use upper bits of addresses to encode various pieces of data, and that the number of available bits is shrinking due to VA size increasing. With the usual 42-bit VA (which is what most JITs assume) they have 22 bits to encode various performance-critical data. With 48-bit VA (e.g., ThunderX world) things start to get complicated, and JITs need to be non-trivially patched at the source level to continue working with less bits available for their performance-critical storage. With upcoming 52-bit VA things might get dire enough for some JITs to declare such configurations unsupported. On the other hand, most JITs are not expected to requires terabytes of RAM and huge VA for their applications. Most JIT applications will happily live in 42-bit world with mere 4 terabytes of RAM that it provides. Therefore, what JITs need in the modern world is a way to make mmap() return addresses below a certain threshold, and error out with ENOMEM when "lower" memory is exhausted. This is very similar to ADDR_LIMIT_32BIT personality, but extended to common VA sizes on 64-bit systems: 39-bit, 42-bit, 48-bit, 52-bit, etc. Since we do not want to penalize the whole system (using an artificially low-size VA), it would be best to have a way to enable VA limit on per-process basis (similar to ADDR_LIMIT_32BIT personality). If that's not possible -- then on per-container / cgroup basis. If that's not possible -- then on system level (similar to vm.mmap_min_addr, but from the other end). Dear kernel people, what can be done to address the JITs need to reduce effective VA size? -- Maxim Kuvyrkov www.linaro.org

7 years, 10 months

[IMPORTANT] Regression after android-review.linaro.org upgrade to Gerrit 2.12.2

by Paul Sokolovsky

Hello, Summary: Your SSH username on https://android-review.linaro.org will now match Linaro username (first.last) after the next login. You local repository clones need to be updated for new username. Detailed description: https://android-review.linaro.org was the first Gerrit server in Linaro, when there were no central LDAP user database yet. As a result, there were free-form SSH usernames used, instead of the later standard first.last as used on all the other Gerrit servers. This inconsistency was a subject of background concern for Systems team, but of course not something having enough priority to "fix". However, Gerrit 2.12.2 upgrade started tonight uncovered following issue: Gerrit tries to synchronize its SSH username setting with LDAP, and fails, as Gerrits own rules disallow changing of username. The symptom of this is error "Authentication temporary unavailable" when a user with "old" SSH username tries to login via browser. While this can be classified as a Gerrit bug (and previous versions were smart enough), we'll unlikely find any timely solution to keep things as they are. So, it makes sense to take a chance of cleaning up username and making this server follow standard username conventions. Consequently: 1. All usernames which don't match "first.last" pattern are reset. 2. If you are affected, you won't be able to perform SSH operations (like git clone/push) until you login via web interface. 3. On the next login via web interface, it will be set to LDAP's "first.last" value. 4. You will need to update remotes of your existing git clones to new username (or alternatively, re-clone). 5. If you already use "first.last" SSH username, you're unaffected. The list of users affected is given below. While it seems long, majority of enrties there are for people no longer at Linaro, or for community accounts (which didn't work since we switched to LDAP anyway). If you need further assistance, please open a ticket at https://servicedesk.linaro.org/servicedesk/customer/portal/4 . Thanks, Paul username:Ng username:pfefferz username:asac username:james_w username:fgiff username:jserv username:mabac username:deeptik username:cyang username:mpoirier username:ndec username:mwaddel username:mansson username:Sachin username:vishalbhoj username:suapapa username:fabo username:pabhishek username:cnxsoft username:amitdanielk username:patrikryd username:sangwook username:ericm username:pundiramit username:glandium username:eazyigz username:tixy username:danilo username:john username:nytowl username:tony_tu username:Sangwook username:StefanEkenberg username:uichi username:plars username:zyga username:ruppi username:ebenpor username:jhkim username:Annamalai username:markoncomputer username:Claude username:tianhongwang username:rchand00 username:omarrmz username:aviksil username:nvl1109 username:a0132810 username:pelya username:krtaylor username:developer4563 username:yusufbu username:dzinman username:arussello username:mdupuy username:williamcharles username:aorth username:lanaczko username:rmcc username:kcrudup username:kelvin username:angelsl username:unixmanlinuxboy username:Quiter username:sourxsunny username:pbeeler username:anmar username:wucongdonglai username:bambi username:rperier username:sgt username:roalex username:vishveshwarbhat username:therbom username:rajagopalvenkat username:winner00 username:ramesh username:abelloni username:sparksco username:fahadkdi username:ryanharkin username:axelfagerstedt username:nocoast username:milo username:fcarpenter username:hongbozhang username:fahadk username:pelya2 username:janjic username:dpervushin username:qoowater username:cerial username:tinojantony username:stephaneeee username:kishoreboddu username:nuclearmistake username:SanjasdfsafsffaySinghsdfasfRawat username:donvigo username:tinojgit username:afarah username:mechmetal username:akbennett username:c username:sikuner username:wasungkim username:stevanr username:deqiang username:anilkumar username:willnewton username:codeart username:lrabiet username:Bintian username:bintian username:vishalbhoj2 username:tusharbehera username:jbergsag username:tgall username:amitkhare username:neo username:paramanands username:sumit username:danielt username:help username:XavierHsu username:Serban username:Z username:koenkooi (127 rows) -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

7 years, 11 months

Developer Reference Platform 16.03 differences compared to Debian

by Riku Voipio

One of the goals of RPB is to follow that our changes go back upstream. For the next RPB release, a more polished report is planned. But to get things started, here's a sample - and to use as baseline to compare progress for the 16.06 release. The list of packages is collected from db410/alip image with distrodelta script[1]. This lists the packages that do not become from Debian (Jessie release) or Debian backports: New packages not in Debian: 96boards-artwork: 0.6-0linaro1 96boards-tools: 0.5 optee-client: 1.0.1+git5+g89f25ce-1.linarojessie.1 glshim: 0.41+git20150911.42a7739-0.linarojessie.1 linaro-artwork: 0.6-0linaro1 linaro-default-settings: 0.3-0linaro1 linaro-overlay: 1112.8 wcnss-config: 1.8 Changed packages: alsa-lib: 1.0.28-1+linaro1.linarojessie.1 * add UCM config file for HDMI and HiFi on DB410c * add UCM config file for HDMI on IFC6410 chromium-browser: 47.0.2526.16-1.6.linarojessie.1 * seccomp and namespace fixes * patches to compile on arm64/armhf firmware-nonfree: 20160110-1.linarojessie.1 * ti-connectivity (updates for HiKey): - Include wl18xx-fw-4 firmware - Add TIInit_11.8.32.bts for bluetooth support isc-dhcp: 4.3.3-8~linaro1 * Reverting requirement for debhelper >= 9.20151220 * Upload to make it work with latest systemd: - https://bugs.96boards.org/show_bug.cgi?id=271 linux: 4.4.0.linaro.104-1.linarojessie.1 * See kernel changes report (TBD) No-changes Backports: apparmor: 2.10-2.linarojessie.1 binutils: 2.25.90.20160101-1.linarojessie.1 gdb: 7.10-1.linarojessie.1 gyp: 0.1+20150913git1f374df9-1.linarojessie.1 java-common: 2:1.8-53.linarojessie.1 nodejs: 4.2.2~dfsg-1.1.linarojessie.1 openssl: 1.0.2d-1.linarojessie.1 systemd: 228-2.4.linarojessie.3 sysvinit: 2.88dsf-59.2.linarojessie.1 util-linux: 2.27.1-1.linarojessie.1 x265: 1.7-4~bpo8+1.linarojessie.1 xorg: 1:7.7+11.linarojessie.1 xorg-server: 2:1.17.3-2.linarojessie.2 xserver-xorg-video-fbdev: 1:0.4.4-1.linarojessie.1 xserver-xorg-video-freedreno: 1.4.0-1.linarojessie.1 [1] https://github.com/suihkulokki/distrodelta with command distrodelta -o Debian 'Debian Backports'

7 years, 12 months

[ANN] Gerrit 2.12.2 upgrade finished

by Paul Sokolovsky

Hello, The planned upgrade to Gerrit 2.12.2 is finished, all active Linaro servers have been upgraded. There were changes requiring action on users's side for https://android-review.linaro.org (see previous email "Regression after android-review.linaro.org upgrade to Gerrit 2.12.2"). There was second issue on https://android-review.linaro.org where a patch after clicking "Submit" was merged into the repository, but stuck in conflicting state in the web interface. This is believed to be caused by reliance on online reindexing introduced in recent Gerrit versions, which proved to be non-robust by looking at the multiple exceptions in logs. android-review.linaro.org has been reindexed in offline mode and patches verified to be processed correctly, and all following servers were upgraded in this mode. If you spot any issues, please report them via https://servicedesk.linaro.org/servicedesk/customer/portal/4 -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

7 years, 12 months

The Linaro 16.04 release is now available for download!

by Koen Kooi

Digital circuits are made from analog parts. -- Don Vonada The Linaro 16.04 release is now available for download! Both LSK and LNG tarball releases have been discontinued this cycle and the preferred way of procuring a release is through git.linaro.org. Using the Android-based images ======================= The Android-based images come in three parts: system, userdata and boot. These need to be combined to form a complete Android install. For an explanation of how to do this please see: http://wiki.linaro.org/Platform/Android/ImageInstallation If you are interested in getting the source and building these images yourself please see the following pages: http://wiki.linaro.org/Platform/Android/GetSource http://wiki.linaro.org/Platform/Android/BuildSource Using the OpenEmbedded-based images ======================= With the Linaro provided downloads and with ARM’s Fast Models virtual platform, you can boot a virtual ARMv8 system and run 64-bit binaries. For more information please see: http://www.linaro.org/engineering/armv8 Using the Debian-based images ======================= The Debian-based images consist of two parts. The first part is a hardware pack, which can be found under the hwpacks directory and contains hardware specific packages (such as the kernel and bootloader). The second part is the rootfs, which is combined with the hardware pack to create a complete image. For more information on how to create an image please see: http://wiki.linaro.org/Platform/DevPlatform/Ubuntu/ImageInstallation Getting involved ============ More information on Linaro can be found on our websites: * Homepage: http://www.linaro.org * Wiki: http://wiki.linaro.org Also subscribe to the important Linaro mailing lists and join our IRC channels to stay on top of Linaro developments: * Announcements: http://lists.linaro.org/mailman/listinfo/linaro-announce * Development: http://lists.linaro.org/mailman/listinfo/linaro-dev * IRC: #linaro on irc.linaro.org or irc.freenode.net #linaro-android irc.linaro.org or irc.freenode.net Known issues with this release ===================== Bug reports for this release should be filed in Bugzilla (http://bugs.linaro.org) against the individual packages or projects that are affected. On behalf of the release team, Koen Kooi Builds and Baselines | Release Manager Linaro.org | Open source software for ARM SoCs

7 years, 12 months

[meta-linaro-toolchain][jethro][PATCH] gcc-runtime: Fix QA Issues

by zongchun.yu＠nxp.com

From: Zongchun Yu <zongchun.yu(a)nxp.com> Fix following QA Issue: ERROR: QA Issue: gcc-runtime: Files/directories were installed but not shipped in any package: /usr/lib/libstdc++fs.la /usr/lib/libstdc++fs.a Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install. gcc-runtime: 2 installed and not shipped files. [installed-vs-shipped] Signed-off-by: Zongchun Yu <zongchun.yu(a)nxp.com> --- .../recipes-devtools/gcc/gcc-runtime_linaro-5.2.bb | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/meta-linaro-toolchain/recipes-devtools/gcc/gcc-runtime_linaro-5.2.bb b/meta-linaro-toolchain/recipes-devtools/gcc/gcc-runtime_linaro-5.2.bb index a147ebd..0ae3085 100644 --- a/meta-linaro-toolchain/recipes-devtools/gcc/gcc-runtime_linaro-5.2.bb +++ b/meta-linaro-toolchain/recipes-devtools/gcc/gcc-runtime_linaro-5.2.bb @@ -5,3 +5,11 @@ require recipes-devtools/gcc/gcc-runtime.inc FILES_libgomp-dev += "\ ${libdir}/gcc/${TARGET_SYS}/${BINV}/include/openacc.h \ " + +FILES_libstdc++-dev += "\ + ${libdir}/libstdc++fs.la \ +" + +FILES_libstdc++-staticdev += "\ + ${libdir}/libstdc++fs.a \ +" -- 1.8.3.2

8 years

Debian-style package build logs

by Riku Voipio

Hi, Our Debian-style package builds logs for RPB, 96boards and linaro builds are now available on repo.linaro.org. Previously build logs were available in jenkins, but they expired in 30 days from build. Now build logs are located in the same directory as the packages - for example qemu, you would find the logs for qemu builds in http://repo.linaro.org/ubuntu/linaro-overlay/pool/main/q/qemu/ directory. The build logs are also broadcast via the packages mailing list: https://lists.linaro.org/pipermail/packages/

8 years

[fido/jethro][PATCH] external-linaro-toolchain: correct path for libgcov.a to package properly

by Denys Dmytriyenko

From: Denys Dmytriyenko <denys(a)ti.com> With migration from crosstool-NG to ABE, libgcov.a changed path and is now available in ${libdir}. So, instead of being packaged into own libgcov-dev package, it gets picked up by "catchall" libc6-staticdev package. This mostly works, as long as nothing directly depends on libgcov-dev. Unfortunately, packagegroup-core-standalone-sdk-target does and is the one being used when building SDKs with -c populate_sdk. Correct path to generate libgcov-dev pkg. Signed-off-by: Denys Dmytriyenko <denys(a)ti.com> --- This is required for fido/jethro, but krogoth/master introduces single -dev package rule, so separate libgcov-dev package can be dropped entirely. .../external-linaro-toolchain/external-linaro-toolchain.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb b/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb index ea41179..531caf7 100644 --- a/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb +++ b/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb @@ -301,7 +301,7 @@ PKGV_gdbserver = "${ELT_VER_GDBSERVER}" ALLOW_EMPTY_${PN}-mtrace = "1" FILES_${PN}-mtrace = "${bindir}/mtrace" -FILES_libgcov-dev = "${libdir}/${TARGET_SYS}/${BINV}/libgcov.a" +FILES_libgcov-dev = "${libdir}/libgcov.a" FILES_libsegfault = "${base_libdir}/libSegFault*" -- 2.2.0

8 years

[ANN] Upcoming Gerrit 2.12 upgrade

by Paul Sokolovsky

Hello, 4 months have passed since the previous Gerrit upgrade (see below for reference), when Systems team had wanted to upgrade directly to 2.12, but due to last-minute issues discovered in it, upgraded to 2.11.5 instead. Gerrit is at 2.12.2 now, with many issues fixed and it being quite stable now. We also have stakeholders waiting for 2.12 functionality any day now. So, Systems team plan to upgrade the following systems: review.linaro.org android-review.linaro.org dev-private-review.linaro.org lhg-review.linaro.org starting end of day Friday, April 29th and throughout Saturday April 30th. Let us know if you have questions or concerns (for example, if you need uninterrupted Gerrit access until end of the US day on April 29). Thanks, Paul Begin forwarded message: Date: Mon, 14 Dec 2015 19:01:46 +0200 From: Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org> To: linaro-dev <linaro-dev(a)lists.linaro.org>, linaro-android <linaro-android(a)lists.linaro.org>, "systems(a)linaro.org" <systems(a)linaro.org> Subject: [ANN] Planning next Gerrit upgrade Hello, We upgraded from Gerrit 2.8 to 2.10 in the beginning of September, and it went pretty smooth and let us overcome few annoying issues and enjoy few new features and better integration with other apps. Unfortunately, 3 months later, 2.10 also feels old, with 2.12 having been released in the interim. With various Linaro groups continuing to leverage advanced Gerrit features and integrations with other apps (Jenkins, Bugzilla), Systems team faces various bugs and issues. None of these issues are too grave, but they're quite convoluted and take much time to be researched and understood. And then we find out that it's a known issue in 2.10, which was fixed in later versions. Jenkins' Gerrit integration already requires 2.12 for full functionality and warns about our version being too old and some features not supported. Which in turns brings concerns that every time it doesn't work as expected, it may be because Gerrit plugin is no longer tested with 2.10 and hits some issue pertaining to it. With that in mind, Systems team would like to start planning for next Gerrit upgrade, and move straight to the latest, 2.12. To remind, the reason we didn't upgrade to 2.11 last time, was because 2.10 was the last version which included old-style change review screen, and we wanted to provide smoother transition and let people to try the new screen at their own pace. So, if you still use the old design, please go to https://review.linaro.org/#/settings/preferences , and in "Change View:" dropdown, select "New Screen", and give it a chance with the help of this doc: https://review.linaro.org/Documentation/user-review-ui.html And if you have any concerns regarding the upgrade, please speak up now. Otherwise, we can do it in one of the following timeframes: 1. Upgrade in January. 2. Upgrade a bit later, but still before the Connect. 3. Discuss and plan upgrade at the Connect. Systems team votes for the choice 1, upgrade next month (apparently, by the end of), as that will allows us to deliver smoother Gerrit experience to other teams, instead of firefighting older version issues. Thanks, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

8 years

gcc-4.9.4, 'no features' not recognized with -mcpu option

by Laurent Thévenoux

Dear Devs, I get the following error when I use gcc 4.9.4 with the -mcpu flag set with a certain configuration of ‘feature/nofeature’, i.e.: -mcpu=cortex-a57+fp+simd+nocrypto+nocrc will fail, but -mcpu=cortex-a57+fp+nocrypto+simd+nocrc won’t, for example. Here the error I get with the former -mcpu flag: Assembler messages: Error: unknown architectural extension `n' Error: unrecognized option -mcpu=cortex-a57+fp+simd+n Minimal test case: $gcc -march=armv8-a+fp+simd+nocrc+nocrypto -mcpu=cortex-a57+fp+simd+nocrypto+nocrc -mtune=cortex-a57 helloworld.c. According to the gcc documentation <https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/AArch64-Options.html#AArch64-O…> the order seems to be irrelevant. I obtained the error with the linaro-gcc 4.9.4 binary release, as well as a personal built from linaro sources package. It also fails with gcc 4.9.2 on the 3.18.0-linaro-hikey debian distribution. I also tried with (linaro) gcc 4.8.5, 5.1.1, 5.2.1, and 5.3.1 versions, and it works well. Do I have to open a bug report for this, or maybe, I just misunderstood something, somewhere? Regards, Laurent Thévenoux

8 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev April 2016