Hi Eric,
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
further output.
That could be due to a number of reasons. Are you connected via
HDMI/usb or a serial console?
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:
http://www.vxmdesign.com/zynq.html
When I use everything from that build, and nothing from Fedora, it
boots up just fine.
OK, what versions of u-boot and kernel? Can you provide, via fpaste
please, a log of the working boot?
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:
The above error could be due to non console support in the kernel, one
of the loads being larger than the memory offsets and hence
overwriting something else or just a DT that's not compatible with our
kernel. Looking at the DT we ship there doesn't look to be microzed
support upstream yet.
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?
microzed-u-boot> fatload mmc 0 0x2000000 uInitrd
reading 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?
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
size.
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
I've enabled a few ZYNQ devices in our u-boot in rawhide [1] 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.
[1]
http://koji.fedoraproject.org/koji/buildinfo?buildID=639326
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).
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.
Let me know how you get on.
Peter