linaro-dev December 2010

linaro-dev@lists.linaro.org

84 participants
75 discussions

by Dave Martin

Hi all, I'd be interested in people's views on the following idea-- feel free to ignore if it doesn't interest you. For power-management purposes, it's useful to be able to turn off functional blocks on the SoC. For on-SoC peripherals, this can be managed through the driver framework in the kernel, but for functional blocks of the CPU itself which are used by instruction set extensions, such as NEON or other media accelerators, it would be interesting if processes could adapt to these units appearing and disappearing at runtime. This would mean that user processes would need to select dynamically between different implementations of accelerated functionality at runtime. This allows for more active power management of such functional blocks: if the CPU is not fully loaded, you can turn them off -- the kernel can spot when there is significant idle time and do this. If the CPU becomes fully loaded, applications which have soft-realtime constraints can notice this and switch to their accelerated code (which will cause the kernel to switch the functional unit(s) on). Or, the kernel can react to increasing CPU load by speculatively turn it on instead. This is analogous to the behaviour of other power governors in the system. Non-aware applications will still work seamlessly -- these may simply run accelerated code if the hardware supports it, causing the kernel to turn the affected functional block(s) on. In order for this to work, some dynamic status information would need to be visible to each user process, and polled each time a function with a dynamically switchable choice of implementations gets called. You probably don't need to worry about race conditions either-- if the process accidentally tries to use a turned-off feature, you will take a fault which gives the kernel the chance to turn the feature back on. Generally, this should be a rare occurrence. The dynamic feature status information should ideally be per-CPU global, though we could have a separate copy per thread, at the cost of more memory. It can't be system-global, since different CPUs may have a different set of functional blocks active at any one time -- for this reason, the information can't be stored in an existing mapping such as the vectors page. Conversely, existing mechanisms such sysfs probably involve too much overhead to be polled every time you call copy_pixmap() or whatever. Alternatively, each thread could register a userspace buffer (a single word is probably adequate) into which the CPU pokes the hardware status flags each time it returns to userspace, if the hardware status has changed or if the thread has been migrated. Either of the above approaches could be prototyped as an mmap'able driver, though this may not be the best approach in the long run. Does anyone have a view on whether this is a worthwhile idea, or what the best approach would be? Cheers ---Dave

14 years, 11 months

Linaro-Alpha-1:Unable to Create Boot Images

by Praveen Arkeri

Hi, I am trying to create boot images for vexpress platform following instructions mentioned here https://wiki.linaro.org/Releases/MilestoneBuilds. Daily Build & HwPack Images used: * http://releases.linaro.org/platform/linaro-n/headless/alpha-1/linaro-nat ty-headless-tar-20101202-1.tar.gz * http://releases.linaro.org/platform/linaro-n/hwpacks/alpha-1/vexpress/20 101201/1/images/hwpack/hwpack_linaro-vexpress_20101201-1_armel_supported .tar.gz I am getting errors while installing images on SD card when I tried following command: sudo linaro-media-create --rootfs ext3 --mmc /dev/sdb --dev vexpress --binary linaro-natty-alip-tar-20101202-1.tar.gz --hwpack hwpack_linaro-vexpress_20101201-1_armel_supported.tar.gz . . Populating Boot Partition Installing Boot Loader tar: binary/usr/lib/u-boot/ca9x4_ct_vxp/u-boot.bin: Not found in archive tar: Exiting with failure status due to previous errors I am not sure whether I am using right build images, can anyone point me to the working build images for vexpress platform. Thanks Praveen

14 years, 11 months

useful embedded linux wiki

by Bill Traynor

Hello, It was suggested to me that I recommend to the list the http://elinux.orgwiki as a good online resource for embedded linux information. If you find it useful, please feel free to register and contribute ;) Thanks Bill

14 years, 11 months

Re: dpkg: emdebian.org and other machines patched for armhf support

by Konstantinos Margaritis

On 7 December 2010 18:35, Paul Brook <paul(a)codesourcery.com> wrote: >> In essence, I would like to express my objection in having the same triplet >> for both softfp and hard ABIs. I know upstream (ARM) objects, but IMHO they >> just haven't done the extensive compiling I have and didn't consider the >> problems (I doubt anyone else has built ~8000 packages for a hardfloat >> port). > > As the relevant upstream maintainer I'll confirm this objection. In the past > gcc used to try and guess which config to use based on variants of the > triplet. In practice this caused more problems than it solved, especially when > you have a single toolchain that can target multiple variants. > > If you want different triplets then I suggest you use the vendor field. e.g > arm-debian_armel-linux-gnueabi and arm-debian_armhf-linux-gnueabi. Which is exactly what I am doing. You are right I should be more specific. Right now, armhf uses arm-hardfloat-linux-gnueabi -which as was suggested here uses the vendor field. It works fine, in truth, only a handful of packages break with the vendor field and the fix is trivial. What was suggested to me was that the vendor field should *NOT* be used and a single arm-linux-gnueabi should be used for both softfp and hard ABIs. I'm sorry but especially in the case of compilers and in particular cross-compilers, this just does not work. Unless there is another way of OS (and ABI) detection, like the DEB_HOST_ABI fields, there is no way to know which ABI to compile from. So, my objection is in not keeping the arm-hardfloat-linux-gnueabi triplet. I did not suggest a different triplet altogether, just the ability to use the vendor field and thus in essence make a different triplet -but not too different. Konstantinos

14 years, 11 months

Re: dpkg: emdebian.org and other machines patched for armhf support

by Konstantinos Margaritis

On Tuesday 07 December 2010 16:02:16 Hector Oron wrote: > Hello, > > I am patching machines to support armhf, which it is almost at 90% > built. I know you are very busy with squeeze release, but could you > give a comment if the patch is wrong or right, as we are using it for > patching machines? Why is it taking so long to include such > architecture? > Let me know if I can help you out doing a NMU if you do not have the > time. Nice timing Hector, I was just thinking of sending a mail to the lists (so I'm cross-posting this mail to both debian-arm and linaro-dev lists as they are [in]directly involved in this). In essence, I would like to express my objection in having the same triplet for both softfp and hard ABIs. I know upstream (ARM) objects, but IMHO they just haven't done the extensive compiling I have and didn't consider the problems (I doubt anyone else has built ~8000 packages for a hardfloat port). So, what is the problem: I'm trying to port some compilers now to armhf now - gnat, openjdk, etc- using cross-compiling (you know, build a cross-compiler on an arch that already supports gnat, then use that cross-compiler to build a native binary and use that binary to build the final compiler on the native machine. It's a complicated process with lots of problems, but I've done this before -I actually did the gnat powerpc port for Debian back in 2000, using that same method, things have evolved since then but not that much. With a different triplet, I just have to add a new triplet entry for armhf to gnat's setup scripts. Using the same triplet, I would have to actually go to great lengths to change the scripts to use something else than the gnu triplet to decide cpu/system detection -not to mention that I would have to push for acceptance for each and every such patch. I'm sorry, but right now I have better things to do than this. Anyway, I know this point has been stressed before, but I now I would like to re-surface this issue again. Till now I was mostly indifferent, but now I'm convinced that we should *not* force the same triplets for the two abis until there is a concrete migration plan of OS detection using another method. It mostly ends down to unnecessary over-engineering with little benefit and way too many problems. I like simplicity and any other solution than a single triplet is not simple at the moment. So, what does this mean? It means that someone has first to propose a proper solution for handling this sort of stuff when a single triplet -something like that has been proposed in http://bugs.debian.org/596298 but though it's a good idea, it has not been discussed as much as it should. It has to actually be decided and even then we still would have to change many configure scripts to use that, as gcc for example configures based on the gnu triplet, NOT something as arbitrary as DEB_{HOST,BUILD}_ABI. In real terms, this means it's going to take a very long time to actually have something that works -no I don't think 6 months are enough. Anyway, with regards to the actual bug report, I have done a 1.15.8.6+armhf.1 release -in debian-ports.org/unreleased for now- which fixes a bug I missed previously. Some tests also fail, but that's beside the point, they have to be fixed to support quads as well -which I will do in the next days and I will send a complete patch. For that matter, I have tested the patch on amd64 and i386 and it doesn't break anything. The problem is that with ~7600 packages built and still the port is not recognized by dpkg. So, bottom line, until the issue with multiarch/DEB_HOST_ABI is actually *decided* could you please please get armhf support into dpkg proper? Or at least give a good reason why you do not accept the patch? Thanks Konstantinos

14 years, 11 months

Fwd: Scalable memory operations with multiple cores

by Robert Fekete

Hi Everyone knowing awfully lot about memory management and multicore op, My name is Robert Fekete and I work in the ST-Ericsson Landing Team. I have a question regarding multicore SMP aware memory operations libc, and I hope you can have an answer or at least direct me to someone who might know better. I have already mailed Michael Hope who recommended me to mail this list(of course). The issue I am experiencing is that when I am running a memset operation(on different non overlapping memory areas) on both cores simultaneously they will affect each other and prolong the work of each processes/cpu's by a factor of ~3-4(measured in Lauterabach). i.e. assume a memset op that takes around 1ms (some really big buffer in a for loop many times) Non-simultaneous memsets: (total time 2ms, each process execution time 1ms, x == running) core1 :xxxxoooo core2 :ooooxxxx Simultaneous memsets: (total time 3ms , each process 3ms) core1 :xxxxxxxxxxxx core2 :xxxxxxxxxxxx Well there are some factors that can explain parts of it. There is a bandwidth limitation which will peak on one memset meaning that two memsets cannot possibly go faster and a proper value should be around 2ms(not 3-4ms), The L2$ is 512k which may lead to severe L2$ mess up since the sceduler is extremely fair and fine granular between the cores. L1$ will also get hurt. But the real issue is that the two totally different memops(big ones though) in parallell will mess up for each other. Not good if one of the processes on core 1(for example) is a high prio compositor and the second process on core 2 is a lowprio crap application. The the Low prio crap App will severely mess up for the compositor. OS prio does not propagate to bus access prio. Is there a way to make this behaviour a bit more deterministic...for the high prio op at least, like a scalable memory operation libc variant. I read an article about a similar issue on Intel CPUs and the solution in this case is a scalable memory allocator lib. http://software.intel.com/en-us/blogs/2009/08/21/is-your-memory-management-… More academic reading of the phenomenon: http://books.google.com/books?id=NF-C2ZQZXekC&pg=PA353&lpg=PA353&dq=multi+c… BR /Robert Fekete

14 years, 11 months

[GIT PULL] ~dmart/linux-2.6-arm: Thumb-2/SMP-on-UP fixes accepted by rmk

by Dave Martin

The following changes since commit fe75943b7808aac7ef001a1bd4d8159a95e758ac: ARM: 6438/2: mmci: add SDIO support for ST Variants (2010-12-02 13:22:08 -0500) are available in the git repository at: git://git.linaro.org/people/dmart/linux-2.6-arm.git for-linaro-2.6.36/accepted-by-rmk Dave Martin (16): Revert "ARM: Avoid undefined Thumb-2 instructions using PC in compressed/head.S" ARM: kexec: Add missing memory clobber to inline asm in crash_setup_regs() ARM: kexec: Fix crash_setup_regs() for ARMv7 and CONFIG_THUMB2_KERNEL ARM: kuser: Fix incorrect cmpxchg syscall in kuser helpers ARM: RealView: Correct data alignment in headsmp.S for CONFIG_THUMB2_KERNEL ARM: vexpress: Correct data alignment in headsmp.S for CONFIG_THUMB2_KERNEL ARM: Allow SMP_ON_UP to work with Thumb-2 kernels. ARM: kexec: Correct data alignment for CONFIG_THUMB2_KERNEL ARM: vfp: Correct data alignment for CONFIG_THUMB2_KERNEL ARM: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in bootp/init.S ARM: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in kernel/head.S ARM: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in mm/proc-v7.S ARM: Thumb-2: Fix CONFIG_THUMB2_KERNEL breakage in compressed/head.S ARM: Thumb-2: Restore sensible zImage header layout for CONFIG_THUMB2_KERNEL ARM: Thumb-2: Fix long-distance conditional branches in head.S for Thumb-2. ARM: kprobes: Don't HAVE_KPROBES when CONFIG_THUMB2_KERNEL is selected arch/arm/Kconfig | 4 ++-- arch/arm/boot/Makefile | 5 ----- arch/arm/boot/bootp/init.S | 2 ++ arch/arm/boot/compressed/head.S | 17 ++++++++++------- arch/arm/include/asm/assembler.h | 22 +++++++++++++++++++--- arch/arm/include/asm/kexec.h | 18 ++++++++++++++---- arch/arm/kernel/entry-armv.S | 6 +++--- arch/arm/kernel/head.S | 20 +++++++++++++++++--- arch/arm/kernel/relocate_kernel.S | 2 ++ arch/arm/mach-realview/headsmp.S | 1 + arch/arm/mach-vexpress/headsmp.S | 1 + arch/arm/mm/proc-v7.S | 4 ++-- arch/arm/vfp/vfphw.S | 1 + 13 files changed, 74 insertions(+), 29 deletions(-)

14 years, 11 months

Landing team pages?

by Michael Opdenacker

Hi, I can't find any details about the landing teams on the wiki, except this https://wiki.linaro.org/LandingTeams It would be useful to have a Wiki page per landing team, showing the team members and the corresponding Launchpad pages (if any). For example, I wanted to reply to a forum question (http://www.linaro.org/linux-bsps/show/15), but didn't find any link to the OMAP landing team. Thank you in advance, Cheers, Michael. -- Michael Opdenacker - Community Manager Linaro, http://linaro.org Cell: +33 621 604 642 IRC: 'opm' in #linaro on irc.freenode.net

14 years, 11 months

Accessing an A9 board

by Michael Hope

Hi there. Does anyone have a Cortex-A9 board with Maverick and a hard disk that I could access? I've heard that we've regressed on the A9 in some benchmarks from 4.4 to 4.5 and would like to verify. -- Michael

14 years, 11 months

[GIT PULL] ~dmart/linux-2.6-arm: toolchain bug workarounds for Thumb-2

by Dave Martin

14 years, 11 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev December 2010