Re: Plan for changing the binary toolchain to 4.7 and hardfloat
Michael, me too.Can you talk to Steve McKintyre and Konstantinos about this? We've spent the last 12 months trying to get alignment / agreement across all of the distributions on this.arm-linux-gnueabihf is the least worst, agreed option. Dave On 19 Mar 2012, at 08:48, Konstantinos Margaritis wrote: > On Sun, 18 Mar 2012 23:27:17 + > Mans Rullgard wrote: >> FWIW, Gentoo has been using arm-hardfloat-linux-gnueabi for hardfloat >> configurations ever since gcc started supporting it. That's of course >> not a triplet, strictly speaking. > > Also fwiw, I have been assured from Gentoo developers that they will change > their triplet to arm-linux-gnueabihf as soon as upstream adopts it. > > I find the situation sad as well, since Linaro has been pushing for this > triplet (at least the OCTO team and me personally for more than a year), and > not having full support from within Linaro with regards to this matter is > quite depressing. And I have to say, especially one of the arguments (Windows > storage issue) should be irrelevant for a Linux problem. > > Regards > > Konstantinos > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: No group tracks at Connect
Hmmm.I prefer Kiko's topics, these can also be grouped under the TL's. Each time we've tried this, we've ended up with WG / team driven tracks as before... Dave On 18 Apr 2012, at 16:43, Zach Pfeffer wrote: > While we're planning for connect, I'd like to suggest that we do away > with team tracks all together and just have topic tracks. This would > align with our topic based approach to things now, and would be a way > to breakdown our silo's. The topic track would be lead by a topic > champion. What do people think? > > -- > Zach Pfeffer > Android Platform Team Lead, Linaro Platform Teams > Linaro.org | Open source software for ARM SoCs > Follow Linaro: http://www.facebook.com/pages/Linaro > http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: No group tracks at Connect
All,
thank you for a lively discussion.I think that there's some very
good ideas floating about. It's clear that we all care passionately about
make Linaro Connect as good as it can possibly be. Some comments:
[1] What is the problem that we're trying to solve? It is, in my view, is
trying to ensure that everyone important to each discussion is able to be there
so that the right decisions take place
I saw some clashes at the last event where meetings were empty or moved so that
the right people were there. I think that this was because we didn't look
across the booking 'silos' before the week itself
Linux kernel intersects most of our problem areas and that makes the kernel
experts a scarce resource and a critical path on scheduling
[2] It's a slice and dice problem with most things being group based.
I don't think that each WG needs to stay together for the morning (technical)
sessions, but they do for the afternoon hacking sessions (mostly)
Zach's point about avoiding silos is a good one
[3] We give the mandate to solve 'heavy lifting' problems to particular groups
The graphics WG is the right 'center of gravity' for UMM, for example
but the overlap between groups can be quite large (especially platforms which
is where the technologies come together)
[4] Kiko's suggestion was to group the sessions by topic (big.LITTLE) and area
(architecture) and Zach's suggestion was to have topic champion (continuous
integration).Practically, some of this is already happening, for example
with Amit pulling together all the big.LITTLE sessions (switcher and MP).
Here's my suggestion:
[1] Take Kiko's 'table' as the basis and transcribe it into the Connect
planning spreadsheets maintained by Arwen etc. That gives us {topic, area,
contents}
[2] Nominate and agree champions / engineering teams to own each topic (add two
columns {champion, team}. The champions could be the TL, they could be
nominated by them, they don't have to work in the team that 'owns' the topic.
[3] Have the champions own creating the sessions and ensuring that the right
people (key decision makers) are signed up. In effect, one of their roles is
to work across silos.
Let's leave aside how the summit tool could show a schedule by topic or whether
we'd have 'topic leader' shirts made for now.
I'm happy to own [1] and support [2] and [3].
Makes sense?
Dave
David Rusling, CTO
Linaro
Lockton House
Clarendon Rd
Cambridge
CB2 8FH
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: No group tracks at Connect
All,
I've created and shared the Connection Sessions spreadsheet, you can
find it here -
https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AnK-Uyci_D20dFlUX1ZOVm5LWDVudkxJM1B0aS1FWWc#gid=0.
Arwen is happy that that spreadsheet will be used for the session
planning. I've added some topics and champions, please contact me to arrange
more / discuss how best to organise things moving forward. If you want a
hint, see what Amit's done...
Dave
On 23 Apr 2012, at 16:47, David Rusling wrote:
> All,
> thank you for a lively discussion.I think that there's some very
> good ideas floating about. It's clear that we all care passionately about
> make Linaro Connect as good as it can possibly be. Some comments:
>
> [1] What is the problem that we're trying to solve? It is, in my view, is
> trying to ensure that everyone important to each discussion is able to be
> there so that the right decisions take place
> I saw some clashes at the last event where meetings were empty or moved so
> that the right people were there. I think that this was because we didn't
> look across the booking 'silos' before the week itself
> Linux kernel intersects most of our problem areas and that makes the kernel
> experts a scarce resource and a critical path on scheduling
>
> [2] It's a slice and dice problem with most things being group based.
> I don't think that each WG needs to stay together for the morning (technical)
> sessions, but they do for the afternoon hacking sessions (mostly)
> Zach's point about avoiding silos is a good one
>
> [3] We give the mandate to solve 'heavy lifting' problems to particular groups
> The graphics WG is the right 'center of gravity' for UMM, for example
> but the overlap between groups can be quite large (especially platforms which
> is where the technologies come together)
>
> [4] Kiko's suggestion was to group the sessions by topic (big.LITTLE) and
> area (architecture) and Zach's suggestion was to have topic champion
> (continuous integration).Practically, some of this is already happening,
> for example with Amit pulling together all the big.LITTLE sessions (switcher
> and MP).
>
> Here's my suggestion:
>
> [1] Take Kiko's 'table' as the basis and transcribe it into the Connect
> planning spreadsheets maintained by Arwen etc. That gives us {topic, area,
> contents}
> [2] Nominate and agree champions / engineering teams to own each topic (add
> two columns {champion, team}. The champions could be the TL, they could be
> nominated by them, they don't have to work in the team that 'owns' the topic.
> [3] Have the champions own creating the sessions and ensuring that the right
> people (key decision makers) are signed up. In effect, one of their roles
> is to work across silos.
>
> Let's leave aside how the summit tool could show a schedule by topic or
> whether we'd have 'topic leader' shirts made for now.
>
> I'm happy to own [1] and support [2] and [3].
>
> Makes sense?
>
> Dave
>
>
> David Rusling, CTO
>
> Linaro
> Lockton House
> Clarendon Rd
> Cambridge
> CB2 8FH
>
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
>
>
>
>
>
>
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: No group tracks at Connect
Champion arranges the meeting the session lead runs it, they can be the same person Dave Sent from my iPad On 24 Apr 2012, at 23:17, Deepak Saxena wrote: > On 24 April 2012 03:22, David Rusling wrote: >> All, >> I've created and shared the Connection Sessions spreadsheet, you can find it >> here >> - >> https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AnK-Uyci_D20dFlUX1ZOVm5LWDVudkxJM1B0aS1FWWc#gid=0. >> Arwen is happy that that spreadsheet will be used for the session >> planning. I've added some topics and champions, please contact me to >> arrange more / discuss how best to organise things moving forward. If you >> want a hint, see what Amit's done... > > What are the responsibilities of the champion vs those of the session lead? > > ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: No group tracks at Connect
See my earlier email. They can be different or the same it's up to you... Dave Sent from my iPad On 25 Apr 2012, at 05:50, Arwen Donaghey wrote: > All, > > My understanding was the session lead is not necessarily the champion. The > champion is the 'guru' or 'owner' of the topic, and the session lead is > exactly that… the session lead. There are a number of sessions covering > various areas of one topic potentially? Please do correct me if this is wrong. > > Regards, > -- > Arwen Donaghey > Events Manager > > T: +44 1223 TBC | M: +44 7791 279 521 > Suite 220 | The Quorum | Barnwell Road | Cambridge | CB2 8FH > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog > Registered Number: 07180318 | VAT Number: 990 0273 24 > > On 25 Apr 2012, at 03:11, Ricardo Salveti wrote: > >> On Tue, Apr 24, 2012 at 7:17 PM, Deepak Saxena wrote: >>> On 24 April 2012 03:22, David Rusling wrote: >>>> All, >>>> I've created and shared the Connection Sessions spreadsheet, you can find >>>> it >>>> here >>>> - >>>> https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AnK-Uyci_D20dFlUX1ZOVm5LWDVudkxJM1B0aS1FWWc#gid=0. >>>> Arwen is happy that that spreadsheet will be used for the session >>>> planning. I've added some topics and champions, please contact me to >>>> arrange more / discuss how best to organise things moving forward. If you >>>> want a hint, see what Amit's done... >>> >>> What are the responsibilities of the champion vs those of the session lead? >> >> Nothing, we're just creating some extra naming for the same things :-) >> Tiger, champion, all funny. >> >> Cheers, >> -- >> Ricardo Salveti de Araujo > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making ARM multiplatform kernels DT-only?
All, not to muddy the waters, but think about where we'd like to be in the future - able to build support for several platforms into one kernel. Device tree is one of the mechanisms to help achieve that as it helps us move away from code laboriously adding the same devices in per platform ways. OK, so who actually wants the same kernel to run on several platforms? I think that (a) anyone who wants to do testing and (b) anyone interesting in supporting enterprise computing. Frankly, none of the mobile boys care, they are happy doing what they do. If I put my commercial hat on, I care about ARMv7 and Cortex-A15 platforms. I care about Cortex-A9 platforms as that's what the Linaro members have today. That covers enterprise and networking. My view would be that we should move towards being able to build support for several platforms into a single kernel. The question becomes 'do we allow non-device tree platforms to be included in a single kernel?'.We could take a hard position and make device tree mandatory or a softer position and not rule out non-DT platforms. The answer to this depends on how clean the end result is and how much working around non-DT platforms has to happen. If it's a lot of work and the results are an ugly compromise, make single kernel device tree only... Dave -- David Rusling, CTO Linaro Lockton House Clarendon Rd Cambridge CB2 8FH Linaro.org<http://www.linaro.org/> │ Open source software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Raspbian's hard float benchmarks
That sounds similar to what Konstantinos found compiling with and without hard float ABI for ARMv7 architecture. Dave On 18/07/12 14:52, Wookey wrote: > +++ Michael Hope [2012-07-18 14:37 +1200]: >> The Raspbian project is a rebuild of Debian for the Raspberry Pi. >> adama did some benchmarks that show the improvement in going from >> ARMv4T with soft float to ARMv6 with hard float: >> http://www.memetic.org/raspbian-benchmarking-armel-vs-armhf/ >> >> The page says that there's a 4-10 % improvement on integer programs >> and up to 40 % on floating point programs. It's hard to tell the new >> instruction vs pipeline influence and if the baseline is soft float or >> softfp/VFP based. > > He said he used debian armel which is soft-float by default, but > packages can specify a softfp/vfp build if they wish (I don't know if > any do). The tests also don't say anything about controlling for the > version of gcc in use. Random binaries in debian armel could have been > built with an older gcc than the one used to build rasbian, depending > on how long ago they were last uploaded and exactly where he was > getting his packages from. > > So it's hard to know how much of the improvement is due to compiling > for v6 over v4t, soft-float vs vfp, armhf ABI vs armel ABI, and > possibly variation in gcc used. I suspect all of those are mixed in. > > Interesting nevertheless. > > Wookey > -- David Rusling, CTO Linaro Lockton House Clarendon Rd Cambridge CB2 8FH Linaro.org<http://www.linaro.org/> │ Open source software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Would you send me your hard float experiment results you presented in Budapest?
Zach, you'd need to use multiarch and have multiple installed libraries so that you could support both hard and soft float ABI. Does Android do anything different / interesting in its image / shared library loader(s)? Dave On 30 Aug 2011, at 17:24, Zach Pfeffer wrote: > Steve, > > I'd like you to meet Jim who did the initial hardfloat work. This > email contains the results that Jim produced. > > I believe that the conclusion was that skia and webkit may benefit, > but that such benefits would impose an undue burden on Android's > distribution model which tries to create libs that can run on as many > architectures as possible. > > -Zach > > > -- Forwarded message -- > From: Jim Huang > Date: 7 August 2011 18:01 > Subject: Re: Would you send me your hard float experiment results you > presented in Budapest? > To: Zach Pfeffer > > > 2011/8/7 Zach Pfeffer : >> Jim, >> >> Thanks. Would it be possible to post them by the end of the day? > > skia -> > >Switch from VFP back to fixed scalar based calculation > >Previous configuration enabled ARM VFP for scalar float, but VFP on >ARM11 is not as powerful as VFPv3 or NEON. > >Reference benchmark: >ItemFixed based VFP-based >--- - >Draw Canvas 58.37 fps 58.40 fps >Draw Circle 37.48 fps 22.93 fps >Draw Circle217.14 fps 18.31 fps >Draw Rect 17.62 fps 20.69 fps >Draw Arc24.79 fps 27.45 fps >Draw Image 19.08 fps 18.73 fps >Draw Text 29.22 fps 25.79 fps > > >> >> Also, have you sync'd up with Mike? He wants to negotiate on your contract. > > I sent mail to Mike already. I don't know how to proceed. > > Thanks, > -jserv > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Linaro-mm-sig] Memory Management Documentation effort
Benjamin, I was reading this when I saw Kiko's response, so he saved me some effort. Really good. It assumes that you understand the general memory allocator and other memory types, it might be an idea to sketch this out. More comments inline. Dave On Tue, 2011-09-06 at 19:40 -0300, Christian Robottom Reis wrote: > On Tue, Sep 06, 2011 at 02:13:38PM +0200, Benjamin Gaignard wrote: > > I'm writing documentation about CMA ( > > https://wiki.linaro.org/OfficeofCTO/MemoryManagement?action=AttachFile&do=view&target=CMA.pdf > > ) > > and DMA_Buf ( > > https://wiki.linaro.org/OfficeofCTO/MemoryManagement?action=AttachFile&do=view&target=DMA_Buffer.pdf > > ) > > > > The goal is to explain outside the Linaro community how CMA and DMA_Buf > > works. > > This is great work, thanks for putting it together, Benjamin. > +1 > Slide 3 of the CMA deck is a bit misleading when it starts by saying > "grabs memory on system boot", but it's otherwise a good summary. > Does it not grab it at system start up? > Does it make sense to cover what happens when unmoveable pages are > requested but there isn't enough memory available to allocate outside of > the CMA area? > Fits with my comment about how the whole memory allocator works, including CMA. > The DMA buffer slides still need some work to put them in context, as > it starts too low-level to help the reader get the big picture -- i.e. > what problem are we trying to solve? But I trust you're planning on > fleshing that out as you work on the slides. > Yes, should also cover IOMMU set up / tear down in future, no? > Can this be a lead-in to actually setting up an area in the wiki which > organizes the current status on the various MM-related threads underway? > I feel that now that we are putting together integration trees and > documentation it would be a good time to invest in making them easy to > find. I like this idea. Also, this would make a good whitepaper or a presentation / training at an event. Many thanks, Dave -- David Rusling, CTO Linaro Lockton House Clarendon Rd Cambridge CB2 8FH Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Fwd: Would you send me your hard float experiment results you presented in Budapest?
I'm a little confused. There's two comparisons to be made. The comparison between vfp enabled in all cases, comparing using the soft float ABI with using the hard float ABI means that you'll identify the effect of moving VFP registers in and out of integer registers to make function call (soft float ABI) versus using them directly (hard float ABI). The comparision of using VFP at all versus only using integer emulation of floating point is separate and different. Both have an effect, the effects manifest themselves differently. Dave On Wed, 2011-09-07 at 16:33 -0500, Rob Clark wrote: > On Fri, Sep 2, 2011 at 1:27 PM, Christian Robottom Reis > wrote: > > On Tue, Aug 30, 2011 at 11:24:59AM -0500, Zach Pfeffer wrote: > >> I'd like you to meet Jim who did the initial hardfloat work. This > >> email contains the results that Jim produced. > > > > Hmm, but the email seems to not actually contain a hard-float run. Or am > > I misreading what he means by Fixed vs VFP? > > > >> I believe that the conclusion was that skia and webkit may benefit, > >> but that such benefits would impose an undue burden on Android's > >> distribution model which tries to create libs that can run on as many > >> architectures as possible. > > > > You may be confusing things here. Hard-float is a pure software ABI > > change, and any platform which supports VFP can use it if you build it > > that way. However, since it is an ABI change it requires that hard-float > > libraries be available. > > > > What /would/ stop code from running on certain platforms is using > > NEON (it would exclude the Tegra2 and some existing Marvell v7s). But > > that doesn't seem to be in question here. > > Fwiw, VFP and NEON share same registers.. so as long as Tegra2 has > VFP, I think it could use hard-float. Are we supporting any armv7-a > that doesn't have at least VFP? > > Although I'm a bit lost on this topic, are we comparing > non-hard-float-but-vfp-enabled (ie. fp op's not falling back to sw) vs > hard-float? Or soft-float vs hard-float? > > BR, > -R > > >> -- Forwarded message -- > >> From: Jim Huang > >> Date: 7 August 2011 18:01 > >> Subject: Re: Would you send me your hard float experiment results you > >> presented in Budapest? > >> To: Zach Pfeffer > >> > >> > >> 2011/8/7 Zach Pfeffer : > >> > Jim, > >> > > >> > Thanks. Would it be possible to post them by the end of the day? > >> > >> skia -> > >> > >>Switch from VFP back to fixed scalar based calculation > >> > >>Previous configuration enabled ARM VFP for scalar float, but VFP on > >>ARM11 is not as powerful as VFPv3 or NEON. > >> > >>Reference benchmark: > >>ItemFixed based VFP-based > >>--- - > >>Draw Canvas 58.37 fps 58.40 fps > >>Draw Circle 37.48 fps 22.93 fps > >>Draw Circle217.14 fps 18.31 fps > >>Draw Rect 17.62 fps 20.69 fps > >>Draw Arc24.79 fps 27.45 fps > >>Draw Image 19.08 fps 18.73 fps > >>Draw Text 29.22 fps 25.79 fps > >> > >> > >> > > >> > Also, have you sync'd up with Mike? He wants to negotiate on your > >> > contract. > >> > >> I sent mail to Mike already. I don't know how to proceed. > >> > >> Thanks, > >> -jserv > > > > > > > >> _______ > >> linaro-dev mailing list > >> linaro-dev@lists.linaro.org > >> http://lists.linaro.org/mailman/listinfo/linaro-dev > > > > -- > > Christian Robottom Reis, Engineering VP > > Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 > > Linaro.org: Open Source Software for ARM SoCs > > > > ___ > > linaro-dev mailing list > > linaro-dev@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/linaro-dev > > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev -- David Rusling, CTO Linaro Lockton House Clarendon Rd Cambridge CB2 8FH Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Fwd: Would you send me your hard float experiment results you presented in Budapest?
Agreed, I'm only interested in hardfloat versus softfloat ABI... Dave On Wed, 2011-09-07 at 23:25 +0100, Mans Rullgard wrote: > On 7 September 2011 23:01, David Rusling wrote: > > I'm a little confused. There's two comparisons to be made. > > > > The comparison between vfp enabled in all cases, comparing using the > > soft float ABI with using the hard float ABI means that you'll identify > > the effect of moving VFP registers in and out of integer registers to > > make function call (soft float ABI) versus using them directly (hard > > float ABI). > > > > The comparision of using VFP at all versus only using integer emulation > > of floating point is separate and different. > > > > Both have an effect, the effects manifest themselves differently. > > I don't think we need to run any tests at all to know the outcome of > VFP (regardless of ABI) versus emulation. > > In addition to the above, a few applications have both floating-point > and fixed-point implementations of the same algorithms with a compile- > time choice of which is used. In these cases, a speed comparison is > of course of interest, although one must keep in mind that the output > is likely to be different, floating-point often having better accuracy. > -- David Rusling, CTO Linaro Lockton House Clarendon Rd Cambridge CB2 8FH Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro Boot up times.
CELF did a bunch of work around boot times, this might be useful - http://elinux.org/images/f/f7/RightApproachMinimalBootTimes.pdf Dave David Rusling, CTO Linaro Lockton House Clarendon Rd Cambridge CB2 8FH Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog On 12 Sep 2011, at 07:43, Fathi Boudra wrote: > Hi, > > On 12 September 2011 09:29, Sudhangathan B S wrote: >> I need to boot Linaro in very short time as my project has a constraint on >> energy. >> The normal linaro boot up time is 2 minutes and 15 seconds on my overo fire. >> I did a little startup tweaks and achieved 2:00 minutes. >> Is there a way to boot up Linaro in under 40 sec. ?? This could include >> increasing CPU speeds or more OS tweaks >> Has anybody worked on this(Linaro boot up times) so far..?? > > Could you give us more context on your results? > Which image are you using? > How do you measure the boot-up time (start/stop markers)? > > Developer Platform Team planned to investigate and improve the boot > speed of our Oneiric based images: > https://blueprints.launchpad.net/linaro-ubuntu/+spec/bootspeed-investigation-11.09 > > Cheers, > > Fathi > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ANN: New Wiki Theme
Hmm, I'm not sure what category TSC and OCTO comes under, but NOT Administrative! Dave On 16 Nov 2011, at 17:49, Joey STANFORD wrote: >> I've been thinking about compromises because the three pages don't >> really get linked to from anywhere else and thus become orphaned. I'm >> thinking about adding a new link to the table called "Administrative". >> This would link to a new page that would then enumerate these links as >> well as links to stuff like "Process". >> >> Thoughts? > > I like it. We need to run it through Steve T's framework filter to > make sure it doesn't break anything. I don't want us to expand out > the front page again to be a website. More content in this case > hampers discoverability . > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: big.LITTLE MP status week of Nov 19, 2012
Are we close to giving a big.LITTLE update to the TSC (both MP and IKS) on Wednesday? Dave On 23 Nov 2012, at 13:26, David Zinman wrote: > > https://wiki.linaro.org/projects/big.LITTLE.MP > > > big.LITTLE MP v12 has been built: > http://lists.linaro.org/pipermail/linaro-dev/2012-November/014490.html > > Roadmap Cards > == > http://cards.linaro.org/browse/CARD-190 > No change from last status > > QA > == > The paperwork for the TC2 board that has been stuck in customs in India and > it's release is hopefully imminent. This also coincides with some cleared > blockages for the QA team and the hardware coming on line in the lab. This > means our QA efforts can proceed much more efficiently. > > > Other efforts > > On big.LITTLE MP kernel branch Vincent has finally found and patched the root > cause of a bug in the scheduler that generates spurious wake up of idle CPU. > He has spent some time to discuss the fix for the inclusion of packing small > tasks patches in the master branch, and is preparing the next version of > packing small tasks but i would like to come with figures for real use case > like mp3. > > Mathieu is concentrating on benchmarking: being able to run same benchmark > with IKS MP and a15 to start comparing things. > > > -- > David Zinman, Project Manager > Linaro.org | Open source software for ARM SoCs > > > -- > David Zinman, Project Manager > Linaro.org | Open source software for ARM SoCs > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Deadline scheduler inclusion in linux-linaro?
Amit, an interesting proposal. I think that most of the LNG steering committee is on this alias, but just in case, I'm adding them to it... Dave Amit Kucheria 17 May 2013 10:15 Hi all,As part of our investigations into the Linux scheduler we'veinteracted with Juri Lelli at the University of Pisa (cc'ed) who ispart of a group that is working on a DEADLINE scheduler[1] forLinux[2].While we're coming at this from a power managment angle[3], I suspectthat LEG and LNG already have real-world usecases that would benefitfrom deadline scheduler found in other RTOSes.So I think it makes sense to merge Juri's tree into linux-linaro goingforward to allow easier experimentation. Does LEG and LNG have anyinterest in this at this point?Juri has expressed an interest in maintaining a current branch of thecode that could be merged into our monthly release. In return, realworld usecases will improve his chances of getting the code mergedinto mainline.Regards,Amit[1] http://retis.sssup.it/?q=node/35[2] https://lkml.org/lkml/2013/2/11/373[3] Mostly involving discussions at this point, no real engineeringeffort invested yet___linaro-dev mailing listlinaro-dev@lists.linaro.orghttp://lists.linaro.org/mailman/listinfo/linaro-dev -- David Rusling CTO Linaro Ltd e. david.rusl...@linaro.org w. http://www.linaro.org Linaro: The future of Linux on ARM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: OpenOCD
Welcome Zach, glad to have you around... Sent from yet another ARM powered mobile device On 20 Sep 2010, at 11:39, Zach Welch wrote: > Hi all, > > I was recently hired by CodeSourcery and have been assigned to Linaro > for the purpose of improving OpenOCD. > > Specifically, I will be adding new support for Cortex-A9 SMP, though I > may also make a few improvements to its handling of Cortex-A8 in the > process. If you have experience using OpenOCD in these contexts, let me > know if you have any specific requests for features or fixes, and I will > try to fold them into my plans. > > After this cross-posted introduction, I believe that most of my > correspondence will appear on the Toolchain mailing list, but I wanted > to make sure that everyone knows that they can find me there. > > Cheers, > -- > Zach Welch > CodeSourcery > zwe...@codesourcery.com > (650) 331-3385 x743 > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The summit and blueprints
Michael, I'm glad that I'm not the only confused one. Good description of the flow... Dave On 14 October 2010 08:23, Amit Kucheria wrote: > On 10 Oct 14, Michael Hope wrote: > > Hi there. I'm confused about how we nominate and schedule things for > > the upcoming summit. I've got a bunch of tr-* TR blueprints and a > > related set of engineering blueprints. Some of these blueprints are > > too big for one session and some need to be bundled up to fill up a > > session. No matter what, summit blueprints need the > > other-linaro-n-foo naming convention to work. > > > > What should I do? My best guess is create other-linaro-n-foo > > blueprints for scheduling's sake and add the TR and engineering > > blueprints as dependencies. > > I've done something like that. The meta blueprints bring together > everything > related to a theme - cpufreq, cpuidle, tools, etc. > > I plan on having a double-session for each theme to cover all topics > related > to the theme. Any left-over discussion will be scheduled at LDS itself. > > > BTW, I've written up my understanding of the workflow at: > > https://wiki.linaro.org/MichaelHope/Sandbox/SummitWorkflow > > That is a useful view. I'll pass it on to my team. > > /Amit > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > -- David A Rusling CTO, Linaro ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: export kernel clock information to user space
and the UK!Cheers, Dave Sent from yet another ARM powered mobile device On 17 Oct 2010, at 16:18, Sundar wrote: > On Sun, Oct 17, 2010 at 9:11 AM, Yong Shen wrote: >> BTW, 'cheers' is normally used in Australia and New Zealand. Are you from >> there? Just curious. :) > > Oh really??..I am not aware of that all.I am from India :). IMO its cool. > > cheers! > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Common ARM context save/restore code
All, this could be a good topic at lin...@uds... Dave Sent from yet another ARM powered mobile device On 18 Oct 2010, at 06:18, "Shilimkar, Santosh" wrote: > Bobby, >> -Original Message- >> From: Bobby Batacharia [mailto:bobby.batacha...@arm.com] >> Sent: Sunday, October 17, 2010 4:08 AM >> To: Shilimkar, Santosh; Jon Callan; linaro-dev@lists.linaro.org >> Subject: RE: Common ARM context save/restore code >> >> Santosh, >> >> Again - apologies for the tardy responses to this thread. >> >>> This is something very different from SOC point of view. >>> Example OMAP4, the restore for GIC, SCU, L2 is handled by ROM >>> code and it expect it to save in a particular pattern and >>> pre-defined memory location. Generic code won't work here. >> >> Understood, and Jon's code certainly doesn't preclude such an approach. >> >> Small point, but I'm not sure I buy the part about pre-defined memory >> locations: that will be a parameter into the generic code. I do agree SoC >> specific code provides the context pointer regardless of where the restore >> happens. The approach we're working on is also intended to respect >> multiple CPU and SoC level TrustZone scenarios: there will clearly be SoC >> and CPU state that can't be Saved/Restored by the OS. (The bulk of that >> non-OS code may or may not be in ROM, depends on the SoC.) >> > The pre-defined locations are needed because not every registers needs to > be saved. For example in GIC, pending. Clear, Set sets of register are > pretty much same with inverted logic and can be easily decoded without > saving all of them but just one type of it. Hence the Save layout > is not linear on OMAP4 and restore is handled in by Secure CODE which > is fixed for a SOC > >> Out of interest, in the OMAP4 implementation, when a single core is >> powered down (but Fabric/DMC, cluster, and potentially another CPU stays >> up), does that core end up calling into non-OS code to save and restore >> its state? >> > Yes... Again I am not saying that you can't have generic code doing that. > It's doable but it will end up with some SOC specific execeptions. > >>> Having said that, would be good to see your patches. >> >> Certainly interested in your comments when we make it public. (I know, I >> know .. soon!) >> > Ok > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro 10.11 Final released
Everyone, many thanks to all of you and the hard work that's gone into this release. To go from a standing start in May and to build an organisation that has, in such a short time, delivered so much is an enormous achievement.I'm looking forward to the next cycle... Dave David Rusling, CTO http://www.linaro.org Linaro Lockton House Clarendon Rd Cambridge CB2 8FH ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: QT4 and atomics
Michael, the best, long term engineering solution, is to rely on the gcc __sync primatives. Whether there any intermediate steps along the way is debatable. Discuss Dave On 14 Nov 2010, at 22:26, Michael Hope wrote: > 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 > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Ubuntu ARM and the linaro kernels
Good discussion. Stupid question - what is the Ubuntu sauce? I'll ask the
kernel dudes in their meeting in two minutes...
Dave
On 15 Nov 2010, at 15:53, John Rigby wrote:
> On Mon, Nov 15, 2010 at 4:28 AM, Loïc Minier wrote:
>> Folks, I think this thread is circling a bit back to itself, perhaps
>> summarizing where we stand and what problems we're trying to solve
>> would help?
>>
>>
>> * Linaro integrates its kernel tree into Ubuntu for two reasons:
>> - because Linaro uses Ubuntu as a base to build its own derived
>> images (out of Ubuntu)
>> - because Linaro wants its kernel shipped/available in distributions
>> such as Ubuntu/MeeGo/whatever for mutual benefit of the distro and
>> of Linaro. For instance, Ubuntu users could install this kernel
>> instead of the official Ubuntu one, or Ubuntu could build images
>> from this kernel (as proposed in the original email).
>>
>> * there are currently the following *three* trees for the Ubuntu Linaro
>> kernel packages to happen (for maverick):
>> - git://git.linaro.org/kernel/linux-linaro-2.6.35.git -- upstreamish
>> tree maintained by Nicolas, based on upstream git tree with patches
>> relevant to Linaro merged in; the Linaro Kernel
>> - git://git.linaro.org/ubuntu/linux-linaro.git -- Ubuntu-ish tree
>> for the linux-linaro source package in Ubuntu or in Linaro PPAs
>> maintained by jcrigby, based on the Linaro Kernel tree with
>> packaging and the Ubuntu stuff ("Sauce") merged in
>> - git://kernel.ubuntu.com/ubuntu/ubuntu-maverick.git linaro branch --
>> pretty much the same as jcrigby's tree maintained by the Ubuntu
>> kernel team; it's mostly a copy of jcrigby's tree when it gets
>> uploaded to Ubuntu, unless the Ubuntu kernel team has to do any
>> minor adjustments/fixups before upload; it exists only because
>> jcrigby can't upload and because /ubuntu is restricted to the
>> official Ubuntu Kernel Team
>>
>> So what problems / questions are we trying to solve?
>> * security support: Linaro isn't in the business of long-term security
>> support of its trees, however I understand that it wouldn't be a big
>> problem to simply add the *Ubuntu* linux-linaro package and the
>> kernel.ubuntu.com git tree to the list of packages/trees which get
>> security updates from the Ubuntu Security Team, especially if the
>> Ubuntu ARM Team moves to this package/tree as their base for some
>> images
>> * for Linaro, the Ubuntu Sauce stuff doesn't add any much value and is
>> a distraction (causes more merge efforts, might cause extra bugs
>> etc.)
>>
>>
>> Is this a fair summary? Did I miss anything?
>>
>>
>> I am not sure I understand the point of contention with the Ubuntu
>> Sauce stuff; is it causing problems to Linaro right now?
>> Linaro GCC is released in source form and then integrated in the
>> Ubuntu gcc-4.x packages which have tons of patches added on top; this
>> is not ideal for Linaro Toolchain WG, but it's part of the process to
>> check whether bugs do apply to the pristine Linaro source, just like
>> you need to test a pristine upstream GCC or Linux when reporting bugs
>> upstream.
>>
>> There are definitely things we could do to improve the Ubuntu Sauce:
>> * split this stuff more; e.g.:
>> - packaging goes in one tree (I think this is already split out?)
>> - patches which come from upstream or were acked upstream go into
>> another tree
>> - patches which are Ubuntu specific such as AUFS go into one or
>> multiple separate trees
>> * we could review the current sauce stuff and only merge in features
>> which are really needed for Linaro images and Ubuntu ARM images; aufs
>> doesn't seem to be needed anymore for instance? Maybe this makes
>> things more complex for little gain though
>> * we could stop merging patches from upstream from Ubuntu, and have
>> them flow in via Linaro instead; again, maybe this makes things more
>> complex for little gain
>>
>>
>> My opinion is that the current approach is okay modulo two things:
>> - we should drop one of the two packaging trees; the
>> linaro / jcrigby versus kernel.ubuntu.com split is useless
>> - we could provide pristine kernel builds, built from the Linaro Kernel
>> directly and without any Ubuntu Sauce
>> . in fact these exist already, they just aren't tested and they use a
>> random config: http://hudson.dooz.org/
>> . if we want Linaro Kernel .debs instead of standalone zImage/uImage,
>> we could do something like
>> https://wiki.ubuntu.com/Kernel/MainlineBuilds
>>
>>
>> Proposed plan:
>> * Oliver/Ricardo to confirm with Ubuntu Security Team whether it's ok
>> to base Ubuntu ARM images on linux-linaro tree as constructed
>> currently
> I can't speak for the Ubuntu ARM folks but I believe their main concern was if
> I stopped including Ubuntu Sauce.
>> * John to request upload permissions for linux-linaro onl
Re: Ubuntu ARM and the linaro kernels
For what it's worth, I agree with Kiko's statement. We have three stakeholders - internal use of the kernel by Linaro, external use by distributions (such as Ubuntu) and external use by community. We need to position ourselves appropriately... Dave On 15 Nov 2010, at 15:57, John Rigby wrote: > On Mon, Nov 15, 2010 at 7:53 AM, Christian Robottom Reis > wrote: >> On Sun, Nov 14, 2010 at 03:05:20AM -0200, Ricardo Salveti wrote: >>> On Thu, Nov 11, 2010 at 4:02 PM, Nicolas Pitre >>> wrote: >> On Tue, 9 Nov 2010, Oliver Grawert wrote: On Thu, 11 Nov 2010, Ricardo Salveti wrote: > That's understandable. Now the question is why John is maintaining and > packaging a tree that also incorporate the Ubuntu sauce on it? I think that the main reason is that this was much easier to have a packaged initial release by simply piggybacking on the existing Ubuntu infrastructure. But John's tree and mine are still separate. >>> >>> Ok, so there's nothing that guarantees that John will continue using >>> the same Ubuntu infrastructure and sauce in the future. >> >> I want to put a firm statement in here that Linaro are committed to >> supporting Ubuntu on ARM through our kernel work, and that if it's >> necessary for us to support the kernel maintenance process then we will >> do it -- so there is a firm guarantee from me that we'll always be open >> to working out what outputs you need. >> >> I'd like to talk over the specific case of SAUCE patches, because I'm >> not entirely sure a) how much effort maintaining them is required and b) >> if we need to carry the Intel (and other arches) specific bits of SAUCE >> as well. >> >> I'm getting the curious feeling that the above isn't clear to the people >> on this thread, so hopefully this is a step towards clarity. > Kiko, > > Thanks for the clarification. You have answered my only question which was if > Linaro engineering was willing to support the inclusion of Ubuntu Sauce. > > John > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
Konstantinos, thanks, I agree with your thoughts. My approach has been to accept small steps in the right direction and encourage reasoned discussion. I also think that Linaro's main function is as a place where all the moving parts can collaborate.Right now, the GPU 'problem' is that of getting both open source and proprietary pieces of the BSPs to work really well together in products. That's really the focus of the Graphics WGs and the partner landing teams. This is a heavy lifting engineering job, and it will take time, but everyone is willing and hopeful of good results.Doing this will also help us have a reasoned discussion about where the open source and proprietary boundaries make sense. Now for a bit of a rant. Personally, I have a deep and abiding respect for open source (for me, it's the key social invention of the internet age), however I also recognise that it would not exist without companies using open source as part of their products.Let's face it, an awful lot of open source engineers are getting their mortgages paid by companies that make use of open source. No company invests in open source for philanthropic reasons; they understand that it is necessary for their businesses.The tricky problem is always in how ethical a company's usage is (and I use the word 'ethical' deliberately because this is wider than mere legal words smithing); whenever I give talks on GPL, I emphasise both the moral as well as the legal duties.In my experience, most companies struggle to understand open source when they first start to interact with it. It usually takes some open source zealots within the company to persuade their management of the right way to behave. The best way to get companies to change their behaviour is to find them and support them. Making threatening GPL noises in email does not help them in any way. Dave David Rusling, CTO http://www.linaro.org Linaro Lockton House Clarendon Rd Cambridge CB2 8FH ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
Alan,
I still stand by my assertion that educating companies as to the
realities and philosophies of open source is better than threatening them.
Your analogy of open source as a standard, a practical de facto standard
written in a programming language is a good one.Forking code (by never
upstreaming it) tends not to be sustainable (although some companies still
try).Proprietary code exists for all sorts of reasons, often a bogus belief
in an intrinsic value.Graphics, in particular, is a very litigious world
and also, the biggest cause of proprietary code, surely some link?
Back to the plot. Linaro is trying to help here, both in reducing
non-optimal code forking and in helping its members work better with the open
source communities. As I said in my earlier mail, this will take time. That
said, I've seen enormous shifts within the ARM partnership already this year
and look forward to more next year.
Merry Christmas / Happy Holidays to one and all.
Dave
ps nice to see that you keep your old email address.Are you still in Wales?
On 23 Dec 2010, at 17:17, Alan Cox wrote:
>> way to behave. The best way to get companies to change their behaviour is
>> to find them and support them. Making threatening GPL noises in email does
>> not help them in any way.
>
> I would disagree based on years of history.
>
> The best way to get a company to change behaviour is for a situation to
> occur in which it is in their own hardcore capitalist self interest to
> change.
>
> In my experience open source usually mirrors standards in this. The
> leading vendors refuse to take part, the smaller vendors see the
> opportunity - often working together - and the bigger vendor eithers gets
> its backside kicked or does a sharp turn in the right direction.
>
> That's the story of email, of the web, and is occuring currently in
> telephony and other areas.
>
> It's also why folks like Dell deserve a lot more credit than they get for
> the success of Linux.
>
> If its not commercially sensible it doesn't matter what the licensing
> says. They are corporations not charities, if it's not economically
> viable for them to manage it all themselves including new driver
> releases, legal risk, all their own review and keeping up with DRI then
> they have to decide which way to go - some go the "hit and run" approach
> ('not got kernel X then sorry but not our problem'), some do the work to
> support it release by release but don't go GPL (eg Nvidia), some open up,
> others just walk away.
>
> Alan
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro Office of CTO meeting minutes
All, apologies, I should have posted the minutes for our first meeting before Christmas.Anyway, here are today's minutes: https://wiki.linaro.org/OfficeofCTO/2011-01-04 Dave David Rusling, CTO http://www.linaro.org Linaro Lockton House Clarendon Rd Cambridge CB2 8FH ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Office of the CTO / meeting minutes
All, please see https://wiki.linaro.org/OfficeofCTO/2011-01-18 for the minutes of today's meeting and https://wiki.linaro.org/OfficeofCTO for the pages where we keep notes etc. Dave David Rusling, CTO http://www.linaro.org Linaro Lockton House Clarendon Rd Cambridge CB2 8FH ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro Instructions for Overo(Gumstix)
Andy, thanks, and I've just added wiki.linaro.org/Boards as a top level index and a page that I've been using for the Efika mx smartbook... Dave On 20 Jan 2011, at 06:50, Andy Doan wrote: > FYI: > > I've just created a page describing how to get a Linaro image running on > the Overo Gumstix board: > https://wiki.linaro.org/Boards/Overo/Setup > > -andy > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Call for opinion: Linaro 'Nano' Image
Yes, but isn't initrd slow to copy from the boot media (caches off, simple byte by byte copy)? Dave On 21 Jan 2011, at 16:27, Arnd Bergmann wrote: > On Friday 21 January 2011 16:50:37 Jamie Bennett wrote: >>> Could we do with an initrd instead of an image? I mean, busybox + >>> small set of tools is probably enough for validation, and will be quite >>> small. >>> >>> There is inherent bloat as soon as we add a package manager in the mix >> >> Right, current thoughts after some IRC discussion are: >> >> * busybox >> * no package manager >> * max size of 30mb (without kernel) >> * some further removal of packages >> >> I think with this in place you will get a ~30mb compress rootfs, we >> could even go further if necessary. > > Sounds good, but that does not answer the question of whether it should > be an initrd, a file system image, or both. > > I think having something available as an initrd image, or at least > an option for this, would be extremely valuable because it lets you > netboot the kernel+image without the need for NFS or for physically > installing the image on the target system. > >Arnd > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Tidying up some ARM boards
We should try this in the Linaro Cambridge office... Dave On 31 Jan 2011, at 11:47, Dave Martin wrote: > On Mon, Jan 31, 2011 at 3:37 AM, Michael Hope wrote: >> My office was getting a bit messy so I re-purposed an old PC case and >> mounted my ARM boards, a switch, and far too many power supplies into >> it: >> http://people.linaro.org/~michaelh/racked/IMG_20110131_145444.jpg > > Neat. But you've got room for _way_ more stuff in there ;) > > ---Dave > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ELC and memory management
Andy, good idea. Jesse will be there, so would be good to agree the problem and start thinking of some directions... Dave Sent from yet another ARM powered mobile device On 25 Mar 2011, at 21:08, "Gross, Andy" wrote: > All, > > Are there plans of having a meeting to discuss memory management at the ELC? > There was a thread a week or so ago about all of the various implementations > of memory managers (pmem, cmem, ump, gem/ttm, etc) where this was mentioned. > > Our interest in this stems from our current effort to migrate our OMAP > display and memory management functionality to the DRI/DRM model. Like > everyone else, we have to allocate large blocks of memory that are used for > display, video encode/decode, and capture. We're in the same boat of having > implementations that are not upstream. > > If there is not already a meeting, would it be possible to carve out some > time on one of the days where there is a graphics centric presentation > (Tues/Wed)? > > > Best Regards, > > Andy Gross > Linux Development Center > Texas Instruments > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Office of the CTO meeting minutes
All, the notes can be found here - https://wiki.linaro.org/OfficeofCTO/2011-03-29 Dave David Rusling, CTO http://www.linaro.org Linaro Lockton House Clarendon Rd Cambridge CB2 8FH ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Libraries with NEON backends
Konstantinos, Steve, I think that it depends on how you interpret "plainly mark".I can imagine several ways of doing this - Naming the (binary) package explicitly - install an additional README file / include in the binary package - explicitly named source tar files I think that the original authors did not want derived works being represented as their original work.So, need to avoid any confusion that the Neon enabled version with the original. I'm with Steve, that marking sources, adding another notice etc is enough. Are the original authors still involved? It might be worth asking them... Dave Sent from yet another ARM powered mobile device On 30 Mar 2011, at 01:04, Konstantinos Margaritis wrote: > On 30 March 2011 01:45, Steve Langasek wrote: >> I don't think this is a correct interpretation of the license. You don't >> have to change a package name to "plainly mark" the source as modified; >> debian/copyright, changelogs, notices in the source files accomplish this. >> This is done for packages all the time, not just for zlib. > > from http://www.gzip.org/zlib/zlib_license.html > > 2. Altered source versions must be plainly marked as such, and must not be > misrepresented as being the original software. > > I read this then as "you cannot distribute it as a replacement of the > original zlib library". > I'll take your word that it's not the case, but it still is confusing to me. > > Konstantinos > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linus being annoyed by the ARM kernel code
Eric, yes, I found that interesting. I've been having discussions about how to do this better, I'm interested in your thoughts. Are you by any chance at ELC in SF? Dave On Fri, 2011-04-01 at 23:43 +0800, Eric Miao wrote: > Just FYI - lengthy but very interesting read, Linus was really good at > wording, enjoy heh :-) > > https://lkml.org/lkml/2011/3/17/283 > > So maybe it's just a right time to talk about using linaro ARM kernel > tree as a fork for quick merge of the ever expanding SoC and board > support, and using it more as a productive kernel for downstream. > And in the mean time, improve the mainline kernel into such a good > shape that with less crappy code we could support more platforms? > > Just a bit thought on that possibility. > > - eric > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev -- David Rusling, CTO http://www.linaro.org Linaro Lockton House Clarendon Rd Cambridge CB2 8FH ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Office of CTO meeting notes
All, the minutes of the last meeting can be found here - https://wiki.linaro.org/OfficeofCTO/2011-04-05 Dave -- David Rusling, CTO http://www.linaro.org Linaro Lockton House Clarendon Rd Cambridge CB2 8FH ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Office of CTO weekly meeting
See https://wiki.linaro.org/OfficeofCTO/2011-04-26: == Actions from previous meeting == * CARRIEDOVER: Steve to investigate Samsung bits * ACTION: Grant to mail David with the exact sessions / meetings he would like to have * Superseded, Grant has added blueprints to LDS, ready for scheduling == Attendees == * David Rusling * Patrik Ryd * Grant Likely === Holiday === * Loïc Minier * Steve !McIntyre == Minutes == * Discussed Developer Summit * Blueprints coming together, see [[https://blueprints.launchpad.net/sprints/uds-o?searchtext=linaro-]] * David * OCTO update to Linaro board, slides circulated * ACTION: all, please review * Monthly executive newsletter * Emphasis on memory management * Organising subarchitecture kernel maintenance in time for LDS * Grant * Working towards getting stuff merged into the device tree * Russell looking at the device tree * UDS: documents need to be readied for presenting * ACTION: dig into device tree blueprint for Qemu / toolchain * Patrik * Busy getting things to work (Panda does, Beagle doesn't) * Trying to get first Android LEB up and running, might demo at LDS David Rusling, CTO http://www.linaro.org Linaro Lockton House Clarendon Rd Cambridge CB2 8FH ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Fedora armv7hl bringup
Hang on. I think that hard float for Android is a different discussion for hard float for 'normal' Linux, including Debian, Ubuntu and Fedora... Dave Sent from yet another ARM powered mobile device On 2 May 2011, at 18:22, Zach Pfeffer wrote: > On 1 May 2011 18:02, Jon Masters wrote: >> On Sun, 2011-05-01 at 13:27 -0500, Zach Pfeffer wrote: >>> On 1 May 2011 03:52, Riku Voipio wrote: On 30 April 2011 07:54, Jon Masters wrote: > In the spirit of reaching out to the Linaro community, I'd like to > engage in some conversation with those working on the HardFP ABI switch > and toolchain effort, since we will shortly be doing the same in the > Fedora ARM community. The intention is to support hardfp in time for the > Fedora 15 ARM release, which *will* lag behind the x86 F-15 release. Of the pointers, Wookey already mentioned the Debian hardfloat port. The other port to look at for patches etch is the MeeGo hardfloat ARM port. You can track the progress at meego bugzilla[1] as well as meet the people on #meego-arm on freenode. Riku [1] https://bugs.meego.com/showdependencytree.cgi?id=11429&hide_resolved=0 >>> >>> We've got a nascent Android project started at: >>> >>> https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-o-hardfloat >>> >>> Is there an Ubuntu session scheduled? >> >> If you mean LDS, there seem to be two sessions (Thu and Fri) related to >> the hardfp ABI, one on cross-toolchains (which from a Fedora point of >> view we don't care about), and one about native. I'd certainly be up for >> further topics around this during the week. We don't want to work in a >> vaccum...one thing I've tasked our guys with doing is reviewing all the >> Linaro and MeeGo patches to see what we can help upstream more quickly >> since Fedora really wants to use as vanilla a toolchain as possible. > > Sounds good, perhaps we can merge > https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-o-hardfloat > with one of the existing topics. Michael, would you like to merge this > with one of the hard float sessions? > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Greetings!
Deepak, welcome and good luck. See you in Budapest Dave On 05/02/11 19:25, Deepak Saxena wrote: Hello all, I want to introduce myself to the linaro-kernel and linaro-dev lists as I just started at Linaro today in the role of Kernel Working Group Technical Lead and will be working closely with all of you on enhancing the ARM Linux ecosystem. I've been using Linux since 1993 and working with the Linux kernel for over 10 years for a variety of companies including silicon vendors, OSVs, and device vendors with a broad variety of experience including ARM CPU and board bring up, hacking on a variety of device drivers, maintaining a distro kernel, maintaining a few ARM sub-architectures, educating HW vendors and new developers about the open source development model, etc. I've been a bit out of the loop of the open source community the last 1-2 years and am really excited to be involved with Linaro working on community-focused technology enablement and enhancement. I expect this first week to be mostly focused on reading up on process, existing deliverables, mailing list archives, etc to wrap my head around where we are right now and where we're headed with the 11.11 release. I'll be at LDS and look forward to meeting many of you next week and I want to encourage anyone who won't be at LDS but has concerns, ideas, questions related to the kernel WG to drop me an email. Thanks! ~Deepak ___ linaro-kernel mailing list linaro-ker...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel -- David Rusling, CTO http://www.linaro.org Linaro Lockton House Clarendon Rd Cambridge CB2 8FH ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Office of CTO meeting minutes
See https://wiki.linaro.org/OfficeofCTO/2011-05-03. Basically, heads down for LDS next week... Dave David Rusling, CTO http://www.linaro.org Linaro Lockton House Clarendon Rd Cambridge CB2 8FH ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
LDS
All, for those of you that are here, welcome (especially any newbies), hope you have a good week! For those of you not here, you can join in as all of the sessions are streamed. You can also ask questions via IRC.A good link to the Linaro sessions is here: http://summit.linaro.org/uds-o/ Dave -- David Rusling, CTO http://www.linaro.org Linaro Lockton House Clarendon Rd Cambridge CB2 8FH ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Usefulness of GCC's 64bit __sync_* ops on ARM
Is this going to end up in a blueprint? This is the last loose end of SMP / atomic memory operations work and I'd like to see it happen Dave On 18 May 2011, at 16:07, Dave Martin wrote: > On Tue, May 17, 2011 at 5:30 PM, Nicolas Pitre > wrote: >> On Tue, 17 May 2011, Dave Martin wrote: >> >>> On Fri, May 6, 2011 at 10:39 PM, Nicolas Pitre >>> wrote: On Fri, 6 May 2011, Ramana Radhakrishnan wrote: > On 6 May 2011 16:06, Ken Werner wrote: >> >> Currently the GCC ARM backend doesn't provide a pattern to inline 64bit >> __sync_* functions but the compiler emits __sync_*_8 function calls [1]. >> The >> libgcc does not provide these symbols via the usual thin wrapper around >> the >> kernel helper [2] because the ARM Linux __kernel_cmpxchg supports 32bit >> only. >> My understanding is that for ARMv7 the GCC backend could be enhanced to >> inline >> the __sync_* functions by using the LDREXD and STREXD instructions. But >> for >> ARMv5 we would still rely on a new kernel helper. > > It's a bit tricky with when you want to use the kernel helper for v5t, > so we've got to find a way of turning this on only with special knobs > and not by default and that's a bit tricky. What is the problem with v5t? > Think new user space and old kernel and a jump into never-never land. The kernel helpers are "versioned". At 0x0ffc you can read the number of helpers currently available. If a program uses a new helper then when it is started this value can be verified to equal or exceed the expected value and bail out otherwise. >>> >>> To what extent do we think that userspace code is actually checking this? >> >> I think right now it is none of it simply because most of the helpers >> were added almost all at once. But if future helpers are added then it >> would be a good idea to check this but only if the new helper is >> actually invoked for a given application. >> >>> I may suggest a patch to the documentation text in entry-armv.S to >>> make this requirement clearer, as well as getting rid of the example >>> assembler code (which I consider to be mis-educative, but more >>> importantly it's also Thumb-incompatible and will likely suffer poor >>> branch-prediction on recent CPUs. >> >> If you have suggestions for improving this then please do so. > > I have a patch which I'll suggest at some point, but it's not high priority. > >> >>> This code was the source of a TLS >>> bug in bionic, and may have been inappropriately pasted elsewhere >>> too...) >> >> What bug? > > Actually, to be fair I think I may be mis-remembering here... I can't > seem to find the exact bug now. > > Cheers > ---Dave > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Office of CTO Meeting Minutes
Basically discussing https://wiki.linaro.org/OfficeofCTO/Schedules/, https://wiki.linaro.org/OfficeofCTO/2011-05-24, getting our act together for the public plan review Dave David Rusling, CTO http://www.linaro.org Linaro Lockton House Clarendon Rd Cambridge CB2 8FH ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Does anyone care about LSB on arm?
s hang out :-) It's easy to think of potential use-cases, and I think ultimately, unless the LSB is in fact entirely irrelevant, this work will get done everntually. But should we get on with that now, rather than whatever else we might be fixing, and if so, who is volunteering to get involved? ( Jon Masters and I have both expressed interest but are not exactly brimming over with spare time. Any more for any more?) Opinions welcome. Wookey -- David Rusling, CTO http://www.linaro.org Linaro Lockton House Clarendon Rd Cambridge CB2 8FH ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Does anyone care about LSB on arm?
Steve, thanks, have a poke around and tell me / OCTO what it means to join in, what the costs and benefits are etc... Dave On 06/01/11 22:36, Steve McIntyre wrote: On Wed, Jun 01, 2011 at 07:32:18AM +0900, David Rusling wrote: On 06/01/11 01:22, Wookey wrote: As this is a non-trivial amount of work, the question then arises, does anyone care about this enough to actually do the work? Linaro is an obvious organisation that could expend some engineering effort on this, but to do that it needs some indication that it's more than a 'would-be-nice'. Wookey, the short answer is 'yes'. The next question is 'who?'. Absolutely, yes. It makes a lot of sense for the growing number of people looking to collaborate here to pool their efforts in an existing central spec/location. Maybe this can be bolted onto the hard float work, I'll let Konstantinos and Steve respond... Ah, I guess I've just volunteered myself haven't I? :-) /me goes to subscribe to the LSB lists and start reading things. Cheers, -- David Rusling, CTO http://www.linaro.org Linaro Lockton House Clarendon Rd Cambridge CB2 8FH ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Office of CTO meeting minutes
See https://wiki.linaro.org/OfficeofCTO/2011-06-14 plus inline: == Actions from previous meeting == == Attendees == * David Rusling * Loïc Minier * Steve !McIntyre * Paul !McKenney * Grant Likely * Ilias Biris * Konstantinos Margaritis == Minutes == * Actions from the last meeting * ONGOING: Steve to arrange for some weekly sync on hf * DONE: Loïc to create a cross-distro or distro list * Anything for the end of June milestone? * Device tree documentation - linaro-kernel-o-devicetree * Wiki description of the benchmarking activity by the end of the month? Yes. * Finishing the cross boot boot strapping for Natty and pushing the patches upstream. * Status * ARM hf * Konstantinos * iMX52 boards running hf * Panda boards running hf * No benchmarks run yet * Steve * Struggling with the LSB work * Finishing off Natty cross-build issues (lots of broken packages!) * Most patches taken by upstream * Grant * Device Tree documentation got posted (2/3 way there * Missing is review / comments * How to add new platforms, but will be written in conjunction with the Kernel working group * Boot architecture document will be out later this week * Date for a meeting, executive decision is August 5th * Loic * ACTION: schedule a call with Lars Knuth with xen [DONE: Thursday noon] * Booked Dublin DS attendance * Hardware pack v2 reviews * Removed old redboot based stuff from Ubuntu builds * Working OMAP 4 Panda board TI images * !OpenMax - important from last week's multimedia mini-summit * Illias * Nothing major, attended the multimedia summit, quite a lot of work there * Paul McKenney * No feedback on the Server proposals * AOB * Chrome 0S * Directly contacted, let's see what happens * Belfry OCTO sessions? Missing anything? * Hardfloat sessions, cross distro announcements - assume Thursday morning half day session * Server - part of the boot architecture discussions? xen is in Cambridge, could invite them face to face * Hour or so session with Xen at the Belfry, also the boot architecture * ACTION: David Rusling send Lars' email address to Grant * Kexec - let's do this as part of a hacking session, but also a topic in the boot architecture discussion * ACTION: Grant add kexec to the boot architecture Belfry discussion David Rusling, CTO http://www.linaro.org Linaro Lockton House Clarendon Rd Cambridge CB2 8FH ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro graphics/multimedia meeting - Aug 16, 2010
Alexander, many thanks for getting this going. Can you add Jesse Barker ( jesse.bar...@arm.com) into this please? Dave On 17 August 2010 09:17, Alexander Sack wrote: > Hi all, > > Notes and actions from our Monday graphics and multimedia cross-vendor > call are available on the wiki: > > + https://wiki.linaro.org/Platform/UserPlatforms/2010-08-16 > > Details about when and where of this meeting can be found here: > > + > https://wiki.linaro.org/WorkingGroups/Middleware/Graphics#Weekly%20Public%20Call > > Thanks, > > -- > > - Alexander > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > -- David A Rusling CTO, Linaro ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
