Re: [PATCH 1/4] tools: mkeficapsule: Add support for parsing capsule params from config file
hi Ilias, On Wed, 22 Nov 2023 at 13:06, Ilias Apalodimas wrote: > > Hi all, > > On Wed, 22 Nov 2023 at 07:23, Sughosh Ganu wrote: > > > > hi Simon, > > > > On Wed, 22 Nov 2023 at 03:42, Simon Glass wrote: > > > > > > Hi Sughosh, > > > > > > On Tue, 21 Nov 2023 at 00:02, Sughosh Ganu > > > wrote: > > > > > > > > Add support for specifying the parameters needed for capsule > > > > generation through a config file, instead of passing them through > > > > command-line. Parameters for more than a single capsule file can be > > > > specified, resulting in generation of multiple capsules through a > > > > single invocation of the command. > > > > > > > > The config file can then be passed to the mkeficapsule tool in such > > > > manner > > > > > > > > $ ./tools/mkeficapsule -f > > > > > > > > Signed-off-by: Sughosh Ganu > > > > --- > > > > tools/Kconfig | 15 ++ > > > > tools/Makefile | 1 + > > > > tools/eficapsule.h | 114 > > > > tools/mkeficapsule.c | 87 + > > > > tools/mkeficapsule_parse.c | 352 + > > > > 5 files changed, 538 insertions(+), 31 deletions(-) > > > > create mode 100644 tools/mkeficapsule_parse.c > > > > > > This patch keeps coming back :-) > > > > > > Can we not add multiple capsules in the binman description? Why do we > > > need a new file format? How can binman decode images produced in this > > > way? > > > > So as Tom mentions, this brings parity with respect to the other > > capsule generation tool in EDKII that generates capsules. IIRC, this > > is something which even Xilix was interested in, and Michal had kind > > of gone through these patches earlier. Lastly, it would be good to > > have support in U-Boot's mkeficapsule tool for generating a single > > capsule file with multiple payloads, and having support for this > > functionality helps in that goal. > > > > Also, you might have noticed that, since your objection to the last > > series, I have removed putting this in binman. So now, this aspect of > > the capsule generation would only be supported through the > > command-line invocation of the tool. > > I think that overall the approach is sane. mkeficapsule is currently > supported and compiled for distros, so the multiple payload support is > useful. If we want to add support to binman, instead of rewriting this > in python, we could just call that tool for parsing and creating > capsules Given the amount of time these patches have been under review(also number of iterations), I would request that this series be reviewed and merged first. I think there is general consensus that there is value to have this functionality in the mkeficapsule tool. If it is deemed fit to support this through binman as well, that task can be taken up separately. Thanks. -sughosh > > Thanks > /Ilias > > > > > > > > Also, could we get sandbox to produce one EFI capsule as part of the > > > normal build? I think that discussion trailed off. > > > > Yes, apologies for missing out on this. Slipped my mind. Would you > > want, say, all the non-signed capsules to be generated as part of the > > sandbox build? > > > > -sughosh
Re: [PATCH 6/7] WIP: efi: Allow helloworld to exit boot services
Hi Simon,
On Wed, 22 Nov 2023 at 00:10, Simon Glass wrote:
>
> Hi Heinrich,
>
> On Tue, 21 Nov 2023 at 10:17, Heinrich Schuchardt wrote:
> >
> > On 11/21/23 12:35, Simon Glass wrote:
> > > This allows testing of the exit_boot_services call, providing more
> > > coverage of the EFI bootmeth.
> > >
> > > Signed-off-by: Simon Glass
> >
> > I would prefer to keep helloworld.efi benign.
> >
> > Please, create a new EFI binary for testing ExitBootServices().
>
> Eek...isn't helloworld already used in tets?\
Yes, but calling exitboot services from it means we need to be really
careful when/how we call it, since once that app runs the boottime
services along with any attached disks will disappear.
Instead having a single EFI app that calls that and then tests for any
runtime services is more scalable
Thanks
/Ilias
>
> >
> > > ---
> > >
> > > lib/efi_loader/helloworld.c | 36 +++-
> > > 1 file changed, 35 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/lib/efi_loader/helloworld.c b/lib/efi_loader/helloworld.c
> > > index 1135d3a3c37e..1fb5fb5a62f2 100644
> > > --- a/lib/efi_loader/helloworld.c
> > > +++ b/lib/efi_loader/helloworld.c
> > > @@ -206,6 +206,26 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
> > > (con_out, u"Cannot open loaded image protocol\r\n");
> > > goto out;
> > > }
> > > +
> > > + {
> > > + ulong ptr = (ulong)loaded_image;
> > > + u16 str[80];
> > > + int i;
> > > +
> > > + for (i = 0; i < 8; i++) {
> > > + uint digit = (ptr >> ((7 - i) * 4)) & 0xf;
> > > +
> > > + if (digit > 9)
> > > + digit = 'a' + digit - 10;
> > > + else
> > > + digit += '0';
> > > + str[i] = digit;
> > > + }
> > > + str[i] = 0;
> > > + con_out->output_string(con_out, str);
> > > + con_out->output_string(con_out, u"\n");
> > > + }
> > > +
> > > print_load_options(loaded_image);
> > >
> > > /* Get the device path to text protocol */
> > > @@ -243,7 +263,21 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
> > > goto out;
> > >
> > > out:
> > > - boottime->exit(handle, ret, 0, NULL);
> > > + /*
> > > + * TODO: Use vendor string to decide whether to call
> > > exit-boot-services
> > > + */
> > > + efi_uintn_t map_size = 0;
> > > + efi_uintn_t map_key;
> > > + efi_uintn_t desc_size;
> > > + u32 desc_version;
> > > +
> > > + ret = boottime->get_memory_map(_size, NULL, _key,
> > > _size,
> > > +_version);
> > > + con_out->output_string(con_out, u"Exiting boot sevices\n");
> > > +
> > > + boottime->exit_boot_services(handle, map_key);
> > > +
> > > + ret = boottime->exit(handle, ret, 0, NULL);
> >
> > After ExitBootServices() you must not call boot services.
> >
> > Call runtime->reset_system(EFI_RESET_COLD, EFI_SUCCESS, 0, NULL) instead.
>
> OK, will do. That will be ignored by sandbox, right?
>
> For now this is just a hack to try to resolve the problem mentioned.
>
> Regards,
> Simon
Re: [PATCH 1/4] tools: mkeficapsule: Add support for parsing capsule params from config file
Hi all, On Wed, 22 Nov 2023 at 07:23, Sughosh Ganu wrote: > > hi Simon, > > On Wed, 22 Nov 2023 at 03:42, Simon Glass wrote: > > > > Hi Sughosh, > > > > On Tue, 21 Nov 2023 at 00:02, Sughosh Ganu wrote: > > > > > > Add support for specifying the parameters needed for capsule > > > generation through a config file, instead of passing them through > > > command-line. Parameters for more than a single capsule file can be > > > specified, resulting in generation of multiple capsules through a > > > single invocation of the command. > > > > > > The config file can then be passed to the mkeficapsule tool in such > > > manner > > > > > > $ ./tools/mkeficapsule -f > > > > > > Signed-off-by: Sughosh Ganu > > > --- > > > tools/Kconfig | 15 ++ > > > tools/Makefile | 1 + > > > tools/eficapsule.h | 114 > > > tools/mkeficapsule.c | 87 + > > > tools/mkeficapsule_parse.c | 352 + > > > 5 files changed, 538 insertions(+), 31 deletions(-) > > > create mode 100644 tools/mkeficapsule_parse.c > > > > This patch keeps coming back :-) > > > > Can we not add multiple capsules in the binman description? Why do we > > need a new file format? How can binman decode images produced in this > > way? > > So as Tom mentions, this brings parity with respect to the other > capsule generation tool in EDKII that generates capsules. IIRC, this > is something which even Xilix was interested in, and Michal had kind > of gone through these patches earlier. Lastly, it would be good to > have support in U-Boot's mkeficapsule tool for generating a single > capsule file with multiple payloads, and having support for this > functionality helps in that goal. > > Also, you might have noticed that, since your objection to the last > series, I have removed putting this in binman. So now, this aspect of > the capsule generation would only be supported through the > command-line invocation of the tool. I think that overall the approach is sane. mkeficapsule is currently supported and compiled for distros, so the multiple payload support is useful. If we want to add support to binman, instead of rewriting this in python, we could just call that tool for parsing and creating capsules Thanks /Ilias > > > > > Also, could we get sandbox to produce one EFI capsule as part of the > > normal build? I think that discussion trailed off. > > Yes, apologies for missing out on this. Slipped my mind. Would you > want, say, all the non-signed capsules to be generated as part of the > sandbox build? > > -sughosh
Re: [PATCH 00/21] Qualcomm generic board support
On Tue, 21 Nov 2023 at 22:39, 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) 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.
>
> == defconfig ==
>
> Most of the board defconfigs and config headers were quite similar, to
> simplify maintenance going forward, all the fully generic boards (sdm845
> and qcs404-evb so far) are adapted to use the new qcom_defconfig. Going
> forward, all new Qualcomm boards should be supported by this defconfig.
> A notable exception is for specific usecases (like U-Boot as the primary
> bootloader).
>
> == The older dragonboards ==
>
> The db410c and db820c both have some custom board init code, as a result
> they aren't yet binary compatible. mach-snapdragon is adjusted so
> that all the necessary config options (e.g. CONFIG_SYS_BOARD) can be set
> from their defconfigs, this makes it possible to enable support for new
> boards without introducing additional config options.
>
> The db410c can run U-Boot either chainloaded like the other boards, or
> as a first-stage bootloader replacing aboot. However it was hardcoded to
> only build for the latter option. This series introduces a new
> "chainloaded" defconfig to enable easier testing via fastboot.
>
> == dynamic environment variables ==
>
> This series also introduces runtime-allocated load addresses via the lmb
> allocator. This allows for booting on boards with vastly different
> memory layouts without any pre-calculation or macro magic in the config
> header. This feature is based on similar code in mach-apple.
>
> The soc, board, and fdtfile environment variables are also generated
> automatically. Many Qualcomm boards follow a similar scheme for DTB
> naming such that the name can often be derived from the root compatible
> properties. This is intended to cover the most common cases and be a
> simple solution for booting generic distro images without having to
> explicitly choose the right DTB. The U-Boot DTS can be tweaked if
> necessary to produce the correct name, the variable can be overwritten,
> or a bootloader like GRUB can load the devicetree instead.
>
> == Upstream DT ==
>
> All Qualcomm boards have had their devicetree files rewritten to be
> based on the upstream SoC/PMIC DTSI files. Previous patch series made
> the necessary driver adjustments to fully support the upstream DT
> format. All future Qualcomm boards should use upstream DTS by default.
>
> ---
> I have tested this series on the Dragonboard410c, Dragonboard820c, and
> Dragonboard845c. I unfortunately don't have access to a QCS404 EVB board
> to test.
I would be happy to test it on QCS404 but your PMIC fixes series is
Re: [PATCH v1 2/3] efi_vars: Implement SPI Flash store
Hi Shahtur
On Wed, 22 Nov 2023 at 01:58, Shantur Rathore wrote:
>
> Currently U-boot uses ESP as storage for EFI variables.
> Devices with SPI Flash are used for storing environment with this
> commit we allow EFI variables to be stored on SPI Flash.
>
> Signed-off-by: Shantur Rathore
> ---
>
> include/efi_variable.h| 25 ++
> lib/efi_loader/Kconfig| 18 +++
> lib/efi_loader/Makefile | 1 +
> lib/efi_loader/efi_var_sf.c | 91 +++
> lib/efi_loader/efi_variable.c | 4 ++
> 5 files changed, 139 insertions(+)
> create mode 100644 lib/efi_loader/efi_var_sf.c
>
> diff --git a/include/efi_variable.h b/include/efi_variable.h
> index ca7e19d514..766dd109f5 100644
> --- a/include/efi_variable.h
> +++ b/include/efi_variable.h
> @@ -188,6 +188,31 @@ efi_status_t efi_var_from_file(void);
>
> #endif // CONFIG_EFI_VARIABLE_FILE_STORE
>
> +#ifdef CONFIG_EFI_VARIABLE_SF_STORE
> +
> +/**
> + * efi_var_from_sf() - read variables from SPI Flash
> + *
> + * EFI variable buffer is read from SPI Flash at offset defined with
> + * CONFIG_EFI_VARIABLE_SF_OFFSET of length CONFIG_EFI_VAR_BUF_SIZE
> + *
> + *
> + * Return: status code
> + */
> +efi_status_t efi_var_from_sf(void);
> +
> +/**
> + * efi_var_to_sf() - save non-volatile variables to SPI Flash
> + *
> + * EFI variable buffer is saved to SPI Flash at offset defined with
> + * CONFIG_EFI_VARIABLE_SF_OFFSET of length CONFIG_EFI_VAR_BUF_SIZE.
> + *
> + * Return: status code
> + */
> +efi_status_t efi_var_to_sf(void);
> +
> +#endif // CONFIG_EFI_VARIABLE_SF_STORE
> +
> /**
> * efi_var_mem_init() - set-up variable list
> *
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index 4ccd26f94a..1fcc6fabb4 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -54,6 +54,17 @@ 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_VARIABLE_SF_STORE
> + bool "Store non-volatile UEFI variables in SPI Flash"
> + depends on SPI_FLASH
> + help
> + Select this option if you want non-volatile UEFI variables to be
> + stored in SPI Flash.
> + Define CONFIG_EFI_VARIABLE_SF_OFFSET as offset in SPI Flash to use
> as
> + the storage for variables. CONFIG_EFI_VAR_BUF_SIZE defines the space
> + needed.
> +
> +
> config EFI_MM_COMM_TEE
> bool "UEFI variables storage service via the trusted world"
> depends on OPTEE
> @@ -108,6 +119,13 @@ config EFI_VARIABLE_NO_STORE
>
> endchoice
>
> +config EFI_VARIABLE_SF_OFFSET
> + hex "EFI variables in SPI flash offset"
> + depends on EFI_VARIABLE_SF_STORE
> + default 0x7D
> + help
> + Offset from the start of the SPI Flash where EFI variables will be
> stored.
> +
> config EFI_VARIABLES_PRESEED
> bool "Initial values for UEFI variables"
> depends on !EFI_MM_COMM_TEE
> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
> index 8d31fc61c6..b9b715b1ff 100644
> --- a/lib/efi_loader/Makefile
> +++ b/lib/efi_loader/Makefile
> @@ -67,6 +67,7 @@ obj-$(CONFIG_EFI_UNICODE_COLLATION_PROTOCOL2) +=
> efi_unicode_collation.o
> obj-y += efi_var_common.o
> obj-y += efi_var_mem.o
> obj-y += efi_var_file.o
> +obj-$(CONFIG_EFI_VARIABLE_SF_STORE) += efi_var_sf.o
> ifeq ($(CONFIG_EFI_MM_COMM_TEE),y)
> obj-y += efi_variable_tee.o
> else
> diff --git a/lib/efi_loader/efi_var_sf.c b/lib/efi_loader/efi_var_sf.c
> new file mode 100644
> index 00..e604a2225c
> --- /dev/null
> +++ b/lib/efi_loader/efi_var_sf.c
> @@ -0,0 +1,91 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * File interface for UEFI variables
> + *
> + * Copyright (c) 2023, Shantur Rtahore
Name is misspelled
> + */
> +
> +#define LOG_CATEGORY LOGC_EFI
> +
> +#include
> +#include
> +#include
> +#include
> +
> +efi_status_t efi_var_to_sf(void)
> +{
> + efi_status_t ret;
> + struct efi_var_file *buf;
> + loff_t len;
> + struct udevice *sfdev;
> +
> + ret = efi_var_collect(, , EFI_VARIABLE_NON_VOLATILE);
> + if (len > EFI_VAR_BUF_SIZE) {
> + log_err("EFI var buffer length more than target SF size");
> + ret = EFI_BAD_BUFFER_SIZE;
The UEFI spec doesn't define this return code for SetVariable.
Instead, EFI_OUT_OF_RESOURCES is used when the available storage isn't
enough to hold the variable and its data.
> + goto error;
> + }
> +
> + debug("%s - Got buffer to write buf->len : %d\n", __func__,
> buf->length);
> +
> + if (ret != EFI_SUCCESS)
> + goto error;
> +
> + ret = uclass_get_device(UCLASS_SPI_FLASH, 0, );
This is a bit weird. Do we always want to use the first available SPI
on the system to store the variables?
I don't remember if the driver model has a mechanism to define one of
the
Re: [PATCH 00/21] Qualcomm generic board support
Hi Caleb,
On Tue, 21 Nov 2023 at 22:39, 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.
>
Thanks for your work. It is a good step towards a generalized u-boot
on Qcom platforms. Although I would like to give it an in-depth
review, I have a common discussion point about DT, see below.
> 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) 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.
Since with this change, we don't need to embed FDT blob in the u-boot
binary, so I was thinking if we really need to import DTs from Linux
for different platforms and then play a catchup game?
IMO, the build command would look like following if we import
pre-built FDT blob from Linux:
- Build u-boot::
$ export CROSS_COMPILE=
$ make qcom_defconfig
$ make
- gzip u-boot::
gzip u-boot-nodtb.bin
- Append dtb to gzipped u-boot::
cat u-boot-nodtb.bin.gz
/arch/arm64/boot/dts/qcom/your-board.dtb >
u-boot-nodtb.bin.gz-dtb
This would avoid the maintenance burden to keep DT in sync with that
of Linux. And since DT bindings in Linux are backwards compatible, we
can say u-boot should work with DTB picked up from any Linux kernel
stable release.
-Sumit
>
> == defconfig ==
>
> Most of the board defconfigs and config headers were quite similar, to
> simplify maintenance going forward, all the fully generic boards (sdm845
> and qcs404-evb so far) are adapted to use the new qcom_defconfig. Going
> forward, all new Qualcomm boards should be supported by this defconfig.
> A notable exception is for specific usecases (like U-Boot as the primary
> bootloader).
>
> == The older dragonboards ==
>
> The db410c and db820c both have some custom board init code, as a result
> they aren't yet binary compatible. mach-snapdragon is adjusted so
> that all the necessary config options (e.g. CONFIG_SYS_BOARD) can be set
> from their defconfigs, this makes it possible to enable support for new
> boards without introducing additional config options.
>
> The db410c can run U-Boot either chainloaded like the other boards, or
> as a first-stage bootloader replacing aboot. However it was hardcoded to
> only build for the latter option. This series introduces a new
> "chainloaded" defconfig to enable easier testing via fastboot.
>
> == dynamic environment variables ==
>
> This series also introduces runtime-allocated load addresses via the lmb
> allocator. This allows for booting on boards with vastly different
> memory layouts without any pre-calculation or macro magic in the config
> header. This feature is based on similar code in mach-apple.
>
> The soc, board, and fdtfile environment variables are also generated
> automatically. Many Qualcomm
Re: [PATCH] mtd: rawnand: omap_gpmc: fix BCH8 HW based correction
Hello Roger,
On 21.11.23 22:56, Roger Quadros wrote:
> Hi,
>
> On 15/11/2023 13:36, Heiko Schocher wrote:
>> Hello Roger,
>>
>> On 15.11.23 12:09, Roger Quadros wrote:
>>>
>>>
>>> On 15/11/2023 07:40, Heiko Schocher wrote:
commit 04fcd2587321 ("mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based
correction")
broke AM335x based boards booting from NAND with ECC BCH8 code.
Use omap_enable_hwecc() instead of omap_enable_hwecc_bch()
in SPL restores correct SPL nand_read_page functionality.
Tested on draco thuban board.
Signed-off-by: Heiko Schocher
---
fix NAND boot for BCH8 based TI AM335x boards
Fix is based on series from Enrico:
https://lists.denx.de/pipermail/u-boot/2023-November/536793.html
and fixes NAND boot for the draco thuban board. But this patch
apply also without the patches from above patchseries, see
azure build:
https://dev.azure.com/hs0298/hs/_build/results?buildId=111=results
which is clean.
Above commit seems to change only U-Boot code and did not
adapt am335x_spl_bch.c, which breaks nand_read_page in SPL
code for AM335x based boards. So use in SPL "old" hw setup
and reading page from NAND in SPL works again.
drivers/mtd/nand/raw/omap_gpmc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/mtd/nand/raw/omap_gpmc.c
b/drivers/mtd/nand/raw/omap_gpmc.c
index 1a5ed0de31..c9b66dadbd 100644
--- a/drivers/mtd/nand/raw/omap_gpmc.c
+++ b/drivers/mtd/nand/raw/omap_gpmc.c
@@ -983,7 +983,11 @@ static int omap_select_ecc_scheme(struct nand_chip
*nand,
nand->ecc.strength = 8;
nand->ecc.size = SECTOR_BYTES;
nand->ecc.bytes = 14;
+#if defined(CONFIG_SPL_BUILD)
+ nand->ecc.hwctl = omap_enable_hwecc;
>>>
>>> I don't think this is correct. omap_enable_hwecc does not setup
>>> the BCH settings and should be used only for 1-bit ECC i.e.
>>> OMAP_ECC_HAM1_CODE_*
>>>
>>> I'm sure it will break the boards not using
>>> CONFIG_SPL_NAND_AM33XX_BCH which is
>>> pretty much most TI boards that are not AM335x.
>>>
>>> Now, I need to identify why AM335x NAND is broken.
>>
>> Yes, I played with setting up stuff in drivers/mtd/nand/raw/am335x_spl_bch.c
>> but failed ...
>>
>> If I can help you testing, feel free to ask!
>
> OK. So I did some tests and we are ending up in a different ECC config on
> AM335x.
> The ecc.steps is not set at all by the driver (it is at 0) and so so nsectors
> gets
> set to -1 and so 7 (0b111) which is wrong.
>
> static void __maybe_unused omap_enable_hwecc_bch(struct mtd_info *mtd,
>int mode)
> {
> ...
> case OMAP_ECC_BCH8_CODE_HW:
> bch_type = 1;
> nsectors = chip->ecc.steps;
> ...
> /* BCH configuration */
> val = ((1 << 16) | /* enable BCH */
> (bch_type<< 12) | /* BCH4/BCH8/BCH16 */
> (wr_mode << 8) | /* wrap mode */
> (dev_width << 7) | /* bus width */
> --> (((nsectors - 1) & 0x7) << 4) | /* number of sectors */
> (info->cs<< 1) | /* ECC CS */
> (0x1));
> ...
> }
>
> setting chip->ecc.steps needs to be fixed in original commit
> c3754e9cc23a ("omap_gpmc: BCH8 support (ELM based)")
>
> But this will still not fix the issue for AM335x as am335x_spl_bch.c
> expects 1 sector at a time ECC calculation.
Yep...
> I also realized that the error correction logic (ELM) is not in page mode
> and so is not suitable for multi-sector error correction.
Okay!
> This means we have to revert the commit
> 04fcd2587321 ("mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based correction")
>
> and go back to 1 sector BCH ECC generation and correction.
Uff... I did exactly this to get it working (in first shot) but feared
sending such a "drastic" patch, as I had the hope to fix "AM335x SPL code",
as U-Boot part works on AM335x...
What I wonder is that above commit introduced "omap_calculate_ecc_bch_multi"
but did not use it in SPL! For U-Boot code omap_calculate_ecc_bch_multi is
used in drivers/mtd/nand/raw/omap_gpmc.c omap_read_page_bch()
but drivers/mtd/nand/raw/am335x_spl_bch.c has no adaption ... so I tried
to adapt this file... but did not get it up working without digging
very deep into it...
> I will send a patch fix in a day or two after doing some tests at my end.
Okay, thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH 2/2] arm: dts: k3-*-binman: Move to using templated FITs
Hi Manorit
On 22/11/23 10:50, Manorit Chawdhry wrote:
Hi Neha,
On 15:40-20231115, Neha Malcom Francis wrote:
Reduce redundancy in code by using templates to generate the A72 boot
binaries (tispl.bin and u-boot.img) as well as R5 boot binary sysfw.itb
(for legacy boot following devices J721E and AM65x).
Signed-off-by: Neha Malcom Francis
---
arch/arm/dts/k3-am625-sk-binman.dtsi | 157 +
.../dts/k3-am625-verdin-wifi-dev-binman.dtsi | 155 +---
arch/arm/dts/k3-am62a-sk-binman.dtsi | 158 +
arch/arm/dts/k3-am64x-binman.dtsi | 151 +---
arch/arm/dts/k3-am65x-binman.dtsi | 273 +-
arch/arm/dts/k3-j7200-binman.dtsi | 159 +
arch/arm/dts/k3-j721e-binman.dtsi | 332 +-
arch/arm/dts/k3-j721s2-binman.dtsi| 157 +
8 files changed, 54 insertions(+), 1488 deletions(-)
diff --git a/arch/arm/dts/k3-am625-sk-binman.dtsi
b/arch/arm/dts/k3-am625-sk-binman.dtsi
index 41277bf4bf..b7b5368886 100644
--- a/arch/arm/dts/k3-am625-sk-binman.dtsi
+++ b/arch/arm/dts/k3-am625-sk-binman.dtsi
@@ -141,10 +141,7 @@
#ifdef CONFIG_TARGET_AM625_A53_EVM
-#define SPL_NODTB "spl/u-boot-spl-nodtb.bin"
#define SPL_AM625_SK_DTB "spl/dts/k3-am625-sk.dtb"
-
-#define UBOOT_NODTB "u-boot-nodtb.bin"
#define AM625_SK_DTB "u-boot.dtb"
{
@@ -155,55 +152,11 @@
};
};
ti-spl {
- filename = "tispl.bin";
- pad-byte = <0xff>;
+ insert-template = <_spl_template>;
fit {
- description = "Configuration to load ATF and SPL";
- #address-cells = <1>;
-
images {
-
- atf {
- description = "ARM Trusted Firmware";
- type = "firmware";
- arch = "arm64";
- compression = "none";
- os = "arm-trusted-firmware";
- load = ;
- entry = ;
- ti-secure {
- content = <>;
- keyfile = "custMpk.pem";
- };
For ATF/OP-TEE Firewalling, can you keep these nodes intact? Just keep
the ti-secure inside atf and tee nodes similar to how you have done that
for DM as all the ATF/OPTEE nodes in the tispl.bin would be different
for devices w.r.t certifications but we can still use templates for
other common stuff.
I believe you will still be able to process firewalling by adding the extra
parameters in the board binman DTSI file. The reason for retaining DM was
different. For example, for J721E:
diff --git a/arch/arm/dts/k3-j721e-binman.dtsi
b/arch/arm/dts/k3-j721e-binman.dtsi
index 5ddb474e3a..647b5dc629 100644
--- a/arch/arm/dts/k3-j721e-binman.dtsi
+++ b/arch/arm/dts/k3-j721e-binman.dtsi
@@ -146,6 +146,27 @@
fit {
images {
+ atf {
+ ti-secure {
+ auth-in-place = <0xa02>;
+
+ firewall-257-0 {
+ /* cpu_0_cpu_0_msmc Background
Firewall */
+ id = <257>;
+ region = <0>;
+ control = <(FWCTRL_EN |
FWCTRL_LOCK |
+
FWCTRL_BG | FWCTRL_CACHE)>;
+ permissions = <((FWPRIVID_ALL
<< FWPRIVID_SHIFT) |
+
FWPERM_SECURE_PRIV_RWCD |
+
FWPERM_SECURE_USER_RWCD |
+
FWPERM_NON_SECURE_PRIV_RWCD |
+
FWPERM_NON_SECURE_USER_RWCD)>;
+ start_address = <0x0
0x0>;
+ end_address = <0xff
0x>;
+ };
+ };
+ };
+
dm {
ti-secure {
content = <>;
I have only checked whether this builds fine without any errors. If you
Re: [PATCH v6 1/2] kbuild: arm64: Add BOOT_TARGETS variable
On Mon, Nov 20, 2023 at 12:02 AM Simon Glass wrote: > > Add a new variable containing a list of possible targets. Mark them as > phony. This matches the approach taken for arch/arm > > Signed-off-by: Simon Glass I encounter difficulty in understanding your subject prefix policy. You used the "arm:" prefix for a patch irrelevant to arm: https://lore.kernel.org/linux-kbuild/cak7lnaqn_qgyztwgdmqyfg+ez5p7rkm47mpgp0dqn_iuhvt...@mail.gmail.com/ And, the one for this patch. "kbuild: arm64: Add BOOT_TARGETS variable" Please do not add "kbuild:" for a patch that modifies arch/arm64, and that was not even submitted to kbuild ML. > --- > > Changes in v6: > - Drop the unwanted .gz suffix > > arch/arm64/Makefile | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile > index 4bd85cc0d32b..ae0c5ee8c78b 100644 > --- a/arch/arm64/Makefile > +++ b/arch/arm64/Makefile > @@ -150,6 +150,10 @@ libs-$(CONFIG_EFI_STUB) += > $(objtree)/drivers/firmware/efi/libstub/lib.a > # Default target when executing plain make > boot := arch/arm64/boot > > +BOOT_TARGETS := Image vmlinuz.efi > + > +PHONY += $(BOOT_TARGETS) > + > ifeq ($(CONFIG_EFI_ZBOOT),) > KBUILD_IMAGE := $(boot)/Image.gz > else > @@ -159,7 +163,7 @@ endif > all: $(notdir $(KBUILD_IMAGE)) > > > -Image vmlinuz.efi: vmlinux > +$(BOOT_TARGETS): vmlinux > $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ > > Image.%: Image > -- > 2.43.0.rc0.421.g78406f8d94-goog > -- Best Regards Masahiro Yamada
Re: [PATCH v6 2/2] arm64: boot: Support Flat Image Tree
On Mon, Nov 20, 2023 at 12:02 AM Simon Glass wrote: > > Add a script which produces a Flat Image Tree (FIT), a single file > containing the built kernel and associated devicetree files. > Compression defaults to gzip which gives a good balance of size and > performance. > > The files compress from about 86MB to 24MB using this approach. > > The FIT can be used by bootloaders which support it, such as U-Boot > and Linuxboot. It permits automatic selection of the correct > devicetree, matching the compatible string of the running board with > the closest compatible string in the FIT. There is no need for > filenames or other workarounds. > > Add a 'make image.fit' build target for arm64, as well. > > The FIT can be examined using 'dumpimage -l'. > > This features requires pylibfdt (use 'pip install libfdt'). It also This feature I CC'ed you in [1] so that you would notice that you are introducing the same bug. [1] https://lore.kernel.org/linux-kbuild/capnjgz1w+0jcdr-qhsbhdxhjfa-unfnfttb4-6bvxytyuhy...@mail.gmail.com/T/#md4084ff402a59ba04f258b24f49ecd1fd4fe7900 > requires compression utilities for the algorithm being used. Supported > compression options are the same as the Image.xxx files. For now there > is no way to change the compression other than by editing the rule for > $(obj)/image.fit > > While FIT supports a ramdisk / initrd, no attempt is made to support > this here, since it must be built separately from the Linux build. > > Signed-off-by: Simon Glass > --- > > (no changes since v5) > > Changes in v5: > - Drop patch previously applied > - Correct compression rule which was broken in v4 > > Changes in v4: > - Use single quotes for UIMAGE_NAME > > Changes in v3: > - Drop temporary file image.itk > - Drop patch 'Use double quotes for image name' > - Drop double quotes in use of UIMAGE_NAME > - Drop unnecessary CONFIG_EFI_ZBOOT condition for help > - Avoid hard-coding "arm64" for the DT architecture > > Changes in v2: > - Drop patch previously applied > - Add .gitignore file > - Move fit rule to Makefile.lib using an intermediate file > - Drop dependency on CONFIG_EFI_ZBOOT > - Pick up .dtb files separately from the kernel > - Correct pylint too-many-args warning for write_kernel() > - Include the kernel image in the file count > - Add a pointer to the FIT spec and mention of its wide industry usage > - Mention the kernel version in the FIT description > > MAINTAINERS| 7 + > arch/arm64/Makefile| 3 +- > arch/arm64/boot/.gitignore | 1 + > arch/arm64/boot/Makefile | 6 +- > scripts/Makefile.lib | 13 ++ > scripts/make_fit.py| 289 + > 6 files changed, 317 insertions(+), 2 deletions(-) > create mode 100755 scripts/make_fit.py > > diff --git a/MAINTAINERS b/MAINTAINERS > index a17935edfa33..f388f45fcbfe 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1585,6 +1585,13 @@ F: Documentation/process/maintainer-soc*.rst > F: arch/arm/boot/dts/Makefile > F: arch/arm64/boot/dts/Makefile > > +ARM64 FIT SUPPORT > +M: Simon Glass > +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) > +S: Maintained > +F: arch/arm64/boot/Makefile > +F: scripts/make_fit.py > + > ARM ARCHITECTED TIMER DRIVER > M: Mark Rutland > M: Marc Zyngier > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile > index ae0c5ee8c78b..a58599dca07e 100644 > --- a/arch/arm64/Makefile > +++ b/arch/arm64/Makefile > @@ -150,7 +150,7 @@ libs-$(CONFIG_EFI_STUB) += > $(objtree)/drivers/firmware/efi/libstub/lib.a > # Default target when executing plain make > boot := arch/arm64/boot > > -BOOT_TARGETS := Image vmlinuz.efi > +BOOT_TARGETS := Image vmlinuz.efi image.fit > > PHONY += $(BOOT_TARGETS) > > @@ -215,6 +215,7 @@ virtconfig: > define archhelp >echo '* Image.gz - Compressed kernel image > (arch/$(ARCH)/boot/Image.gz)' >echo ' Image - Uncompressed kernel image > (arch/$(ARCH)/boot/Image)' > + echo ' image.fit - Flat Image Tree (arch/$(ARCH)/boot/image.fit)' >echo ' install - Install uncompressed kernel' >echo ' zinstall - Install compressed kernel' >echo ' Install using (your) ~/bin/installkernel or' > diff --git a/arch/arm64/boot/.gitignore b/arch/arm64/boot/.gitignore > index af5dc61f8b43..abaae9de1bdd 100644 > --- a/arch/arm64/boot/.gitignore > +++ b/arch/arm64/boot/.gitignore > @@ -2,3 +2,4 @@ > Image > Image.gz > vmlinuz* > +image.fit > diff --git a/arch/arm64/boot/Makefile b/arch/arm64/boot/Makefile > index 1761f5972443..8d591fda078f 100644 > --- a/arch/arm64/boot/Makefile > +++ b/arch/arm64/boot/Makefile > @@ -16,7 +16,8 @@ > > OBJCOPYFLAGS_Image :=-O binary -R .note -R .note.gnu.build-id -R .comment -S > > -targets := Image Image.bz2 Image.gz Image.lz4 Image.lzma Image.lzo Image.zst > +targets := Image Image.bz2 Image.gz Image.lz4 Image.lzma Image.lzo \ > +
Re: [PATCH 1/4] tools: mkeficapsule: Add support for parsing capsule params from config file
hi Tom, On Wed, 22 Nov 2023 at 03:54, Tom Rini wrote: > > On Tue, Nov 21, 2023 at 03:11:50PM -0700, Simon Glass wrote: > > Hi Sughosh, > > > > On Tue, 21 Nov 2023 at 00:02, Sughosh Ganu wrote: > > > > > > Add support for specifying the parameters needed for capsule > > > generation through a config file, instead of passing them through > > > command-line. Parameters for more than a single capsule file can be > > > specified, resulting in generation of multiple capsules through a > > > single invocation of the command. > > > > > > The config file can then be passed to the mkeficapsule tool in such > > > manner > > > > > > $ ./tools/mkeficapsule -f > > > > > > Signed-off-by: Sughosh Ganu > > > --- > > > tools/Kconfig | 15 ++ > > > tools/Makefile | 1 + > > > tools/eficapsule.h | 114 > > > tools/mkeficapsule.c | 87 + > > > tools/mkeficapsule_parse.c | 352 + > > > 5 files changed, 538 insertions(+), 31 deletions(-) > > > create mode 100644 tools/mkeficapsule_parse.c > > > > This patch keeps coming back :-) > > > > Can we not add multiple capsules in the binman description? Why do we > > need a new file format? How can binman decode images produced in this > > way? > > > > Also, could we get sandbox to produce one EFI capsule as part of the > > normal build? I think that discussion trailed off. > > I believe part of the answer here is to support the config file format > that other capsule generators use. Do I recall this all right, Sughosh? Yes, that is correct. There are some other reasons as well, which I have mentioned in the reply to Simon's email. -sughosh
Re: [PATCH 1/4] tools: mkeficapsule: Add support for parsing capsule params from config file
hi Simon, On Wed, 22 Nov 2023 at 03:42, Simon Glass wrote: > > Hi Sughosh, > > On Tue, 21 Nov 2023 at 00:02, Sughosh Ganu wrote: > > > > Add support for specifying the parameters needed for capsule > > generation through a config file, instead of passing them through > > command-line. Parameters for more than a single capsule file can be > > specified, resulting in generation of multiple capsules through a > > single invocation of the command. > > > > The config file can then be passed to the mkeficapsule tool in such > > manner > > > > $ ./tools/mkeficapsule -f > > > > Signed-off-by: Sughosh Ganu > > --- > > tools/Kconfig | 15 ++ > > tools/Makefile | 1 + > > tools/eficapsule.h | 114 > > tools/mkeficapsule.c | 87 + > > tools/mkeficapsule_parse.c | 352 + > > 5 files changed, 538 insertions(+), 31 deletions(-) > > create mode 100644 tools/mkeficapsule_parse.c > > This patch keeps coming back :-) > > Can we not add multiple capsules in the binman description? Why do we > need a new file format? How can binman decode images produced in this > way? So as Tom mentions, this brings parity with respect to the other capsule generation tool in EDKII that generates capsules. IIRC, this is something which even Xilix was interested in, and Michal had kind of gone through these patches earlier. Lastly, it would be good to have support in U-Boot's mkeficapsule tool for generating a single capsule file with multiple payloads, and having support for this functionality helps in that goal. Also, you might have noticed that, since your objection to the last series, I have removed putting this in binman. So now, this aspect of the capsule generation would only be supported through the command-line invocation of the tool. > > Also, could we get sandbox to produce one EFI capsule as part of the > normal build? I think that discussion trailed off. Yes, apologies for missing out on this. Slipped my mind. Would you want, say, all the non-signed capsules to be generated as part of the sandbox build? -sughosh
Re: [PATCH 2/2] arm: dts: k3-*-binman: Move to using templated FITs
Hi Neha,
On 15:40-20231115, Neha Malcom Francis wrote:
> Reduce redundancy in code by using templates to generate the A72 boot
> binaries (tispl.bin and u-boot.img) as well as R5 boot binary sysfw.itb
> (for legacy boot following devices J721E and AM65x).
>
> Signed-off-by: Neha Malcom Francis
> ---
> arch/arm/dts/k3-am625-sk-binman.dtsi | 157 +
> .../dts/k3-am625-verdin-wifi-dev-binman.dtsi | 155 +---
> arch/arm/dts/k3-am62a-sk-binman.dtsi | 158 +
> arch/arm/dts/k3-am64x-binman.dtsi | 151 +---
> arch/arm/dts/k3-am65x-binman.dtsi | 273 +-
> arch/arm/dts/k3-j7200-binman.dtsi | 159 +
> arch/arm/dts/k3-j721e-binman.dtsi | 332 +-
> arch/arm/dts/k3-j721s2-binman.dtsi| 157 +
> 8 files changed, 54 insertions(+), 1488 deletions(-)
>
> diff --git a/arch/arm/dts/k3-am625-sk-binman.dtsi
> b/arch/arm/dts/k3-am625-sk-binman.dtsi
> index 41277bf4bf..b7b5368886 100644
> --- a/arch/arm/dts/k3-am625-sk-binman.dtsi
> +++ b/arch/arm/dts/k3-am625-sk-binman.dtsi
> @@ -141,10 +141,7 @@
>
> #ifdef CONFIG_TARGET_AM625_A53_EVM
>
> -#define SPL_NODTB "spl/u-boot-spl-nodtb.bin"
> #define SPL_AM625_SK_DTB "spl/dts/k3-am625-sk.dtb"
> -
> -#define UBOOT_NODTB "u-boot-nodtb.bin"
> #define AM625_SK_DTB "u-boot.dtb"
>
> {
> @@ -155,55 +152,11 @@
> };
> };
> ti-spl {
> - filename = "tispl.bin";
> - pad-byte = <0xff>;
> + insert-template = <_spl_template>;
>
> fit {
> - description = "Configuration to load ATF and SPL";
> - #address-cells = <1>;
> -
> images {
> -
> - atf {
> - description = "ARM Trusted Firmware";
> - type = "firmware";
> - arch = "arm64";
> - compression = "none";
> - os = "arm-trusted-firmware";
> - load = ;
> - entry = ;
> - ti-secure {
> - content = <>;
> - keyfile = "custMpk.pem";
> - };
For ATF/OP-TEE Firewalling, can you keep these nodes intact? Just keep
the ti-secure inside atf and tee nodes similar to how you have done that
for DM as all the ATF/OPTEE nodes in the tispl.bin would be different
for devices w.r.t certifications but we can still use templates for
other common stuff.
With this change,
Reviewed-by: Manorit Chawdhry
Regards,
Manorit
> - atf: atf-bl31 {
> - };
> - };
> -
> - tee {
> - description = "OP-TEE";
> - type = "tee";
> - arch = "arm64";
> - compression = "none";
> - os = "tee";
> - load = <0x9e80>;
> - entry = <0x9e80>;
> - ti-secure {
> - content = <>;
> - keyfile = "custMpk.pem";
> - };
> - tee: tee-os {
> - };
> - };
> -
> dm {
> - description = "DM binary";
> - type = "firmware";
> - arch = "arm32";
> - compression = "none";
> - os = "DM";
> - load = <0x8900>;
> - entry = <0x8900>;
> ti-secure {
> content = <>;
> keyfile = "custMpk.pem";
> @@ -213,23 +166,6 @@
> };
> };
>
> - spl {
> - description = "SPL (64-bit)";
> - type = "standalone";
> - os = "U-Boot";
> - arch = "arm64";
> - compression = "none";
> - load = ;
> - entry = ;
> -
Re: [PATCH v3 4/5] lib: membuff: fix readline not returning line in case of overflow
On 11/21/23 19:40, Simon Glass wrote:
Hi Svyatoslav,
On Tue, 21 Nov 2023 at 11:35, Svyatoslav Ryhel wrote:
From: Ion Agorria
If line overflows readline it will not be returned, fix this behavior,
make it optional and documented properly.
Signed-off-by: Ion Agorria
Signed-off-by: Svyatoslav Ryhel
Reviewed-by: Mattijs Korpershoek
---
boot/bootmeth_extlinux.c | 2 +-
common/console.c | 2 +-
include/membuff.h| 5 +++--
lib/membuff.c| 4 ++--
4 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/boot/bootmeth_extlinux.c b/boot/bootmeth_extlinux.c
index aa2a4591eb..ae0ad1d53e 100644
--- a/boot/bootmeth_extlinux.c
+++ b/boot/bootmeth_extlinux.c
@@ -82,7 +82,7 @@ static int extlinux_fill_info(struct bootflow *bflow)
log_debug("parsing bflow file size %x\n", bflow->size);
membuff_init(, bflow->buf, bflow->size);
membuff_putraw(, bflow->size, true, );
- while (len = membuff_readline(, line, sizeof(line) - 1, ' '), len) {
+ while (len = membuff_readline(, line, sizeof(line) - 1, ' ', true),
len) {
char *tok, *p = line;
tok = strsep(, " ");
diff --git a/common/console.c b/common/console.c
index 8a869b137e..cd56035171 100644
--- a/common/console.c
+++ b/common/console.c
@@ -846,7 +846,7 @@ bool console_record_overflow(void)
int console_record_readline(char *str, int maxlen)
{
return membuff_readline((struct membuff *)>console_out, str,
- maxlen, '\0');
+ maxlen, '\0', false);
}
int console_record_avail(void)
diff --git a/include/membuff.h b/include/membuff.h
index 21051b0c54..4eba626ce1 100644
--- a/include/membuff.h
+++ b/include/membuff.h
@@ -192,10 +192,11 @@ int membuff_free(struct membuff *mb);
* @mb: membuff to adjust
* @str: Place to put the line
* @maxlen: Maximum line length (excluding terminator)
+ * @must_fit: If true then str is empty if line doesn't fit
* Return: number of bytes read (including terminator) if a line has been
- *read, 0 if nothing was there
+ *read, 0 if nothing was there or line didn't fit when must_fit is set
*/
-int membuff_readline(struct membuff *mb, char *str, int maxlen, int minch);
+int membuff_readline(struct membuff *mb, char *str, int maxlen, int minch,
bool must_fit);
/**
* membuff_extend_by() - expand a membuff
diff --git a/lib/membuff.c b/lib/membuff.c
index 36dc43a523..964e504d5b 100644
--- a/lib/membuff.c
+++ b/lib/membuff.c
@@ -288,7 +288,7 @@ int membuff_free(struct membuff *mb)
(mb->end - mb->start) - 1 - membuff_avail(mb);
}
-int membuff_readline(struct membuff *mb, char *str, int maxlen, int minch)
+int membuff_readline(struct membuff *mb, char *str, int maxlen, int minch,
bool must_fit)
Shouldn't that be the normal case? I might have this wrong, but this
looks like a bug fix to me.
For the extlinux.conf case assuming that the file has ended if a line is
truncated seems to be the wrong thing to do.
Currently we return a value <= maxlen - 1 if no truncation has occurred
and 0 if a truncation occurred.
I would prefer if the function would return maxlen in the case of
truncation and the truncated string. This will allow us to detect
truncation without mistaking it for the end of the buffer.
Best regards
Heinrich
{
int len; /* number of bytes read (!= string length) */
char *s, *end;
@@ -310,7 +310,7 @@ int membuff_readline(struct membuff *mb, char *str, int
maxlen, int minch)
}
/* couldn't get the whole string */
- if (!ok) {
+ if (!ok && must_fit) {
if (maxlen)
*orig = '\0';
return 0;
--
2.40.1
Re: [PATCH v1 2/3] efi_vars: Implement SPI Flash store
On Tue, Nov 21, 2023 at 11:57:12PM +, Shantur Rathore wrote:
> Currently U-boot uses ESP as storage for EFI variables.
> Devices with SPI Flash are used for storing environment with this
> commit we allow EFI variables to be stored on SPI Flash.
>
> Signed-off-by: Shantur Rathore
> ---
>
> include/efi_variable.h| 25 ++
> lib/efi_loader/Kconfig| 18 +++
> lib/efi_loader/Makefile | 1 +
> lib/efi_loader/efi_var_sf.c | 91 +++
> lib/efi_loader/efi_variable.c | 4 ++
> 5 files changed, 139 insertions(+)
> create mode 100644 lib/efi_loader/efi_var_sf.c
>
> diff --git a/include/efi_variable.h b/include/efi_variable.h
> index ca7e19d514..766dd109f5 100644
> --- a/include/efi_variable.h
> +++ b/include/efi_variable.h
> @@ -188,6 +188,31 @@ efi_status_t efi_var_from_file(void);
>
> #endif // CONFIG_EFI_VARIABLE_FILE_STORE
>
> +#ifdef CONFIG_EFI_VARIABLE_SF_STORE
Not needed as I said.
> +
> +/**
> + * efi_var_from_sf() - read variables from SPI Flash
> + *
> + * EFI variable buffer is read from SPI Flash at offset defined with
> + * CONFIG_EFI_VARIABLE_SF_OFFSET of length CONFIG_EFI_VAR_BUF_SIZE
> + *
> + *
> + * Return: status code
> + */
> +efi_status_t efi_var_from_sf(void);
> +
> +/**
> + * efi_var_to_sf() - save non-volatile variables to SPI Flash
> + *
> + * EFI variable buffer is saved to SPI Flash at offset defined with
> + * CONFIG_EFI_VARIABLE_SF_OFFSET of length CONFIG_EFI_VAR_BUF_SIZE.
> + *
> + * Return: status code
> + */
> +efi_status_t efi_var_to_sf(void);
> +
> +#endif // CONFIG_EFI_VARIABLE_SF_STORE
> +
> /**
> * efi_var_mem_init() - set-up variable list
> *
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index 4ccd26f94a..1fcc6fabb4 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -54,6 +54,17 @@ 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_VARIABLE_SF_STORE
> + bool "Store non-volatile UEFI variables in SPI Flash"
> + depends on SPI_FLASH
> + help
> + Select this option if you want non-volatile UEFI variables to be
> + stored in SPI Flash.
> + Define CONFIG_EFI_VARIABLE_SF_OFFSET as offset in SPI Flash to use as
> + the storage for variables. CONFIG_EFI_VAR_BUF_SIZE defines the space
> + needed.
> +
> +
> config EFI_MM_COMM_TEE
> bool "UEFI variables storage service via the trusted world"
> depends on OPTEE
> @@ -108,6 +119,13 @@ config EFI_VARIABLE_NO_STORE
>
> endchoice
>
> +config EFI_VARIABLE_SF_OFFSET
> + hex "EFI variables in SPI flash offset"
> + depends on EFI_VARIABLE_SF_STORE
> + default 0x7D
The default value is definitely board-specific.
Please add "if TARGET_ROCKPRO64_RK3399(?)".
> + help
> + Offset from the start of the SPI Flash where EFI variables will be
> stored.
> +
> config EFI_VARIABLES_PRESEED
> bool "Initial values for UEFI variables"
> depends on !EFI_MM_COMM_TEE
> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
> index 8d31fc61c6..b9b715b1ff 100644
> --- a/lib/efi_loader/Makefile
> +++ b/lib/efi_loader/Makefile
> @@ -67,6 +67,7 @@ obj-$(CONFIG_EFI_UNICODE_COLLATION_PROTOCOL2) +=
> efi_unicode_collation.o
> obj-y += efi_var_common.o
> obj-y += efi_var_mem.o
> obj-y += efi_var_file.o
> +obj-$(CONFIG_EFI_VARIABLE_SF_STORE) += efi_var_sf.o
> ifeq ($(CONFIG_EFI_MM_COMM_TEE),y)
> obj-y += efi_variable_tee.o
> else
> diff --git a/lib/efi_loader/efi_var_sf.c b/lib/efi_loader/efi_var_sf.c
> new file mode 100644
> index 00..e604a2225c
> --- /dev/null
> +++ b/lib/efi_loader/efi_var_sf.c
> @@ -0,0 +1,91 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * File interface for UEFI variables
For Spi Flash?
> + *
> + * Copyright (c) 2023, Shantur Rtahore
> + */
> +
> +#define LOG_CATEGORY LOGC_EFI
> +
> +#include
> +#include
> +#include
> +#include
> +
> +efi_status_t efi_var_to_sf(void)
> +{
> + efi_status_t ret;
> + struct efi_var_file *buf;
> + loff_t len;
> + struct udevice *sfdev;
> +
> + ret = efi_var_collect(, , EFI_VARIABLE_NON_VOLATILE);
> + if (len > EFI_VAR_BUF_SIZE) {
> + log_err("EFI var buffer length more than target SF size");
> + ret = EFI_BAD_BUFFER_SIZE;
> + goto error;
> + }
> +
> + debug("%s - Got buffer to write buf->len : %d\n", __func__,
> buf->length);
log_debug()?
> +
> + if (ret != EFI_SUCCESS)
> + goto error;
> +
> + ret = uclass_get_device(UCLASS_SPI_FLASH, 0, );
> + if (ret)
> + goto error;
> +
> + ret = spi_flash_erase_dm(sfdev, CONFIG_EFI_VARIABLE_SF_OFFSET,
> EFI_VAR_BUF_SIZE);
> + debug("%s - Erased SPI Flash offset %lx\n", __func__,
> CONFIG_EFI_VARIABLE_SF_OFFSET);
> + if (ret)
> + goto error;
> +
> +
[PATCH 1/1] configs: enable VIDEO_ANSI on EFI app
The cls command ignores $stdout if CONFIG_VIDEO_ANSI=n. This leads to unexpected output. Signed-off-by: Heinrich Schuchardt --- configs/efi-x86_app32_defconfig | 1 + configs/efi-x86_app64_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/efi-x86_app32_defconfig b/configs/efi-x86_app32_defconfig index dfc315774a..fd963a8ce4 100644 --- a/configs/efi-x86_app32_defconfig +++ b/configs/efi-x86_app32_defconfig @@ -38,6 +38,7 @@ CONFIG_BOOTFILE="bzImage" CONFIG_USE_ROOTPATH=y CONFIG_REGMAP=y CONFIG_SYSCON=y +CONFIG_VIDEO_ANSI=y # CONFIG_REGEX is not set # CONFIG_GZIP is not set CONFIG_EFI=y diff --git a/configs/efi-x86_app64_defconfig b/configs/efi-x86_app64_defconfig index e0cfe3ee24..14435290d6 100644 --- a/configs/efi-x86_app64_defconfig +++ b/configs/efi-x86_app64_defconfig @@ -40,6 +40,7 @@ CONFIG_BOOTFILE="bzImage" CONFIG_USE_ROOTPATH=y CONFIG_REGMAP=y CONFIG_SYSCON=y +CONFIG_VIDEO_ANSI=y CONFIG_CONSOLE_SCROLL_LINES=5 # CONFIG_REGEX is not set CONFIG_CMD_DHRYSTONE=y -- 2.40.1
Re: [PATCH v1 1/3] efi: filestore: don't compile when config disabled
On Tue, Nov 21, 2023 at 11:57:11PM +, Shantur Rathore wrote:
> Compile out filestore functions when config isn't enabled.
>
> Signed-off-by: Shantur Rathore
> ---
>
> include/efi_variable.h| 21 -
> lib/efi_loader/efi_var_file.c | 13 +++--
> lib/efi_loader/efi_variable.c | 10 +-
> 3 files changed, 28 insertions(+), 16 deletions(-)
>
> diff --git a/include/efi_variable.h b/include/efi_variable.h
> index 805e6c5f1e..ca7e19d514 100644
> --- a/include/efi_variable.h
> +++ b/include/efi_variable.h
> @@ -136,15 +136,6 @@ struct efi_var_file {
> struct efi_var_entry var[];
> };
>
> -/**
> - * efi_var_to_file() - save non-volatile variables as file
> - *
> - * File ubootefi.var is created on the EFI system partion.
> - *
> - * Return: status code
> - */
> -efi_status_t efi_var_to_file(void);
> -
> /**
> * efi_var_collect() - collect variables in buffer
> *
> @@ -172,6 +163,16 @@ efi_status_t __maybe_unused efi_var_collect(struct
> efi_var_file **bufp, loff_t *
> */
> efi_status_t efi_var_restore(struct efi_var_file *buf, bool safe);
>
> +#ifdef CONFIG_EFI_VARIABLE_FILE_STORE
I don't think we need this guard because any function declaration
in a header is harmless even if that function implementation is opted out.
> +/**
> + * efi_var_to_file() - save non-volatile variables as file
> + *
> + * File ubootefi.var is created on the EFI system parition.
> + *
> + * Return: status code
> + */
> +efi_status_t efi_var_to_file(void);
> +
> /**
> * efi_var_from_file() - read variables from file
> *
> @@ -185,6 +186,8 @@ efi_status_t efi_var_restore(struct efi_var_file *buf,
> bool safe);
> */
> efi_status_t efi_var_from_file(void);
>
> +#endif // CONFIG_EFI_VARIABLE_FILE_STORE
> +
> /**
> * efi_var_mem_init() - set-up variable list
> *
> diff --git a/lib/efi_loader/efi_var_file.c b/lib/efi_loader/efi_var_file.c
> index 62e071bd83..7ceb7e3cf7 100644
> --- a/lib/efi_loader/efi_var_file.c
> +++ b/lib/efi_loader/efi_var_file.c
> @@ -117,6 +117,8 @@ efi_status_t __maybe_unused efi_var_collect(struct
> efi_var_file **bufp, loff_t *
> return EFI_SUCCESS;
> }
>
> +#ifdef CONFIG_EFI_VARIABLE_FILE_STORE
Can you refactor the code further to purge all "#ifdef" stuffs from this file?
I mean:
1) move efi_var_collect/restor() to a always-compiled file, say,
efi_var_common.c/efi_variable.c
2) modify call sites of the other functions, for example, as follows:
if (CONFIG_IS_ENABLED(EFI_VARIABLE_STORE))
efi_var_to_file();
# I'm not sure why the return code is ignored everywhere.
3) modify Makefile to compile efi_var_file.c only if EFI_VARIABLE_FILE_STORE
is enabled
4) remove "#ifdef CONFIG_EFI_VARIABLE_FILE_STORE" from efi_var_file.c
-Takahiro Akashi
> +
> /**
> * efi_var_to_file() - save non-volatile variables as file
> *
> @@ -126,7 +128,6 @@ efi_status_t __maybe_unused efi_var_collect(struct
> efi_var_file **bufp, loff_t *
> */
> efi_status_t efi_var_to_file(void)
> {
> -#ifdef CONFIG_EFI_VARIABLE_FILE_STORE
> efi_status_t ret;
> struct efi_var_file *buf;
> loff_t len;
> @@ -150,11 +151,10 @@ error:
> log_err("Failed to persist EFI variables\n");
> free(buf);
> return ret;
> -#else
> - return EFI_SUCCESS;
> -#endif
> }
>
> +#endif // CONFIG_EFI_VARIABLE_FILE_STORE
> +
> efi_status_t efi_var_restore(struct efi_var_file *buf, bool safe)
> {
> struct efi_var_entry *var, *last_var;
> @@ -198,6 +198,7 @@ efi_status_t efi_var_restore(struct efi_var_file *buf,
> bool safe)
> return EFI_SUCCESS;
> }
>
> +#ifdef CONFIG_EFI_VARIABLE_FILE_STORE
> /**
> * efi_var_from_file() - read variables from file
> *
> @@ -211,7 +212,6 @@ efi_status_t efi_var_restore(struct efi_var_file *buf,
> bool safe)
> */
> efi_status_t efi_var_from_file(void)
> {
> -#ifdef CONFIG_EFI_VARIABLE_FILE_STORE
> struct efi_var_file *buf;
> loff_t len;
> efi_status_t ret;
> @@ -236,6 +236,7 @@ efi_status_t efi_var_from_file(void)
> log_err("Invalid EFI variables file\n");
> error:
> free(buf);
> -#endif
> return EFI_SUCCESS;
> }
> +
> +#endif // CONFIG_EFI_VARIABLE_FILE_STORE
> diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
> index be95ed44e6..7fa51d 100644
> --- a/lib/efi_loader/efi_variable.c
> +++ b/lib/efi_loader/efi_variable.c
> @@ -357,8 +357,11 @@ efi_status_t efi_set_variable_int(const u16
> *variable_name,
>* Write non-volatile EFI variables to file
>* TODO: check if a value change has occured to avoid superfluous writes
>*/
> - if (attributes & EFI_VARIABLE_NON_VOLATILE)
> + if (attributes & EFI_VARIABLE_NON_VOLATILE) {
> +#ifdef CONFIG_EFI_VARIABLE_FILE_STORE
> efi_var_to_file();
> +#endif
> + }
>
> return EFI_SUCCESS;
> }
> @@ -466,7 +469,12 @@ efi_status_t efi_init_variables(void)
> if (ret != EFI_SUCCESS)
>
[PATCH v1 3/3] defconfig: rockpro64: Enable SF EFI var store
RockPro64 uses SPI Flash for storing env, also use it store EFI variables. Signed-off-by: Shantur Rathore --- configs/rockpro64-rk3399_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig index affb6137e0..b9dededc9a 100644 --- a/configs/rockpro64-rk3399_defconfig +++ b/configs/rockpro64-rk3399_defconfig @@ -8,6 +8,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x30 CONFIG_ENV_SIZE=0x8000 CONFIG_ENV_OFFSET=0x3F8000 +CONFIG_EFI_VARIABLE_SF_STORE=y +CONFIG_EFI_VARIABLE_SF_OFFSET=0x7D CONFIG_DEFAULT_DEVICE_TREE="rk3399-rockpro64" CONFIG_DM_RESET=y CONFIG_ROCKCHIP_RK3399=y -- 2.40.1
[PATCH v1 2/3] efi_vars: Implement SPI Flash store
Currently U-boot uses ESP as storage for EFI variables.
Devices with SPI Flash are used for storing environment with this
commit we allow EFI variables to be stored on SPI Flash.
Signed-off-by: Shantur Rathore
---
include/efi_variable.h| 25 ++
lib/efi_loader/Kconfig| 18 +++
lib/efi_loader/Makefile | 1 +
lib/efi_loader/efi_var_sf.c | 91 +++
lib/efi_loader/efi_variable.c | 4 ++
5 files changed, 139 insertions(+)
create mode 100644 lib/efi_loader/efi_var_sf.c
diff --git a/include/efi_variable.h b/include/efi_variable.h
index ca7e19d514..766dd109f5 100644
--- a/include/efi_variable.h
+++ b/include/efi_variable.h
@@ -188,6 +188,31 @@ efi_status_t efi_var_from_file(void);
#endif // CONFIG_EFI_VARIABLE_FILE_STORE
+#ifdef CONFIG_EFI_VARIABLE_SF_STORE
+
+/**
+ * efi_var_from_sf() - read variables from SPI Flash
+ *
+ * EFI variable buffer is read from SPI Flash at offset defined with
+ * CONFIG_EFI_VARIABLE_SF_OFFSET of length CONFIG_EFI_VAR_BUF_SIZE
+ *
+ *
+ * Return: status code
+ */
+efi_status_t efi_var_from_sf(void);
+
+/**
+ * efi_var_to_sf() - save non-volatile variables to SPI Flash
+ *
+ * EFI variable buffer is saved to SPI Flash at offset defined with
+ * CONFIG_EFI_VARIABLE_SF_OFFSET of length CONFIG_EFI_VAR_BUF_SIZE.
+ *
+ * Return: status code
+ */
+efi_status_t efi_var_to_sf(void);
+
+#endif // CONFIG_EFI_VARIABLE_SF_STORE
+
/**
* efi_var_mem_init() - set-up variable list
*
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 4ccd26f94a..1fcc6fabb4 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -54,6 +54,17 @@ 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_VARIABLE_SF_STORE
+ bool "Store non-volatile UEFI variables in SPI Flash"
+ depends on SPI_FLASH
+ help
+ Select this option if you want non-volatile UEFI variables to be
+ stored in SPI Flash.
+ Define CONFIG_EFI_VARIABLE_SF_OFFSET as offset in SPI Flash to use as
+ the storage for variables. CONFIG_EFI_VAR_BUF_SIZE defines the space
+ needed.
+
+
config EFI_MM_COMM_TEE
bool "UEFI variables storage service via the trusted world"
depends on OPTEE
@@ -108,6 +119,13 @@ config EFI_VARIABLE_NO_STORE
endchoice
+config EFI_VARIABLE_SF_OFFSET
+ hex "EFI variables in SPI flash offset"
+ depends on EFI_VARIABLE_SF_STORE
+ default 0x7D
+ help
+ Offset from the start of the SPI Flash where EFI variables will be
stored.
+
config EFI_VARIABLES_PRESEED
bool "Initial values for UEFI variables"
depends on !EFI_MM_COMM_TEE
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 8d31fc61c6..b9b715b1ff 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_EFI_UNICODE_COLLATION_PROTOCOL2) +=
efi_unicode_collation.o
obj-y += efi_var_common.o
obj-y += efi_var_mem.o
obj-y += efi_var_file.o
+obj-$(CONFIG_EFI_VARIABLE_SF_STORE) += efi_var_sf.o
ifeq ($(CONFIG_EFI_MM_COMM_TEE),y)
obj-y += efi_variable_tee.o
else
diff --git a/lib/efi_loader/efi_var_sf.c b/lib/efi_loader/efi_var_sf.c
new file mode 100644
index 00..e604a2225c
--- /dev/null
+++ b/lib/efi_loader/efi_var_sf.c
@@ -0,0 +1,91 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * File interface for UEFI variables
+ *
+ * Copyright (c) 2023, Shantur Rtahore
+ */
+
+#define LOG_CATEGORY LOGC_EFI
+
+#include
+#include
+#include
+#include
+
+efi_status_t efi_var_to_sf(void)
+{
+ efi_status_t ret;
+ struct efi_var_file *buf;
+ loff_t len;
+ struct udevice *sfdev;
+
+ ret = efi_var_collect(, , EFI_VARIABLE_NON_VOLATILE);
+ if (len > EFI_VAR_BUF_SIZE) {
+ log_err("EFI var buffer length more than target SF size");
+ ret = EFI_BAD_BUFFER_SIZE;
+ goto error;
+ }
+
+ debug("%s - Got buffer to write buf->len : %d\n", __func__,
buf->length);
+
+ if (ret != EFI_SUCCESS)
+ goto error;
+
+ ret = uclass_get_device(UCLASS_SPI_FLASH, 0, );
+ if (ret)
+ goto error;
+
+ ret = spi_flash_erase_dm(sfdev, CONFIG_EFI_VARIABLE_SF_OFFSET,
EFI_VAR_BUF_SIZE);
+ debug("%s - Erased SPI Flash offset %lx\n", __func__,
CONFIG_EFI_VARIABLE_SF_OFFSET);
+ if (ret)
+ goto error;
+
+ ret = spi_flash_write_dm(sfdev, CONFIG_EFI_VARIABLE_SF_OFFSET, len,
buf);
+ debug("%s - Wrote buffer to SPI Flash : %ld\n", __func__, ret);
+
+ if (ret)
+ goto error;
+
+ ret = EFI_SUCCESS;
+error:
+ if (ret)
+ log_err("Failed to persist EFI variables in SF\n");
+ free(buf);
+ return ret;
+}
+
+efi_status_t efi_var_from_sf(void)
+{
+ struct efi_var_file *buf;
+
[PATCH v1 1/3] efi: filestore: don't compile when config disabled
Compile out filestore functions when config isn't enabled.
Signed-off-by: Shantur Rathore
---
include/efi_variable.h| 21 -
lib/efi_loader/efi_var_file.c | 13 +++--
lib/efi_loader/efi_variable.c | 10 +-
3 files changed, 28 insertions(+), 16 deletions(-)
diff --git a/include/efi_variable.h b/include/efi_variable.h
index 805e6c5f1e..ca7e19d514 100644
--- a/include/efi_variable.h
+++ b/include/efi_variable.h
@@ -136,15 +136,6 @@ struct efi_var_file {
struct efi_var_entry var[];
};
-/**
- * efi_var_to_file() - save non-volatile variables as file
- *
- * File ubootefi.var is created on the EFI system partion.
- *
- * Return: status code
- */
-efi_status_t efi_var_to_file(void);
-
/**
* efi_var_collect() - collect variables in buffer
*
@@ -172,6 +163,16 @@ efi_status_t __maybe_unused efi_var_collect(struct
efi_var_file **bufp, loff_t *
*/
efi_status_t efi_var_restore(struct efi_var_file *buf, bool safe);
+#ifdef CONFIG_EFI_VARIABLE_FILE_STORE
+/**
+ * efi_var_to_file() - save non-volatile variables as file
+ *
+ * File ubootefi.var is created on the EFI system parition.
+ *
+ * Return: status code
+ */
+efi_status_t efi_var_to_file(void);
+
/**
* efi_var_from_file() - read variables from file
*
@@ -185,6 +186,8 @@ efi_status_t efi_var_restore(struct efi_var_file *buf, bool
safe);
*/
efi_status_t efi_var_from_file(void);
+#endif // CONFIG_EFI_VARIABLE_FILE_STORE
+
/**
* efi_var_mem_init() - set-up variable list
*
diff --git a/lib/efi_loader/efi_var_file.c b/lib/efi_loader/efi_var_file.c
index 62e071bd83..7ceb7e3cf7 100644
--- a/lib/efi_loader/efi_var_file.c
+++ b/lib/efi_loader/efi_var_file.c
@@ -117,6 +117,8 @@ efi_status_t __maybe_unused efi_var_collect(struct
efi_var_file **bufp, loff_t *
return EFI_SUCCESS;
}
+#ifdef CONFIG_EFI_VARIABLE_FILE_STORE
+
/**
* efi_var_to_file() - save non-volatile variables as file
*
@@ -126,7 +128,6 @@ efi_status_t __maybe_unused efi_var_collect(struct
efi_var_file **bufp, loff_t *
*/
efi_status_t efi_var_to_file(void)
{
-#ifdef CONFIG_EFI_VARIABLE_FILE_STORE
efi_status_t ret;
struct efi_var_file *buf;
loff_t len;
@@ -150,11 +151,10 @@ error:
log_err("Failed to persist EFI variables\n");
free(buf);
return ret;
-#else
- return EFI_SUCCESS;
-#endif
}
+#endif // CONFIG_EFI_VARIABLE_FILE_STORE
+
efi_status_t efi_var_restore(struct efi_var_file *buf, bool safe)
{
struct efi_var_entry *var, *last_var;
@@ -198,6 +198,7 @@ efi_status_t efi_var_restore(struct efi_var_file *buf, bool
safe)
return EFI_SUCCESS;
}
+#ifdef CONFIG_EFI_VARIABLE_FILE_STORE
/**
* efi_var_from_file() - read variables from file
*
@@ -211,7 +212,6 @@ efi_status_t efi_var_restore(struct efi_var_file *buf, bool
safe)
*/
efi_status_t efi_var_from_file(void)
{
-#ifdef CONFIG_EFI_VARIABLE_FILE_STORE
struct efi_var_file *buf;
loff_t len;
efi_status_t ret;
@@ -236,6 +236,7 @@ efi_status_t efi_var_from_file(void)
log_err("Invalid EFI variables file\n");
error:
free(buf);
-#endif
return EFI_SUCCESS;
}
+
+#endif // CONFIG_EFI_VARIABLE_FILE_STORE
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index be95ed44e6..7fa51d 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -357,8 +357,11 @@ efi_status_t efi_set_variable_int(const u16 *variable_name,
* Write non-volatile EFI variables to file
* TODO: check if a value change has occured to avoid superfluous writes
*/
- if (attributes & EFI_VARIABLE_NON_VOLATILE)
+ if (attributes & EFI_VARIABLE_NON_VOLATILE) {
+#ifdef CONFIG_EFI_VARIABLE_FILE_STORE
efi_var_to_file();
+#endif
+ }
return EFI_SUCCESS;
}
@@ -466,7 +469,12 @@ efi_status_t efi_init_variables(void)
if (ret != EFI_SUCCESS)
return ret;
+#ifdef CONFIG_EFI_VARIABLE_FILE_STORE
ret = efi_var_from_file();
+#else
+ ret = EFI_SUCCESS;
+#endif
+
if (ret != EFI_SUCCESS)
return ret;
if (IS_ENABLED(CONFIG_EFI_VARIABLES_PRESEED)) {
--
2.40.1
[PATCH v1 0/3] efi_vars: SPI Flash store
With this patch series we implement SPI Flash storage for EFI variables. Shantur Rathore (3): efi: filestore: don't compile when config disabled efi_vars: Implement SPI Flash store defconfig: rockpro64: Enable SF EFI var store configs/rockpro64-rk3399_defconfig | 2 + include/efi_variable.h | 46 --- lib/efi_loader/Kconfig | 18 ++ lib/efi_loader/Makefile| 1 + lib/efi_loader/efi_var_file.c | 13 +++-- lib/efi_loader/efi_var_sf.c| 91 ++ lib/efi_loader/efi_variable.c | 14 - 7 files changed, 169 insertions(+), 16 deletions(-) create mode 100644 lib/efi_loader/efi_var_sf.c -- 2.40.1
Re: [UBOOT PATCH v4] test/py: net: Add dhcp abort test
On Tue, Nov 21, 2023 at 06:32:47PM +0530, Love Kumar wrote: > Abort the dhcp request in the middle by pressing ctrl + c on u-boot > prompt and validate the abort status. > > Signed-off-by: Love Kumar Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] test/py: i2c: Add tests for i2c command
On Tue, Nov 21, 2023 at 05:28:43PM +0530, Love Kumar wrote: > Add below test cases for i2c commands: > i2c_bus - To show i2c bus info, > i2c_dev - To set or show the current bus, > i2c_probe - To probe the i2c device, > i2c_eeprom - To test i2c eeprom device, > i2c_probe_all_buses - To list down all the buses and probes it > > Signed-off-by: Love Kumar Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
[PATCH v2 3/3] rpi5: initial support
rpi5: get_board is no longer works. Print model name from
FW FDT
rpi5 deprecated some calls/tags for MBOX. Better to use FW FDT.
However it does not give all information.
Signed-off-by: Dmitry Malkin
---
v2:
new patch
---
board/raspberrypi/rpi/rpi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index cd823ad746..6b678c5d23 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -429,6 +429,7 @@ static void get_board_revision(void)
int ret;
const struct rpi_model *models;
uint32_t models_count;
+const char *fdt_model;
BCM2835_MBOX_INIT_HDR(msg);
BCM2835_MBOX_INIT_TAG(>get_board_rev, GET_BOARD_REV);
@@ -437,6 +438,11 @@ static void get_board_revision(void)
if (ret) {
printf("bcm2835: Could not query board revision\n");
/* Ignore error; not critical */
+if (fdt_magic(fw_dtb_pointer) == FDT_MAGIC) {
+fdt_model = fdt_getprop((void *)fw_dtb_pointer, 0, "model", NULL);
+if (fdt_model != 0)
+printf("FW FDT model : %s\n", fdt_model);
+}
return;
}
--
2.40.1
[PATCH v2 2/3] rpi5: initial support
rpi5: add alternative way to get MBOX address via FDT
node
MBOX on RPI5/bcm2712 has a different offset. Find it via
"brcm,bcm2835-mbox" node.
Signed-off-by: Dmitry Malkin
---
v2:
new patch
---
arch/arm/mach-bcm283x/include/mach/base.h | 1 +
arch/arm/mach-bcm283x/include/mach/mbox.h | 4 ++--
arch/arm/mach-bcm283x/init.c | 12 +++-
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-bcm283x/include/mach/base.h
b/arch/arm/mach-bcm283x/include/mach/base.h
index 4ccaf69693..8cd224921e 100644
--- a/arch/arm/mach-bcm283x/include/mach/base.h
+++ b/arch/arm/mach-bcm283x/include/mach/base.h
@@ -7,6 +7,7 @@
#define _BCM283x_BASE_H_
extern unsigned long rpi_bcm283x_base;
+extern unsigned long rpi_bcm283x_mbox_addr;
#ifdef CONFIG_ARMV7_LPAE
#ifdef CONFIG_TARGET_RPI_4_32B
diff --git a/arch/arm/mach-bcm283x/include/mach/mbox.h
b/arch/arm/mach-bcm283x/include/mach/mbox.h
index 490664f878..ad086be467 100644
--- a/arch/arm/mach-bcm283x/include/mach/mbox.h
+++ b/arch/arm/mach-bcm283x/include/mach/mbox.h
@@ -38,8 +38,8 @@
/* Raw mailbox HW */
-#define BCM2835_MBOX_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
- rpi_bcm283x_base + 0xb880; })
+#define BCM2835_MBOX_PHYSADDR ({ BUG_ON(!rpi_bcm283x_mbox_addr); \
+ rpi_bcm283x_mbox_addr; })
struct bcm2835_mbox_regs {
u32 read;
diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index 362838e9b9..aef3a31f29 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -145,6 +145,11 @@ static void rpi_update_mem_map(void) {}
unsigned long rpi_bcm283x_base = 0x3f00;
+/* This is intialized before relocation. Enforce .data section usage.
+ * Otherwise it's going to .bss and will be zero after relocation.
+ */
+unsigned long __section(".data") rpi_bcm283x_mbox_addr;
+
int arch_cpu_init(void)
{
icache_enable();
@@ -154,7 +159,7 @@ int arch_cpu_init(void)
int mach_cpu_init(void)
{
-int ret, soc_offset;
+int ret, soc_offset, mbox_offset;
u64 io_base, size;
rpi_update_mem_map();
@@ -170,6 +175,11 @@ int mach_cpu_init(void)
return ret;
rpi_bcm283x_base = io_base;
+rpi_bcm283x_mbox_addr = rpi_bcm283x_base + 0xb880;
+
+mbox_offset = fdt_node_offset_by_compatible((void*)gd->fdt_blob,
soc_offset, "brcm,bcm2835-mbox");
+if (mbox_offset > soc_offset)
+rpi_bcm283x_mbox_addr =
fdt_get_base_address((void*)gd->fdt_blob, mbox_offset);
return 0;
}
--
2.40.1
[PATCH v2 1/3] rpi5: initial support
rpi5: add initial memory map for bcm2712
includes:
* 1GB of RAM (from 4GB or 8GB total)
* VPU memory interface
* SOC range (main peripherals)
Signed-off-by: Dmitry Malkin
---
v2:
new patch
---
arch/arm/mach-bcm283x/init.c | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index 7265faf6ce..362838e9b9 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -68,6 +68,33 @@ static struct mm_region
bcm2711_mem_map[MEM_MAP_MAX_ENTRIES] = {
}
};
+static struct mm_region bcm2712_mem_map[MEM_MAP_MAX_ENTRIES] = {
+{
+.virt = 0xUL,
+.phys = 0xUL,
+.size = 0x3f80UL,
+.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+ PTE_BLOCK_INNER_SHARE
+}, {
+.virt = 0x3f80UL,
+.phys = 0x3f80UL,
+.size = 0x0080UL,
+.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+ PTE_BLOCK_NON_SHARE |
+ PTE_BLOCK_PXN | PTE_BLOCK_UXN
+}, {
+.virt = 0x107c00UL,
+.phys = 0x107c00UL,
+.size = 0x000400UL,
+.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+ PTE_BLOCK_NON_SHARE |
+ PTE_BLOCK_PXN | PTE_BLOCK_UXN
+}, {
+/* List terminator */
+0,
+}
+};
+
struct mm_region *mem_map = bcm283x_mem_map;
/*
@@ -78,6 +105,7 @@ static const struct udevice_id board_ids[] = {
{ .compatible = "brcm,bcm2837", .data = (ulong)_mem_map},
{ .compatible = "brcm,bcm2838", .data = (ulong)_mem_map},
{ .compatible = "brcm,bcm2711", .data = (ulong)_mem_map},
+{ .compatible = "brcm,bcm2712", .data = (ulong)_mem_map},
{ },
};
--
2.40.1
[PATCH v2 0/3] rpi5: initial support
These patches bring initial boot support for RPI5. Without it the latest master fails with the message: > DRAM: mbox: Timeout waiting for response > bcm2835: Could not query ARM memory size With those patches and rpi_arm64_defconfig (with disabled CONFIG_VIDEO_BCM2835) I'm able to get a working u-boot prompt (over serial). FDT comes from firmware (EEPROM). > U-Boot 2024.01-rc3-3 > > DRAM: 1016 MiB (effective 8 GiB) > mbox: Header response code invalid > bcm2835: Could not query board revision > FDT model : Raspberry Pi 5 Model B Rev 1.0 > Core: 14 devices, 7 uclasses, devicetree: board > MMC: > Loading Environment from FAT... ** Bad device specification mmc 0 ** > In:serial,usbkbd > Out: serial,vidconsole > Err: serial,vidconsole > Net: No ethernet found. > starting USB... > No working controllers found > Hit any key to stop autoboot: 0 > No working controllers found > No ethernet found. > No ethernet found. > U-Boot> These patches are based on v2024.01-rc3 and tested with RPI5 8GB. Known issues: * CONFIG_VIDEO_BCM2835 doesn't work. * MBOX get board revision (0x10002) doesn't work (the response status is 0x8000_0001). Looks like a number of tags doesn't work anymore (board/serial/MAC) but could be fetched from FW FDT. v2: explicitly set .data section for rpi_bcm283x_mbox_addr due to relocation issue update memory map with VPU range add a patch to get human readable model from FW FDT Dmitry Malkin (3): rpi5: add initial memory map for bcm2712 rpi5: add alternative way to get MBOX address via FDT node rpi5: get_board is no longer works. Print model name from FW FDT arch/arm/mach-bcm283x/include/mach/base.h | 1 + arch/arm/mach-bcm283x/include/mach/mbox.h | 4 +-- arch/arm/mach-bcm283x/init.c | 40 ++- board/raspberrypi/rpi/rpi.c | 6 4 files changed, 48 insertions(+), 3 deletions(-) -- 2.40.1
Re: [PATCH] test/py: mii: Add tests for mii command
On Tue, Nov 21, 2023 at 02:10:51PM +0530, Love Kumar wrote: > Add below test cases for mii commands: > mii_info -To display MII PHY info > mii_list - To list MII devices > mii_set_device - To set MII device > mii_read - To reads register from MII PHY address > mii_dump - To display data from MII PHY address > > Signed-off-by: Love Kumar A thing I'm not sure about now is on my j721e_evm_a72: => mii device MII devices: 'mdio@f00' 'ethernet@4600port@1' Current device: 'mdio@f00' => mii info => => mii device 'ethernet@4600port@1' => mii info 0 PHY 0x00: OUI = 0x80028, Model = 0x23, Rev = 0x01, 100baseT, FDX Which I think matches how things are overall on this platform. So, I don't know if it's reasonable to say I should just disable the test here entirely, or if the test should be able to / require device to be set. Especially since I think as-written it's finding a bug in FEC stuff. -- Tom signature.asc Description: PGP signature
Re: [PATCH] test/py: mii: Add tests for mii command
On Tue, Nov 21, 2023 at 02:10:51PM +0530, Love Kumar wrote:
> Add below test cases for mii commands:
> mii_info -To display MII PHY info
> mii_list - To list MII devices
> mii_set_device - To set MII device
> mii_read - To reads register from MII PHY address
> mii_dump - To display data from MII PHY address
>
> Signed-off-by: Love Kumar
> ---
> test/py/tests/test_mii.py | 68 +++
> 1 file changed, 68 insertions(+)
> create mode 100644 test/py/tests/test_mii.py
>
> diff --git a/test/py/tests/test_mii.py b/test/py/tests/test_mii.py
> new file mode 100644
> index ..b213df3e3f2e
> --- /dev/null
> +++ b/test/py/tests/test_mii.py
> @@ -0,0 +1,68 @@
> +# SPDX-License-Identifier: GPL-2.0
> +# (C) Copyright 2023, Advanced Micro Devices, Inc.
> +
> +import pytest
> +import re
> +
> +"""
> +Note: This test doesn't rely on boardenv_* configuration value but they can
> +change test behavior.
> +
> +For example:
> +
> +# Setup env__mii_deive_test_skip to True if tests with ethernet PHY devices
> +# should be skipped. For example: Missing PHY device
> +env__mii_device_test_skip = True
> +
> +It also checks for MII PHY device exist or not, it skips the test if PHY
> device
> +does not exist.
> +"""
> +
> +@pytest.mark.buildconfigspec("cmd_mii")
> +def test_mii_info(u_boot_console):
> +if u_boot_console.config.env.get("env__mii_device_test_skip", False):
> +pytest.skip("MII device test is not enabled!")
> +expected_output = "PHY"
> +output = u_boot_console.run_command("mii info")
> +if not re.search(r"PHY (.+?):", output):
> +pytest.skip("PHY device does not exist!")
> +assert expected_output in output
> +
> +@pytest.mark.buildconfigspec("cmd_mii")
> +def test_mii_list(u_boot_console):
> +if u_boot_console.config.env.get("env__mii_device_test_skip", False):
> +pytest.skip("MII device test is not enabled!")
> +expected_output = "Current device"
> +output = u_boot_console.run_command("mii device")
> +if not re.search(r"Current device: '(.+?)'", output):
> +pytest.skip("PHY device does not exist!")
> +assert expected_output in output
> +
> +@pytest.mark.buildconfigspec("cmd_mii")
> +def test_mii_set_device(u_boot_console):
> +test_mii_list(u_boot_console)
> +output = u_boot_console.run_command("mii device")
> +eth_num = re.search(r"MII devices: '(.+?)'", output).groups()[0]
> +u_boot_console.run_command(f"mii device {eth_num}")
> +output = u_boot_console.run_command("echo $?")
OK, so this here breaks the next test for me:
=> mii device FEC0
=> mii info
Incorrect PHY address. Range should be 0-31
mii - MII utility commands
...
But doing "mii info 0" next does work. However, what also works if I
have not done "mii device FEC0" but just "mii device" then "mii info"
works. And if I do "mii info 0" and then "mii info" it also works,
because I assume there's some struct member being set somewhere or
similar?
So good news / bad news, the test looks good and seems to have found an
issue that needs to be resolved. The question is, does this patch work
as-is on your platforms? I suspect it does and this is just a problem on
the FEC driver as it looked OK on another platform here real quick, and
I just want to confirm.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/4] tools: mkeficapsule: Add support for parsing capsule params from config file
On Tue, Nov 21, 2023 at 03:11:50PM -0700, Simon Glass wrote: > Hi Sughosh, > > On Tue, 21 Nov 2023 at 00:02, Sughosh Ganu wrote: > > > > Add support for specifying the parameters needed for capsule > > generation through a config file, instead of passing them through > > command-line. Parameters for more than a single capsule file can be > > specified, resulting in generation of multiple capsules through a > > single invocation of the command. > > > > The config file can then be passed to the mkeficapsule tool in such > > manner > > > > $ ./tools/mkeficapsule -f > > > > Signed-off-by: Sughosh Ganu > > --- > > tools/Kconfig | 15 ++ > > tools/Makefile | 1 + > > tools/eficapsule.h | 114 > > tools/mkeficapsule.c | 87 + > > tools/mkeficapsule_parse.c | 352 + > > 5 files changed, 538 insertions(+), 31 deletions(-) > > create mode 100644 tools/mkeficapsule_parse.c > > This patch keeps coming back :-) > > Can we not add multiple capsules in the binman description? Why do we > need a new file format? How can binman decode images produced in this > way? > > Also, could we get sandbox to produce one EFI capsule as part of the > normal build? I think that discussion trailed off. I believe part of the answer here is to support the config file format that other capsule generators use. Do I recall this all right, Sughosh? -- Tom signature.asc Description: PGP signature
Re: [PATCH 09/21] configs: add dragonboard410c_chainloaded_defconfig
Hi Caleb, On Tue, 21 Nov 2023 at 13:21, Caleb Connolly wrote: > > > > On 21/11/2023 19:08, Tom Rini wrote: > > On Tue, Nov 21, 2023 at 05:09:32PM +, Caleb Connolly wrote: > > > >> Revive support for booting db410c using the Linux kernel header, this > >> allows for testing the board more easily via `fastboot`. > >> > >> Signed-off-by: Caleb Connolly > >> --- > >> board/qualcomm/dragonboard410c/MAINTAINERS| 1 + > >> configs/dragonboard410c_chainloaded_defconfig | 75 > >> +++ > >> 2 files changed, 76 insertions(+) > > > > How different is this from the regular defconfig, and assuming this is > > also a partial answer to my question about "why not select?", why is > > this not just a config fragment instead of a whole new defconfig to keep > > in sync? > > Oh, I was totally unaware of the concept of board config fragments in > U-Boot. That's definitely a much cleaner solution. Can you make a single image that handles both? There is ll_boot_init() Regards, Simon
Re: [PATCH v2 2/7] acpi: carve out qfw_acpi.c
On Tue, 21 Nov 2023 at 08:28, Heinrich Schuchardt wrote: > > Move the code related to copying tables from QEMU to a separate code > module. > > Signed-off-by: Heinrich Schuchardt > --- > v2: > new patch > --- > drivers/misc/Makefile | 1 + > drivers/misc/qfw.c | 240 - > drivers/misc/qfw_acpi.c | 256 > 3 files changed, 257 insertions(+), 240 deletions(-) > create mode 100644 drivers/misc/qfw_acpi.c Reviewed-by: Simon Glass
Re: [PATCH 1/4] tools: mkeficapsule: Add support for parsing capsule params from config file
Hi Sughosh, On Tue, 21 Nov 2023 at 00:02, Sughosh Ganu wrote: > > Add support for specifying the parameters needed for capsule > generation through a config file, instead of passing them through > command-line. Parameters for more than a single capsule file can be > specified, resulting in generation of multiple capsules through a > single invocation of the command. > > The config file can then be passed to the mkeficapsule tool in such > manner > > $ ./tools/mkeficapsule -f > > Signed-off-by: Sughosh Ganu > --- > tools/Kconfig | 15 ++ > tools/Makefile | 1 + > tools/eficapsule.h | 114 > tools/mkeficapsule.c | 87 + > tools/mkeficapsule_parse.c | 352 + > 5 files changed, 538 insertions(+), 31 deletions(-) > create mode 100644 tools/mkeficapsule_parse.c This patch keeps coming back :-) Can we not add multiple capsules in the binman description? Why do we need a new file format? How can binman decode images produced in this way? Also, could we get sandbox to produce one EFI capsule as part of the normal build? I think that discussion trailed off. Regards, Simon
Re: [PATCH v2 1/7] acpi: Kconfig symbol CONFIG_QFW_ACPI
On Tue, 21 Nov 2023 at 08:28, Heinrich Schuchardt wrote: > > We have two implementations of write_acpi_tables(). One for writing ACPI > tables based on ACPI_WRITER() entries another based on copying tables from > QEMU. > > Create a symbol CONFIG_QFW_ACPI that signifies copying ACPI tables from > QEMU and use it consistently. > > Signed-off-by: Heinrich Schuchardt > --- > v2: > new patch > --- > drivers/misc/Kconfig | 7 +++ > drivers/misc/qfw.c | 4 ++-- > lib/acpi/Makefile | 2 +- > lib/acpi/acpi_writer.c | 4 ++-- > 4 files changed, 12 insertions(+), 5 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH 1/2] global: Clean up arch/*/dts/Makefile
Hi Tom,
On Tue, 21 Nov 2023 at 07:03, Tom Rini wrote:
>
> On Mon, Nov 20, 2023 at 07:16:12PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Sun, 19 Nov 2023 at 13:28, Tom Rini wrote:
> > >
> > > On Sun, Nov 19, 2023 at 12:09:07PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 17 Nov 2023 at 15:52, Tom Rini wrote:
> > > > >
> > > > > With commit 3609e1dc ("dts: automatically build necessary .dtb files")
> > > > > we now have logic that will ensure that all device trees needed in the
> > > > > binary are built automatically. Any device tree that the developer
> > > > > needs
> > > > > while working can still be built normally via make arch/.../foo.dtb so
> > > > > we can simply drop the rest of this logic.
> > > > >
> > > > > Suggested-by: Rasmus Villemoes
> > > > > Signed-off-by: Tom Rini
> > > > > ---
> > > > > arch/arc/dts/Makefile|8 -
> > > > > arch/arm/dts/Makefile| 1436
> > > > > +-
> > > > > arch/m68k/dts/Makefile | 18 -
> > > > > arch/microblaze/dts/Makefile |2 -
> > > > > arch/mips/dts/Makefile | 37 -
> > > > > arch/nios2/dts/Makefile |2 -
> > > > > arch/powerpc/dts/Makefile| 32 -
> > > > > arch/riscv/dts/Makefile |9 -
> > > > > arch/sandbox/dts/Makefile|5 -
> > > > > arch/sh/dts/Makefile |2 +-
> > > > > arch/x86/dts/Makefile| 22 -
> > > > > arch/xtensa/dts/Makefile |2 -
> > > > > configs/iot2050_defconfig|1 +
> > > > > 13 files changed, 6 insertions(+), 1570 deletions(-)
> > > >
> > > > I can see the motivation for this, but it ends up moving us away from
> > > > driver model and devicetree, IMO. For example, rk3399 and other
> > > > rockchip boards use DT for their init so the same U-Boot can be used
> > > > for all, mostly. Ideally that is the way all boards would be, as they
> > > > are in Linux.
> > > >
> > > > But here I have to manually add all the rk3399 boards to OF_LIST for
> > > > each board and enable SPL_LOAD_FIT (and SPL_FRAMEWORK but that is
> > > > fine) to make this work.
> > >
> > > How are you doing this today on N rk3399 boards if you aren't tweaking a
> > > CONFIG option to get the correct dtb in to the final binary? That I
> > > think is where we go back-and-forth on stuff like this.
> >
> > Basically without SPL_FIT_LOAD it works by stuffing the correct DT
> > into the final image just before it is flashed. But I do imagine in a
> > world where (say) TPL is different for each board but SPL, TF-A,
> > OP-TEE and U-Boot proper are the same for each board.
> >
> > But really we need to encourage these complex SoCs to use runtime
> > configuration from go to whoa. Where DT cannot be used (e.g. TPL) we
> > can do the Zephyr trick or perhaps create a little SoC-specific config
> > block which is provided separately and tacked onto the generic TPL
> > image. Having said that, TPL images are small, so the impact of having
> > one per board is not great.
> >
> > > If there's
> > > deconfigs that can support N boards, but only list a, or only a few, dtb
> > > files in the right CONFIG variable how do you get it to run on the
> > > others? I know you noted some Exynos platforms it's a simple concat to
> > > make another platform work instead. But I really don't know how common
> > > that is in theory, and even less so in practice. Picking up rk3399, you
> > > need bl31 and op-tee and you can only get those so generic too.
> >
> > I understand that they are 100% generic for rk3399. E.g. for TF-A you
> > use PLAT=rk3399 and that is that.
> >
> > >
> > > And part of the issue is that with Linux, the "do board specific things"
> > > just gets pushed down a layer, to us. We have to just know X/Y/Z at
> > > build time so that someone else can know it at run time.
> >
> > Sure, and naturally that gets pushed down from U-Boot proper (which I
> > think is becoming quite generic) to SPL, TPL, etc.
> >
> > If it would help, I could try out (say) rockpro64-rk3399 and
> > firefly-rk3399 to show how this works?
> >
> > I know it is tempting to build everything individually, but it won't
> > be nice. Binman knows what is needed for each board and can be used
> > (one day) to create update files for an SoC without duplication. As
> > soon as you give up on the commonality, everything just explodes in
> > size, complexity and user confusion.
>
> I guess with all of what you said I still don't understand why we need
> the sometimes wrong and not really used lists of dtb files in
> arch/*/dts/Makefile. A rockpro64-rk3399-tpl-only_defconfig still needs
> to say CONFIG_DEFAULT_DEVICETREE="rk3399-rockpro64" so that you build
> the tree so that it's available to binman. We have configs today that
> build and support N boards, and so use SPL_LOAD_FIT and are as generic
> as they can be. The only thing that this patch here changes is that
> you're relying on an implicit CONFIG symbol to list whatever device
> trees you want to be
Re: [PATCH 4/7] WIP: efi: Disable ANSI output
Hi Heinrich,
On Tue, 21 Nov 2023 at 10:32, Heinrich Schuchardt wrote:
>
> On 11/21/23 12:35, Simon Glass wrote:
> > We don't want ANSI characters written in tests since it is a pain to
> > check the output.
>
> I never experienced such pain. The Gitlab output just renders things as
> expected.
>
> >
> > For now, don't bother checking the console size.
> >
> > A better solution is need, which allows ANSI output to be controlled
> > within EFI.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > include/efi_loader.h | 14 --
> > lib/efi_loader/efi_console.c | 17 +++--
> > lib/efi_loader/efi_setup.c | 2 +-
> > 3 files changed, 20 insertions(+), 13 deletions(-)
> >
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index 247be060e1c0..ebe951922791 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -527,8 +527,18 @@ efi_status_t
> > efi_bootmgr_update_media_device_boot_option(void);
> > efi_status_t efi_bootmgr_delete_boot_option(u16 boot_index);
> > /* search the boot option index in BootOrder */
> > bool efi_search_bootorder(u16 *bootorder, efi_uintn_t num, u32 target,
> > u32 *index);
> > -/* Set up console modes */
> > -void efi_setup_console_size(void);
> > +
> > +/**
> > + * efi_setup_console_size() - update the mode table.
> > + *
> > + * @allow_ansi: Allow emitting ANSI characters
> > + *
> > + * By default the only mode available is 80x25. If the console has at
> > least 50
> > + * lines, enable mode 80x50. If we can query the console size and it is
> > neither
> > + * 80x25 nor 80x50, set it as an additional mode.
> > + */
> > +void efi_setup_console_size(bool allow_ansi);
> > +
> > /* Install device tree */
> > efi_status_t efi_install_fdt(void *fdt);
> > /* Run loaded UEFI image */
> > diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
> > index 28087582e8d6..ea1608f8e6ec 100644
> > --- a/lib/efi_loader/efi_console.c
> > +++ b/lib/efi_loader/efi_console.c
> > @@ -349,22 +349,19 @@ static int __maybe_unused query_vidconsole(int *rows,
> > int *cols)
> > return 0;
> > }
> >
> > -/**
> > - * efi_setup_console_size() - update the mode table.
> > - *
> > - * By default the only mode available is 80x25. If the console has at
> > least 50
> > - * lines, enable mode 80x50. If we can query the console size and it is
> > neither
> > - * 80x25 nor 80x50, set it as an additional mode.
> > - */
> > -void efi_setup_console_size(void)
> > +void efi_setup_console_size(bool allow_ansi)
> > {
> > int rows = 25, cols = 80;
> > int ret = -ENODEV;
> >
> > if (IS_ENABLED(CONFIG_VIDEO))
> > ret = query_vidconsole(, );
> > - if (ret)
> > - ret = query_console_serial(, );
> > + if (ret) {
> > + if (allow_ansi)
> > + ret = query_console_serial(, );
> > + else
> > + ret = 0;
> > + }
> > if (ret)
> > return;
> >
> > diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
> > index e6de685e8795..d4226a3011ac 100644
> > --- a/lib/efi_loader/efi_setup.c
> > +++ b/lib/efi_loader/efi_setup.c
> > @@ -230,7 +230,7 @@ efi_status_t efi_init_obj_list(void)
> > return efi_obj_list_initialized;
> >
> > /* Set up console modes */
> > - efi_setup_console_size();
> > + efi_setup_console_size(false);
>
> This would render our console non-compliant. Please, keep it as is.
>
> Testing is not the primary task of U-Boot. If you need to filter test
> output, please, add a filter method to your test setup.
This is just a WIP patch, but we do need a way to avoid outputting
ANSI output since ut_assert_nextline() needs that. Can you suggest a
better way? Perhaps we could have some EFI settings somewhere?
Regards,
Simon
Re: [BUG] Video does not work as expected on efi-x86_app64.defconfig
Hi Heinrich, On Tue, 21 Nov 2023 at 04:58, Heinrich Schuchardt wrote: > > Hello Simon, > > I have built efi-x86_app64_defconfig on v2024.01-rc3. > > On my laptop the video output appears twice. See > https://gist.githubusercontent.com/xypron/24ceedb749a68031790864c3a35c5f30/raw/30068496f43e5b088300748d062d0ad64674bf46/screenshot_efi-x86_app64.jpg > > Are we accessing the video buffer directly instead of using the EFI API? Yes...well we are using EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID (drivers/video/efi.c) but I suspect we are also writing to the serial port (drivers/serial/efi.c) If you adjust stdout does that help? Regards, Simon
Re: U-Booters at LPC
Hi Sean, On Tue, 14 Nov 2023 at 06:30, Sean Anderson wrote: > > Hi Simon, > > On 11/13/23 15:26, Simon Glass wrote: > > Hi Sean, > > > > On Mon, 13 Nov 2023 at 11:15, Sean Anderson wrote: > >> > >> Hi All, > >> > >> I'm at LPC this week, and I'd love to chat with anyone else who's there > >> in person. > > > > That would be good, but sadly I am not :-( > > Ah, well, there's always more conferences. Maybe EOSS next year? I hope...I might have a lot going on in April...when does the CFP open/close? Regards, Simon
Re: [PATCH 2/4] serial: s5p: Use livetree API to get "id" property
On Tue, 21 Nov 2023 at 10:32, Sam Protsenko wrote:
>
> On Mon, Nov 13, 2023 at 12:01 PM Simon Glass wrote:
> > >
> > > The 'port_id' seems to be needed for ARCH_EXYNOS4 boards. Because
> > > Exynos4 doesn't have proper DM clocks, it uses 'id' property to get
> > > corresponding UART clock frequency from its mach code.
> > >
> > > Here is what's happening in the serial driver in case of Exynos4:
> > >
> > > 1. get_uart_clk(port_id) is called
> > > 2. which in turn calls exynos4_get_uart_clk(port_id)
> > > 3. which uses "port_id" value to read corresponding bits of of
> > > CLK_SRC_PERIL0 register
> > > 4. those bits are used to get corresponding PLL clock's frequency
> > > 5. which is in turn used to calculate UART clock rate
> > > 6. calculated rate is returned by get_uart_clk() to serial driver
> > >
> > > So I don't see any *easy* way we can get rid of that id property.
> > >
> > > The proper way of doing that would require converting Exynos4 clock
> > > code to CCF (enabling CONFIG_CLK_EXYNOS). Which of course also means
> > > implementing clocks in dts, akin to kernel's exynos4.dtsi. Then it'll
> > > be possible to get rid of 'id' property.
> >
> > That sounds good!
> >
> > >
> > > Maybe I'm missing something, please let me know.
> >
> > An easy way in the meantime would be to look at the compatible / reg
> > property, e.g. here is a sketch:
> >
> > static int get_id(ofnode node)
> > {
> > ulong addr = (ulong)plat->reg;
> > if (ofnode_device_is_compatible(node, "samsung,exynos4210-uart")) {
> > return (addr >> 16) & 0xf;
> > ...
> >
> > reg = <0x1380 0x3c>;
> > id = <0>;
> > };
> >
> > serail_1: serial@1381 {
> > compatible = "samsung,exynos4210-uart";
> > reg = <0x1381 0x3c>;
> > id = <1>;
> > };
> >
> > serial_2: serial@1382 {
> > compatible = "samsung,exynos4210-uart";
> > reg = <0x1382 0x3c>;
> > id = <2>;
> > };
> >
> > serial_3: serial@1383 {
> > compatible = "samsung,exynos4210-uart";
> > reg = <0x1383 0x3c>;
> > id = <3>;
> > };
> >
> > serial_4: serial@1384 {
> > compatible = "samsung,exynos4210-uart";
> > reg = <0x1384 0x3c>;
> > id = <4>;
> >
>
> To be honest, I'm a bit of busy right now working on U-Boot port for a
> new Exynos dev board, which I want to finalize and upstream ASAP. Do
> you think it's possible to take this one as is for now? At least it
> fixes one issue (fdtdec API and global data pointer).
>
> Thanks!
Yes, OK with me.
Reviewed-by: Simon Glass
Re: [PATCH 3/7] efi: test: Create a disk image with and EFI app in it
Hi Heinrich, On Tue, 21 Nov 2023 at 10:37, Heinrich Schuchardt wrote: > > On 11/21/23 12:35, Simon Glass wrote: > > Create a new disk for use with test, which contains the sandbox > > helloworld app. This will be used to test the EFI boot bootmeth. > > > > Signed-off-by: Simon Glass > > --- > > > > test/py/tests/test_ut.py | 32 > > 1 file changed, 32 insertions(+) > > > > diff --git a/test/py/tests/test_ut.py b/test/py/tests/test_ut.py > > index 1d9149a3f683..f6220c05238a 100644 > > --- a/test/py/tests/test_ut.py > > +++ b/test/py/tests/test_ut.py > > @@ -468,6 +468,37 @@ def test_ut_dm_init(u_boot_console): > > with open(fn, 'wb') as fh: > > fh.write(data) > > > > + > > +def setup_efi_image(cons): > > +"""Create a 20MB disk image with an EFI app on it""" > > +mmc_dev = 7 > > +fname, mnt = setup_image(cons, mmc_dev, 0xc, second_part=True) > > If you would set the partition type GUID to ESP, U-Boot would stop to > complain about EFI variable that cannot be persisted. Doesn't that need a GPT partition type? We do use that for the ChromeOS bootmeth (in setup_cros_image) so we could use it here too. > > There is a pending patch that wants to make the failure to persist EFI > variable fatal. > > [RESEND,v2] efi_loader: Fix UEFI variable error handling > https://patchwork.ozlabs.org/project/uboot/patch/20231113161031.138304-1-o451686...@gmail.com/ Regards, Simon
Re: [PATCH 6/7] WIP: efi: Allow helloworld to exit boot services
Hi Heinrich,
On Tue, 21 Nov 2023 at 10:17, Heinrich Schuchardt wrote:
>
> On 11/21/23 12:35, Simon Glass wrote:
> > This allows testing of the exit_boot_services call, providing more
> > coverage of the EFI bootmeth.
> >
> > Signed-off-by: Simon Glass
>
> I would prefer to keep helloworld.efi benign.
>
> Please, create a new EFI binary for testing ExitBootServices().
Eek...isn't helloworld already used in tets?
>
> > ---
> >
> > lib/efi_loader/helloworld.c | 36 +++-
> > 1 file changed, 35 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/efi_loader/helloworld.c b/lib/efi_loader/helloworld.c
> > index 1135d3a3c37e..1fb5fb5a62f2 100644
> > --- a/lib/efi_loader/helloworld.c
> > +++ b/lib/efi_loader/helloworld.c
> > @@ -206,6 +206,26 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
> > (con_out, u"Cannot open loaded image protocol\r\n");
> > goto out;
> > }
> > +
> > + {
> > + ulong ptr = (ulong)loaded_image;
> > + u16 str[80];
> > + int i;
> > +
> > + for (i = 0; i < 8; i++) {
> > + uint digit = (ptr >> ((7 - i) * 4)) & 0xf;
> > +
> > + if (digit > 9)
> > + digit = 'a' + digit - 10;
> > + else
> > + digit += '0';
> > + str[i] = digit;
> > + }
> > + str[i] = 0;
> > + con_out->output_string(con_out, str);
> > + con_out->output_string(con_out, u"\n");
> > + }
> > +
> > print_load_options(loaded_image);
> >
> > /* Get the device path to text protocol */
> > @@ -243,7 +263,21 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
> > goto out;
> >
> > out:
> > - boottime->exit(handle, ret, 0, NULL);
> > + /*
> > + * TODO: Use vendor string to decide whether to call
> > exit-boot-services
> > + */
> > + efi_uintn_t map_size = 0;
> > + efi_uintn_t map_key;
> > + efi_uintn_t desc_size;
> > + u32 desc_version;
> > +
> > + ret = boottime->get_memory_map(_size, NULL, _key, _size,
> > +_version);
> > + con_out->output_string(con_out, u"Exiting boot sevices\n");
> > +
> > + boottime->exit_boot_services(handle, map_key);
> > +
> > + ret = boottime->exit(handle, ret, 0, NULL);
>
> After ExitBootServices() you must not call boot services.
>
> Call runtime->reset_system(EFI_RESET_COLD, EFI_SUCCESS, 0, NULL) instead.
OK, will do. That will be ignored by sandbox, right?
For now this is just a hack to try to resolve the problem mentioned.
Regards,
Simon
Re: [PATCH 7/7] WIP: efi: debugging
Hi Heinrich, On Tue, 21 Nov 2023 at 10:20, Heinrich Schuchardt wrote: > > On 11/21/23 12:35, Simon Glass wrote: > > This works when run outside a test: > > > > good: > > > > /tmp/b/sandbox/u-boot -T > > -c "bootfl scan mmc; bootfl sel 1; bootfl list; bootfl b" > > > > ** Booting bootflow 'mmc7.bootdev.part_1' with efi > > desc = 18c86ee0 > > dev=mmc, devnr=7:1, path=efi/boot/bootsbox.efi, buffer=11001000, > > size=1600 > > - boot device > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,)/SD(7)/SD(3)/HD(1,MBR,0x2f7d9756,0x800,0x9000) > > - image /efi\boot\bootsbox.efi > > No EFI system partition > > No EFI system partition > > Failed to persist EFI variables > > EFI using ACPI tables at 8ef8000 > > WARNING: Can't have ACPI table and device tree - ignoring DT. > > Loaded from disk > > Booting /efi\boot\bootsbox.efi > > EFI: Call: efi_load_image(false, efi_root, file_path, source_buffer, > > source_size, ) > > info->device_handle = 18f180e0 > > loaded_image info for 18f184e0: 18f18470 > > > > EFI: 0 returned by efi_load_image(false, efi_root, file_path, > > source_buffer, source_size, ) > > EFI: Call: efi_start_image(handle, _data_size, _data) > > Hello, world! > > Running on UEFI 2.10 > > Have ACPI 2.0 table > > Have SMBIOS table > > 18f18470 > > Load options: > > finding > > - search 18c931a0 ret=0 > > File path: /efi\boot\bootsbox.efi > > Vendor: Das U-Boot > > Boot device: > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,)/SD(7)/SD(3)/HD(1,MBR,0x2f7d9756,0x800,0x9000) > > Exiting boot sevices > > EFI: 5 returned by efi_start_image(handle, _data_size, _data) > > Boot failed (err=-22) > > > > bad: > > > > rtv bootflow_efi > > > > ** Booting bootflow 'mmc7.bootdev.part_1' with efi > > Should we have an ESP on the MMC image to persist UEFI variables? That would be a good enhancement, but I would like to get the basics going first. Regards, Simon
Re: [PATCH] mtd: rawnand: omap_gpmc: fix BCH8 HW based correction
Hi,
On 15/11/2023 13:36, Heiko Schocher wrote:
> Hello Roger,
>
> On 15.11.23 12:09, Roger Quadros wrote:
>>
>>
>> On 15/11/2023 07:40, Heiko Schocher wrote:
>>> commit 04fcd2587321 ("mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based
>>> correction")
>>>
>>> broke AM335x based boards booting from NAND with ECC BCH8 code.
>>>
>>> Use omap_enable_hwecc() instead of omap_enable_hwecc_bch()
>>> in SPL restores correct SPL nand_read_page functionality.
>>>
>>> Tested on draco thuban board.
>>>
>>> Signed-off-by: Heiko Schocher
>>>
>>> ---
>>> fix NAND boot for BCH8 based TI AM335x boards
>>>
>>> Fix is based on series from Enrico:
>>>
>>> https://lists.denx.de/pipermail/u-boot/2023-November/536793.html
>>>
>>> and fixes NAND boot for the draco thuban board. But this patch
>>> apply also without the patches from above patchseries, see
>>> azure build:
>>>
>>> https://dev.azure.com/hs0298/hs/_build/results?buildId=111=results
>>>
>>> which is clean.
>>>
>>> Above commit seems to change only U-Boot code and did not
>>> adapt am335x_spl_bch.c, which breaks nand_read_page in SPL
>>> code for AM335x based boards. So use in SPL "old" hw setup
>>> and reading page from NAND in SPL works again.
>>>
>>>
>>> drivers/mtd/nand/raw/omap_gpmc.c | 4
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/mtd/nand/raw/omap_gpmc.c
>>> b/drivers/mtd/nand/raw/omap_gpmc.c
>>> index 1a5ed0de31..c9b66dadbd 100644
>>> --- a/drivers/mtd/nand/raw/omap_gpmc.c
>>> +++ b/drivers/mtd/nand/raw/omap_gpmc.c
>>> @@ -983,7 +983,11 @@ static int omap_select_ecc_scheme(struct nand_chip
>>> *nand,
>>> nand->ecc.strength = 8;
>>> nand->ecc.size = SECTOR_BYTES;
>>> nand->ecc.bytes = 14;
>>> +#if defined(CONFIG_SPL_BUILD)
>>> + nand->ecc.hwctl = omap_enable_hwecc;
>>
>> I don't think this is correct. omap_enable_hwecc does not setup
>> the BCH settings and should be used only for 1-bit ECC i.e.
>> OMAP_ECC_HAM1_CODE_*
>>
>> I'm sure it will break the boards not using
>> CONFIG_SPL_NAND_AM33XX_BCH which is
>> pretty much most TI boards that are not AM335x.
>>
>> Now, I need to identify why AM335x NAND is broken.
>
> Yes, I played with setting up stuff in drivers/mtd/nand/raw/am335x_spl_bch.c
> but failed ...
>
> If I can help you testing, feel free to ask!
OK. So I did some tests and we are ending up in a different ECC config on
AM335x.
The ecc.steps is not set at all by the driver (it is at 0) and so so nsectors
gets
set to -1 and so 7 (0b111) which is wrong.
static void __maybe_unused omap_enable_hwecc_bch(struct mtd_info *mtd,
int mode)
{
...
case OMAP_ECC_BCH8_CODE_HW:
bch_type = 1;
nsectors = chip->ecc.steps;
...
/* BCH configuration */
val = ((1 << 16) | /* enable BCH */
(bch_type<< 12) | /* BCH4/BCH8/BCH16 */
(wr_mode << 8) | /* wrap mode */
(dev_width << 7) | /* bus width */
-->(((nsectors - 1) & 0x7) << 4) | /* number of sectors */
(info->cs<< 1) | /* ECC CS */
(0x1));
...
}
setting chip->ecc.steps needs to be fixed in original commit
c3754e9cc23a ("omap_gpmc: BCH8 support (ELM based)")
But this will still not fix the issue for AM335x as am335x_spl_bch.c
expects 1 sector at a time ECC calculation.
I also realized that the error correction logic (ELM) is not in page mode
and so is not suitable for multi-sector error correction.
This means we have to revert the commit
04fcd2587321 ("mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based correction")
and go back to 1 sector BCH ECC generation and correction.
I will send a patch fix in a day or two after doing some tests at my end.
--
cheers,
-roger
Re: [PATCH 1/1] efi_loader: generated SMBIOS table below 4 GiB
Hi Heinrich,
On Tue, 21 Nov 2023 at 00:33, Heinrich Schuchardt
wrote:
>
> We currently use an outdated format 32-bit format for SMBIOS tables.
> So we must allocate SMBIOS tables below 4 GiB.
Can we please adjust the commit message to something that would
represent the situation better 6 months from now?
Mention that this fixes 53fab13a7 ("efi: Use the installed SMBIOS
tables") and keeps the x86 changes while reverting back to allocate
memory < 4GB
Other than that
Reviewed-by: Ilias Apalodimas
Tested-by: Ilias Apalodimas
Thanks
/Ilias
>
> Signed-off-by: Heinrich Schuchardt
> ---
> lib/efi_loader/efi_smbios.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c
> index 48446f654d..0fbf51b98d 100644
> --- a/lib/efi_loader/efi_smbios.c
> +++ b/lib/efi_loader/efi_smbios.c
> @@ -49,25 +49,27 @@ efi_status_t efi_smbios_register(void)
>
> static int install_smbios_table(void)
> {
> - ulong addr;
> - void *buf;
> + u64 addr;
> + efi_status_t ret;
>
> if (!IS_ENABLED(CONFIG_GENERATE_SMBIOS_TABLE) ||
> IS_ENABLED(CONFIG_X86))
> return 0;
>
> - /* Align the table to a 4KB boundary to keep EFI happy */
> - buf = memalign(SZ_4K, TABLE_SIZE);
> - if (!buf)
> + addr = SZ_4G;
> + ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
> +EFI_RUNTIME_SERVICES_DATA,
> +efi_size_in_pages(TABLE_SIZE), );
> + if (ret != EFI_SUCCESS)
> return log_msg_ret("mem", -ENOMEM);
>
> - addr = map_to_sysmem(buf);
> + addr = map_to_sysmem((void *)(uintptr_t)addr);
> if (!write_smbios_table(addr)) {
> log_err("Failed to write SMBIOS table\n");
> return log_msg_ret("smbios", -EINVAL);
> }
>
> /* Make a note of where we put it */
> - log_debug("SMBIOS tables written to %lx\n", addr);
> + log_debug("SMBIOS tables written to %llx\n", addr);
> gd->arch.smbios_start = addr;
>
> return 0;
> --
> 2.40.1
>
Re: [PATCH v3] smbios: arm64: Ensure table is written at a good address
Hi Simon,
On Tue, 21 Nov 2023 at 04:58, 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 automatically choosing an address below 4GB
> (but as high as possible), if needed.
>
> Tell efi_loader about the address in the same way as we do for ACPI
> tables.
>
> Signed-off-by: Simon Glass
> ---
> Please see previous discussion here:
>
> https://patchwork.ozlabs.org/project/uboot/patch/
> 20231025123117.v2.1.I054cad60e00f8cfde39256c7c7d9c960987fb9be@changeid/
>
> Changes in v3:
> - Add RISC-V to the condition, too
> - Update the commit message
>
> Changes in v2:
> - Update to search for a suitable area automatically, if enabled
>
> lib/Kconfig | 13
> lib/efi_loader/efi_smbios.c | 63 -
> 2 files changed, 75 insertions(+), 1 deletion(-)
>
> diff --git a/lib/Kconfig b/lib/Kconfig
> index 19649517a39b..c70faeeebed5 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -998,6 +998,19 @@ config GENERATE_SMBIOS_TABLE
> See also SMBIOS_SYSINFO which allows SMBIOS values to be provided in
> the devicetree.
>
> +config SMBIOS_TABLE_FIXED
> + bool "Place the SMBIOS table at a special address"
> + depends on GENERATE_SMBIOS_TABLE && SMBIOS && EFI_LOADER
> + depends on ARM64 || RISCV
> + default y
> + help
> + Use this option to place the SMBIOS table at a special address.
> +
> + 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. This option works around this problem by
> + chosing an address just below 4GB, if needed.
> +
> endmenu
>
> config LIB_RATIONAL
> diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c
> index 48446f654d9b..566f206af5b6 100644
> --- a/lib/efi_loader/efi_smbios.c
> +++ b/lib/efi_loader/efi_smbios.c
> @@ -47,6 +47,60 @@ efi_status_t efi_smbios_register(void)
>map_sysmem(addr, 0));
> }
>
> +/**
> + * find_addr_below() - Find a usable region below the given max_addr
> + *
> + * Check if *addrp is suitable to define a memory region which finishes below
> + * @max_addr + @req_size. If so, do nothing and return 0
> + *
> + * As a backup, if CONFIG_SMBIOS_TABLE_FIXED is enabled, search for a
> + * 4KB-aligned DRAM region which is large enough. Make sure it is below
> U-Boot's
> + * stack space, assumed to be 64KB.
> + *
> + * @max_addr: Maximum address that can be used (region must finish before
> here)
> + * @req:size: Required size of region
> + * @addrp: On entry: Current proposed address; on exit, holds the new
> address,
> + * on success
> + * Return 0 if OK (existing region was OK, or a new one was found), -ENOSPC
> if
> + * nothing suitable was found
> + */
> +static int find_addr_below(ulong max_addr, ulong req_size, ulong *addrp)
> +{
> + struct bd_info *bd = gd->bd;
> + ulong max_base;
> + int i;
> +
> + max_base = max_addr - req_size;
> + if (*addrp <= max_base)
> + return 0;
> +
> + if (!IS_ENABLED(CONFIG_SMBIOS_TABLE_FIXED))
> + return -ENOSPC;
> +
> + /* Make sure that the base is at least 64KB below the stack */
> + max_base = min(max_base,
> + ALIGN(gd->start_addr_sp - SZ_64K - req_size, SZ_4K));
> +
> + for (i = CONFIG_NR_DRAM_BANKS - 1; i >= 0; i--) {
> + ulong start = bd->bi_dram[i].start;
> + ulong size = bd->bi_dram[i].size;
> + ulong addr;
> +
> + /* chose an address at most req_size bytes before the end */
> + addr = min(max_base, start - req_size + size);
> +
> + /* check this is in the range */
> + if (addr >= start && addr + req_size < start + size) {
> + *addrp = addr;
> + log_warning("Forcing SMBIOS table to address %lx\n",
> + addr);
> + return 0;
> + }
> + }
> +
> + return -ENOSPC;
> +}
This function doesn't really belong here. We should move it to the mem
subsystem.
AFAICT this is a hotfix for 2024.01. So I prefer picking this [0]
instead, since the smbios table generation is still controlled by EFI
[0]
https://lore.kernel.org/u-boot/20231120222558.32014-1-heinrich.schucha...@canonical.com/
Thanks
/Ilias
> +
> static int install_smbios_table(void)
> {
> ulong addr;
> @@ -61,7 +115,14 @@ static int install_smbios_table(void)
> return log_msg_ret("mem", -ENOMEM);
>
> addr = map_to_sysmem(buf);
> - if (!write_smbios_table(addr)) {
> +
> + /*
> +* Deal with a fixed address if
Re: [PATCH v2 3/6] smbios: Use SMBIOS 3.0 to support an address above 4GB
On Tue, Nov 21, 2023 at 10:40:39PM +0200, Ilias Apalodimas wrote:
> Hi Simon
>
> On Tue, 21 Nov 2023 at 04:17, Simon Glass wrote:
> >
> > Hi Heinrich,
> >
> > On Mon, 20 Nov 2023 at 19:11, Heinrich Schuchardt
> > wrote:
> > >
> > > On 10/15/23 04:45, 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.
> > > >
> > > > Note that we cannot use efi_allocate_pages() since this function has
> > > > nothing to do with EFI. There is no equivalent function to allocate
> > > > memory below 4GB in U-Boot. One solution would be to create a separate
> > > > malloc() pool, or just always put the malloc() pool below 4GB.
> > > >
> > > > Signed-off-by: Simon Glass
> > > > ---
> > > >
> > > > Changes in v2:
> > > > - Check the end of the table rather than the start.
> > > >
> > > > include/smbios.h | 22 +-
> > > > lib/smbios.c | 24 +++-
> > > > 2 files changed, 40 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/include/smbios.h b/include/smbios.h
> > > > index c9df2706f5a6..ddabb558299e 100644
> > > > --- a/include/smbios.h
> > > > +++ b/include/smbios.h
> > > > @@ -12,7 +12,8 @@
> > > >
> > > > /* SMBIOS spec version implemented */
> > > > #define SMBIOS_MAJOR_VER3
> > > > -#define SMBIOS_MINOR_VER 0
> > > > +#define SMBIOS_MINOR_VER 7
> > > > +
> > > >
> > > > enum {
> > > > SMBIOS_STR_MAX = 64, /* Maximum length allowed for a string */
> > > > @@ -54,6 +55,25 @@ struct __packed smbios_entry {
> > > > u8 bcd_rev;
> > > > };
> > > >
> > > > +struct __packed smbios3_entry {
> > > > + u8 anchor[5];
> > > > + u8 checksum;
> > > > + u8 length;
> > > > + u8 major_ver;
> > > > +
> > > > + u8 minor_ver;
> > > > + u8 docrev;
> > > > + u8 entry_point_rev;
> > > > + u8 reserved;
> > > > + u32 max_struct_size;
> > > > +
> > > > + u64 struct_table_address;
> > > > +};
> > > > +
> > > > +/* These two structures should use the same amount of 16-byte-aligned
> > > > space */
> > > > +static_assert(ALIGN(16, sizeof(struct smbios_entry)) ==
> > > > + ALIGN(16, sizeof(struct smbios3_entry)));
> > > > +
> > > > /* BIOS characteristics */
> > > > #define BIOS_CHARACTERISTICS_PCI_SUPPORTED (1 << 7)
> > > > #define BIOS_CHARACTERISTICS_UPGRADEABLE(1 << 11)
> > > > diff --git a/lib/smbios.c b/lib/smbios.c
> > > > index c7a557bc9b7b..92e98388084f 100644
> > > > --- a/lib/smbios.c
> > > > +++ b/lib/smbios.c
> > > > @@ -487,7 +487,11 @@ ulong write_smbios_table(ulong addr)
> > > > addr = ALIGN(addr, 16);
> > > > start_addr = addr;
> > > >
> > > > - addr += sizeof(struct smbios_entry);
> > > > + /*
> > > > + * So far we don't know which struct will be used, but they both
> > > > end
> > > > + * up using the same amount of 16-bit-aligned space
> > > > + */
> > > > + addr += max(sizeof(struct smbios_entry), sizeof(struct
> > > > smbios3_entry));
> > > > addr = ALIGN(addr, 16);
> > > > tables = addr;
> > > >
> > > > @@ -512,14 +516,24 @@ ulong write_smbios_table(ulong addr)
> > > >* sandbox's DRAM buffer.
> > > >*/
> > > > table_addr = (ulong)map_sysmem(tables, 0);
> > > > - if (sizeof(table_addr) > sizeof(u32) && table_addr >
> > > > (ulong)UINT_MAX) {
> > > > + if (sizeof(table_addr) > sizeof(u32) && addr >= (ulong)UINT_MAX) {
> > >
> > > You have to check the end of the the last SMBIOS structure not the start
> > > of the first SMBIOS structure against UINT_MAX.
> > >
> > > > + struct smbios3_entry *se;
> > > > /*
> > > >* We need to put this >32-bit pointer into the table but
> > > > the
> > > >* field is only 32 bits wide.
> > > >*/
> > > > - printf("WARNING: SMBIOS table_address overflow %llx\n",
> > > > -(unsigned long long)table_addr);
> > > > - addr = 0;
> > > > + printf("WARNING: Using SMBIOS3.0 due to table-address
> > > > overflow %lx\n",
> > > > +table_addr);
> > >
> > > This should be log_debug().
> > >
> > > > + se = map_sysmem(start_addr, sizeof(struct smbios_entry));
> > > > + memset(se, '\0', sizeof(struct smbios_entry));
> > > > + memcpy(se->anchor, "_SM3_", 5);
> > > > + se->length = sizeof(struct smbios3_entry);
> > > > + se->major_ver = SMBIOS_MAJOR_VER;
> > > > + se->minor_ver = SMBIOS_MINOR_VER;
> > > > + se->docrev = 0;
> > > > + se->entry_point_rev = 1;
> > > > + se->max_struct_size = len;
> > > > + se->struct_table_address = table_addr;
> > >
> > > You must fill the checksum:
> > >
> > > se->checksum = table_compute_checksum(se, sizeof(struct smbios3_entry));
> > >
> > > With the
Re: [PATCH 14/21] mach-snapdragon: dynamic load addresses
On 21/11/2023 19:24, Tom Rini wrote:
> On Tue, Nov 21, 2023 at 05:09:37PM +, Caleb Connolly wrote:
>
>> Heavily inspired by Apple board code. Use the LMB allocator to configure
>> load addresses at runtime, and implement a lookup table for selecting a
>> devicetree.
>>
>> As some Qualcomm RBx boards have different RAM capacities and base
>> addresses, it isn't possible to hardcode these regions.
>>
>> Signed-off-by: Caleb Connolly
> [snip]
>> +#define KERNEL_COMP_SIZESZ_32M
>> +#define SZ_96M (SZ_64M + SZ_32M)
>> +
>> +#define addr_alloc(lmb, size) lmb_alloc(lmb, size, SZ_2M)
>> +
>> +/* Stolen from arch/arm/mach-apple/board.c */
>> +int board_late_init(void)
>> +{
>> +struct lmb lmb;
>> +u32 status = 0;
>> +
>> +lmb_init_and_reserve(, gd->bd, (void *)gd->fdt_blob);
>> +
>> +/* We need to be fairly conservative here as we support boards with
>> just 1G of TOTAL RAM */
>> +status |= env_set_hex("kernel_addr_r", addr_alloc(, SZ_96M));
>> +status |= env_set_hex("loadaddr", addr_alloc(, SZ_64M));
>> +status |= env_set_hex("fdt_addr_r", addr_alloc(, SZ_2M));
>> +status |= env_set_hex("ramdisk_addr_r", addr_alloc(, SZ_96M));
>> +status |= env_set_hex("kernel_comp_addr_r", addr_alloc(,
>> KERNEL_COMP_SIZE));
>> +status |= env_set_hex("kernel_comp_size", KERNEL_COMP_SIZE);
>> +status |= env_set_hex("scriptaddr", addr_alloc(, SZ_4M));
>> +status |= env_set_hex("pxefile_addr_r", addr_alloc(, SZ_4M));
>
> First, with 1G total, we should I think be fine using SZ_128M and not
> needing to add SZ_96M. Second, having worked on
> https://patchwork.ozlabs.org/project/uboot/patch/20231119144338.630138-2-...@chromium.org/
> a bit I think your sizes are a bit funny. We're looking at where to
> decompress the provided Image file to and so 32M is too small. My
> generic v6.6 Image is 40MB. One of those "would be nice" things to see
> now that I've kicked things around a little was if all of our boot$foo
> decompression logic just asked the lmb to give us a new region of
> max-feasible-size for a Linux kernel (or we make it a choice between 64
> or 128MB max supported kernel image). And further looking at the code
> and matching it up with the function docs, it's even funkier than I had
> thought, sigh.
To your first point, yeah it looks like I can get away with 128M
uncompressed, it definitely feels a bit safer heh
To be honest, most of my testing has been booting via bootflow/bootefi
-> systemd-boot which I assume will be using the EFI allocator to load
everything. I still have a lot of local patches to push upstream,
otherwise I'd definitely be interested in finding a cleaner / more
generic solution here.
>
> And to try and be clear, the second is an ask, but the first is a change
> request, those sizes are too small and inconsistent with supporting a
> large uncompressed kernel.
>
--
// Caleb (they/them)
Re: [PATCH v2 3/6] smbios: Use SMBIOS 3.0 to support an address above 4GB
Hi Simon
On Tue, 21 Nov 2023 at 04:17, Simon Glass wrote:
>
> Hi Heinrich,
>
> On Mon, 20 Nov 2023 at 19:11, Heinrich Schuchardt wrote:
> >
> > On 10/15/23 04:45, 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.
> > >
> > > Note that we cannot use efi_allocate_pages() since this function has
> > > nothing to do with EFI. There is no equivalent function to allocate
> > > memory below 4GB in U-Boot. One solution would be to create a separate
> > > malloc() pool, or just always put the malloc() pool below 4GB.
> > >
> > > Signed-off-by: Simon Glass
> > > ---
> > >
> > > Changes in v2:
> > > - Check the end of the table rather than the start.
> > >
> > > include/smbios.h | 22 +-
> > > lib/smbios.c | 24 +++-
> > > 2 files changed, 40 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/include/smbios.h b/include/smbios.h
> > > index c9df2706f5a6..ddabb558299e 100644
> > > --- a/include/smbios.h
> > > +++ b/include/smbios.h
> > > @@ -12,7 +12,8 @@
> > >
> > > /* SMBIOS spec version implemented */
> > > #define SMBIOS_MAJOR_VER3
> > > -#define SMBIOS_MINOR_VER 0
> > > +#define SMBIOS_MINOR_VER 7
> > > +
> > >
> > > enum {
> > > SMBIOS_STR_MAX = 64, /* Maximum length allowed for a string */
> > > @@ -54,6 +55,25 @@ struct __packed smbios_entry {
> > > u8 bcd_rev;
> > > };
> > >
> > > +struct __packed smbios3_entry {
> > > + u8 anchor[5];
> > > + u8 checksum;
> > > + u8 length;
> > > + u8 major_ver;
> > > +
> > > + u8 minor_ver;
> > > + u8 docrev;
> > > + u8 entry_point_rev;
> > > + u8 reserved;
> > > + u32 max_struct_size;
> > > +
> > > + u64 struct_table_address;
> > > +};
> > > +
> > > +/* These two structures should use the same amount of 16-byte-aligned
> > > space */
> > > +static_assert(ALIGN(16, sizeof(struct smbios_entry)) ==
> > > + ALIGN(16, sizeof(struct smbios3_entry)));
> > > +
> > > /* BIOS characteristics */
> > > #define BIOS_CHARACTERISTICS_PCI_SUPPORTED (1 << 7)
> > > #define BIOS_CHARACTERISTICS_UPGRADEABLE(1 << 11)
> > > diff --git a/lib/smbios.c b/lib/smbios.c
> > > index c7a557bc9b7b..92e98388084f 100644
> > > --- a/lib/smbios.c
> > > +++ b/lib/smbios.c
> > > @@ -487,7 +487,11 @@ ulong write_smbios_table(ulong addr)
> > > addr = ALIGN(addr, 16);
> > > start_addr = addr;
> > >
> > > - addr += sizeof(struct smbios_entry);
> > > + /*
> > > + * So far we don't know which struct will be used, but they both end
> > > + * up using the same amount of 16-bit-aligned space
> > > + */
> > > + addr += max(sizeof(struct smbios_entry), sizeof(struct
> > > smbios3_entry));
> > > addr = ALIGN(addr, 16);
> > > tables = addr;
> > >
> > > @@ -512,14 +516,24 @@ ulong write_smbios_table(ulong addr)
> > >* sandbox's DRAM buffer.
> > >*/
> > > table_addr = (ulong)map_sysmem(tables, 0);
> > > - if (sizeof(table_addr) > sizeof(u32) && table_addr >
> > > (ulong)UINT_MAX) {
> > > + if (sizeof(table_addr) > sizeof(u32) && addr >= (ulong)UINT_MAX) {
> >
> > You have to check the end of the the last SMBIOS structure not the start
> > of the first SMBIOS structure against UINT_MAX.
> >
> > > + struct smbios3_entry *se;
> > > /*
> > >* We need to put this >32-bit pointer into the table but
> > > the
> > >* field is only 32 bits wide.
> > >*/
> > > - printf("WARNING: SMBIOS table_address overflow %llx\n",
> > > -(unsigned long long)table_addr);
> > > - addr = 0;
> > > + printf("WARNING: Using SMBIOS3.0 due to table-address
> > > overflow %lx\n",
> > > +table_addr);
> >
> > This should be log_debug().
> >
> > > + se = map_sysmem(start_addr, sizeof(struct smbios_entry));
> > > + memset(se, '\0', sizeof(struct smbios_entry));
> > > + memcpy(se->anchor, "_SM3_", 5);
> > > + se->length = sizeof(struct smbios3_entry);
> > > + se->major_ver = SMBIOS_MAJOR_VER;
> > > + se->minor_ver = SMBIOS_MINOR_VER;
> > > + se->docrev = 0;
> > > + se->entry_point_rev = 1;
> > > + se->max_struct_size = len;
> > > + se->struct_table_address = table_addr;
> >
> > You must fill the checksum:
> >
> > se->checksum = table_compute_checksum(se, sizeof(struct smbios3_entry));
> >
> > With the checksum filled I can use dmidecode in Linux based on the
> > SMBIOS3 table:
> >
> > ubuntu@ubuntu:~$ sudo dmidecode
> > # dmidecode 3.5
> > # SMBIOS3 entry point at 0x27ef53000
> > Found SMBIOS entry point in EFI, reading table from /dev/mem.
> > SMBIOS 3.7.0 present.
> > # SMBIOS implementations newer than version 3.5.0 are not
> > #
Re: [PATCH v2 2/3] efi: Correct display of table GUIDs
On Sun, 12 Nov 2023 at 22:55, Simon Glass wrote:
>
> The printf() %pU option decodes GUIDs so it is not necessary to do this
> first. Drop the incorrect code.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> cmd/efi_common.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/cmd/efi_common.c b/cmd/efi_common.c
> index f4056096cd3f..1aa2351fcdfd 100644
> --- a/cmd/efi_common.c
> +++ b/cmd/efi_common.c
> @@ -17,10 +17,8 @@ void efi_show_tables(struct efi_system_table *systab)
>
> for (i = 0; i < systab->nr_tables; i++) {
> struct efi_configuration_table *tab = >tables[i];
> - char guid_str[37];
>
> - uuid_bin_to_str(tab->guid.b, guid_str, 1);
> - printf("%p %pUl %s\n", tab->table, guid_str,
> + printf("%p %pUl %s\n", tab->table, tab->guid.b,
>uuid_guid_get_str(tab->guid.b) ?: "(unknown)");
> }
> }
> --
> 2.42.0.869.gea05f2083d-goog
>
Reviewed-by: Ilias Apalodimas
Re: [PATCH v2 7/7] configs: qemu: add config fragment for ACPI
On Tue, 21 Nov 2023 at 17:28, Heinrich Schuchardt wrote: > > Provide a configuration fragment to enable ACPI on QEMU. > > Signed-off-by: Heinrich Schuchardt > --- > v2: > new patch > --- > MAINTAINERS | 1 + > board/emulation/configs/acpi.config | 3 +++ > doc/board/emulation/acpi.rst| 23 +++ > doc/board/emulation/index.rst | 1 + > 4 files changed, 28 insertions(+) > create mode 100644 board/emulation/configs/acpi.config > create mode 100644 doc/board/emulation/acpi.rst > > diff --git a/MAINTAINERS b/MAINTAINERS > index 7c1cb2dc4d..9f443674cb 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -53,6 +53,7 @@ Maintainers List (try to look for most precise areas first) > ACPI: > M: Simon Glass > S: Maintained > +F: board/emulation/configs/acpi.config > F: cmd/acpi.c > F: lib/acpi/ > > diff --git a/board/emulation/configs/acpi.config > b/board/emulation/configs/acpi.config > new file mode 100644 > index 00..b7ed811e33 > --- /dev/null > +++ b/board/emulation/configs/acpi.config > @@ -0,0 +1,3 @@ > +CONFIG_CMD_QFW=y > +CONFIG_ACPI=y > +CONFIG_GENERATE_ACPI_TABLE=y > diff --git a/doc/board/emulation/acpi.rst b/doc/board/emulation/acpi.rst > new file mode 100644 > index 00..e1208ca51e > --- /dev/null > +++ b/doc/board/emulation/acpi.rst > @@ -0,0 +1,23 @@ > +.. SPDX-License-Identifier: GPL-2.0+ > + > +ACPI on QEMU > + > + > +QEMU can provide ACPI tables on ARM, RISC-V, and x86. > + > +The following settings are needed:: > + > +CONFIG_CMD_QFW=y > +CONFIG_ACPI=y > +CONFIG_GENERATE_ACPI_TABLE=y > + > +On x86 these settings are already included in the defconfig files. ARM and > +RISC-V default to use device-trees. > + > +Instead of updating the configuration manually you can add the configuration > +fragment `acpi.config` to the make command for initializing the > configuration. > +E.g. > + > +.. code-block:: bash > + > +make qemu-riscv64_smode_defconfig acpi.config > diff --git a/doc/board/emulation/index.rst b/doc/board/emulation/index.rst > index 932c65adeb..d3d6b8f3d8 100644 > --- a/doc/board/emulation/index.rst > +++ b/doc/board/emulation/index.rst > @@ -6,6 +6,7 @@ Emulation > .. toctree:: > :maxdepth: 1 > > + acpi > blkdev > ../../usage/semihosting > qemu-arm > -- > 2.40.1 > Acked-by: Ilias Apalodimas
Re: [PATCH 02/21] arm: allow CONFIG_LINUX_KERNEL_IMAGE_HEADER to be set in defconfig
On Tue, Nov 21, 2023 at 08:17:30PM +, Caleb Connolly wrote: > > > On 21/11/2023 19:07, Tom Rini wrote: > > On Tue, Nov 21, 2023 at 05:09:25PM +, Caleb Connolly wrote: > > > >> Let this option be enabled dynamically for boards that support multiple > >> mechanisms for booting U-Boot (e.g. as a first-stage or chainloaded > >> bootloader). > >> > >> Signed-off-by: Caleb Connolly > >> --- > >> This patch has no dependencies > >> > >> Cc: Simon Glass > >> --- > >> arch/arm/Kconfig | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > >> index bd48131292e3..1add4282f336 100644 > >> --- a/arch/arm/Kconfig > >> +++ b/arch/arm/Kconfig > >> @@ -81,7 +81,7 @@ config SPL_SYS_NO_VECTOR_TABLE > >> > >> config LINUX_KERNEL_IMAGE_HEADER > >>depends on ARM64 > >> - bool > >> + bool "Linux kernel binary header" > >>help > >> Place a Linux kernel image header at the start of the U-Boot binary. > >> The format of the header is described in the Linux kernel source at > > > > Why are we not select'ing this like the other platforms which need the > > same do? > > On some Qualcomm boards we can boot either as a Linux kernel or we can > replace the first-stage bootloader. To run as the primary bootloader we > unset this option and enable REMAKE_ELF as well as configuring a few > other things. > > Would it make more sense to introduce a Qualcomm specific config option > to handle these cases? Well, part of the image header is that if you try and execute it, it's a jump over the rest of the header, yes? So can't we still do the REMAKE_ELF on top of it? -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/7] efi: Use puts() in cout so that console recording works
On Tue, 21 Nov 2023 at 13:36, Simon Glass wrote: > > At present EFI output to the console use fputs() which bypasses the nit, use ->uses > console-recording feature. This makes it impossible for tests to check > the output of an EFI app. > > There doesn't seem to be any need to do this bypass, so adjust it to > simply use the puts() function. > > Signed-off-by: Simon Glass Reviewed-by: Ilias Apalodimas > --- > > lib/efi_loader/efi_console.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c > index a2d137d7a9e1..28087582e8d6 100644 > --- a/lib/efi_loader/efi_console.c > +++ b/lib/efi_loader/efi_console.c > @@ -182,7 +182,7 @@ static efi_status_t EFIAPI efi_cout_output_string( > } > pos = buf; > utf16_utf8_strcpy(, string); > - fputs(stdout, buf); > + puts(buf); > free(buf); > > /* > -- > 2.43.0.rc1.413.gea7ed67945-goog >
Re: [PATCH 09/21] configs: add dragonboard410c_chainloaded_defconfig
On 21/11/2023 19:08, Tom Rini wrote: > On Tue, Nov 21, 2023 at 05:09:32PM +, Caleb Connolly wrote: > >> Revive support for booting db410c using the Linux kernel header, this >> allows for testing the board more easily via `fastboot`. >> >> Signed-off-by: Caleb Connolly >> --- >> board/qualcomm/dragonboard410c/MAINTAINERS| 1 + >> configs/dragonboard410c_chainloaded_defconfig | 75 >> +++ >> 2 files changed, 76 insertions(+) > > How different is this from the regular defconfig, and assuming this is > also a partial answer to my question about "why not select?", why is > this not just a config fragment instead of a whole new defconfig to keep > in sync? Oh, I was totally unaware of the concept of board config fragments in U-Boot. That's definitely a much cleaner solution. > -- // Caleb (they/them)
Re: [PATCH 02/21] arm: allow CONFIG_LINUX_KERNEL_IMAGE_HEADER to be set in defconfig
On 21/11/2023 19:07, Tom Rini wrote: > On Tue, Nov 21, 2023 at 05:09:25PM +, Caleb Connolly wrote: > >> Let this option be enabled dynamically for boards that support multiple >> mechanisms for booting U-Boot (e.g. as a first-stage or chainloaded >> bootloader). >> >> Signed-off-by: Caleb Connolly >> --- >> This patch has no dependencies >> >> Cc: Simon Glass >> --- >> arch/arm/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index bd48131292e3..1add4282f336 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -81,7 +81,7 @@ config SPL_SYS_NO_VECTOR_TABLE >> >> config LINUX_KERNEL_IMAGE_HEADER >> depends on ARM64 >> -bool >> +bool "Linux kernel binary header" >> help >>Place a Linux kernel image header at the start of the U-Boot binary. >>The format of the header is described in the Linux kernel source at > > Why are we not select'ing this like the other platforms which need the > same do? On some Qualcomm boards we can boot either as a Linux kernel or we can replace the first-stage bootloader. To run as the primary bootloader we unset this option and enable REMAKE_ELF as well as configuring a few other things. Would it make more sense to introduce a Qualcomm specific config option to handle these cases? > -- // Caleb (they/them)
RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages
In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line 268 is for related example code. Thanks, Chasel > -Original Message- > From: Chiu, Chasel > Sent: Tuesday, November 21, 2023 10:34 AM > To: Ard Biesheuvel ; Simon Glass > Cc: devicet...@vger.kernel.org; Mark Rutland ; Rob > Herring ; Tan, Lean Sheng ; lkml > ; Dhaval Sharma ; Brune, > Maximilian ; Yunhui Cui > ; Dong, Guo ; Tom Rini > ; ron minnich ; Guo, Gua > ; linux-a...@vger.kernel.org; U-Boot Mailing List b...@lists.denx.de>; Chiu, Chasel > Subject: RE: [PATCH v7 2/2] schemas: Add some common reserved-memory > usages > > > Hi Ard, > > Here is the POC PR for your reference: > https://github.com/tianocore/edk2/pull/4969/files#diff- > ccebabae5274b21634723a2111ee0de11bed6cfe8cb206ef9e263d9c5f926a9cR26 > 8 > Please note that this PR is still in early phase and expected to have > significant > changes. > > The idea is that payload entry will create gEfiMemoryTypeInformationGuid HOB > with payload default memory types and allow FDT to override if correspond node > present. > Please let me know if you have questions or suggestions. > > Thanks, > Chasel > > > > -Original Message- > > From: Ard Biesheuvel > > Sent: Tuesday, November 21, 2023 8:42 AM > > To: Simon Glass > > Cc: Chiu, Chasel ; devicet...@vger.kernel.org; > > Mark Rutland ; Rob Herring ; > > Tan, Lean Sheng ; lkml > > ; Dhaval Sharma ; > > Brune, Maximilian ; Yunhui Cui > > ; Dong, Guo ; Tom Rini > > ; ron minnich ; Guo, Gua > > ; linux- a...@vger.kernel.org; U-Boot Mailing List > > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory > > usages > > > > On Mon, 20 Nov 2023 at 21:12, Simon Glass wrote: > > > > > > Hi, > > > > > > On Mon, 13 Nov 2023 at 11:09, Chiu, Chasel wrote: > > > > > > > > > > > > Hi Ard, > > > > > > > > Please see my reply below inline. > > > > > > > > Thanks, > > > > Chasel > > > > > > > > > > > > > -Original Message- > > > > > From: Ard Biesheuvel > > > > > Sent: Saturday, November 11, 2023 3:04 AM > > > > > To: Chiu, Chasel > > > > > Cc: Simon Glass ; devicet...@vger.kernel.org; > > > > > Mark Rutland ; Rob Herring > > > > > ; Tan, Lean Sheng ; > > > > > lkml ; Dhaval Sharma > > > > > ; Brune, Maximilian > > > > > ; Yunhui Cui > > > > > ; Dong, Guo ; Tom > > > > > Rini ; ron minnich ; > > > > > Guo, Gua ; linux- a...@vger.kernel.org; > > > > > U-Boot Mailing List > > > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common > > > > > reserved-memory usages > > > > > > > > > > On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel > wrote: > > > > > > > > > > > > > > > > > > Just sharing some usage examples from UEFI/EDK2 scenario. > > > > > > To support ACPI S4/Hibernation, memory map must be consistent > > > > > > before entering and after resuming from S4, in this case > > > > > > payload may need to know previous memory map from bootloader > > > > > > (currently generic payload cannot access platform/bootloader > > > > > > specific non-volatile data, thus could not save/restore memory > > > > > > map > > > > > > information) > > > > > > > > > > So how would EDK2 reconstruct the entire EFI memory map from > > > > > just these unannotated /reserved-memory nodes? The EFI memory > > > > > map contains much more information than that, and all of it has > > > > > to match the pre-hibernate situation, right? Can you given an example? > > > > > > > > > > > > Here we listed only typically memory types that may change cross > > > > different > > platforms. > > > > Reserved memory type already can be handled by reserved-memory > > > > node, > > and rest of the types usually no need to change cross platforms thus > > currently we could rely on default in generic payload. > > > > In the future if we see a need to add new memory types we will > > > > discuss and > > add it to FDT schema. > > > > > > > > > > > > > > > > > > > > > > > Another usage is to support binary model which generic payload > > > > > > is a prebuilt > > > > > binary compatible for all platforms/configurations, however the > > > > > payload default memory map might not always work for all the > > > > > configurations and we want to allow bootloader to override > > > > > payload default > > memory map without recompiling. > > > > > > > > > > > > > > > > Agreed. But can you explain how a EDK2 payload might make > > > > > meaningful use of 'runtime-code' regions provided via DT by the > > > > > non-EDK2 platform init? Can you give an example? > > > > > > > > > > > > Runtime-code/data is used by UEFI payload for booting UEFI OS > > > > which > > required UEFI runtime services. > > > > Platform Init will select some regions from the usable memory and > > > > assign it to > > runtime-code/data for UPL to consume. Or assign same runtime-code/data > > from previous boot. > > > > If UEFI OS is not supported, PlatformInit may not need to provide > > > > runtime-code/data regions to payload. (always providing > > > > runtime-code/data should be
RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages
Hi Ard, Here is the POC PR for your reference: https://github.com/tianocore/edk2/pull/4969/files#diff-ccebabae5274b21634723a2111ee0de11bed6cfe8cb206ef9e263d9c5f926a9cR268 Please note that this PR is still in early phase and expected to have significant changes. The idea is that payload entry will create gEfiMemoryTypeInformationGuid HOB with payload default memory types and allow FDT to override if correspond node present. Please let me know if you have questions or suggestions. Thanks, Chasel > -Original Message- > From: Ard Biesheuvel > Sent: Tuesday, November 21, 2023 8:42 AM > To: Simon Glass > Cc: Chiu, Chasel ; devicet...@vger.kernel.org; Mark > Rutland ; Rob Herring ; Tan, Lean > Sheng ; lkml ; > Dhaval Sharma ; Brune, Maximilian > ; Yunhui Cui ; > Dong, Guo ; Tom Rini ; ron minnich > ; Guo, Gua ; linux- > a...@vger.kernel.org; U-Boot Mailing List > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory > usages > > On Mon, 20 Nov 2023 at 21:12, Simon Glass wrote: > > > > Hi, > > > > On Mon, 13 Nov 2023 at 11:09, Chiu, Chasel wrote: > > > > > > > > > Hi Ard, > > > > > > Please see my reply below inline. > > > > > > Thanks, > > > Chasel > > > > > > > > > > -Original Message- > > > > From: Ard Biesheuvel > > > > Sent: Saturday, November 11, 2023 3:04 AM > > > > To: Chiu, Chasel > > > > Cc: Simon Glass ; devicet...@vger.kernel.org; > > > > Mark Rutland ; Rob Herring > > > > ; Tan, Lean Sheng ; lkml > > > > ; Dhaval Sharma > > > > ; Brune, Maximilian > > > > ; Yunhui Cui > > > > ; Dong, Guo ; Tom > > > > Rini ; ron minnich ; Guo, > > > > Gua ; linux- a...@vger.kernel.org; U-Boot > > > > Mailing List > > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common > > > > reserved-memory usages > > > > > > > > On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel > > > > wrote: > > > > > > > > > > > > > > > Just sharing some usage examples from UEFI/EDK2 scenario. > > > > > To support ACPI S4/Hibernation, memory map must be consistent > > > > > before entering and after resuming from S4, in this case payload > > > > > may need to know previous memory map from bootloader (currently > > > > > generic payload cannot access platform/bootloader specific > > > > > non-volatile data, thus could not save/restore memory map > > > > > information) > > > > > > > > So how would EDK2 reconstruct the entire EFI memory map from just > > > > these unannotated /reserved-memory nodes? The EFI memory map > > > > contains much more information than that, and all of it has to > > > > match the pre-hibernate situation, right? Can you given an example? > > > > > > > > > Here we listed only typically memory types that may change cross different > platforms. > > > Reserved memory type already can be handled by reserved-memory node, > and rest of the types usually no need to change cross platforms thus > currently we > could rely on default in generic payload. > > > In the future if we see a need to add new memory types we will discuss and > add it to FDT schema. > > > > > > > > > > > > > > > > > > Another usage is to support binary model which generic payload > > > > > is a prebuilt > > > > binary compatible for all platforms/configurations, however the > > > > payload default memory map might not always work for all the > > > > configurations and we want to allow bootloader to override payload > > > > default > memory map without recompiling. > > > > > > > > > > > > > Agreed. But can you explain how a EDK2 payload might make > > > > meaningful use of 'runtime-code' regions provided via DT by the > > > > non-EDK2 platform init? Can you give an example? > > > > > > > > > Runtime-code/data is used by UEFI payload for booting UEFI OS which > required UEFI runtime services. > > > Platform Init will select some regions from the usable memory and assign > > > it to > runtime-code/data for UPL to consume. Or assign same runtime-code/data from > previous boot. > > > If UEFI OS is not supported, PlatformInit may not need to provide > > > runtime-code/data regions to payload. (always providing > > > runtime-code/data should be supported too) > > > > > > > > > > > > > > > Under below assumption: > > > > > FDT OS impact has been evaluated and taken care by > > > > > relevant > > > > experts/stakeholders. > > > > > Reviewed-by: Chasel Chiu > > > > > > > > > > > > > I am sorry but I don't know what 'FDT OS impact' means. We are > > > > talking about a firmware-to-firmware abstraction that has the > > > > potential to leak into the OS visible interface. > > > > > > > > I am a maintainer in the Tianocore project myself, so it would > > > > help if you could explain who these relevant experts and > > > > stakeholders are. Was this discussed on the edk2-devel mailing > > > > list? If so, apologies for missing it but I may not have been cc'ed > > > > perhaps? > > > > > > > > > > > > > > > I'm not familiar with FDT OS, also I do not know if who from edk2-devel > > > were > supporting FDT OS, I
[PATCH 19/21] dts: msm8996: import DT from Linux
Drop in msm8996.dtsi, pm8994.dtsi, and associated headers. Adjust
dragonboard820c.dts to work properly, and fix the clock driver.
Signed-off-by: Caleb Connolly
---
arch/arm/dts/dragonboard820c-uboot.dtsi| 32 -
arch/arm/dts/dragonboard820c.dts | 130 +-
arch/arm/dts/msm8996.dtsi | 3959
arch/arm/dts/pm8994.dtsi | 152 +
drivers/clk/qcom/clock-apq8096.c |5 +-
include/dt-bindings/clock/qcom,gcc-msm8996.h | 360 ++
include/dt-bindings/clock/qcom,mmcc-msm8996.h | 295 ++
.../dt-bindings/interconnect/qcom,msm8996-cbf.h| 12 +
include/dt-bindings/interconnect/qcom,msm8996.h| 163 +
9 files changed, 4960 insertions(+), 148 deletions(-)
diff --git a/arch/arm/dts/dragonboard820c-uboot.dtsi
b/arch/arm/dts/dragonboard820c-uboot.dtsi
deleted file mode 100644
index d93c7c1fbdee..
--- a/arch/arm/dts/dragonboard820c-uboot.dtsi
+++ /dev/null
@@ -1,32 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * U-Boot addition to handle Dragonboard 820c pins
- *
- * (C) Copyright 2017 Jorge Ramirez-Ortiz
- */
-
-/ {
- smem {
- bootph-all;
- };
-
- soc {
- bootph-all;
-
- pinctrl@101 {
- bootph-all;
-
- uart {
- bootph-all;
- };
- };
-
- clock-controller@30 {
- bootph-all;
- };
-
- serial@75b {
- bootph-all;
- };
- };
-};
diff --git a/arch/arm/dts/dragonboard820c.dts b/arch/arm/dts/dragonboard820c.dts
index 86b7f83d36d6..067380f2a4fe 100644
--- a/arch/arm/dts/dragonboard820c.dts
+++ b/arch/arm/dts/dragonboard820c.dts
@@ -7,11 +7,12 @@
/dts-v1/;
-#include "skeleton64.dtsi"
+#include "msm8996.dtsi"
+#include "pm8994.dtsi"
/ {
model = "Qualcomm Technologies, Inc. DB820c";
- compatible = "arrow,apq8096-db820c", "qcom,apq8096-sbc";
+ compatible = "qcom,apq8096-db820c", "qcom,apq8096";
#address-cells = <2>;
#size-cells = <2>;
@@ -23,22 +24,11 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@8000 {
device_type = "memory";
reg = <0 0x8000 0 0xc000>;
};
- reserved-memory {
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
-
- smem_mem: smem_region@8630 {
- reg = <0x0 0x8630 0x0 0x20>;
- no-map;
- };
- };
-
psci {
compatible = "arm,psci-1.0";
method = "smc";
@@ -48,105 +38,17 @@
compatible = "qcom,smem";
memory-region = <_mem>;
};
-
- soc: soc {
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0 0 0x>;
- compatible = "simple-bus";
-
- gcc: clock-controller@30 {
- compatible = "qcom,gcc-msm8996";
- #clock-cells = <1>;
- #reset-cells = <1>;
- #power-domain-cells = <1>;
- reg = <0x30 0x9>;
- };
-
- pinctrl: pinctrl@101 {
- compatible = "qcom,msm8996-pinctrl";
- reg = <0x101 0x40>;
-
- blsp8_uart: uart {
- function = "blsp_uart8";
- pins = "GPIO_4", "GPIO_5";
- drive-strength = <8>;
- bias-disable;
- };
- };
-
- blsp2_uart2: serial@75b {
- compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
- reg = <0x75b 0x1000>;
- clocks = < 4>;
- clock-names = "core";
- pinctrl-names = "uart";
- pinctrl-0 = <_uart>;
- };
-
- sdhc2: sdhci@74a4900 {
- compatible = "qcom,sdhci-msm-v4";
- reg = <0x74a4900 0x314>, <0x74a4000 0x800>;
- index = <0x0>;
- bus-width = <4>;
- clock = < 0>;
- clock-frequency = <2>;
-};
-
- spmi_bus: spmi@400f000 {
- compatible = "qcom,spmi-pmic-arb";
- reg = <0x0400f000 0x1000>,
- <0x0440 0x80>,
- <0x04c0 0x80>,
- <0x0580 0x20>,
-
Re: [PATCH v2 1/7] acpi: Kconfig symbol CONFIG_QFW_ACPI
On Tue, Nov 21, 2023 at 08:30:34PM +0100, Heinrich Schuchardt wrote:
> On 11/21/23 20:00, Tom Rini wrote:
> > On Tue, Nov 21, 2023 at 04:27:34PM +0100, Heinrich Schuchardt wrote:
> >
> > > We have two implementations of write_acpi_tables(). One for writing ACPI
> > > tables based on ACPI_WRITER() entries another based on copying tables from
> > > QEMU.
> > >
> > > Create a symbol CONFIG_QFW_ACPI that signifies copying ACPI tables from
> > > QEMU and use it consistently.
> > >
> > > Signed-off-by: Heinrich Schuchardt
> > > ---
> > > v2:
> > > new patch
> > > ---
> > > drivers/misc/Kconfig | 7 +++
> > > drivers/misc/qfw.c | 4 ++--
> > > lib/acpi/Makefile | 2 +-
> > > lib/acpi/acpi_writer.c | 4 ++--
> > > 4 files changed, 12 insertions(+), 5 deletions(-)
> >
> > I still feel like this is a weird direction to go in and that:
> > > diff --git a/lib/acpi/acpi_writer.c b/lib/acpi/acpi_writer.c
> > > index 946f90e8e7..9b9fdc190b 100644
> > > --- a/lib/acpi/acpi_writer.c
> > > +++ b/lib/acpi/acpi_writer.c
> > > @@ -48,7 +48,7 @@ int acpi_write_one(struct acpi_ctx *ctx, const struct
> > > acpi_writer *entry)
> > > return 0;
> > > }
> > > -#ifndef CONFIG_QEMU
> > > +#ifndef CONFIG_QFW_ACPI
> > > static int acpi_write_all(struct acpi_ctx *ctx)
> > > {
> > > const struct acpi_writer *writer =
> > > @@ -115,7 +115,7 @@ ulong acpi_get_rsdp_addr(void)
> > > return map_to_sysmem(gd->acpi_ctx->rsdp);
> > > }
> > > -#endif /* QEMU */
> > > +#endif /* QFW_ACPI */
> > > void acpi_setup_ctx(struct acpi_ctx *ctx, ulong start)
> > > {
> >
> > Will need to be tweaked later on still with some other symbol to denote
> > "ACPI tables were passed along on real hardware by $mechanism". But we
> > can cross that when we come to it.
> >
>
> QFW is only about QEMU. What I did here is separating the transfer of ACPI
> tables from QEMU from the code co-used by the sandbox. Do you think this is
> wrong?
This part is right, yes. But I quoted the generic code here and not the
QEMU part of the code.
> Probably when booting U-Boot via Coreboot we should be able to copy ACPI
> tables. But this will not involve QFW. Is there any code, yet, where U-Boot
> is picking up ACPI tables from Coreboot?
Is there, or should there, or could there be? I don't know the answer
there, and is what I'm driving at. And that is..
> In this case you would not set symbol CONFIG_GENERATE_ACPI_TABLES. Do we
> really need yet another symbol?
Yes, I think a number of our symbols are oddly named, and confusing and
we probably do need a new symbol or two. We have platforms which use
CONFIG_GENERATE_ACPI_TABLES to mean "allocate and populate ACPI
structures" and other platforms to mean "copy ACPI tables someone
generated for us and pass them along to the OS".
--
Tom
signature.asc
Description: PGP signature
Re: Licensing discrepancies or ambiguities
On Tue, Nov 21, 2023 at 11:10:57AM -0800, Vagrant Cascadian wrote: > I've been reviewing the copyright and license information for Das U-Boot > in preparation for uploading to Debian, and found a few surprises. > > tools/libfdt/fdt_rw.c: /* SPDX-License-Identifier: GPL-2.0+ BSD-2-Clause */ This comes from the kernel and has been clarified there: // SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) > I *think* according to the SPDX spec this needs an OR or an AND. I also > see no copyright declaration, although maybe there is a standard > interpretation for this. > > Similar issue with (though thankfully they include copyright > declarations): > > include/bloblist.h:/* SPDX-License-Identifier: GPL-2.0+ BSD-3-Clause */ > common/bloblist.c:// SPDX-License-Identifier: GPL-2.0+ BSD-3-Clause Simon? > doc/README.ubispl:# SPDX-License-Identifier: GPL 2.0+ BSD-3-Clause Should be an OR as well, yes, but it's also out of date and we could just delete if a problem. > This one has a non-existent license: > > test/lib/strlcat.c: // SPDX-License-Identifier: GPL-2.1+ > > No such license exists, though thankfully it references the exact file > in the original glibc sources it came from, which is listed as > LGPL-2.1+. Since you did the research would you mind sending the patch? Thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH 21/21] MAINTAINERS: Qualcomm: add some missing paths
On Tue, Nov 21, 2023 at 05:09:44PM +, Caleb Connolly wrote: > Add board/qualcomm and the SoC/PMIC DTSI files. > Adjust the driver paths to use globs rather than hardcoding every > specific driver. > > Signed-off-by: Caleb Connolly [snip] > +F: arch/arm/dts/msm8*.dtsi > +F: arch/arm/dts/pm8???.dtsi > +F: arch/arm/dts/pms405.dtsi > +F: arch/arm/dts/sdm845.dtsi > F: arch/arm/mach-snapdragon/ > +F: board/qualcomm Maybe: N: qualcomm N: qcom > F: configs/qcom_defconfig > F: doc/board/qualcomm > -F: drivers/button/button-qcom-pmic.c > -F: drivers/clk/qcom/ > +F: drivers/*/*/pm8???-* > +F: drivers/*/*/qcom* > +F: drivers/*/*/qcom/ > +F: drivers/*/*qcom* > +F: drivers/*/qcom/ > F: drivers/gpio/msm_gpio.c > F: drivers/mmc/msm_sdhci.c > F: drivers/phy/msm8916-usbh-phy.c > -F: drivers/pinctrl/qcom/ > F: drivers/serial/serial_msm.c > F: drivers/serial/serial_msm_geni.c > F: drivers/smem/msm_smem.c What about drivers/usb/host/ehci-msm.c drivers/rng/msm_rng.c and drivers/phy/qcom/msm8916-usbh-phy.c ? -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/7] acpi: Kconfig symbol CONFIG_QFW_ACPI
On 11/21/23 20:00, Tom Rini wrote:
On Tue, Nov 21, 2023 at 04:27:34PM +0100, Heinrich Schuchardt wrote:
We have two implementations of write_acpi_tables(). One for writing ACPI
tables based on ACPI_WRITER() entries another based on copying tables from
QEMU.
Create a symbol CONFIG_QFW_ACPI that signifies copying ACPI tables from
QEMU and use it consistently.
Signed-off-by: Heinrich Schuchardt
---
v2:
new patch
---
drivers/misc/Kconfig | 7 +++
drivers/misc/qfw.c | 4 ++--
lib/acpi/Makefile | 2 +-
lib/acpi/acpi_writer.c | 4 ++--
4 files changed, 12 insertions(+), 5 deletions(-)
I still feel like this is a weird direction to go in and that:
diff --git a/lib/acpi/acpi_writer.c b/lib/acpi/acpi_writer.c
index 946f90e8e7..9b9fdc190b 100644
--- a/lib/acpi/acpi_writer.c
+++ b/lib/acpi/acpi_writer.c
@@ -48,7 +48,7 @@ int acpi_write_one(struct acpi_ctx *ctx, const struct
acpi_writer *entry)
return 0;
}
-#ifndef CONFIG_QEMU
+#ifndef CONFIG_QFW_ACPI
static int acpi_write_all(struct acpi_ctx *ctx)
{
const struct acpi_writer *writer =
@@ -115,7 +115,7 @@ ulong acpi_get_rsdp_addr(void)
return map_to_sysmem(gd->acpi_ctx->rsdp);
}
-#endif /* QEMU */
+#endif /* QFW_ACPI */
void acpi_setup_ctx(struct acpi_ctx *ctx, ulong start)
{
Will need to be tweaked later on still with some other symbol to denote
"ACPI tables were passed along on real hardware by $mechanism". But we
can cross that when we come to it.
QFW is only about QEMU. What I did here is separating the transfer of
ACPI tables from QEMU from the code co-used by the sandbox. Do you think
this is wrong?
Probably when booting U-Boot via Coreboot we should be able to copy ACPI
tables. But this will not involve QFW. Is there any code, yet, where
U-Boot is picking up ACPI tables from Coreboot?
In this case you would not set symbol CONFIG_GENERATE_ACPI_TABLES. Do we
really need yet another symbol?
Best regards
Heinrich
Re: [PATCH 14/21] mach-snapdragon: dynamic load addresses
On Tue, Nov 21, 2023 at 05:09:37PM +, Caleb Connolly wrote:
> Heavily inspired by Apple board code. Use the LMB allocator to configure
> load addresses at runtime, and implement a lookup table for selecting a
> devicetree.
>
> As some Qualcomm RBx boards have different RAM capacities and base
> addresses, it isn't possible to hardcode these regions.
>
> Signed-off-by: Caleb Connolly
[snip]
> +#define KERNEL_COMP_SIZE SZ_32M
> +#define SZ_96M (SZ_64M + SZ_32M)
> +
> +#define addr_alloc(lmb, size) lmb_alloc(lmb, size, SZ_2M)
> +
> +/* Stolen from arch/arm/mach-apple/board.c */
> +int board_late_init(void)
> +{
> + struct lmb lmb;
> + u32 status = 0;
> +
> + lmb_init_and_reserve(, gd->bd, (void *)gd->fdt_blob);
> +
> + /* We need to be fairly conservative here as we support boards with
> just 1G of TOTAL RAM */
> + status |= env_set_hex("kernel_addr_r", addr_alloc(, SZ_96M));
> + status |= env_set_hex("loadaddr", addr_alloc(, SZ_64M));
> + status |= env_set_hex("fdt_addr_r", addr_alloc(, SZ_2M));
> + status |= env_set_hex("ramdisk_addr_r", addr_alloc(, SZ_96M));
> + status |= env_set_hex("kernel_comp_addr_r", addr_alloc(,
> KERNEL_COMP_SIZE));
> + status |= env_set_hex("kernel_comp_size", KERNEL_COMP_SIZE);
> + status |= env_set_hex("scriptaddr", addr_alloc(, SZ_4M));
> + status |= env_set_hex("pxefile_addr_r", addr_alloc(, SZ_4M));
First, with 1G total, we should I think be fine using SZ_128M and not
needing to add SZ_96M. Second, having worked on
https://patchwork.ozlabs.org/project/uboot/patch/20231119144338.630138-2-...@chromium.org/
a bit I think your sizes are a bit funny. We're looking at where to
decompress the provided Image file to and so 32M is too small. My
generic v6.6 Image is 40MB. One of those "would be nice" things to see
now that I've kicked things around a little was if all of our boot$foo
decompression logic just asked the lmb to give us a new region of
max-feasible-size for a Linux kernel (or we make it a choice between 64
or 128MB max supported kernel image). And further looking at the code
and matching it up with the function docs, it's even funkier than I had
thought, sigh.
And to try and be clear, the second is an ask, but the first is a change
request, those sizes are too small and inconsistent with supporting a
large uncompressed kernel.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 18/21] dts: msm8916: import DT from Linux
On Tue, Nov 21, 2023 at 05:09:41PM +, Caleb Connolly wrote:
> Import the msm8916 devicetree from Linux and adjust the dragonboard410c
> devicetree to use it.
>
Can you add a note here from which Linux version you took the DT?
It seems quite old, the msm8916-pm8916.dtsi doesn't exist anymore
upstream since v6.5. Would be nice to bring it up to date (I don't have
any more cleanup planned at the moment, so the current state upstream
will probably stay mostly as-is).
>From a quick look I think U-Boot shouldn't be concerned much about the
changes, you might just need to do some trivial renames:
->
_uart2 -> _uart2
Thanks a lot for working on this!
Stephan
> Signed-off-by: Caleb Connolly
> ---
> arch/arm/dts/dragonboard410c-uboot.dtsi | 44 -
> arch/arm/dts/dragonboard410c.dts| 198 +-
> arch/arm/dts/msm8916-pins.dtsi | 582 ++
> arch/arm/dts/msm8916-pm8916.dtsi| 76 +
> arch/arm/dts/msm8916.dtsi | 2194
> +++
> arch/arm/dts/pm8916.dtsi| 183 ++
> include/dt-bindings/arm/coresight-cti-dt.h | 37 +
> include/dt-bindings/clock/qcom,rpmcc.h | 174 ++
> include/dt-bindings/interconnect/qcom,msm8916.h | 100 ++
> include/dt-bindings/reset/qcom,gcc-msm8916.h| 100 ++
> 10 files changed, 3484 insertions(+), 204 deletions(-)
>
> diff --git a/arch/arm/dts/dragonboard410c-uboot.dtsi
> b/arch/arm/dts/dragonboard410c-uboot.dtsi
> deleted file mode 100644
> index cec64bf80f99..
> --- a/arch/arm/dts/dragonboard410c-uboot.dtsi
> +++ /dev/null
> @@ -1,44 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * U-Boot addition to handle Dragonboard 410c pins
> - *
> - * (C) Copyright 2015 Mateusz Kulikowski
> - */
> -
> -/ {
> -
> - smem {
> - bootph-all;
> - };
> -
> - soc {
> - bootph-all;
> -
> - pinctrl@100 {
> - bootph-all;
> -
> - uart {
> - bootph-all;
> - };
> - };
> -
> - qcom,gcc@180 {
> - bootph-all;
> - };
> -
> - serial@78b {
> - bootph-all;
> - };
> - };
> -};
> -
> -
> -_gpios {
> - usb_hub_reset_pm {
> - gpios = <_gpios 2 0>;
> - };
> -
> - usb_sw_sel_pm {
> - gpios = <_gpios 3 0>;
> - };
> -};
> diff --git a/arch/arm/dts/dragonboard410c.dts
> b/arch/arm/dts/dragonboard410c.dts
> index a42b68fee8c0..8933c64e56e5 100644
> --- a/arch/arm/dts/dragonboard410c.dts
> +++ b/arch/arm/dts/dragonboard410c.dts
> @@ -7,193 +7,40 @@
>
> /dts-v1/;
>
> -#include "skeleton64.dtsi"
> #include
>
> +#include "msm8916-pm8916.dtsi"
> +
> / {
> model = "Qualcomm Technologies, Inc. Dragonboard 410c";
> compatible = "qcom,apq8016-sbc", "qcom,apq8016";
> qcom,msm-id = <0xce 0x0 0xf8 0x0 0xf9 0x0 0xfa 0x0 0xf7 0x0>;
> qcom,board-id = <0x10018 0x0>;
> - #address-cells = <0x2>;
> - #size-cells = <0x2>;
>
> aliases {
> usb0 = "/soc/ehci@78d9000";
> + serial0 = _uart2;
> };
>
> - memory {
> + memory@8000 {
> device_type = "memory";
> reg = <0 0x8000 0 0x3da0>;
> };
>
> - reserved-memory {
> - #address-cells = <2>;
> - #size-cells = <2>;
> - ranges;
> -
> - smem_mem: smem_region@8630 {
> - reg = <0x0 0x8630 0x0 0x10>;
> - no-map;
> - };
> - };
> -
> chosen {
> stdout-path = "/soc/serial@78b";
> };
>
> - smem {
> - compatible = "qcom,smem";
> - memory-region = <_mem>;
> - qcom,rpm-msg-ram = <_msg_ram>;
> - };
> -
> - soc {
> - #address-cells = <0x1>;
> - #size-cells = <0x1>;
> - ranges = <0x0 0x0 0x0 0x>;
> - compatible = "simple-bus";
> -
> - rpm_msg_ram: memory@6 {
> - compatible = "qcom,rpm-msg-ram";
> - reg = <0x6 0x8000>;
> - };
> -
> - soc_gpios: pinctrl@100 {
> - compatible = "qcom,msm8916-pinctrl";
> - reg = <0x100 0x40>;
> - gpio-controller;
> - gpio-count = <122>;
> - gpio-bank-name="soc";
> - #gpio-cells = <2>;
> -
> - blsp1_uart: uart {
> - function = "blsp1_uart";
> - pins = "GPIO_4", "GPIO_5";
> - drive-strength = <8>;
> - bias-disable;
> - };
> - };
> - clkc: qcom,gcc@180
Licensing discrepancies or ambiguities
I've been reviewing the copyright and license information for Das U-Boot in preparation for uploading to Debian, and found a few surprises. tools/libfdt/fdt_rw.c: /* SPDX-License-Identifier: GPL-2.0+ BSD-2-Clause */ I *think* according to the SPDX spec this needs an OR or an AND. I also see no copyright declaration, although maybe there is a standard interpretation for this. Similar issue with (though thankfully they include copyright declarations): include/bloblist.h:/* SPDX-License-Identifier: GPL-2.0+ BSD-3-Clause */ common/bloblist.c:// SPDX-License-Identifier: GPL-2.0+ BSD-3-Clause doc/README.ubispl:# SPDX-License-Identifier: GPL 2.0+ BSD-3-Clause This one has a non-existent license: test/lib/strlcat.c: // SPDX-License-Identifier: GPL-2.1+ No such license exists, though thankfully it references the exact file in the original glibc sources it came from, which is listed as LGPL-2.1+. There are certainly more ambiguous issues, but figured I would start with those! live well, vagrant signature.asc Description: PGP signature
Re: [PATCH 09/21] configs: add dragonboard410c_chainloaded_defconfig
On Tue, Nov 21, 2023 at 05:09:32PM +, Caleb Connolly wrote: > Revive support for booting db410c using the Linux kernel header, this > allows for testing the board more easily via `fastboot`. > > Signed-off-by: Caleb Connolly > --- > board/qualcomm/dragonboard410c/MAINTAINERS| 1 + > configs/dragonboard410c_chainloaded_defconfig | 75 > +++ > 2 files changed, 76 insertions(+) How different is this from the regular defconfig, and assuming this is also a partial answer to my question about "why not select?", why is this not just a config fragment instead of a whole new defconfig to keep in sync? -- Tom signature.asc Description: PGP signature
Re: [PATCH 02/21] arm: allow CONFIG_LINUX_KERNEL_IMAGE_HEADER to be set in defconfig
On Tue, Nov 21, 2023 at 05:09:25PM +, Caleb Connolly wrote: > Let this option be enabled dynamically for boards that support multiple > mechanisms for booting U-Boot (e.g. as a first-stage or chainloaded > bootloader). > > Signed-off-by: Caleb Connolly > --- > This patch has no dependencies > > Cc: Simon Glass > --- > arch/arm/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index bd48131292e3..1add4282f336 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -81,7 +81,7 @@ config SPL_SYS_NO_VECTOR_TABLE > > config LINUX_KERNEL_IMAGE_HEADER > depends on ARM64 > - bool > + bool "Linux kernel binary header" > help > Place a Linux kernel image header at the start of the U-Boot binary. > The format of the header is described in the Linux kernel source at Why are we not select'ing this like the other platforms which need the same do? -- Tom signature.asc Description: PGP signature
Re: [PATCH 01/21] arm: init: export prev_bl_fdt_addr
On Tue, Nov 21, 2023 at 05:09:24PM +, Caleb Connolly wrote: > When booting U-Boot on board with a locked down first-stage bootloader, > we emulate the Linux boot header. By passing the U-Boot FDT through this > first-stage bootloader and retrieving it afterwards we can pre-populate > the memory nodes and other info like the KASLR address. > > Add a function to export the FDT addr so that boards can use it over the > built-in FDT. > > Don't check is_addr_accessible() here because we might not yet have a > valid mem_map if it's going to be populated from the FDT, let the board > do their own validation instead. > > Signed-off-by: Caleb Connolly Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 2/7] acpi: carve out qfw_acpi.c
On Tue, Nov 21, 2023 at 04:27:35PM +0100, Heinrich Schuchardt wrote: > Move the code related to copying tables from QEMU to a separate code > module. > > Signed-off-by: Heinrich Schuchardt Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/7] acpi: Kconfig symbol CONFIG_QFW_ACPI
On Tue, Nov 21, 2023 at 04:27:34PM +0100, Heinrich Schuchardt wrote:
> We have two implementations of write_acpi_tables(). One for writing ACPI
> tables based on ACPI_WRITER() entries another based on copying tables from
> QEMU.
>
> Create a symbol CONFIG_QFW_ACPI that signifies copying ACPI tables from
> QEMU and use it consistently.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> v2:
> new patch
> ---
> drivers/misc/Kconfig | 7 +++
> drivers/misc/qfw.c | 4 ++--
> lib/acpi/Makefile | 2 +-
> lib/acpi/acpi_writer.c | 4 ++--
> 4 files changed, 12 insertions(+), 5 deletions(-)
I still feel like this is a weird direction to go in and that:
> diff --git a/lib/acpi/acpi_writer.c b/lib/acpi/acpi_writer.c
> index 946f90e8e7..9b9fdc190b 100644
> --- a/lib/acpi/acpi_writer.c
> +++ b/lib/acpi/acpi_writer.c
> @@ -48,7 +48,7 @@ int acpi_write_one(struct acpi_ctx *ctx, const struct
> acpi_writer *entry)
> return 0;
> }
>
> -#ifndef CONFIG_QEMU
> +#ifndef CONFIG_QFW_ACPI
> static int acpi_write_all(struct acpi_ctx *ctx)
> {
> const struct acpi_writer *writer =
> @@ -115,7 +115,7 @@ ulong acpi_get_rsdp_addr(void)
>
> return map_to_sysmem(gd->acpi_ctx->rsdp);
> }
> -#endif /* QEMU */
> +#endif /* QFW_ACPI */
>
> void acpi_setup_ctx(struct acpi_ctx *ctx, ulong start)
> {
Will need to be tweaked later on still with some other symbol to denote
"ACPI tables were passed along on real hardware by $mechanism". But we
can cross that when we come to it.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v3 4/5] lib: membuff: fix readline not returning line in case of overflow
Hi Svyatoslav,
On Tue, 21 Nov 2023 at 11:35, Svyatoslav Ryhel wrote:
>
> From: Ion Agorria
>
> If line overflows readline it will not be returned, fix this behavior,
> make it optional and documented properly.
>
> Signed-off-by: Ion Agorria
> Signed-off-by: Svyatoslav Ryhel
> Reviewed-by: Mattijs Korpershoek
> ---
> boot/bootmeth_extlinux.c | 2 +-
> common/console.c | 2 +-
> include/membuff.h| 5 +++--
> lib/membuff.c| 4 ++--
> 4 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/boot/bootmeth_extlinux.c b/boot/bootmeth_extlinux.c
> index aa2a4591eb..ae0ad1d53e 100644
> --- a/boot/bootmeth_extlinux.c
> +++ b/boot/bootmeth_extlinux.c
> @@ -82,7 +82,7 @@ static int extlinux_fill_info(struct bootflow *bflow)
> log_debug("parsing bflow file size %x\n", bflow->size);
> membuff_init(, bflow->buf, bflow->size);
> membuff_putraw(, bflow->size, true, );
> - while (len = membuff_readline(, line, sizeof(line) - 1, ' '), len)
> {
> + while (len = membuff_readline(, line, sizeof(line) - 1, ' ',
> true), len) {
> char *tok, *p = line;
>
> tok = strsep(, " ");
> diff --git a/common/console.c b/common/console.c
> index 8a869b137e..cd56035171 100644
> --- a/common/console.c
> +++ b/common/console.c
> @@ -846,7 +846,7 @@ bool console_record_overflow(void)
> int console_record_readline(char *str, int maxlen)
> {
> return membuff_readline((struct membuff *)>console_out, str,
> - maxlen, '\0');
> + maxlen, '\0', false);
> }
>
> int console_record_avail(void)
> diff --git a/include/membuff.h b/include/membuff.h
> index 21051b0c54..4eba626ce1 100644
> --- a/include/membuff.h
> +++ b/include/membuff.h
> @@ -192,10 +192,11 @@ int membuff_free(struct membuff *mb);
> * @mb: membuff to adjust
> * @str: Place to put the line
> * @maxlen: Maximum line length (excluding terminator)
> + * @must_fit: If true then str is empty if line doesn't fit
> * Return: number of bytes read (including terminator) if a line has been
> - *read, 0 if nothing was there
> + *read, 0 if nothing was there or line didn't fit when must_fit is
> set
> */
> -int membuff_readline(struct membuff *mb, char *str, int maxlen, int minch);
> +int membuff_readline(struct membuff *mb, char *str, int maxlen, int minch,
> bool must_fit);
>
> /**
> * membuff_extend_by() - expand a membuff
> diff --git a/lib/membuff.c b/lib/membuff.c
> index 36dc43a523..964e504d5b 100644
> --- a/lib/membuff.c
> +++ b/lib/membuff.c
> @@ -288,7 +288,7 @@ int membuff_free(struct membuff *mb)
> (mb->end - mb->start) - 1 - membuff_avail(mb);
> }
>
> -int membuff_readline(struct membuff *mb, char *str, int maxlen, int minch)
> +int membuff_readline(struct membuff *mb, char *str, int maxlen, int minch,
> bool must_fit)
Shouldn't that be the normal case? I might have this wrong, but this
looks like a bug fix to me.
> {
> int len; /* number of bytes read (!= string length) */
> char *s, *end;
> @@ -310,7 +310,7 @@ int membuff_readline(struct membuff *mb, char *str, int
> maxlen, int minch)
> }
>
> /* couldn't get the whole string */
> - if (!ok) {
> + if (!ok && must_fit) {
> if (maxlen)
> *orig = '\0';
> return 0;
> --
> 2.40.1
>
[PATCH v3 5/5] fastboot: add oem console command support
From: Ion Agorria
"oem console" serves to read console record buffer.
Signed-off-by: Ion Agorria
Signed-off-by: Svyatoslav Ryhel
Reviewed-by: Mattijs Korpershoek
---
doc/android/fastboot.rst | 1 +
drivers/fastboot/Kconfig | 7 +++
drivers/fastboot/fb_command.c | 39 +++
include/fastboot.h| 1 +
4 files changed, 48 insertions(+)
diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst
index 1ad8a897c8..05d8f77759 100644
--- a/doc/android/fastboot.rst
+++ b/doc/android/fastboot.rst
@@ -29,6 +29,7 @@ The following OEM commands are supported (if enabled):
with = boot_ack boot_partition
- ``oem bootbus`` - this executes ``mmc bootbus %x %s`` to configure eMMC
- ``oem run`` - this executes an arbitrary U-Boot command
+- ``oem console`` - this dumps U-Boot console record buffer
Support for both eMMC and NAND devices is included.
diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
index 837c6f1180..58b08120a4 100644
--- a/drivers/fastboot/Kconfig
+++ b/drivers/fastboot/Kconfig
@@ -241,6 +241,13 @@ config FASTBOOT_OEM_RUN
this feature if you are using verified boot, as it will allow an
attacker to bypass any restrictions you have in place.
+config FASTBOOT_CMD_OEM_CONSOLE
+ bool "Enable the 'oem console' command"
+ depends on CONSOLE_RECORD
+ help
+ Add support for the "oem console" command to input and read console
+ record buffer.
+
endif # FASTBOOT
endmenu
diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
index 6f621df074..f95f4e4ae1 100644
--- a/drivers/fastboot/fb_command.c
+++ b/drivers/fastboot/fb_command.c
@@ -41,6 +41,7 @@ static void reboot_recovery(char *, char *);
static void oem_format(char *, char *);
static void oem_partconf(char *, char *);
static void oem_bootbus(char *, char *);
+static void oem_console(char *, char *);
static void run_ucmd(char *, char *);
static void run_acmd(char *, char *);
@@ -108,6 +109,10 @@ static const struct {
.command = "oem run",
.dispatch = CONFIG_IS_ENABLED(FASTBOOT_OEM_RUN, (run_ucmd),
(NULL))
},
+ [FASTBOOT_COMMAND_OEM_CONSOLE] = {
+ .command = "oem console",
+ .dispatch = CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_CONSOLE,
(oem_console), (NULL))
+ },
[FASTBOOT_COMMAND_UCMD] = {
.command = "UCmd",
.dispatch = CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT, (run_ucmd),
(NULL))
@@ -159,6 +164,23 @@ void fastboot_multiresponse(int cmd, char *response)
case FASTBOOT_COMMAND_GETVAR:
fastboot_getvar_all(response);
break;
+ case FASTBOOT_COMMAND_OEM_CONSOLE:
+ if (CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_CONSOLE)) {
+ char buf[FASTBOOT_RESPONSE_LEN] = { 0 };
+
+ if (console_record_isempty()) {
+ console_record_reset();
+ fastboot_okay(NULL, response);
+ } else {
+ int ret = console_record_readline(buf,
sizeof(buf) - 5);
+
+ if (ret < 0)
+ fastboot_fail("Error reading console",
response);
+ else
+ fastboot_response("INFO", response,
"%s", buf);
+ }
+ break;
+ }
default:
fastboot_fail("Unknown multiresponse command", response);
break;
@@ -503,3 +525,20 @@ static void __maybe_unused oem_bootbus(char
*cmd_parameter, char *response)
else
fastboot_okay(NULL, response);
}
+
+/**
+ * oem_console() - Execute the OEM console command
+ *
+ * @cmd_parameter: Pointer to command parameter
+ * @response: Pointer to fastboot response buffer
+ */
+static void __maybe_unused oem_console(char *cmd_parameter, char *response)
+{
+ if (cmd_parameter)
+ console_in_puts(cmd_parameter);
+
+ if (console_record_isempty())
+ fastboot_fail("Empty console", response);
+ else
+ fastboot_response(FASTBOOT_MULTIRESPONSE_START, response, NULL);
+}
diff --git a/include/fastboot.h b/include/fastboot.h
index 59cbea61ec..1e7920eb91 100644
--- a/include/fastboot.h
+++ b/include/fastboot.h
@@ -47,6 +47,7 @@ enum {
FASTBOOT_COMMAND_OEM_PARTCONF,
FASTBOOT_COMMAND_OEM_BOOTBUS,
FASTBOOT_COMMAND_OEM_RUN,
+ FASTBOOT_COMMAND_OEM_CONSOLE,
FASTBOOT_COMMAND_ACMD,
FASTBOOT_COMMAND_UCMD,
FASTBOOT_COMMAND_COUNT
--
2.40.1
[PATCH v3 3/5] common: console: introduce overflow and isempty calls
From: Ion Agorria
Separate record overflow logic and add console_record_isempty
as available calls don't serve to know output has been read
fully with readline's.
Signed-off-by: Ion Agorria
Signed-off-by: Svyatoslav Ryhel
Reviewed-by: Mattijs Korpershoek
---
common/console.c | 15 ---
include/console.h | 26 ++
test/ut.c | 9 -
3 files changed, 42 insertions(+), 8 deletions(-)
diff --git a/common/console.c b/common/console.c
index 98c3ee6ca6..8a869b137e 100644
--- a/common/console.c
+++ b/common/console.c
@@ -818,6 +818,8 @@ int console_record_init(void)
ret = membuff_new((struct membuff *)>console_in,
CONFIG_CONSOLE_RECORD_IN_SIZE);
+ gd->flags |= GD_FLG_RECORD;
+
return ret;
}
@@ -836,11 +838,13 @@ int console_record_reset_enable(void)
return 0;
}
-int console_record_readline(char *str, int maxlen)
+bool console_record_overflow(void)
{
- if (gd->flags & GD_FLG_RECORD_OVF)
- return -ENOSPC;
+ return gd->flags & GD_FLG_RECORD_OVF ? true : false;
+}
+int console_record_readline(char *str, int maxlen)
+{
return membuff_readline((struct membuff *)>console_out, str,
maxlen, '\0');
}
@@ -850,6 +854,11 @@ int console_record_avail(void)
return membuff_avail((struct membuff *)>console_out);
}
+bool console_record_isempty(void)
+{
+ return membuff_isempty((struct membuff *)>console_out);
+}
+
int console_in_puts(const char *str)
{
return membuff_put((struct membuff *)>console_in, str, strlen(str));
diff --git a/include/console.h b/include/console.h
index ceb733b5cb..d949d29c13 100644
--- a/include/console.h
+++ b/include/console.h
@@ -64,6 +64,13 @@ void console_record_reset(void);
*/
int console_record_reset_enable(void);
+/**
+ * console_record_overflow() - returns state of buffers overflow
+ *
+ * Return: true if the console buffer was overflowed
+ */
+bool console_record_overflow(void);
+
/**
* console_record_readline() - Read a line from the console output
*
@@ -84,6 +91,13 @@ int console_record_readline(char *str, int maxlen);
*/
int console_record_avail(void);
+/**
+ * console_record_isempty() - Returns if console output is empty
+ *
+ * Return: true if empty
+ */
+bool console_record_isempty(void);
+
/**
* console_in_puts() - Write a string to the console input buffer
*
@@ -113,6 +127,12 @@ static inline int console_record_reset_enable(void)
return -ENOSYS;
}
+static inline bool console_record_overflow(void)
+{
+ /* No overflow */
+ return false;
+}
+
static inline int console_record_readline(char *str, int maxlen)
{
/* Nothing to read */
@@ -131,6 +151,12 @@ static inline int console_in_puts(const char *str)
return 0;
}
+static inline bool console_record_isempty(void)
+{
+ /* Always empty */
+ return true;
+}
+
#endif /* !CONFIG_CONSOLE_RECORD */
/**
diff --git a/test/ut.c b/test/ut.c
index 28da417686..d202644a15 100644
--- a/test/ut.c
+++ b/test/ut.c
@@ -53,15 +53,14 @@ long ut_check_delta(ulong last)
static int readline_check(struct unit_test_state *uts)
{
- int ret;
-
- ret = console_record_readline(uts->actual_str, sizeof(uts->actual_str));
- if (ret == -ENOSPC) {
+ if (console_record_overflow()) {
ut_fail(uts, __FILE__, __LINE__, __func__,
"Console record buffer too small - increase
CONFIG_CONSOLE_RECORD_OUT_SIZE");
- return ret;
+ return -ENOSPC;
}
+ console_record_readline(uts->actual_str, sizeof(uts->actual_str));
+
return 0;
}
--
2.40.1
[PATCH v3 4/5] lib: membuff: fix readline not returning line in case of overflow
From: Ion Agorria
If line overflows readline it will not be returned, fix this behavior,
make it optional and documented properly.
Signed-off-by: Ion Agorria
Signed-off-by: Svyatoslav Ryhel
Reviewed-by: Mattijs Korpershoek
---
boot/bootmeth_extlinux.c | 2 +-
common/console.c | 2 +-
include/membuff.h| 5 +++--
lib/membuff.c| 4 ++--
4 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/boot/bootmeth_extlinux.c b/boot/bootmeth_extlinux.c
index aa2a4591eb..ae0ad1d53e 100644
--- a/boot/bootmeth_extlinux.c
+++ b/boot/bootmeth_extlinux.c
@@ -82,7 +82,7 @@ static int extlinux_fill_info(struct bootflow *bflow)
log_debug("parsing bflow file size %x\n", bflow->size);
membuff_init(, bflow->buf, bflow->size);
membuff_putraw(, bflow->size, true, );
- while (len = membuff_readline(, line, sizeof(line) - 1, ' '), len) {
+ while (len = membuff_readline(, line, sizeof(line) - 1, ' ', true),
len) {
char *tok, *p = line;
tok = strsep(, " ");
diff --git a/common/console.c b/common/console.c
index 8a869b137e..cd56035171 100644
--- a/common/console.c
+++ b/common/console.c
@@ -846,7 +846,7 @@ bool console_record_overflow(void)
int console_record_readline(char *str, int maxlen)
{
return membuff_readline((struct membuff *)>console_out, str,
- maxlen, '\0');
+ maxlen, '\0', false);
}
int console_record_avail(void)
diff --git a/include/membuff.h b/include/membuff.h
index 21051b0c54..4eba626ce1 100644
--- a/include/membuff.h
+++ b/include/membuff.h
@@ -192,10 +192,11 @@ int membuff_free(struct membuff *mb);
* @mb: membuff to adjust
* @str: Place to put the line
* @maxlen: Maximum line length (excluding terminator)
+ * @must_fit: If true then str is empty if line doesn't fit
* Return: number of bytes read (including terminator) if a line has been
- *read, 0 if nothing was there
+ *read, 0 if nothing was there or line didn't fit when must_fit is set
*/
-int membuff_readline(struct membuff *mb, char *str, int maxlen, int minch);
+int membuff_readline(struct membuff *mb, char *str, int maxlen, int minch,
bool must_fit);
/**
* membuff_extend_by() - expand a membuff
diff --git a/lib/membuff.c b/lib/membuff.c
index 36dc43a523..964e504d5b 100644
--- a/lib/membuff.c
+++ b/lib/membuff.c
@@ -288,7 +288,7 @@ int membuff_free(struct membuff *mb)
(mb->end - mb->start) - 1 - membuff_avail(mb);
}
-int membuff_readline(struct membuff *mb, char *str, int maxlen, int minch)
+int membuff_readline(struct membuff *mb, char *str, int maxlen, int minch,
bool must_fit)
{
int len; /* number of bytes read (!= string length) */
char *s, *end;
@@ -310,7 +310,7 @@ int membuff_readline(struct membuff *mb, char *str, int
maxlen, int minch)
}
/* couldn't get the whole string */
- if (!ok) {
+ if (!ok && must_fit) {
if (maxlen)
*orig = '\0';
return 0;
--
2.40.1
[PATCH v3 2/5] fastboot: implement "getvar all"
From: Ion Agorria
This commit implements "fastboot getvar all" listing
by iterating the existing dispatchers that don't require
parameters (as we pass NULL), uses fastboot multiresponse.
Signed-off-by: Ion Agorria
Signed-off-by: Svyatoslav Ryhel
Reviewed-by: Mattijs Korpershoek
---
doc/android/fastboot-protocol.rst | 3 ++
drivers/fastboot/fb_command.c | 3 ++
drivers/fastboot/fb_getvar.c | 77 +--
include/fastboot-internal.h | 7 +++
4 files changed, 77 insertions(+), 13 deletions(-)
diff --git a/doc/android/fastboot-protocol.rst
b/doc/android/fastboot-protocol.rst
index e8cbd7f24e..8bd6d7168f 100644
--- a/doc/android/fastboot-protocol.rst
+++ b/doc/android/fastboot-protocol.rst
@@ -173,6 +173,9 @@ The various currently defined names are::
bootloader requiring a signature before
it will install or boot images.
+ all Provides all info from commands above as
+ they were called one by one
+
Names starting with a lowercase character are reserved by this
specification. OEM-specific names should not start with lowercase
characters.
diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
index ab72d8c781..6f621df074 100644
--- a/drivers/fastboot/fb_command.c
+++ b/drivers/fastboot/fb_command.c
@@ -156,6 +156,9 @@ int fastboot_handle_command(char *cmd_string, char
*response)
void fastboot_multiresponse(int cmd, char *response)
{
switch (cmd) {
+ case FASTBOOT_COMMAND_GETVAR:
+ fastboot_getvar_all(response);
+ break;
default:
fastboot_fail("Unknown multiresponse command", response);
break;
diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
index 8cb8ffa2c6..f65519c57b 100644
--- a/drivers/fastboot/fb_getvar.c
+++ b/drivers/fastboot/fb_getvar.c
@@ -29,53 +29,67 @@ static void getvar_is_userspace(char *var_parameter, char
*response);
static const struct {
const char *variable;
+ bool list;
void (*dispatch)(char *var_parameter, char *response);
} getvar_dispatch[] = {
{
.variable = "version",
- .dispatch = getvar_version
+ .dispatch = getvar_version,
+ .list = true,
}, {
.variable = "version-bootloader",
- .dispatch = getvar_version_bootloader
+ .dispatch = getvar_version_bootloader,
+ .list = true
}, {
.variable = "downloadsize",
- .dispatch = getvar_downloadsize
+ .dispatch = getvar_downloadsize,
+ .list = true
}, {
.variable = "max-download-size",
- .dispatch = getvar_downloadsize
+ .dispatch = getvar_downloadsize,
+ .list = true
}, {
.variable = "serialno",
- .dispatch = getvar_serialno
+ .dispatch = getvar_serialno,
+ .list = true
}, {
.variable = "version-baseband",
- .dispatch = getvar_version_baseband
+ .dispatch = getvar_version_baseband,
+ .list = true
}, {
.variable = "product",
- .dispatch = getvar_product
+ .dispatch = getvar_product,
+ .list = true
}, {
.variable = "platform",
- .dispatch = getvar_platform
+ .dispatch = getvar_platform,
+ .list = true
}, {
.variable = "current-slot",
- .dispatch = getvar_current_slot
+ .dispatch = getvar_current_slot,
+ .list = true
#if IS_ENABLED(CONFIG_FASTBOOT_FLASH)
}, {
.variable = "has-slot",
- .dispatch = getvar_has_slot
+ .dispatch = getvar_has_slot,
+ .list = false
#endif
#if IS_ENABLED(CONFIG_FASTBOOT_FLASH_MMC)
}, {
.variable = "partition-type",
- .dispatch = getvar_partition_type
+ .dispatch = getvar_partition_type,
+ .list = false
#endif
#if IS_ENABLED(CONFIG_FASTBOOT_FLASH)
}, {
.variable = "partition-size",
- .dispatch = getvar_partition_size
+ .dispatch = getvar_partition_size,
+ .list = false
#endif
}, {
.variable = "is-userspace",
- .dispatch = getvar_is_userspace
+ .dispatch = getvar_is_userspace,
+ .list = true
}
};
@@ -237,6 +251,40 @@ static void getvar_is_userspace(char *var_parameter, char
*response)
fastboot_okay("no", response);
}
+static int current_all_dispatch;
+void fastboot_getvar_all(char *response)
+{
+ /*
+* Find a dispatch getvar that can be listed and send
+
[PATCH v3 1/5] fastboot: multiresponse support
From: Ion Agorria
Currently u-boot fastboot can only send one message back to host,
so if there is a need to print more than one line messages must be
kept sending until all the required data is obtained. This behavior
can be adjusted using multiresponce ability (getting multiple lines
of response) proposed in this patch.
Signed-off-by: Ion Agorria
Signed-off-by: Svyatoslav Ryhel
Reviewed-by: Mattijs Korpershoek
---
drivers/fastboot/fb_command.c | 10 ++
drivers/usb/gadget/f_fastboot.c | 29 +
include/fastboot.h | 18 ++
net/fastboot_udp.c | 29 +++--
4 files changed, 80 insertions(+), 6 deletions(-)
diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
index 5fcadcdf50..ab72d8c781 100644
--- a/drivers/fastboot/fb_command.c
+++ b/drivers/fastboot/fb_command.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -152,6 +153,15 @@ int fastboot_handle_command(char *cmd_string, char
*response)
return -1;
}
+void fastboot_multiresponse(int cmd, char *response)
+{
+ switch (cmd) {
+ default:
+ fastboot_fail("Unknown multiresponse command", response);
+ break;
+ }
+}
+
/**
* okay() - Send bare OKAY response
*
diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 741775a7bc..0850350331 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -497,6 +497,25 @@ static void do_bootm_on_complete(struct usb_ep *ep, struct
usb_request *req)
do_exit_on_complete(ep, req);
}
+static int multiresponse_cmd = -1;
+static void multiresponse_on_complete(struct usb_ep *ep, struct usb_request
*req)
+{
+ char response[FASTBOOT_RESPONSE_LEN] = {0};
+
+ if (multiresponse_cmd == -1)
+ return;
+
+ /* Call handler to obtain next response */
+ fastboot_multiresponse(multiresponse_cmd, response);
+ fastboot_tx_write_str(response);
+
+ /* If response is final OKAY/FAIL response disconnect this handler and
unset cmd */
+ if (!strncmp("OKAY", response, 4) || !strncmp("FAIL", response, 4)) {
+ multiresponse_cmd = -1;
+ fastboot_func->in_req->complete = fastboot_complete;
+ }
+}
+
static void do_acmd_complete(struct usb_ep *ep, struct usb_request *req)
{
/* When usb dequeue complete will be called
@@ -524,6 +543,16 @@ static void rx_handler_command(struct usb_ep *ep, struct
usb_request *req)
fastboot_fail("buffer overflow", response);
}
+ if (!strncmp(FASTBOOT_MULTIRESPONSE_START, response, 4)) {
+ multiresponse_cmd = cmd;
+ fastboot_multiresponse(multiresponse_cmd, response);
+
+ /* Only add complete callback if first is not a final OKAY/FAIL
response */
+ if (strncmp("OKAY", response, 4) && strncmp("FAIL", response,
4)) {
+ fastboot_func->in_req->complete =
multiresponse_on_complete;
+ }
+ }
+
if (!strncmp("DATA", response, 4)) {
req->complete = rx_handler_dl_image;
req->length = rx_bytes_expected(ep);
diff --git a/include/fastboot.h b/include/fastboot.h
index 296451f89d..59cbea61ec 100644
--- a/include/fastboot.h
+++ b/include/fastboot.h
@@ -14,6 +14,16 @@
#define FASTBOOT_VERSION "0.4"
+/*
+ * Signals u-boot fastboot code to send multiple responses by
+ * calling response generating function repeatedly until a OKAY/FAIL
+ * is generated as final response.
+ *
+ * This status code is only used internally to signal, must NOT
+ * be sent to host.
+ */
+#define FASTBOOT_MULTIRESPONSE_START ("MORE")
+
/* The 64 defined bytes plus \0 */
#define FASTBOOT_COMMAND_LEN (64 + 1)
#define FASTBOOT_RESPONSE_LEN (64 + 1)
@@ -172,5 +182,13 @@ void fastboot_data_download(const void *fastboot_data,
*/
void fastboot_data_complete(char *response);
+/**
+ * fastboot_handle_multiresponse() - Called for each response to send
+ *
+ * @cmd: Command id that requested multiresponse
+ * @response: Pointer to fastboot response buffer
+ */
+void fastboot_multiresponse(int cmd, char *response);
+
void fastboot_acmd_complete(void);
#endif /* _FASTBOOT_H_ */
diff --git a/net/fastboot_udp.c b/net/fastboot_udp.c
index d690787478..6fee441ab3 100644
--- a/net/fastboot_udp.c
+++ b/net/fastboot_udp.c
@@ -42,16 +42,15 @@ static int fastboot_remote_port;
static int fastboot_our_port;
/**
- * fastboot_udp_send_info() - Send an INFO packet during long commands.
+ * fastboot_udp_send_response() - Send an response into UDP
*
- * @msg: String describing the reason for waiting
+ * @response: Response to send
*/
-static void fastboot_udp_send_info(const char *msg)
+static void fastboot_udp_send_response(const char *response)
{
uchar *packet;
uchar *packet_base;
[PATCH v3 0/5] Implement fastboot multiresponce
Currently u-boot fastboot can only send one message back to host, so if there is a need to print more than one line messages must be kept sending until all the required data is obtained. This behavior can be adjusted using multiresponce ability (getting multiple lines of response) proposed in this patch set. Implementation of multiresponce leads to ability to dump content of console buffer which, with use of "oem run", allows to entirely avoid need in UART. --- Changes from v2: - fix missing function calls if CONFIG_CONSOLE_RECORD is not enabled Changes from v1: - changed variables to static - fixed multiresponce for udp - documented use of "MORE" - converted #if to if (...) --- Ion Agorria (5): fastboot: multiresponse support fastboot: implement "getvar all" common: console: introduce overflow and isempty calls lib: membuff: fix readline not returning line in case of overflow fastboot: add oem console command support boot/bootmeth_extlinux.c | 2 +- common/console.c | 17 +-- doc/android/fastboot-protocol.rst | 3 ++ doc/android/fastboot.rst | 1 + drivers/fastboot/Kconfig | 7 +++ drivers/fastboot/fb_command.c | 52 + drivers/fastboot/fb_getvar.c | 77 +-- drivers/usb/gadget/f_fastboot.c | 29 include/console.h | 26 +++ include/fastboot-internal.h | 7 +++ include/fastboot.h| 19 include/membuff.h | 5 +- lib/membuff.c | 4 +- net/fastboot_udp.c| 29 +--- test/ut.c | 9 ++-- 15 files changed, 254 insertions(+), 33 deletions(-) -- 2.40.1
Re: [PATCH v2 1/5] cyclic: Add a symbol for SPL
On Tue, Nov 21, 2023 at 09:20:39AM -0700, Simon Glass wrote: > Hi Tom, > > On Tue, 21 Nov 2023 at 06:06, Tom Rini wrote: > > > > On Mon, Nov 20, 2023 at 07:09:25PM -0700, Simon Glass wrote: > > > > > The cyclic subsystem is currently enabled either in all build phases > > > or none. For tools this should not be enabled, but since lib/shc256.c > > > and other files include watchdog.h in the host build, we must make > > > sure that it is not enabled there. > > > > > > Add an SPL symbol so that there is more control of this. > > > > > > Add an include into cyclic.h so that tools can include this file. > > > > > > Also add the kconfig.h header so that CONFIG_IS_ENABLED() works. We > > > could avoid this for now by moving the location of the watchdog.h > > > inclusion to outside the USE_HOSTCC area. But at some point the #ifdefs > > > from these files will likely be removed, so there is no benefit in > > > going that way. > > > > > > Signed-off-by: Simon Glass > > [snip] > > > --- a/include/cyclic.h > > > +++ b/include/cyclic.h > > > @@ -11,6 +11,7 @@ > > > #ifndef __cyclic_h > > > #define __cyclic_h > > > > > > +#include > > > #include > > > #include > > > > As I said, we just need to fix lib/sha*.c so NAK. The only thing that > > stopped me from posting that patch last night was that I went and > > removed from everything in lib/ as a follow-up and that's > > taken a few more iterations. > > > > Yes I had the same thought the first time and mentioned it > specifically in this version. > > If you are a doing a clean-up, perhaps you could drop the #idefs in > the sha files? Nope, they specifically need outside of tools builds for schedule(). -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/7] efi: Show the vendor in helloworld
On 11/21/23 12:35, Simon Glass wrote: Show the vendor name since it useful to see that. With this commit message it remains unclear why displaying the constant value (u"Das U-Boot") is of any value. Best regards Heinrich Signed-off-by: Simon Glass --- lib/efi_loader/helloworld.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lib/efi_loader/helloworld.c b/lib/efi_loader/helloworld.c index bd72822c0b72..1135d3a3c37e 100644 --- a/lib/efi_loader/helloworld.c +++ b/lib/efi_loader/helloworld.c @@ -234,6 +234,9 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle, (con_out, u"Missing device path for device handle\r\n"); goto out; } + con_out->output_string(con_out, u"Vendor: "); + con_out->output_string(con_out, systab->fw_vendor); + con_out->output_string(con_out, u"\n"); con_out->output_string(con_out, u"Boot device: "); ret = print_device_path(device_path, device_path_to_text); if (ret != EFI_SUCCESS)
Re: [PATCH 1/7] efi: Use puts() in cout so that console recording works
On 11/21/23 12:35, Simon Glass wrote: At present EFI output to the console use fputs() which bypasses the console-recording feature. This makes it impossible for tests to check the output of an EFI app. There doesn't seem to be any need to do this bypass, so adjust it to simply use the puts() function. Signed-off-by: Simon Glass Reviewed: Heinrich Schuchardt --- lib/efi_loader/efi_console.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c index a2d137d7a9e1..28087582e8d6 100644 --- a/lib/efi_loader/efi_console.c +++ b/lib/efi_loader/efi_console.c @@ -182,7 +182,7 @@ static efi_status_t EFIAPI efi_cout_output_string( } pos = buf; utf16_utf8_strcpy(, string); - fputs(stdout, buf); + puts(buf); free(buf); /*
Re: [PATCH 02/29] mmc: env: Unify the U_BOOT_ENV_LOCATION conditions
On Sun, Nov 19, 2023 at 07:49:32AM -0700, Simon Glass wrote:
> Hi Heinrich,
>
> On Wed, 15 Nov 2023 at 03:02, Heinrich Schuchardt wrote:
> >
> > On 11/12/23 01:08, Simon Glass wrote:
> > > The declaration of U_BOOT_ENV_LOCATION() uses a different #ifdef
> > > condition from the code it calls. Use the same condition to avoid a
> > > build warning if CONFIG_CMD_SAVEENV is disabled.
> > >
> > > Signed-off-by: Simon Glass
> > > ---
> > >
> > > env/mmc.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/env/mmc.c b/env/mmc.c
> > > index cb14bbb58f13..da84cddd74f0 100644
> > > --- a/env/mmc.c
> > > +++ b/env/mmc.c
> > > @@ -495,7 +495,7 @@ U_BOOT_ENV_LOCATION(mmc) = {
> > > .location = ENVL_MMC,
> > > ENV_NAME("MMC")
> > > .load = env_mmc_load,
> > > -#ifndef CONFIG_SPL_BUILD
> > > +#if defined(CONFIG_CMD_SAVEENV) && !defined(CONFIG_SPL_BUILD)
> >
> > According to README CONFIG_SPL_BUILD is not defined for TPL builds.
> >
> > I assume that we don't want to have below fields in TPL either. Please, use
> >
> > #if CONFIG_IS_ENABLED(CMD_SAVEENV)
>
> I missed this comment in the new version. But note that
> CONFIG_SPL_BUILD covers TPL (and others) as well.
>
> It is a bit confusing. Perhaps we should introduce CONFIG_XPL_BUILD to
> mean anything other than U-Boot proper?
We can see if something like that makes more sense as we further
separate out "library" functionality from "command" functionality. We
might swing back to needing to save environment changes from the
non-cmdline use cases all the same (assorted canary type environment
variables, etc) and be back to needing to tweak this differently. So
what's here is fine with me for today.
Reviewed-by: Tom Rini
... and just put that on the next iteration of the series.
--
Tom
signature.asc
Description: PGP signature
Re: [RFC PATCH 0/2] rpi5: initial support
On Sat, Nov 18, 2023 at 05:41:34PM +0100, Dmitry Malkin wrote: > I was not able to boot rpi5 with the latest master. I run into > dram_init() error: > > DRAM: mbox: Timeout waiting for response > > bcm2835: Could not query ARM memory size > > Apparently there is a new peripheral layout and ARMC MBOX has a > different offset within. > > Turns out there is a compatible node "brcm,bcm2835-mbox" for all RPIs > (bcm238x/bcm271x). > > After fixing this I got to the point where mmu_setup() was hanging > (looks like it was due to incorrect mapping). So I've added a > definition of first gigabyte of RAM and SOC range for bcm2712 into > rpi.c. > > With those two patches and rpi_arm64_defconfig (with disabled > CONFIG_VIDEO_BCM2835) I'm able to get a working u-boot prompt (over > serial). FDT comes from firmware (EEPROM). > > These patches are based on v2024.01-rc2 and tested with RPI5 8GB. > > Known issues: > * CONFIG_VIDEO_BCM2835 doesn't work. > * MBOX get board revision (0x10002) doesn't work (the response status > is 0x8000_0001). > > > Dmitry Malkin (2): > rpi5: add alternative way to get MBOX address via FDT node > rpi5: add initial memory map for bcm2712 > > arch/arm/mach-bcm283x/include/mach/base.h | 1 + > arch/arm/mach-bcm283x/include/mach/mbox.h | 4 ++-- > arch/arm/mach-bcm283x/init.c | 29 ++- > 3 files changed, 31 insertions(+), 3 deletions(-) > I'm glad to someone is looking at this currently, thanks! I suspect we'll need a number of device compatible updates (and related tweaks) to get most things working. -- Tom signature.asc Description: PGP signature
Re: [PATCH 0/4] serial: s5p: Cleanups
On Tue, Nov 7, 2023 at 1:06 PM Sam Protsenko wrote: > > A small collection of cleanup patches for serial_s5p.c driver. Should > induce no functional changes. > > Sam Protsenko (4): > serial: s5p: Remove common.h inclusion > serial: s5p: Use livetree API to get "id" property > serial: s5p: Use named constants for register values > serial: s5p: Improve coding style > > drivers/serial/serial_s5p.c | 71 + > 1 file changed, 40 insertions(+), 31 deletions(-) > > -- + Minkyu Just a kind reminder to review this series. Thanks! > 2.39.2 >
Re: [PATCH v2 1/2] board: samsung: Fix SYS_CONFIG_NAME configs in axy17lte Kconfig
Hi Tom, Minkyu,
On Thu, Nov 9, 2023 at 2:13 PM Sam Protsenko wrote:
>
> There is a couple of issues related to SYS_CONFIG_NAME config in
> axy17lte Kconfig.
>
> 1. The global SYS_CONFIG_NAME in axy17lte Kconfig overrides
>SYS_CONFIG_NAME for all boards specified after this line in
>arch/arm/mach-exynos/Kconfig:
>
>source "board/samsung/axy17lte/Kconfig"
>
>Right now it's the last 'source' line there, so the issue is not
>reproducible. But once some board is moved or added after this line
>the next build error will happen:
>
>GEN include/autoconf.mk.dep
> In file included from ./include/common.h:16:
> include/config.h:3:10: fatal error: configs/exynos78x0-common.h.h:
> No such file or directory
> 3 | #include
>| ^~~
> compilation terminated.
>
>That's happening because axy17lte Kconfig defines SYS_CONFIG_NAME
>option in global namespace (not guarded with any "if TARGET_..."), so
>it basically rewrites the correct SYS_CONFIG_NAME defined in the
>hypothetical boards which might appear after axy17lte in mach-exynos
>Kconfig.
>
> 2. Another side of the issue is that SYS_CONFIG_NAME is defined
>incorrectly in axy17lte Kconfig:
>
>config SYS_CONFIG_NAME
>default "exynos78x0-common.h"
>
>The .h extension should not have been specified there. It's leading
>to a build error, as the generated include file has a double '.h'
>extension.
>
> 3. Each target in axy17lte/Kconfig defines its own SYS_CONFIG_NAME. But
>all of those in fact incorrect, as corresponding
>include/configs/.h header files don't exist.
>
> 4. The global SYS_CONFIG_NAME pretty much repeats the help description
>from arch/Kconfig and doc/README.kconfig.
>
> Corresponding defconfig files (a*y17lte_defconfig) fix above issues by
> overriding SYS_CONFIG_NAME and correctly setting it to
> "exynos78x0-common".
>
> Fix all mentioned issues by removing the incorrect global
> SYS_CONFIG_NAME and instead specifying it (correctly) in SYS_CONFIG_NAME
> options for each target instead.
>
> Signed-off-by: Sam Protsenko
> Fixes: 3e2095e960b4 ("board: samsung: add support for Galaxy A series of 2017
> (a5y17lte)")
> ---
If this series (v2) looks good to you, can you please apply it? It's
needed for the new Exynos dev board port I'm working on right now, and
expect to submit the patches soon.
Thanks!
> Changes in v2:
> - Don't just remove global SYS_CONFIG_NAME, also fix SYS_CONFIG_NAME
> for each target in Kconfig
>
> board/samsung/axy17lte/Kconfig | 14 +++---
> 1 file changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/board/samsung/axy17lte/Kconfig b/board/samsung/axy17lte/Kconfig
> index a018547ff5d4..64a4ffa7e673 100644
> --- a/board/samsung/axy17lte/Kconfig
> +++ b/board/samsung/axy17lte/Kconfig
> @@ -1,11 +1,3 @@
> -config SYS_CONFIG_NAME
> - string "Board configuration name"
> - default "exynos78x0-common.h"
> - help
> - This option contains information about board configuration name.
> - Based on this option include/configs/.h
> header
> - will be used for board configuration.
> -
> if TARGET_A5Y17LTE
> config SYS_BOARD
> default "axy17lte"
> @@ -16,7 +8,7 @@ config SYS_VENDOR
> default "samsung"
>
> config SYS_CONFIG_NAME
> - default "a5y17lte"
> + default "exynos78x0-common"
>
> config EXYNOS7880
> bool "Exynos 7880 SOC support"
> @@ -33,7 +25,7 @@ config SYS_VENDOR
> default "samsung"
>
> config SYS_CONFIG_NAME
> - default "a5y17lte"
> + default "exynos78x0-common"
>
> config EXYNOS7880
> bool "Exynos 7880 SOC support"
> @@ -50,7 +42,7 @@ config SYS_VENDOR
> default "samsung"
>
> config SYS_CONFIG_NAME
> - default "a3y17lte"
> + default "exynos78x0-common"
>
> config EXYNOS7870
> bool "Exynos 7870 SOC support"
> --
> 2.39.2
>
Re: [PATCH 2/4] serial: s5p: Use livetree API to get "id" property
On Mon, Nov 13, 2023 at 12:01 PM Simon Glass wrote:
> >
> > The 'port_id' seems to be needed for ARCH_EXYNOS4 boards. Because
> > Exynos4 doesn't have proper DM clocks, it uses 'id' property to get
> > corresponding UART clock frequency from its mach code.
> >
> > Here is what's happening in the serial driver in case of Exynos4:
> >
> > 1. get_uart_clk(port_id) is called
> > 2. which in turn calls exynos4_get_uart_clk(port_id)
> > 3. which uses "port_id" value to read corresponding bits of of
> > CLK_SRC_PERIL0 register
> > 4. those bits are used to get corresponding PLL clock's frequency
> > 5. which is in turn used to calculate UART clock rate
> > 6. calculated rate is returned by get_uart_clk() to serial driver
> >
> > So I don't see any *easy* way we can get rid of that id property.
> >
> > The proper way of doing that would require converting Exynos4 clock
> > code to CCF (enabling CONFIG_CLK_EXYNOS). Which of course also means
> > implementing clocks in dts, akin to kernel's exynos4.dtsi. Then it'll
> > be possible to get rid of 'id' property.
>
> That sounds good!
>
> >
> > Maybe I'm missing something, please let me know.
>
> An easy way in the meantime would be to look at the compatible / reg
> property, e.g. here is a sketch:
>
> static int get_id(ofnode node)
> {
> ulong addr = (ulong)plat->reg;
> if (ofnode_device_is_compatible(node, "samsung,exynos4210-uart")) {
> return (addr >> 16) & 0xf;
> ...
>
> reg = <0x1380 0x3c>;
> id = <0>;
> };
>
> serail_1: serial@1381 {
> compatible = "samsung,exynos4210-uart";
> reg = <0x1381 0x3c>;
> id = <1>;
> };
>
> serial_2: serial@1382 {
> compatible = "samsung,exynos4210-uart";
> reg = <0x1382 0x3c>;
> id = <2>;
> };
>
> serial_3: serial@1383 {
> compatible = "samsung,exynos4210-uart";
> reg = <0x1383 0x3c>;
> id = <3>;
> };
>
> serial_4: serial@1384 {
> compatible = "samsung,exynos4210-uart";
> reg = <0x1384 0x3c>;
> id = <4>;
>
To be honest, I'm a bit of busy right now working on U-Boot port for a
new Exynos dev board, which I want to finalize and upstream ASAP. Do
you think it's possible to take this one as is for now? At least it
fixes one issue (fdtdec API and global data pointer).
Thanks!
> Regards,
> Simon
Re: [PATCH 3/7] efi: test: Create a disk image with and EFI app in it
On 11/21/23 12:35, Simon Glass wrote:
Create a new disk for use with test, which contains the sandbox
helloworld app. This will be used to test the EFI boot bootmeth.
Signed-off-by: Simon Glass
---
test/py/tests/test_ut.py | 32
1 file changed, 32 insertions(+)
diff --git a/test/py/tests/test_ut.py b/test/py/tests/test_ut.py
index 1d9149a3f683..f6220c05238a 100644
--- a/test/py/tests/test_ut.py
+++ b/test/py/tests/test_ut.py
@@ -468,6 +468,37 @@ def test_ut_dm_init(u_boot_console):
with open(fn, 'wb') as fh:
fh.write(data)
+
+def setup_efi_image(cons):
+"""Create a 20MB disk image with an EFI app on it"""
+mmc_dev = 7
+fname, mnt = setup_image(cons, mmc_dev, 0xc, second_part=True)
If you would set the partition type GUID to ESP, U-Boot would stop to
complain about EFI variable that cannot be persisted.
There is a pending patch that wants to make the failure to persist EFI
variable fatal.
[RESEND,v2] efi_loader: Fix UEFI variable error handling
https://patchwork.ozlabs.org/project/uboot/patch/20231113161031.138304-1-o451686...@gmail.com/
Best regards
Heinrich
+
+loop = None
+mounted = False
+try:
+loop = mount_image(cons, fname, mnt, 'ext4')
+mounted = True
+efi_dir = os.path.join(mnt, 'efi')
+mkdir_cond(efi_dir)
+bootdir = os.path.join(efi_dir, 'boot')
+mkdir_cond(bootdir)
+efi_src = os.path.join(cons.config.build_dir,
+ f'lib/efi_loader/helloworld.efi')
+efi_dst = os.path.join(bootdir, 'bootsbox.efi')
+with open(efi_src, 'rb') as inf:
+with open(efi_dst, 'wb') as outf:
+outf.write(inf.read())
+
+finally:
+if mounted:
+u_boot_utils.run_and_log(cons, 'sudo umount --lazy %s' % mnt)
+if loop:
+u_boot_utils.run_and_log(cons, 'sudo losetup -d %s' % loop)
+
+
+
+
@pytest.mark.buildconfigspec('cmd_bootflow')
def test_ut_dm_init_bootstd(u_boot_console):
"""Initialise data for bootflow tests"""
@@ -476,6 +507,7 @@ def test_ut_dm_init_bootstd(u_boot_console):
setup_bootmenu_image(u_boot_console)
setup_cedit_file(u_boot_console)
setup_cros_image(u_boot_console)
+setup_efi_image(u_boot_console)
# Restart so that the new mmc1.img is picked up
u_boot_console.restart_uboot()
Re: [PATCH 4/7] WIP: efi: Disable ANSI output
On 11/21/23 12:35, Simon Glass wrote:
We don't want ANSI characters written in tests since it is a pain to
check the output.
I never experienced such pain. The Gitlab output just renders things as
expected.
For now, don't bother checking the console size.
A better solution is need, which allows ANSI output to be controlled
within EFI.
Signed-off-by: Simon Glass
---
include/efi_loader.h | 14 --
lib/efi_loader/efi_console.c | 17 +++--
lib/efi_loader/efi_setup.c | 2 +-
3 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 247be060e1c0..ebe951922791 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -527,8 +527,18 @@ efi_status_t
efi_bootmgr_update_media_device_boot_option(void);
efi_status_t efi_bootmgr_delete_boot_option(u16 boot_index);
/* search the boot option index in BootOrder */
bool efi_search_bootorder(u16 *bootorder, efi_uintn_t num, u32 target, u32
*index);
-/* Set up console modes */
-void efi_setup_console_size(void);
+
+/**
+ * efi_setup_console_size() - update the mode table.
+ *
+ * @allow_ansi: Allow emitting ANSI characters
+ *
+ * By default the only mode available is 80x25. If the console has at least 50
+ * lines, enable mode 80x50. If we can query the console size and it is neither
+ * 80x25 nor 80x50, set it as an additional mode.
+ */
+void efi_setup_console_size(bool allow_ansi);
+
/* Install device tree */
efi_status_t efi_install_fdt(void *fdt);
/* Run loaded UEFI image */
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index 28087582e8d6..ea1608f8e6ec 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -349,22 +349,19 @@ static int __maybe_unused query_vidconsole(int *rows, int
*cols)
return 0;
}
-/**
- * efi_setup_console_size() - update the mode table.
- *
- * By default the only mode available is 80x25. If the console has at least 50
- * lines, enable mode 80x50. If we can query the console size and it is neither
- * 80x25 nor 80x50, set it as an additional mode.
- */
-void efi_setup_console_size(void)
+void efi_setup_console_size(bool allow_ansi)
{
int rows = 25, cols = 80;
int ret = -ENODEV;
if (IS_ENABLED(CONFIG_VIDEO))
ret = query_vidconsole(, );
- if (ret)
- ret = query_console_serial(, );
+ if (ret) {
+ if (allow_ansi)
+ ret = query_console_serial(, );
+ else
+ ret = 0;
+ }
if (ret)
return;
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index e6de685e8795..d4226a3011ac 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -230,7 +230,7 @@ efi_status_t efi_init_obj_list(void)
return efi_obj_list_initialized;
/* Set up console modes */
- efi_setup_console_size();
+ efi_setup_console_size(false);
This would render our console non-compliant. Please, keep it as is.
Testing is not the primary task of U-Boot. If you need to filter test
output, please, add a filter method to your test setup.
Best regards
Heinrich
/*
* Probe block devices to find the ESP.
Re: [PATCH 7/7] WIP: efi: debugging
On 11/21/23 12:35, Simon Glass wrote:
This works when run outside a test:
good:
/tmp/b/sandbox/u-boot -T
-c "bootfl scan mmc; bootfl sel 1; bootfl list; bootfl b"
** Booting bootflow 'mmc7.bootdev.part_1' with efi
desc = 18c86ee0
dev=mmc, devnr=7:1, path=efi/boot/bootsbox.efi, buffer=11001000,
size=1600
- boot device
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,)/SD(7)/SD(3)/HD(1,MBR,0x2f7d9756,0x800,0x9000)
- image /efi\boot\bootsbox.efi
No EFI system partition
No EFI system partition
Failed to persist EFI variables
EFI using ACPI tables at 8ef8000
WARNING: Can't have ACPI table and device tree - ignoring DT.
Loaded from disk
Booting /efi\boot\bootsbox.efi
EFI: Call: efi_load_image(false, efi_root, file_path, source_buffer, source_size,
)
info->device_handle = 18f180e0
loaded_image info for 18f184e0: 18f18470
EFI: 0 returned by efi_load_image(false, efi_root, file_path, source_buffer,
source_size, )
EFI: Call: efi_start_image(handle, _data_size, _data)
Hello, world!
Running on UEFI 2.10
Have ACPI 2.0 table
Have SMBIOS table
18f18470
Load options:
finding
- search 18c931a0 ret=0
File path: /efi\boot\bootsbox.efi
Vendor: Das U-Boot
Boot device:
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,)/SD(7)/SD(3)/HD(1,MBR,0x2f7d9756,0x800,0x9000)
Exiting boot sevices
EFI: 5 returned by efi_start_image(handle, _data_size, _data)
Boot failed (err=-22)
bad:
rtv bootflow_efi
** Booting bootflow 'mmc7.bootdev.part_1' with efi
Should we have an ESP on the MMC image to persist UEFI variables?
Best regards
Heinrich
desc = 18c86ee0
dev=mmc, devnr=8:1, path=efi/boot/bootsbox.efi, buffer=11001000,
size=1600
- boot device
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,)/SD(7)/SD(3)/HD(1,MBR,0x2f7d9756,0x800,0x9000)
- image /efi\boot\bootsbox.efi
No EFI system partition
No EFI system partition
Failed to persist EFI variables
EFI using ACPI tables at 8ef8000
WARNING: Can't have ACPI table and device tree - ignoring DT.
Loaded from disk
Booting /efi\boot\bootsbox.efi
EFI: Call: efi_load_image(false, efi_root, file_path, source_buffer, source_size,
)
info->device_handle =
loaded_image info for 18c924e0: 18f15080
EFI: 0 returned by efi_load_image(false, efi_root, file_path, source_buffer,
source_size, )
EFI: Call: efi_start_image(handle, _data_size, _data)
Hello, world!
Running on UEFI 2.10
Have ACPI 2.0 table
Have SMBIOS table
18f15080
Load options:
finding
- search 18c931a0 ret=0
File path: /efi\boot\bootsbox.efi
Missing device handle
Exiting boot sevices
EFI: 5 returned by efi_start_image(handle, _data_size, _data)
Boot failed (err=-22)
test/boot/bootflow.c:1091, bootflow_efi(): console:
Expected 'No EFI system partition',
got 'desc = 18c86ee0'
Test bootflow_efi failed 1 times
Failures: 1
(see 'Missing device handle')
It seems that the device number is inconsistent between generation and
decoding.
function rt_get_suite_and_name() {
local arg
#echo arg $arg
suite=
name=
if [ "$1" = "-f" ]; then
force="-f"
shift
fi
arg="$1"
rest="$2"
# The symbol is something like this:
# _u_boot_list_2_ut_bootstd_test_2_vbe_simple_test_base
# Split it into the suite name (bootstd) and test name
# (vbe_simple_test_base)
read suite name < \
<(nm /tmp/b/$exec/u-boot |grep "list_2_ut.*$arg.*" \
| cut -d' ' -f3 \
| head -1 \
| sed -n 's/_u_boot_list_2_ut_\(.*\)_test_2_/\1 /p')
#echo suite $suite
#echo name $name
#name=${1#dm_test_}
#name=${name#ut_dm_}
}
function rtv() {
local exec=sandbox
local suite name force rest
rt_get_suite_and_name $*
U_BOOT_PERSISTENT_DATA_DIR=/tmp/b/sandbox/persistent-data \
/tmp/b/$exec/u-boot -v -T $rest -c "ut $suite $force $name"
}
Signed-off-by: Simon Glass
---
boot/bootflow.c | 2 ++
boot/bootmeth_efi.c | 1 +
cmd/bootefi.c | 1 +
lib/efi_loader/efi_boottime.c | 5 +
test/boot/bootflow.c | 2 +-
5 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/boot/bootflow.c b/boot/bootflow.c
index 6922e7e0c4e7..0513522a7ec4 100644
--- a/boot/bootflow.c
+++ b/boot/bootflow.c
@@ -464,6 +464,8 @@ void bootflow_init(struct bootflow *bflow, struct udevice
*bootdev,
void bootflow_free(struct bootflow *bflow)
{
+ /* this is where we want to get to (will only happen with USB) */
+ printf("bootflow free\n");
free(bflow->name);
free(bflow->subdir);
free(bflow->fname);
diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c
index ae936c8daa18..edee9e62a458 100644
--- a/boot/bootmeth_efi.c
+++ b/boot/bootmeth_efi.c
@@ -127,6 +127,7 @@
Re: [PATCH 6/7] WIP: efi: Allow helloworld to exit boot services
On 11/21/23 12:35, Simon Glass wrote:
This allows testing of the exit_boot_services call, providing more
coverage of the EFI bootmeth.
Signed-off-by: Simon Glass
I would prefer to keep helloworld.efi benign.
Please, create a new EFI binary for testing ExitBootServices().
---
lib/efi_loader/helloworld.c | 36 +++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/helloworld.c b/lib/efi_loader/helloworld.c
index 1135d3a3c37e..1fb5fb5a62f2 100644
--- a/lib/efi_loader/helloworld.c
+++ b/lib/efi_loader/helloworld.c
@@ -206,6 +206,26 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
(con_out, u"Cannot open loaded image protocol\r\n");
goto out;
}
+
+ {
+ ulong ptr = (ulong)loaded_image;
+ u16 str[80];
+ int i;
+
+ for (i = 0; i < 8; i++) {
+ uint digit = (ptr >> ((7 - i) * 4)) & 0xf;
+
+ if (digit > 9)
+ digit = 'a' + digit - 10;
+ else
+ digit += '0';
+ str[i] = digit;
+ }
+ str[i] = 0;
+ con_out->output_string(con_out, str);
+ con_out->output_string(con_out, u"\n");
+ }
+
print_load_options(loaded_image);
/* Get the device path to text protocol */
@@ -243,7 +263,21 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
goto out;
out:
- boottime->exit(handle, ret, 0, NULL);
+ /*
+* TODO: Use vendor string to decide whether to call exit-boot-services
+*/
+ efi_uintn_t map_size = 0;
+ efi_uintn_t map_key;
+ efi_uintn_t desc_size;
+ u32 desc_version;
+
+ ret = boottime->get_memory_map(_size, NULL, _key, _size,
+ _version);
+ con_out->output_string(con_out, u"Exiting boot sevices\n");
+
+ boottime->exit_boot_services(handle, map_key);
+
+ ret = boottime->exit(handle, ret, 0, NULL);
After ExitBootServices() you must not call boot services.
Call runtime->reset_system(EFI_RESET_COLD, EFI_SUCCESS, 0, NULL) instead.
Best regards
Heinrich
/* We should never arrive here */
return ret;
[PATCH 21/21] MAINTAINERS: Qualcomm: add some missing paths
Add board/qualcomm and the SoC/PMIC DTSI files. Adjust the driver paths to use globs rather than hardcoding every specific driver. Signed-off-by: Caleb Connolly --- MAINTAINERS | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 5a4bfbf550ca..4f87ebfcabee 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -571,15 +571,22 @@ M:Caleb Connolly M: Neil Armstrong R: Sumit Garg S: Maintained +F: arch/arm/dts/msm8*.dtsi +F: arch/arm/dts/pm8???.dtsi +F: arch/arm/dts/pms405.dtsi +F: arch/arm/dts/sdm845.dtsi F: arch/arm/mach-snapdragon/ +F: board/qualcomm F: configs/qcom_defconfig F: doc/board/qualcomm -F: drivers/button/button-qcom-pmic.c -F: drivers/clk/qcom/ +F: drivers/*/*/pm8???-* +F: drivers/*/*/qcom* +F: drivers/*/*/qcom/ +F: drivers/*/*qcom* +F: drivers/*/qcom/ F: drivers/gpio/msm_gpio.c F: drivers/mmc/msm_sdhci.c F: drivers/phy/msm8916-usbh-phy.c -F: drivers/pinctrl/qcom/ F: drivers/serial/serial_msm.c F: drivers/serial/serial_msm_geni.c F: drivers/smem/msm_smem.c -- 2.42.1
[PATCH 20/21] dts: qcs404-evb: import DT from Linux
Following the other boards, pull in the SoC and PMIC DTSI files from
Linux and adjust the board to use it.
Some U-Boot specific adjustments are still needed, so we can't use fully
upstream DT quite yet.
Signed-off-by: Caleb Connolly
---
arch/arm/dts/pms405.dtsi | 149 ++
arch/arm/dts/qcs404-evb-uboot.dtsi | 30 -
arch/arm/dts/qcs404-evb.dts | 441 +-
arch/arm/dts/qcs404.dtsi | 1830 ++
configs/qcs404evb_defconfig | 56 -
include/dt-bindings/clock/qcom,gcc-qcs404.h |4 +
include/dt-bindings/clock/qcom,turingcc-qcs404.h | 15 +
include/dt-bindings/pinctrl/qcom,pmic-gpio.h | 164 ++
8 files changed, 2248 insertions(+), 441 deletions(-)
diff --git a/arch/arm/dts/pms405.dtsi b/arch/arm/dts/pms405.dtsi
new file mode 100644
index ..461ad97032f7
--- /dev/null
+++ b/arch/arm/dts/pms405.dtsi
@@ -0,0 +1,149 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, Linaro Limited
+ */
+
+#include
+#include
+#include
+#include
+
+/ {
+ thermal-zones {
+ pms405-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+
+ thermal-sensors = <_temp>;
+
+ trips {
+ pms405_alert0: pms405-alert0 {
+ temperature = <105000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ pms405_crit: pms405-crit {
+ temperature = <125000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+ };
+};
+
+_bus {
+ pms405_0: pms405@0 {
+ compatible = "qcom,pms405", "qcom,spmi-pmic";
+ reg = <0x0 SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pms405_gpios: gpio@c000 {
+ compatible = "qcom,pms405-gpio", "qcom,spmi-gpio";
+ reg = <0xc000>;
+ gpio-controller;
+ gpio-ranges = <_gpios 0 0 12>;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ pon@800 {
+ compatible = "qcom,pms405-pon";
+ reg = <0x0800>;
+ mode-bootloader = <0x2>;
+ mode-recovery = <0x1>;
+
+ pwrkey {
+ compatible = "qcom,pm8941-pwrkey";
+ interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
+ debounce = <15625>;
+ bias-pull-up;
+ linux,code = ;
+ };
+ };
+
+ pms405_temp: temp-alarm@2400 {
+ compatible = "qcom,spmi-temp-alarm";
+ reg = <0x2400>;
+ interrupts = <0 0x24 0 IRQ_TYPE_EDGE_RISING>;
+ io-channels = <_adc ADC5_DIE_TEMP>;
+ io-channel-names = "thermal";
+ #thermal-sensor-cells = <0>;
+ };
+
+ pms405_adc: adc@3100 {
+ compatible = "qcom,pms405-adc", "qcom,spmi-adc-rev2";
+ reg = <0x3100>;
+ interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #io-channel-cells = <1>;
+
+ channel@0 {
+ reg = ;
+ qcom,pre-scaling = <1 1>;
+ label = "ref_gnd";
+ };
+
+ channel@1 {
+ reg = ;
+ qcom,pre-scaling = <1 1>;
+ label = "vref_1p25";
+ };
+
+ channel@131 {
+ reg = ;
+ qcom,pre-scaling = <1 3>;
+ label = "vph_pwr";
+ };
+
+ channel@6 {
+ reg = ;
+ qcom,pre-scaling = <1 1>;
+ label = "die_temp";
+ };
+
+ channel@77 {
+ reg = ;
+ qcom,ratiometric;
+
[PATCH 18/21] dts: msm8916: import DT from Linux
Import the msm8916 devicetree from Linux and adjust the dragonboard410c
devicetree to use it.
Signed-off-by: Caleb Connolly
---
arch/arm/dts/dragonboard410c-uboot.dtsi | 44 -
arch/arm/dts/dragonboard410c.dts| 198 +-
arch/arm/dts/msm8916-pins.dtsi | 582 ++
arch/arm/dts/msm8916-pm8916.dtsi| 76 +
arch/arm/dts/msm8916.dtsi | 2194 +++
arch/arm/dts/pm8916.dtsi| 183 ++
include/dt-bindings/arm/coresight-cti-dt.h | 37 +
include/dt-bindings/clock/qcom,rpmcc.h | 174 ++
include/dt-bindings/interconnect/qcom,msm8916.h | 100 ++
include/dt-bindings/reset/qcom,gcc-msm8916.h| 100 ++
10 files changed, 3484 insertions(+), 204 deletions(-)
diff --git a/arch/arm/dts/dragonboard410c-uboot.dtsi
b/arch/arm/dts/dragonboard410c-uboot.dtsi
deleted file mode 100644
index cec64bf80f99..
--- a/arch/arm/dts/dragonboard410c-uboot.dtsi
+++ /dev/null
@@ -1,44 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * U-Boot addition to handle Dragonboard 410c pins
- *
- * (C) Copyright 2015 Mateusz Kulikowski
- */
-
-/ {
-
- smem {
- bootph-all;
- };
-
- soc {
- bootph-all;
-
- pinctrl@100 {
- bootph-all;
-
- uart {
- bootph-all;
- };
- };
-
- qcom,gcc@180 {
- bootph-all;
- };
-
- serial@78b {
- bootph-all;
- };
- };
-};
-
-
-_gpios {
- usb_hub_reset_pm {
- gpios = <_gpios 2 0>;
- };
-
- usb_sw_sel_pm {
- gpios = <_gpios 3 0>;
- };
-};
diff --git a/arch/arm/dts/dragonboard410c.dts b/arch/arm/dts/dragonboard410c.dts
index a42b68fee8c0..8933c64e56e5 100644
--- a/arch/arm/dts/dragonboard410c.dts
+++ b/arch/arm/dts/dragonboard410c.dts
@@ -7,193 +7,40 @@
/dts-v1/;
-#include "skeleton64.dtsi"
#include
+#include "msm8916-pm8916.dtsi"
+
/ {
model = "Qualcomm Technologies, Inc. Dragonboard 410c";
compatible = "qcom,apq8016-sbc", "qcom,apq8016";
qcom,msm-id = <0xce 0x0 0xf8 0x0 0xf9 0x0 0xfa 0x0 0xf7 0x0>;
qcom,board-id = <0x10018 0x0>;
- #address-cells = <0x2>;
- #size-cells = <0x2>;
aliases {
usb0 = "/soc/ehci@78d9000";
+ serial0 = _uart2;
};
- memory {
+ memory@8000 {
device_type = "memory";
reg = <0 0x8000 0 0x3da0>;
};
- reserved-memory {
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
-
- smem_mem: smem_region@8630 {
- reg = <0x0 0x8630 0x0 0x10>;
- no-map;
- };
- };
-
chosen {
stdout-path = "/soc/serial@78b";
};
- smem {
- compatible = "qcom,smem";
- memory-region = <_mem>;
- qcom,rpm-msg-ram = <_msg_ram>;
- };
-
- soc {
- #address-cells = <0x1>;
- #size-cells = <0x1>;
- ranges = <0x0 0x0 0x0 0x>;
- compatible = "simple-bus";
-
- rpm_msg_ram: memory@6 {
- compatible = "qcom,rpm-msg-ram";
- reg = <0x6 0x8000>;
- };
-
- soc_gpios: pinctrl@100 {
- compatible = "qcom,msm8916-pinctrl";
- reg = <0x100 0x40>;
- gpio-controller;
- gpio-count = <122>;
- gpio-bank-name="soc";
- #gpio-cells = <2>;
-
- blsp1_uart: uart {
- function = "blsp1_uart";
- pins = "GPIO_4", "GPIO_5";
- drive-strength = <8>;
- bias-disable;
- };
- };
- clkc: qcom,gcc@180 {
- compatible = "qcom,gcc-msm8916";
- reg = <0x180 0x8>;
- #address-cells = <0x1>;
- #size-cells = <0x0>;
- #clock-cells = <0x1>;
- };
-
- serial@78b {
- compatible = "qcom,msm-uartdm-v1.4";
- reg = <0x78b 0x200>;
- clocks = < 4>;
- clock-names = "core";
- pinctrl-names = "uart";
- pinctrl-0 = <_uart>;
- };
-
- ehci@78d9000 {
- compatible = "qcom,ci-hdrc";
-
[PATCH 16/21] doc: board/qualcomm: document generic targets
Replace the board specific docs with a generic board.rst file which documents the build/boot process for the sdm845 and qcs404 boards now that the only differences are the DTB in use. At the same time, create a debugging page to document some useful snippets and tips for working with Qualcomm platforms. Signed-off-by: Caleb Connolly --- MAINTAINERS | 1 + doc/board/qualcomm/board.rst | 119 doc/board/qualcomm/debugging.rst | 61 +++ doc/board/qualcomm/index.rst | 4 +- doc/board/qualcomm/qcs404.rst| 79 --- doc/board/qualcomm/sdm845.rst| 162 --- 6 files changed, 183 insertions(+), 243 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 40b03d2647d0..5a4bfbf550ca 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -573,6 +573,7 @@ R: Sumit Garg S: Maintained F: arch/arm/mach-snapdragon/ F: configs/qcom_defconfig +F: doc/board/qualcomm F: drivers/button/button-qcom-pmic.c F: drivers/clk/qcom/ F: drivers/gpio/msm_gpio.c diff --git a/doc/board/qualcomm/board.rst b/doc/board/qualcomm/board.rst new file mode 100644 index ..3d08b88c39be --- /dev/null +++ b/doc/board/qualcomm/board.rst @@ -0,0 +1,119 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. sectionauthor:: Dzmitry Sankouski + +Qualcomm generic boards +=== + +About this +-- +This document describes how to build and run U-Boot for Qualcomm generic +boards. Right now the generic target supports the Snapdragon 845 SoC, however +it's expected to support more SoCs going forward. + +SDM845 - hi-end qualcomm chip, introduced in late 2017. +Mostly used in flagship phones and tablets of 2018. + +The current boot flow support loading u-boot as an Android boot image via +Qualcomm's UEFI-based ABL (Android) Bootloader. The DTB used by U-Boot will +be appended to the U-Boot image the same way as when booting Linux. U-Boot +will then retrieve the DTB during init. This way the memory layout and KASLR +offset will be populated by ABL. + +Installation + +Build +^ +Setup ``CROSS_COMPILE`` for aarch64 and build U-Boot for your board:: + + $ export CROSS_COMPILE= + $ make _defconfig + $ make + +This will build ``u-boot-nodtb.bin`` in the configured output directory. + +Generate FIT image +^^ +See doc/uImage.FIT for more details + +Pack android boot image +^^^ +We'll assemble android boot image with ``u-boot-nodtb.bin`` instead of linux kernel, +and FIT image instead of ``initramfs``. Android bootloader expect gzipped kernel +with appended dtb, so let's mimic linux to satisfy stock bootloader. + +Boards +-- + +starqlte + + +The starqltechn is a production board for Samsung S9 (SM-G9600) phone, +based on the Qualcomm SDM845 SoC. + +This device is supported by the common qcom_defconfig. + +The DTB is called "starqltechn.dtb" + +More information can be found on the `Samsung S9 page`_. + +dragonboard845c +^^^ + +The dragonboard845c is a Qualcomm Robotics RB3 Development Platform, based on +the Qualcomm SDM845 SoC. + +This device is supported by the common qcom_defconfig + +The DTB is called "dragonboard845c.dtb" + +More information can be found on the `DragonBoard 845c page`_. + +qcs404-evb +^^ + +The QCS404 EvB is a Qualcomm Development Platform, based on the Qualcomm QCS404 SoC. + +This device is supported by the common qcom_defconfig + +The DTB is called "qcs404-evb.dtb" + +Building steps +-- + +Steps: + +- Build u-boot:: + + $ export CROSS_COMPILE= + $ make qcom_defconfig + $ make + +- gzip u-boot:: + + gzip u-boot-nodtb.bin + +- Append dtb to gzipped u-boot:: + +cat u-boot-nodtb.bin.gz arch/arm/dts/your-board.dtb > u-boot-nodtb.bin.gz-dtb + +- A ``qcom.its`` file can be found in ``board/qualcomm/generic/`` + directory. It expects a folder as ``qcom_imgs/`` in the main directory + containing pre-built kernel, dts and ramdisk images. See ``qcom.its`` + for full path to images:: + + mkimage -f qcom.its qcom.itb + +- Now we've got everything to build android boot image:: + + mkbootimg --kernel u-boot-nodtb.bin.gz-dtb --ramdisk db845c.itb \ + --output boot.img --pagesize 4096 --base 0x8000 + +- Flash boot.img using fastboot and erase dtbo to avoid conflicts with our DTB: + + .. code-block:: bash + + fastboot flash boot boot.img + fastboot erase dtbo + +.. _Samsung S9 page: https://en.wikipedia.org/wiki/Samsung_Galaxy_S9 +.. _DragonBoard 845c page: https://www.96boards.org/product/rb3-platform/ diff --git a/doc/board/qualcomm/debugging.rst b/doc/board/qualcomm/debugging.rst new file mode 100644 index ..1c35d1909d12 --- /dev/null +++ b/doc/board/qualcomm/debugging.rst @@ -0,0 +1,61 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. sectionauthor:: Caleb Connolly + +Qualcomm
[PATCH 15/21] mach-snapdragon: generate fdtfile automatically
With just a few basic rules, we can generate the $fdtfile environment
variable to match the format used in Linux. This uses the root
compatible property inside u-boot, with specific handling for the
Dragonboard845c which is a special case, and for the qrb robotics
boards.
This is known to work on supported platforms, and lets us avoid having a
big lookup table.
Signed-off-by: Caleb Connolly
---
arch/arm/mach-snapdragon/board.c | 101 +++
1 file changed, 101 insertions(+)
diff --git a/arch/arm/mach-snapdragon/board.c b/arch/arm/mach-snapdragon/board.c
index 765a2c2a95fc..d142f2fddf8e 100644
--- a/arch/arm/mach-snapdragon/board.c
+++ b/arch/arm/mach-snapdragon/board.c
@@ -111,6 +111,106 @@ int board_init(void)
return 0;
}
+/* Sets up the "board", and "soc" environment variables as well as
constructing the devicetree
+ * path, with a few quirks to handle non-standard dtb filenames. This is not
meant to be a
+ * comprehensive solution to automatically picking the DTB, but aims to be
correct for the
+ * majority case. For most devices it should be possible to make this
algorithm work by
+ * adjusting the root compatible property in the U-Boot DTS. Handling devices
with multiple
+ * variants that are all supported by a single U-Boot image will require
implementing device-
+ * specific detection.
+ */
+static void configure_env(void)
+{
+ const char *first_compat, *last_compat;
+ char *tmp;
+ char buf[32] = { 0 };
+ /*
+* Most DTB filenames follow the scheme: qcom/-[vendor]-.dtb
+* The vendor is skipped when it's a Qualcomm reference board, or the
+* db845c.
+*/
+ char dt_path[64] = { 0 };
+ int compat_count, ret;
+ ofnode root;
+
+ root = ofnode_root();
+ /* This is almost always 2, but be explicit that we want the first and
last compatibles
+* not the first and second.
+*/
+ compat_count = ofnode_read_string_count(root, "compatible");
+ if (compat_count < 2) {
+ log_warning("%s: only one root compatible bailing!\n",
__func__);
+ return;
+ }
+
+ /* The most specific device compatible (e.g. "thundercomm,db845c") */
+ ret = ofnode_read_string_index(root, "compatible", 0, _compat);
+ if (ret < 0) {
+ log_warning("Can't read first compatible\n");
+ return;
+ }
+
+ /* The last compatible is always the SoC compatible */
+ ret = ofnode_read_string_index(root, "compatible", compat_count - 1,
_compat);
+ if (ret < 0) {
+ log_warning("Can't read second compatible\n");
+ return;
+ }
+
+ /* Copy the second compat (e.g. "qcom,sdm845") into buf */
+ strlcpy(buf, last_compat, sizeof(buf) - 1);
+ tmp = buf;
+
+ /* strsep() is destructive, it replaces the comma with a \0 */
+ if (!strsep(, ",")) {
+ log_warning("second compatible '%s' has no ','\n", buf);
+ return;
+ }
+
+ /* tmp now points to just the "sdm845" part of the string */
+ env_set("soc", tmp);
+
+ /* Now figure out the "board" part from the first compatible */
+ memset(buf, 0, sizeof(buf));
+ strlcpy(buf, first_compat, sizeof(buf) - 1);
+ tmp = buf;
+
+ /* The Qualcomm reference boards (RBx, HDK, etc) */
+ if (!strncmp("qcom", buf, strlen("qcom"))) {
+ /*
+* They all have the first compatible as "qcom,-"
+* (e.g. "qcom,qrb5165-rb5"). We extract just the part after
+* the dash.
+*/
+ if (!strsep(, "-")) {
+ log_warning("compatible '%s' has no '-'\n", buf);
+ return;
+ }
+ /* tmp is now "rb5" */
+ env_set("board", tmp);
+ } else {
+ if (!strsep(, ",")) {
+ log_warning("compatible '%s' has no ','\n", buf);
+ return;
+ }
+ /* for thundercomm we just want the bit after the comma (e.g.
"db845c"),
+* for all other boards we replace the comma with a '-' and
take both
+* (e.g. "oneplus-enchilada")
+*/
+ if (!strncmp("thundercomm", buf, strlen("thundercomm"))) {
+ env_set("board", tmp);
+ } else {
+ *(tmp - 1) = '-';
+ env_set("board", buf);
+ }
+ }
+
+ /* Now build the full path name */
+ snprintf(dt_path, sizeof(dt_path), "qcom/%s-%s.dtb",
+env_get("soc"), env_get("board"));
+ env_set("fdtfile", dt_path);
+}
+
void __weak qcom_late_init(void)
{
}
@@ -141,6 +241,7 @@ int board_late_init(void)
if (status)
log_warning("%s: Failed to set run time variables\n", __func__);
+
[PATCH 14/21] mach-snapdragon: dynamic load addresses
Heavily inspired by Apple board code. Use the LMB allocator to configure
load addresses at runtime, and implement a lookup table for selecting a
devicetree.
As some Qualcomm RBx boards have different RAM capacities and base
addresses, it isn't possible to hardcode these regions.
Signed-off-by: Caleb Connolly
---
arch/arm/Kconfig | 1 +
arch/arm/mach-snapdragon/board.c | 36
board/qualcomm/dragonboard410c/dragonboard410c.c | 2 +-
3 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1faa70bb658d..ae44fabb1609 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1075,6 +1075,7 @@ config ARCH_SNAPDRAGON
select OF_SEPARATE
select SMEM
select SPMI
+ select BOARD_LATE_INIT
select OF_BOARD
select SAVE_PREV_BL_FDT_ADDR
imply CMD_DM
diff --git a/arch/arm/mach-snapdragon/board.c b/arch/arm/mach-snapdragon/board.c
index 521390ed6eed..765a2c2a95fc 100644
--- a/arch/arm/mach-snapdragon/board.c
+++ b/arch/arm/mach-snapdragon/board.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
DECLARE_GLOBAL_DATA_PTR;
@@ -110,6 +111,41 @@ int board_init(void)
return 0;
}
+void __weak qcom_late_init(void)
+{
+}
+
+#define KERNEL_COMP_SIZE SZ_32M
+#define SZ_96M (SZ_64M + SZ_32M)
+
+#define addr_alloc(lmb, size) lmb_alloc(lmb, size, SZ_2M)
+
+/* Stolen from arch/arm/mach-apple/board.c */
+int board_late_init(void)
+{
+ struct lmb lmb;
+ u32 status = 0;
+
+ lmb_init_and_reserve(, gd->bd, (void *)gd->fdt_blob);
+
+ /* We need to be fairly conservative here as we support boards with
just 1G of TOTAL RAM */
+ status |= env_set_hex("kernel_addr_r", addr_alloc(, SZ_96M));
+ status |= env_set_hex("loadaddr", addr_alloc(, SZ_64M));
+ status |= env_set_hex("fdt_addr_r", addr_alloc(, SZ_2M));
+ status |= env_set_hex("ramdisk_addr_r", addr_alloc(, SZ_96M));
+ status |= env_set_hex("kernel_comp_addr_r", addr_alloc(,
KERNEL_COMP_SIZE));
+ status |= env_set_hex("kernel_comp_size", KERNEL_COMP_SIZE);
+ status |= env_set_hex("scriptaddr", addr_alloc(, SZ_4M));
+ status |= env_set_hex("pxefile_addr_r", addr_alloc(, SZ_4M));
+
+ if (status)
+ log_warning("%s: Failed to set run time variables\n", __func__);
+
+ qcom_late_init();
+
+ return 0;
+}
+
static void build_mem_map(void)
{
int i;
diff --git a/board/qualcomm/dragonboard410c/dragonboard410c.c
b/board/qualcomm/dragonboard410c/dragonboard410c.c
index bee8034ef92f..ab652e0a7c92 100644
--- a/board/qualcomm/dragonboard410c/dragonboard410c.c
+++ b/board/qualcomm/dragonboard410c/dragonboard410c.c
@@ -113,7 +113,7 @@ int misc_init_r(void)
return 0;
}
-int board_late_init(void)
+int qcom_late_init(void)
{
char serial[16];
--
2.42.1
[PATCH 13/21] mach-snapdragon: generalise board support
Historically, Qualcomm boards have relied on heavy hardcoding in U-Boot, in many cases to the specific SoC but also to the board itself (e.g. memory map). This has been largely resolved by modernising the Qualcomm drivers in U-Boot, however the board code still largely follows this model. This patch removes the board specific memory maps and duplicated board init code, replacing it with generic init code. The memory map is now built at runtime based on data read from DT, this allows for the memory map to be provided without having to recompile U-Boot. Support is also added for booting with appended DTBs, so that the first-stage bootloader can populate the memory map for us. The sdm845 specific init code is dropped entirely, it set an environment variable depending on if a button was pressed, but this variable wasn't used in U-Boot, and could be written to use the button command instead. The KASLR detection is also dropped as with appended dtb, the kaslr seed can be read directly from the DTB passed to U-Boot. A new qcom_defconfig is added, with the aim of providing a generic U-Boot configuration that will work on as many Qualcomm boards as possible. It replaces the defconfig files for the Dragonboard 845c, Galaxy S9, and QCS404 EVB. For now the db410c and 820c are excluded as they still have some board code left. Similarly, the config headers for db845c, starqltechn, and qcs404-evb are replaced by a single qcom header. Signed-off-by: Caleb Connolly --- MAINTAINERS | 2 + arch/arm/Kconfig | 3 + arch/arm/dts/Makefile| 9 +- arch/arm/mach-snapdragon/Kconfig | 96 +++-- arch/arm/mach-snapdragon/Makefile| 6 +- arch/arm/mach-snapdragon/board.c | 166 +++ arch/arm/mach-snapdragon/init_sdm845.c | 73 -- arch/arm/mach-snapdragon/sysmap-apq8016.c| 31 - arch/arm/mach-snapdragon/sysmap-apq8096.c| 31 - arch/arm/mach-snapdragon/sysmap-qcs404.c | 43 -- arch/arm/mach-snapdragon/sysmap-sdm845.c | 31 - board/qualcomm/dragonboard410c/Kconfig | 15 -- board/qualcomm/dragonboard410c/dragonboard410c.c | 25 board/qualcomm/dragonboard820c/Kconfig | 15 -- board/qualcomm/dragonboard820c/dragonboard820c.c | 39 +- board/qualcomm/dragonboard845c/Kconfig | 12 -- board/qualcomm/qcs404-evb/Kconfig| 15 -- board/qualcomm/qcs404-evb/qcs404-evb.c | 21 +-- configs/dragonboard410c_chainloaded_defconfig| 11 +- configs/dragonboard410c_defconfig| 6 +- configs/dragonboard820c_defconfig| 6 +- configs/dragonboard845c_defconfig| 29 configs/qcom_defconfig | 71 ++ configs/qcs404evb_defconfig | 5 +- configs/starqltechn_defconfig| 41 -- include/configs/dragonboard845c.h| 20 --- include/configs/qcom.h | 21 +++ include/configs/qcs404-evb.h | 20 --- 28 files changed, 306 insertions(+), 557 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 8cd102eaa070..40b03d2647d0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -572,6 +572,7 @@ M: Neil Armstrong R: Sumit Garg S: Maintained F: arch/arm/mach-snapdragon/ +F: configs/qcom_defconfig F: drivers/button/button-qcom-pmic.c F: drivers/clk/qcom/ F: drivers/gpio/msm_gpio.c @@ -583,6 +584,7 @@ F: drivers/serial/serial_msm_geni.c F: drivers/smem/msm_smem.c F: drivers/spmi/spmi-msm.c F: drivers/usb/host/ehci-msm.c +F: include/configs/qcom.h ARM STI M: Patrice Chotard diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 1add4282f336..1faa70bb658d 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1075,7 +1075,10 @@ config ARCH_SNAPDRAGON select OF_SEPARATE select SMEM select SPMI + select OF_BOARD + select SAVE_PREV_BL_FDT_ADDR imply CMD_DM + imply LINUX_KERNEL_IMAGE_HEADER config ARCH_SOCFPGA bool "Altera SOCFPGA family" diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 55aceb51cdb0..ec63749fa912 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -600,10 +600,11 @@ dtb-$(CONFIG_TARGET_SL28) += fsl-ls1028a-kontron-sl28.dtb \ dtb-$(CONFIG_TARGET_TEN64) += fsl-ls1088a-ten64.dtb -dtb-$(CONFIG_TARGET_DRAGONBOARD410C) += dragonboard410c.dtb -dtb-$(CONFIG_TARGET_DRAGONBOARD820C) += dragonboard820c.dtb -dtb-$(CONFIG_TARGET_STARQLTECHN) += starqltechn.dtb -dtb-$(CONFIG_TARGET_QCS404EVB) += qcs404-evb.dtb +dtb-$(CONFIG_ARCH_SNAPDRAGON) += dragonboard410c.dtb \ + dragonboard820c.dtb \ + dragonboard845c.dtb \ + starqltechn.dtb \ + qcs404-evb.dtb dtb-$(CONFIG_TARGET_STEMMY)
[PATCH 12/21] board: dragonboard820c: use LINUX_KERNEL_IMAGE_HEADER
db820c predated support for prepending the kernel image header
automatically, drop it's custom linker script and head.S in favour of
this generic support.
Signed-off-by: Caleb Connolly
---
arch/arm/mach-snapdragon/Kconfig | 1 +
board/qualcomm/dragonboard820c/Makefile | 1 -
board/qualcomm/dragonboard820c/head.S | 33 -
board/qualcomm/dragonboard820c/u-boot.lds | 111 --
4 files changed, 1 insertion(+), 145 deletions(-)
diff --git a/arch/arm/mach-snapdragon/Kconfig b/arch/arm/mach-snapdragon/Kconfig
index ad6671081910..f897c393464f 100644
--- a/arch/arm/mach-snapdragon/Kconfig
+++ b/arch/arm/mach-snapdragon/Kconfig
@@ -45,6 +45,7 @@ config TARGET_DRAGONBOARD410C
config TARGET_DRAGONBOARD820C
bool "96Boards Dragonboard 820C"
+ select LINUX_KERNEL_IMAGE_HEADER
imply CLK_QCOM_APQ8096
imply PINCTRL_QCOM_APQ8096
imply BUTTON_QCOM_PMIC
diff --git a/board/qualcomm/dragonboard820c/Makefile
b/board/qualcomm/dragonboard820c/Makefile
index 643311f5b3ba..2ae6d16364aa 100644
--- a/board/qualcomm/dragonboard820c/Makefile
+++ b/board/qualcomm/dragonboard820c/Makefile
@@ -3,4 +3,3 @@
# (C) Copyright 2017 Jorge Ramirez-Ortiz
obj-y := dragonboard820c.o
-extra-y += head.o
diff --git a/board/qualcomm/dragonboard820c/head.S
b/board/qualcomm/dragonboard820c/head.S
deleted file mode 100644
index b052a858fd32..
--- a/board/qualcomm/dragonboard820c/head.S
+++ /dev/null
@@ -1,33 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * ARM64 header for proper chain-loading with Little Kernel.
- *
- * Little Kernel shipped with Dragonboard820C boots standard Linux images for
- * ARM64. This file adds header that is required to boot U-Boot properly.
- *
- * For details see:
- * https://www.kernel.org/doc/Documentation/arm64/booting.txt
- *
- * (C) Copyright 2015 Mateusz Kulikowski
- */
-
-#include
-
-/*
- * per document in linux/Doc/arm64/booting.text
- */
-.global _arm64_header
-_arm64_header:
- b _start
- .word 0
- .quad CONFIG_TEXT_BASE-PHYS_SDRAM_1 /* Image load offset, LE */
- .quad 0/* Effective size of kernel image, little-endian */
- .quad 0/* kernel flags, little-endian */
- .quad 0/* reserved */
- .quad 0/* reserved */
- .quad 0/* reserved */
- .byte 0x41 /* Magic number, "ARM\x64" */
- .byte 0x52
- .byte 0x4d
- .byte 0x64
- .word 0/* reserved (used for PE COFF offset) */
diff --git a/board/qualcomm/dragonboard820c/u-boot.lds
b/board/qualcomm/dragonboard820c/u-boot.lds
deleted file mode 100644
index 5251b59fbe76..
--- a/board/qualcomm/dragonboard820c/u-boot.lds
+++ /dev/null
@@ -1,111 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Override linker script for fastboot-readable images
- *
- * (C) Copyright 2015 Mateusz Kulikowski
- *
- * Based on arch/arm/cpu/armv8/u-boot.lds (Just add header)
- */
-
-OUTPUT_FORMAT("elf64-littleaarch64", "elf64-littleaarch64",
"elf64-littleaarch64")
-OUTPUT_ARCH(aarch64)
-ENTRY(_arm64_header)
-SECTIONS
-{
- . = 0x;
-
- . = ALIGN(8);
- .text :
- {
- *(.__image_copy_start)
- board/qualcomm/dragonboard820c/head.o (.text*)
- CPUDIR/start.o (.text*)
- }
-
- /* This needs to come before *(.text*) */
- .efi_runtime : {
-__efi_runtime_start = .;
- *(.text.efi_runtime*)
- *(.rodata.efi_runtime*)
- *(.data.efi_runtime*)
-__efi_runtime_stop = .;
- }
-
- .text_rest :
- {
- *(.text*)
- }
-
- . = ALIGN(8);
- .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
-
- . = ALIGN(8);
- .data : {
- *(.data*)
- }
-
- . = ALIGN(8);
-
- . = .;
-
- . = ALIGN(8);
- __u_boot_list : {
- KEEP(*(SORT(__u_boot_list*)));
- }
-
- . = ALIGN(8);
-
- .efi_runtime_rel : {
-__efi_runtime_rel_start = .;
- *(.rel*.efi_runtime)
- *(.rel*.efi_runtime.*)
-__efi_runtime_rel_stop = .;
- }
-
- . = ALIGN(8);
-
- .image_copy_end :
- {
- *(.__image_copy_end)
- }
-
- . = ALIGN(8);
-
- .rel_dyn_start :
- {
- *(.__rel_dyn_start)
- }
-
- .rela.dyn : {
- *(.rela*)
- }
-
- .rel_dyn_end :
- {
- *(.__rel_dyn_end)
- }
-
- _end = .;
-
- . = ALIGN(8);
-
- .bss_start : {
- KEEP(*(.__bss_start));
- }
-
- .bss : {
- *(.bss*)
-. = ALIGN(8);
- }
-
- .bss_end : {
- KEEP(*(.__bss_end));
- }
-
- /DISCARD/ : { *(.dynsym) }
- /DISCARD/ : { *(.dynstr*) }
- /DISCARD/ : {
[PATCH 11/21] board: dragonboard410c: import board code from mach-snapdragon
Some of the db410c board support code was written to be generic and
placed in mach-snapdragon. However, as the db410c is the only board
using this, move the code out of mach-snapdragon. This makes is more
obvious what code is relevant for which targets and helps tidy things up
a little more.
Signed-off-by: Caleb Connolly
---
arch/arm/mach-snapdragon/Makefile | 2 -
arch/arm/mach-snapdragon/include/mach/dram.h | 12 -
arch/arm/mach-snapdragon/misc.c| 55 --
board/qualcomm/dragonboard410c/Makefile| 3 +-
board/qualcomm/dragonboard410c/dragonboard410c.c | 4 +-
.../qualcomm/dragonboard410c/misc.c| 51 +++-
.../mach => board/qualcomm/dragonboard410c}/misc.h | 1 +
7 files changed, 54 insertions(+), 74 deletions(-)
diff --git a/arch/arm/mach-snapdragon/Makefile
b/arch/arm/mach-snapdragon/Makefile
index 3a3a297c1768..d02432df8b04 100644
--- a/arch/arm/mach-snapdragon/Makefile
+++ b/arch/arm/mach-snapdragon/Makefile
@@ -6,6 +6,4 @@ obj-$(CONFIG_SDM845) += sysmap-sdm845.o
obj-$(CONFIG_SDM845) += init_sdm845.o
obj-$(CONFIG_TARGET_DRAGONBOARD820C) += sysmap-apq8096.o
obj-$(CONFIG_TARGET_DRAGONBOARD410C) += sysmap-apq8016.o
-obj-y += misc.o
-obj-y += dram.o
obj-$(CONFIG_TARGET_QCS404EVB) += sysmap-qcs404.o
diff --git a/arch/arm/mach-snapdragon/include/mach/dram.h
b/arch/arm/mach-snapdragon/include/mach/dram.h
deleted file mode 100644
index 0a9eedda414c..
--- a/arch/arm/mach-snapdragon/include/mach/dram.h
+++ /dev/null
@@ -1,12 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Snapdragon DRAM
- * Copyright (C) 2018 Ramon Fried
- */
-
-#ifndef DRAM_H
-#define DRAM_H
-
-int msm_fixup_memory(void *blob);
-
-#endif
diff --git a/arch/arm/mach-snapdragon/misc.c b/arch/arm/mach-snapdragon/misc.c
deleted file mode 100644
index 7d452f4529b7..
--- a/arch/arm/mach-snapdragon/misc.c
+++ /dev/null
@@ -1,55 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Miscellaneous Snapdragon functionality
- *
- * (C) Copyright 2018 Ramon Fried
- *
- */
-
-#include
-#include
-#include
-#include
-
-/* UNSTUFF_BITS macro taken from Linux Kernel: drivers/mmc/core/sd.c */
-#define UNSTUFF_BITS(resp, start, size) \
- ({ \
- const int __size = size; \
- const u32 __mask = (__size < 32 ? 1 << __size : 0) - 1; \
- const int __off = 3 - ((start) / 32); \
- const int __shft = (start) & 31; \
- u32 __res; \
- \
- __res = resp[__off] >> __shft; \
- if (__size + __shft > 32) \
- __res |= resp[__off - 1] << ((32 - __shft) % 32); \
- __res & __mask; \
- })
-
-u32 msm_board_serial(void)
-{
- struct mmc *mmc_dev;
-
- mmc_dev = find_mmc_device(0);
- if (!mmc_dev)
- return 0;
-
- if (mmc_init(mmc_dev))
- return 0;
-
- return UNSTUFF_BITS(mmc_dev->cid, 16, 32);
-}
-
-void msm_generate_mac_addr(u8 *mac)
-{
- /* use locally adminstrated pool */
- mac[0] = 0x02;
- mac[1] = 0x00;
-
- /*
-* Put the 32-bit serial number in the last 32-bit of the MAC address.
-* Use big endian order so it is consistent with the serial number
-* written as a hexadecimal string, e.g. 0x1234abcd -> 02:00:12:34:ab:cd
-*/
- put_unaligned_be32(msm_board_serial(), [2]);
-}
diff --git a/board/qualcomm/dragonboard410c/Makefile
b/board/qualcomm/dragonboard410c/Makefile
index 1b99c8b0efef..a3ae1a5f9136 100644
--- a/board/qualcomm/dragonboard410c/Makefile
+++ b/board/qualcomm/dragonboard410c/Makefile
@@ -2,4 +2,5 @@
#
# (C) Copyright 2015 Mateusz Kulikowski
-obj-y := dragonboard410c.o
+obj-y += dragonboard410c.o
+obj-y += misc.o
diff --git a/board/qualcomm/dragonboard410c/dragonboard410c.c
b/board/qualcomm/dragonboard410c/dragonboard410c.c
index 350e0e9e20aa..3ee7e806918b 100644
--- a/board/qualcomm/dragonboard410c/dragonboard410c.c
+++ b/board/qualcomm/dragonboard410c/dragonboard410c.c
@@ -17,10 +17,10 @@
#include
#include
#include
-#include
-#include
#include
+#include "misc.h"
+
DECLARE_GLOBAL_DATA_PTR;
int dram_init(void)
diff --git a/arch/arm/mach-snapdragon/dram.c
b/board/qualcomm/dragonboard410c/misc.c
similarity index 64%
rename from arch/arm/mach-snapdragon/dram.c
rename to board/qualcomm/dragonboard410c/misc.c
index 499dfdf0da6e..27d51ef78914 100644
--- a/arch/arm/mach-snapdragon/dram.c
+++ b/board/qualcomm/dragonboard410c/misc.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Onboard memory detection for Snapdragon boards
+ * Miscellaneous Snapdragon functionality
*
* (C) Copyright 2018 Ramon Fried
*
@@ -9,10 +9,56 @@
#include
#include
#include
+#include
#include
#include
#include
-#include
+#include
+
+#include "misc.h"
+
+/* UNSTUFF_BITS macro taken from Linux
[PATCH 10/21] dts: dragonboard410c: fix compatible and clocks
Use the root compatible strings from upstream Linux, add missing
'#clock-cells' property to the gcc node.
Adjust some of the msm8916/apq8016 drivers to use the correct upstream
compatible properties and DT bindings.
Signed-off-by: Caleb Connolly
---
arch/arm/dts/dragonboard410c.dts | 7 +-
doc/device-tree-bindings/usb/ehci-msm.txt| 10 --
drivers/clk/qcom/clock-apq8016.c | 7 +-
drivers/phy/qcom/msm8916-usbh-phy.c | 2 +-
drivers/pinctrl/qcom/pinctrl-apq8016.c | 2 +-
drivers/usb/host/ehci-msm.c | 2 +-
include/dt-bindings/clock/qcom,gcc-msm8916.h | 179 +++
7 files changed, 190 insertions(+), 19 deletions(-)
diff --git a/arch/arm/dts/dragonboard410c.dts b/arch/arm/dts/dragonboard410c.dts
index c395e6cc0427..a42b68fee8c0 100644
--- a/arch/arm/dts/dragonboard410c.dts
+++ b/arch/arm/dts/dragonboard410c.dts
@@ -12,7 +12,7 @@
/ {
model = "Qualcomm Technologies, Inc. Dragonboard 410c";
- compatible = "qcom,dragonboard", "qcom,apq8016-sbc";
+ compatible = "qcom,apq8016-sbc", "qcom,apq8016";
qcom,msm-id = <0xce 0x0 0xf8 0x0 0xf9 0x0 0xfa 0x0 0xf7 0x0>;
qcom,board-id = <0x10018 0x0>;
#address-cells = <0x2>;
@@ -79,6 +79,7 @@
reg = <0x180 0x8>;
#address-cells = <0x1>;
#size-cells = <0x0>;
+ #clock-cells = <0x1>;
};
serial@78b {
@@ -91,13 +92,13 @@
};
ehci@78d9000 {
- compatible = "qcom,ehci-host";
+ compatible = "qcom,ci-hdrc";
reg = <0x78d9000 0x400>;
phys = <_phy>;
};
ehci_phy: ehci_phy@78d9000 {
- compatible = "qcom,apq8016-usbphy";
+ compatible = "qcom,usb-hs-phy-msm8916";
reg = <0x78d9000 0x400>;
#phy-cells = <0>;
};
diff --git a/doc/device-tree-bindings/usb/ehci-msm.txt
b/doc/device-tree-bindings/usb/ehci-msm.txt
deleted file mode 100644
index 205bb07220fb..
--- a/doc/device-tree-bindings/usb/ehci-msm.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-Chipidea EHCI controller (part of OTG controller) used on Qualcomm devices.
-
-Required properties:
-- compatible: must be "qcom,ehci-host"
-- reg: start address and size of the registers
-
-ehci@78d9000 {
- compatible = "qcom,ehci-host";
- reg = <0x78d9000 0x400>;
-};
diff --git a/drivers/clk/qcom/clock-apq8016.c b/drivers/clk/qcom/clock-apq8016.c
index 0af7191cff52..9de0ad5ed32d 100644
--- a/drivers/clk/qcom/clock-apq8016.c
+++ b/drivers/clk/qcom/clock-apq8016.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "clock-qcom.h"
@@ -125,13 +126,13 @@ static ulong apq8016_clk_set_rate(struct clk *clk, ulong
rate)
struct msm_clk_priv *priv = dev_get_priv(clk->dev);
switch (clk->id) {
- case 0: /* SDC1 */
+ case GCC_SDCC1_APPS_CLK: /* SDC1 */
return clk_init_sdc(priv, 0, rate);
break;
- case 1: /* SDC2 */
+ case GCC_SDCC2_APPS_CLK: /* SDC2 */
return clk_init_sdc(priv, 1, rate);
break;
- case 4: /* UART2 */
+ case GCC_BLSP1_UART2_APPS_CLK: /* UART2 */
return clk_init_uart(priv);
break;
default:
diff --git a/drivers/phy/qcom/msm8916-usbh-phy.c
b/drivers/phy/qcom/msm8916-usbh-phy.c
index 7c9d030a4d8a..b63115036ad9 100644
--- a/drivers/phy/qcom/msm8916-usbh-phy.c
+++ b/drivers/phy/qcom/msm8916-usbh-phy.c
@@ -96,7 +96,7 @@ static struct phy_ops msm_phy_ops = {
};
static const struct udevice_id msm_phy_ids[] = {
- { .compatible = "qcom,apq8016-usbphy" },
+ { .compatible = "qcom,usb-hs-phy-msm8916" },
{ }
};
diff --git a/drivers/pinctrl/qcom/pinctrl-apq8016.c
b/drivers/pinctrl/qcom/pinctrl-apq8016.c
index 8149ffd83cc4..8e698085d78b 100644
--- a/drivers/pinctrl/qcom/pinctrl-apq8016.c
+++ b/drivers/pinctrl/qcom/pinctrl-apq8016.c
@@ -29,7 +29,7 @@ static const char * const msm_pinctrl_pins[] = {
};
static const struct pinctrl_function msm_pinctrl_functions[] = {
- {"blsp1_uart", 2},
+ {"blsp_uart2", 2},
};
static const char *apq8016_get_function_name(struct udevice *dev,
diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index dd0d153500cb..46910159e844 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -132,7 +132,7 @@ void ci_init_after_reset(struct ehci_ctrl *ctrl)
#endif
static const struct udevice_id ehci_usb_ids[] = {
- { .compatible = "qcom,ehci-host", },
+ { .compatible = "qcom,ci-hdrc", },
{ }
};
diff --git a/include/dt-bindings/clock/qcom,gcc-msm8916.h
b/include/dt-bindings/clock/qcom,gcc-msm8916.h
new file
[PATCH 08/21] serial: msm: fix clock handling
Use the modern helpers to fetch the clock and use the correct property
("clocks" instead of "clock")
Signed-off-by: Caleb Connolly
---
arch/arm/dts/dragonboard410c.dts | 3 ++-
arch/arm/dts/dragonboard820c.dts | 3 ++-
drivers/serial/serial_msm.c | 24 +---
3 files changed, 9 insertions(+), 21 deletions(-)
diff --git a/arch/arm/dts/dragonboard410c.dts b/arch/arm/dts/dragonboard410c.dts
index 02c824d0226c..c395e6cc0427 100644
--- a/arch/arm/dts/dragonboard410c.dts
+++ b/arch/arm/dts/dragonboard410c.dts
@@ -84,7 +84,8 @@
serial@78b {
compatible = "qcom,msm-uartdm-v1.4";
reg = <0x78b 0x200>;
- clock = < 4>;
+ clocks = < 4>;
+ clock-names = "core";
pinctrl-names = "uart";
pinctrl-0 = <_uart>;
};
diff --git a/arch/arm/dts/dragonboard820c.dts b/arch/arm/dts/dragonboard820c.dts
index 146a0af8aafe..86b7f83d36d6 100644
--- a/arch/arm/dts/dragonboard820c.dts
+++ b/arch/arm/dts/dragonboard820c.dts
@@ -78,7 +78,8 @@
blsp2_uart2: serial@75b {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
reg = <0x75b 0x1000>;
- clock = < 4>;
+ clocks = < 4>;
+ clock-names = "core";
pinctrl-names = "uart";
pinctrl-0 = <_uart>;
};
diff --git a/drivers/serial/serial_msm.c b/drivers/serial/serial_msm.c
index 6a4d6f1d96fd..d58f9d85d38c 100644
--- a/drivers/serial/serial_msm.c
+++ b/drivers/serial/serial_msm.c
@@ -160,29 +160,14 @@ static int msm_uart_clk_init(struct udevice *dev)
{
uint clk_rate = fdtdec_get_uint(gd->fdt_blob, dev_of_offset(dev),
"clock-frequency", 115200);
- uint clkd[2]; /* clk_id and clk_no */
- int clk_offset;
- struct udevice *clk_dev;
struct clk clk;
int ret;
- ret = fdtdec_get_int_array(gd->fdt_blob, dev_of_offset(dev), "clock",
- clkd, 2);
- if (ret)
- return ret;
-
- clk_offset = fdt_node_offset_by_phandle(gd->fdt_blob, clkd[0]);
- if (clk_offset < 0)
- return clk_offset;
-
- ret = uclass_get_device_by_of_offset(UCLASS_CLK, clk_offset, _dev);
- if (ret)
- return ret;
-
- clk.id = clkd[1];
- ret = clk_request(clk_dev, );
- if (ret < 0)
+ ret = clk_get_by_name(dev, "core", );
+ if (ret < 0) {
+ pr_warn("%s: Failed to get clock: %d\n", __func__, ret);
return ret;
+ }
ret = clk_set_rate(, clk_rate);
clk_free();
@@ -252,6 +237,7 @@ U_BOOT_DRIVER(serial_msm) = {
.priv_auto = sizeof(struct msm_serial_data),
.probe = msm_serial_probe,
.ops= _serial_ops,
+ .flags = DM_FLAG_PRE_RELOC,
};
#ifdef CONFIG_DEBUG_UART_MSM
--
2.42.1
[PATCH 09/21] configs: add dragonboard410c_chainloaded_defconfig
Revive support for booting db410c using the Linux kernel header, this allows for testing the board more easily via `fastboot`. Signed-off-by: Caleb Connolly --- board/qualcomm/dragonboard410c/MAINTAINERS| 1 + configs/dragonboard410c_chainloaded_defconfig | 75 +++ 2 files changed, 76 insertions(+) diff --git a/board/qualcomm/dragonboard410c/MAINTAINERS b/board/qualcomm/dragonboard410c/MAINTAINERS index e78f5b2d6421..653b91b44377 100644 --- a/board/qualcomm/dragonboard410c/MAINTAINERS +++ b/board/qualcomm/dragonboard410c/MAINTAINERS @@ -4,4 +4,5 @@ S: Maintained F: board/qualcomm/dragonboard410c/ F: include/configs/dragonboard410c.h F: configs/dragonboard410c_defconfig +F: configs/dragonboard410c_chainloaded_defconfig F: doc/board/qualcomm/dragonboard410c.rst diff --git a/configs/dragonboard410c_chainloaded_defconfig b/configs/dragonboard410c_chainloaded_defconfig new file mode 100644 index ..d6860f546e9e --- /dev/null +++ b/configs/dragonboard410c_chainloaded_defconfig @@ -0,0 +1,75 @@ +CONFIG_ARM=y +CONFIG_COUNTER_FREQUENCY=1900 +CONFIG_ARCH_SNAPDRAGON=y +CONFIG_TARGET_QCOM=y +CONFIG_POSITION_INDEPENDENT=y +CONFIG_SYS_MALLOC_LEN=0x802000 +CONFIG_ENV_SIZE=0x2000 +CONFIG_ENV_OFFSET=0x0 +CONFIG_DEFAULT_DEVICE_TREE="dragonboard410c" +CONFIG_SYS_BOARD="dragonboard410c" +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_IDENT_STRING="\nQualcomm-DragonBoard 410C" +CONFIG_SYS_LOAD_ADDR=0x8008 +CONFIG_REMAKE_ELF=y +# CONFIG_ANDROID_BOOT_IMAGE is not set +CONFIG_FIT=y +CONFIG_DISTRO_DEFAULTS=y +CONFIG_OF_BOARD_SETUP=y +CONFIG_USE_PREBOOT=y +# CONFIG_DISPLAY_CPUINFO is not set +# CONFIG_DISPLAY_BOARDINFO is not set +CONFIG_MISC_INIT_R=y +CONFIG_LINUX_KERNEL_IMAGE_HEADER=y +CONFIG_SYS_PROMPT="dragonboard410c => " +CONFIG_SYS_MAXARGS=64 +CONFIG_SYS_CBSIZE=512 +CONFIG_SYS_PBSIZE=548 +# CONFIG_CMD_IMI is not set +CONFIG_CMD_MD5SUM=y +CONFIG_CMD_MEMINFO=y +CONFIG_CMD_GPIO=y +CONFIG_CMD_GPT=y +CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y +CONFIG_BOOTP_BOOTFILESIZE=y +CONFIG_CMD_CACHE=y +CONFIG_CMD_TIMER=y +CONFIG_ENV_IS_IN_MMC=y +CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_SYS_MMC_ENV_PART=2 +CONFIG_CLK=y +CONFIG_CLK_QCOM_APQ8016=y +CONFIG_USB_FUNCTION_FASTBOOT=y +CONFIG_FASTBOOT_BUF_ADDR=0x9100 +CONFIG_FASTBOOT_FLASH=y +CONFIG_FASTBOOT_FLASH_MMC_DEV=0 +CONFIG_MSM_GPIO=y +CONFIG_QCOM_PMIC_GPIO=y +CONFIG_LED=y +CONFIG_LED_GPIO=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_MSM=y +CONFIG_PHY=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_QCOM_APQ8016=y +CONFIG_PINCONF=y +CONFIG_DM_PMIC=y +CONFIG_PMIC_QCOM=y +CONFIG_MSM_SERIAL=y +CONFIG_SPMI_MSM=y +CONFIG_BUTTON_QCOM_PMIC=y +CONFIG_USB=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_EHCI_MSM=y +CONFIG_USB_ULPI_VIEWPORT=y +CONFIG_USB_ULPI=y +CONFIG_USB_HOST_ETHER=y +CONFIG_USB_ETHER_ASIX=y +CONFIG_USB_ETHER_ASIX88179=y +CONFIG_USB_ETHER_MCS7830=y +CONFIG_USB_ETHER_SMSC95XX=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_VENDOR_NUM=0x18d1 +CONFIG_USB_GADGET_PRODUCT_NUM=0xd00d +CONFIG_CI_UDC=y -- 2.42.1
