Hi Sam,
On 08/05/2024 13:40, Sam Day wrote:
Salutations Sumit,
On Wednesday, 8 May 2024 at 11:14 AM, Sumit Garg <sumit.g...@linaro.org> wrote:
Hi Sam,
On Wed, 8 May 2024 at 00:11, Sam Day m...@samcday.com wrote:
The newly introduced carve_out_reserved_memory causes issues when
U-Boot is chained from the lk2nd bootloader. lk2nd provides a
simple-framebuffer device and marks the framebuffer region as no-map in
the supplied /reserved-memory. Consequently, the simple_video driver
triggers a page fault when it tries to write to this region.
How does the corresponding Linux kernel driver handle this?
Firstly: I'm something of a middle-man here. I would consider Caleb the
authoritative source on the carveouts stuff (since they wrote it) and Nikita
Travkin the authority on the simplefb handoff (since he originally wrote it for
lk2nd to hand off to Linux simpledrm and then adapted it to work with U-Boot
simplefb).
I consulted with Nikita on your first question here. He linked me to this
snippet:
https://elixir.bootlin.com/linux/v6.9-rc7/source/drivers/gpu/drm/tiny/simpledrm.c#L877
Is the
framebuffer region required to be mapped as normal memory or device
type or something else?
So I guess based on the link above, it's just mapped as normal uncached memory.
I tried to do something like this a few days ago in U-Boot, but a) it doesn't
work and b) I have no idea what I'm doing:
https://github.com/samcday/u-boot/commit/c100cb3711ddf5b01601691f3e6a9ec890d9a496
After talking with Caleb about this for a bit, they suggested the patch you see here as
what I guess could be considered a "stopgap" solution that hopefully makes it
into 2024.07.
Similarly would normal memory type work for
all other reserved memory regions marked as no-map?
I'll let Caleb weigh in here. My understanding is that the other regions
*should* be marked as PTE_TYPE_FAULT because otherwise drivers might
inadvertently speculatively access regions that are very much off-limits, such
as TZ app regions.
Right, carving out reserved regions and having the driver handle them is
theoretically the "correct" thing to do here. But I'm not sure that the
additional complexity offers much value from a U-Boot context.
If we can teach the armv8 PT/cache code to handle this better, and teach
all the drivers to map their regions on-demand, this would probably help
us a lot (especially as right now if you attempt to access dead space
between peripherals then you'll hang the bus...). But U-Boot is a ways
away from that.
Cheers,
-Sam
-Sumit
As per Caleb's advice, this simple patch only does the carveouts for the
qcs404 SoC for which it was originally designed. The intent is to do the
carveouts for more Qualcomm SoCs in future.
---
I'm not sure if it's feasible to get this in for the 2024.07 release,
but it'd be great if we could - it's the only thing that breaks U-Boot
master on msm8916 devices that chain from lk2nd.
Signed-off-by: Sam Day m...@samcday.com
---
arch/arm/mach-snapdragon/board.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-snapdragon/board.c b/arch/arm/mach-snapdragon/board.c
index 3d5994c878..b439a19ec7 100644
--- a/arch/arm/mach-snapdragon/board.c
+++ b/arch/arm/mach-snapdragon/board.c
@@ -467,10 +467,12 @@ void enable_caches(void)
gd->arch.tlb_addr = tlb_addr;
gd->arch.tlb_size = tlb_size;
- carveout_start = get_timer(0);
- /* Takes ~20-50ms on SDM845 /
- carve_out_reserved_memory();
- debug("carveout time: %lums\n", get_timer(carveout_start));
-
+ / We do the carveouts only for QCS404, for now. /
+ if (fdt_node_check_compatible(gd->fdt_blob, 0, "qcom,qcs404") == 0) {
+ carveout_start = get_timer(0);
+ / Takes ~20-50ms on SDM845 */
+ carve_out_reserved_memory();
+ debug("carveout time: %lums\n", get_timer(carveout_start));
+ }
dcache_enable();
}
---
base-commit: 1c40dda60f5f7e83a6d6f541cf5a57eb7e8ec43c
change-id: 20240507-qcs404-carveout-only-7a15bbf3fd89
Best regards,
--
Sam Day m...@samcday.com
--
// Caleb (they/them)
