arm July 2011

arm@lists.fedoraproject.org

25 participants
47 discussions

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

Pogoplug Pro/OXNAS
by Callum Lerwick 24 Nov '11

24 Nov '11

Hi. I've been looking for a way to get a very power efficient, but still full featured Fedora server for a while, and the recent influx of "plug computers" finally provides the answer. Long story short, I ended up snagging a Pogoplug Pro on sale at Micro Center for $50, before I learned that the Pro is NOT derived from the Kirkwood reference design, but is a completely different architecture called OXNAS from Oxford Semiconductor/PLX. As far as my googling can tell, the recent "black" generation of Pogoplug hardware seems to be the only product in the world using the OXNAS 820 SoC right now. It looks like the WD MyBook uses/used an earlier OXNAS 810 chipset. http://www.plxtech.com/products/consumer/nas7820 http://www.linuxfordevices.com/c/a/News/PLX-Technology-NAS-7800/ It is also "cost reduced" from earlier Pogoplugs, having only 128mb RAM and 128mb of flash. Its a bit slower at 700mhz but is somewhat compensated for by being dual-core. On the up side, there is in fact a SATA port hidden inside the Pogoplug Pro. It also has some interesting features like TCP offload and supposedly an encryption engine. (but I haven't seen any sign of support for the encryption engine in the Cloud Engines source so far) There's also a mini-PCIe slot containing the Pro's wireless card. Anyway, I managed to get Fedora 13 beta3 running on it by first installing PlugApps on it, then I just swapped in a Fedora root FS: http://archlinuxarm.org/platforms/armv6/pogoplug-provideov3 Make sure to copy /lib/modules and /usr/local over from the PlugApps FS. The network driver is compiled as a module, and it will not auto load. Especially if you don't have a serial console set up, before booting you'll need to pop in a script at /etc/sysconfig/modules/oxnas-gmac.modules : #!/bin/sh exec /sbin/modprobe gmac >/dev/null 2>&1 Make sure it is chmod 755 Also the driver wants firmware for the TCP offload, and seems to have a bug where it will just lock up the system if it can't find it. You'll find it at /lib/modules/2.6.31.6_SMP_820/gmac_copro_firmware , just move it to /lib/firmware/ and you should have working ethernet. There's some weirdness with the MAC address, the driver just sets it to a hardwired default of "00:30:E0:00:00:00" as there does not seem to be in-kernel infrastructure to read uboot variables. The PlugApps install script writes the MAC into /usr/local/mac_addr and the network scripts change it before bringing the interface up. I don't understand why they don't just read it directly from NVRAM using /usr/local/cloudengines/bin/blparam . But currently my Pogoplug Pro is just using the default MAC. Setting the MAC properly should be a simple matter of scripting... Unfortunately the PlugApps kernel is very minimal. It does not have any NFS server support enabled, and for some reason ext4 is compiled as a module, so your root FS has to be ext2 or ext3. I managed to successfully compile the Cloud Engines kernel source and write it to flash just past the original PlugApps kernel, so the original PlugApps kernel and even the stock Pogoplug OS can still be booted in a pinch using the uboot console. (But I may have overwritten a backup Pogoplug kernel...) http://www.pogoplug.com/developers-open-source.html If you do not have a serial console set up, do NOT mess with the flash! If you screw up the boot sequence, there is no way to un-brick these things without one. There is NO "reset nvram to defaults" button. I'd really like to run btrfs on this, but the stock kernel is 2.6.31, and my research indicates you want at least 2.6.33 for stable btrfs. Also, support for the wireless card was merged in 2.6.34. I have successfully upgraded the kernel through the incredibly awkward and time consuming (but educational) method of applying the Cloud Engines changes to 2.6.31 in a git branch, then rebasing 2.6.32 on top of it. So my Pogoplug Pro has been running 2.6.32 for the last few months with no problem. I'll see about pushing forward further once I have some time to kill. (Pretty much takes a full day for my old secondary laptop to chew through the whole rebase...) So now I have my Pogoplug Pro working nicely as a Samba server for my windows machines, and a NFS4 server for my Fedora machines. I originally wanted to run a MythTV backend on it, but that may be pushing it a bit with only 128mb RAM. Not to mention the fun of getting MythTV compiled for Fedora arm in the first place...

2 1

Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY
by Jon Masters 26 Aug '11

26 Aug '11

Folks, We are hosting another one of our regular Fedora 15 hardfp Virtual Fedora Activity Day today Friday July 15th, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the bootstrap of F15 hardfp (hardware floating point). Last week, we succeeded in reaching a point where we had yum running natively, and after that rapidly went from just under 100 native binary RPMs built to 793 right now! We still do not have all of the dependencies for mock, but we hope to be there soon. We need your help, if you have the time, hardware, and interest in doing so. Together, we can reach a point of running mock, then rebuild all of the packages we have so far natively within a mock, and ultimately have a Koji buildroot sufficient to officially rebuild everything within the standard Fedora ARM Koji infrastructure. You can find a lot more detail here about the stages involved in bringup (we are at stage 3), along with all the pre-reqs/bits: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap_… For general bootstrapping series information: https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap Be sure you follow the instructions to use an armv7hl-YOUR_FAS_USERNAME or group name branch on the Fedora ARM git repo so that we can track who is doing what, and more easily back out changes if you/we discover a problem with your setup. Jon.

2 3

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

05 Aug '11

2 2

Re: [fedora-arm] Centos rootfs
by Donald Gullett 03 Aug '11

03 Aug '11

Compiling the packages is not a problem as i am compiling a load of f14 and f15 packages now. Chris Tyler <chris(a)tylers.info> wrote: >On Sun, 2011-07-31 at 01:32 -0400, Donald Gullett wrote: >> Can anyone point me in the direction of information on building a centos rootfs? > >You'd have to compile a substantial portion of the CentOS package >collection for ARM, then create a rootfs based on that. > >> How was the fedora rootfs setup derived? Was it a posted redhat >> document or procedure or an existing fedora installed system? > >It's a hackish script that runs against the ARM package repo. A >kickstart-based solution will get written in due course, I'm sure. > >-Chris > >_______________________________________________ >arm mailing list >arm(a)lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/arm >

2 1

Re: [fedora-arm] Advice for tablets to run Fedora ARM on?
by Stuart Mumford 02 Aug '11

02 Aug '11

Hello, I have an Advent Vega, which costs 200 GBP and has a NVidia tegra and a full size USB A port and HDMI port. I would be willing to test / work on a Fedora bulid for such a device. Stuart

3 5

[F15] NFS boot [howto]
by Zoran Pericic 02 Aug '11

02 Aug '11

This is how I configured NFS root on my pandaboard. There is also complete boot partition in [1] 1) Install grubby, u-boot and dracut-network from my repo [2] 2) Install kernel-omap. This kernel have path that allow you to set mac address for smsc95xx with smsc95xx.macaddr kernel boot argument. 3) Change KERNEL_ARG in /etc/sysconfig/uboot for dracut network boot [3] KERNEL_ARGS="ro vram=32M root=dhcp fixrtc console=ttyO2,115200 mem=460M@0x80000000 mem=512M@0xA0000000 omapdss.def_disp=dvi smsc95xx.macaddr=5A:3E:83:2D:BA:41 selinux=0" 4) Add option "root-path=SERVER:PATH" to dhcp server host pandaboard1 { hardware ethernet 5a:3e:83:2d:ba:41; fixed-address 10.21.38.31; option root-path "10.21.38.4:/nfs/pandaboard1-fc15"; } 5) Run "flash-kernel --update-bootscript 2.6.38.8-36.06.fc15.armv7hl.omap" [1] http://zpericic.fedorapeople.org/boot/ [2] http://zpericic.fedorapeople.org/RPMS/ [3] http://fedoraproject.org/wiki/Dracut/Options#Network

3 5

About arm choice of toolchain options
by Paulo César Pereira de Andrade 02 Aug '11

02 Aug '11

Hi, Sorry for the cross post and long email :-) Currently I am working on a very initial state build of Mandriva for arm. Thanks to Jeff Johnson for giving me ssh access to armv7 hosts, and Matthew Dawkins for building several Mandriva/Unity linux armv5 packages. What I am trying to understand now is about choice of float abi. I understand that the IHI0042D_aapcs.pdf file I donwload says to use vfp registers for float/double arguments, but softfp seems too good to miss, as armv5 should be around for some time yet. So, I have two chroots, running: softfp# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7l-mandriva-linux-gnueabi/4.6.1/lto-wrapper Target: armv7l-mandriva-linux-gnueabi Configured with: /home/pcpa/bootstrap/rpmbuild/BUILD/gcc-4.6-20110722/configure --prefix=/usr --build=i586-mandriva-linux-gnu --host=armv7l-mandriva-linux-gnueabi --target=armv7l-mandriva-linux-gnueabi --enable-werror=no --enable-cxx --with-cpu=cortex-a8 --with-tune=cortex-a8 --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-abi=aapcs-linux --enable-languages=c,c++ --enable-threads=posix --disable-libssp --disable-libmudflap Thread model: posix gcc version 4.6.1 20110722 (Mandriva) (GCC) thumb# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7l-mandriva-linux-gnueabi/4.6.1/lto-wrapper Target: armv7l-mandriva-linux-gnueabi Configured with: /home/pcpa/bootstrap/rpmbuild/BUILD/gcc-4.6-20110722/configure --prefix=/usr --build=i586-mandriva-linux-gnu --host=armv7l-mandriva-linux-gnueabi --target=armv7l-mandriva-linux-gnueabi --enable-werror=no --enable-cxx --with-cpu=cortex-a8 --with-tune=cortex-a8 --with-arch=armv7-a --with-mode=thumb --with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux --enable-languages=c,c++ --enable-threads=posix --disable-libssp --disable-libmudflap Thread model: posix gcc version 4.6.1 20110722 (Mandriva) (GCC) This is unmodified upstream gcc, and using a set of bootstrap scripts from a git branch I made on a checkout of git clone git://fedorapeople.org/~djdelorie/bootstrap.git Since I am still very "arm noob" :-) and just yesterday did the thumb build to learn about thumb, so far, my impression is that the best approach should be to use thumb+softfp. Just so you know I am running thumb and arm builds, with thumb using hard float and the softfp with arm instructions set: softfp# objdump -d /usr/lib/libm.so | less [...] 00008d30 <__ieee754_atan2>: 8d30: e3a0c000 mov ip, #0 8d34: e347cff0 movt ip, #32752 ; 0x7ff0 8d38: e92d4030 push {r4, r5, lr} 8d3c: ed2d8b10 vpush {d8-d15} 8d40: e3a05000 mov r5, #0 8d44: ec432b18 vmov d8, r2, r3 8d48: e3475ff0 movt r5, #32752 ; 0x7ff0 8d4c: e003c00c and ip, r3, ip 8d50: e15c0005 cmp ip, r5 8d54: e24dd02c sub sp, sp, #44 ; 0x2c 8d58: e1a04003 mov r4, r3 8d5c: ec410b19 vmov d9, r0, r1 8d60: e1a05002 mov r5, r2 8d64: 0a000022 beq 8df4 <__ieee754_atan2+0xc4> [...] thumb# objdump -d /usr/lib/libm.so | less [...] 00007884 <__ieee754_atan2>: 7884: 2100 movs r1, #0 7886: 2000 movs r0, #0 7888: f6c7 71f0 movt r1, #32752 ; 0x7ff0 788c: ec53 2b11 vmov r2, r3, d1 7890: f6c7 70f0 movt r0, #32752 ; 0x7ff0 7894: 4019 ands r1, r3 7896: 4281 cmp r1, r0 7898: e92d 03f0 stmdb sp!, {r4, r5, r6, r7, r8, r9} 789c: ed2d 8b10 vpush {d8-d15} 78a0: 461c mov r4, r3 78a2: b08a sub sp, #40 ; 0x28 78a4: eeb0 8b41 vmov.f64 d8, d1 78a8: 4616 mov r6, r2 78aa: eeb0 9b40 vmov.f64 d9, d0 78ae: d03c beq.n 792a <__ieee754_atan2+0xa6> [...] I am kind of trying to figure what "The Industry" says about it, and just checked the linaro gcc-4.6 relevant changes for me right now, that are... + --with-arch=armv7-a --with-tune=cortex-a8 \ + --with-float=$(float_abi) --with-fpu=neon \ +# check if we're building for armel or armhf +ifeq ($(DEB_TARGET_ARCH),armhf) + float_abi := hard +else ifneq (,$(filter $(DEB_TARGET_ARCH), arm armel)) + float_abi := softfp +endif If I understand correctly, neon will have better support for simd instructions right? Either way, I used two simple benchmarks to try to sell myself the idea of breaking compatibility with armv5 or older binaries, but still not convinced, but, as I said, we should use whatever "The Industry" chooses :-) I used for benchmark http://www.tux.org/~mayer/linux/bmark.html and http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Why-ARMs-EABI… and also compared with my home computer (quad)core i5 x86_64, and attached results... Thanks and again sorry for cross posting and long email, Paulo

5 9

Configuring mock
by Jon Masters 01 Aug '11

01 Aug '11

Dennis, I suspect I just need a few hours doing something else (like sleeping), but I hit a small bump configuring mock. I can see that you use several repos - including on i386 for group deps (cool). However, my mock refuses to recognize the Scotland armv7hl repo. I will look at it in a few hours, should be easy to fix but just annoying. If you have something I don't, like a patch to mock, let me know. Jon. -- Sent from my phone - message formatted and/or shortened accordingly.

3 6

Centos rootfs
by Donald Gullett 31 Jul '11

31 Jul '11

Can anyone point me in the direction of information on building a centos rootfs? How was the fedora rootfs setup derived? Was it a posted redhat document or procedure or an existing fedora installed system?

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

arm July 2011