Hi Folks,
I propose the following triplet for Fedora on AArch64:
aarch64-redhat-linux-gnu
Skipping the vendor part, that means generally:
aarch64-linux-gnu
There should be no reason to deviate from this. I'm putting it out there
now because I don't want another ARMv7 experience later :)
Jon.
Meant to reply to the list.
Begin forwarded message:
> From: Jon Masters <jonathan(a)jonmasters.org>
> Subject: Re: AArch64 triplet
> Date: November 22, 2012 3:32:45 AM EST
> To: Mike Frysinger <vapier(a)gentoo.org>
>
>
> On Nov 20, 2012, at 1:27 PM, Mike Frysinger <vapier(a)gentoo.org> wrote:
>
>> On Tuesday 20 November 2012 03:25:56 Jon Masters wrote:
>>> The only reason for making a change at this time appears to be cosmetic,
>>> for removing /lib for example. I can understand that, and if we were
>>> discussing this a year ago (or even months ago when I first raised it on
>>> this list), then it might be a reasonable change, but at this time I
>>> cannot find an overwhelming technical justification.
>>
>> i don't think removal of /lib/ is really feasible. that's the path that gets
>> used for firmware (/lib/firmware/) and kernel modules (/lib/modules/<kver>/)
>> regardless of the default ABI on the system.
>>
>> similarly, userspace packages are using that path for supplemental files like
>> the bootloader (grub) or ABI-independent settings (udev rules).
>
> Sorry for the confusion. By "getting rid" what I mean is not having libraries in there. As is obvious, there will always be plenty of stuff in there, and it's mandated by standards anyway. So, really, if it's down to whether we (Fedora) have one thing in /lib that could be in /lib64 vs. not then I would rather just keep the dynamic linker where it is in /lib and move on with life.
>
> By the way, we announced our initial Fedora bootstrap work tonight. The wiki has a lot of information about what is currently being done, along with initial images that will grow:
>
> https://fedoraproject.org/wiki/Architectures/ARM/AArch64
>
> Jon.
>
Hi,
On 19/11/2012, Andrew Wafaa <andrew.wafaa(a)arm.com> wrote:
> It's only a few months until the land of waffles, chocolate and beer (to
> name a few of their fine products) hosts one of Europe's great Open Source
> events - FOSDEM [0]. I have submitted two talk proposals for the
> Distribution track, one around the status of ARMv7, and one around ARMv8; I
> believe there will also be a talk from Debian's one and only Wookey around
> bootstrapping ARMv8.
Related to that there is also the embedded and mobile room which is
interested in similar things.
So if you're not building complete distros that is the place to be ;)
===================================================================
Every year there is a special dedicated track for embedded and mobile
projects at Fosdem (see: www.fosdem.org ). If you are interested to
highlight or give a talk about your project check out the cfp.
FOSDEM will be held the 2nd and 3th of February 2013 in Brussels,
Belgium. As usual and for the 10th time there will be an embedded and
mobile room.
For this years program we are looking for people who would like to do
a presentation about their or their community's projects in this area.
These projects must be Free Software or Open Source.
For example involvement and experiences with projects like Arduino,
Tizen, Jolla, Mer, Beagleboard, Openembedded, Android, OpenWrt, Yocto,
Linaro... Kernel hacks for maximising memory usage, using filesystems
on flash, power management, ...
We are also interested in short tutorials, project overviews,
achievements, ports to new hardware and hardware hacking, real life
deployments, ... all are welcome and all submissions will be reviewed
by our panel.
Submissions require a small abstract and short speaker presentation
and should be submitted to fosdem.embedded at gmail.com before the 25th
of December 2012
The panel consists of:
Philippe De Swert
Peter De Schrijver
Geert Uytterhoeven
Thomas Pettazoni
Aloha all,
It's only a few months until the land of waffles, chocolate and beer (to
name a few of their fine products) hosts one of Europe's great Open Source
events - FOSDEM [0]. I have submitted two talk proposals for the
Distribution track, one around the status of ARMv7, and one around ARMv8; I
believe there will also be a talk from Debian's one and only Wookey around
bootstrapping ARMv8.
As the talks are being proposed in the Distribution track, it would be great
if we could get as many people from different distros interested in ARM to
join in the discussions and work to a common goal. If the talks are not
accepted for whatever reason, I would still like to have as many people as
possible in a face to face discussions about the trials and tribulations of
getting Linux on ARM to work - please note this will be focussed on the ARM
architecture and not the architecture of distro components, so leave any
GNOME/KDE/systemd/upstart/udev/*kit/etc angst at home please :)
Hope to see you in Brussels in February,
Andy
0 - http://fosdem.org/2013/
[ Based heavily on notes from
http://summit.linaro.org/lce12/meeting/21345/armv8-mini-summit-4/
but etherpad data has a lovely habit of going away over time... ]
This was an AArch64-specific distribution planning and discussion
session on Tuesday morning as part of the v8 mini-summit; there was
also a general cross-distro session on Monday for discussion about ARM
issues. I've already posted those minutes.
Familiar faces from Debian, Red Hat, SuSe and Ubuntu lead a discussion
about the where these distributions have got with thinking about
AArch64, the challenges that they face and how the community can get
involved
Recap of cross-distro session on Monday:
* Project is set up for sharing bugs and patches for ARMv8.
* Suggested way of working is to file a bug in distro-specific bug
tracker, and also one in the common bug trackers.
* There is already a Linaro cross-distro mailing list - currently
very low traffic.
AArch64 support in packages
===========================
Biggest issue seen to date (Fedora) is the number of packages that
have not reconfigured to pick up the aarch64 target. Jon suggested
using an LWN article perhaps to publicise the need for upstream code
to update their config.
* There has been some discussion as happened on autoconf mailing list
to try and get around the non-update of many packages config
* Using autoreconf automatically for all packages is a big risk, but
might kinda work for the time being? (This is what happens by
default in OE, with a blacklist to disable autoreconf where it's
known to break.)
* There remains the issue of getting the upstream packages fixed
* Identifying which packages need to be fixed is not a simple task
* Suggestion: start with a list of those packages which absolutely
require fixing (on Linaro wiki), handle many cases using a change
to autoconf to use a config variable
Cross-distro compatibility
==========================
How do we make sure that software built on one distro can install and
run on others?
* Key aspects are decided already: the GNU triplet and the runtime
linker path (phew!)
* Jon suggests using LSB to provide that compatibility baseline. It
might be a large piece of work. Some ARMv8 market segments are
likely to require LSB, so this work will have to be done.
* Need regular (monthly) testing of sets of binaries across other
distros - don't wait for LSB. Contents of the test set TBD later,
but start from something simple. Perhaps hello-world, binutils,
gcc, perl, python, ruby. Maybe run a regular bake-off/plug-fest?
* How do we get distro images while the distros are under
construction? Should Linaro do this or should each distro run the
tests from other distros on their own images?
Consensus seems to be that Linaro can help with the testing, writing
scripts etc. to do some of the work, but it's up to the distros to
share their images and software periodically then do the N-way
testing.
Fedora has a git repo of the file system, and plans to provide
tarballs of this in the future.
Issues/problems?
================
Is anything blocking progress for the building?
* What's the timeline for QEMU?
+ It requires enough details about the instruction set (ARMv8
Architecture Architecture Manual)
+ Who would do this work?
+ Linaro could/should provide some coordination of the effort.
* There's (obviously) no hardware available yet. Using models to
build software is not very attractive!
+ How much do you need before you can use a highly parallel build
system (lots of models)? Generally, the number seems to be 300
packages (except Fedora with systemd's 1500 dependencies - some
tinkering may be needed!).
+ Parallel building is still some time away...
* A decent bootloader. When will we have UEFI working?
+ People are working on it, coming Real Soon Now!
+ It would be nice to avoid the proliferation of boot loaders
common on 32-bit ARM now
Involvement
===========
How can other developers get involved?
* The availability of the Foundation model and the initial images
makes this possible
* In reality most packages do not need significant work to make them
build, a small number will have to be ported to AArch64, and a
larger numer will benefit from AArch64 specific code.
* With the public model and code, it makes sense to start publishing
the distro code for wider use ASAP.
Next steps
==========
* At the next Connect, there should be distro code that runs on
ARMv8.
* Linaro should coordinate and help with the cross-distro testing.
* Planning will be done via the cross-distro mailing list.
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
[ Based on notes from
http://summit.linaro.org/lce12/meeting/20963/cross-distro-standardisation-d…
but etherpad data has a lovely habit of going away over time... ]
This was a general cross-distro session for discussion about ARM
issues. There was also a more AArch64-specific session on Tuesday
morning as part of the v8 mini-summit; I'll post notes from that next!
Distros/groups represented
==========================
* Debian
* Ubuntu
* Fedora
* Baserock
* openSUSE
* OpenEmbedded
Existing ports
==============
v7 hard-float is basically done by everybody. Steve McIntyre mopping
up last bits (glibc/binutils/ABI doc, mostly multiarch/multilib
cleanup). TODO: it would be nice to get the binutils hf/sf ABI patches
into the binutils 2.23 branch. It looks like the runtime linker stuff
is just about finished!
Question about Cortex-A15 kernel support, especially LPAE. Looks like
distros will need to ship 2 kernels for ARMv7 in this case:
LPAE/non-LPAE. There is no current way to merge these, and no plans.
ARMv8/AArch64/arm64
===================
Many distributions are starting work on porting to AArch64. Linaro
have released an initial OpenEmbedded-based filesystem which will work
in ARM's v8 models. Toolchains are available too:
http://www.linaro.org/engineering/armv8
Hopefully this will help the distros bootstrap. There are "aarch64"
tags that should be used when filing bugs in various Linaro projects
(gcc-linaro, linux-linaro, linaro-oe, etc.)
There's also a shared bug tracker at
https://launchpad.net/linaro-aarch64
for distros to use, so we don't waste time working in parallel on the
same bugs for AArch64 support. When using this, please file bug
reports in-distro first and link to these. Once fixes are accepted
upstream, mark the linaro-aarch64 bugs fixed.
Distro AArch64 status
=====================
* Ubuntu:
* http://wiki.debian.org/Arm64Port
* https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/arm64bootstrap
* Raring has all components required for armv8 cross toolchain
* Debian
* http://wiki.debian.org/Arm64Port
* Fedora
* Jon Masters has scanned the package set for assembler code,
identifying probable pain-points
Tools
=====
Steve working on strace support - 64-bit is done, working on using
64-bit strace with 32-bit binaries next. Ptrace patches for gdb are
submitted, but until things stabilise people will need to match up
kernel and tools to get things working here.
Standard install instructions for distros?
==========================================
Some discussion about how different various of the ARM boards are in
terms of setup; could/should we talk to them and give recommendations
on making them easier to work with? Ideas:
* Default boot process in server world is UEFI+GRUB. Stick with that.
* Partition layout recommondation (FAT partition for UEFI?)
* Would distros and board makers follow such doc if it existed or
will everyone prefer to "add value" in this area?
* Linaro should write doc with default recommendations, which in long
term should reduce variation and feed into SOC manufacturer boot
code
Network booting
===============
Lots of people are interested in this, especially for installing
clusters of machines like Calxeda/Dell offerings. How should people do
this? 'Use PXE' doesn't really help. There is PXE support in uboot,
developed by Calxeda. Is anybody working on PXE support in UEFI?
Linaro Enterprise Group should...
We could do with some recommendations for how this area should work -
prod the LEG people!
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
