armv7hl requirements
by Jon Masters
Folks,
I'd like to kick off a discussion about flags for ARMv7. My proposal
here is that we treat v7hl as an entirely different architecture, and
don't try any multi-arch kind of hacks (there isn't the established user
base for Fedora ARM to justify doing any of those things at the moment).
Things I think we should consider as a minimum:
*). Little endian (obviously, but worth stating) (l)
*). Cortex-A8 or higher fully compliant core(s)
*). ARM VFP3 hardware floating point (h)
*). ARM NEON Architecture
*). Thumb2 interworking
*). Your suggestion here?
I think we should build for ARM (as opposed to Thumb2) but we should
support interworking with Thumb2 code through the toolchain options. We
should then later consider implementing some Thumb2 optimization. It's
more armv7thl, but the (t) is implied since it's ARMv7 anyway.
Several folks have begun looking at toolchain bringup based on the F-15
toolchain applied to an F-13 userspace initially. But I'd like us to
discuss options/requirements for toolchains before we go too far.
Once I get some feedback, I'll be updating the wiki, along with some
more F-15 goals and (hopefully) generally useful stuff.
Jon.
12 years, 12 months
aapcs-vfpv3 "hardfp" update
by Jon Masters
Folks,
I met with various Linaro, ARM, Canonical, and Debian folks to discuss cross-distro compatibility as far as ABI. I will followup, including details of the Linaro forum we will use for discussion.
Jon.
--
Sent from my phone - message formatted and/or shortened accordingly.
12 years, 12 months
Fedora 2.6.38 kernel for ARM-OMAP
by d.marlin
I was looking to try a newer kernel on the beagle board and panda board
I was using (both running F13), and decided to try building 2.6.38 from
the Fedora 15 SRPM. I modified the spec file to include an option to
build for armv7l, and added an armv7l config file, as well as armv7l
support in Makefile.config. I also included one 2.6.39 upstream patch
(PandaBoard-remove-unused-power-regulators).
All the source and binary packages I built are in:
http://people.redhat.com/dmarlin/packages/FedoraArm/
I built a kernel from the following source package:
SRPMS/kernel-2.6.38.5-24.01.fc13.src.rpm
using the F13 tools on the panda board, and installed and booted it on
both the beagle and panda boards. The command I use to build it is:
rpmbuild -bb --target=armv7l SPECS/kernel.spec
Before installing the kernel binary RPM, I installed new linux-firmware
and grubby RPMs on the boards. The 2.6.38 kernel requires a newer
version of linux-firmware than is available in the F13 ARM repo, so I
rebuilt the one from F15. The new grubby package is not really
necessary, but I patched it to be armv7l aware, otherwise it defaults to
x86 (and looks for lilo or grub bootloaders). The modifications also
provide a placeholder in case I wanted to modify it further to create
the uboot images for the beagle/panda boards.
To install the kernel on the panda board I just use:
rpm -ivh kernel-omap-2.6.38.5-24.01.fc13.armv7l.rpm
It takes a while to install, since it has to install all the modules,
make an initramfs, etc.
I keep all the uboot files in /boot/uboot. To build the uboot images
for this kernel I use:
cd /boot
mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000
-n 2.6.38.5-24.01.fc13.armv7l.omap -d
vmlinuz-2.6.38.5-24.01.fc13.armv7l.omap
uboot/uImage-2.6.38.5-24.01.fc13.armv7l.omap
mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n initramfs -d
initramfs-2.6.38.5-24.01.fc13.armv7l.omap.img
uboot/uInitrd-2.6.38.5-24.01.fc13.armv7l.omap
I then reboot the board from the console, and interrupt the auto-boot
script. The commands I use to boot and test the new kernel on the panda
board are:
setenv mpurate 800
setenv bootargs console=ttyO2,115200n8 mem=463M ro rootwait
root=/dev/mmcblk0p4 mpurate=${mpurate} init=/sbin/init earlyprintk
rd_NO_PLYMOUTH
setenv bootcmd 'mmc rescan 0; mmc init; fatload mmc 0:1 0x80300000
uImage-2.6.38.5-24.01.fc13.armv7l.omap; fatload mmc 0:1 0x81600000
uInitrd-2.6.38.5-24.01.fc13.armv7l.omap; bootm 0x80300000 0x81600000'
boot
Your options may differ, depending on your flash configuration, uboot
version, etc., but these work for me.
I have not preformed extensive testing, but it does boot and seems to
work well on the F13 rootfs.
Notes:
I have only modified this to build for armv7l. Further modifications
will be necessary for other variants.
The config file I used is based on an older existing ARM config, so
I'm sure the options are not optimal.
The config file does not follow the Fedora conventions (broken down
between the generic, arch, and board config files).
I'm not sure the best way to break this out and maintain it, so
suggestions are welcome.
Please let me know if you have any questions, comments, or suggestions.
d.marlin
12 years, 12 months
Re: [fedora-arm] Linaro Developer Summit
by Jon Masters
Great. Already planned to be im those sessions :) Will come say hi tomorrow...catching up on work tonight. Staying at New York Palace (the overflow hotel down the street).
Jon.
--
Sent from my phone - message formatted and/or shortened accordingly.
-----Original Message-----
From: Michael Hope [michael.hope(a)linaro.org]
Received: Saturday, 07 May 2011, 22:51
To: Jon Masters [jonathan(a)jonmasters.org]
CC: Fedora ARM secondary architecture list [arm(a)lists.fedoraproject.org]
Subject: Re: [fedora-arm] Linaro Developer Summit
On Sun, May 8, 2011 at 8:26 AM, Jon Masters <jonathan(a)jonmasters.org> wrote:
> Folks,
>
> I am attending the Linaro Developer Summit next week. If anyone else is
> attending, please do say hi! Also, if there are topics you think are of
> interest to the Fedora ARM project that I might or might not have
> already thought about, let me know if I can do anything useful :)
Hi Jon. I'm keen to meet up and talk about the ARMv7 hard float port.
You might be interested in the toolchain sessions:
http://summit.ubuntu.com/uds-o/track/linaro-toolchain/
and what we currently support:
https://wiki.linaro.org/WorkingGroups/ToolChain/Flyer
Come and say hello! I'm the guy at:
https://wiki.linaro.org/MeetTheTeam#Toolchain
-- Michael
_______________________________________________
arm mailing list
arm(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
13 years
Linaro Developer Summit
by Jon Masters
Folks,
I am attending the Linaro Developer Summit next week. If anyone else is
attending, please do say hi! Also, if there are topics you think are of
interest to the Fedora ARM project that I might or might not have
already thought about, let me know if I can do anything useful :)
I'll send a followup with some notes from the event.
Jon.
13 years
armv7hl VFP notes
by Jon Masters
Folks,
This might be of use to someone else trying to figure this out. I am
going to followup with a thread proposing some flags to consider for
building toolchains based around a minimum of VFP3 *AND* NEON (with some
emphasis on discussion about the latter), and Thumb2 interworking. But
for now, you might find this useful if you're trying to figure out which
way is up when it comes to some of the ARM ABI nomenclature.
ARM has had several ABIs over the years. Linux blazed a trail (OABI)
prior to the real ARM-backed standardization that is known as the
official "Application Binary Interface (ABI) for the ARM Architecture".
This is frequently referred to as EABI, though that is not its name and
there is only a minor reference to that in the docs. You really want to
look at the ABI documentation, of which there are many different levels:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0044d/inde...
There is an overview PDF document there, and also the specifics for ELF,
DWARF, and for the Procedure Call Standard for ARM Architecture (AAPCS).
To start reading, visit "ABI for the ARM Architecture (Base Standard)":
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0036b/IHI0036B_bsabi.pdf
However. The real dirt you're looking for is documented in the AAPCS
(which replaced the APCS/even earlier stuff), which you can find here:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf
Specifically, section 6 alludes to "The Standard Variants" and talks
about modifications for improved performance on VFP. Basically, a
sub-variant of the AAPCS that is ABI incompatible with the base. This
seems to be referred to around the interwebs as aapcs-vfp, for example
by some of the gcc folks, though the official document on ARM's website
cunningly manages to avoid having any useful references to that name, or
to specifically calling out this as the official "hard float ABI".
Anyway, it seems when we're talking about "The hardfp ABI", what we
really mean is aapcs-vfp. Unless I'm smoking something, can we all
please use the real names for things so we give others a hope of
figuring this stuff out without trawling through piles of docs :) I
can't speak for other projects, but I'd like it if we did! Then I'd like
it if the official docs would be fixed to make this more clear too!
Jon.
13 years