linaro-dev

linaro-dev@lists.linaro.org

4332 discussions

by Jamie Bennett

Hi Oliver, Answers in-line below. On 8 Nov 2010, at 15:12, Oliver Grawert wrote: > hi, > > at UDS we discussed the possibility of using linaro kernels for some > of > the ubuntu ARM flavours (currently for omap3 images but there might be > more to come) where we seem to have duplicated efforts in kernel team > and linaro ... > > there were some open questions that require further discussion with a > wider audience which i'd like to bring up in this mail: > > * linaro kernels used in ubuntu ARM would need to move to the > supported > package set (main) which makes them fall under all freeze restrictions > the kernel team sets for ubuntu (only SRUs post kernel freeze, patches > and changes all need to go through the ubuntu-kernel mailing list etc) I think we can deal with the via the SRU process. We have already been using the SRU process this cycle for kernel changes so its a non-issue. > * configuration changes in the linaro kernels would have to happen to > match the ubuntu distro kernel configs in all places where they do not > match yet (this also implies that ubuntu sauce needs to be added to > the > linaro kernels for making all distro features available) I'm not sure Linaro want to carry the Ubuntu sauce and match configs. Linaro's continued effort to consolidate and stream-line kernels rather than expand options to cover all eventualities may conflict, this would need to be carefully investigated. > * someone has to commit to do security support for these kernels to > match the 18 months security support we provide for ubuntu images (can > the ubuntu kernel team and the ubuntu security team commit to that ?) This would be a problem for Linaro. Currently we have no support options that look like what you describe above. The only option at the moment would be for the Ubuntu Security Team to provide security support for the kernels once they come out of Linaro unless Linaro change their model. > if not all of the above bulletpoints (please shout if i missed any > that > are obvious) can be fulfulled we can not take linaro kernels for our > images and another solution needs to be found. I would love to see the sharing of kernels here. We need to come up with a good solution of which I don't have at the moment. I've cc'd linaro-dev in to solicit more comments from the Linaro side. > ciao > oli Regards, Jamie.

14 years, 1 month

Re: QT4 and atomics

by Marcin Juszkiewicz

Dnia niedziela, 14 listopada 2010 o 23:26:46 Michael Hope napisał(a): > Hi there. I've been looking into updating the QT4 atomic operations > as an alternative to working around it in GCC. There's ARM specific > code in: > There are bigger problems here though: > * There's code in corelib/arch/armv6/qatomic*.c that may also being used > * qatomic_armv6.h includes code for RVCT which should be updated for > Thumb-2 by someone > * The code may not work on multi-processor systems like Panda due to > the lack of DMB instructions This is also tracked in https://bugs.launchpad.net/ubuntu/+source/qt4- x11/+bug/490371 Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

14 years, 1 month

QT4 and atomics

by Michael Hope

Hi there. I've been looking into updating the QT4 atomic operations as an alternative to working around it in GCC. There's ARM specific code in: http://qt.gitorious.org/qt/qt/blobs/4.7/src/corelib/arch/qatomic_armv6.h that should be updated to include IT instructions so that it can compile in Thumb-2 mode. There are bigger problems here though: * There's code in corelib/arch/armv6/qatomic*.c that may also being used * qatomic_armv6.h includes code for RVCT which should be updated for Thumb-2 by someone * The code may not work on multi-processor systems like Panda due to the lack of DMB instructions The better fix would be to replace everything with __sync_* primitives similar to qatomic_avr32.h and require GCC 4.4 or higher. The same probably applies to glib. Thoughts? Any volunteers? It's mildly outside the Toolchain WG's mandate. See also: https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/673085 -- Michael

14 years, 1 month

ST-Ericsson ux500 BSP contents

by Arnd Bergmann

I finally got to this and wrote up a summary of the contents of the ST-E BSP that we are mirroring on the Linaro git server: https://wiki.linaro.org/BSP/ST-Ericsson I did not write up my recommendations of how to proceed, but it should give an idea of the work in front of us/them. Linus, if you see any significant omissions or mistakes, please correct me. Arnd

14 years, 1 month

linaro-next tree

by Lorenzo Pieralisi

Hi Nicolas, I noticed that a merge of Grant's ARM DT patches stack into linaro-stable is on the cards and this is good news. I have a couple of questions on linaro-next though. I think it is supposed to track mainline closely, and on this I'd ask your thoughts please since it does not seem to be so at present. It could be nice for us to have a development kernel to base our work against in order to get the latest mainline goodness (and to have a current base to test/develop patches coming from different git dev trees that are not in the mainline yet), but still trying to consolidate code for future linaro stable releases. To sum it up, I am just asking you what are your plans for the linaro-next tree and the operating mode we should aim for. Thank you very much indeed. Cheers, Lorenzo

14 years, 1 month

Re: Teaching sbuild how to use xdeb

by Guilherme Salgado

I thought this would be a simple question about integrating xdeb with sbuild but as it turns out there are other things here that could benefit from being discussed with a bigger audience, so I'm CCing linaro-dev. On Wed, 2010-11-10 at 21:30 +0000, Wookey wrote: > +++ Guilherme Salgado [2010-11-10 17:49 -0200]: > > Hi Wookey, > > > > As I've mentioned on IRC, we want to have sbuild do cross builds using > > xdeb so that we can use it in > > <https://wiki.linaro.org/Platform/Infrastructure/Specs/PackageDevelopmentToo…>. > > Oh, that looks interesting. I'm very keen to have a cross-autobuilder > churning through things to find out how much stuff actually > cross-builds at the moment. > > In fact reading that work thing you seem to be wanting to build > exactly what I want to build: a system that repeatably builds > packages in pristine chroots. I thought sbuild didn't normally do the > pristine chroot thing? (which is why I've been using pbuilder to > supply that functionality to date). Yeah, I don't think sbuild itself provides that, so I'm using schroot's type=file chroots for that. You just point schroot to a tarball containing your chroot and it will (by default) create a new session (with a pristine chroot) every time you 'schroot -c <name>'. If you want to change the contents of the tarball you can easily do that with 'schroot -c <name>-source'. All you need for that to work is the following config: [natty] description=Natty chroot type=file file=/var/chroots/natty.tar location=/natty > > If you look at my (Still developing) cross-building spec: > https://wiki.linaro.org/Platform/Foundations/Specs/CrossBuilding > you'll see that I have very similar ideas, but I want to have tools to > do the various aspects of this job (satisfy-cross-deps, upload things, > download things, do build-ordering), rather than the unhelpfully > monolithic xdeb. It's certainly a good idea to have separate tools (or maybe even libraries?) for the various aspects, and although at first that didn't seem necessary to reach our goals in PackageDevelopmentTools, I think it's clearly becoming more important now as we find opportunities to collaborate. > > Do you realise that pdebuild-cross (in maverick) already makes a chroot to do > cross-building in with a single command: 'pdebuild-cross-create'? I didn't know about that; I'm still finding my way around all these tools for cross-building debs. :) > It installs a base system plus crosstoolchains > plus build-essential. (defaults to -aarmel). Currently there is just a > config for maverick, but we can add some more if we want to have natty > and natty+ppearses flavoured toolchains. That 'make me a cross-chroot' > stuff hides the bits you detail in "Notes on using sbuild+xdeb to do > cross compilation" on having to make sure source lines are put in and > cross-tools installed and so on. It's all done already :-) That sounds quite nice, and I'm all for not reinventing the wheel, so I'll have a look at pdebuild-cross. I just ran pdebuild-cross-create and that seems to create the chroot and tar it up, so even if we go with sbuild I should be able to use pdebuild-cross to create the chroots. > > That actually uses multistrap to do the hard work of setting up the > chroots with the right stuff. This is useful because debootstrap can't > take a base system from here and tool from there - everything has to > come from one place (although we could probably fix that). multistrap > has a neat cascading config scheme for making chroots so you can say > 'maverick + armel-cross-build + this-toolchain'. This is very handy in > the real world where the parts you need are not necessarily (yet) in > the distro. > > > After learning and experimenting a bit, this is what I came up with. I > > have some specific questions further down, but any feedback you might > > have is appreciated. > > I am nervous about sbuild+xdeb. It depends exactly what you are > trying to do, but xdeb's caching and recursive build behaviour, whilst > useful in some ways, also means that builds are not repeatable unless > you either go to special effort to clean things our or do the builds > in a disposable chroot. (pbuilder gives you the disposable thing for > free, at the expense of the time it takes to unpack and install deps > each time). I want a cross-builder to the same thing each time I ask > it to build a package. xdeb doesn't help at all with that as currently > designed. Ah, I see you want that too and propose schroot > snapshots+sessions. That's cool. I've used schroot a lot for managing > cross-build chroots in the past, but that was persistent ones, not > snapshotted pristine ones. You'll have to show me how that works. We > appear to agree completely on the principles of the thing :-) And I hope we can agree on the tools as well. The reason why I went with sbuild is because I was told it'd be more suitable for this job than pbuilder, and one thing I liked about it is that it's got most of its functionality packaged in a library (although it's written in perl) rather than a single tool. Is pbuilder like that as well? > > I still haven't worked out why everyone is so enamoured of xdeb, and > keep trying to design things round it. It has some useful features, I can't answer that, but I can speculate: - it does the job - most Linaro docs I've seen about cross building use it - we have in-house expertise on the tool - it's written in python > but it was designed as a bootstraping-from-local-sources tool, which > is not the same thing at all as a tool for cross-building individual > packages in a repository context. The clever bit of having heuristics > to supply deps is better dealt with by actually fixing the package > metadata, and for packages where that's not yet been done (arguably) That's what MultiArch is about, right? MultiArch seems to be our long-term plan, but in the meantime we have to use something else. That's where xdeb becomes useful, AIUI. > to just brute-force install everything native _and_ cross, which works > just fine and is much easier to understand. (it is slower though - I'm > not sure how much in practice, or how much it really matters). > > Why 'larc' BTW? This tool is expected to grow into something that will help developers manage .deb archives as well, so it was named Linaro Archive Creator. https://wiki.ubuntu.com/Specs/M/ARMDeveloperEnvironment has more details about what the tool should do. > > > We don't necessarily expect this functionality to be desirable upstream, in > > which case we'd need a plan to apply them at runtime so that we don't have to > > maintain a fork of sbuild. If you think the functionality may be wanted > > upstream, I'm sure we'll work together with them to figure out the best > > way to integrate it. Otherwise, following is one way we could approach it > > > > sbuild's build function (lib/Sbuild/Build.pm, part of libsbuild-perl) > > delegates the package building to dpkg-buildpackage and does a lot of sanity > > checks that we might not need or may not make sense for our use cases, so we > > could replace the whole function with a custom implementation which > > delegates the (cross-)building to xdeb. > > - Is that ok? > > - Should xdeb be used only for cross builds? > > - Is it possible to replace (monkey-patching or similar?) that > > function at runtime with our own implementation of it? (I realize > > this is more of a perl question, but I know close to nothing about > > perl) > > I have never looked at sbuild so have no idea what the right way to > do this is. Err, I thought you would know because Steve L. told me to talk to you if I wanted to discuss implementation details. Anyway, it's good that I did because otherwise we wouldn't have found this overlap in our work. > > > Also, sbuild uses a (configurable) dependency resolver to figure out what > > build deps to install, but AIUI xdeb handles that, so I'd change sbuild to > > skip that step completely (by using a new dependency resolver that does > > nothing). > > This is exactly the problem I have with trying to jam xdeb in for > these jobs. It's too high-level. We should have a cross-dep-resolving > tool that _just_ does that and make sbuild use it. (xapt is a > simple-minded one, xdeb contains an implementation of a cleverer one > but you can't use it on it's own). This would result in simple, > maintainable, tools that can be used in various contexts. xdeb seems to be factored into small functions already, so it should be easy to move that functionality into a library or a separate tool. I suspect it'd be the same for the rest of xdeb as well. > > > Are there any other steps currently performed by sbuild that can be > > avoided in our case? Or anything that I've overlooked? Or a better way > > of doing it? > > I think there is a better way, as largely elaborated above: give > sbuild a cross-dep resolver, use apt to install things of the > appropriate arch, passed through dpkg-cross if no multiarch version of > package available. And just issue dpkg-buildpackage -a<arch> > to do cross-builds. That sounds fine as well, and it's definitely more appealing given that we should be able to share at least parts of the new tools/libraries we develop. > > I could be wrong and there is a reason why all this won't fit > together, but I haven't seen one yet. > > > http://paste.ubuntu.com/529453/ is a diff against maverick's sbuild, > > along the lines of what I described above (although dirty and full of > > hard-coded bits). This diff allowed me to use sbuild to cross build > > expat for armel. > > We seem to be on very much the same page, which is great. Quite a lot > of what I've been putting in my spec is actually about how to > implement your spec properly, it seems. Both of us seem keen on the > 'use existing tools by sticking them together' where each tool does > one job well. I think if we fish out the cross-dep resolver and > installer logic into a separate tool then we can do all sorts of > things in a satisfying way. We also need cross-dep metadata in > packages for any tool to get it right. And if we had stage-build Do you mean to fish them both out of xdeb or do you see the installer logic coming from somewhere else? I could have a look at extracting them from xdeb, just to have an idea of how much work it'd involve. > metadata in packages then we could use xdeb's build-ordering logic to > bootstrap new flavours or even ports. Exactly how that works needs a > bit more thought, but it'd be good to keep it in mind. > > Does that all sounds reasonable to you? I'm trying to work out what the It does! > optimal path is and where to derive the code from because there is > strong pressure to do this quickly as well as properly :-) -- Guilherme Salgado <https://launchpad.net/~salgado>

14 years, 1 month

Notes & Actions: Linaro Graphics Working Group - Nov 08, 2010

by Alexandros Frantzis

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

14 years, 1 month

Notes & Actions: Linaro Multimedia Working Group - Nov 09, 2010

by Alexandros Frantzis

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

14 years, 1 month

Linaro Infrastructure Team Weekly Report (2010-11-05 to 2010-11-11)

by Ian Smith

All, The weekly report for the Linaro Infrastructure team may be found at:- Status report: https://wiki.linaro.org/Platform/Infrastructure/Status/2010-11-11 Burndown chart:http://people.canonical.com/~pitti/workitems/maverick/linaro-infrastr… The Infrastructure related blueprints, of which currently there are 4 active ones (4 from the last report), are showing that there are 8 work items in progress (11 last report), and 12 work items to undertake (12 last report). arm-m-validation-dashboard; 0 work items completed since last report; 2 in progress; 8 to do arm-m-image-building-console; 3 work items completed since last report; 4 in progress; 3 to do arm-m-automated-testing-framework; no change in status from last report; 1 in progress; 0 to do arm-m-testsuites-and-profilers; no change in status from last report; 1 in progress; 1 to do In arm-m-image-building-console, 4 items are awaiting review before they can be completed (6 last report). The focus for the team in the past week has remained on preparing Blueprints for the next cycle. Specifics accomplished this week include:- * A number of branches were landed this week, including branches for passwords, a bug for configurable team access, and configurable email notifications. * Produced a testplan for a headless version of the ISEE IGEP (Cortex A8) board. * Locally integrated JSON (JavaScript Object Notation) schema support Please let me know if you have any comments or questions. Kind Regards, ran Ian

14 years, 1 month

Fwd: Problems with BeagleBoard installation

by Michael Hope

(originally from Ira; she's having mail trouble for some reason) Hi, I am trying to install my new BeagleBoard xM. I started with https://wiki.linaro.org/Releases/DailyBuilds, but it failed to write to the SD card giving some errors about QEMU (I can try that again if the error messages are important). Dave Martin also gave me this link https://wiki.linaro.org/Source/ImageInstallation, but it doesn't exist anymore. So, I tried these instructions: https://wiki.linaro.org/Source/VexpressImageInstallation with http://snapshots.linaro.org/10.11-daily/linaro-headless/20101107/0/images/t… and http://jameswestby.net:8080/view/Hardware%20Packs/job/linaro-omap3%20hwpack/ (and --dev beagle). The installation of the SD card went ok, but the board doesn't work. During boot I see the printings as in the attached file and it doesn't go any further. I hope someone can help me with that, because otherwise I am at dead end... Thanks, Ira

14 years, 1 month

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev