Re: [PATCH v1 15/19] ARM: tegra: board2: add generic late init
24 серпня 2023 р. 02:57:34 GMT+03:00, Simon Glass
написав(-ла):
>Hi Svyatoslav,
>
>On Tue, 22 Aug 2023 at 05:25, Svyatoslav Ryhel wrote:
>>
>> Board specific late init allows vendors to set up different device
>> or board specific env variables (like serial number, platform name).
>> In case this information is missing, u-boot will lack info regards
>> serial or platform.
>>
>> To avoid this prior nvidia_board_late_init internal generic function
>> is called which fills required data. In this case platform name is
>> obtained from get_chip and serialno is filled with SoC id.
>>
>> Though SoC id is not dedicated to be devices serial but it fits well
>> in case of restriction of data about device and since SoC is basically
>> a main chip of the device.
>>
>> Tested-by: Andreas Westman Dorcsak # ASUS Transformers
>> Tested-by: Svyatoslav Ryhel # Nvidia Tegratab
>> Signed-off-by: Svyatoslav Ryhel
>> ---
>> arch/arm/mach-tegra/board2.c | 43
>> 1 file changed, 43 insertions(+)
>>
>> diff --git a/arch/arm/mach-tegra/board2.c b/arch/arm/mach-tegra/board2.c
>> index 981768bb0e..ee69cb657a 100644
>> --- a/arch/arm/mach-tegra/board2.c
>> +++ b/arch/arm/mach-tegra/board2.c
>> @@ -26,6 +26,10 @@
>> #include
>> #include
>> #include
>> +#ifndef CONFIG_TEGRA186
>> +#include
>> +#include
>> +#endif
>> #if IS_ENABLED(CONFIG_TEGRA_CLKRST)
>> #include
>> #endif
>> @@ -256,6 +260,37 @@ int board_early_init_f(void)
>> }
>> #endif /* EARLY_INIT */
>>
>> +#ifndef CONFIG_TEGRA186
>> +static void nvidia_board_late_init_generic(void)
>> +{
>> + char serialno_str[17];
>> +
>> + /* Set chip id as serialno */
>> + sprintf(serialno_str, "%016llx", tegra_chip_uid());
>> + env_set("serial#", serialno_str);
>> +
>> + switch (tegra_get_chip()) {
>> + case CHIPID_TEGRA20:
>> + env_set("platform", "Tegra 2 T20");
>> + break;
>> + case CHIPID_TEGRA30:
>> + env_set("platform", "Tegra 3 T30");
>> + break;
>> + case CHIPID_TEGRA114:
>> + env_set("platform", "Tegra 4 T114");
>> + break;
>> + case CHIPID_TEGRA124:
>> + env_set("platform", "Tegra K1 T124");
>> + break;
>> + case CHIPID_TEGRA210:
>> + env_set("platform", "Tegra X1 T210");
>> + break;
>> + default:
>> + return;
>> + }
>> +}
>> +#endif
>> +
>> int board_late_init(void)
>> {
>> #if defined(CONFIG_TEGRA_SUPPORT_NON_SECURE)
>> @@ -268,6 +303,14 @@ int board_late_init(void)
>> #endif
>> start_cpu_fan();
>> cboot_late_init();
>> +
>> + /*
>> +* Perform generic env setup in case
>> +* vendor does not provide it.
>> +*/
>> +#ifndef CONFIG_TEGRA186
>> + nvidia_board_late_init_generic();
>> +#endif
>> nvidia_board_late_init();
>>
>> return 0;
>> --
>> 2.39.2
>>
>
>This would be better done with events. I just sent a series that
>converts board_late_init() to use events [1] and with that you can add
>as many 'spy' functions as you like [2].
This is definitely a nice suggestion, but I would rather dedicate this
convertion a separate patchset since it will affect multiple files and
functions across all mach-terga.
Best regards,
Svyatoslav R.
>Regards,
>Simon
>
>[1] https://patchwork.ozlabs.org/project/uboot/list/?series=369742
>[2] https://u-boot.readthedocs.io/en/latest/develop/event.html
Re: [PATCH 1/2] cmd: efidebug: add uri device path
On 8/23/23 10:37, Masahisa Kojima wrote:
This adds the URI device path option for 'boot add' subcommand.
User can add the URI load option for downloading ISO image file
or EFI application through network(e.g. HTTP).
Signed-off-by: Masahisa Kojima
---
cmd/efidebug.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index 0be3af3e76..62f867df2a 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -829,6 +829,44 @@ static int do_efi_boot_add(struct cmd_tbl *cmdtp, int flag,
argc -= 1;
argv += 1;
break;
+ case 'u':
+ {
+ char *pos;
+ int uridp_len;
+ struct efi_device_path_uri *uridp;
+
+ if (argc < 3 || lo.label) {
+ r = CMD_RET_USAGE;
+ goto out;
+ }
+ id = (int)hextoul(argv[1], );
+ if (*endp != '\0' || id > 0x)
+ return CMD_RET_USAGE;
+
+ efi_create_indexed_name(var_name16, sizeof(var_name16),
+ "Boot", id);
+
+ label = efi_convert_string(argv[2]);
+ if (!label)
+ return CMD_RET_FAILURE;
+ lo.label = label;
+
+ uridp_len = sizeof(struct efi_device_path) +
strlen(argv[3]) + 1; > +fp_free = efi_alloc(uridp_len +
sizeof(END));
+ uridp = (struct efi_device_path_uri *)fp_free;
+ uridp->dp.type = DEVICE_PATH_TYPE_MESSAGING_DEVICE;
+ uridp->dp.sub_type = DEVICE_PATH_SUB_TYPE_MSG_URI;
+ uridp->dp.length = uridp_len;
+ strcpy(uridp->uri, argv[3]);
This assumes that argv[3] is a valid URI.
Would it be preferable to validate that the string is percent encoded,
conforms to RFC 3986, and contains a supported scheme, an authority, and
a path?
As a user I would like related errors to be caught at entry and not at
runtime.
Best regards
Heinrich
+ pos = (char *)uridp + uridp_len;
+ memcpy(pos, , sizeof(END));
+ fp_size += uridp_len + sizeof(END);
+ file_path = (struct efi_device_path *)uridp;
+ argc -= 3;
+ argv += 3;
+ break;
+ }
+
default:
r = CMD_RET_USAGE;
goto out;
@@ -1492,6 +1530,7 @@ static char efidebug_help_text[] =
" -b|-B[:] \n"
" -i|-I [:] \n"
" (-b, -i for short form device path)\n"
+ " -u \n"
" -s ''\n"
"efidebug boot rm [ [ [...]]]\n"
" - delete UEFI Boot variables\n"
Re: [PATCH V5 00/17] board: ti: Add support for BeaglePlay
On 22:10-20230823, Nishanth Menon wrote: > Add support for BeaglePlay - rev 5 Oopsie.. > > Full series: > https://github.com/nmenon/fix-k3-dt-u-boot/commits/beagleplay-v4.2 ^^ Wrong link! That line wasn't supposed to be in this email :( > Instead the following should have been: [...] > Complete code (with the tmp patch) can be found at: > https://github.com/nmenon/fix-k3-dt-u-boot/tree/beagleplay-v5 [...] Sorry for the spam.. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v2 3/8] tests: gpt: Remove test order dependency
On Wed, Aug 23, 2023 at 5:59 PM Simon Glass wrote: > > Hi Joshua, > > On Wed, 23 Aug 2023 at 10:48, Joshua Watt wrote: > > > > Re-create a clean disk image for each test to prevent modifications from > > one test affecting another > > > > Signed-off-by: Joshua Watt > > --- > > test/py/tests/test_gpt.py | 20 > > 1 file changed, 8 insertions(+), 12 deletions(-) > > I suppose this is OK, but is it expensive in terms of time? There wasn't a noticeable slowdown in test execution time on my (admittedly powerful) workstation. > > Reviewed-by: Simon Glass > > Regards, > Simon
Re: [PATCH V4 8/8] doc: board: ti: Add BeaglePlay documentation
On 21:01-20230823, Simon Glass wrote: > Hi Nishanth, > > On Wed, 23 Aug 2023 at 18:18, Nishanth Menon wrote: > > > > On 17:57-20230823, Simon Glass wrote: > > [...] > > > > This is how we have a common bit of rST for how to build N boards, > > > > without having to do a literal copy and paste N times. > > > > > > How about using this? > > > > > > https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#substitution-definitions > > > > I was not able to succeed with complex includes such as: > > https://github.com/u-boot/u-boot/blob/master/doc/board/ti/am62x_sk.rst?plain=1#L89 > > > > am62x complete build procedure defined once and reused in other am62x > > platforms.. But the am62x build procedure itself is reused from common > > k3 build steps. > > I followed through these instructions. I find the env vars quite > confusing, since I don't really know what it is doing. It feels like a > script: > > do $a $b $c > do $f $e > > it is pretty hard to follow. I think it would be better to write > everything out in full for each board, like rockchip does. Unfortunately, this is a few major steps that is repeated for (currently): AM62x SK Toradex Verdin (pending: beagleplay - ) (once all the dust clears up, hopefully phytec) SK-LP I have no reasonable way to offer to keep them all in sync. https://libera.irclog.whitequark.org/u-boot/2023-07-26#34662854; is kind of why I went down this path.S > > Some other minor feedback: > > - The 'make' lines should really have -j $(nproc) added Different styles of shells.. > - The $ signs at the start of each command in the docs are a pain > since it stops me copying the commands into the terminal - can you > remove them? hehe.. "dont" let people blindly copy paste without understanding what is going on argument? If folks are OK, I sure can send a different patch series for that.. (or maybe motivate someone to do that instead of me ;)) > - It doesn't build for me: > > BINMAN .binman_stamp > Image 'ti-dm' is missing external blobs and is non-functional: blob-ext > > /binman/ti-dm/blob-ext > (ti-dm/am62xx/ipc_echo_testb_mcu1_0_release_strip.xer5f): >Missing blob > > Some images are invalid > make[1]: *** > [/scratch/sglass/cosarm/src/third_party/u-boot/files/Makefile:1115: > .binman_stamp] Error 103 > make[1]: Leaving directory '/tmp/b/play' > make: *** [Makefile:177: sub-make] Error 2 ^^ Neha: This is what I was complaining about. https://u-boot.readthedocs.io/en/latest/board/ti/am62x_sk.html?highlight=am62#sources source: https://git.ti.com/git/processor-firmware/ti-linux-firmware.git is missing, we never used to break build previously binman converted now does. I am wondering if I need to explicitly call out git clone instructions out.. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 6/6] stm32mp15: Use u-boot-spl-stm32.bin instead of u-boot-spl.stm32
On 8/24/23 05:02, Simon Glass wrote: A '.stm32' extension is not allowed anymore, so change it. Why? This will likely break a huge amount of scripts, I'm tempted to NAK it unless there is a very good reason.
[PATCH V5 17/17] doc: board: ti: Add BeaglePlay documentation
Add base documentation for BeaglePlay Reviewed-by: Mattijs Korpershoek Signed-off-by: Nishanth Menon --- Cc: Heinrich Schuchardt Changes Since V4: - Just the verbage comment from Simon V4: https://lore.kernel.org/r/20230822184135.2328409-9...@ti.com V3: https://lore.kernel.org/all/20230815164440.2713726-5...@ti.com/ V2: https://lore.kernel.org/u-boot/20230727234446.3651836-5...@ti.com/ V1: https://lore.kernel.org/all/20230725185253.2123433-7...@ti.com/ doc/board/ti/am62x_beagleplay.rst| 256 ++ doc/board/ti/img/beagleplay_emmc.svg | 697 +++ doc/board/ti/k3.rst | 1 + 3 files changed, 954 insertions(+) create mode 100644 doc/board/ti/am62x_beagleplay.rst create mode 100644 doc/board/ti/img/beagleplay_emmc.svg diff --git a/doc/board/ti/am62x_beagleplay.rst b/doc/board/ti/am62x_beagleplay.rst new file mode 100644 index ..8fbeb715c4a8 --- /dev/null +++ b/doc/board/ti/am62x_beagleplay.rst @@ -0,0 +1,256 @@ +.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause +.. sectionauthor:: Nishanth Menon + +AM62x Beagleboard.org Beagleplay + + +Introduction: +- + +BeagleBoard.org BeaglePlay is an easy to use, affordable open source +hardware single board computer based on the Texas Instruments AM625 +SoC that allows you to create connected devices that work even at long +distances using IEEE 802.15.4g LR-WPAN and IEEE 802.3cg 10Base-T1L. +Expansion is provided over open standards based mikroBUS, Grove and +QWIIC headers among other interfaces. + +Further information can be found at: + +* Product Page: https://beagleplay.org/ +* Hardware documentation: https://git.beagleboard.org/beagleplay/beagleplay + +Boot Flow: +-- +Below is the pictorial representation of boot flow: + +.. image:: img/boot_diagram_k3_current.svg + :alt: Boot flow diagram + +- On this platform, 'TI Foundational Security' (TIFS) functions as the + security enclave master while 'Device Manager' (DM), also known as the + 'TISCI server' in "TI terminology", offers all the essential services. + The A53 or M4F (Aux core) sends requests to TIFS/DM to accomplish these + services, as illustrated in the diagram above. + +Sources: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_boot_sources +:end-before: .. k3_rst_include_end_boot_sources + +Build procedure: + +0. Setup the environment variables: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_common_env_vars_desc +:end-before: .. k3_rst_include_end_common_env_vars_desc + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_board_env_vars_desc +:end-before: .. k3_rst_include_end_board_env_vars_desc + +Set the variables corresponding to this platform: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_common_env_vars_defn +:end-before: .. k3_rst_include_end_common_env_vars_defn +.. code-block:: bash + + $ export UBOOT_CFG_CORTEXR="am62x_evm_r5_defconfig beagleplay_r5.config" + $ export UBOOT_CFG_CORTEXA="am62x_evm_a53_defconfig beagleplay_a53.config" + $ export TFA_BOARD=lite + $ # we dont use any extra TFA parameters + $ unset TFA_EXTRA_ARGS + $ export OPTEE_PLATFORM=k3-am62x + $ export OPTEE_EXTRA_ARGS="CFG_WITH_SOFTWARE_PRNG=y" + +.. include:: am62x_sk.rst +:start-after: .. am62x_evm_rst_include_start_build_steps +:end-before: .. am62x_evm_rst_include_end_build_steps + +Target Images +-- +Copy the below images to an SD card and boot: + +* tiboot3-am62x-gp-evm.bin from R5 build as tiboot3.bin +* tispl.bin_unsigned from Cortex-A build as tispl.bin +* u-boot.img_unsigned from Cortex-A build as uboot.img + +Image formats: +-- + +- tiboot3.bin + +.. image:: img/multi_cert_tiboot3.bin.svg + :alt: tiboot3.bin image format + +- tispl.bin + +.. image:: img/dm_tispl.bin.svg + :alt: tispl.bin image format + +Flash to eMMC +- + +The eMMC layout selected is user-friendly for developers. The +boot hardware partition of the eMMC only contains the fixed-size +tiboot3.bin image. This is because the contents of the boot partitions +need to run from the SoC's internal SRAM, which remains a fixed size +constant. The other components of the boot sequence, such as tispl.bin +and u-boot.img, are located in the /BOOT partition in the User Defined +Area (UDA) hardware partition of the eMMC. These components can vary +significantly in size. The choice of keeping tiboot3.bin in boot0 or +boot1 partition depends on A/B update requirements. + +.. image:: img/beagleplay_emmc.svg + :alt: eMMC partitions and boot file organization for BeaglePlay + +The following are the steps from Linux shell to program eMMC: + +.. code-block:: bash + + # # Enable Boot0 boot + # mmc bootpart enable 1 2 /dev/mmcblk0 + # mmc bootbus set single_backward x1 x8 /dev/mmcblk0 + # mmc hwreset enable /dev/mmcblk0 + + # # Clear eMMC boot0 + # echo '0' >>
[PATCH V5 14/17] arm: dts: k3-am625-sk-binman: Add labels for unsigned binary
Add labels for unsigned binary to permit over-ride.
Reviewed-by: Mattijs Korpershoek
Signed-off-by: Nishanth Menon
---
Cc: Simon Glass
Changes since v4:
* Picked up Mattijs' Review
V4: https://lore.kernel.org/r/20230822184135.2328409-6...@ti.com
V3: https://lore.kernel.org/all/20230815164440.2713726-2...@ti.com/
V2: https://lore.kernel.org/u-boot/20230727234446.3651836-2...@ti.com/
V1: https://lore.kernel.org/all/20230725185253.2123433-3...@ti.com/
arch/arm/dts/k3-am625-sk-binman.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/k3-am625-sk-binman.dtsi
b/arch/arm/dts/k3-am625-sk-binman.dtsi
index a35d6418c25f..41277bf4bfdb 100644
--- a/arch/arm/dts/k3-am625-sk-binman.dtsi
+++ b/arch/arm/dts/k3-am625-sk-binman.dtsi
@@ -389,7 +389,7 @@
type = "flat_dt";
arch = "arm";
compression = "none";
- blob {
+ spl_am625_sk_dtb_unsigned: blob {
filename = SPL_AM625_SK_DTB;
};
};
@@ -438,7 +438,7 @@
type = "flat_dt";
arch = "arm";
compression = "none";
- blob {
+ am625_sk_dtb_unsigned: blob {
filename = AM625_SK_DTB;
};
hash {
--
2.40.0
[PATCH V5 12/17] configs: am62x_evm*: Enable EMMC_BOOT configuration
Enable EMMC boot support for AM62x evm base configuration. Reviewed-by: Mattijs Korpershoek Signed-off-by: Nishanth Menon --- Changes since V4: - Picked up Mattijs' reviewed-by V4: https://lore.kernel.org/r/20230822184135.2328409-3...@ti.com configs/am62x_evm_a53_defconfig | 1 + configs/am62x_evm_r5_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig index 1807df8bbee9..112125673699 100644 --- a/configs/am62x_evm_a53_defconfig +++ b/configs/am62x_evm_a53_defconfig @@ -70,6 +70,7 @@ CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_TI_SCI_PROTOCOL=y CONFIG_DM_MAILBOX=y CONFIG_K3_SEC_PROXY=y +CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ADMA=y CONFIG_SPL_MMC_SDHCI_ADMA=y diff --git a/configs/am62x_evm_r5_defconfig b/configs/am62x_evm_r5_defconfig index 3c5f36729842..489ee943fe31 100644 --- a/configs/am62x_evm_r5_defconfig +++ b/configs/am62x_evm_r5_defconfig @@ -92,6 +92,7 @@ CONFIG_DM_MAILBOX=y CONFIG_K3_SEC_PROXY=y CONFIG_SPL_MISC=y CONFIG_ESM_K3=y +CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ADMA=y CONFIG_SPL_MMC_SDHCI_ADMA=y -- 2.40.0
[PATCH V5 11/17] arm: mach-k3: am625_init: Convert rtc_erratumi2327_init to static
The erratum is called locally, make it static, drop the #ifdeffery since
it will only be called in R5 build and mark it potentially unused to
stop compiler screaming at us.
While at this, drop the redundant return for a void function.
Signed-off-by: Nishanth Menon
---
new patch (cleanup before modifying for adding UDA-FS)
arch/arm/mach-k3/am625_init.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm/mach-k3/am625_init.c b/arch/arm/mach-k3/am625_init.c
index 165bca6885ef..499cb57267b9 100644
--- a/arch/arm/mach-k3/am625_init.c
+++ b/arch/arm/mach-k3/am625_init.c
@@ -80,8 +80,6 @@ static __maybe_unused void enable_mcu_esm_reset(void)
writel(stat, CTRLMMR_MCU_RST_CTRL);
}
-#if defined(CONFIG_CPU_V7R)
-
/*
* RTC Erratum i2327 Workaround for Silicon Revision 1
*
@@ -94,7 +92,7 @@ static __maybe_unused void enable_mcu_esm_reset(void)
*
* https://www.ti.com/lit/er/sprz487c/sprz487c.pdf
*/
-void rtc_erratumi2327_init(void)
+static __maybe_unused void rtc_erratumi2327_init(void)
{
u32 counter;
@@ -112,9 +110,7 @@ void rtc_erratumi2327_init(void)
*/
writel(K3RTC_KICK0_UNLOCK_VALUE, REG_K3RTC_KICK0);
writel(K3RTC_KICK1_UNLOCK_VALUE, REG_K3RTC_KICK1);
- return;
}
-#endif
void board_init_f(ulong dummy)
{
--
2.40.0
[PATCH V5 05/17] configs: am62x_evm_a53_defconfig: Switch to bootstd
Switch to using bootstd. Note with this change, we will stop using distro_bootcmd and instead depend entirely on bootflow method of starting the system up. Suggested-by: Tom Rini Suggested-by: Simon Glass Signed-off-by: Nishanth Menon --- New patch (part of bootstd transition) configs/am62x_evm_a53_defconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig index d55caabe22c9..1807df8bbee9 100644 --- a/configs/am62x_evm_a53_defconfig +++ b/configs/am62x_evm_a53_defconfig @@ -28,8 +28,9 @@ CONFIG_SPL_SPI=y # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_SPL_LOAD_FIT=y CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100 -CONFIG_DISTRO_DEFAULTS=y -CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;" +CONFIG_BOOTSTD_FULL=y +CONFIG_BOOTSTD_DEFAULTS=y +CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb" CONFIG_SPL_MAX_SIZE=0x58000 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y CONFIG_SPL_BSS_START_ADDR=0x80c8 -- 2.40.0
[PATCH V5 08/17] include: env: ti: ti_common: Add a generic findfdt
ti_mmc bootmethod uses a findfdt routine that is expected to be
implemented by all platforms.
Define a default findfdt based on configured DEFAULT_DEVICE_TREE option
for u-boot. This saves duplication across multiple boards and handles
architecture folder location changes centrally.
TI ARMV7 platforms will need to override default_device_tree_subarch
in the env file to point to the appropriate platform. Note: default
"omap" is used to cater to "most common" default.
Signed-off-by: Nishanth Menon
---
New patch (part of bootstd transition)
include/env/ti/ti_common.env | 12
1 file changed, 12 insertions(+)
diff --git a/include/env/ti/ti_common.env b/include/env/ti/ti_common.env
index e87a41a6590b..322f849a5560 100644
--- a/include/env/ti/ti_common.env
+++ b/include/env/ti/ti_common.env
@@ -32,3 +32,15 @@ bootcmd_ti_mmc=
else;
run get_kern_${boot}; run get_fdt_${boot}; run
get_overlay_${boot}; run run_kern;
fi;
+default_device_tree=CONFIG_DEFAULT_DEVICE_TREE
+default_device_tree_arch=ti
+#ifdef CONFIG_ARM64
+findfdt=
+ setenv name_fdt ${default_device_tree_arch}/${default_device_tree}.dtb;
+ setenv fdtfile ${name_fdt}
+#else
+default_device_tree_subarch=omap
+findfdt=
+ setenv name_fdt
${default_device_tree_arch}/${default_device_tree_subarch}/${default_device_tree}.dtb;
+ setenv fdtfile ${name_fdt}
+#endif
--
2.40.0
[PATCH V5 07/17] include: env: ti: ti_armv7_common.env: Rename to ti_common.env
ti_armv7_common does not make any more sense as it is used by armv7
and armv8 TI based platforms.
Reported-by: Tom Rini
Signed-off-by: Nishanth Menon
---
New patch review comment from:
https://lore.kernel.org/all/20230823144257.GG3953269@bill-the-cat/
ti_common.h does'nt need any header file support if we switch to
bootstd.
board/siemens/iot2050/iot2050.env | 2 +-
board/ti/am62ax/am62ax.env| 2 +-
board/ti/am62x/am62x.env | 2 +-
board/ti/am64x/am64x.env | 2 +-
board/ti/am65x/am65x.env | 2 +-
board/ti/j721e/j721e.env | 2 +-
board/ti/j721s2/j721s2.env| 2 +-
board/ti/ks2_evm/k2e_evm.env | 2 +-
board/ti/ks2_evm/k2g_evm.env | 2 +-
board/ti/ks2_evm/k2hk_evm.env | 2 +-
board/ti/ks2_evm/k2l_evm.env | 2 +-
include/env/ti/{ti_armv7_common.env => ti_common.env} | 0
12 files changed, 11 insertions(+), 11 deletions(-)
rename include/env/ti/{ti_armv7_common.env => ti_common.env} (100%)
diff --git a/board/siemens/iot2050/iot2050.env
b/board/siemens/iot2050/iot2050.env
index caa9f80e3fca..8bbd7abe98f0 100644
--- a/board/siemens/iot2050/iot2050.env
+++ b/board/siemens/iot2050/iot2050.env
@@ -6,7 +6,7 @@
* Jan Kiszka
*/
-#include
+#include
usb_pgood_delay=900
diff --git a/board/ti/am62ax/am62ax.env b/board/ti/am62ax/am62ax.env
index 3f7c333fa404..bfed7f360844 100644
--- a/board/ti/am62ax/am62ax.env
+++ b/board/ti/am62ax/am62ax.env
@@ -1,4 +1,4 @@
-#include
+#include
#include
default_device_tree=ti/k3-am62a7-sk.dtb
diff --git a/board/ti/am62x/am62x.env b/board/ti/am62x/am62x.env
index 1cf56dbd8128..1ef948df83d7 100644
--- a/board/ti/am62x/am62x.env
+++ b/board/ti/am62x/am62x.env
@@ -1,4 +1,4 @@
-#include
+#include
#include
default_device_tree=ti/k3-am625-sk.dtb
diff --git a/board/ti/am64x/am64x.env b/board/ti/am64x/am64x.env
index 1567907fcbdc..68e4b7f1 100644
--- a/board/ti/am64x/am64x.env
+++ b/board/ti/am64x/am64x.env
@@ -1,4 +1,4 @@
-#include
+#include
#include
#include
diff --git a/board/ti/am65x/am65x.env b/board/ti/am65x/am65x.env
index 755bff2707c8..286b9c300c05 100644
--- a/board/ti/am65x/am65x.env
+++ b/board/ti/am65x/am65x.env
@@ -1,4 +1,4 @@
-#include
+#include
#include
#include
#if CONFIG_CMD_REMOTEPROC
diff --git a/board/ti/j721e/j721e.env b/board/ti/j721e/j721e.env
index 2f2fb0591279..8cc8232fc131 100644
--- a/board/ti/j721e/j721e.env
+++ b/board/ti/j721e/j721e.env
@@ -1,4 +1,4 @@
-#include
+#include
#include
#include
#include
diff --git a/board/ti/j721s2/j721s2.env b/board/ti/j721s2/j721s2.env
index 6825b1469854..64e3d9da85f0 100644
--- a/board/ti/j721s2/j721s2.env
+++ b/board/ti/j721s2/j721s2.env
@@ -1,4 +1,4 @@
-#include
+#include
#include
#include
#include
diff --git a/board/ti/ks2_evm/k2e_evm.env b/board/ti/ks2_evm/k2e_evm.env
index a145db53e5fa..3dbb7934c59a 100644
--- a/board/ti/ks2_evm/k2e_evm.env
+++ b/board/ti/ks2_evm/k2e_evm.env
@@ -1,4 +1,4 @@
-#include
+#include
#include
findfdt=setenv fdtfile ${name_fdt}
diff --git a/board/ti/ks2_evm/k2g_evm.env b/board/ti/ks2_evm/k2g_evm.env
index 4f4941dd0907..2b500fc6edf6 100644
--- a/board/ti/ks2_evm/k2g_evm.env
+++ b/board/ti/ks2_evm/k2g_evm.env
@@ -1,4 +1,4 @@
-#include
+#include
#include
#include
diff --git a/board/ti/ks2_evm/k2hk_evm.env b/board/ti/ks2_evm/k2hk_evm.env
index 0714a51090ef..9991b76f8fcc 100644
--- a/board/ti/ks2_evm/k2hk_evm.env
+++ b/board/ti/ks2_evm/k2hk_evm.env
@@ -1,4 +1,4 @@
-#include
+#include
#include
findfdt=setenv fdtfile ${name_fdt}
diff --git a/board/ti/ks2_evm/k2l_evm.env b/board/ti/ks2_evm/k2l_evm.env
index e8a803a4ed76..4e2debca4bde 100644
--- a/board/ti/ks2_evm/k2l_evm.env
+++ b/board/ti/ks2_evm/k2l_evm.env
@@ -1,4 +1,4 @@
-#include
+#include
#include
findfdt=setenv fdtfile ${name_fdt}
diff --git a/include/env/ti/ti_armv7_common.env b/include/env/ti/ti_common.env
similarity index 100%
rename from include/env/ti/ti_armv7_common.env
rename to include/env/ti/ti_common.env
--
2.40.0
[PATCH V5 16/17] board: ti: am62x: Add am62x_beagleplay_* defconfigs and env file
Add defconfig fragments for am625 based beagleplay and corresponding
customized environment file for beagleplay.
Signed-off-by: Nishanth Menon
---
Changes Since V4:
* New bootstd baseline
* have'nt picked up Mattijs's review as a result
V4: https://lore.kernel.org/r/20230822184135.2328409-8...@ti.com
V3: https://lore.kernel.org/all/20230815164440.2713726-4...@ti.com/
V2: https://lore.kernel.org/u-boot/20230727234446.3651836-4...@ti.com/
V1: https://lore.kernel.org/all/20230725185253.2123433-6...@ti.com/
board/ti/am62x/beagleplay.env| 18 +
board/ti/am62x/beagleplay_a53.config | 55
board/ti/am62x/beagleplay_r5.config | 15
3 files changed, 88 insertions(+)
create mode 100644 board/ti/am62x/beagleplay.env
create mode 100644 board/ti/am62x/beagleplay_a53.config
create mode 100644 board/ti/am62x/beagleplay_r5.config
diff --git a/board/ti/am62x/beagleplay.env b/board/ti/am62x/beagleplay.env
new file mode 100644
index ..73a078b93009
--- /dev/null
+++ b/board/ti/am62x/beagleplay.env
@@ -0,0 +1,18 @@
+#include
+#include
+
+name_kern=Image
+console=ttyS2,115200n8
+args_all=setenv optargs ${optargs} earlycon=ns16550a,mmio32,0x0280
+run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
+set_led_state_fail_load= led led-0 off; led led-1 on;
+ led led-2 off; led led-3 on; led led-4 off
+set_led_state_start_load=led led-0 on; led led-1 off;
+ led led-2 on; led led-3 off; led led-4 on
+boot=mmc
+mmcdev=1
+bootpart=1:1
+bootdir=/boot
+boot_targets=mmc1 mmc0 usb pxe
+bootmeths=extlinux efi
+rd_spec=-
diff --git a/board/ti/am62x/beagleplay_a53.config
b/board/ti/am62x/beagleplay_a53.config
new file mode 100644
index ..f0380416cc5e
--- /dev/null
+++ b/board/ti/am62x/beagleplay_a53.config
@@ -0,0 +1,55 @@
+# Defconfig fragment to apply on top of am62x_evm_a53_defconfig
+
+CONFIG_DEFAULT_DEVICE_TREE="k3-am625-beagleplay"
+CONFIG_OF_LIST="k3-am625-beagleplay"
+CONFIG_SPL_OF_LIST="k3-am625-beagleplay"
+CONFIG_BOOTCOMMAND="run set_led_state_start_load;run findfdt; run envboot;
bootflow scan -lb;run set_led_state_fail_load"
+CONFIG_EXT4_WRITE=y
+CONFIG_LZO=y
+CONFIG_AUTOBOOT_KEYED=y
+CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n"
+CONFIG_AUTOBOOT_DELAY_STR="d"
+CONFIG_AUTOBOOT_STOP_STR=" "
+# Use the Beagleplay env file
+CONFIG_ENV_SOURCE_FILE="beagleplay"
+# Do not use emmc boot - we will use FS only
+CONFIG_SUPPORT_EMMC_BOOT=n
+CONFIG_MMC_IO_VOLTAGE=y
+# CONFIG_SPL_MMC_IO_VOLTAGE is not set
+CONFIG_MMC_UHS_SUPPORT=y
+# CONFIG_SPL_MMC_UHS_SUPPORT is not set
+CONFIG_MMC_HS200_SUPPORT=y
+# CONFIG_SPL_MMC_HS200_SUPPORT is not set
+# Enable GPIO control
+CONFIG_DM_GPIO=y
+CONFIG_SPL_GPIO=y
+CONFIG_DA8XX_GPIO=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPIO_READ=y
+# Enable LEDs
+CONFIG_LED=y
+CONFIG_LED_GPIO=y
+CONFIG_SPL_LED=y
+CONFIG_SPL_LED_GPIO=y
+# Enable I2C bus
+CONFIG_SPL_I2C=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_OMAP24XX=y
+CONFIG_CMD_I2C=y
+# Regulator
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_CMD_REGULATOR=y
+CONFIG_DM_REGULATOR_TPS65219=y
+CONFIG_DM_PMIC=y
+CONFIG_PMIC_TPS65219=y
+CONFIG_CMD_PMIC=y
+# Uses Realtek phy rather than TI phy
+CONFIG_PHY_TI_DP83867=n
+CONFIG_PHY_REALTEK=y
+# No SPI flash on Beagleplay
+CONFIG_SPI=n
+CONFIG_SPI_FLASH=n
+CONFIG_SPL_DM_SPI_FLASH=n
+CONFIG_SPL_SPI_FLASH_SUPPORT=n
diff --git a/board/ti/am62x/beagleplay_r5.config
b/board/ti/am62x/beagleplay_r5.config
new file mode 100644
index ..4ee0375a2a1d
--- /dev/null
+++ b/board/ti/am62x/beagleplay_r5.config
@@ -0,0 +1,15 @@
+# Defconfig fragment to apply on top of:
+# am62x_evm_r5_defconfig
+#
+CONFIG_DEFAULT_DEVICE_TREE="k3-am625-r5-beagleplay"
+CONFIG_OF_LIST="k3-am625-r5-beagleplay"
+CONFIG_SPL_OF_LIST="k3-am625-r5-beagleplay"
+# Do spl board init
+CONFIG_SPL_BOARD_INIT=y
+# Do not use emmc boot - we will use FS only
+CONFIG_SUPPORT_EMMC_BOOT=n
+# No SPI flash on Beagleplay
+CONFIG_SPI=n
+CONFIG_SPI_FLASH=n
+CONFIG_SPL_DM_SPI_FLASH=n
+CONFIG_SPL_SPI_FLASH_SUPPORT=n
--
2.40.0
[PATCH V5 10/17] arm: mach-k3: am625_init: Use IS_ENABLED()
Drop the #ifdeffery and use IS_ENABLED() inline check and let the compiler
do it's thing.
Signed-off-by: Nishanth Menon
---
new patch (cleanup before modifying for adding UDA-FS)
arch/arm/mach-k3/am625_init.c | 35 +--
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-k3/am625_init.c b/arch/arm/mach-k3/am625_init.c
index 0e5d44269ebf..165bca6885ef 100644
--- a/arch/arm/mach-k3/am625_init.c
+++ b/arch/arm/mach-k3/am625_init.c
@@ -121,10 +121,10 @@ void board_init_f(ulong dummy)
struct udevice *dev;
int ret;
-#if defined(CONFIG_CPU_V7R)
- setup_k3_mpu_regions();
- rtc_erratumi2327_init();
-#endif
+ if (IS_ENABLED(CONFIG_CPU_V7R)) {
+ setup_k3_mpu_regions();
+ rtc_erratumi2327_init();
+ }
/*
* Cannot delay this further as there is a chance that
@@ -156,29 +156,28 @@ void board_init_f(ulong dummy)
preloader_console_init();
-#ifdef CONFIG_K3_EARLY_CONS
/*
* Allow establishing an early console as required for example when
* doing a UART-based boot. Note that this console may not "survive"
* through a SYSFW PM-init step and will need a re-init in some way
* due to changing module clock frequencies.
*/
- early_console_init();
-#endif
+ if (IS_ENABLED(CONFIG_K3_EARLY_CONS))
+ early_console_init();
-#if defined(CONFIG_K3_LOAD_SYSFW)
/*
* Configure and start up system controller firmware. Provide
* the U-Boot console init function to the SYSFW post-PM configuration
* callback hook, effectively switching on (or over) the console
* output.
*/
- ret = is_rom_loaded_sysfw();
- if (!ret)
- panic("ROM has not loaded TIFS firmware\n");
+ if (IS_ENABLED(CONFIG_K3_LOAD_SYSFW)) {
+ ret = is_rom_loaded_sysfw();
+ if (!ret)
+ panic("ROM has not loaded TIFS firmware\n");
- k3_sysfw_loader(true, NULL, NULL);
-#endif
+ k3_sysfw_loader(true, NULL, NULL);
+ }
/*
* Force probe of clk_k3 driver here to ensure basic default clock
@@ -209,11 +208,11 @@ void board_init_f(ulong dummy)
enable_mcu_esm_reset();
}
-#if defined(CONFIG_K3_AM64_DDRSS)
- ret = uclass_get_device(UCLASS_RAM, 0, );
- if (ret)
- panic("DRAM init failed: %d\n", ret);
-#endif
+ if (IS_ENABLED(CONFIG_K3_AM64_DDRSS)) {
+ ret = uclass_get_device(UCLASS_RAM, 0, );
+ if (ret)
+ panic("DRAM init failed: %d\n", ret);
+ }
spl_enable_dcache();
}
--
2.40.0
[PATCH V5 13/17] arm: mach-k3: am625: Add support for UDA FS
While boot partition support with EMMC boot is useful, it is
constrained by the size of boot hardware partition itself.
In the case of K3 devices, tispl images can contain OP-TEE images that
can substantially vary in size and the u-boot image itself can vary over
time as we enable various features.
So use the CSD information in the case of EMMC_BOOT configuration being
enabled to pick boot partition or UDA FS mode operation to pick.
If EMMC_BOOT is disabled, then depend on filesystem configuration to
pick data from UDA.
While at this, drop the extraneous whitespace.
Signed-off-by: Nishanth Menon
---
Changes since V4:
- Did'nt pickup Mattijs' reviewed-by - no more iffdeffery - so might be
good to relook.
V4: https://lore.kernel.org/r/20230822184135.2328409-4...@ti.com
arch/arm/mach-k3/am625_init.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-k3/am625_init.c b/arch/arm/mach-k3/am625_init.c
index 499cb57267b9..8fa36f7b913e 100644
--- a/arch/arm/mach-k3/am625_init.c
+++ b/arch/arm/mach-k3/am625_init.c
@@ -220,9 +220,15 @@ u32 spl_mmc_boot_mode(struct mmc *mmc, const u32
boot_device)
u32 bootmode_cfg = (devstat & MAIN_DEVSTAT_PRIMARY_BOOTMODE_CFG_MASK) >>
MAIN_DEVSTAT_PRIMARY_BOOTMODE_CFG_SHIFT;
-
switch (bootmode) {
case BOOT_DEVICE_EMMC:
+ if (IS_ENABLED(CONFIG_SUPPORT_EMMC_BOOT)) {
+ if (spl_mmc_emmc_boot_partition(mmc))
+ return MMCSD_MODE_EMMCBOOT;
+ return MMCSD_MODE_FS;
+ }
+ if (IS_ENABLED(CONFIG_SPL_FS_FAT) ||
IS_ENABLED(CONFIG_SPL_FS_EXT4))
+ return MMCSD_MODE_FS;
return MMCSD_MODE_EMMCBOOT;
case BOOT_DEVICE_MMC:
if (bootmode_cfg & MAIN_DEVSTAT_PRIMARY_MMC_FS_RAW_MASK)
--
2.40.0
[PATCH V5 09/17] board: ti: am62x: am62x.env: Use default findfdt
Use the default findfdt using CONFIG_DEFAULT_DEVICE_TREE
Signed-off-by: Nishanth Menon
---
New patch (part of bootstd transition)
board/ti/am62x/am62x.env | 4
1 file changed, 4 deletions(-)
diff --git a/board/ti/am62x/am62x.env b/board/ti/am62x/am62x.env
index 1ef948df83d7..68b26703bf7f 100644
--- a/board/ti/am62x/am62x.env
+++ b/board/ti/am62x/am62x.env
@@ -1,10 +1,6 @@
#include
#include
-default_device_tree=ti/k3-am625-sk.dtb
-findfdt=
- setenv name_fdt ${default_device_tree};
- setenv fdtfile ${name_fdt}
name_kern=Image
console=ttyS2,115200n8
args_all=setenv optargs ${optargs} earlycon=ns16550a,mmio32,0x0280
--
2.40.0
[PATCH V5 04/17] board: ti: am62x: am62x.env: Add explicit boot_targets
Add explicit boot_targets to indicate the specific boot sequence to
follow.
NOTE: The non-standard ti_mmc emulates what is done for distro_boot.
With bootstd, this will eventually need to be replaced by equivalent
class.
Signed-off-by: Nishanth Menon
---
New patch (part of bootstd transition) - we can argue that ti_mmc
should'nt belong here - but I wanted to maintain the boot_ti_mmc target
that is provided in ti_common.env
board/ti/am62x/am62x.env | 1 +
1 file changed, 1 insertion(+)
diff --git a/board/ti/am62x/am62x.env b/board/ti/am62x/am62x.env
index f2dc87893a92..1cf56dbd8128 100644
--- a/board/ti/am62x/am62x.env
+++ b/board/ti/am62x/am62x.env
@@ -11,6 +11,7 @@ args_all=setenv optargs ${optargs}
earlycon=ns16550a,mmio32,0x0280
${mtdparts}
run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
+boot_targets=ti_mmc mmc0 mmc1 usb pxe dhcp
boot=mmc
mmcdev=1
bootpart=1:2
--
2.40.0
[PATCH V5 03/17] include: configs: am62x_evm: Wrap distroboot with CONFIG_DISTRO_DEFAULTS
Wrap the distro_boot options with CONFIG_DISTRO_DEFAULTS. This is an intermediate step for us to switch over to CONFIG_BOOTSTD_DEFAULTS and drop this section in follow on patches. Signed-off-by: Nishanth Menon --- New patch (part of bootstd transition) include/configs/am62x_evm.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/am62x_evm.h b/include/configs/am62x_evm.h index 379e0c13a395..81d7658cdb0d 100644 --- a/include/configs/am62x_evm.h +++ b/include/configs/am62x_evm.h @@ -9,8 +9,10 @@ #ifndef __CONFIG_AM625_EVM_H #define __CONFIG_AM625_EVM_H +#ifdef CONFIG_DISTRO_DEFAULTS #include #include +#endif /* Now for the remaining common defines */ #include -- 2.40.0
[PATCH V5 01/17] include: configs: ti_armv7_common: Add documentation for protected section
Make the section protected by CONFIG_DISTRO_DEFAULTS macro clear. Signed-off-by: Nishanth Menon --- New patch (part of bootstd transition) include/configs/ti_armv7_common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h index dbbeff34ba82..4e30d0d2ddf8 100644 --- a/include/configs/ti_armv7_common.h +++ b/include/configs/ti_armv7_common.h @@ -200,7 +200,7 @@ #define CFG_EXTRA_ENV_SETTINGS \ BOOTENV -#endif +#endif /* CONFIG_DISTRO_DEFAULTS */ #endif /* CONFIG_ARM64 */ -- 2.40.0
[PATCH V5 06/17] include: configs: am62x_evm: Drop distro_bootcmd usage
Now that BOOTSTD is used by default, drop un-used header file inclusion. Signed-off-by: Nishanth Menon --- New patch (part of bootstd transition) include/configs/am62x_evm.h | 5 - 1 file changed, 5 deletions(-) diff --git a/include/configs/am62x_evm.h b/include/configs/am62x_evm.h index 81d7658cdb0d..c8fe59b75313 100644 --- a/include/configs/am62x_evm.h +++ b/include/configs/am62x_evm.h @@ -9,11 +9,6 @@ #ifndef __CONFIG_AM625_EVM_H #define __CONFIG_AM625_EVM_H -#ifdef CONFIG_DISTRO_DEFAULTS -#include -#include -#endif - /* Now for the remaining common defines */ #include -- 2.40.0
[PATCH V5 00/17] board: ti: Add support for BeaglePlay
Add support for BeaglePlay - rev 5
Full series: https://github.com/nmenon/fix-k3-dt-u-boot/commits/beagleplay-v4.2
Caveats:
* networking: pending
https://lore.kernel.org/all/20230822121350.51324-1-rog...@kernel.org/
* 32kclk and usb: pending:
https://lore.kernel.org/u-boot/20230725185253.2123433-4...@ti.com/
OR
https://github.com/nmenon/fix-k3-dt-u-boot/commit/853b29d63c1ca642be316f1afb0fb778610dec46
being properly resolved (NOTE: without this patch, wlan is broken in
Linux as the 32kclk from SoC is incorrectly supplied to wlan as 25MHz)
* There seems to be a bug in Linux kernel with sdhci that seems to
depend on u-boot initialization of sdhci for functionality.
CI loop check: https://github.com/u-boot/u-boot/pull/425 (whenever that
gets done I guess).
Bootlogs:
SD Boot: https://gist.github.com/nmenon/c74acb3a895053e05623e886df77c8fe
eMMC, no SD boot:
https://gist.github.com/nmenon/16df3b8fc0e9102f29ebb7836b950a08
eMMC with SD card:
https://gist.github.com/nmenon/042dbe7c08589e7bfe1919da1fedc545
Complete code (with the tmp patch) can be found at:
https://github.com/nmenon/fix-k3-dt-u-boot/tree/beagleplay-v5
Baseline: 97841de68043 (origin/next) Merge branch
'2023-08-22-assorted-code-cleanups' into next
Changes since V4:
* Switched boot from distro_boot to bootstd - AM62 as a start will rely
on txt env file.
* Cleanups around am625_init.c (new patches)
* Review comment fixups for documentation
* I have'nt picked up Mattijs's tested by since this is a different
approach (bootstd Vs distro_bootcmd)
* Dropped the sdhci patches AND CFG_EXTRA_ENV_SETTINGS (Instead, we
switch entirely to bootstd and move am62x-sk to bootstd along with
it).
V4: https://lore.kernel.org/all/20230822184135.2328409-1...@ti.com/
V3: https://lore.kernel.org/all/20230815164440.2713726-1...@ti.com/
V2: https://lore.kernel.org/u-boot/20230727234446.3651836-1...@ti.com/
V1: https://lore.kernel.org/all/20230725185253.2123433-1...@ti.com/
Nishanth Menon (16):
include: configs: ti_armv7_common: Add documentation for protected
section
include: configs: am62x_evm: Drop unused SDRAM address
include: configs: am62x_evm: Wrap distroboot with
CONFIG_DISTRO_DEFAULTS
board: ti: am62x: am62x.env: Add explicit boot_targets
configs: am62x_evm_a53_defconfig: Switch to bootstd
include: configs: am62x_evm: Drop distro_bootcmd usage
include: env: ti: ti_armv7_common.env: Rename to ti_common.env
include: env: ti: ti_common: Add a generic findfdt
board: ti: am62x: am62x.env: Use default findfdt
arm: mach-k3: am625_init: Use IS_ENABLED()
arm: mach-k3: am625_init: Convert rtc_erratumi2327_init to static
configs: am62x_evm*: Enable EMMC_BOOT configuration
arm: mach-k3: am625: Add support for UDA FS
arm: dts: k3-am625-sk-binman: Add labels for unsigned binary
board: ti: am62x: Add am62x_beagleplay_* defconfigs and env file
doc: board: ti: Add BeaglePlay documentation
Robert Nelson (1):
arm: dts: Add k3-am625-beagleplay
arch/arm/dts/Makefile |2 +
.../dts/k3-am625-beagleplay-ddr4-1600MTs.dtsi | 2195 +
arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 195 ++
arch/arm/dts/k3-am625-beagleplay.dts | 758 ++
arch/arm/dts/k3-am625-r5-beagleplay.dts | 86 +
arch/arm/dts/k3-am625-sk-binman.dtsi |4 +-
arch/arm/mach-k3/am625_init.c | 49 +-
board/siemens/iot2050/iot2050.env |2 +-
board/ti/am62ax/am62ax.env|2 +-
board/ti/am62x/MAINTAINERS|7 +
board/ti/am62x/am62x.env |7 +-
board/ti/am62x/beagleplay.env | 18 +
board/ti/am62x/beagleplay_a53.config | 55 +
board/ti/am62x/beagleplay_r5.config | 15 +
board/ti/am64x/am64x.env |2 +-
board/ti/am65x/am65x.env |2 +-
board/ti/j721e/j721e.env |2 +-
board/ti/j721s2/j721s2.env|2 +-
board/ti/ks2_evm/k2e_evm.env |2 +-
board/ti/ks2_evm/k2g_evm.env |2 +-
board/ti/ks2_evm/k2hk_evm.env |2 +-
board/ti/ks2_evm/k2l_evm.env |2 +-
configs/am62x_evm_a53_defconfig |6 +-
configs/am62x_evm_r5_defconfig|1 +
doc/board/ti/am62x_beagleplay.rst | 256 ++
doc/board/ti/img/beagleplay_emmc.svg | 697 ++
doc/board/ti/k3.rst |1 +
include/configs/am62x_evm.h |6 -
include/configs/ti_armv7_common.h |2 +-
.../ti/{ti_armv7_common.env => ti_common.env} | 12 +
30 files changed, 4342 insertions(+), 50 deletions(-)
create mode 100644 arch/arm/dts/k3-am625-beagleplay-ddr4-1600MTs.dtsi
create mode 100644 arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
create mode 100644 arch/arm/dts/k3-am625-beagleplay.dts
create mode 100644
[PATCH V5 02/17] include: configs: am62x_evm: Drop unused SDRAM address
Drop unused macro. This was meant for a second region of DDR which we do not need for AM62x evm configurations. Signed-off-by: Nishanth Menon --- New patch (part of bootstd transition) include/configs/am62x_evm.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/include/configs/am62x_evm.h b/include/configs/am62x_evm.h index 44180dc7687b..379e0c13a395 100644 --- a/include/configs/am62x_evm.h +++ b/include/configs/am62x_evm.h @@ -12,9 +12,6 @@ #include #include -/* DDR Configuration */ -#define CFG_SYS_SDRAM_BASE10x88000 - /* Now for the remaining common defines */ #include -- 2.40.0
[PATCH 6/6] stm32mp15: Use u-boot-spl-stm32.bin instead of u-boot-spl.stm32
A '.stm32' extension is not allowed anymore, so change it.
Signed-off-by: Simon Glass
---
arch/arm/dts/stm32mp15-u-boot.dtsi | 2 +-
doc/board/st/stm32mp1.rst| 18 +-
include/configs/stm32mp15_dh_dhsom.h | 2 +-
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/dts/stm32mp15-u-boot.dtsi
b/arch/arm/dts/stm32mp15-u-boot.dtsi
index 573dd4d3ed56..717eb96a517c 100644
--- a/arch/arm/dts/stm32mp15-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp15-u-boot.dtsi
@@ -222,7 +222,7 @@
#if defined(CONFIG_SPL)
{
spl-stm32 {
- filename = "u-boot-spl.stm32";
+ filename = "u-boot-spl-stm32.bin";
mkimage {
args = "-T stm32image -a 0x2ffc2500 -e 0x2ffc2500";
u-boot-spl {
diff --git a/doc/board/st/stm32mp1.rst b/doc/board/st/stm32mp1.rst
index 63b44776ffc1..01ba817aa80d 100644
--- a/doc/board/st/stm32mp1.rst
+++ b/doc/board/st/stm32mp1.rst
@@ -318,7 +318,7 @@ Build Procedure
- stm32mp15_basic_defconfig
- - FSBL = spl/u-boot-spl.stm32
+ - FSBL = spl/u-boot-spl-stm32.bin
- SSBL = u-boot.img (without CONFIG_SPL_LOAD_FIT) or
u-boot.itb (with CONFIG_SPL_LOAD_FIT=y)
@@ -361,7 +361,7 @@ Build Procedure
8. The bootloaders files
+ The **ROM code** expects FSBL binaries with STM32 image header =
- tf-a.stm32 or u-boot-spl.stm32
+ tf-a.stm32 or u-boot-spl-stm32.bin
According the FSBL / the boot mode:
@@ -468,9 +468,9 @@ or:
+---++-+++
| *Num* | *Name* | *Size* | *Trusted boot content* | *Basic boot content*
|
+===++=+++
- | 1 | fsbl1 | 256 KiB | TF-A_ BL2 (tf-a.stm32) | SPL (u-boot-spl.stm32)
|
+ | 1 | fsbl1 | 256 KiB | TF-A_ BL2 (tf-a.stm32) | SPL
(u-boot-spl-stm32.bin) |
+---++-+++
- | 2 | fsbl2 | 256 KiB | TF-A_ BL2 (tf-a.stm32) | SPL (u-boot-spl.stm32)
|
+ | 2 | fsbl2 | 256 KiB | TF-A_ BL2 (tf-a.stm32) | SPL
(u-boot-spl-stm32.bin) |
+---++-+++
| 3 | ssbl | 2MB | U-Boot (u-boot.stm32) | U-Boot (u-boot.img)
|
+---++-+++
@@ -528,8 +528,8 @@ c) copy the FSBL (2 times) and SSBL file on the correct
partition.
for basic boot mode : = /dev/mmcblk0::
-# dd if=u-boot-spl.stm32 of=/dev/mmcblk0p1
-# dd if=u-boot-spl.stm32 of=/dev/mmcblk0p2
+# dd if=u-boot-spl-stm32.bin of=/dev/mmcblk0p1
+# dd if=u-boot-spl-stm32.bin of=/dev/mmcblk0p2
# dd if=u-boot.img of=/dev/mmcblk0p3 # Without CONFIG_SPL_LOAD_FIT
OR
dd if=u-boot.itb of=/dev/mmcblk0p3 # With CONFIG_SPL_LOAD_FIT=y
@@ -542,7 +542,7 @@ Prepare eMMC
You can use U-Boot to copy binary in eMMC.
In the next example, you need to boot from SD card and the images
-(tf-a.stm32, fip.bin / u-boot-spl.stm32, u-boot.img for systems without
+(tf-a.stm32, fip.bin / u-boot-spl-stm32.bin, u-boot.img for systems without
CONFIG_SPL_LOAD_FIT or u-boot.itb for systems with CONFIG_SPL_LOAD_FIT=y) are
presents on SD card (mmc 0) in ext4 partition 4 (bootfs)
@@ -561,7 +561,7 @@ b) copy FSBL, TF-A_ or SPL, on first eMMC boot partition
# ext4load mmc 0:4 0xC000 tf-a.stm32
or
-# ext4load mmc 0:4 0xC000 u-boot-spl.stm32
+# ext4load mmc 0:4 0xC000 u-boot-spl-stm32.bin
# mmc dev 1
# mmc partconf 1 1 1 1
@@ -838,4 +838,4 @@ Arm TrustZone technology
+ https://www.op-tee.org/
+ https://optee.readthedocs.io/en/latest/
+ https://optee.readthedocs.io/en/latest/building/devices/stm32mp1.html
- + https://github.com/OP-TEE/optee_os
\ No newline at end of file
+ + https://github.com/OP-TEE/optee_os
diff --git a/include/configs/stm32mp15_dh_dhsom.h
b/include/configs/stm32mp15_dh_dhsom.h
index 919216906249..ad4e93805ded 100644
--- a/include/configs/stm32mp15_dh_dhsom.h
+++ b/include/configs/stm32mp15_dh_dhsom.h
@@ -22,7 +22,7 @@
"usb_pgood_delay=1000\0" \
"update_sf=" /* Erase SPI NOR and install U-Boot from SD */ \
"setexpr loadaddr1 ${loadaddr} + 0x100 && " \
- "load mmc 0:4 ${loadaddr1} /boot/u-boot-spl.stm32 && " \
+ "load mmc 0:4 ${loadaddr1} /boot/u-boot-spl-stm32.bin && "
\
"env set filesize1 ${filesize} && " \
"load mmc 0:4 ${loadaddr} /boot/u-boot.itb && " \
"sf probe && sf erase 0 0x20 && " \
--
2.42.0.rc1.204.g551eb34607-goog
[PATCH 5/6] kontron_sl28: Use u-boot-update.bin instead of u-boot.update
A '.update' extension is not allowed anymore, so change it.
Signed-off-by: Simon Glass
---
arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 2 +-
doc/board/kontron/sl28.rst| 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
index 83750ab001b2..aacf181e2dd0 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
@@ -64,7 +64,7 @@
{
u-boot-update {
- filename = "u-boot.update";
+ filename = "u-boot-update.bin";
fit {
description = "FIT update image";
diff --git a/doc/board/kontron/sl28.rst b/doc/board/kontron/sl28.rst
index 44435d90c624..2cb8ec62be42 100644
--- a/doc/board/kontron/sl28.rst
+++ b/doc/board/kontron/sl28.rst
@@ -39,12 +39,12 @@ Update image
After the build finished, there will be an update image called
-u-boot.update. This can either be used in the DFU mode (which isn't
+u-boot-update.bin. This can either be used in the DFU mode (which isn't
supported yet) or encapsulated in an EFI UpdateCapsule.
To build the capsule use the following command
- $ tools/mkeficapsule -f u-boot.update -i 1 UpdateUboot
+ $ tools/mkeficapsule -f u-boot-update.bin -i 1 UpdateUboot
Afterward you can copy this file to your ESP into the /EFI/UpdateCapsule/
folder. On the next EFI boot this will automatically update your
--
2.42.0.rc1.204.g551eb34607-goog
[PATCH 4/6] buildman: Start the clock when the build starts
The Kconfig and maintainer processing can take a while, sometimes 5
seconds or more. This skews the timing printed by buildmand when the build
completes. Start the clock when the threads start to avoid this problem.
Signed-off-by: Simon Glass
Suggested-by: Tom Rini
---
tools/buildman/builder.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
index ecbd368c47a5..5305477c5be6 100644
--- a/tools/buildman/builder.py
+++ b/tools/buildman/builder.py
@@ -328,7 +328,7 @@ class Builder:
self._build_period_us = None
self._complete_delay = None
self._next_delay_update = datetime.now()
-self._start_time = datetime.now()
+self._start_time = None
self._step = step
self._error_lines = 0
self.no_subdirs = no_subdirs
@@ -1778,6 +1778,7 @@ class Builder:
self._prepare_output_space()
if not self._ide:
tprint('\rStarting build...', newline=False)
+self._start_time = datetime.now()
self.setup_build(board_selected, commits)
self.process_result(None)
self.thread_exceptions = []
--
2.42.0.rc1.204.g551eb34607-goog
[PATCH 3/6] buildman: Show progress when regenerating the board.cfg file
This can take a while, so show a message when starting.
Signed-off-by: Simon Glass
Reported-by Tom Rini
---
tools/buildman/boards.py | 15 ---
tools/buildman/control.py | 3 ++-
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/tools/buildman/boards.py b/tools/buildman/boards.py
index eef3f19f7ad6..341a5056dfd2 100644
--- a/tools/buildman/boards.py
+++ b/tools/buildman/boards.py
@@ -19,6 +19,7 @@ import time
from buildman import board
from buildman import kconfiglib
+from u_boot_pylib.terminal import print_clear, tprint
### constant variables ###
OUTPUT_FILE = 'boards.cfg'
@@ -863,11 +864,19 @@ class Boards:
Returns:
bool: True if all is well, False if there were warnings
"""
-if not force and output_is_new(output, CONFIG_DIR, '.'):
+if not force:
if not quiet:
-print(f'{output} is up to date. Nothing to do.')
-return True
+tprint('\rChecking for Kconfig changes...', newline=False)
+is_new = output_is_new(output, CONFIG_DIR, '.')
+print_clear()
+if is_new:
+if not quiet:
+print(f'{output} is up to date. Nothing to do.')
+return True
+if not quiet:
+tprint('\rGenerating board list...', newline=False)
params_list, warnings = self.build_board_list(CONFIG_DIR, '.', jobs)
+print_clear()
for warn in warnings:
print(warn, file=sys.stderr)
self.format_and_output(params_list, output)
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index f2ffb7f5b4aa..8f6850c52113 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -621,7 +621,8 @@ def do_buildman(args, toolchains=None, make_func=None,
brds=None,
if not brds:
brds = get_boards_obj(output_dir, args.regen_board_list,
args.maintainer_check, args.full_check,
- args.threads, args.verbose)
+ args.threads, args.verbose and
+ not args.print_arch and not args.print_prefix)
if isinstance(brds, int):
return brds
--
2.42.0.rc1.204.g551eb34607-goog
[PATCH 2/6] buildman: Keep all permitted output files
Now that we have a list of permitted output extensions, use it to ensure
that the -k option preserves all of these.
Signed-off-by: Simon Glass
Suggested-by: Tom Rini
---
tools/buildman/builderthread.py | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/tools/buildman/builderthread.py b/tools/buildman/builderthread.py
index 25f460c207db..d8374e68eb7f 100644
--- a/tools/buildman/builderthread.py
+++ b/tools/buildman/builderthread.py
@@ -23,6 +23,9 @@ from u_boot_pylib import command
RETURN_CODE_RETRY = -1
BASE_ELF_FILENAMES = ['u-boot', 'spl/u-boot-spl', 'tpl/u-boot-tpl']
+# Extensions allowed for images (keep in sync with binman/image.py, README.md)
+ALLOWED_EXTS = ['.bin', '.rom', '.itb', '.img']
+
def mkdir(dirname, parents=False):
"""Make a directory if it doesn't already exist.
@@ -636,10 +639,10 @@ class BuilderThread(threading.Thread):
# Now write the actual build output
if keep_outputs:
-copy_files(
-result.out_dir, build_dir, '',
-['u-boot*', '*.bin', '*.map', '*.img', 'MLO', 'SPL',
- 'include/autoconf.mk', 'spl/u-boot-spl*'])
+to_copy = ['u-boot*', '*.map', 'MLO', 'SPL',
+ 'include/autoconf.mk', 'spl/u-boot-spl*']
+to_copy += [f'*{ext}' for ext in ALLOWED_EXTS]
+copy_files(result.out_dir, build_dir, '', to_copy)
def _send_result(self, result):
"""Send a result to the builder for processing
--
2.42.0.rc1.204.g551eb34607-goog
[PATCH 1/6] binman: Require image filenames to have certain extensions
It is helpful to be able to distinguish output files from other files when
building U-Boot. This is useful for buildman, for example, which can
preserve output files when requested.
Most images use extensions like .bin or .rom but some use other ones.
Introduce a check and produce an error if an image filename does not have
an allowed extension.
Signed-off-by: Simon Glass
---
tools/binman/binman.rst | 5 +
tools/binman/etype/section.py| 3 +--
tools/binman/ftest.py| 12 ++--
tools/binman/image.py| 9 +
tools/binman/test/022_image_name.dts | 4 ++--
tools/binman/test/311_bad_image_name.dts | 17 +
6 files changed, 44 insertions(+), 6 deletions(-)
create mode 100644 tools/binman/test/311_bad_image_name.dts
diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
index aeea33fddb95..3c24a8313c47 100644
--- a/tools/binman/binman.rst
+++ b/tools/binman/binman.rst
@@ -678,6 +678,11 @@ filename:
put into the entry. If binman knows about the entry type (like
u-boot-bin), then there is no need to specify this.
+Note that image filenames must have one of a limited set of extensions:
+`.bin`, `.rom`, `.itb` or `.img`. Others will generate an error. This is
+so that it is clear which output files are images. It allows buildman to
+preserve them when its `-k` option is used, for example.
+
type:
Sets the type of an entry. This defaults to the entry name, but it is
possible to use any name, and then add (for example) 'type = "u-boot"'
diff --git a/tools/binman/etype/section.py b/tools/binman/etype/section.py
index fb49e85a7634..8074f181ea58 100644
--- a/tools/binman/etype/section.py
+++ b/tools/binman/etype/section.py
@@ -10,6 +10,7 @@ images to be created.
from collections import OrderedDict
import concurrent.futures
+import os
import re
import sys
@@ -20,7 +21,6 @@ from u_boot_pylib import tools
from u_boot_pylib import tout
from u_boot_pylib.tools import to_hex_size
-
class Entry_section(Entry):
"""Entry that contains other entries
@@ -203,7 +203,6 @@ class Entry_section(Entry):
self.align_default = fdt_util.GetInt(self._node, 'align-default', 0)
self._filename = fdt_util.GetString(self._node, 'filename',
self._filename)
-
self.ReadEntries()
def ReadEntries(self):
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 1293e9dbf423..5b54239827d4 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -1107,11 +1107,11 @@ class TestFunctional(unittest.TestCase):
retcode = self._DoTestFile('022_image_name.dts')
self.assertEqual(0, retcode)
image = control.images['image1']
-fname = tools.get_output_filename('test-name')
+fname = tools.get_output_filename('test-name.bin')
self.assertTrue(os.path.exists(fname))
image = control.images['image2']
-fname = tools.get_output_filename('test-name.xx')
+fname = tools.get_output_filename('test-name.img')
self.assertTrue(os.path.exists(fname))
def testBlobFilename(self):
@@ -7216,5 +7216,13 @@ fdt fdtmapExtract the devicetree
blob from the fdtmap
self.assertRegex(err,
"Image 'image'.*missing bintools.*: bootgen")
+def testBadImageName(self):
+"""Test that image files can be named"""
+with self.assertRaises(ValueError) as e:
+self._DoTestFile('311_bad_image_name.dts')
+self.assertIn(
+"Image filename 'test-name.what' must use a permitted extension:
.bin, .rom, .itb, .img",
+str(e.exception))
+
if __name__ == "__main__":
unittest.main()
diff --git a/tools/binman/image.py b/tools/binman/image.py
index e77b5d0d97cd..71dc28854412 100644
--- a/tools/binman/image.py
+++ b/tools/binman/image.py
@@ -21,6 +21,9 @@ from dtoc import fdt_util
from u_boot_pylib import tools
from u_boot_pylib import tout
+# Extensions allowed for images (keep in sync with buildman/builderthread.py)
+ALLOWED_EXTS = ['.bin', '.rom', '.itb', '.img']
+
class Image(section.Entry_section):
"""A Image, representing an output from binman
@@ -97,6 +100,12 @@ class Image(section.Entry_section):
self.allow_repack = fdt_util.GetBool(self._node, 'allow-repack')
self._symlink = fdt_util.GetString(self._node, 'symlink')
+if self.section is None:
+ext = os.path.splitext(self._filename)[1]
+if ext not in ALLOWED_EXTS:
+self.Raise(
+f"Image filename '{self._filename}' must use a permitted
extension: {', '.join(ALLOWED_EXTS)}")
+
@classmethod
def FromFile(cls, fname):
"""Convert an image file into an Image for use in binman
diff --git a/tools/binman/test/022_image_name.dts
b/tools/binman/test/022_image_name.dts
[PATCH 0/6] Attempt to enforce standard extensions for build output
In this early stage of using binman to produce output files, we are mostly
seeing people using common extensions such as '.bin' and '.rom'
But unusual extensions appear in some places.
We would like 'buildman -k' to keep the build outputs, but this is hard if
there is no consistency as to the extension used.
This series adjusts binman to enforce just 4 extensions for output images:
.bin
.rom
.itb
.img
Other extensions will produce an error. With this rule observed, buildman
can keep the required files.
Some patches are included to fix up some easy problems. But the following
boards generate 'custMpk.pem' and it is not clear how to fix this, so I am
asking for help from the maintainers:
am62ax_evm_r5 am62x_evm_r5 am64x_evm_r5 am65x_evm_r5
am65x_evm_r5_usbdfu am65x_evm_r5_usbmsc am65x_hs_evm_r5
j7200_evm_r5 j721e_evm_r5 j721s2_evm_r5 verdin-am62_r5
am62ax_evm_a53 am62x_evm_a53 am64x_evm_a53 am65x_evm_a53
am65x_hs_evm_a53 j7200_evm_a72 j721e_evm_a72 j721s2_evm_a72
verdin-am62_a53
It looks like the .pem files are listed as top-level images, e.g.:
_pem {
filename = "../../ti/keys/custMpk.pem";
};
but if the only objective is to pick up an existing file, it is better to
set BINMAN_INDIRS to include that directory. Also we should only have
simple leafnames in the 'filename' property, so the '../../ti/keys' is not
correct. It makes it harder for people to get the files from other places.
Making this easier is one of binman's goals.
Most likely the custmpk_pem node can be removed and the .pem file can be
included directly in the place that needs it, e.g. by adjusting the
ti-secure-rom etype (or ex509_cert) to use tools.get_input_filename() when
reading the key file.
For example, this:
custMpk {
filename = "custMpk.pem";
custmpk_pem: blob-ext {
filename = "../keys/custMpk.pem";
};
};
is really just copying a file from '../keys/custMpk.pem' to 'custMpk.pem'
so is equivalent to:
custMpk {
type = "blob";
filename = "custMpk.pem";
}
(note that blob-ext implies that the blob may be missing, so blob is a
better choice, since the key cannot be missing)
The fact that the .pem files are at the top level means that they are
output images, which surely is not intended. They should be buried in the
image description, at a lower level, as part of something else.
So please take a loke at the above and see if the binman descriptions can
be reworked slightly to follow these new rules.
Simon Glass (6):
binman: Require image filenames to have certain extensions
buildman: Keep all permitted output files
buildman: Show progress when regenerating the board.cfg file
buildman: Start the clock when the build starts
kontron_sl28: Use u-boot-update.bin instead of u-boot.update
stm32mp15: Use u-boot-spl-stm32.bin instead of u-boot-spl.stm32
.../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 2 +-
arch/arm/dts/stm32mp15-u-boot.dtsi | 2 +-
doc/board/kontron/sl28.rst | 4 ++--
doc/board/st/stm32mp1.rst | 18 +-
include/configs/stm32mp15_dh_dhsom.h | 2 +-
tools/binman/binman.rst| 5 +
tools/binman/etype/section.py | 3 +--
tools/binman/ftest.py | 12 ++--
tools/binman/image.py | 9 +
tools/binman/test/022_image_name.dts | 4 ++--
tools/binman/test/311_bad_image_name.dts | 17 +
tools/buildman/boards.py | 15 ---
tools/buildman/builder.py | 3 ++-
tools/buildman/builderthread.py| 11 +++
tools/buildman/control.py | 3 ++-
15 files changed, 81 insertions(+), 29 deletions(-)
create mode 100644 tools/binman/test/311_bad_image_name.dts
--
2.42.0.rc1.204.g551eb34607-goog
Re: [PATCH V4 8/8] doc: board: ti: Add BeaglePlay documentation
Hi Nishanth, On Wed, 23 Aug 2023 at 18:18, Nishanth Menon wrote: > > On 17:57-20230823, Simon Glass wrote: > [...] > > > This is how we have a common bit of rST for how to build N boards, > > > without having to do a literal copy and paste N times. > > > > How about using this? > > > > https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#substitution-definitions > > I was not able to succeed with complex includes such as: > https://github.com/u-boot/u-boot/blob/master/doc/board/ti/am62x_sk.rst?plain=1#L89 > > am62x complete build procedure defined once and reused in other am62x > platforms.. But the am62x build procedure itself is reused from common > k3 build steps. I followed through these instructions. I find the env vars quite confusing, since I don't really know what it is doing. It feels like a script: do $a $b $c do $f $e it is pretty hard to follow. I think it would be better to write everything out in full for each board, like rockchip does. Some other minor feedback: - The 'make' lines should really have -j $(nproc) added - The $ signs at the start of each command in the docs are a pain since it stops me copying the commands into the terminal - can you remove them? - It doesn't build for me: BINMAN .binman_stamp Image 'ti-dm' is missing external blobs and is non-functional: blob-ext /binman/ti-dm/blob-ext (ti-dm/am62xx/ipc_echo_testb_mcu1_0_release_strip.xer5f): Missing blob Some images are invalid make[1]: *** [/scratch/sglass/cosarm/src/third_party/u-boot/files/Makefile:1115: .binman_stamp] Error 103 make[1]: Leaving directory '/tmp/b/play' make: *** [Makefile:177: sub-make] Error 2 Regards, Simon
Re: [PATCH 2/2] efi_loader: support boot from URI device path
On Thu, Aug 24, 2023 at 11:24:31AM +0900, AKASHI Takahiro wrote:
> Kojima-san,
>
> On Wed, Aug 23, 2023 at 05:37:20PM +0900, Masahisa Kojima wrote:
> > This supports to boot from the URI device path.
> > When user selects the URI device path, bootmgr downloads
> > the file using wget into the address specified by loadaddr
> > env variable.
> > If the file is .iso or .img file, mount the image with blkmap
> > then try to boot with the default file(e.g. EFI/BOOT/BOOTAA64.EFI).
> > If the file is .efi file, load and start the downloaded file.
>
> Is this behavior part of UEFI specification?
> Even so, it would be better to describe it in uefi.rst (or else),
> including URI usage.
>
> > Signed-off-by: Masahisa Kojima
> > ---
> > lib/efi_loader/efi_bootmgr.c | 213 +++
> > 1 file changed, 213 insertions(+)
> >
> > diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> > index a40762c74c..8b20f486f2 100644
> > --- a/lib/efi_loader/efi_bootmgr.c
> > +++ b/lib/efi_loader/efi_bootmgr.c
> > @@ -7,10 +7,14 @@
> >
> > #define LOG_CATEGORY LOGC_EFI
> >
> > +#include
> > +#include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -168,6 +172,209 @@ out:
> > return ret;
> > }
> >
> > +#if (IS_ENABLED(CONFIG_BLKMAP) && IS_ENABLED(CONFIG_CMD_WGET) &&
> > IS_ENABLED(CONFIG_CMD_DNS))
> > +/**
> > + * mount_image() - mount the image
> > + *
> > + * @lo_label label of load option
> > + * @file_size file size
> > + * @handle:pointer to handle for newly installed image
> > + * Return: status code
> > + */
> > +static efi_status_t mount_image(u16 *lo_label, int file_size,
> > + efi_handle_t *handle)
>
> I wonder why not adding "address" parameter to make this function
> more generic as Simon suggested.
>
> > +{
> > + int err;
> > + efi_status_t ret;
> > + char *label = NULL, *p;
> > + lbaint_t blknum;
> > + struct udevice *bm_dev;
> > + efi_handle_t bm_handle;
> > + struct udevice *blk, *partition;
> > + struct efi_handler *handler;
> > + struct efi_device_path *file_path;
> > + struct efi_device_path *device_path;
> > +
> > + label = efi_alloc(utf16_utf8_strlen(lo_label) + 1);
> > + if (!label)
> > + return EFI_OUT_OF_RESOURCES;
> > +
> > + p = label;
> > + utf16_utf8_strcpy(, lo_label);
> > + err = blkmap_create(label, NULL);
> > + if (err) {
> > + log_err("failed to create blkmap\n");
> > + ret = EFI_INVALID_PARAMETER;
> > + goto out;
> > + }
> > + bm_dev = blkmap_from_label(label);
> > + if (!bm_dev) {
> > + log_err("\"%s\" is not the name of any known blkmap\n", label);
> > + ret = EFI_INVALID_PARAMETER;
> > + goto out;
> > + }
> > +
> > + blknum = file_size / 512; /* TODO: don't use literal value. */
> > + err = blkmap_map_pmem(bm_dev, 0, blknum, image_load_addr);
> > + if (err) {
> > + log_err("Unable to map %#llx at block %d : %d\n",
> > + (unsigned long long)image_load_addr, 0, err);
> > + ret = EFI_INVALID_PARAMETER;
> > + goto out;
> > + }
> > + log_info("Block %d+0x" LBAF " mapped to %#llx\n", 0, blknum,
> > +(unsigned long long)image_load_addr);
> > +
> > + /* TODO: without calling this, partition devices are not binded. */
> > + blk_list_part(UCLASS_BLKMAP);
>
> I think that blkmap should provide a way to *probe* its child block
> device. In fact,
> struct blkmap *bm = dev_get_plat(bm_dev);
> device_probe(bm->blk);
> should work. (Not tested though)
>
> > +
> > + /*
> > +* Search the partition having EFI_SIMPLE_FILE_SYSTEM_PROTOCOL,
> > +* then try to load with the default boot file(e.g.
> > EFI/BOOT/BOOTAA64.EFI).
> > +*/
> > + device_foreach_child(blk, bm_dev)
>
> Does bm_dev have more than one block devices?
>
> > + {
> > + device_foreach_child(partition, blk)
> > + {
> > + if (dev_tag_get_ptr(partition, DM_TAG_EFI,
> > + (void **)_handle)) {
> > + log_warning("DM_TAG_EFI not found\n");
> > + continue;
> > + }
> > +
> > + ret = efi_search_protocol(
> > + bm_handle,
> > + _simple_file_system_protocol_guid,
> > + );
> > + if (ret != EFI_SUCCESS)
> > + continue;
> > +
> > + ret = efi_search_protocol(
> > + bm_handle, _guid_device_path, );
> > + if (ret != EFI_SUCCESS)
> > + continue;
> > +
> > + ret = efi_protocol_open(handler, (void **)_path,
> > + efi_root,
[PATCH] Convert CFG_SYS_UBOOT_START to Kconfig
Commit 65cc0e2a65d2 ("global: Move remaining CONFIG_SYS_* to CFG_SYS_*")
renamed CONFIG_SYS_UBOOT_START to CFG_SYS_UBOOT_START. Unfortunately,
this meant that the value was no longer available to the Makefile. This
caused imxrt to fail to boot. All the other boards that used this
variable were unaffected because they were using the default value
which is CONFIG_TEXT_BASE.
This commit converts CFG_SYS_UBOOT_START to Kconfig and sets the default
value to CONFIG_TEXT_BASE.
Suggested-by: Marek Vasut
Suggested-by: Tom Rini
Signed-off-by: Jesse Taube
---
Makefile | 16
arch/arm/mach-k3/config_secure.mk | 2 +-
arch/arm/mach-omap2/config_secure.mk | 2 +-
boot/Kconfig | 16
common/spl/spl.c | 6 +-
common/spl/spl_fit.c | 2 +-
configs/imxrt1020-evk_defconfig| 2 ++
configs/imxrt1050-evk_defconfig| 2 ++
configs/imxrt1170-evk_defconfig| 2 ++
include/configs/gardena-smart-gateway-mt7688.h | 4
include/configs/imxrt1020-evk.h| 6 --
include/configs/imxrt1050-evk.h| 6 --
include/configs/imxrt1170-evk.h| 3 ---
include/configs/linkit-smart-7688.h| 4
include/configs/mt7620.h | 3 ---
include/configs/mt7628.h | 3 ---
include/configs/mt8512.h | 2 --
include/configs/vocore2.h | 4
include/spl.h | 2 +-
19 files changed, 31 insertions(+), 56 deletions(-)
diff --git a/Makefile b/Makefile
index 9b90204bfe..13d4c63439 100644
--- a/Makefile
+++ b/Makefile
@@ -1364,14 +1364,6 @@ OBJCOPYFLAGS_u-boot.ldr.srec := -I binary -O srec
u-boot.ldr.hex u-boot.ldr.srec: u-boot.ldr FORCE
$(call if_changed,objcopy)
-#
-# U-Boot entry point, needed for booting of full-blown U-Boot
-# from the SPL U-Boot version.
-#
-ifndef CFG_SYS_UBOOT_START
-CFG_SYS_UBOOT_START := $(CONFIG_TEXT_BASE)
-endif
-
# Boards with more complex image requirements can provide an .its source file
# or a generator script
# NOTE: Please do not use this. We are migrating away from Makefile rules to
use
@@ -1391,7 +1383,7 @@ endif
ifdef CONFIG_SPL_LOAD_FIT
MKIMAGEFLAGS_u-boot.img = -f auto -A $(ARCH) -T firmware -C none -O u-boot \
- -a $(CONFIG_TEXT_BASE) -e $(CFG_SYS_UBOOT_START) \
+ -a $(CONFIG_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
-p $(CONFIG_FIT_EXTERNAL_OFFSET) \
-n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \
$(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(DEVICE_TREE))) \
@@ -1399,10 +1391,10 @@ MKIMAGEFLAGS_u-boot.img = -f auto -A $(ARCH) -T
firmware -C none -O u-boot \
$(patsubst %,-b arch/$(ARCH)/dts/%.dtbo,$(subst
",,$(CONFIG_OF_OVERLAY_LIST)))
else
MKIMAGEFLAGS_u-boot.img = -A $(ARCH) -T firmware -C none -O u-boot \
- -a $(CONFIG_TEXT_BASE) -e $(CFG_SYS_UBOOT_START) \
+ -a $(CONFIG_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
-n "U-Boot $(UBOOTRELEASE) for $(BOARD) board"
MKIMAGEFLAGS_u-boot-ivt.img = -A $(ARCH) -T firmware_ivt -C none -O u-boot \
- -a $(CONFIG_TEXT_BASE) -e $(CFG_SYS_UBOOT_START) \
+ -a $(CONFIG_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
-n "U-Boot $(UBOOTRELEASE) for $(BOARD) board"
u-boot-ivt.img: MKIMAGEOUTPUT = u-boot-ivt.img.log
endif
@@ -1433,7 +1425,7 @@ MKIMAGEFLAGS_u-boot.pbl = -n
$(srctree)/$(CONFIG_SYS_FSL_PBL_RCW:"%"=%) \
UBOOT_BIN := u-boot.bin
MKIMAGEFLAGS_u-boot-lzma.img = -A $(ARCH) -T standalone -C lzma -O u-boot \
- -a $(CONFIG_TEXT_BASE) -e $(CFG_SYS_UBOOT_START) \
+ -a $(CONFIG_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
-n "U-Boot $(UBOOTRELEASE) for $(BOARD) board"
u-boot.bin.lzma: u-boot.bin FORCE
diff --git a/arch/arm/mach-k3/config_secure.mk
b/arch/arm/mach-k3/config_secure.mk
index 7bc8af813a..9cc1f9eb24 100644
--- a/arch/arm/mach-k3/config_secure.mk
+++ b/arch/arm/mach-k3/config_secure.mk
@@ -30,7 +30,7 @@ tispl.bin_HS: $(obj)/u-boot-spl-nodtb.bin_HS $(patsubst
%,$(obj)/dts/%.dtb_HS,$(
$(call if_changed,mkfitimage)
MKIMAGEFLAGS_u-boot.img_HS = -f auto -A $(ARCH) -T firmware -C none -O u-boot \
- -a $(CONFIG_TEXT_BASE) -e $(CFG_SYS_UBOOT_START) \
+ -a $(CONFIG_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
-n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \
$(patsubst %,-b arch/$(ARCH)/dts/%.dtb_HS,$(subst ",,$(CONFIG_OF_LIST)))
diff --git a/arch/arm/mach-omap2/config_secure.mk
b/arch/arm/mach-omap2/config_secure.mk
index 24ddcdb961..f76262bb0c 100644
--- a/arch/arm/mach-omap2/config_secure.mk
+++ b/arch/arm/mach-omap2/config_secure.mk
@@ -102,7 +102,7 @@ u-boot_HS_XIP_X-LOADER: $(obj)/u-boot.bin FORCE
ifdef CONFIG_SPL_LOAD_FIT
MKIMAGEFLAGS_u-boot_HS.img = -f auto -A
Re: [PATCH 2/2] efi_loader: support boot from URI device path
Kojima-san,
On Wed, Aug 23, 2023 at 05:37:20PM +0900, Masahisa Kojima wrote:
> This supports to boot from the URI device path.
> When user selects the URI device path, bootmgr downloads
> the file using wget into the address specified by loadaddr
> env variable.
> If the file is .iso or .img file, mount the image with blkmap
> then try to boot with the default file(e.g. EFI/BOOT/BOOTAA64.EFI).
> If the file is .efi file, load and start the downloaded file.
Is this behavior part of UEFI specification?
Even so, it would be better to describe it in uefi.rst (or else),
including URI usage.
> Signed-off-by: Masahisa Kojima
> ---
> lib/efi_loader/efi_bootmgr.c | 213 +++
> 1 file changed, 213 insertions(+)
>
> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> index a40762c74c..8b20f486f2 100644
> --- a/lib/efi_loader/efi_bootmgr.c
> +++ b/lib/efi_loader/efi_bootmgr.c
> @@ -7,10 +7,14 @@
>
> #define LOG_CATEGORY LOGC_EFI
>
> +#include
> +#include
> #include
> #include
> +#include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -168,6 +172,209 @@ out:
> return ret;
> }
>
> +#if (IS_ENABLED(CONFIG_BLKMAP) && IS_ENABLED(CONFIG_CMD_WGET) &&
> IS_ENABLED(CONFIG_CMD_DNS))
> +/**
> + * mount_image() - mount the image
> + *
> + * @lo_label label of load option
> + * @file_sizefile size
> + * @handle: pointer to handle for newly installed image
> + * Return: status code
> + */
> +static efi_status_t mount_image(u16 *lo_label, int file_size,
> + efi_handle_t *handle)
I wonder why not adding "address" parameter to make this function
more generic as Simon suggested.
> +{
> + int err;
> + efi_status_t ret;
> + char *label = NULL, *p;
> + lbaint_t blknum;
> + struct udevice *bm_dev;
> + efi_handle_t bm_handle;
> + struct udevice *blk, *partition;
> + struct efi_handler *handler;
> + struct efi_device_path *file_path;
> + struct efi_device_path *device_path;
> +
> + label = efi_alloc(utf16_utf8_strlen(lo_label) + 1);
> + if (!label)
> + return EFI_OUT_OF_RESOURCES;
> +
> + p = label;
> + utf16_utf8_strcpy(, lo_label);
> + err = blkmap_create(label, NULL);
> + if (err) {
> + log_err("failed to create blkmap\n");
> + ret = EFI_INVALID_PARAMETER;
> + goto out;
> + }
> + bm_dev = blkmap_from_label(label);
> + if (!bm_dev) {
> + log_err("\"%s\" is not the name of any known blkmap\n", label);
> + ret = EFI_INVALID_PARAMETER;
> + goto out;
> + }
> +
> + blknum = file_size / 512; /* TODO: don't use literal value. */
> + err = blkmap_map_pmem(bm_dev, 0, blknum, image_load_addr);
> + if (err) {
> + log_err("Unable to map %#llx at block %d : %d\n",
> + (unsigned long long)image_load_addr, 0, err);
> + ret = EFI_INVALID_PARAMETER;
> + goto out;
> + }
> + log_info("Block %d+0x" LBAF " mapped to %#llx\n", 0, blknum,
> + (unsigned long long)image_load_addr);
> +
> + /* TODO: without calling this, partition devices are not binded. */
> + blk_list_part(UCLASS_BLKMAP);
I think that blkmap should provide a way to *probe* its child block
device. In fact,
struct blkmap *bm = dev_get_plat(bm_dev);
device_probe(bm->blk);
should work. (Not tested though)
> +
> + /*
> + * Search the partition having EFI_SIMPLE_FILE_SYSTEM_PROTOCOL,
> + * then try to load with the default boot file(e.g.
> EFI/BOOT/BOOTAA64.EFI).
> + */
> + device_foreach_child(blk, bm_dev)
Does bm_dev have more than one block devices?
> + {
> + device_foreach_child(partition, blk)
> + {
> + if (dev_tag_get_ptr(partition, DM_TAG_EFI,
> + (void **)_handle)) {
> + log_warning("DM_TAG_EFI not found\n");
> + continue;
> + }
> +
> + ret = efi_search_protocol(
> + bm_handle,
> + _simple_file_system_protocol_guid,
> + );
> + if (ret != EFI_SUCCESS)
> + continue;
> +
> + ret = efi_search_protocol(
> + bm_handle, _guid_device_path, );
> + if (ret != EFI_SUCCESS)
> + continue;
> +
> + ret = efi_protocol_open(handler, (void **)_path,
> + efi_root, NULL,
> + EFI_OPEN_PROTOCOL_GET_PROTOCOL);
> + if (ret != EFI_SUCCESS)
> + continue;
> +
> + file_path =
Re: [PATCH 7/8] spl: x86: Avoid starting up PCI automatically in SPL
Am 24. August 2023 01:57:55 MESZ schrieb Simon Glass :
>Hi Heinrich,
>
>On Wed, 23 Aug 2023 at 14:19, Heinrich Schuchardt wrote:
>>
>> On 8/23/23 20:47, Simon Glass wrote:
>> > For x86 platforms, PCI is core to their operation and is managed in
>> > arch-specific code. Each platform has its own way of doing this. For TPL
>> > and some SPL implementations, the full driver model PCI is not used.
>> >
>> > A recent change enabled full PCI in TPL/SPL for all boards. This breaks
>> > some x86 boards, so adjust it to skip that for x86.
>>
>> Could you, please, give some more detail?
>>
>> * Which boards are broken?
>
>For example, chromebook_samus and chromebook_samus_tpl
>
>> * Don't these boards have a pci_init() function?
>
>Yes, the same one you are calling.
>
>> * In what way does calling pci_init() lead to a failure?
>
>It probes and sets up PCI devices and uses a lot of pre-alloc RAM.
>
>>
>> It would be preferable to have all architectures and boards use the same
>> high level API. Excluding x86 here looks more like a (necessary) hack
>> than like a target state.
>
>Fair enough, but on x86 we access PCI long before driver model is up.
>Generally we don't fully enumerate it in SPL as it is expensive. It is
>also pointless, since U-Boot proper does it again later.
>
>Regards,
>Simon
>
Acked-by: Heinrich Schuchardt
>
>>
>> Best regards
>>
>> Heinrich
>>
>> >
>> > Signed-off-by: Simon Glass
>> > ---
>> >
>> > common/spl/spl.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/common/spl/spl.c b/common/spl/spl.c
>> > index 0062f3f45d9..13d7b1a742f 100644
>> > --- a/common/spl/spl.c
>> > +++ b/common/spl/spl.c
>> > @@ -800,7 +800,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
>> > IS_ENABLED(CONFIG_SPL_ATF))
>> > dram_init_banksize();
>> >
>> > - if (CONFIG_IS_ENABLED(PCI)) {
>> > + if (CONFIG_IS_ENABLED(PCI) && !IS_ENABLED(CONFIG_X86)) {
>> > ret = pci_init();
>> > if (ret)
>> > puts(SPL_TPL_PROMPT "Cannot initialize PCI\n");
>>
[PATCH 2/2] Revert "binman: Add a temporary hack for duplicate phandles"
The affected boards have been fixed, so drop this hack.
This reverts commit 288ae53cb73605500b7fc01e5919753c878466be.
Signed-off-by: Simon Glass
---
Makefile| 6 --
tools/binman/cmdline.py | 2 --
tools/binman/control.py | 5 -
tools/dtoc/fdt.py | 12
4 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/Makefile b/Makefile
index 9b90204bfe6b..033daf1695c0 100644
--- a/Makefile
+++ b/Makefile
@@ -1328,11 +1328,6 @@ u-boot.ldr: u-boot
# Use 'make BINMAN_VERBOSE=3' to set vebosity level
default_dt := $(if $(DEVICE_TREE),$(DEVICE_TREE),$(CONFIG_DEFAULT_DEVICE_TREE))
-# Temporary workaround for Venice boards
-ifneq
($(CONFIG_TARGET_IMX8MM_VENICE),$(CONFIG_TARGET_IMX8MN_VENICE),$(CONFIG_TARGET_IMX8MP_VENICE),)
-ignore_dups := --ignore-dup-phandles
-endif
-
quiet_cmd_binman = BINMAN $@
cmd_binman = $(srctree)/tools/binman/binman $(if $(BINMAN_DEBUG),-D) \
$(foreach f,$(BINMAN_TOOLPATHS),--toolpath $(f)) \
@@ -1354,7 +1349,6 @@ cmd_binman = $(srctree)/tools/binman/binman $(if
$(BINMAN_DEBUG),-D) \
-a spl-dtb=$(CONFIG_SPL_OF_REAL) \
-a tpl-dtb=$(CONFIG_TPL_OF_REAL) \
-a pre-load-key-path=${PRE_LOAD_KEY_PATH} \
- $(ignore_dups) \
$(BINMAN_$(@F))
OBJCOPYFLAGS_u-boot.ldr.hex := -I binary -O ihex
diff --git a/tools/binman/cmdline.py b/tools/binman/cmdline.py
index 39c61c2c0322..9632ec115e5d 100644
--- a/tools/binman/cmdline.py
+++ b/tools/binman/cmdline.py
@@ -126,8 +126,6 @@ controlled by a description in the board device tree.'''
help='Comma-separated list of bintools to consider missing (for
testing)')
build_parser.add_argument('-i', '--image', type=str, action='append',
help='Image filename to build (if not specified, build all)')
-build_parser.add_argument('--ignore-dup-phandles', action='store_true',
-help='Temporary option to ignore duplicate phandles')
build_parser.add_argument('-I', '--indir', action='append',
help='Add a path to the list of directories to use for input
files')
build_parser.add_argument('-m', '--map', action='store_true',
diff --git a/tools/binman/control.py b/tools/binman/control.py
index 459489558125..c6d3205b8c25 100644
--- a/tools/binman/control.py
+++ b/tools/binman/control.py
@@ -22,7 +22,6 @@ from binman import bintool
from binman import cbfs_util
from binman import elf
from binman import entry
-from dtoc import fdt
from dtoc import fdt_util
from u_boot_pylib import command
from u_boot_pylib import tools
@@ -817,10 +816,6 @@ def Binman(args):
cbfs_util.VERBOSE = args.verbosity > 2
state.use_fake_dtb = args.fake_dtb
-# Temporary hack
-if args.ignore_dup_phandles: # pragma: no cover
-fdt.IGNORE_DUP_PHANDLES = True
-
# Normally we replace the 'u-boot' etype with 'u-boot-expanded', etc.
# When running tests this can be disabled using this flag. When not
# updating the FDT in image, it is not needed by binman, but we use it
diff --git a/tools/dtoc/fdt.py b/tools/dtoc/fdt.py
index 0b20d52f3136..5963925146a5 100644
--- a/tools/dtoc/fdt.py
+++ b/tools/dtoc/fdt.py
@@ -15,9 +15,6 @@ from libfdt import QUIET_NOTFOUND
from u_boot_pylib import tools
from u_boot_pylib import tout
-# Temporary hack
-IGNORE_DUP_PHANDLES = False
-
# This deals with a device tree, presenting it as an assortment of Node and
# Prop objects, representing nodes and properties, respectively. This file
# contains the base classes and defines the high-level API. You can use
@@ -342,11 +339,10 @@ class Node:
if phandle:
dup = self._fdt.phandle_to_node.get(phandle)
if dup:
-if not IGNORE_DUP_PHANDLES:
-raise ValueError(
-f'Duplicate phandle {phandle} in nodes {dup.path} and
{self.path}')
-else:
-self._fdt.phandle_to_node[phandle] = self
+raise ValueError(
+f'Duplicate phandle {phandle} in nodes {dup.path} and
{self.path}')
+
+self._fdt.phandle_to_node[phandle] = self
offset = fdt_obj.first_subnode(self.Offset(), QUIET_NOTFOUND)
while offset >= 0:
--
2.42.0.rc1.204.g551eb34607-goog
[PATCH 1/2] imx: Drop unneeded phandle in FIT template
Adding a phandle to a template node is not allowed, since when the node is
instantiated multiple times, we end up with duplicate phandles.
Drop this invalid constructs.
Signed-off-by: Simon Glass
---
arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi | 2 ++
arch/arm/dts/imx8mm-u-boot.dtsi | 2 +-
arch/arm/dts/imx8mn-u-boot.dtsi | 2 +-
arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi| 2 ++
arch/arm/dts/imx8mp-u-boot.dtsi | 4 ++--
arch/arm/dts/imx8qm-u-boot.dtsi | 2 +-
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 8
7 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
b/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
index 484e31824b85..d93e1cbd8a71 100644
--- a/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-cl-iot-gate-optee-u-boot.dtsi
@@ -41,9 +41,11 @@
};
};
+/* This cannot work since it refers to a template node
_configuration {
loadables = "atf", "fip";
};
+*/
{
phy-reset-gpios = < 22 GPIO_ACTIVE_LOW>;
diff --git a/arch/arm/dts/imx8mm-u-boot.dtsi b/arch/arm/dts/imx8mm-u-boot.dtsi
index 035282bf0b00..6085128e24ec 100644
--- a/arch/arm/dts/imx8mm-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-u-boot.dtsi
@@ -140,7 +140,7 @@
configurations {
default = "@config-DEFAULT-SEQ";
- binman_configuration: @config-SEQ {
+ @config-SEQ {
description = "NAME";
fdt = "fdt-SEQ";
firmware = "uboot";
diff --git a/arch/arm/dts/imx8mn-u-boot.dtsi b/arch/arm/dts/imx8mn-u-boot.dtsi
index 5046b38e4e29..bc57566a108f 100644
--- a/arch/arm/dts/imx8mn-u-boot.dtsi
+++ b/arch/arm/dts/imx8mn-u-boot.dtsi
@@ -204,7 +204,7 @@
configurations {
default = "@config-DEFAULT-SEQ";
- binman_configuration: @config-SEQ {
+ @config-SEQ {
description = "NAME";
fdt = "fdt-SEQ";
firmware = "uboot";
diff --git a/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi
b/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi
index f3fb44046d5c..c4ea536b29bb 100644
--- a/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi
@@ -162,6 +162,8 @@
};
};
+/* This cannot work since it refers to a template node
_configuration {
loadables = "atf", "fip";
};
+*/
diff --git a/arch/arm/dts/imx8mp-u-boot.dtsi b/arch/arm/dts/imx8mp-u-boot.dtsi
index 36e7444a627b..200938a98072 100644
--- a/arch/arm/dts/imx8mp-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-u-boot.dtsi
@@ -146,7 +146,7 @@
type = "flat_dt";
compression = "none";
- uboot_fdt_blob: blob-ext {
+ blob-ext {
filename = "u-boot.dtb";
};
};
@@ -155,7 +155,7 @@
configurations {
default = "@config-DEFAULT-SEQ";
- binman_configuration: @config-SEQ {
+ @config-SEQ {
description = "NAME";
fdt = "fdt-SEQ";
firmware = "uboot";
diff --git a/arch/arm/dts/imx8qm-u-boot.dtsi b/arch/arm/dts/imx8qm-u-boot.dtsi
index a3e0af48109b..d316e869516f 100644
--- a/arch/arm/dts/imx8qm-u-boot.dtsi
+++ b/arch/arm/dts/imx8qm-u-boot.dtsi
@@ -112,7 +112,7 @@
configurations {
default = "@config-DEFAULT-SEQ";
- binman_configuration: @config-SEQ {
+ @config-SEQ {
description = "NAME";
fdt = "fdt-SEQ";
firmware = "uboot";
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 3ecb461b0110..64318d09cf0a 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -41,7 +41,7 @@
os = "arm-trusted-firmware";
load = ;
entry = ;
- atf: atf-bl31 {
+ atf-bl31 {
};
Re: [PATCH] arm: dts: j7200: dtb sync with Linux 6.5-rc1
On 15:01-20230823, reidt wrote:
[...]
> > _ringacc {
> > bootph-pre-ram;
> > };
> > NOTE: you only need to override reg-names and reg in R5.dtsi not
> > u-boot.dtsi.
> >
> > _udmap {
> > bootph-pre-ram;
> > };
>
> I saw you mentioned at [0] that mcu_ringacc (and I assume mcu_udmap)
> need to be retained for now. If moved to r5.dts, something breaks, as dhcp
> fails then [1]. Should the full nodes remain for now until 6.6-rc1 sync? I'll
> still take them outside of mcu_navss.
>
> [0] https://lore.kernel.org/all/20230816114445.c4c7rgdp5arhmiaq@polyester/
> [1] https://gist.github.com/Glockn/f0cf1ae8f8fd92e70f4e798c6221e81a
True.. But, I understand the overrides are only for the R5 usage
when DM is'nt around to support us. So, yes override it in R5 dts - Now
why without a A72 override it breaks is beyond me and I'd suggest poking
Vignesh or someone more knowledgable about DMA/CPSW for help there.
[..]
> > > _i2c0 {
> > > bootph-pre-ram;
> > > +
> > > + lp876441: lp876441@4c {
> >
> > NAK. Why is this new stuff coming in -> should'nt be here.
> >
>
> This was left because _vtm0 uses _reg below which isn't apart
> of the kernel dt files.
Please send it upstream kernel. What breaks if we keep that out of tree?
My vague recollection is avs0 is mandatory for j7200?
>
> >
> > hbmc -> arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi: flash@0,0 weird
> > that does'nt throw a dtbs_check warning
> >
> > WARNING: u-boot,mux-autoprobe -> this is'nt supported.
> >
>
> change these to bootph-pre-ram?
No, I was just surprised to see a new u-boot property.. dont really know
what it does. I doubt switching it to bootph-pre-ram will work there.
[...]
> > > -_i2c0 {
> > > - bootph-pre-ram;
> > > - lp876441: lp876441@4c {
> > > - compatible = "ti,lp876441";
> >
> > There is no such driver in linux kernel compatible space. might need a
> > ticket to implement the driver.
> >
>
> Interesting - I'll look into it. Makes me wonder about the buck1_reg for
> wkup_vtm0 and what's going on there.
Alright - checkout AVS0 - maybe Keerthy or someone can help guide.
[..]
> > > };
> > >
> > > _vtm0 {
> > > + compatible = "ti,am654-vtm", "ti,j721e-avs";
> >
> > _vtm0 -> there is already stuff coming in from kernel. why
> > do we need to define our own compatible "ti,am654-vtm", "ti,j721e-avs"?
> > there is already compatible = "ti,j7200-vtm"; if we need to fix the
> > driver as part of the series, please do as a path in the series.
> >
>
> ti,j7200-vtm doesn't work and throws a "AVS init failed: -19", so i'll
> work on that. The compatible I used was taken from our TI u-boot
Sounds like a driver fixup needed in u-boot to match up with the
compatible that was accepted in upstream kernel. Also the classic
reason why we are now insisting that the device tree come in from
kernel pristine.
[...]
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH V4 8/8] doc: board: ti: Add BeaglePlay documentation
On 17:57-20230823, Simon Glass wrote: [...] > > This is how we have a common bit of rST for how to build N boards, > > without having to do a literal copy and paste N times. > > How about using this? > > https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#substitution-definitions I was not able to succeed with complex includes such as: https://github.com/u-boot/u-boot/blob/master/doc/board/ti/am62x_sk.rst?plain=1#L89 am62x complete build procedure defined once and reused in other am62x platforms.. But the am62x build procedure itself is reused from common k3 build steps. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v2 00/10] Introduce initial TI's J784S4 support
On 17:09-20230823, Hari Nagalla wrote: > On 8/22/23 03:18, Enric Balletbo i Serra wrote: > > > * Temperature sensors, user push buttons and LEDs > > > * 40-pin User Expansion Connector > > > * x2 ENET Expansion Connector, x1 GESI expander, x2 Display connector > > > * x1 15-pin CSI header > > > * x6 MCAN instances > > > > > > Schematics:https://www.ti.com/lit/zip/sprr458 > > > > > > bootlog:https://paste.sr.ht/~hnagalla/f14840abc854519f912923662f1fdc8075d92107 > > > > > Many thanks for this patchset. > > > > There is any plan to rebase all this patchset, fix the comments and > > send it again to upstream? I'd be really interested in help on this > > patchset. > > > > Thanks, > >Enric > > > Hi Enric, > > Yes, we will rebase and send the patch set shortly. > > Sorry for the delay. Let us ensure we have the proper cleanups done for other platforms, documentation AND bootstd support as default. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 1/2] cmd: efidebug: add uri device path
Hi Kojima-san,
On Wed, Aug 23, 2023 at 05:37:19PM +0900, Masahisa Kojima wrote:
> This adds the URI device path option for 'boot add' subcommand.
> User can add the URI load option for downloading ISO image file
> or EFI application through network(e.g. HTTP).
>
> Signed-off-by: Masahisa Kojima
> ---
> cmd/efidebug.c | 39 +++
> 1 file changed, 39 insertions(+)
>
> diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> index 0be3af3e76..62f867df2a 100644
> --- a/cmd/efidebug.c
> +++ b/cmd/efidebug.c
> @@ -829,6 +829,44 @@ static int do_efi_boot_add(struct cmd_tbl *cmdtp, int
> flag,
> argc -= 1;
> argv += 1;
> break;
> + case 'u':
> + {
> + char *pos;
> + int uridp_len;
> + struct efi_device_path_uri *uridp;
> +
> + if (argc < 3 || lo.label) {
> + r = CMD_RET_USAGE;
> + goto out;
> + }
> + id = (int)hextoul(argv[1], );
> + if (*endp != '\0' || id > 0x)
> + return CMD_RET_USAGE;
> +
> + efi_create_indexed_name(var_name16, sizeof(var_name16),
> + "Boot", id);
> +
> + label = efi_convert_string(argv[2]);
> + if (!label)
> + return CMD_RET_FAILURE;
> + lo.label = label;
> +
> + uridp_len = sizeof(struct efi_device_path) +
> strlen(argv[3]) + 1;
> + fp_free = efi_alloc(uridp_len + sizeof(END));
> + uridp = (struct efi_device_path_uri *)fp_free;
> + uridp->dp.type = DEVICE_PATH_TYPE_MESSAGING_DEVICE;
> + uridp->dp.sub_type = DEVICE_PATH_SUB_TYPE_MSG_URI;
> + uridp->dp.length = uridp_len;
> + strcpy(uridp->uri, argv[3]);
> + pos = (char *)uridp + uridp_len;
> + memcpy(pos, , sizeof(END));
> + fp_size += uridp_len + sizeof(END);
> + file_path = (struct efi_device_path *)uridp;
> + argc -= 3;
> + argv += 3;
> + break;
> + }
> +
> default:
> r = CMD_RET_USAGE;
> goto out;
> @@ -1492,6 +1530,7 @@ static char efidebug_help_text[] =
> " -b|-B[:] \n"
> " -i|-I [:] \n"
> " (-b, -i for short form device path)\n"
> + " -u \n"
It might be a matter of personal preference, but
since the current syntax of efidebug is already much complex,
I don't want to add more options unless it's necessary.
How about re-using "-B" option, say
=> efidebug -B 3 debian-netinst uri - https://foo.com/baa
BTW, I think that and should have been moved out of "-b|B"
when Ilias introduced this new syntax.
-Takahiro Akashi
> " -s ''\n"
> "efidebug boot rm [ [ [...]]]\n"
> " - delete UEFI Boot variables\n"
> --
> 2.34.1
>
Re: [PATCH] test: dm: test-fdt: Use fdtdec_get_int() in dm_check_devices()
On Wed, 23 Aug 2023 at 13:38, Marek Vasut wrote: > > The current fdtdec_get_addr() takes into consideration #address-cells > and #size-cells for "ping-expect" property which is clearly neither. > Use fdtdec_get_int() instead and return negative one in case the > property is not in DT or the platform under test is not DT based, > i.e. mimic the current fdtdec_get_addr() behavior. > > This fixes ut dm dm_test_bus_children test. > > Signed-off-by: Marek Vasut > --- > Cc: Mario Six > Cc: Simon Glass > --- > test/dm/test-fdt.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH v2 2/8] doc: Add gpt command documentation
Hi Joshua,
On Wed, 23 Aug 2023 at 10:48, Joshua Watt wrote:
>
> Adds initial documentation for the gpt command
>
> Signed-off-by: Joshua Watt
> ---
> doc/usage/cmd/gpt.rst | 139 ++
> 1 file changed, 139 insertions(+)
> create mode 100644 doc/usage/cmd/gpt.rst
>
> diff --git a/doc/usage/cmd/gpt.rst b/doc/usage/cmd/gpt.rst
> new file mode 100644
> index 00..ea2cf73a60
> --- /dev/null
> +++ b/doc/usage/cmd/gpt.rst
> @@ -0,0 +1,139 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +gpt command
> +===
> +
> +Synopsis
> +
> +
> +::
> +
> +gpt repair
> +gpt write
> +gpt verify
> +gpt setenv
> +gpt enumerate
> +gpt guid []
> +gpt read []
> +gpt swap
> +gpt rename
> +
> +Description
> +---
> +
> +The gpt command lets users read, create, modify, or verify the GPT (GUID
> +Partition Table) partition layout.
> +
> +The syntax of the text description of the partition list is similar to
By 'text description' do you mean '' ?
> +the one used by the 'mbr' command.
OK, but I think you need to show the string as a list of
semicolon-separated components (or whatever) and then describe them.
As written, this is quite confusing.
> +
> +The partition list may start with a set of parameters for the whole disk:
> +
> +* uuid_disk (the UUID of the disk)
> +
> +Following the disk parameters, partitions are specified separated by a ';'.
> +Supported partition parameters are:
> +
> +* name (required)
> +* start (required, partition start offset in bytes)
> +* size (in bytes or '-' to expand it to the whole free area)
> +* bootable (boolean flag)
> +* uuid (partition UUID, optional if CONFIG_RANDOM_UUID=y is enabled)
> +* type (partition type GUID, requires CONFIG_PARTITION_TYPE_GUID=y)
> +
> +Here is an example how to create a 6 partitions, some of the predefined
> sizes:
> +
> +::
> +
> +=> setenv gpt_parts 'uuid_disk=bec9fc2a-86c1-483d-8a0e-0109732277d7;
> +
> name=boot,start=4M,size=128M,bootable,type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7,
> +name=rootfs,size=3072M,type=0FC63DAF-8483-4772-8E79-3D69D8477DE4;
> +name=system-data,size=512M,type=0FC63DAF-8483-4772-8E79-3D69D8477DE4;
> +name=[ext],size=-,type=0FC63DAF-8483-4772-8E79-3D69D8477DE4;
> +name=user,size=-,type=0FC63DAF-8483-4772-8E79-3D69D8477DE4;
> +name=modules,size=100M,type=0FC63DAF-8483-4772-8E79-3D69D8477DE4;
> +name=ramdisk,size=8M,type=0FC63DAF-8483-4772-8E79-3D69D8477DE4
> +=> gpt write mmc 0 $gpt_parts
Please use lower-case hex
> +
> +
> +If 'uuid' is not specified, but CONFIG_RANDOM_UUID is enabled, a random UUID
> +will be generated for the partition
> +
> +The 'gpt verify' command returns 0 if the layout matches the one on the
> storage
> +device or 1 if not. To check if the layout on the MMC #0 storage device
> +matches the provided text description one has to issue following command:
> +
> +::
> +
> +=> gpt verify mmc 0 $gpt_parts
> +
> +The verify sub-command is especially useful in the system update scripts:
> +
> +::
> +
> +=> if gpt verify mmc 0 $gpt_parts; then
> + echo GPT layout needs to be updated
> + ...
> + fi
> +
> +The 'gpt write' command returns 0 on success write or 1 on failure.
> +
> +The 'gpt setenv' command will set a series of environment variables with
> +information about a particular partition. The variables are:
> +
> +* gpt_partition_addr (the starting offset of the partition, in hexadecimal
> blocks)
> +* gpt_partition_size (the size of the partition, in hexadecimal blocks)
> +* gpt_partition_name (the name of the partition)
> +* gpt_partition_entry (the partition number in the table, e.g. 1, 2, 3, etc.)
> +
> +To get the information about the partition named 'rootfs', issue the
> following
> +command:
> +
> +::
> +=> gpt setenv mmc 0 rootfs
> +=> echo ${gpt_partition_addr}
> +2000
> +=> echo ${gpt_partition_size}
> +14a000
> +=> echo ${gpt_partition_name}
> +rootfs
> +=> echo ${gpt_partition_entry}
> +2
> +
> +The 'gpt enumerate' command will set the variable 'gpt_partition_list' with
> the
> +list of partition names on the device. For example:
> +
> +::
> +=> gpt enumerate
> +=> echo gpt_partition_list
> +boot rootfs system-data [ext] user modules ramdisk
> +
> +The 'gpt guid' command will report the GUID of a disk. If 'varname' is
> +specified, the command will set the variable to the GUID, otherwise it will
> be
> +printed out. For example:
> +
> +::
> +=> gpt guid mmc 0
> +bec9fc2a-86c1-483d-8a0e-0109732277d7
> +=> gpt guid mmc gpt_disk_uuid
> +=> echo ${gpt_disk_uuid}
> +bec9fc2a-86c1-483d-8a0e-0109732277d7
> +
> +The 'gpt read' command will print out the current state of the GPT partition
> +table. If 'varname' is specified, the variable will be filled with a
> partition
> +string as described above that is suitable for
Re: [PATCH v2 1/1] doc: describe TPL/VPL/SPL boot
Hi Heinrich, On Wed, 23 Aug 2023 at 15:49, Heinrich Schuchardt wrote: > > This is a stub describing how TPL, VPL, and SPL load the next boot stages > on a detail level for users. > > For sure we will need a few patches on top to catch the whole complexity. > > Signed-off-by: Heinrich Schuchardt > --- > v2: > Mention that PowerPC uses a different naming convention. > Group boot devices by type > Correct reference to UBI > Fix typos > --- > doc/usage/index.rst| 1 + > doc/usage/spl_boot.rst | 321 + > 2 files changed, 322 insertions(+) > create mode 100644 doc/usage/spl_boot.rst > > diff --git a/doc/usage/index.rst b/doc/usage/index.rst > index 072db53614..7f0b26cc5a 100644 > --- a/doc/usage/index.rst > +++ b/doc/usage/index.rst > @@ -4,6 +4,7 @@ Use U-Boot > .. toctree:: > :maxdepth: 1 > > + spl_boot > blkmap > dfu > environment > diff --git a/doc/usage/spl_boot.rst b/doc/usage/spl_boot.rst > new file mode 100644 > index 00..7234d0b1b2 > --- /dev/null > +++ b/doc/usage/spl_boot.rst > @@ -0,0 +1,321 @@ > +.. SPDX-License-Identifier: GPL-2.0-or-later > + > +Booting from TPL/SPL > + > + > +The main U-Boot binary may be too large to be loaded directly by the Boot > ROM. > +This was the own driver for splitting up U-Boot into multiple boot stages. s/own/original/ ? > + > +U-Boot typically goes through the following boot phases where TPL, VPL, and > SPL > +are optional. While many boards use SPL only few use TPL. > + > +TPL > + Tiny program loader. Very early init, as tiny as possible. This loads SPL > + (or VPL if enabled). Oh I thought that was tertiary! It helps us if we need yes another one later...but if we go with Tiny, let's fix it everywhere. > + > +VPL verifying program loader > + Optional verification step, which can select one of several SPL binaries, > + if A/B verified boot is enabled. Implementation of the VPL logic is > + work-in-progress. For now it just boots into SPL. > + > +SPL > + Secondary program loader. Sets up SDRAM and loads U-Boot proper. It may > also > + load other firmware components. > + > +U-Boot > + U-Boot proper, containing the command line and the logic to load an > + operating system, e.g. via UEFI. > + > +The naming convention on the PowerPC architecture deviates from the other > +archtitectures. Here the boot sequence is SPL->TPL->U-Boot. > + > +Only main U-Boot has a command line interface. > + > +Further usages for U-Boot SPL comprise: > + > +* launching BL31 of ARM Trusted Firmware which invokes U-Boot as BL33 > +* launching EDK II > +* launching Linux > +* launching RISC-V OpenSBI which invokes main U-Boot > + > +Target binaries > +--- > + > +Binaries loaded by SPL/TPL can be: > + > +* raw binaries where the entry address equals the start address. This is the > + only binary format supported by TPL. > +* :doc:`FIT ` images > +* legacy U-Boot images > + > +Configuration > +~ > + > +Raw images are only supported in SPL if CONFIG_SPL_RAW_IMAGE_SUPPORT=y. I think it is better to drop the =y stuff on these. > + > +CONFIG_SPL_FIT=y and CONFIG_SPL_LOAD_FIT=y are needed to load FIT images. > + > +CONFIG_SPL_LEGACY_IMAGE_FORMAT=y is needed to load legacy U-Boot images. > +CONFIG_SPL_LEGACY_IMAGE_CRC_CHECK=y enables checking the CRC32 of legacy > U-Boot > +images. > + > +Image load methods > +-- > + > +The image boot methods available for a board must be defined in two places: > + > +The board code implements a function board_boot_order() enumerating up to > +five boot methods and the sequence in which they are tried. (The maximum > +number of boot methods is currently hard coded as variable spl_boot_list[]). > +If there is only one boot method function, spl_boot_device() may be > implemented > +instead. > + > +The configuration controls which of these boot methods are actually > available. > + > +Loading from block devices > +~~ > + > +MMC1, MMC2, MMC2_2 > +These methods read an image from SD card or eMMC. The first digit after > +'MMC' indicates the device number. Required configuration settings > include: > + > +* CONFIG_SPL_MMC=y or CONFIG_TPL_MMC=y > + > +To use a PCI connected MMC controller you need to additionally specify: > + > +* CONFIG_SPL_PCI=y > + > +* CONFIG_SPL_PCI_PNP=y > + > +* CONFIG_MMC=y > + > +* CONFIG_MMC_PCI=y > + > +* CONFIG_MMC_SDHCI=y > + > +To load from a file system use: > + > +* CONFIG_SPL_FS_FAT=y or CONFIG_SPL_FS_EXT=y > + > +* CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="" > + > +NVMe > +This methods load the image from an NVMe drive. > +Required configuration settings include: > + > +* CONFIG_SPL_PCI=y > + > +* CONFIG_SPL_PCI_PNP=y > + > +* CONFIG_SPL_NVME=y > + > +* CONFIG_SPL_NVME_PCI=y > + > +* CONFIG_SPL_NVME_BOOT_DEVICE (number of the NVMe device) > + > +
Re: [PATCH 7/8] spl: x86: Avoid starting up PCI automatically in SPL
Hi Heinrich,
On Wed, 23 Aug 2023 at 14:19, Heinrich Schuchardt wrote:
>
> On 8/23/23 20:47, Simon Glass wrote:
> > For x86 platforms, PCI is core to their operation and is managed in
> > arch-specific code. Each platform has its own way of doing this. For TPL
> > and some SPL implementations, the full driver model PCI is not used.
> >
> > A recent change enabled full PCI in TPL/SPL for all boards. This breaks
> > some x86 boards, so adjust it to skip that for x86.
>
> Could you, please, give some more detail?
>
> * Which boards are broken?
For example, chromebook_samus and chromebook_samus_tpl
> * Don't these boards have a pci_init() function?
Yes, the same one you are calling.
> * In what way does calling pci_init() lead to a failure?
It probes and sets up PCI devices and uses a lot of pre-alloc RAM.
>
> It would be preferable to have all architectures and boards use the same
> high level API. Excluding x86 here looks more like a (necessary) hack
> than like a target state.
Fair enough, but on x86 we access PCI long before driver model is up.
Generally we don't fully enumerate it in SPL as it is expensive. It is
also pointless, since U-Boot proper does it again later.
Regards,
Simon
>
> Best regards
>
> Heinrich
>
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > common/spl/spl.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/common/spl/spl.c b/common/spl/spl.c
> > index 0062f3f45d9..13d7b1a742f 100644
> > --- a/common/spl/spl.c
> > +++ b/common/spl/spl.c
> > @@ -800,7 +800,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> > IS_ENABLED(CONFIG_SPL_ATF))
> > dram_init_banksize();
> >
> > - if (CONFIG_IS_ENABLED(PCI)) {
> > + if (CONFIG_IS_ENABLED(PCI) && !IS_ENABLED(CONFIG_X86)) {
> > ret = pci_init();
> > if (ret)
> > puts(SPL_TPL_PROMPT "Cannot initialize PCI\n");
>
Re: [PATCH v1 15/19] ARM: tegra: board2: add generic late init
Hi Svyatoslav,
On Tue, 22 Aug 2023 at 05:25, Svyatoslav Ryhel wrote:
>
> Board specific late init allows vendors to set up different device
> or board specific env variables (like serial number, platform name).
> In case this information is missing, u-boot will lack info regards
> serial or platform.
>
> To avoid this prior nvidia_board_late_init internal generic function
> is called which fills required data. In this case platform name is
> obtained from get_chip and serialno is filled with SoC id.
>
> Though SoC id is not dedicated to be devices serial but it fits well
> in case of restriction of data about device and since SoC is basically
> a main chip of the device.
>
> Tested-by: Andreas Westman Dorcsak # ASUS Transformers
> Tested-by: Svyatoslav Ryhel # Nvidia Tegratab
> Signed-off-by: Svyatoslav Ryhel
> ---
> arch/arm/mach-tegra/board2.c | 43
> 1 file changed, 43 insertions(+)
>
> diff --git a/arch/arm/mach-tegra/board2.c b/arch/arm/mach-tegra/board2.c
> index 981768bb0e..ee69cb657a 100644
> --- a/arch/arm/mach-tegra/board2.c
> +++ b/arch/arm/mach-tegra/board2.c
> @@ -26,6 +26,10 @@
> #include
> #include
> #include
> +#ifndef CONFIG_TEGRA186
> +#include
> +#include
> +#endif
> #if IS_ENABLED(CONFIG_TEGRA_CLKRST)
> #include
> #endif
> @@ -256,6 +260,37 @@ int board_early_init_f(void)
> }
> #endif /* EARLY_INIT */
>
> +#ifndef CONFIG_TEGRA186
> +static void nvidia_board_late_init_generic(void)
> +{
> + char serialno_str[17];
> +
> + /* Set chip id as serialno */
> + sprintf(serialno_str, "%016llx", tegra_chip_uid());
> + env_set("serial#", serialno_str);
> +
> + switch (tegra_get_chip()) {
> + case CHIPID_TEGRA20:
> + env_set("platform", "Tegra 2 T20");
> + break;
> + case CHIPID_TEGRA30:
> + env_set("platform", "Tegra 3 T30");
> + break;
> + case CHIPID_TEGRA114:
> + env_set("platform", "Tegra 4 T114");
> + break;
> + case CHIPID_TEGRA124:
> + env_set("platform", "Tegra K1 T124");
> + break;
> + case CHIPID_TEGRA210:
> + env_set("platform", "Tegra X1 T210");
> + break;
> + default:
> + return;
> + }
> +}
> +#endif
> +
> int board_late_init(void)
> {
> #if defined(CONFIG_TEGRA_SUPPORT_NON_SECURE)
> @@ -268,6 +303,14 @@ int board_late_init(void)
> #endif
> start_cpu_fan();
> cboot_late_init();
> +
> + /*
> +* Perform generic env setup in case
> +* vendor does not provide it.
> +*/
> +#ifndef CONFIG_TEGRA186
> + nvidia_board_late_init_generic();
> +#endif
> nvidia_board_late_init();
>
> return 0;
> --
> 2.39.2
>
This would be better done with events. I just sent a series that
converts board_late_init() to use events [1] and with that you can add
as many 'spy' functions as you like [2].
Regards,
Simon
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=369742
[2] https://u-boot.readthedocs.io/en/latest/develop/event.html
Re: [PATCH] test: print: Fix hexdump test on 64bit systems
Hi Marek,
On Wed, 23 Aug 2023 at 13:38, Marek Vasut
wrote:
>
> Use the following regex to make this test compatible with
> both 32bit and 64bit systems. The trick is to use %0*lx
> format string for the address prefix in the test.
>
> "
> s@\(ut_assert_nextline("\)0\+\([^:]\+\)\(:.*"\)\();\)@\1%0*lx\3,
> IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x\2UL\4
> "
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Mario Six
> Cc: Simon Glass
> ---
> test/print_ut.c | 28 ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/test/print_ut.c b/test/print_ut.c
> index 47a6ce57840..0a994a05cf6 100644
> --- a/test/print_ut.c
> +++ b/test/print_ut.c
> @@ -283,16 +283,16 @@ static int print_do_hex_dump(struct unit_test_state
> *uts)
> /* bytes */
> console_record_reset();
> print_hex_dump_bytes("", DUMP_PREFIX_ADDRESS, buf, 0x12);
> - ut_assert_nextline(": 00 11 22 33 44 55 66 77 88 99 aa bb cc
> dd ee ff ..\"3DUfw");
> - ut_assert_nextline("0010: 10 00
> ..");
> + ut_assert_nextline("%0*lx: 00 11 22 33 44 55 66 77 88 99 aa bb cc dd
> ee ff ..\"3DUfw", IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x0UL);
Can you put the arg on the next line and perhaps put it at the top of
the file as a #define ?
> + ut_assert_nextline("%0*lx: 10 00
> ..", IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x10UL);
> ut_assert_console_end();
>
> /* line length */
> console_record_reset();
> print_hex_dump("", DUMP_PREFIX_ADDRESS, 8, 1, buf, 0x12, true);
> - ut_assert_nextline(": 00 11 22 33 44 55 66 77 ..\"3DUfw");
> - ut_assert_nextline("0008: 88 99 aa bb cc dd ee ff ");
> - ut_assert_nextline("0010: 10 00..");
> + ut_assert_nextline("%0*lx: 00 11 22 33 44 55 66 77 ..\"3DUfw",
> IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x0UL);
> + ut_assert_nextline("%0*lx: 88 99 aa bb cc dd ee ff ",
> IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x8UL);
> + ut_assert_nextline("%0*lx: 10 00..",
> IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x10UL);
> ut_assert_console_end();
> unmap_sysmem(buf);
>
> @@ -300,31 +300,31 @@ static int print_do_hex_dump(struct unit_test_state
> *uts)
> console_record_reset();
> buf[0x41] = 0x41;
> print_hex_dump("", DUMP_PREFIX_ADDRESS, 0x40, 1, buf, 0x42, true);
> - ut_assert_nextline(": 00 11 22 33 44 55 66 77 88 99 aa bb cc
> dd ee ff 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ..\"3DUfw");
> - ut_assert_nextline("0040: 00 41
>
>
> .A");
> + ut_assert_nextline("%0*lx: 00 11 22 33 44 55 66 77 88 99 aa bb cc dd
> ee ff 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ..\"3DUfw",
> IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x0UL);
> + ut_assert_nextline("%0*lx: 00 41
>
> .A",
> IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x40UL);
> ut_assert_console_end();
>
> /* 16-bit */
> console_record_reset();
> print_hex_dump("", DUMP_PREFIX_ADDRESS, 0, 2, buf, 0x12, true);
> - ut_assert_nextline(": 1100 3322 5544 7766 9988 bbaa ddcc ffee
> ..\"3DUfw");
> - ut_assert_nextline("0010: 0010
> ..");
> + ut_assert_nextline("%0*lx: 1100 3322 5544 7766 9988 bbaa ddcc ffee
> ..\"3DUfw", IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x0UL);
> + ut_assert_nextline("%0*lx: 0010
> ..", IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x10UL);
> ut_assert_console_end();
> unmap_sysmem(buf);
>
> /* 32-bit */
> console_record_reset();
> print_hex_dump("", DUMP_PREFIX_ADDRESS, 0, 4, buf, 0x14, true);
> - ut_assert_nextline(": 33221100 77665544 bbaa9988 ffeeddcc
> ..\"3DUfw");
> - ut_assert_nextline("0010: 0010
> ");
> + ut_assert_nextline("%0*lx: 33221100 77665544 bbaa9988 ffeeddcc
> ..\"3DUfw", IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x0UL);
> + ut_assert_nextline("%0*lx: 0010
Re: [PATCH 1/6] cmd: gpt: Remove confusing help text
On Tue, 15 Aug 2023 at 10:28, Joshua Watt wrote: > > This help text appears to be a fragment of the text shown when > CONFIG_CMD_GPT_RENAME is enabled, but is confusing so remove it. > > Signed-off-by: Joshua Watt > --- > cmd/gpt.c | 2 -- > 1 file changed, 2 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH 2/2] efi_loader: support boot from URI device path
Hi Masahisa,
On Wed, 23 Aug 2023 at 02:38, Masahisa Kojima
wrote:
>
> This supports to boot from the URI device path.
> When user selects the URI device path, bootmgr downloads
> the file using wget into the address specified by loadaddr
> env variable.
> If the file is .iso or .img file, mount the image with blkmap
> then try to boot with the default file(e.g. EFI/BOOT/BOOTAA64.EFI).
> If the file is .efi file, load and start the downloaded file.
>
> Signed-off-by: Masahisa Kojima
> ---
> lib/efi_loader/efi_bootmgr.c | 213 +++
> 1 file changed, 213 insertions(+)
>
Much of this code should be factored out into a help which can be
called from other code. See comments below.
> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> index a40762c74c..8b20f486f2 100644
> --- a/lib/efi_loader/efi_bootmgr.c
> +++ b/lib/efi_loader/efi_bootmgr.c
> @@ -7,10 +7,14 @@
>
> #define LOG_CATEGORY LOGC_EFI
>
> +#include
> +#include
> #include
> #include
> +#include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -168,6 +172,209 @@ out:
> return ret;
> }
>
> +#if (IS_ENABLED(CONFIG_BLKMAP) && IS_ENABLED(CONFIG_CMD_WGET) &&
> IS_ENABLED(CONFIG_CMD_DNS))
> +/**
> + * mount_image() - mount the image
> + *
> + * @lo_label label of load option
> + * @file_size file size
> + * @handle:pointer to handle for newly installed image
> + * Return: status code
> + */
> +static efi_status_t mount_image(u16 *lo_label, int file_size,
> + efi_handle_t *handle)
> +{
> + int err;
> + efi_status_t ret;
> + char *label = NULL, *p;
> + lbaint_t blknum;
> + struct udevice *bm_dev;
> + efi_handle_t bm_handle;
> + struct udevice *blk, *partition;
> + struct efi_handler *handler;
> + struct efi_device_path *file_path;
> + struct efi_device_path *device_path;
> +
> + label = efi_alloc(utf16_utf8_strlen(lo_label) + 1);
> + if (!label)
> + return EFI_OUT_OF_RESOURCES;
> +
>From here:
> + p = label;
> + utf16_utf8_strcpy(, lo_label);
> + err = blkmap_create(label, NULL);
> + if (err) {
> + log_err("failed to create blkmap\n");
> + ret = EFI_INVALID_PARAMETER;
> + goto out;
> + }
> + bm_dev = blkmap_from_label(label);
> + if (!bm_dev) {
> + log_err("\"%s\" is not the name of any known blkmap\n",
> label);
> + ret = EFI_INVALID_PARAMETER;
> + goto out;
> + }
> +
> + blknum = file_size / 512; /* TODO: don't use literal value. */
> + err = blkmap_map_pmem(bm_dev, 0, blknum, image_load_addr);
> + if (err) {
> + log_err("Unable to map %#llx at block %d : %d\n",
> + (unsigned long long)image_load_addr, 0, err);
> + ret = EFI_INVALID_PARAMETER;
> + goto out;
> + }
> + log_info("Block %d+0x" LBAF " mapped to %#llx\n", 0, blknum,
> +(unsigned long long)image_load_addr);
> +
> + /* TODO: without calling this, partition devices are not binded. */
> + blk_list_part(UCLASS_BLKMAP);
> +
> + /*
> +* Search the partition having EFI_SIMPLE_FILE_SYSTEM_PROTOCOL,
> +* then try to load with the default boot file(e.g.
> EFI/BOOT/BOOTAA64.EFI).
> +*/
> + device_foreach_child(blk, bm_dev)
> + {
check code style
> + device_foreach_child(partition, blk)
> + {
to here.
Perhaps have partition_first() and partition_next() iterators?
>From here is EFI code:
> + if (dev_tag_get_ptr(partition, DM_TAG_EFI,
> + (void **)_handle)) {
> + log_warning("DM_TAG_EFI not found\n");
> + continue;
> + }
> +
> + ret = efi_search_protocol(
> + bm_handle,
> + _simple_file_system_protocol_guid,
> + );
> + if (ret != EFI_SUCCESS)
> + continue;
> +
> + ret = efi_search_protocol(
> + bm_handle, _guid_device_path, );
> + if (ret != EFI_SUCCESS)
> + continue;
> +
> + ret = efi_protocol_open(handler, (void
> **)_path,
> + efi_root, NULL,
> +
> EFI_OPEN_PROTOCOL_GET_PROTOCOL);
> + if (ret != EFI_SUCCESS)
> + continue;
> +
> + file_path = expand_media_path(device_path);
> + ret = EFI_CALL(efi_load_image(true, efi_root,
>
Re: [PATCH V4 8/8] doc: board: ti: Add BeaglePlay documentation
Hi Tom, On Wed, 23 Aug 2023 at 11:15, Tom Rini wrote: > > On Wed, Aug 23, 2023 at 09:30:31AM -0600, Simon Glass wrote: > > Hi Nishanth, > > > > On Tue, 22 Aug 2023 at 12:43, Nishanth Menon wrote: > > > > > > Add base documentation for BeaglePlay > > > > > > Signed-off-by: Nishanth Menon > > > --- > > > Cc: Heinrich Schuchardt > > > > > > Changes Since V3: > > > * Updated documentation to give a more clear overview of MMC partitions > > > and flashing information. > > > * Added OpenOCD debug documentation > > > * Added LED status information and indication of various boot stages > > > > > > V3: https://lore.kernel.org/all/20230815164440.2713726-5...@ti.com/ > > > V2: https://lore.kernel.org/u-boot/20230727234446.3651836-5...@ti.com/ > > > V1: https://lore.kernel.org/all/20230725185253.2123433-7...@ti.com/ > > > > > > doc/board/ti/am62x_beagleplay.rst| 256 ++ > > > doc/board/ti/img/beagleplay_emmc.svg | 697 +++ > > > doc/board/ti/k3.rst | 1 + > > > 3 files changed, 954 insertions(+) > > > create mode 100644 doc/board/ti/am62x_beagleplay.rst > > > create mode 100644 doc/board/ti/img/beagleplay_emmc.svg > > > > > > > Great docs, an example to others. > > > > Some nits below. > > > > The bigger problem is that we cannot build this with buildman since it > > needs config fragments and we don't have a way to describe them. In > > fact none of my existing flows can build this board and it breaks all > > my scripts, etc. > > > > I don't think anyone else sees this as a problem? > > > > Anyway, I'll send a separate email on the topic. > > > > > diff --git a/doc/board/ti/am62x_beagleplay.rst > > > b/doc/board/ti/am62x_beagleplay.rst > > > new file mode 100644 > > > index ..5adb7b4c9ace > > > --- /dev/null > > > +++ b/doc/board/ti/am62x_beagleplay.rst > > > @@ -0,0 +1,256 @@ > > > +.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause > > > +.. sectionauthor:: Nishanth Menon > > > + > > > +AM62x Beagleboard.org Beagleplay > > > + > > > + > > > +Introduction: > > > +- > > > + > > > +BeagleBoard.org BeaglePlay is an easy to use, affordable open source > > > +hardware single board computer based on the Texas Instruments AM625 > > > +SoC that allows you to create connected devices that work even at long > > > +distances using IEEE 802.15.4g LR-WPAN and IEEE 802.3cg 10Base-T1L. > > > +Expansion is provided over open standards based mikroBUS, Grove and > > > +QWIIC headers among other interfaces. > > > + > > > +Further information can be found at: > > > + > > > +* Product Page: https://beagleplay.org/ > > > +* Hardware documentation: > > > https://git.beagleboard.org/beagleplay/beagleplay > > > + > > > +Boot Flow: > > > +-- > > > +Below is the pictorial representation of boot flow: > > > + > > > +.. image:: img/boot_diagram_k3_current.svg > > > + :alt: Boot flow diagram > > > + > > > +- On this platform, 'TI Foundational Security' (TIFS) functions as the > > > + security enclave master while 'Device Manager' (DM), also known as the > > > + 'TISCI server' in "TI terminology", offers all the essential services. > > > + The A53/M4F (Aux core) sends requests to TIFS/DM to accomplish these > > > + services, as illustrated in the diagram above. > > > + > > > +Sources: > > > + > > > +.. include:: k3.rst > > > +:start-after: .. k3_rst_include_start_boot_sources > > > +:end-before: .. k3_rst_include_end_boot_sources > > > + > > > +Build procedure: > > > + > > > +0. Setup the environment variables: > > > + > > > +.. include:: k3.rst > > > +:start-after: .. k3_rst_include_start_common_env_vars_desc > > > +:end-before: .. k3_rst_include_end_common_env_vars_desc > > > + > > > +.. include:: k3.rst > > > +:start-after: .. k3_rst_include_start_board_env_vars_desc > > > +:end-before: .. k3_rst_include_end_board_env_vars_desc > > > + > > > +Set the variables corresponding to this platform: > > > + > > > +.. include:: k3.rst > > > +:start-after: .. k3_rst_include_start_common_env_vars_defn > > > +:end-before: .. k3_rst_include_end_common_env_vars_defn > > > +.. code-block:: bash > > > + > > > + $ export UBOOT_CFG_CORTEXR="am62x_evm_r5_defconfig beagleplay_r5.config" > > > + $ export UBOOT_CFG_CORTEXA="am62x_evm_a53_defconfig > > > beagleplay_a53.config" > > > > Can you drop those two variables? It seems to just confuse the matter. > > They are only used once. We are used to seeing a 'defconfig' target > > when configuring, and this just obfuscates things. > > This is how we have a common bit of rST for how to build N boards, > without having to do a literal copy and paste N times. How about using this? https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#substitution-definitions Regards, Simon
Re: [PATCH v2 6/8] cmd: gpt: Preserve type GUID if enabled
Hi Joshua,
On Wed, 23 Aug 2023 at 10:48, Joshua Watt wrote:
>
> If CONFIG_PARTITION_TYPE_GUID is enabled, the type GUID will be
> preserved when writing out the partition string. It was already
> respected when writing out partitions; this ensures that if you capture
> the current partition layout and write it back (such as when renaming),
> the type GUIDs are preserved.
>
> Signed-off-by: Joshua Watt
> ---
> cmd/gpt.c | 16 +++
> test/py/tests/test_gpt.py | 57 +++
> 2 files changed, 73 insertions(+)
>
> diff --git a/cmd/gpt.c b/cmd/gpt.c
> index 70a01f7da1..fdd9c429f6 100644
> --- a/cmd/gpt.c
> +++ b/cmd/gpt.c
> @@ -173,6 +173,9 @@ static int calc_parts_list_len(int numparts)
> /* see part.h for definition of struct disk_partition */
> partlistlen += numparts * (strlen("start=MiB,") + sizeof(lbaint_t) +
> 1);
> partlistlen += numparts * (strlen("size=MiB,") + sizeof(lbaint_t) +
> 1);
> +#ifdef CONFIG_PARTITION_TYPE_GUID
> + partlistlen += numparts * (strlen("type=,") + UUID_STR_LEN + 1);
> +#endif
> partlistlen += numparts * (strlen("uuid=;") + UUID_STR_LEN + 1);
> /* for the terminating null */
> partlistlen++;
> @@ -211,6 +214,11 @@ static struct disk_part *allocate_disk_part(struct
> disk_partition *info,
> PART_TYPE_LEN);
> newpart->gpt_part_info.type[PART_TYPE_LEN - 1] = '\0';
> newpart->gpt_part_info.bootable = info->bootable;
> +#ifdef CONFIG_PARTITION_TYPE_GUID
> + strncpy(newpart->gpt_part_info.type_guid, (const char
> *)info->type_guid,
> + UUID_STR_LEN);
> + newpart->gpt_part_info.type_guid[UUID_STR_LEN] = '\0';
> +#endif
> #ifdef CONFIG_PARTITION_UUIDS
> strncpy(newpart->gpt_part_info.uuid, (const char *)info->uuid,
> UUID_STR_LEN);
> @@ -252,6 +260,9 @@ static void print_gpt_info(void)
>curr->gpt_part_info.name);
> printf("Type %s, bootable %d\n", curr->gpt_part_info.type,
>curr->gpt_part_info.bootable & PART_BOOTABLE);
> +#ifdef CONFIG_PARTITION_TYPE_GUID
> + printf("Type GUID %s\n", curr->gpt_part_info.type_guid);
> +#endif
> #ifdef CONFIG_PARTITION_UUIDS
> printf("UUID %s\n", curr->gpt_part_info.uuid);
> #endif
> @@ -299,6 +310,11 @@ static int create_gpt_partitions_list(int numparts,
> const char *guid,
> curr->gpt_part_info.blksz);
> strncat(partitions_list, partstr, PART_NAME_LEN + 1);
>
> +#ifdef CONFIG_PARTITION_TYPE_GUID
> + strcat(partitions_list, ",type=");
> + strncat(partitions_list, curr->gpt_part_info.type_guid,
> + UUID_STR_LEN + 1);
> +#endif
> strcat(partitions_list, ",uuid=");
> strncat(partitions_list, curr->gpt_part_info.uuid,
> UUID_STR_LEN + 1);
> diff --git a/test/py/tests/test_gpt.py b/test/py/tests/test_gpt.py
> index 8203515e05..f9351f0274 100644
> --- a/test/py/tests/test_gpt.py
> +++ b/test/py/tests/test_gpt.py
> @@ -16,6 +16,26 @@ the test.
> # Mark all tests here as slow
> pytestmark = pytest.mark.slow
>
> +def parse_gpt_parts(s):
> +"""Part a partition string into a list of partitions"""
Please remember to fully comment functions, including arg and return value.
Also 's' can be used in loops but not as a var or param. I think we
need to use 3 chars or more.
> +parts = []
> +for part_str in s.split(';'):
> +part = {}
> +for option in part_str.split(","):
> +if not option:
> +continue
> +
> +if "=" in option:
> +k, v = option.split("=")
> +part[k] = v
> +else:
> +part[option] = True
> +
> +if part:
> +parts.append(part)
> +
> +return parts
> +
> class GptTestDiskImage(object):
> """Disk Image used by the GPT tests."""
>
> @@ -49,11 +69,13 @@ class GptTestDiskImage(object):
> u_boot_utils.run_and_log(u_boot_console, cmd)
> # part1 offset 1MB size 1MB
> cmd = ('sgdisk', '--new=1:2048:4095',
> '--change-name=1:part1',
> +
> '--partition-guid=1:33194895-67f6-4561-8457-6fdeed4f50a3',
> '-A 1:set:2',
> persistent)
> # part2 offset 2MB size 1.5MB
> u_boot_utils.run_and_log(u_boot_console, cmd)
> cmd = ('sgdisk', '--new=2:4096:7167',
> '--change-name=2:part2',
> +
> '--partition-guid=2:cc9c6e4a-6551-4cb5-87be-3210f96c86fb',
> persistent)
> u_boot_utils.run_and_log(u_boot_console, cmd)
> cmd = ('sgdisk', '--load-backup=' + persistent)
> @@ -88,6 +110,40 @@ def test_gpt_read(state_disk_image, u_boot_console):
>
Re: [PATCH v3 5/9] board: qualcomm: Add support for dragonboard845c
Hi Sumit,
On Tue, 12 Jul 2022 at 01:12, Sumit Garg wrote:
>
> Add support for 96Boards Dragonboard 845C aka Robotics RB3 development
> platform. This board complies with 96Boards Open Platform Specifications.
>
> Features:
> - Qualcomm Snapdragon SDA845 SoC
> - 4GiB RAM
> - 64GiB UFS drive
>
> U-boot is chain loaded by ABL in 64-bit mode as part of boot.img.
> For detailed build and boot instructions, refer to
> doc/board/qualcomm/sdm845.rst, board: dragonboard845c.
>
> Signed-off-by: Sumit Garg
> Reviewed-by: Ramon Fried
> ---
> arch/arm/dts/dragonboard845c-uboot.dtsi | 37 +++
> arch/arm/dts/dragonboard845c.dts | 44
> arch/arm/mach-snapdragon/Kconfig | 14 +++
> board/qualcomm/dragonboard845c/Kconfig| 12 +++
> board/qualcomm/dragonboard845c/MAINTAINERS| 6 ++
> board/qualcomm/dragonboard845c/Makefile | 9 ++
> board/qualcomm/dragonboard845c/db845c.its | 63 +++
> .../dragonboard845c/dragonboard845c.c | 9 ++
> configs/dragonboard845c_defconfig | 28 +
> doc/board/qualcomm/sdm845.rst | 100 +++---
> include/configs/dragonboard845c.h | 28 +
> 11 files changed, 337 insertions(+), 13 deletions(-)
> create mode 100644 arch/arm/dts/dragonboard845c-uboot.dtsi
> create mode 100644 arch/arm/dts/dragonboard845c.dts
> create mode 100644 board/qualcomm/dragonboard845c/Kconfig
> create mode 100644 board/qualcomm/dragonboard845c/MAINTAINERS
> create mode 100644 board/qualcomm/dragonboard845c/Makefile
> create mode 100644 board/qualcomm/dragonboard845c/db845c.its
> create mode 100644 board/qualcomm/dragonboard845c/dragonboard845c.c
> create mode 100644 configs/dragonboard845c_defconfig
> create mode 100644 include/configs/dragonboard845c.h
>
[..]
> diff --git a/doc/board/qualcomm/sdm845.rst b/doc/board/qualcomm/sdm845.rst
> index b6642c9579..8ef4749287 100644
> --- a/doc/board/qualcomm/sdm845.rst
> +++ b/doc/board/qualcomm/sdm845.rst
> @@ -35,9 +35,25 @@ Pack android boot image
> ^^^
> We'll assemble android boot image with ``u-boot.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:
> +with appended dtb, so let's mimic linux to satisfy stock bootloader.
>
[..]
> +The dragonboard845c is a Qualcomm Robotics RB3 Development Platform, based on
> +the Qualcomm SDM845 SoC.
> +
> +Steps:
> +
> +- Build u-boot::
> +
> + $ export CROSS_COMPILE=
> + $ make dragonboard845c_defconfig
> + $ make
> +
> +- Create dummy dtb::
> +
> + workdir=/tmp/prepare_payload
> + mkdir -p "$workdir"
> + mock_dtb="$workdir"/payload_mock.dtb
> +
> + dtc -I dts -O dtb -o "$mock_dtb" << EOF
> + /dts-v1/;
> + / {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + memory@8000 {
> + device_type = "memory";
> + /* We expect the bootloader to fill in the size */
> + reg = <0 0x8000 0 0>;
> + };
> +
> + chosen { };
> + };
> + EOF
> +
> +- gzip u-boot::
> +
> + gzip u-boot.bin
> +
> +- Append dtb to gzipped u-boot::
> +
> +cat u-boot.bin.gz "$mock_dtb" > u-boot.bin.gz-dtb
> +
> +- A ``db845c.its`` file can be found in ``board/qualcomm/dragonboard845c/``
> + directory. It expects a folder as ``db845c_imgs/`` in the main directory
> + containing pre-built kernel, dts and ramdisk images. See ``db845c.its``
> + for full path to images::
> +
> + mkimage -f db845c.its db845c.itb
> +
> +- Now we've got everything to build android boot image::
> +
> + mkbootimg --kernel u-boot.bin.gz-dtb --ramdisk db845c.itb \
> + --output boot.img --pagesize 4096 --base 0x8000
> +
> +- Flash boot.img using db845c fastboot method.
What command should be used here? I can run 'fastboot devices' but am
not sure what command to use to flash U-Boot.
Also, is it possible to flash U-Boot as a first-stage bootloader?
> +
> +More information can be found on the `DragonBoard 845c page`_.
>
> .. _Samsung S9 page: https://en.wikipedia.org/wiki/Samsung_Galaxy_S9
> +.. _DragonBoard 845c page: https://www.96boards.org/product/rb3-platform/
> diff --git a/include/configs/dragonboard845c.h
> b/include/configs/dragonboard845c.h
> new file mode 100644
> index 00..108dde199b
> --- /dev/null
> +++ b/include/configs/dragonboard845c.h
> @@ -0,0 +1,28 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Configuration file for Dragonboard 845c, based on Qualcomm SDA845 chip
> + *
> + * (C) Copyright 2022 Sumit Garg
> + */
> +
> +#ifndef __CONFIGS_SDM845_H
> +#define __CONFIGS_SDM845_H
> +
> +#include
> +#include
> +
> +#define CONFIG_SYS_BAUDRATE_TABLE { 115200, 230400, 460800, 921600 }
> +
>
Re: [PATCH 6/6] cmd: gpt: Add command to swap partition order
Hi Joshua,
On Tue, 15 Aug 2023 at 10:28, Joshua Watt wrote:
>
> Adds a command called "gpt swap-postition" which will swap the order two
> partitions are listed in the GPT partition table (but leaves them
> pointing to the same locations on disk).
>
> Signed-off-by: Joshua Watt
> ---
> cmd/gpt.c | 50 --
> 1 file changed, 48 insertions(+), 2 deletions(-)
>
> diff --git a/cmd/gpt.c b/cmd/gpt.c
> index 58564436d3..c8a2b5ae7b 100644
> --- a/cmd/gpt.c
> +++ b/cmd/gpt.c
> @@ -859,7 +859,7 @@ static int do_rename_gpt_parts(struct blk_desc *dev_desc,
> char *subcomm,
> int partlistlen, ret, numparts = 0, partnum, i = 1, ctr1 = 0, ctr2 =
> 0;
>
> if ((subcomm == NULL) || (name1 == NULL) || (name2 == NULL) ||
> - (strcmp(subcomm, "swap") && (strcmp(subcomm, "rename"
> + (strcmp(subcomm, "swap") && strcmp(subcomm, "rename") &&
> strcmp(subcomm, "swap-position")))
While you are here you could tidy this code:
if (!subcomm || !name1 || !name2 ||
...
> return -EINVAL;
>
> ret = get_disk_guid(dev_desc, disk_guid);
> @@ -920,6 +920,48 @@ static int do_rename_gpt_parts(struct blk_desc
> *dev_desc, char *subcomm,
> ret = -EINVAL;
> goto out;
> }
> + } else if(!strcmp(subcomm, "swap-position")) {
> + int idx1, idx2;
> + struct disk_partition first, second;
blank line
> + idx1 = simple_strtoul(name1, NULL, 10);
> + if (idx1 <= 0 || idx1 > numparts) {
> + printf("Illegal partition number %s\n", name1);
> + ret = -EINVAL;
> + goto out;
> + }
> + idx2 = simple_strtoul(name2, NULL, 10);
> + if (idx2 <= 0 || idx2 > numparts) {
> + printf("Illegal partition number %s\n", name2);
> + ret = -EINVAL;
> + goto out;
> + }
> + if (idx1 == idx2) {
> + printf("Cannot swap partition with itself\n");
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + i = 1;
> + list_for_each(pos, _partitions) {
> + curr = list_entry(pos, struct disk_part, list);
> + if (i == idx1) {
> + first = curr->gpt_part_info;
> + } else if (i == idx2) {
> + second = curr->gpt_part_info;
> + }
Can you please either use patman or manually checkpatch on your
patches? This should not have {}
> + i++;
> + }
> +
> + i = 1;
> + list_for_each(pos, _partitions) {
> + curr = list_entry(pos, struct disk_part, list);
> + if (i == idx1) {
> + curr->gpt_part_info = second;
> + } else if (i == idx2) {
> + curr->gpt_part_info = first;
> + }
> + i++;
> + }
> } else { /* rename */
> if (strlen(name2) > PART_NAME_LEN) {
> printf("Names longer than %d characters are
> truncated.\n", PART_NAME_LEN);
> @@ -1122,7 +1164,8 @@ static int do_gpt(struct cmd_tbl *cmdtp, int flag, int
> argc, char *const argv[])
> } else if (strcmp(argv[1], "read") == 0) {
> ret = do_get_gpt_info(blk_dev_desc, (argc == 5) ? argv[4] :
> NULL);
> } else if ((strcmp(argv[1], "swap") == 0) ||
> - (strcmp(argv[1], "rename") == 0)) {
> + (strcmp(argv[1], "rename") == 0) ||
> + (strcmp(argv[1], "swap-position") == 0)) {
> ret = do_rename_gpt_parts(blk_dev_desc, argv[1], argv[4],
> argv[5]);
> #endif
> } else if ((strcmp(argv[1], "set-bootable") == 0)) {
> @@ -1175,11 +1218,14 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
> " gpt swap\n"
> "- change all partitions named name1 to name2\n"
> " and vice-versa\n"
> + " gpt swap-position\n"
> + "- Swap the order of name1 with name2 in the partition table\n"
> " gpt rename\n"
> "- rename the specified partition\n"
> " Example usage:\n"
> " gpt swap mmc 0 foo bar\n"
> " gpt rename mmc 0 3 foo\n"
> + " gpt swap-partitions mmc 0 1 2\n"
> #endif
> " gpt set-bootable \n"
> "- make partition names in list bootable\n"
> --
> 2.33.0
>
Regards,
Simon
Re: [PATCH 2/7] lmb: Tidy up structure access
Hi Heinrich,
On Wed, 23 Aug 2023 at 09:44, Heinrich Schuchardt wrote:
>
> On 23.08.23 15:41, Simon Glass wrote:
> > In some cases it helps to define a local variable pointing to the
> > structure being accessed. This avoids lots of repeated code.
> >
> > There is no need to individually assign each struct member, so use a
> > structure assignment instead.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > lib/lmb.c | 54 +-
> > 1 file changed, 25 insertions(+), 29 deletions(-)
> >
> > diff --git a/lib/lmb.c b/lib/lmb.c
> > index ae1969893f00..8b9a611c5216 100644
> > --- a/lib/lmb.c
> > +++ b/lib/lmb.c
> > @@ -23,20 +23,19 @@ DECLARE_GLOBAL_DATA_PTR;
> >
> > static void lmb_dump_region(struct lmb_region *rgn, char *name)
> > {
> > - unsigned long long base, size, end;
> > - enum lmb_flags flags;
> > int i;
> >
> > printf(" %s.cnt = 0x%lx / max = 0x%lx\n", name, rgn->cnt, rgn->max);
> >
> > for (i = 0; i < rgn->cnt; i++) {
> > - base = rgn->region[i].base;
> > - size = rgn->region[i].size;
> > - end = base + size - 1;
> > - flags = rgn->region[i].flags;
> > + struct lmb_property *prop = >region[i];
> > + unsigned long long end;
> > +
> > + end = prop->base + prop->size - 1;
> >
> > printf(" %s[%d]\t[0x%llx-0x%llx], 0x%08llx bytes flags: %x\n",
> > -name, i, base, end, size, flags);
> > +name, i, (unsigned long long)prop->base, end,
> > +(unsigned long long)prop->size, prop->flags);
> > }
> > }
> >
> > @@ -89,11 +88,8 @@ static void lmb_remove_region(struct lmb_region *rgn,
> > unsigned long r)
> > {
> > unsigned long i;
> >
> > - for (i = r; i < rgn->cnt - 1; i++) {
> > - rgn->region[i].base = rgn->region[i + 1].base;
> > - rgn->region[i].size = rgn->region[i + 1].size;
> > - rgn->region[i].flags = rgn->region[i + 1].flags;
> > - }
> > + for (i = r; i < rgn->cnt - 1; i++)
> > + rgn->region[i] = rgn->region[i + 1];
> > rgn->cnt--;
> > }
> >
> > @@ -122,6 +118,7 @@ void lmb_init(struct lmb *lmb)
> >
> > void arch_lmb_reserve_generic(struct lmb *lmb, ulong sp, ulong end, ulong
> > align)
> > {
> > + struct bd_info *bd = gd->bd;
> > ulong bank_end;
> > int bank;
> >
> > @@ -135,12 +132,10 @@ void arch_lmb_reserve_generic(struct lmb *lmb, ulong
> > sp, ulong end, ulong align)
> > /* adjust sp by 4K to be safe */
> > sp -= align;
> > for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
> > - if (!gd->bd->bi_dram[bank].size ||
> > - sp < gd->bd->bi_dram[bank].start)
> > + if (!bd->bi_dram[bank].size || sp < bd->bi_dram[bank].start)
> > continue;
> > /* Watch out for RAM at end of address space! */
> > - bank_end = gd->bd->bi_dram[bank].start +
> > - gd->bd->bi_dram[bank].size - 1;
> > + bank_end = bd->bi_dram[bank].start + bd->bi_dram[bank].size -
> > 1;
> > if (sp > bank_end)
> > continue;
> > if (bank_end > end)
> > @@ -244,9 +239,11 @@ static long lmb_add_region_flags(struct lmb_region
> > *rgn, phys_addr_t base,
> >
> > /* First try and coalesce this LMB with another. */
> > for (i = 0; i < rgn->cnt; i++) {
> > - phys_addr_t rgnbase = rgn->region[i].base;
> > - phys_size_t rgnsize = rgn->region[i].size;
> > - phys_size_t rgnflags = rgn->region[i].flags;
> > + struct lmb_property *prop = >region[i];
>
> Why call a region prop? Can't we call it "region" or "rgn_ptr" or if you
> want to allude to the position in the array "pos"? This would avoid
> confusion.
We always have rgn so that would be hopelessly confusing.
I am using prop just because that is the struct name.
I did not invent the confusion:
struct lmb_region {
unsigned long cnt;
unsigned long max;
struct lmb_property region[CONFIG_LMB_MAX_REGIONS];
};
There is a region within a region, and also:
struct lmb {
struct lmb_region memory;
struct lmb_region reserved;
struct lmb_property memory_regions[CONFIG_LMB_MEMORY_REGIONS];
struct lmb_property reserved_regions[CONFIG_LMB_RESERVED_REGIONS];
};
I did consider trying to rename one of them...but 'region' is used
extensively in the C code to mean the inner region. We could perhaps
rename the outer 'region' to an 'area'?
Regards,
Simon
Re: [PATCH v2 3/8] tests: gpt: Remove test order dependency
Hi Joshua, On Wed, 23 Aug 2023 at 10:48, Joshua Watt wrote: > > Re-create a clean disk image for each test to prevent modifications from > one test affecting another > > Signed-off-by: Joshua Watt > --- > test/py/tests/test_gpt.py | 20 > 1 file changed, 8 insertions(+), 12 deletions(-) I suppose this is OK, but is it expensive in terms of time? Reviewed-by: Simon Glass Regards, Simon
Re: [PATCH v2 7/8] cmd: gpt: Preserve bootable flag
On Wed, 23 Aug 2023 at 10:48, Joshua Watt wrote: > > Sets the bootable flag when constructing the partition string from the > current partition configuration. This ensures that when the partitions > are written back (for example, when renaming a partition), the flag is > preserved. > > Signed-off-by: Joshua Watt > --- > cmd/gpt.c | 3 +++ > test/py/tests/test_gpt.py | 1 + > 2 files changed, 4 insertions(+) > Reviewed-by: Simon Glass
Re: [PATCH v2 4/8] cmd: gpt: Add gpt_partition_bootable variable
Hi Joshue,
On Wed, 23 Aug 2023 at 10:48, Joshua Watt wrote:
>
> Adds an additional variable called gpt_partition_bootable that indicates
> if the given partition is bootable or not.
>
> Signed-off-by: Joshua Watt
> ---
> cmd/gpt.c | 9 +++--
> doc/usage/cmd/gpt.rst | 3 +++
> test/py/tests/test_gpt.py | 33 +
> 3 files changed, 43 insertions(+), 2 deletions(-)
>
> diff --git a/cmd/gpt.c b/cmd/gpt.c
> index e6f7b0319a..7a8990e400 100644
> --- a/cmd/gpt.c
> +++ b/cmd/gpt.c
> @@ -723,7 +723,7 @@ static int gpt_enumerate(struct blk_desc *desc)
> * gpt_setenv_part_variables() - setup partition environmental variables
> *
> * Setup the gpt_partition_name, gpt_partition_entry, gpt_partition_addr
> - * and gpt_partition_size environment variables.
> + * and gpt_partition_size, gpt_partition_bootable environment variables.
> *
> * @pinfo: pointer to disk partition
> * @i: partition entry
> @@ -750,6 +750,10 @@ static int gpt_setenv_part_variables(struct
> disk_partition *pinfo, int i)
> if (ret)
> goto fail;
>
> + ret = env_set_ulong("gpt_partition_bootable", !!(pinfo->bootable &
> PART_BOOTABLE));
> + if (ret)
> + goto fail;
> +
> return 0;
>
> fail:
> @@ -1057,7 +1061,8 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
> " gpt setenv mmc 0 $name\n"
> "- setup environment variables for partition $name:\n"
> " gpt_partition_addr, gpt_partition_size,\n"
> - " gpt_partition_name, gpt_partition_entry\n"
> + " gpt_partition_name, gpt_partition_entry,\n"
> + " gpt_partition_bootable\n"
Please use single quotes except for the """ for function headers.
> " gpt enumerate mmc 0\n"
> "- store list of partitions to gpt_partition_list environment
> variable\n"
> " gpt guid \n"
> diff --git a/doc/usage/cmd/gpt.rst b/doc/usage/cmd/gpt.rst
> index ea2cf73a60..c9d15b2cba 100644
> --- a/doc/usage/cmd/gpt.rst
> +++ b/doc/usage/cmd/gpt.rst
> @@ -85,6 +85,7 @@ information about a particular partition. The variables are:
> * gpt_partition_size (the size of the partition, in hexadecimal blocks)
> * gpt_partition_name (the name of the partition)
> * gpt_partition_entry (the partition number in the table, e.g. 1, 2, 3, etc.)
> +* gpt_partition_bootable (1 if the partition is marked as bootable, 0 if not)
>
> To get the information about the partition named 'rootfs', issue the
> following
> command:
> @@ -99,6 +100,8 @@ command:
> rootfs
> => echo ${gpt_partition_entry}
> 2
> +=> echo ${gpt_partition_bootable}
> +0
>
> The 'gpt enumerate' command will set the variable 'gpt_partition_list' with
> the
> list of partition names on the device. For example:
> diff --git a/test/py/tests/test_gpt.py b/test/py/tests/test_gpt.py
> index 339468bc12..1537ceb8c8 100644
> --- a/test/py/tests/test_gpt.py
> +++ b/test/py/tests/test_gpt.py
> @@ -49,6 +49,7 @@ class GptTestDiskImage(object):
> u_boot_utils.run_and_log(u_boot_console, cmd)
> # part1 offset 1MB size 1MB
> cmd = ('sgdisk', '--new=1:2048:4095',
> '--change-name=1:part1',
> +'-A 1:set:2',
> persistent)
> # part2 offset 2MB size 1.5MB
> u_boot_utils.run_and_log(u_boot_console, cmd)
> @@ -117,6 +118,38 @@ def test_gpt_guid(state_disk_image, u_boot_console):
> output = u_boot_console.run_command('gpt guid host 0')
> assert '375a56f7-d6c9-4e81-b5f0-09d41ca89efe' in output
>
> +@pytest.mark.boardspec('sandbox')
> +@pytest.mark.buildconfigspec('cmd_gpt')
> +@pytest.mark.requiredtool('sgdisk')
> +def test_gpt_setenv(state_disk_image, u_boot_console):
> +"""Test the gpt setenv command."""
> +u_boot_console.run_command('host bind 0 ' + state_disk_image.path)
> +output = u_boot_console.run_command('gpt setenv host 0 part1')
> +assert 'success!' in output
> +output = u_boot_console.run_command('echo ${gpt_partition_addr}')
> +assert output.rstrip() == '800'
> +output = u_boot_console.run_command('echo ${gpt_partition_size}')
> +assert output.rstrip() == '800'
> +output = u_boot_console.run_command('echo ${gpt_partition_name}')
> +assert output.rstrip() == 'part1'
> +output = u_boot_console.run_command('echo ${gpt_partition_entry}')
> +assert output.rstrip() == "1"
> +output = u_boot_console.run_command('echo ${gpt_partition_bootable}')
> +assert output.rstrip() == "1"
> +
> +output = u_boot_console.run_command('gpt setenv host 0 part2')
> +assert 'success!' in output
> +output = u_boot_console.run_command('echo ${gpt_partition_addr}')
> +assert output.rstrip() == '1000'
> +output = u_boot_console.run_command('echo ${gpt_partition_size}')
> +assert output.rstrip() == 'c00'
> +output = u_boot_console.run_command('echo
Re: [PATCH v2 5/8] cmd: gpt: Add command to set bootable flags
On Wed, 23 Aug 2023 at 10:48, Joshua Watt wrote: > > Adds a command that can be used to modify the GPT partition table to > indicate which partitions should have the bootable flag set > > Signed-off-by: Joshua Watt > --- > cmd/gpt.c | 79 +++ > doc/usage/cmd/gpt.rst | 9 + > test/py/tests/test_gpt.py | 22 +++ > 3 files changed, 110 insertions(+) > Reviewed-by: Simon Glass
[PATCH 1/1] MAINTAINERS: remove Wolfgang Denk
Signed-off-by: Heinrich Schuchardt --- MAINTAINERS | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 47581cf6fb..5bee7ed93a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -960,7 +960,6 @@ F: tools/mkeficapsule.c ENVIRONMENT M: Joe Hershberger -R: Wolfgang Denk S: Maintained F: env/ F: include/env* @@ -970,7 +969,6 @@ F: tools/mkenvimage.c ENVIRONMENT AS TEXT M: Simon Glass -R: Wolfgang Denk S: Maintained F: doc/usage/environment.rst F: scripts/env2string.awk @@ -1288,8 +1286,7 @@ F:drivers/power/ F: include/power/ POWERPC -M: Wolfgang Denk -S: Maintained +S: Orphan (Since 2022-10-21) F: arch/powerpc/ POWERPC MPC8XX -- 2.40.1
Re: [PATCH v2 00/10] Introduce initial TI's J784S4 support
On 8/22/23 03:18, Enric Balletbo i Serra wrote: * Temperature sensors, user push buttons and LEDs * 40-pin User Expansion Connector * x2 ENET Expansion Connector, x1 GESI expander, x2 Display connector * x1 15-pin CSI header * x6 MCAN instances Schematics:https://www.ti.com/lit/zip/sprr458 bootlog:https://paste.sr.ht/~hnagalla/f14840abc854519f912923662f1fdc8075d92107 Many thanks for this patchset. There is any plan to rebase all this patchset, fix the comments and send it again to upstream? I'd be really interested in help on this patchset. Thanks, Enric Hi Enric, Yes, we will rebase and send the patch set shortly. Sorry for the delay. Thanks Hari
[PATCH v2 1/1] doc: describe TPL/VPL/SPL boot
This is a stub describing how TPL, VPL, and SPL load the next boot stages on a detail level for users. For sure we will need a few patches on top to catch the whole complexity. Signed-off-by: Heinrich Schuchardt --- v2: Mention that PowerPC uses a different naming convention. Group boot devices by type Correct reference to UBI Fix typos --- doc/usage/index.rst| 1 + doc/usage/spl_boot.rst | 321 + 2 files changed, 322 insertions(+) create mode 100644 doc/usage/spl_boot.rst diff --git a/doc/usage/index.rst b/doc/usage/index.rst index 072db53614..7f0b26cc5a 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -4,6 +4,7 @@ Use U-Boot .. toctree:: :maxdepth: 1 + spl_boot blkmap dfu environment diff --git a/doc/usage/spl_boot.rst b/doc/usage/spl_boot.rst new file mode 100644 index 00..7234d0b1b2 --- /dev/null +++ b/doc/usage/spl_boot.rst @@ -0,0 +1,321 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Booting from TPL/SPL + + +The main U-Boot binary may be too large to be loaded directly by the Boot ROM. +This was the own driver for splitting up U-Boot into multiple boot stages. + +U-Boot typically goes through the following boot phases where TPL, VPL, and SPL +are optional. While many boards use SPL only few use TPL. + +TPL + Tiny program loader. Very early init, as tiny as possible. This loads SPL + (or VPL if enabled). + +VPL + Optional verification step, which can select one of several SPL binaries, + if A/B verified boot is enabled. Implementation of the VPL logic is + work-in-progress. For now it just boots into SPL. + +SPL + Secondary program loader. Sets up SDRAM and loads U-Boot proper. It may also + load other firmware components. + +U-Boot + U-Boot proper, containing the command line and the logic to load an + operating system, e.g. via UEFI. + +The naming convention on the PowerPC architecture deviates from the other +archtitectures. Here the boot sequence is SPL->TPL->U-Boot. + +Only main U-Boot has a command line interface. + +Further usages for U-Boot SPL comprise: + +* launching BL31 of ARM Trusted Firmware which invokes U-Boot as BL33 +* launching EDK II +* launching Linux +* launching RISC-V OpenSBI which invokes main U-Boot + +Target binaries +--- + +Binaries loaded by SPL/TPL can be: + +* raw binaries where the entry address equals the start address. This is the + only binary format supported by TPL. +* :doc:`FIT ` images +* legacy U-Boot images + +Configuration +~ + +Raw images are only supported in SPL if CONFIG_SPL_RAW_IMAGE_SUPPORT=y. + +CONFIG_SPL_FIT=y and CONFIG_SPL_LOAD_FIT=y are needed to load FIT images. + +CONFIG_SPL_LEGACY_IMAGE_FORMAT=y is needed to load legacy U-Boot images. +CONFIG_SPL_LEGACY_IMAGE_CRC_CHECK=y enables checking the CRC32 of legacy U-Boot +images. + +Image load methods +-- + +The image boot methods available for a board must be defined in two places: + +The board code implements a function board_boot_order() enumerating up to +five boot methods and the sequence in which they are tried. (The maximum +number of boot methods is currently hard coded as variable spl_boot_list[]). +If there is only one boot method function, spl_boot_device() may be implemented +instead. + +The configuration controls which of these boot methods are actually available. + +Loading from block devices +~~ + +MMC1, MMC2, MMC2_2 +These methods read an image from SD card or eMMC. The first digit after +'MMC' indicates the device number. Required configuration settings include: + +* CONFIG_SPL_MMC=y or CONFIG_TPL_MMC=y + +To use a PCI connected MMC controller you need to additionally specify: + +* CONFIG_SPL_PCI=y + +* CONFIG_SPL_PCI_PNP=y + +* CONFIG_MMC=y + +* CONFIG_MMC_PCI=y + +* CONFIG_MMC_SDHCI=y + +To load from a file system use: + +* CONFIG_SPL_FS_FAT=y or CONFIG_SPL_FS_EXT=y + +* CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="" + +NVMe +This methods load the image from an NVMe drive. +Required configuration settings include: + +* CONFIG_SPL_PCI=y + +* CONFIG_SPL_PCI_PNP=y + +* CONFIG_SPL_NVME=y + +* CONFIG_SPL_NVME_PCI=y + +* CONFIG_SPL_NVME_BOOT_DEVICE (number of the NVMe device) + +* CONFIG_SYS_NVME_BOOT_PARTITION (partition to read from) + +To load from a file system use: + +* CONFIG_SPL_FS_FAT=y or CONFIG_SPL_FS_EXT=y + +* CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="" + +SATA +This method reads an image from a SATA drive. +Required configuration settings include: + +* CONFIG_SPL_SATA=y or CONFIG_TPL_SATA=y + +To use a PCIe connecte SATA controller you additionally need: + +* CONFIG_SPL_PCI=y + +* CONFIG_SPL_SATA=y + +* CONFIG_SPL_AHCI_PCI=y + +* CONFIG_SPL_PCI_PNP=y + +To load from a file system use: + +* CONFIG_SPL_FS_FAT=y + +*
[PATCH v4 19/20] x86: doc: Split out manual booting into its own file
Move this out of the main file since for simple users it is easier to rely on standard boot. Signed-off-by: Simon Glass --- (no changes since v2) Changes in v2: - Add new patch doc/arch/x86/index.rst | 1 + doc/arch/x86/manual_boot.rst | 276 +++ doc/arch/x86/x86.rst | 272 +- 3 files changed, 280 insertions(+), 269 deletions(-) create mode 100644 doc/arch/x86/manual_boot.rst diff --git a/doc/arch/x86/index.rst b/doc/arch/x86/index.rst index 3dc19d603d4..69db0a5d648 100644 --- a/doc/arch/x86/index.rst +++ b/doc/arch/x86/index.rst @@ -9,3 +9,4 @@ x86 :maxdepth: 2 x86 + manual_boot diff --git a/doc/arch/x86/manual_boot.rst b/doc/arch/x86/manual_boot.rst new file mode 100644 index 000..ec069f2c397 --- /dev/null +++ b/doc/arch/x86/manual_boot.rst @@ -0,0 +1,276 @@ +Booting Ubuntu Manually +--- + +This shows a manual approach to booting Ubuntu without standard boot or the EFI +interface. + +As an example of how to set up your boot flow with U-Boot, here are +instructions for starting Ubuntu from U-Boot. These instructions have been +tested on Minnowboard MAX with a SATA drive but are equally applicable on +other platforms and other media. There are really only four steps and it's a +very simple script, but a more detailed explanation is provided here for +completeness. + +Note: It is possible to set up U-Boot to boot automatically using syslinux. +It could also use the grub.cfg file (/efi/ubuntu/grub.cfg) to obtain the +GUID. If you figure these out, please post patches to this README. + +Firstly, you will need Ubuntu installed on an available disk. It should be +possible to make U-Boot start a USB start-up disk but for now let's assume +that you used another boot loader to install Ubuntu. + +Use the U-Boot command line to find the UUID of the partition you want to +boot. For example our disk is SCSI device 0:: + + => part list scsi 0 + + Partition Map for SCSI device 0 -- Partition Type: EFI + + Part Start LBA End LBA Name +Attributes +Type GUID +Partition GUID + 10x0800 0x001007ff "" +attrs: 0x +type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b +guid: 9d02e8e4-4d59-408f-a9b0-fd497bc9291c + 20x00100800 0x037d8fff "" +attrs: 0x +type: 0fc63daf-8483-4772-8e79-3d69d8477de4 +guid: 965c59ee-1822-4326-90d2-b02446050059 + 30x037d9000 0x03ba27ff "" +attrs: 0x +type: 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f +guid: 2c4282bd-1e82-4bcf-a5ff-51dedbf39f17 + => + +This shows that your SCSI disk has three partitions. The really long hex +strings are called Globally Unique Identifiers (GUIDs). You can look up the +'type' ones `here`_. On this disk the first partition is for EFI and is in +VFAT format (DOS/Windows):: + + => fatls scsi 0:1 + efi/ + + 0 file(s), 1 dir(s) + + +Partition 2 is 'Linux filesystem data' so that will be our root disk. It is +in ext2 format:: + + => ext2ls scsi 0:2 + 4096 . + 4096 .. + 16384 lost+found + 4096 boot + 12288 etc + 4096 media + 4096 bin + 4096 dev + 4096 home + 4096 lib + 4096 lib64 + 4096 mnt + 4096 opt + 4096 proc + 4096 root + 4096 run + 12288 sbin + 4096 srv + 4096 sys + 4096 tmp + 4096 usr + 4096 var +33 initrd.img +30 vmlinuz + 4096 cdrom +33 initrd.img.old + => + +and if you look in the /boot directory you will see the kernel:: + + => ext2ls scsi 0:2 /boot + 4096 . + 4096 .. + 4096 efi + 4096 grub +3381262 System.map-3.13.0-32-generic +1162712 abi-3.13.0-32-generic + 165611 config-3.13.0-32-generic + 176500 memtest86+.bin + 178176 memtest86+.elf + 178680 memtest86+_multiboot.bin +5798112 vmlinuz-3.13.0-32-generic + 165762 config-3.13.0-58-generic +1165129 abi-3.13.0-58-generic +5823136 vmlinuz-3.13.0-58-generic + 19215259 initrd.img-3.13.0-58-generic +3391763 System.map-3.13.0-58-generic +5825048 vmlinuz-3.13.0-58-generic.efi.signed + 28304443 initrd.img-3.13.0-32-generic + => + +The 'vmlinuz' files contain a packaged Linux kernel. The format is a kind of +self-extracting compressed file mixed with some 'setup' configuration data. +Despite its size (uncompressed it is >10MB) this only includes a basic set of +device drivers, enough to boot on most hardware types. + +The 'initrd' files contain a RAM disk. This is something that can be loaded +into RAM and will
[PATCH v4 20/20] x86: doc: coreboot: Mention 64-bit Linux distros
Add a little more detail as to why coreboot64 is preferred for booting Linux distros. Signed-off-by: Simon Glass --- (no changes since v2) Changes in v2: - Add new patch doc/board/coreboot/coreboot.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/board/coreboot/coreboot.rst b/doc/board/coreboot/coreboot.rst index 88437c27740..a32c3a864f9 100644 --- a/doc/board/coreboot/coreboot.rst +++ b/doc/board/coreboot/coreboot.rst @@ -82,6 +82,8 @@ build in `$CBDIR`:: -device ahci,id=ahci \ -device ide-hd,drive=disk,bus=ahci.0 \ +This allows booting and installing various distros, many of which are +64-bit-only, so cannot work with the 32-bit 'coreboot' build. CBFS access --- -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v4 18/20] x86: doc: Update summaries and add links
Refresh the summary information so it is more up-to-date. Add links to the coreboot and slimbootloader docs. Signed-off-by: Simon Glass --- (no changes since v2) Changes in v2: - Add new patch doc/arch/x86/x86.rst | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/doc/arch/x86/x86.rst b/doc/arch/x86/x86.rst index ef6970b88a5..e75b5a73ffc 100644 --- a/doc/arch/x86/x86.rst +++ b/doc/arch/x86/x86.rst @@ -11,9 +11,9 @@ including supported boards, build instructions, todo list, etc. Status -- U-Boot supports running as a `coreboot`_ payload on x86. So far only Link -(Chromebook Pixel) and `QEMU`_ x86 targets have been tested, but it should -work with minimal adjustments on other x86 boards since coreboot deals with -most of the low-level details. +(Chromebook Pixel), Brya (Alder Lake Chromebook) and `QEMU`_ x86 targets have +been tested, but it should work with minimal adjustments on other x86 boards +since coreboot deals with most of the low-level details. U-Boot is a main bootloader on Intel Edison board. @@ -31,12 +31,14 @@ are supported: - Link (Chromebook Pixel) - Minnowboard MAX - Samus (Chromebook Pixel 2015) + - Coral (Apollo Lake Chromebooks circa 2017) - QEMU x86 (32-bit & 64-bit) As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit Linux kernel as part of a FIT image. It also supports a compressed zImage. U-Boot supports loading an x86 VxWorks kernel. Please check README.vxworks -for more details. +for more details. Finally, U-Boot can boot Linux distributions with a UEFI +interface. Build Instructions for U-Boot as BIOS replacement (bare mode) - @@ -700,9 +702,10 @@ for details of EFI support in U-Boot. Chain-loading - -U-Boot can be chain-loaded from another bootloader, such as coreboot or -Slim Bootloader. Typically this is done by building for targets 'coreboot' or -'slimbootloader'. +U-Boot can be chain-loaded from another bootloader, such as +:doc:`../../board/coreboot/index` coreboot or +:doc:`../../board/intel/slimbootloader`. Typically this is done by building for +targets 'coreboot' or 'slimbootloader'. For example, at present we have a 'coreboot' target but this runs very different code from the bare-metal targets, such as coral. There is very little -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v4 17/20] x86: doc: Move into its own directory
There is enough material that it makes sense to split this up into
several files. Create an x86/ directory for this purpose.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Add new patch
doc/arch/index.rst | 2 +-
doc/arch/x86/index.rst | 11 +++
doc/arch/{ => x86}/x86.rst | 6 +++---
3 files changed, 15 insertions(+), 4 deletions(-)
create mode 100644 doc/arch/x86/index.rst
rename doc/arch/{ => x86}/x86.rst (99%)
diff --git a/doc/arch/index.rst b/doc/arch/index.rst
index 2f916f4026c..60c93b3b664 100644
--- a/doc/arch/index.rst
+++ b/doc/arch/index.rst
@@ -15,5 +15,5 @@ Architecture-specific doc
riscv
sandbox/index
sh
- x86
+ x86/index
xtensa
diff --git a/doc/arch/x86/index.rst b/doc/arch/x86/index.rst
new file mode 100644
index 000..3dc19d603d4
--- /dev/null
+++ b/doc/arch/x86/index.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0+ */
+.. Copyright 2023 Google LLC
+.. sectionauthor:: Simon Glass
+
+x86
+===
+
+.. toctree::
+ :maxdepth: 2
+
+ x86
diff --git a/doc/arch/x86.rst b/doc/arch/x86/x86.rst
similarity index 99%
rename from doc/arch/x86.rst
rename to doc/arch/x86/x86.rst
index 725a1ae5863..ef6970b88a5 100644
--- a/doc/arch/x86.rst
+++ b/doc/arch/x86/x86.rst
@@ -695,8 +695,8 @@ to load a 'u-boot-payload.efi', see below test logs on QEMU.
No controllers found
Hit any key to stop autoboot: 0
-See :doc:`../develop/uefi/u-boot_on_efi` and :doc:`../develop/uefi/uefi` for
-details of EFI support in U-Boot.
+See :doc:`../../develop/uefi/u-boot_on_efi` and :doc:`../../develop/uefi/uefi`
+for details of EFI support in U-Boot.
Chain-loading
-
@@ -732,7 +732,7 @@ SMBIOS tables
To generate SMBIOS tables in U-Boot, for use by the OS, enable the
CONFIG_GENERATE_SMBIOS_TABLE option. The easiest way to provide the values to
use is via the device tree. For details see
-:download:`smbios.txt <../device-tree-bindings/sysinfo/smbios.txt>`.
+:download:`smbios.txt <../../device-tree-bindings/sysinfo/smbios.txt>`.
TODO List
-
--
2.42.0.rc1.204.g551eb34607-goog
[PATCH v4 16/20] x86: coreboot: Record the position of the SMBIOS tables
Make a note of where coreboot installed the SMBIOS tables so that we can pass this on to EFI. Signed-off-by: Simon Glass --- (no changes since v2) Changes in v2: - Add new patch arch/x86/lib/coreboot/cb_sysinfo.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/lib/coreboot/cb_sysinfo.c b/arch/x86/lib/coreboot/cb_sysinfo.c index dfbc80c430e..f7fd9ea5bcb 100644 --- a/arch/x86/lib/coreboot/cb_sysinfo.c +++ b/arch/x86/lib/coreboot/cb_sysinfo.c @@ -471,6 +471,7 @@ int get_coreboot_info(struct sysinfo_t *info) return -ENOENT; gd->arch.coreboot_table = addr; gd_set_acpi_start(map_to_sysmem(info->rsdp)); + gd_set_smbios_start(info->smbios_start); gd->flags |= GD_FLG_SKIP_LL_INIT; return 0; -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v4 15/20] efi: Use the installed SMBIOS tables
U-Boot should set up the SMBIOS tables during startup, as it does on x86.
Ensure that it does this correctly on non-x86 machines too, by creating
an event spy for last-stage init.
Tidy up the installation-condition code while we are here. For
mvebu_armada-37xx add a dependcy on DM_MDIO since it seems that
last_stage_init() is only enabled for some boards.
Signed-off-by: Simon Glass
---
Changes in v4:
- Rewrite this to use events instead
Changes in v3:
- Use log_debug() to show the message
- Squash in the next patch
Changes in v2:
- Add new patch
board/Marvell/mvebu_armada-37xx/board.c | 2 +
lib/Kconfig | 1 +
lib/efi_loader/Makefile | 2 +-
lib/efi_loader/efi_setup.c | 10 ++--
lib/efi_loader/efi_smbios.c | 72 -
test/py/tests/test_event_dump.py| 1 +
6 files changed, 56 insertions(+), 32 deletions(-)
diff --git a/board/Marvell/mvebu_armada-37xx/board.c
b/board/Marvell/mvebu_armada-37xx/board.c
index 3fe5319437e..bd054240b34 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -307,6 +307,8 @@ static int last_stage_init(void)
struct udevice *bus;
ofnode node;
+ if (!IS_ENABLED(CONFIG_DM_MDIO))
+ return 0;
if (!of_machine_is_compatible("globalscale,espressobin"))
return 0;
diff --git a/lib/Kconfig b/lib/Kconfig
index dac0e32649a..d11780293cc 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -1058,6 +1058,7 @@ config SMBIOS
bool "SMBIOS support"
depends on X86 || EFI_LOADER
default y
+ select LAST_STAGE_INIT
help
Indicates that this platform can support System Management BIOS
(SMBIOS) tables. These provide various pieces of information about
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 0eb748ff1a5..8d31fc61c60 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -79,7 +79,7 @@ obj-$(CONFIG_VIDEO) += efi_gop.o
obj-$(CONFIG_BLK) += efi_disk.o
obj-$(CONFIG_NETDEVICES) += efi_net.o
obj-$(CONFIG_ACPI) += efi_acpi.o
-obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o
+obj-$(CONFIG_SMBIOS) += efi_smbios.o
obj-$(CONFIG_EFI_RNG_PROTOCOL) += efi_rng.o
obj-$(CONFIG_EFI_TCG2_PROTOCOL) += efi_tcg2.o
obj-$(CONFIG_EFI_RISCV_BOOT_PROTOCOL) += efi_riscv.o
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index ad719afd632..e6de685e879 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -326,11 +326,11 @@ efi_status_t efi_init_obj_list(void)
if (ret != EFI_SUCCESS)
goto out;
}
-#ifdef CONFIG_GENERATE_SMBIOS_TABLE
- ret = efi_smbios_register();
- if (ret != EFI_SUCCESS)
- goto out;
-#endif
+ if (IS_ENABLED(CONFIG_SMBIOS)) {
+ ret = efi_smbios_register();
+ if (ret != EFI_SUCCESS)
+ goto out;
+ }
ret = efi_watchdog_register();
if (ret != EFI_SUCCESS)
goto out;
diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c
index 306c0bc54f9..48446f654d9 100644
--- a/lib/efi_loader/efi_smbios.c
+++ b/lib/efi_loader/efi_smbios.c
@@ -10,8 +10,14 @@
#include
#include
#include
+#include
#include
#include
+#include
+
+enum {
+ TABLE_SIZE = SZ_4K,
+};
/*
* Install the SMBIOS table as a configuration table.
@@ -20,36 +26,50 @@
*/
efi_status_t efi_smbios_register(void)
{
- /* Map within the low 32 bits, to allow for 32bit SMBIOS tables */
- u64 dmi_addr = U32_MAX;
+ ulong addr;
efi_status_t ret;
- void *dmi;
- /* Reserve 4kiB page for SMBIOS */
- ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
-EFI_RUNTIME_SERVICES_DATA, 1, _addr);
+ addr = gd->arch.smbios_start;
+ if (!addr) {
+ log_err("No SMBIOS tables to install\n");
+ return EFI_NOT_FOUND;
+ }
+
+ /* Mark space used for tables */
+ ret = efi_add_memory_map(addr, TABLE_SIZE, EFI_RUNTIME_SERVICES_DATA);
+ if (ret)
+ return ret;
+
+ log_debug("EFI using SMBIOS tables at %lx\n", addr);
+
+ /* Install SMBIOS information as configuration table */
+ return efi_install_configuration_table(_guid,
+ map_sysmem(addr, 0));
+}
+
+static int install_smbios_table(void)
+{
+ ulong addr;
+ void *buf;
- if (ret != EFI_SUCCESS) {
- /* Could not find space in lowmem, use highmem instead */
- ret = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES,
-EFI_RUNTIME_SERVICES_DATA, 1,
-_addr);
+ if (!IS_ENABLED(CONFIG_GENERATE_SMBIOS_TABLE) || IS_ENABLED(CONFIG_X86))
+ return 0;
-
[PATCH v4 13/20] bootstd: Keep track of use of usb stop
When 'usb stop' is run, doing 'bootflow scan' does not run the USB hunter
again so does not see any devices. Fix this by telling bootstd about the
state of USB.
Signed-off-by: Simon Glass
---
(no changes since v1)
boot/bootdev-uclass.c | 27 +++
drivers/usb/host/usb-uclass.c | 8
include/bootdev.h | 9 +
3 files changed, 44 insertions(+)
diff --git a/boot/bootdev-uclass.c b/boot/bootdev-uclass.c
index fa52bc3a9c4..f91495b0682 100644
--- a/boot/bootdev-uclass.c
+++ b/boot/bootdev-uclass.c
@@ -820,6 +820,33 @@ int bootdev_hunt(const char *spec, bool show)
return result;
}
+int bootdev_unhunt(enum uclass_id id)
+{
+ struct bootdev_hunter *start;
+ int n_ent, i;
+
+ start = ll_entry_start(struct bootdev_hunter, bootdev_hunter);
+ n_ent = ll_entry_count(struct bootdev_hunter, bootdev_hunter);
+ for (i = 0; i < n_ent; i++) {
+ struct bootdev_hunter *info = start + i;
+
+ if (info->uclass == id) {
+ struct bootstd_priv *std;
+ int ret;
+
+ ret = bootstd_get_priv();
+ if (ret)
+ return log_msg_ret("std", ret);
+ if (!(std->hunters_used & BIT(i)))
+ return -EALREADY;
+ std->hunters_used &= ~BIT(i);
+ return 0;
+ }
+ }
+
+ return -ENOENT;
+}
+
int bootdev_hunt_prio(enum bootdev_prio_t prio, bool show)
{
struct bootdev_hunter *start;
diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
index 7a03435ba77..9dee7b98078 100644
--- a/drivers/usb/host/usb-uclass.c
+++ b/drivers/usb/host/usb-uclass.c
@@ -9,6 +9,7 @@
#define LOG_CATEGORY UCLASS_USB
#include
+#include
#include
#include
#include
@@ -208,6 +209,13 @@ int usb_stop(void)
#ifdef CONFIG_USB_STORAGE
usb_stor_reset();
#endif
+ if (CONFIG_IS_ENABLED(BOOTSTD)) {
+ int ret;
+
+ ret = bootdev_unhunt(UCLASS_USB);
+ if (IS_ENABLED(CONFIG_BOOTSTD_FULL) && ret && ret != -EALREADY)
+ printf("failed to unhunt USB (err=%dE)\n", ret);
+ }
uc_priv->companion_device_count = 0;
usb_started = 0;
diff --git a/include/bootdev.h b/include/bootdev.h
index 848233187f8..b079a91b5b7 100644
--- a/include/bootdev.h
+++ b/include/bootdev.h
@@ -320,6 +320,15 @@ int bootdev_hunt(const char *spec, bool show);
*/
int bootdev_hunt_prio(enum bootdev_prio_t prio, bool show);
+/**
+ * bootdev_unhunt() - Mark a device as needing to be hunted again
+ *
+ * @id: uclass ID to update
+ * Return: 0 if done, -EALREADY if already in this state, -ENOENT if no hunter
+ * found for that uclass
+ */
+int bootdev_unhunt(enum uclass_id id);
+
/**
* bootdev_hunt_and_find_by_label() - Hunt for bootdevs by label
*
--
2.42.0.rc1.204.g551eb34607-goog
[PATCH v4 14/20] Record the position of the SMBIOS tables
Remember where these end up so that we can pass this information on to
the EFI layer.
Signed-off-by: Simon Glass
---
Changes in v4:
- Fix arm and riscv
Changes in v2:
- Add new patch
arch/arm/include/asm/global_data.h | 3 +++
arch/riscv/include/asm/global_data.h | 3 +++
arch/sandbox/include/asm/global_data.h | 1 +
arch/x86/include/asm/global_data.h | 1 +
arch/x86/lib/tables.c | 3 +++
include/asm-generic/global_data.h | 8
6 files changed, 19 insertions(+)
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index 2a222c53882..b385bae0266 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -102,6 +102,9 @@ struct arch_global_data {
#ifdef CONFIG_ARCH_IMX8ULP
bool m33_handshake_done;
#endif
+#ifdef CONFIG_SMBIOS
+ ulong smbios_start; /* Start address of SMBIOS table */
+#endif
};
#include
diff --git a/arch/riscv/include/asm/global_data.h
b/arch/riscv/include/asm/global_data.h
index 9d97517e124..937fa4d1544 100644
--- a/arch/riscv/include/asm/global_data.h
+++ b/arch/riscv/include/asm/global_data.h
@@ -32,6 +32,9 @@ struct arch_global_data {
ulong available_harts;
#endif
#endif
+#ifdef CONFIG_SMBIOS
+ ulong smbios_start; /* Start address of SMBIOS table */
+#endif
};
#include
diff --git a/arch/sandbox/include/asm/global_data.h
b/arch/sandbox/include/asm/global_data.h
index f0ab3ba5c14..c6977735029 100644
--- a/arch/sandbox/include/asm/global_data.h
+++ b/arch/sandbox/include/asm/global_data.h
@@ -17,6 +17,7 @@ struct arch_global_data {
ulong table_end;/* End address of x86 tables */
ulong table_start_high; /* Start address of high x86 tables */
ulong table_end_high; /* End address of high x86 tables */
+ ulong smbios_start; /* Start address of SMBIOS table */
};
#include
diff --git a/arch/x86/include/asm/global_data.h
b/arch/x86/include/asm/global_data.h
index ea58259ad77..6f4a7130f1d 100644
--- a/arch/x86/include/asm/global_data.h
+++ b/arch/x86/include/asm/global_data.h
@@ -127,6 +127,7 @@ struct arch_global_data {
ulong table_end;/* End address of x86 tables */
ulong table_start_high; /* Start address of high x86 tables */
ulong table_end_high; /* End address of high x86 tables */
+ ulong smbios_start; /* Start address of SMBIOS table */
};
#endif
diff --git a/arch/x86/lib/tables.c b/arch/x86/lib/tables.c
index 67bc0a72aeb..5b5070f7ca5 100644
--- a/arch/x86/lib/tables.c
+++ b/arch/x86/lib/tables.c
@@ -97,6 +97,9 @@ int write_tables(void)
int size = table->size ? : CONFIG_ROM_TABLE_SIZE;
u32 rom_table_end;
+ if (!strcmp("smbios", table->name))
+ gd->arch.smbios_start = rom_addr;
+
if (IS_ENABLED(CONFIG_BLOBLIST_TABLES) && table->tag) {
if (!gd->arch.table_end)
gd->arch.table_end = rom_addr;
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index 8fc205ded1a..3421daea363 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -552,6 +552,14 @@ static_assert(sizeof(struct global_data) == GD_SIZE);
#define gd_set_acpi_start(addr)
#endif
+#ifdef CONFIG_SMBIOS
+#define gd_smbios_start() gd->smbios_start
+#define gd_set_smbios_start(addr) gd->arch.smbios_start = addr
+#else
+#define gd_smbios_start() 0UL
+#define gd_set_smbios_start(addr)
+#endif
+
#if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
#define gd_multi_dtb_fit() gd->multi_dtb_fit
#define gd_set_multi_dtb_fit(_dtb) gd->multi_dtb_fit = _dtb
--
2.42.0.rc1.204.g551eb34607-goog
[PATCH v4 12/20] x86: smbios: Add a Kconfig indicating SMBIOS-table presence
When booted from coreboot, U-Boot does not build the SMBIOS tables, but it should still pass them on to the OS. Add a new option which indicates whether SMBIOS tables are present, however they were built. Flip the ordering so that the dependency is listed first, which is less confusing. Adjust GENERATE_SMBIOS_TABLE to depend on this new symbol. Signed-off-by: Simon Glass Reviewed-by: Heinrich Schuchardt --- (no changes since v3) Changes in v3: - Allow SMBIOS if EFI_LOADER is enabled - Reword the help Changes in v2: - Add new patch lib/Kconfig | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/lib/Kconfig b/lib/Kconfig index 1d63099b8e1..dac0e32649a 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -984,8 +984,8 @@ config BLOBLIST_TABLES config GENERATE_SMBIOS_TABLE bool "Generate an SMBIOS (System Management BIOS) table" + depends on SMBIOS default y - depends on X86 || EFI_LOADER help The System Management BIOS (SMBIOS) specification addresses how motherboard and system vendors present management information about @@ -1054,6 +1054,19 @@ config SPL_OID_REGISTRY unambiguous persistent name (https://en.wikipedia.org/wiki/Object_identifier). Enable fast lookup object identifier registry in the SPL. +config SMBIOS + bool "SMBIOS support" + depends on X86 || EFI_LOADER + default y + help + Indicates that this platform can support System Management BIOS + (SMBIOS) tables. These provide various pieces of information about + the board, such as the manufacturer and the model name. + + See GENERATE_SMBIOS_TABLE which controls whether U-Boot actually + creates these tables, rather than them coming from a previous firmware + stage. + config SMBIOS_PARSER bool "SMBIOS parser" help -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v4 11/20] efi: x86: Correct the condition for installing ACPI tables
It is not always the case that U-Boot builds the ACPI tables itself. For
example, when booting from coreboot, the ACPI tables are built by
coreboot.
Correct the Makefile condition so that U-Boot can pass on tables built
by a previous firmware stage.
Tidy up the installation-condition code while we are here.
Signed-off-by: Simon Glass
Reviewed-by: Ilias Apalodimas
---
(no changes since v2)
Changes in v2:
- Add new patch
lib/efi_loader/Makefile| 2 +-
lib/efi_loader/efi_setup.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 1a8c8d7cab5..0eb748ff1a5 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -78,7 +78,7 @@ obj-$(CONFIG_EFI_ESRT) += efi_esrt.o
obj-$(CONFIG_VIDEO) += efi_gop.o
obj-$(CONFIG_BLK) += efi_disk.o
obj-$(CONFIG_NETDEVICES) += efi_net.o
-obj-$(CONFIG_GENERATE_ACPI_TABLE) += efi_acpi.o
+obj-$(CONFIG_ACPI) += efi_acpi.o
obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o
obj-$(CONFIG_EFI_RNG_PROTOCOL) += efi_rng.o
obj-$(CONFIG_EFI_TCG2_PROTOCOL) += efi_tcg2.o
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index 58d4e134023..ad719afd632 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -321,11 +321,11 @@ efi_status_t efi_init_obj_list(void)
if (ret != EFI_SUCCESS)
goto out;
#endif
-#ifdef CONFIG_GENERATE_ACPI_TABLE
- ret = efi_acpi_register();
- if (ret != EFI_SUCCESS)
- goto out;
-#endif
+ if (IS_ENABLED(CONFIG_ACPI)) {
+ ret = efi_acpi_register();
+ if (ret != EFI_SUCCESS)
+ goto out;
+ }
#ifdef CONFIG_GENERATE_SMBIOS_TABLE
ret = efi_smbios_register();
if (ret != EFI_SUCCESS)
--
2.42.0.rc1.204.g551eb34607-goog
[PATCH v4 10/20] x86: coreboot: Enable VIDEO_COPY
At least on modern machines the write-back mechanism for the frame buffer
is quite slow when scrolling, since it must read the entire frame buffer
and write it back.
Enable the VIDEO_COPY feature to resolve this problem.
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/x86/dts/coreboot.dts| 1 +
configs/coreboot64_defconfig | 1 +
configs/coreboot_defconfig | 1 +
drivers/video/coreboot.c | 12
4 files changed, 15 insertions(+)
diff --git a/arch/x86/dts/coreboot.dts b/arch/x86/dts/coreboot.dts
index f9ff5346a79..0eb31cae42c 100644
--- a/arch/x86/dts/coreboot.dts
+++ b/arch/x86/dts/coreboot.dts
@@ -42,6 +42,7 @@
};
coreboot-fb {
+ bootph-some-ram;
compatible = "coreboot-fb";
};
};
diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig
index dc3548aa736..555d281ef3c 100644
--- a/configs/coreboot64_defconfig
+++ b/configs/coreboot64_defconfig
@@ -59,6 +59,7 @@ CONFIG_NVME_PCI=y
CONFIG_SYS_NS16550_MEM32=y
CONFIG_SOUND=y
CONFIG_SOUND_I8254=y
+CONFIG_VIDEO_COPY=y
CONFIG_CONSOLE_SCROLL_LINES=5
CONFIG_SPL_ACPI=y
CONFIG_CMD_DHRYSTONE=y
diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig
index 630eb9aa384..edc38f1f592 100644
--- a/configs/coreboot_defconfig
+++ b/configs/coreboot_defconfig
@@ -53,6 +53,7 @@ CONFIG_NVME_PCI=y
CONFIG_SYS_NS16550_MEM32=y
CONFIG_SOUND=y
CONFIG_SOUND_I8254=y
+CONFIG_VIDEO_COPY=y
CONFIG_CONSOLE_SCROLL_LINES=5
CONFIG_CMD_DHRYSTONE=y
# CONFIG_GZIP is not set
diff --git a/drivers/video/coreboot.c b/drivers/video/coreboot.c
index c586475e41e..5b718ae3e5a 100644
--- a/drivers/video/coreboot.c
+++ b/drivers/video/coreboot.c
@@ -73,6 +73,17 @@ err:
return ret;
}
+static int coreboot_video_bind(struct udevice *dev)
+{
+ struct video_uc_plat *uc_plat = dev_get_uclass_plat(dev);
+
+ /* Set the maximum supported resolution */
+ uc_plat->size = 4096 * 2160 * 4;
+ log_debug("%s: Frame buffer size %x\n", __func__, uc_plat->size);
+
+ return 0;
+}
+
static const struct udevice_id coreboot_video_ids[] = {
{ .compatible = "coreboot-fb" },
{ }
@@ -82,5 +93,6 @@ U_BOOT_DRIVER(coreboot_video) = {
.name = "coreboot_video",
.id = UCLASS_VIDEO,
.of_match = coreboot_video_ids,
+ .bind = coreboot_video_bind,
.probe = coreboot_video_probe,
};
--
2.42.0.rc1.204.g551eb34607-goog
[PATCH v4 09/20] x86: coreboot: Align options between coreboot and coreboot64
These two builds are similar but have some different options for not good reason. Line them up to be as similar as possible. Signed-off-by: Simon Glass --- (no changes since v2) Changes in v2: - Update the malloc size too configs/coreboot64_defconfig | 7 +++ configs/coreboot_defconfig | 9 - 2 files changed, 7 insertions(+), 9 deletions(-) diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index c0405633946..dc3548aa736 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -1,5 +1,6 @@ CONFIG_X86=y CONFIG_TEXT_BASE=0x112 +CONFIG_SYS_MALLOC_LEN=0x200 CONFIG_NR_DRAM_BANKS=8 CONFIG_ENV_SIZE=0x1000 CONFIG_DEFAULT_DEVICE_TREE="coreboot" @@ -18,6 +19,9 @@ CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" CONFIG_PRE_CONSOLE_BUFFER=y CONFIG_SYS_CONSOLE_INFO_QUIET=y +CONFIG_LOG=y +CONFIG_LOGF_LINE=y +CONFIG_LOGF_FUNC=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_SPL_NO_BSS_LIMIT=y CONFIG_SYS_PBSIZE=532 @@ -50,10 +54,13 @@ CONFIG_SYS_ATA_ALT_OFFSET=0 CONFIG_ATAPI=y CONFIG_LBA48=y CONFIG_SYS_64BIT_LBA=y +CONFIG_NVME_PCI=y # CONFIG_PCI_PNP is not set CONFIG_SYS_NS16550_MEM32=y CONFIG_SOUND=y CONFIG_SOUND_I8254=y CONFIG_CONSOLE_SCROLL_LINES=5 CONFIG_SPL_ACPI=y +CONFIG_CMD_DHRYSTONE=y # CONFIG_GZIP is not set +CONFIG_SMBIOS_PARSER=y diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index e7e45c2b0a9..630eb9aa384 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -24,23 +24,14 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_PCI_INIT_R=y CONFIG_CMD_IDE=y CONFIG_CMD_MMC=y -CONFIG_CMD_PART=y CONFIG_CMD_SATA=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set -CONFIG_CMD_DHCP=y CONFIG_BOOTP_BOOTFILESIZE=y -CONFIG_CMD_PING=y CONFIG_CMD_TIME=y CONFIG_CMD_SOUND=y -CONFIG_CMD_EXT2=y -CONFIG_CMD_EXT4=y CONFIG_CMD_EXT4_WRITE=y -CONFIG_CMD_FAT=y -CONFIG_CMD_FS_GENERIC=y CONFIG_MAC_PARTITION=y -CONFIG_ISO_PARTITION=y -CONFIG_EFI_PARTITION=y CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_USE_BOOTFILE=y -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v4 08/20] x86: coreboot: Drop USB init on startup
This is very annoying as it is quite slow on many machines. Also, U-Boot has an existing 'preboot' mechanism to enable this feature if desired. Drop this code so that it is possible to choose whether to init USB or not. Signed-off-by: Simon Glass --- (no changes since v1) arch/x86/cpu/coreboot/coreboot.c | 4 1 file changed, 4 deletions(-) diff --git a/arch/x86/cpu/coreboot/coreboot.c b/arch/x86/cpu/coreboot/coreboot.c index c2ceaa9a56c..567f1ab116c 100644 --- a/arch/x86/cpu/coreboot/coreboot.c +++ b/arch/x86/cpu/coreboot/coreboot.c @@ -86,10 +86,6 @@ static int last_stage_init(void) if (IS_ENABLED(CONFIG_SPL_BUILD)) return 0; - /* start usb so that usb keyboard can be used as input device */ - if (IS_ENABLED(CONFIG_USB_KEYBOARD)) - usb_init(); - board_final_init(); return 0; -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v4 07/20] x86: coreboot: Enable CONFIG_SYS_NS16550_MEM32
The debug UART on modern machines uses a 32-bit wide transfer. Without this, setting debug output causes a hang or no output. It is not obvious (when enabling CONFIG_DEBUG_UART) that this is needed. Enable 32-bit access to avoid this trap. Signed-off-by: Simon Glass --- (no changes since v1) configs/coreboot64_defconfig | 1 + configs/coreboot_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index e8165961c19..c0405633946 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -51,6 +51,7 @@ CONFIG_ATAPI=y CONFIG_LBA48=y CONFIG_SYS_64BIT_LBA=y # CONFIG_PCI_PNP is not set +CONFIG_SYS_NS16550_MEM32=y CONFIG_SOUND=y CONFIG_SOUND_I8254=y CONFIG_CONSOLE_SCROLL_LINES=5 diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index 311ca6672cb..e7e45c2b0a9 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -59,6 +59,7 @@ CONFIG_LBA48=y CONFIG_SYS_64BIT_LBA=y CONFIG_NVME_PCI=y # CONFIG_PCI_PNP is not set +CONFIG_SYS_NS16550_MEM32=y CONFIG_SOUND=y CONFIG_SOUND_I8254=y CONFIG_CONSOLE_SCROLL_LINES=5 -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v4 06/20] x86: coreboot: Look for DBG2 UART in SPL too
If coreboot does not set up sysinfo for the UART, SPL currently hangs. Use the DBG2 teechnique there as well. This allows coreboot64 to boot from coreboot even if the console info is missing from sysinfo Signed-off-by: Simon Glass --- (no changes since v1) configs/coreboot64_defconfig | 1 + drivers/serial/Kconfig | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index 5623197f6be..e8165961c19 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -54,4 +54,5 @@ CONFIG_SYS_64BIT_LBA=y CONFIG_SOUND=y CONFIG_SOUND_I8254=y CONFIG_CONSOLE_SCROLL_LINES=5 +CONFIG_SPL_ACPI=y # CONFIG_GZIP is not set diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index 7ca42df6a7e..27b4b9d9650 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -672,7 +672,7 @@ config COREBOOT_SERIAL config COREBOOT_SERIAL_FROM_DBG2 bool "Obtain UART from ACPI tables" depends on COREBOOT_SERIAL - default y if !SPL + default y help Select this to try to find a DBG2 record in the ACPI tables, in the event that coreboot does not provide information about the UART in the -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v4 05/20] x86: Allow APCI in SPL
This is needed so we can find the DBG2 table provided by coreboot. Add a Kconfig so it can be enabled. Signed-off-by: Simon Glass --- (no changes since v1) lib/Kconfig | 8 1 file changed, 8 insertions(+) diff --git a/lib/Kconfig b/lib/Kconfig index 42e559ad0b5..1d63099b8e1 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -289,6 +289,14 @@ config ACPI not necessarily include generation of tables (see GENERATE_ACPI_TABLE), but allows for tables to be located. +config SPL_ACPI + bool "Enable support for ACPI libraries in SPL" + depends on SPL && SUPPORT_ACPI + help + Provides library functions for dealing with ACPI tables in SPL. This + does not necessarily include generation of tables + (see GENERATE_ACPI_TABLE), but allows for tables to be located. + config GENERATE_ACPI_TABLE bool "Generate an ACPI (Advanced Configuration and Power Interface) table" depends on ACPI -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v4 04/20] x86: Set the CPU vendor in SPL
We don't read this information in 64-bit mode, since we don't have the
macros for doing it. Set it to Intel by default. This allows the TSC timer
to work correctly.
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/x86/cpu/x86_64/cpu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/cpu/x86_64/cpu.c b/arch/x86/cpu/x86_64/cpu.c
index d1c3873dd6a..2647bff891f 100644
--- a/arch/x86/cpu/x86_64/cpu.c
+++ b/arch/x86/cpu/x86_64/cpu.c
@@ -8,8 +8,11 @@
#include
#include
#include
+#include
#include
+DECLARE_GLOBAL_DATA_PTR;
+
int cpu_has_64bit(void)
{
return true;
@@ -38,6 +41,10 @@ int x86_mp_init(void)
int x86_cpu_reinit_f(void)
{
+ /* set the vendor to Intel so that native_calibrate_tsc() works */
+ gd->arch.x86_vendor = X86_VENDOR_INTEL;
+ gd->arch.has_mtrr = true;
+
return 0;
}
--
2.42.0.rc1.204.g551eb34607-goog
[PATCH v4 03/20] x86: coreboot: Rearrange arch_cpu_init()
Init errors in SPL are currently ignored by this function.
Change the code to init the CPU, reporting an error if something is wrong.
After that, look for the coreboot table.
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/x86/cpu/coreboot/coreboot.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/x86/cpu/coreboot/coreboot.c b/arch/x86/cpu/coreboot/coreboot.c
index 835b2c77746..c2ceaa9a56c 100644
--- a/arch/x86/cpu/coreboot/coreboot.c
+++ b/arch/x86/cpu/coreboot/coreboot.c
@@ -21,7 +21,14 @@
int arch_cpu_init(void)
{
- int ret = get_coreboot_info(_sysinfo);
+ int ret;
+
+ ret = IS_ENABLED(CONFIG_X86_RUN_64BIT) ? x86_cpu_reinit_f() :
+x86_cpu_init_f();
+ if (ret)
+ return ret;
+
+ ret = get_coreboot_info(_sysinfo);
if (ret != 0) {
printf("Failed to parse coreboot tables.\n");
return ret;
@@ -29,8 +36,7 @@ int arch_cpu_init(void)
timestamp_init();
- return IS_ENABLED(CONFIG_X86_RUN_64BIT) ? x86_cpu_reinit_f() :
-x86_cpu_init_f();
+ return 0;
}
int checkcpu(void)
--
2.42.0.rc1.204.g551eb34607-goog
[PATCH v4 02/20] x86: coreboot: Enable standard boot
Enable bootstd options and provide instructions on how to boot a linux distro using coreboot. Signed-off-by: Simon Glass --- (no changes since v1) configs/coreboot64_defconfig| 14 ++ configs/coreboot_defconfig | 1 + doc/board/coreboot/coreboot.rst | 16 ++-- 3 files changed, 17 insertions(+), 14 deletions(-) diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index a456547a25d..5623197f6be 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -10,39 +10,29 @@ CONFIG_VENDOR_COREBOOT=y CONFIG_TARGET_COREBOOT=y CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y +CONFIG_BOOTSTD_FULL=y +CONFIG_BOOTSTD_DEFAULTS=y CONFIG_SYS_MONITOR_BASE=0x0112 CONFIG_SHOW_BOOT_PROGRESS=y CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" -CONFIG_USE_BOOTCOMMAND=y -CONFIG_BOOTCOMMAND="ext2load scsi 0:3 0100 /boot/vmlinuz; zboot 0100" CONFIG_PRE_CONSOLE_BUFFER=y CONFIG_SYS_CONSOLE_INFO_QUIET=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_SPL_NO_BSS_LIMIT=y -CONFIG_HUSH_PARSER=y CONFIG_SYS_PBSIZE=532 CONFIG_CMD_IDE=y CONFIG_CMD_MMC=y -CONFIG_CMD_PART=y CONFIG_CMD_SATA=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set -CONFIG_CMD_DHCP=y CONFIG_BOOTP_BOOTFILESIZE=y -CONFIG_CMD_PING=y CONFIG_CMD_TIME=y CONFIG_CMD_SOUND=y -CONFIG_CMD_EXT2=y -CONFIG_CMD_EXT4=y CONFIG_CMD_EXT4_WRITE=y -CONFIG_CMD_FAT=y -CONFIG_CMD_FS_GENERIC=y CONFIG_MAC_PARTITION=y # CONFIG_SPL_MAC_PARTITION is not set # CONFIG_SPL_DOS_PARTITION is not set -CONFIG_ISO_PARTITION=y -CONFIG_EFI_PARTITION=y # CONFIG_SPL_EFI_PARTITION is not set CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index aedad4c93c3..311ca6672cb 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -10,6 +10,7 @@ CONFIG_TARGET_COREBOOT=y CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y CONFIG_BOOTSTD_FULL=y +CONFIG_BOOTSTD_DEFAULTS=y CONFIG_SYS_MONITOR_BASE=0x0111 CONFIG_SHOW_BOOT_PROGRESS=y CONFIG_USE_BOOTARGS=y diff --git a/doc/board/coreboot/coreboot.rst b/doc/board/coreboot/coreboot.rst index be5b0de5495..88437c27740 100644 --- a/doc/board/coreboot/coreboot.rst +++ b/doc/board/coreboot/coreboot.rst @@ -67,9 +67,21 @@ To use 4GB of memory, typically necessary for booting Linux distros, add In addition to the 32-bit 'coreboot' build there is a 'coreboot64' build. This produces an image which can be booted from coreboot (32-bit). Internally it works by using a 32-bit SPL binary to switch to 64-bit for running U-Boot. It -can be useful for running UEFI applications, for example. +can be useful for running UEFI applications, for example with the coreboot +build in `$CBDIR`:: + + DISK=ubuntu-23.04-desktop-amd64.iso + CBDIR=~/coreboot/build + + cp $CBDIR/coreboot.rom.in coreboot.rom + cbfstool coreboot.rom add-flat-binary -f u-boot-x86-with-spl.bin \ + -n fallback/payload -c LZMA -l 0x111 -e 0x111 + + qemu-system-x86_64 -m 2G -smp 4 -bios coreboot.rom \ + -drive id=disk,file=$DISK,if=none \ + -device ahci,id=ahci \ + -device ide-hd,drive=disk,bus=ahci.0 \ -This has only been lightly tested. CBFS access --- -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v4 01/20] x86: coreboot: Add IDE and SATA
Add these options to permit access to more disk types. Add some documentation as well. Signed-off-by: Simon Glass --- (no changes since v1) configs/coreboot64_defconfig| 1 + configs/coreboot_defconfig | 9 + doc/board/coreboot/coreboot.rst | 20 3 files changed, 30 insertions(+) diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index 2793e2c0b9d..a456547a25d 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -25,6 +25,7 @@ CONFIG_SYS_PBSIZE=532 CONFIG_CMD_IDE=y CONFIG_CMD_MMC=y CONFIG_CMD_PART=y +CONFIG_CMD_SATA=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index f196ed776d0..aedad4c93c3 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -21,8 +21,10 @@ CONFIG_LOGF_LINE=y CONFIG_LOGF_FUNC=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_PCI_INIT_R=y +CONFIG_CMD_IDE=y CONFIG_CMD_MMC=y CONFIG_CMD_PART=y +CONFIG_CMD_SATA=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y @@ -47,6 +49,13 @@ CONFIG_USE_ROOTPATH=y CONFIG_REGMAP=y CONFIG_SYSCON=y # CONFIG_ACPIGEN is not set +CONFIG_SYS_IDE_MAXDEVICE=4 +CONFIG_SYS_ATA_DATA_OFFSET=0 +CONFIG_SYS_ATA_REG_OFFSET=0 +CONFIG_SYS_ATA_ALT_OFFSET=0 +CONFIG_ATAPI=y +CONFIG_LBA48=y +CONFIG_SYS_64BIT_LBA=y CONFIG_NVME_PCI=y # CONFIG_PCI_PNP is not set CONFIG_SOUND=y diff --git a/doc/board/coreboot/coreboot.rst b/doc/board/coreboot/coreboot.rst index d660a223d9c..be5b0de5495 100644 --- a/doc/board/coreboot/coreboot.rst +++ b/doc/board/coreboot/coreboot.rst @@ -41,6 +41,26 @@ At present it seems that for Minnowboard Max, coreboot does not pass through the video information correctly (it always says the resolution is 0x0). This works correctly for link though. +You can run via QEMU using:: + + qemu-system-x86_64 -bios build/coreboot.rom -serial mon:stdio + +The `-serial mon:stdio` part shows both output in the display and on the +console. It is optional. You can add `nographic` as well to *only* get console +output. + +To run with a SATA drive called `$DISK`:: + + qemu-system-x86_64 -bios build/coreboot.rom -serial mon:stdio \ + -drive id=disk,file=$DISK,if=none \ + -device ahci,id=ahci \ + -device ide-hd,drive=disk,bus=ahci.0 + +Then you can scan it with `scsi scan` and access it normally. + +To use 4GB of memory, typically necessary for booting Linux distros, add +`-m 4GB`. + 64-bit U-Boot - -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v4 00/20] x86: efi: Fixes and improvements for coreboot
This little series fixes various bugs and annoyances in coreboot and
coreboot64.
With this both coreboot and coreboot64 start up and work reasonably well
on Brya (x86 Chromebook) and U-Boot can boot common Linux distros.
- Make coreboot64 debug UART start reliably
- Avoid the long USB-init delay on startup
- Correct the timer speed on coreboo64
- Fix a bootstd cros bug (will likely be squashed into another patch)
- Fix the terribly slow console scrolling
With v2 I have also brought in some lost x86 patches so they are all in
one series.
Changes in v4:
- Fix arm and riscv
- Rewrite this to use events instead
Changes in v3:
- Allow SMBIOS if EFI_LOADER is enabled
- Reword the help
- Use log_debug() to show the message
- Squash in the next patch
Changes in v2:
- Update the malloc size too
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
Simon Glass (20):
x86: coreboot: Add IDE and SATA
x86: coreboot: Enable standard boot
x86: coreboot: Rearrange arch_cpu_init()
x86: Set the CPU vendor in SPL
x86: Allow APCI in SPL
x86: coreboot: Look for DBG2 UART in SPL too
x86: coreboot: Enable CONFIG_SYS_NS16550_MEM32
x86: coreboot: Drop USB init on startup
x86: coreboot: Align options between coreboot and coreboot64
x86: coreboot: Enable VIDEO_COPY
efi: x86: Correct the condition for installing ACPI tables
x86: smbios: Add a Kconfig indicating SMBIOS-table presence
bootstd: Keep track of use of usb stop
Record the position of the SMBIOS tables
efi: Use the installed SMBIOS tables
x86: coreboot: Record the position of the SMBIOS tables
x86: doc: Move into its own directory
x86: doc: Update summaries and add links
x86: doc: Split out manual booting into its own file
x86: doc: coreboot: Mention 64-bit Linux distros
arch/arm/include/asm/global_data.h | 3 +
arch/riscv/include/asm/global_data.h| 3 +
arch/sandbox/include/asm/global_data.h | 1 +
arch/x86/cpu/coreboot/coreboot.c| 16 +-
arch/x86/cpu/x86_64/cpu.c | 7 +
arch/x86/dts/coreboot.dts | 1 +
arch/x86/include/asm/global_data.h | 1 +
arch/x86/lib/coreboot/cb_sysinfo.c | 1 +
arch/x86/lib/tables.c | 3 +
board/Marvell/mvebu_armada-37xx/board.c | 2 +
boot/bootdev-uclass.c | 27 +++
configs/coreboot64_defconfig| 25 +-
configs/coreboot_defconfig | 21 +-
doc/arch/index.rst | 2 +-
doc/arch/x86/index.rst | 12 +
doc/arch/x86/manual_boot.rst| 276 ++
doc/arch/{ => x86}/x86.rst | 295 ++--
doc/board/coreboot/coreboot.rst | 38 ++-
drivers/serial/Kconfig | 2 +-
drivers/usb/host/usb-uclass.c | 8 +
drivers/video/coreboot.c| 12 +
include/asm-generic/global_data.h | 8 +
include/bootdev.h | 9 +
lib/Kconfig | 24 +-
lib/efi_loader/Makefile | 4 +-
lib/efi_loader/efi_setup.c | 20 +-
lib/efi_loader/efi_smbios.c | 72 +++---
test/py/tests/test_event_dump.py| 1 +
28 files changed, 544 insertions(+), 350 deletions(-)
create mode 100644 doc/arch/x86/index.rst
create mode 100644 doc/arch/x86/manual_boot.rst
rename doc/arch/{ => x86}/x86.rst (64%)
--
2.42.0.rc1.204.g551eb34607-goog
Re: [PATCH v2] schemas: Add a schema for memory map
On Tue, Aug 22, 2023 at 3:34 PM Simon Glass wrote:
>
> Hi Rob,
>
> On Tue, 22 Aug 2023 at 12:53, Rob Herring wrote:
> >
> > On Mon, Aug 21, 2023 at 2:48 PM Simon Glass wrote:
> > >
> > > The Devicespec specification skips over handling of a logical view of
> > > the memory map, pointing users to the UEFI specification.
> >
> > It's more that the DT spec defines what is not used with UEFI. If UEFI
> > covers more than the DT Spec defined, then we should look at that.
> >
> > I would look some into (IBM) PowerPC for any prior art in this area.
> > Unfortunately, not publicly documented other than any users.
>
> OK, but I'm not sure what you are looking for here. The DT (as
> currently specified) is an incomplete description of memory, for
> EFI-type firmware.
I thought this was for non-EFI based systems. Confused.
> I recall the ePAPR thing, but not much else. Any
> pointers?
ePAPR is the source of DT Spec. That was mainly FSL PPC, not IBM PPC.
There's something called SPAPR, but no public spec. Otherwise, it's
looking at arch/powerpc in the kernel.
> > > It is common to split firmware into 'Platform Init', which does the
> > > initial hardware setup and a "Payload" which selects the OS to be booted.
> > > Thus an handover interface is required between these two pieces.
> > >
> > > Where UEFI boot-time services are not available, but UEFI firmware is
> > > present on either side of this interface, information about memory usage
> > > and attributes must be presented to the "Payload" in some form.
> > >
> > > This aims to provide an initial schema for this mapping.
> > >
> > > Note that this is separate from the existing /memory and /reserved-memory
> > > nodes, since it is mostly concerned with what the memory is used for. It
> > > may cover only a small fraction of available memory, although it could be
> > > used to signal which area of memory has ECC.
> > >
> > > For now, no attempt is made to create an exhaustive binding, so there are
> > > some example types lists. This can be completed once this has passed
> > > initial review.
> >
> > I don't have much interest in picking this up unless there's some
> > wider agreement. From the previously referenced discussion[1], it
> > didn't seem like there was. But none of those folk are Cc'ed here.
>
> Yes, Ron pointed me to that...although it isn't quite the same thing.
> That is implementing a way to pass SMBIOS and ACPI tables through to
> Linux, right? But it does mention memory types, so I'll send a new
> version with those people on cc, in case they don't look at linux-acpi
> much.
Both are defining regions of memory to pass from one stage to the
next. Isn't that the same thing?
> But note, this is for *firmware* (on both sides of the interface).
> Whether it is useful for Linux is another question. But in any case,
> we should avoid having things in the DT which Linux cannot validate /
> parse.
Perhaps it is easiest if firmware removes its private stuff. You can
put whatever you want into a DT and I don't care if it's not an ABI
between the components. You may still want to document things and have
a schema for other reasons.
> > > ---
> > >
> > > Changes in v2:
> > > - Reword commit message
> > >
> > > dtschema/schemas/memory-map.yaml | 51
> > > 1 file changed, 51 insertions(+)
> > > create mode 100644 dtschema/schemas/memory-map.yaml
> > >
> > > diff --git a/dtschema/schemas/memory-map.yaml
> > > b/dtschema/schemas/memory-map.yaml
> > > new file mode 100644
> > > index 000..97e531e
> > > --- /dev/null
> > > +++ b/dtschema/schemas/memory-map.yaml
> > > @@ -0,0 +1,51 @@
> > > +# SPDX-License-Identifier: BSD-2-Clause
> > > +# Copyright 2023 Google LLC
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/memory-map.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: /memory-map nodes
> > > +description: |
> > > + Common properties always required in /memory-map nodes. These nodes are
> > > + intended to resolve the nonchalant clause 3.4.1 ("/memory node and
> > > UEFI")
> > > + in the Devicetree Specification.
> > > +
> > > +maintainers:
> > > + - Simon Glass
> > > +
> > > +properties:
> > > + $nodename:
> > > +const: '/'
> >
> > This goes in the root node?
>
> I suppose I'm just confused about how the schema is described. I think
> it is better to have a /memory-map node with subnodes of that for each
> region.
What you need is $nodename should be "memory-map", not "/". There is
not a way to say it has to be under the root node other than adding it
to root-node.yaml.
> > > + usage:
> > > +$ref: /schemas/types.yaml#/definitions/string
> > > +description: |
> > > + Describes the usage of the memory region, e.g.:
> > > +
> > > +"acpi-reclaim", "acpi-nvs", "bootcode", "bootdata", "bootdata",
> > > +"runtime-code", "runtime-data"
> >
> > Can't these be covered by reserved-memory? The client is free to
> > reclaim
Re: [PATCH 1/1] doc: describe TPL/VPL/SPL boot
On Wednesday 23 August 2023 22:46:13 Marek Vasut wrote: > On 8/23/23 22:35, Pali Rohár wrote: > > On Wednesday 23 August 2023 22:32:18 Heinrich Schuchardt wrote: > > > Looking at the MAINTAINER file it seems that POWERPC should be set to > > > orphaned. > > > > And this is only just because of your fault folks here, as you have been > > completely ignoring any my patches for improving this situation here and > > finally after more than year of my reminders more of you wrote me > > officially that would ignore any changes from me. > > So go and complain to somebody else, not me. > > Why not pick up the PPC maintainership yourself ? You are qualified enough I > think. I'm not sure if you cannot read or understand above written text, but I will repeat it once again and the last time specially for you: I'm not going to send any changes, improvements or fixes to any people anymore who either implicitly or explicitly wrote that will ignore me or my contributions. > There is a whole thread on frustration about getting patches reviewed and > upstream here too: > > https://lore.kernel.org/all/20230816180808.GB2919664@perftesting/
Re: [PATCH 1/1] doc: describe TPL/VPL/SPL boot
On 8/23/23 22:35, Pali Rohár wrote: On Wednesday 23 August 2023 22:32:18 Heinrich Schuchardt wrote: Looking at the MAINTAINER file it seems that POWERPC should be set to orphaned. And this is only just because of your fault folks here, as you have been completely ignoring any my patches for improving this situation here and finally after more than year of my reminders more of you wrote me officially that would ignore any changes from me. So go and complain to somebody else, not me. Why not pick up the PPC maintainership yourself ? You are qualified enough I think. There is a whole thread on frustration about getting patches reviewed and upstream here too: https://lore.kernel.org/all/20230816180808.GB2919664@perftesting/
Re: [PATCH] usb: xhci: Define 'XHCI_MAX_HALT_USEC' macro only once
On 8/23/23 17:41, Bhupesh Sharma wrote: Right now xhci header file defines XHCI_MAX_HALT_USEC macro twice. Fix the same. Cc: Bin Meng This Cc: ^ stufff Signed-off-by: Bhupesh Sharma --- Should go here , below the --- and then add another --- and the diffstat, i.e. this: Commit Message Blah blah Blah Signed-of-by:... --- Cc: Foo User Cc: Another User ... --- Changelog/Diffstat/patch include/usb/xhci.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/usb/xhci.h b/include/usb/xhci.h index 4a4ac10229..958c94bfa7 100644 --- a/include/usb/xhci.h +++ b/include/usb/xhci.h @@ -1136,8 +1136,6 @@ void xhci_hcd_stop(int index); /* EXTENDED CAPABILITY DEFINITIONS */ -/* Up to 16 ms to halt an HC */ -#define XHCI_MAX_HALT_USEC (16*1000) /* HC not running - set to 1 when run/stop bit is cleared. */ #define XHCI_STS_HALT (1 << 0) Reviewed-by: Marek Vasut The patch is obviously correct, fix up the CC list and send a V2 please. btw if you include the --- in commit message, git will retain the Cc: list below --- too.
Re: [PATCH v1 2/2] doc: board: starfive: Add more info about supported driver
On Tue, 2023-08-22 at 22:33, Shengyu Qu wrote: > Since PLDA PCIE driver is added and VL805 support is enabled in > defconfig for Starfive Visionfive 2, modify the document to keep > consistent. > > Signed-off-by: Shengyu Qu Tested-by: Milan P. Stanić > --- > doc/board/starfive/visionfive2.rst | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/doc/board/starfive/visionfive2.rst > b/doc/board/starfive/visionfive2.rst > index 941899a0a4..460f23aec3 100644 > --- a/doc/board/starfive/visionfive2.rst > +++ b/doc/board/starfive/visionfive2.rst > @@ -20,6 +20,8 @@ The support for following drivers are already enabled: > 3. StarFive JH7110 reset Driver. > 4. Cadence QSPI controller Driver. > 5. MMC SPI Driver for MMC/SD support. > +6. PLDA PCIE controller driver. > +7. On-board VL805 PCIE-USB controller driver. > > Booting from MMC using U-Boot SPL > - > -- > 2.42.0 >
Re: [PATCH v1 1/2] configs: starfive: Enable PCIE auto enum and NVME/USB stuff for Starfive Visionfive 2
On Tue, 2023-08-22 at 22:33, Shengyu Qu wrote:
> Although PCIE driver already exists, board defconfig isn't configured to
> enable PCIE enum on boot, thus USB storage device and NVME drive are not
> supported by default. So modify defconfig to enable PCIE auto enum, then
> start USB subsystem and scan nvme drive on boot.
>
> Signed-off-by: Shengyu Qu
Tested-by: Milan P. Stanić
> ---
> configs/starfive_visionfive2_defconfig | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/configs/starfive_visionfive2_defconfig
> b/configs/starfive_visionfive2_defconfig
> index e9b63e5b84..3002c96f0e 100644
> --- a/configs/starfive_visionfive2_defconfig
> +++ b/configs/starfive_visionfive2_defconfig
> @@ -30,6 +30,7 @@ CONFIG_SPL_SPI=y
> CONFIG_SYS_LOAD_ADDR=0x8200
> CONFIG_SYS_PCI_64BIT=y
> CONFIG_PCI=y
> +CONFIG_PCI_INIT_R=y
> CONFIG_TARGET_STARFIVE_VISIONFIVE2=y
> CONFIG_SPL_OPENSBI_LOAD_ADDR=0x4000
> CONFIG_ARCH_RV64I=y
> @@ -43,7 +44,7 @@ CONFIG_SD_BOOT=y
> CONFIG_USE_BOOTARGS=y
> CONFIG_BOOTARGS="console=ttyS0,115200 debug rootwait earlycon=sbi"
> CONFIG_USE_PREBOOT=y
> -CONFIG_PREBOOT="setenv fdt_addr ${fdtcontroladdr};fdt addr
> ${fdtcontroladdr};"
> +CONFIG_PREBOOT="nvme scan; usb start; setenv fdt_addr ${fdtcontroladdr}; fdt
> addr ${fdtcontroladdr};"
> CONFIG_DEFAULT_FDT_FILE="starfive/jh7110-starfive-visionfive-2.dtb"
> CONFIG_DISPLAY_CPUINFO=y
> CONFIG_DISPLAY_BOARDINFO=y
> @@ -124,4 +125,9 @@ CONFIG_TIMER_EARLY=y
> CONFIG_USB=y
> CONFIG_USB_XHCI_HCD=y
> CONFIG_USB_XHCI_PCI=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_EHCI_PCI=y
> +CONFIG_USB_OHCI_HCD=y
> +CONFIG_USB_OHCI_PCI=y
> +CONFIG_USB_STORAGE=y
> CONFIG_USB_KEYBOARD=y
> --
> 2.42.0
>
Re: [PATCH 1/1] doc: describe TPL/VPL/SPL boot
On Wednesday 23 August 2023 22:32:18 Heinrich Schuchardt wrote: > Looking at the MAINTAINER file it seems that POWERPC should be set to > orphaned. And this is only just because of your fault folks here, as you have been completely ignoring any my patches for improving this situation here and finally after more than year of my reminders more of you wrote me officially that would ignore any changes from me. So go and complain to somebody else, not me.
Re: [PATCH 1/1] doc: describe TPL/VPL/SPL boot
On 8/23/23 22:14, Pali Rohár wrote: On Wednesday 23 August 2023 21:57:28 Heinrich Schuchardt wrote: +Booting from TPL/SPL + + +The main U-Boot binary may be to large to be loaded directly by the Boot ROM. +This was the main driver for splitting up U-Boot into multiple boot stages with +successively larger binaries. + +U-Boot typically goes through the following boot phases where TPL, VPL, and SPL +are optional. While many boards use SPL only few use TPL. + +TPL + Very early init, as tiny as possible. This loads SPL (or VPL if enabled). This is not truth. SPL loads TPL. Or at least it was about year ago for powerpc plat. Thanks for reviewing. Cf. doc/arch/sandbox/sandbox.rst For roc-cc-rk3328_defconfig TPL is much smaller than SPL: 78224 spl/u-boot-spl-nodtb.bin 20744 tpl/u-boot-tpl-nodtb.bin For P2020RDB-PC_NAND_defconfig SPL is much smaller than TPL: 63624 tpl/u-boot-tpl-nodtb.bin 4096 spl/u-boot-spl-nodtb.bin If some boards are running TPL->SPL and others SPL->TPL, we really have a naming convention issue. We cannot expect any user to understand such a confusion. Looking at the MAINTAINER file it seems that POWERPC should be set to orphaned. Best regards Heinrich +VPL + Optional verification step, which can select one of several SPL binaries, + if A/B verified boot is enabled. Implementation of the VPL logic is + work-in-progress. For now it just boots into SPL. + +SPL + Secondary program loader. Sets up SDRAM and loads U-Boot proper. It may also + load other firmware components. SPL initializes NAND then loads TPL from NAND, TPL initialize DDR and then loads U-Boot.
Re: [PATCH 1/1] doc: describe TPL/VPL/SPL boot
On 8/23/23 22:14, Pali Rohár wrote: On Wednesday 23 August 2023 21:57:28 Heinrich Schuchardt wrote: +Booting from TPL/SPL + + +The main U-Boot binary may be to large to be loaded directly by the Boot ROM. +This was the main driver for splitting up U-Boot into multiple boot stages with +successively larger binaries. + +U-Boot typically goes through the following boot phases where TPL, VPL, and SPL +are optional. While many boards use SPL only few use TPL. + +TPL + Very early init, as tiny as possible. This loads SPL (or VPL if enabled). This is not truth. SPL loads TPL. Or at least it was about year ago for powerpc plat. It goes both ways. - It can be either TPL as the Tiny Program Loader, usually hand-rolled in assembly, used e.g. on OneNAND devices to fit into the OneNAND memory mapped window and used to load the next stage (SPL) from that OneNAND memory into SoC SRAM, and then jump to that next stage. - It can be SPL that loads TPL as Tertiary Program Loader , apparently on PPC. +VPL + Optional verification step, which can select one of several SPL binaries, + if A/B verified boot is enabled. Implementation of the VPL logic is + work-in-progress. For now it just boots into SPL. + +SPL + Secondary program loader. Sets up SDRAM and loads U-Boot proper. It may also + load other firmware components. SPL initializes NAND then loads TPL from NAND, TPL initialize DDR and then loads U-Boot. Nope.
Re: [PATCH 1/1] doc: describe TPL/VPL/SPL boot
On Wed, Aug 23, 2023 at 09:57:28PM +0200, Heinrich Schuchardt wrote: > This is a stub describing how TPL, VPL, and SPL load the next boot stages > on a detail level for users. > > For sure we will need a few patches on top to catch the whole complexity. > > Signed-off-by: Heinrich Schuchardt [snip] > +Image load methods > +-- > + > +The image boot methods available for a board must be defined in two places: > + > +The board code implements a function board_boot_order() enumerating up to > +six boot methods and the sequence in which they are tried. If there is only > one > +boot method function, spl_boot_device() may be implemented instead. > + > +The configuration controls which of these boot methods are actually > available. Maybe some words about how some of these methods are SoC / SoC family specific while others are more high level and so more generally available. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] doc: describe TPL/VPL/SPL boot
On Wed, Aug 23, 2023 at 10:14:00PM +0200, Pali Rohár wrote: > On Wednesday 23 August 2023 21:57:28 Heinrich Schuchardt wrote: > > +Booting from TPL/SPL > > + > > + > > +The main U-Boot binary may be to large to be loaded directly by the Boot > > ROM. > > +This was the main driver for splitting up U-Boot into multiple boot stages > > with > > +successively larger binaries. > > + > > +U-Boot typically goes through the following boot phases where TPL, VPL, > > and SPL > > +are optional. While many boards use SPL only few use TPL. > > + > > +TPL > > + Very early init, as tiny as possible. This loads SPL (or VPL if > > enabled). > > This is not truth. SPL loads TPL. Or at least it was about year ago for > powerpc plat. > > > +VPL > > + Optional verification step, which can select one of several SPL > > binaries, > > + if A/B verified boot is enabled. Implementation of the VPL logic is > > + work-in-progress. For now it just boots into SPL. > > + > > +SPL > > + Secondary program loader. Sets up SDRAM and loads U-Boot proper. It may > > also > > + load other firmware components. > > SPL initializes NAND then loads TPL from NAND, TPL initialize DDR and then > loads U-Boot. One of the long standing issues here is that PowerPC is different from everyone else, in terms of terminology here. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] doc: describe TPL/VPL/SPL boot
On 8/23/23 21:57, Heinrich Schuchardt wrote: This is a stub describing how TPL, VPL, and SPL load the next boot stages on a detail level for users. For sure we will need a few patches on top to catch the whole complexity. Signed-off-by: Heinrich Schuchardt --- doc/usage/index.rst| 1 + doc/usage/spl_boot.rst | 309 + 2 files changed, 310 insertions(+) create mode 100644 doc/usage/spl_boot.rst diff --git a/doc/usage/index.rst b/doc/usage/index.rst index 072db53614..7f0b26cc5a 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -4,6 +4,7 @@ Use U-Boot .. toctree:: :maxdepth: 1 + spl_boot blkmap dfu environment diff --git a/doc/usage/spl_boot.rst b/doc/usage/spl_boot.rst new file mode 100644 index 00..05a3bf390d --- /dev/null +++ b/doc/usage/spl_boot.rst @@ -0,0 +1,309 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Booting from TPL/SPL + + +The main U-Boot binary may be to too large to be loaded directly by the Boot ROM. +This was the main driver for splitting up U-Boot into multiple boot stages with +successively larger binaries. Maybe not binaries, but something like "code working set" or so, since e.g. ATF BL31 may be smaller than SPL, but it is still loaded and started by SPL as PSCI provided e.g. on NXP MX8M. +U-Boot typically goes through the following boot phases where TPL, VPL, and SPL +are optional. While many boards use SPL only few use TPL. + +TPL + Very early init, as tiny as possible. This loads SPL (or VPL if enabled). Tiny Program Loader ? +VPL + Optional verification step, which can select one of several SPL binaries, + if A/B verified boot is enabled. Implementation of the VPL logic is + work-in-progress. For now it just boots into SPL. + +SPL + Secondary program loader. Sets up SDRAM and loads U-Boot proper. It may also + load other firmware components. + +U-Boot + U-Boot proper, containing the command line and boot logic. boot logic can also be in SPL btw +Only main U-Boot has a command line interface. + +Further usages for U-Boot SPL comprise: + +* Launching BL31 of ARM Trusted Firmware which invokes U-Boot as BL33 +* launching EDK II +* launching Linux +* launching RISC-V OpenSBI which invokes main U-Boot Launching in caps or lowercase , consistency please. +Target binaries +--- + +Binaries loaded by SPL/TPL can be: + +* raw binaries where the entry address equals the start address. This is the + only binary format supported by TPL. +* :doc:`FIT ` images +* legacy U-Boot images fitImages too . Also mention authentication of next stage. +Configuration +~ + +Raw images are only supported in SPL if CONFIG_SPL_RAW_IMAGE_SUPPORT=y. Shouldn't raw (non-fitImage) images be discouraged , as there is no protection from bitrot in those ? +CONFIG_SPL_FIT=y and CONFIG_SPL_LOAD_FIT=y are needed to load FIT images. + +CONFIG_SPL_LEGACY_IMAGE_FORMAT=y is needed to load legacy U-Boot images. +CONFIG_SPL_LEGACY_IMAGE_CRC_CHECK=y enables checking the CRC32 of legacy U-Boot +images. + +Image load methods +-- + +The image boot methods available for a board must be defined in two places: + +The board code implements a function board_boot_order() enumerating up to +six boot methods Why six ? I have an idea why, but this should be documented. and the sequence in which they are tried. If there is only one +boot method function, spl_boot_device() may be implemented instead. + +The configuration controls which of these boot methods are actually available. + +BOOTROM +The binary is loaded by the boot ROM. +Required configuration settings include: + +* CONFIG_SPL_BOOTROM_SUPPORT=y or CONFIG_TPL_BOOTROM_SUPPORT=y + +DFU +:doc:`Device Firmware Upgrade ` is used to load the binary into RAM. +Required configuration settings include: + +* CONFIG_DFU=y + +* CONFIG_SPL_RAM_SUPPORT=y or CONFIG TPL_RAM_SUPPORT=y + +Ethernet (CPGMAC) Wat's CPGMAC ? +This method loads an image over Ethernet. The BOOTP protocol is used to find +a TFTP server and binary name. The binary is downloaded via the TFTP +protocol. Required configuration settings include: + +* CONFIG_SPL_NET=y or CONFIG_TPL_NET=y + +* CONFIG_SPL_ETH_DEVICE + +FEL +This method does not actually load an image for U-Boot. +FEL is a routine contained in the boot ROM of Allwinner SoCs which serves +for the initial programming or recovery via USB + +MMC1, MMC2, MMC2_2 +These methods read an image from SD card or eMMC. The first digit after +'MMC' indicates the device number. Required configuration settings include: + +* CONFIG_SPL_MMC=y or CONFIG_TPL_MMC=y + +To use a PCI connected MMC controller you need to additionally specify: + +* CONFIG_SPL_PCI=y + +* CONFIG_SPL_PCI_PNP=y + +* CONFIG_MMC=y Why CONFIG_MMC for PCI connected SDMMC controller in SPL ? +*
Re: [PATCH 7/8] spl: x86: Avoid starting up PCI automatically in SPL
On 8/23/23 20:47, Simon Glass wrote:
For x86 platforms, PCI is core to their operation and is managed in
arch-specific code. Each platform has its own way of doing this. For TPL
and some SPL implementations, the full driver model PCI is not used.
A recent change enabled full PCI in TPL/SPL for all boards. This breaks
some x86 boards, so adjust it to skip that for x86.
Could you, please, give some more detail?
* Which boards are broken?
* Don't these boards have a pci_init() function?
* In what way does calling pci_init() lead to a failure?
It would be preferable to have all architectures and boards use the same
high level API. Excluding x86 here looks more like a (necessary) hack
than like a target state.
Best regards
Heinrich
Signed-off-by: Simon Glass
---
common/spl/spl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 0062f3f45d9..13d7b1a742f 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -800,7 +800,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
IS_ENABLED(CONFIG_SPL_ATF))
dram_init_banksize();
- if (CONFIG_IS_ENABLED(PCI)) {
+ if (CONFIG_IS_ENABLED(PCI) && !IS_ENABLED(CONFIG_X86)) {
ret = pci_init();
if (ret)
puts(SPL_TPL_PROMPT "Cannot initialize PCI\n");
Re: [PATCH 1/1] doc: describe TPL/VPL/SPL boot
On Wednesday 23 August 2023 21:57:28 Heinrich Schuchardt wrote: > +Booting from TPL/SPL > + > + > +The main U-Boot binary may be to large to be loaded directly by the Boot ROM. > +This was the main driver for splitting up U-Boot into multiple boot stages > with > +successively larger binaries. > + > +U-Boot typically goes through the following boot phases where TPL, VPL, and > SPL > +are optional. While many boards use SPL only few use TPL. > + > +TPL > + Very early init, as tiny as possible. This loads SPL (or VPL if enabled). This is not truth. SPL loads TPL. Or at least it was about year ago for powerpc plat. > +VPL > + Optional verification step, which can select one of several SPL binaries, > + if A/B verified boot is enabled. Implementation of the VPL logic is > + work-in-progress. For now it just boots into SPL. > + > +SPL > + Secondary program loader. Sets up SDRAM and loads U-Boot proper. It may > also > + load other firmware components. SPL initializes NAND then loads TPL from NAND, TPL initialize DDR and then loads U-Boot.
Re: [PATCH v3 1/2] schemas: Add a schema for memory map
Hi, On Wed, 23 Aug 2023 at 08:24, Ard Biesheuvel wrote: > > On Wed, 23 Aug 2023 at 10:59, Mark Rutland wrote: > > > > On Tue, Aug 22, 2023 at 02:34:42PM -0600, Simon Glass wrote: > > > The Devicetree specification skips over handling of a logical view of > > > the memory map, pointing users to the UEFI specification. > > > > > > It is common to split firmware into 'Platform Init', which does the > > > initial hardware setup and a "Payload" which selects the OS to be booted. > > > Thus an handover interface is required between these two pieces. > > > > > > Where UEFI boot-time services are not available, but UEFI firmware is > > > present on either side of this interface, information about memory usage > > > and attributes must be presented to the "Payload" in some form. > > Not quite. > > This seems to be intended for consumption by Linux booting in ACPI > mode, but not via UEFI, right? Actually, this is for consumption by firmware. The goal is to allow edk2 to boot into U-Boot and vice versa, i.e. provide some interoperability between firmware projects. I will use the "Platform Init" and "Payload" terminology here too. > Some proposed changes to support that > were rejected on the basis that ACPI on non-x86 is strictly tied to > ACPI boot, not only because the ACPI root table (rsdp) can only be > discovered via UEFI, but also because the ACPI subsystem in Linux > cross-references any memory mappings created from AML code against the > UEFI memory map. > > Unfortunately, having a vague, non-exhaustive approximation of the > UEFI memory map is unlikely to be sufficient here. The existing logic > assumes that addresses not covered by the UEFI memory map are MMIO, > which means that either a) the UEFI memory map needs to describe all > RAM exhaustively or b) the existing logic needs to be modified to take > memblock or other information sources into account as well in order to > reason about whether a certain address requires device or normal > memory attributes. > > Note that the ACPI spec only lists EFI as a valid way to obtain the > root table pointer on architectures other than x86. If other ways are > needed, they should be contributed to the spec, rather than being > added to Linux as an ad hoc workaround for bootloaders that have > trouble implementing the spec as is. There is no intent to implement the UEFI spec, here. It is simply that some payloads (EDK2) are used to having this information. Imagine splitting EDK2 into two parts, one of which does platform init and the other which (the payload) boots the OS. The payload wants information from Platform Init and it needs to be in a devicetree, since that is what we have chosen for this interface. So to some extent this is unrelated to whether you have EFI boot services. We just need to be able to pass the information across the interface. Note that the user can (without recompilation, etc.) replace the second part with U-Boot (for example) and it must still work. > > > > > Today Linux does that by passing: > > > > /chosen/linux,uefi-mmap-start > > /chosen/linux,uefi-mmap-size > > /chosen/linux,uefi-mmap-desc-size > > /chosen/linux,uefi-mmap-desc-ver > > > > ... or /chosen/xen,* variants of those. > > > > Can't we document / genericise that? That seems to me to be the fields from the EFI memory-map call, but where is the actual content? I looked in the kernel but it seems to be an internal interface (between the stub and the kernel)? > > > > Given the ACPI angle, promoting this to external ABI would introduce a > DT dependency to ACPI boot. So we'll at least have to be very clear > about which takes precedence, or maybe disregard everything except the > /chosen node when doing ACPI boot? > > This also argues for not creating an ordinary binding for this (i.e., > describing it as part of the platform topology), but putting it under > /chosen as a Linux-only boot tweak. > > > Pointing to that rather than re-encoding it in DT means that it stays > > in-sync > > with the EFI spec and we won't back ourselves into a corner where we cannot > > encode something due to a structural difference. I don't think it's a good > > idea > > to try to re-encode it, or we're just setting ourselves up for futher pain. > > > > What I would prefer is to formalize pseudo-EFI boot and define the > bare required minimum (system table + memory map + config tables) in > an arch-agnostic manner. That way, the only thing that needs to be > passed via DT/boot_params/etc is the (pseudo-)EFI system table > address, and everything else (SMBIOS, ACPI as well as the EFI memory > map and even the initrd) can be passed via config tables as usual, all > of which is already supported in (mostly) generic kernel code. > > This means that booting via the EFI stub would not be required, nor is > implementing boot services or runtime services or any of the other > things that people appear to hate with such a passion. > > I'd actually prefer not to use those /chosen DT nodes,
Re: [PATCH] arm: dts: j7200: dtb sync with Linux 6.5-rc1
On 16:36-20230822, Nishanth Menon wrote:
> On 13:57-20230822, Reid Tonking wrote:
> > Sync j7200 device tree files with Linux 6.5-rc1
>
> I understand this is a major step forward, but a still:
>
> There is more work to do:
> a) split the dev-data.c fixup as the first patch
> b) See comments in
> https://lore.kernel.org/u-boot/20230816114445.c4c7rgdp5arhmiaq@polyester/
>
> [...]
>
> > diff --git a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> > b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> > index f25c7136c9..a00e85e366 100644
> > --- a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> > +++ b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> > @@ -1,6 +1,6 @@
> > // SPDX-License-Identifier: GPL-2.0
> > /*
> > - * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/
> > + * Copyright (C) 2020-2023 Texas Instruments Incorporated -
> > https://www.ti.com/
> > */
> >
> > #include "k3-j7200-binman.dtsi"
> > @@ -8,7 +8,7 @@
> > / {
> > chosen {
> > stdout-path = "serial2:115200n8";
>
> Drop this
>
> > - tick-timer =
> > + tick-timer = _timer0;
> > };
> >
> > aliases {
>
> You dont need the aliases - these come in from board.dts
>
> > @@ -28,16 +28,12 @@
> > bootph-pre-ram;
> > };
> >
> > -_mcu_wakeup {
> > +_esm{
>
> space before the {
>
> > bootph-pre-ram;
> > +};
> >
> > - timer1: timer@4040 {
> > - compatible = "ti,omap5430-timer";
> > - reg = <0x0 0x4040 0x0 0x80>;
> > - ti,timer-alwon;
> > - clock-frequency = <25000>;
> > - bootph-pre-ram;
> > - };
> > +_mcu_wakeup {
> > + bootph-pre-ram;
> >
> > chipid@4314 {
> > bootph-pre-ram;
>
> };
> End it here.
>
all the above, done
> > @@ -45,8 +41,6 @@
> >
> > mcu_navss: bus@2838 {
>
> Dont duplicate the entire node.
> _navss {
> bootph-pre-ram;
> };
>
> _ringacc {
> bootph-pre-ram;
> };
> NOTE: you only need to override reg-names and reg in R5.dtsi not u-boot.dtsi.
>
> _udmap {
> bootph-pre-ram;
> };
I saw you mentioned at [0] that mcu_ringacc (and I assume mcu_udmap)
need to be retained for now. If moved to r5.dts, something breaks, as dhcp
fails then [1]. Should the full nodes remain for now until 6.6-rc1 sync? I'll
still take them outside of mcu_navss.
[0] https://lore.kernel.org/all/20230816114445.c4c7rgdp5arhmiaq@polyester/
[1] https://gist.github.com/Glockn/f0cf1ae8f8fd92e70f4e798c6221e81a
> > bootph-pre-ram;
> > - #address-cells = <2>;
> > - #size-cells = <2>;
> >
> > ringacc@2b80 {
> > reg = <0x0 0x2b80 0x0 0x40>,
> And clean this up.
> >
> > _i2c0 {
> > bootph-pre-ram;
> > +
> > + lp876441: lp876441@4c {
>
> NAK. Why is this new stuff coming in -> should'nt be here.
>
This was left because _vtm0 uses _reg below which isn't apart
of the kernel dt files.
> > + bootph-pre-ram;
> > +
> > + regulators: regulators {
> > + bootph-pre-ram;
> > +
> > + buck1_reg: buck1 {
> > + bootph-pre-ram;
> > + };
> > + };
> > + };
> > };
> >
> > _i2c0 {
> > bootph-pre-ram;
> > +
> > + exp1: gpio@20 {
>
> Again - just do it using the reference
> {
> bootph-pre-ram;
> };
>
> And this pattern repeats itself..
>
> > + bootph-pre-ram;
> > + };
> > +
> > + exp2: gpio@22 {
>
> This as well.
>
will do
>
> hbmc -> arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi: flash@0,0 weird
> that does'nt throw a dtbs_check warning
>
> WARNING: u-boot,mux-autoprobe -> this is'nt supported.
>
change these to bootph-pre-ram?
> Also _r5fss0 -> ti,cluster-mode=<0> -> Drop that.
>
> There is a bit debate about dr_mode = "peripheral";
> https://lore.kernel.org/u-boot/fc205109-fd3d-ea79-abcc-f1638115d...@kernel.org/#r
>
> Depending on where it ends up...
>
I'll keep an eye on this
> [...]
>
> > diff --git a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> > b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> > index e62f9218e8..bd4be7215f 100644
> > --- a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> > +++ b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
>
> [...]
>
> > +_timer0 {
> > + /delete-property/ power-domains;
> > + ti,timer-alwon;
> > + clock-frequency = <2500>;
> > + bootph-pre-ram;
>
> you already caught this - just pre-ram and clock-frequency.
>
> > };
> >
> > _mcu_wakeup {
> > - mcu_secproxy: secproxy@2a38 {
> > + secure_proxy_mcu: mailbox@2a48 {
>
> Move this out.
>
done
> > bootph-pre-ram;
> > - compatible = "ti,am654-secure-proxy";
> > - reg = <0x0 0x2a38 0x0 0x8>,
> > - <0x0 0x2a40 0x0 0x8>,
> > - <0x0 0x2a48 0x0 0x8>;
> > - reg-names = "rt",
[PATCH 1/1] doc: describe TPL/VPL/SPL boot
This is a stub describing how TPL, VPL, and SPL load the next boot stages on a detail level for users. For sure we will need a few patches on top to catch the whole complexity. Signed-off-by: Heinrich Schuchardt --- doc/usage/index.rst| 1 + doc/usage/spl_boot.rst | 309 + 2 files changed, 310 insertions(+) create mode 100644 doc/usage/spl_boot.rst diff --git a/doc/usage/index.rst b/doc/usage/index.rst index 072db53614..7f0b26cc5a 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -4,6 +4,7 @@ Use U-Boot .. toctree:: :maxdepth: 1 + spl_boot blkmap dfu environment diff --git a/doc/usage/spl_boot.rst b/doc/usage/spl_boot.rst new file mode 100644 index 00..05a3bf390d --- /dev/null +++ b/doc/usage/spl_boot.rst @@ -0,0 +1,309 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Booting from TPL/SPL + + +The main U-Boot binary may be to large to be loaded directly by the Boot ROM. +This was the main driver for splitting up U-Boot into multiple boot stages with +successively larger binaries. + +U-Boot typically goes through the following boot phases where TPL, VPL, and SPL +are optional. While many boards use SPL only few use TPL. + +TPL + Very early init, as tiny as possible. This loads SPL (or VPL if enabled). + +VPL + Optional verification step, which can select one of several SPL binaries, + if A/B verified boot is enabled. Implementation of the VPL logic is + work-in-progress. For now it just boots into SPL. + +SPL + Secondary program loader. Sets up SDRAM and loads U-Boot proper. It may also + load other firmware components. + +U-Boot + U-Boot proper, containing the command line and boot logic. + +Only main U-Boot has a command line interface. + +Further usages for U-Boot SPL comprise: + +* Launching BL31 of ARM Trusted Firmware which invokes U-Boot as BL33 +* launching EDK II +* launching Linux +* launching RISC-V OpenSBI which invokes main U-Boot + +Target binaries +--- + +Binaries loaded by SPL/TPL can be: + +* raw binaries where the entry address equals the start address. This is the + only binary format supported by TPL. +* :doc:`FIT ` images +* legacy U-Boot images + +Configuration +~ + +Raw images are only supported in SPL if CONFIG_SPL_RAW_IMAGE_SUPPORT=y. + +CONFIG_SPL_FIT=y and CONFIG_SPL_LOAD_FIT=y are needed to load FIT images. + +CONFIG_SPL_LEGACY_IMAGE_FORMAT=y is needed to load legacy U-Boot images. +CONFIG_SPL_LEGACY_IMAGE_CRC_CHECK=y enables checking the CRC32 of legacy U-Boot +images. + +Image load methods +-- + +The image boot methods available for a board must be defined in two places: + +The board code implements a function board_boot_order() enumerating up to +six boot methods and the sequence in which they are tried. If there is only one +boot method function, spl_boot_device() may be implemented instead. + +The configuration controls which of these boot methods are actually available. + +BOOTROM +The binary is loaded by the boot ROM. +Required configuration settings include: + +* CONFIG_SPL_BOOTROM_SUPPORT=y or CONFIG_TPL_BOOTROM_SUPPORT=y + +DFU +:doc:`Device Firmware Upgrade ` is used to load the binary into RAM. +Required configuration settings include: + +* CONFIG_DFU=y + +* CONFIG_SPL_RAM_SUPPORT=y or CONFIG TPL_RAM_SUPPORT=y + +Ethernet (CPGMAC) +This method loads an image over Ethernet. The BOOTP protocol is used to find +a TFTP server and binary name. The binary is downloaded via the TFTP +protocol. Required configuration settings include: + +* CONFIG_SPL_NET=y or CONFIG_TPL_NET=y + +* CONFIG_SPL_ETH_DEVICE + +FEL +This method does not actually load an image for U-Boot. +FEL is a routine contained in the boot ROM of Allwinner SoCs which serves +for the initial programming or recovery via USB + +MMC1, MMC2, MMC2_2 +These methods read an image from SD card or eMMC. The first digit after +'MMC' indicates the device number. Required configuration settings include: + +* CONFIG_SPL_MMC=y or CONFIG_TPL_MMC=y + +To use a PCI connected MMC controller you need to additionally specify: + +* CONFIG_SPL_PCI=y + +* CONFIG_SPL_PCI_PNP=y + +* CONFIG_MMC=y + +* CONFIG_MMC_PCI=y + +* CONFIG_MMC_SDHCI=y + +To load from a file system use: + +* CONFIG_SPL_FS_FAT=y or CONFIG_SPL_FS_EXT=y + +* CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="" + +NAND +This method loads the image from NAND flash. To read from raw NAND the +following configuraton settings are required: + +* CONFIG_SPL_NAND_SUPPORT=y or CONFIG_TPL_NAND_SUPPORT=y + +If CONFIG_SPL_NAND_RAW_ONLY=y only raw images can be loaded. + +For using the Ubi file system to read from NAND the following configuration +settings are required: + +* CONFIG_SPL_UBI=y of CONFIG_TPL_UBI=y + +NOR +This method loads the image from NOR flash. +Required configuration
[PATCH] test: print: Fix hexdump test on 64bit systems
Use the following regex to make this test compatible with
both 32bit and 64bit systems. The trick is to use %0*lx
format string for the address prefix in the test.
"
s@\(ut_assert_nextline("\)0\+\([^:]\+\)\(:.*"\)\();\)@\1%0*lx\3,
IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x\2UL\4
"
Signed-off-by: Marek Vasut
---
Cc: Mario Six
Cc: Simon Glass
---
test/print_ut.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/test/print_ut.c b/test/print_ut.c
index 47a6ce57840..0a994a05cf6 100644
--- a/test/print_ut.c
+++ b/test/print_ut.c
@@ -283,16 +283,16 @@ static int print_do_hex_dump(struct unit_test_state *uts)
/* bytes */
console_record_reset();
print_hex_dump_bytes("", DUMP_PREFIX_ADDRESS, buf, 0x12);
- ut_assert_nextline(": 00 11 22 33 44 55 66 77 88 99 aa bb cc dd
ee ff ..\"3DUfw");
- ut_assert_nextline("0010: 10 00
..");
+ ut_assert_nextline("%0*lx: 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee
ff ..\"3DUfw", IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x0UL);
+ ut_assert_nextline("%0*lx: 10 00
..", IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x10UL);
ut_assert_console_end();
/* line length */
console_record_reset();
print_hex_dump("", DUMP_PREFIX_ADDRESS, 8, 1, buf, 0x12, true);
- ut_assert_nextline(": 00 11 22 33 44 55 66 77 ..\"3DUfw");
- ut_assert_nextline("0008: 88 99 aa bb cc dd ee ff ");
- ut_assert_nextline("0010: 10 00..");
+ ut_assert_nextline("%0*lx: 00 11 22 33 44 55 66 77 ..\"3DUfw",
IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x0UL);
+ ut_assert_nextline("%0*lx: 88 99 aa bb cc dd ee ff ",
IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x8UL);
+ ut_assert_nextline("%0*lx: 10 00..",
IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x10UL);
ut_assert_console_end();
unmap_sysmem(buf);
@@ -300,31 +300,31 @@ static int print_do_hex_dump(struct unit_test_state *uts)
console_record_reset();
buf[0x41] = 0x41;
print_hex_dump("", DUMP_PREFIX_ADDRESS, 0x40, 1, buf, 0x42, true);
- ut_assert_nextline(": 00 11 22 33 44 55 66 77 88 99 aa bb cc dd
ee ff 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
..\"3DUfw");
- ut_assert_nextline("0040: 00 41
.A");
+ ut_assert_nextline("%0*lx: 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee
ff 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
..\"3DUfw",
IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x0UL);
+ ut_assert_nextline("%0*lx: 00 41
.A",
IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x40UL);
ut_assert_console_end();
/* 16-bit */
console_record_reset();
print_hex_dump("", DUMP_PREFIX_ADDRESS, 0, 2, buf, 0x12, true);
- ut_assert_nextline(": 1100 3322 5544 7766 9988 bbaa ddcc ffee
..\"3DUfw");
- ut_assert_nextline("0010: 0010
..");
+ ut_assert_nextline("%0*lx: 1100 3322 5544 7766 9988 bbaa ddcc ffee
..\"3DUfw", IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x0UL);
+ ut_assert_nextline("%0*lx: 0010
..", IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x10UL);
ut_assert_console_end();
unmap_sysmem(buf);
/* 32-bit */
console_record_reset();
print_hex_dump("", DUMP_PREFIX_ADDRESS, 0, 4, buf, 0x14, true);
- ut_assert_nextline(": 33221100 77665544 bbaa9988 ffeeddcc
..\"3DUfw");
- ut_assert_nextline("0010: 0010
");
+ ut_assert_nextline("%0*lx: 33221100 77665544 bbaa9988 ffeeddcc
..\"3DUfw", IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x0UL);
+ ut_assert_nextline("%0*lx: 0010 ",
IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8, 0x10UL);
ut_assert_console_end();
unmap_sysmem(buf);
/* 64-bit */
console_record_reset();
print_hex_dump("", DUMP_PREFIX_ADDRESS, 16, 8, buf, 0x18, true);
- ut_assert_nextline(": 7766554433221100 ffeeddccbbaa9988
