04:05 <xypron> pivi: distroboot relies on a file with the correct name residing in directory /dtbs/ of the boot partition. Debia and Ubuntu use package flash-kernel to copy the devicetree onto the boot partition.

09:54 <pivi> xypron: yep, that's clear. where I have iasue is with EFI boot, when not using the boot.scr method

10:00 <xypron> pivi: On Ubuntu booted non-secure via EFI update-grub adds a devicetree command to grub.cfg and flash-kernel will not write boot.scr. That way GRUB takes care of loading a devicetree matching the chosen kernel.

11:09 <pbrobinson> pivi: do you mean by specifying an out of FW DT like from a filesystem

11:10 <pbrobinson> A lot of the problems we see with Fedora is things like /usr/lib/ may not be available, you may have encrypted filesystem, LVM, a FS the FW can't read etc

11:11 <pbrobinson> I am mostly taking the stance it needs to be dealt with by the FW, we don't get the OS to provide ACPI tables for example

12:36 <pivi> pbrobinson: I see the point. On the other hand we have a different reality with DT files on embedded devices. Just to add one more data point, think at non-discoverable add-on hardware (e.g. DPI display), that are normally handled with DT overlay.

12:36 <pivi> pbrobinson: that would move the complete handling of this to the firmware, where updating is more complex than the OS

12:37 <pivi> xypron: do you have any pointer on how this is implemented? is this ubuntu specific (e.g. not available in Debian) ?

13:00 <xypron> pivi: Ubuntu's grub2 package has a patch debian/patches/ubuntu-add-devicetree-command-support.patch

13:09 <pivi> fix-ups are not applied by U-Boot when GRUB loads the device-tree ... one more unfortunate reason this is not a generic solution

13:10 <pivi> not sure if EFI is making life easier or more complicate here ...

13:10 <xypron> pivi: Ubuntu's GRUB calls the EFI_DT_FIXUP_PROTOCOL implemented by U-Boot to apply the fixups.

13:11 <xypron> pivi: https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL

13:14 <pbrobinson> pivi: the problem with overlays in Linux is some of these devices are not hot pluggable so you can't in a lot of cases actually deal with them in Linux

13:15 <pbrobinson> pivi: The BeagleBone people had a kernel cape manager thing that they threw away because of the problems of dealing with this in Linux and they now do it all in FW

13:16 <pbrobinson> pivi: IMO UEFI makes no difference here, it's just a defined API/hand off between FW and the OS. The same issues apply with extlinux directly from FW

13:17 <pivi> xypron: wondering how this could work in practice. one fixup that is done on my boards is setting the memorysize. other parts really check some condition to decide on fixups

13:18 <xypron> pivi: Exactly the same fixups are applied in the following cases: DT passed to bootefi command, DT pased to EFI_DT_FIXUP_PROTOCOL.

13:18 <pivi> pbrobinson: not sure if I get your points. I am not looking for hotplug capabilities here, I would jyst like the os to provvide a list of dtbo to u-boot

13:19 <pivi> xypron: I'll try it the next dayd

13:20 <pbrobinson> pivi: but how can the OS provide a list of DTB anything to the firmware if the OS isn't running at that time?

13:20 <pivi> pbrobinson: and this is something that's just easy to do with a boot.scr (we do have it implemented)

13:20 <xypron> pivi: if you want the OS to supply dtbo's the best thing is to let the OS generate a boot.scr script.

13:21 <pbrobinson> but the boot.scr isn't provided by the OS, it's generated by a tool and is readable by the FW

13:21 <pivi> pbrobinson: a file? extlinyx.conf allows it

13:21 <pbrobinson> right, but that's not being provided by the OS, it's basically an independent operation

13:21 <xypron> extlinux.conf is also generated by a tool.

13:21 <xypron> u-boot-menu

13:22 <pbrobinson> the extlinux.conf is generated a number of ways

13:22 <xypron> At least in Ubuntu it is generated by the u-boot-menu package.

13:22 <pivi> to be clear, I am wondering on how to get of a well polished user experience. e.g. install the distro just works

13:22 <pivi> yes, I am well aware of those tools

13:23 <pbrobinson> I have x86 devices which accept overlays style things in HW and that's done in a horrible way from the FW as well to provide the OS with ACPI tables

13:24 <pbrobinson> pivi: I agree we need to improve the way overlays are dealt with, I have been trying to work that out for some time but I am basically at a similar stalemate to where you're at

13:24 <pivi> anyways, as OS I meant the Linux distro, tools included

13:26 <pivi> this on my side started as : why I can't just install debian on my boards? and there the journey you are well aware of started also for me

13:26 <xypron> pivi: if you are thinking of removable add on HW then updating the list of dtbos from the OS is not helpful as on the next boot those dtbos may be the wrong ones.

13:27 <pivi> xypron: I do not see a solution for that. you'll just have to update such list if you alter your hw config

13:27 <pivi> of course, I am thinking at non discoverable hw

13:28 <pbrobinson> well some of the "non discoverable HW" can be dealt with by using eeproms and related, this is how both the Beagle and RPi ecosystem deal with it

13:28 <xypron> The bug is having non-discoverable HW. Plug-and-play is a few decades old.

13:29 <pivi> yes, if you add eeprom like that you are effectively making the hw discoverable

13:29 <pivi> but none of this is standardized

13:29 <pivi> xypron: s/bug/reality

13:30 <xypron> design bug I mean

13:31 <pivi> anyway, would be nice to have this standardized some way

13:31 <pivi> having every vendor come up with their own solution means you'll have to customuze for each of them

13:32 <pbrobinson> there's other ways to detect if the HW is within a known range for a particular device, like a small selection of display options. There's lots of examples of that in U-Boot for detecting revs of HW or variants with different features

13:33 <pbrobinson> pivi: well the overlay side of things in U-Boot is quite standardised already, what isn't yet is a nice UX for dealing with it, and we sort of have the starts of that

13:34 <pivi> you would need to handle the new display that does not exist yet when firmware, e.g. u-boot, is deployed on the device

13:35 <pivi> how wpuld you handle that now in a generic way?

13:35 <pivi> I mean, I know how can I make it work manually

13:36 <pivi> my mind is really at a "just works" experience with a random distro

13:39 <pbrobinson> the only way you can make it just work with random distros is have the FW deal with it

13:39 <pivi> anyway, any of you is at Fosdem next month?

13:47 <pbrobinson> pivi: I may be, I need to review that

13:47 <jkridner> Beagle did a blog series of how to make dtbos compatible between boards and kernel versions by producing compatible symbols.

13:48 <pivi> pbrobinson: just reach out, in case, would be nice to have a chat in person

13:48 <pbrobinson> yep, will try to remember as I work it out :)

13:49 <pivi> jkridner: I assume it's relatively easy to get it working, the challenge is an out if the box experience that just works on any distro

13:50 <pivi> e.g. think at an x86 pc with device on pci

13:52 <pivi> (with easy I mean that all the basic tooling is there today)

13:53 <pbrobinson> well an arm device with devices on pci already just work

13:55 <pivi> with the correct dtb provide by the firmware. that may or may not be trivial. think at the 1000th changes in boot/dtb every kernel version ...

13:55 <pivi> (in linux)

14:07 <sjg1> I am probably going to be at Fosdem and am interested in this topic

14:08 <sjg1> pivi: I send a proposal for extensions here: https://lore.kernel.org/u-boot/CAPnjgZ06s64C2ux1rABNAnMv3q4W++sjhNGCO_uPMH_9sTF7Mw@mail.gmail.com/

14:08 <sjg1> Basically my proposal is to use a sysinfo driver to return information about what the board is, in the form of a list of compatible strings

14:15 <pivi> sjg1: cool, let's find a way to meet, I expect we could organize something

14:16 <pivi> sending an email to the list could be a nice idea

15:06 <IoT-Maker> i have an older Marvell u-boot 2.33 shell here. U-Boot starts a vxworks in and after that a linux an a Marvell Armada XP CPU. I need to manually update but there is no network either in vxworks or u-boot. I have serial console access and openocd/jtag. I was able to dump files from vxworks side from NOR flash using openocd. But how can i store files on vxworks side?

15:06 <IoT-Maker> There is a usbbubt command in u-boot. But how can i use this to store an image?

15:07 <IoT-Maker> I couldn't find documentation about usbbubt command.

15:23 <xypron> IoT-Maker: usbbubt is not an upstream U-Boot command. 'help usbbubt' should provide some informstion. Maybe this page helps: https://elixir.bootlin.com/u-boot/latest/source/doc/mvebu/cmd/bubt.txt

15:45 <IoT-Maker> xyprom: Thank you for the link. help usbbubt tells me: usbbubt - Burn an image on the eUSB module, default file-name is vxWorks. Usage: usbbubt <file-name>, Burn an image on the eUSB module, default file-name is vxWorks. I was asking myself how i can set the source of a file. In your link they explain it comes from tftp. Sadly i can't setup ethernet on u-boot. It is not accessible. I can set an ip and server-ip, but

15:45 <IoT-Maker> thats all.

16:00 <Forty-Bot> IoT-Maker: if you have jtag, you can try getting U-Boot running with that

16:00 <Forty-Bot> IoT-Maker: although some armada boards got removed recently, so you may need to start with e.g. 2021.04 or something

23:25 <yang> Happy GNU year !