Hi Simon,
On Thu, 4 Nov 2021 at 11:49, Simon Glass wrote:
>
> Hi Masahisa,
>
> On Wed, 3 Nov 2021 at 19:16, Masahisa Kojima
> wrote:
> >
> > Hi Simon,
> >
> > On Tue, 2 Nov 2021 at 23:56, Simon Glass wrote:
> > >
> > > Hi Masahisa,
> > >
> > > On Tue, 26 Oct 2021 at 02:26, Masahisa Kojima
>
Instead of hardcoding the watchdog for reset, and the PMIC for poweroff,
use the sysreset framework to manage the available poweroff/reset
backends. This allows (as examples) using the PMIC to do a cold reset,
and using a GPIO to power off H3/H5 boards lacking a PMIC. Furthermore,
it removes the
The sysreset uclass unconditionally provides a definition of the
reset_cpu() function. So does the sunxi board code. Fix the build with
SYSRESET enabled by omitting the function from the board code in that
case. The code still needs to be kept around for use in SPL.
Reviewed-by: Heinrich
Add an option to automatically register watchdog devices with the
wdt_reboot driver for use with sysreset. This allows sysreset to be a
drop-in replacement for platform-specific watchdog reset code, without
needing any device tree changes.
Signed-off-by: Samuel Holland
---
Changes in v3:
-
Currently, the wdt_reboot driver always gets its watchdog device
reference from an OF node. This prevents selecting a watchdog at
runtime. Move the watchdog device reference to the plat data, so
the driver can be bound with the reference pre-provided. The
reference will still be acquired from the
These driver probe functions are not (and should not be) called from
outside the respective driver source files. Therefore, the functions
should be marked static.
Reviewed-by: Heinrich Schuchardt
Signed-off-by: Samuel Holland
---
(no changes since v2)
Changes in v2:
- Also make
None of the sysreset drivers do anything beyond providing sysreset
uclass ops. They should depend on the sysreset uclass.
Reviewed-by: Heinrich Schuchardt
Signed-off-by: Samuel Holland
---
(no changes since v2)
Changes in v2:
- Extend the "if SYSRESET" block to the end of the file.
This series hooks up the watchdog uclass to automatically register
watchdog devices for use with sysreset, doing a bit of minor cleanup
along the way.
The goal is for this to replace the sunxi board-level non-DM reset_cpu()
function. I was surprised to find that the wdt_reboot driver requires
its
On 10/31/21 6:46 PM, Simon Glass wrote:
> Hi Samuel,
>
> On Sun, 22 Aug 2021 at 14:41, Samuel Holland wrote:
>>
>> Add an option to automatically register the first watchdog device with
>> the wdt_reboot driver for use with sysreset. This allows sysreset to be
>> a drop-in replacement for
If the 'bootm' command is not enabled then this code is not available and
this causes a link error. Fix it.
Note that for the EFI app, there is no indication of missing code. It just
hangs!
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/x86/lib/zimage.c | 13 -
1 file
This provides access to EFI tables after U-Boot has exited boot services.
It is not needed in the app since boot services remain alive and we can
just call them whenever needed.
Add a comment to explain this.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Fix 'as' typo
This structure is uncommented. Fix it.
Signed-off-by: Simon Glass
---
(no changes since v3)
Changes in v3:
- Drop comments that confuse sphinx
- Move device_path path change to its own patch
include/efi.h | 23 +++
1 file changed, 23 insertions(+)
diff --git
At present this is disabled, but it should work so long as the kernel does
not need EFI services. Enable it and add a note about remaining work.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Update documentation
arch/x86/lib/bootm.c | 11 +++
Add a function to return this information along with a stub for the
efi_info_get() function, since calling it otherwise hangs U-Boot.
Signed-off-by: Simon Glass
---
(no changes since v1)
include/efi.h | 8 +++-
lib/efi/efi_app.c | 10 ++
2 files changed, 17 insertions(+), 1
Dear Heinrich,
Thank for your comments.
>How about CONFIG_EFI_SECURE_BOOT? Should this also disable the default?
I think yes.
I will update the relation to "default y if !FIT_SIGNATURE && !EFI_SECURE_BOOT",
and add "!EFI_SECURE_BOOT" into LEGACY_IMAGE_FORMAT.
>> + It is enabled
Show the revision of this table this is can be important.
Alo update the 'efi table' entry to show the actual address of the EFI
table rather than our table that points to it. This saves a step and the
intermediate table has nothing else in it.
Signed-off-by: Simon Glass
---
(no changes since
Add a message here so that both paths of memory allocation are reported.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Use log_info() instead of printf()
lib/efi/efi_app.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/efi/efi_app.c
Add info about how to select vidconsole or serial.
Also set up a demo boot command.
Signed-off-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Add a better boot command too
include/configs/efi-x86_app.h | 25 +
1 file changed, 25 insertions(+)
diff --git
At present the 'efi' command only works in the EFI payload. Update it to
work in the app too, so the memory map can be examined.
Signed-off-by: Simon Glass
---
(no changes since v1)
cmd/Makefile | 2 +-
cmd/efi.c | 48 ---
At present this function requires a pointer to struct efi_entry_memmap
but the only field used in there is the desc_size. We want to be able
to use it from the app, so update it to use desc_size directly.
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/x86/cpu/efi/payload.c | 8
The stub checks for failure with efi_init(). Add this for the app as well.
It is unlikely that anything can be done, but we may as well stop.
Signed-off-by: Simon Glass
---
(no changes since v1)
lib/efi/efi_app.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git
At present only 4KB of spare space is left in the DTB when building the
EFI app. Increase this to 32KB so there is plenty of space to insert the
binman definition. This cannot be expanded later (as with OF_SEPARATE)
because the ELF image has already been built.
Signed-off-by: Simon Glass
---
WIth EFI we must embed the devicetree in an ELF image so that it is loaded
as part of the executable file. We want it to include the binman
definition in there also, which in some cases cannot be created until the
ELF (u-boot) is built. Add an option to binman to support writing the
updated dtb to
This is not used anywhere drop it.
Signed-off-by: Simon Glass
---
(no changes since v3)
Changes in v3:
- Move device_path path change to its own patch
include/efi.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/efi.h b/include/efi.h
index 908c5dc6ebd..77e599c256e 100644
---
The comment for this function is missing an argument and the return value.
Fix it.
Signed-off-by: Simon Glass
---
(no changes since v1)
tools/binman/ftest.py | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 8199a4fc7e0..39a4b94cd0b
Typically the bloblist is positioned at a fixed address in memory until
relocation. This is convenient when it is set up in SPL or before
relocation.
But for EFI we want to set it up only when U-Boot proper is running. Add
a way to allocate it using malloc() and update the documentation to cover
At present only the backspace key is supported in U-Boot, when running as
an EFI app. Add support for arrows, home and end as well, to make the CLI
more friendly.
Signed-off-by: Simon Glass
---
(no changes since v1)
drivers/serial/serial_efi.c | 11 +--
1 file changed, 9
Binman needs to be able to update the contents of an ELF file after it has
been build. To support this, add a function to locate the position of a
symbol's contents within the file.
Fix the comments on bss_data.c and Symbol while we are here.
Signed-off-by: Simon Glass
---
(no changes since
When starting the app, locate all block devices and make them available
to U-Boot. This allows listing partitions and accessing files in
filesystems.
EFI also has the concept of 'disks', meaning boot media. For now, this
is not obviously useful in U-Boot, but add code to at least locate these.
At present UCLASS_EFI is used to represent an EFI filesystem among other
things. The description of this uclass is "EFI managed devices" which is
pretty vague. The only driver that uses this uclass is in fact not a real
U-Boot driver, since its operations do not include a struct udevice.
Rather
At present any error from the 'make' command is silently swallowed by the
test system. Fix this by showing it when detected.
Signed-off-by: Simon Glass
---
(no changes since v1)
tools/binman/elf_test.py | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git
Add a block driver which handles read/write for EFI block devices. This
driver actually already exists ('efi_block') but is not really suitable
for use as a real U-Boot driver:
- The operations do not provide a udevice
- The code is designed for running as part of EFI loader, so uses
The current EFI video driver only works when running in the stub. In that
case the stub calls boot services (before jumping to U-Boot proper) and
copies the graphics info over to the efi table. This is necessary because
the stub exits boot services before jumping to U-Boot.
The app maintains
The Exception base class is a very vague and could be confusing to the
test system. Use the more specific ValueError exception instead.
Signed-off-by: Simon Glass
---
(no changes since v1)
tools/patman/tools.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
This variable is already defined by the EFI code. Drop the duplicate
definition when building a 64-bit EFI app.
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/x86/cpu/x86_64/cpu.c | 15 +--
arch/x86/cpu/x86_64/misc.c | 16
lib/efi/efi.c |
Most modern platforms use 64-bit EFI so it is useful to have a U-Boot app
that runs under that. Add a (non-functional) build for this.
Note that --whole-archive causes the gcc 9.2 linker to crash, so disable
this for now. Once this is resolved, things should work.
For now, avoid mentioning the
Most EFI implementations use 64-bit but U-Boot only supports running as
a 32-bit app at present. While efi-x86_payload64 does boot from 64-bit
UEFI it immediately changes back to 32-bit before starting U-Boot.
In order to support a 64-bit U-Boot app, update the Kconfig to add an
option for 32/64
For the EFI app, we must embed the devicetree in the ELF file since that
is the only thing that is run by UEFI. Drop the warning to avoid
confusion.
Signed-off-by: Simon Glass
Reviewed-by: Heinrich Schuchardt
---
(no changes since v2)
Changes in v2:
- Add new patch to drop the OF_EMBED
It is quite complicated to run U-Boot on QEMU since we have four
different builds and they must use different versions of qemu and the
UEFI binaries.
Add a script to help. It requires U-Boot itself to be built. Once that
is done you can use this script to build an image for use with qemu and
There is no need to avoid driver model for networking. Drop this.
Signed-off-by: Simon Glass
Reviewed-by: Heinrich Schuchardt
---
(no changes since v2)
Changes in v2:
- Add new patch to enable DM_ETH for the app
configs/efi-x86_app_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git
At present U-Boot can be built as an EFI app, but it is really just for
testing, with very few features. Instead, the payload build is used for
booting on top of UEFI, where U-Boot takes over the machine immediately
and supplies its own drivers.
But the app could be made more useful.
This series
On Tue, Nov 02, 2021 at 08:56:50AM -0600, Simon Glass wrote:
> Hi Takahiro,
>
> On Thu, 28 Oct 2021 at 22:56, AKASHI Takahiro
> wrote:
> >
> > On Thu, Oct 28, 2021 at 09:17:45PM -0600, Simon Glass wrote:
> > > Hi Takahiro,
> > >
> > > On Thu, 28 Oct 2021 at 00:25, AKASHI Takahiro
> > > wrote:
>
Hi Mark,
On Tue, 2 Nov 2021 at 09:13, Mark Kettenis wrote:
>
> > From: Simon Glass
> > Date: Tue, 2 Nov 2021 08:56:50 -0600
> >
> > Hi Takahiro,
> >
> > > > - can we just build the tool always?
> > >
> > > This is one of my questions.
> > > Why do you want to do so while there are bunch of
Hi Masahisa,
On Wed, 3 Nov 2021 at 19:16, Masahisa Kojima wrote:
>
> Hi Simon,
>
> On Tue, 2 Nov 2021 at 23:56, Simon Glass wrote:
> >
> > Hi Masahisa,
> >
> > On Tue, 26 Oct 2021 at 02:26, Masahisa Kojima
> > wrote:
> > >
> > > TCG PC Client Platform Firmware Profile Specification
> > >
Hi Takahiro,
On Wed, 3 Nov 2021 at 20:04, AKASHI Takahiro wrote:
>
> On Tue, Nov 02, 2021 at 08:58:15AM -0600, Simon Glass wrote:
> > Hi Takahiro,
> >
> > On Thu, 28 Oct 2021 at 23:25, AKASHI Takahiro
> > wrote:
> > >
> > > On Thu, Oct 28, 2021 at 09:17:49PM -0600, Simon Glass wrote:
> > > > Hi
On Wed, 3 Nov 2021 at 20:12, AKASHI Takahiro wrote:
>
> On Tue, Nov 02, 2021 at 08:58:18AM -0600, Simon Glass wrote:
> > Hi Takahiro,
> >
> > On Mon, 1 Nov 2021 at 18:56, AKASHI Takahiro
> > wrote:
> > >
> > > The existing options, "--fit" and "--raw," are only used to put a proper
> > > GUID
Hi Tom,
On Mon, 1 Nov 2021 at 15:58, Tom Rini wrote:
>
> On Sun, Oct 31, 2021 at 05:46:43PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 27 Oct 2021 at 07:13, Tom Rini wrote:
> > >
> > > On Wed, Oct 27, 2021 at 02:21:17PM +0200, Heinrich Schuchardt wrote:
> > > >
> > > >
> > > > On
> From: Leo Yu-Chi Liang(梁育齊)
> Sent: Thursday, November 04, 2021 9:53 AM
> To: u-boot@lists.denx.de
> Cc: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊)
>
> Subject: [PATCH 1/1] board: ae350: Support autoboot from RAM
>
> Add boot command "bootcmd_ram" to support autoboot from RAM.
>
> This
> Hi Rick,
>
> On Mon, Oct 25, 2021 at 10:24 AM Rick Chen wrote:
> >
> > Hi, Bin
> >
> > > Hi Rick,
> > >
> > > On Mon, Oct 25, 2021 at 9:49 AM Rick Chen wrote:
> > > >
> > > > Hi Bin,
> > > >
> > > > > From: Bin Meng
> > > > > Sent: Tuesday, October 19, 2021 4:55 PM
> > > > > To: Alexandre
On Tue, Nov 02, 2021 at 08:58:30AM -0600, Simon Glass wrote:
> Hi Takahiro,
>
> On Mon, 1 Nov 2021 at 18:56, AKASHI Takahiro
> wrote:
> >
> > By specifying CONFIG_EFI_CAPSULE_KEY_PATH, the build process will
> > automatically insert the given key into the device tree.
> > Otherwise, users are
On Tue, Nov 02, 2021 at 08:58:18AM -0600, Simon Glass wrote:
> Hi Takahiro,
>
> On Mon, 1 Nov 2021 at 18:56, AKASHI Takahiro
> wrote:
> >
> > The existing options, "--fit" and "--raw," are only used to put a proper
> > GUID in a capsule header, where GUID identifies a particular FMP (Firmware
>
Hi Heinrich,
On Wed, 27 Oct 2021 at 23:40, Heinrich Schuchardt wrote:
>
> On 10/26/21 5:30 AM, Simon Glass wrote:
> > There is no need to avoid driver model for networking. Drop this.
> >
> > Signed-off-by: Simon Glass
>
> This seems to be an unrelated problem in building efi-x86_app_defconfig:
On 02/11/2021 12:27, Michal Simek wrote:
On 11/2/21 10:00, Michael Walle wrote:
On Fri, Oct 29, 2021 at 2:14 PM Michal Simek wrote:
When MAC address is randomly generated it should be also saved to
variables. This step is there when MAC address is passed via pdata but not
when it is
On Tue, Nov 02, 2021 at 08:58:15AM -0600, Simon Glass wrote:
> Hi Takahiro,
>
> On Thu, 28 Oct 2021 at 23:25, AKASHI Takahiro
> wrote:
> >
> > On Thu, Oct 28, 2021 at 09:17:49PM -0600, Simon Glass wrote:
> > > Hi Takahiro,
> > >
> > > On Thu, 28 Oct 2021 at 00:25, AKASHI Takahiro
> > > wrote:
>
Hi Rob,
On Wed, 27 Oct 2021 at 08:09, Simon Glass wrote:
>
> Hi Rob,
>
> On Tue, 26 Oct 2021 at 20:37, Rob Herring wrote:
> >
> > On Sun, Oct 24, 2021 at 9:39 AM Simon Glass wrote:
> > >
> > > Hi Mark,
> > >
> > > On Thu, 21 Oct 2021 at 02:51, Mark Kettenis
> > > wrote:
> > > >
> > > > >
Add boot command "bootcmd_ram" to support autoboot from RAM.
This feature could be useful at the very initial state of chip design
when there is only a minimal set of peripheral. (e.g. without mmc and mac ..etc)
The kernel image is default to be loaded at 0x200 via debug port,
and the
On Tue, Nov 02, 2021 at 08:57:48AM -0600, Simon Glass wrote:
> Hi Takahiro,
>
> On Thu, 28 Oct 2021 at 23:20, AKASHI Takahiro
> wrote:
> >
> > On Thu, Oct 28, 2021 at 09:17:48PM -0600, Simon Glass wrote:
> > > Hi Takahiro,
> > >
> > > On Thu, 28 Oct 2021 at 00:25, AKASHI Takahiro
> > > wrote:
>
Hi Simon,
On Tue, 2 Nov 2021 at 23:56, Simon Glass wrote:
>
> Hi Masahisa,
>
> On Thu, 21 Oct 2021 at 07:41, Masahisa Kojima
> wrote:
> >
> > is
> >
> > On Thu, 21 Oct 2021 at 22:04, Heinrich Schuchardt
> > wrote:
> > >
> > >
> > >
> > > On 10/21/21 14:52, Masahisa Kojima wrote:
> > > > On
Hi Simon,
On Tue, 2 Nov 2021 at 23:56, Simon Glass wrote:
>
> Hi Masahisa,
>
> On Tue, 26 Oct 2021 at 02:26, Masahisa Kojima
> wrote:
> >
> > TCG PC Client Platform Firmware Profile Specification
> > requires to measure the SMBIOS table that contains static
> > configuration information (e.g.
%d was being used as the specifier for size_t, leading to a
compiler warning
Signed-off-by: Mathew McBride
---
drivers/tpm/tpm_atmel_twi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tpm/tpm_atmel_twi.c b/drivers/tpm/tpm_atmel_twi.c
index 9ca33e4334..e84f9183d1
Without get_desc, the tpm command will not provide a
description of the device in 'tpm device' or 'tpm info'.
Due to the characteristics of the Atmel TPM it isn't
possible to determine certain attributes (e.g open/close
status) without using the TPM stack (compare Infineon
and ST TPM drivers), so
This command is not compiled by default and has not been updated alongside
changes to the tpmv1 API, such as passing the TPM udevice to the relevant
functions.
Signed-off-by: Mathew McBride
---
cmd/tpm-v1.c | 10 +-
lib/tpm-v1.c | 4 ++--
2 files changed, 7 insertions(+), 7
This driver was broken due to an empty offset byte being prepended
at the start of every transmission.
The hardware does not mimic an EEPROM device with registers so
an offset byte is not required.
Signed-off-by: Mathew McBride
---
drivers/tpm/tpm_atmel_twi.c | 1 +
1 file changed, 1
There are no users of this driver without DM_I2C
Signed-off-by: Mathew McBride
---
drivers/tpm/tpm_atmel_twi.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/tpm/tpm_atmel_twi.c b/drivers/tpm/tpm_atmel_twi.c
index 2dcc2af67f..4ff4cf4cd4 100644
---
This command is not compiled by default and was not
updated to pass the udevice to tpm_get_capability.
Signed-off-by: Mathew McBride
---
cmd/tpm-v1.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/cmd/tpm-v1.c b/cmd/tpm-v1.c
index 3a7e35d525..55f2aeff46 100644
---
While doing bringup/rebase for the Ten64 I did some troubleshooting
for the tpm (v1.2, NOT tpm2) command which did not appear to function,
despite the Linux driver and tools (tcsd) working on the same board.
Evidently the Atmel TPM driver hasn't kept up with various step
changes in the I2C and
The sunxi MUSB glue driver has some code to check for external VBUS
presence when it's going to use the MUSB host mode, and it warns if
there is VBUS provided through the cable (in sunxi_musb_enable()).
This code was apparently copied to the USB gadget detection code
From: Marek Behún
Since the default_environment[] buffer is not overwritten anymore by any
board, remove support for read-write default_environment[].
Signed-off-by: Marek Behún
---
include/env_default.h | 2 --
include/env_internal.h | 4
2 files changed, 6 deletions(-)
diff --git
From: Marek Behún
ESPRESSObin's board code uses an ad-hoc solution for ensuring that
ethaddrs are not overwritten by `env default -a` command and that the
`fdtfile` is set to correct value when `env default -a` is called.
This ad-hoc solution is overwriting the default_environment[] buffer in
From: Marek Behún
The default_environment[] buffer is built at compile time, but sometimes
it makes sense for some default environment variables to be determined
at runtime, for example:
- one board code may support different boards, and needs that
fdtfile, board, board_name
are set
From: Marek Behún
Add get_str_list() method to sysinfo operations.
The get_str_list() method is similar to get_str(), but receives one
additional argument, @idx, and fills in the @idx-th string from a given
list.
Add sandbox implementation together with a unittest.
Signed-off-by: Marek Behún
From: Marek Behún
The env_set_default_vars() function does not document return value and
behaves differently from other env_* functions.
Change the return value to return 0 on success and -ve on error.
Signed-off-by: Marek Behún
---
env/common.c | 9 ++---
include/env.h | 1 +
2 files
From: Marek Behún
Make it so that if the .detect() method is not implemented, the sysinfo
is considered to be present.
Signed-off-by: Marek Behún
---
drivers/sysinfo/sysinfo-uclass.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/sysinfo/sysinfo-uclass.c
From: Marek Behún
Add function
sysinfo_get_str_list_max_len()
to determine length of the longest string in a string list, functions
sysinfo_str_list_first() and
sysinfo_str_list_next()
to support iteration over string list elements and macro
for_each_sysinfo_str_list()
to make the
From: Marek Behún
Use the ut_asserteq_str() assertion instead of strcmp() function and
ut_assertok()ing it's result.
Signed-off-by: Marek Behún
---
test/dm/cpu.c | 4 ++--
test/dm/soc.c | 4 ++--
test/dm/sysinfo.c | 6 +++---
test/dm/usb.c | 2 +-
test/dm/virtio.c | 2 +-
From: Marek Behún
Currently sysinfo_get_str() returns 0 if a string is filled in the
given buffer, and otherwise gives no simple mechanism to determine
actual string length.
One implementation returns -ENOSPC if buffer is not large enough.
Change the behaviour of the function to that of
From: Marek Behún
Instead of pretending that we don't have environment to force searching
default environment in env_get_default(), get the data from the
default_environment[] buffer directly.
Signed-off-by: Marek Behún
Reviewed-by: Simon Glass
---
env/common.c | 45
From: Marek Behún
The env_get_f() function returns -1 on failure. Returning 0 means that
the variable exists, and is empty string.
Signed-off-by: Marek Behún
Reviewed-by: Simon Glass
---
env/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/env/common.c
From: Marek Behún
Do not set GD_FLG_ENV_READY nor GD_FLG_ENV_DEFAULT if failed importing
in env_set_default().
Signed-off-by: Marek Behún
Reviewed-by: Simon Glass
---
env/common.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/env/common.c b/env/common.c
index
From: Marek Behún
Hello Simon, Pali,
this is v2 of the series that adds support for board specific runtime
determined default environment variables.
(Went through CI on github.)
As requested, I converted it to use sysinfo (and added support for some
new things into sysinfo).
I haven't tested
Hello! See inline comments below.
On Tuesday 02 November 2021 11:18:10 Roman Bacik wrote:
> From: Bharat Gooty
>
> Broadcom bnxt L2 driver support. Used by the Broadcom
> iproc platforms.
>
> Signed-off-by: Bharat Gooty
> Reviewed-by: Ramon Fried
>
> Signed-off-by: Roman Bacik
> ---
>
>
Hi,
On Sat, 23 Oct 2021 at 03:23, Dario Binacchi wrote:
>
> Hi Guillaume,
>
> > Il 22/10/2021 14:34 Guillaume GARDET ha scritto:
> >
> >
> > Hi Dario,
> >
> > - Dario Binacchi a écrit :
> > > Hi Guillaume,
> > >
> > > > Il 21/10/2021 16:47 Guillaume GARDET ha
> > > > scritto:
> > > >
> >
Hi,
On Fri, 22 Oct 2021 at 05:38, Dario Binacchi wrote:
>
> Hi Guillaume,
>
> > Il 21/10/2021 16:47 Guillaume GARDET ha scritto:
> >
> >
> > Hi,
> >
> > Commit 76c2ff3e [0] broke backlight on Chromebook snow.
> > A revert on top of 2021.10 restores the backlight.
> > Not sure why it breaks on
Hi Ariel
On Tue, 2021-11-02 at 20:18 -0300, Ariel D'Alessandro wrote:
> Add support for iMX8MN VAR-SOM-MX8M-NANO board. Enables support for:
>
> - 1GiB DDR4 RAM
> - 16 GiB eMMC
> - SD card
> - Gigabit ethernet
> - USBOTG1 peripheral - fastboot
>
> Signed-off-by: Ariel D'Alessandro
> ---
>
Mario,
> -Original Message-
> From: U-Boot On Behalf Of Mario
> Lombardo
> Sent: Wednesday, November 3, 2021 5:40 AM
> To: u-boot@lists.denx.de
> Subject: [External] - Slow MMC IO with Raspberry CM3+ Module
>
> Dear u-boot list,
>
> I recently compiled (latest: 2021.10) code of uboot
Hi,
On 30.10.2021 21.25, Simon Glass wrote:
From: Tuomas Tynkkynen
^ Some mishap with the From: line here, since I did not write the patch?
This is similar to the existing qemu_arm target, except that the 'bios' is
image.bin (containing both SPL and U-Boot) rather than in u-boot.bin
Dear u-boot list,
I recently compiled (latest: 2021.10) code of uboot as a boot loader for the
Compute Module 3+ (Raspberry). Everything works fine except one issue: the IO
from the storage is extreme slow. I read about issues in the past related to
ext file systems. However the present issue
To prevent boot unsigned images, same as CONFIG_LEGACY_IMAGE_FORMAT,
don't enable CONFIG_CMD_BOOTI and CONFIG_CMD_BOOTI by default if
CONFIG_FIT_SIGNATURE is enabled.
Signed-off-by: Yuezhang.Mo
---
cmd/Kconfig | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git
From: Bharat Gooty
Broadcom bnxt L2 driver support. Used by the Broadcom
iproc platforms.
Signed-off-by: Bharat Gooty
Reviewed-by: Ramon Fried
Signed-off-by: Roman Bacik
---
Changes in v6:
- remove bnxt_eth_* env variables
- clean up include headers
Changes in v5:
- remove
Introduce BSH SystemMaster (SMM) S2 board family, which consists of:
iMX8MN SMM S2 and iMX8MN SMM S2 PRO boards.
Add support for iMX8MN BSH SMM S2 board:
- 256 MiB DDR3 RAM
- 512MiB Nand
- USBOTG1 peripheral - fastboot.
Add support for iMX8MN BSH SMM S2 PRO board:
- 512 MiB DDR3 RAM
- 8 GiB
From: Michael Trimarchi
Add regs used by GPMI
Signed-off-by: Michael Trimarchi
Signed-off-by: Ariel D'Alessandro
---
arch/arm/include/asm/arch-imx8m/imx-regs.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h
At present the counter never hits the comparitor in this case. Add a
special case.
This ensures that the snow backlight works when at full brightness.
Fixes: 76c2ff3e5fd video: backlight: fix pwm's duty cycle calculation
Signed-off-by: Simon Glass
---
drivers/pwm/exynos_pwm.c | 4
1
On 11/3/21 08:44, Rover Mo wrote:
To prevent boot unsigned images, same as CONFIG_LEGACY_IMAGE_FORMAT,
nits:
%s/boot/booting/
don't enable CONFIG_CMD_BOOTI and CONFIG_CMD_BOOTI by default if
CONFIG_FIT_SIGNATURE is enabled.
Disabling the booti and the bootz command does not stop you from
> From: Simon Glass
> Date: Wed, 3 Nov 2021 10:45:42 -0600
>
> Hi Tom,
>
> On Wed, 3 Nov 2021 at 10:02, Tom Rini wrote:
> >
> > On Wed, Nov 03, 2021 at 09:22:58AM +0100, Mark Kettenis wrote:
> > > > From: Simon Glass
> > > > Date: Tue, 2 Nov 2021 19:20:51 -0600
> > > >
> > > > Hi Mark,
> > >
On Wed, Nov 03, 2021 at 10:45:11AM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Wed, 27 Oct 2021 at 13:25, Tom Rini wrote:
> >
> > On Wed, Oct 27, 2021 at 12:23:21PM -0600, Simon Glass wrote:
> > > Hi François,
> > >
> > > On Wed, 27 Oct 2021 at 09:14, François Ozog
> > > wrote:
> > > >
> > > >
Hi Simon
I don't know if this is correct etiquette but at this moment it feels just
right to do this:
The problem is not confusion it is that the patch set goes in a direction
that makes no sense.
On Tue, 26 Oct 2021 at 02:24, Simon Glass wrote:
> With Ilias' efforts we have dropped
On Tue, Nov 02, 2021 at 11:27:22AM +0100, Michal Simek wrote:
>
>
> On 11/2/21 10:00, Michael Walle wrote:
> > > On Fri, Oct 29, 2021 at 2:14 PM Michal Simek
> > > wrote:
> > > >
> > > > When MAC address is randomly generated it should be also saved to
> > > > variables. This step is there
On 9/16/21 3:02 AM, qianfangui...@163.com wrote:
From: qianfan Zhao
If the downloading file size is equal to the partition size, "fastboot
flash" can't work, at least in sunxi platform, because used an
uninitalized point: ep->desc.
Hm, I think that usb_ep_ops->enable needs to set ep->desc =
Hi Tom,
On Wed, 3 Nov 2021 at 10:02, Tom Rini wrote:
>
> On Wed, Nov 03, 2021 at 09:22:58AM +0100, Mark Kettenis wrote:
> > > From: Simon Glass
> > > Date: Tue, 2 Nov 2021 19:20:51 -0600
> > >
> > > Hi Mark,
> > >
> > > On Wed, 27 Oct 2021 at 16:30, Mark Kettenis
> > > wrote:
> > > >
> > > >
Hi Tom,
On Wed, 3 Nov 2021 at 09:56, Tom Rini wrote:
>
> On Tue, Nov 02, 2021 at 07:20:51PM -0600, Simon Glass wrote:
> > Hi Mark,
> >
> > On Wed, 27 Oct 2021 at 16:30, Mark Kettenis wrote:
> > >
> > > > From: Simon Glass
> > > > Date: Wed, 27 Oct 2021 12:23:21 -0600
> > > >
> > > > Hi
1 - 100 of 160 matches
Mail list logo
