linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

by Wookey

* Back from holidays catch-up * Jetson TK1 board ready to deploy in LAB, but investigating why debian 4.5 kernels work and 4.6 don't before handover. [BB-261/LAB-218] Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/

10 years

Linaro 16.06 Release Available for Download

by Koen Kooi

The aim of science is to seek the simplest explanations of complex facts. Seek simplicity and distrust it. -- Whitehead. The Linaro 16.06 release is now available for download! 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

10 years, 1 month

Re: JITs and 52-bit VA

by Dave Hansen

On 06/22/2016 01:17 PM, Cyrill Gorcunov wrote: > On Wed, Jun 22, 2016 at 12:56:56PM -0700, Dave Hansen wrote: >> >> Yeah, cgroups don't make a lot of sense. >> >> On x86, the 48-bit virtual address is even hard-coded in the ABI[1]. So >> we can't change *any* program's layout without either breaking the ABI >> or having it opt in. >> >> But, we're also lucky to only have one VA layout since day one. >> >> 1. www.x86-64.org/documentation/abi.pdf - “... Therefore, conforming >> processes may only use addresses from 0x00000000 00000000 to 0x00007fff >> ffffffff .” > > Yes, but noone forces you to write conforming programs ;) > After all while hw allows you to run VA with bits > than > 48 it's fine, all side effects of breaking abi is up to > program author (iirc on x86 there is up to 52 bits on > hw level allowed, don't have specs under my hands?) My point was that you can't restrict the vaddr space without breaking the ABI because apps expect to be able to use 0x00007fffffffffff. You also can't extend the vaddr space because apps can *also* expect that there are no valid vaddrs past 0x00007fffffffffff. So, whatever happens here, at least on x86, we can't do anything to the vaddr space without it being an opt-in for *each* *app*.

10 years, 1 month

Re: JITs and 52-bit VA

by Dave Hansen

On 06/22/2016 12:20 PM, Andy Lutomirski wrote: >>> >> As an example, a 32-bit x86 program really could have something mapped >>> >> above the 32-bit boundary. It just wouldn't be useful, but the kernel >>> >> should still understand that it's *user* memory. >>> >> >>> >> So you'd have PR_SET_MMAP_LIMIT and PR_GET_MMAP_LIMIT or similar instead. >> > >> > +1. Also it might be (not sure though, just guessing) suitable to do such >> > thing via memory cgroup controller, instead of carrying this limit per >> > each process (or task structure/vma or mm). > I think we'll want this per mm. After all, a high-VA-limit-aware bash > should be able run high-VA-unaware programs without fiddling with > cgroups. Yeah, cgroups don't make a lot of sense. On x86, the 48-bit virtual address is even hard-coded in the ABI[1]. So we can't change *any* program's layout without either breaking the ABI or having it opt in. But, we're also lucky to only have one VA layout since day one. 1. www.x86-64.org/documentation/abi.pdf - “... Therefore, conforming processes may only use addresses from 0x00000000 00000000 to 0x00007fff ffffffff .”

10 years, 1 month

JITs and 52-bit VA

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

10 years, 1 month

[PATCH PM-QA v3] Fixed array initializations to calculate freq deviation.

by Saul Romero

Changes in cpufreq_06.sh to calculate summatory and average of frequency measurements. Bug: The tests for frequency deviation always fails with 'Err' Cause and solution: In the function 'compute_freq_ratio' the frequency is stored in an array of variables by indirect reference (http://www.tldp.org/LDP/abs/html/ivr.html) but the variable 'index' that points to next element in the array is initialized to 0 every time hence overriding the values. The same happens for the function 'compute_freq_ratio_sum' where the 'index' variable is always initialized to 0 and the variable 'sum' is always set to 0 not adding the subsequent values. Hence these initializations must be deleted from those functions and written into the 'function check_deviation' for keeping the correct values of frequency and calculations of average and summatory. With these changes the tests can now calculate the real values of average for the frequencies and the deviations can be tested and the tests now passes. Signed-off-by: Saul Romero <saul.romero(a)arm.com> --- cpufreq/cpufreq_06.sh | 17 +++-------------- 1 file changed, 3 insertions(+), 14 deletions(-) diff --git a/cpufreq/cpufreq_06.sh b/cpufreq/cpufreq_06.sh index b323dc8..8f1dc22 100755 --- a/cpufreq/cpufreq_06.sh +++ b/cpufreq/cpufreq_06.sh @@ -31,7 +31,6 @@ CPUCYCLE=../utils/cpucycle freq_results_array="results" compute_freq_ratio() { - index=0 cpu=$1 freq=$2 @@ -49,25 +48,18 @@ compute_freq_ratio() { } compute_freq_ratio_sum() { - index=0 - sum=0 - res=$(eval echo \$$freq_results_array$index) sum=$(echo $sum $res | awk '{ printf "%f", $1 + $2 }') index=$((index + 1)) - } __check_freq_deviation() { res=$(eval echo \$$freq_results_array$index) - if [ ! -z "$res" ]; then # compute deviation dev=$(echo $res $avg | awk '{printf "%.3f", (($1 - $2) / $2) * 100}') - # change to absolute dev=$(echo $dev | awk '{ print ($1 >= 0) ? $1 : 0 - $1}') - index=$((index + 1)) res=$(echo $dev | awk '{printf "%f", ($dev > 5.0)}') @@ -85,23 +77,20 @@ check_freq_deviation() { cpu=$1 freq=$2 - check "deviation for frequency $(frequnit $freq)" __check_freq_deviation - } check_deviation() { cpu=$1 - set_governor $cpu userspace - + index=0 for_each_frequency $cpu compute_freq_ratio - + index=0;sum=0 for_each_frequency $cpu compute_freq_ratio_sum avg=$(echo $sum $index | awk '{ printf "%.3f", $1 / $2}') - + index=0 for_each_frequency $cpu check_freq_deviation } -- 2.5.0 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

10 years, 2 months

[PATCH PM-QA v2] Fixed array initializations to calculate freq deviation.

by Saul Romero

Changes in cpufreq_06.sh to calculate summatory and average of frequency measurements. In the function 'compute_freq_ratio' the frequency is stored in an array of variables by indirect reference (http://www.tldp.org/LDP/abs/html/ivr.html) but the variable 'index' that points to next element in the array is initialized to 0 every time hence overriding the values. The same happens for the function 'compute_freq_ratio_sum' where the index variable is always initialized to 0 and the variable 'sum' is always set to 0 not adding the subsequent values. Hence this initializations must be deleted from those functions and written into the 'function check_deviation' for keeping the correct values and calculations of average. With these changes the tests now produce the correct results and the tests passes. Signed-off-by: Saul Romero <saul.romero(a)arm.com> --- cpufreq/cpufreq_06.sh | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/cpufreq/cpufreq_06.sh b/cpufreq/cpufreq_06.sh index b323dc8..a25bbd2 100755 --- a/cpufreq/cpufreq_06.sh +++ b/cpufreq/cpufreq_06.sh @@ -31,7 +31,7 @@ CPUCYCLE=../utils/cpucycle freq_results_array="results" compute_freq_ratio() { - index=0 + #index=0 cpu=$1 freq=$2 @@ -49,25 +49,21 @@ compute_freq_ratio() { } compute_freq_ratio_sum() { - index=0 - sum=0 + #index=0 + #sum=0 res=$(eval echo \$$freq_results_array$index) sum=$(echo $sum $res | awk '{ printf "%f", $1 + $2 }') index=$((index + 1)) - } __check_freq_deviation() { res=$(eval echo \$$freq_results_array$index) - if [ ! -z "$res" ]; then # compute deviation dev=$(echo $res $avg | awk '{printf "%.3f", (($1 - $2) / $2) * 100}') - # change to absolute dev=$(echo $dev | awk '{ print ($1 >= 0) ? $1 : 0 - $1}') - index=$((index + 1)) res=$(echo $dev | awk '{printf "%f", ($dev > 5.0)}') @@ -85,23 +81,20 @@ check_freq_deviation() { cpu=$1 freq=$2 - check "deviation for frequency $(frequnit $freq)" __check_freq_deviation - } check_deviation() { cpu=$1 - set_governor $cpu userspace - + index=0 for_each_frequency $cpu compute_freq_ratio - + index=0;sum=0 for_each_frequency $cpu compute_freq_ratio_sum avg=$(echo $sum $index | awk '{ printf "%.3f", $1 / $2}') - + index=0 for_each_frequency $cpu check_freq_deviation } -- 2.5.0 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

10 years, 2 months

The Linaro 16.05 release is now available for download!

by Koen Kooi

"No amount of careful planning will ever replace dumb luck." ~ Anonymous The Linaro 16.05 release is now available for download! 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

10 years, 2 months

[PATCH PM-QA] Fixed array initializations to calculate freq deviation.

by Saul Romero

Changes in cpufreq_06.sh to calculate summatory and average of frequency measurements. Signed-off-by: Saul Romero <saul.romero(a)arm.com> --- cpufreq/cpufreq_06.sh | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/cpufreq/cpufreq_06.sh b/cpufreq/cpufreq_06.sh index b323dc8..a25bbd2 100755 --- a/cpufreq/cpufreq_06.sh +++ b/cpufreq/cpufreq_06.sh @@ -31,7 +31,7 @@ CPUCYCLE=../utils/cpucycle freq_results_array="results" compute_freq_ratio() { - index=0 + #index=0 cpu=$1 freq=$2 @@ -49,25 +49,21 @@ compute_freq_ratio() { } compute_freq_ratio_sum() { - index=0 - sum=0 + #index=0 + #sum=0 res=$(eval echo \$$freq_results_array$index) sum=$(echo $sum $res | awk '{ printf "%f", $1 + $2 }') index=$((index + 1)) - } __check_freq_deviation() { res=$(eval echo \$$freq_results_array$index) - if [ ! -z "$res" ]; then # compute deviation dev=$(echo $res $avg | awk '{printf "%.3f", (($1 - $2) / $2) * 100}') - # change to absolute dev=$(echo $dev | awk '{ print ($1 >= 0) ? $1 : 0 - $1}') - index=$((index + 1)) res=$(echo $dev | awk '{printf "%f", ($dev > 5.0)}') @@ -85,23 +81,20 @@ check_freq_deviation() { cpu=$1 freq=$2 - check "deviation for frequency $(frequnit $freq)" __check_freq_deviation - } check_deviation() { cpu=$1 - set_governor $cpu userspace - + index=0 for_each_frequency $cpu compute_freq_ratio - + index=0;sum=0 for_each_frequency $cpu compute_freq_ratio_sum avg=$(echo $sum $index | awk '{ printf "%.3f", $1 / $2}') - + index=0 for_each_frequency $cpu check_freq_deviation } -- 2.5.0 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

10 years, 2 months

Re: Let's talk about boot loaders

by Mark Brown

On Fri, May 06, 2016 at 02:03:42PM -0400, Jon Masters wrote: > On 05/06/2016 01:10 PM, Mark Brown wrote: > > On Fri, May 06, 2016 at 12:20:40PM -0400, Jon Masters wrote: > > > But is it really worth trying after so long of the right thing not > > > happening? If anyone really cared about making general purpose distros boot > > > on embedded boards, efforts to compel standards would have happened years > > > ago. To do it right, we would need to have a couple of vendors involved who > > > could compel vendors to comply. > Note: by standards above, I specifically mean "separate platform flash" in > addition to all of the other associated things. Actually, to do it right you Oh, right. In that case this is all irrelevant anyway, there's no need to worry about magic areas of the disk and distros can just do whatever. > > Distros care and currently do ship on such systems - Debian stable lists > > a bunch of boards (something like 20 IIRC) as actively tested for > > example. The board and SoC vendors are to an extent irrelevant here, > I get your point, but for separate flash and getting vendors to ship > firmware, they very much need to be involved. Today, we can't agree as an > industry who is on the hook for this. With an enterprise hat on, I get to Personally I'm not convinced it's particularly worth worrying about - there's enough sensible ways to build systems where the separate storage for bootloaders just isn't solving problems people have that such things are going to be around for a while and inevitably people will end up wanting to run distros on them so at least the community distros need to work with them. > compel vendors to do the only sane thing (in my opinion) which is "thou > shalt ship EFI, on flash that we don't touch". And those who screwed up and > put EFI parameters on hidden disk partitions, or thought EFI variables were > a place to store MAC and platform parameters are slowly found and forced to > comply with the way the industry works. But on embedded, spending a few > cents to do the "right" thing is something that isn't going to happen unless > everyone mandates and pushes for it. It's not just cents, it's also things like board area, manufacturing process, usage models and for some use cases customers who want full control over the software stack. For some kinds of system like the enterprise market what you're describing is absolutely the right way to go but there's other segments where it either isn't solving problems people have or is currently actively worse so there's no compelling reason to adopt. But this is a bit off topic...

10 years, 3 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev