Re: [meta-xilinx] qemuboot.conf
Thanks Nathan, It turns out, through further exploration of the SDK, that when the image is built by the individual application developer (i.e. 'devtool build-image) the qemu config is generated relative to the location within the SDK installation folder location and the absolute paths are thus not an issue. For now, the only obstacle for an efficient SDK workflow using the emulator is the missing SSH/SCP access as reported in a different thread. Br, Martin From: Nathan Rossi Sent: Monday, January 29, 2018 1:58:19 PM To: Martin Siegumfeldt Cc: Alistair Francis; meta-xilinx@yoctoproject.org Subject: Re: [meta-xilinx] qemuboot.conf On 29 January 2018 at 05:51, Martin Siegumfeldt wrote: > > > > > From: Nathan Rossi > Sent: Sunday, January 28, 2018 13:44 > To: Alistair Francis > Cc: Martin Siegumfeldt; meta-xilinx@yoctoproject.org > Subject: Re: [meta-xilinx] qemuboot.conf > > On 24 January 2018 at 09:04, Alistair Francis wrote: >> On Tue, Jan 23, 2018 at 12:53 AM, Martin Siegumfeldt >> wrote: >>> Hi, >>> >>> We are rendering a custom piece of HW based on Ultrascale+, and have the >>> Xilinx QEMU successfully running. An extensible SDK (eSDK) is delivered to >>> the application developers and to close the loop we would like to be capable >>> of delivering also the QEMU instance. The machine image- and qemuboot.conf >>> is not part of the eSDK and is thus delivered next to the eSDK. >>> Unfortunately, the Xilinx conf file describes a few absolute path variables >>> (caused by e.g. >>> https://github.com/Xilinx/meta-xilinx/blob/73921b4a599834308fc0dadb785f395dded89f9e/meta-xilinx-bsp/conf/machine/zcu102-zynqmp.conf#L55 >>> I believe) prohibiting this conf file to be shared between the application >>> developers. AFACICS, this is in contrast to the generic QEMU machine configs >>> (http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.1/machines/) >>> which only describes relative path variables - I assume this is related to >>> the "custom" Xilinx PMU. > > These are not directly related to the PMU part of QEMU execute, since > that part is executed by runqemu. It is simply that runqemu does not > make generic find/replace with all args, only specific ones. > >>> >>> Do you see any way around these absolute paths, which thus enables >>> directly sharing the QEMU instance with eSDK developers? >> >> All of these files should be in the deploy directory, I don't see any >> reason why they need to be absolute. How do the other configs point to >> the images? > > They need to be absolute because the runqemu script does not rewrite > the paths for those arguments, and in turn with runqemu not executing > with the cwd being the deploy directory it is not known where the > intended path to these files are. > > Other configs like QB_ROOTFS_OPT use "@ROOTFS@" replacement strings > that are substituted during runqemu execution. > > http://git.openembedded.org/openembedded-core/tree/scripts/runqemu#n1030 > > Unfortunately I don't think there is a good solution to remove these > fields without improving runqemu itself. Since the paths are only > known by runqemu and cannot be relative to an unknown execution > working directory. > > Thanks Nathan, I was kind of expecting this answer - it can fairly easy > worked around with a sed command. However, for the "staging_bindir_native" > variable, is there a reason this is absolute as apposed to the other > "staging_dir_..." variables? AFAICS, other machines describe this variable > in a relative manner? > That is simply a case of qemuboot.bbclass getting changes that are not reflected in the qemuboot-xilinx.bbclass in meta-xilinx. This change in oe-core added relative pathing, http://git.openembedded.org/openembedded-core/commit/?id=55a0028a961c0ad3c2e5729a9e3919cbbf256fe1 But qemuboot-xilinx.bbclass modifies staging_bindir_native to put in the qemu-xilinx-helper-native specific path. Which doesn't do the relative path logic, since it was created before the oe-core change. http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/meta-xilinx-bsp/classes/qemuboot-xilinx.bbclass#n20 Please send a patch to fix it if you need the relative paths. Regards, Nathan -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] qemuboot.conf
On 29 January 2018 at 05:51, Martin Siegumfeldt wrote: > > > > > From: Nathan Rossi > Sent: Sunday, January 28, 2018 13:44 > To: Alistair Francis > Cc: Martin Siegumfeldt; meta-xilinx@yoctoproject.org > Subject: Re: [meta-xilinx] qemuboot.conf > > On 24 January 2018 at 09:04, Alistair Francis wrote: >> On Tue, Jan 23, 2018 at 12:53 AM, Martin Siegumfeldt >> wrote: >>> Hi, >>> >>> We are rendering a custom piece of HW based on Ultrascale+, and have the >>> Xilinx QEMU successfully running. An extensible SDK (eSDK) is delivered to >>> the application developers and to close the loop we would like to be capable >>> of delivering also the QEMU instance. The machine image- and qemuboot.conf >>> is not part of the eSDK and is thus delivered next to the eSDK. >>> Unfortunately, the Xilinx conf file describes a few absolute path variables >>> (caused by e.g. >>> https://github.com/Xilinx/meta-xilinx/blob/73921b4a599834308fc0dadb785f395dded89f9e/meta-xilinx-bsp/conf/machine/zcu102-zynqmp.conf#L55 >>> I believe) prohibiting this conf file to be shared between the application >>> developers. AFACICS, this is in contrast to the generic QEMU machine configs >>> (http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.1/machines/) >>> which only describes relative path variables - I assume this is related to >>> the "custom" Xilinx PMU. > > These are not directly related to the PMU part of QEMU execute, since > that part is executed by runqemu. It is simply that runqemu does not > make generic find/replace with all args, only specific ones. > >>> >>> Do you see any way around these absolute paths, which thus enables >>> directly sharing the QEMU instance with eSDK developers? >> >> All of these files should be in the deploy directory, I don't see any >> reason why they need to be absolute. How do the other configs point to >> the images? > > They need to be absolute because the runqemu script does not rewrite > the paths for those arguments, and in turn with runqemu not executing > with the cwd being the deploy directory it is not known where the > intended path to these files are. > > Other configs like QB_ROOTFS_OPT use "@ROOTFS@" replacement strings > that are substituted during runqemu execution. > > http://git.openembedded.org/openembedded-core/tree/scripts/runqemu#n1030 > > Unfortunately I don't think there is a good solution to remove these > fields without improving runqemu itself. Since the paths are only > known by runqemu and cannot be relative to an unknown execution > working directory. > > Thanks Nathan, I was kind of expecting this answer - it can fairly easy > worked around with a sed command. However, for the "staging_bindir_native" > variable, is there a reason this is absolute as apposed to the other > "staging_dir_..." variables? AFAICS, other machines describe this variable > in a relative manner? > That is simply a case of qemuboot.bbclass getting changes that are not reflected in the qemuboot-xilinx.bbclass in meta-xilinx. This change in oe-core added relative pathing, http://git.openembedded.org/openembedded-core/commit/?id=55a0028a961c0ad3c2e5729a9e3919cbbf256fe1 But qemuboot-xilinx.bbclass modifies staging_bindir_native to put in the qemu-xilinx-helper-native specific path. Which doesn't do the relative path logic, since it was created before the oe-core change. http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/meta-xilinx-bsp/classes/qemuboot-xilinx.bbclass#n20 Please send a patch to fix it if you need the relative paths. Regards, Nathan -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] qemuboot.conf
From: Nathan Rossi Sent: Sunday, January 28, 2018 13:44 To: Alistair Francis Cc: Martin Siegumfeldt; meta-xilinx@yoctoproject.org Subject: Re: [meta-xilinx] qemuboot.conf On 24 January 2018 at 09:04, Alistair Francis wrote: > On Tue, Jan 23, 2018 at 12:53 AM, Martin Siegumfeldt > wrote: >> Hi, >> >> We are rendering a custom piece of HW based on Ultrascale+, and have the >> Xilinx QEMU successfully running. An extensible SDK (eSDK) is delivered to >> the application developers and to close the loop we would like to be capable >> of delivering also the QEMU instance. The machine image- and qemuboot.conf >> is not part of the eSDK and is thus delivered next to the eSDK. >> Unfortunately, the Xilinx conf file describes a few absolute path variables >> (caused by e.g. >> https://github.com/Xilinx/meta-xilinx/blob/73921b4a599834308fc0dadb785f395dded89f9e/meta-xilinx-bsp/conf/machine/zcu102-zynqmp.conf#L55 >> I believe) prohibiting this conf file to be shared between the application >> developers. AFACICS, this is in contrast to the generic QEMU machine configs >> (http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.1/machines/) >> which only describes relative path variables - I assume this is related to >> the "custom" Xilinx PMU. These are not directly related to the PMU part of QEMU execute, since that part is executed by runqemu. It is simply that runqemu does not make generic find/replace with all args, only specific ones. >> >> Do you see any way around these absolute paths, which thus enables directly >> sharing the QEMU instance with eSDK developers? > > All of these files should be in the deploy directory, I don't see any > reason why they need to be absolute. How do the other configs point to > the images? They need to be absolute because the runqemu script does not rewrite the paths for those arguments, and in turn with runqemu not executing with the cwd being the deploy directory it is not known where the intended path to these files are. Other configs like QB_ROOTFS_OPT use "@ROOTFS@" replacement strings that are substituted during runqemu execution. http://git.openembedded.org/openembedded-core/tree/scripts/runqemu#n1030 Unfortunately I don't think there is a good solution to remove these fields without improving runqemu itself. Since the paths are only known by runqemu and cannot be relative to an unknown execution working directory. Thanks Nathan, I was kind of expecting this answer - it can fairly easy worked around with a sed command. However, for the "staging_bindir_native" variable, is there a reason this is absolute as apposed to the other "staging_dir_..." variables? AFAICS, other machines describe this variable in a relative manner? Regards, Nathan -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] qemuboot.conf
On 24 January 2018 at 09:04, Alistair Francis wrote: > On Tue, Jan 23, 2018 at 12:53 AM, Martin Siegumfeldt > wrote: >> Hi, >> >> We are rendering a custom piece of HW based on Ultrascale+, and have the >> Xilinx QEMU successfully running. An extensible SDK (eSDK) is delivered to >> the application developers and to close the loop we would like to be capable >> of delivering also the QEMU instance. The machine image- and qemuboot.conf >> is not part of the eSDK and is thus delivered next to the eSDK. >> Unfortunately, the Xilinx conf file describes a few absolute path variables >> (caused by e.g. >> https://github.com/Xilinx/meta-xilinx/blob/73921b4a599834308fc0dadb785f395dded89f9e/meta-xilinx-bsp/conf/machine/zcu102-zynqmp.conf#L55 >> I believe) prohibiting this conf file to be shared between the application >> developers. AFACICS, this is in contrast to the generic QEMU machine configs >> (http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.1/machines/) >> which only describes relative path variables - I assume this is related to >> the "custom" Xilinx PMU. These are not directly related to the PMU part of QEMU execute, since that part is executed by runqemu. It is simply that runqemu does not make generic find/replace with all args, only specific ones. >> >> Do you see any way around these absolute paths, which thus enables directly >> sharing the QEMU instance with eSDK developers? > > All of these files should be in the deploy directory, I don't see any > reason why they need to be absolute. How do the other configs point to > the images? They need to be absolute because the runqemu script does not rewrite the paths for those arguments, and in turn with runqemu not executing with the cwd being the deploy directory it is not known where the intended path to these files are. Other configs like QB_ROOTFS_OPT use "@ROOTFS@" replacement strings that are substituted during runqemu execution. http://git.openembedded.org/openembedded-core/tree/scripts/runqemu#n1030 Unfortunately I don't think there is a good solution to remove these fields without improving runqemu itself. Since the paths are only known by runqemu and cannot be relative to an unknown execution working directory. Regards, Nathan -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] qemuboot.conf
On Tue, Jan 23, 2018 at 12:53 AM, Martin Siegumfeldt wrote: > Hi, > > We are rendering a custom piece of HW based on Ultrascale+, and have the > Xilinx QEMU successfully running. An extensible SDK (eSDK) is delivered to > the application developers and to close the loop we would like to be capable > of delivering also the QEMU instance. The machine image- and qemuboot.conf is > not part of the eSDK and is thus delivered next to the eSDK. Unfortunately, > the Xilinx conf file describes a few absolute path variables (caused by e.g. > https://github.com/Xilinx/meta-xilinx/blob/73921b4a599834308fc0dadb785f395dded89f9e/meta-xilinx-bsp/conf/machine/zcu102-zynqmp.conf#L55 > I believe) prohibiting this conf file to be shared between the application > developers. AFACICS, this is in contrast to the generic QEMU machine configs > (http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.1/machines/) > which only describes relative path variables - I assume this is related to > the "custom" Xilinx PMU. > > Do you see any way around these absolute paths, which thus enables directly > sharing the QEMU instance with eSDK developers? All of these files should be in the deploy directory, I don't see any reason why they need to be absolute. How do the other configs point to the images? Alistair > > Thanks, > Martin > -- > ___ > meta-xilinx mailing list > meta-xilinx@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-xilinx -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
[meta-xilinx] qemuboot.conf
Hi, We are rendering a custom piece of HW based on Ultrascale+, and have the Xilinx QEMU successfully running. An extensible SDK (eSDK) is delivered to the application developers and to close the loop we would like to be capable of delivering also the QEMU instance. The machine image- and qemuboot.conf is not part of the eSDK and is thus delivered next to the eSDK. Unfortunately, the Xilinx conf file describes a few absolute path variables (caused by e.g. https://github.com/Xilinx/meta-xilinx/blob/73921b4a599834308fc0dadb785f395dded89f9e/meta-xilinx-bsp/conf/machine/zcu102-zynqmp.conf#L55 I believe) prohibiting this conf file to be shared between the application developers. AFACICS, this is in contrast to the generic QEMU machine configs (http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.1/machines/) which only describes relative path variables - I assume this is related to the "custom" Xilinx PMU. Do you see any way around these absolute paths, which thus enables directly sharing the QEMU instance with eSDK developers? Thanks, Martin -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
