** Description changed: - [ Impact ] + [Impact] - * An explanation of the effects of the bug on users and justification - for backporting the fix to the stable release. + On AMD-Xilinx Kria SoM boards (K26-based KV260 / KR260 and K24-based + KD240), flash-kernel generates the U-Boot boot script from + bootscr.zynqmp.kria and appends cma=<size> to the kernel command line + based on the detected board type. For KR/KV boards (K26) the script + currently requests cma=1000M for Jammy. For Noble onwards it is already + 800M. - * In addition, it is helpful, but not required, to include an - explanation of how the upload fixes this bug. + Recent AMD-supplied Kria boot firmware (BOOT.BIN / PMU firmware / ATF / + U-Boot from the newer Kria SOM starter-kit release v1.07) changed the + memory layout reserved before the kernel hands off, so a contiguous 1000 + MiB CMA reservation no longer fits. The kernel then fails to reserve CMA + at boot, which breaks device-tree overlays and any driver that depends + on CMA-backed DMA buffers on the KV260 / KR260 (accelerated apps, + DP/HDMI, camera pipelines that go through the FPGA fabric). - [ Test Plan ] + Reducing the KR/KV CMA request to 800 MiB restores a successful CMA + reservation with the new firmware while still leaving enough contiguous + memory for the standard Kria accelerated-application workloads. The + KD240 (K24) allocation is unchanged at 512 MiB and is not affected. - * detailed instructions how to reproduce the bug + [Test Plan] - * these should allow someone who is not familiar with the affected - package to reproduce the bug and verify that the updated package - fixes the problem. + 1. On a KV260 (or KR260) starter kit, flash the latest AMD Kria boot firmware. + 2. Install Ubuntu 22.04 (jammy) with the unfixed flash-kernel (3.104ubuntu22). + 3. Reboot and confirm the failure: + - the kernel log shows cma: Failed to reserve … / Reserved memory: failed to reserve … for the 1000M region, or + 4. Install the fixed flash-kernel (3.104ubuntu23), let it regenerate /boot/boot.scr, and reboot. + 5. Confirm on the fixed system: + - dmesg | grep -i cma shows the 800 MiB region reserved successfully, + - cat /proc/cmdline shows cma=800M, + 6. Repeat steps 2–5 on a KD240 to confirm the K24 path is unchanged: cat /proc/cmdline still shows cma=512M and the board boots normally. - * if other testing is appropriate to perform before landing this - update, this should also be described here. + [Where problems could occur] - [ Where problems could occur ] + The change is a one-line value change inside the if test $kria = "KD" … + elif test -n $kria block of bootscr.zynqmp.kria. It only affects boards + whose card1_name is detected as SCK-KR-G or SCK-KV-G; the SCK-KD-G + branch and the fallback (-n $kria false) branch are untouched, and no + other board family reads this script. - * Think about what the upload changes in the software. Imagine the - change is wrong or breaks something else: how would this show up? + Possible regressions: - * It is assumed that any SRU candidate patch is well-tested before - upload and has a low overall risk of regression, but it's important - to make the effort to think about what ''could'' happen in the event - of a regression. + - Users on older Kria boot firmware where 1000 MiB previously worked will now boot with 200 MiB less CMA. Workloads that were sized against the old 1000 MiB budget could hit CMA allocation failures. + Mitigation: 800 MiB still exceeds the CMA footprint documented for the shipped Kria accelerated apps, and users who need more can override bootargs locally. + - If the new firmware layout is even more constrained than we measured, 800 MiB could still be too large on some as-yet-unseen firmware revision. That would present as the same failure this SRU is fixing, not as a new class of regression. + - The change lives entirely in /boot/boot.scr after flash-kernel regenerates it. If the user has a stale boot.scr and flash-kernel fails to update it (e.g. read-only /boot), the fix will not take effect — but this is the normal flash-kernel failure mode and not introduced here. - * This must never be "None" or "Low", or entirely an argument as to why - your upload is low risk. + No changes to packaging, install scripts, or other bootscripts. - * This both shows the SRU team that the risks have been considered, - and provides guidance to testers in regression-testing the SRU. + [Other Info] - [ Other Info ] - - * Anything else you think is useful to include - - * Make sure to explain any deviation from the norm, to save the SRU - reviewer from having to infer your reasoning, possibly incorrectly. - This should also help reduce review iterations, particularly when the - reason for the deviation is not obvious. - - * Anticipate questions from users, SRU, +1 maintenance, security teams - and the Technical Board and address these questions in advance + - The fix is a single one-line change in bootscript/arm64/bootscr.zynqmp.kria (cma="1000M" → cma="800M"), applied only to the KR/KV (K26) branch. + - Upstream / other releases: note whether the same change is needed on noble / oracular or is already there. + - Version being uploaded: flash-kernel 3.104ubuntu23 (jammy).
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2157346 Title: SRU: fix CMA failure for Kria devices on jammy To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/2157346/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
