default-configs/arm-softmmu.mak | 1 + hw/arm/Kconfig | 16 + hw/arm/Makefile.objs | 1 + hw/arm/sbsa-ref.c | 806 ++++++++++++++++++++++++++++++++++++++++ 4 files changed, 824 insertions(+) create mode 100644 hw/arm/sbsa-ref.c
For the Aarch64, there is one machine 'virt', it is primarily meant to run on KVM and execute virtualization workloads, but we need an environment as faithful as possible to physical hardware, to support firmware and OS development for pysical Aarch64 machines. This machine comes with: - Re-designed memory map. - CPU cortex-a57. - EL2 and EL3 enabled. - GIC version 3. - System bus AHCI controller. - System bus XHCI controller. - CDROM and hard disc on AHCI bus. - E1000E ethernet card on PCIE bus. - VGA display adaptor on PCIE bus. - Only minimal device tree nodes. And without: - virtio deivces. - fw_cfg device. - ACPI tables. Arm Trusted Firmware and UEFI porting to this are done accordingly, and it should supply ACPI tables to load OS, the minimal device tree nodes supplied from this platform are only to pass the dynamic info reflecting command line input to firmware, not for loading OS. v9 changes: - only a few lines update to refine the patch format, while the final sbsa-ref.c is kept same with v8 v8 changes: - rebase to latest QEMU tree - use new way of creating flash as in 'virt' machine - other minor typos and comments update v7 changes: - edit memory map for PCIE slightly - add another secure UART which can be used for RAS and MM from EL0. v6 changes: - rebased to the latest QEMU tree - rechecked all the header files included - added the newly introduced system bus EHCI controller - removed the machine_done callback due to commit 5614ca80 - updated block comments styles according to checkpatch.pl - use Kconfig to add new file - use private SBSA* types defination instead of VIRT* in virt.h since nobody else using them so they are in the .c file instead of a new .h file v5 changes: - removed more lines derived from virt.c - designed a new memory map - splitted former one patch into two for easier review - cancled previous EHCI and new HXCI coming later separately V4 changes: - rebased to v3.0.0 - removed timer, uart, rtc, *hci device tree nodes (others were removerd in v3) - other minore codes clean up, mainly unsed header files, comments etc. V3 changes: - rename the platform 'sbsa-ref' - move all the codes to a separate file sbsa-ref.c - remove paravirtualized fw_cfg device - do not supply ACPI tables, since firmware will do it - supply only necessary DT nodes - and other minor code clean up Hongbo Zhang (2): hw/arm: Add arm SBSA reference machine, skeleton part hw/arm: Add arm SBSA reference machine, devices part default-configs/arm-softmmu.mak | 1 + hw/arm/Kconfig | 16 + hw/arm/Makefile.objs | 1 + hw/arm/sbsa-ref.c | 806 ++++++++++++++++++++++++++++++++++++++++ 4 files changed, 824 insertions(+) create mode 100644 hw/arm/sbsa-ref.c -- 2.7.4
Hi, On Sun, Jun 30, 2019 at 06:20:32PM +0800, Hongbo Zhang wrote: > For the Aarch64, there is one machine 'virt', it is primarily meant to > run on KVM and execute virtualization workloads, but we need an > environment as faithful as possible to physical hardware, to support > firmware and OS development for pysical Aarch64 machines. > I tried to boot linux on this machine with -kernel command line argument, but have not been successful. Can someone point me to a working command line, one that lets me load the kernel directly ? Thanks, Guenter
This machine is not ment for direct kernel boot. Is main purpose is development of FW, kernel and other HW/SW parts for SBSA. We are currently working on UEFI and ATF for this machine. It might be somehow possible to run kernel with DT but we do not support it at this moment. If all you want is to boot kernel directly, it is far more convenient to use existing virt machine. niedz., 14 lip 2019, 17:20 użytkownik Guenter Roeck <linux@roeck-us.net> napisał: > Hi, > > On Sun, Jun 30, 2019 at 06:20:32PM +0800, Hongbo Zhang wrote: > > For the Aarch64, there is one machine 'virt', it is primarily meant to > > run on KVM and execute virtualization workloads, but we need an > > environment as faithful as possible to physical hardware, to support > > firmware and OS development for pysical Aarch64 machines. > > > > I tried to boot linux on this machine with -kernel command line argument, > but have not been successful. Can someone point me to a working command > line, one that lets me load the kernel directly ? > > Thanks, > Guenter >
On 7/14/19 8:40 AM, Radoslaw Biernacki wrote: > This machine is not ment for direct kernel boot. Is main purpose is development of FW, kernel and other HW/SW parts for SBSA. We are currently working on UEFI and ATF for this machine. > > It might be somehow possible to run kernel with DT but we do not support it at this moment. If all you want is to boot kernel directly, it is far more convenient to use existing virt machine. > Too bad. As you may know, I am testing the Linux kernel by running it with as many qemu machines as possible. I already run several boot tests with the 'virt' machine, and I was trying to extend test coverage with the sbsa machine. Guenter > niedz., 14 lip 2019, 17:20 użytkownik Guenter Roeck <linux@roeck-us.net <mailto:linux@roeck-us.net>> napisał: > > Hi, > > On Sun, Jun 30, 2019 at 06:20:32PM +0800, Hongbo Zhang wrote: > > For the Aarch64, there is one machine 'virt', it is primarily meant to > > run on KVM and execute virtualization workloads, but we need an > > environment as faithful as possible to physical hardware, to support > > firmware and OS development for pysical Aarch64 machines. > > > > I tried to boot linux on this machine with -kernel command line argument, > but have not been successful. Can someone point me to a working command > line, one that lets me load the kernel directly ? > > Thanks, > Guenter >
If running full machine stack is an option, than I think that you will be able to use SBSA machine in your tests once we have all the FW images ready. But unfortunately we are not there yet. niedz., 14 lip 2019, 23:57 użytkownik Guenter Roeck <linux@roeck-us.net> napisał: > On 7/14/19 8:40 AM, Radoslaw Biernacki wrote: > > This machine is not ment for direct kernel boot. Is main purpose is > development of FW, kernel and other HW/SW parts for SBSA. We are currently > working on UEFI and ATF for this machine. > > > > It might be somehow possible to run kernel with DT but we do not support > it at this moment. If all you want is to boot kernel directly, it is far > more convenient to use existing virt machine. > > > > Too bad. As you may know, I am testing the Linux kernel by running it with > as many qemu > machines as possible. I already run several boot tests with the 'virt' > machine, and > I was trying to extend test coverage with the sbsa machine. > > Guenter > > > niedz., 14 lip 2019, 17:20 użytkownik Guenter Roeck <linux@roeck-us.net > <mailto:linux@roeck-us.net>> napisał: > > > > Hi, > > > > On Sun, Jun 30, 2019 at 06:20:32PM +0800, Hongbo Zhang wrote: > > > For the Aarch64, there is one machine 'virt', it is primarily > meant to > > > run on KVM and execute virtualization workloads, but we need an > > > environment as faithful as possible to physical hardware, to > support > > > firmware and OS development for pysical Aarch64 machines. > > > > > > > I tried to boot linux on this machine with -kernel command line > argument, > > but have not been successful. Can someone point me to a working > command > > line, one that lets me load the kernel directly ? > > > > Thanks, > > Guenter > > > >
On Sun, 30 Jun 2019 at 11:21, Hongbo Zhang <hongbo.zhang@linaro.org> wrote: > > For the Aarch64, there is one machine 'virt', it is primarily meant to > run on KVM and execute virtualization workloads, but we need an > environment as faithful as possible to physical hardware, to support > firmware and OS development for pysical Aarch64 machines. > > This machine comes with: > - Re-designed memory map. > - CPU cortex-a57. > - EL2 and EL3 enabled. > - GIC version 3. > - System bus AHCI controller. > - System bus XHCI controller. > - CDROM and hard disc on AHCI bus. > - E1000E ethernet card on PCIE bus. > - VGA display adaptor on PCIE bus. > - Only minimal device tree nodes. > And without: > - virtio deivces. > - fw_cfg device. > - ACPI tables. I've pointed out a number of issues with these patches, but they all turn out to be very minor (mostly fixable by moving code between patch 1 and 2). The other thing we need is a MAINTAINERS section for the new board: diff --git a/MAINTAINERS b/MAINTAINERS index cad58b94879..0bf3739f06a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -728,6 +728,13 @@ F: include/hw/arm/fsl-imx6.h F: include/hw/misc/imx6_*.h F: include/hw/ssi/imx_spi.h +SBSA-REF +M: Hongbo Zhang <hongbo.zhang@linaro.org> +M: Peter Maydell <peter.maydell@linaro.org> +L: qemu-arm@nongnu.org +S: Maintained +F: hw/arm/sbsa-ref.c + Sharp SL-5500 (Collie) PDA M: Peter Maydell <peter.maydell@linaro.org> L: qemu-arm@nongnu.org So rather than making you do another respin, I'm planning to make the fixes in my target-arm.next tree as I apply the patches. That way we can get this in before softfreeze (which is tomorrow). thanks -- PMM
On Mon, 1 Jul 2019 at 22:54, Peter Maydell <peter.maydell@linaro.org> wrote: > > On Sun, 30 Jun 2019 at 11:21, Hongbo Zhang <hongbo.zhang@linaro.org> wrote: > > > > For the Aarch64, there is one machine 'virt', it is primarily meant to > > run on KVM and execute virtualization workloads, but we need an > > environment as faithful as possible to physical hardware, to support > > firmware and OS development for pysical Aarch64 machines. > > > > This machine comes with: > > - Re-designed memory map. > > - CPU cortex-a57. > > - EL2 and EL3 enabled. > > - GIC version 3. > > - System bus AHCI controller. > > - System bus XHCI controller. > > - CDROM and hard disc on AHCI bus. > > - E1000E ethernet card on PCIE bus. > > - VGA display adaptor on PCIE bus. > > - Only minimal device tree nodes. > > And without: > > - virtio deivces. > > - fw_cfg device. > > - ACPI tables. > > I've pointed out a number of issues with these patches, but they > all turn out to be very minor (mostly fixable by moving code between > patch 1 and 2). The other thing we need is a MAINTAINERS section for > the new board: > > diff --git a/MAINTAINERS b/MAINTAINERS > index cad58b94879..0bf3739f06a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -728,6 +728,13 @@ F: include/hw/arm/fsl-imx6.h > F: include/hw/misc/imx6_*.h > F: include/hw/ssi/imx_spi.h > > +SBSA-REF > +M: Hongbo Zhang <hongbo.zhang@linaro.org> > +M: Peter Maydell <peter.maydell@linaro.org> > +L: qemu-arm@nongnu.org > +S: Maintained > +F: hw/arm/sbsa-ref.c > + > Sharp SL-5500 (Collie) PDA > M: Peter Maydell <peter.maydell@linaro.org> > L: qemu-arm@nongnu.org > > > So rather than making you do another respin, I'm planning to > make the fixes in my target-arm.next tree as I apply the patches. > That way we can get this in before softfreeze (which is tomorrow). > Thank you for the efforts. > thanks > -- PMM
Hi Peter, On Mon, Jul 01, 2019 at 03:54:24PM +0100, Peter Maydell wrote: > I've pointed out a number of issues with these patches, but they > all turn out to be very minor (mostly fixable by moving code between > patch 1 and 2). The other thing we need is a MAINTAINERS section for > the new board: > > diff --git a/MAINTAINERS b/MAINTAINERS > index cad58b94879..0bf3739f06a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -728,6 +728,13 @@ F: include/hw/arm/fsl-imx6.h > F: include/hw/misc/imx6_*.h > F: include/hw/ssi/imx_spi.h > > +SBSA-REF > +M: Hongbo Zhang <hongbo.zhang@linaro.org> > +M: Peter Maydell <peter.maydell@linaro.org> > +L: qemu-arm@nongnu.org > +S: Maintained > +F: hw/arm/sbsa-ref.c > + Sadly, Hongbo is no longer in Linaro (but has generously helped keep working on this platform being upstreamed since he left). It is my understanding that in his new role, Hongbo does not have the bandwidth to keep maintaining this platform once it's in. Unless I have misunderstood this (Hongbo, please confirm - we would certainly love to have your help if you feel that you do have the banwidth), could we please add Radek as a maintainer instead?: M: Radoslaw Biernacki <radoslaw.biernacki@linaro.org> If you think it could be useful, feel free to add me as a designated reviewer: R: Leif Lindholm <leif.lindholm@linaro.org> (I would not be offended if you don't, I have plenty to keep me busy :) > Sharp SL-5500 (Collie) PDA > M: Peter Maydell <peter.maydell@linaro.org> > L: qemu-arm@nongnu.org > > > So rather than making you do another respin, I'm planning to > make the fixes in my target-arm.next tree as I apply the patches. > That way we can get this in before softfreeze (which is tomorrow). Many thanks! Best Regards, Leif
On Tue, 2 Jul 2019 at 00:08, Leif Lindholm <leif.lindholm@linaro.org> wrote: > > Hi Peter, > > On Mon, Jul 01, 2019 at 03:54:24PM +0100, Peter Maydell wrote: > > I've pointed out a number of issues with these patches, but they > > all turn out to be very minor (mostly fixable by moving code between > > patch 1 and 2). The other thing we need is a MAINTAINERS section for > > the new board: > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index cad58b94879..0bf3739f06a 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -728,6 +728,13 @@ F: include/hw/arm/fsl-imx6.h > > F: include/hw/misc/imx6_*.h > > F: include/hw/ssi/imx_spi.h > > > > +SBSA-REF > > +M: Hongbo Zhang <hongbo.zhang@linaro.org> > > +M: Peter Maydell <peter.maydell@linaro.org> > > +L: qemu-arm@nongnu.org > > +S: Maintained > > +F: hw/arm/sbsa-ref.c > > + > > Sadly, Hongbo is no longer in Linaro (but has generously helped keep > working on this platform being upstreamed since he left). It is my > understanding that in his new role, Hongbo does not have the bandwidth > to keep maintaining this platform once it's in. > > Unless I have misunderstood this (Hongbo, please confirm - we would > certainly love to have your help if you feel that you do have the > banwidth), could we please add Radek as a maintainer instead?: > Yes we can add Radoslaw as maintainer. As to me, my new role still have relation with Arm and virtualization, I will keep watching this :) > M: Radoslaw Biernacki <radoslaw.biernacki@linaro.org> > > If you think it could be useful, feel free to add me as a designated > reviewer: > > R: Leif Lindholm <leif.lindholm@linaro.org> > > (I would not be offended if you don't, I have plenty to keep me busy :) > > > Sharp SL-5500 (Collie) PDA > > M: Peter Maydell <peter.maydell@linaro.org> > > L: qemu-arm@nongnu.org > > > > > > So rather than making you do another respin, I'm planning to > > make the fixes in my target-arm.next tree as I apply the patches. > > That way we can get this in before softfreeze (which is tomorrow). > > Many thanks! > > Best Regards, > > Leif
Hi Leif and Peter, We talked with Hongbo about the takeover, so please add me as maintainer. On Mon, 1 Jul 2019 at 18:08, Leif Lindholm <leif.lindholm@linaro.org> wrote: > Hi Peter, > > On Mon, Jul 01, 2019 at 03:54:24PM +0100, Peter Maydell wrote: > > I've pointed out a number of issues with these patches, but they > > all turn out to be very minor (mostly fixable by moving code between > > patch 1 and 2). The other thing we need is a MAINTAINERS section for > > the new board: > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index cad58b94879..0bf3739f06a 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -728,6 +728,13 @@ F: include/hw/arm/fsl-imx6.h > > F: include/hw/misc/imx6_*.h > > F: include/hw/ssi/imx_spi.h > > > > +SBSA-REF > > +M: Hongbo Zhang <hongbo.zhang@linaro.org> > > +M: Peter Maydell <peter.maydell@linaro.org> > > +L: qemu-arm@nongnu.org > > +S: Maintained > > +F: hw/arm/sbsa-ref.c > > + > > Sadly, Hongbo is no longer in Linaro (but has generously helped keep > working on this platform being upstreamed since he left). It is my > understanding that in his new role, Hongbo does not have the bandwidth > to keep maintaining this platform once it's in. > > Unless I have misunderstood this (Hongbo, please confirm - we would > certainly love to have your help if you feel that you do have the > banwidth), could we please add Radek as a maintainer instead?: > > M: Radoslaw Biernacki <radoslaw.biernacki@linaro.org> > > If you think it could be useful, feel free to add me as a designated > reviewer: > > R: Leif Lindholm <leif.lindholm@linaro.org> > > (I would not be offended if you don't, I have plenty to keep me busy :) > > > Sharp SL-5500 (Collie) PDA > > M: Peter Maydell <peter.maydell@linaro.org> > > L: qemu-arm@nongnu.org > > > > > > So rather than making you do another respin, I'm planning to > > make the fixes in my target-arm.next tree as I apply the patches. > > That way we can get this in before softfreeze (which is tomorrow). > > Many thanks! > > Best Regards, > > Leif >
On Mon, 1 Jul 2019 at 17:23, Radoslaw Biernacki <radoslaw.biernacki@linaro.org> wrote: > > Hi Leif and Peter, > > We talked with Hongbo about the takeover, so please add me as maintainer. Thanks for volunteering; I've updated the MAINTAINERS entry in my target-arm queue as Leif suggests. thanks -- PMM
On Sun, 30 Jun 2019 at 11:21, Hongbo Zhang <hongbo.zhang@linaro.org> wrote: > > For the Aarch64, there is one machine 'virt', it is primarily meant to > run on KVM and execute virtualization workloads, but we need an > environment as faithful as possible to physical hardware, to support > firmware and OS development for pysical Aarch64 machines. > > This machine comes with: > - Re-designed memory map. > - CPU cortex-a57. > - EL2 and EL3 enabled. > - GIC version 3. > - System bus AHCI controller. > - System bus XHCI controller. > - CDROM and hard disc on AHCI bus. > - E1000E ethernet card on PCIE bus. > - VGA display adaptor on PCIE bus. > - Only minimal device tree nodes. > And without: > - virtio deivces. > - fw_cfg device. > - ACPI tables. > > Arm Trusted Firmware and UEFI porting to this are done accordingly, and > it should supply ACPI tables to load OS, the minimal device tree nodes > supplied from this platform are only to pass the dynamic info reflecting > command line input to firmware, not for loading OS. Hi; this fails "make check" for me. Running the relevant bit of the test suite standalone: e104462:bionic:arm-clang$ QTEST_QEMU_BINARY=arm-softmmu/qemu-system-arm QTEST_QEMU_IMG=qemu-img tests/qom-test /arm/qom/integratorcp: OK /arm/qom/nuri: OK /arm/qom/mps2-an511: OK /arm/qom/verdex: OK /arm/qom/mps2-an505: OK /arm/qom/ast2500-evb: OK /arm/qom/smdkc210: OK /arm/qom/collie: OK /arm/qom/imx25-pdk: OK /arm/qom/none: OK /arm/qom/spitz: OK /arm/qom/musca-b1: OK /arm/qom/realview-pbx-a9: OK /arm/qom/realview-eb: OK /arm/qom/realview-pb-a8: OK /arm/qom/versatilepb: OK /arm/qom/emcraft-sf2: OK /arm/qom/musicpal: OK /arm/qom/sbsa-ref: ** ERROR:/home/petmay01/linaro/qemu-from-laptop/qemu/qom/object.c:628:object_new_with_type: assertion failed: (type != NULL) Broken pipe /home/petmay01/linaro/qemu-from-laptop/qemu/tests/libqtest.c:145: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) Aborted (core dumped) It looks like the new board model is being added to the 32-bit qemu-system-arm as well as to qemu-system-aarch64. This seems wrong, since the board will only work with a 64-bit CPU. thanks -- PMM
© 2016 - 2024 Red Hat, Inc.