On 4/17/23 1:18 AM, Mike Looijmans wrote:
On 13-04-2023 16:05, Mark Hatle via lists.yoctoproject.org wrote:
On 4/13/23 1:29 AM, Mike Looijmans wrote:
One issue that now pops up is the MACHINE_ESSENTIAL_EXTRA_RDEPENDS
scripting,
in meta-xilinx-core/conf/machine/include/machine-xilinx-default.inc
MACHINE_ESSENTIAL_EXTRA_RDEPENDS .=
"${@bb.utils.contains('IMAGE_BOOT_FILES',
'boot.bin', ' ${PREFERRED_PROVIDER_virtual/boot-bin}', '', d)}"
Some boards DO boot from boot.bin in a fat filesystem (/boot). This is
why that was done. The additional files were placed there as well
(firmwares) so it can be reconstructed on the target, if necessary, or
again some boot methods allow a chained boot where parts can be loaded
from the filesystem.
My thoughts:
- If "some" machine(s) need this, wouldn't it be better to set these for
"some" machine only and not force it to all?
- As far as I know, boot.bin in /boot/ is pointless, the ROM cannot boot
from that. boot.bin must be in the root of the first FAT partition.
The default wks:
https://github.com/Xilinx/meta-xilinx/blob/mickledore-next/meta-xilinx-core/wic/xilinx-default-sd.wks
part /boot --source rootfs --change-directory=boot --fixed-size=512M
--fstype=vfat --use-label --label boot --active --align 4
part / --source rootfs --exclude-path=boot/ --fstype=ext4
--use-label --label root --align 4
The /boot partition is the first partition, FAT and mounted as /boot.
For this particular WKS, yes, maybe. But that would still install things
into the /boot of the rootfs, and then "hide" them by mounting a
partition on top of it.
It will install them into the filesystem "image" (tar.gz, cpio, ext4, etc), when
WKS is build, it then splits them into the two partitions, so "root" doesn't
contain anything inside of the /boot, it's in the separate partition.
Modern u-boot does not need this, it can read ext4 partitions (and may
others).
Yes, but the built-in firmware (when in emmc/sd mode) needs fat for the boot.bin
file. It can certainly be setup into a three partition setup for this mode, but
it's not something we've done at this point.
- On my systems, boot.bin is the one and only file in the fat partition.
Standard config (default u-boot scripting):
https://github.com/Xilinx/meta-xilinx/blob/mickledore-next/meta-xilinx-core/recipes-bsp/u-boot/u-boot-xlnx-scr/boot.cmd.generic.root
The boot mode is identified, assuming it's SD/emmc/usb is will attempt
to identify the media (the first fat partition).
So the boot.bin is required there, then an optional gitimage, optional
uenv config, the kernel, the system.dtb file, optional
devicetree/openamp.dtbo file, optional ramdisk.
So the other files need to be present, in the standard configuration.
If you deviate from this (providing your own u-boot configuration for
instance), then you need to adjust the IMAGE_BOOT_FILES parameter so
you can skip what you don't need.
Standard u-boot (and that includes u-boot-xlnx too) will look for a
bootable partition, and look for /boot/boot.scr in there. This usually
loads kernel and devicetree from that partition, and then mounts that
partition as rootfs.
If there's no bootable partition, it will fall back to the behavior that
you describe, and attempt to boot from the first (FAT) partition.
This allows you to have multiple partitions on the card, and select one
to boot by marking it bootable (using fdisk or parted or similar). Very
convenient for A/B upgrade systems.
So the files like kernel and devicetree need only be present in the
*bootable* partition. This need not be the first partition.
We've been using this for years, as it's the default for many (also
non-xilinx) systems. On our systems, the FAT partition only contains the
bootloader and nothing else. There are usually two (or more) additional
partitions of which one is marked bootable. Bootscript, kernel and
devicetree are inside the bootable partition.
I was aware of some of the above, but not all of the details. I will keep this
in mind as we continue to refactor the defaults.
We still need a way to load the boot.bin into the first fat partition (for an
SD/emmc boot), for QSPI, NAND or JTAG that is not needed. I do intend to
further refactor this using a boot mode mechanism going forward.
One of the reason the remaining files are in the same FAT partition as the
boot.bin (today) is workflow. A standard workflow for many developers is to
generate a revised kernel, device-tree, etc and simply copy the file into the
FAT partition vs construct an all new image. I have a requirement to continue
to support this more windows (FAT) oriented workflow.
The resulting goal of this is I want a mechanism that for SD/EMMC boot modes all
of the files will exist in the mounted filesystem and can be upgraded on the
device itself. For the remaining boot modes, the boot.bin should not exist in
the filesystem and would require a device specific update mechanism for
flashing/loading.
- It's still not correct to force files into the root filesystem. I
currently work around it by just setting
MACHINE_ESSENTIAL_EXTRA_RDEPENDS = "" which I consider an ugly hack.
That is just fine, it's what some images already do.
- It causes build fails on my system.
Can you give examples of failures?
All this is broken. This particular line will put "boot.bin" into the
root
filesystem. Boot files should NOT be in the root filesystem.
If you go back to the Poky WKS:
https://git.yoctoproject.org/poky/tree/scripts/lib/wic/canned-wks/sdimage-bootpart.wks
Then that file disappears as the /boot partition is generated vs
installed from packages. (There are other ways of handling this
through wic as well.)
WIC files aren't the only way to create images, and Xilinx isn't the
only SOM manufacturer.
We tend to use SWUpdate a lot, so we just flash the rootfs onto the
target over network.
Yes, the defaults are produced to provide a getting started view of
the system. They then require customization for individual boards. We
want the system to be easy for developers to use, modify and create
new images from the beginning.
In general, what you (as Xilinx) are doing to make things "easy" for
first-time setup makes it harder for more "real world" systems. Please
thread more carefully.
Like other meta-VENDOR layers, meta-xilinx should focus on MACHINE
support, and not try to be a distro and a bunch of other things too. It
should be possible to combine meta-xilinx with say meta-freescale or so.
We are working on this. meta-xilinx SHOULD be able to be combined with other
(non-xilinx) layers. There are dependencies that introduce meta-virtualization
and other requirements. We've not yet made those dynamic, but the remaining
items should not cause problems when building for non-Xilinx systems. If you
find an issue here, please report it.
There are really four different primary, and lots of sub types of components we
provide. machine conf infrastructure, reference machine.conf files, additional
components, and microblaze architecture support.
meta-xilinx-core is the machine conf infrastructure AND additional components
meta-xilinx-bsp is the reference machine.conf files
meta-microblaze is the microblaze architecture support
In each of the above cases, we've made an effort for these to play nice with
other layers, however we need people to tell us where there are specific
problems so we can add them to our TODO list.
meta-xilinx-tools on the otherhand this work has not been done. The components
that are modified SHOULD be meta-xilinx specific, but we've not done specific
work/validation on this to meet the needs of the Yocto Project compatible
testing and I suspect there are some interactions here that are unexpected.
There should be nothing in this design that prevents you from using
SWupdate or any other mechanism you wish, we're just trying to set
defaults that can help new people to the AMD/Xilinx SoC FPGA platforms
to quickly get up and running while still allowed eventual (necessary)
customization.
(side note, It's the defaults you set that are interfering. And I'm
having a hard time reverting them back to what others would consider
defaults.)
You've mentioned IMAGE_BOOT_FILES, what other problems have you had? If I have
specifics on how this interferes with the usage of other layers that helps be
create test cases and prevent this.
We designed this to expect the customization within the user's
machine.conf file, distro configuration and/or image recipes. If
there are places where we have prevented customization please let us
know. These are likely unintentional. (Note, I didn't say
local.conf. While you can override in local.conf, we've found this
leads to non-sharable, non-reproducible updates over time. We're
trying to steer users to creating their own machinec.conf files and
updating them for their own needs.)
Excellent.
But with that said, I'll look at what can be done to better control
this behavior, in a follow up. I don't want to hold off moving this
to langdale/mickledore much longer -- it's already taken me months to
get it to this point.
First assigning to a _XILINX variable and adding that would help a lot.
Then I can just override that to be empty and get standard OE
behavior back.
As we look into adding the boot mode support, I will consider doing
this. But I don't see anything wrong with you setting:
IMAGE_BOOT_FILES = "boot.bin"
MACHINE_ESSENTIAL_EXTRA_RDEPENDS = ""
etc within your custom machine.conf file that inherits from the base
set (after the inherit).
The concern here is that when MACHINE_ESSENTIAL_EXTRA_RDEPENDS gets
something that really is essential, all the machines that do this will
break. It means manual screening of changes in meta-xilinx and see if we
need to update all machine configs.
The tooling we're working on should assist in this. (First version is coming
soon, and is based on the existing PetaLinux workflows. While it's going to be
functional it will likely be a bit rough in some of the manual configuration
aspects. We're already working on planning refactoring of this tooling further,
with a focus on Yocto Project workflow and configuration.)
--Mark
Thank you for your feedback
--Mark
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5227):
https://lists.yoctoproject.org/g/meta-xilinx/message/5227
Mute This Topic: https://lists.yoctoproject.org/mt/98229455/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
