I created a gcc-linaro project and a ~gcc-linaro-dev team (Julian,
Andrew, and myself right now).
I grabbed Vincent's recent imports of FSF gcc 4.4 and 4.5 branches
(lp:~vila/gcc/4.4 and lp:~vila/gcc/4.5) and pushed the latest tagged
release in each :
bzr push -r tag:gcc_4_4_4_release lp:~gcc-linaro-dev/gcc-linaro/4.4
bzr push -r tag:gcc_4_5_0_release lp:~gcc-linaro-dev/gcc-linaro/4.5
Performance of bzr is a bit inconvenient, I think I'll check with the
bazaar team to see if there's something we can tune on our side or
something they could fix on their side to help this.
I've setup gcc-linaro 4.4 and 4.5 series too so that one can checkout
lp:gcc-linaro/4.4 and lp:gcc-linaro/4.5.
 and then I discovered I didn't even need the local copies:
bzr branch -r tag:gcc_4_4_4_release lp:~vila/gcc/4.4 \
but that doesn't help much since stuff still transits client-side
I would like see git.linaro.org using gitorious.
Em 11/06/2010 06:23, "Loïc Minier" <loic.minier(a)linaro.org>escreveu:
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?
Linaro-dev mailing list
No one has yet discussed the middleware. Am I on the wrong list?
I have been working on a number of middlewares and dbus is the defacto
standard for all. I see a lot of work going on the FreeSmartPhone.Org
(FSO)  standard's implementation. It is being consumed by Angstrom,
debian like and other embedded OSes.
FSO is based on the specifications of freedesktop.org  therefore I
can't see a better middleware technology. Are there any better
> > Would it not make more sense to simply standardize on a readily
> > available toolchain such as CodeSourcery's Lite ARM toolchain?
> Excellent suggestion! :-)
I just subscribed to this maillist and am very interested in build system
setup for linaro as a long time embedded developer (half of my time on UI
system and half on BSP/distribution) and of course most on ARM :-)
I certainly suggest CodeSourcery toolchain too!
But build system is more than just gcc, binutil and libc and in
distributions, it is often bound to package system, and tools to create a
clean chroot to install dependencies automatically.
Some tools like scratchbox basically "pretend" the cross compiling to be
native to avoid/minimize special patches for cross compiling (we can't
guarantee code from upstream are always cross compiling friendly).
OBS(Opensuse Build System) does native compiling through QEMU and it also
can be used similar to scratchbox, i.e., native compiling using cross gcc,
native(x86)bash/perl/python to speed up the build.
I think Debian/Ubuntu and most other dist are similar to OBS too, while
traditional embedded linux doesn't have pkg system and using cross compiling
So my question is what will be the default build system, which, I guess, is
part of deliveries? Since linaro is not a distribution, will it be
dist-agnostic? (Don't get me wrong as I am a Debian/Ubuntu fan :-) ).
I wish to introduce kexecboot software here. It would be great to see
kexecboot in list of Linaro supported projects.
Feel free to contact me about this software by email or on irc.freenode.net,
#kexecboot channel. My nickname is Jay7.
Kexecboot is a C program able to scan the partitions on available devices,
offering a graphical framebuffer menu and allowing user to select from which
one to boot. Specifically, kexecboot creates the command line for kexec.
Typically kexecboot resides together with kexec in a small initramfs,
embedded in a custom-tailored kernel compiled with support for initramfs and
kexec system call. Both binaries are built static, linked against klibc to
Flashed on NAND and launched as first kernel by the original bootloader,
this solution gives following advantages:
* multi machine support: we build for many architectures using OpenEmbedded
(tested on arm and x86/x86_64)
* zImage and uImage support
* easy customization: just add machine-specific workarounds (see Zaurus raw
read of bootparams from NAND)
* small size: complete linux-kexecboot_2.6.x image (initramfs + kernel) is
about 1Mb (less with lzma patches)
* easy boot choice: boot from SD/CF/NAND/... even if bootloader doesn't
* multiple fs detection: we support many filesystems e.g. ext2/3/4, jffs2,
reiserfs, vfat and more (ubifs is work in progress)
* kernel upgrade: no need to flash the device (kernel is in /boot of
* rapid testing: different distributions can live in separate partitions on
the same device
Thus, kexecboot is an interesting solution for embedded linux distributions,
which can just rely on kexecboot whithout having to consider what the real
bootloader can and cannot do.
About customization, initially the program has been developed for Sharp
Zaurus PDA (armv5te). For the machines of that family there is specific code
reading bootparams directly from NAND, circumventing the obsolete bootloader
which is incompatible with modern 2.6.x kernels.
We are sponsored by CELF in this year to do following work:
1.Write user's and developer's guides.
2.Extend architecture and filesystems support. MIPS arch support and UBIFS
support will be added.
3.Improve debugging ability. We should allow users to have ability to look
for debugging information without special hardware (serial cable e.g.).
4.Implement text-mode UI. We have already patches against one of old
releases. This can be used later to use kexecboot UI over serial line or
5.Improve GUI. Make GUI more clean and eye-candy (fonts and icons).
6.Add ability to use multiple kernels on same partition. Current
implementation allows only one kernel per partition.
List of accessible hardware:
- Sharp Zaurus'es: C860, C1000, C3200, SL-5500, SL-6000;
- TouchBook (waiting for order, donated by CELF for this device support
- Ben NanoNote (waiting for delivery, donated by CELF for MIPS support
* Current project home (down at this moment, we are looking for hosting):
* Project git tree:
* OpenEmbedded recipes:
Given the intention of Linaro seems to be improved Linux support for new and
upcoming hardware, how would an individual dev who might be wanting to
contribute acquire suitable hardware? Is there any hardware being targeted
which is currently on the market (e.g. BeagleBoard type systems)? Or are
emulators the intended development platform?
I have previous experience in embedded systems work and was the original
author of the SPCA50x driver for Linux USB webcams. I have also worked on
vxWorks ports and embedded JVM technology but I currently have a full time
job I'm not planning on leaving (Greencard application) and would have to be
a hobbyist contributor - it isn't clear if the Linaro project has scope for
such due to the hardware issue. This I see as the main differentiation
between the Ubuntu development and Linaro.
The cyder is strong in this one Lord!
On Fri, Jun 04, 2010 at 02:47:35PM +0400, Yuri Bushmelev wrote:
> > What's the checkout address of the git tree? Can you update the gitweb
> > to contain that information?
> Ah, sorry. You can checkout it by following command:
> git clone git://git.linuxtogo.org/home/groups/kexecboot/kexecboot.git
> Not sure about gitweb. I'm not familiar with it and seems it's property of
Hmm, I think all you have to do is adding something like this to
@git_base_url_list = ( 'git://git.pengutronix.de/git', 'http://git.pengutronix.de/git', '(developers only) ssh://git.pengutronix.de/git' );
Replace this by your own entries ;)
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Below are the notes from a conference call today for hashing out the details
of integrating Linaro's ARM kernel work into the Ubuntu Maverick development
cycle. I've extracted a couple of action items from the discussion that I
think need to be addressed soon to get us to the next level, but we didn't
identify owners for these during the call; please review these and confirm
that they look correct.
Nico, if there's consensus on these action items, we should capture them as
work items on the whiteboard in
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
== Attendees ==
* Leann Ogasawara
* Steve Langasek
* Andy Whitcroft
* Nicolas Pitre
* Amit Kucheria
* Loïc Minier
== Discussion ==
There were UDS discussions on patch handling and ARM maintenance, but while spec-ing we realized we needed a slighlty different process
ARM has a wide variety of SoCs, more than just CPUs
OMAP support is very different from Freescale etc.
Because we want to upstream patches and merge them in Ubuntu, it's best to have a tree with the OMAP patches both for upstreaming and for merging in Ubuntu
"Merge owner" would merge all these ARM trees together regularly, but the resulting tree would be volatile
Ubuntu kernel would be merged into that tree as well
Would we maintain an arm branch and send pull requests regularly?
Not really, we would rather throw away old version of the patches and send new ones
This would be a bit like linux-next / arm-next
Idea is to distribute support of the various ARM platforms, and not have it in the Ubuntu kernel right away
Final merge would be done just before Ubuntu kernel is frozen
* trees are mergeable upstream or in Ubuntu, feature trees basically
* not one merge request towards Ubuntu per SoC, but a single merge request of everything ARM to Ubuntu
lool: I see the following issues:
* will that cause conflicts?
* will we get the same quality as a result of the e.g. monthly merges every month, or might that regress by surprise
Nicolas explains that merges would be very frequent, e.g. daily, not monthly.
Could push daily PPA builds for testing
Only the individual hardware owners can test the kernel on their hardware
What about kernel version skew between BSPs?
Would have to be a separate source package and would not be part of the
Which platforms would we track?
OMAP is the only mainlineable one right now
Dove might (according to Amit) or might not (according to nico) move to mainline soon, but is easy to mainline
Freescale was planning .34, might be a challenge to move to .35
We're trying to help resolve the blockers when people are trying to mainline patches
We expect to integrate TI OMAP4, Freescale, Samsung, ST/Ericsson
One idea is to have a linux-arm git tree with all the ARM stuff and the Ubuntu tree merged in; master branch would be the Ubuntu delta
Would start with current master branch; in the future might split things like intel specific bits or powerpc bits or whatever into separate trees
What about conflicts?
Depends on the conflict; if there's a large conflict, then that means we need a new topic tree
Would use a fixed list of trees which are mixed together daily in the same order
Would probably also need an ubuntu-arm packaging branch, for the arm specific packaging
How will we merge changelogs?
Cant get list of changes anymore due to the use of rebased/rebuilt from scratch trees
Package would carry the SHA1 of the tree it was built from
Would keep tags for reference purposes
Changelog would mention sha1 hashes of individual trees
Do we want a process for trees we can't merge?
Let's wait until we see this issue
Ubuntu kernel team would own ubuntu-maverick.git master obviously
Linaro would own the integration tree; the Ubuntu kernel team will pull specific versions for upload and tagging in the main maverick tree upon request
This guarantees we can reference them in the future for the package history
Packaging would be cooperative; not sure where the ARM packaging branch would live, nor who would maintain it
Do we run the risk of losing Ubuntu specific changes in ARM specific trees? e.g. CONFIG changes
Config validation is an issue, works well when the configs are in the same tree, but the config checker does not cover enough configs; kernel team is working on covering more configs
Every maintainer of a board should maintain the configs which are required for this or that board
Should that be done by the CONFIG system?
Hard to do because it depends on what gets merged?
* danger of defconfigs provided with the per-Soc branches diverging unchecked from the stock Ubuntu config
* mitigated by the Ubuntu kernel tree config checker, but this doesn't have full coverage of the config options yet
* defconfigs should be sorted upstream
* two-pronged solution; defconfigs need to be sorted upstream, but in the distro we need something viable in the short term
* identify the minimal set of config settings that need to be set for an SoC and append these to the standard Ubuntu config?
(Long discussion about handling of defconfigs upstream)
* Need to be merging everything in a single kernel tree to make sure this continues to work
* But building all the kernel images from a single source package is too slow: we need separate source packages per ARM kernel flavor to be able to build them in parallel on the buildds
* could use a single tree and post-process the packaging to filter which set of packages are built
* Steve doesn't like this approach and would like to keep one branch per source package for the ARM packaging bits, to avoid autogenerated source packages; these branches then can individually be merged with the main ARM integration branch
== Actions ==
* nico to be the daily arm-next merge monkey :-)
* nico to provide a proof-of-concept merge tree for apw to review and provide input on
* apw to act as distro contact for packaging / integration issues of ARM trees
* Ubuntu kernel team to provide glue to generate the changelog entries for the ARM merge on top of the current Ubuntu changelog, taking information about the sha1 of each merged branch from the git commits of the integration branch
* Linaro SoC tree owners to identify the minimum set of SoC-specific options that are required, to append these to the bottom of the Ubuntu config
I am Madhu, recently joined the list. I am excited about the Linaro
project. I am working as Linux embedded engineer for ARM platform. I am
looking forward to contribute in this project.