Hi Mark, thanks for getting back to us about this! We have custom machine configurations that were defined in previous versions of our custom operating system, and I guess what we don't know how to do is to use the gen-machine-conf to define a custom machine. What we were doing previously is probably a weird hybrid of these two workflows. We have a custom xsa file and a standalone dtsi file that defines some custom peripherals, that we used in the SDTGen procedure defined here<https://github.com/Xilinx/system-device-tree-xlnx/blob/master/README.md>. I think one element of confusion for us is what machine name to use in the gen-machineconf command that then uses these files. We tried using our custom machine name which has an associated config file which includes the zynqmp-generic.inc from meta-xilinx, but we also tried using the xilinx zynqmp-generic machine name. The command that we used is below, should we have used a different machine name? It is not quite clear to us how the custom machine definition fits into this, if it is just from the xsa and dtsi files or if we need a conf file to already be present before the gen-machineconf command?
(using gen-machine-conf from meta-xilinx-core) gen-machineconf parse-sdt --hw-description ../tmp_sdt/std_outdir/ -c ../sources/meta-l1calo/conf/ -l ./conf/local.conf --machine-name gfex-production-stf we end up with generated files that are named zynqmp-generic-sdt-full, and the build files produced at build/tmp/deploy/images/zynqmp-generic-sdt-full rather than our machine name gfex-production-stf, which may be fine, but when we build the OS for our custom machine gfex-production-stf, it does not actually boot with our hardware. We have also run the gen-machineconf using a the machine name zynqmp-generic-sdt-full whose output files in the deploy directory match exactly to the files produced when we specify our custom machine name gfex-production-stf in the gen-machineconf command and in the conf/local.conf. We're not sure if we've done something incorrect in the sdt workflow, or we are missing something with the machine configurations in our attempts to update them to 2024.2 (or if we need to get rid of our custom conf files and somehow totally replace them with the sdt generated files). Here are our machine configuration files<https://github.com/UCATLAS/meta-l1calo/tree/kmd-update-2024/conf/machine>, not including the ones that are produced using the gen-machineconf command. Please let us know if there is something we need to add or change for using 2024.2, or if we should be using only machines confs from the SDT workflow rather than our custom ones. (We do have other recipes that depend on the machine name, but I guess that is a problem for a later day once we can actually boot the OS). Thanks, Kristin On Jan 28, 2025 at 6:48 PM +0100, Mark Hatle via lists.yoctoproject.org <[email protected]<mailto:[email protected]>>, wrote: On 1/28/25 11:34 AM, Kristin Dona via lists.yoctoproject.org wrote: Hello, I am trying to upgrade my OS for a custom board/firmware from Xilinx rel-v2020.2 to rel-v2024.2. Previously we were able to build a full OS including a boot.bin with yocto, but with the new updated rel-v2024.2 the boot.bin is not automatically built. I also found some documentation referring to the system device tree generator method for handling the boot workflow, described here <https://github.com/Xilinx/meta-xilinx/blob/master/meta-xilinx-standalone-sdt/README.sdt.bsp.md> but the board is unable to boot with the resulting build. For context, the chip used on my custom board is a ZynqMP (the same as used on the ZCU102 evaluation board). If anyone has any advice on what the updated boot sequence workflow is for ZynqMP devices with a custom bitstream in meta-xilinx rel-v2024.2, that would be greatly appreciated! There are two workflows, a deprecated 'xsct' workflow (this is what would have been used in the past) and a new SDT workflow. In either case, a properly configured machine.conf will trigger a boot.bin to be generated, unless your image has explicitly disabled it. With all of that said, how are you currently generating your machine? Are you using 'gen-machine-conf'? in either the xsct (direct xsa) mode or using SDT Gen and then gen-machine-conf? A common misunderstanding is people trying to hack an existing machine instead of realizing that your machine ISN'T a zcu102, so you need to define a new custom machine and use the gen-machine-conf tool for this. The process is: Vivado -> (save xsa) -> (optional) run SDTGen -> gen-machine-conf -> YP build ^ | |----------------------------------------------------| Each time you make a change to the hardware configuration, you should expect to re-run gen-machine-conf. If there any any manual fixes, settings, etc you will need to re-apply them. So scripting this process is definitely recommended. I'm happy to help you use the suggested workflow. For an example of both, look at: github.com/Xilinx/meta-xilinx-tools scripts/generate-machines-2024.2.sh script for an xsct example github.com/Xilinx/meta-amd-adaptive-socs meta-amd-adaptive-socs-bsps/scripts/generate-machine-sdt.sh for an SDT example. These are the scripts we run to generate the reference machines. --Mark Thanks for your help, Kristin
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#5546): https://lists.yoctoproject.org/g/meta-xilinx/message/5546 Mute This Topic: https://lists.yoctoproject.org/mt/110863138/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
