Re: [PATCH v2 00/21] Universal Payload initial series
> From: Simon Glass > Date: Sat, 13 Jul 2024 08:00:34 +0100 > > Universal Payload (UPL) is an Industry Standard for firmware > components[1]. I think you have some trouble understanding the concept of industry standard ;). I guess you want this to become an industry standard. Firmly https://xkcd.com/927/ territory if you ask me. > UPL is designed to improve interoperability within the > firmware industry, allowing mixing and matching of projects with less > friction and fewer project-specific implementations. UPL is > cross-platform, supporting ARM, x86 and RISC-V initially. > > This series provides some initial support for this, targeting 0.9.1 and > sandbox only. > > Features still to come include: > - Support for architectures > - FIT validation > - Handoff validation > - Interoperability tests > > This series is available at dm/uplb-working and requires the alist > series at dm/alist-working[2] > > [1] https://universalpayload.github.io/spec/ > [2] https://patchwork.ozlabs.org/project/uboot/list/?series=414642 > > Changes in v2: > - Put the upl tests under their own subcommand to avoid bootstd init > - Add a function to init the UPL process in SPL > - Hang when something goes wrong, to avoid a broken boot > - Add a runtime flag to enable UPL > - Add a link to the spec > - Add a link to the command > - Support CI testing > - Rework to use alist instead of fixed-length arrays > > Simon Glass (21): > sandbox: Use const in os_jump_to_file() > sandbox: Fix a comment in os_find_u_boot() > test: Move some SPL-loading test-code into sandbox common > sandbox: Enable SPL_LOAD_BLOCK > fdt: Don't overwrite bloblist devicetree > sandbox: fdt: Avoid overwriting an existing fdt > sandbox: Return error code from read/write/seek > sandbox: Add ELF file to VPL u-boot.img > sandbox: Set up global_data earlier > upl: Add support for reading a upl handoff > upl: Add support for writing a upl handoff > upl: Add basic tests > upl: Add a command > upl: Add support for Universal Payload in SPL > spl: Plumb in the Universal Payload handoff > upl: Plumb in universal payload to the init process > sandbox_vpl: Enable Universal Payload > upl: Add initial documentation > sandbox: Add a flag to enable UPL > sandbox: Add an SPL loader for UPL > upl: Add an end-to-end test > > MAINTAINERS | 13 + > Makefile | 4 +- > arch/sandbox/cpu/cpu.c| 2 + > arch/sandbox/cpu/os.c | 30 +- > arch/sandbox/cpu/spl.c| 116 +- > arch/sandbox/cpu/start.c | 18 +- > arch/sandbox/include/asm/spl.h| 15 + > arch/sandbox/include/asm/state.h | 1 + > boot/Kconfig | 70 > boot/Makefile | 4 + > boot/upl_common.c | 60 +++ > boot/upl_common.h | 24 ++ > boot/upl_read.c | 588 > boot/upl_write.c | 622 ++ > cmd/Kconfig | 7 + > cmd/Makefile | 1 + > cmd/upl.c | 118 ++ > common/board_f.c | 22 ++ > common/board_r.c | 2 + > common/spl/Kconfig| 1 + > common/spl/Makefile | 2 + > common/spl/spl.c | 8 + > common/spl/spl_fit.c | 22 ++ > common/spl/spl_upl.c | 171 > configs/sandbox_defconfig | 1 + > configs/sandbox_vpl_defconfig | 4 + > doc/usage/cmd/upl.rst | 186 + > doc/usage/index.rst | 2 + > doc/usage/upl.rst | 46 +++ > drivers/block/sandbox.c | 4 +- > drivers/usb/emul/sandbox_flash.c | 2 +- > fs/sandbox/sandboxfs.c| 6 +- > include/asm-generic/global_data.h | 19 + > include/os.h | 6 +- > include/spl.h | 16 + > include/test/suites.h | 1 + > include/upl.h | 361 + > lib/fdtdec.c | 1 + > test/boot/Makefile| 2 + > test/boot/upl.c | 436 + > test/cmd_ut.c | 3 + > test/image/spl_load_os.c | 53 +-- > test/py/tests/test_upl.py | 38 ++ > 43 files changed, 3036 insertions(+), 72 deletions(-) > create mode 100644 boot/upl_common.c > create mode 100644 boot/upl_common.h > create mode 100644 boot/upl_read.c > create mode 100644 boot/upl_write.c > create mode 100644 cmd/upl.c > create mode 100644 common/spl/spl_upl.c > create mode 100644 doc/usage/cmd/upl.rst > create mode 100644 doc/usage/upl.rst > create mode 100644 include/upl.h > create mode 100644 test/boot/upl.c > create mode 100644 test/py/tests/test_upl.py > > -- > 2.34.1 > >
Re: [PATCH 1/2] led: Implement software led blinking
> From: Mikhail Kshevetskiy
> Date: Fri, 5 Jul 2024 06:26:24 +0400
>
> From: Michael Polyntsov
>
> If hardware (or driver) doesn't support leds blinking, it's
> now possible to use software implementation of blinking instead.
> This relies on cyclic functions.
>
> v2 changes:
> * Drop sw_blink_state structure, move its necessary fields to
>led_uc_plat structure.
> * Add cyclic_info pointer to led_uc_plat structure. This
>simplify code a lot.
> * Remove cyclic function search logic. Not needed anymore.
> * Fix blinking period. It was twice large.
> * Other cleanups.
>
> v3 changes:
> * Adapt code to recent cyclic function changes
> * Move software blinking functions to separate file
> * Other small changes
>
> Signed-off-by: Michael Polyntsov
> Signed-off-by: Mikhail Kshevetskiy
> ---
> drivers/led/Kconfig| 14 +
> drivers/led/Makefile | 1 +
> drivers/led/led-uclass.c | 16 +-
> drivers/led/led_sw_blink.c | 106 +
> include/led.h | 17 ++
> 5 files changed, 152 insertions(+), 2 deletions(-)
> create mode 100644 drivers/led/led_sw_blink.c
>
> diff --git a/drivers/led/Kconfig b/drivers/led/Kconfig
> index 9837960198d..dc9d4c8a757 100644
> --- a/drivers/led/Kconfig
> +++ b/drivers/led/Kconfig
> @@ -73,6 +73,20 @@ config LED_BLINK
> This option enables support for this which adds slightly to the
> code size.
>
> +config LED_SW_BLINK
> + bool "Support software LED blinking"
> + depends on LED_BLINK
> + select CYCLIC
> + help
> + Turns on led blinking implemented in the software, useful when
> + the hardware doesn't support led blinking. Half of the period
> + led will be ON and the rest time it will be OFF. Standard
> + led commands can be used to configure blinking. Does nothing
> + if driver supports blinking.
> + WARNING: Blinking may be inaccurate during execution of time
> + consuming commands (ex. flash reading). Also it completely
> + stops during OS booting.
Doesn't that make this feature pretty much pointless?
> config SPL_LED
> bool "Enable LED support in SPL"
> depends on SPL_DM
> diff --git a/drivers/led/Makefile b/drivers/led/Makefile
> index 2bcb8589087..e27aa488482 100644
> --- a/drivers/led/Makefile
> +++ b/drivers/led/Makefile
> @@ -4,6 +4,7 @@
> # Written by Simon Glass
>
> obj-y += led-uclass.o
> +obj-$(CONFIG_LED_SW_BLINK) += led_sw_blink.o
> obj-$(CONFIG_LED_BCM6328) += led_bcm6328.o
> obj-$(CONFIG_LED_BCM6358) += led_bcm6358.o
> obj-$(CONFIG_LED_BCM6753) += led_bcm6753.o
> diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c
> index f37bf6a1550..37dc99cecdc 100644
> --- a/drivers/led/led-uclass.c
> +++ b/drivers/led/led-uclass.c
> @@ -58,6 +58,10 @@ int led_set_state(struct udevice *dev, enum led_state_t
> state)
> if (!ops->set_state)
> return -ENOSYS;
>
> + if (IS_ENABLED(CONFIG_LED_SW_BLINK) &&
> + led_sw_on_state_change(dev, state))
> + return 0;
> +
> return ops->set_state(dev, state);
> }
>
> @@ -68,6 +72,10 @@ enum led_state_t led_get_state(struct udevice *dev)
> if (!ops->get_state)
> return -ENOSYS;
>
> + if (IS_ENABLED(CONFIG_LED_SW_BLINK) &&
> + led_sw_is_blinking(dev))
> + return LEDST_BLINK;
> +
> return ops->get_state(dev);
> }
>
> @@ -76,8 +84,12 @@ int led_set_period(struct udevice *dev, int period_ms)
> {
> struct led_ops *ops = led_get_ops(dev);
>
> - if (!ops->set_period)
> - return -ENOSYS;
> + if (!ops->set_period) {
> + if (IS_ENABLED(CONFIG_LED_SW_BLINK))
> + return led_sw_set_period(dev, period_ms);
> + else
> + return -ENOSYS;
> + }
>
> return ops->set_period(dev, period_ms);
> }
> diff --git a/drivers/led/led_sw_blink.c b/drivers/led/led_sw_blink.c
> new file mode 100644
> index 000..ab56111a60b
> --- /dev/null
> +++ b/drivers/led/led_sw_blink.c
> @@ -0,0 +1,106 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Software blinking helpers
> + * Copyright (C) 2024 IOPSYS Software Solutions AB
> + * Author: Mikhail Kshevetskiy
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +static void led_sw_blink(struct cyclic_info *c)
> +{
> + struct led_uc_plat *uc_plat;
> + struct udevice *dev;
> + struct led_ops *ops;
> +
> + uc_plat = container_of(c, struct led_uc_plat, cyclic);
> + dev = uc_plat->dev;
> + ops = led_get_ops(dev);
> +
> + switch (uc_plat->sw_blink_state) {
> + case LED_SW_BLINK_ST_OFF:
> + uc_plat->sw_blink_state = LED_SW_BLINK_ST_ON;
> + ops->set_state(dev, LEDST_ON);
> + break;
> + case LED_SW_BLINK_ST_ON:
> + uc_plat->sw_blink_state = LED_SW_BLINK_ST_OFF;
> + ops->set_state(dev, LEDST_OFF);
>
Re: [PATCH 2/3] rockchip: fix wrong PCI range address in rk3568 dtsi
> Date: Tue, 25 Jun 2024 10:29:48 +0200 > From: Jonas Karlman Hi Jonas, > Hi Etienne, > > On 2024-06-25 08:47, Etienne Dublé wrote: > > Hi Quentin, > > > > Le 24/06/2024 à 15:15, Quentin Schulz a écrit : > >> Hi Etienne, > >> > >> On 6/24/24 2:40 PM, ETIENNE DUBLE wrote: > >>> One of the PCI ranges was wrong in this device tree. > >>> When testing with a FriendlyElec Nanopi R5C board, the > >>> 2nd ethernet interface (labelled "wan") was not working > >>> in u-boot because of that. > >>> > >>> With the correct value (found in FriendlyElec's downstream > >>> u-boot repository), this 2nd ethernet interface now works. > >>> > >>> Signed-off-by: Etienne Dublé > >>> --- > >>> > >>> dts/upstream/src/arm64/rockchip/rk3568.dtsi | 2 +- > >> > >> dts/upstream is only for patches coming from **merged** Linux kernel > >> (i.e. releases or -rc releases or master branch from Linus Torvalds). > >> > >> We do not accept U-Boot-only patches in dts/upstream. > >> > >> Please submit the patch to the Linux kernel first and it will > >> eventually make it to that directory either via a > >> dts/update-dts-subtree.sh pull or dts/update-dts-subtree.sh pick. > >> Depending on maintainer's opinion, fixing the range in > >> arch/arm/dts/rk3568-u-boot.dtsi could be an option, but we really need > >> the patch sent to upstream Linux kernel community first. > >> > >> c.f. https://www.kernel.org/doc/html/v6.5/process/submitting-patches.html > > > > I see, I will look at it. > > In version 2 of the series I will remove this second patch and just > > mention that we are waiting for this problem to be fixed upstream, in > > the cover letter. > > I do not understand the need for such/this patch. The changed address is > the internal io address that is shared with the pci controller and > devices. > > Do you have any issue in linux or is it only in U-Boot?, I suspect this > change is only a workaround to an issue only found in U-Boot. I do see similar issues on OpenBSD, where some configurations of the outbound address translation windows work fine and others don't. It does seem to depend on the PCIe device, but the only configuration that seems to work for everything is when the translation of the mmio windows is 1:1. So for OpenBSD we build U-Boot with a pacthed device tree. The downside of using a 1:1 translation for mmio is that this reduces the size of the 32-bit PCI mmio address space. Now I can't rule out that there are bugs in the OpenBSD driver for the RK3568 PCIe controller, but the driver seems to work fine on other PCIe controllers derived from the Synopsis DesignWare stuff. Etienne's diff isn't using 1:1 translation though. It just makes sure the lower 32 bits of the address are translated 1:1. I'll see if I can retest OpenBSD with such a setup. > The rtl8169 driver or pci system of U-Boot may be of fault and should > probably be fixed instead of changing io addresses to work around issues > in software. E.g rtl8169 has a static ioaddr that is shared between all > drivers, something that may cause issues. > > Regards, > Jonas > > > > > Cheers, > > Etienne > > > >
Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)
> Date: Fri, 21 Jun 2024 00:22:43 +0200 > From: Quentin Schulz Hi Quentin, > FYI, the DDR bin is printing stuff on the console, so we had to modify > it (with a tool from Rockchip) to remove the gibberish breaking the > terminal by setting the appropriate controller, mux and baudrate (for > our products, there's no one size fits all :) ). The question is how to > handle this since we cannot realistically store every possible > permutation of that binary for each UART controller, mux of UART > controller and baudrate (the only parameters **we** modify, but there > are tons of others). To build the RK356x and RK3588 of the u-boot packages on OpenBSD I've written a small program that changes the baudrate from 150 to 115200: https://github.com/openbsd/ports/blob/master/sysutils/u-boot/rk356x/files/rkbinpatch.c https://github.com/openbsd/ports/blob/master/sysutils/u-boot/rk3588/files/rkbinpatch.c This just does the bare minimum and it might break with future changes to the layout of the binaries. But I don't think it would be difficult to add a few more parameters. Cheers, Mark
Re: [PATCH 0/4] rockchip: Add gpio request() ops and drop PCIe reset-gpios workaround
> Date: Mon, 13 May 2024 00:23:33 +0200 > From: Jonas Karlman Hi Jonas, Sorry for the delayed reply. Last week was a bit busy here... > Hi Mark, > > On 2024-05-12 22:41, Mark Kettenis wrote: > >> Date: Sat, 11 May 2024 22:55:18 +0200 > >> From: Jonas Karlman > >> > >> Hi Mark, > >> > >> On 2024-05-11 21:57, Mark Kettenis wrote: > >>>> Date: Sat, 11 May 2024 20:47:40 +0200 > >>>> From: Jonas Karlman > >>> > >>> Hi Jonas & Alex, > >>> > >>>> Hi Alex, > >>>> > >>>> On 2024-05-11 19:44, Alex Bee wrote: > >>>>> Hi Jonas, > >>>>> > >>>>> Am 11.05.24 um 13:28 schrieb Jonas Karlman: > >>>>>> This series add gpio request() and pinctrl gpio_request_enable() ops so > >>>>>> that a gpio requested pin automatically use gpio pinmux and U-Boot > >>>>>> behaves more similar to Linux kernel. > >>>>> > >>>>> I'm not sure that's a good idea. > >>>>> While linux does it the same way, we really shouldn't expect every > >>>>> software/os/ … which uses DT (now or in future) to implicitly switch > >>>>> the > >>>>> pin function when using a pin as gpio. So the real fix would probably > >>>>> be > >>>>> to add the the correct pinctrl settings to the upstream DT of those > >>>>> boards and sync it later on (not sure those if those SoCs already using > >>>>> OF_UPSTREAM) and leave the -u-boot.dtsi-"hack" alone for now. > >>> > >>> I missed Alex's mail, but OpenBSD certainly is one of the OSes that > >>> could break if the pinctrl settings get removed. We currently have no > >>> code to automatically mux the gpio pins on these Rockchip SoCs. I > >>> suppose as long as U-Boot probes the PCIe bus, the pins will already > >>> be muxed correctly and things will continue to work. But I think > >>> there are certain boot scenarios where this won't happen. > >> > >> The control FDT on the known affected boards was only patched to prevent > >> the boards from a full device freeze when PCIe was enumerated. An OS > >> should probably not depend on a workaround made for U-Boot use. > > > > Sure, but I think that means we should try to minimise the number of > > workarounds in U-Boot ;). > > Agree, and something this series tries to accomplish, removing one "bad" > workaround so that once upstream DT is fixed and it trickle down to > dts/upstream/ nothing else needs to be changed in U-Boot. To me it looks as if you're trying to replace an "incomplete" fix with a "questionable" workaround. > >> Is it common for *BDS to use the control FDT or is it more common that a > >> separate .dtb-file to be loaded during boot? > > > > Not sure what the other BSDs do; at this point they're largely > > separate codebases that just share a common ancestry. And I don't > > really like the term "control FDT"; in ideal world there should be > > just be a single FDT that gets used by the various firmware layers, > > U-Boot and the OS. But yes, my goal is to make OpenBSD work with FDT > > provided by U-Boot without loading a separte .dtb file. > > Thanks for the insights. Typically I test linux-next kernel using the > FDT provided by U-Boot. Any suggestions on how I can get a minimal > OpenBSD snapshot to boot on e.g. a RK356x board? Very simple. Just take it a "miniroot" image, e.g. the 7.5 release image: https://ftp.openbsd.org/pub/OpenBSD/7.5/arm64/miniroot75.img and use dd to write it to a micro-SD card or a USB flash drive. I usually put OpenBSD on a USB flash drive and U-Boot on a micro-SD card for testing. If you prefer to use a micro-SD card, just use dd to write u-boot-rockchip.bin on top of the "miniroot" image. This will boot into the installer, but that is probably good enough for testing U-Boot. > >> To recap, the issue on e.g. ROCK 3A is that the upstream DT use pinctrl > >> to signal PCIE30X2 CLKREQn_M1/WAKEn_M1/PERSTn_M1 function, DT also > >> specify a reset-gpios prop pointing on PERSTn_M1. To me this seem like a > >> correct description of HW. > > > > Actually I'm starting to think that it isn't. If you look at table > > 11-11 in Part 2 of the RK3588 TRM (V1.0) you'll see that the > > pcie_perst_n signal is designated as input. The corrsponding chapter > > is missing from the copy
Re: [RFC 02/14] efi_loader: library function efi_dp_merge
> Date: Tue, 14 May 2024 14:49:47 +0200
> From: Heinrich Schuchardt
Hi Heinrich,
> On 4/26/24 17:47, Ilias Apalodimas wrote:
> > Hi Heinrich
> >
> > On Fri, 26 Apr 2024 at 17:53, Heinrich Schuchardt
> > wrote:
> >>
> >> On 26.04.24 16:30, Ilias Apalodimas wrote:
> >>> Hi Heinrich,
> >>>
> >>> On Fri, 26 Apr 2024 at 17:13, Heinrich Schuchardt
> >>> wrote:
>
> Provide a function to append a device_path to a list of device paths
> that is separated by final end nodes.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> include/efi_loader.h | 3 +++
> lib/efi_loader/efi_device_path.c | 31 +++
> 2 files changed, 34 insertions(+)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 9600941aa32..a7d7b8324f1 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -944,6 +944,9 @@ struct efi_load_option {
>
> struct efi_device_path *efi_dp_from_lo(struct efi_load_option *lo,
> const efi_guid_t *guid);
> +struct efi_device_path *efi_dp_merge(const struct efi_device_path *dp1,
> +efi_uintn_t *size,
> +const struct efi_device_path *dp2);
> struct efi_device_path *efi_dp_concat(const struct efi_device_path
> *dp1,
> const struct efi_device_path
> *dp2,
> bool split_end_node);
> diff --git a/lib/efi_loader/efi_device_path.c
> b/lib/efi_loader/efi_device_path.c
> index 46aa59b9e40..16cbe41d32f 100644
> --- a/lib/efi_loader/efi_device_path.c
> +++ b/lib/efi_loader/efi_device_path.c
> @@ -270,6 +270,37 @@ struct efi_device_path *efi_dp_dup(const struct
> efi_device_path *dp)
> return ndp;
> }
>
> +/**
> + * efi_dp_merge() - Concatenate two device paths separated by final end
> node
> + *
> + * @dp1: first device path
> + * @size: pointer to length of @dp1, total size on return
> + * @dp2: second device path
> + *
> + * Return: concatenated device path or NULL
> + */
> +struct efi_device_path *efi_dp_merge(const struct efi_device_path *dp1,
> +efi_uintn_t *size,
> +const struct efi_device_path *dp2)
> +{
> + efi_uintn_t len, len1, len2;
> + struct efi_device_path *dp;
> + u8 *p;
> +
> + len1 = *size;
> + len2 = efi_dp_size(dp2) + sizeof(END);
> + len = len1 + len2;
> + dp = efi_alloc(len);
> + if (!dp)
> + return NULL;
> + memcpy(dp, dp1, len1);
> + p = (u8 *)dp + len1;
> + memcpy(p, dp2, len2);
> + *size = len;
> >>>
> >>> Can't we just use efi_dp_concat()?
> >>
> >> efi_dp_concat cannot be used to put a device-path end-node in between
> >> two device-paths that are concatenated. We need that separator in the
> >> load options.
> >
> > I am not sure I am following you. It's been a few years so please bear
> > with me until I manage to re-read that code and page it back to
> > memory.
> >
> > What I remember though is that the format of the DP looks like this:
> >
> > Loaded image DP - end node - initrd GUID DP (without and end node) -
> > initrd - end of device path.
> > So to jump from the special initrd GUID to the actual DP that contains
> > the initrd you need to do an efi_dp_next(). Also, efi_dp_concat() will
> > inject an end node with a DEVICE_PATH_SUB_TYPE_END type if the third
> > argument is 'true'.
> >
> > What am I missing?
>
> Let us assume
>
> dp1 = /vmlinux/endnode/initrd/endnode
> dp2 = /dtb/endnode
>
> and we invoke dp_concat(dp1, dp2, true):
>
> sz1 is calculated via the efi_dp_size() function which looks for the
> *first* device-path end node.
>
> sz1 = efi_dp_size(dp1) = sizeof(/vmlinux)
>
> sz1 will not include initrd and its endnode.
>
> So dp_concat(/vmlinux/endnode/initrd/endnode, /dtb/endnode, true)
> will return:
>
> /vmlinux/endnode/dtb/endnode
>
> but in our boot option we want
>
> /vmlinux/endnode/initrd/endnode/dtb/endnode
That makes me realize a potential flaw with the design of this boot
option. The concept of an initrd is Linux-specific, but the concept
of loading a DTB to pass along to an EFI image far less so. So how
would this work if I want to only pass the DTB? Would that be:
/vmlinux/endnode/endnode/dtb/endnode
?
Re: [PATCH 0/4] rockchip: Add gpio request() ops and drop PCIe reset-gpios workaround
> Date: Sun, 12 May 2024 21:49:21 +0200
> From: Alex Bee
>
> Am 11.05.24 um 20:47 schrieb Jonas Karlman:
> > Hi Alex,
> >
> > On 2024-05-11 19:44, Alex Bee wrote:
> >> Hi Jonas,
> >>
> >> Am 11.05.24 um 13:28 schrieb Jonas Karlman:
> >>> This series add gpio request() and pinctrl gpio_request_enable() ops so
> >>> that a gpio requested pin automatically use gpio pinmux and U-Boot
> >>> behaves more similar to Linux kernel.
> >> I'm not sure that's a good idea.
> >> While linux does it the same way, we really shouldn't expect every
> >> software/os/ … which uses DT (now or in future) to implicitly switch the
> >> pin function when using a pin as gpio. So the real fix would probably be
> >> to add the the correct pinctrl settings to the upstream DT of those
> >> boards and sync it later on (not sure those if those SoCs already using
> >> OF_UPSTREAM) and leave the -u-boot.dtsi-"hack" alone for now.
> > I fully agree that the pinctrl for the problematic boards should be
> > corrected in upstream DT, but that is a separate issue and should not
> > block adding support for the request()/gpio_request_enable() ops.
> >
> > While the pcie reset-gpios full board freeze that was my driving factor
> > to fully implement the gpio request() ops it is not the only use case,
> > using the gpio cmd on a pin that use a non-gpio pinmux is another.
> >
> > Or do you see any technical issue with having the gpio request() ops
> > implemented and having it ensure gpio pinmux is used on a gpio requested
> > pin? Similar to how gpio/pinctrl is behaving in Linux and on some other
> > platforms in U-Boot?
> No, no general ("technical") issue with adding a .request hook to the gpio
> driver. But now you are now moving the original workaround to an even more
> invisible place which does things implicitly. Maybe just don't remove the
> pinctrl from the boards u-boot-dtsi's - just replace it with
>
> _pins {
> rockchip,pins =
> <2 RK_PD4 4 _pull_none>,
> <2 RK_PD6 RK_FUNC_GPIO _pull_none>,
> <2 RK_PD5 4 _pull_none>;
> };
>
> Even if it would (now) work without. It, at least, documents that there are
> things left to do for the upstream DT.
Right. See the reply I just sent to Jonas. I think that is the right
approach. Probably means that the upstream rk3568-pinctrl.dtsi should
grow separate nodes for when the PCIe controller is in EP or RC mode.
Or maybe the perstn configuration should be split out from the
clkreqn/waken configuration like how buttonrstn is configured.
> What you were saying in reply to Mark's email is not completely true: Not
> all pins are initialized with gpio func as default. It actually depends on
> the pin which function the bootrom sets initially. In case of RK356x's
> GPIO2_PD6 (the pin in question) it's BT656_D6M0 (func2), for instance. So,
> in fact, you are changing it's function when implicitly setting it's func
> to gpio (func0).
>
> Alex
>
> >
> > Regards,
> > Jonas
> >
> >> Alex
> >>> With the gpio and pinctrl ops implemented this series also remove a PCIe
> >>> reset-gpios related device lock-up workaround from board u-boot.dtsi.
> >>>
> >>> PX30, RK3066, RK3188, RK356x and RK3588 are the only SoCs that currently
> >>> define gpio-ranges props and is affected by this series.
> >>>
> >>> A follow up series adding support for the pinmux status cmd will also
> >>> add gpio-ranges props for remaining RK SoCs.
> >>>
> >>> Jonas Karlman (4):
> >>> pinctrl: rockchip: Add gpio_request_enable() ops
> >>> gpio: rockchip: Add request() ops
> >>> rockchip: rk3568-rock-3a: Drop PCIe reset-gpios workaround
> >>> rockchip: rk3568-radxa-e25: Drop PCIe reset-gpios workaround
> >>>
> >>>arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 12 ---
> >>>arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 12 ---
> >>>drivers/gpio/rk_gpio.c| 10 ++
> >>>.../pinctrl/rockchip/pinctrl-rockchip-core.c | 31 +++
> >>>4 files changed, 41 insertions(+), 24 deletions(-)
> >>>
>
Re: [PATCH 0/4] rockchip: Add gpio request() ops and drop PCIe reset-gpios workaround
> Date: Sat, 11 May 2024 22:55:18 +0200 > From: Jonas Karlman > > Hi Mark, > > On 2024-05-11 21:57, Mark Kettenis wrote: > >> Date: Sat, 11 May 2024 20:47:40 +0200 > >> From: Jonas Karlman > > > > Hi Jonas & Alex, > > > >> Hi Alex, > >> > >> On 2024-05-11 19:44, Alex Bee wrote: > >>> Hi Jonas, > >>> > >>> Am 11.05.24 um 13:28 schrieb Jonas Karlman: > >>>> This series add gpio request() and pinctrl gpio_request_enable() ops so > >>>> that a gpio requested pin automatically use gpio pinmux and U-Boot > >>>> behaves more similar to Linux kernel. > >>> > >>> I'm not sure that's a good idea. > >>> While linux does it the same way, we really shouldn't expect every > >>> software/os/ … which uses DT (now or in future) to implicitly switch the > >>> pin function when using a pin as gpio. So the real fix would probably be > >>> to add the the correct pinctrl settings to the upstream DT of those > >>> boards and sync it later on (not sure those if those SoCs already using > >>> OF_UPSTREAM) and leave the -u-boot.dtsi-"hack" alone for now. > > > > I missed Alex's mail, but OpenBSD certainly is one of the OSes that > > could break if the pinctrl settings get removed. We currently have no > > code to automatically mux the gpio pins on these Rockchip SoCs. I > > suppose as long as U-Boot probes the PCIe bus, the pins will already > > be muxed correctly and things will continue to work. But I think > > there are certain boot scenarios where this won't happen. > > The control FDT on the known affected boards was only patched to prevent > the boards from a full device freeze when PCIe was enumerated. An OS > should probably not depend on a workaround made for U-Boot use. Sure, but I think that means we should try to minimise the number of workarounds in U-Boot ;). > Is it common for *BDS to use the control FDT or is it more common that a > separate .dtb-file to be loaded during boot? Not sure what the other BSDs do; at this point they're largely separate codebases that just share a common ancestry. And I don't really like the term "control FDT"; in ideal world there should be just be a single FDT that gets used by the various firmware layers, U-Boot and the OS. But yes, my goal is to make OpenBSD work with FDT provided by U-Boot without loading a separte .dtb file. > To recap, the issue on e.g. ROCK 3A is that the upstream DT use pinctrl > to signal PCIE30X2 CLKREQn_M1/WAKEn_M1/PERSTn_M1 function, DT also > specify a reset-gpios prop pointing on PERSTn_M1. To me this seem like a > correct description of HW. Actually I'm starting to think that it isn't. If you look at table 11-11 in Part 2 of the RK3588 TRM (V1.0) you'll see that the pcie_perst_n signal is designated as input. The corrsponding chapter is missing from the copy of the RK3568 TRM I have, but it is likely that the same applies to the PCIe conroller on the RK3568 SoC. Now these PCIe controllers can function in either Root Complex (RC) or Endpoint (EP) mode. And given the the pcie_perst_n signal is designated as input I think that means that the PERSTn_M1 function only makes sense when the controller is in EP mode. So for the majority of the boards that use the PCIe controller in RC mode, the DT should only configure the CLKREQn_M1 and WAKEn_M1 functions and configure the pin that is used to output PERST# as a GPIO. > When U-Boot probe the PCIE30X2 device the pinctrl driver would > automatically configure CLKREQn_M1/WAKEn_M1/PERSTn_M1 function. > > When U-Boot RK PCIe driver try to use the reset-gpios pin the device > would freeze unless the PERSTn pin is first re-configured for gpio use. > > Current workaround in U-Boot throws away the existing upstream pinctrl > and replace it to only configure gpio func on the PERSTn pin. This also > leaves the CLKREQn and WAKEn to incorrectly use gpio func. > > With this series I try to cleanup the old workaround that I added without > much insight beyond: device no longer freeze and nvme "works" :-) > > > > > I've wondered in the past what the purpose of the gpio-ranges > > properties was. I never considered that they could be used to > > automatically mux the pins for GPIO since the gpio-ranges mapping > > provides no indication of what the correct pin settings arefor the > > GPIO pins. > > The gpio-ranges prop is only used to provide details on how the pins are > mapped between gpio and pin controller. It is not used to change any > muxing. But the property is required to make the U-Boot helpers > pinctrl_gpio_request()/pinctrl_gpio_free
Re: [PATCH 0/4] rockchip: Add gpio request() ops and drop PCIe reset-gpios workaround
> Date: Sat, 11 May 2024 20:47:40 +0200 > From: Jonas Karlman Hi Jonas & Alex, > Hi Alex, > > On 2024-05-11 19:44, Alex Bee wrote: > > Hi Jonas, > > > > Am 11.05.24 um 13:28 schrieb Jonas Karlman: > >> This series add gpio request() and pinctrl gpio_request_enable() ops so > >> that a gpio requested pin automatically use gpio pinmux and U-Boot > >> behaves more similar to Linux kernel. > > > > I'm not sure that's a good idea. > > While linux does it the same way, we really shouldn't expect every > > software/os/ … which uses DT (now or in future) to implicitly switch the > > pin function when using a pin as gpio. So the real fix would probably be > > to add the the correct pinctrl settings to the upstream DT of those > > boards and sync it later on (not sure those if those SoCs already using > > OF_UPSTREAM) and leave the -u-boot.dtsi-"hack" alone for now. I missed Alex's mail, but OpenBSD certainly is one of the OSes that could break if the pinctrl settings get removed. We currently have no code to automatically mux the gpio pins on these Rockchip SoCs. I suppose as long as U-Boot probes the PCIe bus, the pins will already be muxed correctly and things will continue to work. But I think there are certain boot scenarios where this won't happen. I've wondered in the past what the purpose of the gpio-ranges properties was. I never considered that they could be used to automatically mux the pins for GPIO since the gpio-ranges mapping provides no indication of what the correct pin settings arefor the GPIO pins. > > I fully agree that the pinctrl for the problematic boards should be > corrected in upstream DT, but that is a separate issue and should not > block adding support for the request()/gpio_request_enable() ops. > > While the pcie reset-gpios full board freeze that was my driving factor > to fully implement the gpio request() ops it is not the only use case, > using the gpio cmd on a pin that use a non-gpio pinmux is another. > > Or do you see any technical issue with having the gpio request() ops > implemented and having it ensure gpio pinmux is used on a gpio requested > pin? Similar to how gpio/pinctrl is behaving in Linux and on some other > platforms in U-Boot? Well, it removes the incentive to fix the upstream DTs and would make it harder to notice missing pinctrls in the DTs. Cheers, Mark > > Alex > >> > >> With the gpio and pinctrl ops implemented this series also remove a PCIe > >> reset-gpios related device lock-up workaround from board u-boot.dtsi. > >> > >> PX30, RK3066, RK3188, RK356x and RK3588 are the only SoCs that currently > >> define gpio-ranges props and is affected by this series. > >> > >> A follow up series adding support for the pinmux status cmd will also > >> add gpio-ranges props for remaining RK SoCs. > >> > >> Jonas Karlman (4): > >>pinctrl: rockchip: Add gpio_request_enable() ops > >>gpio: rockchip: Add request() ops > >>rockchip: rk3568-rock-3a: Drop PCIe reset-gpios workaround > >>rockchip: rk3568-radxa-e25: Drop PCIe reset-gpios workaround > >> > >> arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 12 --- > >> arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 12 --- > >> drivers/gpio/rk_gpio.c| 10 ++ > >> .../pinctrl/rockchip/pinctrl-rockchip-core.c | 31 +++ > >> 4 files changed, 41 insertions(+), 24 deletions(-) > >> > > > >
Re: Distro Boot instructions with examples
> From: Igor Opaniuk > Date: Tue, 7 May 2024 16:30:17 +0200 > > Hello Antoni, > > On Tue, May 7, 2024 at 4:14 PM Antoni Jankowski > wrote: > > > > Hi, > > > > I've recently learned about the Distro Boot feature of u-boot. This sounds > > interesting, however the official instructions are sparse and examples seem > > to be non-existent. > > > > The platform I'm working with at the moment is a raspberry pi CM4, are > > there any examples of how to implement this concept? Distro Boot seems to > > be suitable for updating all the rootfs at once, including what usually is > > a separate boot partition. > > > > Best regards, > > Antoni > > There is a nice manual from Toradex about Distro Boot integration [1]. > You can also find a bunch of examples of integration of existing boards > just by grep-ing: > > u-boot.git$ grep -ine "config_distro_bootcmd" -r ./include/configs/ > ./include/configs/pico-imx6ul.h:86:#include > ./include/configs/kp_imx6q_tpc.h:84:#include > ./include/configs/imx8mp_venice.h:21:#include > ./include/configs/stm32f746-disco.h:30:#include > ... > > Hope this helps. > > [1] https://developer.toradex.com/linux-bsp/os-development/boot/distro-boot/ However, "distro boot" is being superseded by "standard boot" in recent versions of U-Boot and the raspberry pi boards have already moved on. See doc/develop/bootstd.rst for some documentation on "standard boot".
Re: [PATCH v2 5/5] arm: apple: Do not list bootflows on boot
> From: Janne Grunau via B4 Relay > Date: Thu, 18 Apr 2024 21:00:29 +0200 > > From: Janne Grunau > > The bootflow list is only seen briefly and is probably more confusing > than helpful. To be honest, I think that applies to all boards using BOOTSSTD_FILL. Which probably means the -l should be dropped from the default BOOTCOMMAND for BOOTSTD_FULL. But until that happens: Reviewed-by: Mark Kettenis > > Signed-off-by: Janne Grunau > --- > configs/apple_m1_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/apple_m1_defconfig b/configs/apple_m1_defconfig > index c30aec7c55..4eac1a9e2d 100644 > --- a/configs/apple_m1_defconfig > +++ b/configs/apple_m1_defconfig > @@ -8,6 +8,7 @@ CONFIG_SYS_CBSIZE=256 > CONFIG_SYS_PBSIZE=276 > # CONFIG_DISPLAY_CPUINFO is not set > CONFIG_DISPLAY_BOARDINFO_LATE=y > +CONFIG_BOOTCOMMAND="bootflow scan -b" > CONFIG_BOARD_LATE_INIT=y > CONFIG_CMD_SELECT_FONT=y > # CONFIG_NET is not set > > -- > 2.44.0 > > > >
Re: [PATCH v2 4/5] arm: apple: Switch to standard boot
> From: Janne Grunau via B4 Relay > Date: Thu, 18 Apr 2024 21:00:28 +0200 > > From: Janne Grunau > > Use standard boot instead of the distro boot scripts. Use > BOOTSTD_FULL instead of BOOTSTD_DEFAULTS for easier interactive use. > > Signed-off-by: Janne Grunau Reviewed-by: Mark Kettenis > --- > arch/arm/Kconfig| 2 +- > include/configs/apple.h | 20 ++-- > 2 files changed, 3 insertions(+), 19 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 01d6556c42..9b83b2e6f8 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1034,7 +1034,7 @@ config ARCH_APPLE > select USB > imply CMD_DM > imply CMD_GPT > - imply DISTRO_DEFAULTS > + imply BOOTSTD_FULL > imply OF_HAS_PRIOR_STAGE > > config ARCH_OWL > diff --git a/include/configs/apple.h b/include/configs/apple.h > index a70440b3ad..1e08b11448 100644 > --- a/include/configs/apple.h > +++ b/include/configs/apple.h > @@ -9,26 +9,10 @@ > "stdout=vidconsole,serial\0" \ > "stderr=vidconsole,serial\0" > > -#if IS_ENABLED(CONFIG_CMD_NVME) > - #define BOOT_TARGET_NVME(func) func(NVME, nvme, 0) > -#else > - #define BOOT_TARGET_NVME(func) > -#endif > - > -#if IS_ENABLED(CONFIG_CMD_USB) > - #define BOOT_TARGET_USB(func) func(USB, usb, 0) > -#else > - #define BOOT_TARGET_USB(func) > -#endif > - > -#define BOOT_TARGET_DEVICES(func) \ > - BOOT_TARGET_NVME(func) \ > - BOOT_TARGET_USB(func) > - > -#include > +#define BOOT_TARGETS "nvme usb" > > #define CFG_EXTRA_ENV_SETTINGS \ > ENV_DEVICE_SETTINGS \ > - BOOTENV > + "boot_targets=" BOOT_TARGETS "\0" > > #endif > > -- > 2.44.0 > > > >
Re: [PATCH v3 3/4] efi_loader: add an EFI variable with the file contents
> From: Ilias Apalodimas > Date: Thu, 18 Apr 2024 15:54:52 +0300 Hi Illias, > > Previous patches enabled SetVariableRT using a RAM backend. > Although EBBR [0] defines a variable format we can teach userspace tools > and write the altered variables, it's better if we skip the ABI > requirements completely. > > So let's add a new variable, in its own namespace called "VarToFile" > which contains a binary dump of the updated RT, BS and, NV variables > and will be updated when GetVariable is called. > > Some adjustments are needed to do that. > Currently we discard BS-only variables in EBS(). We need to preserve > those on the RAM backend that exposes the variables. Since BS-only > variables can't appear at runtime we need to move the memory masking > checks from efi_var_collect() to efi_get_next_variable_name_mem()/ > efi_get_variable_mem() and do the filtering at runtime. > > We also need an efi_var_collect() variant available at runtime, in order > to construct the "VarToFile" buffer on the fly. > > All users and applications (for linux) have to do when updating a variable > is dd that variable in the file described by "RTStorageVolatile". I simehow missed your reply to the issue I raised with picking the right ESP to write variables back to. I'm not convinced that the ESP that was used to install Linux on is necessarily th right one. In particular, consider a system with multiple disks, say eMMC and an NVMe disk. Suppose U-Boot is installed on eMMC and picks the ESP on that disk to store the EFI variables. Now I install Linux on the NVMe disk, which creates an ESP to store its bootloader. With your proposed changes, Linux will probably end up writing the variables to the ESP on the NVMe. Now you reboot and U-Boot still reads the EFI variables from eMMC and you've lost any changes... > Linux efivarfs uses a first 4 bytes of the output to represent attributes > in little-endian format. So, storing variables works like this: > > $~ efibootmgr -n 0001 > $~ dd > if=/sys/firmware/efi/efivars/VarToFile-b2ac5fc9-92b7-4acd-aeac-11e818c3130c > of=/boot/efi/ubootefi.var skip=4 bs=1 > > [0] > https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage > > Suggested-by: Ard Biesheuvel # dumping all variables to a > variable > Co-developed-by: Heinrich Schuchardt # > contributed on efi_var_collect_mem() > Signed-off-by: Heinrich Schuchardt > Signed-off-by: Ilias Apalodimas > --- > include/efi_variable.h| 16 +++- > lib/charset.c | 2 +- > lib/efi_loader/efi_runtime.c | 25 + > lib/efi_loader/efi_var_common.c | 6 +- > lib/efi_loader/efi_var_mem.c | 151 +++--- > lib/efi_loader/efi_variable.c | 6 +- > lib/efi_loader/efi_variable_tee.c | 5 - > 7 files changed, 146 insertions(+), 65 deletions(-) > > diff --git a/include/efi_variable.h b/include/efi_variable.h > index 42a2b7c52bef..223bb9a4a5bd 100644 > --- a/include/efi_variable.h > +++ b/include/efi_variable.h > @@ -271,13 +271,16 @@ const efi_guid_t *efi_auth_var_get_guid(const u16 > *name); > * > * @variable_name_size: size of variable_name buffer in bytes > * @variable_name: name of uefi variable's name in u16 > + * @mask:bitmask with required attributes of variables to be > collected. > + * variables are only collected if all of the required > + * attributes match. Use 0 to skip matching > * @vendor: vendor's guid > * > * Return: status code > */ > efi_status_t __efi_runtime > efi_get_next_variable_name_mem(efi_uintn_t *variable_name_size, u16 > *variable_name, > -efi_guid_t *vendor); > +efi_guid_t *vendor, u32 mask); > /** > * efi_get_variable_mem() - Runtime common code across efi variable > * implementations for GetVariable() from > @@ -289,12 +292,15 @@ efi_get_next_variable_name_mem(efi_uintn_t > *variable_name_size, u16 *variable_na > * @data_size: size of the buffer to which the variable value > is copied > * @data:buffer to which the variable value is copied > * @timep: authentication time (seconds since start of epoch) > + * @mask:bitmask with required attributes of variables to be > collected. > + * variables are only collected if all of the required > + * attributes match. Use 0 to skip matching > * Return: status code > */ > efi_status_t __efi_runtime > efi_get_variable_mem(const u16 *variable_name, const efi_guid_t *vendor, >u32 *attributes, efi_uintn_t *data_size, void *data, > - u64 *timep); > + u64 *timep, u32 mask); > > /** > * efi_get_variable_runtime() - runtime implementation of GetVariable() > @@ -334,4 +340,10 @@ efi_get_next_variable_name_runtime(efi_uintn_t >
Re: [PATCH 4/4] arm: apple: Switch to standard boot
> From: Janne Grunau via B4 Relay > Date: Sun, 17 Mar 2024 15:54:50 +0100 > > From: Janne Grunau > > Use standard boot instead of the distro boot scripts. > > Signed-off-by: Janne Grunau As per a somewhat recent discussion about this for the rockchip SoCs, I think we want BOOTSTD_FULL instead of BOOTSTD_DEFAULT. Even though I think that BOOTSTD_FULL is a bit too chatty at the moment. That also solves the issue that BOOTSTD_DEFAULTS doesn't run the EFI bootmgr (which does happen with distroboot). Although Heinrich has a diff to fix that. > --- > arch/arm/Kconfig| 2 +- > include/configs/apple.h | 20 ++-- > 2 files changed, 3 insertions(+), 19 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 01d6556c42..ad89abde41 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1034,7 +1034,7 @@ config ARCH_APPLE > select USB > imply CMD_DM > imply CMD_GPT > - imply DISTRO_DEFAULTS > + imply BOOTSTD_DEFAULTS > imply OF_HAS_PRIOR_STAGE > > config ARCH_OWL > diff --git a/include/configs/apple.h b/include/configs/apple.h > index a70440b3ad..1e08b11448 100644 > --- a/include/configs/apple.h > +++ b/include/configs/apple.h > @@ -9,26 +9,10 @@ > "stdout=vidconsole,serial\0" \ > "stderr=vidconsole,serial\0" > > -#if IS_ENABLED(CONFIG_CMD_NVME) > - #define BOOT_TARGET_NVME(func) func(NVME, nvme, 0) > -#else > - #define BOOT_TARGET_NVME(func) > -#endif > - > -#if IS_ENABLED(CONFIG_CMD_USB) > - #define BOOT_TARGET_USB(func) func(USB, usb, 0) > -#else > - #define BOOT_TARGET_USB(func) > -#endif > - > -#define BOOT_TARGET_DEVICES(func) \ > - BOOT_TARGET_NVME(func) \ > - BOOT_TARGET_USB(func) > - > -#include > +#define BOOT_TARGETS "nvme usb" > > #define CFG_EXTRA_ENV_SETTINGS \ > ENV_DEVICE_SETTINGS \ > - BOOTENV > + "boot_targets=" BOOT_TARGETS "\0" > > #endif > > -- > 2.44.0 > > >
Re: [PATCH 3/4] configs: apple: Enable CMD_SELECT_FONT and FONT_16X32
> From: Janne Grunau via B4 Relay > Date: Sun, 17 Mar 2024 15:54:49 +0100 > > From: Janne Grunau > > Apple devices have high DPI displays so the larger fonts are preferable > for improved readability. This does not yet change the used font based > on the display's pixel density so the standard 8x16 font is still used > by default. > > Signed-off-by: Janne Grunau Reviewed-by: Mark Kettenis > --- > configs/apple_m1_defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/configs/apple_m1_defconfig b/configs/apple_m1_defconfig > index 31d966f0ab..c30aec7c55 100644 > --- a/configs/apple_m1_defconfig > +++ b/configs/apple_m1_defconfig > @@ -9,6 +9,7 @@ CONFIG_SYS_PBSIZE=276 > # CONFIG_DISPLAY_CPUINFO is not set > CONFIG_DISPLAY_BOARDINFO_LATE=y > CONFIG_BOARD_LATE_INIT=y > +CONFIG_CMD_SELECT_FONT=y > # CONFIG_NET is not set > CONFIG_SYS_64BIT_LBA=y > CONFIG_APPLE_SPI_KEYB=y > @@ -19,6 +20,7 @@ CONFIG_USB_XHCI_DWC3=y > CONFIG_USB_XHCI_PCI=y > CONFIG_USB_DWC3=y > CONFIG_USB_KEYBOARD=y > +CONFIG_VIDEO_FONT_16X32=y > CONFIG_SYS_WHITE_ON_BLACK=y > CONFIG_NO_FB_CLEAR=y > CONFIG_VIDEO_SIMPLE=y > > -- > 2.44.0 > > >
Re: [PATCH 2/4] configs: apple: Use "vidconsole,serial" as stdout/stderr
> From: Janne Grunau via B4 Relay > Date: Sun, 17 Mar 2024 15:54:48 +0100 > > From: Janne Grunau > > The display size querying in efi_console relies on this order. The > display should be the primary output device and should be used to > display more than 80x25 chars. > > Signed-off-by: Janne Grunau Reviewed-by: Mark Kettenis > --- > include/configs/apple.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/configs/apple.h b/include/configs/apple.h > index 0576bc04c9..a70440b3ad 100644 > --- a/include/configs/apple.h > +++ b/include/configs/apple.h > @@ -6,8 +6,8 @@ > /* Environment */ > #define ENV_DEVICE_SETTINGS \ > "stdin=serial,usbkbd,spikbd\0" \ > - "stdout=serial,vidconsole\0" \ > - "stderr=serial,vidconsole\0" > + "stdout=vidconsole,serial\0" \ > + "stderr=vidconsole,serial\0" > > #if IS_ENABLED(CONFIG_CMD_NVME) > #define BOOT_TARGET_NVME(func) func(NVME, nvme, 0) > > -- > 2.44.0 > > >
Re: [PATCH 1/4] apple_m1_defconfig: Turn on CONFIG_SYS_64BIT_LBA
> From: Janne Grunau via B4 Relay > Date: Sun, 17 Mar 2024 15:54:47 +0100 > > From: Hector Martin > > This makes USB HDDs >2TiB work. The only reason this hasn't bitten us > for the internal NVMe yet is the 4K sector size, because the largest SSD > Apple sells is 8TB and we can handle up to 16TiB with that sector size. > Close call. > > Signed-off-by: Hector Martin > Signed-off-by: Janne Grunau Reviewed-by: Mark Kettenis > --- > configs/apple_m1_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/apple_m1_defconfig b/configs/apple_m1_defconfig > index e00d72e8be..31d966f0ab 100644 > --- a/configs/apple_m1_defconfig > +++ b/configs/apple_m1_defconfig > @@ -10,6 +10,7 @@ CONFIG_SYS_PBSIZE=276 > CONFIG_DISPLAY_BOARDINFO_LATE=y > CONFIG_BOARD_LATE_INIT=y > # CONFIG_NET is not set > +CONFIG_SYS_64BIT_LBA=y > CONFIG_APPLE_SPI_KEYB=y > # CONFIG_MMC is not set > CONFIG_NVME_APPLE=y > > -- > 2.44.0 > > >
Re: [PATCH] boot: Pass baud rate to stdout-path
> From: John Watts
> Date: Thu, 11 Apr 2024 15:03:20 +1000
>
> Linux might use the wrong baud rate such as 9600 by default, make sure
> to specify it when passing the serial port over.
>
> Signed-off-by: John Watts
> ---
> On my board at least (a sunxi T113) the serial console will initialize
> as 9600 baud instead of the set baud. Pass the baud with the serial
> device to Linux to solve this issue.
You probably should fix this by making sure the device tree you're
using has the appropriate stdout-path node. Because I think the
functionality you're trying to use here is deprecated:
* The linux,stdout-path property has been superseded by the
stdout-path property.
* The description of the OF_STDOUT_VIA_ALIAS option suggests that it
is seprecated as well:
This option currently references CONFIG_CONS_INDEX, which is
incorrect when used with device tree as this option does not
exist / should not be used.
It just happens that sunxi is one of the few remaining "modenr"
platforms that still uses CONFIG_CONS_INDEX.
That said, the diff is interesting. To me it doesn't really make
sense that you can change the serial port and its parameters in
U-Boot, but that this choice doesn't always make it into the device
tree that is passed to the OS.
A particular case that I'm dealing with is the default speed of
150 that the various Rockchip SoCs use. This doesn't work with
many of the USB-to-serial interfaces on the market and is also rather
susceptible to line noise. So for OpenBSD packages I've decide to use
115200 instead. But that means I have to patch all the device trees
in addition to changing the CONFIG_BAUDRATE setting. If U-Boot would
tweak the stdout-path property based on CONFIG_BAUDRATE that would
make things easier.
Cheers,
Mark
> ---
> boot/fdt_support.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/boot/fdt_support.c b/boot/fdt_support.c
> index 090d82ee80..83e62f47b5 100644
> --- a/boot/fdt_support.c
> +++ b/boot/fdt_support.c
> @@ -153,9 +153,9 @@ static int fdt_fixup_stdout(void *fdt, int chosenoff)
> }
>
> /* fdt_setprop may break "path" so we copy it to tmp buffer */
> - memcpy(tmp, path, len);
> + len = sprintf(tmp, "%.*s:%d", len, (char *)path, CONFIG_BAUDRATE);
>
> - err = fdt_setprop(fdt, chosenoff, "linux,stdout-path", tmp, len);
> + err = fdt_setprop(fdt, chosenoff, "linux,stdout-path", tmp, len + 1);
> if (err < 0)
> printf("WARNING: could not set linux,stdout-path %s.\n",
> fdt_strerror(err));
>
> ---
> base-commit: 777c28460947371ada40868dc994dfe8537d7115
> change-id: 20240411-stdout-4f91b566a0f2
>
> Best regards,
> --
> John Watts
>
>
Re: [PATCH 1/1] tools: use adequate entropy source for initialization vector
> From: Heinrich Schuchardt
> Date: Thu, 11 Apr 2024 01:31:16 +0200
>
> The random() function is unsafe to initialize cryptographic data.
> Use getrandom() which reads from /dev/urandom instead.
>
> getrandom() is available on Linux sine release 3.17 and on BSD.
NACK
getrandom() isn't evailable on OpenBSD. Either use getentropy() or
arc4random_buf() instead.
> Addresses-Coverity-ID: 312953 Calling risky function
> Signed-off-by: Heinrich Schuchardt
> ---
> tools/image-host.c | 36 +++-
> 1 file changed, 3 insertions(+), 33 deletions(-)
>
> diff --git a/tools/image-host.c b/tools/image-host.c
> index b2a0f2e6d16..d30a235baf6 100644
> --- a/tools/image-host.c
> +++ b/tools/image-host.c
> @@ -13,11 +13,11 @@
> #include
> #include
> #include
> -
> #if CONFIG_IS_ENABLED(FIT_SIGNATURE)
> #include
> #include
> #endif
> +#include
>
> /**
> * fit_set_hash_value - set hash value in requested has node
> @@ -364,36 +364,6 @@ static int fit_image_read_key_iv_data(const char
> *keydir, const char *key_iv_nam
> return ret;
> }
>
> -static int get_random_data(void *data, int size)
> -{
> - unsigned char *tmp = data;
> - struct timespec date;
> - int i, ret;
> -
> - if (!tmp) {
> - fprintf(stderr, "%s: pointer data is NULL\n", __func__);
> - ret = -1;
> - goto out;
> - }
> -
> - ret = clock_gettime(CLOCK_MONOTONIC, );
> - if (ret) {
> - fprintf(stderr, "%s: clock_gettime has failed (%s)\n", __func__,
> - strerror(errno));
> - goto out;
> - }
> -
> - srandom(date.tv_nsec);
> -
> - for (i = 0; i < size; i++) {
> - *tmp = random() & 0xff;
> - tmp++;
> - }
> -
> - out:
> - return ret;
> -}
> -
> static int fit_image_setup_cipher(struct image_cipher_info *info,
> const char *keydir, void *fit,
> const char *image_name, int image_noffset,
> @@ -465,8 +435,8 @@ static int fit_image_setup_cipher(struct
> image_cipher_info *info,
> if (ret < 0)
> goto out;
> } else {
> - /* Generate an ramdom IV */
> - ret = get_random_data((void *)info->iv, info->cipher->iv_len);
> + /* Generate a ramdom initialization vector */
> + ret = getrandom((void *)info->iv, info->cipher->iv_len, 0);
> }
>
> out:
> --
> 2.43.0
>
>
Re: [PATCH v1 0/4] Enable SetvariableRT
> From: Ilias Apalodimas
> Date: Sat, 6 Apr 2024 17:01:51 +0300
>
> Hi all,
Hi Ilias,
> This is an updated version of [0].
>
> When EFI variables are stored on file we don't allow SetVariableRT,
> since the OS doesn't know how to access or write that file. At the same
> time keeping the U-Boot drivers alive in runtime sections and performing
> writes from the firmware is dangerous -- if at all possible.
>
> For GetVariableRT we copy runtime variables in RAM and expose them to
> the OS. Add a Kconfig option and provide SetVariableRT using the same
> memory back end. The OS will be responsible for syncing the RAM contents
> to the file, otherwise any changes made during runtime won't persist
> reboots.
>
> It's worth noting that the variable store format is defined in EBBR [1]
> and authenticated variables are explicitly prohibited, since they have
> to be stored on a medium that's tamper and rollback protected.
>
> The original RFC was just enabling the memory back end. This is a more
> complete version and we should be able, with small adjustments of
> userspace tools, fix SetVariableRT. If enabled the firmware will add two
> new RO EFI variables after ExitBootServices.
>
> RTStorageVolatile -- contains the filename, relative to the ESP
> VarToFile -- an EFI variable that holds all the BS,RT, NV variables and can
> be copied to the file defined by RTStorageVolatile.
How does the OS know what the right ESP is? The system might have
multiple disks that each have an ESP and more than one of those ESPs
might contain an ubootefi.var file. Maybe this should be a full
EFI device path that includes the partition?
Also, is RTStorageVolutile the right name for this? This is about
storing Non-Volatile variables after all...
>
> If any errors occur during the variable init, the firmware will delete them
> and adjust the RT_PROP table accordingly, disabling SetvarRT.
>
> - pre-patch
> $~ mount | grep efiva
> efivarfs on /sys/firmware/efi/efivars type efivarfs
> (ro,nosuid,nodev,noexec,relatime)
>
> $~ efibootmgr -n 0001
> Could not set BootNext: Read-only file system
>
> - post-patch
> $~ mount | grep efiva
> efivarfs on /sys/firmware/efi/efivars type efivarfs
> (rw,nosuid,nodev,noexec,relatime)
> , disabling SetvarRT.
> $~ efibootmgr -n 0001
> BootNext: 0001
> BootCurrent:
> BootOrder: ,0001
> Boot* debian
> HD(1,GPT,bdae5610-3331-4e4d-9466-acb5caf0b4a6,0x800,0x10)/File(EFI\debian\grubaa64.efi)
> Boot0001* virtio 0
> VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,85001f00)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,16008500){auto_created_boot_option}
>
> $~ efivar -p -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootNext
> GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
> Name: "BootNext"
> Attributes:
> Non-Volatile
> Boot Service Access
> Runtime Service Access
> Value:
> 01 00
>
> [0]
> https://lore.kernel.org/u-boot/20240329071929.2461441-1-ilias.apalodi...@linaro.org/
> [1]
> https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage
>
> Changes since the RFC:
> - Return EFI_INVALID_PARAM if attributes are not volatile
> - Add EFI_WRITE_PROTECTED checks for BS, RT *only* variables
> - Add 2 EFI variables and allow userspace to write the file
> - Add selftests
>
> Ilias Apalodimas (4):
> efi_loader: conditionally enable SetvariableRT
> efi_loader: Add OS notifications for SetVariableRT in RAM
> efi_loader: add an EFI variable with the variable file contents
> efi_selftest: add tests for setvariableRT
>
> include/efi_loader.h | 4 +
> include/efi_variable.h| 15 +-
> lib/efi_loader/Kconfig| 16 ++
> lib/efi_loader/efi_boottime.c | 2 +
> lib/efi_loader/efi_runtime.c | 1 +
> lib/efi_loader/efi_var_common.c | 43 ++--
> lib/efi_loader/efi_var_file.c | 1 -
> lib/efi_loader/efi_var_mem.c | 90 +++-
> lib/efi_loader/efi_variable.c | 210 +-
> lib/efi_loader/efi_variable_tee.c | 1 -
> .../efi_selftest_variables_runtime.c | 116 +-
> 11 files changed, 401 insertions(+), 98 deletions(-)
>
> --
> 2.37.2
>
>
Re: [PATCH v1 0/4] Enable SetvariableRT
> From: Ilias Apalodimas
>
> Hi all,
>
> This is an updated version of [0].
>
> When EFI variables are stored on file we don't allow SetVariableRT,
> since the OS doesn't know how to access or write that file. At the same
> time keeping the U-Boot drivers alive in runtime sections and performing
> writes from the firmware is dangerous -- if at all possible.
>
> For GetVariableRT we copy runtime variables in RAM and expose them to
> the OS. Add a Kconfig option and provide SetVariableRT using the same
> memory back end. The OS will be responsible for syncing the RAM contents
> to the file, otherwise any changes made during runtime won't persist
> reboots.
>
> It's worth noting that the variable store format is defined in EBBR [1]
> and authenticated variables are explicitly prohibited, since they have
> to be stored on a medium that's tamper and rollback protected.
>
> The original RFC was just enabling the memory back end. This is a more
> complete version and we should be able, with small adjustments of
> userspace tools, fix SetVariableRT. If enabled the firmware will add two
> new RO EFI variables after ExitBootServices.
>
> RTStorageVolatile -- contains the filename, relative to the ESP
> VarToFile -- an EFI variable that holds all the BS,RT, NV variables and can
> be copied to the file defined by RTStorageVolatile.
>
> If any errors occur during the variable init, the firmware will delete them
> and adjust the RT_PROP table accordingly, disabling SetvarRT.
>
> - pre-patch
> $~ mount | grep efiva
> efivarfs on /sys/firmware/efi/efivars type efivarfs
> (ro,nosuid,nodev,noexec,relatime)
>
> $~ efibootmgr -n 0001
> Could not set BootNext: Read-only file system
>
> - post-patch
> $~ mount | grep efiva
> efivarfs on /sys/firmware/efi/efivars type efivarfs
> (rw,nosuid,nodev,noexec,relatime)
> , disabling SetvarRT.
> $~ efibootmgr -n 0001
> BootNext: 0001
> BootCurrent:
> BootOrder: ,0001
> Boot* debian
> HD(1,GPT,bdae5610-3331-4e4d-9466-acb5caf0b4a6,0x800,0x10)/File(EFI\debian\grubaa64.efi)
> Boot0001* virtio 0
> VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,85001f00)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,16008500){auto_created_boot_option}
>
> $~ efivar -p -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootNext
> GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
> Name: "BootNext"
> Attributes:
> Non-Volatile
> Boot Service Access
> Runtime Service Access
> Value:
> 01 00
>
> [0]
> https://lore.kernel.org/u-boot/20240329071929.2461441-1-ilias.apalodi...@linaro.org/
> [1]
> https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage
>
> Changes since the RFC:
> - Return EFI_INVALID_PARAM if attributes are not volatile
> - Add EFI_WRITE_PROTECTED checks for BS, RT *only* variables
> - Add 2 EFI variables and allow userspace to write the file
> - Add selftests
>
> Ilias Apalodimas (4):
> efi_loader: conditionally enable SetvariableRT
> efi_loader: Add OS notifications for SetVariableRT in RAM
> efi_loader: add an EFI variable with the variable file contents
> efi_selftest: add tests for setvariableRT
>
> include/efi_loader.h | 4 +
> include/efi_variable.h| 15 +-
> lib/efi_loader/Kconfig| 16 ++
> lib/efi_loader/efi_boottime.c | 2 +
> lib/efi_loader/efi_runtime.c | 1 +
> lib/efi_loader/efi_var_common.c | 43 ++--
> lib/efi_loader/efi_var_file.c | 1 -
> lib/efi_loader/efi_var_mem.c | 90 +++-
> lib/efi_loader/efi_variable.c | 210 +-
> lib/efi_loader/efi_variable_tee.c | 1 -
> .../efi_selftest_variables_runtime.c | 116 +-
> 11 files changed, 401 insertions(+), 98 deletions(-)
I can't get patch 0003 from this series to apply on master or next.
Re: [PATCH v2 1/4] boot: correct the default sequence of boot methods
> From: Heinrich Schuchardt
> Date: Thu, 4 Apr 2024 13:47:39 +0200
>
> The default sequence of boot methods is determined by alphabetical sorting
> during linkage.
>
> * efi_mgr must run before efi to be UEFI compliant
> * pxe should run as last resort
>
> Signed-off-by: Heinrich Schuchardt
This sound very much like you're working around a standard boot design
flaw.
Who does the alphabetical sorting here? Is that just a result of how
the toolchain behaves? If so, that sounds fragile to me and I think
it would be better to make the order explicit in the code.
Cheers,
Mark
> ---
> v2:
> no change
> ---
> boot/bootmeth_efi.c | 2 +-
> boot/bootmeth_efi_mgr.c | 2 +-
> boot/bootmeth_pxe.c | 2 +-
> test/boot/bootflow.c| 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c
> index c4eb331d69e..a46b6c9c805 100644
> --- a/boot/bootmeth_efi.c
> +++ b/boot/bootmeth_efi.c
> @@ -489,7 +489,7 @@ static const struct udevice_id distro_efi_bootmeth_ids[]
> = {
> { }
> };
>
> -U_BOOT_DRIVER(bootmeth_efi) = {
> +U_BOOT_DRIVER(bootmeth_4efi) = {
> .name = "bootmeth_efi",
> .id = UCLASS_BOOTMETH,
> .of_match = distro_efi_bootmeth_ids,
> diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c
> index ed29d7ef021..b7d429f2c3d 100644
> --- a/boot/bootmeth_efi_mgr.c
> +++ b/boot/bootmeth_efi_mgr.c
> @@ -114,7 +114,7 @@ static const struct udevice_id efi_mgr_bootmeth_ids[] = {
> { }
> };
>
> -U_BOOT_DRIVER(bootmeth_efi_mgr) = {
> +U_BOOT_DRIVER(bootmeth_3efi_mgr) = {
> .name = "bootmeth_efi_mgr",
> .id = UCLASS_BOOTMETH,
> .of_match = efi_mgr_bootmeth_ids,
> diff --git a/boot/bootmeth_pxe.c b/boot/bootmeth_pxe.c
> index 8d489a11aa4..70f693aa239 100644
> --- a/boot/bootmeth_pxe.c
> +++ b/boot/bootmeth_pxe.c
> @@ -184,7 +184,7 @@ static const struct udevice_id
> extlinux_bootmeth_pxe_ids[] = {
> { }
> };
>
> -U_BOOT_DRIVER(bootmeth_pxe) = {
> +U_BOOT_DRIVER(bootmeth_zpxe) = {
> .name = "bootmeth_pxe",
> .id = UCLASS_BOOTMETH,
> .of_match = extlinux_bootmeth_pxe_ids,
> diff --git a/test/boot/bootflow.c b/test/boot/bootflow.c
> index 4845b7121c8..e60e9309fa9 100644
> --- a/test/boot/bootflow.c
> +++ b/test/boot/bootflow.c
> @@ -377,7 +377,7 @@ static int bootflow_system(struct unit_test_state *uts)
> if (!IS_ENABLED(CONFIG_EFI_BOOTMGR))
> return -EAGAIN;
> ut_assertok(uclass_first_device_err(UCLASS_BOOTSTD, ));
> - ut_assertok(device_bind(bootstd, DM_DRIVER_GET(bootmeth_efi_mgr),
> + ut_assertok(device_bind(bootstd, DM_DRIVER_GET(bootmeth_3efi_mgr),
> "efi_mgr", 0, ofnode_null(), ));
> ut_assertok(device_probe(dev));
> sandbox_set_fake_efi_mgr_dev(dev, true);
> --
> 2.43.0
>
>
Re: [RFC PATCH] efi_loader: conditionally enable SetvariableRT
> From: Ilias Apalodimas
> Date: Fri, 29 Mar 2024 09:19:27 +0200
>
> When EFI variables are stored on file we don't allow SetVariableRT,
> since the OS doesn't know how to access or write that file. At the same
> time keeping the U-Boot drivers alive in runtime sections and performing
> writes from the firmware is dangerous -- if at all possible.
>
> For GetVariableRT we copy runtime variables in RAM and expose them to
> the OS. Add a Kconfig option and provide SetVariableRT using the same
> memory backend. The OS will be responsible for syncing the RAM contents
> to the file, otherwise any changes made during runtime won't persist
> reboots.
>
> It's worth noting that the variable store format is defined in EBBR [0]
> and authenticated variables are explicitly prohibited, since they have
> to be stored on a medium that's tamper and rollback protected.
>
> - pre-patch
> $~ mount | grep efiva
> efivarfs on /sys/firmware/efi/efivars type efivarfs
> (ro,nosuid,nodev,noexec,relatime)
>
> $~ efibootmgr -n 0001
> Could not set BootNext: Read-only file system
>
> - post-patch
> $~ mount | grep efiva
> efivarfs on /sys/firmware/efi/efivars type efivarfs
> (rw,nosuid,nodev,noexec,relatime)
>
> $~ efibootmgr -n 0001
> BootNext: 0001
> BootCurrent:
> BootOrder: ,0001
> Boot* debian
> HD(1,GPT,bdae5610-3331-4e4d-9466-acb5caf0b4a6,0x800,0x10)/File(EFI\debian\grubaa64.efi)
> Boot0001* virtio 0
> VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,85001f00)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,16008500){auto_created_boot_option}
>
> $~ efivar -p -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootNext
> GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
> Name: "BootNext"
> Attributes:
> Non-Volatile
> Boot Service Access
> Runtime Service Access
> Value:
> 01 00
>
> [0]
> https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage
>
> Open questions:
> Looking at the EFI spec, I can't find a documented way of notifying the OS
> that the storage is volatile. I would like to send a hint to the OS about
> that and I was thinking of adding a configuration table with the filename,
> which U-Boot expects to be on the ESP. Alternatively we could add a device
> path which would be a bit harder to parse from the userspace application,
> but safer in case multiple ESPs are present.
Should there be a way for the OS to opt-in to this new behaviour?
> Since I am not too familiar with how BSDs treat and expose config tables,
> we could instead add a RO efi variable with identical semantics, which
> would be easier to read from userspace.
There is an EFIIOC_GET_TABLE ioctl that allows retreiving a table by GUID.
> Signed-off-by: Ilias Apalodimas
> ---
> lib/efi_loader/Kconfig| 14 +++
> lib/efi_loader/efi_runtime.c | 4 +
> lib/efi_loader/efi_variable.c | 108 --
> .../efi_selftest_variables_runtime.c | 13 ++-
> 4 files changed, 126 insertions(+), 13 deletions(-)
>
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index a7c3e05c13a0..c7f7383189e5 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -63,6 +63,20 @@ config EFI_VARIABLE_FILE_STORE
> Select this option if you want non-volatile UEFI variables to be
> stored as file /ubootefi.var on the EFI system partition.
>
> +config EFI_RT_VOLATILE_STORE
> + bool "Allow variable runtime services in volatile storage (e.g RAM)"
> + depends on EFI_VARIABLE_FILE_STORE
> + help
> + When EFI variables are stored on file we don't allow SetVariableRT,
> + since the OS doesn't know how to write that file. At he same time
> + we copy runtime variables in DRAM and support GetVariableRT
> +
> + Enable this option to allow SetVariableRT on the RAM backend of
> + the EFI variable storate. The OS will be responsible for syncing
> + the RAM contents to the file, otherwise any changes made during
> + runtime won't persist reboots.
> + Authenticated variables are not supported.
> +
> config EFI_MM_COMM_TEE
> bool "UEFI variables storage service via the trusted world"
> depends on OPTEE
> diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
> index 18da6892e796..b38ce239e2d2 100644
> --- a/lib/efi_loader/efi_runtime.c
> +++ b/lib/efi_loader/efi_runtime.c
> @@ -126,6 +126,10 @@ efi_status_t efi_init_runtime_supported(void)
> EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP |
> EFI_RT_SUPPORTED_CONVERT_POINTER;
>
> + if (IS_ENABLED(CONFIG_EFI_RT_VOLATILE_STORE))
> + rt_table->runtime_services_supported |=
> + EFI_RT_SUPPORTED_SET_VARIABLE;
> +
> /*
>* This value must be synced with efi_runtime_detach_list
>
Re: [PATCH v4] disk: dos: Add all options for EFI System Partitions
> From: Peter Robinson
> Date: Sat, 2 Mar 2024 11:20:31 +
>
> The EFI spec states that the ESP can be any of FAT12/16/32 but for
> compatibility doesn't necssarily require the partition to be the
> EFI partition table ID of 0xef. A number of arm devices will not
> find their firmware on a FAT partition with an ID of 0xef so also
> allow the original FAT12/16/32 partition IDs as they are also
> permissable for an ESP.
>
> Signed-off-by: Peter Robinson
Reviewed-by: Mark Kettenis
> ---
>
> v2:
> - Add 0x0c option
> - Make hex constants consistent
> - Move from if to switch statement
> v3:
> - Fix switch brain fart
> v4:
> - Drop boot_ind out of switch
>
> disk/part_dos.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/disk/part_dos.c b/disk/part_dos.c
> index 567ead7511d..a35181dff4f 100644
> --- a/disk/part_dos.c
> +++ b/disk/part_dos.c
> @@ -40,10 +40,21 @@ static int get_bootable(dos_partition_t *p)
> {
> int ret = 0;
>
> - if (p->sys_ind == 0xef)
> + switch (p->sys_ind) {
> + case 0x01:
> + case 0x06:
> + case 0x0b:
> + case 0x0c:
> + case 0xef:
> ret |= PART_EFI_SYSTEM_PARTITION;
> + break;
> + default:
> + break;
> + }
> +
> if (p->boot_ind == 0x80)
> ret |= PART_BOOTABLE;
> +
> return ret;
> }
>
> --
> 2.44.0
>
>
Re: [PATCH v3] disk: dos: Add all options for EFI System Partitions
> From: Peter Robinson
> Date: Sat, 2 Mar 2024 10:54:36 +
Hi Peter,
> The EFI spec states that the ESP can be any of FAT12/16/32 but for
> compatibility doesn't necssarily require the partition to be the
> EFI partition table ID of 0xef. A number of arm devices will not
> find their firmware on a FAT partition with an ID of 0xef so also
> allow the original FAT12/16/32 partition IDs as they are also
> permissable for an ESP.
>
> Signed-off-by: Peter Robinson
> ---
>
> v2:
> - Add 0x0c option
> - Make hex constants consistent
> - Move from if to switch statement
> v3:
> - Fix switch brain fart
Sorry, still not quite right...
> disk/part_dos.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/disk/part_dos.c b/disk/part_dos.c
> index 567ead7511d..97f4ce32bed 100644
> --- a/disk/part_dos.c
> +++ b/disk/part_dos.c
> @@ -40,10 +40,21 @@ static int get_bootable(dos_partition_t *p)
> {
> int ret = 0;
>
> - if (p->sys_ind == 0xef)
> + switch (p->sys_ind) {
> + case 0x01:
> + case 0x06:
> + case 0x0b:
> + case 0x0c:
> + case 0xef:
> ret |= PART_EFI_SYSTEM_PARTITION;
> - if (p->boot_ind == 0x80)
The boot flag is part of p->boot_ind but the switch is for p->sys_ind
(the partition type). You can't handle the boot flag in the same
switch! Probably best to keep the if-statement for that bit.
> + break;
> + case 0x80:
> ret |= PART_BOOTABLE;
> + break;
> + default:
> + break;
> + }
> +
> return ret;
> }
>
> --
> 2.44.0
>
>
Re: [PATCH 4/6] usb: kbd: Ignore Yubikeys
> Date: Sun, 25 Feb 2024 22:57:23 +0100
> From: Marek Vasut
>
> On 2/25/24 5:07 PM, Janne Grunau wrote:
> > Hej,
> >
> > On Wed, Feb 21, 2024, at 13:41, Marek Vasut wrote:
> >> On 2/21/24 08:25, Janne Grunau via B4 Relay wrote:
> >>> From: Hector Martin
> >>>
> >>> We currently only support one USB keyboard device, but some devices
> >>> emulate keyboards for other purposes. Most commonly, people run into
> >>> this with Yubikeys, so let's ignore those.
> >>>
> >>> Even if we end up supporting multiple keyboards in the future, it's
> >>> safer to ignore known non-keyboard devices.
> >>>
> >>> Signed-off-by: Hector Martin
> >>> ---
> >>>common/usb_kbd.c | 19 +++
> >>>1 file changed, 19 insertions(+)
> >>>
> >>> diff --git a/common/usb_kbd.c b/common/usb_kbd.c
> >>> index 4cbc9acb73..774d3555d9 100644
> >>> --- a/common/usb_kbd.c
> >>> +++ b/common/usb_kbd.c
> >>> @@ -120,6 +120,15 @@ struct usb_kbd_pdata {
> >>>
> >>>extern int __maybe_unused net_busy_flag;
> >>>
> >>> +/*
> >>> + * Since we only support one usbkbd device in the iomux,
> >>> + * ignore common keyboard-emulating devices that aren't
> >>> + * real keyboards.
> >>> + */
> >>> +const uint16_t vid_blocklist[] = {
> >>> + 0x1050, /* Yubico */
> >>> +};
> >>> +
> >>>/* The period of time between two calls of usb_kbd_testc(). */
> >>>static unsigned long kbd_testc_tms;
> >>>
> >>> @@ -465,6 +474,7 @@ static int usb_kbd_probe_dev(struct usb_device *dev,
> >>> unsigned int ifnum)
> >>> struct usb_endpoint_descriptor *ep;
> >>> struct usb_kbd_pdata *data;
> >>> int epNum;
> >>> + int i;
> >>>
> >>> if (dev->descriptor.bNumConfigurations != 1)
> >>> return 0;
> >>> @@ -480,6 +490,15 @@ static int usb_kbd_probe_dev(struct usb_device *dev,
> >>> unsigned int ifnum)
> >>> if (iface->desc.bInterfaceProtocol != USB_PROT_HID_KEYBOARD)
> >>> return 0;
> >>>
> >>> + for (i = 0; i < ARRAY_SIZE(vid_blocklist); i++) {
> >>> + if (dev->descriptor.idVendor == vid_blocklist[i]) {
> >>> + printf("Ignoring keyboard device 0x%x:0x%x\n",
> >>> +dev->descriptor.idVendor,
> >>> +dev->descriptor.idProduct);
> >>> + return 0;
> >>> + }
> >>> + }
> >>
> >> I vaguely recall a discussion about previous version of this, I think
> >> the suggestion was to make the list of ignored devices configurable via
> >> environment variable, so users can add to that list from U-Boot shell.
> >> Would it be possible to make it work this way ?
> >
> > oh, I completely forgot that this patch was already submitted. I briefly
> > looked through asahi tree for related patches and did not check whether
> > this was previously submitted.
> > I've added environment based blocking as separate patch with blocking
> > either complete vendor IDs or vendor, product ID combinations. A separate
> > patch to simplify authorship tracking and the implementation doesn't share
> > any code.
>
> It would be better to have only one patch which does not hard-code any
> USB IDs, and then add those blocked IDs via U-Boot default environment
> for this specific machine. We cannot predict what yubico will do in the
> future, whether they might make a device that shouldn't be blocked for
> example. If they do, the user should be able to unblock their device by
> running e.g. '=> setenv usb_blocklist' instead of updating their bootloader.
>
> I think a simple list of blocked VID:PID pairs, maybe with wildcards,
> would be nice, i.e. something like 'usb_blocklist=1234:5678,1050:*' to
> block device 0x1234:0x5678 and all devices with VID 0x1050 . That should
> be easy to parse with strtok()/strtol() or some such and the code should
> not be too complex.
I do like the idea of having a configurable list of usb devices to
ignore. The U-Boot USB stack is still not perfect and there are still
USB devices that will prevent us from booting when connected. The
list will provide a nice workaround for that issue.
But the yubikeys will cause the same problem on other boards as well.
So I think it makes sense to put those in a default list.
Re: [PATCH 2/6] usb: xhci: Set up endpoints for the first 2 interfaces
> Date: Sun, 25 Feb 2024 22:47:41 +0100 > From: Marek Vasut > > On 2/25/24 4:28 PM, Janne Grunau wrote: > > > > > > On Wed, Feb 21, 2024, at 13:39, Marek Vasut wrote: > >> On 2/21/24 08:25, Janne Grunau via B4 Relay wrote: > >>> From: Janne Grunau > >>> > >>> Apple USB keyboards carry the HID keyboard boot protocol on the second > >>> interface. Using the second interface in the USB keyboard driver does > >>> not work since the xhci has not allocated a transfer ring. > >> > >> So, what does this patch do ? That is not clear from the commit message. > > > > rewritten for v2: > > | usb: xhci: Set up endpoints for the first 2 interfaces > > | > > | The xhci driver currently only does the necessary initialization for > > | endpoints found in the first interface descriptor. Apple USB keyboards > > | (released 2021) use the second interface descriptor for the HID keyboard > > | boot protocol. To allow USB drivers to use endpoints from other > > | interface descriptors the xhci driver needs to ensure these endpoints > > | are initialized as well. > > | Use USB_MAX_ACTIVE_INTERFACES to control how many interface descriptors > > | are initialized and useable. Currently defined to 2 as that is enough to > > | make the Apple keyboard usable. > > Would it make sense to make this a tunable Kconfig option ? Maybe, but it should probably be enabled everywhere where CONFIG_USB_KEYBOARD as folks will connect their Apple keyboard to non-Apple hardware as well. And I think someone mentioned on the #asahi irc channel that there are othe keyboards that have the boot protocol on the second interface descriptor. Cheers, Mark
Re: [PATCH] efi_loader: Don't carve out memory reservations too early
> Date: Sat, 17 Feb 2024 12:02:56 +0100
> From: Heinrich Schuchardt
Hi Heinrich,
> On 2/16/24 3:17 PM, Mark Kettenis wrote:
> >> Date: Fri, 16 Feb 2024 00:38:25 +0100
> >> From: Heinrich Schuchardt
> >>
> >> Am 16. Februar 2024 00:25:34 MEZ schrieb Mark Kettenis
> >> :
> >>> Moving the efi_carve_out_dt_rsv() call in commit 1be415b21b2d
> >>> ("efi_loader: create memory reservations in ACPI case")
> >>> broke boards that create additional memory reservations in
> >>> ft_board_setup() since it is now called before those additional
> >>> memory reservations are made. This is the case for the rk3588
> >>> boards and breaks booting OpenBSD on those boards.
> >>>
> >>> Move the call back to its original location and add a call in
> >>> the code path used for ACPI.
> >>>
> >>> Fixes: 1be415b21b2d ("efi_loader: create memory reservations in ACPI
> >>> case")
> >>> Signed-off-by: Mark Kettenis
> >>> ---
> >>> lib/efi_loader/efi_helper.c | 11 +++
> >>> 1 file changed, 7 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/lib/efi_loader/efi_helper.c b/lib/efi_loader/efi_helper.c
> >>> index 5dd9cc876e..58761fae78 100644
> >>> --- a/lib/efi_loader/efi_helper.c
> >>> +++ b/lib/efi_loader/efi_helper.c
> >>> @@ -456,11 +456,11 @@ efi_status_t efi_install_fdt(void *fdt)
> >>> return EFI_LOAD_ERROR;
> >>> }
> >>>
> >>> - /* Create memory reservations as indicated by the device tree */
> >>> - efi_carve_out_dt_rsv(fdt);
> >>> -
> >>> - if (CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE))
> >>> + if (CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)) {
> >>> + /* Create memory reservations as indicated by the device tree */
> >>
> >> Imagine booting the rk3588 board with ACPI.
> >
> > I'd rather not, thank you ;)
> >
> >> Wouldn't we miss creating the ft_board_setup() reservations before
> >> efi_carve_out_dt_rsv(fdt)?
> >
> > Yes. And arguably the these memory reservations should be made way
> > earlier, at the the time that efi_memory_init() runs. I think we're
> > just lucky that efi_allocate_pages() doesn't hand us memory from these
> > areas in copy_fdt().
> >
> > Better ideas?
> >
>
> image_setup_libfdt(, fdt, NULL) must be called before
> efi_carve_out_dt_rsv().
>
> Could you, please, add this call in this path, too. Otherwise the patch
> looks correct.
Yes I can. Just sent out v2.
Thanks,
Mark
> >
> >>> + efi_carve_out_dt_rsv(fdt);
> >>> return EFI_SUCCESS;
> >>> + }
> >>>
> >>> /* Prepare device tree for payload */
> >>> ret = copy_fdt();
> >>> @@ -474,6 +474,9 @@ efi_status_t efi_install_fdt(void *fdt)
> >>> return EFI_LOAD_ERROR;
> >>> }
> >>>
> >>> + /* Create memory reservations as indicated by the device tree */
> >>> + efi_carve_out_dt_rsv(fdt);
> >>> +
> >>> efi_try_purge_kaslr_seed(fdt);
> >>>
> >>> if (CONFIG_IS_ENABLED(EFI_TCG2_PROTOCOL_MEASURE_DTB)) {
> >>
> >
>
>
[PATCH v2] efi_loader: Don't carve out memory reservations too early
Moving the efi_carve_out_dt_rsv() call in commit 1be415b21b2d
("efi_loader: create memory reservations in ACPI case")
broke boards that create additional memory reservations in
ft_board_setup() since it is now called before those additional
memory reservations are made. This is the case for the rk3588
boards and breaks booting OpenBSD on those boards.
Move the call back to its original location and add a call in
the code path used for ACPI after calling image_setup_libfdt()
such that memory reservations made by ft_board_setup() are
applied when booting with ACPI too.
Fixes: 1be415b21b2d ("efi_loader: create memory reservations in ACPI case")
Signed-off-by: Mark Kettenis
---
ChangeLog:
v2: - Call image_setup_libfdt() in the ACPI code path
lib/efi_loader/efi_helper.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/lib/efi_loader/efi_helper.c b/lib/efi_loader/efi_helper.c
index 5dd9cc876e..5f8d9a17fd 100644
--- a/lib/efi_loader/efi_helper.c
+++ b/lib/efi_loader/efi_helper.c
@@ -456,11 +456,16 @@ efi_status_t efi_install_fdt(void *fdt)
return EFI_LOAD_ERROR;
}
- /* Create memory reservations as indicated by the device tree */
- efi_carve_out_dt_rsv(fdt);
+ if (CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)) {
+ if (image_setup_libfdt(, fdt, NULL)) {
+ log_err("ERROR: failed to process device tree\n");
+ return EFI_LOAD_ERROR;
+ }
- if (CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE))
+ /* Create memory reservations as indicated by the device tree */
+ efi_carve_out_dt_rsv(fdt);
return EFI_SUCCESS;
+ }
/* Prepare device tree for payload */
ret = copy_fdt();
@@ -474,6 +479,9 @@ efi_status_t efi_install_fdt(void *fdt)
return EFI_LOAD_ERROR;
}
+ /* Create memory reservations as indicated by the device tree */
+ efi_carve_out_dt_rsv(fdt);
+
efi_try_purge_kaslr_seed(fdt);
if (CONFIG_IS_ENABLED(EFI_TCG2_PROTOCOL_MEASURE_DTB)) {
--
2.43.0
Re: [PATCH v2] disk: dos: Add all options for EFI System Partitions
> From: Peter Robinson
> Date: Sun, 25 Feb 2024 14:14:55 +
>
> The EFI spec states that the ESP can be any of FAT12/16/32 but for
> compatibility doesn't necssarily require the partition to be the
> EFI partition table ID of 0xef. A number of arm devices will not
> find their firmware on a FAT partition with an ID of 0xef so also
> allow the original FAT12/16/32 partition IDs as they are also
> permissable for an ESP.
>
> Signed-off-by: Peter Robinson
> ---
>
> v2:
> - Add 0x0c option
> - Make hex constants consistent
> - Move from if to switch statement
Erh...
> disk/part_dos.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/disk/part_dos.c b/disk/part_dos.c
> index 567ead7511d..ab855adf347 100644
> --- a/disk/part_dos.c
> +++ b/disk/part_dos.c
> @@ -40,10 +40,23 @@ static int get_bootable(dos_partition_t *p)
> {
> int ret = 0;
>
> - if (p->sys_ind == 0xef)
> + switch (p->sys_ind){
> + case 0x01:
> ret |= PART_EFI_SYSTEM_PARTITION;
> - if (p->boot_ind == 0x80)
> + case 0x06:
> + ret |= PART_EFI_SYSTEM_PARTITION;
> + case 0x0b:
> + ret |= PART_EFI_SYSTEM_PARTITION;
> + case 0x0c:
> + ret |= PART_EFI_SYSTEM_PARTITION;
> + case 0xef:
> + ret |= PART_EFI_SYSTEM_PARTITION;
> + case 0x80:
> ret |= PART_BOOTABLE;
> + default:
> + break;
> + }
> +
That really didn't go well. The 0x80 check was for a different struct
member and there are missing break statements. And I suppose the
suggestion to use a switch was to bunch up the EFI partition type
cases.
ENOCOFFEE?
> return ret;
> }
>
> --
> 2.43.2
>
>
Re: [PATCH] disk: dos: Add all options for EFI System Partitions
> From: Peter Robinson
> Date: Mon, 19 Feb 2024 09:12:15 +
>
> The EFI spec states that the ESP can be any of FAT12/16/32 but for
> compatibility doesn't necssarily require the partition to be the
> EFI partition table ID of 0xef. A number of arm devices will not
> find their firmware on a FAT partition with an ID of 0xef so also
> allow the original FAT12/16/32 partition IDs as they are also
> permissable for an ESP.
Hi Peter,
Any reason not to include 0x0c as well? That is what we use on
OpenBSD/armv7 and OpenBSD/arm64. And as far as I know all UEFI
implementations (on arm64 at least) boot from such a partition.
(And yes, we use that partition type because we want to have a
bootable image that works on the various Raspberry Pi models).
That said, what problem does this fix? And what happens if we have
both a 0xea and a 0x01/0x06/0x0b/0x0c partition? In that case U-Boot
should probably prefer the 0xea over the others as the ESP.
Oh, and while your're at it, the hex constants are a bit inconsistent
(0x1/0x6 vs. 0x0b).
Cheers,
Mark
> Signed-off-by: Peter Robinson
> ---
> disk/part_dos.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/disk/part_dos.c b/disk/part_dos.c
> index 567ead7511d..303eb1d13ee 100644
> --- a/disk/part_dos.c
> +++ b/disk/part_dos.c
> @@ -40,6 +40,12 @@ static int get_bootable(dos_partition_t *p)
> {
> int ret = 0;
>
> + if (p->sys_ind == 0x1)
> + ret |= PART_EFI_SYSTEM_PARTITION;
> + if (p->sys_ind == 0x6)
> + ret |= PART_EFI_SYSTEM_PARTITION;
> + if (p->sys_ind == 0x0b)
> + ret |= PART_EFI_SYSTEM_PARTITION;
> if (p->sys_ind == 0xef)
> ret |= PART_EFI_SYSTEM_PARTITION;
> if (p->boot_ind == 0x80)
> --
> 2.43.1
>
>
Re: [PATCH v4] rockchip: spl: Enable caches to speed up checksum validation
> From: Jonas Karlman
> Date: Sat, 17 Feb 2024 12:34:04 +
>
> FIT checksum validation is very slow in SPL due to D-cache not being
> enabled.
>
> Enable caches in SPL on ARM64 SoCs to speed up FIT checksum validation,
> from seconds to milliseconds.
>
> This change enables caches in SPL on all Rockchip ARM64 boards, the
> Kconfig options SPL_SYS_ICACHE_OFF and SPL_SYS_DCACHE_OFF can be used to
> disable caches for a specific board or SoC if needed.
>
> Signed-off-by: Jonas Karlman
> Reviewed-by: Kever Yang
> ---
> Changes in v4:
> - Include cpu_func.h to fix build on armv7
> - Remove common.h include
>
> Changes in v3:
> - Limit to ARM64 SoCs
> - Fix build with SPL_SYS_ICACHE_OFF or SPL_SYS_DCACHE_OFF enabled
> - Use cleanup_before_linux() in spl_board_prepare_for_boot() to disable
> caches before jumping from SPL to next stage
> - Collect r-b tag
>
> Changes in v2:
> - None
>
> This has been tested on multiple RK3328, RK3399, RK356x and RK3588
> boards without any issues, vendor U-Boot also enables caches in SPL for
> all SoCs.
>
> This only worked on RK3288 because the default enable_caches() that does
> not enable caches was being used. Trying to enable caches on my RK3288
> froze my boards in mmu_setup(). So v3 limits the enable_caches() call to
> only include ARM64 SoCs.
FYI, enabling caches on 32-bit ARM SoCs is generally problematic
because of the presence of non-architected caches. This poses a
problem for an OS since it can't easily do cache-management in early
boot code before SoC specific drivers attach.
So I agree that this is the right choice.
> Link to RFC: https://patchwork.ozlabs.org/patch/1802303/
> Link to v2: https://patchwork.ozlabs.org/patch/1889319/
> Link to v3: https://patchwork.ozlabs.org/patch/1891025/
> ---
> arch/arm/mach-rockchip/spl.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
> index 87280e2ba7cc..1586a093fc37 100644
> --- a/arch/arm/mach-rockchip/spl.c
> +++ b/arch/arm/mach-rockchip/spl.c
> @@ -3,7 +3,7 @@
> * (C) Copyright 2019 Rockchip Electronics Co., Ltd
> */
>
> -#include
> +#include
> #include
> #include
> #include
> @@ -136,6 +136,20 @@ void board_init_f(ulong dummy)
> }
> gd->ram_top = gd->ram_base + get_effective_memsize();
> gd->ram_top = board_get_usable_ram_top(gd->ram_size);
> +
> + if (IS_ENABLED(CONFIG_ARM64) && !CONFIG_IS_ENABLED(SYS_DCACHE_OFF)) {
> + gd->relocaddr = gd->ram_top;
> + arch_reserve_mmu();
> + enable_caches();
> + }
> #endif
> preloader_console_init();
> }
> +
> +void spl_board_prepare_for_boot(void)
> +{
> + if (!IS_ENABLED(CONFIG_ARM64) || CONFIG_IS_ENABLED(SYS_DCACHE_OFF))
> + return;
> +
> + cleanup_before_linux();
> +}
> --
> 2.43.0
>
>
Re: [PATCH] efi_loader: Don't carve out memory reservations too early
> Date: Fri, 16 Feb 2024 00:38:25 +0100
> From: Heinrich Schuchardt
>
> Am 16. Februar 2024 00:25:34 MEZ schrieb Mark Kettenis :
> >Moving the efi_carve_out_dt_rsv() call in commit 1be415b21b2d
> >("efi_loader: create memory reservations in ACPI case")
> >broke boards that create additional memory reservations in
> >ft_board_setup() since it is now called before those additional
> >memory reservations are made. This is the case for the rk3588
> >boards and breaks booting OpenBSD on those boards.
> >
> >Move the call back to its original location and add a call in
> >the code path used for ACPI.
> >
> >Fixes: 1be415b21b2d ("efi_loader: create memory reservations in ACPI case")
> >Signed-off-by: Mark Kettenis
> >---
> > lib/efi_loader/efi_helper.c | 11 +++
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> >diff --git a/lib/efi_loader/efi_helper.c b/lib/efi_loader/efi_helper.c
> >index 5dd9cc876e..58761fae78 100644
> >--- a/lib/efi_loader/efi_helper.c
> >+++ b/lib/efi_loader/efi_helper.c
> >@@ -456,11 +456,11 @@ efi_status_t efi_install_fdt(void *fdt)
> > return EFI_LOAD_ERROR;
> > }
> >
> >-/* Create memory reservations as indicated by the device tree */
> >-efi_carve_out_dt_rsv(fdt);
> >-
> >-if (CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE))
> >+if (CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)) {
> >+/* Create memory reservations as indicated by the device tree */
>
> Imagine booting the rk3588 board with ACPI.
I'd rather not, thank you ;)
> Wouldn't we miss creating the ft_board_setup() reservations before
> efi_carve_out_dt_rsv(fdt)?
Yes. And arguably the these memory reservations should be made way
earlier, at the the time that efi_memory_init() runs. I think we're
just lucky that efi_allocate_pages() doesn't hand us memory from these
areas in copy_fdt().
Better ideas?
> >+efi_carve_out_dt_rsv(fdt);
> > return EFI_SUCCESS;
> >+}
> >
> > /* Prepare device tree for payload */
> > ret = copy_fdt();
> >@@ -474,6 +474,9 @@ efi_status_t efi_install_fdt(void *fdt)
> > return EFI_LOAD_ERROR;
> > }
> >
> >+/* Create memory reservations as indicated by the device tree */
> >+efi_carve_out_dt_rsv(fdt);
> >+
> > efi_try_purge_kaslr_seed(fdt);
> >
> > if (CONFIG_IS_ENABLED(EFI_TCG2_PROTOCOL_MEASURE_DTB)) {
>
[PATCH] efi_loader: Don't carve out memory reservations too early
Moving the efi_carve_out_dt_rsv() call in commit 1be415b21b2d
("efi_loader: create memory reservations in ACPI case")
broke boards that create additional memory reservations in
ft_board_setup() since it is now called before those additional
memory reservations are made. This is the case for the rk3588
boards and breaks booting OpenBSD on those boards.
Move the call back to its original location and add a call in
the code path used for ACPI.
Fixes: 1be415b21b2d ("efi_loader: create memory reservations in ACPI case")
Signed-off-by: Mark Kettenis
---
lib/efi_loader/efi_helper.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/lib/efi_loader/efi_helper.c b/lib/efi_loader/efi_helper.c
index 5dd9cc876e..58761fae78 100644
--- a/lib/efi_loader/efi_helper.c
+++ b/lib/efi_loader/efi_helper.c
@@ -456,11 +456,11 @@ efi_status_t efi_install_fdt(void *fdt)
return EFI_LOAD_ERROR;
}
- /* Create memory reservations as indicated by the device tree */
- efi_carve_out_dt_rsv(fdt);
-
- if (CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE))
+ if (CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)) {
+ /* Create memory reservations as indicated by the device tree */
+ efi_carve_out_dt_rsv(fdt);
return EFI_SUCCESS;
+ }
/* Prepare device tree for payload */
ret = copy_fdt();
@@ -474,6 +474,9 @@ efi_status_t efi_install_fdt(void *fdt)
return EFI_LOAD_ERROR;
}
+ /* Create memory reservations as indicated by the device tree */
+ efi_carve_out_dt_rsv(fdt);
+
efi_try_purge_kaslr_seed(fdt);
if (CONFIG_IS_ENABLED(EFI_TCG2_PROTOCOL_MEASURE_DTB)) {
--
2.43.0
Re: [PATCH v2 09/20] rockchip: merge misc.c into board.c
> Date: Fri, 09 Feb 2024 18:58:01 +0100
> From: Dragan Simic
>
> Hello Quentin,
>
> Please, see my comments below.
>
> On 2024-02-09 10:50, Quentin Schulz wrote:
> > From: Quentin Schulz
> >
> > The functions aren't used anywhere else than in board.c, therefore,
> > let's not expose them anymore at all.
> >
> > This merges misc.c and board.c together and removes the functions from
> > the misc.h header file.
>
> The patches I'm going to send, which exclude the unneeded code
> from the U-Boot images for the Pinebook Pro and the Pinebook Pro,
> change the code that this patch moves around.
>
> Perhaps it would be better to have the move of the code and the
> subsequent changes to it performed in a separate series, to make
> checking and accepting the patches simpler as a group, and to
> perhaps make it a bit more clear what actually happened to anyone
> going through the repository history later.
>
> Thus, I was wondering would you, please, be fine with excluding
> this patch from this series and letting me submit it, with proper
> attribution tags, of course, as part of the series I'll submit
> in the next couple of days?
Hello Dragan,
I'm not covinced your patches are a good idea. Unless we're running
into space constraints, or if there are noticable slowdowns in the
boot process because of the extra code, I really don't see what the
benefit of further differentiation between rk3399 boards would be. It
just makes testing things harder.
The smaller the number of special snow flakes, the better!
> > Cc: Quentin Schulz
> > Reviewed-by: Kever Yang
> > Signed-off-by: Quentin Schulz
> > ---
> > arch/arm/include/asm/arch-rockchip/misc.h | 5 --
> > arch/arm/mach-rockchip/Makefile | 1 -
> > arch/arm/mach-rockchip/board.c| 125
> > +++
> > arch/arm/mach-rockchip/misc.c | 135
> > --
> > 4 files changed, 125 insertions(+), 141 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/arch-rockchip/misc.h
> > b/arch/arm/include/asm/arch-rockchip/misc.h
> > index 4155af8c3b0..ef37ff1661a 100644
> > --- a/arch/arm/include/asm/arch-rockchip/misc.h
> > +++ b/arch/arm/include/asm/arch-rockchip/misc.h
> > @@ -6,9 +6,4 @@
> > * Rohan Garg
> > */
> >
> > -int rockchip_cpuid_from_efuse(const u32 cpuid_offset,
> > - const u32 cpuid_length,
> > - u8 *cpuid);
> > -int rockchip_cpuid_set(const u8 *cpuid, const u32 cpuid_length);
> > -int rockchip_setup_macaddr(void);
> > void rockchip_capsule_update_board_setup(void);
> > diff --git a/arch/arm/mach-rockchip/Makefile
> > b/arch/arm/mach-rockchip/Makefile
> > index 1dc92066bbf..c07bdaee4c3 100644
> > --- a/arch/arm/mach-rockchip/Makefile
> > +++ b/arch/arm/mach-rockchip/Makefile
> > @@ -23,7 +23,6 @@ ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
> > # meaning "turn it off".
> > obj-y += boot_mode.o
> > obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> > -obj-$(CONFIG_MISC_INIT_R) += misc.o
> > endif
> >
> > ifeq ($(CONFIG_TPL_BUILD),)
> > diff --git a/arch/arm/mach-rockchip/board.c
> > b/arch/arm/mach-rockchip/board.c
> > index d5cb59c10fa..80b4514852f 100644
> > --- a/arch/arm/mach-rockchip/board.c
> > +++ b/arch/arm/mach-rockchip/board.c
> > @@ -1,20 +1,32 @@
> > // SPDX-License-Identifier: GPL-2.0+
> > /*
> > * (C) Copyright 2019 Rockchip Electronics Co., Ltd.
> > + *
> > + * Copyright (C) 2019 Collabora Inc - https://www.collabora.com/
> > + * Rohan Garg
> > + *
> > + * Based on puma-rk3399.c:
> > + * (C) Copyright 2017 Theobroma Systems Design und Consulting
> > GmbH
> > */
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > #include
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > #include
> > #include
> > #include
> > @@ -297,6 +309,119 @@ int fastboot_set_reboot_flag(enum
> > fastboot_reboot_reason reason)
> > #endif
> >
> > #ifdef CONFIG_MISC_INIT_R
> > +int rockchip_setup_macaddr(void)
> > +{
> > +#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256)
> > + int ret;
> > + const char *cpuid = env_get("cpuid#");
> > + u8 hash[SHA256_SUM_LEN];
> > + int size = sizeof(hash);
> > + u8 mac_addr[6];
> > +
> > + /* Only generate a MAC address, if none is set in the environment */
> > + if (env_get("ethaddr"))
> > + return 0;
> > +
> > + if (!cpuid) {
> > + debug("%s: could not retrieve 'cpuid#'\n", __func__);
> > + return -1;
> > + }
> > +
> > + ret = hash_block("sha256", (void *)cpuid, strlen(cpuid), hash,
> > );
> > + if (ret) {
> > + debug("%s: failed to calculate SHA256\n", __func__);
> > + return -1;
> > + }
> > +
> > + /* Copy 6 bytes of the hash to base the MAC address on */
> > + memcpy(mac_addr, hash, 6);
> > +
>
Re: [PATCH 0/2] smbios: fill wake-up type
> From: Heinrich Schuchardt > Date: Thu, 8 Feb 2024 11:49:50 +0100 > > We should not use the reserved value 0x00 for the wake up type but > use 0x06 (Power Switch). Well, if I look at my collection of boards, many don't even have a power switch. So I think the only sensible default value is 0x02 (Unknown). If there is a compelling use-case for providing a more accurate value, that should probably be done by the various PMIC drivers. > Correctly display wake-up type in smbios command. > > Display SMBIOS type 1 field family in smbios command. > > Heinrich Schuchardt (2): > cmd: smbios: type 1 wake-up time, family > smbios: fill wake-up type > > cmd/smbios.c | 25 +++-- > include/smbios.h | 2 ++ > lib/smbios.c | 1 + > 3 files changed, 26 insertions(+), 2 deletions(-) > > -- > 2.43.0 > >
Re: [PATCH v2] rng: Add Turris Mox rWTM RNG driver
> Date: Mon, 5 Feb 2024 15:54:12 +0100
> From: Marek Behún
>
> So you're using A3720 with OpenBSD? Can I ask which A3720 boards do you
> use?
Hi Marek,
I have a Turris Mox.
Some folks run OpenBSD on the ESPRESSObin and GL.iNet Brume as well
(those are A3700 of course).
Cheers,
Mark
> On Mon, 05 Feb 2024 14:46:24 +0100
> Mark Kettenis wrote:
>
> > > Date: Mon, 5 Feb 2024 12:40:14 +0100
> > > From: Marek Behún
> > >
> > > Hello Max,
> > >
> > > Out of curiousity, what is your use case for having these random
> > > numbers on this platform in U-Boot?
> >
> > It means that U-Boot will implement the EFI RNG protocol. The OpenBSD
> > bootloader will use that to fill an initial pool of random numbers for
> > the kernel. And the Linux kernel EFI stub uses it to do kernel
> > address space randomization.
> >
> > Cheers,
> >
> > Mark
> >
> > > Below are a few more things to change and then you I'll give my
> > > Reviewed-by tag.
> > >
> > > On Sun, 21 Jan 2024 21:17:16 +0100
> > > Max Resch wrote:
> > >
> > > > A RNG driver for Armada 3720 boards running the Turris Mox rWTM firmware
> > > > from CZ.NIC in the secure processor.
> > > >
> > > > Signed-off-by: Max Resch
> > > > ---
> > > >
> > > > Changes in v2:
> > > > - Removed ring buffer implementation
> > > >
> > > > drivers/rng/Kconfig | 8 +++
> > > > drivers/rng/Makefile | 1 +
> > > > drivers/rng/turris_rwtm_rng.c | 122 ++
> > > > 3 files changed, 131 insertions(+)
> > > > create mode 100644 drivers/rng/turris_rwtm_rng.c
> > > >
> > > > diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
> > > > index a89c899568..cd72852a47 100644
> > > > --- a/drivers/rng/Kconfig
> > > > +++ b/drivers/rng/Kconfig
> > > > @@ -105,4 +105,12 @@ config RNG_JH7110
> > > > help
> > > > Enable True Random Number Generator in StarFive JH7110 SoCs.
> > > >
> > > > +config RNG_TURRIS_RWTM
> > > > + bool "Turris Mox TRNG in Secure Processor"
> > > > + depends on DM_RNG && ARMADA_3700
> > > > + help
> > > > + Use TRNG in Turris Mox Secure Processor Firmware. Can be used
> > > > + on other Armada-3700 devices (like EspressoBin) if Secure
> > > > + Firmware from CZ.NIC is used.
> > > > +
> > > > endif
> > > > diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
> > > > index 7e64c4cdfc..ecae1a3da3 100644
> > > > --- a/drivers/rng/Makefile
> > > > +++ b/drivers/rng/Makefile
> > > > @@ -17,3 +17,4 @@ obj-$(CONFIG_RNG_SMCCC_TRNG) += smccc_trng.o
> > > > obj-$(CONFIG_RNG_ARM_RNDR) += arm_rndr.o
> > > > obj-$(CONFIG_TPM_RNG) += tpm_rng.o
> > > > obj-$(CONFIG_RNG_JH7110) += jh7110_rng.o
> > > > +obj-$(CONFIG_RNG_TURRIS_RWTM) += turris_rwtm_rng.o
> > > > diff --git a/drivers/rng/turris_rwtm_rng.c
> > > > b/drivers/rng/turris_rwtm_rng.c
> > > > new file mode 100644
> > > > index 00..143fe0b47f
> > > > --- /dev/null
> > > > +++ b/drivers/rng/turris_rwtm_rng.c
> > > > @@ -0,0 +1,122 @@
> > > > +// SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause
> > > > +/*
> > > > + * Copyright (c) 2024, Max Resch
> > > > + */
> > > > +
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +
> > > > +/* size of entropy buffer */
> > > > +#define RNG_BUFFER_SIZE128U
> > > > +
> > > > +struct turris_rwtm_rng_priv {
> > > > + phys_addr_t buffer;
> > > > +};
> > > > +
> > > > +static int turris_rwtm_rng_fill_entropy(phys_addr_t entropy, size_t
> > > > size)
> > > > +{
> > > > + u32 args[3] = { 1, (u32)entropy, size };
> > > > + int ret;
> > > > +
> > > > + /* flush data cache */
> > > > + flush_dcache_range(entropy, entropy + size);
> > > > +
> > > > + /*
> > >
Re: [PATCH v2] rng: Add Turris Mox rWTM RNG driver
> Date: Mon, 5 Feb 2024 12:40:14 +0100
> From: Marek Behún
>
> Hello Max,
>
> Out of curiousity, what is your use case for having these random
> numbers on this platform in U-Boot?
It means that U-Boot will implement the EFI RNG protocol. The OpenBSD
bootloader will use that to fill an initial pool of random numbers for
the kernel. And the Linux kernel EFI stub uses it to do kernel
address space randomization.
Cheers,
Mark
> Below are a few more things to change and then you I'll give my
> Reviewed-by tag.
>
> On Sun, 21 Jan 2024 21:17:16 +0100
> Max Resch wrote:
>
> > A RNG driver for Armada 3720 boards running the Turris Mox rWTM firmware
> > from CZ.NIC in the secure processor.
> >
> > Signed-off-by: Max Resch
> > ---
> >
> > Changes in v2:
> > - Removed ring buffer implementation
> >
> > drivers/rng/Kconfig | 8 +++
> > drivers/rng/Makefile | 1 +
> > drivers/rng/turris_rwtm_rng.c | 122 ++
> > 3 files changed, 131 insertions(+)
> > create mode 100644 drivers/rng/turris_rwtm_rng.c
> >
> > diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
> > index a89c899568..cd72852a47 100644
> > --- a/drivers/rng/Kconfig
> > +++ b/drivers/rng/Kconfig
> > @@ -105,4 +105,12 @@ config RNG_JH7110
> > help
> > Enable True Random Number Generator in StarFive JH7110 SoCs.
> >
> > +config RNG_TURRIS_RWTM
> > + bool "Turris Mox TRNG in Secure Processor"
> > + depends on DM_RNG && ARMADA_3700
> > + help
> > + Use TRNG in Turris Mox Secure Processor Firmware. Can be used
> > + on other Armada-3700 devices (like EspressoBin) if Secure
> > + Firmware from CZ.NIC is used.
> > +
> > endif
> > diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
> > index 7e64c4cdfc..ecae1a3da3 100644
> > --- a/drivers/rng/Makefile
> > +++ b/drivers/rng/Makefile
> > @@ -17,3 +17,4 @@ obj-$(CONFIG_RNG_SMCCC_TRNG) += smccc_trng.o
> > obj-$(CONFIG_RNG_ARM_RNDR) += arm_rndr.o
> > obj-$(CONFIG_TPM_RNG) += tpm_rng.o
> > obj-$(CONFIG_RNG_JH7110) += jh7110_rng.o
> > +obj-$(CONFIG_RNG_TURRIS_RWTM) += turris_rwtm_rng.o
> > diff --git a/drivers/rng/turris_rwtm_rng.c b/drivers/rng/turris_rwtm_rng.c
> > new file mode 100644
> > index 00..143fe0b47f
> > --- /dev/null
> > +++ b/drivers/rng/turris_rwtm_rng.c
> > @@ -0,0 +1,122 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause
> > +/*
> > + * Copyright (c) 2024, Max Resch
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/* size of entropy buffer */
> > +#define RNG_BUFFER_SIZE128U
> > +
> > +struct turris_rwtm_rng_priv {
> > + phys_addr_t buffer;
> > +};
> > +
> > +static int turris_rwtm_rng_fill_entropy(phys_addr_t entropy, size_t size)
> > +{
> > + u32 args[3] = { 1, (u32)entropy, size };
> > + int ret;
> > +
> > + /* flush data cache */
> > + flush_dcache_range(entropy, entropy + size);
> > +
> > + /*
> > +* get entropy
> > +* args[0] = 1 copies BYTES array in args[1] of length args[2]
> > +*/
> > + ret = mbox_do_cmd(MBOX_CMD_GET_RANDOM, args, 3, NULL, 0);
> > + if (ret < 0)
> > + return ret;
> > +
> > + /* invalidate data cache */
> > + invalidate_dcache_range(entropy, entropy + size);
> > +
> > + return 0;
> > +}
> > +
> > +static int turris_rwtm_rng_random_read(struct udevice *dev, void *data,
> > size_t count)
> > +{
> > + phys_addr_t p;
> > + size_t size;
> > + int ret;
> > +
> > + p = ((struct turris_rwtm_rng_priv *)dev_get_priv(dev))->buffer;
>
> Please declare
>
> struct turris_rwtm_rng_priv *priv = dev_get_priv(dev);
> phys_addr_t phys;
> size_t size;
> int ret;
>
> and then do
>
> phys = priv->buffer;
>
> > + while (count) {
> > + size = min_t(size_t, RNG_BUFFER_SIZE, count);
> > +
> > + ret = turris_rwtm_rng_fill_entropy(p, size);
> > +
> > + memcpy(data, (void *)p, size);
> > + count -= size;
> > + data = (u8 *)data + size;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int turris_rwtm_rng_probe(struct udevice *dev)
> > +{
> > + struct turris_rwtm_rng_priv *priv;
>
> = dev_get_priv(dev);
>
> > + u32 args[] = { 0 };
> > + int ret;
> > +
> > + /*
> > +* check if the random command is supported
> > +* args[0] = 0 would copy 16 DWORDS entropy to out but we ignore them
> > +*/
> > + ret = mbox_do_cmd(MBOX_CMD_GET_RANDOM, args, ARRAY_SIZE(args), NULL, 0);
> > +
> > + if (ret < 0)
> > + return ret;
> > +
> > + /* entropy buffer */
> > + priv = (struct turris_rwtm_rng_priv *)dev_get_priv(dev);
> no need here, do it at the beginning
>
>
> > + priv->buffer = 0;
> > +
> > + /* buffer address need to be aligned */
> > + dma_alloc_coherent(RNG_BUFFER_SIZE, (unsigned long *)>buffer);
> > + if (!priv->buffer)
> > + return -ENOMEM;
> > +
> > + return 0;
> > +}
> > +
> > +static int turris_rwtm_rng_remove(struct
Re: [PATCH v4 0/6] rpi5: initial support
> Date: Mon, 22 Jan 2024 16:16:34 +0200 > From: "Ivan T. Ivanov" > > Hi, > > On 01-22 13:57, Ivan T. Ivanov wrote: > > > Am 20.01.24 um 10:48 schrieb Jens Maus: > > >> Hi, > > >> > > >>> Am 20.01.2024 um 10:22 schrieb Stefan Wahren : > > >>> > > >>> Am 19.01.24 um 22:26 schrieb Jens Maus: > > I actually do have some good and bad news: > > > > 1. Good news: I got u-boot finally showing up with my RaspberryPi5 8GB > > both on the HDMI and on the serial debug UART like you reported. > > > > 2. Bad news: I actually got it working by downgrading the rpi-eeprom > > to the same 2023/10/30 (VERSION:30de0ba5) version like you have. > > > > > > > > One idea would be to enable early debug in U-Boot (no idea how to > > > achieve this). I assume U-Boot crashes before it's able to print the > > > first line, but it's hard to believe it crashes at the very first > > > instruction of U-Boot. So with some luck we should be able to narrow > > > done the cause. > > > > I was able to enable early debug UART in U-Boot and I will try to > > find what is happening, once I get some free cycles. > > Ok, this was relatively easy to find :-) > > New versions of EEPROM firmware change “kernel”/U-Boot load address > from 0x8 to 0x20. And because on RPi’s CONFIG_TEXT_BASE is > hardcoded to 0x8 code run through the fields. > > Hopefully simple patch like bellow make it work fine in older and > newer EEPROM firmware versions. > > Regards, > Ivan > > diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig > index 11ede9435d..ce64f9554f 100644 > --- a/configs/rpi_arm64_defconfig > +++ b/configs/rpi_arm64_defconfig > @@ -1,6 +1,7 @@ > CONFIG_ARM=y > CONFIG_ARCH_BCM283X=y > CONFIG_TEXT_BASE=0x0008 > +CONFIG_POSITION_INDEPENDENT=y Not sure if it really matters, but for the Apple M1 config I set CONFIG_TEXT_BASE to 0x (zero).
Re: [PATCH 1/1] lib: support SMBIOS3 table in uuid_guid_get_str()
> From: Heinrich Schuchardt
> Date: Mon, 22 Jan 2024 14:04:35 +0100
>
> As we support installing SMBIOS3 tables in U-Boot we need to add this GUID
> to the translation table used buy uuid_guid_get_str().
>
> Signed-off-by: Heinrich Schuchardt
Reviewed-by: Mark Kettenis
> ---
> lib/uuid.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/lib/uuid.c b/lib/uuid.c
> index 0be22bc05f7..2d7d99535e7 100644
> --- a/lib/uuid.c
> +++ b/lib/uuid.c
> @@ -176,6 +176,10 @@ static const struct {
> "SMBIOS table",
> SMBIOS_TABLE_GUID,
> },
> + {
> + "SMBIOS3 table",
> + SMBIOS3_TABLE_GUID,
> + },
> {
> "Runtime properties",
> EFI_RT_PROPERTIES_TABLE_GUID,
> --
> 2.43.0
>
>
Re: [PATCH 2/2] coreboot: Switch to a monospaced font
> From: Simon Glass
> Date: Sun, 7 Jan 2024 17:14:55 -0700
>
> The default font is proportional, with different character widths.
> Select a monospace font for coreboot so that the 'dm tree' output lines
> up correctly.
>
> Update the coreboot tests to match.
To be honest, I think defaulting to a proportional font is wrong as a
default for something like U-Boot.
> Signed-off-by: Simon Glass
> ---
>
> configs/coreboot64_defconfig | 3 +++
> configs/coreboot_defconfig | 3 +++
> test/cmd/font.c | 12 +---
> 3 files changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig
> index 49c982ef756..c4571090859 100644
> --- a/configs/coreboot64_defconfig
> +++ b/configs/coreboot64_defconfig
> @@ -64,6 +64,9 @@ CONFIG_SOUND=y
> CONFIG_SOUND_I8254=y
> CONFIG_VIDEO_COPY=y
> CONFIG_CONSOLE_TRUETYPE=y
> +CONFIG_CONSOLE_TRUETYPE_SIZE=20
> +# CONFIG_CONSOLE_TRUETYPE_NIMBUS is not set
> +CONFIG_CONSOLE_TRUETYPE_ANKACODER=y
> CONFIG_CONSOLE_SCROLL_LINES=5
> CONFIG_SPL_ACPI=y
> CONFIG_CMD_DHRYSTONE=y
> diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig
> index d4e44e00dca..7aa841bb54b 100644
> --- a/configs/coreboot_defconfig
> +++ b/configs/coreboot_defconfig
> @@ -61,6 +61,9 @@ CONFIG_SOUND=y
> CONFIG_SOUND_I8254=y
> CONFIG_VIDEO_COPY=y
> CONFIG_CONSOLE_TRUETYPE=y
> +CONFIG_CONSOLE_TRUETYPE_SIZE=20
> +# CONFIG_CONSOLE_TRUETYPE_NIMBUS is not set
> +CONFIG_CONSOLE_TRUETYPE_ANKACODER=y
> CONFIG_CONSOLE_SCROLL_LINES=5
> CONFIG_CMD_DHRYSTONE=y
> # CONFIG_GZIP is not set
> diff --git a/test/cmd/font.c b/test/cmd/font.c
> index 9c1eebf799e..ee1c610106d 100644
> --- a/test/cmd/font.c
> +++ b/test/cmd/font.c
> @@ -29,14 +29,20 @@ static int font_test_base(struct unit_test_state *uts)
>
> ut_assertok(console_record_reset_enable());
> ut_assertok(run_command("font list", 0));
> - ut_assert_nextline("nimbus_sans_l_regular");
> + if (IS_ENABLED(CONFIG_CONSOLE_TRUETYPE_NIMBUS))
> + ut_assert_nextline("nimbus_sans_l_regular");
> + if (IS_ENABLED(CONFIG_CONSOLE_TRUETYPE_ANKACODER))
> + ut_assert_nextline("ankacoder_c75_r");
> if (IS_ENABLED(CONFIG_CONSOLE_TRUETYPE_CANTORAONE))
> ut_assert_nextline("cantoraone_regular");
> ut_assertok(ut_check_console_end(uts));
>
> ut_assertok(vidconsole_get_font_size(dev, , ));
> - ut_asserteq_str("nimbus_sans_l_regular", name);
> - ut_asserteq(18, size);
> + if (IS_ENABLED(CONFIG_CONSOLE_TRUETYPE_ANKACODER))
> + ut_asserteq_str("ankacoder_c75_r", name);
> + else
> + ut_asserteq_str("nimbus_sans_l_regular", name);
> + ut_asserteq(CONFIG_CONSOLE_TRUETYPE_SIZE, size);
>
> if (!IS_ENABLED(CONFIG_CONSOLE_TRUETYPE_CANTORAONE))
> return 0;
> --
> 2.34.1
>
>
Re: [PATCH v3 4/8] dts: Add alternative location for upstream DTB builds
> Date: Sun, 31 Dec 2023 15:39:53 -0500 > From: Tom Rini > > On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote: > > Hi Sumit, > > > > On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg wrote: > > > > > > On Fri, 29 Dec 2023 at 01:18, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini wrote: > > > > > > > > > > On Thu, Dec 28, 2023 at 03:09:12PM +, Simon Glass wrote: > > > > > > Hi Tom, Sumit, > > > > > > > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini wrote: > > > > > > > > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +, Simon Glass wrote: > > > > > > > > Hi Sumit, > > > > > > > > > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Allow platform owners to mirror devicetree files from > > > > > > > > > devitree-rebasing > > > > > > > > > directory into dts/arch/$(ARCH) (special case for > > > > > > > > > dts/arch/arm64). Then > > > > > > > > > build then along with any *-u-boot.dtsi file present in > > > > > > > > > arch/$(ARCH)/dts > > > > > > > > > directory. Also add a new Makefile for arm64. > > > > > > > > > > > > > > > > > > This will help easy migration for platforms which currently > > > > > > > > > are compliant > > > > > > > > > with upstream Linux kernel devicetree files. > > > > > > > > > > > > > > > > > > Signed-off-by: Sumit Garg > > > > > > > > > --- > > > > > > > > > > > > > > > > > > Changes in v3: > > > > > > > > > -- > > > > > > > > > - Minor commit message update > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > -- > > > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ > > > > > > > > > > > > > > > > > > dts/Kconfig | 11 +++ > > > > > > > > > dts/Makefile| 17 ++--- > > > > > > > > > dts/arch/arm64/Makefile | 14 ++ > > > > > > > > > 3 files changed, 39 insertions(+), 3 deletions(-) > > > > > > > > > create mode 100644 dts/arch/arm64/Makefile > > > > > > > > > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig > > > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644 > > > > > > > > > --- a/dts/Kconfig > > > > > > > > > +++ b/dts/Kconfig > > > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE > > > > > > > > > enables a live tree which is available after > > > > > > > > > relocation, > > > > > > > > > and can be adjusted as needed. > > > > > > > > > > > > > > > > > > +config OF_UPSTREAM > > > > > > > > > + bool "Enable use of devicetree imported from Linux > > > > > > > > > kernel release" > > > > > > > > > + help > > > > > > > > > + Traditionally, U-Boot platforms used to have their > > > > > > > > > custom devicetree > > > > > > > > > + files or copy devicetree files from Linux kernel > > > > > > > > > which are hard to > > > > > > > > > + maintain and can usually get out-of-sync from Linux > > > > > > > > > kernel. This > > > > > > > > > + option enables platforms to migrate to > > > > > > > > > devicetree-rebasing repo where > > > > > > > > > + a regular sync will be maintained every major Linux > > > > > > > > > kernel release > > > > > > > > > + cycle. However, platforms can still have some > > > > > > > > > custom u-boot specific > > > > > > > > > + bits maintained as part of *-u-boot.dtsi files. > > > > > > > > > > > > > > > > My only other suggestion here is to mention that this should be > > > > > > > > set in > > > > > > > > Kconfig, for the SoC as a whole. So I believe that means that it > > > > > > > > should be hidden, with no string for the 'bool': > > > > > > > > > > > > > > > > bool # Enable use of devicetree imported from Linux > > > > > > > > kernel release > > > > > > > > > > > > > > I think we can just keep prompting for it now, to make the > > > > > > > transition > > > > > > > easier, before this option just goes away in time, hopefully. > > > > > > > > > > > > > > > Also, this doesn't seem to work for me. Before this series I > > > > > > > > get these > > > > > > > > files when building firefly-rk3399: > > > > > > > > > > > > > > > > rk3399-eaidk-610.dtbrk3399-khadas-edge-v.dtb > > > > > > > > rk3399-orangepi.dtbrk3399-rock-pi-4a.dtb > > > > > > > > rk3399-evb.dtb rk3399-leez-p710.dtb > > > > > > > > rk3399-pinebook-pro.dtbrk3399-rock-pi-4c.dtb > > > > > > > > rk3399-ficus.dtbrk3399-nanopc-t4.dtb > > > > > > > > rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb > > > > > > > > rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb > > > > > > > > rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb > > > > > > > > rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb > > > > > > > > rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb > > > > > > > > rk3399-gru-kevin.dtbrk3399-nanopi-m4.dtb > > > > > > > > rk3399-rock-4c-plus.dtb > > > > >
Re: Proposal: U-Boot memory management
> Date: Fri, 29 Dec 2023 11:17:44 -0500 > From: Tom Rini > > On Fri, Dec 29, 2023 at 05:05:17PM +0100, Heinrich Schuchardt wrote: > > > > > > Am 29. Dezember 2023 16:43:07 MEZ schrieb Tom Rini : > > >On Fri, Dec 29, 2023 at 05:36:09AM +, Simon Glass wrote: > > >> Hi, > > >> > > >> On Sat, Dec 16, 2023 at 6:01 PM Simon Glass wrote: > > >> > > > >> > Hi, > > >> > > > >> > This records my thoughts after a discussion with Ilias & Heinrich re > > >> > memory allocation in U-Boot. > > >> > > > >> > 1. malloc() > > >> > > > >> > malloc() is used for programmatic memory allocation. It allows memory > > >> > to be freed. It is not designed for very large allocations (e.g. a > > >> > 10MB kernel or 100MB ramdisk). > > >> > > > >> > 2. lmb > > >> > > > >> > lmb is used for large blocks of memory, such as those needed for a > > >> > kernel or ramdisk. Allocation is only transitory, for the purposes of > > >> > loading some images and booting. If the boot fails, then all lmb > > >> > allocations go away. > > >> > > > >> > lmb is set up by getting all available memory and then removing what > > >> > is used by U-Boot (code, data, malloc() space, etc.) > > >> > > > >> > lmb reservations have a few flags so that areas of memory can be > > >> > provided with attributes > > >> > > > >> > There are some corner cases...e.g. loading a file does an lmb > > >> > allocation but only for the purpose of avoiding a file being loaded > > >> > over U-Boot code/data. The allocation is dropped immediately after the > > >> > file is loaded. Within the bootm command, or when using standard boot, > > >> > this would be fairly easy to solve. > > >> > > > >> > Linux has renamed lmb to memblock. We should consider doing the same. > > >> > > > >> > 3. EFI > > >> > > > >> > EFI has its own memory-allocation tables. > > >> > > > >> > Like lmb, EFI is able to deal with large allocations. But via a 'pool' > > >> > function it can also do smaller allocations similar to malloc(), > > >> > although each one uses at least 4KB at present. > > >> > > > >> > EFI allocations do not go away when a boot fails. > > >> > > > >> > With EFI it is possible to add allocations post facto, in which case > > >> > they are added to the allocation table just as if the memory was > > >> > allocated with EFI to begin with. > > >> > > > >> > The EFI allocations and the lmb allocations use the same memory, so in > > >> > principle could conflict. > > >> > > > >> > EFI allocations are sometimes used to allocate internal U-Boot data as > > >> > well, if needed by the EFI app. For example, while efi_image_parse() > > >> > uses malloc(), efi_var_mem.c uses EFI allocations since the code runs > > >> > in the app context and may need to access the memory after U-Boot has > > >> > exited. Also efi_smbios.c uses allocate_pages() and then adds a new > > >> > mapping as well. > > >> > > > >> > EFI memory has attributes, including what the memory is used for (to > > >> > some degree of granularity). See enum efi_memory_type and struct > > >> > efi_mem_desc. In the latter there are also attribute flags - whether > > >> > memory is cacheable, etc. > > >> > > > >> > EFI also has the x86 idea of 'conventional' memory, meaning (I > > >> > believe) that below 4GB that isn't reserved for the hardware/system. > > >> > This is meaningless, or at least confusing, on ARM systems. > > >> > > > >> > 4. reservations > > >> > > > >> > It is perhaps worth mentioning a fourth method of memory management, > > >> > where U-Boot reserves chunks of memory before relocation (in > > >> > board_init_f.c), e.g. for the framebuffer, U-Boot code, the malloc() > > >> > region, etc. > > >> > > > >> > > > >> > Problems > > >> > —--- > > >> > > > >> > There are no urgent problems, but here are some things that could be > > >> > improved: > > >> > > > >> > 1. EFI should attach most of its data structures to driver model. This > > >> > work has started, with the partition support, but more effort would > > >> > help. This would make it easier to see which memory is related to > > >> > devices and which is separate. > > >> > > > >> > 2. Some drivers do EFI reservations today, whether EFI is used for > > >> > booting or not (e.g. rockchip video rk_vop_probe()). > > >> > > > >> > 3. U-Boot doesn't really map arch-specific memory attributes (e.g. > > >> > armv8's struct mm_region) to EFI ones. > > >> > > > >> > 4. EFI duplicates some code from bootm, some of which relates to > > >> > memory allocation (e.g. FDT fixup). > > >> > > > >> > 5. EFI code is used even if EFI is never used to boot > > >> > > > >> > 6. EFI allocations can result in the same memory being used as has > > >> > already been allocated by lmb. Users may load files which overwrite > > >> > memory allocated by EFI. > > >> > > >> 7. We need to support doing an allocation when a file is loaded (to > > >> ensure files do not overlap), without making it too difficult to load > > >> multiple files to the same place, if desired. > > >> > >
Re: [PATCH v4 4/7] smbios: Use SMBIOS 3.0 to support an address above 4GB
> From: Simon Glass > Date: Thu, 28 Dec 2023 13:37:03 + > > Hi Ilias, > > On Wed, Dec 27, 2023 at 11:05 AM Ilias Apalodimas > wrote: > > > > Hi Simon, > > > > On Wed, 27 Dec 2023 at 09:40, Simon Glass wrote: > > > > > > When the SMBIOS table is written to an address above 4GB a 32-bit table > > > address is not large enough. > > > > > > Use an SMBIOS3 table in that case. > > > > Maybe I missed this on the previous revisions, but is there a reason > > we don't always use SMBIOS3 now? > > I am not sure...there was some comment about it not being supported in > some cases, so I have tried to accommodate that. > > > And perhaps try to install SMBIOS2 if > > 1. we fail > > due to? > > > 2. and the address is < 4GB > > We could, I suppose. Effectively we would drop generation of SMBIOS2. > > I really don't mind. This whole SMBIOS thing is a bit ridiculous, if > you ask me. Linux added support for the SMBIOS 3.0 64-bit entry point in 2014. I doubt anyone who cares about SMBIOS cares about kernels that old. So if it simplifies things, I'd drop support for the 32-bit SMBIOS entry point.
Re: [RFC PATCH 2/2] common: console: Add support of passing the saved console log to the OS
> From: Bence Cs
> Date: Thu, 28 Dec 2023 00:30:12 +0100
>
> CONFIG_CONSOLE_RECORD_SAVE option allows for the recorded console log to
> be saved to a memory location, along with some metadata. This memory
> address is then passed to the booted OS via command line.
Hi,
Sorry, but I fear the concept of passing the memory location of
something via the concept is an alien concept to some OSes. And even
on Linux there will be issues when you're booting using an EFI
bootloader. So I think this needs some further thought.
A better approach would be to pass the address (and size) of the
buffer through an "u-boot,bootlog" property (or something like that)
in the /chosen node of the device tree. And make sure the memory
block is present in the EFI memory map.
Cheers,
Mark
>
> Signed-off-by: Bence Cs
> ---
>
> Notes:
> Some improvements to consider:
> * pass CONFIG_CONSOLE_RECORD_SAVE_BASE via FDT
> * or possibly add it to U-Boot env, so scripts can choose the passing
> method
> * find a better place to call console_record_save(), ideally as late as
> possible
>
> Link: https://lists.denx.de/pipermail/u-boot/2023-December/541138.html
>
> boot/bootm.c | 27 +--
> common/Kconfig| 13 +
> common/console.c | 13 +
> include/console.h | 19 +++
> 4 files changed, 70 insertions(+), 2 deletions(-)
>
> diff --git a/boot/bootm.c b/boot/bootm.c
> index 7a050ed41a..7f67f6a58e 100644
> --- a/boot/bootm.c
> +++ b/boot/bootm.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -857,6 +858,16 @@ static int process_subst(char *buf, int maxlen)
> return ret;
> }
>
> +static int append_bootlog_base(char *buf, int maxlen)
> +{
> + int size = strlen(buf);
> +
> + if (size + 1 + strlen(" bootlog.base=0x" + 8 > maxlen)
> + return -ENOSPC;
> +
> + sprintf(buf + size, " bootlog.base=0x%08X",
> CONFIG_CONSOLE_RECORD_SAVE_BASE);
> +}
> +
> int bootm_process_cmdline(char *buf, int maxlen, int flags)
> {
> int ret;
> @@ -875,6 +886,11 @@ int bootm_process_cmdline(char *buf, int maxlen, int
> flags)
> if (ret)
> return log_msg_ret("subst", ret);
> }
> + if (IS_ENABLED(CONFIG_CONSOLE_RECORD_SAVE)) {
> + ret = append_bootlog_base(buf, maxlen);
> + if (ret)
> + return log_msg_ret("bootlogbase", ret);
> + }
>
> return 0;
> }
> @@ -882,7 +898,7 @@ int bootm_process_cmdline(char *buf, int maxlen, int
> flags)
> int bootm_process_cmdline_env(int flags)
> {
> const int maxlen = MAX_CMDLINE_SIZE;
> - bool do_silent;
> + bool do_silent, do_pass_record;
> const char *env;
> char *buf;
> int ret;
> @@ -890,7 +906,8 @@ int bootm_process_cmdline_env(int flags)
> /* First check if any action is needed */
> do_silent = IS_ENABLED(CONFIG_SILENT_CONSOLE) &&
> !IS_ENABLED(CONFIG_SILENT_U_BOOT_ONLY) && (flags & BOOTM_CL_SILENT);
> - if (!do_silent && !IS_ENABLED(CONFIG_BOOTARGS_SUBST))
> + do_pass_record = IS_ENABLED(CONFIG_CONSOLE_RECORD_SAVE);
> + if (!do_silent && !do_pass_record && !IS_ENABLED(CONFIG_BOOTARGS_SUBST))
> return 0;
>
> env = env_get("bootargs");
> @@ -1056,6 +1073,13 @@ int bootm_run_states(struct bootm_info *bmi, int
> states)
> }
> #endif
>
> + if (ret)
> + return ret;
> +
> +#if CONFIG_IS_ENABLED(CONSOLE_RECORD_SAVE)
> + console_record_save();
> +#endif /* CONFIG_IS_ENABLED(CONSOLE_RECORD_SAVE) */
> +
> /* From now on, we need the OS boot function */
> if (ret)
> return ret;
> diff --git a/common/Kconfig b/common/Kconfig
> index 0283701f1d..d70fa748c2 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -52,6 +52,19 @@ config CONSOLE_RECORD_IN_SIZE
> The buffer is allocated immediately after the malloc() region is
> ready.
>
> +config CONSOLE_RECORD_SAVE
> + bool "Save a copy of the recording for the OS to read"
> + depends on CONSOLE_RECORD
> + help
> + This option makes a copy of the recorded console log available at a
> fixed
> + RAM location, so that the booted OS can read it
> +
> +config CONSOLE_RECORD_SAVE_BASE
> + hex "Memory location to save the log to"
> + depends on CONSOLE_RECORD_SAVE
> + help
> + The base address for the saved copy (will be passed to the booted OS)
> +
> config SYS_CBSIZE
> int "Console input buffer size"
> default 2048 if ARCH_TEGRA || ARCH_VERSAL || ARCH_ZYNQ || ARCH_ZYNQMP
> || \
> diff --git a/common/console.c b/common/console.c
> index 1ffda49c87..77a41d99f7 100644
> --- a/common/console.c
> +++ b/common/console.c
> @@ -860,6 +860,19 @@ int console_in_puts(const char *str)
>
> #endif
>
> +#if CONFIG_IS_ENABLED(CONSOLE_RECORD_SAVE)
> +void
Re: [PATCH] arm: apple: Disable SMBIOS again
> Date: Sun, 24 Dec 2023 20:37:47 +0100
> From: Heinrich Schuchardt
>
> On 12/24/23 19:12, Mark Kettenis wrote:
> > Apple machines do not have memory below 4G. Since U-Boot does
> > not support the SMBIOS 3 header structures this means we can't
> > support SMBIOS on these machines. Unfortunately the refactoring
> > of the SMBIOS code this cycle accidentally enabled it again.
> >
> > Fixes: 53fab13a7b1 ("efi: Use the installed SMBIOS tables")
> > Signed-off-by: Mark Kettenis
>
> My understanding this is for origin/master. For next we have pending
> patches from Simon to move to SMBIOS 3.
Right. Without this fix EFI boot will fail on U-Boot 2024.01. And
that is 99% of the users.
When the SMBIOS 3 patches land, I intend to turn this back on again
(after making sure the tables are populated with the appropriate
information).
> Reviewed-by: Heinrich Schuchardt
>
> > ---
> > configs/apple_m1_defconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/configs/apple_m1_defconfig b/configs/apple_m1_defconfig
> > index d58a9030db..b868d0e319 100644
> > --- a/configs/apple_m1_defconfig
> > +++ b/configs/apple_m1_defconfig
> > @@ -21,5 +21,5 @@ CONFIG_USB_KEYBOARD=y
> > CONFIG_SYS_WHITE_ON_BLACK=y
> > CONFIG_NO_FB_CLEAR=y
> > CONFIG_VIDEO_SIMPLE=y
> > -# CONFIG_GENERATE_SMBIOS_TABLE is not set
> > +# CONFIG_SMBIOS is not set
> > CONFIG_LMB_MAX_REGIONS=64
>
>
[PATCH] arm: apple: Disable SMBIOS again
Apple machines do not have memory below 4G. Since U-Boot does
not support the SMBIOS 3 header structures this means we can't
support SMBIOS on these machines. Unfortunately the refactoring
of the SMBIOS code this cycle accidentally enabled it again.
Fixes: 53fab13a7b1 ("efi: Use the installed SMBIOS tables")
Signed-off-by: Mark Kettenis
---
configs/apple_m1_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/apple_m1_defconfig b/configs/apple_m1_defconfig
index d58a9030db..b868d0e319 100644
--- a/configs/apple_m1_defconfig
+++ b/configs/apple_m1_defconfig
@@ -21,5 +21,5 @@ CONFIG_USB_KEYBOARD=y
CONFIG_SYS_WHITE_ON_BLACK=y
CONFIG_NO_FB_CLEAR=y
CONFIG_VIDEO_SIMPLE=y
-# CONFIG_GENERATE_SMBIOS_TABLE is not set
+# CONFIG_SMBIOS is not set
CONFIG_LMB_MAX_REGIONS=64
--
2.43.0
Re: Passing boot logs to Linux?
> Date: Tue, 19 Dec 2023 23:45:48 -0500 > From: Sean Anderson > > On 12/19/23 23:11, Simon Glass wrote: > > Hi Csókás, > > > > On Tue, 19 Dec 2023 at 13:15, Csókás Bence wrote: > >> > >> Hi! > >> > >> Is passing the U-Boot boot log to Linux supported yet? We are working > >> with a third-party solution, which works, but is a bit hacky, so I was > >> wondering if an official solution has been merged yet. > >> > >> I saw that there was an option CONFIG_CONSOLE_RECORD that saves > >> everything to a membuff, but I don't know if that can be exported to > >> Linux yet. And if not in the tree yet, would such a patch be welcome? > > > > Not yet, but yes I would like to see this. > > I think most of the infrastructure is already here. We could use > either console recording (as mentioned above), which is more > complete, or a new LOG_DRIVER (which would have the advantage of > omitting things like countdowns). > > In terms of sending things to Linux, I think the natural choice > would be pstore, which we already have a parser for. Well, this should be OS-agnostic of course ;) What is pstore? Is this documented somewhere?
Re: Adding EFI runtime support to the Arm's FF-A bus
> From: Michael Walle > Date: Tue, 19 Dec 2023 11:11:24 +0100 > > Hi Heinrich, Hi Michael, > > Any runtime device drivers for variable storage should not be in the > > U-Boot runtime but live in the secure world (e.g. OP-TEE) FF-A is the > > new ARM protocol for talking to the secure world and hence fits into > > the picture. > > What if I just want a simple embedded boot stack where I don't > want any secure world and just want to be able to boot a COTS linux > distribution via EFI? That already works for many Linux distros. As long as the distro installs the appropriate BOOTxxx.EFI file you don't actually need to set any EFI variables for the OS to boot. It can't get any simpler than that. Of the main Linux distros it seems that only Debian doesn't do this. Someone should probably lobby Debian to do this as well as it would mean that Debian would just work on an EBBR compliant system. Things get more complicated if you want to install multiple OSes. Then having EFI variable support makes things a lot more straightforward. And of course EFI secure boot needs EFI variable support as well (with proper support) for authenticated EFI variables. But IMHO that no longer falls into "simple embedded boot stack" territory. > Assuming, that there might be a simple dedicated EEPROM to store the > variables which is not exposed to linux, is that something which would > be rejected by u-boot mainline now? Not necessarily. But such an approach will have limitations: * Completely hiding the EEPROM from the OS may be hard. Even if you have a dedicated SPI controller for the EEPROM things like the SPI bus clock or power domains may still be under OS control. * It is not possible to properly implement authenticated variables for secure boot if the EEPROM and associated hardware is just removed from the device tree but still accessable to the OS. An implementation that pretends the variables are "secure" will probably be rejected. Cheers, Mark
Re: Adding EFI runtime support to the Arm's FF-A bus
> Date: Thu, 14 Dec 2023 15:53:46 + > From: Abdellatif El Khlifi Hi Abdellatif, > Hi guys, > > I'd like to ask for advice regarding adding EFI RT support to the Arm's FF-A > bus > in U-Boot. > > The objective is to enable the FF-A messaging APIs in EFI RT to be > used for comms with the secure world. This will help getting/setting > EFI variables through FF-A. > > The existing FF-A APIs in U-Boot call the DM APIs (which are not available at > RT). > > Two possible solutions: > > 1/ having the entire U-Boot in RT space (as Simon stated in this > discussion[1]) I don't think this is a terribly good idea. With this approach orders of magnitude more code will be present in kernel address space one the OS kernel is running and calling into the EFI runtime. Including code that may access hardware devices that are now under OS control. It will be nigh impossible to audit all that code and make sure that only a safe subset of it gets called. So... > > 2/ Create an RT variant for the FF-A APIs needed. > These RT variant don't call the DM APIs > (e.g: ffa_mm_communicate_runtime, ffa_sync_send_receive_runtime, ...) > > What do you recommend please ? ...this is what I would recommend. Preferably in a way that refactors the code such that the low-level functionality is shared between the DM and non-DM APIs. > > [1]: > https://lore.kernel.org/all/capnjgz21qlnsfccj9rpqxefqf-njmbf3kyudbboc6wuqxqt...@mail.gmail.com/ > > Cheers, > Abdellatif >
Re: [PATCH 2/2 v3] smbios: Fallback to the default DT if sysinfo nodes are missing
> Date: Wed, 13 Dec 2023 15:56:34 -0500 > From: Tom Rini > > On Wed, Dec 13, 2023 at 01:41:04PM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 13 Dec 2023 at 13:17, Tom Rini wrote: > > > > > > On Wed, Dec 13, 2023 at 12:51:33PM -0700, Simon Glass wrote: > > > > Hi Ilias, > > > > > > > > On Thu, 7 Dec 2023 at 02:19, Ilias Apalodimas > > > > wrote: > > > > > > > > > > In order to fill in the SMBIOS tables U-Boot currently relies on a > > > > > "u-boot,sysinfo-smbios" compatible node. This is fine for the boards > > > > > that already include such nodes. However with some recent EFI > > > > > changes, > > > > > the majority of boards can boot up distros, which usually rely on > > > > > things like dmidecode etc for their reporting. For boards that > > > > > lack this special node the SMBIOS output looks like: > > > > > > > > > > System Information > > > > > Manufacturer: Unknown > > > > > Product Name: Unknown > > > > > Version: Unknown > > > > > Serial Number: Unknown > > > > > UUID: Not Settable > > > > > Wake-up Type: Reserved > > > > > SKU Number: Unknown > > > > > Family: Unknown > > > > > > > > > > This looks problematic since most of the info are "Unknown". The DT > > > > > spec > > > > > specifies standard properties containing relevant information like > > > > > 'model' and 'compatible' for which the suggested format is > > > > > . Unfortunately the 'model' string found in DTs is > > > > > usually lacking the manufacturer so we can't use it for both > > > > > 'Manufacturer' and 'Product Name' SMBIOS entries reliably. > > > > > > > > > > So let's add a last resort to our current smbios parsing. If none of > > > > > the sysinfo properties are found, scan for those information in the > > > > > root node of the device tree. Use the 'model' to fill the 'Product > > > > > Name' and the first value of 'compatible' for the 'Manufacturer', > > > > > since > > > > > that always contains one. > > > > > > > > > > pre-patch: > > > > > Handle 0x0001, DMI type 1, 27 bytes > > > > > System Information > > > > > Manufacturer: Unknown > > > > > Product Name: Unknown > > > > > Version: Unknown > > > > > Serial Number: 1bb24ceb > > > > > UUID: 30303031-3030-3030-3061-613234636435 > > > > > Wake-up Type: Reserved > > > > > SKU Number: Unknown > > > > > Family: Unknown > > > > > [...] > > > > > > > > > > and post patch: > > > > > Handle 0x0001, DMI type 1, 27 bytes > > > > > System Information > > > > > Manufacturer: raspberrypi > > > > > Product Name: Raspberry Pi 4 Model B Rev 1.1 > > > > > Version: Unknown > > > > > Serial Number: 1bb24ceb > > > > > UUID: 30303031-3030-3030-3061-613234636435 > > > > > Wake-up Type: Reserved > > > > > SKU Number: Unknown > > > > > Family: Unknown > > > > > [...] > > > > > > > > > > Signed-off-by: Ilias Apalodimas > > > > > --- > > > > > Simon, I'll work with tou on the refactoring you wanted and > > > > > remove the EFI requirement of SMBIOS in !x86 platforms. > > > > > Since this code has no tests, I'll add some once the refactoring > > > > > is done > > > > > > > > > > Changes since v2: > > > > > - Spelling mistakes > > > > > - rebase on top of patch #1 changes > > > > > Changes since v1: > > > > > - Tokenize the DT node entry and use the appropriate value instead of > > > > > the entire string > > > > > - Removed Peters tested/reviewed-by tags due to the above > > > > > lib/smbios.c | 94 > > > > > +--- > > > > > 1 file changed, 89 insertions(+), 5 deletions(-) > > > > > > > > Can we add a Kconfig to enable this? > > > > > > Why? This is the default option that we want moving forward in order to > > > get the fields populated. > > > > The model name is fine. The manufacturer is in lower case (using the > > DT vendor name), so not in the right format. > > > > It only populates two fields, so far as I can tell. > > Maybe we need to turn this discussion on its head slightly. What do you > want to do to get SMBIOS fields to be widely populated with > generally-correct information? What we have been doing has seen very > little adoption so we need something else. One possibility would be to have a script that maps the board compatible to a vendor name using Documentation/devicetree/bindings/vendor-prefixes.yaml That would solve populating the manufacturer field, but not the product_name unfortunately.
Re: [PATCH 2/2 v2] smbios: Fallback to the default DT if sysinfo nodes are missing
> From: Simon Glass > Date: Wed, 13 Dec 2023 13:41:05 -0700 > > Hi Tom, > > On Wed, 13 Dec 2023 at 13:19, Tom Rini wrote: > > > > On Wed, Dec 13, 2023 at 12:50:03PM -0700, Simon Glass wrote: > > > Hi Ilias, > > > > > > On Mon, 11 Dec 2023 at 00:49, Ilias Apalodimas > > > wrote: > > > > > > > > Hi Tom, > > > > > > > > On Sat, 9 Dec 2023 at 20:49, Tom Rini wrote: > > > > > > > > > > On Wed, Dec 06, 2023 at 06:03:14PM +0200, Ilias Apalodimas wrote: > > > > > > Hi Simon, > > > > > > > > > > > > On Sat, 2 Dec 2023 at 20:28, Simon Glass wrote: > > > > > > > > > > > > > > Hi Ilias, > > > > > > > > > > > > > > On Wed, 29 Nov 2023 at 23:50, Ilias Apalodimas > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > >> > Changes since v1: > > > > > > > >> > - Tokenize the DT node entry and use the appropriate value > > > > > > > >> > instead of > > > > > > > >> > the entire string > > > > > > > >> > - Removed Peters tested/reviewed-by tags due to the above > > > > > > > >> > lib/smbios.c | 94 > > > > > > > >> > +--- > > > > > > > >> > 1 file changed, 90 insertions(+), 4 deletions(-) > > > > > > > >> > > > > > > > > >> > > > > > > > >> Can this be put behind a Kconfig? It adds quite a bit of code > > > > > > > >> which > > > > > > > >> punishes those boards which do the right thing. > > > > > > > > > > > > > > > > > > > > > > > > Sure but OTOH the code increase should be really minimal. But I > > > > > > > > don't mind I can add a Kconfig > > > > > > > > > > > > > > > >> > > > > > > > >> > + > > > > > > > >> > + dt_str = ofnode_read_string(ofnode_root(), > > > > > > > >> > nprop->dt_str); > > > > > > > >> > > > > > > > >> Could this use ofnode_read_string_index() ? > > > > > > > > > > > > > > > > > > > > > > > > Maybe, I'll have a look and change it if that works > > > > > > > > > > > > Unless I am missing something this doesn't work. > > > > > > This is designed to return a string index from a DT property that's > > > > > > defined as > > > > > > foo_property = "value1", "value2" isn't it? > > > > > > > > > > > > The code above is trying to read an existing property (e.g > > > > > > compatible) > > > > > > and get the string after the comma delimiter. > > > > > > Perhaps I should add this in drivers/core/ofnode.c instead? > > > > > > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > >> > > > > > > > >> Any chance of a test for this code? > > > > > > > > > > > > > > > > > > > > > > > > Sure, but any suggestions on where to add the test? > > > > > > > > SMBIOS tables are populated on OS booting, do we have a test > > > > > > > > somewhere that boots an OS? > > > > > > > > > > > > > > They are written on startup, right? They should certainly be in > > > > > > > place > > > > > > > before U-Boot enters the command line. > > > > > > > > > > > > Not always. I am not sure if x86 does that, but on the rest of the > > > > > > architectures, they are only initialized when the efi smbios code > > > > > > runs. Wasn't this something you were trying to change? > > > > > > > > > > One of those things I keep repeating is that we don't know for sure > > > > > what > > > > > the right values here are until we load the DT the OS _will_ use. It's > > > > > quite valid to start U-Boot and pass it a generic "good enough" DT at > > > > > run time until U-Boot can see (GPIOs, EEPROM, whatever) what it's on > > > > > and > > > > > what the real DT to load before passing to the OS is. Since U-Boot > > > > > doesn't need SMBIOS tables itself, we should make these "late" not > > > > > "early". > > > > > > > > Fair enough, we can defer the init and testing of those late, just > > > > before we are about to boot. But this is irrelevant to what this patch > > > > does, can we get the fallback mechanism in first, assuming everyone is > > > > ok with the patch now? > > > > > > > > > > I would like this behind a Kconfig. Making it the default means people > > > are going to start relying on (in user space) and then discover later > > > that it is wrong. > > > > What do you mean wrong, exactly? > > "raspberrypi" instead of "Raspberry Pi", for example, or "friendlyarm" > instead of "FriendlyElec" Heh, well, even in the x86 world vendors can't even spell their own name consistently. > I just wonder what this information is actually used for. If it is > just for fun, that is fine, but I believe some tools do use dmidecode, > at which point it needs to be accurate and should not change later, > e.g. when someone decides to actually add the info. So the Linux kernel uses this information to apply quirks for specific machines. But I hope that on platforms that have a device tree folks will just use the board compatible string for that purpose. Otherwise I think this information is mostly used to populate system information UIs and asset databases.
Re: [PATCH v2] bootstd: Fix a memory leak in the efi manager bootflow
> From: Ilias Apalodimas
> Date: Thu, 7 Dec 2023 14:36:36 +0200
>
> efi_get_var() allocates memory which has to be freed after the value of
> the variable is consumed. Free the memory properly
>
> Fixes: f2bfa0cb1794 ("bootstd: Make efi_mgr bootmeth work for non-sandbox
> setups")
> Signed-off-by: Ilias Apalodimas
> ---
> Apologies for the quick resend but the previous patches wasn't compiling due
> to
> the missing #include
>
> Changes since v1
> - Add #include since it's needed for free()
>
> boot/bootmeth_efi_mgr.c | 2 ++
> 1 file changed, 2 insertions(+)
Oops!
Reviewed-by: Mark Kettenis
> diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c
> index e6c42d41fb80..6428c096d7f8 100644
> --- a/boot/bootmeth_efi_mgr.c
> +++ b/boot/bootmeth_efi_mgr.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> /**
> * struct efi_mgr_priv - private info for the efi-mgr driver
> @@ -65,6 +66,7 @@ static int efi_mgr_read_bootflow(struct udevice *dev,
> struct bootflow *bflow)
> bootorder = efi_get_var(u"BootOrder", _global_variable_guid,
> );
> if (bootorder) {
> + free(bootorder);
> bflow->state = BOOTFLOWST_READY;
> return 0;
> }
> --
> 2.40.1
>
>
Re: [PATCH 1/1] efi_loader: boot options should relate to the ESP
> From: Peter Robinson
> Date: Wed, 6 Dec 2023 10:44:59 +
>
> On Wed, Dec 6, 2023 at 9:31 AM Heinrich Schuchardt
> wrote:
> >
> > On 05.12.23 07:23, Masahisa Kojima wrote:
> > > Hi Heinrich,
> > >
> > > On Tue, 5 Dec 2023 at 11:38, Heinrich Schuchardt
> > > wrote:
> > >>
> > >> * Only generate removable media entries for EFI system partitions.
> > >> * Only offer EFI system partitions for boot options in the eficonfig
> > >>command.
> > >>
> > >> Fixes: c416f1c0bcab ("bootmenu: add removable media entries")
> > >> Fixes: 87d791423ac6 ("eficonfig: menu-driven addition of UEFI boot
> > >> option")
> > >> Signed-off-by: Heinrich Schuchardt
> > >> ---
> > >> cmd/eficonfig.c | 6 --
> > >> lib/efi_loader/efi_bootmgr.c | 3 ++-
> > >> 2 files changed, 6 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
> > >> index 34a59cb15d..c066b28b6b 100644
> > >> --- a/cmd/eficonfig.c
> > >> +++ b/cmd/eficonfig.c
> > >> @@ -626,8 +626,10 @@ static efi_status_t eficonfig_select_volume(struct
> > >> eficonfig_select_file_info *f
> > >> efi_handle_t *volume_handles = NULL;
> > >> struct efi_simple_file_system_protocol *v;
> > >>
> > >> - ret = efi_locate_handle_buffer_int(BY_PROTOCOL,
> > >> _simple_file_system_protocol_guid,
> > >> - NULL, , (efi_handle_t
> > >> **)_handles);
> > >> + /* Find all EFI system partitions */
> > >> + ret = efi_locate_handle_buffer_int(BY_PROTOCOL,
> > >> + _system_partition_guid,
> > >> + NULL, ,
> > >> _handles);
> > >
> > > UEFI specification v2.10 section '3.5 Boot Mechanisms' says
> > > "EFI can boot from a device using the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL or
> > > the
> > > EFI_LOAD_FILE_PROTOCOL."
> > >
> > > So in my understanding of the UEFI spec, I think
> > > efi_simple_file_system_protocol_guid
> > > is correct here.
> > >
> > >> if (ret != EFI_SUCCESS) {
> > >> eficonfig_print_msg("No block device found!");
> > >> return ret;
> > >> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> > >> index 48153bd5ff..9e84391186 100644
> > >> --- a/lib/efi_loader/efi_bootmgr.c
> > >> +++ b/lib/efi_loader/efi_bootmgr.c
> > >> @@ -1047,8 +1047,9 @@ efi_status_t
> > >> efi_bootmgr_update_media_device_boot_option(void)
> > >> efi_handle_t *volume_handles = NULL;
> > >> struct eficonfig_media_boot_option *opt = NULL;
> > >>
> > >> + /* Find all EFI system partitions */
> > >> ret = efi_locate_handle_buffer_int(BY_PROTOCOL,
> > >> -
> > >> _simple_file_system_protocol_guid,
> > >> + _system_partition_guid,
> > >
> > > In EDK II reference implementation[0], it enumerates all
> > > block_io_protocol devices
> > > and eliminates logical partitions.
> > > Should we do the same? If yes, I can prepare the patch on this.
> >
> > This is what the boot options look like on an EDK II system:
> >
> > $ efibootmgr -v
> > BootCurrent: 000D
> > Timeout: 3 seconds
> > BootOrder:
> > 000D,000B,000C,0003,0004,0005,0006,0007,0008,0009,000A,,0001,0002
> > Boot* UiApp
> > FvVol(5eda4200-2c5f-43cb-9da3-0baf74b1b30c)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
> > Boot0001* helloworld
> > VenHw(0d51905b-b77e-452a-a2c0-eca0cc8d514a,54f200)/Sata(1,65535,0)/HD(1,GPT,40c323d0-6b76-47c4-bc82-e05bf5d23c9f,0x2000,0x20)/File(\helloworld.efi)h.e.l.l.o.
> > .w.o.r.l.d...
> > Boot0002* UEFI Crucial_CT128M550SSD1 14270C7CFEFE
> > VenHw(0d51905b-b77e-452a-a2c0-eca0cc8d514a,54f200)/Sata(1,65535,0)N.YMR,Y.
> > Boot0003* UEFI eMMC Device
> > VenHw(0d51905b-b77e-452a-a2c0-eca0cc8d514a,6ef000)/eMMC(0)/Ctrl(0x0)N.YMR,Y.
> > Boot0004* UEFI eMMC Device 2
> > VenHw(0d51905b-b77e-452a-a2c0-eca0cc8d514a,6ef000)/eMMC(0)/Ctrl(0x1)N.YMR,Y.
> > Boot0005* UEFI eMMC Device 3
> > VenHw(0d51905b-b77e-452a-a2c0-eca0cc8d514a,6ef000)/eMMC(0)/Ctrl(0x2)N.YMR,Y.
> > Boot0006* UEFI PXEv4 (MAC:0001)
> > MAC(0001,1)/IPv4(0.0.0.00.0.0.0,0,0)N.YMR,Y.
> > Boot0007* UEFI PXEv4 (MAC:0002)
> > MAC(0002,1)/IPv4(0.0.0.00.0.0.0,0,0)N.YMR,Y.
> > Boot0008* UEFI PXEv4 (MAC:0003)
> > MAC(0003,1)/IPv4(0.0.0.00.0.0.0,0,0)N.YMR,Y.
> > Boot0009* UEFI PXEv4 (MAC:0004)
> > MAC(0004,1)/IPv4(0.0.0.00.0.0.0,0,0)N.YMR,Y.
> > Boot000A* UEFI Shell
> > FvVol(5eda4200-2c5f-43cb-9da3-0baf74b1b30c)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
> > Boot000B* UEFI HL-DT-ST DVDRAM GTC0N
> > VenHw(0d51905b-b77e-452a-a2c0-eca0cc8d514a,54f400)/Sata(1,65535,0)N.YMR,Y.
> > Boot000C* ubuntu
> >
Re: [PATCH 00/21] Qualcomm generic board support
> From: Ilias Apalodimas
> Date: Wed, 6 Dec 2023 12:31:15 +0200
>
> Hi Caleb,
>
> Late to the party, but I'll respond to as much as I can
>
> On Tue, 21 Nov 2023 at 19:09, Caleb Connolly
> wrote:
> >
> > Historically, Qualcomm boards in U-Boot have all had their own
> > board/qualcomm/xyz directory, their own CONFIG_TARGET_XYZ option, their
> > own hardcoded sysmap-xyz.c file, and their own U-Boot specific
> > devicetree with little/no compatibility with upstream DT.
> >
> > This series makes a few final prepatory changes, and then replaces
> > almost all of the board specific code with generic alternatives. The end
> > result is that all Qualcomm boards both current and future (with the
> > exception of the db410c and db820c) can be supported by a single U-Boot
> > binary by just providing the correct DT. New boards can be added without
> > introducing any addition mach/ or board/ code or config options.
> >
> > Due to the nature of this change, the patch ("mach-snapdragon:
> > generalise board support") has become pretty big, I tried a few
> > different ways to represent this in git history, but the other methods
> > (e.g. adding a stub "generic" target and removing it again) were more
> > confusing and made for much messier git history. The current patch is
> > mostly atomic, but requires regenerating the config.
> >
> > The QCS404 EVB board had some code to enable the USB VBUS regulator,
> > this is dropped in favour of a adding a new vbus-supply property to the
> > dwc3-generic driver. This will also be used by the dragonboard845c in a
> > future patch. This handles the common case of a board requiring some
> > regulator be enabled for USB host mode.
> >
> > A more detailed description of the changes is below.
> >
> > == Memory map ==
> >
> > The memory map was historically hardcoded into U-Boot, this meant that
> > U-Boot had to be built for a specific variant of a device. This is
> > changed to instead read the memory map from the DT /memory node.
> >
> > Additionally, most boards mapped addresss 0x0 as valid, as a result if a
> > null pointer access happens then it will cause a bus stall (and board
> > hang). This is fixed so that null pointer accesses will now correctly
> > throw an exception.
> >
> > == DT loading ==
> >
> > Previously, boards used the FDT blob embedded into U-Boot (via
> > OF_SEPARATE). However, most Qualcomm boards run U-Boot as a secondary
> > bootloader, so we can instead rely on the first-stage bootloader to
> > populate some useful FDT properties for us (notably the /memory node and
> > KASLR seed)
>
> Note that the kaslr-seed is not so useful when booting with EFI. The
> kernel's EFI-stub ignores that and instead tries to randomize the
> physical placement of the kernel if it finds an EFI_RNG protocol.
OpenBSD will use it though. And other OSes might as well.
> > and fetch the DTB that it provides. Combined with the memory
> > map changes above, this let's us entirely avoid configuring the memory
> > map explicitly.
Re: [PATCH 01/18] bootm: netbds: Drop passing of arguments
> From: Simon Glass
> Date: Sun, 3 Dec 2023 17:26:17 -0700
Hi Simon,
There is a typo in first line of the commit message: s/netbds/netbsd/.
> It isn't clear how useful it is to pass the arguments of bootm to the
> OS. For example, if "bootm 1000 2000 3000" is used, the three arguments
> at the end are passed to the OS. This seems like a strange approach,
> since the argument have already been parsed by U-Boot and processed.
>
> Rely instead on the "bootargs" mechanism, which is the standard
> approach.
It is a very Linuxy approach though.
I suspect this feature was added to pass kernel arguments for
"one-off" boots. For example
bootm -s
could be used to boot NetBSD in single-user mode and is quite a bit
more convenient than:
setenv bootargs -s
bootm
That said, I'm not sure to what extent the bootm command is used to
boot NetBSD these days. So this may not really matter.
Cheers,
Mark
> Signed-off-by: Simon Glass
> ---
>
> boot/bootm_os.c | 16 +++-
> 1 file changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/boot/bootm_os.c b/boot/bootm_os.c
> index b92422171a84..b5055d78706c 100644
> --- a/boot/bootm_os.c
> +++ b/boot/bootm_os.c
> @@ -102,19 +102,9 @@ static int do_bootm_netbsd(int flag, int argc, char
> *const argv[],
> os_hdr = hdr;
> }
>
> - if (argc > 0) {
> - ulong len;
> - int i;
> -
> - for (i = 0, len = 0; i < argc; i += 1)
> - len += strlen(argv[i]) + 1;
> - cmdline = malloc(len);
> - copy_args(cmdline, argc, argv, ' ');
> - } else {
> - cmdline = env_get("bootargs");
> - if (cmdline == NULL)
> - cmdline = "";
> - }
> + cmdline = env_get("bootargs");
> + if (!cmdline)
> + cmdline = "";
>
> loader = (void (*)(struct bd_info *, struct legacy_img_hdr *, char *,
> char *))images->ep;
>
> --
> 2.43.0.rc2.451.g8631bc7472-goog
>
>
Re: [PATCH v2] arm: apple: t602x: Add missing MMIO regions to memmap
> From: Janne Grunau via B4 Relay
> Date: Fri, 01 Dec 2023 08:12:33 +0100
>
> From: Janne Grunau
>
> The memory maps for Apple's M2 Pro/Max/Ultra left MMIO space out which
> was not used by any driver at the time. The display out exposed as
> simple-framebuffer use a power-domain controlled by a device in an
> unmapped region.
> Add a map covering this region as well as another MMIO region in the
> range 0x4'' - 0x5''. The added regions cover all MMIO
> annotated in Apple's device tree in this range.
>
> Signed-off-by: Janne Grunau
> ---
> Changes in v2:
> - use SZ_1G as block size
> - Link to v1:
> https://lore.kernel.org/r/20231130-apple_t602x_extend_memmap-v1-1-cd96b251d...@jannau.net
> ---
> arch/arm/mach-apple/board.c | 48
> +++++
> 1 file changed, 48 insertions(+)
Reviewed-by: Mark Kettenis
Tom, as this fixes a crash with newer device trees passed by the stage
that runs before U-Boot, it would be good if this could make 2024.01.
Thanks,
Mark
> diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
> index 47393babbc..7a6151a972 100644
> --- a/arch/arm/mach-apple/board.c
> +++ b/arch/arm/mach-apple/board.c
> @@ -370,6 +370,22 @@ static struct mm_region t6020_mem_map[] = {
> .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>PTE_BLOCK_NON_SHARE |
>PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x4,
> + .phys = 0x4,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x48000,
> + .phys = 0x48000,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> }, {
> /* I/O */
> .virt = 0x58000,
> @@ -471,6 +487,22 @@ static struct mm_region t6022_mem_map[] = {
> .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>PTE_BLOCK_NON_SHARE |
>PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x4,
> + .phys = 0x4,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x48000,
> + .phys = 0x48000,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> }, {
> /* I/O */
> .virt = 0x58000,
> @@ -551,6 +583,22 @@ static struct mm_region t6022_mem_map[] = {
> .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>PTE_BLOCK_NON_SHARE |
>PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x24,
> + .phys = 0x24,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x248000,
> + .phys = 0x248000,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> }, {
> /* I/O */
> .virt = 0x258000,
>
> ---
> base-commit: 43f2873fa98b1da6eb56d756315c7bd7db63db27
> change-id: 20231130-apple_t602x_extend_memmap-c82c522ca8c0
>
> Best regards,
> --
> Janne Grunau
>
>
>
Re: [PATCH] arm: apple: t602x: Add missing MMIO regions to memmap
> Date: Thu, 30 Nov 2023 23:04:36 +0100 > From: "Janne Grunau" > > Hej Mark, > > On Thu, Nov 30, 2023, at 21:45, Mark Kettenis wrote: > >> From: Janne Grunau via B4 Relay > >> Date: Thu, 30 Nov 2023 13:42:22 +0100 > >> > >> From: Janne Grunau > >> > >> The memory maps for Apple's M2 Pro/Max/Ultra left MMIO space out which > >> was not used by any driver at the time. The display out exposed as > >> simple-framebuffer use a power-domain controlled by a device in an > >> unmapped region. > >> Add a map covering this region as well as another MMIO region in the > >> range 0x4'' - 0x5''. The added regions cover all MMIO > >> annotated in Apple's device tree in this range. > >> > >> Signed-off-by: Janne Grunau > >> --- > >> arch/arm/mach-apple/board.c | 48 > >> + > >> 1 file changed, 48 insertions(+) > > > > Hi Janne, > > > > Is there a reason why you can't use a SZ_1G mapping for the blocks > > where you're using a SZ_512M mapping? With SZ_1G the mapping code > > will use a 1G block descriptor which avoids another level of page > > tables. > > no reason except that SZ_512M was sufficient to cover all devices in > Apple DT. Shall I resend the patch? Yes please!
Re: [PATCH] arm: apple: t602x: Add missing MMIO regions to memmap
> From: Janne Grunau via B4 Relay
> Date: Thu, 30 Nov 2023 13:42:22 +0100
>
> From: Janne Grunau
>
> The memory maps for Apple's M2 Pro/Max/Ultra left MMIO space out which
> was not used by any driver at the time. The display out exposed as
> simple-framebuffer use a power-domain controlled by a device in an
> unmapped region.
> Add a map covering this region as well as another MMIO region in the
> range 0x4'' - 0x5''. The added regions cover all MMIO
> annotated in Apple's device tree in this range.
>
> Signed-off-by: Janne Grunau
> ---
> arch/arm/mach-apple/board.c | 48
> +
> 1 file changed, 48 insertions(+)
Hi Janne,
Is there a reason why you can't use a SZ_1G mapping for the blocks
where you're using a SZ_512M mapping? With SZ_1G the mapping code
will use a 1G block descriptor which avoids another level of page
tables.
> diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
> index 47393babbc..e05ec431bc 100644
> --- a/arch/arm/mach-apple/board.c
> +++ b/arch/arm/mach-apple/board.c
> @@ -370,6 +370,22 @@ static struct mm_region t6020_mem_map[] = {
> .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>PTE_BLOCK_NON_SHARE |
>PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x4,
> + .phys = 0x4,
> + .size = SZ_512M,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x48000,
> + .phys = 0x48000,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> }, {
> /* I/O */
> .virt = 0x58000,
> @@ -471,6 +487,22 @@ static struct mm_region t6022_mem_map[] = {
> .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>PTE_BLOCK_NON_SHARE |
>PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x4,
> + .phys = 0x4,
> + .size = SZ_512M,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x48000,
> + .phys = 0x48000,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> }, {
> /* I/O */
> .virt = 0x58000,
> @@ -551,6 +583,22 @@ static struct mm_region t6022_mem_map[] = {
> .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>PTE_BLOCK_NON_SHARE |
>PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x24,
> + .phys = 0x24,
> + .size = SZ_512M,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x248000,
> + .phys = 0x248000,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> }, {
> /* I/O */
> .virt = 0x258000,
>
> ---
> base-commit: 43f2873fa98b1da6eb56d756315c7bd7db63db27
> change-id: 20231130-apple_t602x_extend_memmap-c82c522ca8c0
>
> Best regards,
> --
> Janne Grunau
>
>
Re: [PATCH 1/1] usb: USB_XHCI_PCI depends on PCI
> From: Heinrich Schuchardt > Date: Mon, 20 Nov 2023 15:56:36 +0100 > > Compiling with CONFIG_USB_XHCI_PCI and CONFIG_PCI=n results in > > usb/host/xhci-pci.c:48:(.text.xhci_pci_probe+0x44): > undefined reference to `dm_pci_write_config32 > > Add the missing Kconfig dependency. > > Signed-off-by: Heinrich Schuchardt Reviewed-by: Mark Kettenis > --- > drivers/usb/host/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig > index b501ea514b..35610ffc2b 100644 > --- a/drivers/usb/host/Kconfig > +++ b/drivers/usb/host/Kconfig > @@ -90,7 +90,7 @@ config USB_XHCI_OMAP > > config USB_XHCI_PCI > bool "Support for PCI-based xHCI USB controller" > - depends on DM_USB > + depends on DM_USB && PCI > default y if X86 > help > Enables support for the PCI-based xHCI controller. > -- > 2.40.1 > >
Re: bootstd: Support for distro specific EFI folders
> Date: Sat, 18 Nov 2023 23:52:11 +0100 > From: Heinrich Schuchardt Hi Heinrich, > On 11/18/23 22:28, Shantur Rathore wrote: > > Hi Heinrich, > > > > On Fri, Nov 17, 2023 at 3:12 PM Heinrich Schuchardt > > wrote: > >> > >> On 11/16/23 19:45, Shantur Rathore wrote: > >>> On Thu, Nov 16, 2023 at 6:15 PM Heinrich Schuchardt > >>> wrote: > > On 11/16/23 17:52, Shantur Rathore wrote: > > Hi Simon, > > > > Currently bootstd - bootmethod_efi only looks for the default > > bootxx64.efi in /EFI/boot folder only. > > Generally many distros end up putting their bootloaders in > > EFI/ folders like EFI/ubuntu and EFI/debian etc. > > > > In x86 worlds, the NVRAM is modified and new boot entries are added to > > support these but in the U-boot world the NVRAM variables are > > read-only. > > I guess you are referring to UEFI boot options. These typically are not > stored in non-volatile RAM but on a SPI flash device. > > >>> > >>> Thanks for correcting me. > >>> > > > > What would be the best way to implement this? > > > > I was thinking of having a "efi_prefixes" environment variable which > > can be set to "ubuntu debian centos" etc and bootmethod_efi can try > > all of them. Will bootmethod_efi be able to support multiple entries ( > > thinking of multiboot ) ? > > On my laptop I have: > > EFI/Microsoft/Boot/bootmgr.efi > EFI/Microsoft/Boot/memtest.efi > EFI/Boot/bootx64.efi > EFI/Boot/fbx64.efi > EFI/Boot/mmx64.efi > EFI/debian/shimx64.efi > EFI/debian/grubx64.efi > EFI/debian/mmx64.efi > EFI/debian/fbx64.efi > EFI/ubuntu/grubx64.efi > EFI/ubuntu/shimx64.efi > EFI/ubuntu/mmx64.efi > > Obviously each installed operating system provides multiple EFI binaries > and non uses the fallback file name BOOT.EFI. A value "ubuntu > debian centos" would not be able to describe which file you are looking > for. > > We already have the U-Boot command line eficonfig and efidebug commands > to set up UEFI boot options which can describe which EFI binary to load > and which command line to pass to it. These are considered by the > existing boot flows. > >>> > >>> So, I am building a new RockPro64 based cluster and using Canonical > >>> MAAS to set them up automatically, booting them up using DHCP and > >>> installing them over the network. > >>> I configured an Armbian image using Packer to be compatible with MAAS > >>> and it happily installs it. As part of installation process, a > >>> grub-install is run which installs the grub efi, > >>> this EFI ends up in EFI/debian instead of expected EFI/boot. > >>> To be able to make it boot, I have to add commands to move it to > >>> EFI/boot. I am trying to find a way in U-Boot that would allow me to > >>> skip this step. > >>> With eficonfig if I understand correctly, it would need manual > >>> intervention to create boot entries. > >>> > > If you are installing the shim-signed package on Ubuntu, the EFI boot > option for Ubuntu is set up by EFI/BOOT/BOOT.EFI using the content > of EFI/ubuntu/BOOT.CSV. This is done before ExitBootServices() and > therefore should work with current U-Boot. > > Patches are pending upstream to make EFI variables writable from Linux > if they are stored in the RPMB partition in the eMMC. See this series: > > https://lore.kernel.org/linux-efi/20231107054057.1893-2-masahisa.koj...@linaro.org/ > > >>> > >>> Would it be possible to save it in SPI Flash as the U-Boot environment ? > >> > >> Currently this is not supported by U-Boot. > >> > >> The U-Boot environment variables can be stored in lots of different > >> places SPI flash is only one of these. But none of these locations is > >> protected from OS access which would be preferable for UEFI variables > >> for security reasons. > >> > >> To support boards without eMMC the right way forward would be writing a > >> new implementation of the OP-TEE standalone MM which writes the > >> variables to SPI flash instead of the RPMB partition and ensures that > >> the SPI flash' MMIO registers are protected against access from the > >> non-secure world. > > > > Thanks for explaining this to me. > > This seems like a long way to go, for now what would be an acceptable > > solution, some options are > > > > 1. Allow to set a space separated efi_prefixes (e.g. "boot ubuntu > > debian") variable which is ready by bootmeth_efi and used as > > efi/ instead of efi/boot. > > 2. Improve bootmeth_efi to find all boot.efi in efi/ folder and > > present all them as bootflows to bootstd. > > As mentioned in a prior mail ubuntu/boot.efi and debian/boot.efi > don't exist. I would prefer not to add any distro specific stuff in > upstream U-Boot. Instead we will continue to drive what Linaro has > suggested to improve U-Boot EFI
Re: [PATCH 1/1] risc-v: qemu: imply NVME_PCI
> From: Heinrich Schuchardt
> Date: Thu, 16 Nov 2023 11:22:51 +0100
>
> CONFIG_NVME=y without CONFIG_NVME_PCI=y does not provide working NVMe
> support. Instead of implying CONFIG_NVME we must imply CONFIG_NVME_PCI
> which will select CONFIG_NVME.
>
> Fixes: e64db0d92e32 ("riscv: qemu: Enable e1000 and nvme support")
> Signed-off-by: Heinrich Schuchardt
> ---
> board/emulation/qemu-riscv/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed by: Mark Kettenis
> diff --git a/board/emulation/qemu-riscv/Kconfig
> b/board/emulation/qemu-riscv/Kconfig
> index 933b035991..32511b4e4e 100644
> --- a/board/emulation/qemu-riscv/Kconfig
> +++ b/board/emulation/qemu-riscv/Kconfig
> @@ -56,8 +56,8 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> imply SCSI_AHCI
> imply AHCI_PCI
> imply E1000
> - imply NVME
> imply PCI
> + imply NVME_PCI
> imply PCIE_ECAM_GENERIC
> imply DM_RNG
> imply SCSI
> --
> 2.40.1
>
>
Re: [PATCH v4 09/12] x86: Enable SSE in 64-bit mode
> From: Simon Glass
> Date: Tue, 14 Nov 2023 17:48:25 -0700
>
> Hi,
>
> On Tue, 14 Nov 2023 at 17:44, Bin Meng wrote:
> >
> > Hi Tom,
> >
> > On Wed, Nov 15, 2023 at 12:22 AM Tom Rini wrote:
> > >
> > > On Tue, Nov 14, 2023 at 09:49:08AM +0800, Bin Meng wrote:
> > > > Hi Tom,
> > > >
> > > > On Tue, Nov 14, 2023 at 7:52 AM Tom Rini wrote:
> > > > >
> > > > > On Tue, Nov 14, 2023 at 07:46:36AM +0800, Bin Meng wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Tue, Nov 14, 2023 at 6:59 AM Tom Rini wrote:
> > > > > > >
> > > > > > > On Mon, Nov 13, 2023 at 03:28:13PM -0700, Simon Glass wrote:
> > > > > > > > Hi Bin,
> > > > > > > >
> > > > > > > > On Mon, 13 Nov 2023 at 15:08, Bin Meng
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi Simon,
> > > > > > > > >
> > > > > > > > > On Mon, Nov 13, 2023 at 4:03 AM Simon Glass
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > This is needed to support Truetype fonts. In any case, the
> > > > > > > > > > compiler
> > > > > > > > > > expects SSE to be available in 64-bit mode. Provide an
> > > > > > > > > > option to enable
> > > > > > > > > > SSE so that hardware floating-point arithmetic works.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Simon Glass
> > > > > > > > > > Suggested-by: Bin Meng
> > > > > > > > > > ---
> > > > > > > > > >
> > > > > > > > > > Changes in v4:
> > > > > > > > > > - Use a Kconfig option
> > > > > > > > > >
> > > > > > > > > > arch/x86/Kconfig | 8
> > > > > > > > > > arch/x86/config.mk| 4
> > > > > > > > > > arch/x86/cpu/x86_64/cpu.c | 12
> > > > > > > > > > drivers/video/Kconfig | 1 +
> > > > > > > > > > 4 files changed, 25 insertions(+)
> > > > > > > > > >
> > > > > > > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > > > > > > > > > index 99e59d94c606..6b532d712ee8 100644
> > > > > > > > > > --- a/arch/x86/Kconfig
> > > > > > > > > > +++ b/arch/x86/Kconfig
> > > > > > > > > > @@ -723,6 +723,14 @@ config ROM_TABLE_SIZE
> > > > > > > > > > hex
> > > > > > > > > > default 0x1
> > > > > > > > > >
> > > > > > > > > > +config X86_HARDFP
> > > > > > > > > > + bool "Support hardware floating point"
> > > > > > > > > > + help
> > > > > > > > > > + U-Boot generally does not make use of floating
> > > > > > > > > > point. Where this is
> > > > > > > > > > + needed, it can be enabled using this option. This
> > > > > > > > > > adjusts the
> > > > > > > > > > + start-up code for 64-bit mode and changes the
> > > > > > > > > > compiler options for
> > > > > > > > > > + 64-bit to enable SSE.
> > > > > > > > >
> > > > > > > > > As discussed in another thread, this option should be made
> > > > > > > > > global to
> > > > > > > > > all architectures and by default no.
> > > > > > > > >
> > > > > > > > > > +
> > > > > > > > > > config HAVE_ITSS
> > > > > > > > > > bool "Enable ITSS"
> > > > > > > > > > help
> > > > > > > > > > diff --git a/arch/x86/config.mk b/arch/x86/config.mk
> > > > > > > > > > index 26ec1af2f0b0..2e3a7119e798 100644
> > > > > > > > > > --- a/arch/x86/config.mk
> > > > > > > > > > +++ b/arch/x86/config.mk
> > > > > > > > > > @@ -27,9 +27,13 @@ ifeq ($(IS_32BIT),y)
> > > > > > > > > > PLATFORM_CPPFLAGS += -march=i386 -m32
> > > > > > > > > > else
> > > > > > > > > > PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic)
> > > > > > > > > > -fno-common -march=core2 -m64
> > > > > > > > > > +
> > > > > > > > > > +ifndef CONFIG_X86_HARDFP
> > > > > > > > > > PLATFORM_CPPFLAGS += -mno-mmx -mno-sse
> > > > > > > > > > endif
> > > > > > > > > >
> > > > > > > > > > +endif # IS_32BIT
> > > > > > > > > > +
> > > > > > > > > > PLATFORM_RELFLAGS += -fdata-sections -ffunction-sections
> > > > > > > > > > -fvisibility=hidden
> > > > > > > > > >
> > > > > > > > > > KBUILD_LDFLAGS += -Bsymbolic -Bsymbolic-functions
> > > > > > > > > > diff --git a/arch/x86/cpu/x86_64/cpu.c
> > > > > > > > > > b/arch/x86/cpu/x86_64/cpu.c
> > > > > > > > > > index 2647bff891f8..5ea746ecce4d 100644
> > > > > > > > > > --- a/arch/x86/cpu/x86_64/cpu.c
> > > > > > > > > > +++ b/arch/x86/cpu/x86_64/cpu.c
> > > > > > > > > > @@ -10,6 +10,7 @@
> > > > > > > > > > #include
> > > > > > > > > > #include
> > > > > > > > > > #include
> > > > > > > > > > +#include
> > > > > > > > > >
> > > > > > > > > > DECLARE_GLOBAL_DATA_PTR;
> > > > > > > > > >
> > > > > > > > > > @@ -39,11 +40,22 @@ int x86_mp_init(void)
> > > > > > > > > > return 0;
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > +/* enable SSE features for hardware floating point */
> > > > > > > > > > +static void setup_sse_features(void)
> > > > > > > > > > +{
> > > > > > > > > > + asm ("mov %%cr4, %%rax\n" \
> > > > > > > > > > + "or %0, %%rax\n" \
> > > > > > > > > > + "mov %%rax, %%cr4\n" \
> > > > > > > > > > + : : "i" (X86_CR4_OSFXSR |
Re: [PATCH v2 1/1] efi_loader: expose the device-tree file name
> From: Simon Glass > Date: Fri, 3 Nov 2023 13:17:18 -0600 > > Hi, > > On Mon, 23 Oct 2023 at 11:06, Mark Kettenis wrote: > > > > > Date: Mon, 23 Oct 2023 12:34:55 -0400 > > > From: Tom Rini > > > > > > On Mon, Oct 23, 2023 at 05:37:34PM +0200, Mark Kettenis wrote: > > > > > From: Simon Glass > > > > > Date: Mon, 23 Oct 2023 00:08:40 -0700 > > > > > > > > > > > > fdt_node_check_compatible() does most of the work...then you need > > > > > > > to > > > > > > > check which FDT has the most specific match (i.e. latest in the > > > > > > > string > > > > > > > list). That handles things like board revisions, variants, etc. > > > > > > > > > > > > > > My concern is about adding a feature when there is already a > > > > > > > defined > > > > > > > spec and mechanism for this to work. What happens when we load the > > > > > > > file and the compatible is wrong? > > > > > > > > > > > > > > At best, I see the filename as a hint. > > > > > > > > > > > > > > [Perhaps this is the wrong time to ask, but why are kernels +DT > > > > > > > not > > > > > > > shipped in FIT on ARM?] > > > > > > > > > > > > FIT is U-Boot specific. For Linux distributions it is easier to use > > > > > > a > > > > > > firmware agnostic method of booting. > > > > > > > > > > I'd like to suggest that distros use both. Then U-Boot can work as it > > > > > was designed and we can avoid these work-arounds. > > > > > > > > > > FIT is actually implemented in various other bootloaders. In fact > > > > > perhaps grub is the only one that doesn't? I can't think of any > > > > > others. > > > > > > > > Simon, please stop pushing this. OpenBSD's bootloader does not > > > > support FIT and we have no interest in supporting it. Our users > > > > expect to be able to just copy a new kernel in place and use it and > > > > our OS upgrade procedure depends on this as well. And this is > > > > incompatble with FIT. I've explained this about a dozen times to you > > > > now. > > > > > > In the context of this thread, genuinely, how will OpenBSD (and the rest > > > of the BSD families) operate? I agree U-Boot doesn't want to have to > > > know all of the UFSes, so that means the SCT will be populated either by > > > the DT passed to U-Boot, or the DT we were built with. Is it that since > > > the next stage is an EFI app, it will check that variable and use that > > > hint? > > > > Yes, that is exactly what I want to do. Hopefully the DT that is > > passed to U-Boot or that U-Boot was built with will be good enough in > > most cases. But when it isn't users can use the OpenBSD bootloader > > (which is an EFI app) to load an updated DT. > > > > I can't speak for the other BSDs, but I think both FreeBSD and NetBSD > > have a very similar boot mechanism. > > I've been thinking about this patch a bit more, and I have grave misgivings. > > I predict that if we take this, it will become an ABI from U-Boot and > we will not be able to drop it. Why would we want to drop it? > Here is what I suggest instead: provide a protocol for U-Boot to > provide the DT over EFI. Provide any information needed by U-Boot, > such as the directory containing the files. So you want something more complicated than a simple EFI variable? Why? > We already have the ability to put a DT in the system table. We > already have a way to package DT into a FIT and allow U-Boot to select > the correct one. Please stop pushing FIT for use cases where it doesn't make sense. > With something like this it will be impossible for U-Boot to boot a > distro without using grub, etc. since it won't know what DT to use. > This information would be held in a script somewhere which no one can > figure out without executing it. Huh? U-Boot already knows the name of name of the DT filename. It is what we currently use in the distroboot scripts. You are free to use a U-Boot specific bootflow based on that if you really want to. But many distros (or other OSes like OpenBSD) really don't want to maintain support for multiple boot flows.
Re: [PATCH v4 1/1] efi_loader: expose the device-tree file name
> Date: Wed, 25 Oct 2023 21:57:44 +0200
> From: Heinrich Schuchardt
>
> On 10/25/23 20:23, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Tue, 24 Oct 2023 at 18:02, Simon Glass wrote:
> >>
> >> Hi Heinrich,
> >>
> >> On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
> >> wrote:
> >>>
> >>> Forward and backward compatibility of Linux kernel device-trees is
> >>> sometimes missing. One solution approach is to load a kernel specific
> >>> device-tree. This can either be done via a U-Boot scripts (like the one
> >>> generated by Debian package flash-kernel or by a boot loader like GRUB.
> >>> The boot loader approach currently requires to know the device-tree name
> >>> before first boot which makes it unusable for generic images.
> >>>
> >>> Expose the device-tree file name as EFI variable FdtFile.
> >>> This will allow bootloaders to load a kernel specific device-tree.
> >>
> >> kernel-specific
> >>
> >>>
> >>> The variable will not be exposed on ACPI based systems or if the
> >>> environment variable fdtfile is not defined.
> >>>
> >>> Signed-off-by: Heinrich Schuchardt
> >>> ---
> >>> v4:
> >>> Generalize the description of the content of $fdtfile.
> >>> v3:
> >>> Add documentation
> >>> v2:
> >>> Use a unique GUID to enable future U-Boot independent
> >>> standardization.
> >>> Do not try to add the variable on ACPI based systems.
> >>> ---
> >>> doc/develop/uefi/uefi.rst | 14 ++
> >>> include/efi_loader.h | 5 +
> >>> lib/efi_loader/efi_setup.c | 30 ++
> >>> 3 files changed, 49 insertions(+)
> >>>
> >>> diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
> >>> index fb16ac743a..702c490831 100644
> >>> --- a/doc/develop/uefi/uefi.rst
> >>> +++ b/doc/develop/uefi/uefi.rst
> >>> @@ -916,6 +916,20 @@ So our final format of the FilePathList[] is::
> >>>
> >>> Loaded image - end node (0xff) - VenMedia - initrd_1 - [end node
> >>> (0x01) - initrd_n ...] - end node (0xff)
> >>>
> >>> +EFI variable FdtFile
> >>> +
> >>> +
> >>> +Ideally U-Boot would always expose a device-tree that can be used for
> >>> booting
> >>> +any operating systems. Unfortunately operating systems like Linux
> >>> sometimes
> >>> +break forward and backward compatibility. In this case there is a need
> >>> to load
> >>> +an operating system version specific device-tree.
> >>
> >> This seems to be a strong statement. Given the effort that goes into
> >> the DT, changes are supposed to be backwards-compatible. Is this
> >> generally true, or is it just that we want an up-to-date DT for the
> >> kernel to enable new features?
> >
> > Did you see this comment?
>
> It would have been nice to put the person which made that comment on copy.
>
> The truth lies in the world "supposed":
>
> The idea of a device-tree that never needs to change is quite old and
> never became true on ARM devices.
>
> We all know Linux tends to break both forward and backward compatibility
> of device-trees. Here is a nice example:
>
> d0c6707ca423 ("arm64: dts: allwinner: H5: NanoPi Neo Plus2: phy-mode
> rgmii-id")
>
> Driver changes broke forward and backwards compatibility of a lot of
> Allwinner boards.
Well, that happened in 2020. Things have gotten better over time.
> Distros will continue to load the device-tree that matches the kernel to
> get the best possible board support and need to do this efficiently.
Right. Even if there is full backward/forward compatibility, you
probably want the latest device-tree to make sure you get the most
complete hardware support.
But this shouldn't be used as an argument to not care about
backward/forward compatibility.
Re: [PATCH] smbios: arm64: Allow table to be written at a fixed addr
> Date: Tue, 24 Oct 2023 18:34:05 -0400 > From: Tom Rini > > On Mon, Oct 23, 2023 at 05:31:19PM +0200, Mark Kettenis wrote: > > > From: Simon Glass > > > Date: Mon, 23 Oct 2023 00:04:14 -0700 > > > > > > Hi Caleb, > > > > > > On Sat, 21 Oct 2023 at 01:43, Caleb Connolly > > > wrote: > > > > > > > > Hi Simon, > > > > > > > > On 21/10/2023 01:45, Simon Glass wrote: > > > > > U-Boot typically sets up its malloc() pool near the top of memory. On > > > > > ARM64 systems this can result in an SMBIOS table above 4GB which is > > > > > not supported by SMBIOSv2. > [snip] > > There is absolutely no guarantee that arm64 machines have memory below > > 4GB. Examples of SoCs that have no memory below 4GB are AMD's Opteron > > A1100 SoC and all the recent Apple SoCs. > > So one thing to resolve here is where does that requirement about the > SMBIOS table needing to be below 4GB come from (standards wise), and in > turn is that obeyed by consumers like say Linux or OpenBSD? Answering my > own question, maybe in part, https://www.dmtf.org/standards/smbios reads > to me like there's a v3 and maybe we should be doing what we need to > support / identify as that, if it doesn't have that restriction? Right. U-Boot implements SMBIOS 2.x which is pretty much obsolete and uses 32-bit addresses. SMBIOS 3.x allows for 64-bit addresses. So to fix this U-Boot needs support for SMBIOS 3.x. Personally I don't see why we'd need SMBIOS support on non-x86 platforms, which is why implementing this isn't a high priority for me. I simply disabled SMBIOS support for M1 for now.
Re: [PATCH] arm: init: add an option to use FDT from previous bootloader
> From: Simon Glass > Date: Tue, 24 Oct 2023 12:34:39 -0700 > > > This mechanism of retrieving the DTB is also used on the apple M1 I > > think, and any other board where we're booting U-Boot as a drop-in for > > the kernel on arm64. > > I believe M1 is an open source project so perhaps they could adopt > firmware handoff when it is finalised. Hi Simon, I'll repeat what I've said before; handoff for M1 is deliberately 100% compatible with handoff to the Linux kernel such that it is possible to bypass U-Boot and directly boot a Linux kernel. This is a feature the Asahi Linux developers depend on. If you want us to make changes here, you need to convince the Linux kernel developers to adjust Documentation/arch/arm64/bootig.rst to allow for the firmware handoff convention.
Re: [PATCH v2 1/1] efi_loader: expose the device-tree file name
> Date: Mon, 23 Oct 2023 12:34:55 -0400 > From: Tom Rini > > On Mon, Oct 23, 2023 at 05:37:34PM +0200, Mark Kettenis wrote: > > > From: Simon Glass > > > Date: Mon, 23 Oct 2023 00:08:40 -0700 > > > > > > > > fdt_node_check_compatible() does most of the work...then you need to > > > > > check which FDT has the most specific match (i.e. latest in the string > > > > > list). That handles things like board revisions, variants, etc. > > > > > > > > > > My concern is about adding a feature when there is already a defined > > > > > spec and mechanism for this to work. What happens when we load the > > > > > file and the compatible is wrong? > > > > > > > > > > At best, I see the filename as a hint. > > > > > > > > > > [Perhaps this is the wrong time to ask, but why are kernels +DT not > > > > > shipped in FIT on ARM?] > > > > > > > > FIT is U-Boot specific. For Linux distributions it is easier to use a > > > > firmware agnostic method of booting. > > > > > > I'd like to suggest that distros use both. Then U-Boot can work as it > > > was designed and we can avoid these work-arounds. > > > > > > FIT is actually implemented in various other bootloaders. In fact > > > perhaps grub is the only one that doesn't? I can't think of any > > > others. > > > > Simon, please stop pushing this. OpenBSD's bootloader does not > > support FIT and we have no interest in supporting it. Our users > > expect to be able to just copy a new kernel in place and use it and > > our OS upgrade procedure depends on this as well. And this is > > incompatble with FIT. I've explained this about a dozen times to you > > now. > > In the context of this thread, genuinely, how will OpenBSD (and the rest > of the BSD families) operate? I agree U-Boot doesn't want to have to > know all of the UFSes, so that means the SCT will be populated either by > the DT passed to U-Boot, or the DT we were built with. Is it that since > the next stage is an EFI app, it will check that variable and use that > hint? Yes, that is exactly what I want to do. Hopefully the DT that is passed to U-Boot or that U-Boot was built with will be good enough in most cases. But when it isn't users can use the OpenBSD bootloader (which is an EFI app) to load an updated DT. I can't speak for the other BSDs, but I think both FreeBSD and NetBSD have a very similar boot mechanism. Cheers, Mark
Re: [PATCH v2 1/1] efi_loader: expose the device-tree file name
> From: Simon Glass > Date: Mon, 23 Oct 2023 00:08:40 -0700 > > > > fdt_node_check_compatible() does most of the work...then you need to > > > check which FDT has the most specific match (i.e. latest in the string > > > list). That handles things like board revisions, variants, etc. > > > > > > My concern is about adding a feature when there is already a defined > > > spec and mechanism for this to work. What happens when we load the > > > file and the compatible is wrong? > > > > > > At best, I see the filename as a hint. > > > > > > [Perhaps this is the wrong time to ask, but why are kernels +DT not > > > shipped in FIT on ARM?] > > > > FIT is U-Boot specific. For Linux distributions it is easier to use a > > firmware agnostic method of booting. > > I'd like to suggest that distros use both. Then U-Boot can work as it > was designed and we can avoid these work-arounds. > > FIT is actually implemented in various other bootloaders. In fact > perhaps grub is the only one that doesn't? I can't think of any > others. Simon, please stop pushing this. OpenBSD's bootloader does not support FIT and we have no interest in supporting it. Our users expect to be able to just copy a new kernel in place and use it and our OS upgrade procedure depends on this as well. And this is incompatble with FIT. I've explained this about a dozen times to you now.
Re: [PATCH] smbios: arm64: Allow table to be written at a fixed addr
> From: Simon Glass > Date: Mon, 23 Oct 2023 00:04:14 -0700 > > Hi Caleb, > > On Sat, 21 Oct 2023 at 01:43, Caleb Connolly > wrote: > > > > Hi Simon, > > > > On 21/10/2023 01:45, Simon Glass wrote: > > > U-Boot typically sets up its malloc() pool near the top of memory. On > > > ARM64 systems this can result in an SMBIOS table above 4GB which is > > > not supported by SMBIOSv2. > > > > > > Work around this problem by providing a new option to choose an address > > > just below 4GB, if needed. > > I may well be missing something here, but I don't quite understand the > > justification behind the original patch [1] which caused this regression. > > > > I'm currently preparing support for a few different Qualcomm boards > > which have different memory layouts, so far it's been possible to avoid > > having any fixed addresses, so the same u-boot image can be used on all > > of them (with just a different DTB). > > What sort of memory layout do you have? I could enhance the patch to > find the top of a memory bank below 4GB, perhaps? E.g. see the > 'bdinfo' command. > > > > > As I mentioned before, efi_allocate_pages() seems to work fine from > > install_smbios_table(), I haven't delved into the code too much but I > > wonder if this could be an acceptable solution? > > Unfortunately that function is EFI-specific. The function can only be > called once EFI is inited. We only want to do that if booting with > EFI. > > The tables are written at the start of U-Boot, partly because that is > how it is done on x86 and partly so the 'acpi' command actually works. > > The EFI code ended up writing a separate set of tables, which is of > course not correct. > > I did look at creating an API in U-Boot to alloc memory below 4GB but > then decided that for just this one use case it might not be worth it. > > > > > Barring that, could we use an environment variable to pass this address > > in? Although I think that might not be a very desirable solution. > > > > I appreciate you taking the time to prepare this patch and CC me. If > > nobody else objects to this patch then I'd prefer to avoid blocking it. > > In either case, I'd greatly appreciate any input on the above > > suggestions so that I can implement a solution for my boards. > > I would like it to be automatic. I assumed on ARM64 that there is > memory available at 3.99GB if U-Boot has relocated to above 4GB, but > as above I could make this more clever. There is absolutely no guarantee that arm64 machines have memory below 4GB. Examples of SoCs that have no memory below 4GB are AMD's Opteron A1100 SoC and all the recent Apple SoCs. Cheers, Mark
Re: [PATCH v2 1/1] efi_loader: expose the device-tree file name
> From: Simon Glass > Date: Thu, 19 Oct 2023 07:55:49 -0600 > > Hi Heinrich, > > On Wed, 18 Oct 2023 at 02:15, Heinrich Schuchardt > wrote: > > > > On 10/18/23 05:33, Simon Glass wrote: > > > Hi Heinrich, > > > > > > On Tue, 17 Oct 2023 at 07:50, Heinrich Schuchardt > > > wrote: > > >> > > >> Forward and backward compatibility of Linux kernel device-trees is > > >> sometimes missing. One solution approach is to load a kernel specific > > >> device-tree. This can either be done via a U-Boot scripts (like the one > > >> generated by Debian package flash-kernel or by a boot loader like GRUB. > > >> The boot loader approach currently requires to know the device-tree name > > >> before first boot which makes it unusable for generic images. > > >> > > >> Expose the device-tree file name as EFI variable FdtFile. > > >> This will allow bootloaders to load a kernel specific device-tree. > > >> > > >> The variable will not be exposed on ACPI based systems or if the > > >> environment variable fdtfile is not defined. > > >> > > >> Signed-off-by: Heinrich Schuchardt > > >> --- > > >> v2: > > >> Use a unique GUID to enable future U-Boot independent > > >> standardization. > > >> Do not try to add the variable on ACPI based systems. > > >> --- > > >> include/efi_loader.h | 5 + > > >> lib/efi_loader/efi_setup.c | 30 ++ > > >> 2 files changed, 35 insertions(+) > > > > > > I was too slow to reply to v1. > > > > > > Does grub load the DT? I was assuming that U-Boot would pass it on? > > > What is the interface between U-Boot and grub? > > > > The device-tree built into U-Boot is often out of date and not usable to > > boot current Linux. A single device-tree can be loaded by U-Boot from > > file and passed on as EFI configuration table. This device-tree may not > > be compatible with all kernel versions exposed by GRUB. > > > > GRUB provides a devicetree command. It is disabled if you use secure > > boot. At least in Debian and Ubuntu GRUB invokes the > > EFI_DT_FIXUP_PROTOCOL exposed by U-Boot to run U-Boot's device-tree > > fix-ups after loading a device-tree. > > > > Vendor scripts for GRUB like Ubuntu's /etc/grub.d/10_linux add > > devicetree commands to the boot options in grub.cfg. > > Thanks. I wonder if you could document this somewhere? It seems like > there are a lot of options and it is quite complicated. > > Back to the question, I suppose you are expecting grub to load the DT > using this filename? But why doesn't U-Boot load it instead? It seems > very convoluted. >From an OpenBSD perspective: * It allows us to load directly from an OpenBSD filesystem. (And yes I really think you don't want to add support for all the different flavours of the UFS/FFS filesystem to U-Boot). * It means we don't have to worry about breaking other OS installs on the same disk since we can avoid copying the device tree onto the (shared) EFI System Partition. * It means that we can provide a uniform user interface that is independent on the UEFI implementation; the user doesn't need to care whether they are dealing with U-Boot, EDK2 or some other proprietary UEFI implementation. Cheers, Mark
Re: [PATCH] efi_loader: fix efi_bootmgr_enumerate_boot_option
> From: Heinrich Schuchardt
> Date: Tue, 17 Oct 2023 19:51:48 +0200
>
> Only auto-generate boot options for removable media.
>
> For testing the different handling of removable and non-removable devices
> an emulated USB device can be used:
>
> make qemu-riscv64_smode_defconfig; make
> qemu-system-riscv64 -M virt -kernel u-boot.bin -nographic \
> -device qemu-xhci -drive if=none,file=disk.img,format=raw,id=USB1 \
> -device usb-storage,drive=USB1,removable=on
Unless I misunderstand what this patch does, this may result in
systems that don't boot after installation.
On most boards U-Boot does not provide a way to create persistent EFI
variables after ExitBootServices() is called. This means that an OS
installer cannot create a boot entry for the OS installation it just
created. Therefore the EFI boot manager will not boot the newly
installed system.
Now as long as the traditional distro boot mechanism or the EFI distro
boot bootmeth is enabled the system will probobly still attempt to
boot the installed system. But do want to rely on that?
> Fixes: c416f1c0bcab ("bootmenu: add removable media entries")
> Fixes: 339b527bd450 ("Move bootorder and bootoption apis to lib")
> Signed-off-by: Heinrich Schuchardt
> ---
> lib/efi_loader/efi_bootmgr.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> index a40762c74c..96d45157b3 100644
> --- a/lib/efi_loader/efi_bootmgr.c
> +++ b/lib/efi_loader/efi_bootmgr.c
> @@ -346,7 +346,7 @@ error:
> }
>
> /**
> - * efi_bootmgr_enumerate_boot_option() - enumerate the possible bootable
> media
> + * efi_bootmgr_enumerate_boot_option() - boot options for removable boot
> media
> *
> * @opt: pointer to the media boot option structure
> * @volume_handles: pointer to the efi handles
> @@ -370,6 +370,9 @@ static efi_status_t
> efi_bootmgr_enumerate_boot_option(struct eficonfig_media_boo
> struct efi_device_path *device_path;
> struct efi_device_path *short_dp;
>
> + if (!efi_disk_is_removable(volume_handles[i]))
> + continue;
> +
> ret = efi_search_protocol(volume_handles[i],
> _guid_device_path, );
> if (ret != EFI_SUCCESS)
> continue;
> @@ -674,7 +677,10 @@ efi_status_t
> efi_bootmgr_update_media_device_boot_option(void)
> goto out;
> }
>
> - /* enumerate all devices supporting EFI_SIMPLE_FILE_SYSTEM_PROTOCOL */
> + /*
> + * Enumerate all removable devices supporting the
> + * EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.
> + */
> ret = efi_bootmgr_enumerate_boot_option(opt, volume_handles, count);
> if (ret != EFI_SUCCESS)
> goto out;
> --
> 2.40.1
>
>
Re: [PATCH 1/1] efi_loader: expose the device-tree file name
> From: Heinrich Schuchardt
> Date: Tue, 17 Oct 2023 10:55:07 +0200
>
> Forward and backward compatibility of Linux kernel device-trees is
> sometimes missing. One solution approach is to load a kernel specific
> device-tree. This can either be done via a U-Boot scripts (like the one
> generated by Debian package flash-kernel or by a boot loader like GRUB.
> The boot loader approach currently requires to know the device-tree name
> before first boot which makes it unusable for generic images.
Even if the device trees are compatile, we often see that additonal
nodes get added at a later stage. So the ability to load a more
complete device tree for the OS is useful and means a user doesn't
necessarily need to update U-Boot to make additional devices work in
their OS.
> Expose the device-tree file name as EFI variable FdtFile.
> This will allow bootloaders to load a kernel specific device-tree.
Right. I'm considering adding support for loading device trees to the
OpenBSD bootloader and this feature would be really useful since it
would allow me to automagically load the right device tree from the
root filesystem of the OS.
Is my understanding right that this is a null-terminated (8-bit) ASCII
string? Can this variable be documented somewhere, maybe together
with the EFI_DT_FIXUP_PROTOCOL?
> Signed-off-by: Heinrich Schuchardt
> ---
> lib/efi_loader/efi_setup.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
> index e6de685e87..b24feb94dc 100644
> --- a/lib/efi_loader/efi_setup.c
> +++ b/lib/efi_loader/efi_setup.c
> @@ -26,6 +26,27 @@ void __weak allow_unaligned(void)
> {
> }
>
> +/**
> + * efi_init_fdtfile() - set EFI variable FdtFile
> + *
> + * Return: status code
> + */
> +static efi_status_t efi_init_fdtfile(void)
> +{
> + char *val;
> +
> + val = env_get("fdtfile");
> + if (!val)
> + return EFI_SUCCESS;
> +
> + return efi_set_variable_int(u"FdtFile",
> + _u_boot_guid,
> + EFI_VARIABLE_BOOTSERVICE_ACCESS |
> + EFI_VARIABLE_RUNTIME_ACCESS |
> + EFI_VARIABLE_READ_ONLY,
> + strlen(val) + 1, val, false);
> +}
> +
> /**
> * efi_init_platform_lang() - define supported languages
> *
> @@ -250,6 +271,11 @@ efi_status_t efi_init_obj_list(void)
> if (ret != EFI_SUCCESS)
> goto out;
>
> + /* Define EFI variable FdtFile */
> + ret = efi_init_fdtfile();
> + if (ret != EFI_SUCCESS)
> + goto out;
> +
> /* Indicate supported features */
> ret = efi_init_os_indications();
> if (ret != EFI_SUCCESS)
> --
> 2.40.1
>
>
Re: [PATCH] arm: mach-apple: Move M1/M2 specifics into a separate folder
> Date: Wed, 11 Oct 2023 07:42:39 +0300
> From: Ivaylo Ivanov
>
> S5L8950X is definitely belongs to the mach-apple folder, since it's the
> first truly apple-made SoC: it uses AIC, DART, Apple GPIO, etc etc. I
> might be wrong but I haven't seen any references of RTKit on S5L8950X.
Yes your device tree has:
compatible = "samsung,s5l8950", "samsung,s5l89xx";
I do understand that it is hard to tell when Apple hardware changed
from being a Samsung SoC with some Apple hardware blocks into an Apple
SoC with some Samsung hardware blocks. U-Boot typically follows the
precedent set by the Linux kernel. So if you're also planning to
upstream Linux support for these devices, it probably is best to sort
this out with the Linux maintainers first.
The U-Boot support for mach-apple was never intended to be
M1-specific. The goal was always to support a wider range with a
single board.c file as long as that makes sense. That probably
doesn't make sense for 32-bit SoCs like yours. And if there are
significant differences in the way U-Boot is started on iPhone/iPad
platforms we probably need a different set of files and configs as
well.
So my preferred approach would be to park this diff until a later
stage where it is more obvious what the best way to split things up
is.
> I have already have gotten u-boot working with AIC timer and partial
> dwc2 support (plug-in detection works, not sure yet why it doesn't
> expose a USB interface to my PC) on the iPhone 5. It's confirmed to also
> work on the 5c, and with a few changes addresses-wise it also works on
> A5. Here's a rough link to my changes (which are still to-be-improved)
> on my github u-boot repo:
> https://github.com/ivoszbg/u-boot/commit/e20958e142cb881488602b7e864c00073dfe32db
Most of the stuff in your board.c file probably doesn't belong there,
but in separate clock and USB glue drivers.
> In my opinion, M1 support shouldn't have been placed in the mach-apple
> folder like that in the first place. It's disrupting the work for a ton
> of Apple SoCs, as if M1 is the only apple SoC in existence.
>
> On 10/11/23 00:17, Mark Kettenis wrote:
> >> Date: Tue, 29 Aug 2023 22:13:53 +0300
> >> From: Ivaylo Ivanov
> >>
> >> I'm currently working on S5L8950X. I also have some T7000 and T8010
> >> devices that I'll work on in the future.
> >>
> >> There's a project called freemyipod that has a fork of U-Boot working on
> >> iPod Nano's (specifically the S5L8730 in the iPod Nano 5). I've read
> >> that they're planning on upstreaming it in the near future.
> >
> > ok, well, most of the code you're moving isn't really M1/M2 specific.
> > Apple uses RTKit all over the place. And some of the SoCs you mention
> > are really close to M1/M2. And the older ones have a lot of Samsung
> > heritage so I'm not sure they belong under mach-apple ...
> >
> > Also, unless you actually have code to support other Apple SoCs, this
> > just causes disruption for upstreaming more of the M1/M2 code. So I
> > think this is best left alone until you actually show your code and we
> > can see how to integrate it.
> >
> >>
> >> On 8/29/23 20:43, Mark Kettenis wrote:
> >>>> From: ivo.iva...@null.net
> >>>> Date: Tue, 29 Aug 2023 20:25:19 +0300
> >>>>
> >>>> From: Ivaylo Ivanov
> >>>>
> >>>> Currently, mach-apple assumes we're working with M1/M2. Make room for
> >>>> adding support for other Apple SoCs by moving everything from the M1/M2
> >>>> SoC family in "mach-apple/" into "mach-apple/m1/".
> >>>
> >>> Which other Apple SoCs?
> >>>
> >>>> Signed-off-by: Ivaylo Ivanov
> >>>> ---
> >>>> arch/arm/Kconfig | 29 --
> >>>> arch/arm/mach-apple/Kconfig | 42
> >>>> arch/arm/mach-apple/Makefile | 5 +--
> >>>> arch/arm/mach-apple/m1/Makefile | 6 +++
> >>>> arch/arm/mach-apple/{ => m1}/board.c | 0
> >>>> arch/arm/mach-apple/{ => m1}/lowlevel_init.S | 0
> >>>> arch/arm/mach-apple/{ => m1}/rtkit.c | 0
> >>>> arch/arm/mach-apple/{ => m1}/sart.c | 0
> >>>> configs/apple_m1_defconfig | 1 +
> >>>> 9 files changed, 50 insertions(+), 33 deletions(-)
> >>>> create mode 100644 arch/arm/mach-apple/m1/Makefile
> >>>> rename arch/arm/mach-apple/{ => m1}/board.c (100%)
> >>>> rename a
Re: [PATCH] arm: mach-apple: Move M1/M2 specifics into a separate folder
> Date: Tue, 29 Aug 2023 22:13:53 +0300
> From: Ivaylo Ivanov
>
> I'm currently working on S5L8950X. I also have some T7000 and T8010
> devices that I'll work on in the future.
>
> There's a project called freemyipod that has a fork of U-Boot working on
> iPod Nano's (specifically the S5L8730 in the iPod Nano 5). I've read
> that they're planning on upstreaming it in the near future.
ok, well, most of the code you're moving isn't really M1/M2 specific.
Apple uses RTKit all over the place. And some of the SoCs you mention
are really close to M1/M2. And the older ones have a lot of Samsung
heritage so I'm not sure they belong under mach-apple ...
Also, unless you actually have code to support other Apple SoCs, this
just causes disruption for upstreaming more of the M1/M2 code. So I
think this is best left alone until you actually show your code and we
can see how to integrate it.
>
> On 8/29/23 20:43, Mark Kettenis wrote:
> >> From: ivo.iva...@null.net
> >> Date: Tue, 29 Aug 2023 20:25:19 +0300
> >>
> >> From: Ivaylo Ivanov
> >>
> >> Currently, mach-apple assumes we're working with M1/M2. Make room for
> >> adding support for other Apple SoCs by moving everything from the M1/M2
> >> SoC family in "mach-apple/" into "mach-apple/m1/".
> >
> > Which other Apple SoCs?
> >
> >> Signed-off-by: Ivaylo Ivanov
> >> ---
> >> arch/arm/Kconfig | 29 --
> >> arch/arm/mach-apple/Kconfig | 42
> >> arch/arm/mach-apple/Makefile | 5 +--
> >> arch/arm/mach-apple/m1/Makefile | 6 +++
> >> arch/arm/mach-apple/{ => m1}/board.c | 0
> >> arch/arm/mach-apple/{ => m1}/lowlevel_init.S | 0
> >> arch/arm/mach-apple/{ => m1}/rtkit.c | 0
> >> arch/arm/mach-apple/{ => m1}/sart.c | 0
> >> configs/apple_m1_defconfig | 1 +
> >> 9 files changed, 50 insertions(+), 33 deletions(-)
> >> create mode 100644 arch/arm/mach-apple/m1/Makefile
> >> rename arch/arm/mach-apple/{ => m1}/board.c (100%)
> >> rename arch/arm/mach-apple/{ => m1}/lowlevel_init.S (100%)
> >> rename arch/arm/mach-apple/{ => m1}/rtkit.c (100%)
> >> rename arch/arm/mach-apple/{ => m1}/sart.c (100%)
> >>
> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >> index 97c25b4f14..5339da370c 100644
> >> --- a/arch/arm/Kconfig
> >> +++ b/arch/arm/Kconfig
> >> @@ -980,38 +980,9 @@ config ARCH_NPCM
> >>
> >> config ARCH_APPLE
> >>bool "Apple SoCs"
> >> - select ARM64
> >> - select CLK
> >> - select CMD_PCI
> >> - select CMD_USB
> >>select DM
> >> - select DM_GPIO
> >> - select DM_KEYBOARD
> >> - select DM_MAILBOX
> >>select DM_RESET
> >>select DM_SERIAL
> >> - select DM_SPI
> >> - select DM_USB
> >> - select VIDEO
> >> - select IOMMU
> >> - select LINUX_KERNEL_IMAGE_HEADER
> >> - select OF_BOARD_SETUP
> >> - select OF_CONTROL
> >> - select PCI
> >> - select PINCTRL
> >> - select POSITION_INDEPENDENT
> >> - select POWER_DOMAIN
> >> - select REGMAP
> >> - select SPI
> >> - select SYSCON
> >> - select SYSRESET
> >> - select SYSRESET_WATCHDOG
> >> - select SYSRESET_WATCHDOG_AUTO
> >> - select USB
> >> - imply CMD_DM
> >> - imply CMD_GPT
> >> - imply DISTRO_DEFAULTS
> >> - imply OF_HAS_PRIOR_STAGE
> >>
> >> config ARCH_OWL
> >>bool "Actions Semi OWL SoCs"
> >> diff --git a/arch/arm/mach-apple/Kconfig b/arch/arm/mach-apple/Kconfig
> >> index 294690ec0e..a38779b387 100644
> >> --- a/arch/arm/mach-apple/Kconfig
> >> +++ b/arch/arm/mach-apple/Kconfig
> >> @@ -3,6 +3,46 @@ if ARCH_APPLE
> >> config TEXT_BASE
> >>default 0x
> >>
> >> +choice
> >> + prompt "Apple Silicon architecture type select"
> >> + optional
> >> +
> >> +config ARCH_APPLE_M1
> >> + bool "Apple M1/M2 SoC family"
> >> + select ARM64
> >> + select CLK
> >> + select CMD_PCI
> >> + select CMD_USB
> >> + select DM_GPIO
> >> + select DM_KEYBOARD
> >> + select DM_MAILBOX
> >> + select DM_SPI
> >> + select DM_USB
> >> + sele
Re: [PATCH v1 1/7] rockchip: dts: rk3568: Resync from kernel-4.19
> From: Elaine Zhang > Date: Tue, 10 Oct 2023 16:51:49 +0800 > > Resync from kernel-4.19: > (a6cf6aca12c0 drivers: rkflash: Ajudst the dll strategy) Linux 4.19 is ancient; why are you not synching from 6.5 or a 6.6 release candidate? > Change-Id: I7b7134946b76dbd8963cfaafdc5b56750622855e > Signed-off-by: Elaine Zhang > --- > include/dt-bindings/clock/rk3568-cru.h | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/include/dt-bindings/clock/rk3568-cru.h > b/include/dt-bindings/clock/rk3568-cru.h > index c1942422a438..251445cf7632 100644 > --- a/include/dt-bindings/clock/rk3568-cru.h > +++ b/include/dt-bindings/clock/rk3568-cru.h > @@ -478,6 +478,13 @@ > #define CPLL_50M 415 > #define CPLL_25M 416 > #define CPLL_100M417 > +#define SCLK_DDRCLK 418 > +#define I2S1_MCLKOUT 419 > +#define I2S3_MCLKOUT 420 > +#define I2S1_MCLK_RX_IOE 421 > +#define I2S1_MCLK_TX_IOE 422 > +#define I2S2_MCLK_IOE423 > +#define I2S3_MCLK_IOE424 > > #define PCLK_CORE_PVTM 450 > > -- > 2.17.1 > >
Re: [PATCH] lmb: remove overlapping region with next range
> Date: Mon, 25 Sep 2023 11:21:26 -0400
> From: Tom Rini
>
> On Sun, Sep 24, 2023 at 04:48:32PM +0530, Udit Kumar wrote:
>
> > In case of new memory range to be added is coalesced
> > with any already added non last lmb region.
> >
> > And there is possibility that, then region in which new memory
> > range added is not adjacent to next region. But have some
> > sections are overlapping.
> >
> > So along with adjacency check with next lmb region,
> > check for overlap should be done.
> >
> > In case overlap is found, adjust and merge these two lmb
> > region into one.
> >
> > Reported-by: Suman Anna
> > Signed-off-by: Udit Kumar
>
> This is good! I wonder if this addresses the issue that has caused
> other platforms to need to set CONFIG_LMB_MAX_REGIONS=64 and I'm
> wondering if any of the other maintainers I've cc'd here can drop back
> to the default number of regions and then re-test their failure case?
> Thanks!
Hi Tom,
For the Apple M1 systems I don't think it makes sense to reduce the
number of regions. These systems don't have TPL or SPL, have plenty
of memory (at least 8GB) and are really fast. And we anticipate that
the number of memory regions will only grow in the future.
Cheers,
Mark
> > ---
> > logs
> > https://gist.github.com/uditkumarti/5d08c34442235ad270cfa863792ebcdc
> > seqeunce : line 1 to 13
> > without fix : line 96-100
> > with fix : line 199-202
> >
> > lib/lmb.c | 37 +
> > 1 file changed, 33 insertions(+), 4 deletions(-)
> >
> > diff --git a/lib/lmb.c b/lib/lmb.c
> > index b2c233edb6..2580d01d90 100644
> > --- a/lib/lmb.c
> > +++ b/lib/lmb.c
> > @@ -74,6 +74,16 @@ static long lmb_addrs_adjacent(phys_addr_t base1,
> > phys_size_t size1,
> > return 0;
> > }
> >
> > +static long lmb_regions_overlap(struct lmb_region *rgn, unsigned long r1,
> > + unsigned long r2)
> > +{
> > + phys_addr_t base1 = rgn->region[r1].base;
> > + phys_size_t size1 = rgn->region[r1].size;
> > + phys_addr_t base2 = rgn->region[r2].base;
> > + phys_size_t size2 = rgn->region[r2].size;
> > +
> > + return lmb_addrs_overlap(base1, size1, base2, size2);
> > +}
> > static long lmb_regions_adjacent(struct lmb_region *rgn, unsigned long r1,
> > unsigned long r2)
> > {
> > @@ -81,7 +91,6 @@ static long lmb_regions_adjacent(struct lmb_region *rgn,
> > unsigned long r1,
> > phys_size_t size1 = rgn->region[r1].size;
> > phys_addr_t base2 = rgn->region[r2].base;
> > phys_size_t size2 = rgn->region[r2].size;
> > -
> > return lmb_addrs_adjacent(base1, size1, base2, size2);
> > }
> >
> > @@ -105,6 +114,23 @@ static void lmb_coalesce_regions(struct lmb_region
> > *rgn, unsigned long r1,
> > lmb_remove_region(rgn, r2);
> > }
> >
> > +/*Assmptuon : base addr of region 1 < base addr of region 2*/
> > +static void lmb_fix_over_lap_regions(struct lmb_region *rgn, unsigned long
> > r1,
> > +unsigned long r2)
> > +{
> > + phys_addr_t base1 = rgn->region[r1].base;
> > + phys_size_t size1 = rgn->region[r1].size;
> > + phys_addr_t base2 = rgn->region[r2].base;
> > + phys_size_t size2 = rgn->region[r2].size;
> > +
> > + if (base1 + size1 > base2 + size2) {
> > + printf("This will not be a case any time\n");
> > + return;
> > + }
> > + rgn->region[r1].size = base2 + size2 - base1;
> > + lmb_remove_region(rgn, r2);
> > +}
> > +
> > void lmb_init(struct lmb *lmb)
> > {
> > #if IS_ENABLED(CONFIG_LMB_USE_MAX_REGIONS)
> > @@ -249,7 +275,6 @@ static long lmb_add_region_flags(struct lmb_region
> > *rgn, phys_addr_t base,
> > phys_size_t rgnflags = rgn->region[i].flags;
> > phys_addr_t end = base + size - 1;
> > phys_addr_t rgnend = rgnbase + rgnsize - 1;
> > -
> > if (rgnbase <= base && end <= rgnend) {
> > if (flags == rgnflags)
> > /* Already have this region, so we're done */
> > @@ -278,10 +303,14 @@ static long lmb_add_region_flags(struct lmb_region
> > *rgn, phys_addr_t base,
> > }
> > }
> >
> > - if ((i < rgn->cnt - 1) && lmb_regions_adjacent(rgn, i, i + 1)) {
> > - if (rgn->region[i].flags == rgn->region[i + 1].flags) {
> > + if (i < rgn->cnt - 1 && rgn->region[i].flags == rgn->region[i +
> > 1].flags) {
> > + if (lmb_regions_adjacent(rgn, i, i + 1)) {
> > lmb_coalesce_regions(rgn, i, i + 1);
> > coalesced++;
> > + } else if (lmb_regions_overlap(rgn, i, i + 1)) {
> > + /* fix overlapping area */
> > + lmb_fix_over_lap_regions(rgn, i, i + 1);
> > + coalesced++;
> > }
> > }
> >
> > --
> > 2.34.1
> >
>
> --
> Tom
>
> [2:application/pgp-signature Show Save:signature.asc (659B)]
>
Re: [PATCH v4] board: rockchip: Add Bananapi R2Pro Board
> Date: Mon, 18 Sep 2023 20:09:54 +0200
> From: Frank Wunderlich
>
> Am 18. September 2023 19:52:31 MESZ schrieb Mark Kettenis
> :
> >> From: Frank Wunderlich
> >> Date: Mon, 18 Sep 2023 19:36:24 +0200
>
> Hi Mark,
Hello Frank,
> >> --- /dev/null
> >> +++ b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
> >> @@ -0,0 +1,28 @@
> >> +// SPDX-License-Identifier: GPL-2.0+
> >> +/*
> >> + * (C) Copyright 2021 Rockchip Electronics Co., Ltd
> >> + */
> >> +
> >> +#include "rk356x-u-boot.dtsi"
> >> +
> >> +/ {
> >> + chosen {
> >> + stdout-path =
> >> + };
> >> +};
> >> +
> >> + {
> >> + clock-frequency = <2400>;
> >> + bootph-pre-ram;
> >> + status = "okay";
> >> +};
> >> +
> >> + {
> >> + status = "disabled";
> >> +};
> >> +
> >> +/delete-node/ &{/ethernet@fe2a/mdio/switch@0};
> >
> >Why are you deleting the switch node? This way an OS that uses the
> >device tree provided by U-boot will not have a working switch...
>
> Is there such an OS?
Yes, OpenBSD tends to rely on the device tree provided by U-Boot. It
is impossible to include device trees for all possible boards on the
installation media. And if U-Boot provides the device tree for the
board we don't need to (as long as the device tree uses the "official"
bindings).
> Linux uses own dts.
Well, Linux *may* use its own dts. Some boards never make it in the
official Linux tree. Or a generic Linux distro may use a kernel that
was released before the board made it to the market. So generic Linux
distros face the same problem as OpenBSD in that it isn't practical to
include device trees for every possible board on the installation
media.
So the goal is that U-Boot provides a usable device tree for as many
boards as possible.
> The switch will also not work because the gmac0 is deactivated to
> fix the timeout in uboot because phy does not answer.
I missed that. But that is a bug in U-Boot that should be fixed.
Probably by adding support for "fixed-link" switch ports. Now I
appreciate that having a U-Boot that partly works is better than no
U-Boot at all. So that may justify what you did. However...
> I can leave the switch-node, but i do not want the timeout on network access
> on gmac0.
...such a timeout could be seen as a reminder that the work isn't
finished yet.
> >> + {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + switch@0 {
> >> + compatible = "mediatek,mt7531";
> >> + reg = <0>;
> >> +
> >> + ports {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + port@1 {
> >> + reg = <1>;
> >> + label = "lan0";
> >> + };
> >> +
> >> + port@2 {
> >> + reg = <2>;
> >> + label = "lan1";
> >> + };
> >> +
> >> + port@3 {
> >> + reg = <3>;
> >> + label = "lan2";
> >> + };
> >> +
> >> + port@4 {
> >> + reg = <4>;
> >> + label = "lan3";
> >> + };
> >> +
> >> + port@5 {
> >> + reg = <5>;
> >> + label = "cpu";
> >> + ethernet = <>;
> >> + phy-mode = "rgmii";
> >> +
> >> + fixed-link {
> >> + speed = <1000>;
> >> + full-duplex;
> >> + pause;
> >> + };
> >> + };
> >> + };
> >> + };
> >> +};
>
>
> regards Frank
>
Re: [PATCH v4] board: rockchip: Add Bananapi R2Pro Board
> From: Frank Wunderlich
> Date: Mon, 18 Sep 2023 19:36:24 +0200
>
> Add Bananapi R2 Pro board.
>
> tested:
> - sdcard
> - both front usb-ports
> - sata
> - wan-port
>
> lan-ports are connected to mt7531 switch where driver needs to be separated
> from mtk ethernet-driver.
>
> Signed-off-by: Frank Wunderlich
> ---
> because iodomain is different to evb and now iodomain driver is sent as
> patch we need to separate between EVB and R2Pro else board can be bricked.
> ---
> v4:
> - add r2pro board to readme
> - update r2pro dts to linux version
> - remove switch node from linux dts
> - disable gmac0 because switch driver does not work yet
> to solve timeout error:
> ethernet@fe2a Waiting for PHY auto negotiation to complete.
> TIMEOUT!
> phy_startup() failed: -110FAILED: -110ethernet@fe01 Waiting for PHY
> auto nee
> - cleanup r2pro u-boot.dtsi like jonas suggests
> - update and reorder defconfig based on jonas suggestions
> - dts: disable usb_host0_ohci because of error on usb-start
> scanning bus usb@fd84 for devices...
> ERROR: USB-error: DEVICENOTRESPONDING: Device did not respond to token (IN)
> or did
> not provide a handshake (OUT) (5)
> unable to get device descriptor (error=-1)
> - pcie is not yet working, so not adding these options
> rockchip_pcie3phy phy@fe8c: lock failed 0x689
> rockchip_pcie3phy phy@fe8c: PHY: Failed to init phy@fe8c: -110.
> pcie_dw_rockchip pcie@fe27: failed to init phy (ret=-110)
> rockchip_pcie3phy phy@fe8c: lock failed 0x689
> rockchip_pcie3phy phy@fe8c: PHY: Failed to init phy@fe8c: -110.
> pcie_dw_rockchip pcie@fe28: failed to init phy (ret=-110)
> - emmc not tested as it is empty on my board because it breaks sdcard boot
>
> v3:
> - disable gmac0 as switch-driver is not yet ready to attach to the mac
>
> v2:
> - drop switch-node for now as u-boot driver works differently to linux
> ---
> arch/arm/dts/Makefile | 3 +-
> arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi | 28 +
> arch/arm/dts/rk3568-bpi-r2pro.dts | 852 ++
> configs/bpi-r2pro-rk3568_defconfig| 95 +++
> doc/board/rockchip/rockchip.rst | 1 +
> 5 files changed, 978 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
> create mode 100644 arch/arm/dts/rk3568-bpi-r2pro.dts
> create mode 100644 configs/bpi-r2pro-rk3568_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 85fd5b1157b1..71c557e87e9e 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -183,7 +183,8 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
> rk3568-nanopi-r5s.dtb \
> rk3568-odroid-m1.dtb \
> rk3568-radxa-e25.dtb \
> - rk3568-rock-3a.dtb
> + rk3568-rock-3a.dtb \
> + rk3568-bpi-r2pro.dtb
>
> dtb-$(CONFIG_ROCKCHIP_RK3588) += \
> rk3588-edgeble-neu6a-io.dtb \
> diff --git a/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
> b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
> new file mode 100644
> index ..089e54f8cece
> --- /dev/null
> +++ b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
> @@ -0,0 +1,28 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2021 Rockchip Electronics Co., Ltd
> + */
> +
> +#include "rk356x-u-boot.dtsi"
> +
> +/ {
> + chosen {
> + stdout-path =
> + };
> +};
> +
> + {
> + clock-frequency = <2400>;
> + bootph-pre-ram;
> + status = "okay";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> +/delete-node/ &{/ethernet@fe2a/mdio/switch@0};
Why are you deleting the switch node? This way an OS that uses the
device tree provided by U-boot will not have a working switch...
> +
> +_host0_ohci {
> + status = "disabled";
> +};
> diff --git a/arch/arm/dts/rk3568-bpi-r2pro.dts
> b/arch/arm/dts/rk3568-bpi-r2pro.dts
> new file mode 100644
> index ..f9127ddfbb7d
> --- /dev/null
> +++ b/arch/arm/dts/rk3568-bpi-r2pro.dts
> @@ -0,0 +1,852 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Author: Frank Wunderlich
> + *
> + */
> +
> +/dts-v1/;
> +#include
> +#include
> +#include
> +#include
> +#include "rk3568.dtsi"
> +
> +/ {
> + model = "Bananapi-R2 Pro (RK3568) DDR4 Board";
> + compatible = "rockchip,rk3568-bpi-r2pro", "rockchip,rk3568";
> +
> + aliases {
> + ethernet0 =
> + ethernet1 =
> + mmc0 =
> + mmc1 =
> + };
> +
> + chosen: chosen {
> + stdout-path = "serial2:150n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <_led_pin _led_pin>;
> +
> + blue_led: led-0 {
> + color = ;
> + default-state = "off";
> + function = LED_FUNCTION_STATUS;
> + gpios = < RK_PD6 GPIO_ACTIVE_HIGH>;
> +
Re: [PATCH v2] bootstd: Make efi_mgr bootmeth work for non-sandbox setups
> From: Simon Glass
> Date: Sun, 10 Sep 2023 13:13:16 -0600
>
> Hi Mark,
>
> On Sun, 10 Sept 2023 at 08:57, Mark Kettenis wrote:
> >
> > > From: Simon Glass
> > > Date: Thu, 7 Sep 2023 09:57:34 -0600
> > >
> > > Hi Mark,
> > >
> > > On Thu, 7 Sept 2023 at 07:08, Mark Kettenis
> > > wrote:
> > > >
> > > > > From: Simon Glass
> > > > > Date: Thu, 7 Sep 2023 06:23:10 -0600
> > > > >
> > > > > Hi Mark,
> > > > >
> > > > > On Sun, 3 Sept 2023 at 14:40, Mark Kettenis
> > > > > wrote:
> > > > > >
> > > > > > Enable the bootflow based on this bootmeth if the BootOrder EFI
> > > > > > variable is set.
> > > > > >
> > > > > > Signed-off-by: Mark Kettenis
> > > > > > ---
> > > > > >
> > > > > > ChangeLog:
> > > > > >
> > > > > > v2: - Initialize EFI subsystem to populate EFI variables
> > > > > >
> > > > > >
> > > > > > boot/bootmeth_efi_mgr.c | 17 -
> > > > > > 1 file changed, 16 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c
> > > > > > index e9d973429f..e6c42d41fb 100644
> > > > > > --- a/boot/bootmeth_efi_mgr.c
> > > > > > +++ b/boot/bootmeth_efi_mgr.c
> > > > > > @@ -14,6 +14,8 @@
> > > > > > #include
> > > > > > #include
> > > > > > #include
> > > > > > +#include
> > > > > > +#include
> > > > > >
> > > > > > /**
> > > > > > * struct efi_mgr_priv - private info for the efi-mgr driver
> > > > > > @@ -46,13 +48,26 @@ static int efi_mgr_check(struct udevice *dev,
> > > > > > struct bootflow_iter *iter)
> > > > > > static int efi_mgr_read_bootflow(struct udevice *dev, struct
> > > > > > bootflow *bflow)
> > > > > > {
> > > > > > struct efi_mgr_priv *priv = dev_get_priv(dev);
> > > > > > + efi_status_t ret;
> > > > > > + efi_uintn_t size;
> > > > > > + u16 *bootorder;
> > > > > >
> > > > > > if (priv->fake_dev) {
> > > > > > bflow->state = BOOTFLOWST_READY;
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > - /* To be implemented */
> > > > > > + ret = efi_init_obj_list();
> > > > >
> > > > > Doesn't this start up the whole EFI system? Is there a cheaper way to
> > > > > see if the variable subsystem exists, or can work?
> > > >
> > > > A fair bit of it at least. With the possible exception of launching
> > > > EFI capsules (which shouldn't happen for a "normal" boot), I don't
> > > > think this is very expensive though.
> > > >
> > > > There currently isn't a way to only initialize the variable subsystem;
> > > > we can't just call efi_init_variables() here since we have to also
> > > > call efi_disks_register() and a later efi_init_obj_list() call would
> > > > call efi_init_variables() again, which would leak memory.
> > > >
> > > > Alternatively we could just unconditionally declare the efi_mgr
> > > > bootmeth as "ready" (like you already do for sandbox). That would
> > > > postpone initialization of the EFI subsystem until we actually execute
> > > > this bootmeth.
> > > >
> > > > But we need to do something before we switch more targets to standard
> > > > boot since otherwise booting through the EFI boot manager is just
> > > > plain broken.
> > >
> > > Yes...
> > >
> > > I don't have any great ideas on this. If we could get the EFI code
> > > better integrated into U-Boot then perhaps we would not need this
> > > 'monolithm' init?
> >
> > You'll have to take that up with the maintainers of the EFI loader
> > subsystem. I just want to repair the breakage that was introduced
> > with bootstd.
>
> Yes, understood. Do you know how long it takes to do this step?
It is instant. But then this is on a fast machine with the EFI
variables stored on the internal NVMe disk, which is plenty fast as
well. And I haven't enabled any of the capsule or TPM stuff hich may
take more time.
> The control for this feature is CMD_BOOTEFI_BOOTMGR...I think it would
> be better to have BOOTEFI_BOOTMGR as well as CMD_BOOTEFI_BOOTMGR,
> since it is strange to have a CMD Kconfig in lib/efi_loader
>
> I am OK with this patch as I don't see any alternative. We need to do
> something and we can always improve it if it causes problems.
>
> Heinrich?
>
> Regards,
> Simon
>
Re: [PATCH] arm: apple: Add initial Apple M2 Ultra support
> From: Janne Grunau
> Date: Wed, 06 Sep 2023 23:50:34 +0200
>
> Apple's M2 Ultra SoC are somewhat similar to the M1 Ultra but needs
> a tweaked memory map as the M2 Pro/Max SoCs. USB, NVMe, UART, WDT
> and PCIe are working with the existing drivers.
>
> Signed-off-by: Janne Grunau
Reviewed-by: Mark Kettenis
> ---
> arch/arm/mach-apple/board.c | 183
>
> 1 file changed, 183 insertions(+)
>
> diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
> index d50194811843..47393babbc62 100644
> --- a/arch/arm/mach-apple/board.c
> +++ b/arch/arm/mach-apple/board.c
> @@ -444,6 +444,187 @@ static struct mm_region t6020_mem_map[] = {
> }
> };
>
> +/* Apple M2 Ultra */
> +
> +static struct mm_region t6022_mem_map[] = {
> + {
> + /* I/O */
> + .virt = 0x28000,
> + .phys = 0x28000,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x34000,
> + .phys = 0x34000,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x38000,
> + .phys = 0x38000,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x58000,
> + .phys = 0x58000,
> + .size = SZ_512M,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* PCIE */
> + .virt = 0x5a000,
> + .phys = 0x5a000,
> + .size = SZ_512M,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRE) |
> + PTE_BLOCK_INNER_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* PCIE */
> + .virt = 0x5c000,
> + .phys = 0x5c000,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRE) |
> + PTE_BLOCK_INNER_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x7,
> + .phys = 0x7,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0xb,
> + .phys = 0xb,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0xf,
> + .phys = 0xf,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x13,
> + .phys = 0x13,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x228000,
> + .phys = 0x228000,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x234000,
> + .phys = 0x234000,
> + .size = SZ_1G,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* I/O */
> + .virt = 0x238000,
> +
Re: [PATCH] arm: apple: Add initial Apple M2 Ultra support
> From: Simon Glass
> Date: Sun, 10 Sep 2023 16:36:48 -0600
>
> Hi,
>
> On Wed, 6 Sept 2023 at 15:50, Janne Grunau wrote:
> >
> > Apple's M2 Ultra SoC are somewhat similar to the M1 Ultra but needs
> > a tweaked memory map as the M2 Pro/Max SoCs. USB, NVMe, UART, WDT
> > and PCIe are working with the existing drivers.
> >
> > Signed-off-by: Janne Grunau
> > ---
> > arch/arm/mach-apple/board.c | 183
> >
> > 1 file changed, 183 insertions(+)
> >
> > diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
> > index d50194811843..47393babbc62 100644
> > --- a/arch/arm/mach-apple/board.c
> > +++ b/arch/arm/mach-apple/board.c
> > @@ -444,6 +444,187 @@ static struct mm_region t6020_mem_map[] = {
> > }
> > };
> >
> > +/* Apple M2 Ultra */
> > +
> > +static struct mm_region t6022_mem_map[] = {
> > + {
> > + /* I/O */
> > + .virt = 0x28000,
> > + .phys = 0x28000,
> > + .size = SZ_1G,
> > + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> > +PTE_BLOCK_NON_SHARE |
> > +PTE_BLOCK_PXN | PTE_BLOCK_UXN
> > + }, {
>
> Is there no devicetree binding for this information?
Not directly. The device tree does contain the addresses of the
devices of course. But what we want here is a memory map that uses a
few big ranges that cover all the devices in the device tree rather
than lots of small ranges that cover the individual devices.
But yes, it sucks that every time Apple produces a new SoC we need to
add another memory map.
Re: [PATCH v2] bootstd: Make efi_mgr bootmeth work for non-sandbox setups
> From: Simon Glass
> Date: Thu, 7 Sep 2023 09:57:34 -0600
>
> Hi Mark,
>
> On Thu, 7 Sept 2023 at 07:08, Mark Kettenis wrote:
> >
> > > From: Simon Glass
> > > Date: Thu, 7 Sep 2023 06:23:10 -0600
> > >
> > > Hi Mark,
> > >
> > > On Sun, 3 Sept 2023 at 14:40, Mark Kettenis wrote:
> > > >
> > > > Enable the bootflow based on this bootmeth if the BootOrder EFI
> > > > variable is set.
> > > >
> > > > Signed-off-by: Mark Kettenis
> > > > ---
> > > >
> > > > ChangeLog:
> > > >
> > > > v2: - Initialize EFI subsystem to populate EFI variables
> > > >
> > > >
> > > > boot/bootmeth_efi_mgr.c | 17 -
> > > > 1 file changed, 16 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c
> > > > index e9d973429f..e6c42d41fb 100644
> > > > --- a/boot/bootmeth_efi_mgr.c
> > > > +++ b/boot/bootmeth_efi_mgr.c
> > > > @@ -14,6 +14,8 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > > +#include
> > > >
> > > > /**
> > > > * struct efi_mgr_priv - private info for the efi-mgr driver
> > > > @@ -46,13 +48,26 @@ static int efi_mgr_check(struct udevice *dev,
> > > > struct bootflow_iter *iter)
> > > > static int efi_mgr_read_bootflow(struct udevice *dev, struct bootflow
> > > > *bflow)
> > > > {
> > > > struct efi_mgr_priv *priv = dev_get_priv(dev);
> > > > + efi_status_t ret;
> > > > + efi_uintn_t size;
> > > > + u16 *bootorder;
> > > >
> > > > if (priv->fake_dev) {
> > > > bflow->state = BOOTFLOWST_READY;
> > > > return 0;
> > > > }
> > > >
> > > > - /* To be implemented */
> > > > + ret = efi_init_obj_list();
> > >
> > > Doesn't this start up the whole EFI system? Is there a cheaper way to
> > > see if the variable subsystem exists, or can work?
> >
> > A fair bit of it at least. With the possible exception of launching
> > EFI capsules (which shouldn't happen for a "normal" boot), I don't
> > think this is very expensive though.
> >
> > There currently isn't a way to only initialize the variable subsystem;
> > we can't just call efi_init_variables() here since we have to also
> > call efi_disks_register() and a later efi_init_obj_list() call would
> > call efi_init_variables() again, which would leak memory.
> >
> > Alternatively we could just unconditionally declare the efi_mgr
> > bootmeth as "ready" (like you already do for sandbox). That would
> > postpone initialization of the EFI subsystem until we actually execute
> > this bootmeth.
> >
> > But we need to do something before we switch more targets to standard
> > boot since otherwise booting through the EFI boot manager is just
> > plain broken.
>
> Yes...
>
> I don't have any great ideas on this. If we could get the EFI code
> better integrated into U-Boot then perhaps we would not need this
> 'monolithm' init?
You'll have to take that up with the maintainers of the EFI loader
subsystem. I just want to repair the breakage that was introduced
with bootstd.
Re: [RFC PATCH 0/5] Allow for removal of DT nodes and properties
> From: Jassi Brar > Date: Fri, 8 Sep 2023 09:37:12 -0500 > > Hi Simon, > > On Thu, Sep 7, 2023 at 3:08 PM Simon Glass wrote: > > On Wed, 6 Sept 2023 at 23:20, Ilias Apalodimas > > > > > > > > I beg to differ. Devicetree is more than just hardware and always has > > > > > been. See, for example the /chosen and /options nodes. > > > > > > > > There are exceptions... > > > > > > > > > > We've been this over and over again and frankly it gets a bit annoying. > > > It's called *DEVICE* tree for a reason. As Rob pointed out there are > > > exceptions, but those made a lot of sense. Having arbitrary internal ABI > > > stuff of various projects in the schema just defeats the definition of a > > > spec. > > > > Our efforts should not just be about internal ABI, but working to > > provide a consistent configuration system for all firmware elements. > > > Sure, programmatically we can pass any data/info via DT, however it is > only meant to map hardware features onto data structures. > > devicetree.org landing page > "The devicetree is a data structure for describing hardware." > > devicetree-specification-v0.3.pdf Chapter-2 Line-1 >"DTSpec specifies a construct called a devicetree to describe > system hardware." But it doesn't say that it describes *only* hardware. And it does describe more than just hardware. There is /chosen to specify firmware configuration and there are several examples of device tree bindings that describe non-discoverable firmware interfaces in the Linux tree. And it has been that way since the days of IEEE 1275. There are also bindings describing things like the firmware partition layout. > If we want to digress from the spec, we need the majority of > developers to switch sides :) which is unlikely to happen and rightly > so, imho. It isn't even clear what the spec is. There is the document you reference above, there are the yaml files at https://github.com/devicetree-org/dt-schema and then there are additional yaml files in the Linux tree. As far as I know it isn't written down anywhere that those are the only places where device tree bindings can live. Anyway, let's face it, there is some consensus among developers that what Simon has done in U-Boot is pushing the use of devicetree beyond the point where a significant fraction of developers thinks it makes sense. And I think I agree with that. But you can't beat him with the spec to make your point. Now the devicetree is cleverly constructed such that it is possible to define additional bindings without the risk of conflicting with bindings developed by other parties. In particular if U-Boot is augmenting a device tree with properties that are prefixed with "u-boot," this isn't going to hurt an operating system that uses such an augmented device tree. The real problem is that some folks developed a certification program that allegedly requires schema verification and now propose adding code to U-Boot that doesn't really solve any problem. My proposed solution would be to change said certification program to allow firmware to augment the device tree with properties and nodes with compatibles that are in the namespace controlled by the firmware. Cheers, Mark
Re: [PATCH v2] bootstd: Make efi_mgr bootmeth work for non-sandbox setups
> From: Simon Glass
> Date: Thu, 7 Sep 2023 06:23:10 -0600
>
> Hi Mark,
>
> On Sun, 3 Sept 2023 at 14:40, Mark Kettenis wrote:
> >
> > Enable the bootflow based on this bootmeth if the BootOrder EFI
> > variable is set.
> >
> > Signed-off-by: Mark Kettenis
> > ---
> >
> > ChangeLog:
> >
> > v2: - Initialize EFI subsystem to populate EFI variables
> >
> >
> > boot/bootmeth_efi_mgr.c | 17 -
> > 1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c
> > index e9d973429f..e6c42d41fb 100644
> > --- a/boot/bootmeth_efi_mgr.c
> > +++ b/boot/bootmeth_efi_mgr.c
> > @@ -14,6 +14,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> >
> > /**
> > * struct efi_mgr_priv - private info for the efi-mgr driver
> > @@ -46,13 +48,26 @@ static int efi_mgr_check(struct udevice *dev, struct
> > bootflow_iter *iter)
> > static int efi_mgr_read_bootflow(struct udevice *dev, struct bootflow
> > *bflow)
> > {
> > struct efi_mgr_priv *priv = dev_get_priv(dev);
> > + efi_status_t ret;
> > + efi_uintn_t size;
> > + u16 *bootorder;
> >
> > if (priv->fake_dev) {
> > bflow->state = BOOTFLOWST_READY;
> > return 0;
> > }
> >
> > - /* To be implemented */
> > + ret = efi_init_obj_list();
>
> Doesn't this start up the whole EFI system? Is there a cheaper way to
> see if the variable subsystem exists, or can work?
A fair bit of it at least. With the possible exception of launching
EFI capsules (which shouldn't happen for a "normal" boot), I don't
think this is very expensive though.
There currently isn't a way to only initialize the variable subsystem;
we can't just call efi_init_variables() here since we have to also
call efi_disks_register() and a later efi_init_obj_list() call would
call efi_init_variables() again, which would leak memory.
Alternatively we could just unconditionally declare the efi_mgr
bootmeth as "ready" (like you already do for sandbox). That would
postpone initialization of the EFI subsystem until we actually execute
this bootmeth.
But we need to do something before we switch more targets to standard
boot since otherwise booting through the EFI boot manager is just
plain broken.
> > + if (ret)
> > + return log_msg_ret("init", ret);
> > +
> > + /* Enable this method if the "BootOrder" UEFI exists. */
> > + bootorder = efi_get_var(u"BootOrder", _global_variable_guid,
> > + );
> > + if (bootorder) {
> > + bflow->state = BOOTFLOWST_READY;
> > + return 0;
> > + }
> >
> > return -EINVAL;
> > }
> > --
> > 2.42.0
> >
>
> Regards,
> Simon
>
[PATCH v2] bootstd: Make efi_mgr bootmeth work for non-sandbox setups
Enable the bootflow based on this bootmeth if the BootOrder EFI
variable is set.
Signed-off-by: Mark Kettenis
---
ChangeLog:
v2: - Initialize EFI subsystem to populate EFI variables
boot/bootmeth_efi_mgr.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c
index e9d973429f..e6c42d41fb 100644
--- a/boot/bootmeth_efi_mgr.c
+++ b/boot/bootmeth_efi_mgr.c
@@ -14,6 +14,8 @@
#include
#include
#include
+#include
+#include
/**
* struct efi_mgr_priv - private info for the efi-mgr driver
@@ -46,13 +48,26 @@ static int efi_mgr_check(struct udevice *dev, struct
bootflow_iter *iter)
static int efi_mgr_read_bootflow(struct udevice *dev, struct bootflow *bflow)
{
struct efi_mgr_priv *priv = dev_get_priv(dev);
+ efi_status_t ret;
+ efi_uintn_t size;
+ u16 *bootorder;
if (priv->fake_dev) {
bflow->state = BOOTFLOWST_READY;
return 0;
}
- /* To be implemented */
+ ret = efi_init_obj_list();
+ if (ret)
+ return log_msg_ret("init", ret);
+
+ /* Enable this method if the "BootOrder" UEFI exists. */
+ bootorder = efi_get_var(u"BootOrder", _global_variable_guid,
+ );
+ if (bootorder) {
+ bflow->state = BOOTFLOWST_READY;
+ return 0;
+ }
return -EINVAL;
}
--
2.42.0
Re: [PATCH] arm: mach-apple: Move M1/M2 specifics into a separate folder
> From: ivo.iva...@null.net
> Date: Tue, 29 Aug 2023 20:25:19 +0300
>
> From: Ivaylo Ivanov
>
> Currently, mach-apple assumes we're working with M1/M2. Make room for
> adding support for other Apple SoCs by moving everything from the M1/M2
> SoC family in "mach-apple/" into "mach-apple/m1/".
Which other Apple SoCs?
> Signed-off-by: Ivaylo Ivanov
> ---
> arch/arm/Kconfig | 29 --
> arch/arm/mach-apple/Kconfig | 42
> arch/arm/mach-apple/Makefile | 5 +--
> arch/arm/mach-apple/m1/Makefile | 6 +++
> arch/arm/mach-apple/{ => m1}/board.c | 0
> arch/arm/mach-apple/{ => m1}/lowlevel_init.S | 0
> arch/arm/mach-apple/{ => m1}/rtkit.c | 0
> arch/arm/mach-apple/{ => m1}/sart.c | 0
> configs/apple_m1_defconfig | 1 +
> 9 files changed, 50 insertions(+), 33 deletions(-)
> create mode 100644 arch/arm/mach-apple/m1/Makefile
> rename arch/arm/mach-apple/{ => m1}/board.c (100%)
> rename arch/arm/mach-apple/{ => m1}/lowlevel_init.S (100%)
> rename arch/arm/mach-apple/{ => m1}/rtkit.c (100%)
> rename arch/arm/mach-apple/{ => m1}/sart.c (100%)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 97c25b4f14..5339da370c 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -980,38 +980,9 @@ config ARCH_NPCM
>
> config ARCH_APPLE
> bool "Apple SoCs"
> - select ARM64
> - select CLK
> - select CMD_PCI
> - select CMD_USB
> select DM
> - select DM_GPIO
> - select DM_KEYBOARD
> - select DM_MAILBOX
> select DM_RESET
> select DM_SERIAL
> - select DM_SPI
> - select DM_USB
> - select VIDEO
> - select IOMMU
> - select LINUX_KERNEL_IMAGE_HEADER
> - select OF_BOARD_SETUP
> - select OF_CONTROL
> - select PCI
> - select PINCTRL
> - select POSITION_INDEPENDENT
> - select POWER_DOMAIN
> - select REGMAP
> - select SPI
> - select SYSCON
> - select SYSRESET
> - select SYSRESET_WATCHDOG
> - select SYSRESET_WATCHDOG_AUTO
> - select USB
> - imply CMD_DM
> - imply CMD_GPT
> - imply DISTRO_DEFAULTS
> - imply OF_HAS_PRIOR_STAGE
>
> config ARCH_OWL
> bool "Actions Semi OWL SoCs"
> diff --git a/arch/arm/mach-apple/Kconfig b/arch/arm/mach-apple/Kconfig
> index 294690ec0e..a38779b387 100644
> --- a/arch/arm/mach-apple/Kconfig
> +++ b/arch/arm/mach-apple/Kconfig
> @@ -3,6 +3,46 @@ if ARCH_APPLE
> config TEXT_BASE
> default 0x
>
> +choice
> + prompt "Apple Silicon architecture type select"
> + optional
> +
> +config ARCH_APPLE_M1
> + bool "Apple M1/M2 SoC family"
> + select ARM64
> + select CLK
> + select CMD_PCI
> + select CMD_USB
> + select DM_GPIO
> + select DM_KEYBOARD
> + select DM_MAILBOX
> + select DM_SPI
> + select DM_USB
> + select VIDEO
> + select IOMMU
> + select LINUX_KERNEL_IMAGE_HEADER
> + select OF_BOARD_SETUP
> + select OF_CONTROL
> + select PCI
> + select PINCTRL
> + select POSITION_INDEPENDENT
> + select POWER_DOMAIN
> + select REGMAP
> + select SPI
> + select SYSCON
> + select SYSRESET
> + select SYSRESET_WATCHDOG
> + select SYSRESET_WATCHDOG_AUTO
> + select USB
> + imply CMD_DM
> + imply CMD_GPT
> + imply DISTRO_DEFAULTS
> + imply OF_HAS_PRIOR_STAGE
> +
> +endchoice
> +
> +if ARCH_APPLE_M1
> +
> config SYS_CONFIG_NAME
> default "apple"
>
> @@ -19,3 +59,5 @@ config LNX_KRNL_IMG_TEXT_OFFSET_BASE
> default TEXT_BASE
>
> endif
> +
> +endif
> diff --git a/arch/arm/mach-apple/Makefile b/arch/arm/mach-apple/Makefile
> index 50b465b947..d147ccdde2 100644
> --- a/arch/arm/mach-apple/Makefile
> +++ b/arch/arm/mach-apple/Makefile
> @@ -1,6 +1,3 @@
> # SPDX-License-Identifier: GPL-2.0+
>
> -obj-y += board.o
> -obj-y += lowlevel_init.o
> -obj-y += rtkit.o
> -obj-$(CONFIG_NVME_APPLE) += sart.o
> +obj-$(CONFIG_ARCH_APPLE_M1) += m1/
> diff --git a/arch/arm/mach-apple/m1/Makefile b/arch/arm/mach-apple/m1/Makefile
> new file mode 100644
> index 00..50b465b947
> --- /dev/null
> +++ b/arch/arm/mach-apple/m1/Makefile
> @@ -0,0 +1,6 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +
> +obj-y += board.o
> +obj-y += lowlevel_init.o
> +obj-y += rtkit.o
> +obj-$(CONFIG_NVME_APPLE) += sart.o
> diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/m1/board.c
> similarity index 100%
> rename from arch/arm/mach-apple/board.c
> rename to arch/arm/mach-apple/m1/board.c
> diff --git a/arch/arm/mach-apple/lowlevel_init.S
> b/arch/arm/mach-apple/m1/lowlevel_init.S
> similarity index 100%
> rename from arch/arm/mach-apple/lowlevel_init.S
> rename to arch/arm/mach-apple/m1/lowlevel_init.S
> diff --git a/arch/arm/mach-apple/rtkit.c b/arch/arm/mach-apple/m1/rtkit.c
> similarity index 100%
> rename from arch/arm/mach-apple/rtkit.c
> rename to
Re: [PATCH v5 00/13] Add video damage tracking
> Date: Tue, 29 Aug 2023 08:20:49 +0200 > From: Alexander Graf > > On 28.08.23 23:54, Heinrich Schuchardt wrote: > > On 8/28/23 22:24, Alexander Graf wrote: > >> > >> On 28.08.23 19:54, Simon Glass wrote: > >>> Hi Alex, > >>> > >>> On Wed, 23 Aug 2023 at 02:56, Alexander Graf wrote: > Hey Simon, > > On 22.08.23 20:56, Simon Glass wrote: > > Hi Alex, > > > > On Tue, 22 Aug 2023 at 01:47, Alexander Graf wrote: > >> On 22.08.23 01:03, Simon Glass wrote: > >>> Hi Alex, > >>> > >>> On Mon, 21 Aug 2023 at 16:40, Alexander Graf > >>> wrote: > On 22.08.23 00:10, Simon Glass wrote: > > Hi Alex, > > > > On Mon, 21 Aug 2023 at 14:20, Alexander Graf > > wrote: > >> On 21.08.23 21:57, Simon Glass wrote: > >>> Hi Alex, > >>> > >>> On Mon, 21 Aug 2023 at 13:33, Alexander Graf > >>> wrote: > On 21.08.23 21:11, Simon Glass wrote: > > Hi Alper, > > > > On Mon, 21 Aug 2023 at 07:51, Alper Nebi Yasak > > wrote: > >> This is a rebase of Alexander Graf's video damage tracking > >> series, with > >> some tests and other changes. The original cover letter is > >> as follows: > >> > >>> This patch set speeds up graphics output on ARM by a > >>> factor of 60x. > >>> > >>> On most ARM SBCs, we keep the frame buffer in DRAM and map > >>> it as cached, > >>> but need it accessible by the display controller which > >>> reads directly > >>> from a later point of consistency. Hence, we flush the > >>> frame buffer to > >>> DRAM on every change. The full frame buffer. > > It should not, see below. > > > >>> Unfortunately, with the advent of 4k displays, we are > >>> seeing frame buffers > >>> that can take a while to flush out. This was reported by > >>> Da Xue with grub, > >>> which happily print 1000s of spaces on the screen to draw > >>> a menu. Every > >>> printed space triggers a cache flush. > > That is a bug somewhere in EFI. > Unfortunately not :). You may call it a bug in grub: It > literally prints > over space characters for every character in its menu that it > wants > cleared. On every text screen draw. > > This wouldn't be a big issue if we only flush the reactangle > that gets > modified. But without this patch set, we're flushing the full > DRAM > buffer on every u-boot text console character write, which > means for > every character (as that's the only API UEFI has). > > As a nice side effect, we speed up the normal U-Boot text > console as > well with this patch set, because even "normal" text prints > that write > for example a single line of text on the screen today flush > the full > frame buffer to DRAM. > >>> No, I mean that it is a bug that U-Boot (apparently) flushes > >>> the cache > >>> after every character. It doesn't do that for normal character > >>> output > >>> and I don't think it makes sense to do it for EFI either. > >> I see. Let's trace the calls: > >> > >> efi_cout_output_string() > >> -> fputs() > >> -> vidconsole_puts() > >> -> video_sync() > >> -> flush_dcache_range() > >> > >> Unfortunately grub abstracts character backends down to the > >> "print > >> character" level, so it calls UEFI's sopisticated > >> "output_string" > >> callback with single characters at a time, which means we do a > >> full > >> dcache flush for every character that we print: > >> > >> https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/term/efi/console.c#n165 > >> > >> > >> > >> > >>> This patch set implements the easiest mitigation against > >>> this problem: > >>> Damage tracking. We remember the lowest common denominator > >>> region that was > >>> touched since the last video_sync() call and only flush > >>> that. The most > >>> typical writer to the frame buffer is the video console, > >>> which always > >>> writes rectangles of characters on the screen and syncs > >>> afterwards. > >>> > >>> With this patch set applied, we reduce drawing a large > >>> grub menu (with > >>>
Re: [PATCH 17/19] Make DISTRO_DEFAULTS as deprecated
> From: Simon Glass > Date: Thu, 24 Aug 2023 13:59:08 -0600 > > Encourage people to move to distro boot. Add a short migration guide. Doesn't this commit message say the exact opposite of what the patch does? > Signed-off-by: Simon Glass > --- > > boot/Kconfig| 7 ++- > doc/develop/bootstd.rst | 23 +++ > 2 files changed, 29 insertions(+), 1 deletion(-) > > diff --git a/boot/Kconfig b/boot/Kconfig > index 02b33323d726..4742ee2027bd 100644 > --- a/boot/Kconfig > +++ b/boot/Kconfig > @@ -781,7 +781,7 @@ config SYS_BOOT_RAMDISK_HIGH > endmenu # Boot images > > config DISTRO_DEFAULTS > - bool "Select defaults suitable for booting general purpose Linux > distributions" > + bool "(deprecated) 'Defaults suitable for booting general purpose Linux > distributions" > select BOOT_DEFAULTS > select AUTO_COMPLETE > select CMDLINE_EDITING > @@ -789,6 +789,11 @@ config DISTRO_DEFAULTS > select HUSH_PARSER > select SYS_LONGHELP > help > + Note: These scripts have been replaced by Standard Boot. Do not use > + them on new boards. See 'Migrating from distro_boot' at > + doc/develop/bootstd.rst > + > + > Select this to enable various options and commands which are suitable > for building u-boot for booting general purpose Linux distributions. > > diff --git a/doc/develop/bootstd.rst b/doc/develop/bootstd.rst > index ec3136535783..8b2f0849a1c0 100644 > --- a/doc/develop/bootstd.rst > +++ b/doc/develop/bootstd.rst > @@ -458,6 +458,28 @@ readyFile was loaded and is ready for use. In this > state the bootflow is > === > === > > > +Migrating from distro_boot > +-- > + > +To migrate from distro_boot: > + > +#. Update your board header files to remove the BOOTENV and BOOT_TARGET_xxx > + defines. Standard boot finds available boot devices automatically. > + > +#. Remove the "boot_targets" variable unless you need it. Standard boot uses > a > + default order from fastest to slowest, which generally matches the order > used > + by boards. > + > +#. Make sure that CONFIG_BOOTSTD_DEFAULTS is enabled by your board, so it can > + boot common Linux distributions. > + > +An example patch is at migrate_patch_. > + > +If you are using custom boot scripts for your board, consider creating your > +own bootmeth to hold the logic. There are various examples at > +`boot/bootmeth_...`. > + > + > Theory of operation > --- > > @@ -768,3 +790,4 @@ Other ideas: > .. _BootLoaderSpec: > http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ > .. _distro_boot: https://github.com/u-boot/u-boot/blob/master/boot/distro.c > .. _bootflow_h: > https://github.com/u-boot/u-boot/blob/master/include/bootflow.h > +.. _migrate_patch: > https://patchwork.ozlabs.org/project/uboot/patch/20230727215433.578830-2-...@chromium.org/ > -- > 2.42.0.rc1.204.g551eb34607-goog > >
Re: [PATCH 18/18] riscv: qemu: Enable usb keyboard as an input device
> Date: Sun, 23 Jul 2023 11:30:31 +0200
> From: Heinrich Schuchardt
>
> Am 23. Juli 2023 10:38:00 MESZ schrieb Mark Kettenis
> :
> >> From: Bin Meng
> >> Date: Sun, 23 Jul 2023 12:40:41 +0800
> >>
> >> This brings PCI xHCI support to QEMU RISC-V and uses a usb keyboard
> >> as one of the input devices.
> >>
> >> Signed-off-by: Bin Meng
> >>
> >> ---
> >>
> >> board/emulation/qemu-riscv/Kconfig | 5 +
> >> board/emulation/qemu-riscv/qemu-riscv.c | 5 +
> >> doc/board/emulation/qemu-riscv.rst | 5 +
> >> include/configs/qemu-riscv.h| 2 +-
> >> 4 files changed, 16 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/board/emulation/qemu-riscv/Kconfig
> >> b/board/emulation/qemu-riscv/Kconfig
> >> index 7220c55350..b503578d27 100644
> >> --- a/board/emulation/qemu-riscv/Kconfig
> >> +++ b/board/emulation/qemu-riscv/Kconfig
> >> @@ -76,5 +76,10 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> >>imply VIDEO_BOCHS
> >>imply SYS_WHITE_ON_BLACK
> >>imply PRE_CONSOLE_BUFFER
> >> + imply USB
> >> + imply USB_XHCI_HCD
> >> + imply USB_XHCI_PCI
> >> + imply USB_KEYBOARD
> >> + imply CMD_USB
> >>
> >> endif
> >> diff --git a/board/emulation/qemu-riscv/qemu-riscv.c
> >> b/board/emulation/qemu-riscv/qemu-riscv.c
> >> index f39f3be366..181abbbf97 100644
> >> --- a/board/emulation/qemu-riscv/qemu-riscv.c
> >> +++ b/board/emulation/qemu-riscv/qemu-riscv.c
> >> @@ -12,6 +12,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include
> >>
> >> @@ -41,6 +42,10 @@ int board_init(void)
> >>
> >> int board_late_init(void)
> >> {
> >> + /* start usb so that usb keyboard can be used as input device */
> >> + if (CONFIG_IS_ENABLED(USB_KEYBOARD))
> >> + usb_init();
> >> +
> >
> >This is typically handled by including "usb start" in CONFIG_PREBOOT,
> >which is done by boot/Kconfig. Any reason why that doesn't work for
> >you?
>
> We run pci_init() in board_r.c. Why don't do the same for USB
> instead of the PREBOOT quirk?
Well, yes, that was going to be my next question. If using PREBOOT is
for some reason no longer the preferred way to do this, should there
be some other generic method to make sure the USB controllers are
started when a USB keyboard is configured as an input method. Doing
something generic like this in board-specific code seems wrong to me.
Cheers,
Mark
> >
> >>return 0;
> >> }
> >>
> >> diff --git a/doc/board/emulation/qemu-riscv.rst
> >> b/doc/board/emulation/qemu-riscv.rst
> >> index 9d21f3270c..61137bcbf1 100644
> >> --- a/doc/board/emulation/qemu-riscv.rst
> >> +++ b/doc/board/emulation/qemu-riscv.rst
> >> @@ -138,6 +138,11 @@ and adding::
> >>
> >> -serial stdio -device VGA
> >>
> >> +In addition, a usb keyboard can be attached to an emulated xHCI
> >> controller in
> >> +RISC-V virt machine as an option of input devices by adding::
> >> +
> >> +-device qemu-xhci,id=xhci -device usb-kbd,bus=xhci.0
> >> +
> >> Running with KVM
> >>
> >>
> >> diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu-riscv.h
> >> index d5146e70f7..584559cfa3 100644
> >> --- a/include/configs/qemu-riscv.h
> >> +++ b/include/configs/qemu-riscv.h
> >> @@ -17,7 +17,7 @@
> >>
> >> /* Environment options */
> >>
> >> -#define CFG_STD_DEVICES_SETTINGS "stdin=serial\0" \
> >> +#define CFG_STD_DEVICES_SETTINGS "stdin=serial,usbkbd\0" \
> >>"stdout=serial,vidconsole\0" \
> >>"stderr=serial,vidconsole\0"
> >>
> >> --
> >> 2.34.1
> >>
> >>
>
Re: [PATCH 18/18] riscv: qemu: Enable usb keyboard as an input device
> From: Bin Meng
> Date: Sun, 23 Jul 2023 12:40:41 +0800
>
> This brings PCI xHCI support to QEMU RISC-V and uses a usb keyboard
> as one of the input devices.
>
> Signed-off-by: Bin Meng
>
> ---
>
> board/emulation/qemu-riscv/Kconfig | 5 +
> board/emulation/qemu-riscv/qemu-riscv.c | 5 +
> doc/board/emulation/qemu-riscv.rst | 5 +
> include/configs/qemu-riscv.h| 2 +-
> 4 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/board/emulation/qemu-riscv/Kconfig
> b/board/emulation/qemu-riscv/Kconfig
> index 7220c55350..b503578d27 100644
> --- a/board/emulation/qemu-riscv/Kconfig
> +++ b/board/emulation/qemu-riscv/Kconfig
> @@ -76,5 +76,10 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> imply VIDEO_BOCHS
> imply SYS_WHITE_ON_BLACK
> imply PRE_CONSOLE_BUFFER
> + imply USB
> + imply USB_XHCI_HCD
> + imply USB_XHCI_PCI
> + imply USB_KEYBOARD
> + imply CMD_USB
>
> endif
> diff --git a/board/emulation/qemu-riscv/qemu-riscv.c
> b/board/emulation/qemu-riscv/qemu-riscv.c
> index f39f3be366..181abbbf97 100644
> --- a/board/emulation/qemu-riscv/qemu-riscv.c
> +++ b/board/emulation/qemu-riscv/qemu-riscv.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -41,6 +42,10 @@ int board_init(void)
>
> int board_late_init(void)
> {
> + /* start usb so that usb keyboard can be used as input device */
> + if (CONFIG_IS_ENABLED(USB_KEYBOARD))
> + usb_init();
> +
This is typically handled by including "usb start" in CONFIG_PREBOOT,
which is done by boot/Kconfig. Any reason why that doesn't work for
you?
> return 0;
> }
>
> diff --git a/doc/board/emulation/qemu-riscv.rst
> b/doc/board/emulation/qemu-riscv.rst
> index 9d21f3270c..61137bcbf1 100644
> --- a/doc/board/emulation/qemu-riscv.rst
> +++ b/doc/board/emulation/qemu-riscv.rst
> @@ -138,6 +138,11 @@ and adding::
>
> -serial stdio -device VGA
>
> +In addition, a usb keyboard can be attached to an emulated xHCI controller in
> +RISC-V virt machine as an option of input devices by adding::
> +
> +-device qemu-xhci,id=xhci -device usb-kbd,bus=xhci.0
> +
> Running with KVM
>
>
> diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu-riscv.h
> index d5146e70f7..584559cfa3 100644
> --- a/include/configs/qemu-riscv.h
> +++ b/include/configs/qemu-riscv.h
> @@ -17,7 +17,7 @@
>
> /* Environment options */
>
> -#define CFG_STD_DEVICES_SETTINGS "stdin=serial\0" \
> +#define CFG_STD_DEVICES_SETTINGS "stdin=serial,usbkbd\0" \
> "stdout=serial,vidconsole\0" \
> "stderr=serial,vidconsole\0"
>
> --
> 2.34.1
>
>
Re: [PATCH] Makefile: Use sort shortopts
> From: Marek Vasut
> Date: Thu, 20 Jul 2023 14:50:42 +0200
>
> POSIX does not defined longopts for sort, use shortops
> for even more compatibility.
Even though OpenBSD's sort does implement the long options this is
still good to have!
Reviewed-by: Mark Kettenis
> Fixes: cc5a490cf465 ("Makefile: Sort u-boot-initial-env output")
> Reported-by: Milan P. Stanić
> Signed-off-by: Marek Vasut
> ---
> Cc: Christoph Niedermaier
> Cc: Marek Behún
> Cc: Simon Glass
> Cc: Stefano Babic
> Cc: u-b...@dh-electronics.com
> Cc: u-boot@lists.denx.de
> ---
> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 87f9fc786e8..5fc16b3b1f1 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2444,7 +2444,7 @@ quiet_cmd_genenv = GENENV $@
> cmd_genenv = \
> $(objtree)/tools/printinitialenv | \
> sed -e '/^\s*$$/d' | \
> - sort --field-separator='=' -k1,1 --stable -o $@
> + sort -t '=' -k 1,1 -s -o $@
>
> u-boot-initial-env: $(env_h) FORCE
> $(Q)$(MAKE) $(build)=tools $(objtree)/tools/printinitialenv
> --
> 2.40.1
>
>
Re: [PATCH] bootstd: Make efi_mgr bootmeth work for non-sandbox setups
> Date: Fri, 14 Jul 2023 22:21:04 +0200
> From: Heinrich Schuchardt
Hi Heinrich,
> Am 14. Juli 2023 21:56:02 MESZ schrieb Mark Kettenis :
> >Enable the bootflow based on this bootmeth if the BootOrder EFI
> >variable is set.
> >
> >Signed-off-by: Mark Kettenis
> >---
> > boot/bootmeth_efi_mgr.c | 12 +++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> >diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c
> >index e9d973429f..db650861ff 100644
> >--- a/boot/bootmeth_efi_mgr.c
> >+++ b/boot/bootmeth_efi_mgr.c
> >@@ -14,6 +14,8 @@
> > #include
> > #include
> > #include
> >+#include
> >+#include
> >
> > /**
> > * struct efi_mgr_priv - private info for the efi-mgr driver
> >@@ -46,13 +48,21 @@ static int efi_mgr_check(struct udevice *dev, struct
> >bootflow_iter *iter)
> > static int efi_mgr_read_bootflow(struct udevice *dev, struct bootflow
> > *bflow)
> > {
> > struct efi_mgr_priv *priv = dev_get_priv(dev);
> >+efi_uintn_t size;
> >+u16 *bootorder;
> >
> > if (priv->fake_dev) {
> > bflow->state = BOOTFLOWST_READY;
> > return 0;
> > }
> >
> >-/* To be implemented */
> >+/* Enable this method if the "BootOrder" UEFI exists. */
> >+bootorder = efi_get_var(u"BootOrder", _global_variable_guid,
> >+);
>
> Are EFI variables already loaded when you hit this code?
They are in my case since I have some board code initializes the EFI
subsystem early. But in general it would not. So I guess this would
need a call to efi_init_obj_list().
> Even if the variable Boot Order is not set we must boot
> EFI/BOOT/BOOT.EFI.
That will still happen. If the efi_mgr method fails, standard boot
will iterate over devices and use the efi method to boot from the
default path.
> >+if (bootorder) {
> >+bflow->state = BOOTFLOWST_READY;
> >+return 0;
> >+}
> >
> > return -EINVAL;
> > }
>
Re: [PATCH 3/3] usb: xhci-pci: Load ASMedia XHCI controller firmware
> Date: Fri, 14 Jul 2023 23:30:43 +0200 > From: Marek Vasut Hi Marek, Your suggestions are reasonable, but would make the driver deviate further from its Linux equivalent: https://github.com/AsahiLinux/linux/blob/asahi/drivers/usb/host/xhci-pci-asmedia.c Right now I can actually easily diff the two drivers to pick up improvements. Changing things the way you suggest would make that harder. Cheers, Mark > On 7/14/23 22:43, Mark Kettenis wrote: > > The ASMedia XHCI controller found on some of the Apple Silicon > > machines needs firmware to operate. Use the file system > > firmware loader interface to read the firmware and load it > > onto the controller. This allows keyboards connected to the > > type-A ports on these machines to function in U-Boot. > > > > Signed-off-by: Mark Kettenis > > --- > > MAINTAINERS | 1 + > > drivers/usb/host/Kconfig| 11 + > > drivers/usb/host/Makefile | 1 + > > drivers/usb/host/xhci-pci-asmedia.c | 394 > > drivers/usb/host/xhci-pci.c | 9 + > > include/usb/xhci.h | 3 + > > 6 files changed, 419 insertions(+) > > create mode 100644 drivers/usb/host/xhci-pci-asmedia.c > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 2477923a52..0acf04fff8 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -124,6 +124,7 @@ F: drivers/iommu/apple_dart.c > > F:drivers/nvme/nvme_apple.c > > F:drivers/pci/pcie_apple.c > > F:drivers/pinctrl/pinctrl-apple.c > > +F: drivers/usb/host/xhci-pci-asmedia.c > > F:drivers/watchdog/apple_wdt.c > > F:include/configs/apple.h > > > > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig > > index 1a883babf4..ad8dfabeeb 100644 > > --- a/drivers/usb/host/Kconfig > > +++ b/drivers/usb/host/Kconfig > > @@ -95,6 +95,17 @@ config USB_XHCI_PCI > > help > > Enables support for the PCI-based xHCI controller. > > > > +config USB_XHCI_PCI_ASMEDIA > > + bool "Support for ASMedia xHCI USB controller" > > + depends on USB_XHCI_PCI > > + default y if ARCH_APPLE > > + imply FS_LOADER > > + help > > + Enables support for loading firmware for the ASMedia xHCI > > + controller. This is needed on Apple Silicon machines that > > + contain ASMedia xHCI controllers without the full USB > > + firmware. > > + > > config USB_XHCI_RCAR > > bool "Renesas RCar USB 3.0 support" > > default y > > diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile > > index 8dad36f936..2aa2d80263 100644 > > --- a/drivers/usb/host/Makefile > > +++ b/drivers/usb/host/Makefile > > @@ -52,6 +52,7 @@ obj-$(CONFIG_USB_XHCI_MTK) += xhci-mtk.o > > obj-$(CONFIG_USB_XHCI_MVEBU) += xhci-mvebu.o > > obj-$(CONFIG_USB_XHCI_OMAP) += xhci-omap.o > > obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o > > +obj-$(CONFIG_USB_XHCI_PCI_ASMEDIA) += xhci-pci-asmedia.o > > obj-$(CONFIG_USB_XHCI_RCAR) += xhci-rcar.o > > obj-$(CONFIG_USB_XHCI_STI) += dwc3-sti-glue.o > > obj-$(CONFIG_USB_XHCI_OCTEON) += dwc3-octeon-glue.o > > diff --git a/drivers/usb/host/xhci-pci-asmedia.c > > b/drivers/usb/host/xhci-pci-asmedia.c > > new file mode 100644 > > index 00..cc1d25bde2 > > --- /dev/null > > +++ b/drivers/usb/host/xhci-pci-asmedia.c > > @@ -0,0 +1,394 @@ > > +// SPDX-License-Identifier: GPL-2.0 OR MIT > > +/* > > + * ASMedia xHCI firmware loader > > + * Copyright (C) The Asahi Linux Contributors > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +/* Configuration space registers */ > > +#define ASMT_CFG_CONTROL 0xe0 > > +#define ASMT_CFG_CONTROL_WRITE BIT(1) > > +#define ASMT_CFG_CONTROL_READ BIT(0) > > + > > +#define ASMT_CFG_SRAM_ADDR 0xe2 > > + > > +#define ASMT_CFG_SRAM_ACCESS 0xef > > +#define ASMT_CFG_SRAM_ACCESS_READ BIT(6) > > +#define ASMT_CFG_SRAM_ACCESS_ENABLEBIT(7) > > + > > +#define ASMT_CFG_DATA_READ00xf0 > > +#define ASMT_CFG_DATA_READ10xf4 > > + > > +#define ASMT_CFG_DATA_WRITE0 0xf8 > > +#define ASMT_CFG_DATA_WRITE1 0xfc > > + > > +#define ASMT_CMD_GET_FWVER 0x860840 &
Re: [PATCH 1/3] apple: Set up file system firmware loader
> Date: Fri, 14 Jul 2023 23:27:42 +0200
> From: Marek Vasut
>
> On 7/14/23 22:43, Mark Kettenis wrote:
> > Find the appropriate EFI system partition on the internal NVMe
> > storage and set the U-Boot environment variables such that
> > the file system firmware loader can load firmware from it.
> >
> > Signed-off-by: Mark Kettenis
> > ---
> > arch/arm/mach-apple/board.c | 60 +
> > 1 file changed, 60 insertions(+)
> >
> > diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
> > index d501948118..7799a0f916 100644
> > --- a/arch/arm/mach-apple/board.c
> > +++ b/arch/arm/mach-apple/board.c
> > @@ -8,6 +8,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> >
> > #include
> > #include
> > @@ -539,6 +541,60 @@ u64 get_page_table_size(void)
> > return SZ_256K;
> > }
> >
> > +static char *asahi_esp_devpart(void)
> > +{
> > + struct disk_partition info;
> > + struct blk_desc *nvme_blk;
> > + const char *uuid = NULL;
> > + int devnum, len, p, part, ret;
> > + static char devpart[64];
> > + struct udevice *dev;
> > + ofnode node;
> > +
> > + if (devpart[0])
> > + return devpart;
> > +
> > + node = ofnode_path("/chosen");
> > + if (ofnode_valid(node)) {
> > + uuid = ofnode_get_property(node, "asahi,efi-system-partition",
> > + );
> > + }
> > +
> > + nvme_scan_namespace();
> > + for (devnum = 0, part = 0;; devnum++) {
> > + nvme_blk = blk_get_devnum_by_uclass_id(UCLASS_NVME, devnum);
> > + if (nvme_blk == NULL)
> > + break;
> > +
> > + dev = dev_get_parent(nvme_blk->bdev);
> > + if (!device_is_compatible(dev, "apple,nvme-ans2"))
>
> Can we somehow use ofnode_for_each_compatible_node() here ?
> That might simplify this code.
I don't really see how that would simplify things. I'm iterating over
all NVMe devices here and then checking the compatible of the parent
to make sure I pick the on-board one. I could do the inverse and
lookup the node first and then use that to find the NVMe block device,
but it will still involve a loop and several function calls.
>
> > + continue;
> > +
> > + for (p = 1; p <= MAX_SEARCH_PARTITIONS; p++) {
> > + ret = part_get_info(nvme_blk, p, );
> > + if (ret < 0)
> > + break;
> > +
> > + if (info.bootable & PART_EFI_SYSTEM_PARTITION) {
> > + if (uuid && strcasecmp(uuid, info.uuid) == 0) {
> > + part = p;
> > + break;
> > + }
> > + if (part == 0)
> > + part = p;
> > + }
> > + }
> > +
> > + if (part > 0)
> > + break;
> > + }
> > +
> > + if (part > 0)
> > + snprintf(devpart, sizeof(devpart), "%d:%d", devnum, part);
> > +
> > + return devpart;
> > +}
> > +
> > #define KERNEL_COMP_SIZE SZ_128M
> >
> > int board_late_init(void)
> > @@ -546,6 +602,10 @@ int board_late_init(void)
> > struct lmb lmb;
> > u32 status = 0;
> >
> > + status |= env_set("storage_interface",
> > + blk_get_uclass_name(UCLASS_NVME));
> > + status |= env_set("fw_dev_part", asahi_esp_devpart());
>
> I think env_set() returns integer (and this could be negative too), so
> you might want to check the return value instead of casting it to
> unsigned integer.
I'm just using the existing idiom. But maybe I should just check the
return value and throw a warning instead? Not having the firmware
loader available isn't fatal. It just means some of the USB ports
won't work.
Re: [PATCH 2/3] iopoll: Add readb_poll_sleep_timeout
> Date: Fri, 14 Jul 2023 23:22:00 +0200 > From: Marek Vasut > > On 7/14/23 22:43, Mark Kettenis wrote: > > Add a variant of readl_poll_sleep_timeout that reads a single > > byte to match the readb_poll_timeout API that Linux has. > > > > Signed-off-by: Mark Kettenis > > --- > > include/linux/iopoll.h | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/include/linux/iopoll.h b/include/linux/iopoll.h > > index 0ee2bddaa8..89990e95e9 100644 > > --- a/include/linux/iopoll.h > > +++ b/include/linux/iopoll.h > > @@ -49,6 +49,9 @@ > > #define readl_poll_sleep_timeout(addr, val, cond, sleep_us, timeout_us) \ > > readx_poll_sleep_timeout(readl, addr, val, cond, sleep_us, timeout_us) > > > > +#define readb_poll_sleep_timeout(addr, val, cond, sleep_us, timeout_us) \ > > + readx_poll_sleep_timeout(readb, addr, val, cond, sleep_us, timeout_us) > > readb variant should go before readl variant I think. That makes to order consistent, so that makes sense. I'll fix that in the next revision.
[PATCH 3/3] usb: xhci-pci: Load ASMedia XHCI controller firmware
The ASMedia XHCI controller found on some of the Apple Silicon
machines needs firmware to operate. Use the file system
firmware loader interface to read the firmware and load it
onto the controller. This allows keyboards connected to the
type-A ports on these machines to function in U-Boot.
Signed-off-by: Mark Kettenis
---
MAINTAINERS | 1 +
drivers/usb/host/Kconfig| 11 +
drivers/usb/host/Makefile | 1 +
drivers/usb/host/xhci-pci-asmedia.c | 394
drivers/usb/host/xhci-pci.c | 9 +
include/usb/xhci.h | 3 +
6 files changed, 419 insertions(+)
create mode 100644 drivers/usb/host/xhci-pci-asmedia.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 2477923a52..0acf04fff8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -124,6 +124,7 @@ F: drivers/iommu/apple_dart.c
F: drivers/nvme/nvme_apple.c
F: drivers/pci/pcie_apple.c
F: drivers/pinctrl/pinctrl-apple.c
+F: drivers/usb/host/xhci-pci-asmedia.c
F: drivers/watchdog/apple_wdt.c
F: include/configs/apple.h
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 1a883babf4..ad8dfabeeb 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -95,6 +95,17 @@ config USB_XHCI_PCI
help
Enables support for the PCI-based xHCI controller.
+config USB_XHCI_PCI_ASMEDIA
+ bool "Support for ASMedia xHCI USB controller"
+ depends on USB_XHCI_PCI
+ default y if ARCH_APPLE
+ imply FS_LOADER
+ help
+ Enables support for loading firmware for the ASMedia xHCI
+ controller. This is needed on Apple Silicon machines that
+ contain ASMedia xHCI controllers without the full USB
+ firmware.
+
config USB_XHCI_RCAR
bool "Renesas RCar USB 3.0 support"
default y
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 8dad36f936..2aa2d80263 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_USB_XHCI_MTK) += xhci-mtk.o
obj-$(CONFIG_USB_XHCI_MVEBU) += xhci-mvebu.o
obj-$(CONFIG_USB_XHCI_OMAP) += xhci-omap.o
obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
+obj-$(CONFIG_USB_XHCI_PCI_ASMEDIA) += xhci-pci-asmedia.o
obj-$(CONFIG_USB_XHCI_RCAR) += xhci-rcar.o
obj-$(CONFIG_USB_XHCI_STI) += dwc3-sti-glue.o
obj-$(CONFIG_USB_XHCI_OCTEON) += dwc3-octeon-glue.o
diff --git a/drivers/usb/host/xhci-pci-asmedia.c
b/drivers/usb/host/xhci-pci-asmedia.c
new file mode 100644
index 00..cc1d25bde2
--- /dev/null
+++ b/drivers/usb/host/xhci-pci-asmedia.c
@@ -0,0 +1,394 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * ASMedia xHCI firmware loader
+ * Copyright (C) The Asahi Linux Contributors
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Configuration space registers */
+#define ASMT_CFG_CONTROL 0xe0
+#define ASMT_CFG_CONTROL_WRITE BIT(1)
+#define ASMT_CFG_CONTROL_READ BIT(0)
+
+#define ASMT_CFG_SRAM_ADDR 0xe2
+
+#define ASMT_CFG_SRAM_ACCESS 0xef
+#define ASMT_CFG_SRAM_ACCESS_READ BIT(6)
+#define ASMT_CFG_SRAM_ACCESS_ENABLEBIT(7)
+
+#define ASMT_CFG_DATA_READ00xf0
+#define ASMT_CFG_DATA_READ10xf4
+
+#define ASMT_CFG_DATA_WRITE0 0xf8
+#define ASMT_CFG_DATA_WRITE1 0xfc
+
+#define ASMT_CMD_GET_FWVER 0x860840
+#define ASMT_FWVER_ROM 0x010250090816
+
+/* BAR0 registers */
+#define ASMT_REG_ADDR 0x3000
+
+#define ASMT_REG_WDATA 0x3004
+#define ASMT_REG_RDATA 0x3008
+
+#define ASMT_REG_STATUS0x3009
+#define ASMT_REG_STATUS_BUSY BIT(7)
+
+#define ASMT_REG_CODE_WDATA0x3010
+#define ASMT_REG_CODE_RDATA0x3018
+
+#define ASMT_MMIO_CPU_MISC 0x500e
+#define ASMT_MMIO_CPU_MISC_CODE_RAM_WR BIT(0)
+
+#define ASMT_MMIO_CPU_MODE_NEXT0x5040
+#define ASMT_MMIO_CPU_MODE_CUR 0x5041
+
+#define ASMT_MMIO_CPU_MODE_RAM BIT(0)
+#define ASMT_MMIO_CPU_MODE_HALFSPEED BIT(1)
+
+#define ASMT_MMIO_CPU_EXEC_CTRL0x5042
+#define ASMT_MMIO_CPU_EXEC_CTRL_RESET BIT(0)
+#define ASMT_MMIO_CPU_EXEC_CTRL_HALT BIT(1)
+
+#define TIMEOUT_USEC 1
+#define RESET_TIMEOUT_USEC 50
+
+static int asmedia_mbox_tx(struct udevice *pdev, u64 data)
+{
+ u8 op;
+ int i;
+
+ for (i = 0; i < TIMEOUT_USEC; i++) {
+ dm_pci_read_config8(pdev, ASMT_CFG_CONTROL, );
+ if (!(op & ASMT_CFG_CONTROL_WRITE))
+ break;
+ udelay(1);
+ }
+
+ if (op & ASMT_CFG_CONTROL_WRITE) {
+ dev_err(pdev,
+ "Timed out on mailbox tx: 0x%llx\n",
+
[PATCH 2/3] iopoll: Add readb_poll_sleep_timeout
Add a variant of readl_poll_sleep_timeout that reads a single byte to match the readb_poll_timeout API that Linux has. Signed-off-by: Mark Kettenis --- include/linux/iopoll.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/iopoll.h b/include/linux/iopoll.h index 0ee2bddaa8..89990e95e9 100644 --- a/include/linux/iopoll.h +++ b/include/linux/iopoll.h @@ -49,6 +49,9 @@ #define readl_poll_sleep_timeout(addr, val, cond, sleep_us, timeout_us) \ readx_poll_sleep_timeout(readl, addr, val, cond, sleep_us, timeout_us) +#define readb_poll_sleep_timeout(addr, val, cond, sleep_us, timeout_us) \ + readx_poll_sleep_timeout(readb, addr, val, cond, sleep_us, timeout_us) + #define readx_poll_timeout(op, addr, val, cond, timeout_us) \ read_poll_timeout(op, val, cond, false, timeout_us, addr) -- 2.41.0
[PATCH 1/3] apple: Set up file system firmware loader
Find the appropriate EFI system partition on the internal NVMe
storage and set the U-Boot environment variables such that
the file system firmware loader can load firmware from it.
Signed-off-by: Mark Kettenis
---
arch/arm/mach-apple/board.c | 60 +
1 file changed, 60 insertions(+)
diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
index d501948118..7799a0f916 100644
--- a/arch/arm/mach-apple/board.c
+++ b/arch/arm/mach-apple/board.c
@@ -8,6 +8,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -539,6 +541,60 @@ u64 get_page_table_size(void)
return SZ_256K;
}
+static char *asahi_esp_devpart(void)
+{
+ struct disk_partition info;
+ struct blk_desc *nvme_blk;
+ const char *uuid = NULL;
+ int devnum, len, p, part, ret;
+ static char devpart[64];
+ struct udevice *dev;
+ ofnode node;
+
+ if (devpart[0])
+ return devpart;
+
+ node = ofnode_path("/chosen");
+ if (ofnode_valid(node)) {
+ uuid = ofnode_get_property(node, "asahi,efi-system-partition",
+ );
+ }
+
+ nvme_scan_namespace();
+ for (devnum = 0, part = 0;; devnum++) {
+ nvme_blk = blk_get_devnum_by_uclass_id(UCLASS_NVME, devnum);
+ if (nvme_blk == NULL)
+ break;
+
+ dev = dev_get_parent(nvme_blk->bdev);
+ if (!device_is_compatible(dev, "apple,nvme-ans2"))
+ continue;
+
+ for (p = 1; p <= MAX_SEARCH_PARTITIONS; p++) {
+ ret = part_get_info(nvme_blk, p, );
+ if (ret < 0)
+ break;
+
+ if (info.bootable & PART_EFI_SYSTEM_PARTITION) {
+ if (uuid && strcasecmp(uuid, info.uuid) == 0) {
+ part = p;
+ break;
+ }
+ if (part == 0)
+ part = p;
+ }
+ }
+
+ if (part > 0)
+ break;
+ }
+
+ if (part > 0)
+ snprintf(devpart, sizeof(devpart), "%d:%d", devnum, part);
+
+ return devpart;
+}
+
#define KERNEL_COMP_SIZE SZ_128M
int board_late_init(void)
@@ -546,6 +602,10 @@ int board_late_init(void)
struct lmb lmb;
u32 status = 0;
+ status |= env_set("storage_interface",
+ blk_get_uclass_name(UCLASS_NVME));
+ status |= env_set("fw_dev_part", asahi_esp_devpart());
+
lmb_init_and_reserve(, gd->bd, (void *)gd->fdt_blob);
/* somewhat based on the Linux Kernel boot requirements:
--
2.41.0
[PATCH 0/3] Load ASMedia XHCI controller firmware
Some of the Apple desktop machine have a PCI ASMedia XHCI controller that needs firmware to be uploaded to function. This firmware is placed on the EFI system partition by the Asahi installer. So this series sets up a file system firmware loader that reads from that partition and ports the Linux driver that uploads this firmware to the controller. With this series, users can use USB devices (such as a keyboard) when they are connected to USB ports handled by the ASMedia XHCI controller. This includes the type-A ports on the M2 Mac mini for example. Mark Kettenis (3): apple: Set up file system firmware loader iopoll: Add readb_poll_sleep_timeout usb: xhci-pci: Load ASMedia XHCI controller firmware MAINTAINERS | 1 + arch/arm/mach-apple/board.c | 60 + drivers/usb/host/Kconfig| 11 + drivers/usb/host/Makefile | 1 + drivers/usb/host/xhci-pci-asmedia.c | 394 drivers/usb/host/xhci-pci.c | 9 + include/linux/iopoll.h | 3 + include/usb/xhci.h | 3 + 8 files changed, 482 insertions(+) create mode 100644 drivers/usb/host/xhci-pci-asmedia.c -- 2.41.0
