Skip to content
Snippets Groups Projects
  1. Jan 08, 2022
  2. Dec 20, 2021
    • Jessica Clarke's avatar
      hw/riscv: Use load address rather than entry point for fw_dynamic next_addr · 7e322a7f
      Jessica Clarke authored
      
      The original BBL boot method had the kernel embedded as an opaque blob
      that was blindly jumped to, which OpenSBI implemented as fw_payload.
      OpenSBI then implemented fw_jump, which allows the payload to be loaded
      elsewhere, but still blindly jumps to a fixed address at which the
      kernel is to be loaded. Finally, OpenSBI introduced fw_dynamic, which
      allows the previous stage to inform it where to jump to, rather than
      having to blindly guess like fw_jump, or embed the payload as part of
      the build like fw_payload. When used with an opaque binary (i.e. the
      output of objcopy -O binary), it matches the behaviour of the previous
      methods. However, when used with an ELF, QEMU currently passes on the
      ELF's entry point address, which causes a discrepancy compared with all
      the other boot methods if that entry point is not the first instruction
      in the binary.
      
      This difference specific to fw_dynamic with an ELF is not apparent when
      booting Linux, since its entry point is the first instruction in the
      binary. However, FreeBSD has a separate ELF entry point, following the
      calling convention used by its bootloader, that differs from the first
      instruction in the binary, used for the legacy SBI entry point, and so
      the specific combination of QEMU's default fw_dynamic firmware with
      booting FreeBSD as an ELF rather than a raw binary does not work.
      
      Thus, align the behaviour when loading an ELF with the behaviour when
      loading a raw binary; namely, use the base address of the loaded kernel
      in place of the entry point.
      
      The uImage code is left as-is in using the U-Boot header's entry point,
      since the calling convention for that entry point is the same as the SBI
      one and it mirrors what U-Boot will do.
      
      Signed-off-by: default avatarJessica Clarke <jrtc27@jrtc27.com>
      Reviewed-by: default avatarAlistair Francis <alistair.francis@wdc.com>
      Message-Id: <20211214032456.70203-1-jrtc27@jrtc27.com>
      Signed-off-by: default avatarAlistair Francis <alistair.francis@wdc.com>
      7e322a7f
  3. Dec 15, 2021
    • Markus Armbruster's avatar
      hw: Replace trivial drive_get_next() by drive_get() · 64eaa820
      Markus Armbruster authored
      
      drive_get_next() is basically a bad idea.  It returns the "next" block
      backend of a certain interface type.  "Next" means bus=0,unit=N, where
      subsequent calls count N up from zero, per interface type.
      
      This lets you define unit numbers implicitly by execution order.  If the
      order changes, or new calls appear "in the middle", unit numbers change.
      ABI break.  Hard to spot in review.
      
      A number of machines connect just one backend with drive_get_next().
      Change them to use drive_get() directly.  This makes the (zero) unit
      number explicit in the code.
      
      Cc: Beniamino Galvani <b.galvani@gmail.com>
      Cc: Peter Maydell <peter.maydell@linaro.org>
      Cc: Subbaraya Sundeep <sundeep.lkml@gmail.com>
      Cc: Niek Linnenbank <nieklinnenbank@gmail.com>
      Cc: Andrew Baumann <Andrew.Baumann@microsoft.com>
      Cc: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
      Cc: Jean-Christophe Dubois <jcd@tribudubois.net>
      Cc: Alistair Francis <Alistair.Francis@wdc.com>
      Cc: Bin Meng <bin.meng@windriver.com>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Cc: Artyom Tarasenko <atar4qemu@gmail.com>
      Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
      Cc: Michael Tokarev <mjt@tls.msk.ru>
      Cc: Laurent Vivier <laurent@vivier.eu>
      Cc: qemu-arm@nongnu.org
      Cc: qemu-riscv@nongnu.org
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20211117163409.3587705-3-armbru@redhat.com>
      64eaa820
    • Markus Armbruster's avatar
      hw/sd/ssi-sd: Do not create SD card within controller's realize · 36aa285f
      Markus Armbruster authored
      
      ssi_sd_realize() creates an "sd-card" device.  This is inappropriate,
      and marked FIXME.
      
      Move it to the boards that create these devices.  Prior art: commit
      eb4f566b for device "generic-sdhci", and commit 26c607b8 for
      device "pl181".
      
      The device remains not user-creatable, because its users should (and
      do) wire up its GPIO chip-select line.
      
      Cc: Peter Maydell <peter.maydell@linaro.org>
      Cc: Alistair Francis <Alistair.Francis@wdc.com>
      Cc: Bin Meng <bin.meng@windriver.com>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Cc: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
      Cc: qemu-arm@nongnu.org
      Cc: qemu-riscv@nongnu.org
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20211117163409.3587705-2-armbru@redhat.com>
      Reviewed-by: default avatarPhilippe Mathieu-Daudé <f4bug@amsat.org>
      Reviewed-by: default avatarAlistair Francis <alistair.francis@wdc.com>
      36aa285f
  4. Oct 28, 2021
  5. Oct 22, 2021
  6. Oct 21, 2021
  7. Oct 06, 2021
  8. Sep 21, 2021
  9. Sep 20, 2021
  10. Sep 01, 2021
  11. Aug 26, 2021
  12. Jul 20, 2021
  13. Jul 14, 2021
  14. Jun 24, 2021
Loading