linaro-dev June 2010

linaro-dev@lists.linaro.org

44 participants
30 discussions

by Loïc Minier

Hi folks 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 [1]: 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. Cheers, [1] 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 \ lp:~gcc-linaro-dev/gcc-linaro/4.4 but that doesn't help much since stuff still transits client-side -- Loïc Minier

14 years, 1 month

Re: [Linaro-dev] git.linaro.org repos structure

by Rodrigo Belem

I would like see git.linaro.org using gitorious. Em 11/06/2010 06:23, "Loïc Minier" <loic.minier(a)linaro.org>escreveu: Hi folks I'd like to discuss structure of the repositories we create on git.linaro.org for interaction with upstreams using git (e.g. kernel and u-boot). 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 /linaro-kernel/linux/arm-next.git. What do you folks think? Thanks! -- Loïc Minier _______________________________________________ Linaro-dev mailing list Linaro-dev(a)lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev

14 years, 1 month

[Linaro-dev] What about the middleware?

by Shaz

Dear all, 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) [1] standard's implementation. It is being consumed by Angstrom, debian like and other embedded OSes. FSO is based on the specifications of freedesktop.org [2] therefore I can't see a better middleware technology. Are there any better alternatives? [1] http://www.freesmartphone.org/ [2] http://wiki.freesmartphone.org/index.php/Main_Page -- Shaz

14 years, 1 month

[Linaro-dev] linaro build system (was Re: Availability of hardware for Linaro development?)

by JD Zheng

> > > > Would it not make more sense to simply standardize on a readily > > available toolchain such as CodeSourcery's Lite ARM toolchain? > > Excellent suggestion! :-) > > Hello, 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 directly. 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 :-) ). Thanks. Jiandong Zheng

14 years, 1 month

[Linaro-dev] Introducing kexecboot software

by Yuri Bushmelev

Hello! 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 optimize size. 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 support it * 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 removable media) * 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 telnet/ssh connection. 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 work). - Ben NanoNote (waiting for delivery, donated by CELF for MIPS support work); Links: * Current project home (down at this moment, we are looking for hosting): http://projects.linuxtogo.org/projects/kexecboot * Project git tree: http://git.linuxtogo.org/?p=groups/kexecboot/kexecboot.git * OpenEmbedded recipes: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/kexecboot -- Yuri Bushmelev

14 years, 1 month

[Linaro-dev] Test

by David Rusling

All, Please ignore this - I replied to an email this morning but didn't see it on the mailing list, just checking... Dave CTO, Linaro

14 years, 1 month

[Linaro-dev] Availability of hardware for Linaro development?

by Joel Crisp

Hi all 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. Thoughts? Thanks Joel -- The cyder is strong in this one Lord!

14 years, 1 month

Re: [Linaro-dev] Introducing kexecboot software

by Robert Schwebel

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 > LinuxToGo. Hmm, I think all you have to do is adding something like this to /etc/gitweb.conf: @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 |

14 years, 1 month

[Linaro-dev] Minutes from ARM kernel merge+packaging processes call 20100603

by Steve Langasek

Hi everyone, 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 <https://blueprints.launchpad.net/ubuntu-arm/+spec/arm-m-kernel-version-alig…>. Thanks, -- 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/ slangasek(a)ubuntu.com vorlon(a)debian.org == Attendees == * Leann Ogasawara * Steve Langasek * Andy Whitcroft * Nicolas Pitre * Amit Kucheria * Loïc Minier == Discussion == https://wiki.ubuntu.com/Specs/M/ARMKernelVersionAlignment 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 Goals: * 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 integration merge 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

14 years, 1 month

[Linaro-dev] self introduction

by Madhu

Hi All, 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. Regards, Madhu

14 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev June 2010