linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

by James Westby

[ resending with the correct address ] On Fri, 27 Aug 2010 14:03:32 -0400, James Westby <james.westby(a)canonical.com> wrote: > On Fri, 20 Aug 2010 16:26:46 -0400, James Westby <james.westby(a)linaro.org> wrote: > > There is also one larger question, which is that I disagree that we > > shouldn't provide anything that will go in a hardware pack in the linaro > > images. I think that having the images be useful by themselves has lots > > of benefits. > > > > - Being able to quickly spin up an image in QEMU makes for easier > > testing. > > - Requiring a hardware pack for every operation will make some things > > more tedious. > > - If everything in a hardware pack becomes more consolidated then > > hardware packs probably become less useful. > - Not having a flag day where suddenly our images aren't installable > and hwpack-install has to work well, and before that date we can't > test hwpack-install on the images we produce. > > Having not had anyone convince me that stripping our images is the right > thing to do I have carried on attempting to write the spec without > requiring this. There will be a few issues, such as ensuring that the > kernel we want is the one that boots, but we have that problem on hwpack > upgrades anyway, so it doesn't go away by stripping the images. > > I have > > https://wiki.linaro.org/Platform/UserPlatforms/Specs/10.11/HardwarePacks > > to a state where I am happy to start implementation now. Feedback on the > spec is still welcome, and things will still be subject to change. In > particular there are still a number of TODOs in the spec where I don't > know how to proceed, but I believe that none of those block us starting > implementation of other parts. > > Is the current status quo to create specs under the "linaro" project on > Launchpad? I'll create a spec for this so that we can track work items > for it. > > Thanks, > > James >

15 years

Notes & Actions: Linaro graphics/multimedia - Sep 13, 2010

by Alexandros Frantzis

Hi, notes and actions from our Monday graphics and multimedia cross-vendor call are available on the wiki: + https://wiki.linaro.org/Platform/UserPlatforms/2010-09-13 Details about when and where of this meeting can be found here: + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics#Weekly%20Public%2… Thanks, -- - Alexandros

15 years

Upcoming release coordination

by Michael Hope

Hi there. We all have the November release coming up. Even though the different groups have different release cycles, it would be nice to do a coordinated release in November that shows off the work we've all been doing. As part of that I want to make sure the toolchain outputs play well together with the outputs from other groups. At least we need a QEMU (toolchain), kernel, and test head (user platforms) that work well together. A GDB and kernel combination with interrupted syscall and hardware watchpoint support would be good as well. Benchmark numbers up in the dashboard too. Past that it would be nice to have a common 'Linaro' PPA where you can get the latest of everything, including cross compilers, QEMU, and similar on the host side, and also compilers, libraries, power management tools, and similar on the device side. I know we have the overlay PPA but it focuses on stability and is for the test head only. Even past that it would be nice to have easy to consume examples as well such as: * A demo showing a cross compiled OpenGL app, run on a device due to a good kernel, showing better numbers due to driver and compiler improvements, and profiled using valgrind and oprofile * A package with startup scripts, QEMU, kernel, and test head all ready to run * The same but with the latest versions of all packages from all groups already installed * The same but installed as part of a Ubuntu Maverick VMWare image to give a very low barrier to entry, and to let Windows users try things out I normally overdo these things so feel free to bring me back down to earth. I'm going to at least talk with Loic and Alexander about the QEMU/Kernel/Test head combo. -- Michael

15 years

Eclipse Wiki Page

by Tom Gall

Hi All, I've started a Eclipse page https://wiki.linaro.org/Eclipse/Evaluation It's mostly meant as a place to collect Eclipse information which perhaps might drive some future blueprints. It's mostly skeleton at this point so feel free to add to it. Regards, Tom User Platforms

15 years

Linaro Foundations Team Weekly Report (2010-09-02 to 2010-09-08)

by Steve Langasek

The weekly report for the Linaro Foundations team may be found at: Status report: https://wiki.linaro.org/Platform/Foundations/2010-09-08 Overall status: https://wiki.linaro.org/Releases/FoundationsStatus Work continues on bugfixing for the 10.11 release, as well as some spec work not affecting the archive. The burndown chart at http://people.canonical.com/~pitti/workitems/maverick/linaro-foundations.ht… shows that we are on target to complete remaining engineering work for the 10.11 release. Actions: * slangasek to follow up on bug #623478 for sponsorship * npitre to give jcrigby feedback on devicetree u-boot patches * slangasek to post DebConf 10 gobby notes publically * slangasek to nudge Keybuk to review bootchart changes rather than redirecting to upstream, since Ubuntu and upstream are quite out of sync * jcrigby, dmart to follow up on getting linux-tools to build in linaro kernel package Cheers, -- 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

15 years

omap3 startup memory map

by Peter Maydell

Hi. I have a question about what the memory map of the TI OMAP3 (35xx) looks like on startup, which I'm hoping somebody here can answer. (Steve, Richard: you're on the CC: because Loic suggested that you would be good people to ask.) I'm currently looking at a bug in qemu: https://bugs.launchpad.net/qemu-maemo/+bug/628471 where we hang on bootup. That happens because the qemu implementation of NAND attached to the omap GPMC doesn't try to map anything into the memory space (it only does this for NOR devices). >From reading the OMAP35xx TRM I believe that when a NAND device is mapped into GPMC space (by setting GPMC_CONFIG7_i appropriately) then reads and writes to any address in the mapped region behave like accesses to GPMC_NAND_DATA_i. I have a patch which implements this mapping for NAND devices; however this causes a conflict about what should be mapped at address zero on startup, because: (a) at reset GPMC_CONFIG7_i is 0xf40 for CS0 and 0xf00 for CS1..7, which maps CS0 to address 0. (On the Beagle board this is NAND.) (b) qemu also wants to map the boot ROM in at address 0 The TRM isn't terribly clear (to me :-)) about what happens at address zero on startup (it talks about a "1MB boot space" but doesn't say what this is or what address it is at or when it stops being in effect...) It's also possible that qemu is wrong about mapping boot rom related things at address zero; we are emulating much of what the hardware's boot ROM does rather than actually executing it. However I would expect that there ought to be some real RAM/ROM there for the reset/exception vectors if nothing else... So can anybody tell me what happens on real hardware? Thanks in advance -- Peter Maydell

15 years, 1 month

Experimental clutter packages with rectangle texture API

by Alexandros Frantzis

Hi all! I have released an experimental package of clutter that includes two additional patches (relatively to the maverick package): 1. debian/patches/remove_cogl_gl_types.patch: This patch removes all references to GL types and defines from the cogl and headers and additionally removes GL headers from cogl-defines.h. The reason for this patch is to ease cross-building of GLES2 clutter apps against libclutter-1.0-dev (instead of requiring libclutter-eglx-es20-1.0-dev). It also makes sense for Cogl (which is supposed to be an abstraction layer) to *not* force any particular GL header inclusion. The side effect of this patch is that applications that need to directly use GL functions, types etc must explicitly include the GL headers of their choice instead of relying on clutter to do this for them. This, of course, breaks some applications (clutk, mutter, gnome-shell to name a few) but the fix is trivial (just a correct GL header inclusion in the application itself). 2. debian/patches/rectangle-texture.patch: This patch exports an API for explicitly creating rectangle textures. It uses code backported from the 1.3 branch plus some additions needed to produce a complete API (eg clutter_texture_rectangle_new_from_file()). The purpose of this patch is to provide a GL-version-independent way for applications to use rectangle textures. This will make applications (eg mutter) GL agnostic and therefore make them more easy to package and use with different GL(ES) versions. Note that upstream is planning on following this approach and explicitly exporting API to create specific texture types. Hopefully, they will implement this soon :) For a simple test of this package (and especially the rectangle texture API) you can use the Cogl Basics example *with* the attached patch. The Cogl Basics examples is at: http://wiki.clutter-project.org/wiki/Cogl/CoglBasicsExample The packaging branch is at: lp:~linaro-user-platforms/ubuntu/maverick/clutter-1.0/clutter-1.0-texture-rectangle and packages are in: https://launchpad.net/~afrantzis/+archive/clutter-1.2 My next steps are to start patching clutk, mutter etc so that: a. They build. b. They make use of the rectangle texture API where needed. Any comments, feedback etc more than welcome :) Thanks, Alexandros

15 years, 1 month

I/O errors on NAND on beagle rev C3

by Loïc Minier

Hi folks I've had problem upgrading my beagleboard C3 for a while; today, I reflashed kernel and initrd, got problems loading the initrd I had written but not the kernel. Upon boot, I could see the MTDs again (in the past I couldn't anymore due to a missing config), but flash-kernel gives only I/O errors. Is anybody else seeing I/O errors to NAND with a beagleboard rev C and Linaro OMAP kernels? 2.6.35-1003-linaro-omap is what I have here I wonder whether it's the hardware being dead, or a kernel bug Thanks -- Loïc Minier

15 years, 1 month

Notes from Landing Teams call 2010/09/10

by Loïc Minier

Hi Notes from today's Landing Teams call; also at https://wiki.linaro.org/LandingTeams/Meetings/2010-09-10 Cheers === Attendees === * Loïc Minier * Torez Smith * Matt Waddel * Scott Bambrough === Agenda === * Action items from last meeting. * Achievements / progress reports * OMAP3 * Versatile Express * Meetings next weeks === Action Items === * Loïc to check what to do with broken boards * Torez to ask Mounir to add the IGEP board to Internal/Hardware wiki page * Matt to list known bugs link on Boards/Vexpress * Matt to request jcrigby to build the mouse driver in the kernel and to file a bug to track the other issue === Action Items from Previous Meeting === * Loïc to find a replacement XM for Torez * Loïc to check what to do with broken boards * Torez to add boards to Internal/Hardware wiki page === Minutes === * Action items from last meeting. * Loïc to find a replacement XM for Torez . DONE we have a spare but Stephen expects IBM to provide hardware RSN; if that does not happen, he will ship one * Loïc to check what to do with broken boards . CARRYOVER chatting with TI to decide * Torez to add boards to Internal/Hardware wiki page . CARRYOVER Torez to ask Mounir to do it * Achievements / progress reports * OMAP3 * LP #618734 - Added a patch and reassigned to jcrigby - fixes config to get ethernet working; also tested on XM, no regression * LP #619206 - libertas-firmware missing - not sure how to test wifi? * Should apt-get install wireless-tools wpasupplicant libertas-firmware * Also need to enable multiverse * LP #622429 - ethernet shows up as usb0 - oddly, IGEP as a random address, but is named eth0; investigating * LP #633338 - no LCD on IGEP - should be high prio; expects to attack it soon * Versatile Express * flash-kernel now working! yeah `\o/` * Validated kernels from Hudson * Found that framebuffer issue is known bug and you got a huge diff with the fix somewhere in it; looking into that * Will link to list of known bugs from Boards/Vexpress . ACTION Matt to list known bugs link on Boards/Vexpress * Mouse stopped working; seems to be since it moved as a module; in general, this seems to be a genuine bug, but building the driver in the kernel is probably the best workaround in the short term . ACTION Matt to request jcrigby to build the mouse driver in the kernel and to file a bug to track the other issue * Similar issue also affects Torez on IGEP's eth0 * Meetings next weeks * Loïc travelling * Matt leading the calls * Next Monday cancelled, not sure about the next one * Scott offering to lead the Monday in 10 days, but away next week * Torez proposes joining the KCWG meetings, and she's welcome to! -- Loïc Minier

15 years, 1 month

Notes from Kernel Consolidation WG call 2010/09/06

by Loïc Minier

Hi folks I failed horribly at sending out emails with the notes of Kernel Consolidation WG calls in the last weeks, sorry about that. (They were pushed to the wiki though.) Please find the notes from this week's call below, as well as activity reports of people in the WG; also at: https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Meetings/2010-09-… Cheers, == Notes from call == === Attendees === * Loïc Minier * Arnd Bergmann * Dave Martin * Shajul Abraham * Jeremy Kerr * Nicolas Pitre * Grant Likely === Agenda === * Action items from last meeting. * Progress update. * Blueprint status. === Action Items === * Richard to talk to Michael Hope about runtime library opts * Richard to check with Gokul about posting his slides from the Sprint plenary * Richard to compile wiki page on the state of the OMAP4 BSPs next trees * Dave to review i.MX51 BSP * John to update DT u-boot patches * Loïc to work on kernel build infrastructure * Arnd to look into DT support for ARM boards - combined support in a single kernel with only device trees differing to support different ARM boards * Nicolas to finish SECCOMP support * Arnd to send patches to fix all io.h copies * Nico to send feedback to jk on the DT ARM patches * Matt to test Lorenzo's vexpress tree after asking Lorenzo for a sample config * Arnd to document BSP review on [[BSP/STE]] or so * Nicolas to start a wiki page on recommendations for BSP authors === Action Items from Previous Meeting === * Loïc to check with Richard what's going on about these: * Richard to talk to Michael Hope about runtime library opts * Richard to check with Gokul about posting his slides from the Sprint plenary * Richard to compile wiki page on the state of the OMAP4 BSPs next trees * Dave to review i.MX51 BSP * John to update DT u-boot patches * Loïc to work on kernel build infrastructure * Arnd to look into DT support for ARM boards - combined support in a single kernel with only device trees differing to support different ARM boards * Loïc to pass Vexpress board to Arnd * Loïc to poke amitk and other stakeholders and defer remaining things for next cycle on security features blueprint * Arnd to send patches to fix all io.h copies * Nico to send feedback to jk on the DT ARM patches this week * Matt to test Lorenzo's vexpress tree after asking Lorenzo for a sample config * Loïc to send out his notes on release process * Matt to file bugs and try the ARM kernel for both bugs === Minutes === * Loïc to check with Richard what's going on about these: . DONE * Richard to talk to Michael Hope about runtime library opts * Richard to check with Gokul about posting his slides from the Sprint plenary * Richard to compile wiki page on the state of the OMAP4 BSPs next trees * Dave to review i.MX51 BSP . INPROGRESS Dave started reviewing the BSP; needs to write a wiki page from it * Based on 2.6.31 * Tried applying diff from .31 to .32 * Has this huge 10 MB patch as a single commit when the kernel is moved to a new version; not clear how to move this forward * Covers much more than i.mx51 * Arnd started reviewing the ST-E BSP; the upstream version of the kernel is a bit weird, mixup of .34 and .29; saw many warnings * Discussed with Linus Walleij who said this branch is dead, but only used for current products * About 10 times more code in the BSP than upstream * Contains random other stuff which is not part of their tree * ST-Ericsson will continue porting this tree to 2.6.35 internally, Arnd thinks that .36 would be a better target * Makes direct recommendation to Linus, but it's specific to their BSP . ACTION Arnd to document BSP review on [[BSP/STE]] or so . ACTION Nicolas to start a wiki page on recommendations for BSP authors * John to update DT u-boot patches . CO * Loïc to work on kernel build infrastructure . INPROGRESSS switched to Hudson (hudson-ci.org) and got a multi-way u-boot build going; worked fine and intends to deploy, mostly needs configs to go with the kernels now :-) * Frederick started looking at the problems of configs and config policies, and will be sending mail + wiki page to linaro-dev@; Nicolas can review and comment * Arnd to look into DT support for ARM boards - combined support in a single kernel with only device trees differing to support different ARM boards . CO * Loïc to pass Vexpress board to Arnd . DONE * Loïc to poke amitk and other stakeholders and defer remaining things for next cycle on security features blueprint . DONE only SECCOMP remains, Nicolas has it all in his head :-) . ACTION Nicolas to finish SECCOMP support * Arnd to send patches to fix all io.h copies . INPROGRESS thrown the old patches away and is working on a new version of the patches now; mostly fixing the code to use the correct pointer type all over the place, without awful casts; trying to fix code to use iomemory pointers * Nico to send feedback to jk on the DT ARM patches this week . INPROGRESS, Nicolas writing amendments to the patches and about to send them to Jeremy and Grant * Matt to test Lorenzo's vexpress tree after asking Lorenzo for a sample config . CO * Loïc to send out his notes on release process . DONE * Matt to file bugs and try the ARM kernel for both bugs . DONE * Arnd to file bug on SD card alignment . DONE * Arnd bought an Android tablet PC and looked at the kernel sources; this is for very old cores from Asian manufacturers * Arnd also worked a bit on BKL removal * Nicolas started work on the gdb vector page bug; patch he sent wasn't sufficient, since gdb is using /proc/*/mem as well; trying to fix this nicely * Shajul trying to boot devicetree on ST-E platform with an embedded platform; only has memory and cmdline in the devicetree and working on the clock * Dave has been mostly working on non-kernel stuff this week, such as building stuff with -Os * Jeremy worked on debug macros, rebasing them on a newer kernel; Russell requested a different strategy on merging them, should be ok for the beginning of the merge window * Jeremy will be away for about 3 weeks at the beginning of October * Jeremy thinks we should consider merging the common clock framework now, since discussion seems to have quieten down; should go via Russell's tree, his initial work to start with * Grant works on random platform-specific stuff, and notably OMAP; Grant is syncing with Richard on this work * Grant is also working on a lot of tools, compilers etc. for FPGA platforms notably == Activity reports == === Shaju Abraham === * Work on device tree support for V210 is progressing * Tested common clock API for the V210; works * Making a small DTS file for the V210 to test DeviceTree part === Matt Waddel === ==== this week ==== * validated new vexpress headless images * found bug in u-boot causing initrd problems * found problem with flash mtd mounting (thx lool and scottb) * several changes to linaro-media-create script for vexpress * closed outstanding linaro-media-create bugs assigned to me * qatracker deploy instructions * re-formated u-boot patches - will submit tomorrow ==== next week ==== * US holiday * push u-boot changes before merge window opens * bug fixing on vexpress - memory issue, initrd on command line * flash-kernel implementation * try Lorenzo's vexpress arm device-tree * Start mmc u-boot device driver === Arnd Bergmann === * debugged Versatile PCI with Peter Maydell * started review of ST-Ericsson BSP * mmio cleanup in arm tree * investigated Telechips BSP ==== Non-Linaro but noteworthy ==== * Open vSwitch discussion * cleanup of TTY layer * debugging of BKL removal fallout === Dave Martin === ==== arm-m-memory-footprint ==== * Ongoing discussion with upstream. ==== arm-m-debugging-with-oprofile ==== * See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/608775 for detail on current status (still waiting for feedback from upstream developer for final patch) ==== Kernel ==== ===== arm-m-missing-security-features ===== * kees still working on SECCOMP support; ===== miscellaneous ===== * Investigation of Freescale bsp mostly done -- need to write up. * Retested omap3 / vexpress release candidates; reported some issues. * Tested amit's NEON conditional NEON en-/dis-ablement workaround for i.MX51. * UDS travel now booked ==== Plans ==== * Summarise -Os results * Test the linaro stable kernel tree on OMAP3/Beagle -- see whether the omapfb problems are now fixed. * Test omap/vexpress beta release candidates when they've been respun. * Follow up with jcrigby on how to enable building of a fixed linux-tools package for linaro. === John Rigby === ==== Kernel Packaging ==== * Put the ST-E kernel in its own tree on git.linaro.org and added packaging. * Got feedback on linux-linaro kernel, it needs to recommend uboot-mkimage. * Proposed two possible ways of doing per-flavour sources to Tim Gardner. He said they would probably work but said he didn't like the idea. ==== U-Boot ==== * Did a new U-Boot DevTree patch submission. No feedback yet. * Discussed unified U-Boot via email with Loic and Steve Sakoman. Steve is pretty skeptical. ==== Other ==== * Helped with testing release. First rc was bad because it had old kernel. ==== Next Week ==== * First monthly kernel build is due Wednesday. === Paul McKenney === ==== RCU Priority Boosting ==== * Implemented and tested RCU priority boosting changes to the rcutorture test suite. * The testing experience highlighted a hole in the design, which I am fixing. (I will need to priority-boost the RCU softirq, which will mean converting it to a kthread -- easy change.) * Started coding TINY_PREEMPT_RCU's priority boosting. ==== ARM Hardware ==== * Worked with IBM India to straighten out the process for receiving ARM development boards (they were applying processes appropriate for $1M servers to $200 development boards). * Received a Sheeva Plug, have not yet had time to play with it. === Nicolas Pitre === * Merged some fixes for ARM profiling and for the OMAP framebuffer in the linaro 2.6.35 stable kernel tree * Handling of patches for i.MX51 and CONFIG_NEON * Review of the DT patchset from gcl's git tree. Some style issues only so far. * Tested patch for bug 620611: turned out to be insufficient. investigation for a proper fix has led me deep down in the generic mm code. * Some minor progress on the SECCOMP patch. * Misc (meeting attendance, mailing list monitoring, etc.) -- Loïc Minier

15 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev