| Message ID | 20240507-qcs404-carveout-only-v1-1-93d06884b862@samcday.com |
|---|---|
| State | Accepted |
| Delegated to: | Caleb Connolly |
| Headers | show |
| Series | mach-snapdragon: do carveouts for qcs404 only | expand |
Hi Sam, On Wed, 8 May 2024 at 00:11, Sam Day <me@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? Is the framebuffer region required to be mapped as normal memory or device type or something else? Similarly would normal memory type work for all other reserved memory regions marked as no-map? -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 <me@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 <me@samcday.com> > >
Salutations Sumit, On Wednesday, 8 May 2024 at 11:14 AM, Sumit Garg <sumit.garg@linaro.org> wrote: > > > Hi Sam, > > On Wed, 8 May 2024 at 00:11, Sam Day me@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. 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 me@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 me@samcday.com
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.garg@linaro.org> wrote: > >> >> >> Hi Sam, >> >> On Wed, 8 May 2024 at 00:11, Sam Day me@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 me@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 me@samcday.com
On Wed, 8 May 2024 at 18:09, Caleb Connolly <caleb.connolly@linaro.org> wrote: > > 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.garg@linaro.org> wrote: > > > >> > >> > >> Hi Sam, > >> > >> On Wed, 8 May 2024 at 00:11, Sam Day me@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 Can you start adding some debug prints as to what might be happening? Also, look at my proposal below to hook memory mapping properly for drivers. > > > > 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. I am not sure if U-Boot is really that far away although you can say the infrastructure is not hooked up for Arm. Have a look into map_physmem() and unmap_physmem() utilized by various drivers which are actually hooked up on MIPS. So I think the right way to approach this feature on Qcom platforms is to start hooking up those APIs on mach-snapdragon to begin with via mmu_set_region_dcache_behaviour() underneath. We can always go ahead and make it more generic if needed on other platforms too. -Sumit
'Ello Sumit, On Wednesday, 8 May 2024 at 4:48 PM, Sumit Garg <sumit.garg@linaro.org> wrote: > > > On Wed, 8 May 2024 at 18:09, Caleb Connolly caleb.connolly@linaro.org wrote: > > > 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.garg@linaro.org wrote: > > > > > > > Hi Sam, > > > > > > > > On Wed, 8 May 2024 at 00:11, Sam Day me@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 > > > Can you start adding some debug prints as to what might be happening? > Also, look at my proposal below to hook memory mapping properly for > drivers. I got to the bottom of the issue. This commit seems to work: https://github.com/samcday/u-boot/commit/25bf923c251b56d297d16898210fa36616294415 Calling mmu_set_region_dcache_behaviour alone is insufficient, as it does not change the "flags" of the page-table entry in the way that mmu_change_region_attr does. That's why it was triggering an abort in the previous attempt: __asm_flush_dcache_range was trying to scrub an entry that was still marked as PTE_TYPE_FAULT I guess :) > > > > 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. > > > I am not sure if U-Boot is really that far away although you can say > the infrastructure is not hooked up for Arm. Have a look into > map_physmem() and unmap_physmem() utilized by various drivers which > are actually hooked up on MIPS. So I think the right way to approach > this feature on Qcom platforms is to start hooking up those APIs on > mach-snapdragon to begin with via mmu_set_region_dcache_behaviour() > underneath. We can always go ahead and make it more generic if needed > on other platforms too. So I'm happy to explore this further in a separate patch. Such a patch doesn't seem like something that is suitable for inclusion in 2024.07 at this stage, right? If not, I'm wondering if there's any chance we can still pull this patch in as a stopgap measure? As it currently stands, the carveouts call is the *only* thing preventing msm8916 devices from booting U-Boot when chained from lk2nd. -Sam > > -Sumit
On 09/05/2024 14:59, Sam Day wrote: > 'Ello Sumit, > > On Wednesday, 8 May 2024 at 4:48 PM, Sumit Garg <sumit.garg@linaro.org> wrote: > >> >> >> On Wed, 8 May 2024 at 18:09, Caleb Connolly caleb.connolly@linaro.org wrote: >> >>> 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.garg@linaro.org wrote: >>>> >>>>> Hi Sam, >>>>> >>>>> On Wed, 8 May 2024 at 00:11, Sam Day me@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 >> >> >> Can you start adding some debug prints as to what might be happening? >> Also, look at my proposal below to hook memory mapping properly for >> drivers. > > I got to the bottom of the issue. This commit seems to work: > https://github.com/samcday/u-boot/commit/25bf923c251b56d297d16898210fa36616294415 > > Calling mmu_set_region_dcache_behaviour alone is insufficient, as it > does not change the "flags" of the page-table entry in the way that > mmu_change_region_attr does. That's why it was triggering an abort > in the previous attempt: __asm_flush_dcache_range was trying to scrub > an entry that was still marked as PTE_TYPE_FAULT I guess :) > >> >>>> 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. >> >> >> I am not sure if U-Boot is really that far away although you can say >> the infrastructure is not hooked up for Arm. Have a look into >> map_physmem() and unmap_physmem() utilized by various drivers which >> are actually hooked up on MIPS. So I think the right way to approach >> this feature on Qcom platforms is to start hooking up those APIs on >> mach-snapdragon to begin with via mmu_set_region_dcache_behaviour() >> underneath. We can always go ahead and make it more generic if needed >> on other platforms too. > > So I'm happy to explore this further in a separate patch. Such a patch > doesn't seem like something that is suitable for inclusion in 2024.07 > at this stage, right? > > If not, I'm wondering if there's any chance we can still pull this patch > in as a stopgap measure? As it currently stands, the carveouts call is > the *only* thing preventing msm8916 devices from booting U-Boot when > chained from lk2nd. This patches fixes simplefb on all Qualcomm devices, I'm going to pull it in and we can pursue other solutions down the line. Thanks both, > > -Sam > >> >> -Sumit
On Tue, 07 May 2024 18:41:23 +0000, Sam Day 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. > > 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. > > [...] Applied, thanks! [1/1] mach-snapdragon: do carveouts for qcs404 only https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/a8910537bb6c Best regards,
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(); }
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. 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 <me@samcday.com> --- arch/arm/mach-snapdragon/board.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) --- base-commit: 1c40dda60f5f7e83a6d6f541cf5a57eb7e8ec43c change-id: 20240507-qcs404-carveout-only-7a15bbf3fd89 Best regards,