Hi Simon
Le sam. 4 déc. 2021 à 18:42, Simon Glass a écrit :
> Hi François,
>
> On Sat, 4 Dec 2021 at 04:06, François Ozog
> wrote:
> >
> > Hi Simon
> >
> > Le sam. 4 déc. 2021 à 02:02, Simon Glass a écrit :
> >>
> >> Hi Heinrich,
> >>
> >> On Fri, 3 Dec 2021 at 13:28, Heinrich Schuchardt
>
Hi Simon
Le sam. 4 déc. 2021 à 18:35, Simon Glass a écrit :
> Hi François,
>
> On Sat, 4 Dec 2021 at 09:55, François Ozog
> wrote:
> >
> > Hi Simon
> >
> > Le sam. 4 déc. 2021 à 16:21, Simon Glass a écrit :
> >>
> >> Hi Tom,
> >>
> >> On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote:
> >> >
> >>
The sja1105_check_device_id() function contains logic to work without
changing the device tree on reworked boards, one of which I have (the
NXP LS1021A-TSN normally has a SJA1105T, but I have a version with a
resoldered SJA1105Q which is pin compatible). This logic is taken from
the Linux driver.
If the DSA API is going to allow drivers to do things such as:
- phy_config in dsa_ops :: port_probe
- phy_startup in dsa_ops :: port_enable
then it would actually be good if the ->port_probe() method would
actually be called in all cases before the ->port_enable() is.
Currently this is true
This small patch set contains some bug fixes. The first is for the
recently introduced ->port_probe() DSA switch method, and the second is
for the recently introduced SJA1105 driver.
Vladimir Oltean (2):
net: dsa: fix phydev->speed being uninitialized for the CPU port fixed
PHY
net: dsa:
Hi Tom,
On Sat, 4 Dec 2021 at 11:03, Tom Rini wrote:
>
> On Sat, Dec 04, 2021 at 08:20:55AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote:
> > >
> > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
> > >
> > > [huge snip]
> > > > >
On 12/4/21 16:56, Simon Glass wrote:
At present this code is inline in the app and stub. But they do the same
thing. The difference is that the stub does it immediately and the app
doesn't want to do it until the end (when it boots a kernel) or not at
all, if returning to UEFI.
Move it into a
On 12/4/21 16:56, Simon Glass wrote:
Comment some functions that need more information.
Signed-off-by: Simon Glass
---
(no changes since v1)
lib/efi/efi_stub.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/lib/efi/efi_stub.c b/lib/efi/efi_stub.c
index
Hi Simon,
On Sat, Dec 04, 2021 at 10:25:29AM -0700, Simon Glass wrote:
> Hi Ilias,
>
> On Sat, 4 Dec 2021 at 08:58, Ilias Apalodimas
> wrote:
> >
> > Hi Simon,
> >
> > [...]
> > > > [huge snip]
> > > > > > There's things that need to be cleaned up because we have some small
> > > > > > number
On 12/4/21 16:56, Simon Glass wrote:
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,
On Sat, Dec 04, 2021 at 08:20:55AM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote:
> >
> > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
> >
> > [huge snip]
> > > > There's things that need to be cleaned up because we have some small
> > > >
On Fri, Dec 03, 2021 at 02:19:32PM +0800, Leo Liang wrote:
> Hi Tom,
>
> The following changes since commit 4a14bfffd42f968ed9d72a780a8d44a9053c5b95:
>
> Merge https://source.denx.de/u-boot/custodians/u-boot-marvell (2021-11-30
> 08:59:22 -0500)
>
> are available in the Git repository at:
>
Hi François,
On Sat, 4 Dec 2021 at 04:06, François Ozog wrote:
>
> Hi Simon
>
> Le sam. 4 déc. 2021 à 02:02, Simon Glass a écrit :
>>
>> Hi Heinrich,
>>
>> On Fri, 3 Dec 2021 at 13:28, Heinrich Schuchardt wrote:
>> >
>> > On 12/3/21 9:13 PM, Simon Glass wrote:
>> > > Hi Heinrich,
>> > >
>> > >
Hi François,
On Sat, 4 Dec 2021 at 09:55, François Ozog wrote:
>
> Hi Simon
>
> Le sam. 4 déc. 2021 à 16:21, Simon Glass a écrit :
>>
>> Hi Tom,
>>
>> On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote:
>> >
>> > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
>> >
>> > [huge snip]
>> >
Hi Mark,
On Sat, 4 Dec 2021 at 09:09, Mark Kettenis wrote:
>
> > From: Simon Glass
> > Date: Sat, 4 Dec 2021 08:20:55 -0700
> >
> > Hi Tom,
> >
> > On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote:
> > >
> > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
> > >
> > > [huge snip]
> >
Hi Ilias,
On Sat, 4 Dec 2021 at 08:58, Ilias Apalodimas
wrote:
>
> Hi Simon,
>
> [...]
> > > [huge snip]
> > > > > There's things that need to be cleaned up because we have some small
> > > > > number of platforms that went off and did their own thing. But
> > > > > largely
> > > > > yes,
Hi Simon
Le sam. 4 déc. 2021 à 16:21, Simon Glass a écrit :
> Hi Tom,
>
> On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote:
> >
> > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
> >
> > [huge snip]
> > > > There's things that need to be cleaned up because we have some small
> > > >
At present some 32-bit settings are used with the 64-bit app. Fix this by
separating out the two cases.
Be careful not to break the 64-bit payload, which needs to build a 64-bit
EFI stub with a 32-bit U-Boot.
Signed-off-by: Simon Glass
---
Changes in v5:
- Add new patch to set the correct link
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 ---
Make sure the linker lists are in the right place and drop the eh_frame
section, which is not needed.
Signed-off-by: Simon Glass
---
Changes in v5:
- Add new patch to round out the link script for 64-bit EFI
arch/x86/lib/elf_x86_64_efi.lds | 5 -
1 file changed, 4 insertions(+), 1
Since EFI does not relocate and uses the same global_data pointer
throughout the board-init process, drop this unnecessary setup, to avoid
a hang.
Signed-off-by: Simon Glass
---
Changes in v5:
- Add new patch to avoid setting up global_data again with EFI
common/board_r.c | 5 ++---
1 file
> From: Simon Glass
> Date: Sat, 4 Dec 2021 08:20:55 -0700
>
> Hi Tom,
>
> On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote:
> >
> > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
> >
> > [huge snip]
> > > > There's things that need to be cleaned up because we have some small
> > > >
Hi Simon,
[...]
> > [huge snip]
> > > > There's things that need to be cleaned up because we have some small
> > > > number of platforms that went off and did their own thing. But largely
> > > > yes, things make sense to me. We have:
> > > > - We embedded the device tree that will configure
That script is not intended for use with EFI, so update the logic to avoid
using it.
Signed-off-by: Simon Glass
---
Changes in v5:
- Add new patch to avoid using the 64-bit link script for the EFI app
arch/x86/cpu/config.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Now that the linker crash is resolved, build the 64-bit EFI app, including
all the required code.
Signed-off-by: Simon Glass
---
Changes in v5:
- Add new patch to build the 64-bit app properly
- Add various patches to fix up the 64-bit app so that it boots
Changes in v2:
- Add new patch to
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
Add an empty CPU init function to avoid fiddling with low-level CPU
features in the app. Set up the C runtime correctly for 64-bit use
and avoid clearing BSS, since this is done by EFI when U-Boot is loaded.
Signed-off-by: Simon Glass
---
Changes in v5:
- Add new patch to tweak the code used
Show the revision of this table as it 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
---
Changes in v5:
- Fix
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
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
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 this code is inline in the app and stub. But they do the same
thing. The difference is that the stub does it immediately and the app
doesn't want to do it until the end (when it boots a kernel) or not at
all, if returning to UEFI.
Move it into a function so it can be called as needed.
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
---
At present each of these has its own static variable and helper functions.
Move them into a shared file.
Signed-off-by: Simon Glass
---
(no changes since v1)
include/efi.h | 21 +
lib/efi/efi.c | 29 +
lib/efi/efi_app.c | 21
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
Comment some functions that need more information.
Signed-off-by: Simon Glass
---
(no changes since v1)
lib/efi/efi_stub.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/lib/efi/efi_stub.c b/lib/efi/efi_stub.c
index b3393e47fae..156cbf0b928 100644
---
This should return false when the EFI app is running, since UEFI has done
the required low-level init. Fix it.
Signed-off-by: Simon Glass
---
(no changes since v1)
include/init.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/init.h b/include/init.h
index
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
---
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
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.
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
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
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
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 +++
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
These names are better used for access to devices provided by an EFI
layer. Use EFI_LOADER instead here, since these are only available in
U-Boot's EFI_LOADER layer.
Signed-off-by: Simon Glass
---
Changes in v5:
- Add new patch to resolve EFI/EFI_LOADER conflict
doc/develop/uefi/uefi.rst
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
Hi Heinrich,
On Sat, 13 Nov 2021 at 02:29, Heinrich Schuchardt wrote:
>
>
>
> On 11/8/21 06:29, AKASHI Takahiro wrote:
> > On Sun, Nov 07, 2021 at 09:43:22AM -0700, Simon Glass wrote:
> >> Hi Heinrich,
> >>
> >> On Sun, 7 Nov 2021 at 01:21, Heinrich Schuchardt
> >> wrote:
> >>>
> >>>
> >>>
>
Hi Tom,
On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote:
>
> On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
>
> [huge snip]
> > > There's things that need to be cleaned up because we have some small
> > > number of platforms that went off and did their own thing. But largely
> > >
Hi Francesco,
On Fri, Dec 3, 2021 at 5:47 AM Francesco Dolcini
wrote:
> I think that this applies even with just one chip select, it is just
> prescribing a procedure and explicitly saying that it must be done for
> all the chip select in use, either 1 or 2.
According to the NXP application
On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
[huge snip]
> > There's things that need to be cleaned up because we have some small
> > number of platforms that went off and did their own thing. But largely
> > yes, things make sense to me. We have:
> > - We embedded the device
Hi Simon and Sandrine
Le jeu. 2 déc. 2021 à 08:10, Sandrine Bailleux
a écrit :
> Hi Simon,
>
> On 12/1/21 5:51 PM, Simon Glass wrote:
> > Hi Sandrine,
> >
> > On Wed, 1 Dec 2021 at 03:32, Sandrine Bailleux
> > wrote:
> >>
> >> Hi everyone,
> >>
> >> I am Sandrine Bailleux, from the Trusted
Hi Simon
Le sam. 4 déc. 2021 à 02:02, Simon Glass a écrit :
> Hi Heinrich,
>
> On Fri, 3 Dec 2021 at 13:28, Heinrich Schuchardt
> wrote:
> >
> > On 12/3/21 9:13 PM, Simon Glass wrote:
> > > Hi Heinrich,
> > >
> > > On Fri, 3 Dec 2021 at 06:09, Heinrich Schuchardt
> wrote:
> > >>
> > >> On
54 matches
Mail list logo
