aboutsummaryrefslogtreecommitdiff
path: root/include/hw/arm/boot.h
AgeCommit message (Collapse)Author
2023-05-10hw/arm/boot: Make write_bootloader() public as arm_write_bootloader()Cédric Le Goater
The arm boot.c code includes a utility function write_bootloader() which assists in writing a boot-code fragment into guest memory, including handling endianness and fixing it up with entry point addresses and similar things. This is useful not just for the boot.c code but also in board model code, so rename it to arm_write_bootloader() and make it globally visible. Since we are making it public, make its API a little neater: move the AddressSpace* argument to be next to the hwaddr argument, and allow the fixupcontext array to be const, since we never modify it in this function. Cc: qemu-stable@nongnu.org Signed-off-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20230424152717.1333930-2-peter.maydell@linaro.org [PMM: Split out from another patch by Cédric, added doc comment] Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 0fe43f0abf19bbe24df3dbf0613bb47ed55f1482) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2022-09-14target/arm: Make boards pass base address to armv7m_load_kernel()Peter Maydell
Currently armv7m_load_kernel() takes the size of the block of memory where it should load the initial guest image, but assumes that it should always load it at address 0. This happens to be true of all our M-profile boards at the moment, but it isn't guaranteed to always be so: M-profile CPUs can be configured (via init-svtor and init-nsvtor, which match equivalent hardware configuration signals) to have the initial vector table at any address, not just zero. (For instance the Teeny board has the boot ROM at address 0x0200_0000.) Add a base address argument to armv7m_load_kernel(), so that callers now pass in both base address and size. All the current callers pass 0, so this is not a behaviour change. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220823160417.3858216-3-peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2022-02-08hw/arm/boot: Drop nb_cpus field from arm_boot_infoPeter Maydell
We use the arm_boot_info::nb_cpus field in only one place, and that place can easily get the number of CPUs locally rather than relying on the board code to have set the field correctly. (At least one board, xlnx-versal-virt, does not set the field despite having more than one CPU.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Tested-by: Cédric Le Goater <clg@kaod.org> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20220127154639.2090164-16-peter.maydell@linaro.org
2022-02-08hw/arm/boot: Don't write secondary boot stub if using PSCIPeter Maydell
If we're using PSCI emulation to start secondary CPUs, there is no point in writing the "secondary boot" stub code, because it will never be used -- secondary CPUs start powered-off, and when powered on are set to begin execution at the address specified by the guest's power-on PSCI call, not at the stub. Move the call to the hook that writes the secondary boot stub code so that we can do it only if we're starting a Linux kernel and not using PSCI. (None of the users of the hook care about the ordering of its call relative to anything else: they only use it to write a rom blob to guest memory.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Tested-by: Cédric Le Goater <clg@kaod.org> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20220127154639.2090164-14-peter.maydell@linaro.org
2022-02-08hw/arm/boot: Support setting psci-conduit based on guest ELPeter Maydell
Currently we expect board code to set the psci-conduit property on CPUs and ensure that secondary CPUs are created with the start-powered-off property set to false, if the board wishes to use QEMU's builtin PSCI emulation. This worked OK for the virt board where we first wanted to use it, because the virt board directly creates its CPUs and is in a reasonable position to set those properties. For other boards which model real hardware and use a separate SoC object, however, it is more awkward. Most PSCI-using boards just set the psci-conduit board unconditionally. This was never strictly speaking correct (because you would not be able to run EL3 guest firmware that itself provided the PSCI interface, as the QEMU implementation would overrule it), but mostly worked in practice because for non-PSCI SMC calls QEMU would emulate the SMC instruction as normal (by trapping to guest EL3). However, we would like to make our PSCI emulation follow the part of the SMCC specification that mandates that SMC calls with unknown function identifiers return a failure code, which means that all SMC calls will be handled by the PSCI code and the "emulate as normal" path will no longer be taken. We tried to implement that in commit 9fcd15b9193e81 ("arm: tcg: Adhere to SMCCC 1.3 section 5.2"), but this regressed attempts to run EL3 guest code on the affected boards: * mcimx6ul-evk, mcimx7d-sabre, orangepi, xlnx-zcu102 * for the case only of EL3 code loaded via -kernel (and not via -bios or -pflash), virt and xlnx-versal-virt so for the 7.0 release we reverted it (in commit 4825eaae4fdd56f). This commit provides a mechanism that boards can use to arrange that psci-conduit is set if running guest code at a low enough EL but not if it would be running at the same EL that the conduit implies that the QEMU PSCI implementation is using. (Later commits will convert individual board models to use this mechanism.) We do this by moving the setting of the psci-conduit and start-powered-off properties to arm_load_kernel(). Boards which want to potentially use emulated PSCI must set a psci_conduit field in the arm_boot_info struct to the type of conduit they want to use (SMC or HVC); arm_load_kernel() will then set the CPUs up accordingly if it is not going to start the guest code at the same or higher EL as the fake QEMU firmware would be at. Board/SoC code which uses this mechanism should no longer set the CPU psci-conduit property directly. It should only set the start-powered-off property for secondaries if EL3 guest firmware running bare metal expects that rather than the alternative "all CPUs start executing the firmware at once". Note that when calculating whether we are going to run guest code at EL3, we ignore the setting of arm_boot_info::secure_board_setup, which might cause us to run a stub bit of guest code at EL3 which does some board-specific setup before dropping to EL2 or EL1 to run the guest kernel. This is OK because only one board that enables PSCI sets secure_board_setup (the highbank board), and the stub code it writes will behave the same way whether the one SMC call it makes is handled by "emulate the SMC" or by "PSCI default returns an error code". So we can leave that stub code in place until after we've changed the PSCI default behaviour; at that point we will remove it. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Tested-by: Cédric Le Goater <clg@kaod.org> Message-id: 20220127154639.2090164-4-peter.maydell@linaro.org
2019-11-11hw/arm/boot: Set NSACR.{CP11, CP10} in dummy SMC setup routineClement Deschamps
The boot.c code usually puts the CPU into NS mode directly when it is booting a kernel. Since fc1120a7f5f2d4b6 this has included a requirement to set NSACR to give NS state access to the FPU; we fixed that for the usual code path in ece628fcf6. However, it is also possible for a board model to request an alternative mode of booting, where its 'board_setup' code hook runs in Secure state and is responsible for doing the S->NS transition after it has done whatever work it must do in Secure state. In this situation the board_setup code now also needs to update NSACR. This affects all boards which set info->secure_board_setup, which is currently the 'raspi' and 'highbank' families. They both use the common arm_write_secure_board_setup_dummy_smc(). Set the NSACR CP11 and CP10 bits in the code written by that function, to allow FPU access in Non-Secure state when using dummy SMC setup routine. Otherwise an AArch32 kernel booted on the highbank or raspi boards will UNDEF as soon as it tries to use the FPU. Update the comment describing secure_board_setup to note the new requirements on users of it. This fixes a kernel panic when booting raspbian on raspi2. Successfully tested with: 2017-01-11-raspbian-jessie-lite.img 2018-11-13-raspbian-stretch-lite.img 2019-07-10-raspbian-buster-lite.img Fixes: fc1120a7f5 Signed-off-by: Clement Deschamps <clement.deschamps@greensocs.com> Tested-by: Laurent Bonnans <laurent.bonnans@here.com> Message-id: 20191104151137.81931-1-clement.deschamps@greensocs.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: updated comment to boot.h to note new requirement on users of secure_board_setup; edited/rewrote commit message] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-09-03hw/arm: simplify arm_load_dtbTao Xu
In struct arm_boot_info, kernel_filename, initrd_filename and kernel_cmdline are copied from from MachineState. This patch add MachineState as a parameter into arm_load_dtb() and move the copy chunk of kernel_filename, initrd_filename and kernel_cmdline into arm_load_kernel(). Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Liu Jingqi <jingqi.liu@intel.com> Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Tao Xu <tao3.xu@intel.com> Message-Id: <20190809065731.9097-2-tao3.xu@intel.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Andrew Jeffery <andrew@aj.id.au> Acked-by: Cédric Le Goater <clg@kaod.org> [ehabkost: include hw/boards.h again to fix build failures] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-08-16Include exec/memory.h slightly lessMarkus Armbruster
Drop unnecessary inclusions from headers. Downgrade a few more to exec/hwaddr.h. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-17-armbru@redhat.com>
2019-08-16Include hw/irq.h a lot lessMarkus Armbruster
In my "build everything" tree, changing hw/irq.h triggers a recompile of some 5400 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). hw/hw.h supposedly includes it for convenience. Several other headers include it just to get qemu_irq and.or qemu_irq_handler. Move the qemu_irq and qemu_irq_handler typedefs from hw/irq.h to qemu/typedefs.h, and then include hw/irq.h only where it's still needed. Touching it now recompiles only some 500 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-13-armbru@redhat.com>
2019-05-23arm: Rename hw/arm/arm.h to hw/arm/boot.hPeter Maydell
The header file hw/arm/arm.h now includes only declarations relating to hw/arm/boot.c functionality. Rename it accordingly, and adjust its header comment. The bulk of this commit was created via perl -pi -e 's|hw/arm/arm.h|hw/arm/boot.h|' hw/arm/*.c include/hw/arm/*.h In a few cases we can just delete the #include: hw/arm/msf2-soc.c, include/hw/arm/aspeed_soc.h and include/hw/arm/bcm2836.h did not require it. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190516163857.6430-4-peter.maydell@linaro.org