May 2011 - arm - Fedora mailing-lists

Fedora ARM 12 on IGEPv2 (Beagle Board clone)
by Matthew Wilson 01 Jan '16

01 Jan '16

Hi all, I would like to introduce myself to the group. I have recently received an IGEPv2 board [1], which is based on the Beagle Board, but with wifi, bluetooth, ethernet, and more RAM. I'm still at the "wow, it's tiny and it runs Linux" stage. I should get a bit more time over the next month and Christmas to play around properly with it. I'm new to embedded development, but neither new to Linux nor ARM (writing my first ARM assembly some 15 years ago). However, for the past 6 years I've not even built a Linux kernel, preferring to use the default kernel in Fedora for simplicity :) Firstly, a thank you to those involved in Fedora ARM for getting it to this stage. If I get the time, I'd really like to contribute some (probably small) effort to help get Fedora ARM working well on the IGEPv2 and Beagle Board. As I progress, I'd like to know what I can do to help. In the meantime, I have some questions. Apologies in advance if these seem simple. 1) There are various different kernels from different sources. I'm used to there being a small set of "right" kernels (that is, Fedora's idea of "right") for x86. I fully appreciate that different ARM-based boards are quite different in capabilities (like different instruction set variants). a) Is there likely to be some standardised vanilla Fedora ARM kernel source? (Or is that simply the source RPM available for Fedora?) Then patches /could/ be offered for the more common systems (e.g. Beagle Board & clones, SheevaPlug). b) Would it then make sense to offer these as pre-built RPMs for common systems? c) Is there any guidance on which version is good to use as a base? I've seen quite different kernel versions being used (from 2.6.27 to 2.6.31). 2) I understand a little bit about the different calling conventions, FP differences (e.g. soft FPU versus VFP), and instruction set differences (v5 versus v7). a) Can the kernel can be safely built with a different instruction set targeted? (I know there are different optimisation options passed to GCC. Apologies if this seems a bit newbie-ish.) b) For FP-heavy programs (e.g. ogg encoding), is it possible to build the packages with VFP/NEON but still get them to work in a soft FPU system? I'd imagine any call to an external library would have to somehow be defined to use a different calling standard. 3) There seem to be some missing dependencies in the packages in the current Fedora ARM repository. For example, emacs is requiring libotf, which doesn't seem to be there in the repository. And likewise with the xorg-x11-font* packages needing ttmkdir. I'm confused as to how the RPM could have been successfully built without it. What am I missing? 4) I see there has been some discussion over unaligned data access. (Oh, I remember that from the ARM2 days.) It seems as if the Cortex-A8 cores allow unaligned data access when set up to do so [2]. Does this, in any way, help with the compatibility of packages targetting Cortex-A8? 5) I've managed to get various source packages missing from the Fedora ARM repositories to compile successfully (natively). I guess there is a reason why there are not in the repos right now -- is that reason down to time and priorities, or is there some blocking bugs with many of these packages? I look forward to being able to contribute something back into Fedora! Kind regards, Matthew [1] http://www.igep-platform.com/index.php?option=com_content&view=article&id=4… [2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344j/Beihgi…

11 15

Stable kernel 2.6.37.6 for Fedora on Toshiba AC100 and Question
by intersolar-direct 05 Aug '11

05 Aug '11

2 2

Fedora 14 on armv5tel status update
by Peter Robinson 26 Jun '11

26 Jun '11

Hi All, I've been working on getting Fedora 14 moving forward with the assistance of Dennis. I've almost got the build root done except for a few notable exceptions (glibc, python, perl, sqlite, nss I'm looking at you....) and the things that depend on them. A lot of the of the failures (python/sqlite/nss) are in the test suites so they should be relatively easy to fix. I want to try and get upstream to either fix or disable the offending issue where possible. The glibc issue is interesting... it seems its a regression from F-13, we had to apply a patch for F-13 but even with all that in place I still get some failures. So it seems to be a regression (and we're seeing it on the F-15 glibc one as well. I'll do some more testing and follow up with the logs etc so that someone more smart than I am might be able to comment and assist :-) All help and feedback welcome :-D I've setup a tracker bug for various issues here: https://bugzilla.redhat.com/show_bug.cgi?id=706236 Once I have the last of the buildroot issue cleaned up we'll release one of the automatic tools onto the dist-f14 packages and see how quickly we can get F-14 Gold out of the way and move onto the more interesting things :-D Cheers, Peter

3 4

Fedora 13 ARM Beta3 Release
by Paul Whalen 23 Jun '11

23 Jun '11

We are pleased to announce the release of Fedora 13 ARM Beta3. This release includes additional software not found in Beta2, most notably Abiword for your word processing needs. Unfortunately at this time we are not able to offer OpenOffice due to some issues with java packages ( java experts we could use your help! ). A new root file system compose is available for download – http://scotland.proximity.on.ca/fedora-arm/beta/f13/rootfs-f13-beta3-2011-0… The latest repository – http://arm.koji.fedoraproject.org/mash/beta/f13-arm-2011-05-10/f13-arm/arm/… We are again asking for feedback as we prepare for a final compose of Fedora 13 for ARM, and put all our efforts behind Fedora 14. Feedback can be forward to us via the mailing list – arm(a)lists.fedoraproject.org.

10 31

smsc95xx performance bug: eth vs usb
by DJ Delorie 22 Jun '11

22 Jun '11

This is a weird bug, has anyone else seen or fixed it? If you connect storage up to a pandaboard USB port (flash or sata), you get about 5 MB/sec throughput. Now, if you "ping -i 0.001" the pandaboard from another host, you can increase the *storage* performance to 22 MB/sec (for my disk, max 32 MB/sec on an x86 desktop). Note that the ethernet device is itself also on the same USB hub (on chip) as the device storage. This tells me that something in the smsc95xx driver is either missing an interrupt, or not polling fast enough, but I couldn't find anything. USB protocol analyzer shows that most of the time, the transfers are happening at the full speed, so it's just stopping every once in a while, killing performance. Kernel is 2.6.38.5-23.fc13.armv7l.omap from the Fedora 15 development SRPMs.

8 24

Any thoughts on running Fedora+XFCE on an Efika Smartbook?
by Niels de Vos 13 Jun '11

13 Jun '11

Hi list, I know that some of you have an Efika Smartbook (http://www.genesi-usa.com/products/smartbook) and am interested in your opinions on it. I'm looking to getting one myself, but only if there are positive experiences with it. My normal usage of such a netbook would be some browsing, emailing and some development (mainly with vim) while traveling. I assume that the 10" display is just big enough for it (a 7" EeePC is a little too small). Things I'd like some information on: - Will XFCE run without major issues? - How is the keyboard, are the keys (much) smaller than a standard laptop keyboard? - Is the display good readable when sitting outside, possibly in the sun? - Any other pros/cons you can think of. Many thanks, Niels

7 15

Hardware Crypto Offload on Kirkwood (SheevaPlug)
by Gordan Bobic 28 May '11

28 May '11

Hi, In case anyone is interested, I got this working on F13. It required building the cryptodev kernel module and rebuilding the standard F13 OpenSSL package with three additional parameters (the cryptodev support is already in the standard OpenSSL package sources, it just isn't enabled in the default build). More details available here: http://www.altechnative.net/?p=174 Any chance we can have cryptodev enabled in the standard package build? I cannot see any drawbacks to having it available - when cryptodev device isn't there, it will simply fall back to the software implementation. (Note: required cryptodev header file provided by the external kernel driver). Gordan

12 40

FWD: ANNOUNCE: Linaro Plan Reviews (May 31st to June 8th)
by Jon Masters 27 May '11

27 May '11

Sending on behalf of Christian Reis (kiko): Hello there, Starting next Tuesday, May 31st, Linaro tech leads will be running a set of public phone calls to present official plans for our engineering units. Calls are daily at 15:00 UTC, and there are local dial-in numbers for most countries around the world. Schedule and details are listed here: https://wiki.linaro.org/Cycles/1111/PublicPlanReview For each call we will provide a set of slides discussing features planned and the blueprints that specify and track them. The calls are open to the general public; anybody is welcome to dial in and listen. Questions can be asked via IRC using #linaro-meeting on Freenode; details on how to access IRC itself are also linked to from that page. Calls will also be recorded and available for later perusal. If you'd like a daily reminder of the call topic let me know and I'll put you on the reminder list. The first call, on Tuesday itself, will cover Power Management, and be hosted by Amit Kucheria. See you there, -- Christian Robottom Reis | [+55] 16 9112 6430 | http://launchpad.net/~kiko Linaro Engineering VP | [ +1] 612 216 4935 | http://async.com.br/~kiko

2 1

Hardware Crypto Offload on i.MX515 (Efika)
by Gordan Bobic 25 May '11

25 May '11

Just looking at the specsheet of the Freescale i.MX515, and this jumped out at me: Symmetric/Asymmetric Hashing and Random Accelerator (SAHARA) Lite is a cryptographic acceleration engine security co-processor Implements: * Block encryption algorithms (AES, DES, and 3DES) * Hashing algorithms (MD5, SHA-1, SHA-224, and SHA-256) * Stream cipher algorithm (ARC4) * True hardware random number generator (TRNG) Does anybody know at what kernel version the support for this was added (if it has already been added)? And since I know the Genesi guys read this list, does the Kernel+OpenSSL combo that comes with Efika have this enabled as standard? (I lent my smartbook to somebody for a few days hence why I'm asking rather than just checking - I thought I'd get a head start on trying to get this working in the same way as it does on the Kirkwood (SheevaPlug). I also notice there is this in the i.MX515: Security Controller (SCC) type 2 * AES engine * Secure/Non-Secure RAM * Support for multiple keys and TZ/non-TZ separation Does this mean there are two independent AES crypto co-processors in there? What about kernel support? Gordan

3 7

Re: [fedora-arm] Hardware Crypto Offload on Kirkwood (SheevaPlug)
by Gordan Bobic 25 May '11

25 May '11

Jason Burrell wrote: > > NSS supports PKCS#11 which most hardware crypto accelerators > (including > > things like smartcards and offloading coprocessors) use. As far as I > > know, the only OpenSSL PKCS#11 library is external to it, from the > > OpenSC people. > > Hmm... Are the relevant kernel drivers and interfaces in place for > PKCS#11 for any of the crypto offload engines discussed (Kirkwood, > Tegra, Freescale)? Can somebody point me at the relevant interface docs? > > > Generally, the CPU-based "crypto" hardware is actually just a few > acceleration functions, so you don't usually access it through PKCS#11. > I know NSS supports the Intel AES instructions directly (not via > PKCS#11), so it should be possible to add others as well. Accelerating instructions are something for the compilers and assemblers to deal with. I was specifically talking about asynchronous offload engines that ARM SoCs often to have. > So are you saying that the number of organizations that _don't_ use > OpenSSH, OpenLDAP, mod_ssl, etc. is greater than those that do (limiting > the field here to those that use some unix-like OS)? That would surprise > me if it really is the case. > > > I don't have figures as to the number of deployments of any of those > tools, but only OpenSSH is listed as not yet supporting NSS anyway. > > I do think there are many deployments of OpenSSL that aren't following > its license's advertising requirements. As you stated, OpenSSH is used > pretty much everywhere, but I don't even remember the last time I saw a > statement saying a product included software from OpenSSL, except in > hidden about boxes, which isn't what a clear reading for the Four-clause > BSD license states. Just out of interest, have OpenSSL maintainers complained at having just about every distribution on the planet break their licencing terms? Gordan

3 2

Re: [fedora-arm] Fedora 14 on armv5tel status update (Peter Robinson)
by intersolar-direct 25 May '11

25 May '11

1 0

Re: [fedora-arm] Fedora 14 on armv5tel status update (Peter Robinson)
by intersolar-direct 25 May '11

25 May '11

1 0

Re: [fedora-arm] Fedora 14 on armv5tel status update (Peter Robinson)
by intersolar-direct 25 May '11

25 May '11

1 0

Re: [fedora-arm] Hardware Crypto Offload on Kirkwood (SheevaPlug)
by Gordan Bobic 25 May '11

25 May '11

Jason Burrell wrote: > On May 25, 2011 6:06 AM, "Gordan Bobic" <gordan(a)bobich.net > <mailto:gordan@bobich.net>> wrote: > > > > Andrew Haley wrote: > > > > >> I'm not against NSS - really I'm not. But there are other > considerations > > >> to be taken into account. > > >> > > >> 1) Does NSS have any kind of support for hardware crypto offload? > If so, > > >> I haven't found any references to it (but maybe my google-foo is weak > > >> today). > > > > > > Interesting question; not sure. > > > > I think it is an important one to answer, and sooner rather than later. > > This is particularly important to the ARM community since a lot of > > (most?) ARMs seem to have a crypto co-processor of some description > > (Freescales, Kirkwood and Tegra definitely seem to have this, I haven't > > checked others, but since these are the three classes of devices I own, > > that's 3 out of 3 - I don't think it's luck/coincidence). > > > > This is particularly important for server applications. ARM is getting > > some traction in the server market. ZT make a really nice (if expensive) > > multi-ARM server. I have seriously discussed using ShevaPlugs/GuruPlugs > > specifically for large scale-out low-power SSL offload with clients. > > Crypto offload support is already important, and it's importance is only > > going to go up. > > > > NSS supports PKCS#11 which most hardware crypto accelerators (including > things like smartcards and offloading coprocessors) use. As far as I > know, the only OpenSSL PKCS#11 library is external to it, from the > OpenSC people. Hmm... Are the relevant kernel drivers and interfaces in place for PKCS#11 for any of the crypto offload engines discussed (Kirkwood, Tegra, Freescale)? Can somebody point me at the relevant interface docs? > > >> 3) Volume of supported commonly used software - if NSS has a clear > > >> advantage in terms of support base, then so be it, let's all put our > > >> weight behind it. But my perception is that this is not the case. > > >> Everything I touch upon on a daily basis seems to be linked against > > >> OpenSSL rather than NSS. > > > > > > Well, that's not true for everyone, and certainly not for users of > > > GPG. > > > > I thought it was mentioned on this thread recently that GPG brings it's > > own implementation anyway. Did I misunderstand? > > > > > But the real question is whether one group of Fedora developers is > > > determinedly going to push NSS and the other OpenSSL. That is not a > > > route to happiness. > > > > It's not, but losing crypto offload and/or a performance drop-off and > > bloat due to shimming isn't a happy solution, either. If we can address > > those (the latter by sending patches to build against NSS upstream so > > shimming isn't required), then it'd be a great idea. > > > > But purely in terms of standardizing on a single crypto library - has > > anyone actually performed an exhaustive analysis on how much would need > > to be changed to go either way? The wiki page that has been referenced a > > few times seems distinctly non-exhaustive. Maybe my perception is > > non-representative here, but as I said, all the things I get my hands > > dirty on a regular basis are linked against OpenSSL rather than NSS. The > > pragmatist in me says that maybe that makes OpenSSL a better target to > > standardize on, but I would like to see an exhaustive analysis / > > empirical evidence showing otherwise. > > > > "FIPS" OpenSSL isn't the same thing as "normal" OpenSSL. From OpenSSL's > own FIPS docs, "The FIPS Object Module is the special monolithic object > module built from the special source distribution identified in the > Security Policy. It is not the same as the OpenSSL product or any > specific official OpenSSL distribution release." > > So requiring FIPS (which the US gov't and many large organizations do) > undermines the argument that OpenSSL is used more extensively. So are you saying that the number of organizations that _don't_ use OpenSSH, OpenLDAP, mod_ssl, etc. is greater than those that do (limiting the field here to those that use some unix-like OS)? That would surprise me if it really is the case. Gordan

1 0

Fwd: [Fedora-trans-ru] Выпуск Fedora 15
by Misha Shnurapet 24 May '11

24 May '11

1 0

Re: [fedora-arm] Hardware Crypto Offload on Kirkwood (SheevaPlug)
by Gordan Bobic 24 May '11

24 May '11

On 05/24/2011 07:27 PM, Alexander Boström wrote: > mån 2011-05-23 klockan 15:15 +0100 skrev Gordan Bobic: > >> What I'm pondering now is something like a dkms package for the >> cryptodev kernel module, but I seem to remember reading somewhere that >> dkms is a non-Fedora RHEL thing. What do you guys think would be the >> best way to approach it, especially since we don't have "standard" >> kernels at the moment? > > It's probably a lot easier to just patch your kernel build (or ask > whoever builds your kernel to do it). Then you won't need kernel build > tools installed on your little arm device. I really don't think that's a big deal. Cryptodev module takes seconds to build, and even if you are building your own kernel, it means you can just install the new kernel, and the new module with automatically be built for it. So it still saves effort. > Anyway, you'll also need support in various libraries and applications, > which means that cryptodev.h must be available somewhere. The right > place to put that is probably glibc-devel or kernel-headers, but that's > not likely to happen until the support is in the mainline kernel. I was thinking about including it in the dkms-cryptodev package. After all, it is cryptodev module that brings it along. > I suggest you try to help get cryptodev upstreamed into kernel.org or > figure out why that hasn't happened. Once there's a solution in place > upstream it's a lot easier to let the code trickle down naturally into > all kernels and get support added to various related components. My experience on the lkml has been that it's pretty difficult to not get ignored. Perhaps somebody better established there might stand a better chance. Gordan

2 4

Fedora on PandaBoard
by orb 19 May '11

19 May '11

Hello, Can someone point me to some basic instructions on getting fedora up and running on OMAP4 PandaBoard? I would like to update omappedia.org with basic instructions on getting this distro up. I am new to fedora so I would appreciate a good place to start. I tried downloading F13 release based on this thread -- http://lists.fedoraproject.org/pipermail/arm/2011-May/001271.html -- but I am unable to download it. Is there another place I can get this? Can someone post/send some binaries for me to try? Any help on this matter would be greatly appreciated. Thanks Omar Barron

2 1

F13 Beta 3 - wrong yum repos?
by Quentin Armitage 18 May '11

18 May '11

F13 Beta 3, at least at http://arm.koji.fedoraproject.org/mash/beta/f13-arm-2011-05-10/f13-arm/arm/… has fedora-release-13-1.2.beta2.noarch.rpm but presumably this should be beta3. Looking at the /etc/yum.repos.d/*repo files in that package, they not surprisingly point to http://arm.koji.fedoraproject.org/mash/beta/f13-arm-2011-03-23/f13-arm/arm/… which are the Beta 2 packages. Presumably, if Beta 3 is installed, then any additional packages installed via yum will pull in the Beta 2 packages. The only packages that I have installed on Beta2 that are upgraded in Beta3 are thte gcc suite and perl-version. I intend to edit the /etc/yum.repos.d/* files to point to the new location and install them; presumably that's an easy way to get to Beta3. Hope this make sense, Quentin Armtitage.

1 1

Should we and where could we document tasks and their progress?
by Niels de Vos 17 May '11

17 May '11

Hello all, there is quite some activity on this list about different topics, this is really encouraging! I'm just wondering how (I and possibly others) can keep track of all this. Some of the topics are quite difficult to keep up with and some pointers to the current status or options would be very useful imho. Personally I only have some hours distributed across the week to spend on Fedora ARM. I'd like to use that time as effective as possible, and that would include writing down what I did so that others can continue where I left. Some of the goals/topics that were recently discussed and which I think that would benefit from some kind of tracking-page: - Compile options, optimizations and multi-lib (at least for an overview of considerations, comparisons and decisions) - kernel package(s) - bootloader integration - updated buildroots for mock/koji One way of tracking progress and creating some documentation would be a page in the wiki, something like the Feature pages as has been done for - systemd: https://fedoraproject.org/wiki/Features/systemd - GNOME 3: https://fedoraproject.org/wiki/Features/Gnome3 An other option would be to file a bug in bugzilla or a ticket (https://fedorahosted.org/arm/) and work from there. For small things this might work, for larger tasks that require more working together it might be unsuitable. On other topics like the optimizations it might be sufficient to a linaro forum where most of the discussions take place. For a generic kernel package a git-repository (like "fedpkg clone kernel") could possibly work out as well. My main interest would be to have it listed in a place where I can find it and read-up. I'm happy to start documenting some specific topics, but would like some opinions from the rest of you. Thanks, Niels

1 0

fsck.ext3?
by Scott M. Jones 15 May '11

15 May '11

I'm trying the F13-beta3 rootfs on a Beagleboard-XM and I get this at bootup: fsck: cannot check /dev/mmcblk0p2: fsck.ext3 not found fsck: cannot check /dev/mmcblk0p2: fsck.ext3 not found I checked in /sbin and there is a fsck.cramfs but no fsck.ext3. My root partition is ext3. I am able to fsck by moving the SD card to an F14/Intel system, but is there a package I can add to get the ext3 fsck on ARM? Thanks, Scott

3 2

armv7hl requirements
by Jon Masters 13 May '11

13 May '11

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.

15 48

aapcs-vfpv3 "hardfp" update
by Jon Masters 13 May '11

13 May '11

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.

1 0

Fedora 2.6.38 kernel for ARM-OMAP
by d.marlin 11 May '11

11 May '11

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

1 0

Re: [fedora-arm] Linaro Developer Summit
by Jon Masters 08 May '11

08 May '11

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

1 0

Linaro Developer Summit
by Jon Masters 07 May '11

07 May '11

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.

2 1

armv7hl VFP notes
by Jon Masters 04 May '11

04 May '11

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/index.… 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.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

arm May 2011