Dan/all,
Looking closer, I am not sure the comments I saw on the Linaro project
are relevant. The Linaro Stratos project is about making virtio work on
multiple hypervisors including Xen. When I saw the comments below I
therefore assumed they were about virtio. Looking more closely the
developer seems to be using Xen native APIs and not virtio.
Here are the Zephyr PR he mentions in the text body:
https://github.com/zephyrproject-rtos/zephyr/pull/36691https://github.com/zephyrproject-rtos/zephyr/pull/39960
His comments on Stratos project issue:
*********************************************
Currently I am working on Xen support in Zephyr (main goal now is to
start Zephyr as Dom0 and create 1 Zephyr guest).
During development I am trying to upstream some features to Zephyr
mainline. Currently I have 1 merged pull-request and 1 is now on review.
Merged PR contains:
Some of Xen public headers, which were placed in Zephyr tree
(include/xen/public/);
Hypercall interface to Xen for arm64 (arch/arm64/core/xen);
PV console driver for DomUs. It is implemented as UART driver, but works
with console ring-buffer instead of real hardware. Such solution was
made because Zephyr has lot of good features for UART drivers (UART
logging backend, shell backend, console with symbol processing stuff
etc.). Also this driver can set up consoleio hooks for printk and
stdout. It allows to receive boot logs ASAP after start with debug
version of hypervisor (very helpful for boot debug).
PR, that is on review contains:
Support for Xen Enlighten page.
Support for pre-defined event-channels (PV console, XenBus).
UART PV console driver improvement - now it is interrupt driven through
the console event channel.
Dom0 console driver. It is also UART-like, but works with consoleio
hypercalls for input and output (which are always available only for
Dom0), instead of console ring-buffer.
Also some other features are now under development: grant tables, XenBus
and starting Zephyr as Domain-0. They are present on my github, but
currently are not ready for review or upstream.
Current status for these features:
Grant tables: taken from Unikraft, ported to Zephyr code base and
tested. Works, but currently is not finished yet. Planned to push it as
next PR to Zephyr repo.
XenBus: also taken from Unikraft, cleaned-up and ported to Zephyr.
Tested: able to list directories, write and read from files in Xenstore.
Driver registration on bus was not tested due to lack of any backend
drivers, but Zephyr uses fully static configuration, so this should not
be a problem.
Zephyr Domain-0: currently I am working on this PoC and successfully
started simple sample (samples/subsys/shell/shell_module) with Dom0
console driver on R-Car Gen3 hardware. It looks a little bit hacky due
to static configuration in Zephyr (it does not use device tree in
runtime, so we need to know Dom0 and GIC location on compile time to
build and link with right addresses), but I think it is OK for PoC.
Lot of problems during development are caused by the licensing - Zephyr
is licensed under Apache-2.0, so I can not use GPL-2.0 code in there.
Also when I am trying to use MIT code from Xen (public headers) or
Unikraft (Xenbus and grant table drivers) it causes long Zephyr TSC
negotiation to take MIT code inside the Zephyr tree. So It may take some
time to add suitable Xen support in Zephyr upstream.
But I will continue PoC development and share some of the updates here.
Please, contact me if you need any other details.
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Hi all,
Please let us know if you have any additional agenda topics for this week.
* Individual updates
* Arnaud: SDK to use upstream versions.
* What to work on before next Wednesday's call?
Notes from last week's call: https://github.com/OpenAMP/openamp-system-reference/wiki/OpenAMP-System-Ref…
Thanks & regards,
Nathalie
Hi Nathalie,
Please add following to agenda:
KV260 BSP Yocto flow status.
Thanks,
Tanmay Shah
tanmay.shah(a)xilinx.com<mailto:tanmay.shah@xilinx.com>
From: Openamp-system-reference <openamp-system-reference-bounces(a)lists.openampproject.org> on behalf of Nathalie Chan King Choy via Openamp-system-reference <openamp-system-reference(a)lists.openampproject.org>
Reply-To: Nathalie Chan King Choy <nathalie(a)xilinx.com>
Date: Monday, November 1, 2021 at 10:32 AM
To: "openamp-system-reference(a)lists.openampproject.org" <openamp-system-reference(a)lists.openampproject.org>
Subject: [OA-syst-ref] Calling for agenda items: 11/3 OpenAMP System Reference weekly
Happy Monday!
Please let us know if you have any additional agenda topics for this week. Here is what I have so far:
* Individual updates
* Nathalie: KV260 ordering, PMU ROM ELF updates
* What to work on before next Wednesday’s call?
Notes from last week’s call at https://github.com/OpenAMP/openamp-system-reference/wiki/OpenAMP-System-Ref…
Thanks & regards,
Nathalie
Happy Monday!
Please let us know if you have any additional agenda topics for this week. Here is what I have so far:
* Individual updates
* Nathalie: KV260 ordering, PMU ROM ELF updates
* What to work on before next Wednesday's call?
Notes from last week's call at https://github.com/OpenAMP/openamp-system-reference/wiki/OpenAMP-System-Ref…
Thanks & regards,
Nathalie
Hi all,
Please let me know if you have additional agenda topics: Here's what I have so far:
* Individual updates
* Did anything interesting come out of OpenAMP System Reference presentation to LEDGE HPP group?
* Any updates on recruiting TI or NXP to System Reference working group?
* What to shoot to accomplish before next Wednesday's call?
Reminder of action items from last time:
* (In progress?) Tanmay: Check w/ Yocto team about "K26" vs "KV260"
* Tanmay: Set autoboot to no & see if DHCP gets an IP address
* (DONE) Nathalie: Find out if we document that info someplace (SOM schematic won't be published, just carrier card)
* Tanmay: There is user guide on how to create boot.bin. Will find it & send out.
* (DONE) Paul: Send link to wiki page
Thanks & regards,
Nathalie
Hi Bill,
Following documents / User Guide can help to understand how BOOT.BIN is generated.
1. Petalinux Tools Userguide: https://www.xilinx.com/content/dam/xilinx/support/documentation/sw_manuals/…
* Page – 31 explains how to generat BOOT.BIN using petalinux (petalinux-package tool)
* Internally it should be using bootgen utility
2. Bootgen userguide : https://www.xilinx.com/content/dam/xilinx/support/documentation/sw_manuals/…
* This user guide explains whole bif (boot image format) file format (Page – 45)
* It also explains how to use bootgen command.
i. In general I use something like following to generat BOOT.BIN:
bootgen -arch <platform name> -image boot.bif -w -o BOOT.BIN
Platform name could be: zynq, zynqmp or versal
We mention all the images’ path in bif file, i.e. fsbl, ATF, u-boot etc.. and bootgen can combine them all in one BOOT.BIN file and we can use that BOOT.BIN to boot to u-boot.
In Yocto this is taken care by Vitis xsct tool. So we don’t have to generate it manually.
Thanks,
Tanmay Shah
tanmay.shah(a)xilinx.com<mailto:tanmay.shah@xilinx.com>
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
Hello,
Looking thru notes from the last meeting, I see that Bill noted a need
to manually resize a Xilinx SD card image after the build as "pain
point". I looked into it, and found a workaround on how to build an
image of proper size right away:
--- a/meta-xilinx-bsp/classes/image-types-xilinx-qemu.bbclass
+++ b/meta-xilinx-bsp/classes/image-types-xilinx-qemu.bbclass
@@ -6,5 +6,5 @@
# 512K).
CONVERSIONTYPES_append = " qemu-sd"
-CONVERSION_CMD_qemu-sd = "cp ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.qemu-sd; truncate -s %512K ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.qemu-sd"
+CONVERSION_CMD_qemu-sd = "cp ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.qemu-sd; truncate -s %256M ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.qemu-sd"
CONVERSION_DEPENDS_qemu-sd = "coreutils-native"
Interesting, that comment on that file says:
# Define the 'qemu-sd' conversion type
#
# This conversion type pads any image to the 512K boundary to ensure that the
# image file can be used directly with QEMU's SD emulation which requires the
# block device to match that of valid SD card sizes (which are multiples of
# 512K).
As can be seen, the care was taken to pad the SD card image already,
but seems that QEMU requirements got changed after that. And my change
is indeed just a workaround, as it makes the image be padded to 256MB,
which works as intended up to 512MB of the image size (and not
practical for small images either).
A quick googling up led me to
https://support.xilinx.com/s/article/76596 which says:
> A check has been introduced in QEMU to see if image size is power of
> 2.
So, I assume it's a recent addition to Xilinx QEMU, though I didn't
check the sources.
--
Best Regards,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hello,
Coming back from vacation, I find myself in having a bit of trouble
getting back to various previous instructions/docs which were posted.
We seem to have 2 disjoint documentation repositories - one at Github
wiki, https://github.com/OpenAMP/openamp-system-reference/wiki , one at
Google Drive. So, I took care to cross-link gdrive folders/docs from
the main wiki.
I'm not sure if the split is intentional, e.g. if Google Drive contains
information which shouldn't be public. If so, please redact my changes
as needed.
Thanks,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hi all,
Hopefully everyone received the updated calendar invitation, pushing out by 1hr to avoid conflict with the Zephyr TSC weekly.
Please let me know if you have additional agenda topics. Here's what I've got so far:
* Individual updates
* If Bill has a chance to look at ST instructions, perhaps more in-depth discussion here.
* Any discussion points from Bill's notes on Tanmay's build steps (no changes required)?
* <Does Etsam have proposal for what to work on & dependencies?>
* What to shoot to accomplish before next Wednesday's call?
Just in case your calendar invitation is missing, you can use this link on 9/29 at 9am Pacific Time:
Join Zoom Meeting<https://xilinx.zoom.us/j/95281364886?pwd=U2dBN3RORmVyU3owb1lzd3BIcUREdz09&f…>
Thanks & regards,
Nathalie