Linaro-android

linaro-android@lists.linaro.org

1072 discussions

by YongQin Liu

Hi, kecheng So you can boot your PandaboardES with the image downloaded from http://releases.linaro.org/14.05/android/panda/, and you can use your DS-5 with it right? And your problem is that you can not find the CPU PMU data with your DS-5 tool? If so I don't think I can help you much here. I have no idea about the CPU PMU data. It might be better to check with the DS-5 team on how to collect the CPU PMU data. Just one thing I can think of is that, do you need to configure the DS-5 to collect the CPU PMU data if that is not collected by default? And I add linaro-android@ in the loop, there might be more people can help you. Thanks, Yongqin Liu On 30 March 2016 at 22:51, 季柯丞 <jkcll302089(a)gmail.com> wrote: > Dear Mr liu: > Hi, my name is Ji kecheng. I am a PhD of Southeast University. > We wanna use DS-5 to get the CPU PMU(Performance Monitor Unit) with the > Pandaboard ES(OMAP 4430/OMAP 4460). > However, we have tried the image downloaded with the link as follow, it > doesn't work. > http://releases.linaro.org/14.05/android/panda/ > > We found the gator.ko has been integrated in the image. But we cannot > fetch any PMU data. > Could you help me to fix this problem? > > Ji Kecheng > Best Regards > -- Best Regards, Yongqin Liu --------------------------------------------------------------- #mailing list linaro-android(a)lists.linaro.org <linaro-dev(a)lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-android

9 years

android-build toolchain-trunk, toolchain64-trunk jobs are broken due to unavailability of TCWG files

by Paul Sokolovsky

Hello, Following jobs: https://android-build.linaro.org/jenkins/job/linaro-android_toolchain-trunk/ https://android-build.linaro.org/jenkins/job/linaro-android_toolchain64-tru… appear to be broken for a month or more. Of their 6h15m runtime (when they're killed by build timeout) it spends about 3h in what appears to be an infinite loop trying to download some TCWG deliverables: https://android-build.linaro.org/jenkins/job/linaro-android_toolchain64-tru… As it happens for prolonged time and uses an anti-pattern (infinite loop) which wastes good deal of resources, I'm disabling these jobs now. Please review whether they're needed and fix them, and please be sure to use finite number of retries. P.S. This came up with me reviewing job status after Jenkins security upgrade over the weekend. 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

9 years, 1 month

[ANN] Gerrit upgraded to 2.11.5

by Paul Sokolovsky

Hello, All Linaro Gerrit servers have been upgraded to Gerrit 2.11.5 in planned manner. As was announced previously, we intended to upgrade directly to the latest 2.12, but literally couple of dates before upgrade we found out that there's known issue which affects replication services and thus our Git HA infrastructure. The bug has bean fixed by now in the Gerrit master, but the date of 2.12.1 release wasn't yet announced. As the aim of the current upgrade was to get on newer Gerrit version than now-old 2.10, we decided to upgrade to 2.11.5 in the meantime, and revisit upgrade to 2.12 after bug fix releases. Upgrade services appear to work stable based based on weekend monitoring, ditto for CI loops integrating with Gerrit. If you spot any issues, please provide details in a direct reply (not "Reply All") to this mail. One of the most user-facing changes in 2.11 is dropping support for "old" change screen UI design. About 20 people of (hundreds) in Linaro used the old design, and they were notified beforehand of the upgrade. You can read about changes and new features in 2.11 at https://gerrit-documentation.storage.googleapis.com/ReleaseNotes/ReleaseNot… As a sneak peek: * Yet in 2.10, there was introduced feature of editing a commit message in the Web UI. That's convenient if you e.g. spotted a typo in colleague's commit message - you don't need describe him/her an issue and make them rebase a change via command line, but can fix it on spot in the browser (subject to ACLs). * 2.11 brings this idea forward and allows to create entire patchsets via web browser, or post follow-up changes changes in the same way. It yet to be seen how useful this functionality is (in github, which has similar functionality, it's actually useful - if you e.g. read a README and spot a typo, you can submit a pull request with the fix on spot). Happy code reviewing from Systems Team! -- 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

9 years, 2 months

Re: [Linaro-validation] lava-android-test development state

by Milosz Wasilewski

Petr, On 19 January 2016 at 18:34, Petr Vorel <petr.vorel(a)gmail.com> wrote: > Hi there, > > what is the development state of lava-android-test? > * last development happen year ago, last tag 2014.01 > * not in Linaro's patchwork (https://patches.linaro.org/) > * no Debian package (there is empty git repo pkg/lava-android-test.git) > * last build isn't in PyPi (well other packages seems to be even pulled from > PyPi). > > Is it considered as done, or just abandoned? (if yes, why?) It's not used any more. The main reason (from my perspective) was inability of matching the test results to executed tests. The test that were important to us were migrated to lava-test-shell. Second reason for dropping support for lava-android-test was increasing difficulty in maintaining lava-android-test dependencies on LAVA servers deployed in our LAB. This solution didn't scale well and was abandoned. We have legacy support for lava-android-test in multi node environment if someone still wants to use this code. However my personal recommendation is to move to lava-test-shell. milosz > > I'm considering to use it for testing Android firmware builds, it looks nice... > > Thanks for info. > > Kind regards, > Petr > > PS: I'm sorry to posting to both lists, not sure which one is the right one. > _______________________________________________ > linaro-validation mailing list > linaro-validation(a)lists.linaro.org > https://lists.linaro.org/mailman/listinfo/linaro-validation

9 years, 3 months

lava-android-test development state

by Petr Vorel

Hi there, what is the development state of lava-android-test? * last development happen year ago, last tag 2014.01 * not in Linaro's patchwork (https://patches.linaro.org/) * no Debian package (there is empty git repo pkg/lava-android-test.git) * last build isn't in PyPi (well other packages seems to be even pulled from PyPi). Is it considered as done, or just abandoned? (if yes, why?) I'm considering to use it for testing Android firmware builds, it looks nice... Thanks for info. Kind regards, Petr PS: I'm sorry to posting to both lists here and linaro-validation) as I'm not sure which one is the right one.

9 years, 3 months

Blur vs. Block on icon highlighting

by Shawn Guo

Hi, I'm running into a problem on Android 5.1 when using keyboard to move input focus among different application icons. It seems that the problem may be related to how application icon is highlighted when it gets input focus. On customer's system, the application icon will be highlighted with a blur effect around it. As a comparison on hikey, I found that the icons gets highlighted with a square block around them. The attached pictures demonstrate the differences there. I guess that such input focus highlighting effect should be done by GPU. But the customer's system runs a same version Mali DDK as Hikey. So I'm wondering if this different behavior is caused by Android level of configuration. That's why I'm asking help from Android mail list. Any comment or hint about how this different behavior comes will be much appreciated. Thanks. Regards, Shawn

9 years, 3 months

The static linked 32bit binary size is different between flounder and flo

by YongQin Liu

Hi, Bero Any idea why the size of the binaries compiled from the same source files are different between the flounder version and the flo version? 10:29:01 liuyq: marshmallow$ ll out/target/product/{flo,flounder}/system/bin/libstagefright_mp3dec_test -rwxrwxr-x 1 liuyq liuyq 231360 Nov 2 10:29 out/target/product/flo/system/bin/libstagefright_mp3dec_test* -rwxrwxr-x 1 liuyq liuyq 124684 Nov 2 10:28 out/target/product/flounder/system/bin/libstagefright_mp3dec_test* 10:29:39 liuyq: marshmallow$ The binaries are 32bit static linked version compiled with the attached Android.mk And the size of libc.so files are different as well. 10:37:13 liuyq: marshmallow$ ll out/target/product/{flo,flounder}/system/lib/libc.so -h -rwxrwxr-x 1 liuyq liuyq 659K Oct 29 15:34 out/target/product/flo/system/lib/libc.so* -rwxrwxr-x 1 liuyq liuyq 540K Oct 19 18:32 out/target/product/flounder/system/lib/libc.so* 10:37:21 liuyq: marshmallow$ Some features are not compiled into the libc.so on the flounder platform? -- Best Regards, Yongqin Liu --------------------------------------------------------------- #mailing list linaro-android(a)lists.linaro.org <linaro-dev(a)lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-android

9 years, 3 months

[ANN] Planning next Gerrit upgrade

by Paul Sokolovsky

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

9 years, 4 months

Contribution to Linaro Mobile Group.

by Javier Romero

Hi, My name is Javier Romero and live in Buenos Aires, Argentina. I'm an electronic technician and teach Android OS in an IT institute, also work as a Linux Sysadmin. Would like to know if there is something where I can help with, on the Linaro Mobile Group. I appreciate your kind attention. With my Best regards, *Javier Romero* *E-mail: xavinux(a)gmail.com <xavinux(a)gmail.com>* *Skype: xavinux*

9 years, 5 months

Default Java version on android-build and imminent Jenkins upgrade

by Paul Sokolovsky

Hello, The latest Jenkins LTS release, 1.625, requires Java7 to run (to give some context, Java9 is in beta now, Java7 is many years old). As learned with some pain on ci.linaro.org, which already upgraded, this requirement applies not just to a Jenkins master, but also to build slaves, just to run slave agent to be connected to a master. We install both Java6 and Java7 on android-build.linaro.org slaves, but the default is still Java6, "for compatibility with older Android versions", as a comment says. Is Java6 being a default still relevant? The easiest way to accommodate the upcoming upgrade is just to switch default to Java7. If there're issues expected with that, we can follow an alternative way of adding adhoc version overrides for slave startup. -- 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

9 years, 5 months

← Newer
1
2
3
4
5
6
7
...
108
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-android