We're currently working on our 2023.1 release. It currently contains a VPK120
machine. However, I don't yet have the ability to release the current work.
I'm hoping I can find some time soon to backport what I CAN release, and that
will likely help you. I'd be targeting langdale and master most likely with
that work, but it shouldn't be too hard to backport to Kirkstone.
--Mark
On 1/30/23 11:58 AM, Thompson, Corey via lists.yoctoproject.org wrote:
Hi.
I am aware that there isn't a vpk120 machine configuration in 2022.x, so
I provided a machine config for it in my minimal working example that is
similar to what we use at my organization.
Is there any update available here? Perhaps some workaround that we
could put in our layer to deal with it until this has better support in
2023.1? As I mentioned earlier, having to change our local.conf to
build without initramfs for QEMU, but with initramfs for the real VPK120
board is a bit of a burden on our development workflow.
Thanks,
Corey
On Tue, Jan 10, 2023 at 05:06:22PM -0700, Gundlupet Raju, Sandeep wrote:
Hi Corey,
In 2022.x Yocto we don't have a vpk120 machine configuration file, this is
something we have planned to add in 2023.1. But still you should be able to
use versal-generic machine conf file with below configs and run it on
qemu/hw.
HDF_BASE = "file://"
HDF_PATH = "/<ABSOLUTE_PATH_TO_XSA>/vpk120.xsa"
# Versal PLM Variables
YAML_SERIAL_CONSOLE_STDIN:pn-plm-firmware =
"versal_cips_0_pspmc_0_psv_sbsauart_0"
YAML_SERIAL_CONSOLE_STDOUT:pn-plm-firmware =
"versal_cips_0_pspmc_0_psv_sbsauart_0"
# Versal Device-tree Variables
YAML_CONSOLE_DEVICE_CONFIG:pn-device-tree =
"versal_cips_0_pspmc_0_psv_sbsauart_0"
YAML_DT_BOARD_FLAGS = "{BOARD versal-vpk120-reva}"
$ MACHINE=versal-generic bitbake core-image-minimal
I will take a look on this issue.
Thanks,
Sandeep
On 1/10/2023 2:36 PM, Thompson, Corey via lists.yoctoproject.org wrote:
Hello.
I'm having trouble with runqemu (for the VPK120 Versal evaluation board)
after updating from rel-v2022.1_update2 to rel-v2022.2. I see there has
been a lot of refactoring in this area between the two releases, and now
it looks like there is an attempt to boot using the initramfs-bundled
kernel if there is one. However, when I use runqemu with these options,
I see nothing happen. I never see the PLMFW run, no kernel boots, QEMU
simply appears to hang until I terminate it.
I realize that I can work around the issue by setting
INITRAMFS_IMAGE_BUNDLE="0", but the problem is that we want to be able
to use the same config that we use to generate hardware images, and this
is the configuration that we prefer to use for our hardware targets.
I've put together a minimum working example to try to illustrate the
issue. You can find it at this link; instructions are in the README.
https://urldefense.com/v3/__https://github.com/cmtptr/corey-build__;!!OSsGDw!MRnAYtme997qx-Cs3ZR89mLkqVUpKc1h7PmJ-5GTOBzCvNy_EMHq2FxrFxBEayHG8GnUjeBclxyJvADSqRWwabE$
[github[.]com]
Any pointers here would be greatly appreciated.
Thanks,
Corey
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5142):
https://lists.yoctoproject.org/g/meta-xilinx/message/5142
Mute This Topic: https://lists.yoctoproject.org/mt/96633802/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
