qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@linaro.org>
To: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>,
	qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Leif Lindholm <quic_llindhol@quicinc.com>,
	Radoslaw Biernacki <rad@semihalf.com>,
	Cleber Rosa <crosa@redhat.com>,
	Wainer dos Santos Moschetta <wainersm@redhat.com>,
	Beraldo Leal <bleal@redhat.com>,
	qemu-arm@nongnu.org
Subject: Re: [PATCH v2 2/2] tests/avocado: update firmware for sbsa-ref
Date: Thu, 20 Jun 2024 09:02:28 +0200	[thread overview]
Message-ID: <49dc3d36-1f4a-41b8-acd2-e758bebbfa87@linaro.org> (raw)
In-Reply-To: <20240620060014.605563-3-marcin.juszkiewicz@linaro.org>

Hi Marcin,

On 20/6/24 08:00, Marcin Juszkiewicz wrote:
> Update firmware to have graphics card memory fix from EDK2 commit
> c1d1910be6e04a8b1a73090cf2881fb698947a6e:
> 
>      OvmfPkg/QemuVideoDxe: add feature PCD to remap framebuffer W/C
> 
>      Some platforms (such as SBSA-QEMU on recent builds of the emulator) only
>      tolerate misaligned accesses to normal memory, and raise alignment
>      faults on such accesses to device memory, which is the default for PCIe
>      MMIO BARs.
> 
>      When emulating a PCIe graphics controller, the framebuffer is typically
>      exposed via a MMIO BAR, while the disposition of the region is closer to
>      memory (no side effects on reads or writes, except for the changing
>      picture on the screen; direct random access to any pixel in the image).
> 
>      In order to permit the use of such controllers on platforms that only
>      tolerate these types of accesses for normal memory, it is necessary to
>      remap the memory. Use the DXE services to set the desired capabilities
>      and attributes.
> 
>      Hide this behavior under a feature PCD so only platforms that really
>      need it can enable it. (OVMF on x86 has no need for this)
> 
> With this fix enabled we can boot sbsa-ref with more than one cpu core.

To keep bisection working, don't we want this patch first, then the
previous one on top?

> Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
> ---
>   tests/avocado/machine_aarch64_sbsaref.py | 14 +++++++-------
>   1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/tests/avocado/machine_aarch64_sbsaref.py b/tests/avocado/machine_aarch64_sbsaref.py
> index 136b495096..e920bbf08c 100644
> --- a/tests/avocado/machine_aarch64_sbsaref.py
> +++ b/tests/avocado/machine_aarch64_sbsaref.py
> @@ -37,18 +37,18 @@ def fetch_firmware(self):
>   
>           Used components:
>   
> -        - Trusted Firmware 2.11.0
> -        - Tianocore EDK2 stable202405
> -        - Tianocore EDK2-platforms commit 4bbd0ed
> +        - Trusted Firmware         v2.11.0
> +        - Tianocore EDK2           4d4f569924
> +        - Tianocore EDK2-platforms 3f08401
>   
>           """
>   
>           # Secure BootRom (TF-A code)
>           fs0_xz_url = (
>               "https://artifacts.codelinaro.org/artifactory/linaro-419-sbsa-ref/"
> -            "20240528-140808/edk2/SBSA_FLASH0.fd.xz"
> +            "20240619-148232/edk2/SBSA_FLASH0.fd.xz"
>           )
> -        fs0_xz_hash = "fa6004900b67172914c908b78557fec4d36a5f784f4c3dd08f49adb75e1892a9"
> +        fs0_xz_hash = "0c954842a590988f526984de22e21ae0ab9cb351a0c99a8a58e928f0c7359cf7"
>           tar_xz_path = self.fetch_asset(fs0_xz_url, asset_hash=fs0_xz_hash,
>                                         algorithm='sha256')
>           archive.extract(tar_xz_path, self.workdir)
> @@ -57,9 +57,9 @@ def fetch_firmware(self):
>           # Non-secure rom (UEFI and EFI variables)
>           fs1_xz_url = (
>               "https://artifacts.codelinaro.org/artifactory/linaro-419-sbsa-ref/"
> -            "20240528-140808/edk2/SBSA_FLASH1.fd.xz"
> +            "20240619-148232/edk2/SBSA_FLASH1.fd.xz"
>           )
> -        fs1_xz_hash = "5f3747d4000bc416d9641e33ff4ac60c3cc8cb74ca51b6e932e58531c62eb6f7"
> +        fs1_xz_hash = "c6ec39374c4d79bb9e9cdeeb6db44732d90bb4a334cec92002b3f4b9cac4b5ee"
>           tar_xz_path = self.fetch_asset(fs1_xz_url, asset_hash=fs1_xz_hash,
>                                         algorithm='sha256')
>           archive.extract(tar_xz_path, self.workdir)



      reply	other threads:[~2024-06-20  7:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-20  6:00 [PATCH v2 0/2] tests/avocado: make sbsa-ref working with >1 core Marcin Juszkiewicz
2024-06-20  6:00 ` [PATCH v2 1/2] tests/avocado: use default amount of cores on sbsa-ref Marcin Juszkiewicz
2024-06-20  9:34   ` Peter Maydell
2024-06-20  9:55     ` Marcin Juszkiewicz
2024-06-20 10:04       ` Peter Maydell
2024-06-20  6:00 ` [PATCH v2 2/2] tests/avocado: update firmware for sbsa-ref Marcin Juszkiewicz
2024-06-20  7:02   ` Philippe Mathieu-Daudé [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49dc3d36-1f4a-41b8-acd2-e758bebbfa87@linaro.org \
    --to=philmd@linaro.org \
    --cc=bleal@redhat.com \
    --cc=crosa@redhat.com \
    --cc=marcin.juszkiewicz@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quic_llindhol@quicinc.com \
    --cc=rad@semihalf.com \
    --cc=wainersm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).