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