-----BEGIN PGP SIGNED MESSAGE-----
'clang++' compiler is unable to use ARM %optflags used on Fedora
Which flags i can use on ARM architectures with clang++ compiler?
mailto: sagitter 'at' fedoraproject 'dot' org
GPG Key: 0x565E653C
Check on https://keys.fedoraproject.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
[Apologies to Peter for the duplicate; earlier today I accidentally
sent this reply to him rather than the list, so I'm forwarding it to
the list in case anyone else is interested.]
On Wed, May 27, 2015 at 7:35 AM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
> That could be due to a number of reasons. Are you connected via
> HDMI/usb or a serial console?
Serial console over USB. MicroZed has an on-board CP2104 USB-serial
bridge, connected to Zynq UART pins in MIO bank 1/501.
> OK, what versions of u-boot and kernel?
U-Boot identifies itself as U-Boot 2013.10. The kernel identifies as
3.8.0-xilinx. Both are forked from the Xilinx repos on github, with
additional patches for MicroZed from VXM Design. The repo is:
I haven't tried using that kernel with Fedora userspace yet; I was
hoping to use the Fedora kernel.
> Can you provide, via fpaste please, a log of the working boot?
> I suspect it's an issue with the DTB, do you know what version of
> kernel the DT works with, where it comes from etc?
I think the DT comes from Xilinx, but may have changes by VXM Design. It's here:
If there is a DT problem, is there a Fedora Zynq DT for another board
that I should look at for comparison?
> You'd only need different ones if our kernel was too large to fix in
> the defined range. It's possible it is as we have a multiplatform
> kernel which is quite a bit larger than a custom kernel for a specific
OK, I'll check that.
> I've enabled a few ZYNQ devices in our u-boot in rawhide  so I'd be
> interested in feedback how you get on with that. I'm not sure of the
> feature set of the upstream zynq support. It's been on my list to look
> at but I've not had anyone request it until now. I'd certainly be
> interested in feedback and assistance in ensuring we can support these
> moving forward.
I'll certainly provide all of the feedback and patches that I can. It
would be nice to see MicroZed as a supported Fedora ARM platform.
> Interesting, I wonder if the upstream u-boot support uses the same
> modification so as to not require the Xilinx FSBL. Once the above
> build completes I'd be interested to here if the binary works to at
> least get to a working u-boot prompt.
Does your Zynq work still require a Xilinx FSBL?
It appears that there's a 192KB limit on the boot.bin image size that
the Zynq ROM will load into RAM, and normal u-boot is larger. It
appears that the VXM Design hack is to build a small u-boot (37628
bytes) as boot.bin, and have that load and run a full u-boot.
However, I haven't really dug into this so I could be mistaken. I
need to redo the buildroot build from scratch and capture all the
output to a log so I can figure out what the build actually does.
I'm trying to get Fedora 22 on a MicroZed board (based on XIlinx Zynq
7Z020, dual-core ARM Cortex-A9), and I don't entirely know what I'm
doing, so I could use some assistance. I'm getting the kernel loaded
by U-Boot, but after the "Starting kernel ..." message I don't get any
I'm trying to use the kernel from the Fedora 22 release, but I need a
MicroZed-specific U-Boot and device tree, so right now I am using
known-good ones cross compiled from source on an x86_64 using
buildroot, as described here:
When I use everything from that build, and nothing from Fedora, it
boots up just fine.
When I try to use u-boot and the device tree from that, and the uImage
and uInitrd from Fedora 21, it appears that U-boot loads the uImage
and uInitrd OK. The U-boot is configured to use a different name for
the ramdisk file, so its automatic boot sequence fails after loading
the kernel and device tree, but I manually load the uInitrd using the
fatload command, then tell it to boot:
microzed-u-boot> fatload mmc 0 0x2000000 uInitrd
27397171 bytes read in 1348 ms (19.4 MiB/s)
microzed-u-boot> bootm 0x3f00000 0x2000000 0x3e00000
## Booting kernel from Legacy Image at 03f00000 ...
Image Name: 4.0.4-301.fc22.armv7hl
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 5645832 Bytes = 5.4 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 02000000 ...
Image Name: initramfs
Image Type: ARM Linux RAMDisk Image (uncompressed)
Data Size: 27397107 Bytes = 26.1 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 03e00000
Booting using the fdt blob at 0x3e00000
Loading Kernel Image ... OK
Loading Ramdisk to 1e5df000, end 1ffffbf3 ... OK
Loading Device Tree to 1e5da000, end 1e5dec70 ... OK
Starting kernel ...
Are the load addresses OK, or do I need different ones for Fedora?
Should a device tree blob that works for a different Linux setup be at
least minimally functional for Fedora?
Thanks for any advice! If I can get this working, I'll try to set up
to build a suitable U-Boot natively, rather than through
cross-compilation with buildroot. The vmxdesign people that provided
the buildroot setup have some modifications to the U-Boot, forked from
the Xilinx U-Boot, which eliminate the need for the Xilinx FSBL (first
stage boot loader) ordinarily needed on Zynq. That's useful for Fedora
because the FSBL licensing is not great (or at least, it wasn't the
last time I checked).
We are proud to announce the official release of Fedora 22 for aarch64,
the community-driven and community-built operating system now available
in Cloud, Server, and Workstation editions.
If that's all you need to hear, jump over to Get Fedora to download
-- or for current users, run the FedUp upgrade tool.
In addition to the latest versions of all your favorite free and
open source software, Fedora 22 marks our second release with
distinctly-targeted offerings for cloud computing, the server room,
and the desktops and laptops of software developers and creators
everywhere. Thanks to the hard work of developers, designers,
packagers, translators, testers, documentation writers, and
everyone else, we're incredibly confident in saying that this is
our best and most polished release yet.
Also with this release, we return to our traditional six-month
cadence -- we'll see you back here sometime around Halloween!
Highlights in the Fedora 22 release
Every Fedora release has its own character. If this release had a
human analogue, it'd be Fedora 21 after it'd been to college,
landed a good job, and kept its New Year's Resolution to go to the
gym on a regular basis. What we're saying is that Fedora 22 has
built on the foundation we laid with Fedora 21 and the work to
create distinct editions of Fedora focused on the desktop, server,
and cloud (respectively). It's not radically different, but there
are a fair amount of new features coupled with features we've
already introduced but have improved for Fedora 22.
* Database Server Role -- The Fedora Server edition focuses on easy of
different server roles. Fedora 21 debuted with an Domain Controller
Role featuring FreeIPA. For this release, we've added a Database
Server role, built around PostgreSQL.
* Default to XFS filesystem -- The default file system type for
Fedora Server installs will be XFS running atop LVM for all
partitions except /boot. The /boot partition will remain a non-LVM,
ext4 partition due to technological limitations of the bootloader.
* Cockpit will be compatible between OS releases -- Cockpit is a
server manager that makes it easy to administer your GNU/Linux
servers via a web browser.
- Easy to use. Cockpit is perfect for new sysadmins, allowing
them to easily perform simple tasks such as storage
administration, inspecting journals and starting and stopping
- No interference. Jumping between the terminal and the web
tool is no problem. A service started via Cockpit can be
stopped via the terminal. Likewise, if an error occurs in the
terminal, it can be seen in the Cockpit journal interface.
- Multi-server. You can monitor and administer several servers
at the same time.
Other changes of note
Faster and better dependency management with DNF
With Fedora 22, we're introducing a major change under the hood.
Specifically, we're now using DNF and hawkey to manage packages.
DNF is much like the Yum software package manager (it's largely
command-line compatible), but re-written and re-engineered to
provide optimal performance and (along with Hawkey) provide a
strict API definition for plugins and extending projects. DNF also
makes use of the libsolv library initially pioneered by the
openSUSE Project to provide faster and better dependency
It also boasts a better performance and memory footprint vs. Yum,
and is designed to have a cleaner codebase and be easier to
If you're using the Fedora 22 Workstation edition, and managing
packages with the Software Application, odds are you won't notice a
difference. Server and Cloud users who fall back on Yum commands
will receive a reminder (courtesy of dnf-yum) that Yum is
deprecated and DNF is now the default package manager. DNF has been
in development for quite some time, so we're confident it's ready
for prime time. The classic Yum command line tool has been renamed
to yum-deprecated as a transitional step for tools still using it.
See Read The Docs for compatibility changes from Yum to DNF in
GNU Compiler Collection 5
Fedora 22 comes with GCC 5.1 as the primary compiler suite.
Downloads, upgrades, documentation, and common bugs
You can start by downloading Fedora 22:
If you are upgrading from a previous release of Fedora, refer to:
Fedora's FedUp utility enables an easy upgrade to Fedora 22 from
previous releases. See the FedUp page on the Fedora wiki for more
Read the full release notes for Fedora 22, guides for several languages,
and learn about known bugs and how to report new ones:
Fedora 22 common bugs are documented at:
This page includes information on several known non-blocker bugs in
Fedora 22. Please be sure to read it before installing!
Read this announcement in glorious full color on Fedora Magazine, at
and follow the Magazine for regular user-focused articles covering
all things Fedora.