Main / Vitis
The hello world project default UART baud rate is 115200. SDKIn 2019, the SDK is actually an IDE which comes as part of Vivado or it can be installed separately "for embedded software developers". It is built on Eclipse and includes JTAG debugging capabilities. The way to launch the SDK IDE GUI is a great secret, but I've figured it out. For example with v2019.1 go to /tools/Xilinx/SDK/2019.1/bin and run xsdk. Note that running /tools/Xilinx/SDK/2019.1/eclipse/lnx64.o/eclipse will fail. Xilinx AI SDK for Neural Networks Instead of "bare metal" they use the term "standalone" to refer to a system sans RTOS. After 2019 the XSDK was discontinued in favor of Vitis. Handy Linux Tool Launch ScriptsPut this script in /usr/bin so you can launch multiple versions of tools simply from command line, rather than having to alter the PATH every time you want to launch a different version. #!/bin/bash echo "Adding Vivado 2019.1 executable dir to temporary PATH" export PATH=$PATH:/tools/Xilinx/Vivado/2019.1/bin/ vivado & This one I call /usr/bin/xsdklaunch_2019.1 #!/bin/bash echo "Entering Xilinx SDK executable dir" cd /tools/Xilinx/SDK/2019.1/bin source ../settings64.sh export CROSS_COMPILE=arm-linux-gnueabihf- ./xsdk & echo "Returning to CWD" cd - Troubleshootinggetting a nullptr syntax error even though -std=c++11 or higher is set: If the XSDK crashes and then you can't restart it with your workspace, giving the following error: InstallationWhen installing XSDK 2019.1, the log may report XSDB or XSCT errors, missing things causing failures. Try sudo apt install libtinfo5. HLSVitis HLS is apparently different software for IP block creation from regular Vitis, even as a Vitis installation creates the two directories. Hardware PlatformTo get a PL build from Vivado that you can use in the XSDK, it's not straightforward. In Vivado 2016.4, the Export command from the File menu doesn't really do anything. Instead, you have to do the Launch SDK command, and this will actually create the <projname>/<projname>.sdk/System_wrapper_hw_platform_0/ folder full of the ps7_init C files and headers, block diagram Tcl files, the .hdf, and the bitstream .bit. Then this must be imported into the XSDK or pointed to for getting the bitstream when building a boot image. TODO fix this section The bootloader BSP for the Zynq ps7_cortexa9 has a file in the include/ dir called xparameters.h that holds the addresses of the AXI-mapped PL blocks, and this file is key for the ARM SW to access them. For example, /standalone_bsp_0/ps7_cortexa9_0/include/xparameters.h:25:#define XPAR_PS7_DDR_0_S_AXI_BASEADDR 0x00100000 causes a special calculation for the DDR_REG variable. This file definitely has to be generated from the FPGA logic sources (though it's not clear exactly the mechanism used) because it has information about specific logic blocks /* Definitions for peripheral CARRIER_0_DATA_ARBITER_0 */ When we export the ECC additions out of Vivado, we should see a change to these files, right? Indeed, here it is: /* Definitions for peripheral ECC_PROXY_IP_1 */
There are three other files dependent on the S_AXI_BASEADDR/HIGHADDR: ./vsg_bootloader/src/main.c ? used for DDR init check, this is hopefully a POST sequence and wouldn?t be affected by the needed MMU change ./vsg_bootloader/src/mmc.c ? we load the OS from QSPI flash so hopefully this is not used ./vsg_bootloader/src/fsbl.h ? see derived definitions connections in following modules ./vsg_bootloader/src/image_mover.c ? a load address check uses it, could this be a problem? Summary of 32-bit RAM ECC proxy necessary file changes to FSBL and app code: FSBL ./vsg_bootloader/src/fsbl.h add a new temp storage address for files in DDR and ECC proxy memory addresses ./vsg_bootloader/src/main.c change DDR init test to point at temp storage location instead of ECC-protected memory, because the PL hasn?t been programmed yet so it?s not yet accessible ./vsg_bootloader/src/image_mover.c Change PS partition flag compare to use ECC proxy addresses instead of original DDR start/end ./vsg_bootloader/src/mmc.c Change the DDR start/end addresses to be the new ECC proxy addresses ./vsg_bootloader/src/fsbl_hooks.c After bitstream programmed, I init the FPGA, enable interfaces, and do a memory test on ECC-protected DDR. ./vsg_bootloader/src/translation_table.S adjust the size of the unused FPGA slave2 area, and make the DDR non-cacheable or else we crash on handoff to app APP ./VSG_CPU0/src/lscript.ld set up the loading location in ECC-prot memory and arrange the rest of the memory as needed FSBL ConfigurationThis is a secret that apparently isn't documented anywhere, but there's a trick to getting the debug prints in the bootloader to actually show, and there's more to it than simply adding a -D flag for FSBL_DEBUG_INFO, although that's also required. You must also include the xuartps.h file in main.c (https://xilinx.github.io/embeddedsw.github.io/uartps/doc/html/api/xuartps_8h.html) and add a bunch of code. #ifdef __cplusplus extern "C" { #endif void outbyte(char c); #ifdef __cplusplus } #endif void outbyte(char c) { #if defined(XPAR_PS7_UART_1_DEVICE_ID) XUartPs_SendByte(XPAR_PS7_UART_1_BASEADDR, c); #elif defined(XPAR_PS7_UART_0_DEVICE_ID) XUartPs_SendByte(XPAR_PS7_UART_0_BASEADDR, c); #endif } /* inside main() */ #if defined(XPAR_PS7_UART_0_DEVICE_ID) { XUartPs_Config *c = XUartPs_LookupConfig(XPAR_PS7_UART_0_DEVICE_ID); if (c) { XUartPs mUartInstance; int status = XUartPs_CfgInitialize(&mUartInstance,c,c->BaseAddress); if (status == XST_SUCCESS) { status = XUartPs_SetBaudRate(&mUartInstance,921600); } } } #endif #if defined(XPAR_PS7_UART_1_DEVICE_ID) { XUartPs_Config *c = XUartPs_LookupConfig(XPAR_PS7_UART_1_DEVICE_ID); if (c) { XUartPs mUartInstance; int status = XUartPs_CfgInitialize(&mUartInstance,c,c->BaseAddress); if (status == XST_SUCCESS) { status = XUartPs_SetBaudRate(&mUartInstance,921600); } } } #endif |