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.
- 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.
- 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.
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.
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.)
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).
Thank you for your feedback
--Mark
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5225):
https://lists.yoctoproject.org/g/meta-xilinx/message/5225
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]]
-=-=-=-=-=-=-=-=-=-=-=-
