linaro-dev March 2011

linaro-dev@lists.linaro.org

123 participants
172 discussions

Instructions for building Linaro GCC with crosstool-NG

by Michael Hope

I've written some short instructions on using crosstool-NG to build Linaro GCC: https://wiki.linaro.org/WorkingGroups/ToolChain/Using/CrosstoolNg Could someone review these for me please? Linaro GCC is already available in a bunch of places including OpenBricks, crosstool-NG, OpenEmbedded, OpenWRT, and (of course) Ubuntu. I hope to write a short page on each so people know where to find our toolchain in the distribution of their choice. -- Michael

13 years, 9 months

Notes & Actions: Linaro Graphics Working Group - Mar 02, 2011 and Mar 09, 2011

by Alexandros Frantzis

Hi, notes and actions from our Wednesday graphics working group call are available on the wiki: + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-03-02 + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-03-09 Details about when and where of this meeting can be found here: + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics#Weekly%20Public%2… === 2011-03-02 === * KDE/kwin * Patch "Integrate patch for gles and glsl-es version detection" pushed to upstream. * http://commits.kde.org/kde-workspace/125016902ae852dcd067a33bad08cdc25197c2… * Patch "Add GLES2 support to kcm_opengl" accepted by upstream. * http://commits.kde.org/kde-workspace/56ad38c97393a446b75dfb57fafdcd149419aa… * Patch "remove direct GL dependency in libplasma" accepted by upstream. * http://commits.kde.org/kdelibs/46b3025245ee6b22cfa8d2a898756f5c075d822e * cairo-gles2 * GL_CLAMP_TO_BORDER and 1D texture solutions now passing test suite (patch to be submitted this week). * Simple examples now able to run through cairo-gles in development tree (some changes not submission ready yet). * glcompbench: new enhancements made to facilitate test iteration and test framework integration. * DRI/Mali: git repositories setup for Xorg driver and kernel modules (kernel tree based to linux-linaro-2.6.38). === 2011-03-09 === * cairo-gles2 * GLES2 backend is officially working!!! * Testing in ARM targets is ongoing. * Once accepted upstream it will be made available in a PPA. * Patchset "Add GLESv2 support to the GL backend" sent upstream for review * http://lists.cairographics.org/archives/cairo/2011-March/021808.html * First round of reviews done and proposed changes have been implemented * Benchmarks * Updates to glmark2 and glcompbench based upon latest Efika images. * GLEW GLES2 work underway. * Working on list of topics for 11.11 Thanks, -- - Alexandros

13 years, 9 months

Making linaro-nano smaller or Give Up Disk Space for Lent

by Tom Gall

Hi All, In the developer platforms team we're working on getting the linaro-nano image so that it is considerably smaller. To date I've been using the approach I outlined last fall in a previous post to this list. Some highlights to nano: * The linaro-image boots just as our linaro-headless image did (upstart and friends) * it can be updated, or additional pkgs installed via apt-get * networking works * busybox is in use tho not necessarily universally * ureadahead, python, have been removed * docs have been removed * linux-firmware has been removed (binary kernel firmware blobs) * locales is remove Installed image is 125 Megs. (Down from 290 Meg) We're on the cusp of being able to fit into 128 megs of flash. This brings me to the subject of the kernel. hwpacks besides installing linux-firmware (32 Megs) but also approx 50 Megs in modules. Yet on my beagleboard lsmod notes Module Size Used by asix 12805 0 usbnet 17027 1 asix omap2_mcspi 8441 0 omap_wdt 4093 0 hid_apple 4999 0 twl4030_usb 4950 0 twl4030_pwrbutton 1298 0 gpio_keys 6072 0 leds_gpio 2198 0 usbhid 39072 0 hid 74787 2 hid_apple,usbhid Clearly we don't need all of these modules and I don't think it's an unreasonable change our policy to "build what's needed + some reasonable subset of function that our average user might neeed". I don't know why we're installed the firmware deb, does any of the hardware we're supporting even use that? >From the directories where modules are located there is the following size info: 812 ./crypto 7568 ./net 2456 ./sound 60 ./arch 28372 ./drivers 172 ./lib 272 ./ubuntu 8316 ./fs 48032 . Going deeper it's pretty easy to spot low hanging fruit: >From fs - Do we need afs, jfs, code, minix, hpfs, xfs, hfs, hfsplus, gfs2, reiserfs... I'm thinking no. >From drivers - net and media make about about 1/3rd of the 28 meg in use, I'm sure there's a number of drivers in here that can just be turned off. >From sound - ac97, are there arm boards that use that? >From net - x25, decnet, appletalk ? So that said, what is the best way to proceed? 1) Is there agreement that for all the kernels we supply that we should change the policy for kernel configs to not default to everything on? (Maybe we should be using the upstream config with minimal modifications?) Pro: everyone benefits from the diet Con: Our kernel would be build slightly different than ubuntu's others: 2) Linaro-media-create shouldn't install linux-firmware_1.47_all.deb ? Do we have any any hardware that needs it? If so could there be a --nano option to not install it? 3) linaro-media-create should have some kind of option (--nano) to clear out apt caches (saves ~40 meg of space) Specifically from the installed image after the hwpack deps are installed get rid of the following: rm -f ./var/lib/apt/lists/*Packages rm -f ./var/lib/apt/lists/*Sources rm -f ./var/lib/apt/lists/*Release rm -f ./var/lib/apt/lists/*Release.gpg rm -f ./var/cache/apt/pkgcache.bin rm -f ./var/cache/apt/srcpkgcache.bin Pro: if you never run apt* you won't mind the cold caches Con: if you're running out of nand and you're going to apt-get upgrade your system, you're probably going to run out of space (Probably a problem to solve in a future cycle) It's important through this exercise for people to speak up about what can and can NOT be safely turned off. Thanks for your time, attention, suggestions and feedback. Regards, Tom

13 years, 9 months

[NOTES] 2011-03-11 Engineering Resources weekly meeting

by Matt Waddel

Hi, The minutes from the Engineering Resources team meeting can be found here: https://wiki.linaro.org/Mentoring/Status/WeeklyMeeting/2011-03-11 Summary below. --Matt === Action Items from This Meeting === * AddNewHardware/HardwarePack pages need to explain kernel packages as Steve noted below * HardwarePacks page refers to Maverick instead of Natty * Mentoring section needs to be renamed and back links should be fixed * A better header for wiki that includes things like a "Resources" link in banner/header * Toolchain documentation improvement === Minutes === ==== Feedback from Steve L ==== * No super hot button issues with team * come up with clearer idea of what goes in hwpacks and policies around them * snag with v310 hwpack. needed u-boot not built by John R * missing linux-meta package in their hwpack. package name changes each time ABI is bumped. (Scott has had people confused by Meta-Packages) * Do we need new "types/names" of hwpacks for situations like this * Maybe ER team needs to add some to HWPACK documentation to mention these things. * Scott B - ask Andy Green for feedback on documentation changes * HardwarePacks page refers to Maverick. Should be Natty and probably say "CURRENT RELEASE" * documentation under mentoring. needs to be promoted * rename to how-to * put something on main page and list latest updates * suggestions for front page: * change the way the header looks so that people will actually start to notice it again. Put some main links in this new header * joey links: https://wiki.canonical.com/OEMServices https://wiki.linaro.org/LinaroHeader ==== Feedback from Scott B ==== * cross-compiler documentation is still confusing * break up page by 4.4/4.5 versions into 2 pages. and then versions. * we shouldn't even suggest 4.4. 4.5 is what should be used * explain why you do a add-apt-repository * Cross-development Environment for userspace. There's nothing. We don't have a good story on this. Steve says we're improving so not spend much time trying to explain ==== Feedback from Kiko ==== * echo steve's comments on hwpacks * (scott) naming convention for community/landing team to indicate what is supported ==== Discussion after leads ==== * RequirementsProcessHowto - should be per release for as things change * ProductRequirement is a little off. Its not needed * Joey to ask if 1111 release will just use TechnicalTopics or still do a TechnicalRequirements page

13 years, 9 months

A good skia [was: Re: [RFC] Linaro Toolchain for Android and NDK]

by Michael Hope

On Tue, Mar 1, 2011 at 4:32 AM, Jesse Barker <jesse.barker(a)linaro.org> wrote: > FWIW, skia certainly isn't android only and, at least for the purposes of > getting the validation side of things up and running, could be run on a > non-android build (Jammy is likely doing something like this for his work, > though not oriented at abrek at the moment). Of course, I could be > over-simplifying here ;-). I'd like to use Skia as a toolchain benchmark but the upstream seems a bit messy. I'm using this export: http://people.linaro.org/~michaelh/skia-0~svn788.tar.xz from http://code.google.com/p/skia/ which I then build and run using these rules: http://bazaar.launchpad.net/~linaro-toolchain-dev/cbuild/trunk/view/head:/l… The code.google version seems a bit broken. autoconf scripts are included but they don't work. The non-autoconf Makefile assumes Intel with SSE2. The Android Skia seems to be a fork from some time ago and uses build scripts that are tightly tied into the Android build system. What's the best version to use? I'd like to standardise across Linaro for benchmarking so that results can be compared across groups, or at least so we don't get confused. -- Michael

13 years, 9 months

storage liability test

by Per Forlin

Hi, I am looking for a test framework to verify liability of I/O storage. Most of the test tool I find focus on performance. I would like to run test that compares in-buffer and out-buffer, use different address and size alignment for in-buffer and out-buffer, runs tests simultaneously on multiple block devices, etc... The test can run on FS level or block level either way is fine. Any suggestions? /Per

13 years, 9 months

[REPORT] 2011-03-10 Validation team weekly report

by Jamie Bennett

Hi, The Validation team weekly report for 2011-03-10 is now available and can be found at: https://wiki.linaro.org/Platform/Validation/Status/2011-03-10 The report is also reproduced in full below. Regards, Jamie. -- Linaro Release Manager | Platform Project Manager -- * Period: (20110302-20110309) * PM: JamieBennett <jamie.bennett(a)linaro.org> * Past reports : https://wiki.linaro.org/Platform/Validation/Status * Burndown information : http://status.linaro.org/linaro-validation.html == Key Points for wider discussion == * A request for comments on the Debian Django packaging guide has been made. Please read and give comments on: http://wiki.debian.org/DjangoPackagingDraft. * Power Management tests are planned to be integrated into the test suite and visualisation tools. The best way to do this is under discussion and the team invites more comments. == Team Highlights == * The Django packaging guideline for Debian was produced and is available at http://wiki.debian.org/DjangoPackagingDraft. There are discussions ongoing on the debian-python mailing list for feedback. * A first (and second) release of the django-debian package was made for connecting django database settings to dbconfig-common. This is being used on the LAVA project for database integration. * Initial discussions have been made to integrate some of the work the Power Management Working Group is doing in to abrek (the test-suite framework) and launch-control (the test visualisation tool). The ability to automatically test and visualise the power consumption on boards will take the Validation team around 2-4 weeks to complete. * Work continues on LAVA with two new branches containing improvements done this week. * abrek gained the ability to save bundles at the end of a test run. == Upcoming Deliverables == * launch-control 0.3c2 deployed on validation.linaro.org == Risks / Issues == * '''HIGH IMPACT''': Zygmunt's Beagle Board C4 appears to have hardware issues (1 week). * '''HIGH IMPACT''': The validation scheduler Blueprint continues to lag behind with 37 work items to complete (none completed so far) - https://launchpad.net/lava/+spec/linaro-n-validation-scheduler (several weeks). Discussions are on going to find a way to unblock this project. == Miscellaneous == * Wiki pages of note this week: * http://wiki.debian.org/DjangoPackagingDraft

13 years, 9 months

ARM cross compiler backport available for Lucid and Maverick

by Marcin Juszkiewicz

I would like to announce new Linaro PPA available for all users of Ubuntu 10.04 Lucid and 10.10 Maverick releases: https://launchpad.net/~linaro-maintainers/+archive/toolchain What is inside? Packages with current (gcc-linaro 2011.01-1 based on 4.5.2 release) cross toolchain backported from Ubuntu 11.04 Natty. Please test them and report any problems. Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

13 years, 9 months

[REPORT] 2011-03-10 Developer Platform team weekly report

by Jamie Bennett

Hi, The Developer Platform team weekly report for 2011-03-10 is now available and can be found at: https://wiki.linaro.org/Platform/DevPlatform/Status/2011-03-10 The report is also reproduced in full below. Regards, Jamie. -- Linaro Release Manager | Platform Project Manager -- * Period: (20110303-20110309) * PM: JamieBennett <jamie.bennett(a)linaro.org> * Past reports : https://wiki.linaro.org/Platform/DevPlatform/Status * Burndown information : http://status.linaro.org/linaro-foundations.html == Key Points for wider discussion == * The process to produce and upstream ALIP cross-compile fixes is slow, what can we do to speed this up? * Multi-arch changes are still landing to the Ubuntu archive, lots of testing is needed here. * Panda display issues are now resolved so more testing of images on the Panda board is possible. * The Nano image needs to be slimmed down further. Tom has proposed some changes but others need to review and comment on them. == Team Highlights == * LTTng 0.245 has been ported to the linux-linaro-2.6.38 kernel. The changes are available at: http://git.linaro.org/gitweb?p=people/aviksil/linux-2.6-lttng-linaro.git;a=… * Work continues on parts of kdelibs with the GL dependency removed from libplasma and kdebase-window-manager updated. * After many investigations the Panda non-display issue (bug:728603) has a fix. A config option change will enable the display to work with a knock-on effect of other bugs such as bug:720055 also being resolved. * A thumb2 enabled kernel build has been turned on after work by both the Kernel Working Group and the Developer Platform team. * Linaro's smallest full image, Nano, got reduced in size to 125mb installed. Proposed changes to eventually get closer to the 64mb installed target are currently in discussion. * libjpeg-turbo got further work this week as lintian errors were fixed. * Several more packages have been fixed for cross-compilation in the Ubuntu archive. * dpkg support for multiarch library installation is in the Ubuntu archive but needs another upload due to changes in the planned dpkg database format. There has also been some patches submitted to apt for the major multiarch blocker bugs as the team continue towards a true multi-arch solution. * Cross toolchain packages got reuploaded to the archive fixing recent issues. == Upcoming Deliverables == * Beta Freeze 2011-03-24 * New build of Linaro Linux kernel * systemtap v1.3 + cherry-picked fixes * apt fixes to Ubuntu * New dpkg to Ubuntu that implements support for the final multi-arch library paths == Risks / Issues == * '''MEDIUM IMPACT''': Peter Pearce reports that bootstrapping & making cross-compile patches upstreamable are slowing the rate of package fixing. The (current) alip package list will not be complete for beta freeze. * '''LOW IMPACT''': All multiarch work is landing past feature-freeze. Requires exception approval from the Ubuntu and Linaro release teams. == Miscellaneous == * Wiki pages of note this week: * http://wiki.debian.org/DebianBootstrap * https://wiki.linaro.org/Chromiumos/ChromeosWm

13 years, 9 months

Re: Making linaro-nano smaller or Give Up Disk Space for Lent

by Tom Gall

On Thu, Mar 10, 2011 at 8:59 AM, Guillaume Leteller <guillaume.letellier(a)arm.com> wrote: > Hi > >> In the developer platforms team we're working on getting the >> linaro-nano image so that it is considerably smaller. > > Brilliant! > >> Some highlights to nano: >> * The linaro-image boots just as our linaro-headless image did >> (upstart and friends) >> * it can be updated, or additional pkgs installed via apt-get >> * networking works >> * busybox is in use tho not necessarily universally >> * ureadahead, python, have been removed >> * docs have been removed >> * linux-firmware has been removed (binary kernel firmware blobs) >> * locales is remove >> >> Installed image is 125 Megs. (Down from 290 Meg) We're on the cusp of >> being able to fit into 128 megs of flash. > > Isn't it quite big for a "Nano" image? It looks like a size for a > 'developer' version. > Do we know why it's so big? It's a process. I'd like to get down to 64 Meg but one step at a time, 128 Meg being a first step. I feel this is reasonable as both my Beagle C4 and Beagle Xm both have 256 Meg of NAND. > In comparison, ARM developed AEL/ALIP > (http://www.linux-arm.org/LinuxFilesystem/AELFileSystemPage) and we were > hoping to use Linaro's Nano image from now on. > The size of the AEL/ALIP minimal version (busybox, ssh) was only 25MB > (compressed - Cramfs). And the version with X11 and a desktop was 55MB. Indeed. > Those images are useful for development boards with 64MB of flash or when > using CPU models. Do you have some boards in mind that only have 64Meg of Flash? >> > 3) linaro-media-create should have some kind of option (--nano) to >> > clear out apt caches (saves ~40 meg of space) >> >> If you want this it should be an easy change to make. > > This looks good if it's an easy change. > > Does it address the problem with Modules and firmware? > Is it possible to get an image without Hwpacks? > > Regards, > > Guillaume Thanks for the info and feedback Guillaume. Regards, Tom

13 years, 9 months

← Newer
1
...
9
10
11
12
13
14
15
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev March 2011