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 _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
