Greetings,
I've just created linux-linaro-core-tracking branch in
git://git.linaro.org/kernel/linux-linaro-tracking.git.
It is based on mainline tip, and has all the Platform and Working Groups
topics which would appear in the next linux-linaro kernel release. No
topics from the Landing Teams there (this is what "core" implies). This
tree will be the basis for the next (12.05) linux-linaro kernel release.
So if you have a topic to be added to 12.05 you can ask me to add it
(the sooner you ask, the better), and it will appear in
linux-linaro-core-tracking first. The request to add a topic must
include the git tree location for me to pull the topic from, and the
base used by this topic (mainline, or another topic). If no base for the
topic is specified, the mainline is assumed. If needed, this is ok to
rebase the topic; this would be easier for me to handle than e.g.
reconfiguring my scripts to use topic-3.4rc5 branch instead of
topic-3.4rc4 branch used so far etc. Again, starting from now this tree
is open for the next release (12.05) topics.
The linux-linaro-core-tracking tree is first of all to identify the
conflicts early, so it could fail to build sometimes, or the kernel
built from it may not boot etc. The plan is to rebase this tree on the
current mainline tip daily. The topics causing the conflicts would be
excluded from the linux-linaro-core-tracking tree, and would be brought
back into it after the conflicts are resolved by the topic owners.
Thanks,
Andrey
Hi.
I have gotten a lot of help from you guys getting the PowerVR drivers up
and running with the 3.3 kernel on the Pandaboard ES. Problem now is
that all I tested then, was that X was running. After some more work, we
tried out EGL, and found out that this is not working.
The 3.3 kernel I'm using is revision
f8e851d03e884b60b5207f59a342da9cafdb415f from tilt-3.3 from the
ti-landing team. I'm using the PowerVR drivers in
http://ppa.launchpad.net/tiomap-dev/omap-trunk/ubuntu/pool/main/, that
is pvr-omap4_1.7.15.0.1.57 and pvr-omap4-dkms_1.7.15.0.1.54. I'm also
using the libdrm, libdri2 and xorg server from the same place, using the
versions from:
https://launchpad.net/~tiomap-dev/+archive/omap-trunk?field.series_filter=p…
Problem is, when trying to run something using EGL, I get the output from:
http://pastebin.com/e5deVmiD
Running it through gdb on the device, I see that it segfaults in
omap_bo_handle in /usr/lib/libdrm_omap.so.1
This file is compiled, using the patches listed in debian/patches/series
in the latest commit from git://gitorious.org/ubuntu-omap/libdrm.git,
and with configure arguments:
--enable-omap-experimental-api
--enable-udev
--enable-libkms
--disable-radeon
Any ideas on what might be wrong or what I can try? I have tried copying
the libdrm_omap binary from the ppa, as it looks like that might be at
fault, but no luck.
Best Regards
Martin Ertsas
While we're planning for connect, I'd like to suggest that we do away
with team tracks all together and just have topic tracks. This would
align with our topic based approach to things now, and would be a way
to breakdown our silo's. The topic track would be lead by a topic
champion. What do people think?
--
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hi,
Trying to get back to the proper way of scheduling and publishing what
will be covered by the Developer Platform team during the 12.05 cycle,
follows the blueprint description of what we're planning to work on
during this cycle.
Milestone link: https://launchpad.net/linaro-dev-platform/+milestone/12.05
The list is quite long, but most of the blueprints are basically
covering work that was supposed to get done during 12.04, that
unfortunately got blocked once LAVA got off-line.
Some interesting topics we'll cover this month:
* Common Ubuntu kernel config fragment across all kernel packages
used at the LEB
* Ubuntu sauce produced as a topic branch for Linux Linaro
* Cross toolchain updates based on 4.7 for Quantal
* Enablement test cases to be used with LAVA (usb-host-mode and others)
* Cross buildd and multi-arch fixes planning work that might come
with the ARMv8 effort
Hopefully this cycle we'll also be able to get the images in a better
shape sooner, trying to get the QA and Release team more involved with
our releases (to improve our image/builds quality).
Thanks!
--
Ricardo Salveti de Araujo
This patchset makes some cleanup on these cpuidle drivers
and consolidate the code across both architecture.
Tested on OMAP3 (igepV2).
Partially tested on OMAP4 (pandaboard), without offlining the cpu1.
V3 :
* replace OMAP4_NUM_STATES and OMAP3_NUM_STATES by ARRAY_SIZE
* Fixed changelog
* Fixed OMAP4_NUM_STATES going back and forth in the patchset
* Removed erratum check at init time
V2 :
* Fixed a couple of typos in the patch description
V1 : Initial Post
Daniel Lezcano (18):
ARM: OMAP4: cpuidle - Remove unused valid field
ARM: OMAP4: cpuidle - Declare the states with the driver declaration
ARM: OMAP4: cpuidle - Remove the cpuidle_params_table table
ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration
ARM: OMAP4: cpuidle - Initialize omap4_idle_data at compile time
ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly
ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot
time
ARM: OMAP3: cpuidle - remove rx51 cpuidle parameters table
ARM: OMAP3: define cpuidle statically
ARM: OMAP3: cpuidle - remove errata check in the init function
ARM: OMAP3: cpuidle - remove the 'valid' field
ARM: OMAP3: cpuidle - remove cpuidle_params_table
ARM: OMAP3: define statically the omap3_idle_data
ARM: OMAP3: cpuidle - use omap3_idle_data directly
ARM: OMAP3: cpuidle - simplify next_valid_state
ARM: OMAP3: set omap3_idle_data as static
ARM: OMAP3/4: consolidate cpuidle Makefile
ARM: OMAP3: cpuidle - set global variables static
arch/arm/mach-omap2/Makefile | 11 +-
arch/arm/mach-omap2/board-rx51.c | 38 +++---
arch/arm/mach-omap2/cpuidle34xx.c | 306 +++++++++++++++----------------------
arch/arm/mach-omap2/cpuidle44xx.c | 134 +++++++----------
arch/arm/mach-omap2/pm.h | 38 ++---
5 files changed, 212 insertions(+), 315 deletions(-)
--
1.7.5.4
Hi, Linas
Sorry, one thing I want to make sure is that you are using the android
images from https://android-build.linaro.org/?
Hi, All
If you have met such problems as below, please give your suggestion.
Thanks,
Yongqin Liu
---------- Forwarded message ----------
From: Linas Chang <shchang(a)marvell.com>
Date: 2 May 2012 15:46
Subject: RE: adb question
To: YongQin Liu <yongqin.liu(a)linaro.org>
Hi YongQin****
** **
I test more times , I found the case since be changed****
** **
I found device hard to get ip , so I install a dhcp server at my computer ,
and ethnet connect to snowboard directly****
** **
After device boot up , through your command “netcfg eth0 dhcp” ,I still
can’t obtain IP ****
** **
But I found strange thing , even console show up “dhcp time out” ,but the
log for dhcp server at my computer told me , it has assign a IP to
snowboard , even snowboard console show dhcp time out****
** **
At this case , I used fixed IP that same as my computer dhcp log said for
snow board , I could ping device form host , and adb look ok ,connect and
push also work****
** **
But I need to connect to my server to do further thing , so I can’t used
above method to fixed adb issue ,and if I connect to server I hard to know
which IP server assign to snow board****
** **
** **
So do you have any idea why dhcp server assign IP to snowboard , but
snowboard console still told me it can’t obtain IP from DHCP server****
** **
** **
** **
Linas****
** **
*From:* YongQin Liu [mailto:yongqin.liu@linaro.org]
*Sent:* Tuesday, April 24, 2012 11:54 AM
*To:* Linas Chang
*Subject:* Re: adb question****
** **
Hi, Linas****
On 24 April 2012 11:29, Linas Chang <shchang(a)marvell.com> wrote:****
Thanks for your help****
****
Currently , I could do the adb shell follow your instruction****
****
But I still can’t do adb push****
Could you paste your error information?****
>From this sentence, I think we can't see why it can't do the adb push
command.****
** **
And about the question below, I am sorry I can't give you any help.****
You can wait other members for help.****
** **
Thanks,****
Yongqin Liu ****
****
And I notice there are code dump during system boot up , I don’t build the
linux BSP and android , I used pre-build binary , the code dump as below****
****
Another question , I found your product spec said , snowboard need 5V power
, could you let me know which amp is device needed****
****
9.562652] ------------[ cut here ]------------****
[ 9.567291] WARNING: at
/mnt/jenkins/workspace/linaro-android_snowball-ics-gcc46-igloo-stable-blob-12.03-release/build/kernel/kernel/softirq.c:159
local_bh_enable_ip+0xa0/0xd4()****
[ 9.583129] Modules linked in: gator(O)****
[ 9.586975] [<c001d8a0>] (unwind_backtrace+0x0/0x144) from [<c05d9e2c>]
(dump_stack+0x20/0x24)****
[ 9.595611] [<c05d9e2c>] (dump_stack+0x20/0x24) from [<c003378c>]
(warn_slowpath_common+0x5c/0x74)****
[ 9.604553] [<c003378c>] (warn_slowpath_common+0x5c/0x74) from
[<c00337d0>] (warn_slowpath_null+0x2c/0x34)****
[ 9.614227] [<c00337d0>] (warn_slowpath_null+0x2c/0x34) from
[<c003af64>] (local_bh_enable_ip+0xa0/0xd4)****
[ 9.623687] [<c003af64>] (local_bh_enable_ip+0xa0/0xd4) from
[<c05e1f58>] (_raw_spin_unlock_bh+0x48/0x4c)****
[ 9.633270] [<c05e1f58>] (_raw_spin_unlock_bh+0x48/0x4c) from
[<c040b61c>] (cg2900_hu_dequeue+0x7c/0x244)****
[ 9.642852] [<c040b61c>] (cg2900_hu_dequeue+0x7c/0x244) from
[<c040db10>] (cg2900_hci_uart_tx_wakeup+0x124/0x180)****
[ 9.653106] [<c040db10>] (cg2900_hci_uart_tx_wakeup+0x124/0x180) from
[<c040dbcc>] (hci_uart_tty_wakeup+0x60/0x7c)****
[ 9.663452] [<c040dbcc>] (hci_uart_tty_wakeup+0x60/0x7c) from
[<c028bd0c>] (tty_wakeup+0x60/0x6c)****
[ 9.672332] [<c028bd0c>] (tty_wakeup+0x60/0x6c) from [<c02a71a8>]
(uart_write_wakeup+0x28/0x30)****
[ 9.681030] [<c02a71a8>] (uart_write_wakeup+0x28/0x30) from [<c02aa1ac>]
(pl011_int+0x518/0x5b0)****
[ 9.689819] [<c02aa1ac>] (pl011_int+0x518/0x5b0) from [<c00946d4>]
(handle_irq_event_percpu+0x78/0x2e0)****
[ 9.699218] [<c00946d4>] (handle_irq_event_percpu+0x78/0x2e0) from
[<c0094988>] (handle_irq_event+0x4c/0x6c)****
[ 9.709045] [<c0094988>] (handle_irq_event+0x4c/0x6c) from [<c00978cc>]
(handle_fasteoi_irq+0xa8/0x168)****
[ 9.718444] [<c00978cc>] (handle_fasteoi_irq+0xa8/0x168) from
[<c0093e70>] (generic_handle_irq+0x3c/0x50)****
[ 9.728027] [<c0093e70>] (generic_handle_irq+0x3c/0x50) from
[<c0016058>] (handle_IRQ+0x5c/0xbc)****
[ 9.736816] [<c0016058>] (handle_IRQ+0x5c/0xbc) from [<c0008544>]
(gic_handle_irq+0x34/0xb8)****
[ 9.745239] [<c0008544>] (gic_handle_irq+0x34/0xb8) from [<c0014c80>]
(__irq_svc+0x40/0x70)****
[ 9.753601] Exception stack(0xed1d5d68 to 0xed1d5db0)****
[ 9.758636] 5d60: c090a880 00000000 ed1d5e6c c0029324
fffffffd 00000000****
[ 9.766815] 5d80: 00000000 ed1d5e6c 00000000 00000000 00000000 ed1d5dd4
c090a880 ed1d5db0****
[ 9.774993] 5da0: c005afa4 c0029324 20000013 ffffffff****
[ 9.780059] [<c0014c80>] (__irq_svc+0x40/0x70) from [<c0029324>]
(qos_delayed_cpufreq_notifier+0x0/0xb8)****
[ 9.789550] [<c0029324>] (qos_delayed_cpufreq_notifier+0x0/0xb8) from
[<c005b168>] (__srcu_notifier_call_chain+0x54/0x70)****
[ 9.800506] [<c005b168>] (__srcu_notifier_call_chain+0x54/0x70) from
[<c005b1ac>] (srcu_notifier_call_chain+0x28/0x30)****
[ 9.811187] [<c005b1ac>] (srcu_notifier_call_chain+0x28/0x30) from
[<c03cf124>] (cpufreq_notify_transition+0xc4/0x2dc)****
[ 9.821899] [<c03cf124>] (cpufreq_notify_transition+0xc4/0x2dc) from
[<c03d43a0>] (dbx500_cpufreq_target+0x9c/0x150)****
[ 9.832427] [<c03d43a0>] (dbx500_cpufreq_target+0x9c/0x150) from
[<c03ce29c>] (__cpufreq_driver_target+0x88/0xc4)****
[ 9.842681] [<c03ce29c>] (__cpufreq_driver_target+0x88/0xc4) from
[<c03d29b8>] (do_dbs_timer+0x498/0x4b0)****
[ 9.852264] [<c03d29b8>] (do_dbs_timer+0x498/0x4b0) from [<c004f170>]
(process_one_work+0x138/0x4ac)****
[ 9.861389] [<c004f170>] (process_one_work+0x138/0x4ac) from
[<c004f88c>] (worker_thread+0x188/0x374)****
[ 9.870605] [<c004f88c>] (worker_thread+0x188/0x374) from [<c0054b64>]
(kthread+0x98/0xa4)****
[ 9.878875] [<c0054b64>] (kthread+0x98/0xa4) from [<c0016318>]
(kernel_thread_exit+0x0/0x8)****
[ 9.887237] ---[ end trace c0fe18d58f2dc323 ]---****
****
****
Linas****
****
*From:* YongQin Liu [mailto:yongqin.liu@linaro.org]
*Sent:* Monday, April 23, 2012 7:48 PM
*To:* Linas Chang
*Cc:* linaro-android(a)lists.linaro.org
*Subject:* Re: adb question****
****
Hi, Linas****
****
Maybe you can try following commands:****
****
----------------------------------------------------------------------------------------------
****
netcfg eth0 dhcp #get your eth network up****
ifconfig eth0 #get your board IP ****
echo 0>/sys/class/android_usb/android0/enable #enable adb via IP****
setprop service.adb.tcp.port 5555 #set the adb
connection port****
stop adbd # restart
adbd****
start adbd****
----------------------------------------------------------------------------------------------
****
****
If the above commands work for you, please let me know.****
I will update the wiki then.****
****
Thanks,****
Yongqin Liu****
****
On 23 April 2012 19:06, Linas Chang <shchang(a)marvell.com> wrote:****
Dear linaro-support team****
****
Currently , I used
linaro-android_snowball-ics-gcc46-igloo-stable-blob-12.03-release at your
snowboard****
****
I face a question , that is****
****
When I used adb , follow below command form your web-site****
****
- ADB only works over IP
In the console type:****
· stop adbd****
· setprop service.adb.tcp.port 6565****
· start adbd****
· ifconfig eth0 # to get boardsIP****
****
after my host connect to device****
, I try to used adb push –s <device IP>:6565 <my txt file> /data or adb –s
<device ip>:6565 shell form host****
Both fail ,and I didn’t see any error meaage , it look like hang after I
type above adb command****
****
Do you have any suggestion about this****
****
Thanks for your help****
****
Linas****
****
****
****
_______________________________________________
linaro-android mailing list
linaro-android(a)lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-android****
****
** **
Fathi,
Since we're at the start of 12.05 we need to shift the builds over to
the tip toolchain and stop daily builds for various baselines. I
figure we can also get the configs into git. Do you want to take care
of getting the current configs into git and then shift the builds or
the other way around?
For 12.05 I'd kill all dailies except for the tips listed on
android-build.linaro.org under:
"Users who are interested in tip builds with Linaro goodness should use:"
People can always re-enable dalies they're interested in.
--
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Postmortem and lessons learned for Linaro's release 2012.04
https://wiki.linaro.org/Cycles/1204/Release/Review
Highlights and Key Successes
============================
The Linaro 12.04 delivery included ARM Fast Models a platform which
assists programmers by giving them a virtual environment to develop
software for unreleased silicon.
The migration to Ubuntu 12.04 (Precise Pangolin) by the Ubuntu Developer
Platform team was delivered and built for armhf. Linaro U-boot is now
based on the upstream release v2012.04.1. Support for big.LITTLE integrated
switcher continues to be added to deliverables.
The Snowball board has been enabled with multimedia support by the
Android team. The team is also supporting big.LITTLE testing and
development.
Postmortem and Lessons Learned
==============================
The unavailability of the LAVA lab was a perpetual handicap throughout the
cycle. Consequences of the inaccessible lab include inconsistent testing of
the images, possible missed issues, and the reduced quantity and quality of
deliverables. Jenkins scripting has also been unstable for this cycle adding
to the unpredictability of the release.
However, even with these problems, the engineers pulled together and
exhibited some great teamwork and effort in order to release on time.
Particular acknowledgement goes to Fathi, Paul L., Abhishek, Botao,
Ricardo, Andy D., Deepti, and Georgy.
Some of the teams are dealing with staffing issues with the departures of
a few members, and new people coming on board. Some teams have
reduced resources.
An issue that some teams have drawn attention to is the opaqueness of the
TSC and roadmap process. Some roadmap processes are requested of
teams with little notice for delivery, and without good communication of
the deliverable.
Some lessons learned from the cycle are:
* Need a staging area with the same setup as production
* This would mitigate the risk of an essential build service like LAVA and
Jenkins going down
* Can be deployed to production, staging and personal environments.
* Validation server has a ton of data that is not duplicated in personal
environments. It is important to be able to work from a backup copy
* Blueprints should be updated on a weekly basis and given particular
attention at the beginning of the cycle.
* When IS issues happen, use the IS stakeholders: Joey, Danilo, Fathi.
Platform Blueprints
----------------------------
The number of blueprints that missed the cycle:
Android 22 out of 35
Developer Platform 12 out of 22
Infrastructure 5 out of 10
Lava 7 out of 11
Total: 46 out of 78
59% if blueprints scheduled for this cycle were not delivered.
* Not included is data from working groups and landing teams
Source: https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AjEaTwrvj1bidDFtQ…
--
David Zinman
Linaro Release Manager | Project Manager
Linaro.org | Open source software for ARM SoCs