On 07.09.23 15:00, Michal Simek wrote:
Use proper project name in README, rst and comment.
Done in connection to commit bb922ca3eb4b ("global: Use proper project name
U-Boot (next)").
Signed-off-by: Michal Simek
For ppce500:
Reviewed-by: Alexander Graf
Alex
On 30.08.23 21:12, Alper Nebi Yasak wrote:
On 2023-08-22 02:03 +03:00, Simon Glass wrote:
Hi Alex,
On Mon, 21 Aug 2023 at 16:44, Alexander Graf wrote:
On 22.08.23 00:10, Simon Glass wrote:
Hi Alex,
On Mon, 21 Aug 2023 at 13:59, Alexander Graf wrote:
On 21.08.23 21:11, Simon Glass
On 29.08.23 11:19, Mark Kettenis wrote:
Date: Tue, 29 Aug 2023 08:20:49 +0200
From: Alexander Graf
On 28.08.23 23:54, Heinrich Schuchardt wrote:
On 8/28/23 22:24, Alexander Graf wrote:
On 28.08.23 19:54, Simon Glass wrote:
Hi Alex,
On Wed, 23 Aug 2023 at 02:56, Alexander Graf wrote
On 30.08.23 20:27, Alper Nebi Yasak wrote:
Hi all,
On 2023-08-29 09:27 +03:00, Alexander Graf wrote:
On 29.08.23 00:08, Simon Glass wrote:
On Mon, 28 Aug 2023 at 14:24, Alexander Graf wrote:
On 28.08.23 19:54, Simon Glass wrote:
U-Boot does have video_sync() but it doesn't know when
Hi Simon,
On 29.08.23 00:08, Simon Glass wrote:
Hi Alex,
On Mon, 28 Aug 2023 at 14:24, Alexander Graf wrote:
On 28.08.23 19:54, Simon Glass wrote:
Hi Alex,
On Wed, 23 Aug 2023 at 02:56, Alexander Graf wrote:
Hey Simon,
On 22.08.23 20:56, Simon Glass wrote:
Hi Alex,
On Tue, 22 Aug
On 28.08.23 23:54, Heinrich Schuchardt wrote:
On 8/28/23 22:24, Alexander Graf wrote:
On 28.08.23 19:54, Simon Glass wrote:
Hi Alex,
On Wed, 23 Aug 2023 at 02:56, Alexander Graf wrote:
Hey Simon,
On 22.08.23 20:56, Simon Glass wrote:
Hi Alex,
On Tue, 22 Aug 2023 at 01:47, Alexander
2023 at 06:10, Alper Nebi Yasak wrote:
From: Alexander Graf
Now that we have everything in place to support ramfb, let's wire it up
by default in the ARM QEMU targets. That way, you can easily use a
graphical console by just passing -device ramfb to the QEMU command line.
Signed-off
On 28.08.23 20:28, Alper Nebi Yasak wrote:
On 2023-08-28 20:54 +03:00, Simon Glass wrote:
Hi Alper,
On Mon, 28 Aug 2023 at 09:46, Alper Nebi Yasak wrote:
On 2023-08-22 21:56 +03:00, Simon Glass wrote:
Hi Alper,
On Tue, 22 Aug 2023 at 06:10, Alper Nebi Yasak wrote:
From: Alexander Graf
On 28.08.23 19:54, Simon Glass wrote:
Hi Alex,
On Wed, 23 Aug 2023 at 02:56, Alexander Graf wrote:
Hey Simon,
On 22.08.23 20:56, Simon Glass wrote:
Hi Alex,
On Tue, 22 Aug 2023 at 01:47, Alexander Graf wrote:
On 22.08.23 01:03, Simon Glass wrote:
Hi Alex,
On Mon, 21 Aug 2023 at 16:40
Hey Simon,
On 22.08.23 20:56, Simon Glass wrote:
Hi Alex,
On Tue, 22 Aug 2023 at 01:47, Alexander Graf wrote:
On 22.08.23 01:03, Simon Glass wrote:
Hi Alex,
On Mon, 21 Aug 2023 at 16:40, Alexander Graf wrote:
On 22.08.23 00:10, Simon Glass wrote:
Hi Alex,
On Mon, 21 Aug 2023 at 14:20
On 22.08.23 01:03, Simon Glass wrote:
Hi Alex,
On Mon, 21 Aug 2023 at 16:40, Alexander Graf wrote:
On 22.08.23 00:10, Simon Glass wrote:
Hi Alex,
On Mon, 21 Aug 2023 at 14:20, Alexander Graf wrote:
On 21.08.23 21:57, Simon Glass wrote:
Hi Alex,
On Mon, 21 Aug 2023 at 13:33, Alexander
On 22.08.23 00:10, Simon Glass wrote:
Hi Alex,
On Mon, 21 Aug 2023 at 13:59, Alexander Graf wrote:
On 21.08.23 21:11, Simon Glass wrote:
Hi Alper,
On Mon, 21 Aug 2023 at 07:51, Alper Nebi Yasak wrote:
From: Alexander Graf
Now that we have a damage area tells us which parts
On 22.08.23 00:10, Simon Glass wrote:
Hi Alex,
On Mon, 21 Aug 2023 at 14:20, Alexander Graf wrote:
On 21.08.23 21:57, Simon Glass wrote:
Hi Alex,
On Mon, 21 Aug 2023 at 13:33, Alexander Graf wrote:
On 21.08.23 21:11, Simon Glass wrote:
Hi Alper,
On Mon, 21 Aug 2023 at 07:51, Alper
On 21.08.23 21:57, Simon Glass wrote:
Hi Alex,
On Mon, 21 Aug 2023 at 13:33, Alexander Graf wrote:
On 21.08.23 21:11, Simon Glass wrote:
Hi Alper,
On Mon, 21 Aug 2023 at 07:51, Alper Nebi Yasak wrote:
This is a rebase of Alexander Graf's video damage tracking series, with
some tests
On 21.08.23 21:11, Simon Glass wrote:
Hi Alper,
On Mon, 21 Aug 2023 at 07:51, Alper Nebi Yasak wrote:
From: Alexander Graf
CONFIG_VIDEO_COPY implemented a range-based copying mechanism: If we
print a single character, it will always copy the full range of bytes
from the top left corner
On 21.08.23 21:11, Simon Glass wrote:
Hi Alper,
On Mon, 21 Aug 2023 at 07:51, Alper Nebi Yasak wrote:
From: Alexander Graf
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
ore
- Add patch "video: Use VIDEO_DAMAGE for VIDEO_COPY"
v1: https://lore.kernel.org/all/20220606234336.5021-1-ag...@csgraf.de/
Alexander Graf (9):
dm: video: Add damage tracking API
dm: video: Add damage notification on display fills
vidconsole: Add damage notifications to all
.
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 |
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
n 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 d
-by: Alexander Graf
Reported-by: Da Xue
---
v1 -> v2:
- Fix dcache range; we were flushing too much before
- Remove ifdefs
v3 -> v4:
- Simplify first damage logic
---
drivers/video/video-uclass.c | 45 +---
1 file changed, 37 insertions(+), 8 deletions(-)
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(+)
diff --git a/drivers/video
Now that we have a damage tracking API, let's populate damage done by
UEFI payloads when they BLT data onto the screen.
Signed-off-by: Alexander Graf
Reported-by: Da Xue
---
v1 -> v2:
- Remove ifdefs from gop
v2 -> v3:
- Adapt to always assume DM is used
v3 -> v4:
- Sk
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
driv
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
---
driv
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(+)
diff --git a/drivers/video/video-uclass.c b
ip 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: A
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
.
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 |
Now that we have a damage tracking API, let's populate damage done by
UEFI payloads when they BLT data onto the screen.
Signed-off-by: Alexander Graf
Reported-by: Da Xue
---
v1 -> v2:
- Remove ifdefs from gop
v2 -> v3:
- Adapt to always assume DM is used
---
lib/efi_loader/efi
-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.
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(+)
diff --git a/drivers/video
in later patches.
Signed-off-by: Alexander Graf
Reported-by: Da Xue
---
v1 -> v2:
- Remove ifdefs
v2 -> v3:
- Adapt Kconfig to DM always
---
drivers/video/Kconfig| 14
drivers/video/video-uclass.c | 41
include/v
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
driv
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(+)
diff --git a/drivers/video/video-uclass.c b
nge
v2 -> v3:
- Rebase
- Adapt to DM_VIDEO always
- Make CONFIG_COPY always select VIDEO_DAMAGE
Alexander Graf (7):
dm: video: Add damage tracking API
dm: video: Add damage notification on display clear
vidconsole: Add damage notifications to all vidconsole drivers
video: Add
.
Signed-off-by: Alexander Graf
---
configs/chromebook_coral_defconfig | 1 +
configs/chromebook_link_defconfig| 1 +
configs/chromebook_samus_defconfig | 1 +
configs/minnowmax_defconfig | 1 +
configs/sandbox_defconfig| 1 +
configs/xilinx_zynqmp_virt_defconfig | 1
Now that we have a damage tracking API, let's populate damage done by
UEFI payloads when they BLT data onto the screen.
Signed-off-by: Alexander Graf
Reported-by: Da Xue
---
v1 -> v2:
- Remove ifdefs from gop
---
lib/efi_loader/efi_gop.c | 7 ++-
1 file changed, 6 insertions(+)
-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.
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
driv
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(+)
diff --git a/drivers/video
in later patches.
Signed-off-by: Alexander Graf
Reported-by: Da Xue
---
v1 -> v2:
- Remove ifdefs
---
drivers/video/Kconfig| 15 +
drivers/video/video-uclass.c | 41
include/video.h | 29 +++--
3 fi
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(+)
diff --git a/drivers/video/video-uclass.c b
nge
Alexander Graf (7):
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 fl
On 09.06.22 22:32, Heinrich Schuchardt wrote:
Am 9. Juni 2022 21:04:37 MESZ schrieb Alexander Graf :
On 07.06.22 10:28, Heinrich Schuchardt wrote:
On 6/7/22 01:43, 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
On 07.06.22 10:28, Heinrich Schuchardt wrote:
On 6/7/22 01:43, 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
On 07.06.22 10:00, Heinrich Schuchardt wrote:
On 6/7/22 01:43, 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
Hey Heinrich,
On 07.06.22 09:12, Heinrich Schuchardt wrote:
On 6/7/22 01:43, Alexander Graf wrote:
Now that we have a damage tracking API, let's populate damage done by
UEFI payloads when they BLT data onto the screen.
Signed-off-by: Alexander Graf
Reported-by: Da Xue
---
lib/efi_loader
-by: Alexander Graf
Reported-by: Da Xue
---
drivers/video/video-uclass.c | 49 ++--
1 file changed, 42 insertions(+), 7 deletions(-)
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 9ac1974670..5661beea38 100644
--- a/drivers/video/video
Now that we have a damage tracking API, let's populate damage done by
UEFI payloads when they BLT data onto the screen.
Signed-off-by: Alexander Graf
Reported-by: Da Xue
---
lib/efi_loader/efi_gop.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/lib/efi_loader/efi_gop.c b/lib
as damaged on every update.
Signed-off-by: Alexander Graf
Reported-by: Da Xue
---
drivers/video/console_normal.c | 10 ++
drivers/video/console_rotate.c | 18 ++
drivers/video/console_truetype.c | 12
3 files changed, 40 insertions(+)
diff --git a/drivers
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(+)
diff --git a/drivers/video
in later patches.
Signed-off-by: Alexander Graf
Reported-by: Da Xue
---
drivers/video/Kconfig| 15 ++
drivers/video/video-uclass.c | 40
include/video.h | 39 +--
3 files changed, 92 insertions
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(+)
diff --git a/drivers/video/video-uclass.c b
the current approach. It would make
full screen updates much more expensive.
Alexander Graf (6):
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
On 27.02.22 16:35, Heinrich Schuchardt wrote:
On 2/27/22 15:40, Alexander Graf wrote:
QEMU implements multiple ways to expose graphics output to the virt
machine, but most of them are incompatible with hardware virtualization.
The one that does work reliably is ramfb. It's a very simple
Now that we have everything in place to support ramfb, let's wire it up
by default in the RISC-V QEMU targets. That way, you can easily use a
graphical console by just passing -device ramfb to the QEMU command line.
Signed-off-by: Alexander Graf
---
board/emulation/qemu-riscv/Kconfig | 6
Hey Heinrich,
On 27.02.22 16:33, Heinrich Schuchardt wrote:
On 2/27/22 15:13, Alexander Graf wrote:
On 27.02.22 14:07, Mark Kettenis wrote:
From: Alexander Graf
Date: Sun, 27 Feb 2022 13:18:56 +0100
For targets that enable ACPI, we should not pass Device Trees into
the payload. However
Now that we have everything in place to support ramfb, let's wire it up
by default in the ARM QEMU targets. That way, you can easily use a
graphical console by just passing -device ramfb to the QEMU command line.
Signed-off-by: Alexander Graf
---
arch/arm/Kconfig| 4
Now that we have a ramfb device driver, let's add the necessary glueing
magic to also spawn it when we find its qfw file node.
Signed-off-by: Alexander Graf
---
drivers/misc/qfw.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/misc/qfw.c b/drivers/misc
the host about its location and properties. The host then just
displays the contents of the frame buffer on screen.
This patch implements a trivial version of a ramfb driver - hard coded
to a single resolution.
Signed-off-by: Alexander Graf
---
drivers/video/Kconfig | 8 +++
drivers/video
The QEMU fw_cfg device supports writing entries as well. Add the constant
define for it so that we can leverage write functionality later.
Signed-off-by: Alexander Graf
---
include/qfw.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/qfw.h b/include/qfw.h
index 7ca132e66a
, we have a very simple, KVM compatible way to expose
GOP via UEFI to payloads and thus enable development and testing of
graphical OS functionality with QEMU's -M virt.
Alexander Graf (4):
qfw: Add WRITE definition
ramfb: Add driver for ramfb display
qfw: Spawn ramfb device if its file
when passed from
qfw's ACPI framework. With this patch, it happily uses it.
Signed-off-by: Alexander Graf
---
drivers/misc/qfw.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/qfw.c b/drivers/misc/qfw.c
index 754bc6a603..7c6ed41f48 100644
asm/tables.h does not exist on ARM and I did not need it to make the
code compile successfully. Let's not include it there.
Signed-off-by: Alexander Graf
---
Maybe someone with more insight into the qfw code could tell me if we can remove
the include altogether? :)
---
drivers/misc/qfw.c | 2
On 27.02.22 14:07, Mark Kettenis wrote:
From: Alexander Graf
Date: Sun, 27 Feb 2022 13:18:56 +0100
For targets that enable ACPI, we should not pass Device Trees into
the payload. However, our distro boot logic always passes the builtin
DT as an argument.
To make it easy to use ACPI
there as well.
Signed-off-by: Alexander Graf
---
lib/acpi/Makefile | 2 ++
lib/acpi/acpi_writer.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/acpi/Makefile b/lib/acpi/Makefile
index 956b5a0d72..66ba0e94ac 100644
--- a/lib/acpi/Makefile
+++ b/lib/acpi/Makefile
-by: Alexander Graf
---
include/configs/qemu-arm.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
index d45f606860..7ae71e0029 100644
--- a/include/configs/qemu-arm.h
+++ b/include/configs/qemu-arm.h
@@ -39,6 +39,12 @@
# define
successfully
distro boot payloads on ACPI enabled targets.
Signed-off-by: Alexander Graf
---
cmd/bootefi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 94d18ca73f..2c9bc0dcd2 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -265,8 +265,8
On 20.05.21 18:42, Simon Glass wrote:
Hi,
Re Jeremy's comment:
Using DT to pass platform info at this level is sort of crazy on an ACPI
machine which won't have native DTs. Meaning there is an additional
level of unnecessary indirection that needs to be converted back into a
format which can
On 14.05.20 20:46, Heinrich Schuchardt wrote:
On 5/14/20 2:38 PM, Michael Walle wrote:
On some architectures, specifically the layerscape, the secondary cores
wait for an interrupt before entering the spin-tables. This applies only
to boards which doesn't have PSCI provided by TF-a and u-boot
Abner (HPS SW/FW Technologist) ;
>> Heinrich Schuchardt ; Alexander Graf
>> ; U-Boot Mailing List ; Atish Patra
>> ; l...@nuviainc.com
>> Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
>>
>>> On Thu, Feb 13, 2020 at 2:11 PM
> Am 06.02.2020 um 22:06 schrieb Atish Patra :
>
> On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf wrote:
>>
>>
>>> On 06.02.20 19:28, Atish Patra wrote:
>>> On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel
>>> wrote:
>>>> O
On 06.02.20 19:28, Atish Patra wrote:
On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel
wrote:
On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt wrote:
RISC-V booting currently is based on a per boot stage lottery to determine
the active CPU. The Hart State Management (HSM) SBI extension
On 20.01.20 18:22, Tom Rini wrote:
+A few people that may have insight to my question
On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote:
Add distro boot command support for SPI flash.
This distro boot will read the boot script at specific
location at the flash and start sourcing
On 03.12.19 11:26, Alexander Graf wrote:
On 03.12.19 09:08, Heinrich Schuchardt wrote:
On 12/3/19 7:37 AM, Alexander Graf wrote:
On 03.12.19 08:27, Heinrich Schuchardt wrote:
As part of moving the parsing of command line arguments to
do_bootefi()
call efi_install_fdt() with the address
On 03.12.19 09:08, Heinrich Schuchardt wrote:
On 12/3/19 7:37 AM, Alexander Graf wrote:
On 03.12.19 08:27, Heinrich Schuchardt wrote:
As part of moving the parsing of command line arguments to do_bootefi()
call efi_install_fdt() with the address of the device tree instead of a
string
On 03.12.19 08:27, Heinrich Schuchardt wrote:
As part of moving the parsing of command line arguments to do_bootefi()
call efi_install_fdt() with the address of the device tree instead of a
string.
Signed-off-by: Heinrich Schuchardt
---
cmd/bootefi.c | 30 --
1
On 12.11.19 13:00, matthias@kernel.org wrote:
From: Matthias Brugger
For bcm283x based on arm64 we also have to change the mm_region.
Add assign this in mach_cpu_init() so we can create now one binary
for RPi3 and RPi4.
Signed-off-by: Matthias Brugger
For the future, can you think of
On 12.11.19 13:00, matthias@kernel.org wrote:
From: Matthias Brugger
As part of the effort to create one binary for several bcm83x SoCs
we use the SoC compatible to decide which IO base address we use.
Signed-off-by: Matthias Brugger
Is there any reason we can't just base on the
On 12.11.19 13:00, matthias@kernel.org wrote:
From: Matthias Brugger
The fw_dtb_pointer was defined in the assembly code, which makes him
live in section .text_rest
Put that's not necessary, we can push the variable in the .data section.
This will prevent relocation errors like:
On 16.10.19 18:50, Matthias Brugger wrote:
On 27/09/2019 12:14, Alexander Graf wrote:
On 27.09.19 11:00, matthias@kernel.org wrote:
From: Matthias Brugger
For bcm283x based on arm64 we also have to change the mm_region.
Add assign this in mach_cpu_init() so we can create now one binary
On 27.09.19 18:11, Stephen Warren wrote:
On 9/27/19 9:22 AM, Alexander Graf wrote:
On 27.09.19 17:01, Stephen Warren wrote:
On 9/27/19 3:00 AM, matthias@kernel.org wrote:
From: Matthias Brugger
We move the per SOC define BCM283x_BASE to a global variable.
This is a first step
On 27.09.19 17:01, Stephen Warren wrote:
On 9/27/19 3:00 AM, matthias@kernel.org wrote:
From: Matthias Brugger
We move the per SOC define BCM283x_BASE to a global variable.
This is a first step to provide a single binary for several bcm283x
SoCs.
How will this work, given that the
On 27.09.19 11:00, matthias@kernel.org wrote:
From: Matthias Brugger
For bcm283x based on arm64 we also have to change the mm_region.
Add assign this in mach_cpu_init() so we can create now one binary
for RPi3 and RPi4.
Signed-off-by: Matthias Brugger
---
On 27.09.19 11:00, matthias@kernel.org wrote:
From: Matthias Brugger
As part of the effort to create one binary for several bcm83x SoCs
we use the SoC compatible to decide which IO base address we use.
Signed-off-by: Matthias Brugger
---
arch/arm/mach-bcm283x/Kconfig | 6
On 27.09.19 11:00, matthias@kernel.org wrote:
From: Matthias Brugger
We move the per SOC define BCM283x_BASE to a global variable.
This is a first step to provide a single binary for several bcm283x
SoCs.
Signed-off-by: Matthias Brugger
---
arch/arm/mach-bcm283x/include/mach/base.h
On 06.09.19 14:58, Matthias Brugger wrote:
On 06/09/2019 14:11, Alexander Graf wrote:
On 06.09.19 13:56, matthias@kernel.org wrote:
From: Matthias Brugger
When booting through the efi stub, the memory map get's created by
reading the dram bank information. Depending on the version
On 06.09.19 13:56, matthias@kernel.org wrote:
From: Matthias Brugger
When booting through the efi stub, the memory map get's created by
reading the dram bank information. Depending on the version of the RPi4
this information changes. Read the device tree to initialize the dram
bank data
> Am 05.09.2019 um 22:35 schrieb Heinrich Schuchardt :
>
>> On 9/5/19 10:21 PM, Alexander Graf wrote:
>>> On 05.09.19 10:06, Heinrich Schuchardt wrote:
>>> When backspacing in column 0 do no set the column index to ULONG_MAX.
>>> Ensure that the
On 05.09.19 10:06, Heinrich Schuchardt wrote:
EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.SetMode() should return EFI_UNDEFINED if a
screen mode is not available.
Signed-off-by: Heinrich Schuchardt
Reviewed-by: Alexander Graf
Alex
___
U-Boot mailing list
On 05.09.19 10:06, Heinrich Schuchardt wrote:
When backspacing in column 0 do no set the column index to ULONG_MAX.
Ensure that the row number is not set to ULONG_MAX even if the row count is
advertised as 0.
Ignore control characters other the 0x08, 0x0a, 0x0d when updating the
column.
On 27.07.19 10:02, Heinrich Schuchardt wrote:
GRUB on ARM 32bit prior to version 2.04 lacks proper handling of caches.
In U-Boot v2019.04 a workaround for this was inadvertently removed.
The workaround is currently also needed for booting on systems with caches
that cannot be managed via CP15
On 26.07.19 13:55, Matthias Brugger wrote:
On 26/07/2019 13:16, Alexander Graf wrote:
On 24.07.19 16:39, Andrei Gherzan wrote:
From: Matthias Brugger
Devices of bcm283x have different base address, depending if they are on
bcm2835 or bcm2836/7. Use BCM283x_BASE depending on the SoC you
On 24.07.19 16:39, Andrei Gherzan wrote:
From: Matthias Brugger
Devices of bcm283x have different base address, depending if they are on
bcm2835 or bcm2836/7. Use BCM283x_BASE depending on the SoC you want to
build and only add the offset in the header files.
Signed-off-by: Matthias Brugger
On 18.07.19 19:46, Heinrich Schuchardt wrote:
Always call cleanup_before_linux() on ARM 32bit during ExitBootServices().
This fixes a problem problem for booting BSD on ARM 32bit.
Reported-by: Jonathan Gray
Signed-off-by: Heinrich Schuchardt
NAK. Instead this should never call
On 18.07.19 19:33, Heinrich Schuchardt wrote:
On 7/18/19 11:16 AM, Jonathan Gray wrote:
On Thu, Jul 18, 2019 at 10:39:57AM +0200, Mark Kettenis wrote:
Date: Thu, 18 Jul 2019 16:00:16 +1000
From: Jonathan Gray
On Fri, Feb 08, 2019 at 07:46:49PM +0100, Heinrich Schuchardt wrote:
Remove the
On 18.07.19 19:33, Heinrich Schuchardt wrote:
On 7/18/19 11:16 AM, Jonathan Gray wrote:
On Thu, Jul 18, 2019 at 10:39:57AM +0200, Mark Kettenis wrote:
Date: Thu, 18 Jul 2019 16:00:16 +1000
From: Jonathan Gray
On Fri, Feb 08, 2019 at 07:46:49PM +0100, Heinrich Schuchardt wrote:
Remove the
On 10.07.19 06:09, Poonam Aggrwal wrote:
Corrected the email address of Alex.
-Original Message-
From: U-Boot On Behalf Of Poonam
Aggrwal
Sent: Wednesday, July 10, 2019 9:37 AM
To: Alexander Graf
Cc: u-boot@lists.denx.de
Subject: [U-Boot] Boot Linux using EFI environment from u-boot
On 08.07.19 12:13, Daniel Kiper wrote:
Sorry for late reply but I am busy...
On Fri, Jun 28, 2019 at 11:42:06AM +0100, Leif Lindholm wrote:
On Fri, Jun 28, 2019 at 12:17:54PM +0200, Alexander Graf wrote:
On 28.06.19 12:03, Heinrich Schuchardt wrote:
I would be interested in joining. I hope
1 - 100 of 2405 matches
Mail list logo
