Ionel

There are some options to change the boot.src A. Manual: 1. Copy existing boot.src in a file boot.cmd.defalut 2. Remove generated hash form boot.cmd.defalut up to first: "# This is a boot....." 3. Add your changes 4. In a petalinux envirnment shell run command: mkimage -c none -rm -T script -d images/linux/boot.cmd.default images/linux/boot.scr B. Automatic: I. Via petalinux-config Pre-bootenv varialble by setting your variables there. Ex a=1; b=3; .. Anything more advance it becomes complicated. for instance adding: " character. II. Via yocto: append to meta-xilinx/meta-xilinx-core/recipes-bsp/u-boot/u-boot-xlnx-scr.bb recipe in meta-user layer.

Hi @shubhanshu Depending on your petalinux version you may also need to copy boot.scr on the first partition. Changes for petalinux projects can be found here. Demos are on different branches: https://github.com/Digilent/Eclypse-Z7-OS You can also enable fsbl debug to see what is going on at boot time.

Hi @m3atwad You may have noticed that to boot the board with newer versions of petalinux boot.scr is used instead of uEnv.txt You can read on how to change this boot script Also the serverip environment variable used for finding the tftp server can be set at startup by entering in u-boot CLI ZynqMP> setenv serverip <HOST IP ADDRESS>;saveenv https://docs.amd.com/r/en-US/ug1144-petalinux-tools-reference-guide/Booting-a-PetaLinux-Image-on-Hardware-with-TFTP saveenv command should save this variable in qspi-boot partition you can find the partition definition in file: components/plnx_workspace/device-tree/device-tree/system-conf.dtsi and can be changed with petalinux-config command You can also use Pre bootenv to bake some environment changes into BOOT.bin/boot.scr https://docs.amd.com/r/en-US/ug1144-petalinux-tools-reference-guide/Configuring-U-Boot-Boot-Script-boot.scr

Hi @Bogy I think what you are looking for is in components/plnx_workspace/device-tree/device-tree/ in pl.dtsi and pcw.dtsi files. Those files are generated based on your design. In system-user.dtsi you can change those nodes by addressing them with &node_name.

Hi @Ronson How did you partition and format the SD card? What files have you placed on the SD card? What petalinux command did you use to build BOOT.BIN ? Have you enable FSBL debug ? FSBL messages are thrown on UART early on. How early did you connect to the serial console to view those messages? Answering those question will most likely lead to the solution. If not please add your answer to those question if you reply

Hi @m3atwad You can read how to setup tftp boot in UG1144 for your petalinux version For 2024.1 here is good starting point https://docs.amd.com/r/en-US/ug1144-petalinux-tools-reference-guide/Booting-PetaLinux-Image-on-Hardware-with-TFTP

HI @yogurth Is there a reason why you need a soft CPU (microblaze) when you have a hard CPU inside zynq-7000?

Hi @Dr. Vegapunk XSA file is used to provide a hardware description for building a petalinux image. When you build low level software you need to have clear description of targeted hardware. If you have a XSA file you can start a project from scratch following the manual (UG1144) for your version of petalinux. https://docs.amd.com/r/en-US/ug1144-petalinux-tools-reference-guide/Creating-a-Project Here is a demo project https://github.com/Digilent/Zybo-Z7-OS/tree/20/Petalinux/master

If you want to build out of tree kernel module you can look at this doetna doc and this example

TCP awaits for acknowledged before sending the next package while UDP does not. Therefor you can loose data via UDP. If that is not a concern it is ok. Even if there is such a tool, how do you connect such a tool the PS cache?

Here there is a petlinux project. You might find other device tree related configurations for this board. https://github.com/Digilent/Cora-Z7-OS/tree/07S/master https://github.com/Digilent/Cora-Z7-OS/blob/07S/master/project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi

A void* pointer is just a reference to a byte in memory (in this case a mapped memory) and dose not add any constraints on how to use the memory that follows. Anything that escape the memory segment/page or incorrect access leads to a segmentation fault. In addition if your pointer refers something on stack, know that the referred memory will be freed on a function exit/return. And next use of the pointer will lead to of course segmentation fault. Maybe using the heap in this case. This is all that can be said without any explicit situation (source code). For example without knowing how and when the mapping/unmapping is performed.

You can not have paths like C::/Temp... in Linux. You can look into Linux file system structure to understand how it is structured. Somewhere in your project configuration a windows file path is used and the makefile is generated accordingly

In first menuconfig image, shouldn't `Xilinx DRM HDMI subsystem Driver` option be enabled ? Also using logs, searchable text instead of screenshots is much easier. (Ctrl+Shift+C to copy selected text form terminal).

You have a syntax error in your device tree: