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
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
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
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
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
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
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(-)
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
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
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/dirty/gas-workarounds
NOTE: These patches are workarounds for toolchain bugs
and should not be merged in a branch intended to go upstream.
Dave Martin (2):
Add local symbols in relocate_kernel.S to work around gas bugs
ARM: omap: Work around gas pc-relative adr/ldr global label bug for Thumb-2
arch/arm/kernel/relocate_kernel.S | 14 ++++++++++----
arch/arm/mach-omap2/sleep34xx.S | 3 ++-
2 files changed, 12 insertions(+), 5 deletions(-)