cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
tscbailey
Contributor
Contributor
697 Views
Registered: ‎11-19-2018

SDK hangs when it attempts to run metal_init

I am generating an application to run under Linux built by petalinux 2018.3. I am using this application to interface with the RFDC library for use with a RFSOC part.

When I build the application in yocto and run it, it executes as I expect. It has no problems initializing libmetal and the rfdc library.

When I build the application using SDK 2018.3.1 and debug it uusing the TCF agent, the application hangs.  Specifically, I am unable to run metal_init. When it attempts to call the function, the application hangs and I have to terminate the debug session. 

I'm at a loss for where I need to start to debug this problem.  Any suggestions? 

 

Regards, 

Doug Bailey 

Tags (2)
0 Kudos
5 Replies
tscbailey
Contributor
Contributor
638 Views
Registered: ‎11-19-2018

One thing that puzzles me is that I can only get the project to compile if I enable the libmetal in the BSP settings.  Since I am debugging this over Linux, why would I have to set that in the BSP settings? 

Is this linking to the same library that is in the Linux build?

I've noticed that the header files between the BSP and the Linux sysroot differ.  Is my problem versioning differences? 

Regards, 

Doug Bailey 

 

0 Kudos
tscbailey
Contributor
Contributor
633 Views
Registered: ‎11-19-2018

FWIW:  Here is a test app that fails:   It is linked against the libmetal library in the petalinux sysroot I generated with petalinux-build --sdk.

I can run the generated elf file from the Linux command line.  I just cannot run it from the debugger. 

 

#include <stdio.h>
#include <xrfdc.h>


/******************************************************************************
 * Callback for libmetal log handler.  Allows libmetal/RFDC messages to
 * output to the console.
 ******************************************************************************
 */
static void my_metal_default_log_handler(enum metal_log_level level,
			       const char *format, ...)
{
	return;
}


int main()
{
    struct metal_init_params init_param = {	\
                    .log_handler	= my_metal_default_log_handler,	\
                    .log_level		= METAL_LOG_DEBUG,			\
    };

    printf("Test Access to LibMetal\n");

    if (metal_init(&init_param)) {
            fprintf(stderr, "ERROR: Failed to run metal initialization\n");
            return XRFDC_FAILURE;
    }
    return 0;
}

 

 

0 Kudos
tscbailey
Contributor
Contributor
617 Views
Registered: ‎11-19-2018

The call that the SDK hangs on is a system call:

modprobe vfio-pci > /dev/null 2>&1

The SDK does not like it. 

 

 

 

0 Kudos
tscbailey
Contributor
Contributor
599 Views
Registered: ‎11-19-2018

It appears that metal_init attempts to detect the presence of the vfio-pci and uio_pci_generic drivers.  If they are not loaded, it attempts to modprobe them.  The system call to modprobe causes the SDK to hang and become unusable.. 

This only happens within the SDK and is not a problem when running programs from the command line. 

My solution was to build those two drivers into the kernel.  Since they are never referenced in my project, their inclusion is benign. 

 

tscbailey
Contributor
Contributor
60 Views
Registered: ‎11-19-2018

An update for Vitis 2020.2.  

libmetal applications encounter the same error.  However, now there are 5 modules that need to be built into the kernel to insure that Vitis does not invoke the system command to modprobe them.  

They are: 

vfio-platform
uio_pdrv_genirq
uio_dmem_genirq
vfio-pci
uio_pci_generic

 

0 Kudos