Re: [PULL next] u-boot-at91-2023.04-a
On Thu, Jan 05, 2023 at 09:54:12AM +, eugen.hris...@microchip.com wrote: > Hello Tom, > > Please pull tag u-boot-at91-2023.04-a , the first set of at91 features > for the next cycle 2023.04. > > This feature set includes the new DM-based NAND flash driver (old non-DM > driver is still kept for backwards compatibility), and the move to DM > NAND flash driver for sam9x60ek board. Feature set also includes > devicetree alignment for sama7g5 with Linux, devicetree alignment on USB > with Linux for all boards (sama5, sam9x60), chip id for sama7g5, minor > configs and tweaks. > > Thanks, > Eugen > > > The following changes since commit d2ad92927ea91ab8cece92a308350602c594dd3e: > >Merge branch '2022-12-05-Kconfig-migrations-and-renames' into next > (2022-12-05 21:04:24 -0500) > > are available in the Git repository at: > >https://source.denx.de/u-boot/custodians/u-boot-at91.git > tags/u-boot-at91-2023.04-a > > for you to fetch changes up to 61040097a9d1c8022bae7936c52b729ff1adb163: > >reset: at91: Add reset driver for basic assert/deassert operations > (2023-01-05 10:06:35 +0200) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [regression] 2023.01 breaks u-boot-initial-env for aarch64
On 1/6/23 19:44, Otavio Salvador wrote:
Hello,
When using v2023.01-rc4-49-g582e3c9fb23 for aarch64
(technically imx8mm-lpddr4-evk) I get following error:
| /bin/false)
| cat u-boot-nodtb.bin dts/dt.dtb > u-boot-dtb.bin
| cp u-boot-dtb.bin u-boot.bin
| aarch64-oel-linux-objcopy --dump-section
.rodata.default_environment=u-boot-initial-env env/common.o; sed --in-place
-e 's/\x00/\x0A/g' u-boot-initial-env; sed --in-place -e '/^\s*$/d'
u-boot-initial-env; sort --field-separator== -k1,1 --stable
u-boot-initial-env -o u-boot-initial-env
| aarch64-oel-linux-objcopy: env/common.o: can't dump section
'.rodata.default_environment' - it does not exist: file format not
recognized
| sed: can't read u-boot-initial-env: No such file or directory
The very same works just fine with 2022.10 it works. I didn't investigate
more yet.
Do you have LTO enabled?
Does 486aef08de ("u-boot-initial-env: rework make target") fix things?
--Sean
[PATCH] net: ipv6: Fix IPv6 netmask parsing
From: Sean Edmond
It should be possible to specify a netmask when
setting a static IPv6 address. For example:
setenv ip6addr 2001:cafe:cafe:cafe::100/64
The net_prefix_length and net_ip6 should be updated
properly.
Signed-off-by: Sean Edmond
---
net/net6.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/net6.c b/net/net6.c
index fdea078788..75577bcea1 100644
--- a/net/net6.c
+++ b/net/net6.c
@@ -47,10 +47,13 @@ static int on_ip6addr(const char *name, const char *value,
enum env_op op,
}
mask = strchr(value, '/');
- len = strlen(value);
- if (mask)
- net_prefix_length = simple_strtoul(value + len, NULL, 10);
+ if (mask) {
+ net_prefix_length = simple_strtoul(mask + 1, NULL, 10);
+ len = mask - value;
+ } else {
+ len = strlen(value);
+ }
return string_to_ip6(value, len, _ip6);
}
--
2.39.0
[regression] 2023.01 breaks u-boot-initial-env for aarch64
Hello, When using v2023.01-rc4-49-g582e3c9fb23 for aarch64 (technically imx8mm-lpddr4-evk) I get following error: | /bin/false) | cat u-boot-nodtb.bin dts/dt.dtb > u-boot-dtb.bin | cp u-boot-dtb.bin u-boot.bin | aarch64-oel-linux-objcopy --dump-section .rodata.default_environment=u-boot-initial-env env/common.o; sed --in-place -e 's/\x00/\x0A/g' u-boot-initial-env; sed --in-place -e '/^\s*$/d' u-boot-initial-env; sort --field-separator== -k1,1 --stable u-boot-initial-env -o u-boot-initial-env | aarch64-oel-linux-objcopy: env/common.o: can't dump section '.rodata.default_environment' - it does not exist: file format not recognized | sed: can't read u-boot-initial-env: No such file or directory The very same works just fine with 2022.10 it works. I didn't investigate more yet. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
Re: [PATCH v3 6/7] video: Only dcache flush damaged lines
Hi, On Tue, 3 Jan 2023 at 13:25, Alexander Graf wrote: > > > On 30.12.22 22:12, Heinrich Schuchardt wrote: > > On 12/30/22 20:58, Alexander Graf wrote: > >> Now that we have a damage area tells us which parts of the frame buffer > >> actually need updating, let's only dcache flush those on video_sync() > >> calls. With this optimization in place, frame buffer updates - > >> especially > >> on large screen such as 4k displays - speed up significantly. > >> > >> Signed-off-by: Alexander Graf > >> Reported-by: Da Xue > >> > >> --- > >> > >> v1 -> v2: > >> > >>- Fix dcache range; we were flushing too much before > >>- Remove ifdefs > >> --- > >> drivers/video/video-uclass.c | 51 ++-- > >> 1 file changed, 43 insertions(+), 8 deletions(-) > >> > >> diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c > >> index f1fbeaadcb..bf93f524c7 100644 > >> --- a/drivers/video/video-uclass.c > >> +++ b/drivers/video/video-uclass.c > >> @@ -297,9 +297,45 @@ int video_damage(struct udevice *vid, int x, int > >> y, int width, int height) > >> return 0; > >> } > >> > >> +#if defined(CONFIG_ARM) && !CONFIG_IS_ENABLED(SYS_DCACHE_OFF) > > > > ARM isn't the only architecture implementing flush_dcache_range(). > > So this condition needs to be fixed as well as the one in video_sync. > > > > Why don't you simply rely on priv->flash_dcache irrespective of the > > architecture? Let the video drivers decide if they need it. > > > This is code that already was #ifdef'ed before. The way I understand its > history, we couldn't decisively ensure that flush_dcache_range() exists, > so we couldn't build the code always. > > I agree that it looks weird and error prone though. I believe you're > trying to say we should just make sure there's always a > flush_dcache_range() function and keep the rest to the compiler? > Can / should we use the dma_map stuff here? Regards, Simon
Re: [PATCH v2] cmd: mmc: Expand bkops handling
On Thu, 5 Jan 2023 at 07:19, Marek Vasut wrote: > > Add more capable "bkops" command which allows enabling and disabling both > manual and automatic bkops. The existing 'mmc bkops-enable' subcommand is > poorly named to cover all the possibilities, hence the new-ish subcommand. > Note that both commands are wrappers around the same common code. > > Signed-off-by: Marek Vasut > --- > Cc: Jaehoon Chung > Cc: Peng Fan > --- > V2: - Add kerneldoc comment to mmc_set_bkops_enable > - Drop ifdef around mmc_set_bkops_enable in mmc.h > --- > cmd/mmc.c | 49 +++ > drivers/mmc/mmc.c | 14 +- > include/mmc.h | 14 +++--- > 3 files changed, 61 insertions(+), 16 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH v4 3/9] vidconsole: Add damage notifications to all vidconsole drivers
On Tue, 3 Jan 2023 at 14:50, Alexander Graf wrote: > > Now that we have a damage tracking API, let's populate damage done by > vidconsole drivers. We try to declare as little memory as damaged as > possible, with the exception of rotated screens that I couldn't get my > head wrapped around. On those, we revert to the old behavior and mark > the full screen as damaged on every update. > > Signed-off-by: Alexander Graf > Reported-by: Da Xue > > --- > > v1 -> v2: > > - Fix ranges in truetype target > - Limit rotate to necessary damange > --- > drivers/video/console_normal.c | 10 ++ > drivers/video/console_rotate.c | 54 > drivers/video/console_truetype.c | 15 + > 3 files changed, 79 insertions(+) > Reviewed-by: Simon Glass
Re: [PATCH v4 7/9] video: Use VIDEO_DAMAGE for VIDEO_COPY
Hi Alexander, On Tue, 3 Jan 2023 at 14:50, Alexander Graf wrote: > > CONFIG_VIDEO_COPY implemented a range based copying mechanism: If we range-based > print a single character, it will always copy the full range of bytes > from the top left corner of the character to the lower right onto the > uncached frame buffer. This includes pretty much the full line contents > of the printed character. > > Since we now have proper damage tracking, let's make use of that to reduce > the amount of data we need to copy. With this patch applied, we will only > copy the tiny rectangle surrounding characters when we print them, > speeding up the video console. > > As a bonus, we remove a lot of code. > > Signed-off-by: Alexander Graf > > --- > > v2 -> v3: > > - Rebase > - Make CONFIG_COPY always select VIDEO_DAMAGE > --- > drivers/video/Kconfig | 5 ++ > drivers/video/console_normal.c| 14 + > drivers/video/console_rotate.c| 37 ++--- > drivers/video/console_truetype.c | 17 +- > drivers/video/vidconsole-uclass.c | 16 -- > drivers/video/video-uclass.c | 91 --- > drivers/video/video_bmp.c | 7 --- > include/video.h | 37 - > include/video_console.h | 49 - > 9 files changed, 37 insertions(+), 236 deletions(-) > This feature needs some tests in test/dm/video.c For sandbox, I think you will need to allow it to be enabled / disabled at runtime, so the some tests can use it and some not? Regards, Simon
Re: [PATCH v3 02/25] cli: Move readline character-processing to a state machine
Hi Heinrich,
On Fri, 6 Jan 2023 at 08:50, Heinrich Schuchardt wrote:
>
> On 1/6/23 15:52, Simon Glass wrote:
> > The current cread_line() function is very long. It handles the escape
> > processing inline. The menu command does similar processing but at the
> > character level, so there is some duplication.
> >
> > Split the character processing into a new function cli_ch_process() which
> > processes individual characters and returns the resulting input character,
> > taking account of escape sequences. It requires the caller to set up and
> > maintain its state.
> >
> > Update cread_line() to use this new function.
> >
> > The only intended functional change is that an invalid escape sequence
> > does not add invalid/control characters into the input buffer, but instead
> > discards these.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > (no changes since v1)
> >
> > common/Makefile | 6 +-
> > common/cli_getch.c| 204 ++
> > common/cli_readline.c | 150 +--
> > include/cli.h | 72 +++
> > 4 files changed, 301 insertions(+), 131 deletions(-)
> > create mode 100644 common/cli_getch.c
> >
> > diff --git a/common/Makefile b/common/Makefile
> > index 20addfb244c..67485e77a04 100644
> > --- a/common/Makefile
> > +++ b/common/Makefile
> > @@ -38,7 +38,7 @@ obj-$(CONFIG_SPLASH_SOURCE) += splash_source.o
> > obj-$(CONFIG_MENU) += menu.o
> > obj-$(CONFIG_UPDATE_COMMON) += update.o
> > obj-$(CONFIG_USB_KEYBOARD) += usb_kbd.o
> > -obj-$(CONFIG_CMDLINE) += cli_readline.o cli_simple.o
> > +obj-$(CONFIG_CMDLINE) += cli_getch.o cli_readline.o cli_simple.o
> >
> > endif # !CONFIG_SPL_BUILD
> >
> > @@ -93,8 +93,8 @@ obj-y += eeprom/eeprom_field.o eeprom/eeprom_layout.o
> > endif
> >
> > obj-y += cli.o
> > -obj-$(CONFIG_FSL_DDR_INTERACTIVE) += cli_simple.o cli_readline.o
> > -obj-$(CONFIG_STM32MP1_DDR_INTERACTIVE) += cli_simple.o cli_readline.o
> > +obj-$(CONFIG_FSL_DDR_INTERACTIVE) += cli_getch.o cli_simple.o
> > cli_readline.o
> > +obj-$(CONFIG_STM32MP1_DDR_INTERACTIVE) += cli_getch.o cli_simple.o
> > cli_readline.o
> > obj-$(CONFIG_DFU_OVER_USB) += dfu.o
> > obj-y += command.o
> > obj-$(CONFIG_$(SPL_TPL_)LOG) += log.o
> > diff --git a/common/cli_getch.c b/common/cli_getch.c
> > new file mode 100644
> > index 000..9eeea7fef29
> > --- /dev/null
> > +++ b/common/cli_getch.c
> > @@ -0,0 +1,204 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * (C) Copyright 2000
> > + * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> > + *
> > + * Copyright 2022 Google LLC
> > + */
> > +
> > +#include
> > +#include
> > +
> > +/**
> > + * enum cli_esc_state_t - indicates what to do with an escape character
> > + *
> > + * @ESC_REJECT: Invalid escape sequence, so the esc_save[] characters are
> > + * returned from each subsequent call to cli_ch_esc()
> > + * @ESC_SAVE: Character should be saved in esc_save until we have another
> > one
> > + * @ESC_CONVERTED: Escape sequence has been completed and the resulting
> > + * character is available
> > + */
> > +enum cli_esc_state_t {
> > + ESC_REJECT,
> > + ESC_SAVE,
> > + ESC_CONVERTED
> > +};
> > +
> > +void cli_ch_init(struct cli_ch_state *cch)
> > +{
> > + memset(cch, '\0', sizeof(*cch));
> > +}
> > +
> > +/**
> > + * cli_ch_esc() - Process a character in an ongoing escape sequence
> > + *
> > + * @cch: State information
> > + * @ichar: Character to process
> > + * @actp: Returns the action to take
> > + * Returns: Output character if *actp is ESC_CONVERTED, else 0
> > + */
> > +static int cli_ch_esc(struct cli_ch_state *cch, int ichar,
> > + enum cli_esc_state_t *actp)
> > +{
> > + enum cli_esc_state_t act = ESC_REJECT;
> > +
> > + switch (cch->esc_len) {
> > + case 1:
> > + if (ichar == '[' || ichar == 'O')
> > + act = ESC_SAVE;
> > + break;
> > + case 2:
> > + switch (ichar) {
> > + case 'D': /* <- key */
> > + ichar = CTL_CH('b');
> > + act = ESC_CONVERTED;
> > + break; /* pass off to ^B handler */
> > + case 'C': /* -> key */
> > + ichar = CTL_CH('f');
> > + act = ESC_CONVERTED;
> > + break; /* pass off to ^F handler */
> > + case 'H': /* Home key */
> > + ichar = CTL_CH('a');
> > + act = ESC_CONVERTED;
> > + break; /* pass off to ^A handler */
> > + case 'F': /* End key */
> > + ichar = CTL_CH('e');
> > + act = ESC_CONVERTED;
> > + break; /* pass off to ^E handler */
> > + case 'A': /* up arrow */
> > + ichar = CTL_CH('p');
> > + act = ESC_CONVERTED;
Re: [PATCH v4 4/9] video: Add damage notification on bmp display
On Tue, 3 Jan 2023 at 14:50, Alexander Graf wrote: > > Let's report the video damage when we draw a bitmap on the screen. This > way we can later lazily flush only relevant regions to hardware. > > Signed-off-by: Alexander Graf > Reported-by: Da Xue > --- > drivers/video/video_bmp.c | 2 ++ > 1 file changed, 2 insertions(+) > Reviewed-by: Simon Glass
Re: [PATCH v4 8/9] video: Always compile cache flushing code
On Tue, 3 Jan 2023 at 14:50, Alexander Graf wrote: > > The dcache flushing code path was conditional on ARM && !DCACHE config > options. However, dcaches exist on other platforms as well and may need > clearing if their driver requires it. > > Simplify the compile logic and always enable the dcache flush logic in > the video core. That way, drivers can always rely on it to call the arch > specific callbacks. > > This will increase code size for non-ARM platforms with CONFIG_VIDEO=y > slightly. > > Reported-by: Heinrich Schuchardt > Signed-off-by: Alexander Graf > --- > drivers/video/video-uclass.c | 14 +- > 1 file changed, 5 insertions(+), 9 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH v4 0/9] Add video damage tracking
Hi Alex, On Tue, 3 Jan 2023 at 14:50, Alexander Graf wrote: > > This patch set speeds up graphics output on ARM by a factor of 60x. > > On most ARM SBCs, we keep the frame buffer in DRAM and map it as cached, > but need it accessible by the display controller which reads directly > from a later point of consistency. Hence, we flush the frame buffer to > DRAM on every change. The full frame buffer. > > Unfortunately, with the advent of 4k displays, we are seeing frame buffers > that can take a while to flush out. This was reported by Da Xue with grub, > which happily print 1000s of spaces on the screen to draw a menu. Every > printed space triggers a cache flush. > > This patch set implements the easiest mitigation against this problem: > Damage tracking. We remember the lowest common denominator region that was > touched since the last video_sync() call and only flush that. The most > typical writer to the frame buffer is the video console, which always > writes rectangles of characters on the screen and syncs afterwards. > > With this patch set applied, we reduce drawing a large grub menu (with > serial console attached for size information) on an RK3399-ROC system > at 1440p from 55 seconds to less than 1 second. > > Version 2 also implements VIDEO_COPY using this mechanism, reducing its > overhead compared to before as well. So even x86 systems should be faster > with this now :). > > > Alternatives considered: > > 1) Lazy sync - Sandbox does this. It only calls video_sync(true) ever > so often. We are missing timers to do this generically. > > 2) Double buffering - We could try to identify whether anything changed > at all and only draw to the FB if it did. That would require > maintaining a second buffer that we need to scan. > > 3) Text buffer - Maintain a buffer of all text printed on the screen with > respective location. Don't write if the old and new character are > identical. This would limit applicability to text only and is an > optimization on top of this patch set. > > 4) Hash screen lines - Create a hash (sha256?) over every line when it > changes. Only flush when it does. I'm not sure if this would waste > more time, memory and cache than the current approach. It would make > full screen updates much more expensive. > > v1 -> v2: > > - new patch: video: Use VIDEO_DAMAGE for VIDEO_COPY > - Remove ifdefs > - Fix dcache range; we were flushing too much before > - Fix ranges in truetype target > - Limit rotate to necessary damange damage > > v2 -> v3: > > - Rebase > - Adapt to DM_VIDEO always > - Make CONFIG_COPY always select VIDEO_DAMAGE > > v3 -> v4: > > - New patch: video: Always compile cache flushing code > - New patch: video: Enable VIDEO_DAMAGE for drivers that need it > - Simplify first damage logic > - Skip damage on EfiBltVideoToBltBuffer > - Move damage clear from patch 6 to patch 1 > - Remove VIDEO_DAMAGE default for ARM > > Alexander Graf (9): > dm: video: Add damage tracking API > dm: video: Add damage notification on display clear > vidconsole: Add damage notifications to all vidconsole drivers > video: Add damage notification on bmp display > efi_loader: GOP: Add damage notification on BLT > video: Only dcache flush damaged lines > video: Use VIDEO_DAMAGE for VIDEO_COPY > video: Always compile cache flushing code > video: Enable VIDEO_DAMAGE for drivers that need it > > arch/arm/mach-omap2/omap3/Kconfig | 1 + > arch/arm/mach-sunxi/Kconfig | 1 + > drivers/video/Kconfig | 27 + > drivers/video/console_normal.c| 22 ++-- > drivers/video/console_rotate.c| 87 +- > drivers/video/console_truetype.c | 30 ++--- > drivers/video/exynos/Kconfig | 1 + > drivers/video/imx/Kconfig | 1 + > drivers/video/meson/Kconfig | 1 + > drivers/video/rockchip/Kconfig| 1 + > drivers/video/stm32/Kconfig | 1 + > drivers/video/vidconsole-uclass.c | 16 --- > drivers/video/video-uclass.c | 187 +- > drivers/video/video_bmp.c | 7 +- > include/video.h | 54 - > include/video_console.h | 49 > lib/efi_loader/efi_gop.c | 6 + > 17 files changed, 251 insertions(+), 241 deletions(-) > > -- > 2.37.1 (Apple Git-137.1) > This looks good but needs tests and a rebase to -next Regards, Simon
Re: [PATCH u-boot 2/2] Makefile: Build working u-boot-dtb.bin target also for mpc85xx
Hi Pali, On Tue, 3 Jan 2023 at 10:05, Pali Rohár wrote: > > On Tuesday 03 January 2023 11:02:17 Simon Glass wrote: > > > > > > 3. Add a common binman image for u-boot.bin (used by every board) > > > > > > > > > > It should be u-boot-dtb.bin (not u-boot.bin). At least this is the > > > > > current file name. (See this my patch series again, which aligns this > > > > > naming also for powerpc/mpc85xx). > > > > > > > > We changed this 6 years ago and I'm not keen on going back. > > > > > > > > ad1ecd2063d fdt: Build a U-Boot binary without device tree > > > > > > I just do not understand you because in that commit is exactly what I > > > wrote. In file u-boot-dtb.bin is u-boot binary with DTB and in file > > > u-boot-nodtb.bin is u-boot binary without DTB. > > > > > > So binman should take input files u-boot-nodtb.bin and DTB binary. And > > > should produce output file u-boot-dtb.bin. Is there any issue with it? > > > > Actually u-boot-dtb.bin is a hangover from that commit, left in to > > allow people to adjust. So I think we should remove creation of > > u-boot-dtb.bin > > Ok, complete remove of u-boot-dtb.bin creation also works. OK good. - Simon
Re: [PATCH v8 09/13] rockchip: Use multiple-images for rk3399
Hi Quentin,
On Thu, 5 Jan 2023 at 02:47, Quentin Schulz
wrote:
>
> Hi Simon,
>
> On 1/4/23 21:01, Simon Glass wrote:
> > Hi Quentin,
> >
> > On Mon, 2 Jan 2023 at 09:42, Quentin Schulz
> > wrote:
> >>
> >> Hi Simon,
> >>
> >> On 12/22/22 00:07, Simon Glass wrote:
> >>> Enable multiple-images so we can generate more than one image. Also
> >>> add a comment for the end of the #if block.
> >>>
> >>> Signed-off-by: Simon Glass
> >>> ---
> >>>
> >>> (no changes since v5)
> >>>
> >>> Changes in v5:
> >>> - Rename from 'Include binman script in 64-bit boards'
> >>> - Drop duplicate #include in rk3368-u-boot.dtsi
> >>> - Keep the name as fit for puma
> >>> - Drop redundant check for CONFIG_ROCKCHIP_SPI_IMAGE
> >>> - Drop imply of BINMAN in Kconfig (rely on ARCH_ROCKCHIP instead)
> >>>
> >>>arch/arm/dts/rk3399-u-boot.dtsi | 3 ++-
> >>>1 file changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi
> >>> b/arch/arm/dts/rk3399-u-boot.dtsi
> >>> index 3c1a15fe51b..85a4f472d5d 100644
> >>> --- a/arch/arm/dts/rk3399-u-boot.dtsi
> >>> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
> >>> @@ -62,6 +62,7 @@
> >>>
> >>>#if defined(CONFIG_ROCKCHIP_SPI_IMAGE) && defined(CONFIG_HAS_ROM)
> >>> {
> >>> + multiple-images;
> >>>rom {
> >>>filename = "u-boot.rom";
> >>>size = <0x40>;
> >>> @@ -82,7 +83,7 @@
> >>>};
> >>>};
> >>>};
> >>> -#endif
> >>> +#endif /* CONFIG_ROCKCHIP_SPI_IMAGE */
> >>
> >> && CONFIG_HAS_ROM
> >>
> >> On a different topic, I'm a bit confused by this u-boot.rom binary. is
> >> it not just for Chromebooks? We now have u-boot-rockchip-spi.bin for SPI
> >> images but they are different (same as u-boot-rockchip.bin, just
> >> formatted in a way it can be flashed on a SPI flash).
> >
> > The .rom is for SPI flash, not just Chromebooks. Perhaps we should
> > unify the two of them?
> >
>
> I was under the impression that this .rom was mostly used for
> Chromebooks which is the reason why I didn't change any of it when
> adding support for u-boot-rockchip-spi.bin back then since the images
> are different (-spi has the u-boot fit instead of legacy, -spi has
> support for tpl while .rom only has support for SPL).
>
> I'm all for unifying them if we can find something that does not make
> the ifdef situation in rockchip-u-boot.dtsi more dire :)
Great!
>
> HAS_ROM is enabled on:
> TARGET_CHROMEBOOK_JERRY
> TARGET_EVB_RK3288
> TARGET_CHROMEBOOK_BOB
> TARGET_CHROMEBOOK_KEVIN
>
> so this binman entry will only be used for the last two (the first two
> are handled in arch/arm/dts/rk3288-u-boot.dtsi, but with the same
> content as in arch/arm/dts/rk3399-u-boot.dtsi). Hence why I thought it
> was Chromebook related :)
>
> Are there any requirements for those devices that make them require
> something different than current u-boot-rockchip-spi.bin?
Not that I know of. I can test something if it helps.
Regards,
Simon
Re: [PATCH v4 9/9] video: Enable VIDEO_DAMAGE for drivers that need it
Hi Alex, On Tue, 3 Jan 2023 at 14:50, Alexander Graf wrote: > > Some drivers call video_set_flush_dcache() to indicate that they want to > have the dcache flushed for the frame buffer. These drivers benefit from > our new video damage control, because we can reduce the amount of memory > that gets flushed significantly. > > This patch enables video damage control for all device drivers that call > video_set_flush_dcache() to make sure they benefit from it. > > Signed-off-by: Alexander Graf > --- > arch/arm/mach-omap2/omap3/Kconfig | 1 + > arch/arm/mach-sunxi/Kconfig | 1 + > drivers/video/Kconfig | 9 + > drivers/video/exynos/Kconfig | 1 + > drivers/video/imx/Kconfig | 1 + > drivers/video/meson/Kconfig | 1 + > drivers/video/rockchip/Kconfig| 1 + > drivers/video/stm32/Kconfig | 1 + > 8 files changed, 16 insertions(+) > > diff --git a/arch/arm/mach-omap2/omap3/Kconfig > b/arch/arm/mach-omap2/omap3/Kconfig > index 3e97ec2629..ea231f16a2 100644 > --- a/arch/arm/mach-omap2/omap3/Kconfig > +++ b/arch/arm/mach-omap2/omap3/Kconfig > @@ -113,6 +113,7 @@ config TARGET_NOKIA_RX51 > select CMDLINE_TAG > select INITRD_TAG > select REVISION_TAG > + select VIDEO_DAMAGE Please avoid using select since it means that boards cannot disable it. You can use 'imply' instead. Or you can use 'default y' for the damage Kconfig. Regards, Simon
Re: [PATCH] common: bouncebuf: Use dma-mapping for cache ops
On Fri, 6 Jan 2023 at 11:02, Andrew Davis wrote: > > This matches how this would be done in Linux and these functions > do the alignment for us which makes the code look cleaner. > > Signed-off-by: Andrew Davis > --- > common/bouncebuf.c | 13 +++-- > 1 file changed, 7 insertions(+), 6 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH v4 1/9] dm: video: Add damage tracking API
Hi Alex,
On Tue, 3 Jan 2023 at 14:50, Alexander Graf wrote:
>
> We are going to introduce image damage tracking to fasten up screen
> refresh on large displays. This patch adds damage tracking for up to
> one rectangle of the screen which is typically enough to hold blt or
> text print updates. Callers into this API and a reduced dcache flush
> code path will follow in later patches.
>
> Signed-off-by: Alexander Graf
> Reported-by: Da Xue
>
> ---
>
> v1 -> v2:
>
> - Remove ifdefs
>
> v2 -> v3:
>
> - Adapt Kconfig to DM always
>
> v3 -> v4:
>
> - Move damage clear from patch 6 to this one
> - Simplify first damage logic
> - Remove VIDEO_DAMAGE default for ARM
> ---
> drivers/video/Kconfig| 13
> drivers/video/video-uclass.c | 41
> include/video.h | 29 +++--
> 3 files changed, 81 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index f539977d9b..826a1a6587 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -62,6 +62,19 @@ config VIDEO_COPY
> To use this, your video driver must set @copy_base in
> struct video_uc_plat.
>
> +config VIDEO_DAMAGE
> + bool "Enable damage tracking of frame buffer regions"
> + help
> + On some machines (most ARM), the display frame buffer resides in
> + RAM. To make the display controller pick up screen updates, we
> + have to flush frame buffer contents from CPU caches into RAM which
> + can be a slow operation.
> +
> + This feature adds damage tracking to collect information about
> regions
> + that received updates. When we want to sync, we then only flush
> + regions of the frame buffer that were modified before, speeding up
> + screen refreshes significantly.
> +
> config BACKLIGHT_PWM
> bool "Generic PWM based Backlight Driver"
> depends on BACKLIGHT && DM_PWM
> diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
> index 0ce376ca3f..d18c8cd2b1 100644
> --- a/drivers/video/video-uclass.c
> +++ b/drivers/video/video-uclass.c
> @@ -21,6 +21,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #ifdef CONFIG_SANDBOX
> #include
> #endif
> @@ -254,6 +256,37 @@ void video_set_default_colors(struct udevice *dev, bool
> invert)
> priv->colour_bg = video_index_to_colour(priv, back);
> }
>
> +/* Notify about changes in the frame buffer */
> +int video_damage(struct udevice *vid, int x, int y, int width, int height)
> +{
> + struct video_priv *priv = dev_get_uclass_priv(vid);
> + int endx = x + width;
> + int endy = y + height;
> +
> + if (!CONFIG_IS_ENABLED(VIDEO_DAMAGE))
> + return 0;
> +
> + if (x > priv->xsize)
> + return 0;
> +
> + if (y > priv->ysize)
> + return 0;
> +
> + if (endx > priv->xsize)
> + endx = priv->xsize;
> +
> + if (endy > priv->ysize)
> + endy = priv->ysize;
> +
> + /* Span a rectangle across all old and new damage */
> + priv->damage.x = min(x, priv->damage.x);
> + priv->damage.y = min(y, priv->damage.y);
> + priv->damage.endx = max(endx, priv->damage.endx);
> + priv->damage.endy = max(endy, priv->damage.endy);
> +
> + return 0;
Should we make this void, then?
> +}
> +
> /* Flush video activity to the caches */
> int video_sync(struct udevice *vid, bool force)
> {
> @@ -288,6 +321,14 @@ int video_sync(struct udevice *vid, bool force)
> last_sync = get_timer(0);
> }
> #endif
> +
> + if (CONFIG_IS_ENABLED(VIDEO_DAMAGE)) {
> + priv->damage.x = priv->xsize;
> + priv->damage.y = priv->ysize;
> + priv->damage.endx = 0;
> + priv->damage.endy = 0;
> + }
> +
> return 0;
> }
>
> diff --git a/include/video.h b/include/video.h
> index 43f2e2c02f..4b35e97f79 100644
> --- a/include/video.h
> +++ b/include/video.h
> @@ -109,6 +109,12 @@ struct video_priv {
Please update the comment when you add struct members.
> void *fb;
> int fb_size;
> void *copy_fb;
> + struct {
> + int x;
> + int y;
> + int endx;
> + int endy;
> + } damage;
> int line_length;
> u32 colour_fg;
> u32 colour_bg;
> @@ -211,8 +217,9 @@ int video_fill(struct udevice *dev, u32 colour);
> * @return: 0 on success, error code otherwise
> *
> * Some frame buffers are cached or have a secondary frame buffer. This
> - * function syncs these up so that the current contents of the U-Boot frame
> - * buffer are displayed to the user.
> + * function syncs the damaged parts of them up so that the current contents
> + * of the U-Boot frame buffer are displayed to the user. It clears the damage
> + * buffer.
>
Re: [PATCH v4 2/9] dm: video: Add damage notification on display clear
On Tue, 3 Jan 2023 at 14:50, Alexander Graf wrote: > > Let's report the video damage when we clear the screen. This > way we can later lazily flush only relevant regions to hardware. > > Signed-off-by: Alexander Graf > Reported-by: Da Xue > --- > drivers/video/video-uclass.c | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Simon Glass
Re: [PATCH v3 03/25] bootmenu: Add a few comments
Hi Heinrich,
On Fri, 6 Jan 2023 at 09:53, Heinrich Schuchardt wrote:
>
> On 1/6/23 15:52, Simon Glass wrote:
> > The behaviour of these two functions is completely undocumented. Add some
> > notes so the poor, suffering dev can figure out what is going on.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > (no changes since v1)
> >
> > include/menu.h | 42 ++
> > 1 file changed, 42 insertions(+)
> >
> > diff --git a/include/menu.h b/include/menu.h
> > index 702aacb170c..0b4d9734149 100644
> > --- a/include/menu.h
> > +++ b/include/menu.h
> > @@ -42,6 +42,7 @@ struct bootmenu_data {
> > struct bootmenu_entry *first; /* first menu entry */
> > };
> >
> > +/** enum bootmenu_key - keys that can be returned by the bootmenu */
> > enum bootmenu_key {
> > KEY_NONE = 0,
> > KEY_UP,
> > @@ -53,8 +54,49 @@ enum bootmenu_key {
> > KEY_SPACE,
> > };
> >
> > +/**
> > + * bootmenu_autoboot_loop() - handle autobooting if no key is pressed
> > + *
> > + * This shows a prompt to allow the user to press a key to interrupt auto
> > boot
> > + * of the first menu option.
> > + *
> > + * It then waits for the required time (menu->delay in seconds) for a key
> > to be
> > + * pressed. If nothing is pressed in that time, @key returns KEY_SELECT
> > + * indicating that the current option should be chosen.
> > + *
> > + * @menu: Menu being processed
> > + * @key: Returns the code for the key the user pressed:
> > + * enter: KEY_SELECT
> > + * Ctrl-C: KEY_QUIT
> > + * anything else: KEY_NONE
> > + * @esc: Set to 1 if the escape key is pressed, otherwise not updated
> > + */
> > void bootmenu_autoboot_loop(struct bootmenu_data *menu,
> > enum bootmenu_key *key, int *esc);
> > +
> > +/**
> > + * bootmenu_loop() - handle waiting for a keypress when autoboot is
> > disabled
> > + *
> > + * This is used when the menu delay is negative, indicating that the delay
> > has
> > + * elapsed, or there was no delay to begin with.
> > + *
> > + * It reads a character and processes it, returning a menu-key code if a
> > + * character is recognised
> > + *
> > + * @menu: Menu being processed
> > + * @key: Returns the code for the key the user pressed:
> > + * enter: KEY_SELECT
> > + * Ctrl-C: KEY_QUIT
> > + * Up arrow: KEY_UP
> > + * Down arrow: KEY_DOWN
> > + * Escape (by itself): KEY_QUIT
> > + * Plus: KEY_PLUS
> > + * Minus: KEY_MINUS
> > + * Space: KEY_SPACE
> > + * @esc: On input, a non-zero value indicates that an escape sequence has
> > + * resulted in that many characters so far. On exit this is updated to
> > the
> > + * new number of characters
> > + */
> > void bootmenu_loop(struct bootmenu_data *menu,
> > enum bootmenu_key *key, int *esc);
>
> This should not be an exported function. The program part that wants to
> display a menu should not have to deal with navigation keys.
This is a patch to add comments to code which is not otherwise
addressed in this series. We need comments so that we know what things
do. We can always adjust the logic later.
My intent with this series is to add a new menu which is more flexible.
Regards,
Simon
Re: [PATCH v2 1/2] lib: zstd: update to latest Linux zstd 1.5.2
> From: Tom Rini > On Mon, Jan 02, 2023 at 04:02:06PM +, Maier, Brandon L > > > > I understand Linux replaced their custom zstd code with the Facebook zstd > code, so the changes are widespread. The new zstd does support many > optional performance features as documented in zstd's lib/README[1], > which I have already added a KConfig to disable all of them in this patch. For > reference, if I enable the performance options the build size increases as so: > > > > aarch64: (for 2/2 boards) all +27432.0 rodata +320.0 text +27112.0 > >arm: (for 5/5 boards) all +21801.6 rodata +256.0 text +21545.6 > >sandbox: (for 2/2 boards) all +59004.0 bss +16.0 rodata +800.0 text > +58188.0 > > > > I haven't had any luck finding another way to decrease build size. > > > > [1] > https://github.com/facebook/zstd/blob/dev/lib/README.md#modular-build > > After skimming over that, did you see if not disabling inlining, and > letting the compiler figure it out is a big size penalty? That is one of the settings I am already enabling. To clarify from that README, the settings I am enabling in U-Boot are HUF_FORCE_DECOMPRESS_X1, ZSTD_FORCE_DECOMPRESS_SEQUENCES_SHORT, ZSTD_NO_INLINE, and ZSTD_STRIP_ERROR_STRINGS. Which is what upstream zstd uses for their own ZSTD_LIB_MINIFY option in lib/libzstd.mk. If I drop the ZSTD_NO_INLINE, the build sizes increase as follows: aarch64: (for 2/2 boards) all +6212.0 rodata +8.0 text +6204.0 arm: (for 5/5 boards) all +7408.0 text +7408.0 sandbox: (for 2/2 boards) all +21928.0 bss -16.0 data +16.0 rodata +224.0 text +21704.0 > Also, while the arch-level details are good, a specific platform set of > numbers > instead might give some ideas on where maybe reductions could come from. I looked over each platform, but the size deltas are consistent within each architecture. What stands out though is that the old ZSTD ARM code is about 4.6kb smaller (25%) than the old ZSTD AARCH64 code. The newer ZSTD doesn't do that, both ARM and AARCH64 are about the same in size. That is why there is a 4k jump in size for just the arm boards. Comparing the functions list between the two, both archs appear similar except ZSTD_decompressBlock_internal() grows significantly on aarch64 for some reason. I haven't seen any obvious root cause though. Here is the full breakdown of platform size deltas aarch64: (for 2/2 boards) all +535.5 rodata +965.5 text -430.0 turris_mox : all +572 rodata +968 text -396 mvebu_espressobin-88f3720: all +499 rodata +963 text -464 arm: (for 5/5 boards) all +4489.6 rodata +940.0 text +3549.6 turris_omnia : all +4608 rodata +940 text +3668 m53menlo : all +4460 rodata +940 text +3520 dh_imx6: all +4460 rodata +940 text +3520 stm32mp15_dhcom_basic: all +4460 rodata +940 text +3520 stm32mp15_dhcor_basic: all +4460 rodata +940 text +3520 sandbox: (for 2/2 boards) all +8.0 rodata +784.0 text -776.0 sandbox: all +528 bss -32 rodata +768 text -208 sandbox64 : all -512 bss +32 rodata +800 text -1344 > Finally, what is the whole list of platforms that grow? All of them except sandbox64 grow by some amount. > It's all not ideal, yes, but it looks like BTRFS is the main user, right now, > which > isn't widely enabled. So maybe we can look towards improving upstream a > bit here, if motivated. I can't speak for the BTRFS code as I don't have a suitable platform to test it on. But the zstd code does appear to be broken on master. Running the zstd compression test in sandbox or sandbox64 both segfault. And I have similar problems trying to decompress FIT images on our AARCH64 platform. The primary motivation to this patch is that the new version does work. And this seems like the appropriate fix given Linux has abandoned the original version of this code. > > -- > Tom
Re: [PATCH v2 3/3] lmb: consider EFI memory map
On 2023-01-05, Heinrich Schuchardt wrote:
> Add reservations for all EFI memory areas that are not
> EFI_CONVENTIONAL_MEMORY.
>
> Signed-off-by: Heinrich Schuchardt
Tested on odroid-c2, fixes booting from extlinux.conf and boot.scr using
booti, and still works using EFI boot as well.
Thanks!
Tested-by: Vagrant Cascadian
live well,
vagrant
> ---
> v2:
> use efi_get_memory_map_alloc()
> ---
> lib/lmb.c | 36
> 1 file changed, 36 insertions(+)
>
> diff --git a/lib/lmb.c b/lib/lmb.c
> index c599608fa3..ec790760db 100644
> --- a/lib/lmb.c
> +++ b/lib/lmb.c
> @@ -7,7 +7,9 @@
> */
>
> #include
> +#include
> #include
> +#include
> #include
> #include
> #include
> @@ -153,6 +155,37 @@ void arch_lmb_reserve_generic(struct lmb *lmb, ulong sp,
> ulong end, ulong align)
> }
> }
>
> +/**
> + * efi_lmb_reserve() - add reservations for EFI memory
> + *
> + * Add reservations for all EFI memory areas that are not
> + * EFI_CONVENTIONAL_MEMORY.
> + *
> + * @lmb: lmb environment
> + * Return: 0 on success, 1 on failure
> + */
> +static __maybe_unused int efi_lmb_reserve(struct lmb *lmb)
> +{
> + struct efi_mem_desc *memmap = NULL, *map;
> + efi_uintn_t i, map_size = 0;
> + efi_status_t ret;
> +
> + ret = efi_get_memory_map_alloc(_size, );
> + if (ret != EFI_SUCCESS)
> + return 1;
> +
> + for (i = 0, map = memmap; i < map_size / sizeof(*map); ++map, ++i) {
> + if (map->type != EFI_CONVENTIONAL_MEMORY)
> + lmb_reserve(lmb,
> + map_to_sysmem((void *)(uintptr_t)
> + map->physical_start),
> + map->num_pages * EFI_PAGE_SIZE);
> + }
> + efi_free_pool(memmap);
> +
> + return 0;
> +}
> +
> static void lmb_reserve_common(struct lmb *lmb, void *fdt_blob)
> {
> arch_lmb_reserve(lmb);
> @@ -160,6 +193,9 @@ static void lmb_reserve_common(struct lmb *lmb, void
> *fdt_blob)
>
> if (CONFIG_IS_ENABLED(OF_LIBFDT) && fdt_blob)
> boot_fdt_add_mem_rsv_regions(lmb, fdt_blob);
> +
> + if (CONFIG_IS_ENABLED(EFI_LOADER))
> + efi_lmb_reserve(lmb);
> }
>
> /* Initialize the struct, add memory and call arch/board reserve functions */
signature.asc
Description: PGP signature
Re: [PATCH v2 2/3] efi_loader: carve out efi_get_memory_map_alloc()
On 2023-01-05, Heinrich Schuchardt wrote:
> Carve out code from efidebug command used to read the memory map.
>
> Signed-off-by: Heinrich Schuchardt
Tested on odroid-c2, fixes booting from extlinux.conf and boot.scr using
booti, and still works using EFI boot as well.
Thanks!
Tested-by: Vagrant Cascadian
live well,
vagrant
> ---
> v2:
> new patch
> ---
> cmd/efidebug.c | 18 --
> include/efi_loader.h| 3 +++
> lib/efi_loader/efi_memory.c | 34 ++
> 3 files changed, 41 insertions(+), 14 deletions(-)
>
> diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> index 569003ae2e..e6959ede93 100644
> --- a/cmd/efidebug.c
> +++ b/cmd/efidebug.c
> @@ -591,25 +591,15 @@ static void print_memory_attributes(u64 attributes)
> static int do_efi_show_memmap(struct cmd_tbl *cmdtp, int flag,
> int argc, char *const argv[])
> {
> - struct efi_mem_desc *memmap = NULL, *map;
> - efi_uintn_t map_size = 0;
> + struct efi_mem_desc *memmap, *map;
> + efi_uintn_t map_size;
> const char *type;
> int i;
> efi_status_t ret;
>
> - ret = efi_get_memory_map(_size, memmap, NULL, NULL, NULL);
> - if (ret == EFI_BUFFER_TOO_SMALL) {
> - map_size += sizeof(struct efi_mem_desc); /* for my own */
> - ret = efi_allocate_pool(EFI_BOOT_SERVICES_DATA, map_size,
> - (void *));
> - if (ret != EFI_SUCCESS)
> - return CMD_RET_FAILURE;
> - ret = efi_get_memory_map(_size, memmap, NULL, NULL, NULL);
> - }
> - if (ret != EFI_SUCCESS) {
> - efi_free_pool(memmap);
> + ret = efi_get_memory_map_alloc(_size, );
> + if (ret != EFI_SUCCESS)
> return CMD_RET_FAILURE;
> - }
>
> printf("Type Start%.*s End%.*s Attributes\n",
> EFI_PHYS_ADDR_WIDTH - 5, spc, EFI_PHYS_ADDR_WIDTH - 3, spc);
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 0899e293e5..02d151b715 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -734,6 +734,9 @@ efi_status_t efi_allocate_pool(enum efi_memory_type
> pool_type,
> efi_uintn_t size, void **buffer);
> /* EFI pool memory free function. */
> efi_status_t efi_free_pool(void *buffer);
> +/* Allocate and retrieve EFI memory map */
> +efi_status_t efi_get_memory_map_alloc(efi_uintn_t *map_size,
> + struct efi_mem_desc **memory_map);
> /* Returns the EFI memory map */
> efi_status_t efi_get_memory_map(efi_uintn_t *memory_map_size,
> struct efi_mem_desc *memory_map,
> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> index 8d347f101f..32254d2433 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -736,6 +736,40 @@ efi_status_t efi_get_memory_map(efi_uintn_t
> *memory_map_size,
> return EFI_SUCCESS;
> }
>
> +/**
> + * efi_get_memory_map_alloc() - allocate map describing memory usage
> + *
> + * The caller is responsible for calling FreePool() if the call succeeds.
> + *
> + * @memory_map buffer to which the memory map is written
> + * @map_size size of the memory map
> + * Return: status code
> + */
> +efi_status_t efi_get_memory_map_alloc(efi_uintn_t *map_size,
> + struct efi_mem_desc **memory_map)
> +{
> + efi_status_t ret;
> +
> + *memory_map = NULL;
> + *map_size = 0;
> + ret = efi_get_memory_map(map_size, *memory_map, NULL, NULL, NULL);
> + if (ret == EFI_BUFFER_TOO_SMALL) {
> + *map_size += sizeof(struct efi_mem_desc); /* for the map */
> + ret = efi_allocate_pool(EFI_BOOT_SERVICES_DATA, *map_size,
> + (void **)memory_map);
> + if (ret != EFI_SUCCESS)
> + return ret;
> + ret = efi_get_memory_map(map_size, *memory_map,
> + NULL, NULL, NULL);
> + if (ret != EFI_SUCCESS) {
> + efi_free_pool(*memory_map);
> + *memory_map = NULL;
> + }
> + }
> +
> + return ret;
> +}
> +
> /**
> * efi_add_conventional_memory_map() - add a RAM memory area to the map
> *
signature.asc
Description: PGP signature
Re: linksys wrt1900acs v2 boot problem
Hi all, On Fri, Jan 6, 2023 at 9:35 AM Pali Rohár wrote: > > Hello Dilyan! > > On Tuesday 28 September 2021 22:01:40 Dilyan Lazarov wrote: > > Hi, > > I have a problem with my linksys wrt1900acs. > > My main question is this a hardware problem or software problem? > > Is it possible to address? > > This looks like DDR3 training SW issue problem. Marek worked on in and > tried to address issue. He should know more details in this area. > > > I have started researching and have tried with "kwboot" under Windows VM - > > Ubuntu 20 - Linux but I have a problem with usb serial connection. I have > > tried several things but I understand that it isn't possible to start USB > > to Serial on a Windows VM. > > I will expect your response. > > Thank you in advance. > > You need to use kwboot natively. It was heavily tested on Linux and I > think it should work also on BSD systems. Windows systems are not really > supported and kwboot will not work on them. > > > All the best > > Dilyan > > > > I see the following Log from U-Boot with PuTTy under Windows 10: > > BootROM - 1.73 > > Booting from NAND flash > > > > General initialization - Version: 1.0.0 > > Detected Device ID 6820 > > High speed PHY - Version: 2.0 > > > > Init RD NAS topology Serdes Lane 3 is USB3 > > Serdes Lane 4 is SGMII > > board SerDes lanes topology details: > > | Lane # | Speed | Type | > > > > | 0| 06 | SATA0 | > > | 1| 05 | PCIe0 | > > | 2| 06 | SATA1 | > > | 3| 05 | USB3 HOST1 | > > | 4| 05 | PCIe1 | > > | 5| 00 | SGMII2 | > > > > :** Link is Gen1, check the EP capability > > PCIe, Idx 0: Link upgraded to Gen2 based on client cpabilities > > :** Link is Gen1, check the EP capability > > PCIe, Idx 1: remains Gen1 > > High speed PHY - Ended Successfully > > DDR3 Training Sequence - Ver TIP-1.26.0 > > mvSysEnvGetTopologyUpdateInfo: TWSI Read failed > > WL Supp: IF 0 busId 1 Failed ! > > WL Supp: IF 0 failed > > ddr3TipDynamicWriteLevelingSupp failure > > DRAM initialization Failed (res 0x1) > > DDR3 run algorithm - FAILED 0x1 > > DDR3 Training Sequence - FAILED > > > > > > ** DRAM initialization failed! > > -- > > Dilyan > > Could you please try to update U-Boot to the new version? If the issue > is still there? Because DDR3 marvell driver was updated and it is > possible that also your issue is fixed now too... I can confirm that on the Synology DS116 board (also Armada 385, 1GB DDR3). The last tests I ran on this board were built with u-boot-2022.07 and did not see any problem with DDR3 training. All the best, Tony
Re: [PATCH] Revert "common/memsize.c: Fix get_effective_memsize() to check for overflow"
On Fri, Jan 06, 2023 at 11:09:30PM +0100, Pali Rohár wrote: > On Friday 06 January 2023 16:45:41 Tom Rini wrote: > > On Fri, Jan 06, 2023 at 04:14:08PM -0500, Tom Rini wrote: > > > On Fri, Jan 06, 2023 at 09:22:56PM +0100, Pali Rohár wrote: > > > > On Friday 06 January 2023 12:25:24 Tom Rini wrote: > > > > > On Fri, Jan 06, 2023 at 05:45:43PM +0100, Pali Rohár wrote: > > > > > > On Friday 06 January 2023 10:51:43 Tom Rini wrote: > > > > > > > This reverts commit 777706bcfe08c284aed06886db7d482af3f8. > > > > > > > > > > > > > > The changes to this generic function, which is intended to help > > > > > > > with > > > > > > > 32bit platforms with large amounts of memory has unintended side > > > > > > > effects > > > > > > > (which in turn lead to boot failures) on other platforms which > > > > > > > were > > > > > > > previously functional. > > > > > > > > > > > > As mentioned previously, unfortunately this revert breaks 32-bit > > > > > > u-boot > > > > > > on 36-bit mpc85xx boards with 32-bit e500v2 cores and 4GB DDR > > > > > > module. > > > > > > > > > > > > Which platforms currently have broken u-boot without this revert? > > > > > > The > > > > > > only one which was reported is stm32mp but for it there different > > > > > > workaround patch waiting in the queue. > > > > > > > > > > Are you able to test on one of these PowerPC platforms currently? As > > > > > the stm32 problem shows, not everything is getting tested frequently > > > > > enough, so how many other cases are lurking out there. And, I think > > > > > overall issue is that the overflow check-and-change you introduce here > > > > > should just be in the CONFIG_MAX_MEM_MAPPED==true case. As that's the > > > > > case you're dealing with, yes? > > > > > > > > I was planning to do big retest again after all powerpc patches are > > > > reviewed and merged... > > > > > > Yes, but can you test one of them now, to see if my idea works? > > Ok, I will try to look at during the weekend. OK, good, thanks. > > > > Anyway, if the issue here is with ram_size and its reduction was needed > > > > for mpc85xx (at the time of introduction of that patch), what about > > > > putting mpc85xx ifdef around ram_size reduction? For arm boards it would > > > > have same behavior as revert of that commit and for mpc85xx it would be > > > > no change. > > This is what I mean: > > #ifdef CONFIG_MPC85xx > if (gd->ram_base + ram_size < gd->ram_base) > ram_size = ...; > #endif > > > > > I agree that this code needs to be revisited, together with ram_top > > > > issue and also code which fills DDR banks. Because really mapped memory > > > > for u-boot and real size of DDR are two different things here. > > > > > > The issue here is that we see two now (given Fabio's reminder about > > > another thread I had forgotten) of unintended consequences, on 32bit > > > platforms trying to normally have 2GB of memory, which does not require > > > special treatment. > > Running git grep get_effective_memsize and git grep 'gd->ram_top' shows > the root of this issue: Different platforms, boards and common code use > these things differently. This needs to be "fixed" = unified in whole > codebase. We need a function which returns mappable memory for u-boot > (intptr_t type is enough) and another function (or structure or > whatever) which says total size of RAM as u64 type (to ensure that it > would work also for 4GB SODIMM modules on pure 32-bit platforms). And > then each place in u-boot code has to be modified to use the correct > function. > > Second issue is then gd->ram_top. Either say 4GB for 32-bit ram_top type > is not supported or say that zero value is special and represents 4GB. > And also every place in u-boot code needs to be adjusted by this > decision / code. > > Fixing both issues make easily break lot of boards (if done improperly) > as it touches whole u-boot code base. So not easy task. > > > What I'm leaning towards right now even, is that since it's hard to test > > the non-36bit platforms that do set CONFIG_MAX_MEM_MAPPED, to see if > > their behavior also changed here, the 36bit platforms should just be > > overriding get_effective_memsize. > > There are (at least) 3 situation: > 1) if RAM is mapped to the end of physical address space (possibly just >small e.g. 1GB) > 2) if platform is >32-bit but running in 32-bit mode (so physical >address is u64 because we do not have e.g. int36_t; but void* is >32-bit) > 3) if RAM is exactly 4GB and u-boot is 32-bit > > And every one has different edge cases and cause different problems. > Now, as I pointed above that every platform / board is using > get_effective_memsize() differently, plus we have CONFIG_MAX_MEM_MAPPED > option, it means that number of test matrix is really huge. > > It looks like that ARM issues are caused by the fact that RAM is mapped > to the end of the physical address space (so it does not matter how big > or small it is). And powerpc issue
Pull request efi-2023-01-rc5-4
The following changes since commit 9ddcdcc03cc6f0f46895604c589af17fdbdfe8b7: Merge tag 'u-boot-stm32-20230106' of https://gitlab.denx.de/u-boot/custodians/u-boot-stm (2023-01-06 08:16:15 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2023-01-rc5-4 for you to fetch changes up to 4bba71ff83e2b2a1607c5b3b9995767691242b29: efi_loader: make .data section of *_efi.so files RW (2023-01-06 22:27:30 +0100) Gitlab CI showed no issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/14631 Bbooting via EFI and via booti/bootz was susccessful on * Orange Pi PC * Pine A64 LTS Pull request efi-2023-01-rc5-4 UEFI: * correct the vexpress loaddr which collides with memory used by EFI * consider the EFI memory map for LMB memory reservation * avoid RWX section warnings for .data section of *_efi.so files Heinrich Schuchardt (4): vexpress: adjust loadaddr efi_loader: carve out efi_get_memory_map_alloc() lmb: consider EFI memory map efi_loader: make .data section of *_efi.so files RW arch/arm/lib/elf_aarch64_efi.lds | 8 +++- cmd/efidebug.c| 18 -- include/configs/vexpress_common.h | 1 + include/efi_loader.h | 3 +++ lib/efi_loader/efi_memory.c | 34 ++ lib/lmb.c | 36 6 files changed, 85 insertions(+), 15 deletions(-)
Re: [PATCH] Revert "common/memsize.c: Fix get_effective_memsize() to check for overflow"
On Friday 06 January 2023 16:45:41 Tom Rini wrote: > On Fri, Jan 06, 2023 at 04:14:08PM -0500, Tom Rini wrote: > > On Fri, Jan 06, 2023 at 09:22:56PM +0100, Pali Rohár wrote: > > > On Friday 06 January 2023 12:25:24 Tom Rini wrote: > > > > On Fri, Jan 06, 2023 at 05:45:43PM +0100, Pali Rohár wrote: > > > > > On Friday 06 January 2023 10:51:43 Tom Rini wrote: > > > > > > This reverts commit 777706bcfe08c284aed06886db7d482af3f8. > > > > > > > > > > > > The changes to this generic function, which is intended to help with > > > > > > 32bit platforms with large amounts of memory has unintended side > > > > > > effects > > > > > > (which in turn lead to boot failures) on other platforms which were > > > > > > previously functional. > > > > > > > > > > As mentioned previously, unfortunately this revert breaks 32-bit > > > > > u-boot > > > > > on 36-bit mpc85xx boards with 32-bit e500v2 cores and 4GB DDR module. > > > > > > > > > > Which platforms currently have broken u-boot without this revert? The > > > > > only one which was reported is stm32mp but for it there different > > > > > workaround patch waiting in the queue. > > > > > > > > Are you able to test on one of these PowerPC platforms currently? As > > > > the stm32 problem shows, not everything is getting tested frequently > > > > enough, so how many other cases are lurking out there. And, I think > > > > overall issue is that the overflow check-and-change you introduce here > > > > should just be in the CONFIG_MAX_MEM_MAPPED==true case. As that's the > > > > case you're dealing with, yes? > > > > > > I was planning to do big retest again after all powerpc patches are > > > reviewed and merged... > > > > Yes, but can you test one of them now, to see if my idea works? Ok, I will try to look at during the weekend. > > > Anyway, if the issue here is with ram_size and its reduction was needed > > > for mpc85xx (at the time of introduction of that patch), what about > > > putting mpc85xx ifdef around ram_size reduction? For arm boards it would > > > have same behavior as revert of that commit and for mpc85xx it would be > > > no change. This is what I mean: #ifdef CONFIG_MPC85xx if (gd->ram_base + ram_size < gd->ram_base) ram_size = ...; #endif > > > I agree that this code needs to be revisited, together with ram_top > > > issue and also code which fills DDR banks. Because really mapped memory > > > for u-boot and real size of DDR are two different things here. > > > > The issue here is that we see two now (given Fabio's reminder about > > another thread I had forgotten) of unintended consequences, on 32bit > > platforms trying to normally have 2GB of memory, which does not require > > special treatment. Running git grep get_effective_memsize and git grep 'gd->ram_top' shows the root of this issue: Different platforms, boards and common code use these things differently. This needs to be "fixed" = unified in whole codebase. We need a function which returns mappable memory for u-boot (intptr_t type is enough) and another function (or structure or whatever) which says total size of RAM as u64 type (to ensure that it would work also for 4GB SODIMM modules on pure 32-bit platforms). And then each place in u-boot code has to be modified to use the correct function. Second issue is then gd->ram_top. Either say 4GB for 32-bit ram_top type is not supported or say that zero value is special and represents 4GB. And also every place in u-boot code needs to be adjusted by this decision / code. Fixing both issues make easily break lot of boards (if done improperly) as it touches whole u-boot code base. So not easy task. > What I'm leaning towards right now even, is that since it's hard to test > the non-36bit platforms that do set CONFIG_MAX_MEM_MAPPED, to see if > their behavior also changed here, the 36bit platforms should just be > overriding get_effective_memsize. There are (at least) 3 situation: 1) if RAM is mapped to the end of physical address space (possibly just small e.g. 1GB) 2) if platform is >32-bit but running in 32-bit mode (so physical address is u64 because we do not have e.g. int36_t; but void* is 32-bit) 3) if RAM is exactly 4GB and u-boot is 32-bit And every one has different edge cases and cause different problems. Now, as I pointed above that every platform / board is using get_effective_memsize() differently, plus we have CONFIG_MAX_MEM_MAPPED option, it means that number of test matrix is really huge. It looks like that ARM issues are caused by the fact that RAM is mapped to the end of the physical address space (so it does not matter how big or small it is). And powerpc issue is 4GB of RAM together with running in 32-bit mode. Anyway, has U-Boot support for 32-bit x86 CPUs with PAE support? If yes, then I bet that there can be other edge cases when e.g. 8GB of DDR is connected.
Re: kwboot : bug when board stops acking
Hello,
On Fri, Jan 6, 2023 at 9:52 AM Pali Rohár wrote:
>
> Hello Stephane!
>
> On Wednesday 08 January 2020 15:21:12 SC wrote:
> > Hi list,
> >
> > I think there's a bug in kwboot.
> > I have a faulty board that stops acking xmodem frames after a certain
> > number of packets and kwboot
> > instead of exiting continues to send frames up to 100%.
> > With the one second retry timer it's very long! More than 2 hours :-(
>
> I saw very similar bugs in kwboot and together with Marek we fixed lot
> of issues in kwboot.
>
> Could you test if last version of kwboot from U-Boot git master branch
> has still same or similar issue?
>
> > The bug is in the kwboot_xm_sendblock() fonction :
> > https://gitlab.denx.de/u-boot/u-boot/blob/master/tools/kwboot.c#L375
> > kwboot_tty_recv detects the timeout but the return value is based on the
> > last character received
> > (line 403)
> > The variable c is not initialized so if it keeps the previous value which
> > is ACK => rc=0 => infinite
> > loop
> >
> > There are several ways to fix the bug:
> > * Surround the "switch(c)" with a test:
> > if ( !((rc == -1) && (errno == ETIMEDOUT)) ) {
> > rc = -1;
> > switch (c) {
> > case ACK:
> > rc = 0;
> > break;
> > case NAK:
> > errno = EBADMSG;
> > break;
> > case CAN:
> > errno = ECANCELED;
> > break;
> > default:
> > errno = EPROTO;
> > break;
> > }
> > }
> > return rc;
> > * In the case of a TIMEOUT set c to a specific value and add the case in
> > the switch
> >
I've been running the latest kwboot (2023.01-rc4), and I did not see
this problem. And the current code looks OK to me. c is modified
before it is used later:
https://github.com/u-boot/u-boot/blob/master/tools/kwboot.c#L1238
And the function kwboot_xm_sendblock() in GitHub is line L1215!
https://github.com/u-boot/u-boot/blob/master/tools/kwboot.c#L1215
Probably Stephane is running an older version of kwboot?
Best,
Tony
> > Do you agree with my diagnosis?
> > What is the best solution to fix this bug?
> > Should I provide a patch?
> >
> > Thank you,
> > Stephane
Re: [PATCH] Revert "common/memsize.c: Fix get_effective_memsize() to check for overflow"
On Fri, Jan 06, 2023 at 04:14:08PM -0500, Tom Rini wrote: > On Fri, Jan 06, 2023 at 09:22:56PM +0100, Pali Rohár wrote: > > On Friday 06 January 2023 12:25:24 Tom Rini wrote: > > > On Fri, Jan 06, 2023 at 05:45:43PM +0100, Pali Rohár wrote: > > > > On Friday 06 January 2023 10:51:43 Tom Rini wrote: > > > > > This reverts commit 777706bcfe08c284aed06886db7d482af3f8. > > > > > > > > > > The changes to this generic function, which is intended to help with > > > > > 32bit platforms with large amounts of memory has unintended side > > > > > effects > > > > > (which in turn lead to boot failures) on other platforms which were > > > > > previously functional. > > > > > > > > As mentioned previously, unfortunately this revert breaks 32-bit u-boot > > > > on 36-bit mpc85xx boards with 32-bit e500v2 cores and 4GB DDR module. > > > > > > > > Which platforms currently have broken u-boot without this revert? The > > > > only one which was reported is stm32mp but for it there different > > > > workaround patch waiting in the queue. > > > > > > Are you able to test on one of these PowerPC platforms currently? As > > > the stm32 problem shows, not everything is getting tested frequently > > > enough, so how many other cases are lurking out there. And, I think > > > overall issue is that the overflow check-and-change you introduce here > > > should just be in the CONFIG_MAX_MEM_MAPPED==true case. As that's the > > > case you're dealing with, yes? > > > > I was planning to do big retest again after all powerpc patches are > > reviewed and merged... > > Yes, but can you test one of them now, to see if my idea works? > > > Anyway, if the issue here is with ram_size and its reduction was needed > > for mpc85xx (at the time of introduction of that patch), what about > > putting mpc85xx ifdef around ram_size reduction? For arm boards it would > > have same behavior as revert of that commit and for mpc85xx it would be > > no change. > > > > I agree that this code needs to be revisited, together with ram_top > > issue and also code which fills DDR banks. Because really mapped memory > > for u-boot and real size of DDR are two different things here. > > The issue here is that we see two now (given Fabio's reminder about > another thread I had forgotten) of unintended consequences, on 32bit > platforms trying to normally have 2GB of memory, which does not require > special treatment. What I'm leaning towards right now even, is that since it's hard to test the non-36bit platforms that do set CONFIG_MAX_MEM_MAPPED, to see if their behavior also changed here, the 36bit platforms should just be overriding get_effective_memsize. -- Tom signature.asc Description: PGP signature
Re: [PATCH] Revert "common/memsize.c: Fix get_effective_memsize() to check for overflow"
On Fri, Jan 06, 2023 at 09:22:56PM +0100, Pali Rohár wrote: > On Friday 06 January 2023 12:25:24 Tom Rini wrote: > > On Fri, Jan 06, 2023 at 05:45:43PM +0100, Pali Rohár wrote: > > > On Friday 06 January 2023 10:51:43 Tom Rini wrote: > > > > This reverts commit 777706bcfe08c284aed06886db7d482af3f8. > > > > > > > > The changes to this generic function, which is intended to help with > > > > 32bit platforms with large amounts of memory has unintended side effects > > > > (which in turn lead to boot failures) on other platforms which were > > > > previously functional. > > > > > > As mentioned previously, unfortunately this revert breaks 32-bit u-boot > > > on 36-bit mpc85xx boards with 32-bit e500v2 cores and 4GB DDR module. > > > > > > Which platforms currently have broken u-boot without this revert? The > > > only one which was reported is stm32mp but for it there different > > > workaround patch waiting in the queue. > > > > Are you able to test on one of these PowerPC platforms currently? As > > the stm32 problem shows, not everything is getting tested frequently > > enough, so how many other cases are lurking out there. And, I think > > overall issue is that the overflow check-and-change you introduce here > > should just be in the CONFIG_MAX_MEM_MAPPED==true case. As that's the > > case you're dealing with, yes? > > I was planning to do big retest again after all powerpc patches are > reviewed and merged... Yes, but can you test one of them now, to see if my idea works? > Anyway, if the issue here is with ram_size and its reduction was needed > for mpc85xx (at the time of introduction of that patch), what about > putting mpc85xx ifdef around ram_size reduction? For arm boards it would > have same behavior as revert of that commit and for mpc85xx it would be > no change. > > I agree that this code needs to be revisited, together with ram_top > issue and also code which fills DDR banks. Because really mapped memory > for u-boot and real size of DDR are two different things here. The issue here is that we see two now (given Fabio's reminder about another thread I had forgotten) of unintended consequences, on 32bit platforms trying to normally have 2GB of memory, which does not require special treatment. -- Tom signature.asc Description: PGP signature
Re: [PATCH] Revert "common/memsize.c: Fix get_effective_memsize() to check for overflow"
On Fri, Jan 6, 2023 at 12:51 PM Tom Rini wrote:
>
> This reverts commit 777706bcfe08c284aed06886db7d482af3f8.
>
> The changes to this generic function, which is intended to help with
> 32bit platforms with large amounts of memory has unintended side effects
> (which in turn lead to boot failures) on other platforms which were
> previously functional.
>
> Reported-by: Marek Vasut
> Cc: Patrick Delaunay
> Cc: Pali Rohár
> Signed-off-by: Tom Rini
Peng also reported an imx issue caused by 777706bc
(""common/memsize.c: Fix get_effective_memsize() to check for
overflow""):
https://patchwork.ozlabs.org/project/uboot/patch/20221107080016.1304-2-peng@oss.nxp.com/
Re: [PATCH] Revert "common/memsize.c: Fix get_effective_memsize() to check for overflow"
On Friday 06 January 2023 12:25:24 Tom Rini wrote: > On Fri, Jan 06, 2023 at 05:45:43PM +0100, Pali Rohár wrote: > > On Friday 06 January 2023 10:51:43 Tom Rini wrote: > > > This reverts commit 777706bcfe08c284aed06886db7d482af3f8. > > > > > > The changes to this generic function, which is intended to help with > > > 32bit platforms with large amounts of memory has unintended side effects > > > (which in turn lead to boot failures) on other platforms which were > > > previously functional. > > > > As mentioned previously, unfortunately this revert breaks 32-bit u-boot > > on 36-bit mpc85xx boards with 32-bit e500v2 cores and 4GB DDR module. > > > > Which platforms currently have broken u-boot without this revert? The > > only one which was reported is stm32mp but for it there different > > workaround patch waiting in the queue. > > Are you able to test on one of these PowerPC platforms currently? As > the stm32 problem shows, not everything is getting tested frequently > enough, so how many other cases are lurking out there. And, I think > overall issue is that the overflow check-and-change you introduce here > should just be in the CONFIG_MAX_MEM_MAPPED==true case. As that's the > case you're dealing with, yes? I was planning to do big retest again after all powerpc patches are reviewed and merged... Anyway, if the issue here is with ram_size and its reduction was needed for mpc85xx (at the time of introduction of that patch), what about putting mpc85xx ifdef around ram_size reduction? For arm boards it would have same behavior as revert of that commit and for mpc85xx it would be no change. I agree that this code needs to be revisited, together with ram_top issue and also code which fills DDR banks. Because really mapped memory for u-boot and real size of DDR are two different things here.
Re: [PATCH 0/4] Enable gigadevice and add new part #s
Hi, Michal, On 1/5/23 20:47, Vlim wrote: >> Regarding the location of the entry, I believe you want me to add the entry >> in >> the alphabetical order? > > Not really. I want to you follow Kconfig layout which is what make > savedefconfig > && cp defconfig configs/ is for. > > Can you be more specific on this requirement? > I believe this is pertaining to the defconfig files. > Where is the correct line to insert the following entry? > CONFIG_SPI_FLASH_GIGADEVICE=y Again. Just enable that option and run for example make xilinx_zynqmp_virt_defconfig echo CONFIG_SPI_FLASH_GIGADEVICE=y >> .config make savedefconfig cp defconfig configs/xilinx_zynqmp_virt_defconfig git commit -a -s And that's it. Your symbol will be added to proper location. I did the make command, but it says nothing to be done. Do I need to install an additional software package in order to perform this function? victor@victor-17Z990-R-AAC9U1:~/Desktop/u-boot-xlnx/configs$ make zynq_cse_qspi_defconfig make: Nothing to be done for 'zynq_cse_qspi_defconfig'. victor@victor-17Z990-R-AAC9U1:~/Desktop/u-boot-xlnx/configs$ Regards, Victor
[PATCH v2] ARM: omap3: evm: Name this directory omap3evm
Before this was named just evm, which doesn't match the naming
of the other TI board file directory and makes it look like a
common directory for evms. Name this omap3evm.
Signed-off-by: Andrew Davis
---
Changes from v1:
- Call dir omap3evm instead of omap3
arch/arm/mach-omap2/omap3/Kconfig | 2 +-
board/ti/{evm => omap3evm}/Kconfig | 2 +-
board/ti/{evm => omap3evm}/MAINTAINERS | 2 +-
board/ti/{evm => omap3evm}/Makefile| 0
board/ti/{evm => omap3evm}/evm.c | 0
board/ti/{evm => omap3evm}/evm.h | 0
6 files changed, 3 insertions(+), 3 deletions(-)
rename board/ti/{evm => omap3evm}/Kconfig (86%)
rename board/ti/{evm => omap3evm}/MAINTAINERS (85%)
rename board/ti/{evm => omap3evm}/Makefile (100%)
rename board/ti/{evm => omap3evm}/evm.c (100%)
rename board/ti/{evm => omap3evm}/evm.h (100%)
diff --git a/arch/arm/mach-omap2/omap3/Kconfig
b/arch/arm/mach-omap2/omap3/Kconfig
index 3e97ec26295..671e4791c67 100644
--- a/arch/arm/mach-omap2/omap3/Kconfig
+++ b/arch/arm/mach-omap2/omap3/Kconfig
@@ -163,7 +163,7 @@ config SYS_SOC
source "board/logicpd/am3517evm/Kconfig"
source "board/ti/beagle/Kconfig"
source "board/timll/devkit8000/Kconfig"
-source "board/ti/evm/Kconfig"
+source "board/ti/omap3evm/Kconfig"
source "board/isee/igep00x0/Kconfig"
source "board/logicpd/omap3som/Kconfig"
source "board/nokia/rx51/Kconfig"
diff --git a/board/ti/evm/Kconfig b/board/ti/omap3evm/Kconfig
similarity index 86%
rename from board/ti/evm/Kconfig
rename to board/ti/omap3evm/Kconfig
index 4f490ddd9d5..08a8aa20ae8 100644
--- a/board/ti/evm/Kconfig
+++ b/board/ti/omap3evm/Kconfig
@@ -1,7 +1,7 @@
if TARGET_OMAP3_EVM
config SYS_BOARD
- default "evm"
+ default "omap3evm"
config SYS_VENDOR
default "ti"
diff --git a/board/ti/evm/MAINTAINERS b/board/ti/omap3evm/MAINTAINERS
similarity index 85%
rename from board/ti/evm/MAINTAINERS
rename to board/ti/omap3evm/MAINTAINERS
index cd315c1635b..fb4268b312f 100644
--- a/board/ti/evm/MAINTAINERS
+++ b/board/ti/omap3evm/MAINTAINERS
@@ -1,6 +1,6 @@
EVM BOARD
M: Derald D. Woods
S: Maintained
-F: board/ti/evm/
+F: board/ti/omap3evm/
F: include/configs/omap3_evm.h
F: configs/omap3_evm_defconfig
diff --git a/board/ti/evm/Makefile b/board/ti/omap3evm/Makefile
similarity index 100%
rename from board/ti/evm/Makefile
rename to board/ti/omap3evm/Makefile
diff --git a/board/ti/evm/evm.c b/board/ti/omap3evm/evm.c
similarity index 100%
rename from board/ti/evm/evm.c
rename to board/ti/omap3evm/evm.c
diff --git a/board/ti/evm/evm.h b/board/ti/omap3evm/evm.h
similarity index 100%
rename from board/ti/evm/evm.h
rename to board/ti/omap3evm/evm.h
--
2.38.1
Re: Pull request for u-boot-nand-20230104
On Thu, Jan 05, 2023 at 09:10:55AM +0100, Dario Binacchi wrote: > Hi Tom, > > The following changes since commit a95410696d21d38b629c61a09c100197c5fc533a: > > Merge branch '2023-01-02-platform-updates' into next (2023-01-02 > 18:07:41 -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-nand-flash.git > tags/u-boot-nand-20230104 > > for you to fetch changes up to 48f219cb16f88cd2e392e2f438409a00d3ddff54: > > mtd: rawnand: omap_elm: u-boot driver model support (2023-01-04 > 17:24:30 +0100) > > Gitlab CI showed no issues: > https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/14597 > NAK. This commit: commit 48f219cb16f88cd2e392e2f438409a00d3ddff54 Author: Roger Quadros Date: Tue Dec 20 12:22:03 2022 +0200 mtd: rawnand: omap_elm: u-boot driver model support Support u-boot driver model. We still retain support legacy way of doing things if ELM_BASE is defined in We could completely get rid of that if all platforms defining ELM_BASE get rid of that definition and enable CONFIG_SYS_NAND_SELF_INIT and are verified to work. Signed-off-by: Roger Quadros Signed-off-by: Michael Trimarchi Breaks am335x_evm thusly: U-Boot SPL 2023.01-rc4-00388-g48f219cb16f8-dirty (Jan 06 2023 - 13:56:52 -0500) Trying to boot from MMC1 U-Boot 2023.01-rc4-00388-g48f219cb16f8-dirty (Jan 06 2023 - 13:56:52 -0500) CPU : AM335X-GP rev 2.1 Model: TI AM335x EVM DRAM: 1 GiB Error binding driver 'omap-elm': -96 Some drivers failed to bind Error binding driver 'ti_sysc': -96 Some drivers failed to bind Error binding driver 'simple_bus': -96 Some drivers failed to bind Error binding driver 'simple_bus': -96 Some drivers failed to bind Error binding driver 'simple_bus': -96 Some drivers failed to bind initcall sequence bffdbbe0 failed at call 808155a9 (err=-96) ### ERROR ### Please RESET the board ### -- Tom signature.asc Description: PGP signature
Re: [PATCH] ARM: omap3: evm: Name this directory omap3
On Fri, Jan 06, 2023 at 12:13:12PM -0600, Andrew Davis wrote:
> On 10/7/22 10:21 PM, Derald Woods wrote:
> > On Fri, Oct 07, 2022 at 12:33:14PM -0500, Andrew Davis wrote:
> > > Before this was named just evm, which doesn't match the naming
> > > of the other TI board file directory and makes it look like a
> > > common directory for evms. Name this omap3.
> > >
> > > Signed-off-by: Andrew Davis
> > > ---
> > > arch/arm/mach-omap2/omap3/Kconfig | 2 +-
> > > board/ti/{evm => omap3}/Kconfig | 2 +-
> > > board/ti/{evm => omap3}/MAINTAINERS | 2 +-
> > > board/ti/{evm => omap3}/Makefile| 0
> > > board/ti/{evm => omap3}/evm.c | 0
> > > board/ti/{evm => omap3}/evm.h | 0
> > > 6 files changed, 3 insertions(+), 3 deletions(-)
> > > rename board/ti/{evm => omap3}/Kconfig (87%)
> > > rename board/ti/{evm => omap3}/MAINTAINERS (87%)
> > > rename board/ti/{evm => omap3}/Makefile (100%)
> > > rename board/ti/{evm => omap3}/evm.c (100%)
> > > rename board/ti/{evm => omap3}/evm.h (100%)
> > >
> > > diff --git a/arch/arm/mach-omap2/omap3/Kconfig
> > > b/arch/arm/mach-omap2/omap3/Kconfig
> > > index 3e97ec2629..4e9924faf7 100644
> > > --- a/arch/arm/mach-omap2/omap3/Kconfig
> > > +++ b/arch/arm/mach-omap2/omap3/Kconfig
> > > @@ -163,7 +163,7 @@ config SYS_SOC
> > > source "board/logicpd/am3517evm/Kconfig"
> > > source "board/ti/beagle/Kconfig"
> > > source "board/timll/devkit8000/Kconfig"
> > > -source "board/ti/evm/Kconfig"
> > > +source "board/ti/omap3/Kconfig"
> > > source "board/isee/igep00x0/Kconfig"
> > > source "board/logicpd/omap3som/Kconfig"
> > > source "board/nokia/rx51/Kconfig"
> > > diff --git a/board/ti/evm/Kconfig b/board/ti/omap3/Kconfig
> > > similarity index 87%
> > > rename from board/ti/evm/Kconfig
> > > rename to board/ti/omap3/Kconfig
> > > index 4f490ddd9d..d60b229a4e 100644
> > > --- a/board/ti/evm/Kconfig
> > > +++ b/board/ti/omap3/Kconfig
> > > @@ -1,7 +1,7 @@
> > > if TARGET_OMAP3_EVM
> > >
> > > config SYS_BOARD
> > > - default "evm"
> > > + default "omap3"
> > >
> > > config SYS_VENDOR
> > >default "ti"
> > > diff --git a/board/ti/evm/MAINTAINERS b/board/ti/omap3/MAINTAINERS
> > > similarity index 87%
> > > rename from board/ti/evm/MAINTAINERS
> > > rename to board/ti/omap3/MAINTAINERS
> > > index cd315c1635..95b34bbd11 100644
> > > --- a/board/ti/evm/MAINTAINERS
> > > +++ b/board/ti/omap3/MAINTAINERS
> > > @@ -1,6 +1,6 @@
> > > EVM BOARD
> > > M: Derald D. Woods
> > > S: Maintained
> > > -F: board/ti/evm/
> > > +F: board/ti/omap3/
> > > F: include/configs/omap3_evm.h
> > > F: configs/omap3_evm_defconfig
> > > diff --git a/board/ti/evm/Makefile b/board/ti/omap3/Makefile
> > > similarity index 100%
> > > rename from board/ti/evm/Makefile
> > > rename to board/ti/omap3/Makefile
> > > diff --git a/board/ti/evm/evm.c b/board/ti/omap3/evm.c
> > > similarity index 100%
> > > rename from board/ti/evm/evm.c
> > > rename to board/ti/omap3/evm.c
> > > diff --git a/board/ti/evm/evm.h b/board/ti/omap3/evm.h
> > > similarity index 100%
> > > rename from board/ti/evm/evm.h
> > > rename to board/ti/omap3/evm.h
> > > --
> > > 2.37.3
> > >
> >
> > It seems to me that something like 'omap3evm' would be more appropriate
> > for a directory name. Using just 'omap3' may be too generic. The actual
> > EVM configurations are TMDSEVM3530 [1] and TMDSEVM3730 [2], with the
> > corresponding processor boards attached. It would also align with the
> > TARGET_OMAP3_EVM definition still in use. These are my observations.
> >
>
> I'm not sure about that, the convention seems to be the directory name
> matches the SoC, then the source files match for each type/name of
> board. This is at least true for some newer TI boards, but I agree it
> is not always followed for the older devices. I have no strong preference
> either way, just as long as we can not call it "board/ti/evm" like it
> is now..
>
> This patch still applies to the latest u-boot, or I can send a v2.
I'd like a v2 of "omap3evm" please, we have other omap3 platforms still
so it would just be a different confusion I feel (and most of the other
board/ti/SOC/ directories support the EVM + SK + other stuff model,
while this is just the 3530/3730 boards that are iirc otherwise very
similar). Thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] ARM: omap3: evm: Name this directory omap3
On 10/7/22 10:21 PM, Derald Woods wrote:
On Fri, Oct 07, 2022 at 12:33:14PM -0500, Andrew Davis wrote:
Before this was named just evm, which doesn't match the naming
of the other TI board file directory and makes it look like a
common directory for evms. Name this omap3.
Signed-off-by: Andrew Davis
---
arch/arm/mach-omap2/omap3/Kconfig | 2 +-
board/ti/{evm => omap3}/Kconfig | 2 +-
board/ti/{evm => omap3}/MAINTAINERS | 2 +-
board/ti/{evm => omap3}/Makefile| 0
board/ti/{evm => omap3}/evm.c | 0
board/ti/{evm => omap3}/evm.h | 0
6 files changed, 3 insertions(+), 3 deletions(-)
rename board/ti/{evm => omap3}/Kconfig (87%)
rename board/ti/{evm => omap3}/MAINTAINERS (87%)
rename board/ti/{evm => omap3}/Makefile (100%)
rename board/ti/{evm => omap3}/evm.c (100%)
rename board/ti/{evm => omap3}/evm.h (100%)
diff --git a/arch/arm/mach-omap2/omap3/Kconfig
b/arch/arm/mach-omap2/omap3/Kconfig
index 3e97ec2629..4e9924faf7 100644
--- a/arch/arm/mach-omap2/omap3/Kconfig
+++ b/arch/arm/mach-omap2/omap3/Kconfig
@@ -163,7 +163,7 @@ config SYS_SOC
source "board/logicpd/am3517evm/Kconfig"
source "board/ti/beagle/Kconfig"
source "board/timll/devkit8000/Kconfig"
-source "board/ti/evm/Kconfig"
+source "board/ti/omap3/Kconfig"
source "board/isee/igep00x0/Kconfig"
source "board/logicpd/omap3som/Kconfig"
source "board/nokia/rx51/Kconfig"
diff --git a/board/ti/evm/Kconfig b/board/ti/omap3/Kconfig
similarity index 87%
rename from board/ti/evm/Kconfig
rename to board/ti/omap3/Kconfig
index 4f490ddd9d..d60b229a4e 100644
--- a/board/ti/evm/Kconfig
+++ b/board/ti/omap3/Kconfig
@@ -1,7 +1,7 @@
if TARGET_OMAP3_EVM
config SYS_BOARD
- default "evm"
+ default "omap3"
config SYS_VENDOR
default "ti"
diff --git a/board/ti/evm/MAINTAINERS b/board/ti/omap3/MAINTAINERS
similarity index 87%
rename from board/ti/evm/MAINTAINERS
rename to board/ti/omap3/MAINTAINERS
index cd315c1635..95b34bbd11 100644
--- a/board/ti/evm/MAINTAINERS
+++ b/board/ti/omap3/MAINTAINERS
@@ -1,6 +1,6 @@
EVM BOARD
M: Derald D. Woods
S: Maintained
-F: board/ti/evm/
+F: board/ti/omap3/
F: include/configs/omap3_evm.h
F: configs/omap3_evm_defconfig
diff --git a/board/ti/evm/Makefile b/board/ti/omap3/Makefile
similarity index 100%
rename from board/ti/evm/Makefile
rename to board/ti/omap3/Makefile
diff --git a/board/ti/evm/evm.c b/board/ti/omap3/evm.c
similarity index 100%
rename from board/ti/evm/evm.c
rename to board/ti/omap3/evm.c
diff --git a/board/ti/evm/evm.h b/board/ti/omap3/evm.h
similarity index 100%
rename from board/ti/evm/evm.h
rename to board/ti/omap3/evm.h
--
2.37.3
It seems to me that something like 'omap3evm' would be more appropriate
for a directory name. Using just 'omap3' may be too generic. The actual
EVM configurations are TMDSEVM3530 [1] and TMDSEVM3730 [2], with the
corresponding processor boards attached. It would also align with the
TARGET_OMAP3_EVM definition still in use. These are my observations.
I'm not sure about that, the convention seems to be the directory name
matches the SoC, then the source files match for each type/name of
board. This is at least true for some newer TI boards, but I agree it
is not always followed for the older devices. I have no strong preference
either way, just as long as we can not call it "board/ti/evm" like it
is now..
This patch still applies to the latest u-boot, or I can send a v2.
Andrew
- Derald
[1]
https://www.digikey.com/en/products/detail/texas-instruments/TMDSEVM3530/2232584
[2]
https://www.digikey.com/en/products/detail/texas-instruments/TMDSEVM3730/2627669
[3]
https://media.digikey.com/pdf/Data%20Sheets/Texas%20Instruments%20PDFs/tmdsevm3730.pdf
[4]
https://media.digikey.com/pdf/Data%20Sheets/Texas%20Instruments%20PDFs/TMDSEVM3530.pdf
[PATCH] common: bouncebuf: Use dma-mapping for cache ops
This matches how this would be done in Linux and these functions
do the alignment for us which makes the code look cleaner.
Signed-off-by: Andrew Davis
---
common/bouncebuf.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/common/bouncebuf.c b/common/bouncebuf.c
index 6d98920de66..93a35668cc2 100644
--- a/common/bouncebuf.c
+++ b/common/bouncebuf.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
static int addr_aligned(struct bounce_buffer *state)
{
@@ -59,9 +60,9 @@ int bounce_buffer_start_extalign(struct bounce_buffer *state,
void *data,
* Flush data to RAM so DMA reads can pick it up,
* and any CPU writebacks don't race with DMA writes
*/
- flush_dcache_range((unsigned long)state->bounce_buffer,
- (unsigned long)(state->bounce_buffer) +
- state->len_aligned);
+ dma_map_single(state->bounce_buffer,
+ state->len_aligned,
+ DMA_BIDIRECTIONAL);
return 0;
}
@@ -78,9 +79,9 @@ int bounce_buffer_stop(struct bounce_buffer *state)
{
if (state->flags & GEN_BB_WRITE) {
/* Invalidate cache so that CPU can see any newly DMA'd data */
- invalidate_dcache_range((unsigned long)state->bounce_buffer,
- (unsigned long)(state->bounce_buffer) +
- state->len_aligned);
+ dma_unmap_single((dma_addr_t)state->bounce_buffer,
+state->len_aligned,
+DMA_BIDIRECTIONAL);
}
if (state->bounce_buffer == state->user_buffer)
--
2.38.1
Re: kwboot : bug when board stops acking
Hello Stephane!
On Wednesday 08 January 2020 15:21:12 SC wrote:
> Hi list,
>
> I think there's a bug in kwboot.
> I have a faulty board that stops acking xmodem frames after a certain number
> of packets and kwboot
> instead of exiting continues to send frames up to 100%.
> With the one second retry timer it's very long! More than 2 hours :-(
I saw very similar bugs in kwboot and together with Marek we fixed lot
of issues in kwboot.
Could you test if last version of kwboot from U-Boot git master branch
has still same or similar issue?
> The bug is in the kwboot_xm_sendblock() fonction :
> https://gitlab.denx.de/u-boot/u-boot/blob/master/tools/kwboot.c#L375
> kwboot_tty_recv detects the timeout but the return value is based on the last
> character received
> (line 403)
> The variable c is not initialized so if it keeps the previous value which is
> ACK => rc=0 => infinite
> loop
>
> There are several ways to fix the bug:
> * Surround the "switch(c)" with a test:
> if ( !((rc == -1) && (errno == ETIMEDOUT)) ) {
> rc = -1;
> switch (c) {
> case ACK:
> rc = 0;
> break;
> case NAK:
> errno = EBADMSG;
> break;
> case CAN:
> errno = ECANCELED;
> break;
> default:
> errno = EPROTO;
> break;
> }
> }
> return rc;
> * In the case of a TIMEOUT set c to a specific value and add the case in the
> switch
>
> Do you agree with my diagnosis?
> What is the best solution to fix this bug?
> Should I provide a patch?
>
> Thank you,
> Stephane
Re: Netgear RN102 U-Boot Nand Driver Modification
Hello Abdus! On Thursday 24 September 2020 17:26:49 Abdus Rainey wrote: > I have recently modded a Netgear RN102 NAND flash from 128 MB to 4096 MB > (Samsung k9gbg08u0a) but i have a problem with NAND initialization. > I can boot with kwboot which is unique for Armada CPU's. > > Here is my log from kwboot with my stock mtd0: > > > root at whitepawnxeon:/home/jigsaw/Downloads# kwboot -t -B 115200 > /dev/ttyUSB0 -b mtd0stockuboot.img -p > Sending boot message. Please reboot the target...- > Sending boot image... > 0 % [..] ... > 5 % [. > > General initialization - Version: 1.0.0 > > High speed PHY - Version: 2.1.4 (COM-PHY-V20) > Update PEX Device ID 0x6710 > High speed PHY - Ended Successfully > > DDR3 Training Sequence - Ver 5.7.1 > DDR3 Training Sequence - Run without PBS. > DDR3 Training Sequence - Ended Successfully > .] > 5 % [..] ... > 99 % [..] > [Type Ctrl-\ + c to quit] > > __ __ _ _ > | \/ | __ _ _ _| | | > | |\/| |/ _` | '__\ \ / / _ \ | | > | | | | (_| | | \ V / __/ | | > |_| |_|\__,_|_|\_/ \___|_|_| > _ _ _ > | | | | | __ ) ___ ___ | |_ > | | | |___| _ \ / _ \ / _ \| __| > | |_| |___| |_) | (_) | (_) | |_ > \___/|/ \___/ \___/ \__| > ** LOADER ** > > > U-Boot 2011.12-gec25d27-dirty (Oct 26 2015 - 16:53:05) Marvell version: > v2011.12 2014_T2.0p1 > 06/23/2015 ReadyNAS-102 V2.0 > > Board: DB-88F6710-BP > SoC: MV6710 A1 > CPU: Marvell PJ4B v7 UP (Rev 1) LE >CPU@ 1200 [MHz] >L2 @ 600 [MHz] >TClock @ 200 [MHz] >DDR@ 600 [MHz] >DDR 16Bit Width, FastPath Memory Access > DRAM: 512 MiB > > Map: Code: 0x1feef000:0x1ff9ef34 >BSS: 0x1ffef0a0 >Stack: 0x1f9eeef8 >Heap: 0x1f9ef000:0x1feef000 > > NAND: (ID 0xd7ec) nand_get_flash_type: second ID read did not match ac,d7 > against ec,52 > No NAND device found!!! > 0 MiB This error message means that your u-boot does not have a driver for your NAND memory. Or it has driver, but it is missing manufacturer id, so driver correctly binds to that NAND device. > As you can see u-boot sees device id and manufacturer id but cannot recognize > it.My stock u-boot is very old and i get u-boot source code from Netgear > GPL.(ReadyNASOS_V6.6.0_WW_src.zip) > In here https://forum.doozan.com/read.php?2,106589,108204#msg-108204 you can > see my whole story about this device. > Can someone suggest any solution? I would suggest to update to the new U-Boot version. This is really old version. Also look into U-Boot source code if NAND drivers support this id. If id is not supported then it is possible that change would be relatively easy if id is just missing in the supported list.
Re: linksys wrt1900acs v2 boot problem
Hello Dilyan! On Tuesday 28 September 2021 22:01:40 Dilyan Lazarov wrote: > Hi, > I have a problem with my linksys wrt1900acs. > My main question is this a hardware problem or software problem? > Is it possible to address? This looks like DDR3 training SW issue problem. Marek worked on in and tried to address issue. He should know more details in this area. > I have started researching and have tried with "kwboot" under Windows VM - > Ubuntu 20 - Linux but I have a problem with usb serial connection. I have > tried several things but I understand that it isn't possible to start USB > to Serial on a Windows VM. > I will expect your response. > Thank you in advance. You need to use kwboot natively. It was heavily tested on Linux and I think it should work also on BSD systems. Windows systems are not really supported and kwboot will not work on them. > All the best > Dilyan > > I see the following Log from U-Boot with PuTTy under Windows 10: > BootROM - 1.73 > Booting from NAND flash > > General initialization - Version: 1.0.0 > Detected Device ID 6820 > High speed PHY - Version: 2.0 > > Init RD NAS topology Serdes Lane 3 is USB3 > Serdes Lane 4 is SGMII > board SerDes lanes topology details: > | Lane # | Speed | Type | > > | 0| 06 | SATA0 | > | 1| 05 | PCIe0 | > | 2| 06 | SATA1 | > | 3| 05 | USB3 HOST1 | > | 4| 05 | PCIe1 | > | 5| 00 | SGMII2 | > > :** Link is Gen1, check the EP capability > PCIe, Idx 0: Link upgraded to Gen2 based on client cpabilities > :** Link is Gen1, check the EP capability > PCIe, Idx 1: remains Gen1 > High speed PHY - Ended Successfully > DDR3 Training Sequence - Ver TIP-1.26.0 > mvSysEnvGetTopologyUpdateInfo: TWSI Read failed > WL Supp: IF 0 busId 1 Failed ! > WL Supp: IF 0 failed > ddr3TipDynamicWriteLevelingSupp failure > DRAM initialization Failed (res 0x1) > DDR3 run algorithm - FAILED 0x1 > DDR3 Training Sequence - FAILED > > > ** DRAM initialization failed! > -- > Dilyan Could you please try to update U-Boot to the new version? If the issue is still there? Because DDR3 marvell driver was updated and it is possible that also your issue is fixed now too...
Re: [PATCH] Revert "common/memsize.c: Fix get_effective_memsize() to check for overflow"
On Fri, Jan 06, 2023 at 05:45:43PM +0100, Pali Rohár wrote: > On Friday 06 January 2023 10:51:43 Tom Rini wrote: > > This reverts commit 777706bcfe08c284aed06886db7d482af3f8. > > > > The changes to this generic function, which is intended to help with > > 32bit platforms with large amounts of memory has unintended side effects > > (which in turn lead to boot failures) on other platforms which were > > previously functional. > > As mentioned previously, unfortunately this revert breaks 32-bit u-boot > on 36-bit mpc85xx boards with 32-bit e500v2 cores and 4GB DDR module. > > Which platforms currently have broken u-boot without this revert? The > only one which was reported is stm32mp but for it there different > workaround patch waiting in the queue. Are you able to test on one of these PowerPC platforms currently? As the stm32 problem shows, not everything is getting tested frequently enough, so how many other cases are lurking out there. And, I think overall issue is that the overflow check-and-change you introduce here should just be in the CONFIG_MAX_MEM_MAPPED==true case. As that's the case you're dealing with, yes? -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: stm32mp: Fix board_get_usable_ram_top() again
Hi Marek,
On 1/5/23 02:22, Marek Vasut wrote:
Do not access gd->ram_size and assume this is actual valid RAM size. Since
commit
777706b ("common/memsize.c: Fix get_effective_memsize() to check for
overflow")
the RAM size may be less than gd->ram_size , call get_effective_memsize() to get
the limited value instead.
The aforementioned commit makes STM32MP15xx boards with 1 GiB of DRAM
at 0xc000 hang on boot, which is a grave defect.
Signed-off-by: Marek Vasut
---
Cc: Pali Rohar
Cc: Patrice Chotard
Cc: Patrick Delaunay
Cc: Tom Rini
---
arch/arm/mach-stm32mp/dram_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-stm32mp/dram_init.c
b/arch/arm/mach-stm32mp/dram_init.c
index 9346fa8546d..80ba5c27741 100644
--- a/arch/arm/mach-stm32mp/dram_init.c
+++ b/arch/arm/mach-stm32mp/dram_init.c
@@ -51,7 +51,7 @@ phys_size_t board_get_usable_ram_top(phys_size_t total_size)
/* found enough not-reserved memory to relocated U-Boot */
lmb_init();
- lmb_add(, gd->ram_base, gd->ram_size);
+ lmb_add(, gd->ram_base, get_effective_memsize());
boot_fdt_add_mem_rsv_regions(, (void *)gd->fdt_blob);
/* add 8M for reserved memory for display, fdt, gd,... */
size = ALIGN(SZ_8M + CONFIG_SYS_MALLOC_LEN + total_size,
MMU_SECTION_SIZE),
Applied to u-boot-stm/master, thanks!
For my point a view , this patch is an acceptable workaround for master
branch and v2023.01 delivery.
but the initial commit 777706b ("common/memsize.c: Fix
get_effective_memsize() to
check should be revisited or reverted (in master or in next ?).
For details see comments in patch
"arm: stm32mp: Fix board_get_usable_ram_top() again"
http://patchwork.ozlabs.org/project/uboot/patch/2023010501.238075-1-ma...@denx.de/
https://lore.kernel.org/u-boot/2023010501.238075-1-ma...@denx.de/
Regards
Patrick
Re: [PULL] Pull request for u-boot master / v2023.01 = u-boot-stm32-20230106
On Fri, Jan 06, 2023 at 11:48:54AM +0100, Patrick DELAUNAY wrote:
> Hi Tom,
>
> Please pull the STM32 related fixes for u-boot/master, v2023.01:
> u-boot-stm32-20230106
>
>
> - stm32mp: Fix board_get_usable_ram_top(): workaround to avoid issue after
> the
>
> commit 777706b ("common/memsize.c: Fix get_effective_memsize() to
> check
>
> for overflow") because the effective DDR effective size is reduce by 4KiB
> and sometime the board hang on boot
>
>
> CI status:
> https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/14623
>
>
> This last patch for v2023.01 avoids a hang on 1GB DDR STM32MP15 board
> detected
>
> by Marek and caused by Pali patch.
>
>
> For my point a view , this patch is an acceptable workaround for master
> branch and v2023.01 delivery
>
> but the initial patch should be revisited or reverted (in master or in next
> ?).
>
>
> For details see comments in patch
>
> "arm: stm32mp: Fix board_get_usable_ram_top() again"
>
> http://patchwork.ozlabs.org/project/uboot/patch/2023010501.238075-1-ma...@denx.de/
>
> https://lore.kernel.org/u-boot/2023010501.238075-1-ma...@denx.de/
Yes, I want to see how this progresses, thanks for taking a work-around
for now. But for now I have also posted a revert, to help spur
discussion.
>
> Thanks,
> Patrick
>
> =
>
>
> The following changes since commit 8d6cbf5e6bc4e10e38b954763fa025caed517cc2:
>
> Merge tag 'efi-2023-01-rc5-3' of
> https://source.denx.de/u-boot/custodians/u-boot-efi (2023-01-04 08:50:24
> -0500)
>
> are available in the Git repository at:
>
> https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git
> tags/u-boot-stm32-20230106
>
> for you to fetch changes up to a2e0b041d662e4c80502cd5c9a8326d026f9deb1:
>
> arm: stm32mp: Fix board_get_usable_ram_top() again (2023-01-06 11:02:17
> +0100)
>
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] arm: rmobile: rzg2_beacon: Enable alternative Ethernet PHY
On Wed, Jan 04, 2023 at 12:05:43PM -0600, Adam Ford wrote: > Due to the part shortage, the AR8031 PHY was replaced with a > Micrel KSZ9131. Enabling both config options keeps backward > compatibility with either platform, and both appear to be > auto-detected. > > Signed-off-by: Adam Ford > Reviewed-by: Marek Vasut > > diff --git a/configs/rzg2_beacon_defconfig b/configs/rzg2_beacon_defconfig > index 36787057a2..b4ea6c630a 100644 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: dts: rz-g2-beacon-u-boot: Fix QSPI Regression
On Wed, Jan 04, 2023 at 09:53:09AM -0600, Adam Ford wrote:
> The QSPI is accessed via the RPC-IF, but the compatible flags
> previously used a different name. This compatibel name was changed
> which broke the ability to access the QSPI. Fix this by removing
> the custom naming reference.
>
> Fixes: 68083b897b57 ("renesas: Fix RPC-IF compatible values")
> Signed-off-by: Adam Ford
> Reviewed-by: Marek Vasut
>
> diff --git a/arch/arm/dts/rz-g2-beacon-u-boot.dtsi
> b/arch/arm/dts/rz-g2-beacon-u-boot.dtsi
> index 4d17854918..da1c3b0939 100644
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] pylibfdt: Fix disable version normalization
On Wed, Jan 04, 2023 at 03:43:33PM +0100, Philippe Schenker wrote:
> From: Philippe Schenker
>
> On Arch Linux based systems python setuptools does not contain
> "setuptools.extern" hence it is failing with the following
> error-message:
> "
> ModuleNotFoundError: No module named 'setuptools.extern'
> "
>
> According to a eschwartz `setuptools.extern` is not a public API and
> shall not be assumed to be present in the setuptools package. He
> mentions that the setuptools project anyway wants to drop this. [1]
>
> Use the correct solution introduced by python setuptools developers to
> disable normalization. [2]
>
> [1] https://bbs.archlinux.org/viewtopic.php?id=259608
> [2] https://github.com/pypa/setuptools/pull/2026
> Fixes: 440098c42e73 ("pylibfdt: Fix version normalization warning")
> Signed-off-by: Philippe Schenker
> Reviewed-by: Marek Vasut
> Reviewed-by: Simon Glass
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] rockchip: Fix the broken Video out for rk3288 boards
On Mon, Jan 02, 2023 at 11:53:45PM +0530, Jagan Teki wrote:
> Video out on RK3288 boards has been broken since from few
> releases due to the adding of reset support on vop but
> missed enabling DM_RESET on associated boards.
>
> This patch fixes those RK3288 boards.
>
> Cc: Simon Glass
> Cc: Lin Huang
> Cc: Jernej Skrabec
> Cc: Michael Trimarchi
> Cc: Arnaud Patard (Rtp)
> Fixes: <9749d2ea29e1> ("rockchip: video: vop: Add reset support")
> Reported-by: Manoj Sai
> Signed-off-by: Jagan Teki
> Reviewed-by: Simon Glass
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] imx7d-pico: Fix the name of the u-boot.dtsi file
On Sat, Dec 31, 2022 at 01:25:14PM -0300, Fabio Estevam wrote:
> Since commit 2f96d4dd95f8 ("imx7s/d: synchronise device trees with linux")
> the imx7d-pico board no longer boots.
>
> The reason is that prior to the above commit there was an explicit
> inclusion of arch/arm/dts/imx7d-pico-u-boot.dtsi inside imx7d-pico.dtsi.
>
> After the syncing with the Linux upstream dtsi, this u-boot.dtsi inclusion
> is gone and the board fails to boot.
>
> U-Boot uses the imx7d-pico-pi.dtb file, so rename the u-boot.dtsi to
> imx7d-pico-pi-u-boot.dtsi which gets included automatically by U-Boot
> standard make logic and makes the board boot again.
>
> Signed-off-by: Fabio Estevam
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH u-boot] powerpc/mpc85xx: socrates: Re-enable building u-boot-socrates.bin
On Wed, Dec 28, 2022 at 07:18:39PM +0100, Pali Rohár wrote:
> U-Boot build system builds final U-Boot binary for socrates board in custom
> file u-boot-socrates.bin (instead of standard u-boot.bin). Output target
> file u-boot-socrates.bin is generated by binman as defined in board binman
> config file arch/powerpc/dts/socrates-u-boot.dtsi.
>
> But binman was disabled in commit 5af42eafd7e1 ("Makefile: Reduce usage of
> custom mpc85xx u-boot.bin target") for all mpc85xx boards which do not use
> standard powerpc binman config file arch/powerpc/dts/u-boot.dtsi and boards
> which do not require binman at all.
>
> The only such mpc85xx board is socrates. So since that commit, U-Boot does
> not final binary for socrates board anymore.
>
> Fix this issue by re-enabling binman for socrates board. And build process
> starts again producing u-boot-socrates.bin binary.
>
> Note that build process for this socrates board always produce u-boot.bin
> binary which is broken and not usable for socrates board. Long term
> solution should be to disable building broken binary u-boot.bin and then
> renaming u-boot-socrates.bin to u-boot.bin, or switching to use common
> powerpc binman config file arch/powerpc/dts/socrates-u-boot.dtsi (if it is
> possible).
>
> Fixes: 5af42eafd7e1 ("Makefile: Reduce usage of custom mpc85xx u-boot.bin
> target")
> Signed-off-by: Pali Rohár
> Tested-by: Heiko Schocher
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] Revert "Revert "cmd: pxe_utils: Check fdtcontroladdr in label_boot""
On Sat, Dec 17, 2022 at 06:41:13PM +0100, Marek Vasut wrote: > This reverts commit ed6251187afabf811a5fd49a44ebd61c53c7b378. > > Superseded by "cmd: pxe_utils: Limit fdtcontroladdr usage to non-fitImage" > which is less heavy-handed approach and retains part of the original > behavior for non-fitImage. > > Signed-off-by: Marek Vasut > Acked-by: Neil Armstrong Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] cmd: pxe_utils: Limit fdtcontroladdr usage to non-fitImage
On Wed, Dec 14, 2022 at 07:45:18AM +0100, Marek Vasut wrote:
> Commit d5ba6188dfb ("cmd: pxe_utils: Check fdtcontroladdr in label_boot")
> forces '$fdtcontroladdr' DT address as a third parameter of bootm command
> even if the PXE transfer pulls in a fitImage which contains configuration
> node with its own DT that is preferrable to be passed to Linux. Limit the
> $fdtcontroladdr fallback utilization to non-fitImages, since it is highly
> likely a fitImage would come with its own DT, while single-file images do
> need a separate DT.
>
> Fixes: d5ba6188dfb ("cmd: pxe_utils: Check fdtcontroladdr in label_boot")
> Signed-off-by: Marek Vasut
> Reviewed-by: Quentin Schulz
> Tested-by: Quentin Schulz
> Reviewed-by: Simon Glass
> Reviewed-by: Peter Hoyes
> Tested-by: Peter Hoyes
> Reviewed-by: Neil Armstrong
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] i2c: uniphier-f: correct error recovery
On Fri, Dec 09, 2022 at 08:38:27PM +0900, Dai Okamura wrote: > The uniphier i2c block can recognize some handshake errors. > But driver handles all error detections as no error if no timeout. > So this makes unrecoverable state. > > This replaces the return values with the right ones to tell the i2c > framework the errors: > - EDEADLK for arbitration lost error > - ENODATA for no answer error > > Signed-off-by: Dai Okamura > Acked-by: Kunihiko Hayashi > Reviewed-by: Heiko Schocher Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] Revert "common/memsize.c: Fix get_effective_memsize() to check for overflow"
On Friday 06 January 2023 10:51:43 Tom Rini wrote:
> This reverts commit 777706bcfe08c284aed06886db7d482af3f8.
>
> The changes to this generic function, which is intended to help with
> 32bit platforms with large amounts of memory has unintended side effects
> (which in turn lead to boot failures) on other platforms which were
> previously functional.
As mentioned previously, unfortunately this revert breaks 32-bit u-boot
on 36-bit mpc85xx boards with 32-bit e500v2 cores and 4GB DDR module.
Which platforms currently have broken u-boot without this revert? The
only one which was reported is stm32mp but for it there different
workaround patch waiting in the queue.
> Reported-by: Marek Vasut
> Cc: Patrick Delaunay
> Cc: Pali Rohár
> Signed-off-by: Tom Rini
> ---
> common/memsize.c | 18 +++---
> 1 file changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/common/memsize.c b/common/memsize.c
> index 3c80ad2c8346..31884acca0df 100644
> --- a/common/memsize.c
> +++ b/common/memsize.c
> @@ -94,23 +94,11 @@ long get_ram_size(long *base, long maxsize)
>
> phys_size_t __weak get_effective_memsize(void)
> {
> - phys_size_t ram_size = gd->ram_size;
> -
> - /*
> - * Check for overflow and limit ram size to some representable value.
> - * It is required that ram_base + ram_size must be representable by
> - * phys_size_t type and must be aligned by direct access, therefore
> - * calculate it from last 4kB sector which should work as alignment
> - * on any platform.
> - */
> - if (gd->ram_base + ram_size < gd->ram_base)
> - ram_size = ((phys_size_t)~0xfffULL) - gd->ram_base;
> -
> #ifndef CONFIG_MAX_MEM_MAPPED
> - return ram_size;
> + return gd->ram_size;
> #else
> /* limit stack to what we can reasonable map */
> - return ((ram_size > CONFIG_MAX_MEM_MAPPED) ?
> - CONFIG_MAX_MEM_MAPPED : ram_size);
> + return ((gd->ram_size > CONFIG_MAX_MEM_MAPPED) ?
> + CONFIG_MAX_MEM_MAPPED : gd->ram_size);
> #endif
> }
> --
> 2.25.1
>
Re: [PATCH v2] usb: gadget: fastboot: detach usb just before rebooting
On Thu, Jan 05, 2023 at 14:25, Dario Binacchi
wrote:
> Hi Mattijs,
>
> On Thu, Jan 5, 2023 at 12:03 PM Mattijs Korpershoek
> wrote:
>>
>> On Thu, Jan 05, 2023 at 10:10, Dario Binacchi
>> wrote:
>>
>> > Hi Mattijs,
>> >
>> > On Thu, Jan 5, 2023 at 10:06 AM Mattijs Korpershoek
>> > wrote:
>> >>
>> >> On Wed, Jan 04, 2023 at 17:46, Dario Binacchi
>> >> wrote:
>> >>
>> >> > The patch fixes the following error when updating a BSH SMM S2 board:
>> >> > 3:72>Start Cmd:FB[-t 8000]: ucmd nand write ${loadaddr} nanddtb
>> >> > ${filesize}
>> >> > 3:72>Okay (0.023s)
>> >> > 3:72>Start Cmd:FB: reboot
>> >> > 3:72>Fail Bulk(R):LIBUSB_ERROR_IO(0s)
>> >> >
>> >> > The "fastboot reboot" command detaches the USB when it still needs to be
>> >> > used. So let's detach the USB just before the reset.
>> >> >
>> >> > CC: Mattijs Korpershoek
>> >> > Fixes: 5f7e01e9d5d800 ("usb: gadget: fastboot: detach usb on reboot
>> >> > commands")
>> >> > Suggested-by: Michael Trimarchi
>> >> > Signed-off-by: Dario Binacchi
>> >>
>> >> Hi Dario,
>> >>
>> >> Thank you for your patch and for reporting the problem.
>> >>
>> >> Unfortunately, applying it seems to break the problem I tried to
>> >> solve with 5f7e01e9d5d800 ("usb: gadget: fastboot: detach usb on reboot
>> >> commands")
>> >>
>> >> Does reverting 5f7e01e9d5d800 also solves your issue?
>> >
>> > Yes
>> >
>> >>
>> >> I'll spend some time on this.
>> >
>> > Ok, thanks. So we can test on our hardware.
>>
>> So historically, I wanted to make this a "arch specific fix, as
>> discussed in
>> https://lore.kernel.org/u-boot/20220728-reset-usb-controller-v2-0-ef7657ce7...@baylibre.com/
>>
>> To me, the problem with calling g_dnl_trigger_detach() in the
>> fastboot_func->in_req->complete() handler is that it's called too late.
>>
>> In fact, the main fastboot loop is as following:
>>
>> while (1) {
>> if (g_dnl_detach())
>> break;
>> if (ctrlc())
>> break;
>> schedule();
>> usb_gadget_handle_interrupts(controller_index);
>> }
>> ret = CMD_RET_SUCCESS;
>>
>> exit:
>> usb_gadget_release(controller_index);
>> g_dnl_unregister();
>> g_dnl_clear_detach();
>>
>> return ret;
>>
>> usb_gadget_handle_interrupts, will at some point, call complete() which will
>> call compl_do_reset().
>> But in compl_do_reset(), we already reset the board
>> (without going through the exit: section from cmd/fastboot.c)
>>
>> For the BSH SMM S2 board, since it's being updated with uuu,
>> I assume that the host PC also triggers a call of acmd_complete() afterwards?
>>
>> Can you try the following diff as well, on top of your change? (for testing
>> purposes)
>>
>> --- a/drivers/usb/gadget/f_fastboot.c
>> +++ b/drivers/usb/gadget/f_fastboot.c
>> @@ -492,7 +492,7 @@ static void do_bootm_on_complete(struct usb_ep *ep,
>> struct usb_request *req)
>>
>> static void compl_do_reset(struct usb_ep *ep, struct usb_request *req)
>> {
>> - do_exit_on_complete(ep, req);
>> + usb_gadget_release(0);
>> do_reset(NULL, 0, 0, NULL);
>> }
>>
>> I suspect this will also break your flashing.
>
> No, I am able to flash and reset the board.
> This change works.
With some additional testing on my end, I can see that the final message
(sending OKAY to the host) done on fastboot_func->in_ep is not done on
my end. I think I am lucky that my controller driver (dwc2_udc_otg)
delivers the message to my host anyways and calls done() even when
messages are aborted.
I think I have something that might be better.
Dario, could you do another test for me, please?
1. Revert 5f7e01e9d5d800 ("usb: gadget: fastboot: detach usb on reboot
commands")
2. Apply the following diff:
diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index d0e92c7a071f..f4311328a2da 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -421,6 +421,7 @@ static int fastboot_tx_write_str(const char *buffer)
static void compl_do_reset(struct usb_ep *ep, struct usb_request *req)
{
+ g_dnl_unregister();
do_reset(NULL, 0, 0, NULL);
}
The call to g_dnl_unregister() will end up calling
g_dnl_unbind() which calls usb_gadget_disconnect()
where each controller can implement a soft disconnect (which I can do
for dwc2_udc_otg)
>
>>
>> > Regards Dario
>> >
>> >>
>> >> >
>> >> > ---
>> >> >
>> >> > Changes in v2:
>> >> > - Add 'Suggested-by' tag.
>> >> >
>> >> > drivers/usb/gadget/f_fastboot.c | 12 ++--
>> >> > 1 file changed, 6 insertions(+), 6 deletions(-)
>> >> >
>> >> > diff --git a/drivers/usb/gadget/f_fastboot.c
>> >> > b/drivers/usb/gadget/f_fastboot.c
>> >> > index 07b1681c8a9a..0b3fae564d0a 100644
>> >> > --- a/drivers/usb/gadget/f_fastboot.c
>> >> > +++ b/drivers/usb/gadget/f_fastboot.c
>> >> > @@ -419,11 +419,6 @@ static int fastboot_tx_write_str(const char
>> >> > *buffer)
>> >> > return fastboot_tx_write(buffer,
Re: [PATCH] arm: stm32mp: Fix board_get_usable_ram_top() again
On Friday 06 January 2023 10:13:34 Patrick DELAUNAY wrote:
> Hi,
>
> On 1/5/23 20:25, Pali Rohar wrote:
> > Ok, so it is working...
> >
> > On Thursday 05 January 2023 19:31:19 Patrick DELAUNAY wrote:
> > > I tested on STM32MP157C-EV1 on my side...
> > >
> > > with 1GiB mermory size
> > >
> > > U-Boot is booting on next TOP (for trusted boot with TF-A and OP-TEE)
> > >
> > >
> > >
> > > U-Boot 2023.01-rc4-00386-gb429e78942de (Jan 05 2023 - 17:44:04 +0100)
> > >
> > > stm32_smc: Failed to exec svc=82001003 op=1 in secure mode (err = -1)
> > > stm32_smc: Failed to exec svc=82001003 op=1 in secure mode (err = -1)
> > > CPU: STM32MP157C?? Rev.Z
> > > Model: STMicroelectronics STM32MP157C eval daughter on eval mother
> > > Board: stm32mp1 in trusted mode (st,stm32mp157c-ev1)
> > > stm32_smc: Failed to exec svc=82001003 op=1 in secure mode (err = -1)
> > > DRAM: 1 GiB
> > >
> > >
> > >
> > > STM32MP> bdinfo
> > > boot_params = 0x
> > > DRAM bank = 0x
> > > -> start = 0xc000
> > > -> size = 0x3000 << the patch is applied - 4kiB here
> > > !!!
> > But this is wrong. DRAM bank size should not be changed. I think that in
> > U-Boot is another issue which propagates mapped U-Boot RAM size/range to
> > the places where should be real DDR size.
>
>
> Yes it is wrong
>
> and it is introduced by your patch...
>
>
> in the STM32MP15x platfrorm are using the genric weak function
>
>
> ./common/board_f.c:267
>
>
> __weak int dram_init_banksize(void)
> {
> gd->bd->bi_dram[0].start = gd->ram_base;
> gd->bd->bi_dram[0].size = get_effective_memsize();
>
> return 0;
> }
>
> For me:
>
> get_effective_memsize() must return the effective size of the DDR
>
> and NOT -4KiB to avoid side effects in other part of the code (LMB for
> example)
Ok, this needs to be reworked. But seems it is not just simple issue.
>
> I think today we need to revert your patch.
Hard revert without anything else is not the solution. As it will break
all 36-bit powerpc boards with 4GB of DDR RAM on which is u-boot running
in 32-bit mode.
Re: [PATCH v3 03/25] bootmenu: Add a few comments
On 1/6/23 15:52, Simon Glass wrote:
The behaviour of these two functions is completely undocumented. Add some
notes so the poor, suffering dev can figure out what is going on.
Signed-off-by: Simon Glass
---
(no changes since v1)
include/menu.h | 42 ++
1 file changed, 42 insertions(+)
diff --git a/include/menu.h b/include/menu.h
index 702aacb170c..0b4d9734149 100644
--- a/include/menu.h
+++ b/include/menu.h
@@ -42,6 +42,7 @@ struct bootmenu_data {
struct bootmenu_entry *first; /* first menu entry */
};
+/** enum bootmenu_key - keys that can be returned by the bootmenu */
enum bootmenu_key {
KEY_NONE = 0,
KEY_UP,
@@ -53,8 +54,49 @@ enum bootmenu_key {
KEY_SPACE,
};
+/**
+ * bootmenu_autoboot_loop() - handle autobooting if no key is pressed
+ *
+ * This shows a prompt to allow the user to press a key to interrupt auto boot
+ * of the first menu option.
+ *
+ * It then waits for the required time (menu->delay in seconds) for a key to be
+ * pressed. If nothing is pressed in that time, @key returns KEY_SELECT
+ * indicating that the current option should be chosen.
+ *
+ * @menu: Menu being processed
+ * @key: Returns the code for the key the user pressed:
+ * enter: KEY_SELECT
+ * Ctrl-C: KEY_QUIT
+ * anything else: KEY_NONE
+ * @esc: Set to 1 if the escape key is pressed, otherwise not updated
+ */
void bootmenu_autoboot_loop(struct bootmenu_data *menu,
enum bootmenu_key *key, int *esc);
+
+/**
+ * bootmenu_loop() - handle waiting for a keypress when autoboot is disabled
+ *
+ * This is used when the menu delay is negative, indicating that the delay has
+ * elapsed, or there was no delay to begin with.
+ *
+ * It reads a character and processes it, returning a menu-key code if a
+ * character is recognised
+ *
+ * @menu: Menu being processed
+ * @key: Returns the code for the key the user pressed:
+ * enter: KEY_SELECT
+ * Ctrl-C: KEY_QUIT
+ * Up arrow: KEY_UP
+ * Down arrow: KEY_DOWN
+ * Escape (by itself): KEY_QUIT
+ * Plus: KEY_PLUS
+ * Minus: KEY_MINUS
+ * Space: KEY_SPACE
+ * @esc: On input, a non-zero value indicates that an escape sequence has
+ * resulted in that many characters so far. On exit this is updated to the
+ * new number of characters
+ */
void bootmenu_loop(struct bootmenu_data *menu,
enum bootmenu_key *key, int *esc);
This should not be an exported function. The program part that wants to
display a menu should not have to deal with navigation keys.
Best regards
Heinrich
[PATCH] Revert "common/memsize.c: Fix get_effective_memsize() to check for overflow"
This reverts commit 777706bcfe08c284aed06886db7d482af3f8.
The changes to this generic function, which is intended to help with
32bit platforms with large amounts of memory has unintended side effects
(which in turn lead to boot failures) on other platforms which were
previously functional.
Reported-by: Marek Vasut
Cc: Patrick Delaunay
Cc: Pali Rohár
Signed-off-by: Tom Rini
---
common/memsize.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/common/memsize.c b/common/memsize.c
index 3c80ad2c8346..31884acca0df 100644
--- a/common/memsize.c
+++ b/common/memsize.c
@@ -94,23 +94,11 @@ long get_ram_size(long *base, long maxsize)
phys_size_t __weak get_effective_memsize(void)
{
- phys_size_t ram_size = gd->ram_size;
-
- /*
-* Check for overflow and limit ram size to some representable value.
-* It is required that ram_base + ram_size must be representable by
-* phys_size_t type and must be aligned by direct access, therefore
-* calculate it from last 4kB sector which should work as alignment
-* on any platform.
-*/
- if (gd->ram_base + ram_size < gd->ram_base)
- ram_size = ((phys_size_t)~0xfffULL) - gd->ram_base;
-
#ifndef CONFIG_MAX_MEM_MAPPED
- return ram_size;
+ return gd->ram_size;
#else
/* limit stack to what we can reasonable map */
- return ((ram_size > CONFIG_MAX_MEM_MAPPED) ?
- CONFIG_MAX_MEM_MAPPED : ram_size);
+ return ((gd->ram_size > CONFIG_MAX_MEM_MAPPED) ?
+ CONFIG_MAX_MEM_MAPPED : gd->ram_size);
#endif
}
--
2.25.1
Re: [PATCH v3 02/25] cli: Move readline character-processing to a state machine
On 1/6/23 15:52, Simon Glass wrote:
The current cread_line() function is very long. It handles the escape
processing inline. The menu command does similar processing but at the
character level, so there is some duplication.
Split the character processing into a new function cli_ch_process() which
processes individual characters and returns the resulting input character,
taking account of escape sequences. It requires the caller to set up and
maintain its state.
Update cread_line() to use this new function.
The only intended functional change is that an invalid escape sequence
does not add invalid/control characters into the input buffer, but instead
discards these.
Signed-off-by: Simon Glass
---
(no changes since v1)
common/Makefile | 6 +-
common/cli_getch.c| 204 ++
common/cli_readline.c | 150 +--
include/cli.h | 72 +++
4 files changed, 301 insertions(+), 131 deletions(-)
create mode 100644 common/cli_getch.c
diff --git a/common/Makefile b/common/Makefile
index 20addfb244c..67485e77a04 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -38,7 +38,7 @@ obj-$(CONFIG_SPLASH_SOURCE) += splash_source.o
obj-$(CONFIG_MENU) += menu.o
obj-$(CONFIG_UPDATE_COMMON) += update.o
obj-$(CONFIG_USB_KEYBOARD) += usb_kbd.o
-obj-$(CONFIG_CMDLINE) += cli_readline.o cli_simple.o
+obj-$(CONFIG_CMDLINE) += cli_getch.o cli_readline.o cli_simple.o
endif # !CONFIG_SPL_BUILD
@@ -93,8 +93,8 @@ obj-y += eeprom/eeprom_field.o eeprom/eeprom_layout.o
endif
obj-y += cli.o
-obj-$(CONFIG_FSL_DDR_INTERACTIVE) += cli_simple.o cli_readline.o
-obj-$(CONFIG_STM32MP1_DDR_INTERACTIVE) += cli_simple.o cli_readline.o
+obj-$(CONFIG_FSL_DDR_INTERACTIVE) += cli_getch.o cli_simple.o cli_readline.o
+obj-$(CONFIG_STM32MP1_DDR_INTERACTIVE) += cli_getch.o cli_simple.o
cli_readline.o
obj-$(CONFIG_DFU_OVER_USB) += dfu.o
obj-y += command.o
obj-$(CONFIG_$(SPL_TPL_)LOG) += log.o
diff --git a/common/cli_getch.c b/common/cli_getch.c
new file mode 100644
index 000..9eeea7fef29
--- /dev/null
+++ b/common/cli_getch.c
@@ -0,0 +1,204 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2000
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * Copyright 2022 Google LLC
+ */
+
+#include
+#include
+
+/**
+ * enum cli_esc_state_t - indicates what to do with an escape character
+ *
+ * @ESC_REJECT: Invalid escape sequence, so the esc_save[] characters are
+ * returned from each subsequent call to cli_ch_esc()
+ * @ESC_SAVE: Character should be saved in esc_save until we have another one
+ * @ESC_CONVERTED: Escape sequence has been completed and the resulting
+ * character is available
+ */
+enum cli_esc_state_t {
+ ESC_REJECT,
+ ESC_SAVE,
+ ESC_CONVERTED
+};
+
+void cli_ch_init(struct cli_ch_state *cch)
+{
+ memset(cch, '\0', sizeof(*cch));
+}
+
+/**
+ * cli_ch_esc() - Process a character in an ongoing escape sequence
+ *
+ * @cch: State information
+ * @ichar: Character to process
+ * @actp: Returns the action to take
+ * Returns: Output character if *actp is ESC_CONVERTED, else 0
+ */
+static int cli_ch_esc(struct cli_ch_state *cch, int ichar,
+ enum cli_esc_state_t *actp)
+{
+ enum cli_esc_state_t act = ESC_REJECT;
+
+ switch (cch->esc_len) {
+ case 1:
+ if (ichar == '[' || ichar == 'O')
+ act = ESC_SAVE;
+ break;
+ case 2:
+ switch (ichar) {
+ case 'D': /* <- key */
+ ichar = CTL_CH('b');
+ act = ESC_CONVERTED;
+ break; /* pass off to ^B handler */
+ case 'C': /* -> key */
+ ichar = CTL_CH('f');
+ act = ESC_CONVERTED;
+ break; /* pass off to ^F handler */
+ case 'H': /* Home key */
+ ichar = CTL_CH('a');
+ act = ESC_CONVERTED;
+ break; /* pass off to ^A handler */
+ case 'F': /* End key */
+ ichar = CTL_CH('e');
+ act = ESC_CONVERTED;
+ break; /* pass off to ^E handler */
+ case 'A': /* up arrow */
+ ichar = CTL_CH('p');
+ act = ESC_CONVERTED;
+ break; /* pass off to ^P handler */
+ case 'B': /* down arrow */
+ ichar = CTL_CH('n');
+ act = ESC_CONVERTED;
+ break; /* pass off to ^N handler */
+ case '1':
+ case '2':
+ case '3':
+ case '4':
+ case '7':
+ case '8':
+ if (cch->esc_save[1] == '[') {
+ /* see if
Re: [PATCH 1/2] efi_loader: refine set_keyboard_layout() status
On 1/6/23 10:46, Vincent Stehlé wrote:
As per the EFI specification, the HII database protocol function
set_keyboard_layout() must return EFI_INVALID_PARAMETER when it is called
with a NULL key_guid argument. Modify the function accordingly to improve
conformance.
Signed-off-by: Vincent Stehlé
Cc: Heinrich Schuchardt
Cc: Ilias Apalodimas
---
lib/efi_loader/efi_hii.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/efi_loader/efi_hii.c b/lib/efi_loader/efi_hii.c
index 27db3be6a17..3b54ecb11ac 100644
--- a/lib/efi_loader/efi_hii.c
+++ b/lib/efi_loader/efi_hii.c
@@ -758,6 +758,9 @@ set_keyboard_layout(const struct efi_hii_database_protocol
*this,
{
EFI_ENTRY("%p, %pUs", this, key_guid);
+ if (!key_guid)
+ return EFI_EXIT(EFI_INVALID_PARAMETER);
This is just suppressing an SCT warning for an unimplemented function. I
think we should complete the implementation of the HII protocols instead
of trying to hide the deficiency.
Best regards
Heinrich
+
return EFI_EXIT(EFI_NOT_FOUND);
}
[PATCH v3 13/25] video: Fix unchnaged typo
Fix this typo in the header file. Signed-off-by: Simon Glass Reviewed-by: Heinrich Schuchardt --- (no changes since v1) include/video.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/video.h b/include/video.h index 43f2e2c02f0..3f67a93bc93 100644 --- a/include/video.h +++ b/include/video.h @@ -248,7 +248,7 @@ void video_bmp_get_info(void *bmp_image, ulong *widthp, ulong *heightp, * that direction * - if a coordinate is -ve then it will be offset to the * left/top of the centre by that many pixels - * - if a coordinate is positive it will be used unchnaged. + * - if a coordinate is positive it will be used unchanged. * Return: 0 if OK, -ve on error */ int video_bmp_display(struct udevice *dev, ulong bmp_image, int x, int y, -- 2.39.0.314.g84b9a713c41-goog
Re: [PATCH] arm: stm32mp: Fix board_get_usable_ram_top() again
On 1/6/23 10:13, Patrick DELAUNAY wrote: Hi, Hi, For me: get_effective_memsize() must return the effective size of the DDR and NOT -4KiB to avoid side effects in other part of the code (LMB for example) I think today we need to revert your patch. I agree it would be good to revert the patch for the v2023.01 release , and then re-add it once all the issues it triggers are explained or resolved in satisfactory manner.
[PATCH v3 04/25] menu: Rename KEY_... to BKEY_...
This enum values conflict with linux/input.h so rename them.
Signed-off-by: Simon Glass
---
(no changes since v1)
cmd/bootmenu.c | 10 +-
cmd/eficonfig.c | 26 +-
common/menu.c | 34 +-
include/menu.h | 32
4 files changed, 51 insertions(+), 51 deletions(-)
diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
index 3340be16325..c80004c54dc 100644
--- a/cmd/bootmenu.c
+++ b/cmd/bootmenu.c
@@ -86,7 +86,7 @@ static char *bootmenu_choice_entry(void *data)
{
struct bootmenu_data *menu = data;
struct bootmenu_entry *iter;
- enum bootmenu_key key = KEY_NONE;
+ enum bootmenu_key key = BKEY_NONE;
int esc = 0;
int i;
@@ -100,22 +100,22 @@ static char *bootmenu_choice_entry(void *data)
}
switch (key) {
- case KEY_UP:
+ case BKEY_UP:
if (menu->active > 0)
--menu->active;
/* no menu key selected, regenerate menu */
return NULL;
- case KEY_DOWN:
+ case BKEY_DOWN:
if (menu->active < menu->count - 1)
++menu->active;
/* no menu key selected, regenerate menu */
return NULL;
- case KEY_SELECT:
+ case BKEY_SELECT:
iter = menu->first;
for (i = 0; i < menu->active; ++i)
iter = iter->next;
return iter->key;
- case KEY_QUIT:
+ case BKEY_QUIT:
/* Quit by choosing the last entry - U-Boot console */
iter = menu->first;
while (iter->next)
diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
index ce7175a5666..8f246bc271f 100644
--- a/cmd/eficonfig.c
+++ b/cmd/eficonfig.c
@@ -187,31 +187,31 @@ static char *eficonfig_choice_entry(void *data)
int esc = 0;
struct list_head *pos, *n;
struct eficonfig_entry *entry;
- enum bootmenu_key key = KEY_NONE;
+ enum bootmenu_key key = BKEY_NONE;
struct efimenu *efi_menu = data;
while (1) {
bootmenu_loop((struct bootmenu_data *)efi_menu, , );
switch (key) {
- case KEY_UP:
+ case BKEY_UP:
if (efi_menu->active > 0)
--efi_menu->active;
/* no menu key selected, regenerate menu */
return NULL;
- case KEY_DOWN:
+ case BKEY_DOWN:
if (efi_menu->active < efi_menu->count - 1)
++efi_menu->active;
/* no menu key selected, regenerate menu */
return NULL;
- case KEY_SELECT:
+ case BKEY_SELECT:
list_for_each_safe(pos, n, _menu->list) {
entry = list_entry(pos, struct eficonfig_entry,
list);
if (entry->num == efi_menu->active)
return entry->key;
}
break;
- case KEY_QUIT:
+ case BKEY_QUIT:
/* Quit by choosing the last entry */
entry = list_last_entry(_menu->list, struct
eficonfig_entry, list);
return entry->key;
@@ -1864,14 +1864,14 @@ static efi_status_t
eficonfig_choice_change_boot_order(struct efimenu *efi_menu)
{
int esc = 0;
struct list_head *pos, *n;
- enum bootmenu_key key = KEY_NONE;
+ enum bootmenu_key key = BKEY_NONE;
struct eficonfig_entry *entry, *tmp;
while (1) {
bootmenu_loop(NULL, , );
switch (key) {
- case KEY_PLUS:
+ case BKEY_PLUS:
if (efi_menu->active > 0) {
list_for_each_safe(pos, n, _menu->list) {
entry = list_entry(pos, struct
eficonfig_entry, list);
@@ -1885,11 +1885,11 @@ static efi_status_t
eficonfig_choice_change_boot_order(struct efimenu *efi_menu)
list_add(>list, >list);
}
fallthrough;
- case KEY_UP:
+ case BKEY_UP:
if (efi_menu->active > 0)
--efi_menu->active;
return EFI_NOT_READY;
- case KEY_MINUS:
+ case BKEY_MINUS:
if (efi_menu->active < efi_menu->count - 3) {
list_for_each_safe(pos, n, _menu->list) {
[PATCH v3 02/25] cli: Move readline character-processing to a state machine
The current cread_line() function is very long. It handles the escape
processing inline. The menu command does similar processing but at the
character level, so there is some duplication.
Split the character processing into a new function cli_ch_process() which
processes individual characters and returns the resulting input character,
taking account of escape sequences. It requires the caller to set up and
maintain its state.
Update cread_line() to use this new function.
The only intended functional change is that an invalid escape sequence
does not add invalid/control characters into the input buffer, but instead
discards these.
Signed-off-by: Simon Glass
---
(no changes since v1)
common/Makefile | 6 +-
common/cli_getch.c| 204 ++
common/cli_readline.c | 150 +--
include/cli.h | 72 +++
4 files changed, 301 insertions(+), 131 deletions(-)
create mode 100644 common/cli_getch.c
diff --git a/common/Makefile b/common/Makefile
index 20addfb244c..67485e77a04 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -38,7 +38,7 @@ obj-$(CONFIG_SPLASH_SOURCE) += splash_source.o
obj-$(CONFIG_MENU) += menu.o
obj-$(CONFIG_UPDATE_COMMON) += update.o
obj-$(CONFIG_USB_KEYBOARD) += usb_kbd.o
-obj-$(CONFIG_CMDLINE) += cli_readline.o cli_simple.o
+obj-$(CONFIG_CMDLINE) += cli_getch.o cli_readline.o cli_simple.o
endif # !CONFIG_SPL_BUILD
@@ -93,8 +93,8 @@ obj-y += eeprom/eeprom_field.o eeprom/eeprom_layout.o
endif
obj-y += cli.o
-obj-$(CONFIG_FSL_DDR_INTERACTIVE) += cli_simple.o cli_readline.o
-obj-$(CONFIG_STM32MP1_DDR_INTERACTIVE) += cli_simple.o cli_readline.o
+obj-$(CONFIG_FSL_DDR_INTERACTIVE) += cli_getch.o cli_simple.o cli_readline.o
+obj-$(CONFIG_STM32MP1_DDR_INTERACTIVE) += cli_getch.o cli_simple.o
cli_readline.o
obj-$(CONFIG_DFU_OVER_USB) += dfu.o
obj-y += command.o
obj-$(CONFIG_$(SPL_TPL_)LOG) += log.o
diff --git a/common/cli_getch.c b/common/cli_getch.c
new file mode 100644
index 000..9eeea7fef29
--- /dev/null
+++ b/common/cli_getch.c
@@ -0,0 +1,204 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2000
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * Copyright 2022 Google LLC
+ */
+
+#include
+#include
+
+/**
+ * enum cli_esc_state_t - indicates what to do with an escape character
+ *
+ * @ESC_REJECT: Invalid escape sequence, so the esc_save[] characters are
+ * returned from each subsequent call to cli_ch_esc()
+ * @ESC_SAVE: Character should be saved in esc_save until we have another one
+ * @ESC_CONVERTED: Escape sequence has been completed and the resulting
+ * character is available
+ */
+enum cli_esc_state_t {
+ ESC_REJECT,
+ ESC_SAVE,
+ ESC_CONVERTED
+};
+
+void cli_ch_init(struct cli_ch_state *cch)
+{
+ memset(cch, '\0', sizeof(*cch));
+}
+
+/**
+ * cli_ch_esc() - Process a character in an ongoing escape sequence
+ *
+ * @cch: State information
+ * @ichar: Character to process
+ * @actp: Returns the action to take
+ * Returns: Output character if *actp is ESC_CONVERTED, else 0
+ */
+static int cli_ch_esc(struct cli_ch_state *cch, int ichar,
+ enum cli_esc_state_t *actp)
+{
+ enum cli_esc_state_t act = ESC_REJECT;
+
+ switch (cch->esc_len) {
+ case 1:
+ if (ichar == '[' || ichar == 'O')
+ act = ESC_SAVE;
+ break;
+ case 2:
+ switch (ichar) {
+ case 'D': /* <- key */
+ ichar = CTL_CH('b');
+ act = ESC_CONVERTED;
+ break; /* pass off to ^B handler */
+ case 'C': /* -> key */
+ ichar = CTL_CH('f');
+ act = ESC_CONVERTED;
+ break; /* pass off to ^F handler */
+ case 'H': /* Home key */
+ ichar = CTL_CH('a');
+ act = ESC_CONVERTED;
+ break; /* pass off to ^A handler */
+ case 'F': /* End key */
+ ichar = CTL_CH('e');
+ act = ESC_CONVERTED;
+ break; /* pass off to ^E handler */
+ case 'A': /* up arrow */
+ ichar = CTL_CH('p');
+ act = ESC_CONVERTED;
+ break; /* pass off to ^P handler */
+ case 'B': /* down arrow */
+ ichar = CTL_CH('n');
+ act = ESC_CONVERTED;
+ break; /* pass off to ^N handler */
+ case '1':
+ case '2':
+ case '3':
+ case '4':
+ case '7':
+ case '8':
+ if (cch->esc_save[1] == '[') {
+ /* see if next character is ~ */
+
[PATCH v3 08/25] menu: Make use of CLI character processing
Avoid duplicating some of the escape-sequence processing here and use the
CLI function instead.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Rebase to master
cmd/bootmenu.c | 9 +++--
cmd/eficonfig.c| 12 --
common/cli_getch.c | 12 --
common/menu.c | 92 +-
include/cli.h | 4 +-
include/menu.h | 7 +++-
6 files changed, 56 insertions(+), 80 deletions(-)
diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
index 573afe16609..52d8c2f266d 100644
--- a/cmd/bootmenu.c
+++ b/cmd/bootmenu.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
#include
@@ -84,19 +85,21 @@ static void bootmenu_print_entry(void *data)
static char *bootmenu_choice_entry(void *data)
{
+ struct cli_ch_state s_cch, *cch = _cch;
struct bootmenu_data *menu = data;
struct bootmenu_entry *iter;
enum bootmenu_key key = BKEY_NONE;
- int esc = 0;
int i;
+ cli_ch_init(cch);
+
while (1) {
if (menu->delay >= 0) {
/* Autoboot was not stopped */
- key = bootmenu_autoboot_loop(menu, );
+ key = bootmenu_autoboot_loop(menu, cch);
} else {
/* Some key was pressed, so autoboot was stopped */
- key = bootmenu_loop(menu, );
+ key = bootmenu_loop(menu, cch);
}
switch (key) {
diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
index 96cb1a367f3..d830e4af53b 100644
--- a/cmd/eficonfig.c
+++ b/cmd/eficonfig.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
#include
@@ -184,14 +185,16 @@ static void eficonfig_display_statusline(struct menu *m)
*/
static char *eficonfig_choice_entry(void *data)
{
- int esc = 0;
+ struct cli_ch_state s_cch, *cch = _cch;
struct list_head *pos, *n;
struct eficonfig_entry *entry;
enum bootmenu_key key = BKEY_NONE;
struct efimenu *efi_menu = data;
+ cli_ch_init(cch);
+
while (1) {
- key = bootmenu_loop((struct bootmenu_data *)efi_menu, );
+ key = bootmenu_loop((struct bootmenu_data *)efi_menu, cch);
switch (key) {
case BKEY_UP:
@@ -1862,13 +1865,14 @@ static void eficonfig_display_change_boot_order(struct
efimenu *efi_menu)
*/
static efi_status_t eficonfig_choice_change_boot_order(struct efimenu
*efi_menu)
{
- int esc = 0;
+ struct cli_ch_state s_cch, *cch = _cch;
struct list_head *pos, *n;
enum bootmenu_key key = BKEY_NONE;
struct eficonfig_entry *entry, *tmp;
+ cli_ch_init(cch);
while (1) {
- key = bootmenu_loop(NULL, );
+ key = bootmenu_loop(NULL, cch);
switch (key) {
case BKEY_PLUS:
diff --git a/common/cli_getch.c b/common/cli_getch.c
index 9eeea7fef29..87c23edcf4b 100644
--- a/common/cli_getch.c
+++ b/common/cli_getch.c
@@ -140,10 +140,11 @@ int cli_ch_process(struct cli_ch_state *cch, int ichar)
* sequence
*/
if (!ichar) {
- if (cch->emit_upto) {
+ if (cch->emitting) {
if (cch->emit_upto < cch->esc_len)
return cch->esc_save[cch->emit_upto++];
cch->emit_upto = 0;
+ cch->emitting = false;
}
return 0;
} else if (ichar == -ETIMEDOUT) {
@@ -174,18 +175,21 @@ int cli_ch_process(struct cli_ch_state *cch, int ichar)
case ESC_SAVE:
/* save this character and return nothing */
cch->esc_save[cch->esc_len++] = ichar;
- return 0;
+ ichar = 0;
+ break;
case ESC_REJECT:
/*
* invalid escape sequence, start returning the
* characters in it
*/
cch->esc_save[cch->esc_len++] = ichar;
- return cch->esc_save[cch->emit_upto++];
+ ichar = cch->esc_save[cch->emit_upto++];
+ cch->emitting = true;
+ break;
case ESC_CONVERTED:
/* valid escape sequence, return the resulting char */
cch->esc_len = 0;
- return ichar;
+ break;
}
}
diff --git a/common/menu.c b/common/menu.c
index 7db98942a61..45f36ae3ede 100644
--- a/common/menu.c
+++ b/common/menu.c
@@ -15,6 +15,8 @@
#include "menu.h"
+#define ansi 0
+
/*
* Internally, each item in a menu is represented by a struct menu_item.
*
@@ -425,15 +427,19 @@ int menu_destroy(struct menu *m)
[PATCH v3 23/25] bootstd: Add a test for the bootstd menu
Add a test which checks that two operating systems can be displayed in a
menu, allowing one to be selected.
Enable a few things on snow so that the unit tests build.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Fix 'touse' typo
- Fix pylint warning in mkdir_cond()
arch/sandbox/dts/test.dts| 11 ++
configs/snow_defconfig | 4 +
test/boot/bootflow.c | 51 +++
test/py/tests/bootstd/armbian.bmp.xz | Bin 0 -> 1384 bytes
test/py/tests/bootstd/mmc4.img.xz| Bin 0 -> 7072 bytes
test/py/tests/test_ut.py | 218 ---
6 files changed, 265 insertions(+), 19 deletions(-)
create mode 100644 test/py/tests/bootstd/armbian.bmp.xz
create mode 100644 test/py/tests/bootstd/mmc4.img.xz
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index dffe10adbf4..2e580f980fc 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -94,6 +94,10 @@
compatible = "u-boot,distro-efi";
};
+ theme {
+ font-size = <30>;
+ };
+
/*
* This is used for the VBE OS-request tests. A FAT filesystem
* created in a partition with the VBE information appearing
@@ -1013,6 +1017,13 @@
non-removable;
};
+ /* This is used for bootstd bootmenu tests */
+ mmc4 {
+ status = "disabled";
+ compatible = "sandbox,mmc";
+ filename = "mmc4.img";
+ };
+
pch {
compatible = "sandbox,pch";
};
diff --git a/configs/snow_defconfig b/configs/snow_defconfig
index 6921c5667da..faa3a944c02 100644
--- a/configs/snow_defconfig
+++ b/configs/snow_defconfig
@@ -28,7 +28,11 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x205
CONFIG_FIT=y
CONFIG_FIT_BEST_MATCH=y
+CONFIG_BOOTSTD_FULL=y
CONFIG_SILENT_CONSOLE=y
+CONFIG_BLOBLIST=y
+# CONFIG_SPL_BLOBLIST is not set
+CONFIG_BLOBLIST_ADDR=0x43d0
# CONFIG_SPL_FRAMEWORK is not set
CONFIG_SPL_FOOTPRINT_LIMIT=y
CONFIG_SPL_MAX_FOOTPRINT=0x3800
diff --git a/test/boot/bootflow.c b/test/boot/bootflow.c
index 00dfd990687..abafa44b2ed 100644
--- a/test/boot/bootflow.c
+++ b/test/boot/bootflow.c
@@ -11,15 +11,21 @@
#include
#include
#include
+#include
#include
#ifdef CONFIG_SANDBOX
#include
#endif
+#include
#include
#include
#include
#include "bootstd_common.h"
+DECLARE_GLOBAL_DATA_PTR;
+
+extern U_BOOT_DRIVER(bootmeth_script);
+
static int inject_response(struct unit_test_state *uts)
{
/*
@@ -462,3 +468,48 @@ static int bootflow_cmd_boot(struct unit_test_state *uts)
return 0;
}
BOOTSTD_TEST(bootflow_cmd_boot, UT_TESTF_DM | UT_TESTF_SCAN_FDT);
+
+/* Check 'bootflow menu' to select a bootflow */
+static int bootflow_cmd_menu(struct unit_test_state *uts)
+{
+ static const char *order[] = {"mmc2", "mmc1", "mmc4", NULL};
+ struct udevice *dev, *bootstd;
+ struct bootstd_priv *std;
+ const char **old_order;
+ char prev[3];
+ ofnode node;
+
+ /* Enable the mmc4 node since we need a second bootflow */
+ node = ofnode_path("/mmc4");
+ ut_assertok(lists_bind_fdt(gd->dm_root, node, , NULL, false));
+
+ /* Enable the script bootmeth too */
+ ut_assertok(uclass_first_device_err(UCLASS_BOOTSTD, ));
+ ut_assertok(device_bind(bootstd, DM_DRIVER_REF(bootmeth_script),
+ "bootmeth_script", 0, ofnode_null(), ));
+
+ /* Change the order to include mmc4 */
+ std = dev_get_priv(bootstd);
+ old_order = std->bootdev_order;
+ std->bootdev_order = order;
+
+ console_record_reset_enable();
+ ut_assertok(run_command("bootflow scan", 0));
+ ut_assert_console_end();
+
+ /* Restore the order used by the device tree */
+ std->bootdev_order = old_order;
+
+ /* Add keypresses to move to and select the second one in the list */
+ prev[0] = CTL_CH('n');
+ prev[1] = '\r';
+ prev[2] = '\0';
+ ut_asserteq(2, console_in_puts(prev));
+
+ ut_assertok(run_command("bootflow menu", 0));
+ ut_assert_nextline("Selected: Armbian");
+ ut_assert_console_end();
+
+ return 0;
+}
+BOOTSTD_TEST(bootflow_cmd_menu, UT_TESTF_DM | UT_TESTF_SCAN_FDT);
diff --git a/test/py/tests/bootstd/armbian.bmp.xz
b/test/py/tests/bootstd/armbian.bmp.xz
new file mode 100644
index
..ad137ea6e6df5c51d0a98a4be190c4cb4c48fc76
GIT binary patch
literal 1384
zcmV-u1(*8$H+ooF000E$*0e?f03iV!G|osUT>v2yL`vV4GWns~_Xm1L
zxE>Ubk@J6u_+aW`8~-8B2G301rYP}LjG-Uj!5v5M@cMEp)w7Jy+>!JE+yYjbr*Cj;GV^2Hw
z@W7BuO=bDneVey~z?{IPxUWVi=>AB+fXkNrMXePTCtS4$20)TF}em=4#*uIHD
z1l@)}!B8#S*Y2}K?!cbS0x0Q6+%GVl9r84w9-r^ww#S)^#5L%?tS_gQGFqN4x0;M*
z069Xd{Tg$MBJXPB3ZuxY@@+^>NZzLHs%(t8LBUGbn8_tB+-cv$3n422Xoz1d8hrHM
[PATCH v3 20/25] expo: Add support for scene menus
A menu is a key part of the expo design. It consists of a number of items
which the user can select from.
Add the initial implementation of this.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Drop the _add suffix on expo creation function
- Put strings in a separate structure referenced by ID
boot/Makefile | 2 +
boot/scene_menu.c | 390 ++
2 files changed, 392 insertions(+)
create mode 100644 boot/scene_menu.c
diff --git a/boot/Makefile b/boot/Makefile
index f0c31549213..0b30fcd64a9 100644
--- a/boot/Makefile
+++ b/boot/Makefile
@@ -47,6 +47,8 @@ ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_SPL_LOAD_FIT) += common_fit.o
endif
+obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE) += expo.o scene.o scene_menu.o
+
obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE) += vbe.o vbe_request.o
obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_SIMPLE) += vbe_simple.o
obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_SIMPLE_FW) += vbe_simple_fw.o
diff --git a/boot/scene_menu.c b/boot/scene_menu.c
new file mode 100644
index 000..18998e862ab
--- /dev/null
+++ b/boot/scene_menu.c
@@ -0,0 +1,390 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Implementation of a menu in a scene
+ *
+ * Copyright 2022 Google LLC
+ * Written by Simon Glass
+ */
+
+#define LOG_CATEGORY LOGC_BOOT
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "scene_internal.h"
+
+static void scene_menuitem_destroy(struct scene_menitem *item)
+{
+ free(item->name);
+ free(item);
+}
+
+void scene_menu_destroy(struct scene_obj_menu *menu)
+{
+ struct scene_menitem *item, *next;
+
+ list_for_each_entry_safe(item, next, >item_head, sibling)
+ scene_menuitem_destroy(item);
+}
+
+/**
+ * menu_point_to_item() - Point to a particular menu item
+ *
+ * Sets the currently pointed-to / highlighted menu item
+ */
+static void menu_point_to_item(struct scene_obj_menu *menu, uint item_id)
+{
+ menu->cur_item_id = item_id;
+}
+
+int scene_menu_arrange(struct scene *scn, struct scene_obj_menu *menu)
+{
+ struct scene_menitem *item;
+ int y, cur_y;
+ int ret;
+
+ y = menu->obj.y;
+ if (menu->title_id) {
+ ret = scene_obj_set_pos(scn, menu->title_id, menu->obj.x, y);
+ if (ret < 0)
+ return log_msg_ret("tit", ret);
+
+ ret = scene_obj_get_hw(scn, menu->title_id, NULL);
+ if (ret < 0)
+ return log_msg_ret("hei", ret);
+
+ y += ret * 2;
+ }
+
+ /*
+* Currently everything is hard-coded to particular columns so this
+* won't work on small displays and looks strange if the font size is
+* small. This can be updated once text measuring is supported in
+* vidconsole
+*/
+ cur_y = -1;
+ list_for_each_entry(item, >item_head, sibling) {
+ int height;
+
+ ret = scene_obj_get_hw(scn, item->desc_id, NULL);
+ if (ret < 0)
+ return log_msg_ret("get", ret);
+ height = ret;
+
+ if (item->flags & SCENEMIF_GAP_BEFORE)
+ y += height;
+
+ /* select an item if not done already */
+ if (!menu->cur_item_id)
+ menu_point_to_item(menu, item->id);
+
+ /*
+* Put the label on the left, then leave a space for the
+* pointer, then the key and the description
+*/
+ if (item->label_id) {
+ ret = scene_obj_set_pos(scn, item->label_id,
menu->obj.x,
+ y);
+ if (ret < 0)
+ return log_msg_ret("nam", ret);
+ }
+
+ ret = scene_obj_set_pos(scn, item->key_id, menu->obj.x + 230,
+ y);
+ if (ret < 0)
+ return log_msg_ret("key", ret);
+
+ ret = scene_obj_set_pos(scn, item->desc_id, menu->obj.x + 280,
+ y);
+ if (ret < 0)
+ return log_msg_ret("des", ret);
+
+ if (menu->cur_item_id == item->id)
+ cur_y = y;
+
+ if (item->preview_id) {
+ bool hide;
+
+ /*
+* put all previews on top of each other, on the right
+* size of the display
+*/
+ ret = scene_obj_set_pos(scn, item->preview_id, -4, y);
+ if (ret < 0)
+ return log_msg_ret("prev", ret);
+
+ hide = menu->cur_item_id != item->id;
+ ret = scene_obj_set_hide(scn, item->preview_id, hide);
+
[PATCH v3 25/25] expo: Add documentation
Add some documentation for the expo feature. Signed-off-by: Simon Glass --- Changes in v3: - Rebase to master Changes in v2: - Update for new API doc/develop/expo.rst | 188 ++ doc/develop/index.rst | 1 + 2 files changed, 189 insertions(+) create mode 100644 doc/develop/expo.rst diff --git a/doc/develop/expo.rst b/doc/develop/expo.rst new file mode 100644 index 000..32dd7f09030 --- /dev/null +++ b/doc/develop/expo.rst @@ -0,0 +1,188 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Expo menu += + +U-Boot provides a menu implementation for use with selecting bootflows and +changing U-Boot settings. This is in early stages of development. + +Motivation +-- + +U-Boot already has a text-based menu system accessed via the +:doc:`../usage/cmd/bootmenu`. This works using environment variables, or via +some EFI-specific hacks. + +The command makes use of a lower-level `menu` implementation, which is quite +flexible and can be used to make menu hierarchies. + +However this system is not flexible enough for use with standard boot. It does +not support a graphical user interface and cannot currently support anything +more than a very simple list of items. While it does support multiple menus in +hierarchies, these are implemented by the caller. See for example `eficonfig.c`. + +Another challenge with the current menu implementation is that it controls +the event loop, such that bootmenu_loop() does not return until a key is +pressed. This makes it difficult to implement dynamic displays or to do other +things while the menu is running, such as searching for more bootflows. + +For these reasons an attempt has been made to develop a more flexible system +which can handle menus as well as other elements. This is called 'expo', short +for exposition, in an attempt to avoid common words like display, screen, menu +and the like. The primary goal is to support Verified Boot for Embedded (VBE), +although it is available to any boot method, using the 'bootflow menu' command. + +Efforts have been made to use common code with the existing menu, including +key processing in particular. + +Previous work looked at integrating Nuklear into U-Boot. This works fine and +could provide a way to provide a more flexible UI, perhaps with expo dealing +with the interface to Nuklear. But this is quite a big step and it may be years +before this becomes desirable, if at all. For now, U-Boot only needs a fairly +simple set of menus and options, so rendering them directly is fairly +straightforward. + +Concepts + + +The creator of the expo is here called a `controller` and it controls most +aspects of the expo. This is the code that you must write to use expo. + +An `expo` is a set of scenes which can be presented to the user one at a time, +to show information and obtain input from the user. + +A `scene` is a collection of objects which are displayed together on the screen. +Only one scene is visible at a time and scenes do not share objects. + +A `scene object` is something that appears in the scene, such as some text, an +image or a menu. Objects can be positioned and hidden. + +A `menu object` contains a title, a set of `menu items` and a pointer to the +current item. Menu items consist of a keypress (indicating what to press to +select the item), label and description. All three are shown in a single line +within the menu. Items can also have a preview image, which is shown when the +item is highlighted. + +All components have a name. This is purely for debugging, so it is easy to see +what object is referred to. Of course the ID numbers can help as well, but they +are less easy to distinguish. + +While the expo implementation provides support for handling keypresses and +rendering on the display or serial port, it does not actually deal with reading +input from the user, nor what should be done when a particular menu item is +selected. This is deliberate since having the event loop outside the expo is +more flexible, particularly in a single-threaded environment like U-Boot. + +Everything within an expo has a unique ID number. This is done so that it is +easy to refer to things after the expo has been created. The expectation is that +the controller declares an enum containing all of the elements in the expo, +passing the ID of each object as it is created. When a menu item is selected, +its ID is returned. When a object's font or position needs to change, the ID is +passed to expo functions to indicate which object it is. It is possible for expo +to auto-allocate IDs, but this is not recommended. The use of IDs is a +convenience, removing the need for the controller to store pointers to objects, +or even the IDs of objects. Programmatic creation of many items in a loop can be +handled by allocating space in the enum for a maximum number of items, then +adding the loop count to the enum values to obtain unique IDs. + +All text strings are stored in a
[PATCH v3 21/25] expo: Add basic tests
Add some tests for the expo, including setting up and rendering an expo.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Drop the _add suffix on expo creation function
- Put strings in a separate structure referenced by ID
test/boot/Makefile | 2 +
test/boot/expo.c | 539 +
2 files changed, 541 insertions(+)
create mode 100644 test/boot/expo.c
diff --git a/test/boot/Makefile b/test/boot/Makefile
index d724629d3b0..22ed61c8fa0 100644
--- a/test/boot/Makefile
+++ b/test/boot/Makefile
@@ -5,6 +5,8 @@
obj-$(CONFIG_BOOTSTD) += bootdev.o bootstd_common.o bootflow.o bootmeth.o
obj-$(CONFIG_FIT) += image.o
+obj-$(CONFIG_EXPO) += expo.o
+
ifdef CONFIG_OF_LIVE
obj-$(CONFIG_BOOTMETH_VBE_SIMPLE) += vbe_simple.o
endif
diff --git a/test/boot/expo.c b/test/boot/expo.c
new file mode 100644
index 000..7104dff05e8
--- /dev/null
+++ b/test/boot/expo.c
@@ -0,0 +1,539 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2022 Google LLC
+ * Written by Simon Glass
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "bootstd_common.h"
+#include "../../boot/scene_internal.h"
+
+enum {
+ /* scenes */
+ SCENE1 = 7,
+ SCENE2,
+
+ /* objects */
+ OBJ_LOGO,
+ OBJ_TEXT,
+ OBJ_TEXT2,
+ OBJ_MENU,
+ OBJ_MENU_TITLE,
+
+ /* strings */
+ STR_TEXT,
+ STR_TEXT2,
+ STR_MENU_TITLE,
+ STR_POINTER_TEXT,
+
+ STR_ITEM1_LABEL,
+ STR_ITEM1_DESC,
+ STR_ITEM1_KEY,
+ STR_ITEM1_PREVIEW,
+
+ STR_ITEM2_LABEL,
+ STR_ITEM2_DESC,
+ STR_ITEM2_KEY,
+ STR_ITEM2_PREVIEW,
+
+ /* menu items */
+ ITEM1,
+ ITEM1_LABEL,
+ ITEM1_DESC,
+ ITEM1_KEY,
+ ITEM1_PREVIEW,
+
+ ITEM2,
+ ITEM2_LABEL,
+ ITEM2_DESC,
+ ITEM2_KEY,
+ ITEM2_PREVIEW,
+
+ /* pointer to current item */
+ POINTER_TEXT,
+};
+
+#define BAD_POINTER((void *)1)
+
+/* names for various things */
+#define EXPO_NAME "my menus"
+#define SCENE_NAME1"main"
+#define SCENE_NAME2"second"
+#define SCENE_TITLE"Main Menu"
+#define LOGO_NAME "logo"
+
+/* Check base expo support */
+static int expo_base(struct unit_test_state *uts)
+{
+ struct udevice *dev;
+ struct expo *exp;
+ ulong start_mem;
+ char name[100];
+ int i;
+
+ ut_assertok(uclass_first_device_err(UCLASS_VIDEO, ));
+
+ start_mem = ut_check_free();
+
+ exp = NULL;
+ strcpy(name, EXPO_NAME);
+ ut_assertok(expo_new(name, NULL, ));
+ *name = '\0';
+ ut_assertnonnull(exp);
+ ut_asserteq(0, exp->scene_id);
+ ut_asserteq(0, exp->next_id);
+
+ /* Make sure the name was allocated */
+ ut_assertnonnull(exp->name);
+ ut_asserteq_str(EXPO_NAME, exp->name);
+
+ ut_assertok(expo_set_display(exp, dev));
+ expo_destroy(exp);
+ ut_assertok(ut_check_delta(start_mem));
+
+ /* test handling out-of-memory conditions */
+ for (i = 0; i < 2; i++) {
+ struct expo *exp2;
+
+ malloc_enable_testing(i);
+ exp2 = BAD_POINTER;
+ ut_asserteq(-ENOMEM, expo_new(EXPO_NAME, NULL, ));
+ ut_asserteq_ptr(BAD_POINTER, exp2);
+ malloc_disable_testing();
+ }
+
+ return 0;
+}
+BOOTSTD_TEST(expo_base, UT_TESTF_DM | UT_TESTF_SCAN_FDT);
+
+/* Check creating a scene */
+static int expo_scene(struct unit_test_state *uts)
+{
+ struct scene *scn;
+ struct expo *exp;
+ ulong start_mem;
+ char name[100];
+ int id;
+
+ start_mem = ut_check_free();
+
+ ut_assertok(expo_new(EXPO_NAME, NULL, ));
+
+ scn = NULL;
+ ut_asserteq(0, exp->next_id);
+ strcpy(name, SCENE_NAME1);
+ id = scene_new(exp, name, SCENE1, );
+ *name = '\0';
+ ut_assertnonnull(scn);
+ ut_asserteq(SCENE1, id);
+ ut_asserteq(SCENE1 + 1, exp->next_id);
+ ut_asserteq_ptr(exp, scn->expo);
+
+ /* Make sure the name was allocated */
+ ut_assertnonnull(scn->name);
+ ut_asserteq_str(SCENE_NAME1, scn->name);
+
+ /* Set the title */
+ strcpy(name, SCENE_TITLE);
+ ut_assertok(scene_title_set(scn, name));
+ *name = '\0';
+ ut_assertnonnull(scn->title);
+ ut_asserteq_str(SCENE_TITLE, scn->title);
+
+ /* Use an allocated ID */
+ scn = NULL;
+ id = scene_new(exp, SCENE_NAME2, 0, );
+ ut_assertnonnull(scn);
+ ut_asserteq(SCENE2, id);
+ ut_asserteq(SCENE2 + 1, exp->next_id);
+ ut_asserteq_ptr(exp, scn->expo);
+
+ ut_asserteq_str(SCENE_NAME2, scn->name);
+
+ expo_destroy(exp);
+
+ ut_assertok(ut_check_delta(start_mem));
+
+ return 0;
+}
+BOOTSTD_TEST(expo_scene, UT_TESTF_DM | UT_TESTF_SCAN_FDT);
+
+/* Check creating a scene with objects */
[PATCH v3 24/25] bootstd: Support setting a theme for the menu
Allow a theme to be set. For now this is very simple, just a default font
size to use for all elements.
Signed-off-by: Simon Glass
---
(no changes since v1)
boot/bootflow_menu.c | 43 ++
boot/bootstd-uclass.c | 2 ++
include/bootflow.h| 10 ++
include/bootstd.h | 4 +++
test/boot/bootflow.c | 83 +--
5 files changed, 139 insertions(+), 3 deletions(-)
diff --git a/boot/bootflow_menu.c b/boot/bootflow_menu.c
index 1105783afeb..7f06dac0af7 100644
--- a/boot/bootflow_menu.c
+++ b/boot/bootflow_menu.c
@@ -129,6 +129,43 @@ int bootflow_menu_new(struct expo **expp)
return 0;
}
+int bootflow_menu_apply_theme(struct expo *exp, ofnode node)
+{
+ struct menu_priv *priv = exp->priv;
+ struct scene *scn;
+ u32 font_size;
+ int ret;
+
+ log_debug("Applying theme %s\n", ofnode_get_name(node));
+ scn = expo_lookup_scene_id(exp, MAIN);
+ if (!scn)
+ return log_msg_ret("scn", -ENOENT);
+
+ /* Avoid error-checking optional items */
+ if (!ofnode_read_u32(node, "font-size", _size)) {
+ int i;
+
+ log_debug("font size %d\n", font_size);
+ scene_txt_set_font(scn, OBJ_PROMPT, NULL, font_size);
+ scene_txt_set_font(scn, OBJ_POINTER, NULL, font_size);
+ for (i = 0; i < priv->num_bootflows; i++) {
+ ret = scene_txt_set_font(scn, ITEM_DESC + i, NULL,
+font_size);
+ if (ret)
+ return log_msg_ret("des", ret);
+ scene_txt_set_font(scn, ITEM_KEY + i, NULL, font_size);
+ scene_txt_set_font(scn, ITEM_LABEL + i, NULL,
+ font_size);
+ }
+ }
+
+ ret = scene_arrange(scn);
+ if (ret)
+ return log_msg_ret("arr", ret);
+
+ return 0;
+}
+
int bootflow_menu_run(struct bootstd_priv *std, bool text_mode,
struct bootflow **bflowp)
{
@@ -149,6 +186,12 @@ int bootflow_menu_run(struct bootstd_priv *std, bool
text_mode,
if (ret)
return log_msg_ret("exp", ret);
+ if (ofnode_valid(std->theme)) {
+ ret = bootflow_menu_apply_theme(exp, std->theme);
+ if (ret)
+ return log_msg_ret("thm", ret);
+ }
+
/* For now we only support a video console */
ret = uclass_first_device_err(UCLASS_VIDEO, );
if (ret)
diff --git a/boot/bootstd-uclass.c b/boot/bootstd-uclass.c
index 565c22a36e7..7887acdc11b 100644
--- a/boot/bootstd-uclass.c
+++ b/boot/bootstd-uclass.c
@@ -33,6 +33,8 @@ static int bootstd_of_to_plat(struct udevice *dev)
>prefixes);
dev_read_string_list(dev, "bootdev-order",
>bootdev_order);
+
+ priv->theme = ofnode_find_subnode(dev_ofnode(dev), "theme");
}
return 0;
diff --git a/include/bootflow.h b/include/bootflow.h
index e7a09568f1b..c201246c6de 100644
--- a/include/bootflow.h
+++ b/include/bootflow.h
@@ -7,6 +7,7 @@
#ifndef __bootflow_h
#define __bootflow_h
+#include
#include
struct bootstd_priv;
@@ -347,6 +348,15 @@ int bootflow_iter_uses_system(const struct bootflow_iter
*iter);
*/
int bootflow_menu_new(struct expo **expp);
+/**
+ * bootflow_menu_apply_theme() - Apply a theme to a bootmenu
+ *
+ * @exp: Expo to update
+ * @node: Node containing the theme information
+ * Returns 0 on success, -ve on error
+ */
+int bootflow_menu_apply_theme(struct expo *exp, ofnode node);
+
/**
* bootflow_menu_run() - Create and run a menu of available bootflows
*
diff --git a/include/bootstd.h b/include/bootstd.h
index 01be249d16e..4fa0d531001 100644
--- a/include/bootstd.h
+++ b/include/bootstd.h
@@ -9,6 +9,8 @@
#ifndef __bootstd_h
#define __bootstd_h
+#include
+
struct udevice;
/**
@@ -27,6 +29,7 @@ struct udevice;
* @bootmeth_count: Number of bootmeth devices in @bootmeth_order
* @bootmeth_order: List of bootmeth devices to use, in order, NULL-terminated
* @vbe_bootmeth: Currently selected VBE bootmeth, NULL if none
+ * @theme: Node containing the theme information
*/
struct bootstd_priv {
const char **prefixes;
@@ -37,6 +40,7 @@ struct bootstd_priv {
int bootmeth_count;
struct udevice **bootmeth_order;
struct udevice *vbe_bootmeth;
+ ofnode theme;
};
/**
diff --git a/test/boot/bootflow.c b/test/boot/bootflow.c
index abafa44b2ed..5b76cd3ab14 100644
--- a/test/boot/bootflow.c
+++ b/test/boot/bootflow.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_SANDBOX
#include
#endif
@@ -21,6 +22,8 @@
#include
#include
#include "bootstd_common.h"
+#include "../../boot/bootflow_internal.h"
+#include
[PATCH v3 22/25] bootstd: Support creating a boot menu
Create an expo to handle the boot menu. For now this is quite simple, with
just a header, some menu items and a pointer to show the current one.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Rebase to master
boot/Makefile| 1 +
boot/bootflow_internal.h | 47
boot/bootflow_menu.c | 241 +++
cmd/bootflow.c | 37 +-
include/bootflow.h | 23
5 files changed, 347 insertions(+), 2 deletions(-)
create mode 100644 boot/bootflow_internal.h
create mode 100644 boot/bootflow_menu.c
diff --git a/boot/Makefile b/boot/Makefile
index 0b30fcd64a9..f990e66f522 100644
--- a/boot/Makefile
+++ b/boot/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_SANDBOX) +=
bootmeth_sandbox.o
obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_SCRIPT) += bootmeth_script.o
ifdef CONFIG_$(SPL_TPL_)BOOTSTD_FULL
obj-$(CONFIG_$(SPL_TPL_)CMD_BOOTEFI_BOOTMGR) += bootmeth_efi_mgr.o
+obj-$(CONFIG_$(SPL_TPL_)BOOTSTD) += bootflow_menu.o
endif
obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += image-fdt.o
diff --git a/boot/bootflow_internal.h b/boot/bootflow_internal.h
new file mode 100644
index 000..38cf02a55b5
--- /dev/null
+++ b/boot/bootflow_internal.h
@@ -0,0 +1,47 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Internal header file for bootflow
+ *
+ * Copyright 2022 Google LLC
+ * Written by Simon Glass
+ */
+
+#ifndef __BOOTFLOW_INTERNAL_H
+#define __BOOTFLOW_INTERNAL_H
+
+/* expo IDs for elements of the bootflow menu */
+enum {
+ START,
+
+ /* strings */
+ STR_PROMPT,
+ STR_MENU_TITLE,
+ STR_POINTER,
+
+ /* scene */
+ MAIN,
+
+ /* objects */
+ OBJ_U_BOOT_LOGO,
+ OBJ_MENU,
+ OBJ_PROMPT,
+ OBJ_MENU_TITLE,
+ OBJ_POINTER,
+
+ /* strings for menu items */
+ STR_LABEL = 100,
+ STR_DESC = 200,
+ STR_KEY = 300,
+
+ /* menu items / components (bootflow number is added to these) */
+ ITEM = 400,
+ ITEM_LABEL = 500,
+ ITEM_DESC = 600,
+ ITEM_KEY = 700,
+ ITEM_PREVIEW = 800,
+
+ /* left margin for the main menu */
+ MARGIN_LEFT = 100,
+};
+
+#endif /* __BOOTFLOW_INTERNAL_H */
diff --git a/boot/bootflow_menu.c b/boot/bootflow_menu.c
new file mode 100644
index 000..1105783afeb
--- /dev/null
+++ b/boot/bootflow_menu.c
@@ -0,0 +1,241 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Provide a menu of available bootflows and related options
+ *
+ * Copyright 2022 Google LLC
+ * Written by Simon Glass
+ */
+
+#define LOG_CATEGORY UCLASS_BOOTSTD
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "bootflow_internal.h"
+
+/**
+ * struct menu_priv - information about the menu
+ *
+ * @num_bootflows: Number of bootflows in the menu
+ */
+struct menu_priv {
+ int num_bootflows;
+};
+
+int bootflow_menu_new(struct expo **expp)
+{
+ struct udevice *last_bootdev;
+ struct scene_obj_menu *menu;
+ struct menu_priv *priv;
+ struct bootflow *bflow;
+ struct scene *scn;
+ struct expo *exp;
+ void *logo;
+ int ret, i;
+
+ priv = calloc(1, sizeof(*priv));
+ if (!priv)
+ return log_msg_ret("prv", -ENOMEM);
+
+ ret = expo_new("bootflows", priv, );
+ if (ret)
+ return log_msg_ret("exp", ret);
+
+ ret = scene_new(exp, "main", MAIN, );
+ if (ret < 0)
+ return log_msg_ret("scn", ret);
+
+ ret |= scene_txt_str(scn, "prompt", OBJ_PROMPT, STR_PROMPT,
+"UP and DOWN to choose, ENTER to select", NULL);
+
+ ret = scene_menu(scn, "main", OBJ_MENU, );
+ ret |= scene_obj_set_pos(scn, OBJ_MENU, MARGIN_LEFT, 100);
+ ret |= scene_txt_str(scn, "title", OBJ_MENU_TITLE, STR_MENU_TITLE,
+"U-Boot - Boot Menu", NULL);
+ ret |= scene_menu_set_title(scn, OBJ_MENU, OBJ_PROMPT);
+
+ logo = video_get_u_boot_logo();
+ if (logo) {
+ ret |= scene_img(scn, "ulogo", OBJ_U_BOOT_LOGO, logo, NULL);
+ ret |= scene_obj_set_pos(scn, OBJ_U_BOOT_LOGO, -4, 4);
+ }
+
+ ret |= scene_txt_str(scn, "cur_item", OBJ_POINTER, STR_POINTER, ">",
+NULL);
+ ret |= scene_menu_set_pointer(scn, OBJ_MENU, OBJ_POINTER);
+ if (ret < 0)
+ return log_msg_ret("new", -EINVAL);
+
+ last_bootdev = NULL;
+ for (ret = bootflow_first_glob(), i = 0; !ret && i < 36;
+ret = bootflow_next_glob(), i++) {
+ char str[2], *label, *key;
+ uint preview_id;
+ bool add_gap;
+
+ if (bflow->state != BOOTFLOWST_READY)
+ continue;
+
+ *str = i < 10 ? '0' + i : 'A' + i - 10;
+ str[1] = '\0';
+ key = strdup(str);
+ if (!key)
+
[PATCH v3 19/25] expo: Add support for scenes
A scene is a single screen within an expo. It is possible to move between
scenes but only one can be displayed at once.
Add a basic implementation.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Drop the _add suffix on expo creation function
- Put strings in a separate structure referenced by ID
boot/scene.c | 414 ++
boot/scene_internal.h | 123 +
2 files changed, 537 insertions(+)
create mode 100644 boot/scene.c
create mode 100644 boot/scene_internal.h
diff --git a/boot/scene.c b/boot/scene.c
new file mode 100644
index 000..030f6aa2a0a
--- /dev/null
+++ b/boot/scene.c
@@ -0,0 +1,414 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Implementation of a scene, a collection of text/image/menu items in an expo
+ *
+ * Copyright 2022 Google LLC
+ * Written by Simon Glass
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "scene_internal.h"
+
+uint resolve_id(struct expo *exp, uint id)
+{
+ if (!id)
+ id = exp->next_id++;
+ else if (id >= exp->next_id)
+ exp->next_id = id + 1;
+
+ return id;
+}
+
+int scene_new(struct expo *exp, const char *name, uint id, struct scene **scnp)
+{
+ struct scene *scn;
+
+ scn = calloc(1, sizeof(struct scene));
+ if (!scn)
+ return log_msg_ret("expo", -ENOMEM);
+ scn->name = strdup(name);
+ if (!scn->name) {
+ free(scn);
+ return log_msg_ret("name", -ENOMEM);
+ }
+
+ INIT_LIST_HEAD(>obj_head);
+ scn->id = resolve_id(exp, id);
+ scn->expo = exp;
+ list_add_tail(>sibling, >scene_head);
+
+ *scnp = scn;
+
+ return scn->id;
+}
+
+void scene_obj_destroy(struct scene_obj *obj)
+{
+ if (obj->type == SCENEOBJT_MENU)
+ scene_menu_destroy((struct scene_obj_menu *)obj);
+ free(obj->name);
+ free(obj);
+}
+
+void scene_destroy(struct scene *scn)
+{
+ struct scene_obj *obj, *next;
+
+ list_for_each_entry_safe(obj, next, >obj_head, sibling)
+ scene_obj_destroy(obj);
+
+ free(scn->name);
+ free(scn->title);
+ free(scn);
+}
+
+int scene_title_set(struct scene *scn, const char *title)
+{
+ free(scn->title);
+ scn->title = strdup(title);
+ if (!scn->title)
+ return log_msg_ret("tit", -ENOMEM);
+
+ return 0;
+}
+
+int scene_obj_count(struct scene *scn)
+{
+ struct scene_obj *obj;
+ int count = 0;
+
+ list_for_each_entry(obj, >obj_head, sibling)
+ count++;
+
+ return count;
+}
+
+void *scene_obj_find(struct scene *scn, uint id, enum scene_obj_t type)
+{
+ struct scene_obj *obj;
+
+ list_for_each_entry(obj, >obj_head, sibling) {
+ if (obj->id == id &&
+ (type == SCENEOBJT_NONE || obj->type == type))
+ return obj;
+ }
+
+ return NULL;
+}
+
+int scene_obj_add(struct scene *scn, const char *name, uint id,
+ enum scene_obj_t type, uint size, struct scene_obj **objp)
+{
+ struct scene_obj *obj;
+
+ obj = calloc(1, size);
+ if (!obj)
+ return log_msg_ret("obj", -ENOMEM);
+ obj->name = strdup(name);
+ if (!obj->name) {
+ free(obj);
+ return log_msg_ret("name", -ENOMEM);
+ }
+
+ obj->id = resolve_id(scn->expo, id);
+ obj->scene = scn;
+ obj->type = type;
+ list_add_tail(>sibling, >obj_head);
+ *objp = obj;
+
+ return obj->id;
+}
+
+int scene_img(struct scene *scn, const char *name, uint id, char *data,
+ struct scene_obj_img **imgp)
+{
+ struct scene_obj_img *img;
+ int ret;
+
+ ret = scene_obj_add(scn, name, id, SCENEOBJT_IMAGE,
+ sizeof(struct scene_obj_img),
+ (struct scene_obj **));
+ if (ret < 0)
+ return log_msg_ret("obj", -ENOMEM);
+
+ img->data = data;
+
+ if (imgp)
+ *imgp = img;
+
+ return img->obj.id;
+}
+
+int scene_txt(struct scene *scn, const char *name, uint id, uint str_id,
+ struct scene_obj_txt **txtp)
+{
+ struct scene_obj_txt *txt;
+ int ret;
+
+ ret = scene_obj_add(scn, name, id, SCENEOBJT_TEXT,
+ sizeof(struct scene_obj_txt),
+ (struct scene_obj **));
+ if (ret < 0)
+ return log_msg_ret("obj", -ENOMEM);
+
+ txt->str_id = str_id;
+
+ if (txtp)
+ *txtp = txt;
+
+ return txt->obj.id;
+}
+
+int scene_txt_str(struct scene *scn, const char *name, uint id, uint str_id,
+ const char *str, struct scene_obj_txt **txtp)
+{
+ struct scene_obj_txt *txt;
+ int ret;
+
+ ret = expo_str(scn->expo, name, str_id, str);
+ if (ret < 0)
+
[PATCH v3 18/25] expo: Add basic implementation
An expo is a way of presenting and collecting information from the
user. It consists of a collection of 'scenes' of which only one is
presented at a time. An expo is typically used to show a boot menu
and allow settings to be changed.
One created, the same expo can be automatically presented in graphical
form using a vidconsole, or in text form on a serial console.
Add an initial implementation of the expo itself. Supports for scenes
and objects is provided later.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Drop the _add suffix on expo creation function
- Put strings in a separate structure referenced by ID
boot/Kconfig | 12 +
boot/expo.c | 170
configs/tools-only_defconfig | 2 +
include/expo.h | 521 +++
4 files changed, 705 insertions(+)
create mode 100644 boot/expo.c
create mode 100644 include/expo.h
diff --git a/boot/Kconfig b/boot/Kconfig
index 424ad0e466d..f672a325776 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -556,6 +556,18 @@ config VPL_BOOTMETH_VBE_SIMPLE_FW
endif # BOOTMETH_VBE
+config EXPO
+ bool "Support for expos - groups of scenes displaying a UI"
+ default y if BOOTMETH_VBE
+ help
+ An expo is a way of presenting and collecting information from the
+ user. It consists of a collection of 'scenes' of which only one is
+ presented at a time. An expo is typically used to show a boot menu
+ and allow settings to be changed.
+
+ The expo can be presented in graphics form using a vidconsole, or in
+ text form on a serial console.
+
config BOOTMETH_SANDBOX
def_bool y
depends on SANDBOX
diff --git a/boot/expo.c b/boot/expo.c
new file mode 100644
index 000..05950a17603
--- /dev/null
+++ b/boot/expo.c
@@ -0,0 +1,170 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Implementation of a expo, a collection of scenes providing menu options
+ *
+ * Copyright 2022 Google LLC
+ * Written by Simon Glass
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "scene_internal.h"
+
+int expo_new(const char *name, void *priv, struct expo **expp)
+{
+ struct expo *exp;
+
+ exp = calloc(1, sizeof(struct expo));
+ if (!exp)
+ return log_msg_ret("expo", -ENOMEM);
+ exp->name = strdup(name);
+ if (!exp->name) {
+ free(exp);
+ return log_msg_ret("name", -ENOMEM);
+ }
+ exp->priv = priv;
+ INIT_LIST_HEAD(>scene_head);
+ INIT_LIST_HEAD(>str_head);
+
+ *expp = exp;
+
+ return 0;
+}
+
+static void estr_destroy(struct expo_string *estr)
+{
+ free(estr);
+}
+
+void expo_destroy(struct expo *exp)
+{
+ struct scene *scn, *next;
+ struct expo_string *estr, *enext;
+
+ list_for_each_entry_safe(scn, next, >scene_head, sibling)
+ scene_destroy(scn);
+
+ list_for_each_entry_safe(estr, enext, >str_head, sibling)
+ estr_destroy(estr);
+
+ free(exp->name);
+ free(exp);
+}
+
+int expo_str(struct expo *exp, const char *name, uint id, const char *str)
+{
+ struct expo_string *estr;
+
+ estr = calloc(1, sizeof(struct expo_string));
+ if (!estr)
+ return log_msg_ret("obj", -ENOMEM);
+
+ estr->id = resolve_id(exp, id);
+ estr->str = str;
+ list_add_tail(>sibling, >str_head);
+
+ return estr->id;
+}
+
+const char *expo_get_str(struct expo *exp, uint id)
+{
+ struct expo_string *estr;
+
+ list_for_each_entry(estr, >str_head, sibling) {
+ if (estr->id == id)
+ return estr->str;
+ }
+
+ return NULL;
+}
+
+int expo_set_display(struct expo *exp, struct udevice *dev)
+{
+ exp->display = dev;
+
+ return 0;
+}
+
+void exp_set_text_mode(struct expo *exp, bool text_mode)
+{
+ exp->text_mode = text_mode;
+}
+
+struct scene *expo_lookup_scene_id(struct expo *exp, uint scene_id)
+{
+ struct scene *scn;
+
+ list_for_each_entry(scn, >scene_head, sibling) {
+ if (scn->id == scene_id)
+ return scn;
+ }
+
+ return NULL;
+}
+
+int expo_set_scene_id(struct expo *exp, uint scene_id)
+{
+ if (!expo_lookup_scene_id(exp, scene_id))
+ return log_msg_ret("id", -ENOENT);
+ exp->scene_id = scene_id;
+
+ return 0;
+}
+
+int expo_render(struct expo *exp)
+{
+ struct udevice *dev = exp->display;
+ struct video_priv *vid_priv = dev_get_uclass_priv(dev);
+ struct scene *scn = NULL;
+ u32 colour;
+ int ret;
+
+ colour = video_index_to_colour(vid_priv, VID_WHITE);
+ ret = video_fill(dev, colour);
+ if (ret)
+ return log_msg_ret("fill", ret);
+
+ if (exp->scene_id) {
+ scn = expo_lookup_scene_id(exp, exp->scene_id);
+ if (!scn)
+
[PATCH v3 16/25] bootstd: Allow reading a logo for the OS
Some operating systems provide a logo in bmp format. Read this in if
present so it can be displayed in the menu.
Signed-off-by: Simon Glass
---
(no changes since v1)
boot/bootmeth-uclass.c | 69 --
boot/bootmeth_script.c | 4 +++
cmd/bootflow.c | 6
include/bootflow.h | 4 +++
include/bootmeth.h | 16 ++
test/boot/bootflow.c | 1 +
6 files changed, 91 insertions(+), 9 deletions(-)
diff --git a/boot/bootmeth-uclass.c b/boot/bootmeth-uclass.c
index 25552dd96f6..4c3529d1555 100644
--- a/boot/bootmeth-uclass.c
+++ b/boot/bootmeth-uclass.c
@@ -290,25 +290,19 @@ int bootmeth_try_file(struct bootflow *bflow, struct
blk_desc *desc,
return 0;
}
-int bootmeth_alloc_file(struct bootflow *bflow, uint size_limit, uint align)
+static int alloc_file(const char *fname, uint size, void **bufp)
{
loff_t bytes_read;
ulong addr;
char *buf;
- uint size;
int ret;
- size = bflow->size;
- log_debug(" - script file size %x\n", size);
- if (size > size_limit)
- return log_msg_ret("chk", -E2BIG);
-
- buf = memalign(align, size + 1);
+ buf = malloc(size + 1);
if (!buf)
return log_msg_ret("buf", -ENOMEM);
addr = map_to_sysmem(buf);
- ret = fs_read(bflow->fname, addr, 0, 0, _read);
+ ret = fs_read(fname, addr, 0, size, _read);
if (ret) {
free(buf);
return log_msg_ret("read", ret);
@@ -316,12 +310,69 @@ int bootmeth_alloc_file(struct bootflow *bflow, uint
size_limit, uint align)
if (size != bytes_read)
return log_msg_ret("bread", -EINVAL);
buf[size] = '\0';
+
+ *bufp = buf;
+
+ return 0;
+}
+
+int bootmeth_alloc_file(struct bootflow *bflow, uint size_limit, uint align)
+{
+ void *buf;
+ uint size;
+ int ret;
+
+ size = bflow->size;
+ log_debug(" - script file size %x\n", size);
+ if (size > size_limit)
+ return log_msg_ret("chk", -E2BIG);
+
+ ret = alloc_file(bflow->fname, bflow->size, );
+ if (ret)
+ return log_msg_ret("all", ret);
+
bflow->state = BOOTFLOWST_READY;
bflow->buf = buf;
return 0;
}
+int bootmeth_alloc_other(struct bootflow *bflow, const char *fname,
+void **bufp, uint *sizep)
+{
+ struct blk_desc *desc = NULL;
+ char path[200];
+ loff_t size;
+ void *buf;
+ int ret;
+
+ snprintf(path, sizeof(path), "%s%s", bflow->subdir, fname);
+ log_debug("trying: %s\n", path);
+
+ if (bflow->blk)
+ desc = dev_get_uclass_plat(bflow->blk);
+
+ ret = setup_fs(bflow, desc);
+ if (ret)
+ return log_msg_ret("fs", ret);
+
+ ret = fs_size(path, );
+ log_debug(" %s - err=%d\n", path, ret);
+
+ ret = setup_fs(bflow, desc);
+ if (ret)
+ return log_msg_ret("fs", ret);
+
+ ret = alloc_file(path, size, );
+ if (ret)
+ return log_msg_ret("all", ret);
+
+ *bufp = buf;
+ *sizep = size;
+
+ return 0;
+}
+
int bootmeth_common_read_file(struct udevice *dev, struct bootflow *bflow,
const char *file_path, ulong addr, ulong *sizep)
{
diff --git a/boot/bootmeth_script.c b/boot/bootmeth_script.c
index 6f2a09846db..a8f77e29f99 100644
--- a/boot/bootmeth_script.c
+++ b/boot/bootmeth_script.c
@@ -109,6 +109,10 @@ static int script_read_bootflow(struct udevice *dev,
struct bootflow *bflow)
if (ret)
return log_msg_ret("inf", ret);
+ ret = bootmeth_alloc_other(bflow, "boot.bmp", >logo,
+ >logo_size);
+ /* ignore error */
+
return 0;
}
diff --git a/cmd/bootflow.c b/cmd/bootflow.c
index 6b8ac8c8504..495ef85f25b 100644
--- a/cmd/bootflow.c
+++ b/cmd/bootflow.c
@@ -338,6 +338,12 @@ static int do_bootflow_info(struct cmd_tbl *cmdtp, int
flag, int argc,
printf("Buffer:%lx\n", (ulong)map_to_sysmem(bflow->buf));
printf("Size: %x (%d bytes)\n", bflow->size, bflow->size);
printf("OS:%s\n", bflow->os_name ? bflow->os_name : "(none)");
+ printf("Logo: %s\n", bflow->logo ?
+ simple_xtoa((ulong)map_to_sysmem(bflow->logo)) : "(none)");
+ if (bflow->logo) {
+ printf("Logo size: %x (%d bytes)\n", bflow->logo_size,
+ bflow->logo_size);
+ }
printf("Error: %d\n", bflow->err);
if (dump && bflow->buf) {
/* Set some sort of maximum on the size */
diff --git a/include/bootflow.h b/include/bootflow.h
index 776158c65df..8a07ab30191 100644
--- a/include/bootflow.h
+++ b/include/bootflow.h
@@ -49,6 +49,8 @@ enum bootflow_state_t {
* @state: Current state (enum bootflow_state_t)
* @subdir: Subdirectory to fetch files from (with
[PATCH v3 17/25] menu: Factor out menu-keypress decoding
Move this code into a separate function so that it can be used in the new
VBE menu.
Signed-off-by: Simon Glass
---
(no changes since v1)
common/menu.c | 48 ++--
include/menu.h | 10 ++
2 files changed, 40 insertions(+), 18 deletions(-)
diff --git a/common/menu.c b/common/menu.c
index 45f36ae3ede..cdcdbb2a185 100644
--- a/common/menu.c
+++ b/common/menu.c
@@ -483,26 +483,11 @@ enum bootmenu_key bootmenu_autoboot_loop(struct
bootmenu_data *menu,
return key;
}
-enum bootmenu_key bootmenu_loop(struct bootmenu_data *menu,
- struct cli_ch_state *cch)
+enum bootmenu_key bootmenu_conv_key(int ichar)
{
- enum bootmenu_key key = BKEY_NONE;
- int c;
-
- c = cli_ch_process(cch, 0);
- if (!c) {
- while (!c && !tstc()) {
- schedule();
- mdelay(10);
- c = cli_ch_process(cch, -ETIMEDOUT);
- }
- if (!c) {
- c = getchar();
- c = cli_ch_process(cch, c);
- }
- }
+ enum bootmenu_key key;
- switch (c) {
+ switch (ichar) {
case '\n':
/* enter key was pressed */
key = BKEY_SELECT;
@@ -527,7 +512,34 @@ enum bootmenu_key bootmenu_loop(struct bootmenu_data *menu,
case ' ':
key = BKEY_SPACE;
break;
+ default:
+ key = BKEY_NONE;
+ break;
+ }
+
+ return key;
+}
+
+enum bootmenu_key bootmenu_loop(struct bootmenu_data *menu,
+ struct cli_ch_state *cch)
+{
+ enum bootmenu_key key;
+ int c;
+
+ c = cli_ch_process(cch, 0);
+ if (!c) {
+ while (!c && !tstc()) {
+ schedule();
+ mdelay(10);
+ c = cli_ch_process(cch, -ETIMEDOUT);
+ }
+ if (!c) {
+ c = getchar();
+ c = cli_ch_process(cch, c);
+ }
}
+ key = bootmenu_conv_key(c);
+
return key;
}
diff --git a/include/menu.h b/include/menu.h
index 3996075a337..1e88141d6bf 100644
--- a/include/menu.h
+++ b/include/menu.h
@@ -53,6 +53,8 @@ enum bootmenu_key {
BKEY_PLUS,
BKEY_MINUS,
BKEY_SPACE,
+
+ BKEY_COUNT,
};
/**
@@ -101,4 +103,12 @@ enum bootmenu_key bootmenu_autoboot_loop(struct
bootmenu_data *menu,
enum bootmenu_key bootmenu_loop(struct bootmenu_data *menu,
struct cli_ch_state *cch);
+/**
+ * bootmenu_conv_key() - Convert a U-Boot keypress into a menu key
+ *
+ * @ichar: Keypress to convert (ASCII, including control characters)
+ * Returns: Menu key that corresponds to @ichar, or BKEY_NONE if none
+ */
+enum bootmenu_key bootmenu_conv_key(int ichar);
+
#endif /* __MENU_H__ */
--
2.39.0.314.g84b9a713c41-goog
[PATCH v3 14/25] video: Add font functions to the vidconsole API
Support for fonts currently depends on the type of vidconsole in use. Add
two new methods to enumerate fonts and to set the font.
Fix a few other method comments while we are here.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Rename vidconsole_get_font() to vidconsole_get_font_size()
cmd/font.c| 11 -
drivers/video/console_truetype.c | 27 +++
drivers/video/vidconsole-uclass.c | 33 ++
include/video_console.h | 75 ++-
test/cmd/font.c | 6 +--
5 files changed, 127 insertions(+), 25 deletions(-)
diff --git a/cmd/font.c b/cmd/font.c
index 3e522f3aaa1..7b4347f32b5 100644
--- a/cmd/font.c
+++ b/cmd/font.c
@@ -15,7 +15,11 @@
static int do_font_list(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
- vidconsole_list_fonts();
+ struct udevice *dev;
+
+ if (uclass_first_device_err(UCLASS_VIDEO_CONSOLE, ))
+ return CMD_RET_FAILURE;
+ vidconsole_list_fonts(dev);
return 0;
}
@@ -47,6 +51,7 @@ static int do_font_select(struct cmd_tbl *cmdtp, int flag,
int argc,
static int do_font_size(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
+ const char *font_name;
struct udevice *dev;
uint size;
int ret;
@@ -56,9 +61,11 @@ static int do_font_size(struct cmd_tbl *cmdtp, int flag, int
argc,
if (uclass_first_device_err(UCLASS_VIDEO_CONSOLE, ))
return CMD_RET_FAILURE;
+ font_name = vidconsole_get_font_size(dev, );
size = dectoul(argv[1], NULL);
- ret = vidconsole_select_font(dev, NULL, size);
+
+ ret = vidconsole_select_font(dev, font_name, size);
if (ret) {
printf("Failed (error %d)\n", ret);
return CMD_RET_FAILURE;
diff --git a/drivers/video/console_truetype.c b/drivers/video/console_truetype.c
index 4abc0bc2ff1..9cac9a6de4d 100644
--- a/drivers/video/console_truetype.c
+++ b/drivers/video/console_truetype.c
@@ -584,14 +584,20 @@ static struct font_info *console_truetype_find_font(void)
return NULL;
}
-void vidconsole_list_fonts(void)
+int console_truetype_get_font(struct udevice *dev, int seq,
+ struct vidfont_info *info)
{
struct font_info *tab;
+ int i;
- for (tab = font_table; tab->begin; tab++) {
- if (abs(tab->begin - tab->end) > 4)
- printf("%s\n", tab->name);
+ for (i = 0, tab = font_table; tab->begin; tab++, i++) {
+ if (i == seq && font_valid(tab)) {
+ info->name = tab->name;
+ return 0;
+ }
}
+
+ return -ENOENT;
}
/**
@@ -674,7 +680,8 @@ static void select_metrics(struct udevice *dev, struct
console_tt_metrics *met)
vc_priv->tab_width_frac = VID_TO_POS(met->font_size) * 8 / 2;
}
-int vidconsole_select_font(struct udevice *dev, const char *name, uint size)
+static int truetype_select_font(struct udevice *dev, const char *name,
+ uint size)
{
struct console_tt_priv *priv = dev_get_priv(dev);
struct console_tt_metrics *met;
@@ -684,7 +691,7 @@ int vidconsole_select_font(struct udevice *dev, const char
*name, uint size)
if (!size)
size = CONFIG_CONSOLE_TRUETYPE_SIZE;
if (!name)
- name = priv->cur_met->font_name;
+ name = font_table->name;
met = find_metrics(dev, name, size);
if (!met) {
@@ -694,7 +701,9 @@ int vidconsole_select_font(struct udevice *dev, const char
*name, uint size)
int ret;
ret = truetype_add_metrics(dev,
- tab->name, size, tab->begin);
+ tab->name,
+ size,
+ tab->begin);
if (ret < 0)
return log_msg_ret("add", ret);
@@ -715,7 +724,7 @@ int vidconsole_select_font(struct udevice *dev, const char
*name, uint size)
return 0;
}
-const char *vidconsole_get_font(struct udevice *dev, uint *sizep)
+const char *vidconsole_get_font_size(struct udevice *dev, uint *sizep)
{
struct console_tt_priv *priv = dev_get_priv(dev);
struct console_tt_metrics *met = priv->cur_met;
@@ -763,6 +772,8 @@ struct vidconsole_ops console_truetype_ops = {
.set_row= console_truetype_set_row,
.backspace = console_truetype_backspace,
.entry_start= console_truetype_entry_start,
+
[PATCH v3 15/25] bootstd: Read the Operating System name for distro/scripts
Add the concept of an OS name to the bootflow. This typically includes the
OS name, version and kernel version.
Implement this for the distro and script bootmeths so that it works with
Armbian and older version of Fedora.
Signed-off-by: Simon Glass
---
(no changes since v1)
boot/bootflow.c| 1 +
boot/bootmeth_distro.c | 36
boot/bootmeth_script.c | 34 ++
cmd/bootflow.c | 1 +
include/bootflow.h | 3 +++
test/boot/bootflow.c | 1 +
6 files changed, 76 insertions(+)
diff --git a/boot/bootflow.c b/boot/bootflow.c
index f9ad4099244..163cd4953dd 100644
--- a/boot/bootflow.c
+++ b/boot/bootflow.c
@@ -354,6 +354,7 @@ void bootflow_free(struct bootflow *bflow)
free(bflow->subdir);
free(bflow->fname);
free(bflow->buf);
+ free(bflow->os_name);
}
void bootflow_remove(struct bootflow *bflow)
diff --git a/boot/bootmeth_distro.c b/boot/bootmeth_distro.c
index 5c6c687f0a6..6ef0fa1f2c9 100644
--- a/boot/bootmeth_distro.c
+++ b/boot/bootmeth_distro.c
@@ -66,6 +66,38 @@ static int distro_check(struct udevice *dev, struct
bootflow_iter *iter)
return 0;
}
+/**
+ * distro_fill_info() - Decode the extlinux file to find out distro info
+ *
+ * @bflow: Bootflow to process
+ * @return 0 if OK, -ve on error
+ */
+static int distro_fill_info(struct bootflow *bflow)
+{
+ struct membuff mb;
+ char line[200];
+ char *data;
+ int len;
+
+ log_debug("parsing bflow file size %x\n", bflow->size);
+ membuff_init(, bflow->buf, bflow->size);
+ membuff_putraw(, bflow->size, true, );
+ while (len = membuff_readline(, line, sizeof(line) - 1, ' '), len) {
+ char *tok, *p = line;
+
+ tok = strsep(, " ");
+ if (p) {
+ if (!strcmp("label", tok)) {
+ bflow->os_name = strdup(p);
+ if (!bflow->os_name)
+ return log_msg_ret("os", -ENOMEM);
+ }
+ }
+ }
+
+ return 0;
+}
+
static int distro_read_bootflow(struct udevice *dev, struct bootflow *bflow)
{
struct blk_desc *desc;
@@ -99,6 +131,10 @@ static int distro_read_bootflow(struct udevice *dev, struct
bootflow *bflow)
if (ret)
return log_msg_ret("read", ret);
+ ret = distro_fill_info(bflow);
+ if (ret)
+ return log_msg_ret("inf", ret);
+
return 0;
}
diff --git a/boot/bootmeth_script.c b/boot/bootmeth_script.c
index 16c5dadcca1..6f2a09846db 100644
--- a/boot/bootmeth_script.c
+++ b/boot/bootmeth_script.c
@@ -35,6 +35,36 @@ static int script_check(struct udevice *dev, struct
bootflow_iter *iter)
return 0;
}
+/**
+ * script_fill_info() - Decode the U-Boot script to find out distro info
+ *
+ * @bflow: Bootflow to process
+ * @return 0 if OK, -ve on error
+ */
+static int script_fill_info(struct bootflow *bflow)
+{
+ char *name = NULL;
+ char *data;
+ uint len;
+ int ret;
+
+ log_debug("parsing bflow file size %x\n", bflow->size);
+
+ ret = image_locate_script(bflow->buf, bflow->size, NULL, , );
+ if (!ret) {
+ if (strstr(data, "armbianEnv"))
+ name = "Armbian";
+ }
+
+ if (name) {
+ bflow->os_name = strdup(name);
+ if (!bflow->os_name)
+ return log_msg_ret("os", -ENOMEM);
+ }
+
+ return 0;
+}
+
static int script_read_bootflow(struct udevice *dev, struct bootflow *bflow)
{
struct blk_desc *desc = NULL;
@@ -75,6 +105,10 @@ static int script_read_bootflow(struct udevice *dev, struct
bootflow *bflow)
if (ret)
return log_msg_ret("read", ret);
+ ret = script_fill_info(bflow);
+ if (ret)
+ return log_msg_ret("inf", ret);
+
return 0;
}
diff --git a/cmd/bootflow.c b/cmd/bootflow.c
index 313103d2775..6b8ac8c8504 100644
--- a/cmd/bootflow.c
+++ b/cmd/bootflow.c
@@ -337,6 +337,7 @@ static int do_bootflow_info(struct cmd_tbl *cmdtp, int
flag, int argc,
printf("Filename: %s\n", bflow->fname);
printf("Buffer:%lx\n", (ulong)map_to_sysmem(bflow->buf));
printf("Size: %x (%d bytes)\n", bflow->size, bflow->size);
+ printf("OS:%s\n", bflow->os_name ? bflow->os_name : "(none)");
printf("Error: %d\n", bflow->err);
if (dump && bflow->buf) {
/* Set some sort of maximum on the size */
diff --git a/include/bootflow.h b/include/bootflow.h
index 32de261..776158c65df 100644
--- a/include/bootflow.h
+++ b/include/bootflow.h
@@ -52,6 +52,8 @@ enum bootflow_state_t {
* @buf: Bootflow file contents (allocated)
* @size: Size of bootflow file in bytes
* @err: Error number received (0 if OK)
+ * @os_name: Name of the OS / distro being booted, or
[PATCH v3 12/25] video: truetype: Rename the metrics function
This should really have a 'truetype' prefix. Fix it.
Signed-off-by: Simon Glass
---
(no changes since v1)
drivers/video/console_truetype.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/console_truetype.c b/drivers/video/console_truetype.c
index 6859c9fa116..4abc0bc2ff1 100644
--- a/drivers/video/console_truetype.c
+++ b/drivers/video/console_truetype.c
@@ -595,7 +595,7 @@ void vidconsole_list_fonts(void)
}
/**
- * vidconsole_add_metrics() - Add a new font/size combination
+ * truetype_add_metrics() - Add a new font/size combination
*
* @dev: Video console device to update
* @font_name: Name of font
@@ -604,8 +604,8 @@ void vidconsole_list_fonts(void)
* @return 0 if OK, -EPERM if stbtt failed, -E2BIG if the the metrics table is
* full
*/
-static int vidconsole_add_metrics(struct udevice *dev, const char *font_name,
- uint font_size, const void *font_data)
+static int truetype_add_metrics(struct udevice *dev, const char *font_name,
+ uint font_size, const void *font_data)
{
struct console_tt_priv *priv = dev_get_priv(dev);
struct console_tt_metrics *met;
@@ -693,7 +693,7 @@ int vidconsole_select_font(struct udevice *dev, const char
*name, uint size)
!strcmp(name, tab->name)) {
int ret;
- ret = vidconsole_add_metrics(dev,
+ ret = truetype_add_metrics(dev,
tab->name, size, tab->begin);
if (ret < 0)
return log_msg_ret("add", ret);
@@ -745,7 +745,7 @@ static int console_truetype_probe(struct udevice *dev)
return -EBFONT;
}
- ret = vidconsole_add_metrics(dev, tab->name, font_size, tab->begin);
+ ret = truetype_add_metrics(dev, tab->name, font_size, tab->begin);
if (ret < 0)
return log_msg_ret("add", ret);
priv->cur_met = >metrics[ret];
--
2.39.0.314.g84b9a713c41-goog
[PATCH v3 11/25] video: Enable VIDEO_ANSI by default only with EFI
This is not generally needed unless EFI_LOADER is used. Adjust the default setting to reduce the size of the U-Boot build. Signed-off-by: Simon Glass --- (no changes since v1) drivers/video/Kconfig | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index c841b99bb30..0c914dc1165 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -112,10 +112,13 @@ config VIDEO_BPP32 config VIDEO_ANSI bool "Support ANSI escape sequences in video console" - default y + default y if EFI_LOADER help Enable ANSI escape sequence decoding for a more fully functional - console. + console. Functionality includes changing the text colour and moving + the cursor. These date from the 1970s and are still widely used today + to control a text terminal. U-Boot implements these by decoding the + sequences and performing the appropriate operation. config VIDEO_MIPI_DSI bool "Support MIPI DSI interface" -- 2.39.0.314.g84b9a713c41-goog
[PATCH v3 10/25] image: Move common image code to image_board and command
We should use the cmd/ directory for commands rather than for common code
used elsewhere in U-Boot. Move the common 'source' code into
image-board.c to achieve this.
The image_source_script() function needs to call run_command_list() so
seems to belong better in the command library. Move and rename it.
Signed-off-by: Simon Glass
---
(no changes since v1)
.../cmd_stm32prog/cmd_stm32prog.c | 2 +-
boot/bootmeth_script.c| 2 +-
boot/image-board.c| 133 +++
cmd/source.c | 155 +-
common/command.c | 19 +++
drivers/usb/gadget/f_sdp.c| 2 +-
include/command.h | 12 ++
include/image.h | 12 --
8 files changed, 168 insertions(+), 169 deletions(-)
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
index 007f7131306..6fb3d868d77 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
@@ -154,7 +154,7 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag,
int argc,
do_bootz(cmdtp, 0, 4, bootm_argv);
}
if (data->script)
- image_source_script(data->script, "script@stm32prog");
+ cmd_source_script(data->script, "script@stm32prog");
if (reset) {
puts("Reset...\n");
diff --git a/boot/bootmeth_script.c b/boot/bootmeth_script.c
index d1c3f940037..16c5dadcca1 100644
--- a/boot/bootmeth_script.c
+++ b/boot/bootmeth_script.c
@@ -101,7 +101,7 @@ static int script_boot(struct udevice *dev, struct bootflow
*bflow)
log_debug("mmc_bootdev: %s\n", env_get("mmc_bootdev"));
addr = map_to_sysmem(bflow->buf);
- ret = image_source_script(addr, NULL);
+ ret = cmd_source_script(addr, NULL);
if (ret)
return log_msg_ret("boot", ret);
diff --git a/boot/image-board.c b/boot/image-board.c
index 34d1e5f18be..7f96a80c85b 100644
--- a/boot/image-board.c
+++ b/boot/image-board.c
@@ -971,3 +971,136 @@ void genimg_print_time(time_t timestamp)
tm.tm_year, tm.tm_mon, tm.tm_mday,
tm.tm_hour, tm.tm_min, tm.tm_sec);
}
+
+/**
+ * get_default_image() - Return default property from /images
+ *
+ * Return: Pointer to value of default property (or NULL)
+ */
+static const char *get_default_image(const void *fit)
+{
+ int images_noffset;
+
+ images_noffset = fdt_path_offset(fit, FIT_IMAGES_PATH);
+ if (images_noffset < 0)
+ return NULL;
+
+ return fdt_getprop(fit, images_noffset, FIT_DEFAULT_PROP, NULL);
+}
+
+int image_locate_script(void *buf, int size, const char *fit_uname,
+ char **datap, uint *lenp)
+{
+ const struct legacy_img_hdr *hdr;
+ const void *fit_data;
+ const void *fit_hdr;
+ size_t fit_len;
+ int noffset;
+ int verify;
+ ulong len;
+ u32 *data;
+
+ verify = env_get_yesno("verify");
+
+ switch (genimg_get_format(buf)) {
+ case IMAGE_FORMAT_LEGACY:
+ if (IS_ENABLED(CONFIG_LEGACY_IMAGE_FORMAT)) {
+ hdr = buf;
+
+ if (!image_check_magic(hdr)) {
+ puts("Bad magic number\n");
+ return 1;
+ }
+
+ if (!image_check_hcrc(hdr)) {
+ puts("Bad header crc\n");
+ return 1;
+ }
+
+ if (verify) {
+ if (!image_check_dcrc(hdr)) {
+ puts("Bad data crc\n");
+ return 1;
+ }
+ }
+
+ if (!image_check_type(hdr, IH_TYPE_SCRIPT)) {
+ puts("Bad image type\n");
+ return 1;
+ }
+
+ /* get length of script */
+ data = (u32 *)image_get_data(hdr);
+
+ len = uimage_to_cpu(*data);
+ if (!len) {
+ puts("Empty Script\n");
+ return 1;
+ }
+
+ /*
+* scripts are just multi-image files with one
+* component, so seek past the zero-terminated sequence
+* of image lengths to get to the actual image data
+*/
+ while (*data++);
+ }
+ break;
+ case IMAGE_FORMAT_FIT:
+ if (IS_ENABLED(CONFIG_FIT)) {
+ fit_hdr = buf;
[PATCH v3 09/25] image: Add a function to find a script in an image
Split this functionality out of the 'source' command so it can be used
from another place. For now leave it where it is, but a future patch will
move it out of cmd/
Signed-off-by: Simon Glass
---
(no changes since v1)
cmd/source.c| 173 ++--
include/image.h | 13
2 files changed, 107 insertions(+), 79 deletions(-)
diff --git a/cmd/source.c b/cmd/source.c
index 698d9f86d96..dfa995f1df6 100644
--- a/cmd/source.c
+++ b/cmd/source.c
@@ -24,7 +24,6 @@
#include
#include
-#if defined(CONFIG_FIT)
/**
* get_default_image() - Return default property from /images
*
@@ -40,123 +39,139 @@ static const char *get_default_image(const void *fit)
return fdt_getprop(fit, images_noffset, FIT_DEFAULT_PROP, NULL);
}
-#endif
-int image_source_script(ulong addr, const char *fit_uname)
+int image_locate_script(void *buf, int size, const char *fit_uname,
+ char **datap, uint *lenp)
{
ulong len;
-#if defined(CONFIG_LEGACY_IMAGE_FORMAT)
const struct legacy_img_hdr *hdr;
-#endif
u32 *data;
int verify;
- void *buf;
-#if defined(CONFIG_FIT)
const void* fit_hdr;
int noffset;
const void *fit_data;
size_t fit_len;
-#endif
verify = env_get_yesno("verify");
- buf = map_sysmem(addr, 0);
switch (genimg_get_format(buf)) {
-#if defined(CONFIG_LEGACY_IMAGE_FORMAT)
case IMAGE_FORMAT_LEGACY:
- hdr = buf;
+ if (IS_ENABLED(CONFIG_LEGACY_IMAGE_FORMAT)) {
+ hdr = buf;
- if (!image_check_magic (hdr)) {
- puts ("Bad magic number\n");
- return 1;
- }
+ if (!image_check_magic(hdr)) {
+ puts("Bad magic number\n");
+ return 1;
+ }
- if (!image_check_hcrc (hdr)) {
- puts ("Bad header crc\n");
- return 1;
- }
+ if (!image_check_hcrc(hdr)) {
+ puts("Bad header crc\n");
+ return 1;
+ }
+
+ if (verify) {
+ if (!image_check_dcrc(hdr)) {
+ puts("Bad data crc\n");
+ return 1;
+ }
+ }
- if (verify) {
- if (!image_check_dcrc (hdr)) {
- puts ("Bad data crc\n");
+ if (!image_check_type(hdr, IH_TYPE_SCRIPT)) {
+ puts("Bad image type\n");
return 1;
}
- }
- if (!image_check_type (hdr, IH_TYPE_SCRIPT)) {
- puts ("Bad image type\n");
- return 1;
- }
+ /* get length of script */
+ data = (u32 *)image_get_data(hdr);
- /* get length of script */
- data = (u32 *)image_get_data (hdr);
+ len = uimage_to_cpu(*data);
+ if (!len) {
+ puts("Empty Script\n");
+ return 1;
+ }
- if ((len = uimage_to_cpu (*data)) == 0) {
- puts ("Empty Script\n");
- return 1;
+ /*
+* scripts are just multi-image files with one
+* component, so seek past the zero-terminated sequence
+* of image lengths to get to the actual image data
+*/
+ while (*data++);
}
-
- /*
-* scripts are just multi-image files with one component, seek
-* past the zero-terminated sequence of image lengths to get
-* to the actual image data
-*/
- while (*data++);
break;
-#endif
-#if defined(CONFIG_FIT)
case IMAGE_FORMAT_FIT:
- fit_hdr = buf;
- if (fit_check_format(fit_hdr, IMAGE_SIZE_INVAL)) {
- puts ("Bad FIT image format\n");
- return 1;
- }
+ if (IS_ENABLED(CONFIG_FIT)) {
+ fit_hdr = buf;
+ if (fit_check_format(fit_hdr, IMAGE_SIZE_INVAL)) {
+ puts("Bad FIT image format\n");
+ return 1;
+ }
- if (!fit_uname)
- fit_uname =
[PATCH v3 07/25] menu: Use a switch statement
Convert the long line of if() statements to a switch() since this makes
better use of the C language.
Signed-off-by: Simon Glass
---
(no changes since v1)
common/menu.c | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/common/menu.c b/common/menu.c
index 6842f5409d6..7db98942a61 100644
--- a/common/menu.c
+++ b/common/menu.c
@@ -543,22 +543,31 @@ enum bootmenu_key bootmenu_loop(struct bootmenu_data
*menu, int *esc)
break;
}
- /* enter key was pressed */
- if (c == '\r')
+ switch (c) {
+ case '\r':
+ /* enter key was pressed */
key = BKEY_SELECT;
-
- /* ^C was pressed */
- if (c == 0x3)
+ break;
+ case CTL_CH('c'):
+ /* ^C was pressed */
key = BKEY_QUIT;
-
- if (c == '+')
+ break;
+ case CTL_CH('p'):
+ key = BKEY_UP;
+ break;
+ case CTL_CH('n'):
+ key = BKEY_DOWN;
+ break;
+ case '+':
key = BKEY_PLUS;
-
- if (c == '-')
+ break;
+ case '-':
key = BKEY_MINUS;
-
- if (c == ' ')
+ break;
+ case ' ':
key = BKEY_SPACE;
+ break;
+ }
return key;
}
--
2.39.0.314.g84b9a713c41-goog
[PATCH v3 06/25] menu: Update bootmenu_loop() to return the code
Use the return value to save having to pass around a pointer. This also
resolves any ambiguity about what *key contains when the function is
called.
Signed-off-by: Simon Glass
---
(no changes since v1)
cmd/bootmenu.c | 2 +-
cmd/eficonfig.c | 4 ++--
common/menu.c | 30 --
include/menu.h | 11 +--
4 files changed, 24 insertions(+), 23 deletions(-)
diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
index 0e22f504fe4..573afe16609 100644
--- a/cmd/bootmenu.c
+++ b/cmd/bootmenu.c
@@ -96,7 +96,7 @@ static char *bootmenu_choice_entry(void *data)
key = bootmenu_autoboot_loop(menu, );
} else {
/* Some key was pressed, so autoboot was stopped */
- bootmenu_loop(menu, , );
+ key = bootmenu_loop(menu, );
}
switch (key) {
diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
index 8f246bc271f..96cb1a367f3 100644
--- a/cmd/eficonfig.c
+++ b/cmd/eficonfig.c
@@ -191,7 +191,7 @@ static char *eficonfig_choice_entry(void *data)
struct efimenu *efi_menu = data;
while (1) {
- bootmenu_loop((struct bootmenu_data *)efi_menu, , );
+ key = bootmenu_loop((struct bootmenu_data *)efi_menu, );
switch (key) {
case BKEY_UP:
@@ -1868,7 +1868,7 @@ static efi_status_t
eficonfig_choice_change_boot_order(struct efimenu *efi_menu)
struct eficonfig_entry *entry, *tmp;
while (1) {
- bootmenu_loop(NULL, , );
+ key = bootmenu_loop(NULL, );
switch (key) {
case BKEY_PLUS:
diff --git a/common/menu.c b/common/menu.c
index bafc8470d7d..6842f5409d6 100644
--- a/common/menu.c
+++ b/common/menu.c
@@ -476,9 +476,9 @@ enum bootmenu_key bootmenu_autoboot_loop(struct
bootmenu_data *menu, int *esc)
return key;
}
-void bootmenu_loop(struct bootmenu_data *menu,
- enum bootmenu_key *key, int *esc)
+enum bootmenu_key bootmenu_loop(struct bootmenu_data *menu, int *esc)
{
+ enum bootmenu_key key = BKEY_NONE;
int c;
if (*esc == 1) {
@@ -505,17 +505,17 @@ void bootmenu_loop(struct bootmenu_data *menu,
/* First char of ANSI escape sequence '\e' */
if (c == '\e') {
*esc = 1;
- *key = BKEY_NONE;
+ key = BKEY_NONE;
}
break;
case 1:
/* Second char of ANSI '[' */
if (c == '[') {
*esc = 2;
- *key = BKEY_NONE;
+ key = BKEY_NONE;
} else {
/* Alone ESC key was pressed */
- *key = BKEY_QUIT;
+ key = BKEY_QUIT;
*esc = (c == '\e') ? 1 : 0;
}
break;
@@ -524,7 +524,7 @@ void bootmenu_loop(struct bootmenu_data *menu,
/* Third char of ANSI (number '1') - optional */
if (*esc == 2 && c == '1') {
*esc = 3;
- *key = BKEY_NONE;
+ key = BKEY_NONE;
break;
}
@@ -532,31 +532,33 @@ void bootmenu_loop(struct bootmenu_data *menu,
/* ANSI 'A' - key up was pressed */
if (c == 'A')
- *key = BKEY_UP;
+ key = BKEY_UP;
/* ANSI 'B' - key down was pressed */
else if (c == 'B')
- *key = BKEY_DOWN;
+ key = BKEY_DOWN;
/* other key was pressed */
else
- *key = BKEY_NONE;
+ key = BKEY_NONE;
break;
}
/* enter key was pressed */
if (c == '\r')
- *key = BKEY_SELECT;
+ key = BKEY_SELECT;
/* ^C was pressed */
if (c == 0x3)
- *key = BKEY_QUIT;
+ key = BKEY_QUIT;
if (c == '+')
- *key = BKEY_PLUS;
+ key = BKEY_PLUS;
if (c == '-')
- *key = BKEY_MINUS;
+ key = BKEY_MINUS;
if (c == ' ')
- *key = BKEY_SPACE;
+ key = BKEY_SPACE;
+
+ return key;
}
diff --git a/include/menu.h b/include/menu.h
index 9f30a3c1acd..8b9b36214f7 100644
--- a/include/menu.h
+++ b/include/menu.h
@@ -83,7 +83,10 @@ enum bootmenu_key bootmenu_autoboot_loop(struct
bootmenu_data *menu, int *esc);
* character is recognised
*
* @menu: Menu being processed
- * @key: Returns the code for the key the user pressed:
+ * @esc: On input, a non-zero value indicates that an escape sequence has
+ * resulted in that many characters so far. On exit this is updated to the
+ * new number of characters
[PATCH v3 05/25] menu: Update bootmenu_autoboot_loop() to return the code
Use the return value to save having to pass around a pointer. This also
resolves any ambiguity about what *key contains when the function is
called.
Signed-off-by: Simon Glass
---
(no changes since v1)
cmd/bootmenu.c | 2 +-
common/menu.c | 16 +---
include/menu.h | 7 +++
3 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
index c80004c54dc..0e22f504fe4 100644
--- a/cmd/bootmenu.c
+++ b/cmd/bootmenu.c
@@ -93,7 +93,7 @@ static char *bootmenu_choice_entry(void *data)
while (1) {
if (menu->delay >= 0) {
/* Autoboot was not stopped */
- bootmenu_autoboot_loop(menu, , );
+ key = bootmenu_autoboot_loop(menu, );
} else {
/* Some key was pressed, so autoboot was stopped */
bootmenu_loop(menu, , );
diff --git a/common/menu.c b/common/menu.c
index a245c5a9c6c..bafc8470d7d 100644
--- a/common/menu.c
+++ b/common/menu.c
@@ -425,9 +425,9 @@ int menu_destroy(struct menu *m)
return 1;
}
-void bootmenu_autoboot_loop(struct bootmenu_data *menu,
- enum bootmenu_key *key, int *esc)
+enum bootmenu_key bootmenu_autoboot_loop(struct bootmenu_data *menu, int *esc)
{
+ enum bootmenu_key key = BKEY_NONE;
int i, c;
while (menu->delay > 0) {
@@ -446,16 +446,16 @@ void bootmenu_autoboot_loop(struct bootmenu_data *menu,
switch (c) {
case '\e':
*esc = 1;
- *key = BKEY_NONE;
+ key = BKEY_NONE;
break;
case '\r':
- *key = BKEY_SELECT;
+ key = BKEY_SELECT;
break;
case 0x3: /* ^C */
- *key = BKEY_QUIT;
+ key = BKEY_QUIT;
break;
default:
- *key = BKEY_NONE;
+ key = BKEY_NONE;
break;
}
@@ -471,7 +471,9 @@ void bootmenu_autoboot_loop(struct bootmenu_data *menu,
printf(ANSI_CURSOR_POSITION ANSI_CLEAR_LINE, menu->count + 5, 1);
if (menu->delay == 0)
- *key = BKEY_SELECT;
+ key = BKEY_SELECT;
+
+ return key;
}
void bootmenu_loop(struct bootmenu_data *menu,
diff --git a/include/menu.h b/include/menu.h
index 29b457921e9..9f30a3c1acd 100644
--- a/include/menu.h
+++ b/include/menu.h
@@ -65,14 +65,13 @@ enum bootmenu_key {
* indicating that the current option should be chosen.
*
* @menu: Menu being processed
- * @key: Returns the code for the key the user pressed:
+ * @esc: Set to 1 if the escape key is pressed, otherwise not updated
+ * Returns: code for the key the user pressed:
* enter: KEY_SELECT
* Ctrl-C: KEY_QUIT
* anything else: KEY_NONE
- * @esc: Set to 1 if the escape key is pressed, otherwise not updated
*/
-void bootmenu_autoboot_loop(struct bootmenu_data *menu,
- enum bootmenu_key *key, int *esc);
+enum bootmenu_key bootmenu_autoboot_loop(struct bootmenu_data *menu, int *esc);
/**
* bootmenu_loop() - handle waiting for a keypress when autoboot is disabled
--
2.39.0.314.g84b9a713c41-goog
[PATCH v3 03/25] bootmenu: Add a few comments
The behaviour of these two functions is completely undocumented. Add some
notes so the poor, suffering dev can figure out what is going on.
Signed-off-by: Simon Glass
---
(no changes since v1)
include/menu.h | 42 ++
1 file changed, 42 insertions(+)
diff --git a/include/menu.h b/include/menu.h
index 702aacb170c..0b4d9734149 100644
--- a/include/menu.h
+++ b/include/menu.h
@@ -42,6 +42,7 @@ struct bootmenu_data {
struct bootmenu_entry *first; /* first menu entry */
};
+/** enum bootmenu_key - keys that can be returned by the bootmenu */
enum bootmenu_key {
KEY_NONE = 0,
KEY_UP,
@@ -53,8 +54,49 @@ enum bootmenu_key {
KEY_SPACE,
};
+/**
+ * bootmenu_autoboot_loop() - handle autobooting if no key is pressed
+ *
+ * This shows a prompt to allow the user to press a key to interrupt auto boot
+ * of the first menu option.
+ *
+ * It then waits for the required time (menu->delay in seconds) for a key to be
+ * pressed. If nothing is pressed in that time, @key returns KEY_SELECT
+ * indicating that the current option should be chosen.
+ *
+ * @menu: Menu being processed
+ * @key: Returns the code for the key the user pressed:
+ * enter: KEY_SELECT
+ * Ctrl-C: KEY_QUIT
+ * anything else: KEY_NONE
+ * @esc: Set to 1 if the escape key is pressed, otherwise not updated
+ */
void bootmenu_autoboot_loop(struct bootmenu_data *menu,
enum bootmenu_key *key, int *esc);
+
+/**
+ * bootmenu_loop() - handle waiting for a keypress when autoboot is disabled
+ *
+ * This is used when the menu delay is negative, indicating that the delay has
+ * elapsed, or there was no delay to begin with.
+ *
+ * It reads a character and processes it, returning a menu-key code if a
+ * character is recognised
+ *
+ * @menu: Menu being processed
+ * @key: Returns the code for the key the user pressed:
+ * enter: KEY_SELECT
+ * Ctrl-C: KEY_QUIT
+ * Up arrow: KEY_UP
+ * Down arrow: KEY_DOWN
+ * Escape (by itself): KEY_QUIT
+ * Plus: KEY_PLUS
+ * Minus: KEY_MINUS
+ * Space: KEY_SPACE
+ * @esc: On input, a non-zero value indicates that an escape sequence has
+ * resulted in that many characters so far. On exit this is updated to the
+ * new number of characters
+ */
void bootmenu_loop(struct bootmenu_data *menu,
enum bootmenu_key *key, int *esc);
--
2.39.0.314.g84b9a713c41-goog
[PATCH v3 01/25] sandbox: Enable mmc command and legacy images
The mmc command is useful for testing mmc disk images in sandbox, so
enable it. We also need to enable legacy images so that we can run tests
which use them.
Disable it for a few avb tests since MMC is not implemented there yet.
Signed-off-by: Simon Glass
---
(no changes since v1)
configs/sandbox_defconfig | 2 ++
configs/sandbox_flattree_defconfig | 2 ++
test/py/tests/test_android/test_avb.py | 2 ++
3 files changed, 6 insertions(+)
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index be46cae7aad..0b26673bf4f 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -13,6 +13,7 @@ CONFIG_FIT=y
CONFIG_FIT_RSASSA_PSS=y
CONFIG_FIT_CIPHER=y
CONFIG_FIT_VERBOSE=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
CONFIG_BOOTSTAGE=y
CONFIG_BOOTSTAGE_REPORT=y
CONFIG_BOOTSTAGE_FDT=y
@@ -72,6 +73,7 @@ CONFIG_CMD_IDE=y
CONFIG_CMD_I2C=y
CONFIG_CMD_LOADM=y
CONFIG_CMD_LSBLK=y
+CONFIG_CMD_MMC=y
CONFIG_CMD_MUX=y
CONFIG_CMD_OSD=y
CONFIG_CMD_PCI=y
diff --git a/configs/sandbox_flattree_defconfig
b/configs/sandbox_flattree_defconfig
index 88aaddfa4ae..41453e0e2fa 100644
--- a/configs/sandbox_flattree_defconfig
+++ b/configs/sandbox_flattree_defconfig
@@ -11,6 +11,7 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_FIT_VERBOSE=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
CONFIG_BOOTSTAGE=y
CONFIG_BOOTSTAGE_REPORT=y
CONFIG_BOOTSTAGE_FDT=y
@@ -40,6 +41,7 @@ CONFIG_CMD_DEMO=y
CONFIG_CMD_GPIO=y
CONFIG_CMD_GPT=y
CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
CONFIG_CMD_OSD=y
CONFIG_CMD_PCI=y
CONFIG_CMD_REMOTEPROC=y
diff --git a/test/py/tests/test_android/test_avb.py
b/test/py/tests/test_android/test_avb.py
index a3f883136b0..bc5c5b55821 100644
--- a/test/py/tests/test_android/test_avb.py
+++ b/test/py/tests/test_android/test_avb.py
@@ -39,6 +39,7 @@ def test_avb_verify(u_boot_console):
@pytest.mark.buildconfigspec('cmd_avb')
@pytest.mark.buildconfigspec('cmd_mmc')
+@pytest.mark.notbuildconfigspec('sandbox')
def test_avb_mmc_uuid(u_boot_console):
"""Check if 'avb get_uuid' works, compare results with
'part list mmc 1' output
@@ -97,6 +98,7 @@ def test_avb_is_unlocked(u_boot_console):
@pytest.mark.buildconfigspec('cmd_avb')
@pytest.mark.buildconfigspec('cmd_mmc')
+@pytest.mark.notbuildconfigspec('sandbox')
def test_avb_mmc_read(u_boot_console):
"""Test mmc read operation
"""
--
2.39.0.314.g84b9a713c41-goog
[PATCH v3 00/25] bootstd: Add a boot menu
So far standard boot lacks a boot menu, although it is possible to create a rudimentary one using the existing 'bootmenu' command. Even then, this text-based menu offer only basic functionality and does not take full advantage of the displays which are common on many devices. This series provides a 'bootflow menu' command which allows the user to select from the available bootflows. An attempt is made to show the name of the available operating systems, by reading more information into the bootflow. A logo can be read also, where supported, so that this can be presented to the user when an option is highlighted. Full use is made of TrueType fonts, if enabled. For cases where only a serial console is available, it falls back to a simple text-based menu. All of this is implementing using a new 'expo' construct, a collection of scenes (like menu screens) which can be navigated by the user to view information and select options. This is fairly general and should be able to cope with a wider array of use cases, with less hacking of the menu code, such as is currently needed for CMD_BOOTEFI_BOOTMGR. Of course it would be possible to enhance the existing menu rather than creating a new setup. Instead it seems better to make the existing menu use expo, if code space permits. It avoids the event-loop problem and should be more extensible, given its loosely coupled components and use of IDs instead of pointers. Further motivation is provided in the documentation. For now the CLI keypress-decoding code is split out to be used by the new menu. The key codes defined by menu.h are reused also. This is of course just a starting point. Some ideas for future work are included in the documentation. Changes in v3: - Rebase to master Changes in v2: - Drop the _add suffix on expo creation function - Fix 'touse' typo - Fix pylint warning in mkdir_cond() - Put strings in a separate structure referenced by ID - Rebase to master - Rename vidconsole_get_font() to vidconsole_get_font_size() - Update for new API Simon Glass (25): sandbox: Enable mmc command and legacy images cli: Move readline character-processing to a state machine bootmenu: Add a few comments menu: Rename KEY_... to BKEY_... menu: Update bootmenu_autoboot_loop() to return the code menu: Update bootmenu_loop() to return the code menu: Use a switch statement menu: Make use of CLI character processing image: Add a function to find a script in an image image: Move common image code to image_board and command video: Enable VIDEO_ANSI by default only with EFI video: truetype: Rename the metrics function video: Fix unchnaged typo video: Add font functions to the vidconsole API bootstd: Read the Operating System name for distro/scripts bootstd: Allow reading a logo for the OS menu: Factor out menu-keypress decoding expo: Add basic implementation expo: Add support for scenes expo: Add support for scene menus expo: Add basic tests bootstd: Support creating a boot menu bootstd: Add a test for the bootstd menu bootstd: Support setting a theme for the menu expo: Add documentation .../cmd_stm32prog/cmd_stm32prog.c | 2 +- arch/sandbox/dts/test.dts | 11 + boot/Kconfig | 12 + boot/Makefile | 3 + boot/bootflow.c | 1 + boot/bootflow_internal.h | 47 ++ boot/bootflow_menu.c | 284 + boot/bootmeth-uclass.c| 69 ++- boot/bootmeth_distro.c| 36 ++ boot/bootmeth_script.c| 40 +- boot/bootstd-uclass.c | 2 + boot/expo.c | 170 ++ boot/image-board.c| 133 + boot/scene.c | 414 ++ boot/scene_internal.h | 123 boot/scene_menu.c | 390 + cmd/bootflow.c| 44 +- cmd/bootmenu.c| 19 +- cmd/eficonfig.c | 38 +- cmd/font.c| 11 +- cmd/source.c | 140 + common/Makefile | 6 +- common/cli_getch.c| 208 +++ common/cli_readline.c | 150 + common/command.c | 19 + common/menu.c | 157 +++-- configs/sandbox_defconfig | 2 + configs/sandbox_flattree_defconfig| 2 + configs/snow_defconfig| 4 + configs/tools-only_defconfig | 2 + doc/develop/expo.rst | 188 ++ doc/develop/index.rst | 1 + drivers/usb/gadget/f_sdp.c
Re: [PATCH] fastboot: remove #ifdef CONFIG when it is possible
On Thu, Jan 05, 2023 at 12:37:58PM +0100, Patrick DELAUNAY wrote:
> Hi Tom,
>
> On 1/3/23 21:35, Tom Rini wrote:
> > On Thu, Dec 15, 2022 at 10:15:50AM +0100, Patrick Delaunay wrote:
> > > Much of the fastboot code predates the introduction of Kconfig and
> > > has quite a few #ifdefs in it which is unnecessary now that we can use
> > > IS_ENABLED() et al.
> > >
> > > Signed-off-by: Patrick Delaunay
> > > ---
> > >
> > > cmd/fastboot.c | 35 +--
> > > drivers/fastboot/fb_command.c | 104
> > > drivers/fastboot/fb_common.c| 11 ++--
> > > drivers/fastboot/fb_getvar.c| 49 ++-
> > > drivers/usb/gadget/f_fastboot.c | 7 +--
> > > include/fastboot.h | 13
> > > net/fastboot.c | 8 +--
> > > 7 files changed, 82 insertions(+), 145 deletions(-)
> > >
> > > diff --git a/cmd/fastboot.c b/cmd/fastboot.c
> > > index b498e4b22bb3..b94dbd548843 100644
> > > --- a/cmd/fastboot.c
> > > +++ b/cmd/fastboot.c
> > > @@ -19,8 +19,14 @@
> > > static int do_fastboot_udp(int argc, char *const argv[],
> > > uintptr_t buf_addr, size_t buf_size)
> > > {
> > > -#if CONFIG_IS_ENABLED(UDP_FUNCTION_FASTBOOT)
> > > - int err = net_loop(FASTBOOT);
> > > + int err;
> > > +
> > > + if (!CONFIG_IS_ENABLED(UDP_FUNCTION_FASTBOOT)) {
> > > + pr_err("Fastboot UDP not enabled\n");
> > > + return CMD_RET_FAILURE;
> > > + }
> > > +
> > > + err = net_loop(FASTBOOT);
> > > if (err < 0) {
> > > printf("fastboot udp error: %d\n", err);
> > > @@ -28,21 +34,21 @@ static int do_fastboot_udp(int argc, char *const
> > > argv[],
> > > }
> > > return CMD_RET_SUCCESS;
> > > -#else
> > > - pr_err("Fastboot UDP not enabled\n");
> > > - return CMD_RET_FAILURE;
> > > -#endif
> > > }
> > This probably needs to become an if (CONFIG_IS_ENABLED(...)) { ... }
> > else { ... } in order to remain size-neutral.
>
>
> Are you sure ?
>
>
> {
> if (!CONFIG_IS_ENABLED(UDP_FUNCTION_FASTBOOT)) {
>
> return CMD_RET_FAILURE;
> }
>
>
>
> return CMD_RET_SUCCESS;
> }
>
>
> For me, it is exactly the same size after compiler/linker than :
>
>
> {
> if (!CONFIG_IS_ENABLED(UDP_FUNCTION_FASTBOOT)) {
>
> return CMD_RET_FAILURE;
> } else {
>
> return CMD_RET_SUCCESS;
>
> }
>
> }
>
>
> if UDP_FUNCTION_FASTBOOTis activated or not
>
> or I forget something during the Christmas break.
If you've size-tested and it's the same, OK. I'm just worried about
strings not being discarded since that's sometimes an unexpected side
effect / bug.
--
Tom
signature.asc
Description: PGP signature
Re: Please pull u-boot-dm/next
On Thu, Jan 05, 2023 at 09:40:20PM -0600, Simon Glass wrote: > Hi Tom, > > This is for the -next branch > > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/14617 > > > The following changes since commit a95410696d21d38b629c61a09c100197c5fc533a: > > Merge branch '2023-01-02-platform-updates' into next (2023-01-02 18:07:41 > -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-dm.git tags/dm-next-5jan23 > > for you to fetch changes up to 8c042fb7f9f475367804b26a892fd522ad8fcfcc: > > patman: add '--get-maintainer-script' argument (2023-01-05 19:21:57 -0700) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 0/4] Fix sparse warnings
On 1/6/23 13:00, Ashok Reddy Soma wrote: Run and fix sparse warnings in below files -drivers/mmc/zynq_sdhci.c -board/xilinx/common/board.h -drivers/gpio/zynqmp_gpio_modepin.c -board/xilinx/versal/board.c Algapally Santosh Sagar (4): xilinx: common: Add missing prototype for board_get_usable_ram_top gpio: zynqmp: Remove unused variable ret xilinx: versal: Add missing prototype drivers: mmc: Change datatype to fix a warning board/xilinx/common/board.h| 4 board/xilinx/versal/board.c| 1 + drivers/gpio/zynqmp_gpio_modepin.c | 3 +-- drivers/mmc/zynq_sdhci.c | 2 +- 4 files changed, 7 insertions(+), 3 deletions(-) Please do it against upstream. M
Re: [PATCH 1/4] xilinx: common: Add missing prototype for board_get_usable_ram_top
On 1/6/23 13:00, Ashok Reddy Soma wrote: From: Algapally Santosh Sagar Add missing prototype to fix the sparse warning, warning: no previous prototype for 'board_get_usable_ram_top' [-Wmissing-prototypes]. Signed-off-by: Algapally Santosh Sagar Signed-off-by: Ashok Reddy Soma --- board/xilinx/common/board.h | 4 1 file changed, 4 insertions(+) diff --git a/board/xilinx/common/board.h b/board/xilinx/common/board.h index 69e642429b..ef7f3f3dce 100644 --- a/board/xilinx/common/board.h +++ b/board/xilinx/common/board.h @@ -11,4 +11,8 @@ int board_late_init_xilinx(void); int xilinx_read_eeprom(void); +#if defined(CONFIG_LMB) +phys_size_t board_get_usable_ram_top(phys_size_t total_size); it is already in include/init.h. M
Re: [PATCH 2/4] gpio: zynqmp: Remove unused variable ret
On 1/6/23 13:00, Ashok Reddy Soma wrote:
From: Algapally Santosh Sagar
There is a unused variable ret, due to which we are getting sparse warning
as below.
warning: variable 'ret' set but not used [-Wunused-but-set-variable].
Remove variable ret.
Signed-off-by: Algapally Santosh Sagar
Signed-off-by: Ashok Reddy Soma
---
drivers/gpio/zynqmp_gpio_modepin.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpio/zynqmp_gpio_modepin.c
b/drivers/gpio/zynqmp_gpio_modepin.c
index 078fd83395..52eda9ceb4 100644
--- a/drivers/gpio/zynqmp_gpio_modepin.c
+++ b/drivers/gpio/zynqmp_gpio_modepin.c
@@ -45,9 +45,8 @@ static int modepin_gpio_set_value(struct udevice *dev,
unsigned int offset,
{
u32 ret_payload[PAYLOAD_ARG_CNT];
u32 out_val = 0;
- int ret;
- ret = get_gpio_modepin(ret_payload);
+ get_gpio_modepin(ret_payload);
:-) what about return error if get_gpio_modepin fails?
M
if (value)
out_val = OUTVAL(offset) | ret_payload[1];
else
Re: [PATCH 4/4] drivers: mmc: Change datatype to fix a warning
mmc: zynq_sdhci: Fix wrong tuning_loop_counter datatype On 1/6/23 13:00, Ashok Reddy Soma wrote: From: Algapally Santosh Sagar tuning_loop_counter is of char type. Change to int to fix below warning. warning: comparison is always false due to limited range of data type. Conceptually description should be done a way that you say I fixed this issue because datatype wasn't correct. And this was reported by spare. And you are doing it because it is not correct not because there is a warning. Warning just points to it. M Signed-off-by: Algapally Santosh Sagar Signed-off-by: Ashok Reddy Soma --- drivers/mmc/zynq_sdhci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c index 7dcf6ad842..be4075c97a 100644 --- a/drivers/mmc/zynq_sdhci.c +++ b/drivers/mmc/zynq_sdhci.c @@ -249,7 +249,7 @@ static int arasan_sdhci_execute_tuning(struct mmc *mmc, u8 opcode) u32 ctrl; struct sdhci_host *host; struct arasan_sdhci_priv *priv = dev_get_priv(mmc->dev); - char tuning_loop_counter = SDHCI_TUNING_LOOP_COUNT; + int tuning_loop_counter = SDHCI_TUNING_LOOP_COUNT; dev_dbg(mmc->dev, "%s\n", __func__);
Re: [PATCH 3/4] xilinx: versal: Add missing prototype
Add missing header in subject? On 1/6/23 13:00, Ashok Reddy Soma wrote: From: Algapally Santosh Sagar Add missing prototype to fix the sparse warning, warning: no previous prototype for 'do_go_exec' [-Wmissing-prototypes]. Signed-off-by: Algapally Santosh Sagar Signed-off-by: Ashok Reddy Soma --- board/xilinx/versal/board.c | 1 + 1 file changed, 1 insertion(+) diff --git a/board/xilinx/versal/board.c b/board/xilinx/versal/board.c index f9f5457ed2..d8562ce47a 100644 --- a/board/xilinx/versal/board.c +++ b/board/xilinx/versal/board.c @@ -22,6 +22,7 @@ #include #include #include "../common/board.h" +#include alphabetic order please. M DECLARE_GLOBAL_DATA_PTR;
Re: Pull request: u-boot-rockchip/for-next
Please send a new PR. On Fri, Jan 6, 2023, 4:40 AM Kever Yang wrote: > Hi Tom, > > I have remove the rk3399.dtsi sync patch and update the for-next > branch. > > Do you need me to resend a new PR, or could you merge the latest > patches? > > The new CI result: > > https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/14618 > > > Thanks, > > - Kever > > On 2023/1/5 17:01, Kever Yang wrote: > > Hi Tom, > > > > Please pull the updates for rockchip platform for next: > > - Add support for rv1126 soc and rv1126 neu2 io board; > > - Add support for rk3399 pine64 pinephone pro board; > > - dts sync from linux for rk3399; > > > > Travis: > > > https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/14601 > > > > Thanks, > > - Kever > > > > The following changes since commit > a95410696d21d38b629c61a09c100197c5fc533a: > > > >Merge branch '2023-01-02-platform-updates' into next (2023-01-02 > 18:07:41 -0500) > > > > are available in the Git repository at: > > > >https://source.denx.de/u-boot/custodians/u-boot-rockchip.git for-next > > > > for you to fetch changes up to 7c2c42aa4b623dae0dd59064ff2b147eb01dbb75: > > > >rockchip: Add initial support for the PINE64 Pinephone Pro > (2023-01-04 17:00:48 +0800) > > > > > > Christopher Obbard (1): > >configs: roc-pc-rk3399: Enable rockchip efuse support > > > > Jagan Teki (25): > >ram: Mark ram-uclass depend on TPL_DM or SPL_DM > >ram: rockchip: Add common ddr type configs > >ram: rockchip: Compute ddr capacity based on grf split > >ram: rockchip: Update ddr pctl regs for px30 > >ram: rockchip: Add rv1126 ddr3 support > >ram: rockchip: Add rv1126 ddr loader params > >ram: rockchip: Add rv1126 ddr driver support > >ram: rockchip: rv1126: Control ddr init prints via DEBUG > >ram: rockchip: Add rv1126 lpddr4 support > >pinctrl: rockchip: Add pinctrl route types > >pinctrl: rockchip: Add rv1126 support > >arch: rockchip: Add cru header for rv1126 > >dt-bindings: clk: Add dt-binding header for RV1126 > >clk: rockchip: Add rv1126 clk support > >dt-bindings: power: Add power-domain header for rv1126 > >arm: rockchip: Add grf header for rv1126 > >ARM: dts: rockchip: Add Rockchip RV1126 pinctrl > >ARM: dts: rockchip: Add Rockchip RV1126 SoC > >arm: rockchip: Add RV1126 arch core support > >arm: rockchip: rv1126: Set dram area unsecure for SPL > >rockchip: mkimage: Add rv1126 support > >ARM: dts: rockchip: rv1126: Add Edgeble Neural Compute Module > 2(Neu2) > >ARM: dts: rockchip: rv1126: Add Edgeble Neural Compute Module > 2(Neu2) IO > >ARM: dts: rockchip: Add rv1126-u-boot.dtsi > >board: rockchip: Add Edgeble Neu2 IO Board > > > > John Keeping (2): > >rc4: mark key as const > >rockchip: mkimage: make RC4 key const > > > > Peter Robinson (3): > >arm64: dts: rk3399: sync rk3399.dtsi from 6.1-rc1 > >arm64: dts: rk3399: Add upstream Pinephone Pro dts > >rockchip: Add initial support for the PINE64 Pinephone Pro > > > > Quentin Schulz (3): > >rockchip: px30: make watchdog and tsadc trigger a first global > reset > >rockchip: clk: add watchdog clock to px30_clk_enable > >rockchip: puma-rk3399: sync DTS with Linux kernel next-20221114 > > > > arch/arm/dts/Makefile |4 + > > arch/arm/dts/rk3399-opp.dtsi |6 +- > > arch/arm/dts/rk3399-pinephone-pro-u-boot.dtsi | 31 + > > arch/arm/dts/rk3399-pinephone-pro.dts | 474 +++ > > arch/arm/dts/rk3399-puma-haikou.dts|5 +- > > arch/arm/dts/rk3399-puma.dtsi | 32 +- > > arch/arm/dts/rk3399-u-boot.dtsi| 36 +- > > arch/arm/dts/rk3399.dtsi | 200 +- > > arch/arm/dts/rv1126-edgeble-neu2-io-u-boot.dtsi| 10 + > > arch/arm/dts/rv1126-edgeble-neu2-io.dts| 42 + > > arch/arm/dts/rv1126-edgeble-neu2.dtsi | 338 ++ > > arch/arm/dts/rv1126-pinctrl.dtsi | 211 ++ > > arch/arm/dts/rv1126-u-boot.dtsi| 62 + > > arch/arm/dts/rv1126.dtsi | 438 +++ > > arch/arm/include/asm/arch-rockchip/cru_rv1126.h| 459 +++ > > .../include/asm/arch-rockchip/dram_spec_timing.h | 452 +++ > > arch/arm/include/asm/arch-rockchip/grf_rv1126.h| 251 ++ > > arch/arm/include/asm/arch-rockchip/sdram_common.h | 214 +- > > arch/arm/include/asm/arch-rockchip/sdram_msch.h| 12 + > > .../include/asm/arch-rockchip/sdram_pctl_px30.h| 100 +- > > .../include/asm/arch-rockchip/sdram_phy_rv1126.h | 93 + > > arch/arm/include/asm/arch-rockchip/sdram_rv1126.h | 420 +++ > >
[PATCH 6/6] configs: stm32mp13: Activate command stm32key
Activate the command stm32key with CONFIG_CMD_STM32KEY. Signed-off-by: Patrick Delaunay --- configs/stm32mp13_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig index f3d5e9812c6c..70b0d5dc99bf 100644 --- a/configs/stm32mp13_defconfig +++ b/configs/stm32mp13_defconfig @@ -7,6 +7,7 @@ CONFIG_DEFAULT_DEVICE_TREE="stm32mp135f-dk" CONFIG_SYS_PROMPT="STM32MP> " CONFIG_STM32MP13x=y CONFIG_DDR_CACHEABLE_SIZE=0x1000 +CONFIG_CMD_STM32KEY=y CONFIG_TARGET_ST_STM32MP13x=y CONFIG_ENV_OFFSET_REDUND=0x94 # CONFIG_ARMV7_NONSEC is not set -- 2.25.1
[PATCH 5/6] board: st: Add support of STM32MP13x boards in stm32board cmd
Add board identifiers for STMicroelectronics STM32MP13x boards: - DISCO board: MB1635 Signed-off-by: Patrick Delaunay --- board/st/common/Kconfig | 2 +- board/st/common/cmd_stboard.c | 7 --- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/board/st/common/Kconfig b/board/st/common/Kconfig index 2f57118bb265..aba3590866e0 100644 --- a/board/st/common/Kconfig +++ b/board/st/common/Kconfig @@ -1,7 +1,7 @@ config CMD_STBOARD bool "stboard - command for OTP board information" depends on ARCH_STM32MP - default y if TARGET_ST_STM32MP15x + default y if TARGET_ST_STM32MP15x || TARGET_ST_STM32MP13x help This compile the stboard command to read and write the board in the OTP. diff --git a/board/st/common/cmd_stboard.c b/board/st/common/cmd_stboard.c index 213fb5d30208..853ab78bbf16 100644 --- a/board/st/common/cmd_stboard.c +++ b/board/st/common/cmd_stboard.c @@ -2,8 +2,8 @@ /* * Copyright (C) 2019, STMicroelectronics - All Rights Reserved * - * the st command stboard supports the STMicroelectronics board identification - * saved in OTP 59. + * the command stboard supports the STMicroelectronics board identification + * saved in OTP_BOARD. * * The ST product codification have several element * - "Commercial Product Name" (CPN): type of product board (DKX, EVX) @@ -18,7 +18,7 @@ * - Finished Good = EVA32MP157A1$AU1 * * Both information are written on board and these information are also saved - * in OTP59, with: + * in OTP_BOARD (59 for STM32MP15x or 60 for STM32MP13x), with: * bit [31:16] (hex) => Board id, MB * bit [15:12] (dec) => Variant CPN (115) * bit [11:8] (dec) => Revision board (index with A = 1, Z = 26) @@ -49,6 +49,7 @@ static bool check_stboard(u16 board) 0x1298, 0x1341, 0x1497, + 0x1635, }; for (i = 0; i < ARRAY_SIZE(st_board_id); i++) -- 2.25.1
[PATCH 4/6] configs: stm32mp13: Activate CONFIG_CMD_FUSE
Activate the command fuse to access on STM32MP13x OTP with the BSEC driver. Signed-off-by: Patrick Delaunay --- configs/stm32mp13_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig index af6b1839d039..f3d5e9812c6c 100644 --- a/configs/stm32mp13_defconfig +++ b/configs/stm32mp13_defconfig @@ -26,6 +26,7 @@ CONFIG_CMD_MEMINFO=y CONFIG_CMD_MEMTEST=y CONFIG_CMD_UNZIP=y CONFIG_CMD_CLK=y +CONFIG_CMD_FUSE=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_LSBLK=y -- 2.25.1
[PATCH 2/6] stm32mp: Add OP-TEE support in bsec driver
When OP-TEE is used, the SMC for BSEC management are not available and
the STM32MP BSEC pseudo TA must be used (it is mandatory for STM32MP13
and it is a new feature for STM32MP15x).
The BSEC driver try to open a session to this PTA BSEC at probe
and use it for OTP read or write access to fuse or to shadow.
This patch also adapts the commands stm32key and stboard to handle
the BSEC_LOCK_PERM lock value instead of 1.
Signed-off-by: Patrick Delaunay
---
arch/arm/mach-stm32mp/bsec.c | 173 +-
arch/arm/mach-stm32mp/cmd_stm32key.c | 4 +-
arch/arm/mach-stm32mp/include/mach/bsec.h | 7 +
board/st/common/cmd_stboard.c | 5 +-
doc/board/st/stm32mp1.rst | 6 +-
5 files changed, 183 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-stm32mp/bsec.c b/arch/arm/mach-stm32mp/bsec.c
index 51ccff9aa560..fe79c986f95c 100644
--- a/arch/arm/mach-stm32mp/bsec.c
+++ b/arch/arm/mach-stm32mp/bsec.c
@@ -10,9 +10,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
#include
#include
#include
@@ -63,10 +65,43 @@
*/
#define BSEC_LOCK_PROGRAM 0x04
+#define PTA_BSEC_UUID { 0x94cf71ad, 0x80e6, 0x40b5, \
+ { 0xa7, 0xc6, 0x3d, 0xc5, 0x01, 0xeb, 0x28, 0x03 } }
+
+/*
+ * Read OTP memory
+ *
+ * [in]value[0].a OTP start offset in byte
+ * [in]value[0].b Access type (0:shadow, 1:fuse,
2:lock)
+ * [out] memref[1].bufferOutput buffer to store read values
+ * [out] memref[1].size Size of OTP to be read
+ *
+ * Return codes:
+ * TEE_SUCCESS - Invoke command success
+ * TEE_ERROR_BAD_PARAMETERS - Incorrect input param
+ * TEE_ERROR_ACCESS_DENIED - OTP not accessible by caller
+ */
+#define PTA_BSEC_READ_MEM 0x0
+
/*
- * OTP status: bit 0 permanent lock
+ * Write OTP memory
+ *
+ * [in]value[0].a OTP start offset in byte
+ * [in]value[0].b Access type (0:shadow, 1:fuse,
2:lock)
+ * [in]memref[1].bufferInput buffer to read values
+ * [in]memref[1].size Size of OTP to be written
+ *
+ * Return codes:
+ * TEE_SUCCESS - Invoke command success
+ * TEE_ERROR_BAD_PARAMETERS - Incorrect input param
+ * TEE_ERROR_ACCESS_DENIED - OTP not accessible by caller
*/
-#define BSEC_LOCK_PERM BIT(0)
+#define PTA_BSEC_WRITE_MEM 0x1
+
+/* value of PTA_BSEC access type = value[in] b */
+#define SHADOW_ACCESS 0
+#define FUSE_ACCESS1
+#define LOCK_ACCESS2
/**
* bsec_lock() - manage lock for each type SR/SP/SW
@@ -359,6 +394,10 @@ struct stm32mp_bsec_plat {
u32 base;
};
+struct stm32mp_bsec_priv {
+ struct udevice *tee;
+};
+
static int stm32mp_bsec_read_otp(struct udevice *dev, u32 *val, u32 otp)
{
struct stm32mp_bsec_plat *plat;
@@ -470,14 +509,109 @@ static int stm32mp_bsec_write_lock(struct udevice *dev,
u32 val, u32 otp)
return bsec_permanent_lock_otp(dev, plat->base, otp);
}
+static int bsec_pta_open_session(struct udevice *tee, u32 *tee_session)
+{
+ const struct tee_optee_ta_uuid uuid = PTA_BSEC_UUID;
+ struct tee_open_session_arg arg;
+ int rc;
+
+ memset(, 0, sizeof(arg));
+ tee_optee_ta_uuid_to_octets(arg.uuid, );
+ arg.clnt_login = TEE_LOGIN_REE_KERNEL;
+ rc = tee_open_session(tee, , 0, NULL);
+ if (rc < 0)
+ return -ENODEV;
+
+ *tee_session = arg.session;
+
+ return 0;
+}
+
+static int bsec_optee_open(struct udevice *dev)
+{
+ struct stm32mp_bsec_priv *priv = dev_get_priv(dev);
+ struct udevice *tee;
+ u32 tee_session;
+ int rc;
+
+ tee = tee_find_device(NULL, NULL, NULL, NULL);
+ if (!tee)
+ return -ENODEV;
+
+ /* try to open the STM32 BSEC TA */
+ rc = bsec_pta_open_session(tee, _session);
+ if (rc)
+ return rc;
+
+ tee_close_session(tee, tee_session);
+
+ priv->tee = tee;
+
+ return 0;
+}
+
+static int bsec_optee_pta(struct udevice *dev, int cmd, int type, int offset,
+ void *buff, ulong size)
+{
+ struct stm32mp_bsec_priv *priv = dev_get_priv(dev);
+ u32 tee_session;
+ struct tee_invoke_arg arg;
+ struct tee_param param[2];
+ struct tee_shm *fw_shm;
+ int rc;
+
+ rc = bsec_pta_open_session(priv->tee, _session);
+ if (rc)
+ return rc;
+
+ rc = tee_shm_register(priv->tee, buff, size, 0, _shm);
+ if (rc)
+ goto close_session;
+
+ memset(, 0, sizeof(arg));
+ arg.func = cmd;
+ arg.session = tee_session;
+
+ memset(param, 0, sizeof(param));
+
+ param[0].attr = TEE_PARAM_ATTR_TYPE_VALUE_INPUT;
+ param[0].u.value.a = offset;
+ param[0].u.value.b =
[PATCH 3/6] stm32mp: Add support of STM32MP13x in bsec driver
Add support for "st,stm32mp13-bsec" for STM32MP13x in the
bsec driver based on OP-TEE pseudo TA STM32MP BSEC.
Signed-off-by: Patrick Delaunay
---
arch/arm/mach-stm32mp/bsec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-stm32mp/bsec.c b/arch/arm/mach-stm32mp/bsec.c
index fe79c986f95c..f5f4b20d4776 100644
--- a/arch/arm/mach-stm32mp/bsec.c
+++ b/arch/arm/mach-stm32mp/bsec.c
@@ -761,6 +761,7 @@ static int stm32mp_bsec_probe(struct udevice *dev)
}
static const struct udevice_id stm32mp_bsec_ids[] = {
+ { .compatible = "st,stm32mp13-bsec" },
{ .compatible = "st,stm32mp15-bsec" },
{}
};
--
2.25.1
[PATCH 1/6] stm32mp: cosmetic: Update of bsec driver
Remove unnecessary return in stm32mp_bsec_write_lock and replace tab
by space for plat_auto opts.
Signed-off-by: Patrick Delaunay
---
arch/arm/mach-stm32mp/bsec.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-stm32mp/bsec.c b/arch/arm/mach-stm32mp/bsec.c
index c00130b08b36..51ccff9aa560 100644
--- a/arch/arm/mach-stm32mp/bsec.c
+++ b/arch/arm/mach-stm32mp/bsec.c
@@ -468,8 +468,6 @@ static int stm32mp_bsec_write_lock(struct udevice *dev, u32
val, u32 otp)
plat = dev_get_plat(dev);
return bsec_permanent_lock_otp(dev, plat->base, otp);
-
- return -EINVAL;
}
static int stm32mp_bsec_read(struct udevice *dev, int offset,
@@ -608,7 +606,7 @@ U_BOOT_DRIVER(stm32mp_bsec) = {
.id = UCLASS_MISC,
.of_match = stm32mp_bsec_ids,
.of_to_plat = stm32mp_bsec_of_to_plat,
- .plat_auto = sizeof(struct stm32mp_bsec_plat),
+ .plat_auto = sizeof(struct stm32mp_bsec_plat),
.ops = _bsec_ops,
.probe = stm32mp_bsec_probe,
};
--
2.25.1
