Folks,
I want to let you know I have some notes from LPC that I will be sending
out. I didn't get to this on Friday, so I plan to have it out first
thing Mon. I'll followup to this thread once I have that taken care of.
Jon.
Jon Masters <jcm(a)edison.jonmasters.org> wrote:
>---begin log---
>jonmasters [19:14:43] <infinity:#linaro-armhf> lool: jonmasters took
>pretty comprehensive notes, not sure if he's sent them anywhere yet.
>jonmasters [19:14:59] <infinity:#linaro-armhf> jonmasters: ^
>---end of log---
I will send notes later. Before Mon anyway.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Folks,
A couple of things from me. Split into two sections:
Dialin
------
IRC: #linaro-armhf (irc.freenode.net)
Time: 8pm Pacific tonight.
I have had a special line setup on the Red Hat Conference system. To
dial into this, use one of the following country-specific codes with the
access code of 6177591337 (which is my US cellphone number btw).
Global Network Access
Toll-Free Dial-in Numbers:
Australia : 1800337169
Brazil : 08008921002
Finland : 0800117116
France : 0805632867
Germany : 08006647541
United Kingdom: 08006948057
United States: 18004518679
Agenda
------
(Steve already sent out a comprehensive agenda)
To Steve's other point around topics for tonight, I agree that the only
things (being brutally honest also here) I really care about is
hardfloat and standardization. I think we should collectively consider
at the start of the meeting whether it makes sense (IMO it does) to
confine our discussion to topics we can make progress on in the limited
time that we have. I also suggest seeing if we can find another time to
followup tomorrow that we can all agree on. For those of us here in
person, I assume there can be dinner/beverages after. I am open to
grabbing a late dinner if anyone else is interested too.
Topics I would like to specifically include in the discussion:
1. Agree that all the distros want hard float. And what that means (just
refer to the AAPCS stuff we all already know). Basically a statement "we
the assembled Linux community will be supporting a common definition of
hardfloat in our distributions", etc. I have people asking me on and off
about hardfloat thinking every distro is doing its own thing...which
actually is far worse than reality. So, let's fix this with a generic
fluffy media-friendly statement.
2. Cross standardization. Not just LSB but how are we going to keep
these discussions going? There is the hardfloat IRC channel, etc. but I
think this is bigger than HF. I want an ongoing cross-distro discussion
around ARM standards. That can be cross-distro, but it *must* actually
have some agreed framework, with regular syncups. I would go as far as
to say we need a regular phone call (can be once a month) just to force
us all to keep this collective ball rolling.
Thanks!
Jon.
P.S. Please forward this information to anyone else who should dial in.
I am not yet certain this will actually work given that this isn't a
regular LF event so the folks I would usually ask for assistance hooking
this up (an actual, non-cell phone with some kind of speakerphone that
will work, etc.) but I'm pinging folks now.
David:
On Wed, Aug 24, 2011 at 6:55 PM, <david(a)lang.hm> wrote:
> ARM is currently in worse shape than the PC market ever was in this aspect,
> but in this case it's less a matter of getting the hardware guys to change
> what they do than it is to get better documentation of what the hardware is
> really doing and not duplicating drivers for cases where the right answer is
> just replacing a constant with a variable (just as an example of the very
> common case where the same component is wired to a different address)
I agree.
Maybe Linaro or an equivalent organization could provide a "ARM kernel
janitor" service to the community, where they refactor existing ARM
platform/driver code to make it more common. This is something that's
difficult for a single person with experience in only one or two SoCs
to do, but it would be pretty straightforward work for a team of three
or four people with broad coverage of the SoC devices the kernel
supports now.
As such refactoring consolidated larger and larger chunks of kernel
code, new designs would gravitate towards those consolidated
implementations because they would be the dominant references.
b.g.
--
Bill Gatliff
bgat(a)billgatliff.com
On Tue, Aug 23, 2011 at 02:41:32PM -0500, David Mandala wrote:
>On 08/23/2011 11:11 AM, Steve McIntyre wrote:
>> UPDATE: we've not had many people confirm interest in this event yet,
>> which is a shame. If you would like to join us for this session,
>> please reply and let me know. If we don't get enough interest by the
>> end of Sunday (28th August), then we'll have to cancel the meeting.
>>
>> Cheers,
>I will be attending
Thanks David.
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
On Mon, Aug 01, 2011 at 02:34:56PM -0400, DJ Delorie wrote:
>
>> I haven't looked at the docs in a while, but we are most likely going
>> to need this again in the distant future. Plus the fact it seems to
>> come up all the time.
>
>One of the things I'm hoping we get out of this is an official fully
>automated way to bootstrap, make it fast, and do it often. Then it
>will always be there when we need it.
Sounds like an excellent idea. :-)
We're working on a similar goal within Debian too.
Cheers,
--
Steve McIntyre
steve.mcintyre(a)linaro.org
Hi,
[my first, friendly, post]
At Mandriva there is some interest of having an arm based distro.
Matthew Dawkins made an awesome job on providing a very complete
qemu image with a Mandriva/Unity Linux distro
http://distro.ibiblio.org/pub/linux/distributions/unity/other/unitybuild-ar…
[above link is a qemu image, kernel and a script to start qemu]
Personally, I am doing some research on it for self teaching, and
I made several qemu images for testing, based on buildroot.net and
based on openembedded.org.
Also for the sake of self teaching, I made an arm port of my fork
of gnu lightning at https://github.com/pcpa/lightning and I also
wrote another jit (based on lightning) for my toy/hobby programming
language at https://code.google.com/p/exl/source/browse/
That being said, we have an almost ready to go armv5 port, based
on mostly unmodified upstream packages (gcc, binutils, etc). But we
expect that armv7 based boards will be common enough to require
another distro build. So far our idea should to be to work on what
appears to be the Fedora goal, e.g.
http://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap
but from my minimal arm architecture knowledge, what I am proposing
"over here at Mandriva" is to make it using arm instruction set, and
using armv5 abi (floats passed/returned on integer registers), but
enabling vfp-16 (using floats only for temporaries), this way,
armv5 packages would work unmodified in the armv7 based distro.
Well, this is kind of attempting to work on sequential steps, but
of course, going to thumb-2 and full/proper aapcs (hard float register
arguments, etc) is not out of question. But so far my knowledge of
of the state of art of thumb2 toolchain is not that great, but I
made a "contrib" mandriva package based on codesourcery toolchain
http://svn.mandriva.com/viewvc/packages/cooker/cross-arm/current/
Thanks,
Paulo
Hi folks,
Many GNU/Linux distributions are doing some ARM porting; this tends to
result in work duplication, and there doesn't seem to be a general
purpose forum to bring ARM porters together.
We're inviting developers of GNU/Linux distributions with an interest
in ARM to join a new "cross-distro" list, hosted at Linaro:
http://lists.linaro.org/mailman/listinfo/cross-distro
Any ARM Linux / Free Software discussion is welcome on the list, for
instance porting software to build on ARM, toolchain problems, dealing
with new ABIs, Thumb-2, NEON, kernel problems, announcement of new
tools etc.
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
