Notices by Darrell Harmon (dlharmon@chaos.social)

This is the current state of Xilinx package markings or lack thereof. I added the pencil marking of size and speed grade so I don't mix it up with an identical appearance but incompatible part, redacted the QR code. There's an app to look up the QR code, requires a login and approval.

@azonenberg I'd agree embedded Linux is much harder in most cases, especially dealing with firmware updates to end users.

Tools like buildroot can make embedded Linux less painful. Run from a smallish ramdisk for ease of update.

I think some of the attraction is familiar software libraries and APIs. Using something like QT for the GUI can be a big deciding factor.

SOC FPGAs are nice in being able to share DDR between the CPU and FPGA but of course you can run that bare metal if desired.

@azonenberg The Xilinx documented way of using Zynq is indeed a pain. I've done direct instantiation of the PS block (Zynq-7), a small TCL script that generates an IP core breaking out all the desired AXI busses for the more complex Zynq US+. Configuration and startup is ugly the Xilinx way too. I've worked around that and have an open source CLI flow.

@azonenberg I should do a writeup as a blog post of pure CLI flow on Zynq US+. Running the top level makefile results in a boot image with software, FPGA, etc all packed together. Xilinx did release quite a bit of the boot image generation stuff under permissive licenses recently which helped greatly.

@azonenberg I am running Linux on the PS but bare metal is simple enough. You can specify an elf file for each of the CPUs to bootgen. That kicks out an image you can put in flash. JTAG boot is different, having to load and run PMU firmware and first stage bootloader (DRAM init, etc) then load those binaries into RAM. PMUFW and FSBL are both open source (MIT) bare metal code available from Xilinx Github repos. FSBL does contain a design specific header file generated by Vivado with DDR, PLL, etc

@azonenberg Oddly, the PMU (power management unit, starts on ROM, but needs FW load) is a hard core Microblaze. Not sure why they did that when they were already licensing ARM cores. That does add the complexity of another compiler, different JTAG debug port. The CSU (configuration security unit, only can run from ROM) is also Microblaze, both of these cores are triple modular redundant which might have been why they used their own. Also seems there's another Microblaze in the video codec.