Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: [email protected]
W: www.topic.nl
Please consider the environment before printing this e-mail
On 14-04-2023 16:07, Mark Hatle via lists.yoctoproject.org wrote:
On 4/14/23 1:02 AM, Mike Looijmans wrote:
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: [email protected]
W: www.topic.nl
Please consider the environment before printing this e-mail
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.
Modern u-boot does not need this, it can read ext4 partitions (and may
others).
- 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.
- 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.
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.)
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.
Thank you for your feedback
--Mark
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5226):
https://lists.yoctoproject.org/g/meta-xilinx/message/5226
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]]
-=-=-=-=-=-=-=-=-=-=-=-
