Hi,
I have an interesting observation that I thought might be interesting
to the tool-chain team.
I was trying to build u-boot in Thumb2 for OMAP4. Everything was fine
until I added some patches recently. One of these patches introduced an
API (let's say foo()) that has a weakly linked alias(let's say
__foo()) and a strongly linked implementation(the real foo()) in an
assembly file.
Although I give -mthumb and -mthumb-interwork for all the files,
apparently GCC generates ARM code for assembly files. In the final
image foobar() calls foo() using a BL. Since foobar() is in Thumb and
foo() in ARM, it ends up crashing. Looks like foobar() assumed foo()
to be Thumb because __foo() is Thumb.
Also I see that 'objdump -S' aborts when it tries to parse foo().
I could workaround this problem by having foo() also in a C file that
in turn calls into the assembly file.
I tried Linaro GCC 4.5.2 and Codesourcery Lite GCC 4.4.1. Both seem to
have the issue.
Isn't this an issue with GCC or am I missing something?
-Aneesh
Re-sending as these patches did not make it to the lists due to
issues with my 'git send-email'
v3 has mainly 2 differences from v2
-1- TWL driver now uses just one table for both dt and
non-dt based lookup for driver data.
-2- All common regulator nodes for twl4030 and twl6030 are
now defined in the twl4030.dtsi and twl6030.dtsi instead of
repeating the nodes in all board files, which also means
the patch ('arm/dts: twl: Pass regulator data from dt')
has a dependency with the series from Benoit which adds the
twl4030.dtsi and twl6030.dtsi files[1].
I have tested the patches on omap4panda and omap3beagle boards.
[1] git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.4/dt_i2c_twl
Rajendra Nayak (2):
regulator: twl: adapt twl-regulator driver to dt
arm/dts: twl: Pass regulator data from dt
.../bindings/regulator/twl-regulator.txt | 63 ++++++
arch/arm/boot/dts/omap3-beagle.dts | 6 +
arch/arm/boot/dts/twl4030.dtsi | 18 ++
arch/arm/boot/dts/twl6030.dtsi | 60 +++++
drivers/regulator/twl-regulator.c | 227 +++++++++++++-------
5 files changed, 301 insertions(+), 73 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/twl-regulator.txt
Hey,
As usual, here it goes the announcement of the 12.02 RC images. This
time it's later than usual because we had an issue with our builder
(offspring), but seems to be all solved now (thanks to Fathi).
This release includes a newer version of Unity (2d and 3d), XBMC and
for Pandaboard's OpenGL ES drivers. Other than that we also had minor
fixes for other boards, with improvements at the audio support as
well.
You can find our current test cases at
https://wiki.linaro.org/Platform/QA/TestCases/Ubuntu, and the 12.02 RC
builds (for all boards and image flavors) at
http://snapshots.linaro.org/oneiric/, with build id
20120221-1 for hwpacks and 20120221-0 for the rootfs (nano, developer,
alip, ubuntu-desktop and linaro-tv-xbmc).
For our four main boards we also have a testing spreadsheet, were we
publish the official release testing, done by the dev platform
engineers.
You can find the links at
https://wiki.linaro.org/Platform/DevPlatform/Testing (note that you
can find the bug reports from the test cases by looking at the QA page
tag links).
Fathi will be coordinating all respin requests in the next following
days at linaro-release m-l, and the final image will be published this
thursday, at releases.linaro.org.
Please also be sure to publish any bug report with the RC images
against https://launchpad.net/linaro-ubuntu, or just contact us at
#linaro @ freenode
(https://wiki.linaro.org/MeetTheTeam#Developer_Platform).
Thanks,
--
Ricardo Salveti de Araujo
Hello
here is the status of the Graphics group. Latest meeting minutes can be
found in
https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2012-02-22
= Highlights =
- related to the 12.02 release the group managed to release the intended
components: libmatrix, glcompbench, glmark2, glproxy. Details are in the
12.02 release highlights -
https://wiki.linaro.org/Cycles/1202/Release/Highlights
- On the Unity/Nux/Compiz front: we are discussing the way forward
related to compiz-core with Ubuntu DX. There is a patch from our side,
based on earlier work done while Travis was still working for GFX - in
discussions this is the 'distro' or 'ifdef' patch, which is rather large
and work has been going on to split it into parts.
One part introduces an API which does not affect Compiz or Unity per se.
The objective is to have Unity using the new API. In doing so, Unity
will be loosing its fixed function OpenGL code and it will start to use
a more recent part of the OpenGL API that is more compatible with OpenGL
ES (it would turn the compiz package into a compiz-gles2). This will
reduce the difference in code between Unity on the desktop and Unity on ARM.
The point is this API patch won't be used right away when it is
proposed. So there aren't any existing automated DX tests to exercise it
in Unity immediately. This is an issue since the DX team are trying to
achieve working unity-3d for 12.04 before anything else, and they are
past feature freeze.
It has now been agreed to work on getting the 'distro' patch landed as
soon as possible. The API patch will be worked on at a later stage.
- dmabuf plans: the points from the discussions at Connect are being
collected at
https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/UMM/Status,
and a number of blueprints are being created and discussed to reflect
the work under https://blueprints.launchpad.net/linaro-mm-sig/
- 12.03 plans: apart from the compiz and dmabuf work which was mentioned
above, the group will focus on working towards glmark2 backlog items,
glcompbench + glproxy.
- GFX LAVA dashboard: Alexandros has given a private demo of the
dashboard to a number of people. It is clear that the tests employed are
really useful in discovering regressions and issues with performance,
comparing daily test-run results. The development strategy is to focus
on the glmark2 benchmark first. After the glmark2 visualization is in a
good state, the team will start looking into visualizing additional
benchmarks. Due to the Linaro data policy there is also some polishing
needed - perhaps there will be 2 versions of the dashboard with the
externally available being completely compliant with the data policy.
Please note that the requirement to make a private version available
under permission is proving challenging, seems we would be spending much
time protecting the private dashboard view
- Finally related to prototyping around perf events (Mali): currently
this is bit stuck in not getting much data across the GPUs (information
is different between GPUs as well as the way to get the information is
different for different GPUs), trying to solve this in a good way.
Requires some driver specific modifications to generate the data
correctly, we will continue piloting this.
Questions, issues please let me know.
Best regards
--
Ilias Biris ilias.biris(a)linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs
This patch series moves the timekeeping and irq enabling from the platform
code to the core cpuidle driver. Also, the platform irq disabling was removed
as it appears that all calls into cpuidle_call_idle will have already called
local_irq_disable().
To save reviewers time, only a few platforms which required the most changes
are included in this version. If these changes are approved, the next version
will include the remaining platform code which should require minimal changes.
For those who have followed the previous patch versions, as you know, the
previous version of this patch series added some helper functionality which
used a wrapper function to remove the time keeping and irq enabling/disabling
from the platform code. There was also initialization helper functionality
which has now been removed from this version. If the basic implementation
in this version is approved, then a separate patch submission effort can be
made to focus on consolidation of initialziation functionality.
Based on 3.3-rc1
v3 submission can be found here:
http://www.spinics.net/lists/arm-kernel/msg156751.html
Changes since v3:
* Removed drivers/cpuidle/common.c
** Removed the initialization helper functions
** Removed the wrapper used to consolidate time keeping and irq enable/disable
* Add time keeping and local_irq_disable handling in cpuidle_call_idle().
* Made necessary modifications to a few platforms that required the most changes
** Note on omap3: changed structure of omap3_idle_drvdata and added
per_next_state and per_saved_state vars to accomodate new framework.
v2 submission can be found here:
http://comments.gmane.org/gmane.linux.ports.arm.kernel/144199
Changes since v2:
* Made various code organization and style changes as suggested in v1 review.
* Removed at91 use of common code. A separate effort is underway to clean
at91 code and the author has offered to convert to common interface as part
of those changes (if this common interface is accepted in time).
* Made platform cpuidle_driver objects __initdata and dynamically added one
persistent instance of this object in common code.
* Removed imx5 pm usage of gpc_dvfs clock as it is no longer needed after
being enabled during clock initialization.
* Re-organized patches.
v1 submission can be found here:
http://comments.gmane.org/gmane.linux.ports.arm.kernel/142791
Changes since v1:
* Common interface moved to drivers/cpuidle and made non arch-specific.
* Made various fixes and suggested additions to the common cpuidle
code from v1 review.
* Added callback for filling in driver_data field as needed.
* Modified the various platforms with these changes.
Robert Lee (4):
cpuidle: Add time keeping and irq enabling
ARM: omap: Remove cpuidle timekeeping and irq enable/disable
acpi: Remove cpuidle timekeeping and irq enable/disable
x86: Remove cpuidle timekeeping and irq enable/disable
arch/arm/mach-omap2/cpuidle34xx.c | 96 ++++++++----------
drivers/acpi/processor_idle.c | 203 ++++++++++++++++++++++---------------
drivers/cpuidle/cpuidle.c | 75 +++++++++++---
drivers/idle/intel_idle.c | 110 ++++++++++++++------
include/linux/cpuidle.h | 26 +++--
5 files changed, 317 insertions(+), 193 deletions(-)
Hi all,
The LAVA team is working on support for private jobs -- we already have
some support for private results, but if the log of the job that
produced the results is publicly visible, this isn't much privacy.
The model for result security is that a set of results can be:
- anonymous (anyone can see, anyone can write)
- public (anyone can see, only owning user or group can write)
- private (only owning user or group can see or write)
Each non-anonymous set of results is owned by a group or user. I think
this model is sufficiently flexible -- the only gap I can see is that
it's not possible to have a stream where a subset of the people who can
see it can submit results to it.
Clearly it makes sense to have the set of people who can see the
eventual results and see the job output be the same. Currently the
former group is encoded in the stream name of the submit_results action,
for example:
{
"command": "submit_results",
"parameters":
{
"server": "http://locallava/RPC2/",
"stream": "/private/personal/mwhudson/test/"
}
}
would place results in a stream called 'test' that only I can or
"stream": "/public/team/linaro/kernel/"
identifies a stream that anyone can see but only members of the linaro
group can put results in.
The scheduler *could* read out this parameter from the job json and
enforce the privacy rules based on this, but that seems a bit fragile
somehow. I think top level attribute in the json describing who can
see the job would make sense -- we can then make sure the stream name on
the submit_results matches this.
Does the /{public,private}/{personal,team}/{team-or-user-name} syntax
make sense to people? I think it's reasonably clear and nicely terse.
We should do as much validation at submit time as we can (rejecting jobs
that submit to streams that do not exist, for example).
Cheers,
mwh
On Thu, Feb 16, 2012 at 12:49:21PM +0530, Amit wrote:
> I am not able to install any packages related to linaro for example
> when I tried that below command
>
> sudo add-apt-repository ppa:linaro-maintainers/toolchain
> I am getting error like
> Error reading
> https://launchpad.net/api/1.0/~linaro-maintainers/+archive/toolchain:
> <urlopen error [Errno 111] Connection refused>
>
> But when I use a direct INTERNET connection without proxy its working
> fine.
The problem you're running into is that add-apt-repository is fetching a
GPG key from the Ubuntu keyserver, which is running on port 11371. You
can indeed punch a hold in the firewall, but you can also just issue
sudo gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 7BE1F97B
since this is a one-time operation -- once the key is set up
transferring packages is done over regular http.
--
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
Linaro.org: Open Source Software for ARM SoCs
Hi. I'm trying to track down the sources that made the U-Boot and
U-Boot SPL for the beagle 1201 release image:
http://releases.linaro.org/images/12.01/oneiric/nano/
sources.txt says that's this hwpack:
http://releases.linaro.org/12.01/ubuntu/oneiric-hwpacks/
but the manifest.txt there:
http://releases.linaro.org/12.01/ubuntu/oneiric-hwpacks/hwpack_linaro-omap3…
only says:
u-boot-tools=2011.06-3ubuntu1
and doesn't say where I should find this version of the package.
I guessed that it might be the u-boot package 2011.06-3ubuntu1 from
oneiric, but that does not seem to contain the SPL code, so I'm
guessing it's the wrong one. (Also U-Boot announces itself as
"U-Boot 2011.12 (Jan 22 2012 - 00:52:03)" so that manifest is
clearly a load of rubbish...)
Can anybody help?
thanks in advance
-- PMM
