I would like to introduce myself to the group. I have recently
received an IGEPv2 board , 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
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
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) 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 .
Does this, in any way, help with the compatibility of packages
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!
today I posted first enablement patches for Cavium Thunder.
See here for the thread:
The patches are publicly hosted on kernel.org:
We will add more patches for Thunder soon.
Please take a look at the patches and consider them for integration
into the arm64 Fedora kernel. Let me know if you have questions or how
I could help adding Thunder support to Fedora.
I will also be at Flock in Prague next week. Maybe we can meet there
and start a discussion on this.
----- Forwarded message from Robert Richter <rric(a)kernel.org> -----
Subject: [PATCH 0/5] arm64, thunder: Enable Cavium Thunder SoC Family
Date: Wed, 30 Jul 2014 17:06:29 +0200
From: Robert Richter <rric(a)kernel.org>
To: Catalin Marinas <catalin.marinas(a)arm.com>, Will Deacon <will.deacon(a)arm.com>, Rob Herring <robh+dt(a)kernel.org>, Arnd Bergmann <arnd(a)arndb.de>
Cc: linux-kernel(a)vger.kernel.org, linux-arm-kernel(a)lists.infradead.org, Robert Richter <rrichter(a)cavium.com>
X-Mailer: git-send-email 2.0.1
From: Robert Richter <rrichter(a)cavium.com>
This initial patches enable Cavium Thunder SoC Family. The patches add
Kconfig and devicetree support and then add Thunder to the defconfig.
The last patch is unrelated to Thunder and enables the tmpfs mount
option for a more convinient use of defconfig with distros.
The Thunder system needs more enablement patches for subsystems and
devices, this includes network, ahci, gicv3/gicv3-its, pci, smmu, kvm.
We will send separate patch sets for these. All of them base on this
Patches are available here:
Radha Mohan Chintakuntla (3):
arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family
arm64, thunder: Add initial dts for Cavium Thunder SoC
arm64, thunder: document devicetree bindings for Cavium Thunder SoC
Robert Richter (2):
arm64, defconfig: Enable Cavium Thunder SoC in defconfig
arm64, defconfig: Enable tmpfs mount option
.../devicetree/bindings/arm/cavium-thunder.txt | 10 +
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
arch/arm64/Kconfig | 6 +
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/thunder-88xx.dts | 387 +++++++++++++++++++++
arch/arm64/configs/defconfig | 2 +
6 files changed, 407 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/cavium-thunder.txt
create mode 100644 arch/arm64/boot/dts/thunder-88xx.dts
----- End forwarded message -----
In case you do not know yet: there is no virtualisation support
in Fedora 21 on APM Mustang. Looks like one of 3.18-rc commits
went into 3.17/stable tree and disabled it for us.
Added into to https://bugzilla.redhat.com/show_bug.cgi?id=1165290
[root@pinkiepie virt]# LC_ALL=C virsh create hrw-f21.xml
error: Failed to create domain from hrw-f21.xml
error: unsupported configuration: Domain requires KVM, but it is not available. Check that virtualisation is enabled in the host BIOS, and host configuration is setup to load the kvm modules.
[root@pinkiepie virt]# dmesg|grep -i kvm
[ 0.303959] kvm : GICV size 0x2000 not a multiple of page size 0x10000
[ 0.303965] kvm : error: no compatible GIC info found
[ 0.304070] kvm : error initializing Hyp mode: -6
[root@pinkiepie virt]# uname -a
Linux pinkiepie 3.17.4-301.fc21.aarch64 #1 SMP Sun Nov 30 20:41:43 UTC 2014 aarch64 aarch64 aarch64 GNU/Linux
Recently I tried F21 on that board. The result was a bit disappointing...
Apperently Fedora has several issues with that hardware:
- thermal shutdown, after message something like "kernel trap/thermal
- wlcore module error
- some other error, possibly related to swap module /Need to redo testing
here, not captured on logs/
What do You think? What is advisable to do /if any/ in this situation?
I have some time, maybe can provide ssh/vnc access, if somebody is
interested to examine issues.
However, in that case we probably have to do something with that termal
I'm not experienced with specific kernel things that maybe involved.
Release Candidate 7 is out.
- kernel 3.17.4-302 to fix serial consoles and KVM virtualisation
- pungi/lorax fixes to fix el torito image generation to make isos
bootable on aarch64
---------- Forwarded message ----------
From: *Brooks Hu* <brooks.hu(a)gmail.com>
Date: Friday, December 26, 2014
Subject: Help!Failed to find a suitable stage1 device when using PXE
I am trying automatic PXE installation (Fedora 21 for AARCH64) on my
Mustang board, but looks like kickstart can't work.
Here comes the detail:
Starting installer, one moment...
find_file: stat /proc/device-tree/chosen/bootpath, No such file or directory
anaconda 21.48.21-1 for Fedora-Server 21 started.
* installation log files are stored in /tmp during the installation
* shell is available on TTY2
* when reporting a bug add logs from /tmp as separate text/plain
10:26:29 Not asking for VNC because of an automated install
Starting automated install......
Generating updated storage configuration
storage configuration failed: failed to find a suitable stage1 device
1) [x] Language settings 2) [!] Timezone settings
(English (United States)) (Timezone is not set.)
3) [x] Installation source 4) [!] Software selection
(ftp://192.168.1.1/F21/) (Nothing selected)
5) [!] Installation Destination 6) [x] Network configuration
(No disks selected) (Wired (eth0) connected)
7) [!] Root password 8) [!] User creation
(Password is not set.) (No user will be created)
Not enough space in filesystems for the current software selection. An
additional 2861.02 MiB is needed.
Please make your choice from above ['q' to quit | 'b' to begin
UEFI version is 1.1.0-rh-0.13
Here comes the kick start config file(I modified based on a sample from
part efi --fstype=efi --size=300 --ondisk=sda
part /boot --fstype=ext4 --size=512 --ondisk=sda
part / --fstype=ext4 --size=20096 --ondisk=sda
part /vz --fstype=ext4 --size=40768 --ondisk=sda
part swap --size=4000
bootloader --location=partition --ondisk=sda
network --bootproto dhcp
auth --enableshadow --passalgo=sha512
timezone --utc America/New_York
vztturlmap $FS_SERVER http://myrepository.com
I have tried all kinds of option combination, also deleted all the
partitions, but it still can't work. Any suggestions/comments are welcomed!
Compose started at Wed Dec 31 05:15:06 UTC 2014
New package: php-bantu-ini-get-wrapper-1.0.1-1.fc22
Convenience wrapper around PHP's ini_get() function
New package: rubygem-opennebula-4.10.1-1.fc22
OpenNebula Client API
* Tue Dec 30 2014 Eduardo Echeverria <echevemaster(a)gmail.com> - 1.0.0-1
- Bump to the new version of upstream
Size change: 3910 bytes
* Mon Dec 29 2014 Helio Chissini de Castro <hcastro(a)redhat.com> - 0.8.0-10
- Rebuild against new Qt 5.4.0
Size change: 122 bytes
* Mon Dec 29 2014 Erik van Pienbroek <epienbro(a)fedoraproject.org> - 0-0.11.git.30d6c2.20141113
- Update to 20141113 snapshot (git revision 30d6c2)
- Include all patches which were used by the Qt5 fork
- Reverted some recent commits as they break mingw-qt5-qtwebkit 5.4
Size change: 532169 bytes
Added Packages: 2
Removed Packages: 0
Modified Packages: 3
Size of added packages: 65254 (64 k)
Size change of modified packages: 536201 (524 k)
Size of removed packages: 0 (0 )
Size change: 601455 (587 k)
Compose finished at Wed Dec 31 07:01:48 UTC 2014