Re: [PATCH] tools: mxsboot: pre-fill buffer with 0xff, not 0
On 12/4/23 02:35, Fabio Estevam wrote: Hi Alessandro, [Adding Marek and Rogan] On Sun, Dec 3, 2023 at 9:24 PM Alessandro Rubini wrote: The tool works for me, with imx28 and NAND memory, but the resulting blocks are reported as bad, both by u-boot and the kernel. This makes it impossible to erase from Linux (for an upgrade without console access, for example -- u-boot can "nand scrub" but linux can't). pre-filling with 0xff creates a proper boot loader image, but no bad-block marker is there when written to flash. Signed-off-by: Alessandro Rubini Isn't there some kobs-ng or whatever tool it was to properly initialize the NAND on MXS ?
Re: [PATCH v2 17/18] qemu-arm: Get bloblist from boot arguments
On 11/27/23 20:50, Raymond Mao wrote:
Add platform custom function to get bloblist from boot arguments.
Check whether boot arguments aligns with the register conventions
defined in FW Handoff spec v0.9.
Add bloblist related options into qemu default config.
Signed-off-by: Raymond Mao
---
Changes in v2
- New patch file created for v2.
board/emulation/qemu-arm/Makefile| 1 +
board/emulation/qemu-arm/lowlevel_init.S | 19 +
board/emulation/qemu-arm/qemu-arm.c | 54
configs/qemu_arm64_defconfig | 3 ++
configs/qemu_arm_defconfig | 3 ++
5 files changed, 80 insertions(+)
create mode 100644 board/emulation/qemu-arm/lowlevel_init.S
diff --git a/board/emulation/qemu-arm/Makefile
b/board/emulation/qemu-arm/Makefile
index a22d1237ff..12821e7083 100644
--- a/board/emulation/qemu-arm/Makefile
+++ b/board/emulation/qemu-arm/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0+
obj-y += qemu-arm.o
+obj-$(CONFIG_OF_BOARD) += lowlevel_init.o
diff --git a/board/emulation/qemu-arm/lowlevel_init.S
b/board/emulation/qemu-arm/lowlevel_init.S
new file mode 100644
index 00..d72d7c938a
--- /dev/null
+++ b/board/emulation/qemu-arm/lowlevel_init.S
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+/*
+ * Copyright (c) 2023, Linaro Limited
+ */
+
+#include
+
+.global save_boot_params
+save_boot_params:
+#ifdef CONFIG_ARM64
+ adr x9, qemu_saved_args
Based on logic below this is available only when CONFIG_OF_BOARD is enabled.
Please look below.
+ stp x0, x1, [x9]
+ /* Increment the address by 16 bytes for the next pair of values */
+ stp x2, x3, [x9, #16]
+#else
+ ldr r12, =qemu_saved_args
+ stm r12, {r0, r1, r2, r3}
+#endif
+ b save_boot_params_ret
diff --git a/board/emulation/qemu-arm/qemu-arm.c
b/board/emulation/qemu-arm/qemu-arm.c
index 942f1fff57..a3892630d8 100644
--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -4,6 +4,9 @@
*/
#include
+#if IS_ENABLED(CONFIG_OF_BOARD) && IS_ENABLED(CONFIG_BLOBLIST)
+#include
+#endif
you have dependency on OF_BOARD and BLOBLIST.
#include
#include
#include
@@ -102,6 +105,16 @@ static struct mm_region qemu_arm64_mem_map[] = {
struct mm_region *mem_map = qemu_arm64_mem_map;
#endif
+#if IS_ENABLED(CONFIG_OF_BOARD)
And here OF_BOARD.
Not all should be aligned but I don't think current #if
Thanks,
Michal
Re: [PATCH] mtd: spi-nor: Add IS25LP02G flash support
On 12/4/23 04:27, Venkatesh Yadav Abbarapu wrote: Add support for ISSI 256MB flash IS25LP02G. This part supports 4byte opcodes. It also supports dual and quad read. Signed-off-by: sreekanth sunnam Likely Sreekanth Sunnam here too? M
Re: [PATCH] clk: zynqmp: enable topsw_lsbus clock
On 12/4/23 04:12, Venkatesh Yadav Abbarapu wrote: Display port is using topsw_lsbus clock, it is failing while enabling the clock, so enable the topsw_lsbus clock. Signed-off-by: sreekanth sunnam Likely Sreekanth Sunnam M
Re: [PATCH 1/5] cyclic: Disable in SPL builds
Hi Simon,
On 11/19/23 19:23, Simon Glass wrote:
Hi Tom,
On Sun, 19 Nov 2023 at 08:59, Tom Rini wrote:
On Sun, Nov 19, 2023 at 07:46:39AM -0700, Simon Glass wrote:
The cyclic subsystem is currently enabled in all build phases or none.
So far it doesn't have any purpose within SPL builds, so adjust the
rules to prevent it being built in that case.
Signed-off-by: Simon Glass
---
common/Makefile | 2 +-
include/cyclic.h | 6 --
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/common/Makefile b/common/Makefile
index 1495436d5d45..27443863bf9b 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -77,7 +77,7 @@ obj-$(CONFIG_CROS_EC) += cros_ec.o
obj-y += dlmalloc.o
obj-$(CONFIG_$(SPL_TPL_)SYS_MALLOC_F) += malloc_simple.o
-obj-$(CONFIG_CYCLIC) += cyclic.o
+obj-$(CONFIG_$(SPL_TPL_)CYCLIC) += cyclic.o
obj-$(CONFIG_$(SPL_TPL_)EVENT) += event.o
obj-$(CONFIG_$(SPL_TPL_)HASH) += hash.o
This is fine, but I suspect we're missing SPL_CYCLIC as a symbol and
SPL_WDT should be select'ing that, same as "WDT".
Ooops I had assumed that it wasn't used in SPL but of course watchdog
is completely migrated to it now...I will add a symbol.
BTW the watchdog Kconfig seems a little confusiing. There is only one
board using WATCHDOG without WDT and only 3 using HW_WATCHDOG
Setfan, I wonder if some more clean-up could be done?
I fully agree that the watchdog Kconfig options are confusing. Perhaps
I can find some time in the Holidays to try to clean this up and finally
get rid of this HW_WATCHDOG stuff completely.
Thanks,
Stefan
diff --git a/include/cyclic.h b/include/cyclic.h
index 44ad3cb6b803..d3b368dd90df 100644
--- a/include/cyclic.h
+++ b/include/cyclic.h
@@ -11,6 +11,7 @@
#ifndef __cyclic_h
#define __cyclic_h
+#include
#include
#include
Is this really needed? What's blowing up since we should have -include
.../linux/kconfig.h cover this.
It is the CONFIG_IS_ENABLED() when building. We have kconfig.h in a
few other places (used by tools) too.
In file included from include/watchdog.h:13,
from tools/../lib/sha1.c:25,
from tools/generated/lib/sha1.c:1:
include/cyclic.h:47:22: error: missing binary operator before token "("
47 | #if CONFIG_IS_ENABLED(CYCLIC)
| ^
Regards,
Simon
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 1/5] cyclic: Add a symbol for SPL
On 12/2/23 16:33, Simon Glass wrote:
The cyclic subsystem is currently enabled either in all build phases
or none. For tools this should not be enabled, but since lib/shc256.c
and other files include watchdog.h in the host build, we must make
sure that it is not enabled there.
Add an SPL symbol so that there is more control of this.
Add an include into cyclic.h so that tools can include this file.
Also add the kconfig.h header so that CONFIG_IS_ENABLED() works. We
could avoid this for now by moving the location of the watchdog.h
inclusion to outside the USE_HOSTCC area. But at some point the #ifdefs
from these files will likely be removed, so there is no benefit in
going that way.
Signed-off-by: Simon Glass
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
Changes in v2:
- Add an SPL_CYCLIC symbol
- Add a lot more explanation about the header files
common/Kconfig| 8
common/Makefile | 2 +-
drivers/watchdog/Kconfig | 1 +
include/asm-generic/global_data.h | 2 +-
include/cyclic.h | 6 --
5 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/common/Kconfig b/common/Kconfig
index 0283701f1d05..5906a4af7c33 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -626,6 +626,14 @@ config CYCLIC
if CYCLIC
+config SPL_CYCLIC
+ bool "General-purpose cyclic execution mechanism (SPL)"
+ help
+ This enables a general-purpose cyclic execution infrastructure in SPL,
+ to allow "small" (run-time wise) functions to be executed at
+ a specified frequency. Things like LED blinking or watchdog
+ triggering are examples for such tasks.
+
config CYCLIC_MAX_CPU_TIME_US
int "Sets the max allowed time for a cyclic function in us"
default 1000
diff --git a/common/Makefile b/common/Makefile
index 1495436d5d45..27443863bf9b 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -77,7 +77,7 @@ obj-$(CONFIG_CROS_EC) += cros_ec.o
obj-y += dlmalloc.o
obj-$(CONFIG_$(SPL_TPL_)SYS_MALLOC_F) += malloc_simple.o
-obj-$(CONFIG_CYCLIC) += cyclic.o
+obj-$(CONFIG_$(SPL_TPL_)CYCLIC) += cyclic.o
obj-$(CONFIG_$(SPL_TPL_)EVENT) += event.o
obj-$(CONFIG_$(SPL_TPL_)HASH) += hash.o
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 07fc4940e918..378435c55cc7 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -395,6 +395,7 @@ config WDT_ARM_SMC
config SPL_WDT
bool "Enable driver model for watchdog timer drivers in SPL"
depends on SPL_DM
+ select SPL_CYCLIC if CYCLIC
help
Enable driver model for watchdog timer in SPL.
This is similar to CONFIG_WDT in U-Boot.
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index e8c6412e3f8d..77f11a4383c9 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -485,7 +485,7 @@ struct global_data {
*/
struct event_state event_state;
#endif
-#ifdef CONFIG_CYCLIC
+#if CONFIG_IS_ENABLED(CYCLIC)
/**
* @cyclic_list: list of registered cyclic functions
*/
diff --git a/include/cyclic.h b/include/cyclic.h
index 44ad3cb6b803..d3b368dd90df 100644
--- a/include/cyclic.h
+++ b/include/cyclic.h
@@ -11,6 +11,7 @@
#ifndef __cyclic_h
#define __cyclic_h
+#include
#include
#include
@@ -44,7 +45,8 @@ struct cyclic_info {
/** Function type for cyclic functions */
typedef void (*cyclic_func_t)(void *ctx);
-#if defined(CONFIG_CYCLIC)
+#if CONFIG_IS_ENABLED(CYCLIC)
+
/**
* cyclic_register - Register a new cyclic function
*
@@ -122,6 +124,6 @@ static inline int cyclic_unregister_all(void)
{
return 0;
}
-#endif
+#endif /* CYCLIC */
#endif
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] mmc: Poll CD in case cyclic framework is enabled
On 12/4/23 02:05, Marek Vasut wrote: On 12/4/23 01:44, Simon Glass wrote: Hi Marek, On Sun, 3 Dec 2023 at 14:01, Marek Vasut wrote: On 12/3/23 18:44, Simon Glass wrote: Hi Marek, On Sat, 2 Dec 2023 at 16:41, Marek Vasut wrote: In case the cyclic framework is enabled, poll the card detect of already initialized cards and deinitialize them in case they are removed. Since the card initialization is a longer process and card initialization is done on first access to an uninitialized card anyway, avoid initializing newly detected uninitialized cards in the cyclic callback. Signed-off-by: Marek Vasut --- Cc: Jaehoon Chung Cc: Peng Fan --- drivers/mmc/mmc-uclass.c | 27 +++ 1 file changed, 27 insertions(+) This is really nice! I wonder whether we can use this cyclic stuff for USB , that's on my roadmap to look at . We could auto-detect new devices in the background, which would be tidy. And maybe do block transfers in the background ? Just the detect would be amazing!! One thing on my mind is that we could have a console buffer, so that output from background tasks can be collected and written just before displaying the U-Boot prompt. I am itching to implement that part of it :-) And a 'dmesg' command to go along with it ? Go for it. It's very nice to see, that the cyclic infrastructure is finally getting used by other interfaces / devices etc. Really interesting. I assume there are many more potential use cases where it may be helpful. Thanks for all your work on this, Stefan
Re: [PATCH 1/4] tools: mkeficapsule: Add support for parsing capsule params from config file
hi Simon, On Sat, 2 Dec 2023 at 00:02, Simon Glass wrote: > > Hi Sughosh, > > On Thu, 30 Nov 2023 at 23:39, Sughosh Ganu wrote: > > > > hi Simon, > > > > On Thu, 30 Nov 2023 at 08:16, Simon Glass wrote: > > > > > > Hi Sughosh, > > > > > > On Wed, 22 Nov 2023 at 00:40, Sughosh Ganu > > > wrote: > > > > > > > > hi Ilias, > > > > > > > > On Wed, 22 Nov 2023 at 13:06, Ilias Apalodimas > > > > wrote: > > > > > > > > > > Hi all, > > > > > > > > > > On Wed, 22 Nov 2023 at 07:23, Sughosh Ganu > > > > > wrote: > > > > > > > > > > > > hi Simon, > > > > > > > > > > > > On Wed, 22 Nov 2023 at 03:42, Simon Glass wrote: > > > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > > > On Tue, 21 Nov 2023 at 00:02, Sughosh Ganu > > > > > > > wrote: > > > > > > > > > > > > > > > > Add support for specifying the parameters needed for capsule > > > > > > > > generation through a config file, instead of passing them > > > > > > > > through > > > > > > > > command-line. Parameters for more than a single capsule file > > > > > > > > can be > > > > > > > > specified, resulting in generation of multiple capsules through > > > > > > > > a > > > > > > > > single invocation of the command. > > > > > > > > > > > > > > > > The config file can then be passed to the mkeficapsule tool in > > > > > > > > such > > > > > > > > manner > > > > > > > > > > > > > > > > $ ./tools/mkeficapsule -f > > > > > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > > > > --- > > > > > > > > tools/Kconfig | 15 ++ > > > > > > > > tools/Makefile | 1 + > > > > > > > > tools/eficapsule.h | 114 > > > > > > > > tools/mkeficapsule.c | 87 + > > > > > > > > tools/mkeficapsule_parse.c | 352 > > > > > > > > + > > > > > > > > 5 files changed, 538 insertions(+), 31 deletions(-) > > > > > > > > create mode 100644 tools/mkeficapsule_parse.c > > > > > > > > > > > > > > This patch keeps coming back :-) > > > > > > > > > > > > > > Can we not add multiple capsules in the binman description? Why > > > > > > > do we > > > > > > > need a new file format? How can binman decode images produced in > > > > > > > this > > > > > > > way? > > > > > > > > > > > > So as Tom mentions, this brings parity with respect to the other > > > > > > capsule generation tool in EDKII that generates capsules. IIRC, this > > > > > > is something which even Xilix was interested in, and Michal had kind > > > > > > of gone through these patches earlier. Lastly, it would be good to > > > > > > have support in U-Boot's mkeficapsule tool for generating a single > > > > > > capsule file with multiple payloads, and having support for this > > > > > > functionality helps in that goal. > > > > > > > > > > > > Also, you might have noticed that, since your objection to the last > > > > > > series, I have removed putting this in binman. So now, this aspect > > > > > > of > > > > > > the capsule generation would only be supported through the > > > > > > command-line invocation of the tool. > > > > > > > > > > I think that overall the approach is sane. mkeficapsule is currently > > > > > supported and compiled for distros, so the multiple payload support is > > > > > useful. If we want to add support to binman, instead of rewriting this > > > > > in python, we could just call that tool for parsing and creating > > > > > capsules > > > > > > > > Given the amount of time these patches have been under review(also > > > > number of iterations), I would request that this series be reviewed > > > > and merged first. I think there is general consensus that there is > > > > value to have this functionality in the mkeficapsule tool. If it is > > > > deemed fit to support this through binman as well, that task can be > > > > taken up separately. Thanks. > > > > > > The point you are missing is that it is the entire goal of 'skirting > > > around' binman which is suspect. > > > > > > If there is a need to generate an output file from the build, we > > > should support it in binman. If people start creating configuration > > > files all over the place, then they are not using binman, right? > > > > > > I understand that there are pre-existing vendor-specific config files, > > > etc. that the EFI thing is a grey area, but I cannot imagine that this > > > patch would lead to a good outcome. > > > > > > The goal of binman is to bring order to the chaos of firmware > > > packaging...we cannot do that if it is not actually used. > > > > > > So let's figure out what is missing from binman's capsule generation > > > (multiple capsules? accept/reject capsules?) and how best to add it. > > > > I think I need to jog your memory back a bit. For context, I have > > jotted down the points. > > > > * The mkeficapsule tool generates capsules in U-Boot. > > * Currently, when the tool is invoked from the command-line, the > > capsules are generated by passing the capsule parameters as cmd-line > >
Re: [PATCH v2] watchdog: Correct watchdog timeout print message
On 12/3/23 09:30, Chanho Park wrote:
The wdt_start function takes timeout_ms as a parameter and starts the
watchdog with this value. However, when you output the message, it shows
the default timeout value for the watchdog device.
So this patch fixes that part to output the correct timeout value.
Before -->
StarFive # wdt start 3000
WDT: Started watchdog@1307 without servicing (60s timeout)
After -->
StarFive # wdt start 3000
WDT: Started watchdog@1307 without servicing (3s timeout)
Fixes: c2fd0ca1a822 ("watchdog: Integrate watchdog triggering into the cyclic
framework")
Signed-off-by: Chanho Park
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
Change from v1:
- Use lldiv to fix a build error of m68k arch
drivers/watchdog/wdt-uclass.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c
index ed329284decb..417e8d7eef95 100644
--- a/drivers/watchdog/wdt-uclass.c
+++ b/drivers/watchdog/wdt-uclass.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include
#include
#include
@@ -141,7 +142,7 @@ int wdt_start(struct udevice *dev, u64 timeout_ms, ulong
flags)
printf("WDT: Started %s with%s servicing %s (%ds timeout)\n",
dev->name, IS_ENABLED(CONFIG_WATCHDOG) ? "" : "out",
- str, priv->timeout);
+ str, (u32)lldiv(timeout_ms, 1000));
}
return ret;
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 00/12] cmd: bootefi: refactor the code for bootmgr
Akashi-san On Mon, 4 Dec 2023 at 03:58, AKASHI Takahiro wrote: > > Hi Heinrich, Ilias > > On Tue, Nov 21, 2023 at 10:29:38AM +0900, AKASHI Takahiro wrote: > > This patch set is motivated by the discussion[1] regarding > > CONFIG_BOOTEFI_BOOTMGR option. > > > > At the end, bootefi.c will be decomposed into two parts, one for > > providing the command itself and one for implementing helper functions. > > EFI_LOADER will now be available without CONFIG_CMDLINE or specifically > > CONFIG_CMD_BOOTEFI if invoked via bootmeth/bootstd. > > > > Then, EFI_LOADER library side will be further split into two options > > for fine-grain control: > > CONFIG_EFI_BINARY_EXEC: execute UEFI binaries which are to be explicitly > > loaded by U-Boot's load commands/functions or other methods > > (like a jtag debugger?) > > It supports bootmeth_efi as well as "bootefi |hello"(/"bootm"?). > > > > CONFIG_EFI_BOOTMGR: provide EFI boot manger functionality > > It supports bootmeth_efi_mgr as well as "bootefi bootmgr". > > > > As such, We will no longer need CONFIG_EFI_BINARY_EXEC if we want to only > > make use of the UEFI boot manger for booting a next stage OS. > > Any other comments? > I think the changes are no doubt trivial. I had other patches down the queue, I'll have a look within the week! Thanks /Ilias > > -Takahiro Akashi > > > > Prerequisite > > > > This patch set is based on top of Tom's "next" branch. > > > > Patches > > === > > Patch#1-#12: I hope that those commits show step-by-step refactoring > > without introducing degradation. > > > > Tests > > = > > * run UT efi_selftest on sandbox locally > > * run test_efi_bootmgr on sandbox locally > > > > Unfortunately, I could not submit a pull request for CI test. > > > > Changes > > === > > v2 (Nov 21, 2023) > > * rebased onto Tom's next branch > > * remove already merged commits > > * revise commit messages > > * add patch #5 which was split from ex-patch#5 > > RFC (Oct 26, 2023) > > > > [1] https://lists.denx.de/pipermail/u-boot/2023-October/534598.html > > > > AKASHI Takahiro (12): > > cmd: bootefi: unfold do_bootefi_image() > > cmd: bootefi: re-organize do_bootefi() > > cmd: bootefi: carve out EFI boot manager interface > > cmd: bootefi: carve out binary execution interface > > cmd: bootefi: localize global device paths for efi_selftest > > cmd: bootefi: move library interfaces under lib/efi_loader > > cmd: efidebug: ease efi configuration dependency > > bootmeth: use efi_loader interfaces instead of bootefi command > > efi_loader: split unrelated code from efi_bootmgr.c > > efi_loader: rename BOOTEFI_BOOTMGR to EFI_BOOTMGR > > net: tftp: remove explicit efi configuration dependency > > fs: remove explicit efi configuration dependency > > > > boot/Kconfig | 4 +- > > boot/Makefile| 2 +- > > boot/bootm_os.c | 31 +- > > boot/bootmeth_efi.c | 8 +- > > boot/bootmeth_efi_mgr.c | 2 +- > > cmd/Kconfig | 21 +- > > cmd/bootefi.c| 670 +-- > > cmd/efidebug.c | 4 +- > > fs/fs.c | 7 +- > > include/efi_loader.h | 34 +- > > lib/efi_loader/Kconfig | 11 +- > > lib/efi_loader/Makefile | 2 +- > > lib/efi_loader/efi_bootmgr.c | 37 ++ > > lib/efi_loader/efi_device_path.c | 3 +- > > lib/efi_loader/efi_helper.c | 498 ++- > > net/tftp.c | 10 +- > > test/boot/bootflow.c | 2 +- > > 17 files changed, 700 insertions(+), 646 deletions(-) > > > > -- > > 2.34.1 > >
Re: [PATCH v2 0/3] sunxi: add OrangePi Zero 3 board support
I have tested a newly built u-boot with the patches you provided and it works well. It is the same configuration as what I have been testing with for the last few weeks. I loaded the U-boot to SPI flash and tested with the SD card removed from the system and put in a USB card reader. The output for that test is below. For completeness you might want to mention that another difference between the zero2 and zero3 is the emac phy going from Realtek to Motorcomm. Thank you for fixing my patch attempt. It is the first one I have ever done. Thank you also for your patience with my fumbling attempts. I have learned a lot from you in the last two weeks. U-Boot SPL 2024.01-rc3-00043-g5c4e9d0c74-dirty (Dec 03 2023 - 18:21:41 -0800) DRAM: 1024 MiB Trying to boot from sunxi SPI NOTICE: BL31: v2.10.0 (debug):v2.10.0 NOTICE: BL31: Built : 18:07:18, Nov 23 2023 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0b2828, model: OrangePi Zero3 INFO:ARM GICv2 driver initialized INFO:Configuring SPC Controller INFO:PMIC: Probing AXP305 on RSB ERROR: RSB: set run-time address: 0x10003 INFO:Could not init RSB: -65539 INFO:BL31: Platform setup done INFO:BL31: Initializing runtime services INFO:BL31: cortex_a53: CPU workaround for erratum 855873 was applied INFO:BL31: cortex_a53: CPU workaround for erratum 1530924 was applied INFO:PSCI: Suspend is unavailable INFO:BL31: Preparing for EL3 exit to normal world INFO:Entry point address = 0x4a00 INFO:SPSR = 0x3c9 INFO:Changed devicetree. U-Boot 2024.01-rc3-00043-g5c4e9d0c74-dirty (Dec 03 2023 - 18:21:41 -0800) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 1 GiB Core: 57 devices, 25 uclasses, devicetree: separate WDT: Not starting watchdog@30090a0 MMC: mmc@402: 0 Loading Environment from SPIFlash... SF: Detected zb25vq128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB OK In:serial@500 Out: serial@500 Err: serial@500 Allwinner mUSB OTG (Peripheral) Net: eth0: ethernet@502using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in MAC de:ad:be:ef:00:01 HOST MAC de:ad:be:ef:00:00 RNDIS ready , eth1: usb_ether starting USB... Bus usb@520: USB EHCI 1.00 Bus usb@5200400: USB OHCI 1.0 scanning bus usb@520 for devices... Device NOT ready Request Sense returned 02 3A 00 Device NOT ready Request Sense returned 02 3A 00 Device NOT ready Request Sense returned 02 3A 00 2 USB Device(s) found scanning bus usb@5200400 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0 Card did not respond to voltage select! : -110 Device 0: Vendor: Generic- Rev: 1.00 Prod: SD/MMC Type: Removable Hard Disk Capacity: 15193.5 MB = 14.8 GB (31116288 x 512) ... is now current device Scanning usb 0:1... Found U-Boot script /boot/boot.scr 1052 bytes read in 1 ms (1 MiB/s) ## Executing script at 4fc0 Card did not respond to voltage select! : -110 ** Bad device specification mmc 0 ** 19472 bytes read in 3 ms (6.2 MiB/s) No FDT memory address configured. Please configure the FDT address via "fdt addr " command. Aborting! 7088139 bytes read in 324 ms (20.9 MiB/s) 22491144 bytes read in 1025 ms (20.9 MiB/s) Moving Image from 0x4008 to 0x4020, end=4180 ## Loading init Ramdisk from Legacy Image at 4ff0 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size:7088075 Bytes = 6.8 MiB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa0 Booting using the fdt blob at 0x4fa0 Working FDT set to 4fa0 Loading Ramdisk to 4993d000, end 49fff7cb ... OK Loading Device Tree to 49935000, end 4993cc0f ... OK Working FDT set to 49935000 Starting kernel ... Welcome to Debian GNU/Linux 12 (bookworm)! On 2023-12-03 4:59 p.m., Andre Przywara wrote: A small update for the OrangePi Zero 3 support series. This fixes USB support, and upgrades the DRAM clock to 792, for better stability (as the other DRAM parameters were tailored to that frequency). I added the tags on the way. Please test! = The OrangePi Zero 3 is a small development board featuring the Allwinner H618 SoC. Compared to its predecessor OrangePi Zero 2, the new board uses LPDDR4 DRAM instead of DDR3 DRAM, and an X-Powers AXP313 PMIC instead of the AXP305. U-Boot gained support for both LPDDR4 DRAM and the new PMIC just recently, so add a user for those features by adding a defconfig for the new board. To make this work, patch 1/3 introduces support for zBIT SPI NOR flash chip, and patch 2/3 removes the default AXP305 PMIC selection when compiling for H616 SoCs. Patch 3/3 then adds the defconfig. The DT was already synced from the Linux kernel repo a few weeks ago. Cheers, Andre
Re: [PATCH 00/21] Qualcomm generic board support
+ Linux kernel DT bindings maintainers, EBBR ML On Thu, 30 Nov 2023 at 20:05, Tom Rini wrote: > > On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: > > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong > > wrote: > > > > > > On 29/11/2023 16:34, Caleb Connolly wrote: > > > > > > > > > > > > On 23/11/2023 07:04, Sumit Garg wrote: > > > >> On Wed, 22 Nov 2023 at 21:34, Caleb Connolly > > > >> wrote: > > > >>> > > > >>> > > > >>> > > > >>> On 22/11/2023 14:27, Tom Rini wrote: > > > On Wed, Nov 22, 2023 at 07:44:09PM +0530, Sumit Garg wrote: > > > > On Wed, 22 Nov 2023 at 19:31, Tom Rini wrote: > > > >> > > > >> On Wed, Nov 22, 2023 at 11:51:29AM +0530, Sumit Garg wrote: > > > >>> Hi Caleb, > > > >>> > > > >>> On Tue, 21 Nov 2023 at 22:39, Caleb Connolly > > > >>> wrote: > > > >> [snip] > > > == DT loading == > > > > > > Previously, boards used the FDT blob embedded into U-Boot (via > > > OF_SEPARATE). However, most Qualcomm boards run U-Boot as a > > > secondary > > > bootloader, so we can instead rely on the first-stage bootloader > > > to > > > populate some useful FDT properties for us (notably the /memory > > > node and > > > KASLR seed) and fetch the DTB that it provides. Combined with > > > the memory > > > map changes above, this let's us entirely avoid configuring the > > > memory > > > map explicitly. > > > >>> > > > >>> Since with this change, we don't need to embed FDT blob in the > > > >>> u-boot > > > >>> binary, so I was thinking if we really need to import DTs from > > > >>> Linux > > > >>> for different platforms and then play a catchup game? > > > >>> > > > >>> For now, yes. > > > >> > > > >> But why? Is there any value added by larger u-boot specific DT (most > > > >> of the nodes being unused by u-boot) than what currently u-boot > > > >> supports? The more important part is to get alignment with Linux DT > > > >> bindings. If you need to have memory/reserved-memory nodes in u-boot > > > >> DT for generalization purposes then you should import those particular > > > >> nodes only. > > > > > > > > I've been thinking about and hacking on this for the last week or so, > > > > sorry for the delayed reply here. > > > > > > > > The value is in preventing any of the existing bindings from regressing, > > > > That is actually best addressed in Linux by checking the DTS against > > yaml DT bindings. We don't have that testing available in u-boot and > > only depend on careful reviews. > > I would absolutely love for someone to make another attempt at updating > our kbuild infrastucture so that we can run the validation targets. > Given that EBBR requires [1] the platform (firmware/bootloader) and not OS to supply the devicetree, it becomes evident that firmware/bootloaders import DTS from Linux kernel (where it is maintained). But currently u-boot doesn't have a proper way to validate those DTS against DT bindings (maintained in Linux kernel). Although there are Devicetree schema tools available here [2], there isn't a versioned release package of DT bindings which one should use to validate DTS files. @DT bindings maintainers, Given the ease of maintenance of DT bindings within Linux kernel source tree, I don't have a specific objection there. But can we ease DTS testing for firmware/bootloader projects by providing a versioned release package for DT bindings? Or if someone else has a better idea here please feel free to chime in. [1] https://arm-software.github.io/ebbr/#guiding-principles [2] https://github.com/devicetree-org/dt-schema -Sumit > -- > Tom
[PATCH] efi_loader: use event callback for initrd deregistration
Currently efi_initrd_deregister() is called in bootefi.c
when the image started from bootefi command returns.
Since efi_guid_event_group_return_to_efibootmgr event is
implemented, so let's use this event for invoking
initrd deregistration.
Signed-off-by: Masahisa Kojima
---
Note that this patch can be applied to u-boot/next.
This patch requires the patch e0d1a1ea68("efi_loader: add return to efibootmgr
event group")
cmd/bootefi.c| 5 --
lib/efi_loader/efi_load_initrd.c | 82 +---
2 files changed, 55 insertions(+), 32 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 4d74969ad6..e52bd3f743 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -390,11 +390,6 @@ static efi_status_t do_bootefi_exec(efi_handle_t handle,
void *load_options)
out:
free(load_options);
- if (IS_ENABLED(CONFIG_EFI_LOAD_FILE2_INITRD)) {
- if (efi_initrd_deregister() != EFI_SUCCESS)
- log_err("Failed to remove loadfile2 for initrd\n");
- }
-
/* Notify EFI_EVENT_GROUP_RETURN_TO_EFIBOOTMGR event group. */
list_for_each_entry(evt, _events, link) {
if (evt->group &&
diff --git a/lib/efi_loader/efi_load_initrd.c b/lib/efi_loader/efi_load_initrd.c
index 193433782c..7ca7785c04 100644
--- a/lib/efi_loader/efi_load_initrd.c
+++ b/lib/efi_loader/efi_load_initrd.c
@@ -184,6 +184,50 @@ out:
return ret;
}
+/**
+ * efi_initrd_deregister() - delete the handle for loading initial RAM disk
+ *
+ * This will delete the handle containing the Linux specific vendor device
+ * path and EFI_LOAD_FILE2_PROTOCOL for loading an initrd
+ *
+ * Return: status code
+ */
+efi_status_t efi_initrd_deregister(void)
+{
+ efi_status_t ret;
+
+ if (!efi_initrd_handle)
+ return EFI_SUCCESS;
+
+ ret = efi_uninstall_multiple_protocol_interfaces(efi_initrd_handle,
+/* initramfs */
+_guid_device_path,
+_lf2_handle,
+/* LOAD_FILE2 */
+
_guid_load_file2_protocol,
+_lf2_protocol,
+NULL);
+ efi_initrd_handle = NULL;
+
+ return ret;
+}
+
+/**
+ * efi_initrd_return_notify() - return to efibootmgr callback
+ *
+ * @event: the event for which this notification function is registered
+ * @context: event context
+ */
+static void EFIAPI efi_initrd_return_notify(struct efi_event *event,
+ void *context)
+{
+ efi_status_t ret;
+
+ EFI_ENTRY("%p, %p", event, context);
+ ret = efi_initrd_deregister();
+ EFI_EXIT(ret);
+}
+
/**
* efi_initrd_register() - create handle for loading initial RAM disk
*
@@ -197,6 +241,7 @@ out:
efi_status_t efi_initrd_register(void)
{
efi_status_t ret;
+ struct efi_event *event;
/*
* Allow the user to continue if Boot file path is not set for
@@ -215,34 +260,17 @@ efi_status_t efi_initrd_register(void)
_guid_load_file2_protocol,
_lf2_protocol,
NULL);
+ if (ret != EFI_SUCCESS) {
+ log_err("installing EFI_LOAD_FILE2_PROTOCOL failed\n");
+ return ret;
+ }
- return ret;
-}
-
-/**
- * efi_initrd_deregister() - delete the handle for loading initial RAM disk
- *
- * This will delete the handle containing the Linux specific vendor device
- * path and EFI_LOAD_FILE2_PROTOCOL for loading an initrd
- *
- * Return: status code
- */
-efi_status_t efi_initrd_deregister(void)
-{
- efi_status_t ret;
-
- if (!efi_initrd_handle)
- return EFI_SUCCESS;
-
- ret = efi_uninstall_multiple_protocol_interfaces(efi_initrd_handle,
-/* initramfs */
-_guid_device_path,
-_lf2_handle,
-/* LOAD_FILE2 */
-
_guid_load_file2_protocol,
-_lf2_protocol,
-NULL);
- efi_initrd_handle = NULL;
+ ret = efi_create_event(EVT_NOTIFY_SIGNAL, TPL_CALLBACK,
+ efi_initrd_return_notify, NULL,
+ _guid_event_group_return_to_efibootmgr,
+ );
+ if (ret != EFI_SUCCESS)
+
[PATCH] mtd: spi-nor: Add IS25LP02G flash support
Add support for ISSI 256MB flash IS25LP02G. This part supports 4byte
opcodes. It also supports dual and quad read.
Signed-off-by: sreekanth sunnam
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/mtd/spi/spi-nor-ids.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 3cb132dcff..9a73198227 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -217,6 +217,8 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ INFO("is25lp01g", 0x9d601b, 0, 64 * 1024, 2048,
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+ { INFO("is25lp02g", 0x9d6022, 0, 64 * 1024, 4096,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ INFO("is25wp008", 0x9d7014, 0, 64 * 1024, 16, SPI_NOR_QUAD_READ) },
{ INFO("is25wp016", 0x9d7015, 0, 64 * 1024, 32, SPI_NOR_QUAD_READ) },
{ INFO("is25wp032", 0x9d7016, 0, 64 * 1024, 64,
--
2.17.1
[PATCH] clk: zynqmp: enable topsw_lsbus clock
Display port is using topsw_lsbus clock, it is failing while enabling the clock, so enable the topsw_lsbus clock. Signed-off-by: sreekanth sunnam Signed-off-by: Venkatesh Yadav Abbarapu --- drivers/clk/clk_zynqmp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/clk_zynqmp.c b/drivers/clk/clk_zynqmp.c index 1cfe0e25b1..c059b9e8e6 100644 --- a/drivers/clk/clk_zynqmp.c +++ b/drivers/clk/clk_zynqmp.c @@ -844,6 +844,7 @@ static int zynqmp_clk_enable(struct clk *clk) break; case qspi_ref ... can1_ref: case lpd_lsbus: + case topsw_lsbus: clkact_shift = 24; mask = 0x1; break; -- 2.17.1
Re: [PATCH v2 00/12] cmd: bootefi: refactor the code for bootmgr
Hi Heinrich, Ilias On Tue, Nov 21, 2023 at 10:29:38AM +0900, AKASHI Takahiro wrote: > This patch set is motivated by the discussion[1] regarding > CONFIG_BOOTEFI_BOOTMGR option. > > At the end, bootefi.c will be decomposed into two parts, one for > providing the command itself and one for implementing helper functions. > EFI_LOADER will now be available without CONFIG_CMDLINE or specifically > CONFIG_CMD_BOOTEFI if invoked via bootmeth/bootstd. > > Then, EFI_LOADER library side will be further split into two options > for fine-grain control: > CONFIG_EFI_BINARY_EXEC: execute UEFI binaries which are to be explicitly > loaded by U-Boot's load commands/functions or other methods > (like a jtag debugger?) > It supports bootmeth_efi as well as "bootefi |hello"(/"bootm"?). > > CONFIG_EFI_BOOTMGR: provide EFI boot manger functionality > It supports bootmeth_efi_mgr as well as "bootefi bootmgr". > > As such, We will no longer need CONFIG_EFI_BINARY_EXEC if we want to only > make use of the UEFI boot manger for booting a next stage OS. Any other comments? I think the changes are no doubt trivial. -Takahiro Akashi > Prerequisite > > This patch set is based on top of Tom's "next" branch. > > Patches > === > Patch#1-#12: I hope that those commits show step-by-step refactoring > without introducing degradation. > > Tests > = > * run UT efi_selftest on sandbox locally > * run test_efi_bootmgr on sandbox locally > > Unfortunately, I could not submit a pull request for CI test. > > Changes > === > v2 (Nov 21, 2023) > * rebased onto Tom's next branch > * remove already merged commits > * revise commit messages > * add patch #5 which was split from ex-patch#5 > RFC (Oct 26, 2023) > > [1] https://lists.denx.de/pipermail/u-boot/2023-October/534598.html > > AKASHI Takahiro (12): > cmd: bootefi: unfold do_bootefi_image() > cmd: bootefi: re-organize do_bootefi() > cmd: bootefi: carve out EFI boot manager interface > cmd: bootefi: carve out binary execution interface > cmd: bootefi: localize global device paths for efi_selftest > cmd: bootefi: move library interfaces under lib/efi_loader > cmd: efidebug: ease efi configuration dependency > bootmeth: use efi_loader interfaces instead of bootefi command > efi_loader: split unrelated code from efi_bootmgr.c > efi_loader: rename BOOTEFI_BOOTMGR to EFI_BOOTMGR > net: tftp: remove explicit efi configuration dependency > fs: remove explicit efi configuration dependency > > boot/Kconfig | 4 +- > boot/Makefile| 2 +- > boot/bootm_os.c | 31 +- > boot/bootmeth_efi.c | 8 +- > boot/bootmeth_efi_mgr.c | 2 +- > cmd/Kconfig | 21 +- > cmd/bootefi.c| 670 +-- > cmd/efidebug.c | 4 +- > fs/fs.c | 7 +- > include/efi_loader.h | 34 +- > lib/efi_loader/Kconfig | 11 +- > lib/efi_loader/Makefile | 2 +- > lib/efi_loader/efi_bootmgr.c | 37 ++ > lib/efi_loader/efi_device_path.c | 3 +- > lib/efi_loader/efi_helper.c | 498 ++- > net/tftp.c | 10 +- > test/boot/bootflow.c | 2 +- > 17 files changed, 700 insertions(+), 646 deletions(-) > > -- > 2.34.1 >
Re: [PATCH] tools: mxsboot: pre-fill buffer with 0xff, not 0
Hi Alessandro, [Adding Marek and Rogan] On Sun, Dec 3, 2023 at 9:24 PM Alessandro Rubini wrote: > > The tool works for me, with imx28 and NAND memory, but the resulting > blocks are reported as bad, both by u-boot and the kernel. > > This makes it impossible to erase from Linux (for an upgrade without > console access, for example -- u-boot can "nand scrub" but linux can't). > > pre-filling with 0xff creates a proper boot loader image, but no > bad-block marker is there when written to flash. > > Signed-off-by: Alessandro Rubini > --- > tools/mxsboot.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/mxsboot.c b/tools/mxsboot.c > index 04d86f87a8..8f4018aa56 100644 > --- a/tools/mxsboot.c > +++ b/tools/mxsboot.c > @@ -478,7 +478,7 @@ static int mx28_create_nand_image(int infd, int outfd) > goto err0; > } > > - memset(buf, 0, size); > + memset(buf, 0xff, size); This makes sense: Reviewed-by: Fabio Estevam Thanks
Re: [PATCH v2] net: designware: Support high memory nodes
On Sat, 2 Dec 2023 10:39:49 +0100
Nils Le Roux wrote:
Hi Nils,
> Some platforms (such as the Lichee Pi 4A) have their dwmac device
> addressable only in high memory space. Storing the node's base address
> on 32 bits is not possible in such case.
>
> Use platform's physical address type to store the base address.
>
> Signed-off-by: Nils Le Roux
> Cc: Andre Przywara
many thanks for the changes, that looks good to me now. I have
compile-tested that for arm64 and arm.
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
>
> Changes in v2:
> - explicitly define and handle ioaddr as a virtual address
> - use an intermediate variable to assign the PCI base address
> - use appropriate placeholder to print physical addresses
> ---
> drivers/net/designware.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/designware.c b/drivers/net/designware.c
> index a174344b3e..78bfce07f6 100644
> --- a/drivers/net/designware.c
> +++ b/drivers/net/designware.c
> @@ -678,8 +678,8 @@ int designware_eth_probe(struct udevice *dev)
> {
> struct eth_pdata *pdata = dev_get_plat(dev);
> struct dw_eth_dev *priv = dev_get_priv(dev);
> - u32 iobase = pdata->iobase;
> - ulong ioaddr;
> + phys_addr_t iobase = pdata->iobase;
> + void *ioaddr;
> int ret, err;
> struct reset_ctl_bulk reset_bulk;
> #ifdef CONFIG_CLK
> @@ -740,16 +740,18 @@ int designware_eth_probe(struct udevice *dev)
>* or via a PCI bridge, fill in plat before we probe the hardware.
>*/
> if (IS_ENABLED(CONFIG_PCI) && device_is_on_pci_bus(dev)) {
> - dm_pci_read_config32(dev, PCI_BASE_ADDRESS_0, );
> - iobase &= PCI_BASE_ADDRESS_MEM_MASK;
> - iobase = dm_pci_mem_to_phys(dev, iobase);
> + u32 pcibase;
>
> + dm_pci_read_config32(dev, PCI_BASE_ADDRESS_0, );
> + pcibase &= PCI_BASE_ADDRESS_MEM_MASK;
> +
> + iobase = dm_pci_mem_to_phys(dev, pcibase);
> pdata->iobase = iobase;
> pdata->phy_interface = PHY_INTERFACE_MODE_RMII;
> }
>
> - debug("%s, iobase=%x, priv=%p\n", __func__, iobase, priv);
> - ioaddr = iobase;
> + debug("%s, iobase=%pa, priv=%p\n", __func__, , priv);
> + ioaddr = phys_to_virt(iobase);
> priv->mac_regs_p = (struct eth_mac_regs *)ioaddr;
> priv->dma_regs_p = (struct eth_dma_regs *)(ioaddr + DW_DMA_BASE_OFFSET);
> priv->interface = pdata->phy_interface;
Re: [PATCH] mmc: Poll CD in case cyclic framework is enabled
On 12/4/23 01:44, Simon Glass wrote: Hi Marek, On Sun, 3 Dec 2023 at 14:01, Marek Vasut wrote: On 12/3/23 18:44, Simon Glass wrote: Hi Marek, On Sat, 2 Dec 2023 at 16:41, Marek Vasut wrote: In case the cyclic framework is enabled, poll the card detect of already initialized cards and deinitialize them in case they are removed. Since the card initialization is a longer process and card initialization is done on first access to an uninitialized card anyway, avoid initializing newly detected uninitialized cards in the cyclic callback. Signed-off-by: Marek Vasut --- Cc: Jaehoon Chung Cc: Peng Fan --- drivers/mmc/mmc-uclass.c | 27 +++ 1 file changed, 27 insertions(+) This is really nice! I wonder whether we can use this cyclic stuff for USB , that's on my roadmap to look at . We could auto-detect new devices in the background, which would be tidy. And maybe do block transfers in the background ? Just the detect would be amazing!! One thing on my mind is that we could have a console buffer, so that output from background tasks can be collected and written just before displaying the U-Boot prompt. I am itching to implement that part of it :-) And a 'dmesg' command to go along with it ? Go for it.
[PATCH v2 3/3] sunxi: H616: Add OrangePi Zero 3 board support
The OrangePi Zero 3 is a small development board featuring the Allwinner H618 SoC, shipping with up to 4GB of DRAM, Gigabit Ethernet, a micro-HDMI connector and two USB sockets. The board uses LPDDR4 DRAM and an X-Powers AXP313a PMIC, support for which was recently added to U-Boot. Add a defconfig file selecting the right drivers and DRAM options. Since the .dts file was synced from the Linux kernel repo already, we just need to add one line to the Makefile to actually build the .dtb. The DRAM parameters were derived from the values found in the BSP DRAM drivers on the SPI NOR flash. Signed-off-by: Andre Przywara Tested-by: Mikhail Kalashnikov Tested-by: Bob McChesney --- arch/arm/dts/Makefile| 1 + board/sunxi/MAINTAINERS | 5 + configs/orangepi_zero3_defconfig | 32 3 files changed, 38 insertions(+) create mode 100644 configs/orangepi_zero3_defconfig diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 1be08c5fdc2..5fc888680b3 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -835,6 +835,7 @@ dtb-$(CONFIG_MACH_SUN50I_H6) += \ sun50i-h6-tanix-tx6-mini.dtb dtb-$(CONFIG_MACH_SUN50I_H616) += \ sun50i-h616-orangepi-zero2.dtb \ + sun50i-h618-orangepi-zero3.dtb \ sun50i-h616-x96-mate.dtb dtb-$(CONFIG_MACH_SUN50I) += \ sun50i-a64-amarula-relic.dtb \ diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index 00614372119..f556857a391 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -455,6 +455,11 @@ M: Jernej Skrabec S: Maintained F: configs/orangepi_zero2_defconfig +ORANGEPI ZERO 3 BOARD +M: Andre Przywara +S: Maintained +F: configs/orangepi_zero3_defconfig + ORANGEPI PC 2 BOARD M: Andre Przywara S: Maintained diff --git a/configs/orangepi_zero3_defconfig b/configs/orangepi_zero3_defconfig new file mode 100644 index 000..5a019fed84b --- /dev/null +++ b/configs/orangepi_zero3_defconfig @@ -0,0 +1,32 @@ +CONFIG_ARM=y +CONFIG_ARCH_SUNXI=y +CONFIG_DEFAULT_DEVICE_TREE="sun50i-h618-orangepi-zero3" +CONFIG_SPL=y +CONFIG_DRAM_SUN50I_H616_DX_ODT=0x07070707 +CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e +CONFIG_DRAM_SUN50I_H616_CA_DRI=0x0e0e +CONFIG_DRAM_SUN50I_H616_ODT_EN=0x +CONFIG_DRAM_SUN50I_H616_TPR6=0x4400 +CONFIG_DRAM_SUN50I_H616_TPR10=0x402f6663 +CONFIG_DRAM_SUN50I_H616_TPR11=0x24242624 +CONFIG_DRAM_SUN50I_H616_TPR12=0x0f0f100f +CONFIG_MACH_SUN50I_H616=y +CONFIG_SUNXI_DRAM_H616_LPDDR4=y +CONFIG_DRAM_CLK=792 +CONFIG_USB1_VBUS_PIN="PC16" +CONFIG_R_I2C_ENABLE=y +CONFIG_SPL_SPI_SUNXI=y +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set +CONFIG_SPL_I2C=y +CONFIG_SPL_SYS_I2C_LEGACY=y +CONFIG_SYS_I2C_MVTWSI=y +CONFIG_SYS_I2C_SLAVE=0x7f +CONFIG_SYS_I2C_SPEED=40 +CONFIG_SPI_FLASH_ZBIT=y +CONFIG_PHY_MOTORCOMM=y +CONFIG_SUN8I_EMAC=y +CONFIG_AXP313_POWER=y +CONFIG_SPI=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_MUSB_GADGET=y -- 2.35.8
[PATCH v2 2/3] sunxi: H616: remove default AXP305 selection
The original H616 devices released about three years ago were typically paired with an X-Powers AXP305 PMIC. Newer devices uses the smaller AXP313, and there seem to be far more systems with this PMIC around now. Remove the default AXP305 selection for the H616 SoC from the Kconfig, and move the PMIC selection into the board defconfig files instead. Signed-off-by: Andre Przywara Reviewed-by: Jaehoon Chung --- configs/orangepi_zero2_defconfig | 1 + configs/x96_mate_defconfig | 1 + drivers/power/Kconfig| 1 - 3 files changed, 2 insertions(+), 1 deletion(-) diff --git a/configs/orangepi_zero2_defconfig b/configs/orangepi_zero2_defconfig index 50009e823cb..98aed846f1f 100644 --- a/configs/orangepi_zero2_defconfig +++ b/configs/orangepi_zero2_defconfig @@ -20,6 +20,7 @@ CONFIG_SYS_I2C_SPEED=40 CONFIG_SPI_FLASH_MACRONIX=y CONFIG_PHY_REALTEK=y CONFIG_SUN8I_EMAC=y +CONFIG_AXP305_POWER=y CONFIG_SPI=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_OHCI_HCD=y diff --git a/configs/x96_mate_defconfig b/configs/x96_mate_defconfig index 318951e19c2..e805e0952b3 100644 --- a/configs/x96_mate_defconfig +++ b/configs/x96_mate_defconfig @@ -18,6 +18,7 @@ CONFIG_SPL_SYS_I2C_LEGACY=y CONFIG_SYS_I2C_MVTWSI=y CONFIG_SYS_I2C_SLAVE=0x7f CONFIG_SYS_I2C_SPEED=40 +CONFIG_AXP305_POWER=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_OHCI_HCD=y diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index 2395720c99c..33b8bc1214d 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -56,7 +56,6 @@ choice depends on ARCH_SUNXI default AXP209_POWER if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I default AXP221_POWER if MACH_SUN6I || MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUN8I_R40 - default AXP305_POWER if MACH_SUN50I_H616 default AXP818_POWER if MACH_SUN8I_A83T default SUNXI_NO_PMIC if MACH_SUNXI_H3_H5 || MACH_SUN50I || MACH_SUN8I_V3S -- 2.35.8
[PATCH v2 1/3] mtd: spi-nor: Add support for zBIT ZB25VQ128
Add support for the zBIT ZB25VQ128 (128M-bit) SPI NOR flash memory chip,
as used on the Xunlong Orange Pi Zero 3 board.
Signed-off-by: Andre Przywara
---
drivers/mtd/spi/Kconfig | 5 +
drivers/mtd/spi/spi-nor-ids.c | 5 +
2 files changed, 10 insertions(+)
diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
index 732b0760452..abed392c28d 100644
--- a/drivers/mtd/spi/Kconfig
+++ b/drivers/mtd/spi/Kconfig
@@ -224,6 +224,11 @@ config SPI_FLASH_XTX
Add support for various XTX (XTX Technology Limited)
SPI flash chips (XT25xxx).
+config SPI_FLASH_ZBIT
+ bool "ZBIT SPI flash support"
+ help
+ Add support for Zbit Semiconductor Inc. SPI flash chips (ZB25xxx).
+
endif
config SPI_FLASH_USE_4K_SECTORS
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 3cb132dcffc..f86e7ff8e58 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -571,6 +571,11 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
SPI_NOR_4B_OPCODES) },
{ INFO("xt25w01g", 0x0b651B, 0, 64 * 1024, 2048,
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
SPI_NOR_4B_OPCODES) },
+#endif
+#ifdef CONFIG_SPI_FLASH_ZBIT
+ /* Zbit Semiconductor Inc. */
+ { INFO("zb25vq128", 0x5e4018, 0, 64 * 1024, 256,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
#endif
{ },
};
--
2.35.8
[PATCH v2 0/3] sunxi: add OrangePi Zero 3 board support
A small update for the OrangePi Zero 3 support series. This fixes USB support, and upgrades the DRAM clock to 792, for better stability (as the other DRAM parameters were tailored to that frequency). I added the tags on the way. Please test! = The OrangePi Zero 3 is a small development board featuring the Allwinner H618 SoC. Compared to its predecessor OrangePi Zero 2, the new board uses LPDDR4 DRAM instead of DDR3 DRAM, and an X-Powers AXP313 PMIC instead of the AXP305. U-Boot gained support for both LPDDR4 DRAM and the new PMIC just recently, so add a user for those features by adding a defconfig for the new board. To make this work, patch 1/3 introduces support for zBIT SPI NOR flash chip, and patch 2/3 removes the default AXP305 PMIC selection when compiling for H616 SoCs. Patch 3/3 then adds the defconfig. The DT was already synced from the Linux kernel repo a few weeks ago. Cheers, Andre Changelog v1 .. v2: - add tags - set DRAM clock to 792 MHz (from the default 720 MHz) - fix USB support by supplying USB VBUS enable GPIO Andre Przywara (3): mtd: spi-nor: Add support for zBIT ZB25VQ128 sunxi: H616: remove default AXP305 selection sunxi: H616: Add OrangePi Zero 3 board support arch/arm/dts/Makefile| 1 + board/sunxi/MAINTAINERS | 5 + configs/orangepi_zero2_defconfig | 1 + configs/orangepi_zero3_defconfig | 32 configs/x96_mate_defconfig | 1 + drivers/mtd/spi/Kconfig | 5 + drivers/mtd/spi/spi-nor-ids.c| 5 + drivers/power/Kconfig| 1 - 8 files changed, 50 insertions(+), 1 deletion(-) create mode 100644 configs/orangepi_zero3_defconfig -- 2.35.8
[PATCH 00/14] pxe: Allow extlinux booting without CMDLINE enabled
This series is the culmanation of the current line of refactoring series. It adjusts pxe to call the booting functionality directly rather than going through the command-line interface. With this is is possible to boot using the extlinux bootmeth without the command line enabled. It also updates fastboot to do a similar thing. This is cmdf (part f of CMDLINE refactoring) It depends on dm/cmde-working which depends on dm/cmdd-working which depends on dm/bootstda-working which depends on dm/cmdc-working Simon Glass (14): boot: Reorder FIT and BOOTSTD to be first bootm: Add a Kconfig option for bootm functionality bootm: Make OS booting dependent on BOOTM treewide: Make arch-specific bootm code depend on BOOTM boot: Update SYS_BOOTM_LEN to depend on BOOTM fastboot: Change fastboot_buf_addr to an address bootm: Make cmdline optional with bootm_boot_start() fastboot: Remove dependencies on CMDLINE pxe: Refactor to reduce the size of label_boot() pxe: Refactor to avoid over-using bootm_argv pxe: Move calculation of FDT file into a function pxe: Allow booting without CMDLINE for bootm methods pxe: Allow booting without CMDLINE for the zboot method x86: Drop message about features being missing with 64-bit arch/arc/lib/Makefile | 2 +- arch/arm/lib/Makefile | 2 +- arch/m68k/lib/Makefile| 2 +- arch/microblaze/lib/Makefile | 2 +- arch/mips/lib/Makefile| 2 +- arch/nios2/lib/Makefile | 2 +- arch/powerpc/lib/Makefile | 2 +- arch/riscv/lib/Makefile | 2 +- arch/sandbox/lib/Makefile | 2 +- arch/sh/lib/Makefile | 2 +- arch/x86/lib/Makefile | 2 +- arch/x86/lib/spl.c| 2 +- arch/xtensa/lib/Makefile | 2 +- boot/Kconfig | 99 - boot/Makefile | 2 +- boot/bootm.c | 10 +- boot/pxe_utils.c | 361 ++ cmd/Kconfig | 50 +-- cmd/fastboot.c| 2 +- configs/colibri_vf_defconfig | 2 +- configs/iot_devkit_defconfig | 2 +- configs/mx6memcal_defconfig | 2 +- configs/tools-only_defconfig | 2 +- configs/xilinx_versal_mini_defconfig | 2 +- configs/xilinx_versal_mini_emmc0_defconfig| 2 +- configs/xilinx_versal_mini_emmc1_defconfig| 2 +- configs/xilinx_versal_mini_ospi_defconfig | 2 +- configs/xilinx_versal_mini_qspi_defconfig | 2 +- configs/xilinx_versal_net_mini_defconfig | 2 +- configs/xilinx_versal_net_mini_emmc_defconfig | 2 +- configs/xilinx_versal_net_mini_ospi_defconfig | 2 +- configs/xilinx_versal_net_mini_qspi_defconfig | 2 +- configs/xilinx_zynqmp_mini_defconfig | 2 +- configs/xilinx_zynqmp_mini_emmc0_defconfig| 2 +- configs/xilinx_zynqmp_mini_emmc1_defconfig| 2 +- configs/xilinx_zynqmp_mini_nand_defconfig | 2 +- .../xilinx_zynqmp_mini_nand_single_defconfig | 2 +- configs/xilinx_zynqmp_mini_qspi_defconfig | 2 +- configs/zynq_cse_nand_defconfig | 2 +- configs/zynq_cse_nor_defconfig| 2 +- configs/zynq_cse_qspi_defconfig | 2 +- doc/board/emulation/qemu-x86.rst | 2 +- drivers/fastboot/Kconfig | 1 - drivers/fastboot/fb_command.c | 13 +- drivers/fastboot/fb_common.c | 37 +- include/bootm.h | 2 +- include/fastboot-internal.h | 2 +- include/fastboot.h| 6 +- 48 files changed, 352 insertions(+), 305 deletions(-) -- 2.43.0.rc2.451.g8631bc7472-goog
[PATCH 00/18] Complete decoupling of bootm logic from commands
This series continues refactoring the bootm code to allow it to be used with CONFIG_COMMAND disabled. The OS-handling code is refactored and a new bootm_run() function is created to run through the bootm stages. This completes the work. A booti_go() function is created also, in case it proves useful, but at last for now standard boot does not use this. This is cmdd (part d of CMDLINE refactoring) It depends on dm/bootstda-working which depends on dm/cmdc-working Simon Glass (18): bootm: netbds: Drop passing of arguments bootm: plan: Drop passing of arguments bootm: qnxelf: Drop passing of arguments nios2: Drop separate parsing of bootm args treewide: bootm: Drop command-line args to boot_os_fn bootm: Drop arguments from boot_selected_os() mips: Add a reset_cpu() function m68k: Add a reset_cpu() function ppc: Add a reset_cpu() function nios2: Add a reset_cpu() function riscv: Add a reset_cpu() function bootm: Adjust how the board is reset bootm: Drop arguments from do_bootm_states() and rename bootm: Create a function to run through the bootm states stm32: Use local vars in stm32prog for initrd and fdt bootm: Create a function to run through the bootz states stm32: Use bootm_run() and bootz_run() bootm: Create a function to run through the booti states arch/arc/lib/bootm.c | 2 +- arch/arm/lib/bootm.c | 3 +- .../cmd_stm32prog/cmd_stm32prog.c | 35 +++-- arch/m68k/lib/bootm.c | 3 +- arch/m68k/lib/traps.c | 7 + arch/microblaze/lib/bootm.c | 3 +- arch/mips/cpu/cpu.c | 8 +- arch/mips/lib/bootm.c | 5 +- arch/nios2/cpu/cpu.c | 8 +- arch/nios2/lib/bootm.c| 5 +- arch/powerpc/lib/bootm.c | 3 +- arch/powerpc/lib/traps.c | 10 ++ arch/riscv/cpu/cpu.c | 13 ++ arch/riscv/lib/bootm.c| 5 +- arch/riscv/lib/reset.c| 7 +- arch/sandbox/lib/bootm.c | 2 +- arch/sh/lib/bootm.c | 3 +- arch/x86/lib/bootm.c | 3 +- arch/xtensa/lib/bootm.c | 2 +- boot/bootm.c | 125 ++ boot/bootm_os.c | 101 +- cmd/booti.c | 55 cmd/bootm.c | 36 +++-- cmd/bootz.c | 38 -- include/bootm.h | 107 +-- 25 files changed, 362 insertions(+), 227 deletions(-) -- 2.43.0.rc2.451.g8631bc7472-goog
Re: efi: Set Variable Runtime implementation
Hi Shantur, On Sun, 3 Dec 2023 at 14:51, Shantur Rathore wrote: > > Hi Simon, > > On Sun, Dec 3, 2023 at 5:44 PM Simon Glass wrote: > > > > Hi Shantur, > > > > On Sat, 2 Dec 2023 at 16:03, Shantur Rathore wrote: > > > > > > Hi Simon, > > > > > > On Fri, Dec 1, 2023 at 6:44 PM Simon Glass wrote: > > > > > > > > Hi Shantur, > > > > > > > > On Mon, 27 Nov 2023 at 10:27, Shantur Rathore wrote: > > > > > > > > > > + Simon as he seems to have done a lot of work in the driver model. > > > > > > > > > > On Mon, Nov 27, 2023 at 10:12 AM Shantur Rathore > > > > > wrote: > > > > > > > > > > > > Hi Ilias, > > > > > > > > > > > > On Mon, Nov 27, 2023 at 7:16 AM Ilias Apalodimas > > > > > > wrote: > > > > > > > > > > > > > > Hi Shantur > > > > > > > > > > > > > > On Sun, 26 Nov 2023 at 12:33, Shantur Rathore > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Peter, > > > > > > > > > > > > > > > > On Sat, Nov 25, 2023 at 6:19 AM Peter Robinson > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi Shantur, > > > > > > > > > > > > > > > > > > On Fri, Nov 24, 2023 at 11:55 PM Shantur Rathore > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Ilias, > > > > > > > > > > > > > > > > > > > > On Fri, Nov 24, 2023 at 10:50 PM Ilias Apalodimas > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Shantur > > > > > > > > > > > > > > > > > > > > > > On Fri, 24 Nov 2023 at 18:51, Shantur Rathore > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi Heinrich, > > > > > > > > > > > > > > > > > > > > > > > > I am trying to work out how to enable the SetVariableRT > > > > > > > > > > > > service in > > > > > > > > > > > > U-Boot and came across your patch [1] which initially > > > > > > > > > > > > had the > > > > > > > > > > > > SetVariable RT service enabled in EFI but in the final > > > > > > > > > > > > patch this was > > > > > > > > > > > > removed. > > > > > > > > > > > > I am hoping to implement it on top of the SPI Flash EFI > > > > > > > > > > > > store [2] to > > > > > > > > > > > > be able to set Boot order and boot items from Linux the > > > > > > > > > > > > UEFI way. > > > > > > > > > > > > > > > > > > > > > > > > Can I pick your brain on why it was dropped in the > > > > > > > > > > > > patch? > > > > > > > > > > > > Is there any limitation in SetVariableRT service ? > > > > > > > > > > > > > > > > > > > > > > I recently had a talk about it in Plumbers [0]. Generally > > > > > > > > > > > speaking, RT > > > > > > > > > > > + hardware owned by the kernel is a very weird > > > > > > > > > > > combination since you > > > > > > > > > > > can't guarantee exclusive access to the flash or the bus > > > > > > > > > > > and you have > > > > > > > > > > > to preserve a *lot* of code alive in u-boot. > > > > > > > > > > > > > > > > > > > > > > I'll respond to your v1 patchset and we can discuss > > > > > > > > > > > details there as well. > > > > > > > > > > > > > > > > > > > > > > [0] https://lpc.events/event/17/contributions/1653/ > > > > > > > > > > > > > > > > > > > > Thanks for the background and helping me understand the > > > > > > > > > > problem. > > > > > > > > > > Makes me wonder how things work in the PC world. > > > > > > > > > > U-boot being only ~1MB, can we not leave it all in memory > > > > > > > > > > and maybe > > > > > > > > > > just disable SPI access to Linux. > > > > > > > > > > > > > > That would work, but you cant guarantee Linux wont enable the SPI > > > > > > > flash. > > > > > > > > > > > > > > > > > > > > > > > > > That's basically it, on x86 there's specific HW that's owned > > > > > > > > > by > > > > > > > > > firmware, I don't know the exact low level details of how > > > > > > > > > that works. > > > > > > > > > > > > > > > > > > I think x86 devices generally use eSPI for this HW [1] but I > > > > > > > > > don't > > > > > > > > > know the low level details. The Arm SBSA (Server HW spec) and > > > > > > > > > SBBR > > > > > > > > > (Server Base Boot Requirements) specs that are key to > > > > > > > > > ServerReady may > > > > > > > > > go into some details too if you're curious. > > > > > > > > > > > > > > On X86 the SPI flash is handled entirely by the firmware and SMM. > > > > > > > You > > > > > > > can find more details here [0] > > > > > > > > > > > > Thanks for more info. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > I think the firmware is still accessible to PCs as one could > > > > > > > > update the firmware > > > > > > > > in Windows so Windows has access to that device. > > > > > > > > > > > > > > > > I had some try myself and found that setting a variable to > > > > > > > > memory backed storage > > > > > > > > is doable with SetVariable call but we want to store it in any > > > > > > > > non-volatile storage > > > > > > > > things really don't look good. > > > > > > > > > > > > > > > > To be able to write SetVariable to any device, the
Re: [u-boot-gitdm PATCH 2/2] Add some more employers
Hi Tom, Would it be worth be resending this as individual patches and copying the people for each domain? Or perhaps we could have a way to encourage people to add the details? Regards, Simon On Sun, 3 Dec 2023 at 14:32, Tom Rini wrote: > > On Sun, Dec 03, 2023 at 09:49:49AM +0100, Jonas Karlman wrote: > > Hi Simon, > > > > On 2023-12-03 05:46, Simon Glass wrote: > > > This looks at the top unknowns: > > > > > >git log --pretty=%ae v2023.01.. |sed 's/.*@//' |sort |uniq -c | > > > sort -nr | > > >(while read count email; do > > >if ! grep -q $email u-boot-config/domain-map; then > > > echo "$count $email"; > > >fi; done ) > > > > > > It reduces the (Unknown) count from a third to a fifth. > > > > > > Signed-off-by: Simon Glass > > > --- > > > > > > u-boot-config/domain-map | 38 ++ > > > 1 file changed, 38 insertions(+) > > > > > > diff --git a/u-boot-config/domain-map b/u-boot-config/domain-map > > > index 63cb60f..27f1a7e 100644 > > > --- a/u-boot-config/domain-map > > > +++ b/u-boot-config/domain-map > > > > [...] > > > > > @@ -164,10 +175,13 @@ jmicron.com jmicron.com > > > jp.fujitsu.com Fujitsu > > > juniper.netJuniper Networks > > > katalix.comKatalix Systems > > > +kernel-space.org kernelspace > > > keymile.comKeymile > > > keyspan.comInnoSys > > > +kwiboo.se Kwiboo > > > > kwiboo.se is my personal domain and I have no affiliation with kwiboo ltd. > > > > My kwiboo nickname and the kwiboo ltd company have no affiliation, the > > name conflict is purely accidental. I started using kwiboo as a nickname > > from around 2005, someone unrelated registered kwiboo ltd in 2007. > > > > All my U-Boot contributions should be affiliated with me personally and > > should and cannot be affiliated with an employer. > > And this is why I prefer these updates to come as single entry changes > and from someone involved there as well. I will keep an eye on what the > stats do with the subdomain on the Renesas contributions, however. > > -- > Tom
Re: [PATCH v3 3/3] defconfig: rockpro64: Enable SF EFI var store
Hi Shantur,
On Sun, 3 Dec 2023 at 14:49, Shantur Rathore wrote:
>
> Hi Simon,
>
> On Sun, Dec 3, 2023 at 5:44 PM Simon Glass wrote:
> >
> > Hi Shantur,
> >
> > On Sat, 2 Dec 2023 at 16:12, Shantur Rathore wrote:
> > >
> > > Hi Simon,
> > >
> > > On Fri, Dec 1, 2023 at 6:44 PM Simon Glass wrote:
> > > >
> > > > Hi Shantur,
> > > >
> > > > On Sun, 26 Nov 2023 at 15:09, Shantur Rathore wrote:
> > > > >
> > > > > RockPro64 uses SPI Flash for storing env, also use it store
> > > > > EFI variables.
> > > > >
> > > > > Signed-off-by: Shantur Rathore
> > > > > ---
> > > > >
> > > > > configs/rockpro64-rk3399_defconfig | 2 ++
> > > > > 1 file changed, 2 insertions(+)
> > > > >
> > > > > diff --git a/configs/rockpro64-rk3399_defconfig
> > > > > b/configs/rockpro64-rk3399_defconfig
> > > > > index 4cd6b76665..f550f2ae43 100644
> > > > > --- a/configs/rockpro64-rk3399_defconfig
> > > > > +++ b/configs/rockpro64-rk3399_defconfig
> > > > > @@ -8,6 +8,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> > > > > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x30
> > > > > CONFIG_ENV_SIZE=0x8000
> > > > > CONFIG_ENV_OFFSET=0x3F8000
> > > > > +CONFIG_EFI_VARIABLE_SF_STORE=y
> > > > > +CONFIG_EFI_VARIABLE_SF_OFFSET=0x7D
> > > >
> > > > Can we use this offset in binman when creating the SPI-flash image?
> > >
> > > Unless I missed something, binman is used when something is bundled
> > > with a u-boot image.
> > > This is similar to ENV_OFFSET letting u-boot know where it can write
> > > the EFI variables.
> > > I didn't see ENV_OFFSET referred in rk3399-u-boot.dtsi or
> > > rk3399-rockpro64-u-boot.dtsi
> > >
> > > Please correct me if I am wrong.
> >
> > Well, this is what I see in arch/arm/dts/rk3399-u-boot.dtsi :
> >
> > #if defined(CONFIG_ROCKCHIP_SPI_IMAGE) && defined(CONFIG_HAS_ROM)
> > {
> >multiple-images;
> >rom {
> > filename = "u-boot.rom";
> > size = <0x40>;
> > pad-byte = <0xff>;
> >
> > mkimage {
> > args = "-n rk3399 -T rkspi";
> > u-boot-spl {
> > };
> > };
> > u-boot-img {
> > offset = <0x4>;
> > };
> > u-boot {
> > offset = <0x30>;
> > };
> > fdtmap {
> > };
> >};
> > };
> > #endif /* CONFIG_ROCKCHIP_SPI_IMAGE && CONFIG_HAS_ROM */
> >
> > So it looks like 0x3f8000 fits in there somewhere.
> >
>
> Thanks for clarifying. Now I see how ENV space is declared as used by u-boot.
>
>
> > In fact, I wonder if we should add something like:
> >
> > u-boot-env {
> >offset = ;
> > };
> >
> > so the environment gets filled into the SPI flash when we write the image?
> >
>
> Do we want to reset the environment to default on every u-boot update?
> I believe this would overwrite the environment space isn't it.
It depends on how the update is done. If the image written is smaller
than the full size of the SPI flash and the environment is at the end
of it, then it would be preserved.
But in fact the u-boot.rom file is 0x40 bytes (4MB) so I don't see
how that would work. So we might as well add the environment in?
>
> > I suppose we could also add the EFI variable store, although that
> > would require adding a new entry type to binman.
> >
>
> I am not sure about this but surely EFI vars can be moved to a location
> just after the u-boot environment and increase the u-boot image size.
Yes.
>
> Would you still need an entry in dts?
My point was really just that the binman description should contain
the full layout of the flash. Otherwise someone might adjust something
such that the environment overlays U-Boot code, etc.
Regards,
Simon
Re: [PATCH] mmc: Poll CD in case cyclic framework is enabled
Hi Marek, On Sun, 3 Dec 2023 at 14:01, Marek Vasut wrote: > > On 12/3/23 18:44, Simon Glass wrote: > > Hi Marek, > > > > On Sat, 2 Dec 2023 at 16:41, Marek Vasut > > wrote: > >> > >> In case the cyclic framework is enabled, poll the card detect of already > >> initialized cards and deinitialize them in case they are removed. Since > >> the card initialization is a longer process and card initialization is > >> done on first access to an uninitialized card anyway, avoid initializing > >> newly detected uninitialized cards in the cyclic callback. > >> > >> Signed-off-by: Marek Vasut > >> --- > >> Cc: Jaehoon Chung > >> Cc: Peng Fan > >> --- > >> drivers/mmc/mmc-uclass.c | 27 +++ > >> 1 file changed, 27 insertions(+) > > > > This is really nice! > > I wonder whether we can use this cyclic stuff for USB , that's on my > roadmap to look at . We could auto-detect new devices in the background, > which would be tidy. And maybe do block transfers in the background ? Just the detect would be amazing!! One thing on my mind is that we could have a console buffer, so that output from background tasks can be collected and written just before displaying the U-Boot prompt. I am itching to implement that part of it :-) > > > Is there a remove() method where we could unregister the cyclic? > > I guess I need to move this into mmc_init/mmc_deinit . Yes, I suppose so. Regards, Simon
[PATCH 14/14] x86: Drop message about features being missing with 64-bit
At this point most things work, including booting a distro, so drop
this message.
Signed-off-by: Simon Glass
---
arch/x86/lib/spl.c | 2 +-
doc/board/emulation/qemu-x86.rst | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/lib/spl.c b/arch/x86/lib/spl.c
index c15f11f8cdf4..4e4cf18dec5c 100644
--- a/arch/x86/lib/spl.c
+++ b/arch/x86/lib/spl.c
@@ -283,7 +283,7 @@ void __noreturn jump_to_image_no_args(struct spl_image_info
*spl_image)
{
int ret;
- printf("Jumping to 64-bit U-Boot: Note many features are missing\n");
+ printf("Jumping to 64-bit U-Boot\n");
ret = cpu_jump_to_64bit_uboot(spl_image->entry_point);
debug("ret=%d\n", ret);
hang();
diff --git a/doc/board/emulation/qemu-x86.rst b/doc/board/emulation/qemu-x86.rst
index c604e42990ed..4eeba46ba7a9 100644
--- a/doc/board/emulation/qemu-x86.rst
+++ b/doc/board/emulation/qemu-x86.rst
@@ -134,7 +134,7 @@ The output will be something like this::
U-Boot SPL 2023.07 (Jul 23 2023 - 08:00:12 -0600)
Trying to boot from SPI
- Jumping to 64-bit U-Boot: Note many features are missing
+ Jumping to 64-bit U-Boot
U-Boot 2023.07 (Jul 23 2023 - 08:00:12 -0600)
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 13/14] pxe: Allow booting without CMDLINE for the zboot method
Use zboot_run() to boot rather than the command line. This allows
extlinux to be used (on x86) without CMDLINE being enabled.
Collect any error but do not return it, to match the existing code.
Signed-off-by: Simon Glass
---
boot/pxe_utils.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
index 322ee93a2804..2bfd82e68b9b 100644
--- a/boot/pxe_utils.c
+++ b/boot/pxe_utils.c
@@ -568,10 +568,8 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
char *initrd_addr_str, char *initrd_filesize)
{
struct bootm_info bmi;
- char *zboot_argv[] = { "zboot", NULL, "0", NULL, NULL };
const char *fdt_addr;
ulong kernel_addr_r;
- int zboot_argc = 3;
void *buf;
int ret;
@@ -624,16 +622,10 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
}
bmi.addr_fit = kernel_addr;
- zboot_argv[1] = kernel_addr;
- if (initrd_addr_str) {
+ if (initrd_addr_str)
bmi.conf_ramdisk = initrd_str;
- zboot_argv[3] = initrd_addr_str;
- zboot_argv[4] = initrd_filesize;
- zboot_argc = 5;
- }
-
if (!fdt_addr)
fdt_addr = env_get("fdt_addr");
@@ -658,8 +650,13 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
else if (IS_ENABLED(CONFIG_BOOTM))
ret = bootz_run();
/* Try booting an x86_64 Linux kernel image */
- else if (IS_ENABLED(CONFIG_CMD_ZBOOT))
- do_zboot_parent(ctx->cmdtp, 0, zboot_argc, zboot_argv, NULL);
+ else if (IS_ENABLED(CONFIG_ZBOOT))
+ ret = zboot_run(hextoul(kernel_addr, NULL), 0,
+ initrd_addr_str ?
+ hextoul(initrd_addr_str, NULL) : 0,
+ initrd_addr_str ?
+ hextoul(initrd_filesize, NULL) : 0,
+ 0, NULL);
unmap_sysmem(buf);
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 12/14] pxe: Allow booting without CMDLINE for bootm methods
Use bootm_run() to boot rather than the command line. This allows
extlinux to be used without CMDLINE being enabled.
Collect any error but do not return it, to match the existing code.
Signed-off-by: Simon Glass
---
boot/pxe_utils.c | 33 -
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
index a34f4410e07e..322ee93a2804 100644
--- a/boot/pxe_utils.c
+++ b/boot/pxe_utils.c
@@ -5,6 +5,7 @@
*/
#include
+#include
#include
#include
#include
@@ -566,13 +567,15 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
char *kernel_addr, char *initrd_str,
char *initrd_addr_str, char *initrd_filesize)
{
- char *bootm_argv[] = { "bootm", NULL, NULL, NULL, NULL };
+ struct bootm_info bmi;
char *zboot_argv[] = { "zboot", NULL, "0", NULL, NULL };
const char *fdt_addr;
ulong kernel_addr_r;
- int bootm_argc = 2;
int zboot_argc = 3;
void *buf;
+ int ret;
+
+ memset(, '\0', sizeof(struct bootm_info));
fdt_addr = env_get("fdt_addr_r");
@@ -620,12 +623,11 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
}
}
- bootm_argv[1] = kernel_addr;
+ bmi.addr_fit = kernel_addr;
zboot_argv[1] = kernel_addr;
if (initrd_addr_str) {
- bootm_argv[2] = initrd_str;
- bootm_argc = 3;
+ bmi.conf_ramdisk = initrd_str;
zboot_argv[3] = initrd_addr_str;
zboot_argv[4] = initrd_filesize;
@@ -641,23 +643,20 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
if (!fdt_addr && genimg_get_format(buf) != IMAGE_FORMAT_FIT)
fdt_addr = env_get("fdtcontroladdr");
- if (fdt_addr) {
- if (!bootm_argv[2])
- bootm_argv[2] = "-";
- bootm_argc = 4;
- }
- bootm_argv[3] = (char *)fdt_addr;
+ bmi.conf_fdt = fdt_addr;
+ if (IS_ENABLED(CONFIG_BOOTM))
+ bmi.images =
/* Try bootm for legacy and FIT format image */
if (genimg_get_format(buf) != IMAGE_FORMAT_INVALID &&
-IS_ENABLED(CONFIG_CMD_BOOTM))
- do_bootm(ctx->cmdtp, 0, bootm_argc, bootm_argv);
+ IS_ENABLED(CONFIG_BOOTM))
+ ret = bootm_run();
/* Try booting an AArch64 Linux kernel image */
- else if (IS_ENABLED(CONFIG_CMD_BOOTI))
- do_booti(ctx->cmdtp, 0, bootm_argc, bootm_argv);
+ else if (IS_ENABLED(CONFIG_BOOTM))
+ ret = booti_run();
/* Try booting a Image */
- else if (IS_ENABLED(CONFIG_CMD_BOOTZ))
- do_bootz(ctx->cmdtp, 0, bootm_argc, bootm_argv);
+ else if (IS_ENABLED(CONFIG_BOOTM))
+ ret = bootz_run();
/* Try booting an x86_64 Linux kernel image */
else if (IS_ENABLED(CONFIG_CMD_ZBOOT))
do_zboot_parent(ctx->cmdtp, 0, zboot_argc, zboot_argv, NULL);
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 11/14] pxe: Move calculation of FDT file into a function
This code undertakes a separate task from the main logic of
label_run_boot() so move it into its own function.
Signed-off-by: Simon Glass
---
boot/pxe_utils.c | 112 +++
1 file changed, 64 insertions(+), 48 deletions(-)
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
index a6aee68bb797..a34f4410e07e 100644
--- a/boot/pxe_utils.c
+++ b/boot/pxe_utils.c
@@ -469,6 +469,68 @@ skip_overlay:
}
#endif
+/**
+ * calc_fdt_fname() - Figure out the filename to use for the FDT
+ *
+ * Determine the path to the FDT filename, based on the "fdtfile" environment
+ * variable. Use -.dtb as a fallback
+ *
+ * @fdtdir: Directory to use for the FDT file
+ * Return: allocated filename (including directory), or NULL if out of memory
+ */
+static char *calc_fdt_fname(const char *fdtdir)
+{
+ char *fdtfile;
+ char *f1, *f2, *f3, *f4, *slash;
+ int len;
+
+ f1 = env_get("fdtfile");
+ if (f1) {
+ f2 = "";
+ f3 = "";
+ f4 = "";
+ } else {
+ /*
+* For complex cases where this code doesn't generate the
+* correct filename, the board code should set $fdtfile during
+* early boot, or the boot scripts should set $fdtfile before
+* invoking "pxe" or "sysboot".
+*/
+ f1 = env_get("soc");
+ f2 = "-";
+ f3 = env_get("board");
+ f4 = ".dtb";
+ if (!f1) {
+ f1 = "";
+ f2 = "";
+ }
+ if (!f3) {
+ f2 = "";
+ f3 = "";
+ }
+ }
+
+ len = strlen(fdtdir);
+ if (!len)
+ slash = "./";
+ else if (fdtdir[len - 1] != '/')
+ slash = "/";
+ else
+ slash = "";
+
+ len = strlen(fdtdir) + strlen(slash) + strlen(f1) + strlen(f2) +
+ strlen(f3) + strlen(f4) + 1;
+ fdtfile = malloc(len);
+ if (!fdtfile) {
+ printf("malloc fail (FDT filename)\n");
+ return NULL;
+ }
+
+ snprintf(fdtfile, len, "%s%s%s%s%s%s", fdtdir, slash, f1, f2, f3, f4);
+
+ return fdtfile;
+}
+
/**
* label_run_boot() - Run the correct boot procedure
*
@@ -525,55 +587,9 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
if (label->fdt) {
fdtfile = label->fdt;
} else if (label->fdtdir) {
- char *f1, *f2, *f3, *f4, *slash;
- int len;
-
- f1 = env_get("fdtfile");
- if (f1) {
- f2 = "";
- f3 = "";
- f4 = "";
- } else {
- /*
-* For complex cases where this code doesn't
-* generate the correct filename, the board
-* code should set $fdtfile during early boot,
-* or the boot scripts should set $fdtfile
-* before invoking "pxe" or "sysboot".
-*/
- f1 = env_get("soc");
- f2 = "-";
- f3 = env_get("board");
- f4 = ".dtb";
- if (!f1) {
- f1 = "";
- f2 = "";
- }
- if (!f3) {
- f2 = "";
- f3 = "";
- }
- }
-
- len = strlen(label->fdtdir);
- if (!len)
- slash = "./";
- else if (label->fdtdir[len - 1] != '/')
- slash = "/";
- else
- slash = "";
-
- len = strlen(label->fdtdir) + strlen(slash) +
- strlen(f1) + strlen(f2) + strlen(f3) +
- strlen(f4) + 1;
- fdtfilefree = malloc(len);
- if (!fdtfilefree) {
- printf("malloc fail (FDT filename)\n");
+ fdtfilefree = calc_fdt_fname(label->fdtdir);
+ if (!fdtfilefree)
return -ENOMEM;
- }
-
- snprintf(fdtfilefree, len, "%s%s%s%s%s%s",
-label->fdtdir, slash, f1, f2, f3, f4);
fdtfile = fdtfilefree;
[PATCH 10/14] pxe: Refactor to avoid over-using bootm_argv
The bootm_argv[3] expression is used in many places. It is the FDT
address, so use that name throughout.
Assign it to bootm_argv[3] only at the end, when all the conditions are
resolved.
Signed-off-by: Simon Glass
---
boot/pxe_utils.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
index 6fbccadd99e6..a6aee68bb797 100644
--- a/boot/pxe_utils.c
+++ b/boot/pxe_utils.c
@@ -506,18 +506,19 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
{
char *bootm_argv[] = { "bootm", NULL, NULL, NULL, NULL };
char *zboot_argv[] = { "zboot", NULL, "0", NULL, NULL };
+ const char *fdt_addr;
ulong kernel_addr_r;
int bootm_argc = 2;
int zboot_argc = 3;
void *buf;
- bootm_argv[3] = env_get("fdt_addr_r");
+ fdt_addr = env_get("fdt_addr_r");
/* For FIT, the label can be identical to kernel one */
if (label->fdt && !strcmp(label->kernel_label, label->fdt)) {
- bootm_argv[3] = kernel_addr;
+ fdt_addr = kernel_addr;
/* if fdt label is defined then get fdt from server */
- } else if (bootm_argv[3]) {
+ } else if (fdt_addr) {
char *fdtfile = NULL;
char *fdtfilefree = NULL;
@@ -582,7 +583,7 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
free(fdtfilefree);
if (err < 0) {
- bootm_argv[3] = NULL;
+ fdt_addr = NULL;
if (label->fdt) {
printf("Skipping %s for failure
retrieving FDT\n",
@@ -599,7 +600,7 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
label_boot_fdtoverlay(ctx, label);
#endif
} else {
- bootm_argv[3] = NULL;
+ fdt_addr = NULL;
}
}
@@ -615,20 +616,21 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
zboot_argc = 5;
}
- if (!bootm_argv[3])
- bootm_argv[3] = env_get("fdt_addr");
+ if (!fdt_addr)
+ fdt_addr = env_get("fdt_addr");
kernel_addr_r = genimg_get_kernel_addr(kernel_addr);
buf = map_sysmem(kernel_addr_r, 0);
- if (!bootm_argv[3] && genimg_get_format(buf) != IMAGE_FORMAT_FIT)
- bootm_argv[3] = env_get("fdtcontroladdr");
+ if (!fdt_addr && genimg_get_format(buf) != IMAGE_FORMAT_FIT)
+ fdt_addr = env_get("fdtcontroladdr");
- if (bootm_argv[3]) {
+ if (fdt_addr) {
if (!bootm_argv[2])
bootm_argv[2] = "-";
bootm_argc = 4;
}
+ bootm_argv[3] = (char *)fdt_addr;
/* Try bootm for legacy and FIT format image */
if (genimg_get_format(buf) != IMAGE_FORMAT_INVALID &&
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 09/14] pxe: Refactor to reduce the size of label_boot()
This function is far too long and complicated. Split out the part
which actually calls the boot commands into a separate function.
Change a strncpy() to strlcpy() to keep checkpatch happy.
No functional change is intended.
Signed-off-by: Simon Glass
---
boot/pxe_utils.c | 301 +--
1 file changed, 163 insertions(+), 138 deletions(-)
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
index a92bb896c63e..6fbccadd99e6 100644
--- a/boot/pxe_utils.c
+++ b/boot/pxe_utils.c
@@ -470,159 +470,47 @@ skip_overlay:
#endif
/**
- * label_boot() - Boot according to the contents of a pxe_label
+ * label_run_boot() - Run the correct boot procedure
*
- * If we can't boot for any reason, we return. A successful boot never
- * returns.
+ * fdt usage is optional:
+ * It handles the following scenarios.
*
- * The kernel will be stored in the location given by the 'kernel_addr_r'
- * environment variable.
+ * Scenario 1: If fdt_addr_r specified and "fdt" or "fdtdir" label is
+ * defined in pxe file, retrieve fdt blob from server. Pass fdt_addr_r to
+ * bootm, and adjust argc appropriately.
*
- * If the label specifies an initrd file, it will be stored in the location
- * given by the 'ramdisk_addr_r' environment variable.
+ * If retrieve fails and no exact fdt blob is specified in pxe file with
+ * "fdt" label, try Scenario 2.
*
- * If the label specifies an 'append' line, its contents will overwrite that
- * of the 'bootargs' environment variable.
+ * Scenario 2: If there is an fdt_addr specified, pass it along to
+ * bootm, and adjust argc appropriately.
+ *
+ * Scenario 3: If there is an fdtcontroladdr specified, pass it along to
+ * bootm, and adjust argc appropriately, unless the image type is fitImage.
+ *
+ * Scenario 4: fdt blob is not available.
*
* @ctx: PXE context
* @label: Label to process
+ * @kernel_addr: string containing the kernel address / config
+ * @initrd_str: string containing the initrd address / size
+ * @initrd_addr_str: initrd address, or NULL if none
+ * @initrd_filesize: initrd size in bytes; only valid if initrd_addr_str is not
+ * NULL
* Returns does not return on success, otherwise returns 0 if a localboot
* label was processed, or 1 on error
*/
-static int label_boot(struct pxe_context *ctx, struct pxe_label *label)
+static int label_run_boot(struct pxe_context *ctx, struct pxe_label *label,
+ char *kernel_addr, char *initrd_str,
+ char *initrd_addr_str, char *initrd_filesize)
{
char *bootm_argv[] = { "bootm", NULL, NULL, NULL, NULL };
char *zboot_argv[] = { "zboot", NULL, "0", NULL, NULL };
- char *kernel_addr = NULL;
- char *initrd_addr_str = NULL;
- char initrd_filesize[10];
- char initrd_str[28];
- char mac_str[29] = "";
- char ip_str[68] = "";
- char *fit_addr = NULL;
+ ulong kernel_addr_r;
int bootm_argc = 2;
int zboot_argc = 3;
- int len = 0;
- ulong kernel_addr_r;
void *buf;
- label_print(label);
-
- label->attempted = 1;
-
- if (label->localboot) {
- if (label->localboot_val >= 0)
- label_localboot(label);
- return 0;
- }
-
- if (!label->kernel) {
- printf("No kernel given, skipping %s\n",
- label->name);
- return 1;
- }
-
- if (get_relfile_envaddr(ctx, label->kernel, "kernel_addr_r",
- NULL) < 0) {
- printf("Skipping %s for failure retrieving kernel\n",
- label->name);
- return 1;
- }
-
- kernel_addr = env_get("kernel_addr_r");
- /* for FIT, append the configuration identifier */
- if (label->config) {
- int len = strlen(kernel_addr) + strlen(label->config) + 1;
-
- fit_addr = malloc(len);
- if (!fit_addr) {
- printf("malloc fail (FIT address)\n");
- return 1;
- }
- snprintf(fit_addr, len, "%s%s", kernel_addr, label->config);
- kernel_addr = fit_addr;
- }
-
- /* For FIT, the label can be identical to kernel one */
- if (label->initrd && !strcmp(label->kernel_label, label->initrd)) {
- initrd_addr_str = kernel_addr;
- } else if (label->initrd) {
- ulong size;
- if (get_relfile_envaddr(ctx, label->initrd, "ramdisk_addr_r",
- ) < 0) {
- printf("Skipping %s for failure retrieving initrd\n",
- label->name);
- goto cleanup;
- }
- strcpy(initrd_filesize, simple_xtoa(size));
- initrd_addr_str = env_get("ramdisk_addr_r");
- size = snprintf(initrd_str, sizeof(initrd_str),
[PATCH 08/14] fastboot: Remove dependencies on CMDLINE
It is possible to boot a kernel without CMDLINE being enabled. Update
the implementation to handle this, and drop the condition from the
FASTBOOT config.
Signed-off-by: Simon Glass
---
drivers/fastboot/Kconfig | 1 -
drivers/fastboot/fb_common.c | 26 --
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
index 11fc0fe1c800..837c6f1180da 100644
--- a/drivers/fastboot/Kconfig
+++ b/drivers/fastboot/Kconfig
@@ -1,5 +1,4 @@
menu "Fastboot support"
- depends on CMDLINE
config FASTBOOT
bool
diff --git a/drivers/fastboot/fb_common.c b/drivers/fastboot/fb_common.c
index 07f5946d9ed1..85935380e79d 100644
--- a/drivers/fastboot/fb_common.c
+++ b/drivers/fastboot/fb_common.c
@@ -11,6 +11,7 @@
*/
#include
+#include
#include
#include
#include
@@ -144,20 +145,17 @@ void fastboot_boot(void)
{
char *s;
- s = env_get("fastboot_bootcmd");
- if (s) {
- run_command(s, CMD_FLAG_ENV);
- } else if (IS_ENABLED(CONFIG_CMD_BOOTM)) {
- static char boot_addr_start[20];
- static char *const bootm_args[] = {
- "bootm", boot_addr_start, NULL
- };
-
- snprintf(boot_addr_start, sizeof(boot_addr_start) - 1,
-"%lx", fastboot_buf_addr);
- printf("Booting kernel at %s...\n\n\n", boot_addr_start);
-
- do_bootm(NULL, 0, 2, bootm_args);
+ if (IS_ENABLED(CONFIG_CMDLINE)) {
+ s = env_get("fastboot_bootcmd");
+ if (s) {
+ run_command(s, CMD_FLAG_ENV);
+ return;
+ }
+ } else if (IS_ENABLED(CONFIG_BOOTM)) {
+ int ret;
+
+ printf("Booting kernel at %lx...\n\n\n", fastboot_buf_addr);
+ ret = bootm_boot_start(fastboot_buf_addr, NULL);
/*
* This only happens if image is somehow faulty so we start
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 07/14] bootm: Make cmdline optional with bootm_boot_start()
Allow the default command line to be used when booting the OS. This is
needed by fastboot.
Signed-off-by: Simon Glass
---
boot/bootm.c| 10 ++
include/bootm.h | 2 +-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/boot/bootm.c b/boot/bootm.c
index f630b8c1a9c3..4a5da2a3bebf 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -1187,10 +1187,12 @@ int bootm_boot_start(ulong addr, const char *cmdline)
snprintf(addr_str, sizeof(addr_str), "%lx", addr);
- ret = env_set("bootargs", cmdline);
- if (ret) {
- printf("Failed to set cmdline\n");
- return ret;
+ if (cmdline) {
+ ret = env_set("bootargs", cmdline);
+ if (ret) {
+ printf("Failed to set cmdline\n");
+ return ret;
+ }
}
memset(, '\0', sizeof(bmi));
bmi.addr_fit = addr_str;
diff --git a/include/bootm.h b/include/bootm.h
index 1800ca32c264..8b0c907497ae 100644
--- a/include/bootm.h
+++ b/include/bootm.h
@@ -286,7 +286,7 @@ void zimage_dump(struct boot_params *base_ptr, bool
show_cmdline);
* bootm_boot_start() - Boot an image at the given address
*
* @addr: Image address
- * @cmdline: Command line to set
+ * @cmdline: Command line to set, NULL for default
*/
int bootm_boot_start(ulong addr, const char *cmdline);
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 06/14] fastboot: Change fastboot_buf_addr to an address
Given the name of this variable, it should be an address, not a
pointer. Update this, to make it easier to use with sandbox.
Signed-off-by: Simon Glass
---
cmd/fastboot.c| 2 +-
drivers/fastboot/fb_command.c | 13 -
drivers/fastboot/fb_common.c | 15 ---
include/fastboot-internal.h | 2 +-
include/fastboot.h| 6 +++---
5 files changed, 17 insertions(+), 21 deletions(-)
diff --git a/cmd/fastboot.c b/cmd/fastboot.c
index c3c19231c988..792e83d372c3 100644
--- a/cmd/fastboot.c
+++ b/cmd/fastboot.c
@@ -159,7 +159,7 @@ NXTARG:
return CMD_RET_USAGE;
}
- fastboot_init((void *)buf_addr, buf_size);
+ fastboot_init(buf_addr, buf_size);
if (!strcmp(argv[1], "udp"))
return do_fastboot_udp(argc, argv, buf_addr, buf_size);
diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
index 5fcadcdf503d..ec030886dbb8 100644
--- a/drivers/fastboot/fb_command.c
+++ b/drivers/fastboot/fb_command.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -252,7 +253,7 @@ void fastboot_data_download(const void *fastboot_data,
return;
}
/* Download data to fastboot_buf_addr */
- memcpy(fastboot_buf_addr + fastboot_bytes_received,
+ memcpy(map_sysmem(fastboot_buf_addr, 0) + fastboot_bytes_received,
fastboot_data, fastboot_data_len);
pre_dot_num = fastboot_bytes_received / BYTES_PER_DOT;
@@ -296,13 +297,15 @@ void fastboot_data_complete(char *response)
*/
static void __maybe_unused flash(char *cmd_parameter, char *response)
{
+ void *buf = map_sysmem(fastboot_buf_addr, 0);
+
if (IS_ENABLED(CONFIG_FASTBOOT_FLASH_MMC))
- fastboot_mmc_flash_write(cmd_parameter, fastboot_buf_addr,
-image_size, response);
+ fastboot_mmc_flash_write(cmd_parameter, buf, image_size,
+response);
if (IS_ENABLED(CONFIG_FASTBOOT_FLASH_NAND))
- fastboot_nand_flash_write(cmd_parameter, fastboot_buf_addr,
- image_size, response);
+ fastboot_nand_flash_write(cmd_parameter, buf, image_size,
+ response);
}
/**
diff --git a/drivers/fastboot/fb_common.c b/drivers/fastboot/fb_common.c
index 3576b0677299..07f5946d9ed1 100644
--- a/drivers/fastboot/fb_common.c
+++ b/drivers/fastboot/fb_common.c
@@ -20,7 +20,7 @@
/**
* fastboot_buf_addr - base address of the fastboot download buffer
*/
-void *fastboot_buf_addr;
+ulong fastboot_buf_addr;
/**
* fastboot_buf_size - size of the fastboot download buffer
@@ -154,7 +154,7 @@ void fastboot_boot(void)
};
snprintf(boot_addr_start, sizeof(boot_addr_start) - 1,
-"0x%p", fastboot_buf_addr);
+"%lx", fastboot_buf_addr);
printf("Booting kernel at %s...\n\n\n", boot_addr_start);
do_bootm(NULL, 0, 2, bootm_args);
@@ -214,16 +214,9 @@ void fastboot_set_progress_callback(void (*progress)(const
char *msg))
fastboot_progress_callback = progress;
}
-/*
- * fastboot_init() - initialise new fastboot protocol session
- *
- * @buf_addr: Pointer to download buffer, or NULL for default
- * @buf_size: Size of download buffer, or zero for default
- */
-void fastboot_init(void *buf_addr, u32 buf_size)
+void fastboot_init(ulong buf_addr, u32 buf_size)
{
- fastboot_buf_addr = buf_addr ? buf_addr :
- (void *)CONFIG_FASTBOOT_BUF_ADDR;
+ fastboot_buf_addr = buf_addr ? buf_addr : CONFIG_FASTBOOT_BUF_ADDR;
fastboot_buf_size = buf_size ? buf_size : CONFIG_FASTBOOT_BUF_SIZE;
fastboot_set_progress_callback(NULL);
}
diff --git a/include/fastboot-internal.h b/include/fastboot-internal.h
index bf2f2b3c8914..d3e1c106e23f 100644
--- a/include/fastboot-internal.h
+++ b/include/fastboot-internal.h
@@ -6,7 +6,7 @@
/**
* fastboot_buf_addr - base address of the fastboot download buffer
*/
-extern void *fastboot_buf_addr;
+extern ulong fastboot_buf_addr;
/**
* fastboot_buf_size - size of the fastboot download buffer
diff --git a/include/fastboot.h b/include/fastboot.h
index 296451f89d44..744ab61cc18a 100644
--- a/include/fastboot.h
+++ b/include/fastboot.h
@@ -103,13 +103,13 @@ int fastboot_set_reboot_flag(enum fastboot_reboot_reason
reason);
*/
void fastboot_set_progress_callback(void (*progress)(const char *msg));
-/*
+/**
* fastboot_init() - initialise new fastboot protocol session
*
- * @buf_addr: Pointer to download buffer, or NULL for default
+ * @buf_addr: Address of download buffer, or 0 for default
* @buf_size: Size of download buffer, or zero for default
*/
-void fastboot_init(void *buf_addr, u32 buf_size);
+void fastboot_init(ulong buf_addr, u32
[PATCH 05/14] boot: Update SYS_BOOTM_LEN to depend on BOOTM
Use the new CONFIG_BOOTM symbol to determine whether SYS_BOOT_LEN is visible or not, since we want to support decompression when CMDLINE is disabled. Signed-off-by: Simon Glass --- boot/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/boot/Kconfig b/boot/Kconfig index 9fa8789bc2b1..d83047acbd0d 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -800,7 +800,7 @@ endif # MEASURED_BOOT config SYS_BOOTM_LEN hex "Maximum size of a decompresed OS image" - depends on CMD_BOOTM || CMD_BOOTI || CMD_BOOTZ || \ + depends on BOOTM || CMD_BOOTI || CMD_BOOTZ || \ LEGACY_IMAGE_FORMAT || SPL_LEGACY_IMAGE_FORMAT default 0x400 if PPC || ARM64 default 0x100 if X86 || ARCH_MX6 || ARCH_MX7 -- 2.43.0.rc2.451.g8631bc7472-goog
[PATCH 04/14] treewide: Make arch-specific bootm code depend on BOOTM
Allow these functions to be compiled in when CONFIG_BOOTM is enabled, even if CONFIG_CMD_BOOTM is not. Signed-off-by: Simon Glass --- arch/arc/lib/Makefile| 2 +- arch/arm/lib/Makefile| 2 +- arch/m68k/lib/Makefile | 2 +- arch/microblaze/lib/Makefile | 2 +- arch/mips/lib/Makefile | 2 +- arch/nios2/lib/Makefile | 2 +- arch/powerpc/lib/Makefile| 2 +- arch/riscv/lib/Makefile | 2 +- arch/sandbox/lib/Makefile| 2 +- arch/sh/lib/Makefile | 2 +- arch/x86/lib/Makefile| 2 +- arch/xtensa/lib/Makefile | 2 +- 12 files changed, 12 insertions(+), 12 deletions(-) diff --git a/arch/arc/lib/Makefile b/arch/arc/lib/Makefile index 0eb44bcf33d0..bde1c3d8af3a 100644 --- a/arch/arc/lib/Makefile +++ b/arch/arc/lib/Makefile @@ -12,6 +12,6 @@ obj-y += reset.o obj-y += ints_low.o obj-y += init_helpers.o -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o lib-$(CONFIG_USE_PRIVATE_LIBGCC) += _millicodethunk.o libgcc2.o diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index b1bcd3746625..b20a467f684c 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -31,7 +31,7 @@ endif obj-$(CONFIG_CPU_V7M) += cmd_boot.o obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o obj-$(CONFIG_CMD_BOOTZ) += bootm.o zimage.o else obj-$(CONFIG_$(SPL_TPL_)FRAMEWORK) += spl.o diff --git a/arch/m68k/lib/Makefile b/arch/m68k/lib/Makefile index 6e1fd938f526..5ccd9545cb5c 100644 --- a/arch/m68k/lib/Makefile +++ b/arch/m68k/lib/Makefile @@ -8,7 +8,7 @@ lib-$(CONFIG_USE_PRIVATE_LIBGCC) += lshrdi3.o muldi3.o ashldi3.o ashrdi3.o obj-y += bdinfo.o -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o obj-y += cache.o obj-y += interrupts.o obj-y += time.o diff --git a/arch/microblaze/lib/Makefile b/arch/microblaze/lib/Makefile index dfd8135f4f25..2f234825f804 100644 --- a/arch/microblaze/lib/Makefile +++ b/arch/microblaze/lib/Makefile @@ -3,6 +3,6 @@ # (C) Copyright 2003-2006 # Wolfgang Denk, DENX Software Engineering, w...@denx.de. -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o obj-$(CONFIG_CMD_BDI) += bdinfo.o obj-y += muldi3.o diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile index 9ee1fcb5c702..f8e162c53b58 100644 --- a/arch/mips/lib/Makefile +++ b/arch/mips/lib/Makefile @@ -10,7 +10,7 @@ obj-y += reloc.o obj-y += stack.o obj-y += traps.o -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o obj-$(CONFIG_CMD_GO) += boot.o obj-$(CONFIG_SPL_BUILD) += spl.o diff --git a/arch/nios2/lib/Makefile b/arch/nios2/lib/Makefile index a9f3c7100e72..68a5ca007d55 100644 --- a/arch/nios2/lib/Makefile +++ b/arch/nios2/lib/Makefile @@ -4,5 +4,5 @@ # Wolfgang Denk, DENX Software Engineering, w...@denx.de. obj-y += cache.o -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o obj-y += libgcc.o diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile index bb819dcbb6cc..dcce9834927d 100644 --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -34,7 +34,7 @@ obj-y += ticks.o endif obj-y += reloc.o -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o obj-y += cache.o obj-y += extable.o obj-y += interrupts.o diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile index 9a05b662fd63..0b2c88db6bad 100644 --- a/arch/riscv/lib/Makefile +++ b/arch/riscv/lib/Makefile @@ -6,7 +6,7 @@ # Copyright (C) 2017 Andes Technology Corporation # Rick Chen, Andes Technology Corporation -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o obj-$(CONFIG_CMD_GO) += boot.o obj-y += cache.o diff --git a/arch/sandbox/lib/Makefile b/arch/sandbox/lib/Makefile index a2bc5a7ee60f..c4924b23c832 100644 --- a/arch/sandbox/lib/Makefile +++ b/arch/sandbox/lib/Makefile @@ -7,5 +7,5 @@ obj-y += fdt_fixup.o interrupts.o sections.o obj-$(CONFIG_PCI) += pci_io.o -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o obj-$(CONFIG_CMD_BOOTZ) += bootm.o diff --git a/arch/sh/lib/Makefile b/arch/sh/lib/Makefile index e7520a328d54..8c3c30293a3c 100644 --- a/arch/sh/lib/Makefile +++ b/arch/sh/lib/Makefile @@ -6,7 +6,7 @@ extra-y+= start.o obj-y += board.o -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o obj-y += time.o obj-$(CONFIG_CMD_SH_ZIMAGEBOOT) += zimageboot.o diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile index 8fc35e1b51ea..94aa335ede4c 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -16,7 +16,7 @@ obj-$(CONFIG_X86_32BIT_INIT) += string.o endif ifndef CONFIG_SPL_BUILD -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o endif obj-y += cmd_boot.o obj-$(CONFIG_$(SPL_)COREBOOT_SYSINFO) += coreboot/ diff --git a/arch/xtensa/lib/Makefile b/arch/xtensa/lib/Makefile
[PATCH 03/14] bootm: Make OS booting dependent on BOOTM
Booting an OS does not require the 'bootm' command, so change the condition for these options. Move them into boot/ so they don't depend on CMDLINE Note that CMD_BOOTM_PRE_LOAD has been put directly into the bootm code so will need some additional refactoring (and a test!) to allow it to change over. Signed-off-by: Simon Glass --- boot/Kconfig | 49 + cmd/Kconfig | 49 - 2 files changed, 49 insertions(+), 49 deletions(-) diff --git a/boot/Kconfig b/boot/Kconfig index 8b32a51f7e7c..9fa8789bc2b1 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -689,6 +689,55 @@ config BOOTM This option should normally be enabled. It is used to implement the 'bootm' command. +config BOOTM_LINUX + bool "Support booting Linux OS images" + depends on BOOTM || CMD_BOOTZ || CMD_BOOTI + default y + help + Support booting the Linux kernel directly via a command such as bootm + or booti or bootz. + +config BOOTM_NETBSD + bool "Support booting NetBSD (non-EFI) loader images" + depends on BOOTM + default y + help + Support booting NetBSD via the bootm command. + +config BOOTM_OPENRTOS + bool "Support booting OPENRTOS / FreeRTOS images" + depends on BOOTM + help + Support booting OPENRTOS / FreeRTOS via the bootm command. + +config BOOTM_OSE + bool "Support booting Enea OSE images" + depends on (ARM && (ARM64 || CPU_V7A || CPU_V7R) || SANDBOX || PPC || X86) + depends on BOOTM + help + Support booting Enea OSE images via the bootm command. + +config BOOTM_PLAN9 + bool "Support booting Plan9 OS images" + depends on BOOTM + default y + help + Support booting Plan9 images via the bootm command. + +config BOOTM_RTEMS + bool "Support booting RTEMS OS images" + depends on BOOTM + default y + help + Support booting RTEMS images via the bootm command. + +config BOOTM_VXWORKS + bool "Support booting VxWorks OS images" + depends on BOOTM + default y + help + Support booting VxWorks images via the bootm command. + config ANDROID_BOOT_IMAGE bool "Android Boot Images" default y if FASTBOOT diff --git a/cmd/Kconfig b/cmd/Kconfig index 74e1950e51fc..758e817e2eae 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -291,48 +291,6 @@ config CMD_BOOTI help Boot an AArch64 Linux Kernel image from memory. -config BOOTM_LINUX - bool "Support booting Linux OS images" - depends on CMD_BOOTM || CMD_BOOTZ || CMD_BOOTI - default y - help - Support booting the Linux kernel directly via a command such as bootm - or booti or bootz. - -config BOOTM_NETBSD - bool "Support booting NetBSD (non-EFI) loader images" - depends on CMD_BOOTM - default y - help - Support booting NetBSD via the bootm command. - -config BOOTM_OPENRTOS - bool "Support booting OPENRTOS / FreeRTOS images" - depends on CMD_BOOTM - help - Support booting OPENRTOS / FreeRTOS via the bootm command. - -config BOOTM_OSE - bool "Support booting Enea OSE images" - depends on (ARM && (ARM64 || CPU_V7A || CPU_V7R) || SANDBOX || PPC || X86) - depends on CMD_BOOTM - help - Support booting Enea OSE images via the bootm command. - -config BOOTM_PLAN9 - bool "Support booting Plan9 OS images" - depends on CMD_BOOTM - default y - help - Support booting Plan9 images via the bootm command. - -config BOOTM_RTEMS - bool "Support booting RTEMS OS images" - depends on CMD_BOOTM - default y - help - Support booting RTEMS images via the bootm command. - config CMD_SEAMA bool "Support read SEAMA NAND images" depends on MTD_RAW_NAND @@ -349,13 +307,6 @@ config CMD_VBE is used to boot. Updating the parameters is not currently supported. -config BOOTM_VXWORKS - bool "Support booting VxWorks OS images" - depends on CMD_BOOTM - default y - help - Support booting VxWorks images via the bootm command. - config CMD_BOOTEFI bool "bootefi" depends on EFI_LOADER -- 2.43.0.rc2.451.g8631bc7472-goog
[PATCH 02/14] bootm: Add a Kconfig option for bootm functionality
Create a separate Kconfig option which enables the bootm logic, separate from the 'bootm' command. This will eventually allow booting without CMDLINE enabled. Update boards which disable CMD_BOOTM to disable BOOTM instead, since CMD_BOOTM now depends on BOOTM Signed-off-by: Simon Glass --- boot/Kconfig | 12 boot/Makefile| 2 +- cmd/Kconfig | 1 + configs/colibri_vf_defconfig | 2 +- configs/iot_devkit_defconfig | 2 +- configs/mx6memcal_defconfig | 2 +- configs/tools-only_defconfig | 2 +- configs/xilinx_versal_mini_defconfig | 2 +- configs/xilinx_versal_mini_emmc0_defconfig | 2 +- configs/xilinx_versal_mini_emmc1_defconfig | 2 +- configs/xilinx_versal_mini_ospi_defconfig| 2 +- configs/xilinx_versal_mini_qspi_defconfig| 2 +- configs/xilinx_versal_net_mini_defconfig | 2 +- configs/xilinx_versal_net_mini_emmc_defconfig| 2 +- configs/xilinx_versal_net_mini_ospi_defconfig| 2 +- configs/xilinx_versal_net_mini_qspi_defconfig| 2 +- configs/xilinx_zynqmp_mini_defconfig | 2 +- configs/xilinx_zynqmp_mini_emmc0_defconfig | 2 +- configs/xilinx_zynqmp_mini_emmc1_defconfig | 2 +- configs/xilinx_zynqmp_mini_nand_defconfig| 2 +- configs/xilinx_zynqmp_mini_nand_single_defconfig | 2 +- configs/xilinx_zynqmp_mini_qspi_defconfig| 2 +- configs/zynq_cse_nand_defconfig | 2 +- configs/zynq_cse_nor_defconfig | 2 +- configs/zynq_cse_qspi_defconfig | 2 +- 25 files changed, 36 insertions(+), 23 deletions(-) diff --git a/boot/Kconfig b/boot/Kconfig index e0098b3f31d7..8b32a51f7e7c 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -677,6 +677,18 @@ config BOOTMETH_SCRIPT endif # BOOTSTD +config BOOTM + bool "Support booting an application image from memory" + default y + help + This is the main boot implementation in U-Boot, supporting a wide + variety of features including FIT and legacy-image boot, kernel and + FDT selection, setting up of the command line for the OS and many + other features. + + This option should normally be enabled. It is used to implement the + 'bootm' command. + config ANDROID_BOOT_IMAGE bool "Android Boot Images" default y if FASTBOOT diff --git a/boot/Makefile b/boot/Makefile index de0eafed14b1..a4ea2f9e062f 100644 --- a/boot/Makefile +++ b/boot/Makefile @@ -6,7 +6,7 @@ ifndef CONFIG_SPL_BUILD obj-$(CONFIG_BOOT_RETRY) += bootretry.o -obj-$(CONFIG_CMD_BOOTM) += bootm.o bootm_os.o +obj-$(CONFIG_BOOTM) += bootm.o bootm_os.o obj-$(CONFIG_CMD_BOOTZ) += bootm.o bootm_os.o obj-$(CONFIG_CMD_BOOTI) += bootm.o bootm_os.o diff --git a/cmd/Kconfig b/cmd/Kconfig index 584ffd039686..74e1950e51fc 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -219,6 +219,7 @@ config CMD_BOOTD config CMD_BOOTM bool "bootm" + depends on BOOTM default y help Boot an application image from the memory. diff --git a/configs/colibri_vf_defconfig b/configs/colibri_vf_defconfig index 8b2324fd5648..48019f0fa0b8 100644 --- a/configs/colibri_vf_defconfig +++ b/configs/colibri_vf_defconfig @@ -17,6 +17,7 @@ CONFIG_SYS_MEMTEST_END=0x87c0 CONFIG_ENV_VARS_UBOOT_CONFIG=y CONFIG_HAS_BOARD_SIZE_LIMIT=y CONFIG_BOARD_SIZE_LIMIT=520192 +# CONFIG_BOOTM is not set CONFIG_BOOTDELAY=1 CONFIG_FDT_FIXUP_PARTITIONS=y CONFIG_USE_BOOTCOMMAND=y @@ -33,7 +34,6 @@ CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="Colibri VFxx # " CONFIG_SYS_PBSIZE=1056 # CONFIG_CMD_BOOTD is not set -# CONFIG_CMD_BOOTM is not set CONFIG_CMD_BOOTZ=y # CONFIG_CMD_ELF is not set # CONFIG_CMD_IMI is not set diff --git a/configs/iot_devkit_defconfig b/configs/iot_devkit_defconfig index 55ced6bc3c32..a09f3ed5f77b 100644 --- a/configs/iot_devkit_defconfig +++ b/configs/iot_devkit_defconfig @@ -14,12 +14,12 @@ CONFIG_DEFAULT_DEVICE_TREE="iot_devkit" CONFIG_SYS_CLK_FREQ=1600 CONFIG_SYS_LOAD_ADDR=0x3000 CONFIG_LOCALVERSION="-iotdk-1.0" +# CONFIG_BOOTM is not set # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set CONFIG_SYS_PROMPT="IoTDK# " CONFIG_SYS_CBSIZE=256 CONFIG_SYS_PBSIZE=280 # CONFIG_CMD_BOOTD is not set -# CONFIG_CMD_BOOTM is not set # CONFIG_CMD_ELF is not set # CONFIG_CMD_XIMG is not set # CONFIG_CMD_LOADB is not set diff --git a/configs/mx6memcal_defconfig b/configs/mx6memcal_defconfig index 6dd64b6da1ba..6da7a0eaf09c 100644 --- a/configs/mx6memcal_defconfig +++ b/configs/mx6memcal_defconfig @@ -14,6 +14,7 @@ CONFIG_SPL_SERIAL=y CONFIG_SPL=y CONFIG_SYS_MEMTEST_START=0x1000 CONFIG_SYS_MEMTEST_END=0x2000 +# CONFIG_BOOTM is not set CONFIG_SUPPORT_RAW_INITRD=y CONFIG_SPL_SYS_MALLOC=y CONFIG_SPL_WATCHDOG=y @@ -21,7 +22,6 @@
[PATCH 01/14] boot: Reorder FIT and BOOTSTD to be first
The boot menu shows Android first and then a timestamp option. Move these later since they are less commonly used. Signed-off-by: Simon Glass --- boot/Kconfig | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/boot/Kconfig b/boot/Kconfig index b438002059c3..e0098b3f31d7 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -2,24 +2,6 @@ menu "Boot options" menu "Boot images" -config ANDROID_BOOT_IMAGE - bool "Android Boot Images" - default y if FASTBOOT - help - This enables support for booting images which use the Android - image format header. - -config TIMESTAMP - bool "Show image date and time when displaying image information" - default y if CMD_DATE - help - When CONFIG_TIMESTAMP is selected, the timestamp (date and time) of - an image is printed by image commands like bootm or iminfo. This - is shown as 'Timestamp: xxx' and 'Created: xxx'. If this option is - enabled, then U-Boot requires FITs to have a timestamp. If a FIT is - loaded that does not, the message 'Wrong FIT format: no timestamp' - is shown. - menuconfig FIT bool "Flattened Image Tree (FIT)" select HASH @@ -695,6 +677,24 @@ config BOOTMETH_SCRIPT endif # BOOTSTD +config ANDROID_BOOT_IMAGE + bool "Android Boot Images" + default y if FASTBOOT + help + This enables support for booting images which use the Android + image format header. + +config TIMESTAMP + bool "Show image date and time when displaying image information" + default y if CMD_DATE + help + When CONFIG_TIMESTAMP is selected, the timestamp (date and time) of + an image is printed by image commands like bootm or iminfo. This + is shown as 'Timestamp: xxx' and 'Created: xxx'. If this option is + enabled, then U-Boot requires FITs to have a timestamp. If a FIT is + loaded that does not, the message 'Wrong FIT format: no timestamp' + is shown. + config LEGACY_IMAGE_FORMAT bool "Enable support for the legacy image format" default y if !FIT_SIGNATURE && !TI_SECURE_DEVICE -- 2.43.0.rc2.451.g8631bc7472-goog
[PATCH 13/13] x86: zboot: Tidy up the comment for zboot_run()
The current use case (ChromeOS) is the uncommon case. Document how this function is more normally used, where base is 0 and cmdline is NULL Signed-off-by: Simon Glass --- include/bootm.h | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/include/bootm.h b/include/bootm.h index c815c40e3c4d..1800ca32c264 100644 --- a/include/bootm.h +++ b/include/bootm.h @@ -248,11 +248,14 @@ int bootm_process_cmdline_env(int flags); * * @addr: Address where the bzImage is moved before booting, either * BZIMAGE_LOAD_ADDR or ZIMAGE_LOAD_ADDR - * @base: Pointer to the boot parameters, typically at address - * DEFAULT_SETUP_BASE + * @size: Size of bzImage, or 0 to detect this * @initrd: Address of the initial ramdisk, or 0 if none * @initrd_size: Size of the initial ramdisk, or 0 if none - * @cmdline: Command line to use for booting + * @base_addr: If non-zero, this indicates that the boot parameters have already + * been loaded by the caller to this address, so the load_zimage() call + * in zboot_load() will be skipped when booting + * @cmdline: If non-NULL, the environment variable containing the command line + * to use for booting * Return: -EFAULT on error (normally it does not return) */ int zboot_run(ulong addr, ulong size, ulong initrd, ulong initrd_size, -- 2.43.0.rc2.451.g8631bc7472-goog
[PATCH 12/13] x86: zboot: Use zboot_start() in zboot_run()
Now that we have a function to start the process of booting a zimage,
use it in zboot_run() to avoid duplicated logic.
Signed-off-by: Simon Glass
---
arch/x86/lib/zimage.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index f2d4f3b50162..d7403876c13d 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -442,19 +442,7 @@ int zboot_run(ulong addr, ulong size, ulong initrd, ulong
initrd_size,
{
int ret;
- memset(, '\0', sizeof(state));
-
- if (base) {
- state.base_ptr = map_sysmem(base, 0);
- state.load_address = addr;
- } else {
- state.bzimage_addr = addr;
- }
- state.bzimage_size = size;
- state.initrd_addr = initrd;
- state.initrd_size = initrd_size;
- state.cmdline = cmdline;
-
+ zboot_start(addr, size, initrd, initrd_size, base, cmdline);
ret = zboot_load();
if (ret)
return log_msg_ret("ld", ret);
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 11/13] x86: zboot: Separate logic functions from commands
Move zboot_start() and zboot_info() in with the other logic functions.
Signed-off-by: Simon Glass
---
arch/x86/include/asm/zimage.h | 25 +
arch/x86/lib/zimage.c | 23 +++
cmd/x86/zboot.c | 32
3 files changed, 52 insertions(+), 28 deletions(-)
diff --git a/arch/x86/include/asm/zimage.h b/arch/x86/include/asm/zimage.h
index ac6683ea9ef3..8b5426051701 100644
--- a/arch/x86/include/asm/zimage.h
+++ b/arch/x86/include/asm/zimage.h
@@ -134,4 +134,29 @@ struct boot_params *load_zimage(char *image, unsigned long
kernel_size,
int setup_zimage(struct boot_params *setup_base, char *cmd_line, int auto_boot,
ulong initrd_addr, ulong initrd_size, ulong cmdline_force);
+/**
+ * zboot_start() - Prepare to boot a zimage
+ *
+ * Record information about a zimage so it can be booted
+ *
+ * @bzimage_addr: Address of the bzImage to boot
+ * @bzimage_size: Size of the bzImage, or 0 to detect this
+ * @initrd_addr: Address of the initial ramdisk, or 0 if none
+ * @initrd_size: Size of the initial ramdisk, or 0 if none
+ * @base_addr: If non-zero, this indicates that the boot parameters have
already
+ * been loaded by the caller to this address, so the load_zimage() call
+ * in zboot_load() will be skipped when booting
+ * @cmdline: Environment variable containing the 'override' command line, or
+ * NULL to use the one in the setup block
+ */
+void zboot_start(ulong bzimage_addr, ulong bzimage_size, ulong initrd_addr,
+ulong initrd_size, ulong base_addr, const char *cmdline);
+
+/**
+ * zboot_info() - Show simple info about a zimage
+ *
+ * Shows wherer the kernel was loaded and also the setup base
+ */
+void zboot_info(void);
+
#endif
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index e8a1849947e6..f2d4f3b50162 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -652,3 +652,26 @@ void zimage_dump(struct boot_params *base_ptr, bool
show_cmdline)
if (get_boot_protocol(hdr, false) >= 0x215)
print_num("Kernel info offset", hdr->kernel_info_offset);
}
+
+void zboot_start(ulong bzimage_addr, ulong bzimage_size, ulong initrd_addr,
+ulong initrd_size, ulong base_addr, const char *cmdline)
+{
+ memset(, '\0', sizeof(state));
+
+ state.bzimage_size = bzimage_size;
+ state.initrd_addr = initrd_addr;
+ state.initrd_size = initrd_size;
+ if (base_addr) {
+ state.base_ptr = map_sysmem(base_addr, 0);
+ state.load_address = bzimage_addr;
+ } else {
+ state.bzimage_addr = bzimage_addr;
+ }
+ state.cmdline = cmdline;
+}
+
+void zboot_info(void)
+{
+ printf("Kernel loaded at %08lx, setup_base=%p\n",
+ state.load_address, state.base_ptr);
+}
diff --git a/cmd/x86/zboot.c b/cmd/x86/zboot.c
index 572b58a5537d..addf28cb4aae 100644
--- a/cmd/x86/zboot.c
+++ b/cmd/x86/zboot.c
@@ -10,26 +10,6 @@
#include
#include
-static int zboot_start(ulong bzimage_addr, ulong bzimage_size,
- ulong initrd_addr, ulong initrd_size, ulong base_addr,
- const char *cmdline)
-{
- memset(, '\0', sizeof(state));
-
- state.bzimage_size = bzimage_size;
- state.initrd_addr = initrd_addr;
- state.initrd_size = initrd_size;
- if (base_addr) {
- state.base_ptr = map_sysmem(base_addr, 0);
- state.load_address = bzimage_addr;
- } else {
- state.bzimage_addr = bzimage_addr;
- }
- state.cmdline = cmdline;
-
- return 0;
-}
-
static int do_zboot_start(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
@@ -47,8 +27,10 @@ static int do_zboot_start(struct cmd_tbl *cmdtp, int flag,
int argc,
base_addr = argc > 5 ? hextoul(argv[5], NULL) : 0;
cmdline = argc > 6 ? env_get(argv[6]) : NULL;
- return zboot_start(bzimage_addr, bzimage_size, initrd_addr, initrd_size,
- base_addr, cmdline);
+ zboot_start(bzimage_addr, bzimage_size, initrd_addr, initrd_size,
+ base_addr, cmdline);
+
+ return 0;
}
static int do_zboot_load(struct cmd_tbl *cmdtp, int flag, int argc,
@@ -81,12 +63,6 @@ static int do_zboot_setup(struct cmd_tbl *cmdtp, int flag,
int argc,
return 0;
}
-static void zboot_info(void)
-{
- printf("Kernel loaded at %08lx, setup_base=%p\n",
- state.load_address, state.base_ptr);
-}
-
static int do_zboot_info(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 10/13] x86: zboot: Rename zboot_start() to zboot_run()
The term 'start' is used withint bootm and zboot to indicate the first
phase of booting an image.
Since zboot_start() does the whole boot, rename it to zboot_run() to
align with bootm_run() etc.
Fix a log message while we are here.
Signed-off-by: Simon Glass
---
arch/x86/lib/zimage.c | 6 +++---
boot/bootmeth_cros.c | 6 +++---
include/bootm.h | 6 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index b72e2f01bd57..e8a1849947e6 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -437,8 +437,8 @@ int zboot_go(void)
return ret;
}
-int zboot_start(ulong addr, ulong size, ulong initrd, ulong initrd_size,
- ulong base, char *cmdline)
+int zboot_run(ulong addr, ulong size, ulong initrd, ulong initrd_size,
+ ulong base, char *cmdline)
{
int ret;
@@ -463,7 +463,7 @@ int zboot_start(ulong addr, ulong size, ulong initrd, ulong
initrd_size,
return log_msg_ret("set", ret);
ret = zboot_go();
if (ret)
- return log_msg_ret("set", ret);
+ return log_msg_ret("go", ret);
return -EFAULT;
}
diff --git a/boot/bootmeth_cros.c b/boot/bootmeth_cros.c
index cd72db8250ce..f015f2e1c75f 100644
--- a/boot/bootmeth_cros.c
+++ b/boot/bootmeth_cros.c
@@ -432,9 +432,9 @@ static int cros_boot(struct udevice *dev, struct bootflow
*bflow)
}
if (IS_ENABLED(CONFIG_X86)) {
- ret = zboot_start(map_to_sysmem(bflow->buf), bflow->size, 0, 0,
- map_to_sysmem(bflow->x86_setup),
- bflow->cmdline);
+ ret = zboot_run(map_to_sysmem(bflow->buf), bflow->size, 0, 0,
+ map_to_sysmem(bflow->x86_setup),
+ bflow->cmdline);
} else {
ret = bootm_boot_start(map_to_sysmem(bflow->buf),
bflow->cmdline);
diff --git a/include/bootm.h b/include/bootm.h
index ce5298e4ed97..c815c40e3c4d 100644
--- a/include/bootm.h
+++ b/include/bootm.h
@@ -242,7 +242,7 @@ int bootm_process_cmdline(char *buf, int maxlen, int flags);
int bootm_process_cmdline_env(int flags);
/**
- * zboot_start() - Boot a zimage
+ * zboot_run() - Run through the various steps to boot a zimage
*
* Boot a zimage, given the component parts
*
@@ -255,8 +255,8 @@ int bootm_process_cmdline_env(int flags);
* @cmdline: Command line to use for booting
* Return: -EFAULT on error (normally it does not return)
*/
-int zboot_start(ulong addr, ulong size, ulong initrd, ulong initrd_size,
- ulong base, char *cmdline);
+int zboot_run(ulong addr, ulong size, ulong initrd, ulong initrd_size,
+ ulong base, char *cmdline);
/*
* zimage_get_kernel_version() - Get the version string from a kernel
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 09/13] x86: zboot: Move argument processing outside zboot_start()
Process the arguments before calling zboot_start() so that we can
separate the command line from the internal logic.
Signed-off-by: Simon Glass
---
cmd/x86/zboot.c | 67 +
1 file changed, 28 insertions(+), 39 deletions(-)
diff --git a/cmd/x86/zboot.c b/cmd/x86/zboot.c
index f49cdd91a1f8..572b58a5537d 100644
--- a/cmd/x86/zboot.c
+++ b/cmd/x86/zboot.c
@@ -10,56 +10,45 @@
#include
#include
-static void zboot_start(int argc, char *const argv[])
+static int zboot_start(ulong bzimage_addr, ulong bzimage_size,
+ ulong initrd_addr, ulong initrd_size, ulong base_addr,
+ const char *cmdline)
{
- const char *s;
-
memset(, '\0', sizeof(state));
- if (argc >= 2) {
- /* argv[1] holds the address of the bzImage */
- s = argv[1];
- } else {
- s = env_get("fileaddr");
- }
- if (s)
- state.bzimage_addr = hextoul(s, NULL);
-
- if (argc >= 3) {
- /* argv[2] holds the size of the bzImage */
- state.bzimage_size = hextoul(argv[2], NULL);
+ state.bzimage_size = bzimage_size;
+ state.initrd_addr = initrd_addr;
+ state.initrd_size = initrd_size;
+ if (base_addr) {
+ state.base_ptr = map_sysmem(base_addr, 0);
+ state.load_address = bzimage_addr;
+ } else {
+ state.bzimage_addr = bzimage_addr;
}
+ state.cmdline = cmdline;
- if (argc >= 4)
- state.initrd_addr = hextoul(argv[3], NULL);
- if (argc >= 5)
- state.initrd_size = hextoul(argv[4], NULL);
- if (argc >= 6) {
- /*
-* When the base_ptr is passed in, we assume that the image is
-* already loaded at the address given by argv[1] and therefore
-* the original bzImage is somewhere else, or not accessible.
-* In any case, we don't need access to the bzImage since all
-* the processing is assumed to be done.
-*
-* So set the base_ptr to the given address, use this arg as the
-* load address and set bzimage_addr to 0 so we know that it
-* cannot be proceesed (or processed again).
-*/
- state.base_ptr = (void *)hextoul(argv[5], NULL);
- state.load_address = state.bzimage_addr;
- state.bzimage_addr = 0;
- }
- if (argc >= 7)
- state.cmdline = env_get(argv[6]);
+ return 0;
}
static int do_zboot_start(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
- zboot_start(argc, argv);
+ ulong bzimage_addr = 0, bzimage_size, initrd_addr, initrd_size;
+ ulong base_addr;
+ const char *s, *cmdline;
- return 0;
+ /* argv[1] holds the address of the bzImage */
+ s = cmd_arg1(argc, argv) ? : env_get("fileaddr");
+ if (s)
+ bzimage_addr = hextoul(s, NULL);
+ bzimage_size = argc > 2 ? hextoul(argv[2], NULL) : 0;
+ initrd_addr = argc > 3 ? hextoul(argv[3], NULL) : 0;
+ initrd_size = argc > 4 ? hextoul(argv[4], NULL) : 0;
+ base_addr = argc > 5 ? hextoul(argv[5], NULL) : 0;
+ cmdline = argc > 6 ? env_get(argv[6]) : NULL;
+
+ return zboot_start(bzimage_addr, bzimage_size, initrd_addr, initrd_size,
+ base_addr, cmdline);
}
static int do_zboot_load(struct cmd_tbl *cmdtp, int flag, int argc,
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 08/13] x86: zboot: Drop intermediate zboot_go() function
This function only calls zboot_go() so drop it.
Signed-off-by: Simon Glass
---
cmd/x86/zboot.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/cmd/x86/zboot.c b/cmd/x86/zboot.c
index f392b6b3e493..f49cdd91a1f8 100644
--- a/cmd/x86/zboot.c
+++ b/cmd/x86/zboot.c
@@ -106,21 +106,12 @@ static int do_zboot_info(struct cmd_tbl *cmdtp, int flag,
int argc,
return 0;
}
-static int _zboot_go(void)
-{
- int ret;
-
- ret = zboot_go();
-
- return ret;
-}
-
static int do_zboot_go(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
int ret;
- ret = _zboot_go();
+ ret = zboot_go();
if (ret) {
printf("Kernel returned! (err=%d)\n", ret);
return CMD_RET_FAILURE;
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 07/13] x86: zboot: Drop intermediate zboot_setup() function
Move error checking into the caller so that do_zboot_setup() can call
zboot_setup() directly.
Signed-off-by: Simon Glass
---
cmd/x86/zboot.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/cmd/x86/zboot.c b/cmd/x86/zboot.c
index d39ab6a9698f..f392b6b3e493 100644
--- a/cmd/x86/zboot.c
+++ b/cmd/x86/zboot.c
@@ -74,11 +74,10 @@ static int do_zboot_load(struct cmd_tbl *cmdtp, int flag,
int argc,
return 0;
}
-static int _zboot_setup(void)
+static int do_zboot_setup(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
{
- struct boot_params *base_ptr = state.base_ptr;
-
- if (!base_ptr) {
+ if (!state.base_ptr) {
printf("base is not set: use 'zboot load' first\n");
return CMD_RET_FAILURE;
}
@@ -87,13 +86,10 @@ static int _zboot_setup(void)
return CMD_RET_FAILURE;
}
- return 0;
-}
+ if (zboot_setup())
+ return CMD_RET_FAILURE;
-static int do_zboot_setup(struct cmd_tbl *cmdtp, int flag, int argc,
- char *const argv[])
-{
- return _zboot_setup();
+ return 0;
}
static void zboot_info(void)
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 06/13] x86: zboot: Move environment setting into zboot_load()
The only difference between the command and the underlying logic is the
setting of envrionment variables. Move this out of the command
processing since it needs to be done in any case.
Signed-off-by: Simon Glass
---
arch/x86/lib/zimage.c | 7 +++
cmd/x86/zboot.c | 16 ++--
2 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index 1d1249fc25ac..b72e2f01bd57 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -370,6 +370,7 @@ int setup_zimage(struct boot_params *setup_base, char
*cmd_line, int auto_boot,
int zboot_load(void)
{
struct boot_params *base_ptr;
+ int ret;
if (state.base_ptr) {
struct boot_params *from = (struct boot_params *)state.base_ptr;
@@ -389,6 +390,12 @@ int zboot_load(void)
}
state.base_ptr = base_ptr;
+ ret = env_set_hex("zbootbase", map_to_sysmem(state.base_ptr));
+ if (!ret)
+ ret = env_set_hex("zbootaddr", state.load_address);
+ if (ret)
+ return ret;
+
return 0;
}
diff --git a/cmd/x86/zboot.c b/cmd/x86/zboot.c
index f5c90a8ba896..d39ab6a9698f 100644
--- a/cmd/x86/zboot.c
+++ b/cmd/x86/zboot.c
@@ -62,30 +62,18 @@ static int do_zboot_start(struct cmd_tbl *cmdtp, int flag,
int argc,
return 0;
}
-static int _zboot_load(void)
+static int do_zboot_load(struct cmd_tbl *cmdtp, int flag, int argc,
+char *const argv[])
{
int ret;
ret = zboot_load();
- if (!ret)
- ret = env_set_hex("zbootbase", map_to_sysmem(state.base_ptr));
- if (!ret)
- ret = env_set_hex("zbootaddr", state.load_address);
if (ret)
return ret;
return 0;
}
-static int do_zboot_load(struct cmd_tbl *cmdtp, int flag, int argc,
-char *const argv[])
-{
- if (_zboot_load())
- return CMD_RET_FAILURE;
-
- return 0;
-}
-
static int _zboot_setup(void)
{
struct boot_params *base_ptr = state.base_ptr;
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 05/13] x86: zboot: Create separate functions for the logic
Separate out the commands from the logic. This will eventually allow
the logic to be used when CONFIG_CMDLINE is not enabled.
Signed-off-by: Simon Glass
---
cmd/x86/zboot.c | 66 ++---
1 file changed, 52 insertions(+), 14 deletions(-)
diff --git a/cmd/x86/zboot.c b/cmd/x86/zboot.c
index 03cab1d67ebf..f5c90a8ba896 100644
--- a/cmd/x86/zboot.c
+++ b/cmd/x86/zboot.c
@@ -10,8 +10,7 @@
#include
#include
-static int do_zboot_start(struct cmd_tbl *cmdtp, int flag, int argc,
- char *const argv[])
+static void zboot_start(int argc, char *const argv[])
{
const char *s;
@@ -53,6 +52,27 @@ static int do_zboot_start(struct cmd_tbl *cmdtp, int flag,
int argc,
}
if (argc >= 7)
state.cmdline = env_get(argv[6]);
+}
+
+static int do_zboot_start(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ zboot_start(argc, argv);
+
+ return 0;
+}
+
+static int _zboot_load(void)
+{
+ int ret;
+
+ ret = zboot_load();
+ if (!ret)
+ ret = env_set_hex("zbootbase", map_to_sysmem(state.base_ptr));
+ if (!ret)
+ ret = env_set_hex("zbootaddr", state.load_address);
+ if (ret)
+ return ret;
return 0;
}
@@ -60,18 +80,13 @@ static int do_zboot_start(struct cmd_tbl *cmdtp, int flag,
int argc,
static int do_zboot_load(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
- if (zboot_load())
- return CMD_RET_FAILURE;
-
- if (env_set_hex("zbootbase", map_to_sysmem(state.base_ptr)) ||
- env_set_hex("zbootaddr", state.load_address))
+ if (_zboot_load())
return CMD_RET_FAILURE;
return 0;
}
-static int do_zboot_setup(struct cmd_tbl *cmdtp, int flag, int argc,
- char *const argv[])
+static int _zboot_setup(void)
{
struct boot_params *base_ptr = state.base_ptr;
@@ -87,24 +102,47 @@ static int do_zboot_setup(struct cmd_tbl *cmdtp, int flag,
int argc,
return 0;
}
-static int do_zboot_info(struct cmd_tbl *cmdtp, int flag, int argc,
-char *const argv[])
+static int do_zboot_setup(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ return _zboot_setup();
+}
+
+static void zboot_info(void)
{
printf("Kernel loaded at %08lx, setup_base=%p\n",
state.load_address, state.base_ptr);
+}
+
+static int do_zboot_info(struct cmd_tbl *cmdtp, int flag, int argc,
+char *const argv[])
+{
+ zboot_info();
return 0;
}
+static int _zboot_go(void)
+{
+ int ret;
+
+ ret = zboot_go();
+
+ return ret;
+}
+
static int do_zboot_go(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
int ret;
- ret = zboot_go();
- printf("Kernel returned! (err=%d)\n", ret);
+ ret = _zboot_go();
+ if (ret) {
+ printf("Kernel returned! (err=%d)\n", ret);
+ return CMD_RET_FAILURE;
+ }
- return CMD_RET_FAILURE;
+ return 0;
}
static int do_zboot_dump(struct cmd_tbl *cmdtp, int flag, int argc,
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 02/13] x86: zboot: Move command code into its own file
Much of the code in zimage.c deals with the zboot command. Move it into
a sepatate zboot.c file within the cmd/ directory. This will eventually
allow use of the zimage logic without the command being enabled.
Signed-off-by: Simon Glass
---
arch/x86/include/asm/zimage.h | 31 ++
arch/x86/lib/zimage.c | 199 +
cmd/x86/Makefile | 1 +
cmd/x86/zboot.c | 203 ++
4 files changed, 239 insertions(+), 195 deletions(-)
create mode 100644 cmd/x86/zboot.c
diff --git a/arch/x86/include/asm/zimage.h b/arch/x86/include/asm/zimage.h
index a91cfb2b8dd0..ac6683ea9ef3 100644
--- a/arch/x86/include/asm/zimage.h
+++ b/arch/x86/include/asm/zimage.h
@@ -71,6 +71,37 @@ struct zboot_state {
extern struct zboot_state state;
+/**
+ * zimage_dump() - Dump information about a zimage
+ *
+ * @base_ptr: Pointer to the boot parameters
+ * @show_cmdline: true to show the kernel command line
+ */
+void zimage_dump(struct boot_params *base_ptr, bool show_cmdline);
+
+/**
+ * zboot_load() - Load a zimage
+ *
+ * Load the zimage into the correct place
+ *
+ * Return: 0 if OK, -ve on error
+ */
+int zboot_load(void);
+
+/**
+ * zboot_setup() - Set up the zboot image reeady for booting
+ *
+ * Return: 0 if OK, -ve on error
+ */
+int zboot_setup(void);
+
+/**
+ * zboot_go() - Start the image
+ *
+ * Return: 0 if OK, -ve on error
+ */
+int zboot_go(void);
+
/**
* load_zimage() - Load a zImage or bzImage
*
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index b04d39b36dd4..1d1249fc25ac 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -56,6 +56,7 @@ DECLARE_GLOBAL_DATA_PTR;
#define COMMAND_LINE_SIZE 2048
+/* Current state of the boot */
struct zboot_state state;
static void build_command_line(char *command_line, int auto_boot)
@@ -366,54 +367,7 @@ int setup_zimage(struct boot_params *setup_base, char
*cmd_line, int auto_boot,
return 0;
}
-static int do_zboot_start(struct cmd_tbl *cmdtp, int flag, int argc,
- char *const argv[])
-{
- const char *s;
-
- memset(, '\0', sizeof(state));
- if (argc >= 2) {
- /* argv[1] holds the address of the bzImage */
- s = argv[1];
- } else {
- s = env_get("fileaddr");
- }
-
- if (s)
- state.bzimage_addr = hextoul(s, NULL);
-
- if (argc >= 3) {
- /* argv[2] holds the size of the bzImage */
- state.bzimage_size = hextoul(argv[2], NULL);
- }
-
- if (argc >= 4)
- state.initrd_addr = hextoul(argv[3], NULL);
- if (argc >= 5)
- state.initrd_size = hextoul(argv[4], NULL);
- if (argc >= 6) {
- /*
-* When the base_ptr is passed in, we assume that the image is
-* already loaded at the address given by argv[1] and therefore
-* the original bzImage is somewhere else, or not accessible.
-* In any case, we don't need access to the bzImage since all
-* the processing is assumed to be done.
-*
-* So set the base_ptr to the given address, use this arg as the
-* load address and set bzimage_addr to 0 so we know that it
-* cannot be proceesed (or processed again).
-*/
- state.base_ptr = (void *)hextoul(argv[5], NULL);
- state.load_address = state.bzimage_addr;
- state.bzimage_addr = 0;
- }
- if (argc >= 7)
- state.cmdline = env_get(argv[6]);
-
- return 0;
-}
-
-static int zboot_load(void)
+int zboot_load(void)
{
struct boot_params *base_ptr;
@@ -438,20 +392,7 @@ static int zboot_load(void)
return 0;
}
-static int do_zboot_load(struct cmd_tbl *cmdtp, int flag, int argc,
-char *const argv[])
-{
- if (zboot_load())
- return CMD_RET_FAILURE;
-
- if (env_set_hex("zbootbase", map_to_sysmem(state.base_ptr)) ||
- env_set_hex("zbootaddr", state.load_address))
- return CMD_RET_FAILURE;
-
- return 0;
-}
-
-static int zboot_setup(void)
+int zboot_setup(void)
{
struct boot_params *base_ptr = state.base_ptr;
int ret;
@@ -465,33 +406,7 @@ static int zboot_setup(void)
return 0;
}
-static int do_zboot_setup(struct cmd_tbl *cmdtp, int flag, int argc,
- char *const argv[])
-{
- struct boot_params *base_ptr = state.base_ptr;
-
- if (!base_ptr) {
- printf("base is not set: use 'zboot load' first\n");
- return CMD_RET_FAILURE;
- }
- if (zboot_setup()) {
- puts("Setting up boot parameters failed ...\n");
- return CMD_RET_FAILURE;
- }
-
- return 0;
-}
-
-static int do_zboot_info(struct cmd_tbl *cmdtp,
[PATCH 04/13] x86: zboot: Avoid iteration in do_zboot_states()
Drop the iteration and write out each state in full. This will allow
the arguments to be reduced and adjusted in future patches.
Signed-off-by: Simon Glass
---
cmd/x86/zboot.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/cmd/x86/zboot.c b/cmd/x86/zboot.c
index c9375fb417c1..03cab1d67ebf 100644
--- a/cmd/x86/zboot.c
+++ b/cmd/x86/zboot.c
@@ -136,19 +136,20 @@ U_BOOT_SUBCMDS(zboot,
int do_zboot_states(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[], int state_mask)
{
- int i;
-
- for (i = 0; i < ZBOOT_STATE_COUNT; i++) {
- struct cmd_tbl *cmd = _subcmds[i];
- int mask = 1 << i;
- int ret;
-
- if (mask & state_mask) {
- ret = cmd->cmd(cmd, flag, argc, argv);
- if (ret)
- return ret;
- }
- }
+ int ret;
+
+ if (flag & ZBOOT_STATE_START)
+ ret = do_zboot_start(cmdtp, flag, argc, argv);
+ if (!ret && (flag & ZBOOT_STATE_LOAD))
+ ret = do_zboot_load(cmdtp, flag, argc, argv);
+ if (!ret && (flag & ZBOOT_STATE_SETUP))
+ ret = do_zboot_setup(cmdtp, flag, argc, argv);
+ if (!ret && (flag & ZBOOT_STATE_INFO))
+ ret = do_zboot_info(cmdtp, flag, argc, argv);
+ if (!ret && (flag & ZBOOT_STATE_GO))
+ ret = do_zboot_go(cmdtp, flag, argc, argv);
+ if (ret)
+ return ret;
return 0;
}
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 03/13] x86: zboot: Create a separate ZBOOT option for zboot logic
Most of the functionality of zboot is contained in the logic which handles a zimage. Create a separate Kconfig for the logic so that it can (later) be used without the command itself being enabled. Enable ZBOOT by default on x86, with the command depending on that. The existing 'imply' can therefore be removed. Signed-off-by: Simon Glass --- arch/Kconfig | 1 - arch/x86/Kconfig | 8 arch/x86/lib/Makefile | 2 +- cmd/Kconfig | 2 ++ 4 files changed, 11 insertions(+), 2 deletions(-) diff --git a/arch/Kconfig b/arch/Kconfig index 2e0528d819c9..de91aac4b8d4 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -246,7 +246,6 @@ config X86 imply CMD_PCI imply CMD_SF imply CMD_SF_TEST - imply CMD_ZBOOT imply DM_GPIO imply DM_KEYBOARD imply DM_MMC diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 99e59d94c606..e5ee10af33c5 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1053,4 +1053,12 @@ config SPL_COREBOOT_SYSINFO display, memory and build information. It is stored in struct sysinfo_t after parsing by get_coreboot_info(). +config ZBOOT + bool "Support the zImage format" + default y + help + Enable this to support booting the x86-specific zImage format. This + uses a special, binary format containing information about the Linux + format to boot. + endmenu diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile index 90a7618ecfde..8fc35e1b51ea 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -48,7 +48,7 @@ obj-$(CONFIG_$(SPL_TPL_)GENERATE_ACPI_TABLE) += acpi_table.o endif obj-y += tables.o ifndef CONFIG_SPL_BUILD -obj-$(CONFIG_CMD_ZBOOT)+= zimage.o +obj-$(CONFIG_ZBOOT) += zimage.o endif obj-$(CONFIG_USE_HOB) += hob.o ifndef CONFIG_TPL_BUILD diff --git a/cmd/Kconfig b/cmd/Kconfig index 9ebea76c2ce5..584ffd039686 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -538,6 +538,8 @@ config THOR_RESET_OFF config CMD_ZBOOT bool "zboot - x86 boot command" + depends on ZBOOT + default y help With x86 machines it is common to boot a bzImage file which contains both a kernel and a setup.bin file. The latter includes -- 2.43.0.rc2.451.g8631bc7472-goog
[PATCH 01/13] x86: zboot: Move zimage definitions to the header file
In preparation for splitting the zboot-command code into a separate
file, move the definitions into the header file.
While we are here, mention when load_address and base_ptr are set up
and explain bzimage_addr better. Make cmdline const since it cannot be
changed.
Signed-off-by: Simon Glass
---
arch/x86/include/asm/zimage.h | 41 +++
arch/x86/lib/zimage.c | 36 +-
2 files changed, 42 insertions(+), 35 deletions(-)
diff --git a/arch/x86/include/asm/zimage.h b/arch/x86/include/asm/zimage.h
index 655675b66614..a91cfb2b8dd0 100644
--- a/arch/x86/include/asm/zimage.h
+++ b/arch/x86/include/asm/zimage.h
@@ -30,6 +30,47 @@
#define BZIMAGE_LOAD_ADDR 0x10
#define ZIMAGE_LOAD_ADDR 0x1
+enum {
+ ZBOOT_STATE_START = BIT(0),
+ ZBOOT_STATE_LOAD= BIT(1),
+ ZBOOT_STATE_SETUP = BIT(2),
+ ZBOOT_STATE_INFO= BIT(3),
+ ZBOOT_STATE_GO = BIT(4),
+
+ /* This one doesn't execute automatically, so stop the count before 5 */
+ ZBOOT_STATE_DUMP= BIT(5),
+ ZBOOT_STATE_COUNT = 5,
+};
+
+/**
+ * struct zboot_state - Current state of the boot
+ *
+ * @bzimage_addr: Address of the bzImage to boot, or 0 if the image has already
+ * been loaded and does not exist (as a cohesive whole) in memory
+ * @bzimage_size: Size of the bzImage, or 0 to detect this
+ * @initrd_addr: Address of the initial ramdisk, or 0 if none
+ * @initrd_size: Size of the initial ramdisk, or 0 if none
+ * @load_address: Address where the bzImage is moved before booting, either
+ * BZIMAGE_LOAD_ADDR or ZIMAGE_LOAD_ADDR
+ * This is set up when loading the zimage
+ * @base_ptr: Pointer to the boot parameters, typically at address
+ * DEFAULT_SETUP_BASE
+ * This is set up when loading the zimage
+ * @cmdline: Environment variable containing the 'override' command line, or
+ * NULL to use the one in the setup block
+ */
+struct zboot_state {
+ ulong bzimage_addr;
+ ulong bzimage_size;
+ ulong initrd_addr;
+ ulong initrd_size;
+ ulong load_address;
+ struct boot_params *base_ptr;
+ const char *cmdline;
+};
+
+extern struct zboot_state state;
+
/**
* load_zimage() - Load a zImage or bzImage
*
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index a41e1ccf8a65..b04d39b36dd4 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -56,41 +56,7 @@ DECLARE_GLOBAL_DATA_PTR;
#define COMMAND_LINE_SIZE 2048
-/**
- * struct zboot_state - Current state of the boot
- *
- * @bzimage_addr: Address of the bzImage to boot
- * @bzimage_size: Size of the bzImage, or 0 to detect this
- * @initrd_addr: Address of the initial ramdisk, or 0 if none
- * @initrd_size: Size of the initial ramdisk, or 0 if none
- * @load_address: Address where the bzImage is moved before booting, either
- * BZIMAGE_LOAD_ADDR or ZIMAGE_LOAD_ADDR
- * @base_ptr: Pointer to the boot parameters, typically at address
- * DEFAULT_SETUP_BASE
- * @cmdline: Environment variable containing the 'override' command line, or
- * NULL to use the one in the setup block
- */
-struct zboot_state {
- ulong bzimage_addr;
- ulong bzimage_size;
- ulong initrd_addr;
- ulong initrd_size;
- ulong load_address;
- struct boot_params *base_ptr;
- char *cmdline;
-} state;
-
-enum {
- ZBOOT_STATE_START = BIT(0),
- ZBOOT_STATE_LOAD= BIT(1),
- ZBOOT_STATE_SETUP = BIT(2),
- ZBOOT_STATE_INFO= BIT(3),
- ZBOOT_STATE_GO = BIT(4),
-
- /* This one doesn't execute automatically, so stop the count before 5 */
- ZBOOT_STATE_DUMP= BIT(5),
- ZBOOT_STATE_COUNT = 5,
-};
+struct zboot_state state;
static void build_command_line(char *command_line, int auto_boot)
{
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 00/13] Complete decoupling of zboot logic from commands
This series refactors the zboot code to allow it to be used with CONFIG_COMMAND disabled. A new zboot_run() function is used to boot a zimage. This is cmde (part e of CMDLINE refactoring) It depends on dm/cmdd-working which depends on dm/bootstda-working which depends on dm/cmdc-working Simon Glass (13): x86: zboot: Move zimage definitions to the header file x86: zboot: Move command code into its own file x86: zboot: Create a separate ZBOOT option for zboot logic x86: zboot: Avoid iteration in do_zboot_states() x86: zboot: Create separate functions for the logic x86: zboot: Move environment setting into zboot_load() x86: zboot: Drop intermediate zboot_setup() function x86: zboot: Drop intermediate zboot_go() function x86: zboot: Move argument processing outside zboot_start() x86: zboot: Rename zboot_start() to zboot_run() x86: zboot: Separate logic functions from commands x86: zboot: Use zboot_start() in zboot_run() x86: zboot: Tidy up the comment for zboot_run() arch/Kconfig | 1 - arch/x86/Kconfig | 8 + arch/x86/include/asm/zimage.h | 97 arch/x86/lib/Makefile | 2 +- arch/x86/lib/zimage.c | 267 -- boot/bootmeth_cros.c | 6 +- cmd/Kconfig | 2 + cmd/x86/Makefile | 1 + cmd/x86/zboot.c | 182 +++ include/bootm.h | 15 +- 10 files changed, 333 insertions(+), 248 deletions(-) create mode 100644 cmd/x86/zboot.c -- 2.43.0.rc2.451.g8631bc7472-goog
[PATCH 18/18] bootm: Create a function to run through the booti states
In a few places, the booti command is used to handle a boot. We want
these to be done without needing CONFIG_CMDLINE, so add a new
booti_run() function to handle this.
So far this is not used.
Signed-off-by: Simon Glass
---
boot/bootm.c| 13 +
include/bootm.h | 13 +
2 files changed, 26 insertions(+)
diff --git a/boot/bootm.c b/boot/bootm.c
index 22c6d1604176..f630b8c1a9c3 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -1155,6 +1155,19 @@ int bootz_run(struct bootm_info *bmi)
return bootm_run_states(bmi, states);
}
+int booti_run(struct bootm_info *bmi)
+{
+ int states;
+
+ bmi->cmd_name = "booti";
+ states = BOOTM_STATE_MEASURE | BOOTM_STATE_OS_PREP |
+ BOOTM_STATE_OS_FAKE_GO | BOOTM_STATE_OS_GO;
+ if (IS_ENABLED(CONFIG_SYS_BOOT_RAMDISK_HIGH))
+ states |= BOOTM_STATE_RAMDISK;
+
+ return bootm_run_states(bmi, states);
+}
+
int bootm_boot_start(ulong addr, const char *cmdline)
{
char addr_str[30];
diff --git a/include/bootm.h b/include/bootm.h
index d7c9486553e4..ce5298e4ed97 100644
--- a/include/bootm.h
+++ b/include/bootm.h
@@ -163,6 +163,19 @@ int bootm_run(struct bootm_info *bmi);
*/
int bootz_run(struct bootm_info *bmi);
+/**
+ * booti_run() - Run the entire booti process
+ *
+ * This runs through the booti process from start to finish, using the default
+ * set of states.
+ *
+ * This uses bootm_run_states().
+ *
+ * @bmi: bootm information
+ * Return: 0 if ok, something else on error
+ */
+int booti_run(struct bootm_info *bmi);
+
void arch_preboot_os(void);
/*
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 17/18] stm32: Use bootm_run() and bootz_run()
Use the new bootm/z_run() functions to avoid having to create an
argument list for the stm32prog code.
Signed-off-by: Simon Glass
---
.../cmd_stm32prog/cmd_stm32prog.c | 22 +++
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
index 8670535844d3..5e1dc7a03810 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
#include
@@ -125,12 +126,10 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag,
int argc,
char dtb_addr[20];
char initrd_addr[40];
char *fdt_arg, *initrd_arg;
- char *bootm_argv[5] = {
- "bootm", boot_addr_start,
- };
const void *uimage = (void *)data->uimage;
const void *dtb = (void *)data->dtb;
const void *initrd = (void *)data->initrd;
+ struct bootm_info bmi;
fdt_arg = dtb_addr;
if (!dtb)
@@ -141,7 +140,7 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag,
int argc,
snprintf(boot_addr_start, sizeof(boot_addr_start) - 1,
"0x%p", uimage);
- initrd_arg = "-";
+ initrd_arg = NULL;
if (initrd) {
snprintf(initrd_addr, sizeof(initrd_addr) - 1,
"0x%p:0x%zx", initrd, data->initrd_size);
@@ -149,15 +148,20 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag,
int argc,
}
printf("Booting kernel at %s %s %s...\n\n\n", boot_addr_start,
- initrd_arg, fdt_arg);
- bootm_argv[2] = initrd_arg;
- bootm_argv[3] = fdt_arg;
+ initrd_arg ?: "-", fdt_arg);
+
+ memset(, '\0', sizeof(bmi));
+ bmi.addr_fit = boot_addr_start;
+ bmi.conf_ramdisk = initrd_arg;
+ bmi.conf_fdt = fdt_arg;
+ bmi.boot_progress = true;
+ bmi.images =
/* Try bootm for legacy and FIT format image */
if (genimg_get_format(uimage) != IMAGE_FORMAT_INVALID)
- do_bootm(cmdtp, 0, 4, bootm_argv);
+ bootm_run();
else if (IS_ENABLED(CONFIG_CMD_BOOTZ))
- do_bootz(cmdtp, 0, 4, bootm_argv);
+ bootz_run();
}
if (data->script)
cmd_source_script(data->script, NULL, NULL);
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 16/18] bootm: Create a function to run through the bootz states
In a few places, the bootz command is used to handle a boot. We want
these to be done without needing CONFIG_CMDLINE, so add a new
bootz_run() function to handle this.
Signed-off-by: Simon Glass
---
boot/bootm.c| 13 +
cmd/bootz.c | 9 ++---
include/bootm.h | 13 +
3 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/boot/bootm.c b/boot/bootm.c
index 301ba480677d..22c6d1604176 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -1142,6 +1142,19 @@ int bootm_run(struct bootm_info *bmi)
return bootm_run_states(bmi, states);
}
+int bootz_run(struct bootm_info *bmi)
+{
+ int states;
+
+ bmi->cmd_name = "bootz";
+ states = BOOTM_STATE_MEASURE | BOOTM_STATE_OS_PREP |
+ BOOTM_STATE_OS_FAKE_GO | BOOTM_STATE_OS_GO;
+ if (IS_ENABLED(CONFIG_SYS_BOOT_RAMDISK_HIGH))
+ states |= BOOTM_STATE_RAMDISK;
+
+ return bootm_run_states(bmi, states);
+}
+
int bootm_boot_start(ulong addr, const char *cmdline)
{
char addr_str[30];
diff --git a/cmd/bootz.c b/cmd/bootz.c
index fa6743a71170..f03062f1cf75 100644
--- a/cmd/bootz.c
+++ b/cmd/bootz.c
@@ -75,7 +75,7 @@ static int bootz_start(struct cmd_tbl *cmdtp, int flag, int
argc,
int do_bootz(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
{
struct bootm_info bmi;
- int states, ret;
+ int ret;
/* Consume 'bootz' */
argc--; argv++;
@@ -102,12 +102,7 @@ int do_bootz(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
bmi.images =
bmi.cmd_name = "bootz";
- states = BOOTM_STATE_MEASURE | BOOTM_STATE_OS_PREP |
- BOOTM_STATE_OS_FAKE_GO | BOOTM_STATE_OS_GO;
- if (IS_ENABLED(CONFIG_SYS_BOOT_RAMDISK_HIGH))
- states |= BOOTM_STATE_RAMDISK;
-
- ret = bootm_run_states(, states);
+ ret = bootz_run();
return ret;
}
diff --git a/include/bootm.h b/include/bootm.h
index ef46c085b594..d7c9486553e4 100644
--- a/include/bootm.h
+++ b/include/bootm.h
@@ -150,6 +150,19 @@ int bootm_run_states(struct bootm_info *bmi, int states);
*/
int bootm_run(struct bootm_info *bmi);
+/**
+ * bootz_run() - Run the entire bootz process
+ *
+ * This runs through the bootz process from start to finish, using the default
+ * set of states.
+ *
+ * This uses bootm_run_states().
+ *
+ * @bmi: bootm information
+ * Return: 0 if ok, something else on error
+ */
+int bootz_run(struct bootm_info *bmi);
+
void arch_preboot_os(void);
/*
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 15/18] stm32: Use local vars in stm32prog for initrd and fdt
Rather than assigning to the bootm_argv[] array multiple times, use
local variables for the two things that can change and assign them at
the end.
This makes it easier to drop the array eventually.
Tidu up an overly short line while we are here.
Signed-off-by: Simon Glass
---
.../cmd_stm32prog/cmd_stm32prog.c | 23 +++
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
index 2411bcf06d8f..8670535844d3 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
@@ -124,30 +124,35 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag,
int argc,
char boot_addr_start[20];
char dtb_addr[20];
char initrd_addr[40];
+ char *fdt_arg, *initrd_arg;
char *bootm_argv[5] = {
- "bootm", boot_addr_start, "-", dtb_addr, NULL
+ "bootm", boot_addr_start,
};
const void *uimage = (void *)data->uimage;
const void *dtb = (void *)data->dtb;
const void *initrd = (void *)data->initrd;
+ fdt_arg = dtb_addr;
if (!dtb)
- bootm_argv[3] = env_get("fdtcontroladdr");
+ fdt_arg = env_get("fdtcontroladdr");
else
- snprintf(dtb_addr, sizeof(dtb_addr) - 1,
-"0x%p", dtb);
+ snprintf(dtb_addr, sizeof(dtb_addr) - 1, "0x%p", dtb);
snprintf(boot_addr_start, sizeof(boot_addr_start) - 1,
"0x%p", uimage);
+ initrd_arg = "-";
if (initrd) {
- snprintf(initrd_addr, sizeof(initrd_addr) - 1,
"0x%p:0x%zx",
-initrd, data->initrd_size);
- bootm_argv[2] = initrd_addr;
+ snprintf(initrd_addr, sizeof(initrd_addr) - 1,
+"0x%p:0x%zx", initrd, data->initrd_size);
+ initrd_arg = initrd_addr;
}
- printf("Booting kernel at %s %s %s...\n\n\n",
- boot_addr_start, bootm_argv[2], bootm_argv[3]);
+ printf("Booting kernel at %s %s %s...\n\n\n", boot_addr_start,
+ initrd_arg, fdt_arg);
+ bootm_argv[2] = initrd_arg;
+ bootm_argv[3] = fdt_arg;
+
/* Try bootm for legacy and FIT format image */
if (genimg_get_format(uimage) != IMAGE_FORMAT_INVALID)
do_bootm(cmdtp, 0, 4, bootm_argv);
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 14/18] bootm: Create a function to run through the bootm states
In quite a few places, the bootm command is used to handle a boot. We
want these to be done without needing CONFIG_CMDLINE, so add a new
bootm_run() function to handle this.
Signed-off-by: Simon Glass
---
boot/bootm.c| 19 +++
cmd/bootm.c | 14 +-
include/bootm.h | 13 +
3 files changed, 33 insertions(+), 13 deletions(-)
diff --git a/boot/bootm.c b/boot/bootm.c
index 1f46bb88b38e..301ba480677d 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -1123,6 +1123,25 @@ err:
return ret;
}
+int bootm_run(struct bootm_info *bmi)
+{
+ int states;
+
+ bmi->cmd_name = "bootm";
+ states = BOOTM_STATE_START | BOOTM_STATE_FINDOS | BOOTM_STATE_PRE_LOAD |
+ BOOTM_STATE_FINDOTHER | BOOTM_STATE_LOADOS |
+ BOOTM_STATE_OS_PREP | BOOTM_STATE_OS_FAKE_GO |
+ BOOTM_STATE_OS_GO;
+ if (IS_ENABLED(CONFIG_SYS_BOOT_RAMDISK_HIGH))
+ states |= BOOTM_STATE_RAMDISK;
+ if (IS_ENABLED(CONFIG_MEASURED_BOOT))
+ states |= BOOTM_STATE_MEASURE;
+ if (IS_ENABLED(CONFIG_PPC) || IS_ENABLED(CONFIG_MIPS))
+ states |= BOOTM_STATE_OS_CMDLINE;
+
+ return bootm_run_states(bmi, states);
+}
+
int bootm_boot_start(ulong addr, const char *cmdline)
{
char addr_str[30];
diff --git a/cmd/bootm.c b/cmd/bootm.c
index 68fb48f77a90..744a84d6c394 100644
--- a/cmd/bootm.c
+++ b/cmd/bootm.c
@@ -132,7 +132,6 @@ static int do_bootm_subcommand(struct cmd_tbl *cmdtp, int
flag, int argc,
int do_bootm(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
{
struct bootm_info bmi;
- int states;
int ret;
/* determine if we have a sub command */
@@ -153,17 +152,6 @@ int do_bootm(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
return do_bootm_subcommand(cmdtp, flag, argc, argv);
}
- states = BOOTM_STATE_START | BOOTM_STATE_FINDOS | BOOTM_STATE_PRE_LOAD |
- BOOTM_STATE_FINDOTHER | BOOTM_STATE_LOADOS |
- BOOTM_STATE_OS_PREP | BOOTM_STATE_OS_FAKE_GO |
- BOOTM_STATE_OS_GO;
- if (IS_ENABLED(CONFIG_SYS_BOOT_RAMDISK_HIGH))
- states |= BOOTM_STATE_RAMDISK;
- if (IS_ENABLED(CONFIG_MEASURED_BOOT))
- states |= BOOTM_STATE_MEASURE;
- if (IS_ENABLED(CONFIG_PPC) || IS_ENABLED(CONFIG_MIPS))
- states |= BOOTM_STATE_OS_CMDLINE;
-
memset(, '\0', sizeof(struct bootm_info));
if (argc)
bmi.addr_fit = argv[0];
@@ -173,7 +161,7 @@ int do_bootm(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
bmi.conf_fdt = argv[2];
bmi.boot_progress = true;
bmi.images =
- ret = bootm_run_states(, states);
+ ret = bootm_run();
return ret ? CMD_RET_FAILURE : 0;
}
diff --git a/include/bootm.h b/include/bootm.h
index a3bef1ab88f2..ef46c085b594 100644
--- a/include/bootm.h
+++ b/include/bootm.h
@@ -137,6 +137,19 @@ int bootm_measure(struct bootm_headers *images);
*/
int bootm_run_states(struct bootm_info *bmi, int states);
+/**
+ * bootm_run() - Run the entire bootm process
+ *
+ * This runs through the bootm process from start to finish, using the default
+ * set of states.
+ *
+ * This uses bootm_run_states().
+ *
+ * @bmi: bootm information
+ * Return: 0 if ok, something else on error
+ */
+int bootm_run(struct bootm_info *bmi);
+
void arch_preboot_os(void);
/*
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 13/18] bootm: Drop arguments from do_bootm_states() and rename
Create a new struct which holds the information required by bootm. Set
this up for each existing caller.
Now that none of the functions called from do_bootm_states() need an
argv[] list, change the arguments of do_bootm_states() as well.
For booti make sure it only uses argv[] and argc at the top of the
function, so we can eventually refactor to remove these parameters.
Finally, rename the function to bootm_run_states() to better indicate
its purpose. The 'do_' prefix is used to indicate a command processor,
which this is now not.
Signed-off-by: Simon Glass
---
arch/mips/lib/bootm.c | 2 +-
boot/bootm.c | 60 ---
cmd/booti.c | 55 ++-
cmd/bootm.c | 26 +--
cmd/bootz.c | 45 +++-
include/bootm.h | 57 +---
6 files changed, 160 insertions(+), 85 deletions(-)
diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
index 05dbe6131728..339a875bdf20 100644
--- a/arch/mips/lib/bootm.c
+++ b/arch/mips/lib/bootm.c
@@ -216,7 +216,7 @@ static int boot_reloc_fdt(struct bootm_headers *images)
{
/*
* In case of legacy uImage's, relocation of FDT is already done
-* by do_bootm_states() and should not repeated in 'bootm prep'.
+* by bootm_run_states() and should not repeated in 'bootm prep'.
*/
if (images->state & BOOTM_STATE_FDT) {
debug("## FDT already relocated\n");
diff --git a/boot/bootm.c b/boot/bootm.c
index de5c32099ceb..1f46bb88b38e 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -989,35 +989,9 @@ unmap_image:
return ret;
}
-/**
- * Execute selected states of the bootm command.
- *
- * Note the arguments to this state must be the first argument, Any 'bootm'
- * or sub-command arguments must have already been taken.
- *
- * Note that if states contains more than one flag it MUST contain
- * BOOTM_STATE_START, since this handles and consumes the command line args.
- *
- * Also note that aside from boot_os_fn functions and bootm_load_os no other
- * functions we store the return value of in 'ret' may use a negative return
- * value, without special handling.
- *
- * @param cmdtpPointer to bootm command table entry
- * @param flag Command flags (CMD_FLAG_...)
- * @param argc Number of subcommand arguments (0 = no arguments)
- * @param argv Arguments
- * @param states Mask containing states to run (BOOTM_STATE_...)
- * @param images Image header information
- * @param boot_progress 1 to show boot progress, 0 to not do this
- * Return: 0 if ok, something else on error. Some errors will cause this
- * function to perform a reboot! If states contains BOOTM_STATE_OS_GO
- * then the intent is to boot an OS, so this function will not return
- * unless the image type is standalone.
- */
-int do_bootm_states(struct cmd_tbl *cmdtp, int flag, int argc,
- char *const argv[], int states, struct bootm_headers
*images,
- int boot_progress)
+int bootm_run_states(struct bootm_info *bmi, int states)
{
+ struct bootm_headers *images = bmi->images;
boot_os_fn *boot_fn;
ulong iflag = 0;
int ret = 0, need_boot_fn;
@@ -1032,17 +1006,18 @@ int do_bootm_states(struct cmd_tbl *cmdtp, int flag,
int argc,
ret = bootm_start();
if (!ret && (states & BOOTM_STATE_PRE_LOAD))
- ret = bootm_pre_load(argv[0]);
+ ret = bootm_pre_load(bmi->addr_fit);
if (!ret && (states & BOOTM_STATE_FINDOS))
- ret = bootm_find_os(cmdtp->name, argv[0]);
+ ret = bootm_find_os(bmi->cmd_name, bmi->addr_fit);
if (!ret && (states & BOOTM_STATE_FINDOTHER)) {
ulong img_addr;
- img_addr = argc ? hextoul(argv[0], NULL) : image_load_addr;
- ret = bootm_find_other(img_addr, cmd_arg1(argc, argv),
- cmd_arg2(argc, argv));
+ img_addr = bmi->addr_fit ? hextoul(bmi->addr_fit, NULL)
+ : image_load_addr;
+ ret = bootm_find_other(img_addr, bmi->conf_ramdisk,
+ bmi->conf_fdt);
}
if (IS_ENABLED(CONFIG_MEASURED_BOOT) && !ret &&
@@ -1119,7 +1094,7 @@ int do_bootm_states(struct cmd_tbl *cmdtp, int flag, int
argc,
ret = boot_selected_os(BOOTM_STATE_OS_FAKE_GO, images, boot_fn);
if (!ret && cmd_list)
- ret = run_command_list(cmd_list, -1, flag);
+ ret = run_command_list(cmd_list, -1, 0);
}
#endif
@@ -1150,19 +1125,11 @@ err:
int bootm_boot_start(ulong addr, const char *cmdline)
{
- static struct cmd_tbl cmd = {"bootm"};
char addr_str[30];
- char *argv[] = {addr_str, NULL};
+
[PATCH 12/18] bootm: Adjust how the board is reset
Use reset_cpu() to reset the board, copying the logic from the 'reset'
command. This makes more sense than directly calling the do_reset()
function with the arguments passsed to the bootm command.
Signed-off-by: Simon Glass
---
boot/bootm.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/boot/bootm.c b/boot/bootm.c
index d2448f6306dc..de5c32099ceb 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -1138,10 +1138,12 @@ err:
if (iflag)
enable_interrupts();
- if (ret == BOOTM_ERR_UNIMPLEMENTED)
+ if (ret == BOOTM_ERR_UNIMPLEMENTED) {
bootstage_error(BOOTSTAGE_ID_DECOMP_UNIMPL);
- else if (ret == BOOTM_ERR_RESET)
- do_reset(cmdtp, flag, argc, argv);
+ } else if (ret == BOOTM_ERR_RESET) {
+ printf("Resetting the board...\n");
+ reset_cpu();
+ }
return ret;
}
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 11/18] riscv: Add a reset_cpu() function
The current do_reset() is called from a command context. Add a function
which can be used from anywhere, as is done on ARM. Adjust do_reset()
to call it.
Note that reset_cpu() is normally provided by SYSRESET so make this
declaration conditional on that being disabled.
Signed-off-by: Simon Glass
---
arch/riscv/cpu/cpu.c | 13 +
arch/riscv/lib/reset.c | 7 ++-
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index ebd39cb41a60..8445c5823e17 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -3,10 +3,13 @@
* Copyright (C) 2018, Bin Meng
*/
+#include
#include
+#include
#include
#include
#include
+#include
#include
#include
#include
@@ -162,3 +165,13 @@ int arch_early_init_r(void)
__weak void harts_early_init(void)
{
}
+
+#if !CONFIG_IS_ENABLED(SYSRESET)
+void reset_cpu(void)
+{
+ printf("resetting ...\n");
+
+ printf("reset not supported yet\n");
+ hang();
+}
+#endif
diff --git a/arch/riscv/lib/reset.c b/arch/riscv/lib/reset.c
index 712e1bdb8e1d..c4153c9e6e02 100644
--- a/arch/riscv/lib/reset.c
+++ b/arch/riscv/lib/reset.c
@@ -4,14 +4,11 @@
*/
#include
-#include
+#include
int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
{
- printf("resetting ...\n");
-
- printf("reset not supported yet\n");
- hang();
+ reset_cpu();
return 0;
}
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 10/18] nios2: Add a reset_cpu() function
The current do_reset() is called from a command context. Add a function
which can be used from anywhere, as is done on ARM.
Signed-off-by: Simon Glass
---
arch/nios2/cpu/cpu.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/nios2/cpu/cpu.c b/arch/nios2/cpu/cpu.c
index 79a54d1bc259..de7bfa947f11 100644
--- a/arch/nios2/cpu/cpu.c
+++ b/arch/nios2/cpu/cpu.c
@@ -35,11 +35,17 @@ int checkboard(void)
}
#endif
-int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
+void reset_cpu(void)
{
disable_interrupts();
/* indirect call to go beyond 256MB limitation of toolchain */
nios2_callr(gd->arch.reset_addr);
+}
+
+int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
+{
+ reset_cpu();
+
return 0;
}
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 09/18] ppc: Add a reset_cpu() function
The current do_reset() is called from a command context. Add a function
which can be used from anywhere, as is done on ARM.
This is only needed if CONFIG_SYSRESET is disabled.
Since there are lots of reset functions, this one actually just calls
do_reset(). Future refactoring could correct this.
Signed-off-by: Simon Glass
---
arch/powerpc/lib/traps.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/powerpc/lib/traps.c b/arch/powerpc/lib/traps.c
index c7bce82a44b3..cf8da2e5df0d 100644
--- a/arch/powerpc/lib/traps.c
+++ b/arch/powerpc/lib/traps.c
@@ -4,6 +4,8 @@
* Wolfgang Denk, DENX Software Engineering, w...@denx.de.
*/
+#include
+#include
#include
#include
@@ -17,3 +19,11 @@ int arch_initr_trap(void)
return 0;
}
+
+#ifndef CONFIG_SYSRESET
+void reset_cpu(void)
+{
+ /* TODO: Refactor all the do_reset calls to be reset_cpu() instead */
+ do_reset(NULL, 0, 0, NULL);
+}
+#endif
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 08/18] m68k: Add a reset_cpu() function
The current do_reset() is called from a command context. Add a function
which can be used from anywhere, as is done on ARM.
Since there are lots of reset functions, this one actually just calls
do_reset(). Future refactoring could correct this.
Signed-off-by: Simon Glass
---
arch/m68k/lib/traps.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/m68k/lib/traps.c b/arch/m68k/lib/traps.c
index c283351181d8..ae8ae6ccf592 100644
--- a/arch/m68k/lib/traps.c
+++ b/arch/m68k/lib/traps.c
@@ -7,6 +7,7 @@
* Wolfgang Denk, DENX Software Engineering, w...@denx.de.
*/
+#include
#include
#include
#include
@@ -65,3 +66,9 @@ int arch_initr_trap(void)
return 0;
}
+
+void reset_cpu(void)
+{
+ /* TODO: Refactor all the do_reset calls to be reset_cpu() instead */
+ do_reset(NULL, 0, 0, NULL);
+}
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 07/18] mips: Add a reset_cpu() function
The current do_reset() is called from a command context. Add a function
which can be used from anywhere, as is done on ARM.
Signed-off-by: Simon Glass
---
arch/mips/cpu/cpu.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/mips/cpu/cpu.c b/arch/mips/cpu/cpu.c
index acfc9dc43f17..443465047715 100644
--- a/arch/mips/cpu/cpu.c
+++ b/arch/mips/cpu/cpu.c
@@ -4,6 +4,7 @@
* Wolfgang Denk, DENX Software Engineering,
*/
+#include
#include
#include
#include
@@ -20,9 +21,14 @@ void __weak _machine_restart(void)
/* NOP */;
}
-int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
+void reset_cpu(void)
{
_machine_restart();
+}
+
+int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
+{
+ reset_cpu();
return 0;
}
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 06/18] bootm: Drop arguments from boot_selected_os()
The argc and argv parameters are not used now, so drop them.
Signed-off-by: Simon Glass
---
boot/bootm.c| 6 ++
boot/bootm_os.c | 4 ++--
include/bootm.h | 4 ++--
3 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/boot/bootm.c b/boot/bootm.c
index c343f313e80a..d2448f6306dc 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -1117,8 +1117,7 @@ int do_bootm_states(struct cmd_tbl *cmdtp, int flag, int
argc,
if (!ret && (states & BOOTM_STATE_OS_FAKE_GO)) {
char *cmd_list = env_get("fakegocmd");
- ret = boot_selected_os(argc, argv, BOOTM_STATE_OS_FAKE_GO,
- images, boot_fn);
+ ret = boot_selected_os(BOOTM_STATE_OS_FAKE_GO, images, boot_fn);
if (!ret && cmd_list)
ret = run_command_list(cmd_list, -1, flag);
}
@@ -1132,8 +1131,7 @@ int do_bootm_states(struct cmd_tbl *cmdtp, int flag, int
argc,
/* Now run the OS! We hope this doesn't return */
if (!ret && (states & BOOTM_STATE_OS_GO))
- ret = boot_selected_os(argc, argv, BOOTM_STATE_OS_GO,
- images, boot_fn);
+ ret = boot_selected_os(BOOTM_STATE_OS_GO, images, boot_fn);
/* Deal with any fallout */
err:
diff --git a/boot/bootm_os.c b/boot/bootm_os.c
index df1aab4b3e4d..22ff62e5fb65 100644
--- a/boot/bootm_os.c
+++ b/boot/bootm_os.c
@@ -527,8 +527,8 @@ __weak void board_preboot_os(void)
/* please define board specific board_preboot_os() */
}
-int boot_selected_os(int argc, char *const argv[], int state,
-struct bootm_headers *images, boot_os_fn *boot_fn)
+int boot_selected_os(int state, struct bootm_headers *images,
+boot_os_fn *boot_fn)
{
arch_preboot_os();
board_preboot_os();
diff --git a/include/bootm.h b/include/bootm.h
index 0e4662485006..b8d74d03a8c4 100644
--- a/include/bootm.h
+++ b/include/bootm.h
@@ -42,8 +42,8 @@ boot_os_fn *bootm_os_get_boot_func(int os);
int bootm_host_load_images(const void *fit, int cfg_noffset);
#endif
-int boot_selected_os(int argc, char *const argv[], int state,
-struct bootm_headers *images, boot_os_fn *boot_fn);
+int boot_selected_os(int argc, struct bootm_headers *images,
+boot_os_fn *boot_fn);
ulong bootm_disable_interrupts(void);
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 05/18] treewide: bootm: Drop command-line args to boot_os_fn
These arguments are not used now. They cannot be provided when there is
no bootm command invoked to provide arguments. Drop the argc and argv
parameters.
Signed-off-by: Simon Glass
---
arch/arc/lib/bootm.c| 2 +-
arch/arm/lib/bootm.c| 3 +--
arch/m68k/lib/bootm.c | 3 +--
arch/microblaze/lib/bootm.c | 3 +--
arch/mips/lib/bootm.c | 3 +--
arch/nios2/lib/bootm.c | 3 +--
arch/powerpc/lib/bootm.c| 3 +--
arch/riscv/lib/bootm.c | 5 ++--
arch/sandbox/lib/bootm.c| 2 +-
arch/sh/lib/bootm.c | 3 +--
arch/x86/lib/bootm.c| 3 +--
arch/xtensa/lib/bootm.c | 2 +-
boot/bootm.c| 6 ++---
boot/bootm_os.c | 46 ++---
include/bootm.h | 7 +-
15 files changed, 34 insertions(+), 60 deletions(-)
diff --git a/arch/arc/lib/bootm.c b/arch/arc/lib/bootm.c
index 44ec5864a1c6..0ae7a21b24b6 100644
--- a/arch/arc/lib/bootm.c
+++ b/arch/arc/lib/bootm.c
@@ -78,7 +78,7 @@ static void boot_jump_linux(struct bootm_headers *images, int
flag)
board_jump_and_run(kernel_entry, r0, 0, r2);
}
-int do_bootm_linux(int flag, int argc, char *argv[], struct bootm_headers
*images)
+int do_bootm_linux(int flag, struct bootm_headers *images)
{
/* No need for those on ARC */
if ((flag & BOOTM_STATE_OS_BD_T) || (flag & BOOTM_STATE_OS_CMDLINE))
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index c56285738a26..ebaac029e094 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -378,8 +378,7 @@ static void boot_jump_linux(struct bootm_headers *images,
int flag)
* DIFFERENCE: Instead of calling prep and go at the end
* they are called if subcommand is equal 0.
*/
-int do_bootm_linux(int flag, int argc, char *const argv[],
- struct bootm_headers *images)
+int do_bootm_linux(int flag, struct bootm_headers *images)
{
/* No need for those on ARM */
if (flag & BOOTM_STATE_OS_BD_T || flag & BOOTM_STATE_OS_CMDLINE)
diff --git a/arch/m68k/lib/bootm.c b/arch/m68k/lib/bootm.c
index 79d8b34c0d56..0720861ae9cc 100644
--- a/arch/m68k/lib/bootm.c
+++ b/arch/m68k/lib/bootm.c
@@ -34,8 +34,7 @@ void arch_lmb_reserve(struct lmb *lmb)
arch_lmb_reserve_generic(lmb, get_sp(), gd->ram_top, 1024);
}
-int do_bootm_linux(int flag, int argc, char *const argv[],
- struct bootm_headers *images)
+int do_bootm_linux(int flag, struct bootm_headers *images)
{
int ret;
struct bd_info *kbd;
diff --git a/arch/microblaze/lib/bootm.c b/arch/microblaze/lib/bootm.c
index f3ec4b741b88..93cdf62e18cf 100644
--- a/arch/microblaze/lib/bootm.c
+++ b/arch/microblaze/lib/bootm.c
@@ -81,8 +81,7 @@ static void boot_prep_linux(struct bootm_headers *images)
}
}
-int do_bootm_linux(int flag, int argc, char *const argv[],
- struct bootm_headers *images)
+int do_bootm_linux(int flag, struct bootm_headers *images)
{
images->cmdline_start = (ulong)env_get("bootargs");
diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
index d6d2f7d9d031..05dbe6131728 100644
--- a/arch/mips/lib/bootm.c
+++ b/arch/mips/lib/bootm.c
@@ -300,8 +300,7 @@ static void boot_jump_linux(struct bootm_headers *images)
linux_extra);
}
-int do_bootm_linux(int flag, int argc, char *const argv[],
- struct bootm_headers *images)
+int do_bootm_linux(int flag, struct bootm_headers *images)
{
/* No need for those on MIPS */
if (flag & BOOTM_STATE_OS_BD_T)
diff --git a/arch/nios2/lib/bootm.c b/arch/nios2/lib/bootm.c
index 823d524c9a2d..040a806bc75e 100644
--- a/arch/nios2/lib/bootm.c
+++ b/arch/nios2/lib/bootm.c
@@ -16,8 +16,7 @@ DECLARE_GLOBAL_DATA_PTR;
#define NIOS_MAGIC 0x534f494e /* enable command line and initrd passing */
-int do_bootm_linux(int flag, int argc, char *const argv[],
- struct bootm_headers *images)
+int do_bootm_linux(int flag, struct bootm_headers *images)
{
void (*kernel)(int, int, int, char *) = (void *)images->ep;
char *commandline = env_get("bootargs");
diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
index 910121ec9c85..4d248cb13b5f 100644
--- a/arch/powerpc/lib/bootm.c
+++ b/arch/powerpc/lib/bootm.c
@@ -223,8 +223,7 @@ static int boot_body_linux(struct bootm_headers *images)
return 0;
}
-noinline int do_bootm_linux(int flag, int argc, char *const argv[],
- struct bootm_headers *images)
+noinline int do_bootm_linux(int flag, struct bootm_headers *images)
{
int ret;
diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index f9e1e18ae026..d90f26091530 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -105,8 +105,7 @@ static void boot_jump_linux(struct bootm_headers *images,
int flag)
}
}
-int do_bootm_linux(int flag, int argc, char *const argv[],
- struct
[PATCH 04/18] nios2: Drop separate parsing of bootm args
This function is supposed to boot the OS. Parsing of the arguments is done in easier phases. The code to handle this is already here, behind an #ifdef on CONFIG_OF_LIBFDT so rely on that. Signed-off-by: Simon Glass --- arch/nios2/lib/bootm.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/nios2/lib/bootm.c b/arch/nios2/lib/bootm.c index 06c094d0f1c7..823d524c9a2d 100644 --- a/arch/nios2/lib/bootm.c +++ b/arch/nios2/lib/bootm.c @@ -29,8 +29,6 @@ int do_bootm_linux(int flag, int argc, char *const argv[], if (images->ft_len) of_flat_tree = images->ft_addr; #endif - if (!of_flat_tree && argc > 1) - of_flat_tree = (char *)hextoul(argv[1], NULL); if (of_flat_tree) initrd_end = (ulong)of_flat_tree; -- 2.43.0.rc2.451.g8631bc7472-goog
[PATCH 03/18] bootm: qnxelf: Drop passing of arguments
It isn't clear how useful it is to pass the arguments of bootm to the
OS. For example, if "bootm 1000 2000 3000" is used, the '1000' argument
is passed to QNX. This seems like a strange approach, since the argument
have already been parsed by U-Boot and processed.
Rely instead on the "bootargs" mechanism, which is the standard
approach.
Also make sure that the argument list is NULL-terminated.
Signed-off-by: Simon Glass
---
boot/bootm_os.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/boot/bootm_os.c b/boot/bootm_os.c
index 4aa1db848d6c..598671e576c6 100644
--- a/boot/bootm_os.c
+++ b/boot/bootm_os.c
@@ -333,7 +333,7 @@ int do_bootm_vxworks(int flag, int argc, char *const argv[],
static int do_bootm_qnxelf(int flag, int argc, char *const argv[],
struct bootm_headers *images)
{
- char *local_args[2];
+ char *local_args[3];
char str[16];
int dcache;
@@ -348,8 +348,9 @@ static int do_bootm_qnxelf(int flag, int argc, char *const
argv[],
#endif
sprintf(str, "%lx", images->ep); /* write entry-point into string */
- local_args[0] = argv[0];
- local_args[1] = str;/* and provide it via the arguments */
+ local_args[0] = "qnxelf";
+ local_args[1] = env_get("bootargs");
+ local_args[2] = NULL;
/*
* QNX images require the data cache is disabled.
@@ -358,7 +359,7 @@ static int do_bootm_qnxelf(int flag, int argc, char *const
argv[],
if (dcache)
dcache_disable();
- do_bootelf(NULL, 0, 2, local_args);
+ do_bootelf(NULL, 0, local_args[1] ? 2 : 1, local_args);
if (dcache)
dcache_enable();
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 02/18] bootm: plan: Drop passing of arguments
It isn't clear how useful it is to pass the arguments of bootm to the
OS. For example, if "bootm 1000 2000 3000" is used, the three arguments
at the end are passed to the OS. This seems like a strange approach,
since the argument have already been parsed by U-Boot and processed.
Rely instead on the "bootargs" mechanism, which is the standard
approach.
Drop the helper function as well.
Signed-off-by: Simon Glass
---
boot/bootm_os.c | 26 --
1 file changed, 4 insertions(+), 22 deletions(-)
diff --git a/boot/bootm_os.c b/boot/bootm_os.c
index b5055d78706c..4aa1db848d6c 100644
--- a/boot/bootm_os.c
+++ b/boot/bootm_os.c
@@ -41,20 +41,6 @@ static int do_bootm_standalone(int flag, int argc, char
*const argv[],
/* OS booting routines */
/***/
-#if defined(CONFIG_BOOTM_NETBSD) || defined(CONFIG_BOOTM_PLAN9)
-static void copy_args(char *dest, int argc, char *const argv[], char delim)
-{
- int i;
-
- for (i = 0; i < argc; i++) {
- if (i > 0)
- *dest++ = delim;
- strcpy(dest, argv[i]);
- dest += strlen(argv[i]);
- }
-}
-#endif
-
static void __maybe_unused fit_unsupported_reset(const char *msg)
{
if (CONFIG_IS_ENABLED(FIT_VERBOSE)) {
@@ -211,16 +197,12 @@ static int do_bootm_plan9(int flag, int argc, char *const
argv[],
/* See README.plan9 */
s = env_get("confaddr");
- if (s != NULL) {
+ if (s) {
char *confaddr = (char *)hextoul(s, NULL);
- if (argc > 0) {
- copy_args(confaddr, argc, argv, '\n');
- } else {
- s = env_get("bootargs");
- if (s != NULL)
- strcpy(confaddr, s);
- }
+ s = env_get("bootargs");
+ if (!s)
+ strcpy(confaddr, s);
}
entry_point = (void (*)(void))images->ep;
--
2.43.0.rc2.451.g8631bc7472-goog
[PATCH 01/18] bootm: netbds: Drop passing of arguments
It isn't clear how useful it is to pass the arguments of bootm to the
OS. For example, if "bootm 1000 2000 3000" is used, the three arguments
at the end are passed to the OS. This seems like a strange approach,
since the argument have already been parsed by U-Boot and processed.
Rely instead on the "bootargs" mechanism, which is the standard
approach.
Signed-off-by: Simon Glass
---
boot/bootm_os.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/boot/bootm_os.c b/boot/bootm_os.c
index b92422171a84..b5055d78706c 100644
--- a/boot/bootm_os.c
+++ b/boot/bootm_os.c
@@ -102,19 +102,9 @@ static int do_bootm_netbsd(int flag, int argc, char *const
argv[],
os_hdr = hdr;
}
- if (argc > 0) {
- ulong len;
- int i;
-
- for (i = 0, len = 0; i < argc; i += 1)
- len += strlen(argv[i]) + 1;
- cmdline = malloc(len);
- copy_args(cmdline, argc, argv, ' ');
- } else {
- cmdline = env_get("bootargs");
- if (cmdline == NULL)
- cmdline = "";
- }
+ cmdline = env_get("bootargs");
+ if (!cmdline)
+ cmdline = "";
loader = (void (*)(struct bd_info *, struct legacy_img_hdr *, char *,
char *))images->ep;
--
2.43.0.rc2.451.g8631bc7472-goog
rk3328 gmac does U-Boot erroneously not set RSF?
Hi all, I suspect U-Boot is not setting the RSF bit in GMAC_OP_MODE register. This can result in allowing to receive frames with bad CRC. I suspect the Linux driver may be similarly affected, but I have not checked it out. Unfortunately all my spare time is taken up by development on my own OS, so I do not have the time to investigate fully and/or provide a patch. I am just reporting this potential issue as a good Samaritan, but please understand that I am not willing to apply any patches or recompile U-Boot or conduct any tests or anything of that nature. Thanks all.
[PATCH] tools: mxsboot: pre-fill buffer with 0xff, not 0
The tool works for me, with imx28 and NAND memory, but the resulting
blocks are reported as bad, both by u-boot and the kernel.
This makes it impossible to erase from Linux (for an upgrade without
console access, for example -- u-boot can "nand scrub" but linux can't).
pre-filling with 0xff creates a proper boot loader image, but no
bad-block marker is there when written to flash.
Signed-off-by: Alessandro Rubini
---
tools/mxsboot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/mxsboot.c b/tools/mxsboot.c
index 04d86f87a8..8f4018aa56 100644
--- a/tools/mxsboot.c
+++ b/tools/mxsboot.c
@@ -478,7 +478,7 @@ static int mx28_create_nand_image(int infd, int outfd)
goto err0;
}
- memset(buf, 0, size);
+ memset(buf, 0xff, size);
fcb = mx28_nand_get_fcb(MAX_BOOTSTREAM_SIZE);
if (!fcb) {
--
2.30.2
Re: [PATCH 1/1] correct documentation for SPI flashing
On Fri, 1 Dec 2023 10:50:39 -0800 Stephen Graf wrote: Hi Stephen, thanks for the patch, and you almost nailed it, some little things: - The patch should start a new thread on the list, so do not reply to an existing discussion or (un)related patch. This avoids the patch getting buried in longish threads and helps tools like patchworks to find and process it. Also please just send the patch, and avoid any quoted text from previous discussions outside of the commit message. - Please prefix your commit message with some context tags, in this case "sunxi: ", so that people scanning the list can ignore it if it's outside their scope of interest. - Please limit commit messages to 75 characters per line. $ scripts/checkpatch.pl 0001-correct_documentation_for_SPI_flashing.patch will do some checks on the patch and would report this. Anyway, those are minor things, I will just fix them while committing. > The mtd_debug write does not work in this context. The flashcp command does > work, provides > both the erase and write functions and with the verbose option gives good > feedback. > > Signed-off-by: Stephen Graf Reviewed-by: Andre Przywara Cheers, Andre > --- > doc/board/allwinner/sunxi.rst | 3 +-- > 1 file changed, 1 insertions(+), 2 deletions(-) > > diff --git a/doc/board/allwinner/sunxi.rst b/doc/board/allwinner/sunxi.rst > index 797222d8d3..d0c89b956b 100644 > --- a/doc/board/allwinner/sunxi.rst > +++ b/doc/board/allwinner/sunxi.rst > @@ -251,8 +251,7 @@ the SPI flash content from Linux, using the `MTD utils`_:: > > # apt-get install mtd-utils > # mtdinfo > -# mtd_debug erase /dev/mtdX 0 0xf > -# mtd_debug write /dev/mtdX 0 0xf u-boot-sunxi-with-spl.bin > +# flashcp -v u-boot-sunxi-with-spl.bin /dev/mtdX > > ``/dev/mtdX`` needs to be replaced with the respective device name, as > listed > in the output of ``mtdinfo``. > --- > > On 2023-11-30 4:27 p.m., Andre Przywara wrote: > > Hi Stephen, > > > > On 30/11/2023 01:13, Stephen Graf wrote: > >> Is the attached patch file going in the right direction? > > > > yes, thanks, the change itself looks alright, but it needs to be: > > - in a separate email, with a descriptive subject, prefixed by [PATCH] > > - have the diff inline, not as an attachment (to allow easy commenting in > > an email thread) > > - have a Signed-off-by: tag with your name and email address. This is to > > signify that the change is an original one made by you and you are happy to > > submit this under the (GPL) license conditions. > > - an explanation *why* this change is required (mtd_debug write being not > > reliable, etc) > > - sent to the U-Boot list and the maintainer (me) > > > > Look at the U-Boot mailing list (archive) for examples. > > "git format-patch" creates everything in the right format (mbox), and "git > > send-email" will send this via an SMTP server you point it to. Or you > > import this into your client. > > > > If you could try this (with the Signed-off-by being the most important > > change), I am happy to submit this with the next push. > > > > Thanks, > > Andre > > > >> > >> On 2023-11-29 3:57 p.m., Andre Przywara wrote: > >>> Hi Stephen, > >>> > >>> On 28/11/2023 20:07, Stephen Graf wrote: > Below is the console log from trying to use mtd_debug write. It returned > immediately with a strange success message. > > root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf > /home/sysadmin/u-boot-sunxi-with-spl.bin > file_to_flash: fread, size 0xf, n 0xf > fread(): Success > >>> > >>> interesting, I was under the impression that "mtd_debug write" would be > >>> the way to write to flash. In hindsight, the "debug" in that name should > >>> have probably put me off. Anyway, "cat" is probably not a good choice, > >>> "dd" is better, but it looks like "flashcp" (also part of mtdutils) is > >>> the go-to tool, since it does the required erasing automatically and also > >>> reportedly does some error detection. Can you please test this? > >>> # flashcp u-boot-sunxi-with-spl.bin /dev/mtd0 > >>> I would test this on my end ASAP as well. > >>> > >>> Do you feel like sending a patch to the U-Boot documentation to get this > >>> changed then? > >>> > >>> Thanks, > >>> Andre > >>> >
Re: [PATCH] common: usb-hub: Reset hub port before scanning
On 12/3/23 22:42, Shantur Rathore wrote: Hi Marek, On Sun, Dec 3, 2023 at 8:42 PM Marek Vasut wrote: On 11/24/23 01:37, Shantur Rathore wrote: Hi Marek, Hi, sorry for the late reply. In my case RockPro64, the power to usb ports onboard is controlled by a regulator. This regulator is enabled as part of init as here https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/rk3399-rockpro64.dtsi#L177 On init, the usb devices connected to the port are powered up, in my case AM8180 (a RTL9210 based ) NVMe to USB enclosure with UAS. But the usb controller is only enabled at 'usb start' and by this time the device is in some state that it doesn't get detected. One way to make sure the devices connected to the ports are in an initialising state is by issuing a port reset before scanning the port. Why not remove this regulator-always-on and let the PHY driver turn the VBUS ON only when it is needed ? Wouldn't that solve the problem too AND remove unnecessarily enabled regulator ? [...] Removing the regulator-always-on does make it work but there are few issues 1. regulator is used to control power to multiple ports ( USB3.0 and USB2.0 in RockPro64 ), so this could lead to all ports turning off if a phy resets / turns off power I vaguely recall seeing some refcounting patch for regulator subsystem, would that help ? I don't think this would be a problem for u-boot, but linux maybe. How so ? Actually, I am wrong. I wasn't sure if there is refcounting for the regulator subsystem in linux. just found it has so this is null and void. 2. Even with regulator-always-on and without this reset port patch, linux was always able to detect the drive on the port, so there is something missing in u-boot. 3. Looking at usb hub code in Linux, I found that for USB3.0 it tries to reset the port before scanning. The comment says /* Is a USB 3.0 port in the Inactive or Compliance Mode state? * Port warm reset is required to recover */ i. https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L5736 ii. https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2836 I believe this isn't implemented in u-boot and hence explicit reset of a port fixes the issue. I feel this is separate issue and what needs to be fixed first is the hard-wired VBus control. I beg to differ on this, couple of reasons for this 1. The same drive works fine without being reset on the USB2.0 ports - this confirms that the issue is related to USB3.0 only. This is a separate issue from the hard-wired VBus control. I agree the issue does exist, I would simply like to avoid conflating the hard-wired VBus control with device reset. 2. Linux is able to detect the same drive on USB3.0 when u-boot fails - this confirms issue doesn't lie with regulator-always-on See above 3. The links I pasted earlier mentions that in USB3.0 the ports need reset and this is done before the port is scanned. Adding the similar reset in u-boot fixes all with the same regulator-always-on. AFAIK u-boot doesn't handle this special USB3.0 case and maybe this is why I was finding a few posts around the drive not being detected in the USB3.0 port in u-boot but works in a USB2.0 port. I am not disputing the need for USB 3.0 device reset, I believe there are two issues here -- one is the hard-wired VBus regulator -- the other is this USB 3.0 reset. They should both be fixed. Sure, agreed 100%. Do we need to fix both at the same time? Both patches seem to be independent. Separate patch for the regulator please .
Re: [PATCH v3 3/3] defconfig: rockpro64: Enable SF EFI var store
On 2023-12-03 22:49, Shantur Rathore wrote:
On Sun, Dec 3, 2023 at 5:44 PM Simon Glass wrote:
In fact, I wonder if we should add something like:
u-boot-env {
offset = ;
};
so the environment gets filled into the SPI flash when we write the
image?
Do we want to reset the environment to default on every u-boot update?
I believe this would overwrite the environment space isn't it.
Obviously, resetting the U-Boot environment on updates would be a really
bad idea, which may even render some boards unbootable.
I suppose we could also add the EFI variable store, although that
would require adding a new entry type to binman.
I am not sure about this but surely EFI vars can be moved to a location
just after the u-boot environment and increase the u-boot image size.
Would you still need an entry in dts?
Re: efi: Set Variable Runtime implementation
Hi Simon, On Sun, Dec 3, 2023 at 5:44 PM Simon Glass wrote: > > Hi Shantur, > > On Sat, 2 Dec 2023 at 16:03, Shantur Rathore wrote: > > > > Hi Simon, > > > > On Fri, Dec 1, 2023 at 6:44 PM Simon Glass wrote: > > > > > > Hi Shantur, > > > > > > On Mon, 27 Nov 2023 at 10:27, Shantur Rathore wrote: > > > > > > > > + Simon as he seems to have done a lot of work in the driver model. > > > > > > > > On Mon, Nov 27, 2023 at 10:12 AM Shantur Rathore > > > > wrote: > > > > > > > > > > Hi Ilias, > > > > > > > > > > On Mon, Nov 27, 2023 at 7:16 AM Ilias Apalodimas > > > > > wrote: > > > > > > > > > > > > Hi Shantur > > > > > > > > > > > > On Sun, 26 Nov 2023 at 12:33, Shantur Rathore > > > > > > wrote: > > > > > > > > > > > > > > Hi Peter, > > > > > > > > > > > > > > On Sat, Nov 25, 2023 at 6:19 AM Peter Robinson > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Shantur, > > > > > > > > > > > > > > > > On Fri, Nov 24, 2023 at 11:55 PM Shantur Rathore > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi Ilias, > > > > > > > > > > > > > > > > > > On Fri, Nov 24, 2023 at 10:50 PM Ilias Apalodimas > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Shantur > > > > > > > > > > > > > > > > > > > > On Fri, 24 Nov 2023 at 18:51, Shantur Rathore > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Heinrich, > > > > > > > > > > > > > > > > > > > > > > I am trying to work out how to enable the SetVariableRT > > > > > > > > > > > service in > > > > > > > > > > > U-Boot and came across your patch [1] which initially had > > > > > > > > > > > the > > > > > > > > > > > SetVariable RT service enabled in EFI but in the final > > > > > > > > > > > patch this was > > > > > > > > > > > removed. > > > > > > > > > > > I am hoping to implement it on top of the SPI Flash EFI > > > > > > > > > > > store [2] to > > > > > > > > > > > be able to set Boot order and boot items from Linux the > > > > > > > > > > > UEFI way. > > > > > > > > > > > > > > > > > > > > > > Can I pick your brain on why it was dropped in the patch? > > > > > > > > > > > Is there any limitation in SetVariableRT service ? > > > > > > > > > > > > > > > > > > > > I recently had a talk about it in Plumbers [0]. Generally > > > > > > > > > > speaking, RT > > > > > > > > > > + hardware owned by the kernel is a very weird combination > > > > > > > > > > since you > > > > > > > > > > can't guarantee exclusive access to the flash or the bus > > > > > > > > > > and you have > > > > > > > > > > to preserve a *lot* of code alive in u-boot. > > > > > > > > > > > > > > > > > > > > I'll respond to your v1 patchset and we can discuss details > > > > > > > > > > there as well. > > > > > > > > > > > > > > > > > > > > [0] https://lpc.events/event/17/contributions/1653/ > > > > > > > > > > > > > > > > > > Thanks for the background and helping me understand the > > > > > > > > > problem. > > > > > > > > > Makes me wonder how things work in the PC world. > > > > > > > > > U-boot being only ~1MB, can we not leave it all in memory and > > > > > > > > > maybe > > > > > > > > > just disable SPI access to Linux. > > > > > > > > > > > > That would work, but you cant guarantee Linux wont enable the SPI > > > > > > flash. > > > > > > > > > > > > > > > > > > > > > > That's basically it, on x86 there's specific HW that's owned by > > > > > > > > firmware, I don't know the exact low level details of how that > > > > > > > > works. > > > > > > > > > > > > > > > > I think x86 devices generally use eSPI for this HW [1] but I > > > > > > > > don't > > > > > > > > know the low level details. The Arm SBSA (Server HW spec) and > > > > > > > > SBBR > > > > > > > > (Server Base Boot Requirements) specs that are key to > > > > > > > > ServerReady may > > > > > > > > go into some details too if you're curious. > > > > > > > > > > > > On X86 the SPI flash is handled entirely by the firmware and SMM. > > > > > > You > > > > > > can find more details here [0] > > > > > > > > > > Thanks for more info. > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > I think the firmware is still accessible to PCs as one could > > > > > > > update the firmware > > > > > > > in Windows so Windows has access to that device. > > > > > > > > > > > > > > I had some try myself and found that setting a variable to memory > > > > > > > backed storage > > > > > > > is doable with SetVariable call but we want to store it in any > > > > > > > non-volatile storage > > > > > > > things really don't look good. > > > > > > > > > > > > > > To be able to write SetVariable to any device, the whole u-boot > > > > > > > driver > > > > > > > model would need > > > > > > > to be kept in memory, might as well just keep the whole u-boot in > > > > > > > memory at this point, it's anyway small. > > > > > > > I don't have much knowledge on how to or pros and cons of doing > > > > > > > this. > > > > > > > > > > > > The major problem here is who owns
Re: [PATCH v3 3/3] defconfig: rockpro64: Enable SF EFI var store
Hi Simon,
On Sun, Dec 3, 2023 at 5:44 PM Simon Glass wrote:
>
> Hi Shantur,
>
> On Sat, 2 Dec 2023 at 16:12, Shantur Rathore wrote:
> >
> > Hi Simon,
> >
> > On Fri, Dec 1, 2023 at 6:44 PM Simon Glass wrote:
> > >
> > > Hi Shantur,
> > >
> > > On Sun, 26 Nov 2023 at 15:09, Shantur Rathore wrote:
> > > >
> > > > RockPro64 uses SPI Flash for storing env, also use it store
> > > > EFI variables.
> > > >
> > > > Signed-off-by: Shantur Rathore
> > > > ---
> > > >
> > > > configs/rockpro64-rk3399_defconfig | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/configs/rockpro64-rk3399_defconfig
> > > > b/configs/rockpro64-rk3399_defconfig
> > > > index 4cd6b76665..f550f2ae43 100644
> > > > --- a/configs/rockpro64-rk3399_defconfig
> > > > +++ b/configs/rockpro64-rk3399_defconfig
> > > > @@ -8,6 +8,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> > > > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x30
> > > > CONFIG_ENV_SIZE=0x8000
> > > > CONFIG_ENV_OFFSET=0x3F8000
> > > > +CONFIG_EFI_VARIABLE_SF_STORE=y
> > > > +CONFIG_EFI_VARIABLE_SF_OFFSET=0x7D
> > >
> > > Can we use this offset in binman when creating the SPI-flash image?
> >
> > Unless I missed something, binman is used when something is bundled
> > with a u-boot image.
> > This is similar to ENV_OFFSET letting u-boot know where it can write
> > the EFI variables.
> > I didn't see ENV_OFFSET referred in rk3399-u-boot.dtsi or
> > rk3399-rockpro64-u-boot.dtsi
> >
> > Please correct me if I am wrong.
>
> Well, this is what I see in arch/arm/dts/rk3399-u-boot.dtsi :
>
> #if defined(CONFIG_ROCKCHIP_SPI_IMAGE) && defined(CONFIG_HAS_ROM)
> {
>multiple-images;
>rom {
> filename = "u-boot.rom";
> size = <0x40>;
> pad-byte = <0xff>;
>
> mkimage {
> args = "-n rk3399 -T rkspi";
> u-boot-spl {
> };
> };
> u-boot-img {
> offset = <0x4>;
> };
> u-boot {
> offset = <0x30>;
> };
> fdtmap {
> };
>};
> };
> #endif /* CONFIG_ROCKCHIP_SPI_IMAGE && CONFIG_HAS_ROM */
>
> So it looks like 0x3f8000 fits in there somewhere.
>
Thanks for clarifying. Now I see how ENV space is declared as used by u-boot.
> In fact, I wonder if we should add something like:
>
> u-boot-env {
>offset = ;
> };
>
> so the environment gets filled into the SPI flash when we write the image?
>
Do we want to reset the environment to default on every u-boot update?
I believe this would overwrite the environment space isn't it.
> I suppose we could also add the EFI variable store, although that
> would require adding a new entry type to binman.
>
I am not sure about this but surely EFI vars can be moved to a location
just after the u-boot environment and increase the u-boot image size.
Would you still need an entry in dts?
Re: [PATCH] common: usb-hub: Reset hub port before scanning
Hi Marek, On Sun, Dec 3, 2023 at 8:42 PM Marek Vasut wrote: > > On 11/24/23 01:37, Shantur Rathore wrote: > > Hi Marek, > > Hi, > > sorry for the late reply. > > > In my case RockPro64, the power to usb ports onboard is controlled by > > a regulator. > > This regulator is enabled as part of init as here > > https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/rk3399-rockpro64.dtsi#L177 > > > > On init, the usb devices connected to the port are powered up, in my > > case AM8180 (a RTL9210 based ) NVMe to USB enclosure with UAS. > > But the usb controller is only enabled at 'usb start' and by this time > > the device is in some state that it doesn't get detected. > > > > One way to make sure the devices connected to the ports are in an > > initialising state is by issuing a port reset before scanning the > > port. > > Why not remove this regulator-always-on and let the PHY driver turn the > VBUS ON only when it is needed ? > > Wouldn't that solve the problem too AND remove unnecessarily enabled > regulator ? > > [...] > >>> > >>> Removing the regulator-always-on does make it work but there are few > >>> issues > >>> > >>> 1. regulator is used to control power to multiple ports ( USB3.0 and > >>> USB2.0 in RockPro64 ), > >>> so this could lead to all ports turning off if a phy resets / turns off > >>> power > >> > >> I vaguely recall seeing some refcounting patch for regulator subsystem, > >> would that help ? > > > > I don't think this would be a problem for u-boot, but linux maybe. > > How so ? Actually, I am wrong. I wasn't sure if there is refcounting for the regulator subsystem in linux. just found it has so this is null and void. > > >>> 2. Even with regulator-always-on and without this reset port patch, > >>> linux was always > >>> able to detect the drive on the port, so there is something missing in > >>> u-boot. > >>> 3. Looking at usb hub code in Linux, I found that for USB3.0 it tries > >>> to reset the port before > >>> scanning. The comment says > >>> > >>> /* Is a USB 3.0 port in the Inactive or Compliance Mode state? > >>>* Port warm reset is required to recover > >>>*/ > >>> > >>> i. > >>> https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L5736 > >>> ii. > >>> https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2836 > >>> > >>> I believe this isn't implemented in u-boot and hence explicit reset of > >>> a port fixes the issue. > >> > >> I feel this is separate issue and what needs to be fixed first is the > >> hard-wired VBus control. > > > > I beg to differ on this, couple of reasons for this > > > > 1. The same drive works fine without being reset on the USB2.0 ports - this > > confirms that the issue is related to USB3.0 only. > > This is a separate issue from the hard-wired VBus control. I agree the > issue does exist, I would simply like to avoid conflating the hard-wired > VBus control with device reset. > > > 2. Linux is able to detect the same drive on USB3.0 when u-boot fails - this > > confirms issue doesn't lie with regulator-always-on > > See above > > > 3. The links I pasted earlier mentions that in USB3.0 the ports need reset > > and this is done before the port is scanned. Adding the similar reset in > > u-boot > > fixes all with the same regulator-always-on. AFAIK u-boot doesn't handle > > this special USB3.0 case and maybe this is why I was finding a few posts > > around the drive not being detected in the USB3.0 port in u-boot but works > > in > > a USB2.0 port. > > I am not disputing the need for USB 3.0 device reset, I believe there > are two issues here -- one is the hard-wired VBus regulator -- the other > is this USB 3.0 reset. They should both be fixed. Sure, agreed 100%. Do we need to fix both at the same time? Both patches seem to be independent. Kind regards, Shantur
Re: [u-boot-gitdm PATCH 2/2] Add some more employers
On Sun, Dec 03, 2023 at 09:49:49AM +0100, Jonas Karlman wrote: > Hi Simon, > > On 2023-12-03 05:46, Simon Glass wrote: > > This looks at the top unknowns: > > > >git log --pretty=%ae v2023.01.. |sed 's/.*@//' |sort |uniq -c | > > sort -nr | > >(while read count email; do > >if ! grep -q $email u-boot-config/domain-map; then > > echo "$count $email"; > >fi; done ) > > > > It reduces the (Unknown) count from a third to a fifth. > > > > Signed-off-by: Simon Glass > > --- > > > > u-boot-config/domain-map | 38 ++ > > 1 file changed, 38 insertions(+) > > > > diff --git a/u-boot-config/domain-map b/u-boot-config/domain-map > > index 63cb60f..27f1a7e 100644 > > --- a/u-boot-config/domain-map > > +++ b/u-boot-config/domain-map > > [...] > > > @@ -164,10 +175,13 @@ jmicron.com jmicron.com > > jp.fujitsu.com Fujitsu > > juniper.netJuniper Networks > > katalix.comKatalix Systems > > +kernel-space.org kernelspace > > keymile.comKeymile > > keyspan.comInnoSys > > +kwiboo.se Kwiboo > > kwiboo.se is my personal domain and I have no affiliation with kwiboo ltd. > > My kwiboo nickname and the kwiboo ltd company have no affiliation, the > name conflict is purely accidental. I started using kwiboo as a nickname > from around 2005, someone unrelated registered kwiboo ltd in 2007. > > All my U-Boot contributions should be affiliated with me personally and > should and cannot be affiliated with an employer. And this is why I prefer these updates to come as single entry changes and from someone involved there as well. I will keep an eye on what the stats do with the subdomain on the Renesas contributions, however. -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-sh/master-rpc-off
On Sat, Dec 02, 2023 at 08:08:40PM +0100, Marek Vasut wrote: > The following changes since commit 43f2873fa98b1da6eb56d756315c7bd7db63db27: > > MAINTAINERS: Step up as co-maintainer of Tegra SOC platform (2023-11-28 > 11:23:02 -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-sh.git master-rpc-off > > for you to fetch changes up to 13bdb6a269108d3f9b953bf4b73079d66ecc37af: > > ARM: dts: renesas: Disable RPC driver on R8A779G0 V4H White Hawk board > (2023-12-02 17:16:01 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-usb/master
On Sat, Dec 02, 2023 at 07:25:14AM +0100, Marek Vasut wrote: > The following changes since commit 43f2873fa98b1da6eb56d756315c7bd7db63db27: > > MAINTAINERS: Step up as co-maintainer of Tegra SOC platform (2023-11-28 > 11:23:02 -0500) > > are available in the Git repository at: > > git://source.denx.de/u-boot-usb.git master > > for you to fetch changes up to 493e0e2577bfe11b3065a30a6f5c827f95c1df94: > > usb: USB_XHCI_PCI depends on PCI (2023-12-01 16:01:59 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] mmc: Poll CD in case cyclic framework is enabled
On 12/3/23 18:44, Simon Glass wrote: Hi Marek, On Sat, 2 Dec 2023 at 16:41, Marek Vasut wrote: In case the cyclic framework is enabled, poll the card detect of already initialized cards and deinitialize them in case they are removed. Since the card initialization is a longer process and card initialization is done on first access to an uninitialized card anyway, avoid initializing newly detected uninitialized cards in the cyclic callback. Signed-off-by: Marek Vasut --- Cc: Jaehoon Chung Cc: Peng Fan --- drivers/mmc/mmc-uclass.c | 27 +++ 1 file changed, 27 insertions(+) This is really nice! I wonder whether we can use this cyclic stuff for USB , that's on my roadmap to look at . We could auto-detect new devices in the background, which would be tidy. And maybe do block transfers in the background ? Is there a remove() method where we could unregister the cyclic? I guess I need to move this into mmc_init/mmc_deinit .
Re: [PATCH 1/2] command: Allocate history buffer using calloc()
On 12/3/23 18:44, Simon Glass wrote: Hi Marek, On Sat, 2 Dec 2023 at 13:53, Marek Vasut wrote: The history buffer is currently a static array which can be some 10-40 kiB depending on configuration, and so adds considerably to the U-Boot binary size. Allocate it dynamically instead to reduce the U-Boot binary size. Signed-off-by: Marek Vasut --- Cc: Simon Glass --- common/cli_readline.c | 26 +- 1 file changed, 17 insertions(+), 9 deletions(-) This is very intriguing... I would expect this to end up in BSS, so not part of the image, but allocated when U-Boot starts. What do you mean by U-Boot binary size? Which architecture is this? ARM64 , I spotted it at rcar3_salvator-x_defconfig but it has been a while since I created those patches , they were on hold for a while .
Re: [PATCH] common: usb-hub: Reset hub port before scanning
On 11/24/23 01:37, Shantur Rathore wrote: Hi Marek, Hi, sorry for the late reply. In my case RockPro64, the power to usb ports onboard is controlled by a regulator. This regulator is enabled as part of init as here https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/rk3399-rockpro64.dtsi#L177 On init, the usb devices connected to the port are powered up, in my case AM8180 (a RTL9210 based ) NVMe to USB enclosure with UAS. But the usb controller is only enabled at 'usb start' and by this time the device is in some state that it doesn't get detected. One way to make sure the devices connected to the ports are in an initialising state is by issuing a port reset before scanning the port. Why not remove this regulator-always-on and let the PHY driver turn the VBUS ON only when it is needed ? Wouldn't that solve the problem too AND remove unnecessarily enabled regulator ? [...] Removing the regulator-always-on does make it work but there are few issues 1. regulator is used to control power to multiple ports ( USB3.0 and USB2.0 in RockPro64 ), so this could lead to all ports turning off if a phy resets / turns off power I vaguely recall seeing some refcounting patch for regulator subsystem, would that help ? I don't think this would be a problem for u-boot, but linux maybe. How so ? 2. Even with regulator-always-on and without this reset port patch, linux was always able to detect the drive on the port, so there is something missing in u-boot. 3. Looking at usb hub code in Linux, I found that for USB3.0 it tries to reset the port before scanning. The comment says /* Is a USB 3.0 port in the Inactive or Compliance Mode state? * Port warm reset is required to recover */ i. https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L5736 ii. https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2836 I believe this isn't implemented in u-boot and hence explicit reset of a port fixes the issue. I feel this is separate issue and what needs to be fixed first is the hard-wired VBus control. I beg to differ on this, couple of reasons for this 1. The same drive works fine without being reset on the USB2.0 ports - this confirms that the issue is related to USB3.0 only. This is a separate issue from the hard-wired VBus control. I agree the issue does exist, I would simply like to avoid conflating the hard-wired VBus control with device reset. 2. Linux is able to detect the same drive on USB3.0 when u-boot fails - this confirms issue doesn't lie with regulator-always-on See above 3. The links I pasted earlier mentions that in USB3.0 the ports need reset and this is done before the port is scanned. Adding the similar reset in u-boot fixes all with the same regulator-always-on. AFAIK u-boot doesn't handle this special USB3.0 case and maybe this is why I was finding a few posts around the drive not being detected in the USB3.0 port in u-boot but works in a USB2.0 port. I am not disputing the need for USB 3.0 device reset, I believe there are two issues here -- one is the hard-wired VBus regulator -- the other is this USB 3.0 reset. They should both be fixed.
Re: [PATCH] usb: xhci: Replace terrible formatting with different terrible formatting
On 11/27/23 06:57, Hector Martin wrote: On 2023/11/23 8:50, Marek Vasut wrote: Replace one type of terrible code formatting with a different type of terrible code formatting. No functional change. Signed-off-by: Marek Vasut --- Cc: Bin Meng Cc: Hector Martin --- drivers/usb/host/xhci-ring.c | 18 +++--- 1 file changed, 7 insertions(+), 11 deletions(-) Lol. Reviewed-by: Hector Martin Thanks
Re: bootstd: Support for distro specific EFI folders
Hi Heinrich, On Sun, 3 Dec 2023 at 13:00, Heinrich Schuchardt wrote: > > On 12/3/23 20:50, Simon Glass wrote: > > Hi Heinrich, > > > > On Sun, 3 Dec 2023 at 11:33, Heinrich Schuchardt > > wrote: > >> > >> On 12/3/23 19:22, Simon Glass wrote: > >>> Hi Heinrich, > >>> > >>> On Sun, 3 Dec 2023 at 10:53, Heinrich Schuchardt > >>> wrote: > > On 12/3/23 18:44, Simon Glass wrote: > > Hi Heinrich, > > > > On Sun, 3 Dec 2023 at 03:55, Heinrich Schuchardt > > wrote: > >> > >> On 12/3/23 00:38, Shantur Rathore wrote: > >>> Hi Simon, > >>> > >>> On Sat, Dec 2, 2023 at 6:33 PM Simon Glass wrote: > > Hi, > > On Mon, 20 Nov 2023 at 00:02, Ilias Apalodimas > wrote: > > > > Hi Mark, > > > > On Sun, 19 Nov 2023 at 19:38, Mark Kettenis > > wrote: > >> > >>> Date: Sat, 18 Nov 2023 23:52:11 +0100 > >>> From: Heinrich Schuchardt > >> > >> Hi Heinrich, > >> > >>> On 11/18/23 22:28, Shantur Rathore wrote: > Hi Heinrich, > > On Fri, Nov 17, 2023 at 3:12 PM Heinrich Schuchardt > wrote: > > > > On 11/16/23 19:45, Shantur Rathore wrote: > >> On Thu, Nov 16, 2023 at 6:15 PM Heinrich Schuchardt > >> wrote: > >>> > >>> On 11/16/23 17:52, Shantur Rathore wrote: > Hi Simon, > > Currently bootstd - bootmethod_efi only looks for the default > bootxx64.efi in /EFI/boot folder only. > Generally many distros end up putting their bootloaders in > EFI/ folders like EFI/ubuntu and EFI/debian etc. > > In x86 worlds, the NVRAM is modified and new boot entries > are added to > support these but in the U-boot world the NVRAM variables are > read-only. > >>> > >>> I guess you are referring to UEFI boot options. These > >>> typically are not > >>> stored in non-volatile RAM but on a SPI flash device. > >>> > >> > >> Thanks for correcting me. > >> > > What would be the best way to implement this? > > I was thinking of having a "efi_prefixes" environment > variable which > can be set to "ubuntu debian centos" etc and bootmethod_efi > can try > all of them. Will bootmethod_efi be able to support multiple > entries ( > thinking of multiboot ) ? > >>> > >>> On my laptop I have: > >>> > >>> EFI/Microsoft/Boot/bootmgr.efi > >>> EFI/Microsoft/Boot/memtest.efi > >>> EFI/Boot/bootx64.efi > >>> EFI/Boot/fbx64.efi > >>> EFI/Boot/mmx64.efi > >>> EFI/debian/shimx64.efi > >>> EFI/debian/grubx64.efi > >>> EFI/debian/mmx64.efi > >>> EFI/debian/fbx64.efi > >>> EFI/ubuntu/grubx64.efi > >>> EFI/ubuntu/shimx64.efi > >>> EFI/ubuntu/mmx64.efi > >>> > >>> Obviously each installed operating system provides multiple > >>> EFI binaries > >>> and non uses the fallback file name BOOT.EFI. A value > >>> "ubuntu > >>> debian centos" would not be able to describe which file you > >>> are looking > >>> for. > >>> > >>> We already have the U-Boot command line eficonfig and > >>> efidebug commands > >>> to set up UEFI boot options which can describe which EFI > >>> binary to load > >>> and which command line to pass to it. These are considered by > >>> the > >>> existing boot flows. > >> > >> So, I am building a new RockPro64 based cluster and using > >> Canonical > >> MAAS to set them up automatically, booting them up using DHCP > >> and > >> installing them over the network. > >> I configured an Armbian image using Packer to be compatible > >> with MAAS > >> and it happily installs it. As part of installation process, a > >> grub-install is run which installs the grub efi, > >> this EFI ends up in EFI/debian instead of expected EFI/boot. > >> To be able to make it boot, I have to add commands to move it > >> to > >> EFI/boot. I am trying to find a way in U-Boot that would allow > >> me to > >> skip this step. > >> With eficonfig if I
Re: bootstd: Support for distro specific EFI folders
On 12/3/23 20:50, Simon Glass wrote: Hi Heinrich, On Sun, 3 Dec 2023 at 11:33, Heinrich Schuchardt wrote: On 12/3/23 19:22, Simon Glass wrote: Hi Heinrich, On Sun, 3 Dec 2023 at 10:53, Heinrich Schuchardt wrote: On 12/3/23 18:44, Simon Glass wrote: Hi Heinrich, On Sun, 3 Dec 2023 at 03:55, Heinrich Schuchardt wrote: On 12/3/23 00:38, Shantur Rathore wrote: Hi Simon, On Sat, Dec 2, 2023 at 6:33 PM Simon Glass wrote: Hi, On Mon, 20 Nov 2023 at 00:02, Ilias Apalodimas wrote: Hi Mark, On Sun, 19 Nov 2023 at 19:38, Mark Kettenis wrote: Date: Sat, 18 Nov 2023 23:52:11 +0100 From: Heinrich Schuchardt Hi Heinrich, On 11/18/23 22:28, Shantur Rathore wrote: Hi Heinrich, On Fri, Nov 17, 2023 at 3:12 PM Heinrich Schuchardt wrote: On 11/16/23 19:45, Shantur Rathore wrote: On Thu, Nov 16, 2023 at 6:15 PM Heinrich Schuchardt wrote: On 11/16/23 17:52, Shantur Rathore wrote: Hi Simon, Currently bootstd - bootmethod_efi only looks for the default bootxx64.efi in /EFI/boot folder only. Generally many distros end up putting their bootloaders in EFI/ folders like EFI/ubuntu and EFI/debian etc. In x86 worlds, the NVRAM is modified and new boot entries are added to support these but in the U-boot world the NVRAM variables are read-only. I guess you are referring to UEFI boot options. These typically are not stored in non-volatile RAM but on a SPI flash device. Thanks for correcting me. What would be the best way to implement this? I was thinking of having a "efi_prefixes" environment variable which can be set to "ubuntu debian centos" etc and bootmethod_efi can try all of them. Will bootmethod_efi be able to support multiple entries ( thinking of multiboot ) ? On my laptop I have: EFI/Microsoft/Boot/bootmgr.efi EFI/Microsoft/Boot/memtest.efi EFI/Boot/bootx64.efi EFI/Boot/fbx64.efi EFI/Boot/mmx64.efi EFI/debian/shimx64.efi EFI/debian/grubx64.efi EFI/debian/mmx64.efi EFI/debian/fbx64.efi EFI/ubuntu/grubx64.efi EFI/ubuntu/shimx64.efi EFI/ubuntu/mmx64.efi Obviously each installed operating system provides multiple EFI binaries and non uses the fallback file name BOOT.EFI. A value "ubuntu debian centos" would not be able to describe which file you are looking for. We already have the U-Boot command line eficonfig and efidebug commands to set up UEFI boot options which can describe which EFI binary to load and which command line to pass to it. These are considered by the existing boot flows. So, I am building a new RockPro64 based cluster and using Canonical MAAS to set them up automatically, booting them up using DHCP and installing them over the network. I configured an Armbian image using Packer to be compatible with MAAS and it happily installs it. As part of installation process, a grub-install is run which installs the grub efi, this EFI ends up in EFI/debian instead of expected EFI/boot. To be able to make it boot, I have to add commands to move it to EFI/boot. I am trying to find a way in U-Boot that would allow me to skip this step. With eficonfig if I understand correctly, it would need manual intervention to create boot entries. If you are installing the shim-signed package on Ubuntu, the EFI boot option for Ubuntu is set up by EFI/BOOT/BOOT.EFI using the content of EFI/ubuntu/BOOT.CSV. This is done before ExitBootServices() and therefore should work with current U-Boot. Patches are pending upstream to make EFI variables writable from Linux if they are stored in the RPMB partition in the eMMC. See this series: https://lore.kernel.org/linux-efi/20231107054057.1893-2-masahisa.koj...@linaro.org/ Would it be possible to save it in SPI Flash as the U-Boot environment ? Currently this is not supported by U-Boot. The U-Boot environment variables can be stored in lots of different places SPI flash is only one of these. But none of these locations is protected from OS access which would be preferable for UEFI variables for security reasons. To support boards without eMMC the right way forward would be writing a new implementation of the OP-TEE standalone MM which writes the variables to SPI flash instead of the RPMB partition and ensures that the SPI flash' MMIO registers are protected against access from the non-secure world. Thanks for explaining this to me. This seems like a long way to go, for now what would be an acceptable solution, some options are 1. Allow to set a space separated efi_prefixes (e.g. "boot ubuntu debian") variable which is ready by bootmeth_efi and used as efi/ instead of efi/boot. 2. Improve bootmeth_efi to find all boot.efi in efi/ folder and present all them as bootflows to bootstd. As mentioned in a prior mail ubuntu/boot.efi and debian/boot.efi don't exist. I would prefer not to add any distro specific stuff in upstream U-Boot. Instead we will continue to drive what Linaro has suggested to improve U-Boot EFI variables support in Linux. I agree that adding hacks like this is not a good idea. + 1 The Linaro
Re: bootstd: Support for distro specific EFI folders
Hi Heinrich, On Sun, 3 Dec 2023 at 11:33, Heinrich Schuchardt wrote: > > On 12/3/23 19:22, Simon Glass wrote: > > Hi Heinrich, > > > > On Sun, 3 Dec 2023 at 10:53, Heinrich Schuchardt > > wrote: > >> > >> On 12/3/23 18:44, Simon Glass wrote: > >>> Hi Heinrich, > >>> > >>> On Sun, 3 Dec 2023 at 03:55, Heinrich Schuchardt > >>> wrote: > > On 12/3/23 00:38, Shantur Rathore wrote: > > Hi Simon, > > > > On Sat, Dec 2, 2023 at 6:33 PM Simon Glass wrote: > >> > >> Hi, > >> > >> On Mon, 20 Nov 2023 at 00:02, Ilias Apalodimas > >> wrote: > >>> > >>> Hi Mark, > >>> > >>> On Sun, 19 Nov 2023 at 19:38, Mark Kettenis > >>> wrote: > > > Date: Sat, 18 Nov 2023 23:52:11 +0100 > > From: Heinrich Schuchardt > > Hi Heinrich, > > > On 11/18/23 22:28, Shantur Rathore wrote: > >> Hi Heinrich, > >> > >> On Fri, Nov 17, 2023 at 3:12 PM Heinrich Schuchardt > >> wrote: > >>> > >>> On 11/16/23 19:45, Shantur Rathore wrote: > On Thu, Nov 16, 2023 at 6:15 PM Heinrich Schuchardt > wrote: > > > > On 11/16/23 17:52, Shantur Rathore wrote: > >> Hi Simon, > >> > >> Currently bootstd - bootmethod_efi only looks for the default > >> bootxx64.efi in /EFI/boot folder only. > >> Generally many distros end up putting their bootloaders in > >> EFI/ folders like EFI/ubuntu and EFI/debian etc. > >> > >> In x86 worlds, the NVRAM is modified and new boot entries are > >> added to > >> support these but in the U-boot world the NVRAM variables are > >> read-only. > > > > I guess you are referring to UEFI boot options. These typically > > are not > > stored in non-volatile RAM but on a SPI flash device. > > > > Thanks for correcting me. > > >> > >> What would be the best way to implement this? > >> > >> I was thinking of having a "efi_prefixes" environment variable > >> which > >> can be set to "ubuntu debian centos" etc and bootmethod_efi > >> can try > >> all of them. Will bootmethod_efi be able to support multiple > >> entries ( > >> thinking of multiboot ) ? > > > > On my laptop I have: > > > > EFI/Microsoft/Boot/bootmgr.efi > > EFI/Microsoft/Boot/memtest.efi > > EFI/Boot/bootx64.efi > > EFI/Boot/fbx64.efi > > EFI/Boot/mmx64.efi > > EFI/debian/shimx64.efi > > EFI/debian/grubx64.efi > > EFI/debian/mmx64.efi > > EFI/debian/fbx64.efi > > EFI/ubuntu/grubx64.efi > > EFI/ubuntu/shimx64.efi > > EFI/ubuntu/mmx64.efi > > > > Obviously each installed operating system provides multiple EFI > > binaries > > and non uses the fallback file name BOOT.EFI. A value > > "ubuntu > > debian centos" would not be able to describe which file you are > > looking > > for. > > > > We already have the U-Boot command line eficonfig and efidebug > > commands > > to set up UEFI boot options which can describe which EFI binary > > to load > > and which command line to pass to it. These are considered by > > the > > existing boot flows. > > So, I am building a new RockPro64 based cluster and using > Canonical > MAAS to set them up automatically, booting them up using DHCP and > installing them over the network. > I configured an Armbian image using Packer to be compatible with > MAAS > and it happily installs it. As part of installation process, a > grub-install is run which installs the grub efi, > this EFI ends up in EFI/debian instead of expected EFI/boot. > To be able to make it boot, I have to add commands to move it to > EFI/boot. I am trying to find a way in U-Boot that would allow > me to > skip this step. > With eficonfig if I understand correctly, it would need manual > intervention to create boot entries. > > > > > If you are installing the shim-signed package on Ubuntu, the > > EFI boot > > option for Ubuntu is set up by EFI/BOOT/BOOT.EFI using > > the content > > of EFI/ubuntu/BOOT.CSV. This is done before > >
Re: bootstd: Support for distro specific EFI folders
On 12/3/23 19:22, Simon Glass wrote: Hi Heinrich, On Sun, 3 Dec 2023 at 10:53, Heinrich Schuchardt wrote: On 12/3/23 18:44, Simon Glass wrote: Hi Heinrich, On Sun, 3 Dec 2023 at 03:55, Heinrich Schuchardt wrote: On 12/3/23 00:38, Shantur Rathore wrote: Hi Simon, On Sat, Dec 2, 2023 at 6:33 PM Simon Glass wrote: Hi, On Mon, 20 Nov 2023 at 00:02, Ilias Apalodimas wrote: Hi Mark, On Sun, 19 Nov 2023 at 19:38, Mark Kettenis wrote: Date: Sat, 18 Nov 2023 23:52:11 +0100 From: Heinrich Schuchardt Hi Heinrich, On 11/18/23 22:28, Shantur Rathore wrote: Hi Heinrich, On Fri, Nov 17, 2023 at 3:12 PM Heinrich Schuchardt wrote: On 11/16/23 19:45, Shantur Rathore wrote: On Thu, Nov 16, 2023 at 6:15 PM Heinrich Schuchardt wrote: On 11/16/23 17:52, Shantur Rathore wrote: Hi Simon, Currently bootstd - bootmethod_efi only looks for the default bootxx64.efi in /EFI/boot folder only. Generally many distros end up putting their bootloaders in EFI/ folders like EFI/ubuntu and EFI/debian etc. In x86 worlds, the NVRAM is modified and new boot entries are added to support these but in the U-boot world the NVRAM variables are read-only. I guess you are referring to UEFI boot options. These typically are not stored in non-volatile RAM but on a SPI flash device. Thanks for correcting me. What would be the best way to implement this? I was thinking of having a "efi_prefixes" environment variable which can be set to "ubuntu debian centos" etc and bootmethod_efi can try all of them. Will bootmethod_efi be able to support multiple entries ( thinking of multiboot ) ? On my laptop I have: EFI/Microsoft/Boot/bootmgr.efi EFI/Microsoft/Boot/memtest.efi EFI/Boot/bootx64.efi EFI/Boot/fbx64.efi EFI/Boot/mmx64.efi EFI/debian/shimx64.efi EFI/debian/grubx64.efi EFI/debian/mmx64.efi EFI/debian/fbx64.efi EFI/ubuntu/grubx64.efi EFI/ubuntu/shimx64.efi EFI/ubuntu/mmx64.efi Obviously each installed operating system provides multiple EFI binaries and non uses the fallback file name BOOT.EFI. A value "ubuntu debian centos" would not be able to describe which file you are looking for. We already have the U-Boot command line eficonfig and efidebug commands to set up UEFI boot options which can describe which EFI binary to load and which command line to pass to it. These are considered by the existing boot flows. So, I am building a new RockPro64 based cluster and using Canonical MAAS to set them up automatically, booting them up using DHCP and installing them over the network. I configured an Armbian image using Packer to be compatible with MAAS and it happily installs it. As part of installation process, a grub-install is run which installs the grub efi, this EFI ends up in EFI/debian instead of expected EFI/boot. To be able to make it boot, I have to add commands to move it to EFI/boot. I am trying to find a way in U-Boot that would allow me to skip this step. With eficonfig if I understand correctly, it would need manual intervention to create boot entries. If you are installing the shim-signed package on Ubuntu, the EFI boot option for Ubuntu is set up by EFI/BOOT/BOOT.EFI using the content of EFI/ubuntu/BOOT.CSV. This is done before ExitBootServices() and therefore should work with current U-Boot. Patches are pending upstream to make EFI variables writable from Linux if they are stored in the RPMB partition in the eMMC. See this series: https://lore.kernel.org/linux-efi/20231107054057.1893-2-masahisa.koj...@linaro.org/ Would it be possible to save it in SPI Flash as the U-Boot environment ? Currently this is not supported by U-Boot. The U-Boot environment variables can be stored in lots of different places SPI flash is only one of these. But none of these locations is protected from OS access which would be preferable for UEFI variables for security reasons. To support boards without eMMC the right way forward would be writing a new implementation of the OP-TEE standalone MM which writes the variables to SPI flash instead of the RPMB partition and ensures that the SPI flash' MMIO registers are protected against access from the non-secure world. Thanks for explaining this to me. This seems like a long way to go, for now what would be an acceptable solution, some options are 1. Allow to set a space separated efi_prefixes (e.g. "boot ubuntu debian") variable which is ready by bootmeth_efi and used as efi/ instead of efi/boot. 2. Improve bootmeth_efi to find all boot.efi in efi/ folder and present all them as bootflows to bootstd. As mentioned in a prior mail ubuntu/boot.efi and debian/boot.efi don't exist. I would prefer not to add any distro specific stuff in upstream U-Boot. Instead we will continue to drive what Linaro has suggested to improve U-Boot EFI variables support in Linux. I agree that adding hacks like this is not a good idea. + 1 The Linaro approach that involves OP-TEE makes for a fairly complex solution. And there are plenty of boards that have
Re: bootstd: Support for distro specific EFI folders
Hi Heinrich, On Sun, 3 Dec 2023 at 10:53, Heinrich Schuchardt wrote: > > On 12/3/23 18:44, Simon Glass wrote: > > Hi Heinrich, > > > > On Sun, 3 Dec 2023 at 03:55, Heinrich Schuchardt > > wrote: > >> > >> On 12/3/23 00:38, Shantur Rathore wrote: > >>> Hi Simon, > >>> > >>> On Sat, Dec 2, 2023 at 6:33 PM Simon Glass wrote: > > Hi, > > On Mon, 20 Nov 2023 at 00:02, Ilias Apalodimas > wrote: > > > > Hi Mark, > > > > On Sun, 19 Nov 2023 at 19:38, Mark Kettenis > > wrote: > >> > >>> Date: Sat, 18 Nov 2023 23:52:11 +0100 > >>> From: Heinrich Schuchardt > >> > >> Hi Heinrich, > >> > >>> On 11/18/23 22:28, Shantur Rathore wrote: > Hi Heinrich, > > On Fri, Nov 17, 2023 at 3:12 PM Heinrich Schuchardt > wrote: > > > > On 11/16/23 19:45, Shantur Rathore wrote: > >> On Thu, Nov 16, 2023 at 6:15 PM Heinrich Schuchardt > >> wrote: > >>> > >>> On 11/16/23 17:52, Shantur Rathore wrote: > Hi Simon, > > Currently bootstd - bootmethod_efi only looks for the default > bootxx64.efi in /EFI/boot folder only. > Generally many distros end up putting their bootloaders in > EFI/ folders like EFI/ubuntu and EFI/debian etc. > > In x86 worlds, the NVRAM is modified and new boot entries are > added to > support these but in the U-boot world the NVRAM variables are > read-only. > >>> > >>> I guess you are referring to UEFI boot options. These typically > >>> are not > >>> stored in non-volatile RAM but on a SPI flash device. > >>> > >> > >> Thanks for correcting me. > >> > > What would be the best way to implement this? > > I was thinking of having a "efi_prefixes" environment variable > which > can be set to "ubuntu debian centos" etc and bootmethod_efi can > try > all of them. Will bootmethod_efi be able to support multiple > entries ( > thinking of multiboot ) ? > >>> > >>> On my laptop I have: > >>> > >>> EFI/Microsoft/Boot/bootmgr.efi > >>> EFI/Microsoft/Boot/memtest.efi > >>> EFI/Boot/bootx64.efi > >>> EFI/Boot/fbx64.efi > >>> EFI/Boot/mmx64.efi > >>> EFI/debian/shimx64.efi > >>> EFI/debian/grubx64.efi > >>> EFI/debian/mmx64.efi > >>> EFI/debian/fbx64.efi > >>> EFI/ubuntu/grubx64.efi > >>> EFI/ubuntu/shimx64.efi > >>> EFI/ubuntu/mmx64.efi > >>> > >>> Obviously each installed operating system provides multiple EFI > >>> binaries > >>> and non uses the fallback file name BOOT.EFI. A value > >>> "ubuntu > >>> debian centos" would not be able to describe which file you are > >>> looking > >>> for. > >>> > >>> We already have the U-Boot command line eficonfig and efidebug > >>> commands > >>> to set up UEFI boot options which can describe which EFI binary > >>> to load > >>> and which command line to pass to it. These are considered by the > >>> existing boot flows. > >> > >> So, I am building a new RockPro64 based cluster and using Canonical > >> MAAS to set them up automatically, booting them up using DHCP and > >> installing them over the network. > >> I configured an Armbian image using Packer to be compatible with > >> MAAS > >> and it happily installs it. As part of installation process, a > >> grub-install is run which installs the grub efi, > >> this EFI ends up in EFI/debian instead of expected EFI/boot. > >> To be able to make it boot, I have to add commands to move it to > >> EFI/boot. I am trying to find a way in U-Boot that would allow me > >> to > >> skip this step. > >> With eficonfig if I understand correctly, it would need manual > >> intervention to create boot entries. > >> > >>> > >>> If you are installing the shim-signed package on Ubuntu, the EFI > >>> boot > >>> option for Ubuntu is set up by EFI/BOOT/BOOT.EFI using the > >>> content > >>> of EFI/ubuntu/BOOT.CSV. This is done before > >>> ExitBootServices() and > >>> therefore should work with current U-Boot. > >>> > >>> Patches are pending upstream to make EFI variables writable from > >>> Linux > >>> if they are stored in the RPMB partition in the eMMC. See this > >>> series: > >>> > >>> https://lore.kernel.org/linux-efi/20231107054057.1893-2-masahisa.koj...@linaro.org/ >
Re: bootstd: Support for distro specific EFI folders
On 12/3/23 18:44, Simon Glass wrote: Hi Heinrich, On Sun, 3 Dec 2023 at 03:55, Heinrich Schuchardt wrote: On 12/3/23 00:38, Shantur Rathore wrote: Hi Simon, On Sat, Dec 2, 2023 at 6:33 PM Simon Glass wrote: Hi, On Mon, 20 Nov 2023 at 00:02, Ilias Apalodimas wrote: Hi Mark, On Sun, 19 Nov 2023 at 19:38, Mark Kettenis wrote: Date: Sat, 18 Nov 2023 23:52:11 +0100 From: Heinrich Schuchardt Hi Heinrich, On 11/18/23 22:28, Shantur Rathore wrote: Hi Heinrich, On Fri, Nov 17, 2023 at 3:12 PM Heinrich Schuchardt wrote: On 11/16/23 19:45, Shantur Rathore wrote: On Thu, Nov 16, 2023 at 6:15 PM Heinrich Schuchardt wrote: On 11/16/23 17:52, Shantur Rathore wrote: Hi Simon, Currently bootstd - bootmethod_efi only looks for the default bootxx64.efi in /EFI/boot folder only. Generally many distros end up putting their bootloaders in EFI/ folders like EFI/ubuntu and EFI/debian etc. In x86 worlds, the NVRAM is modified and new boot entries are added to support these but in the U-boot world the NVRAM variables are read-only. I guess you are referring to UEFI boot options. These typically are not stored in non-volatile RAM but on a SPI flash device. Thanks for correcting me. What would be the best way to implement this? I was thinking of having a "efi_prefixes" environment variable which can be set to "ubuntu debian centos" etc and bootmethod_efi can try all of them. Will bootmethod_efi be able to support multiple entries ( thinking of multiboot ) ? On my laptop I have: EFI/Microsoft/Boot/bootmgr.efi EFI/Microsoft/Boot/memtest.efi EFI/Boot/bootx64.efi EFI/Boot/fbx64.efi EFI/Boot/mmx64.efi EFI/debian/shimx64.efi EFI/debian/grubx64.efi EFI/debian/mmx64.efi EFI/debian/fbx64.efi EFI/ubuntu/grubx64.efi EFI/ubuntu/shimx64.efi EFI/ubuntu/mmx64.efi Obviously each installed operating system provides multiple EFI binaries and non uses the fallback file name BOOT.EFI. A value "ubuntu debian centos" would not be able to describe which file you are looking for. We already have the U-Boot command line eficonfig and efidebug commands to set up UEFI boot options which can describe which EFI binary to load and which command line to pass to it. These are considered by the existing boot flows. So, I am building a new RockPro64 based cluster and using Canonical MAAS to set them up automatically, booting them up using DHCP and installing them over the network. I configured an Armbian image using Packer to be compatible with MAAS and it happily installs it. As part of installation process, a grub-install is run which installs the grub efi, this EFI ends up in EFI/debian instead of expected EFI/boot. To be able to make it boot, I have to add commands to move it to EFI/boot. I am trying to find a way in U-Boot that would allow me to skip this step. With eficonfig if I understand correctly, it would need manual intervention to create boot entries. If you are installing the shim-signed package on Ubuntu, the EFI boot option for Ubuntu is set up by EFI/BOOT/BOOT.EFI using the content of EFI/ubuntu/BOOT.CSV. This is done before ExitBootServices() and therefore should work with current U-Boot. Patches are pending upstream to make EFI variables writable from Linux if they are stored in the RPMB partition in the eMMC. See this series: https://lore.kernel.org/linux-efi/20231107054057.1893-2-masahisa.koj...@linaro.org/ Would it be possible to save it in SPI Flash as the U-Boot environment ? Currently this is not supported by U-Boot. The U-Boot environment variables can be stored in lots of different places SPI flash is only one of these. But none of these locations is protected from OS access which would be preferable for UEFI variables for security reasons. To support boards without eMMC the right way forward would be writing a new implementation of the OP-TEE standalone MM which writes the variables to SPI flash instead of the RPMB partition and ensures that the SPI flash' MMIO registers are protected against access from the non-secure world. Thanks for explaining this to me. This seems like a long way to go, for now what would be an acceptable solution, some options are 1. Allow to set a space separated efi_prefixes (e.g. "boot ubuntu debian") variable which is ready by bootmeth_efi and used as efi/ instead of efi/boot. 2. Improve bootmeth_efi to find all boot.efi in efi/ folder and present all them as bootflows to bootstd. As mentioned in a prior mail ubuntu/boot.efi and debian/boot.efi don't exist. I would prefer not to add any distro specific stuff in upstream U-Boot. Instead we will continue to drive what Linaro has suggested to improve U-Boot EFI variables support in Linux. I agree that adding hacks like this is not a good idea. + 1 The Linaro approach that involves OP-TEE makes for a fairly complex solution. And there are plenty of boards that have neither eMMC nor SPI flash. If Secure Boot is not a requirement (and I'd argue that for most "hobbyist" boards
Re: bootstd: Support for distro specific EFI folders
Hi Heinrich, On Sun, 3 Dec 2023 at 03:55, Heinrich Schuchardt wrote: > > On 12/3/23 00:38, Shantur Rathore wrote: > > Hi Simon, > > > > On Sat, Dec 2, 2023 at 6:33 PM Simon Glass wrote: > >> > >> Hi, > >> > >> On Mon, 20 Nov 2023 at 00:02, Ilias Apalodimas > >> wrote: > >>> > >>> Hi Mark, > >>> > >>> On Sun, 19 Nov 2023 at 19:38, Mark Kettenis > >>> wrote: > > > Date: Sat, 18 Nov 2023 23:52:11 +0100 > > From: Heinrich Schuchardt > > Hi Heinrich, > > > On 11/18/23 22:28, Shantur Rathore wrote: > >> Hi Heinrich, > >> > >> On Fri, Nov 17, 2023 at 3:12 PM Heinrich Schuchardt > >> wrote: > >>> > >>> On 11/16/23 19:45, Shantur Rathore wrote: > On Thu, Nov 16, 2023 at 6:15 PM Heinrich Schuchardt > wrote: > > > > On 11/16/23 17:52, Shantur Rathore wrote: > >> Hi Simon, > >> > >> Currently bootstd - bootmethod_efi only looks for the default > >> bootxx64.efi in /EFI/boot folder only. > >> Generally many distros end up putting their bootloaders in > >> EFI/ folders like EFI/ubuntu and EFI/debian etc. > >> > >> In x86 worlds, the NVRAM is modified and new boot entries are > >> added to > >> support these but in the U-boot world the NVRAM variables are > >> read-only. > > > > I guess you are referring to UEFI boot options. These typically are > > not > > stored in non-volatile RAM but on a SPI flash device. > > > > Thanks for correcting me. > > >> > >> What would be the best way to implement this? > >> > >> I was thinking of having a "efi_prefixes" environment variable > >> which > >> can be set to "ubuntu debian centos" etc and bootmethod_efi can try > >> all of them. Will bootmethod_efi be able to support multiple > >> entries ( > >> thinking of multiboot ) ? > > > > On my laptop I have: > > > > EFI/Microsoft/Boot/bootmgr.efi > > EFI/Microsoft/Boot/memtest.efi > > EFI/Boot/bootx64.efi > > EFI/Boot/fbx64.efi > > EFI/Boot/mmx64.efi > > EFI/debian/shimx64.efi > > EFI/debian/grubx64.efi > > EFI/debian/mmx64.efi > > EFI/debian/fbx64.efi > > EFI/ubuntu/grubx64.efi > > EFI/ubuntu/shimx64.efi > > EFI/ubuntu/mmx64.efi > > > > Obviously each installed operating system provides multiple EFI > > binaries > > and non uses the fallback file name BOOT.EFI. A value "ubuntu > > debian centos" would not be able to describe which file you are > > looking > > for. > > > > We already have the U-Boot command line eficonfig and efidebug > > commands > > to set up UEFI boot options which can describe which EFI binary to > > load > > and which command line to pass to it. These are considered by the > > existing boot flows. > > So, I am building a new RockPro64 based cluster and using Canonical > MAAS to set them up automatically, booting them up using DHCP and > installing them over the network. > I configured an Armbian image using Packer to be compatible with MAAS > and it happily installs it. As part of installation process, a > grub-install is run which installs the grub efi, > this EFI ends up in EFI/debian instead of expected EFI/boot. > To be able to make it boot, I have to add commands to move it to > EFI/boot. I am trying to find a way in U-Boot that would allow me to > skip this step. > With eficonfig if I understand correctly, it would need manual > intervention to create boot entries. > > > > > If you are installing the shim-signed package on Ubuntu, the EFI > > boot > > option for Ubuntu is set up by EFI/BOOT/BOOT.EFI using the > > content > > of EFI/ubuntu/BOOT.CSV. This is done before > > ExitBootServices() and > > therefore should work with current U-Boot. > > > > Patches are pending upstream to make EFI variables writable from > > Linux > > if they are stored in the RPMB partition in the eMMC. See this > > series: > > > > https://lore.kernel.org/linux-efi/20231107054057.1893-2-masahisa.koj...@linaro.org/ > > > > Would it be possible to save it in SPI Flash as the U-Boot > environment ? > >>> > >>> Currently this is not supported by U-Boot. > >>> > >>> The U-Boot environment variables can be stored in lots of different > >>> places SPI flash is only one of these. But none of these locations is > >>> protected from OS access which would be preferable for UEFI
Re: [PATCH] mmc: Poll CD in case cyclic framework is enabled
Hi Marek, On Sat, 2 Dec 2023 at 16:41, Marek Vasut wrote: > > In case the cyclic framework is enabled, poll the card detect of already > initialized cards and deinitialize them in case they are removed. Since > the card initialization is a longer process and card initialization is > done on first access to an uninitialized card anyway, avoid initializing > newly detected uninitialized cards in the cyclic callback. > > Signed-off-by: Marek Vasut > --- > Cc: Jaehoon Chung > Cc: Peng Fan > --- > drivers/mmc/mmc-uclass.c | 27 +++ > 1 file changed, 27 insertions(+) This is really nice! Is there a remove() method where we could unregister the cyclic? Reviewed-by: Simon Glass
Re: [PATCH 2/2] command: Move command completion temporary buffer to stack
On Sat, 2 Dec 2023 at 13:53, Marek Vasut wrote: > > The command completion temporary buffer seems to be only > used by the argv tokenizer, move it to stack. This saves > 2 kiB from the binary size (depends on configuration) per: > $ aarch64-linux-gnu-readelf -s u-boot | sort -n -k 3 > > Signed-off-by: Marek Vasut > --- > Cc: Simon Glass > --- > common/command.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH] doc: Replace examples of MD5 and SHA1 with SHA256
Hi Sean, On Sat, 2 Dec 2023 at 12:38, Sean Anderson wrote: > > On 12/2/23 14:33, Sean Anderson wrote: > > Both SHA1 and (especially) MD5 are no longer as safe as they once were for > > cryptographic use. Replaces examples which use them with examples using > > SHA256 instead. This will provide more-secure defaults for users who use > > documentation examples as a base for their own use. This is not too > > necessary for non-verified-boot scenarios (since someone could just replace > > the checksum), but I wanted to be complete. > > > > Signed-off-by: Sean Anderson > > --- > > I forgot to mention this in the commit message, but all the new hashes were > generated like > > echo fake kernel hash | sha256sum > > which should be fine, since the actual values were just for example anyway. Ah, I was wondering about that. Reviewed-by: Simon Glass Regards, Simon
