Forwarding to the list as I hit reply rather than reply all.
Begin forwarded message:
> From: Jamie Bennett <jamie.bennett(a)linaro.org>
> Date: 25 June 2010 11:15:32 GMT+01:00
> To: JD Zheng <entropy.zjd(a)gmail.com>
> Subject: Re: [Linaro-dev] Contributing in development.
> On 24 Jun 2010, at 17:47, JD Zheng <entropy.zjd(a)gmail.com> wrote:
>> Guys join us @ #linaro on freenode irc for more interactive and useful hints.
>> Considering time difference and people has to work during the day, IRC isn't convenient. I'd like to see at least some summary in maillist. Anyway, this is just suggestion.
> We are a very transparent initiative and it's easy to find an area in which you are interested. The wiki page at https://wiki.linaro.org/Releases/ lists the work being concentrated on (blueprints) and what the goals of the next release, 10.11 are (technical requirements). Another page, https://wiki.linaro.org/EngineeringUnits/ details the various groups and their areas of interest. In fact the wiki is a great source of information. As mentioned before there is also irc, mailing lists and the website at www.linaro.org (and many of the team also have personal blogs).
> After looking at the above, if you need more direction, the please just ask.
We are designing some work based on our existing implementation of secure
computing on mobile devices but I wanted to get an idea what has been
planned by the base system designers regarding trustzone security feature
available to modern ARM architectures. Apart from trustzone trusted
computing features can still exist so not sure what is the progress on your
I have added some preliminary ideas on Linaro/Ubuntu lauchpad for trusted
computing as well but before actually taking it serious for full design
based on existing research and respectively possible implementation steps we
would like to confirm with you regarding any plans that I might not
contradict or possibly add synergy to them.
MeeGo security framework is a bit different than ours with respect to MAC as
we use SELinux and possibly Tomoyo as they can take care of complex and
simple scenarios respectively.
I'm posting this to see if anyone, especially from the Linaro
partners, sees a use for a universal ARM bringup image.
This small (<64MB ) flasheable image would contain an FDT enabled
boot loader and kernel. It would contain (at least) drivers for common
UARTs, network chips & USB devices.
This would allow a prototype board to be brought to the stage
where the standard Ubuntu USB installer image could be booted, without
the effort of a full boot loader & kernel port.
Only the device tree for the new platform would need to be
developed initially, allowing the full ports to be developed alongside
the initial debugging of the prototype platform.
Dnia czwartek, 24 czerwca 2010 o 07:37:47 Tarek El-Sherbiny napisał(a):
> The FriendlyARM is a cheep and powerful kit. It comes with LCD and all the
> other stuff. It is also Linux preloaded.
But it uses s3c2440 which is armv4t. Linaro concentrate on armv7 cpus.
And yes - FriendlyARM boards are nice and cheap way to get into embedded
In order to verify the images generated by Linaro, we'll have to start
the verification on real platforms. As of now, I am proposing that we
test on _atleast_ the boards in the following table. These boards were
chosen for their general availability to us inside Linaro, to
external developers and their cost. Also, I've only listed
SoC Board name Comments
TI OMAP3 Beagleboard C2, C3, C4 Very popular
TI OMAP3 Beagleboard XM 512Mb RAM, 37xx, limited
availability for now
i.MX51 Babbage2.5, Babbage3.0 Public availability to be checked
TI OMAP4 Panda Public availability 4Q?
Please feel free to suggest other boards that might help the community
get involved in testing, verification and development of Linaro. I
can't promise that we'll include all of them in our test setup, but
where possible we'll try to enable support for these boards (in the
kernel, for example) so that developers can use the pre-built images
with some modifications on their favourite boards.
One other factor we need to worry about is enablement of the platform
in the mainline kernel. Some boards such as the Freescale Babbage have
only the very basic HW support in mainline currently. So we will have
to enable enough of the platform in mainline to make it worthwhile
testing on that board.
 HW Availability is an ongoing problem and we're trying to do the
best with what we already have or will definitely have in the near
I just made available the first Linaro kernel merge result at the
[ The native Git protocol for cloning is not operational at the moment
so maybe announcing this now will increase pressure for having this
fixed more quickly. ]
The process we're experimenting at the moment for the production of this
kernel is described on this page:
Right now, this is a merge of:
- mainline 2.6.35-rc3
- Maverick Ubuntu-2.6.35-3.4
- RMK's ARM devel branch
- Catalin Marinas' ARM patches from
- and the kernel security features for ARM I've been working on lately
(stack protector, address space layout randomization)
There is no extra support for specific hardware target beyond what's
already included with the above. I expect this will change the next
time this tree is rebuilt (let me know if you have a tree that should be
considered for inclusion) but this initial announcement should at least
get the ball rolling.
Further improvements being considered:
- Include a file with details about what trees and versions were
included in the merge.
- Add references to each release with that info on a wiki page.
If you have any questions or comment please don't hesitate to ask me.
Matthias sent a review of the changes he had to do to the toolchain
packaging in Ubuntu to apply the Linaro diff we sent him, and reported
a list of testsuite results changes.
Instead of tracking this over email, I moved the results to
https://wiki.linaro.org/Toolchain/UbuntuRegressions and would like us
to track progress there. Ultimately, we should file bug reports but
the place where we file them differs depending on the action. Some
might be Linaro GCC bugs, some might be FSF GCC bugs, some might be
Ubuntu packaging bugs etc.
I did not finish to merge all feedback from CS folks in there, so it is
still incomplete; Andrew is currently fixing some of that -- thanks
A summary from this weeks kernel consolidation working group meeting
is now available.
It can be viewed online at the following link and is reproduced below.
A list of all meetings can be found at:
== Wed 16th June 2010 ==
=== Links ===
* [[WorkingGroups/KernelConsolidation/20100509| Previous meeting]]
* [[WorkingGroups/KernelConsolidation/20100623| Next meeting]]
=== Attendees ===
* Jamie Bennett ''(JamieBennett)''
* Jeremy Kerr ''(jk)''
* Amit Kucheria ''(amitk)''
* Loic Minier ''(lool)''
* Nicolas Pitre ''(npitre)''
* Matt Waddel ''(mattman)''
=== Agenda ===
* Action points from last meeting.
* Blueprint status.
||<rowbgcolor="#333333" rowstyle="color: white; font-weight:
bold;"style="text-align: center;">Blueprint ||<style="text-align:
|| Jeremy Kerr ||
|| Nicolas Pitre ||
|| Amit Kucheria ||
|| Dave Martin ||
|| Will Deacon ||
|| Grant Likely ||
|| Eric Miao ||
|| Matt Waddel ||
=== Action Points ===
* jk to send out call for help on ALSA device-tree work.
* lool will contact Will to discuss if this needs back porting.
* lool to talk to IS about getting clone support.
* npitre to briefly look into git configuration on IS behalf. lool
may need to investigate further if no answer can be found.
* npitre to add a text file to the git tree explaining where and what
has been merged into the consolidation kernel tree.
* npitre to produce a wiki page describing his git kernel tree and
the policies and procedures for merging.
* amitk to discuss the lack ARM comments so far with slangasek
* npitre to use the Linaro tool chain to see if the issue persists.
* lool to invite John Rigby to future kernel Work Group calls to
discuss the uboot and boot interface in general.
=== Action Points from Previous Meeting ===
* jk to put a basic template on devicetree.org to outline this.
* jk and jamiebennett to try to get participants to work on this.
* npitre to looking into producing a kernel module for testing the
kernel stack protector.
* amitk to expand the wiki to give more device information and send
out and email.
* davem to mail Catalin to discuss the flow of kernel patches from
ARM to Ubuntu/Linaro.
* jk to reignite discussion on the mailing lists.
=== Minutes ===
* jk put basic ALSA template up at http://devicetree.org/SoC_Audio,
* [ACTION] jk to send out call for help on ALSA device-tree work.
* amitk produced a list of hardware that is interesting to Linaro at
this moment in time:
* amitk was asked the status of imx51 upstream.
* He explained that everything that was rewritten from scratch is
now upstream. Base board, USB, i2c, serial, all there.
* Some 2.6.36 patches need back-porting to 2.6.35. amitk offered to
maintain a tree that npitre to pull from.
* jk explained that the device-tree spec had good discussion lately.
Most work is done and reviewers are only requesting small changes.
* jk needs to talk to npitre about the boot interface.
* nitre explained that Russell King is still waiting for a real
implementation before he is convinced it is the right way forward.
This is coming and has a lot of support.
* 2.6.36 could be a target for the device tree work if reviewers
comments are favorable, not entirely optimistic though.
* Will Deacon has sent patches for hardware break-point support to
the mailing list. npitre is in contact with Will about this.
* [ACTION] lool will contact Will to discuss if this needs back porting.
* npitre said that git.linaro.org cannot currently clone trees.
* [ACTION] lool to talk to IS about getting clone support.
* [ACTION] npitre to briefly look into git configuration on IS
behalf. lool may need to investigate further if no answer can be
* [ACTION] npitre to add a text file to the git tree explaining where
and what has been merged into the consolidation kernel tree.
* [ACTION] nitre to produce a wiki page describing his git kernel
tree and the policies and procedures for merging.
* amitk is waiting on ARM to spec out the kernel power management
features they care about so they can be added to the blueprint. lool
suggested that amitk should just continue on without the feedback for
now to get the review process started, folding in any future comments
* [ACTION] amitk to discuss the lack ARM comments so far with slangasek
* Most of the missing security features have already been implemented
by npitre. Some tool chain support is needed to support further work
on this spec. For example, everything needs to be compiled with
position independent code.
* npitre has asked for feedback from ARM on the security test he
produced that didn’t produce a result he expected. No response yet as
the main contact on this is absent. The tool chain nitre is using is
the Code Sourcery one. lool asked if npitre could use the official
Linaro tool chain just released.
* [ACTION] npitre to use the Linaro tool chain to see if the issue persists.
* amitk has a patch for his work items on the security spec. This
needs testing before sending to npitre.
* The state of uboot was discussed. The team agreed that in the
short-term one uboot per SoC would be desirable.
* [ACTION] lool to invite John Rigby to future kernel Work Group
calls to discuss the uboot and boot interface in general.
* jk explained that the ALSA blueprint should probably be considered
done now there is partial documentation available as there is little
interest from people who could actually do the work this cycle.
* mattman has produced a new blueprint:
Linaro Release Manager
I have some questions regarding upcoming Linaro event.
Can anyone explain goals of upcoming summit (19-23 July)? Wiki page
contains no goals ATM.
Will there be a possibility and any point/sense for 'external' projects
(e.g. kexecboot) and people to participate in summit?
Is there any possibility to have some sponsor help with travel expenses to
come to summit?
I'd like to discuss structure of the repositories we create on
git.linaro.org for interaction with upstreams using git (e.g. kernel
I think we should have two layouts:
- /$person/$project/$topic repos for personal repositories,
- /$project/$topic repos for canonical repositories, such as team repos
For instance, /jcrigby/u-boot/for-upstream.git or
What do you folks think?