Re: [PATCH v2] aspeed: Deprecate the tacoma-bmc machine
On Sat, 31 Aug 2024 at 05:41, Guenter Roeck wrote: > > On Fri, Aug 30, 2024 at 10:09:25AM +0200, Cédric Le Goater wrote: > > Hello, > > > > > > > > > I solved the problem by adding support for IBM Bonnell (which > > > > > instantiates > > > > > the TPM chip through its devicetree file, similar to tacoma-bmc) to > > > > > my local > > > > > copy of qemu. > > > > > > > > Hmm, did you copy the rainier-bmc machine definition ? > > > > > > > For aspeed_machine_bonnell_class_init(), pretty much yes, since I don't > > > know > > > the actual hardware. For I2C initialization I used the devicetree file. > > > You can find the patch in the master-local or v9.1.0-local branches > > > of my qemu clone at https://github.com/groeck/qemu if you are interested. > > > > Oh nice ! Let's merge the IBM Bonnell machine. We can ask IBM to help fixing > > the definitions (strapping). Enabling the PCA9554 is good to have too. Instead of adding Bonnell to qemu, could we use the Rainier machine? I know the kernel device tree removed the i2c tpm, but there's no harm in it being present in the qemu machine. The bonnell device tree should boot fine on the rainier machine for your purposes. Cheers, Joel
Re: [RFC PATCH 11/11] ppc/pnv: Change powernv default to powernv10
On Wed, 11 Oct 2023 at 07:28, Nicholas Piggin wrote: > > On Tue Oct 10, 2023 at 10:05 PM AEST, Joel Stanley wrote: > > On Tue, 10 Oct 2023 at 18:24, Nicholas Piggin wrote: > > > > > > POWER10 is the latest IBM Power machine. Although it is not offered in > > > "OPAL mode" (i.e., powernv configuration), so there is a case that it > > > should remain at powernv9, most of the development work is going into > > > powernv10 at the moment. > > > > > > Signed-off-by: Nicholas Piggin > > > > Reviewed-by: Joel Stanley > > > > Do we need to update the docs? > > What did you have in mind? Add some powernv10 examples? Nothing in mind. The docs don't actually mention which cpu is the default, which has the upside of us not needing to update it. Cheers, Joel
Re: [PATCH v2] misc/pca9552: Let external devices set pca9552 inputs
On Fri, 6 Oct 2023 at 07:23, Glenn Miles wrote:
>
> Allow external devices to drive pca9552 input pins by adding
> input GPIO's to the model. This allows a device to connect
> its output GPIO's to the pca9552 input GPIO's.
>
> In order for an external device to set the state of a pca9552
> pin, the pin must first be configured for high impedance (LED
> is off). If the pca9552 pin is configured to drive the pin low
> (LED is on), then external input will be ignored.
Does this let us use qom-set from the monitor, and have the guest see
the state change?
An example in the commit message, or even better would be a test.
Some other comments below.
>
> Signed-off-by: Glenn Miles
> ---
> Based-on: <20230927203221.3286895-1-mil...@linux.vnet.ibm.com>
> ([PATCH] misc/pca9552: Fix inverted input status)
> hw/misc/pca9552.c | 39 ++-
> include/hw/misc/pca9552.h | 3 ++-
> 2 files changed, 36 insertions(+), 6 deletions(-)
>
> diff --git a/hw/misc/pca9552.c b/hw/misc/pca9552.c
> index ad811fb249..f28b5ecd7e 100644
> --- a/hw/misc/pca9552.c
> +++ b/hw/misc/pca9552.c
> @@ -113,16 +113,22 @@ static void pca955x_update_pin_input(PCA955xState *s)
> switch (config) {
> case PCA9552_LED_ON:
> /* Pin is set to 0V to turn on LED */
> -qemu_set_irq(s->gpio[i], 0);
> +qemu_set_irq(s->gpio_out[i], 0);
> s->regs[input_reg] &= ~(1 << input_shift);
> break;
> case PCA9552_LED_OFF:
> /*
> * Pin is set to Hi-Z to turn off LED and
> - * pullup sets it to a logical 1.
> + * pullup sets it to a logical 1 unless
> + * external device drives it low.
> */
> -qemu_set_irq(s->gpio[i], 1);
> -s->regs[input_reg] |= 1 << input_shift;
> +if (s->ext_state[i] == 0) {
> +qemu_set_irq(s->gpio_out[i], 0);
> +s->regs[input_reg] &= ~(1 << input_shift);
> +} else {
> +qemu_set_irq(s->gpio_out[i], 1);
> +s->regs[input_reg] |= 1 << input_shift;
> +}
> break;
> case PCA9552_LED_PWM0:
> case PCA9552_LED_PWM1:
> @@ -337,6 +343,7 @@ static const VMStateDescription pca9552_vmstate = {
> VMSTATE_UINT8(len, PCA955xState),
> VMSTATE_UINT8(pointer, PCA955xState),
> VMSTATE_UINT8_ARRAY(regs, PCA955xState, PCA955X_NR_REGS),
> +VMSTATE_UINT8_ARRAY(ext_state, PCA955xState, PCA955X_PIN_COUNT_MAX),
> VMSTATE_I2C_SLAVE(i2c, PCA955xState),
> VMSTATE_END_OF_LIST()
> }
> @@ -355,6 +362,7 @@ static void pca9552_reset(DeviceState *dev)
> s->regs[PCA9552_LS2] = 0x55;
> s->regs[PCA9552_LS3] = 0x55;
>
> +memset(s->ext_state, 1, PCA955X_PIN_COUNT_MAX);
> pca955x_update_pin_input(s);
>
> s->pointer = 0xFF;
> @@ -377,6 +385,26 @@ static void pca955x_initfn(Object *obj)
> }
> }
>
> +static void pca955x_set_ext_state(PCA955xState *s, int pin, int level)
> +{
> +if (s->ext_state[pin] != level) {
> +uint16_t pins_status = pca955x_pins_get_status(s);
> +s->ext_state[pin] = level;
> +pca955x_update_pin_input(s);
> +pca955x_display_pins_status(s, pins_status);
> +}
> +}
> +
> +static void pca955x_gpio_in_handler(void *opaque, int pin, int level)
> +{
> +
> +PCA955xState *s = PCA955X(opaque);
> +PCA955xClass *k = PCA955X_GET_CLASS(s);
> +
> +assert((pin >= 0) && (pin < k->pin_count));
> +pca955x_set_ext_state(s, pin, level);
> +}
> +
> static void pca955x_realize(DeviceState *dev, Error **errp)
> {
> PCA955xClass *k = PCA955X_GET_CLASS(dev);
> @@ -386,7 +414,8 @@ static void pca955x_realize(DeviceState *dev, Error
> **errp)
> s->description = g_strdup("pca-unspecified");
> }
>
> -qdev_init_gpio_out(dev, s->gpio, k->pin_count);
> +qdev_init_gpio_out(dev, s->gpio_out, k->pin_count);
> +qdev_init_gpio_in(dev, pca955x_gpio_in_handler, k->pin_count);
> }
>
> static Property pca955x_properties[] = {
> diff --git a/include/hw/misc/pca9552.h b/include/hw/misc/pca9552.h
> index b6f4e264fe..c36525f0c3 100644
> --- a/include/hw/misc/pca9552.h
> +++ b/include/hw/misc/pca9552.h
> @@ -30,7 +30,8 @@ struct PCA955xState {
> uint8_t pointer;
>
> uint8_t regs[PCA955X_NR_REGS];
> -qemu_irq gpio[PCA955X_PIN_COUNT_MAX];
> +qemu_irq gpio_out[PCA955X_PIN_COUNT_MAX];
I wondered if the renaming of gpio to gpio_out could be a separate
patch, but once I'd read the entire patch it made sense, so don't
bother.
I think Cédric has some magic for sorting the header file changes at
the start of the diff output. Here it is:
https://gitlab.com/qemu-project/qemu/-/blob/master/scripts/git.orderfile?ref_type=heads
We should add that to the tips and tricks part of
docs/devel/submitting-a-patch.rst
> +uint8_t ext_state[PCA955X_PIN_COUNT_MAX];
State is 0 or 1
Re: [RFC PATCH 10/11] ppc/spapr: change pseries machine default to POWER10 CPU
On Tue, 10 Oct 2023 at 18:25, Nicholas Piggin wrote:
>
> POWER10 is the latest pseries CPU.
>
> Signed-off-by: Nicholas Piggin
Reviewed-by: Joel Stanley
> ---
> hw/ppc/spapr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index d4230d3647..9d3475d64b 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -4661,7 +4661,7 @@ static void spapr_machine_class_init(ObjectClass *oc,
> void *data)
>
> smc->dr_lmb_enabled = true;
> smc->update_dt_enabled = true;
> -mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("power9_v2.2");
> +mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("power10_v2.0");
> mc->has_hotpluggable_cpus = true;
> mc->nvdimm_supported = true;
> smc->resize_hpt_default = SPAPR_RESIZE_HPT_ENABLED;
> --
> 2.42.0
>
>
Re: [RFC PATCH 11/11] ppc/pnv: Change powernv default to powernv10
On Tue, 10 Oct 2023 at 18:24, Nicholas Piggin wrote:
>
> POWER10 is the latest IBM Power machine. Although it is not offered in
> "OPAL mode" (i.e., powernv configuration), so there is a case that it
> should remain at powernv9, most of the development work is going into
> powernv10 at the moment.
>
> Signed-off-by: Nicholas Piggin
Reviewed-by: Joel Stanley
Do we need to update the docs?
We should consider updating the skiboot to the latest release too.
> ---
> hw/ppc/pnv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index eb54f93986..f3dad5ae05 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -2195,8 +2195,6 @@ static void pnv_machine_power9_class_init(ObjectClass
> *oc, void *data)
>
> xfc->match_nvt = pnv_match_nvt;
>
> -mc->alias = "powernv";
> -
> pmc->compat = compat;
> pmc->compat_size = sizeof(compat);
> pmc->dt_power_mgt = pnv_dt_power_mgt;
> @@ -2220,6 +2218,8 @@ static void pnv_machine_power10_class_init(ObjectClass
> *oc, void *data)
> mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("power10_v2.0");
> compat_props_add(mc->compat_props, phb_compat, G_N_ELEMENTS(phb_compat));
>
> +mc->alias = "powernv";
> +
> pmc->compat = compat;
> pmc->compat_size = sizeof(compat);
> pmc->dt_power_mgt = pnv_dt_power_mgt;
> --
> 2.42.0
>
>
Re: [RFC PATCH 05/11] testing/avocado: ppc add new BookE boot_linux_console.py tests
On Tue, 10 Oct 2023 at 18:23, Nicholas Piggin wrote:
>
> Add simple Linux kernel boot tests for BookE 64-bit and 32-bit CPUs
> using Guenter Roeck's rootfs images for Linux testing, and a gitlab
> repository with kernel images that I built since there are very few
> sources of modern BookE images now.
>
> Signed-off-by: Nicholas Piggin
Reviewed-by: Joel Stanley
Should we get mpe to add a https://github.com/linuxppc/qemu-ci-images
for you to keep those kernel images? But perhaps you'd prefer to keep
them on gitlab. Just a suggestion.
> ---
> tests/avocado/boot_linux_console.py | 53 +
> 1 file changed, 53 insertions(+)
>
> diff --git a/tests/avocado/boot_linux_console.py
> b/tests/avocado/boot_linux_console.py
> index 9434304cd3..dc3346ef49 100644
> --- a/tests/avocado/boot_linux_console.py
> +++ b/tests/avocado/boot_linux_console.py
> @@ -1355,6 +1355,59 @@ def test_ppc64_e500(self):
> tar_hash = '6951d86d644b302898da2fd701739c9406527fe1'
> self.do_test_advcal_2018('19', tar_hash, 'uImage')
>
> +def test_ppc64_e6500(self):
> +"""
> +:avocado: tags=arch:ppc64
> +:avocado: tags=machine:ppce500
> +:avocado: tags=cpu:e6500
> +:avocado: tags=accel:tcg
> +"""
> +kernel_url =
> ('https://gitlab.com/npiggin/qemu-ci-images/-/raw/main/ppc/corenet64_vmlinux?ref_type=heads&inline=false')
Is the ref_type?heads=inline-false required? I seem to get the file
successfully with wget and those omitted.
> +kernel_hash = '01051590b083fec66cb3b9e2e553e95d4cf47691'
> +kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
> +
> +initrd_url =
> ('https://github.com/groeck/linux-build-test/raw/master/rootfs/ppc64/rootfs.cpio.gz')
> +initrd_hash = '798acffc036c3b1ae6cacf95c869bba2'
> +initrd_path = self.fetch_asset(initrd_url, asset_hash=initrd_hash,
> + algorithm="md5")
> +
> +self.vm.set_console()
> +kernel_command_line = self.KERNEL_COMMON_COMMAND_LINE
> +self.vm.add_args('-smp', '2',
> + '-kernel', kernel_path,
> + '-initrd', initrd_path,
> + '-append', kernel_command_line,
> + '-no-reboot')
> +self.vm.launch()
> +# Wait for VM to shut down gracefully
> +self.vm.wait()
> +
> +def test_ppc32_mpc85xx(self):
> +"""
> +:avocado: tags=arch:ppc
> +:avocado: tags=machine:ppce500
> +:avocado: tags=cpu:mpc8568
> +:avocado: tags=accel:tcg
> +"""
> +kernel_url =
> ('https://gitlab.com/npiggin/qemu-ci-images/-/raw/main/ppc/mpc85xx_vmlinux?ref_type=heads&inline=false')
> +kernel_hash = '726f7f574a491282454850b48546b3827593142b'
> +kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
> +
> +initrd_url =
> ('https://github.com/groeck/linux-build-test/raw/master/rootfs/ppc/rootfs.cpio.gz')
> +initrd_hash = '4d30fa93b742c493e8cf2140e49bbd9a'
> +initrd_path = self.fetch_asset(initrd_url, asset_hash=initrd_hash,
> + algorithm="md5")
> +
> +self.vm.set_console()
> +kernel_command_line = self.KERNEL_COMMON_COMMAND_LINE
> +self.vm.add_args('-kernel', kernel_path,
> + '-initrd', initrd_path,
> + '-append', kernel_command_line,
> + '-no-reboot')
> +self.vm.launch()
> +# Wait for VM to shut down gracefully
> +self.vm.wait()
> +
> def do_test_ppc64_powernv(self, proc):
> self.require_accelerator("tcg")
> images_url =
> ('https://github.com/open-power/op-build/releases/download/v2.7/')
> --
> 2.42.0
>
>
Re: [PATCH 1/4] aspeed/i2c: Clean up local variable shadowing
On Fri, 22 Sept 2023 at 15:59, Cédric Le Goater wrote:
>
> Remove superfluous local 'data' variable and use the one define at the
> top of the routine. This fixes :
>
> ../hw/i2c/aspeed_i2c.c: In function ‘aspeed_i2c_bus_recv’:
> ../hw/i2c/aspeed_i2c.c:315:17: warning: declaration of ‘data’ shadows a
> previous local [-Wshadow=compatible-local]
> 315 | uint8_t data;
> | ^~~~
> ../hw/i2c/aspeed_i2c.c:288:13: note: shadowed declaration is here
> 288 | uint8_t data;
> | ^~~~
>
> Signed-off-by: Cédric Le Goater
Reviewed-by: Joel Stanley
messy.
> ---
> hw/i2c/aspeed_i2c.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/hw/i2c/aspeed_i2c.c b/hw/i2c/aspeed_i2c.c
> index 7275d40749a9..1037c22b2f79 100644
> --- a/hw/i2c/aspeed_i2c.c
> +++ b/hw/i2c/aspeed_i2c.c
> @@ -312,7 +312,6 @@ static void aspeed_i2c_bus_recv(AspeedI2CBus *bus)
> SHARED_ARRAY_FIELD_DP32(bus->regs, reg_pool_ctrl, RX_COUNT, i &
> 0xff);
> SHARED_ARRAY_FIELD_DP32(bus->regs, reg_cmd, RX_BUFF_EN, 0);
> } else if (SHARED_ARRAY_FIELD_EX32(bus->regs, reg_cmd, RX_DMA_EN)) {
> -uint8_t data;
> /* In new mode, clear how many bytes we RXed */
> if (aspeed_i2c_is_new_mode(bus->controller)) {
> ARRAY_FIELD_DP32(bus->regs, I2CM_DMA_LEN_STS, RX_LEN, 0);
> --
> 2.41.0
>
Re: [Qemu-devel] [PATCH 08/19] aspeed/timer: Fix behaviour running Linux
On Fri, 22 Sept 2023 at 13:21, Cédric Le Goater wrote: > > +t->start = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL); > > +return calculate_time(t, MAX(MAX(t->match[0], t->match[1]), 0)); > > This MAX(MAX(x, y), 0) looks strange to me. Would you remember where it comes > from ? Thanks, That looks very strange. I think you've sorted it, so I wanted to bring up the MAX macros themselves. It's unfortunate that they create a non-unique local variable. Are we allowed to borrow the kernels macros? They have some infrastructure for creating a unique local variable name, as well as handling the const and non-const variants with the one macro. https://elixir.bootlin.com/linux/v6.5/source/include/linux/minmax.h Cheers, Joel
Re: [PATCH v3.2 5/7] aspeed: Create flash devices only when defaults are enabled
On Thu, 31 Aug 2023 at 21:13, Cédric Le Goater wrote:
>
> When the -nodefaults option is set, flash devices should be created
> with :
>
> -blockdev node-name=fmc0,driver=file,filename=./flash.img \
> -device mx66u51235f,cs=0x0,bus=ssi.0,drive=fmc0 \
>
> To be noted that in this case, the ROM will not be installed and the
> initial boot sequence (U-Boot loading) will fetch instructions using
> SPI transactions which is significantly slower. That's exactly how HW
> operates though.
>
> Signed-off-by: Cédric Le Goater
Reviewed-by: Joel Stanley
A good addition. Thanks!
> ---
> docs/system/arm/aspeed.rst | 35 +--
> hw/arm/aspeed.c| 6 --
> 2 files changed, 33 insertions(+), 8 deletions(-)
>
> diff --git a/docs/system/arm/aspeed.rst b/docs/system/arm/aspeed.rst
> index 80538422a1a4..b2dea54eedad 100644
> --- a/docs/system/arm/aspeed.rst
> +++ b/docs/system/arm/aspeed.rst
> @@ -104,7 +104,7 @@ To boot a kernel directly from a Linux build tree:
> -dtb arch/arm/boot/dts/aspeed-ast2600-evb.dtb \
> -initrd rootfs.cpio
>
> -The image should be attached as an MTD drive. Run :
> +To boot the machine from the flash image, use an MTD drive :
>
> .. code-block:: bash
>
> @@ -117,23 +117,46 @@ Options specific to Aspeed machines are :
> device by using the FMC controller to load the instructions, and
> not simply from RAM. This takes a little longer.
>
> - * ``fmc-model`` to change the FMC Flash model. FW needs support for
> - the chip model to boot.
> + * ``fmc-model`` to change the default FMC Flash model. FW needs
> + support for the chip model to boot.
>
> - * ``spi-model`` to change the SPI Flash model.
> + * ``spi-model`` to change the default SPI Flash model.
>
>* ``bmc-console`` to change the default console device. Most of the
> machines use the ``UART5`` device for a boot console, which is
> mapped on ``/dev/ttyS4`` under Linux, but it is not always the
> case.
>
> -For instance, to start the ``ast2500-evb`` machine with a different
> -FMC chip and a bigger (64M) SPI chip, use :
> +To use other flash models, for instance a different FMC chip and a
> +bigger (64M) SPI for the ``ast2500-evb`` machine, run :
>
> .. code-block:: bash
>
> -M ast2500-evb,fmc-model=mx25l25635e,spi-model=mx66u51235f
>
> +When more flexibility is needed to define the flash devices, to use
> +different flash models or define all flash devices (up to 8), the
> +``-nodefaults`` QEMU option can be used to avoid creating the default
> +flash devices.
> +
> +Flash devices should then be created from the command line and attached
> +to a block device :
> +
> +.. code-block:: bash
> +
> + $ qemu-system-arm -M ast2600-evb \
> +-blockdev node-name=fmc0,driver=file,filename=/path/to/fmc0.img \
> + -device mx66u51235f,bus=ssi.0,cs=0x0,drive=fmc0 \
> + -blockdev node-name=fmc1,driver=file,filename=/path/to/fmc1.img \
> + -device mx66u51235f,bus=ssi.0,cs=0x1,drive=fmc1 \
> + -blockdev node-name=spi1,driver=file,filename=/path/to/spi1.img \
> + -device mx66u51235f,cs=0x0,bus=ssi.1,drive=spi1 \
> + -nographic -nodefaults
> +
> +In that case, the machine boots fetching instructions from the FMC0
> +device. It is slower to start but closer to what HW does. Using the
> +machine option ``execute-in-place`` has a similar effect.
> +
> To change the boot console and use device ``UART3`` (``/dev/ttyS2``
> under Linux), use :
>
> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
> index cd92cf9ce0bb..271512ce5ced 100644
> --- a/hw/arm/aspeed.c
> +++ b/hw/arm/aspeed.c
> @@ -396,12 +396,14 @@ static void aspeed_machine_init(MachineState *machine)
> connect_serial_hds_to_uarts(bmc);
> qdev_realize(DEVICE(&bmc->soc), NULL, &error_abort);
>
> -aspeed_board_init_flashes(&bmc->soc.fmc,
> +if (defaults_enabled()) {
> +aspeed_board_init_flashes(&bmc->soc.fmc,
> bmc->fmc_model ? bmc->fmc_model :
> amc->fmc_model,
> amc->num_cs, 0);
> -aspeed_board_init_flashes(&bmc->soc.spi[0],
> +aspeed_board_init_flashes(&bmc->soc.spi[0],
> bmc->spi_model ? bmc->spi_model :
> amc->spi_model,
> 1, amc->num_cs);
> +}
>
> if (machine->kernel_filename && sc->num_cpus > 1) {
> /* With no u-boot we must set up a boot stub for the secondary CPU
> */
> --
> 2.41.0
>
>
Re: [PATCH v3 5/7] aspeed: Create flash devices only when defaults are enabled
On Thu, 31 Aug 2023 at 13:22, Cédric Le Goater wrote:
>
> On 8/31/23 15:00, Joel Stanley wrote:
> > On Thu, 31 Aug 2023 at 12:39, Cédric Le Goater wrote:
> >>
> >> When the -nodefaults option is set, flash devices should be created
> >> with :
> >>
> >> -blockdev node-name=fmc0,driver=file,filename=./flash.img \
> >> -device mx66u51235f,cs=0x0,bus=ssi.0,drive=fmc0 \
> >>
> >> To be noted that in this case, the ROM will not be installed and the
> >> initial boot sequence (U-Boot loading) will fetch instructions using
> >> SPI transactions which is significantly slower. That's exactly how HW
> >> operates though.
> >>
> >> Signed-off-by: Cédric Le Goater
> >
> > I think this is the first foray for the aspeed machines into
> > nodefaults removing things that previously would have just worked.
>
> This is true. It is change from the previous behavior.
>
> QEMU should probably complain if no fmc0 are found to boot from.
> Would that be ok ? And yes, documentation needs some update.
I didn't consider warning. That would help users who blindly added
-nodefaults and wondered why nothing was happening.
This is what happens if you add -nodefaults to an "old" command line
with your patch applied:
$ ./build/qemu-system-arm -M rainier-bmc -nographic -nodefaults
-serial stdio -drive
file=obmc-phosphor-image-rainier.static.mtd,if=mtd,format=raw
qemu-system-arm: -drive
file=obmc-phosphor-image-rainier.static.mtd,if=mtd,format=raw: machine
type does not support if=mtd,bus=0,unit=0
Which at least isn't sitting there spinning, as I was worried. I'll
leave it to you as to whether it needs a helpful message.
Cheers,
Joel
>
> Thanks,
>
> C.
>
> > I
> > know we haven't had it in our recommended command lines for a long
> > time, so that's fine.
> >
> > Reviewed-by: Joel Stanley
> >
> > Should the content of your commit message go in the docs?
> >
> >> ---
> >> hw/arm/aspeed.c | 6 --
> >> 1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
> >> index cd92cf9ce0bb..271512ce5ced 100644
> >> --- a/hw/arm/aspeed.c
> >> +++ b/hw/arm/aspeed.c
> >> @@ -396,12 +396,14 @@ static void aspeed_machine_init(MachineState
> >> *machine)
> >> connect_serial_hds_to_uarts(bmc);
> >> qdev_realize(DEVICE(&bmc->soc), NULL, &error_abort);
> >>
> >> -aspeed_board_init_flashes(&bmc->soc.fmc,
> >> +if (defaults_enabled()) {
> >> +aspeed_board_init_flashes(&bmc->soc.fmc,
> >> bmc->fmc_model ? bmc->fmc_model :
> >> amc->fmc_model,
> >> amc->num_cs, 0);
> >> -aspeed_board_init_flashes(&bmc->soc.spi[0],
> >> +aspeed_board_init_flashes(&bmc->soc.spi[0],
> >> bmc->spi_model ? bmc->spi_model :
> >> amc->spi_model,
> >> 1, amc->num_cs);
> >> +}
> >>
> >> if (machine->kernel_filename && sc->num_cpus > 1) {
> >> /* With no u-boot we must set up a boot stub for the secondary
> >> CPU */
> >> --
> >> 2.41.0
> >>
>
Re: [PATCH v3 5/7] aspeed: Create flash devices only when defaults are enabled
On Thu, 31 Aug 2023 at 12:39, Cédric Le Goater wrote:
>
> When the -nodefaults option is set, flash devices should be created
> with :
>
> -blockdev node-name=fmc0,driver=file,filename=./flash.img \
> -device mx66u51235f,cs=0x0,bus=ssi.0,drive=fmc0 \
>
> To be noted that in this case, the ROM will not be installed and the
> initial boot sequence (U-Boot loading) will fetch instructions using
> SPI transactions which is significantly slower. That's exactly how HW
> operates though.
>
> Signed-off-by: Cédric Le Goater
I think this is the first foray for the aspeed machines into
nodefaults removing things that previously would have just worked. I
know we haven't had it in our recommended command lines for a long
time, so that's fine.
Reviewed-by: Joel Stanley
Should the content of your commit message go in the docs?
> ---
> hw/arm/aspeed.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
> index cd92cf9ce0bb..271512ce5ced 100644
> --- a/hw/arm/aspeed.c
> +++ b/hw/arm/aspeed.c
> @@ -396,12 +396,14 @@ static void aspeed_machine_init(MachineState *machine)
> connect_serial_hds_to_uarts(bmc);
> qdev_realize(DEVICE(&bmc->soc), NULL, &error_abort);
>
> -aspeed_board_init_flashes(&bmc->soc.fmc,
> +if (defaults_enabled()) {
> +aspeed_board_init_flashes(&bmc->soc.fmc,
>bmc->fmc_model ? bmc->fmc_model :
> amc->fmc_model,
>amc->num_cs, 0);
> -aspeed_board_init_flashes(&bmc->soc.spi[0],
> +aspeed_board_init_flashes(&bmc->soc.spi[0],
>bmc->spi_model ? bmc->spi_model :
> amc->spi_model,
>1, amc->num_cs);
> +}
>
> if (machine->kernel_filename && sc->num_cpus > 1) {
> /* With no u-boot we must set up a boot stub for the secondary CPU */
> --
> 2.41.0
>
Re: [PATCH for-8.2 2/3] pnv/lpc: Hook up xscom region for P9/P10
On Tue, 29 Aug 2023 at 14:45, Cédric Le Goater wrote: > > On 8/9/23 16:56, Frederic Barrat wrote: > > Hello Joel, > > > > So we're re-using the same xscom ops as on P8. A quick look at the > > definition of those 4 registers on P8 (0xb0020) and on P9/P10 (0x00090040) > > seem to show they are not the same though. Am i missing something? > > Joel, are we ok ? Should we grab this patch ? or not. Sorry, I chatted to Fred about this one but forgot to reply on the list. I made a bad assumption about the xscom registers matching between p8 and p9/10. This patch will need to be reworked, so please ignore it. Cheers, Joel
Re: [PATCH] tests/avocado/machine_aspeed.py: Update SDK images
On Mon, 28 Aug 2023 at 09:01, Cédric Le Goater wrote:
>
> Switch to the latest v8.06 release which introduces interesting
> changes for the AST2600 I2C and I3C models. Also take the AST2600 A2
> images instead of the default since QEMU tries to model The AST2600 A3
> SoC.
Is there any value in testing both the old and the new images?
Reviewed-by: Joel Stanley
>
> Signed-off-by: Cédric Le Goater
> ---
>
> Requires patches from Hang Yu [1]
>
> [1]
> https://lore.kernel.org/qemu-devel/20230812065230.8839-1-francis_...@stu.pku.edu.cn/
>
>
> tests/avocado/machine_aspeed.py | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/tests/avocado/machine_aspeed.py b/tests/avocado/machine_aspeed.py
> index 724ee72c0208..90f1b7cb77a1 100644
> --- a/tests/avocado/machine_aspeed.py
> +++ b/tests/avocado/machine_aspeed.py
> @@ -316,8 +316,8 @@ def test_arm_ast2500_evb_sdk(self):
> """
>
> image_url = ('https://github.com/AspeedTech-BMC/openbmc/releases/'
> - 'download/v08.01/ast2500-default-obmc.tar.gz')
> -image_hash =
> ('5375f82b4c43a79427909342a1e18b4e48bd663e38466862145d27bb358796fd')
> + 'download/v08.06/ast2500-default-obmc.tar.gz')
> +image_hash =
> ('e1755f3cadff69190438c688d52dd0f0d399b70a1e14b1d3d5540fc4851d38ca')
> image_path = self.fetch_asset(image_url, asset_hash=image_hash,
>algorithm='sha256')
> archive.extract(image_path, self.workdir)
> @@ -334,8 +334,8 @@ def test_arm_ast2600_evb_sdk(self):
> """
>
> image_url = ('https://github.com/AspeedTech-BMC/openbmc/releases/'
> - 'download/v08.01/ast2600-default-obmc.tar.gz')
> -image_hash =
> ('f12ef15e8c1f03a214df3b91c814515c5e2b2f56119021398c1dbdd626817d15')
> + 'download/v08.06/ast2600-a2-obmc.tar.gz')
> +image_hash =
> ('9083506135f622d5e7351fcf7d4e1c7125cee5ba16141220c0ba88931f3681a4')
> image_path = self.fetch_asset(image_url, asset_hash=image_hash,
>algorithm='sha256')
> archive.extract(image_path, self.workdir)
> @@ -345,8 +345,8 @@ def test_arm_ast2600_evb_sdk(self):
> self.vm.add_args('-device',
> 'ds1338,bus=aspeed.i2c.bus.5,address=0x32');
> self.do_test_arm_aspeed_sdk_start(
> -self.workdir + '/ast2600-default/image-bmc')
> -self.wait_for_console_pattern('nodistro.0 ast2600-default ttyS4')
> +self.workdir + '/ast2600-a2/image-bmc')
> +self.wait_for_console_pattern('nodistro.0 ast2600-a2 ttyS4')
>
> self.ssh_connect('root', '0penBmc', False)
> self.ssh_command('dmesg -c > /dev/null')
> --
> 2.41.0
>
Re: [PATCH v1 5/7] hw/fsi: IBM's On-chip Peripheral Bus
On Fri, 25 Aug 2023 at 20:35, Ninad Palsule wrote:
>
> This is a part of patchset where IBM's Flexible Service Interface is
> introduced.
>
> The On-Chip Peripheral Bus (OPB): A low-speed bus typically found in
> POWER processors. This now makes an appearance in the ASPEED SoC due
> to tight integration of the FSI master IP with the OPB, mainly the
> existence of an MMIO-mapping of the CFAM address straight onto a
> sub-region of the OPB address space.
>
> Signed-off-by: Andrew Jeffery
> Signed-off-by: Cédric Le Goater
> Signed-off-by: Ninad Palsule
Reviewed-by: Joel Stanley
> ---
> hw/fsi/Kconfig | 4 +
> hw/fsi/fsi-master.c | 3 +-
> hw/fsi/meson.build | 1 +
> hw/fsi/opb.c | 194 +++
> include/hw/fsi/opb.h | 45 ++
> 5 files changed, 245 insertions(+), 2 deletions(-)
> create mode 100644 hw/fsi/opb.c
> create mode 100644 include/hw/fsi/opb.h
>
> diff --git a/hw/fsi/Kconfig b/hw/fsi/Kconfig
> index 087980be22..560ce536db 100644
> --- a/hw/fsi/Kconfig
> +++ b/hw/fsi/Kconfig
> @@ -1,3 +1,7 @@
> +config OPB
> +bool
> +select CFAM
> +
> config CFAM
> bool
> select FSI
> diff --git a/hw/fsi/fsi-master.c b/hw/fsi/fsi-master.c
> index fe1693539a..ba00e2bb7d 100644
> --- a/hw/fsi/fsi-master.c
> +++ b/hw/fsi/fsi-master.c
> @@ -13,8 +13,7 @@
>
> #include "hw/fsi/bits.h"
> #include "hw/fsi/fsi-master.h"
> -
> -#define TYPE_OP_BUS "opb"
> +#include "hw/fsi/opb.h"
>
> #define TO_REG(x) ((x) >> 2)
>
> diff --git a/hw/fsi/meson.build b/hw/fsi/meson.build
> index ca80d11cb9..cab645f4ea 100644
> --- a/hw/fsi/meson.build
> +++ b/hw/fsi/meson.build
> @@ -2,3 +2,4 @@ system_ss.add(when: 'CONFIG_LBUS', if_true: files('lbus.c'))
> system_ss.add(when: 'CONFIG_SCRATCHPAD', if_true:
> files('engine-scratchpad.c'))
> system_ss.add(when: 'CONFIG_CFAM', if_true: files('cfam.c'))
> system_ss.add(when: 'CONFIG_FSI', if_true:
> files('fsi.c','fsi-master.c','fsi-slave.c'))
> +system_ss.add(when: 'CONFIG_OPB', if_true: files('opb.c'))
> diff --git a/hw/fsi/opb.c b/hw/fsi/opb.c
> new file mode 100644
> index 00..ac7693c001
> --- /dev/null
> +++ b/hw/fsi/opb.c
> @@ -0,0 +1,194 @@
> +/*
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + * Copyright (C) 2023 IBM Corp.
> + *
> + * IBM On-chip Peripheral Bus
> + */
> +
> +#include "qemu/osdep.h"
> +
> +#include "qapi/error.h"
> +#include "qemu/log.h"
> +
> +#include "hw/fsi/opb.h"
> +
> +static MemTxResult opb_read(OPBus *opb, hwaddr addr, void *data, size_t len)
> +{
> +return address_space_read(&opb->as, addr, MEMTXATTRS_UNSPECIFIED, data,
> + len);
> +}
> +
> +uint8_t opb_read8(OPBus *opb, hwaddr addr)
> +{
> +MemTxResult tx;
> +uint8_t data;
> +
> +tx = opb_read(opb, addr, &data, sizeof(data));
> +/* FIXME: improve error handling */
> +assert(!tx);
> +
> +return data;
> +}
> +
> +uint16_t opb_read16(OPBus *opb, hwaddr addr)
> +{
> +MemTxResult tx;
> +uint16_t data;
> +
> +tx = opb_read(opb, addr, &data, sizeof(data));
> +/* FIXME: improve error handling */
> +assert(!tx);
> +
> +return data;
> +}
> +
> +uint32_t opb_read32(OPBus *opb, hwaddr addr)
> +{
> +MemTxResult tx;
> +uint32_t data;
> +
> +tx = opb_read(opb, addr, &data, sizeof(data));
> +/* FIXME: improve error handling */
> +assert(!tx);
> +
> +return data;
> +}
> +
> +static MemTxResult opb_write(OPBus *opb, hwaddr addr, void *data, size_t len)
> +{
> +return address_space_write(&opb->as, addr, MEMTXATTRS_UNSPECIFIED, data,
> + len);
> +}
> +
> +void opb_write8(OPBus *opb, hwaddr addr, uint8_t data)
> +{
> +MemTxResult tx;
> +
> +tx = opb_write(opb, addr, &data, sizeof(data));
> +/* FIXME: improve error handling */
> +assert(!tx);
> +}
> +
> +void opb_write16(OPBus *opb, hwaddr addr, uint16_t data)
> +{
> +MemTxResult tx;
> +
> +tx = opb_write(opb, addr, &data, sizeof(data));
> +/* FIXME: improve error handling */
> +assert(!tx);
> +}
> +
> +void opb_write32(OPBus *opb, hwaddr addr, uint32_t data)
> +{
> +MemTxResult tx;
> +
> +tx = opb_write(opb, addr, &data, sizeof(data));
> +/* FIXME: improve error handling
Re: [PATCH v1 4/7] hw/fsi: Introduce IBM's FSI
On Fri, 25 Aug 2023 at 20:44, Ninad Palsule wrote: > > This is a part of patchset where IBM's Flexible Service Interface is > introduced. > > This commit models the FSI bus. CFAM is hanging out of FSI bus. The bus > is model such a way that it is embeded inside the FSI master which is a > bus controller. > > The FSI master: A controller in the platform service processor (e.g. > BMC) driving CFAM engine accesses into the POWER chip. At the > hardware level FSI is a bit-based protocol supporting synchronous and > DMA-driven accesses of engines in a CFAM. > > Signed-off-by: Andrew Jeffery > Signed-off-by: Cédric Le Goater > Signed-off-by: Ninad Palsule Reviewed-by: Joel Stanley > --- > hw/fsi/cfam.c | 1 + > hw/fsi/fsi-master.c | 203 > hw/fsi/fsi.c| 54 ++ > hw/fsi/meson.build | 2 +- > include/hw/fsi/cfam.h | 2 - > include/hw/fsi/fsi-master.h | 30 ++ > include/hw/fsi/fsi.h| 35 +++ > 7 files changed, 324 insertions(+), 3 deletions(-) > create mode 100644 hw/fsi/fsi-master.c > create mode 100644 hw/fsi/fsi.c > create mode 100644 include/hw/fsi/fsi-master.h > create mode 100644 include/hw/fsi/fsi.h > > diff --git a/hw/fsi/cfam.c b/hw/fsi/cfam.c > index 19256050bd..12ce31cac4 100644 > --- a/hw/fsi/cfam.c > +++ b/hw/fsi/cfam.c > @@ -12,6 +12,7 @@ > > #include "hw/fsi/bits.h" > #include "hw/fsi/cfam.h" > +#include "hw/fsi/fsi.h" > #include "hw/fsi/engine-scratchpad.h" > > #include "hw/qdev-properties.h" > diff --git a/hw/fsi/fsi-master.c b/hw/fsi/fsi-master.c > new file mode 100644 > index 00..fe1693539a > --- /dev/null > +++ b/hw/fsi/fsi-master.c > @@ -0,0 +1,203 @@ > +/* > + * SPDX-License-Identifier: GPL-2.0-or-later > + * Copyright (C) 2023 IBM Corp. > + * > + * IBM Flexible Service Interface master > + */ > + > +#include "qemu/osdep.h" > + > +#include "qapi/error.h" > + > +#include "qemu/log.h" > + > +#include "hw/fsi/bits.h" > +#include "hw/fsi/fsi-master.h" > + > +#define TYPE_OP_BUS "opb" > + > +#define TO_REG(x) ((x) >> 2) > + > +#define FSI_MMODE TO_REG(0x000) > +#define FSI_MMODE_IPOLL_DMA_ENBE_BIT(0) > +#define FSI_MMODE_HW_ERROR_RECOVERY_ENBE_BIT(1) > +#define FSI_MMODE_RELATIVE_ADDRESS_EN BE_BIT(2) > +#define FSI_MMODE_PARITY_CHECK_EN BE_BIT(3) > +#define FSI_MMODE_CLOCK_DIVIDER_0 BE_GENMASK(4, 13) > +#define FSI_MMODE_CLOCK_DIVIDER_1 BE_GENMASK(14, 23) > +#define FSI_MMODE_DEBUG_ENBE_BIT(24) > + > +#define FSI_MDELAY TO_REG(0x004) > +#define FSI_MDELAY_ECHO_0 BE_GENMASK(0, 3) > +#define FSI_MDELAY_SEND_0 BE_GENMASK(4, 7) > +#define FSI_MDELAY_ECHO_1 BE_GENMASK(8, 11) > +#define FSI_MDELAY_SEND_1 BE_GENMASK(12, 15) > + > +#define FSI_MENP0 TO_REG(0x010) > +#define FSI_MENP32 TO_REG(0x014) > +#define FSI_MSENP0 TO_REG(0x018) > +#define FSI_MLEVP0 TO_REG(0x018) > +#define FSI_MSENP32 TO_REG(0x01c) > +#define FSI_MLEVP32 TO_REG(0x01c) > +#define FSI_MCENP0 TO_REG(0x020) > +#define FSI_MREFP0 TO_REG(0x020) > +#define FSI_MCENP32 TO_REG(0x024) > +#define FSI_MREFP32 TO_REG(0x024) > + > +#define FSI_MAEBTO_REG(0x070) > +#define FSI_MAEB_ANY_CPU_ERRORBE_BIT(0) > +#define FSI_MAEB_ANY_DMA_ERRORBE_GENMASK(1, 16) > +#define FSI_MAEB_ANY_PARITY_ERROR BE_BIT(17) > + > +#define FSI_MVERTO_REG(0x074) > +#define FSI_MVER_VERSION BE_GENMASK(0, 7) > +#define FSI_MVER_BRIDGES BE_GENMASK(8, 15) > +#define FSI_MVER_PORTSBE_GENMASK(16, 23) > + > +#define FSI_MRESP0 TO_REG(0x0d0) > +#define FSI_MRESP0_RESET_PORT_GENERAL BE_BIT(0) > +#define FSI_MRESP0_RESET_PORT_ERROR BE_BIT(1) > +#define FSI_MRESP0_RESET_ALL_BRIDGES_GENERAL BE_BIT(2) > +#define FSI_MRESP0_RESET_ALL_PORTS_GENERALBE_BIT(3) > +#define FSI_MRESP0_RESET_MASTER
Re: [PATCH v1 6/7] hw/fsi: Aspeed APB2OPB interface
On Fri, 25 Aug 2023 at 20:31, Ninad Palsule wrote: > > This is a part of patchset where IBM's Flexible Service Interface is > introduced. > > An APB-to-OPB bridge enabling access to the OPB from the ARM core in > the AST2600. Hardware limitations prevent the OPB from being directly > mapped into APB, so all accesses are indirect through the bridge. > > Signed-off-by: Andrew Jeffery > Signed-off-by: Cédric Le Goater > Signed-off-by: Ninad Palsule > --- > hw/arm/Kconfig | 1 + > hw/fsi/Kconfig | 4 + > hw/fsi/aspeed-apb2opb.c | 346 > hw/fsi/meson.build | 1 + > hw/fsi/trace-events | 2 + > hw/fsi/trace.h | 1 + > include/hw/fsi/aspeed-apb2opb.h | 32 +++ > meson.build | 1 + > 8 files changed, 388 insertions(+) > create mode 100644 hw/fsi/aspeed-apb2opb.c > create mode 100644 hw/fsi/trace-events > create mode 100644 hw/fsi/trace.h > create mode 100644 include/hw/fsi/aspeed-apb2opb.h > > diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig > index 7e68348440..a6994cd9d7 100644 > --- a/hw/arm/Kconfig > +++ b/hw/arm/Kconfig > @@ -589,6 +589,7 @@ config FSL_IMX7 > select PCI_EXPRESS_DESIGNWARE > select SDHCI > select UNIMP > +select APB2OPB_ASPEED > > config ARM_SMMUV3 > bool > diff --git a/hw/fsi/Kconfig b/hw/fsi/Kconfig > index 560ce536db..fbb021658d 100644 > --- a/hw/fsi/Kconfig > +++ b/hw/fsi/Kconfig > @@ -1,3 +1,7 @@ > +config APB2OPB_ASPEED > +bool > +select OPB > + > config OPB > bool > select CFAM > diff --git a/hw/fsi/aspeed-apb2opb.c b/hw/fsi/aspeed-apb2opb.c > new file mode 100644 > index 00..bbc63f2eb3 > --- /dev/null > +++ b/hw/fsi/aspeed-apb2opb.c > @@ -0,0 +1,346 @@ > +/* > + * SPDX-License-Identifier: GPL-2.0-or-later > + * Copyright (C) 2023 IBM Corp. > + * > + * ASPEED APB-OPB FSI interface > + */ > + > +#include "qemu/osdep.h" > +#include "qemu/log.h" > +#include "qom/object.h" > +#include "qapi/error.h" > +#include "trace.h" > + > +#include "hw/fsi/aspeed-apb2opb.h" > +#include "hw/qdev-core.h" > + > +#define TO_REG(x) (x >> 2) > +#define GENMASK(t, b) (((1ULL << ((t) + 1)) - 1) & ~((1ULL << (b)) - 1)) We should put this in a common header. > + > +#define APB2OPB_VERSIONTO_REG(0x00) > +#define APB2OPB_VERSION_VER GENMASK(7, 0) > + > +#define APB2OPB_TRIGGERTO_REG(0x04) > +#define APB2OPB_TRIGGER_EN BIT(0) > + > +#define APB2OPB_CONTROLTO_REG(0x08) > +#define APB2OPB_CONTROL_OFF GENMASK(31, 13) > + > +#define APB2OPB_OPB2FSITO_REG(0x0c) > +#define APB2OPB_OPB2FSI_OFF GENMASK(31, 22) > + > +#define APB2OPB_OPB0_SEL TO_REG(0x10) > +#define APB2OPB_OPB1_SEL TO_REG(0x28) > +#define APB2OPB_OPB_SEL_EN BIT(0) > + > +#define APB2OPB_OPB0_MODE TO_REG(0x14) > +#define APB2OPB_OPB1_MODE TO_REG(0x2c) > +#define APB2OPB_OPB_MODE_RD BIT(0) > + > +#define APB2OPB_OPB0_XFER TO_REG(0x18) > +#define APB2OPB_OPB1_XFER TO_REG(0x30) > +#define APB2OPB_OPB_XFER_FULLBIT(1) > +#define APB2OPB_OPB_XFER_HALFBIT(0) > + > +#define APB2OPB_OPB0_ADDR TO_REG(0x1c) > +#define APB2OPB_OPB0_WRITE_DATATO_REG(0x20) > + > +#define APB2OPB_OPB1_DMA_ENTO_REG(0x24) > +#define APB2OPB_OPB1_DMA_EN_3 BIT(3) > +#define APB2OPB_OPB1_DMA_EN_2 BIT(2) > +#define APB2OPB_OPB1_DMA_EN_1 BIT(1) > +#define APB2OPB_OPB1_DMA_EN_0 BIT(0) > + > +#define APB2OPB_OPB1_ADDR TO_REG(0x34) > +#define APB2OPB_OPB1_WRITE_DATA TO_REG(0x38) > + > +#define APB2OPB_OPB_CLKTO_REG(0x3c) > +#define APB2OPB_OPB_CLK_SYNC BIT(0) > + > +#define APB2OPB_IRQ_CLEAR TO_REG(0x40) > +#define APB2OPB_IRQ_CLEAR_EN BIT(0) > + > +#define APB2OPB_IRQ_MASK TO_REG(0x44) > +#define APB2OPB_IRQ_MASK_OPB1_TX_ACK BIT(17) > +#define APB2OPB_IRQ_MASK_OPB0_TX_ACK BIT(16) > +#define APB2OPB_IRQ_MASK_CH3_TCONT BIT(15) > +#define APB2OPB_IRQ_MASK_CH2_TCONT BIT(14) > +#define APB2OPB_IRQ_MASK_CH1_TCONT BIT(13) > +#define APB2OPB_IRQ_MASK_CH0_TCONT BIT(12) > +#define APB2OPB_IRQ_MASK_CH3_FIFO_EMPTY BIT(11) > +#define APB2OPB_IRQ_MASK_CH2_FIFO_EMPTY BIT(10) > +#define APB2OPB_IRQ_MASK_CH1_FIFO_EMPTY BIT(9) > +#define APB2OPB_IRQ_MASK_CH0_FIFO_EMPTY BIT(8) > +#define APB2OPB_IRQ_MASK_CH3_FIFO_FULL BIT(7) > +#define APB2OPB_IRQ_MASK_CH2_FIFO_FULL BIT(6) > +#define APB2OPB_IRQ_MASK_CH1_FIFO_FULL BIT(5) > +#define APB2OPB_IRQ_MASK_CH0_FIFO_FULL BIT(4) > +#define APB2OPB_IRQ_MASK_CH3_DMA_EOT BIT(3) > +#define
Re: [PATCH v1 7/7] hw/arm: Hook up FSI module in AST2600
On Fri, 25 Aug 2023 at 20:35, Ninad Palsule wrote: > > This patchset introduces IBM's Flexible Service Interface(FSI). > > Time for some fun with inter-processor buses. FSI allows a service > processor access to the internal buses of a host POWER processor to > perform configuration or debugging. > > FSI has long existed in POWER processes and so comes with some baggage, > including how it has been integrated into the ASPEED SoC. > > Working backwards from the POWER processor, the fundamental pieces of > interest for the implementation are: > > 1. The Common FRU Access Macro (CFAM), an address space containing >various "engines" that drive accesses on buses internal and external >to the POWER chip. Examples include the SBEFIFO and I2C masters. The >engines hang off of an internal Local Bus (LBUS) which is described >by the CFAM configuration block. > > 2. The FSI slave: The slave is the terminal point of the FSI bus for >FSI symbols addressed to it. Slaves can be cascaded off of one >another. The slave's configuration registers appear in address space >of the CFAM to which it is attached. > > 3. The FSI master: A controller in the platform service processor (e.g. >BMC) driving CFAM engine accesses into the POWER chip. At the >hardware level FSI is a bit-based protocol supporting synchronous and >DMA-driven accesses of engines in a CFAM. > > 4. The On-Chip Peripheral Bus (OPB): A low-speed bus typically found in >POWER processors. This now makes an appearance in the ASPEED SoC due >to tight integration of the FSI master IP with the OPB, mainly the >existence of an MMIO-mapping of the CFAM address straight onto a >sub-region of the OPB address space. > > 5. An APB-to-OPB bridge enabling access to the OPB from the ARM core in >the AST2600. Hardware limitations prevent the OPB from being directly >mapped into APB, so all accesses are indirect through the bridge. > > The implementation appears as following in the qemu device tree: > > (qemu) info qtree > bus: main-system-bus > type System > ... > dev: aspeed.apb2opb, id "" > gpio-out "sysbus-irq" 1 > mmio 1e79b000/1000 > bus: opb.1 > type opb > dev: fsi.master, id "" > bus: fsi.bus.1 > type fsi.bus > dev: cfam.config, id "" > dev: cfam, id "" > bus: lbus.1 > type lbus > dev: scratchpad, id "" > address = 0 (0x0) > bus: opb.0 > type opb > dev: fsi.master, id "" > bus: fsi.bus.0 > type fsi.bus > dev: cfam.config, id "" > dev: cfam, id "" > bus: lbus.0 > type lbus > dev: scratchpad, id "" > address = 0 (0x0) > > The LBUS is modelled to maintain the qdev bus hierarchy and to take > advantage of the object model to automatically generate the CFAM > configuration block. The configuration block presents engines in the > order they are attached to the CFAM's LBUS. Engine implementations > should subclass the LBusDevice and set the 'config' member of > LBusDeviceClass to match the engine's type. > > CFAM designs offer a lot of flexibility, for instance it is possible for > a CFAM to be simultaneously driven from multiple FSI links. The modeling > is not so complete; it's assumed that each CFAM is attached to a single > FSI slave (as a consequence the CFAM subclasses the FSI slave). > > As for FSI, its symbols and wire-protocol are not modelled at all. This > is not necessary to get FSI off the ground thanks to the mapping of the > CFAM address space onto the OPB address space - the models follow this > directly and map the CFAM memory region into the OPB's memory region. > Future work includes supporting more advanced accesses that drive the > FSI master directly rather than indirectly via the CFAM mapping, which > will require implementing the FSI state machine and methods for each of > the FSI symbols on the slave. Further down the track we can also look at > supporting the bitbanged SoftFSI drivers in Linux by extending the FSI > slave model to resolve sequences of GPIO IRQs into FSI symbols, and > calling the associated symbol method on the slave to map the access onto > the CFAM. > > Testing: > Tested by reading cfam config address 0 on rainier machine. We can > ignore the error line as it is not related. > root@p10bmc:~# pdbg -a getcfam 0x0 > Unable to open dtb file '/var/lib/phosphor-software-manager/pnor/rw/DEVTREE' Delete this line (and the explanation). It's something to follow up with the version of pdbg that openbmc has, but unrelated to this patch. > p0: 0x0 = 0xc0022d15 > > Signed-off-by: Andrew Jeffery > Signed-off-by: Cédric Le Goater > Signed-off-by: Ninad Palsule > --- > hw/arm/aspeed_ast2600.c | 15 +++
Re: [PATCH v1 1/7] hw/fsi: Introduce IBM's Local bus
On Fri, 25 Aug 2023 at 20:31, Ninad Palsule wrote:
>
> This is a part of patchset where IBM's Flexible Service Interface is
> introduced.
>
> The LBUS is modelled to maintain the qdev bus hierarchy and to take
> advantage of the object model to automatically generate the CFAM
> configuration block. The configuration block presents engines in the
> order they are attached to the CFAM's LBUS. Engine implementations
> should subclass the LBusDevice and set the 'config' member of
> LBusDeviceClass to match the engine's type.
>
> Signed-off-by: Andrew Jeffery
> Signed-off-by: Cédric Le Goater
> Signed-off-by: Ninad Palsule
> ---
> hw/Kconfig| 1 +
> hw/fsi/Kconfig| 2 +
> hw/fsi/lbus.c | 94 +++
> hw/fsi/meson.build| 1 +
> hw/meson.build| 1 +
> include/hw/fsi/bits.h | 15 +++
> include/hw/fsi/lbus.h | 57 ++
> 7 files changed, 171 insertions(+)
> create mode 100644 hw/fsi/Kconfig
> create mode 100644 hw/fsi/lbus.c
> create mode 100644 hw/fsi/meson.build
> create mode 100644 include/hw/fsi/bits.h
> create mode 100644 include/hw/fsi/lbus.h
>
> diff --git a/hw/Kconfig b/hw/Kconfig
> index ba62ff6417..2ccb73add5 100644
> --- a/hw/Kconfig
> +++ b/hw/Kconfig
> @@ -9,6 +9,7 @@ source core/Kconfig
> source cxl/Kconfig
> source display/Kconfig
> source dma/Kconfig
> +source fsi/Kconfig
> source gpio/Kconfig
> source hyperv/Kconfig
> source i2c/Kconfig
> diff --git a/hw/fsi/Kconfig b/hw/fsi/Kconfig
> new file mode 100644
> index 00..687449e14e
> --- /dev/null
> +++ b/hw/fsi/Kconfig
> @@ -0,0 +1,2 @@
> +config LBUS
> +bool
> diff --git a/hw/fsi/lbus.c b/hw/fsi/lbus.c
> new file mode 100644
> index 00..afb26ef7ea
> --- /dev/null
> +++ b/hw/fsi/lbus.c
> @@ -0,0 +1,94 @@
> +/*
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + * Copyright (C) 2023 IBM Corp.
> + *
> + * IBM Local bus where FSI slaves are connected
> + */
> +
> +#include "qemu/osdep.h"
> +
> +#include "qapi/error.h"
> +#include "qemu/log.h"
> +
> +#include "hw/fsi/lbus.h"
> +
> +#include "hw/qdev-properties.h"
> +
> +static void lbus_realize(BusState *bus, Error **errp)
> +{
> +LBusNode *node;
> +LBus *lbus = LBUS(bus);
> +
> +memory_region_init(&lbus->mr, OBJECT(lbus), TYPE_LBUS,
> + (2 * 1024 * 1024) - 0x400);
> +
> +QLIST_FOREACH(node, &lbus->devices, next) {
> +memory_region_add_subregion(&lbus->mr, node->ldev->address,
> +&node->ldev->iomem);
> +}
> +}
> +
> +static void lbus_init(Object *o)
> +{
> +}
> +
> +static void lbus_class_init(ObjectClass *klass, void *data)
> +{
> +BusClass *k = BUS_CLASS(klass);
> +k->realize = lbus_realize;
> +}
> +
> +static const TypeInfo lbus_info = {
> +.name = TYPE_LBUS,
> +.parent = TYPE_BUS,
> +.instance_init = lbus_init,
> +.instance_size = sizeof(LBus),
> +.class_init = lbus_class_init,
> +};
> +
> +static Property lbus_device_props[] = {
> +DEFINE_PROP_UINT32("address", LBusDevice, address, 0),
> +DEFINE_PROP_END_OF_LIST(),
> +};
> +
> +DeviceState *lbus_create_device(LBus *bus, const char *type, uint32_t addr)
> +{
> +DeviceState *dev;
> +LBusNode *node;
> +
> +dev = qdev_new(type);
> +qdev_prop_set_uint8(dev, "address", addr);
> +qdev_realize_and_unref(dev, &bus->bus, &error_fatal);
> +
> +/* Move to post_load */
> +node = g_malloc(sizeof(struct LBusNode));
> +node->ldev = LBUS_DEVICE(dev);
> +QLIST_INSERT_HEAD(&bus->devices, node, next);
> +
> +return dev;
> +}
> +
> +static void lbus_device_class_init(ObjectClass *klass, void *data)
> +{
> +DeviceClass *dc = DEVICE_CLASS(klass);
> +
> +dc->bus_type = TYPE_LBUS;
> +device_class_set_props(dc, lbus_device_props);
> +}
> +
> +static const TypeInfo lbus_device_type_info = {
> +.name = TYPE_LBUS_DEVICE,
> +.parent = TYPE_DEVICE,
> +.instance_size = sizeof(LBusDevice),
> +.abstract = true,
> +.class_init = lbus_device_class_init,
> +.class_size = sizeof(LBusDeviceClass),
> +};
> +
> +static void lbus_register_types(void)
> +{
> +type_register_static(&lbus_info);
> +type_register_static(&lbus_device_type_info);
> +}
> +
> +type_init(lbus_register_types);
> diff --git a/hw/fsi/meson.build b/hw/fsi/meson.build
> new file mode 100644
> index 00..e1007d5fea
> --- /dev/null
> +++ b/hw/fsi/meson.build
> @@ -0,0 +1 @@
> +system_ss.add(when: 'CONFIG_LBUS', if_true: files('lbus.c'))
> diff --git a/hw/meson.build b/hw/meson.build
> index c7ac7d3d75..6c71ee9cfa 100644
> --- a/hw/meson.build
> +++ b/hw/meson.build
> @@ -43,6 +43,7 @@ subdir('virtio')
> subdir('watchdog')
> subdir('xen')
> subdir('xenpv')
> +subdir('fsi')
>
> subdir('alpha')
> subdir('arm')
> diff --git a/include/hw/fsi/bits.h b/include/hw/fsi/bits.h
> new file mode 100644
> index 00..338ae483cf
> --- /dev/null
> +++ b/include/hw/fsi/bits.h
> @@
Re: [PATCH v1 0/7] Introduce model for IBM's FSP
Hi Ninad, On Fri, 25 Aug 2023 at 20:51, Ninad Palsule wrote: > > Hello, > > Please review the patch-set. > > This is a first step towards introducing model for IBM's Flexible > Service Interface. The full functionality will be implemented over the > time. You have a typo in the subject, I think you meant to write FSI instead of FSP.
[PATCH for-8.2 3/3] HACK: pnv/lpc: Set up XSCOM dt for P9
To test qemu's model of the xscom interface, apply this patch to qemu and the following change to skiboot: --- a/hw/lpc.c +++ b/hw/lpc.c @@ -1266,7 +1266,7 @@ static void lpc_init_chip_p9(struct dt_node *opb_node) lpc = zalloc(sizeof(struct lpcm)); assert(lpc); lpc->chip_id = gcid; - lpc->mbase = (void *)addr; + lpc->xbase = dt_get_address(lpc_node, 0, NULL); lpc->fw_idsel = 0xff; lpc->fw_rdsz = 0xff; lpc->node = lpc_node; Signed-off-by: Joel Stanley --- hw/ppc/pnv_lpc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/hw/ppc/pnv_lpc.c b/hw/ppc/pnv_lpc.c index 6c6a3134087f..62ab688407a3 100644 --- a/hw/ppc/pnv_lpc.c +++ b/hw/ppc/pnv_lpc.c @@ -218,6 +218,11 @@ int pnv_dt_lpc(PnvChip *chip, void *fdt, int root_offset, uint64_t lpcm_addr, offset = fdt_add_subnode(fdt, lpcm_offset, name); _FDT(offset); g_free(name); +uint32_t lpc_pcba = PNV9_XSCOM_LPC_BASE; +reg[0] = cpu_to_be32(lpc_pcba); +reg[1] = cpu_to_be32(PNV_XSCOM_LPC_SIZE); + +_FDT((fdt_setprop(fdt, offset, "reg", reg, sizeof(reg; _FDT((fdt_setprop_cell(fdt, offset, "#address-cells", 2))); _FDT((fdt_setprop_cell(fdt, offset, "#size-cells", 1))); _FDT((fdt_setprop(fdt, offset, "compatible", lpc_compat, -- 2.40.1
[PATCH for-8.2 1/3] pnv/lpc: Place mmio regs in their own memory region
The P9 and P10 models re-used the xscom_regs memory region for the mmio
access, which is confusing.
Add a separate memory region in preparation for enabling both xscom and
mmio access.
Signed-off-by: Joel Stanley
---
include/hw/ppc/pnv_lpc.h | 3 ++-
hw/ppc/pnv.c | 4 ++--
hw/ppc/pnv_lpc.c | 2 +-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/hw/ppc/pnv_lpc.h b/include/hw/ppc/pnv_lpc.h
index 5d22c4557041..3000964f8999 100644
--- a/include/hw/ppc/pnv_lpc.h
+++ b/include/hw/ppc/pnv_lpc.h
@@ -81,8 +81,9 @@ struct PnvLpcController {
uint32_t lpc_hc_irqstat;
uint32_t lpc_hc_error_addr;
-/* XSCOM registers */
+/* Registers */
MemoryRegion xscom_regs;
+MemoryRegion mmio_regs;
/* PSI to generate interrupts */
qemu_irq psi_irq;
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index eb54f93986df..afdaa25c2b26 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1565,7 +1565,7 @@ static void pnv_chip_power9_realize(DeviceState *dev,
Error **errp)
return;
}
memory_region_add_subregion(get_system_memory(), PNV9_LPCM_BASE(chip),
-&chip9->lpc.xscom_regs);
+&chip9->lpc.mmio_regs);
chip->fw_mr = &chip9->lpc.isa_fw;
chip->dt_isa_nodename = g_strdup_printf("/lpcm-opb@%" PRIx64 "/lpc@0",
@@ -1784,7 +1784,7 @@ static void pnv_chip_power10_realize(DeviceState *dev,
Error **errp)
return;
}
memory_region_add_subregion(get_system_memory(), PNV10_LPCM_BASE(chip),
-&chip10->lpc.xscom_regs);
+&chip10->lpc.mmio_regs);
chip->fw_mr = &chip10->lpc.isa_fw;
chip->dt_isa_nodename = g_strdup_printf("/lpcm-opb@%" PRIx64 "/lpc@0",
diff --git a/hw/ppc/pnv_lpc.c b/hw/ppc/pnv_lpc.c
index d692858bee78..caf5e10a5f96 100644
--- a/hw/ppc/pnv_lpc.c
+++ b/hw/ppc/pnv_lpc.c
@@ -664,7 +664,7 @@ static void pnv_lpc_power9_realize(DeviceState *dev, Error
**errp)
}
/* P9 uses a MMIO region */
-memory_region_init_io(&lpc->xscom_regs, OBJECT(lpc), &pnv_lpc_mmio_ops,
+memory_region_init_io(&lpc->mmio_regs, OBJECT(lpc), &pnv_lpc_mmio_ops,
lpc, "lpcm", PNV9_LPCM_SIZE);
}
--
2.40.1
[PATCH for-8.2 2/3] pnv/lpc: Hook up xscom region for P9/P10
>From P9 on the LPC bus is memory mapped. However the xscom access still
is possible, so add it too.
Signed-off-by: Joel Stanley
---
include/hw/ppc/pnv_xscom.h | 6 ++
hw/ppc/pnv.c | 4
hw/ppc/pnv_lpc.c | 6 ++
3 files changed, 16 insertions(+)
diff --git a/include/hw/ppc/pnv_xscom.h b/include/hw/ppc/pnv_xscom.h
index 9bc64635471e..42601bdf419d 100644
--- a/include/hw/ppc/pnv_xscom.h
+++ b/include/hw/ppc/pnv_xscom.h
@@ -96,6 +96,9 @@ struct PnvXScomInterfaceClass {
#define PNV9_XSCOM_SBE_CTRL_BASE 0x00050008
#define PNV9_XSCOM_SBE_CTRL_SIZE 0x1
+#define PNV9_XSCOM_LPC_BASE 0x00090040
+#define PNV9_XSCOM_LPC_SIZE PNV_XSCOM_LPC_SIZE
+
#define PNV9_XSCOM_SBE_MBOX_BASE 0x000D0050
#define PNV9_XSCOM_SBE_MBOX_SIZE 0x16
@@ -155,6 +158,9 @@ struct PnvXScomInterfaceClass {
#define PNV10_XSCOM_SBE_CTRL_BASE PNV9_XSCOM_SBE_CTRL_BASE
#define PNV10_XSCOM_SBE_CTRL_SIZE PNV9_XSCOM_SBE_CTRL_SIZE
+#define PNV10_XSCOM_LPC_BASE PNV9_XSCOM_LPC_BASE
+#define PNV10_XSCOM_LPC_SIZE PNV9_XSCOM_LPC_SIZE
+
#define PNV10_XSCOM_SBE_MBOX_BASE PNV9_XSCOM_SBE_MBOX_BASE
#define PNV10_XSCOM_SBE_MBOX_SIZE PNV9_XSCOM_SBE_MBOX_SIZE
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index afdaa25c2b26..a5db655b41b6 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1566,6 +1566,8 @@ static void pnv_chip_power9_realize(DeviceState *dev,
Error **errp)
}
memory_region_add_subregion(get_system_memory(), PNV9_LPCM_BASE(chip),
&chip9->lpc.mmio_regs);
+pnv_xscom_add_subregion(chip, PNV9_XSCOM_LPC_BASE,
+&chip9->lpc.xscom_regs);
chip->fw_mr = &chip9->lpc.isa_fw;
chip->dt_isa_nodename = g_strdup_printf("/lpcm-opb@%" PRIx64 "/lpc@0",
@@ -1785,6 +1787,8 @@ static void pnv_chip_power10_realize(DeviceState *dev,
Error **errp)
}
memory_region_add_subregion(get_system_memory(), PNV10_LPCM_BASE(chip),
&chip10->lpc.mmio_regs);
+pnv_xscom_add_subregion(chip, PNV10_XSCOM_LPC_BASE,
+&chip10->lpc.xscom_regs);
chip->fw_mr = &chip10->lpc.isa_fw;
chip->dt_isa_nodename = g_strdup_printf("/lpcm-opb@%" PRIx64 "/lpc@0",
diff --git a/hw/ppc/pnv_lpc.c b/hw/ppc/pnv_lpc.c
index caf5e10a5f96..6c6a3134087f 100644
--- a/hw/ppc/pnv_lpc.c
+++ b/hw/ppc/pnv_lpc.c
@@ -666,6 +666,12 @@ static void pnv_lpc_power9_realize(DeviceState *dev, Error
**errp)
/* P9 uses a MMIO region */
memory_region_init_io(&lpc->mmio_regs, OBJECT(lpc), &pnv_lpc_mmio_ops,
lpc, "lpcm", PNV9_LPCM_SIZE);
+
+/* but the XSCOM region still exists */
+pnv_xscom_region_init(&lpc->xscom_regs, OBJECT(lpc),
+ &pnv_lpc_xscom_ops, lpc, "xscom-lpc",
+ PNV_XSCOM_LPC_SIZE);
+
}
static void pnv_lpc_power9_class_init(ObjectClass *klass, void *data)
--
2.40.1
[PATCH for-8.2 0/3] pnv/lpc: Hook up xscoms for LPC
P8 used xscoms for accessing the LPC bus. In P9 the LPC bus was memory mapped, simplifying access, however the xscom registers remained. Some firmwares use this method on P9 and P10, so wire it up in qemu. The third patch is a hack that shows how to test this access method with skiboot. It should not be applied. Joel Stanley (3): pnv/lpc: Place mmio regs in their own memory region pnv/lpc: Hook up xscom region for P9/P10 HACK: pnv/lpc: Set up XSCOM dt for P9 include/hw/ppc/pnv_lpc.h | 3 ++- include/hw/ppc/pnv_xscom.h | 6 ++ hw/ppc/pnv.c | 8 ++-- hw/ppc/pnv_lpc.c | 13 - 4 files changed, 26 insertions(+), 4 deletions(-) -- 2.40.1
[PATCH] configure: Fix linux-user host detection for ppc64le
Revert the changes in the recent "Fix linux-user host detection for
riscv64" patch as it broke ppc64le. Instead add riscv to the switch
statement that performs normalisation of the host cpu name.
Fixes: 89e5b7935e92 ("configure: Fix linux-user host detection for riscv64")
Signed-off-by: Joel Stanley
---
Tested on a ppc64le host. Please check it works on riscv too.
---
configure | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/configure b/configure
index 98dc78280e67..fd0efa69bc36 100755
--- a/configure
+++ b/configure
@@ -469,13 +469,6 @@ else
echo "WARNING: unrecognized host CPU, proceeding with 'uname -m' output
'$cpu'"
fi
-case "$cpu" in
- riscv*)
-host_arch=riscv ;;
- *)
-host_arch="$cpu" ;;
-esac
-
# Normalise host CPU name and set multilib cflags. The canonicalization
# isn't really necessary, because the architectures that we check for
# should not hit the 'uname -m' case, but better safe than sorry.
@@ -508,6 +501,9 @@ case "$cpu" in
cpu="ppc64"
CPU_CFLAGS="-m64 -mlittle-endian" ;;
+ riscv*)
+cpu="riscv" ;;
+
s390)
CPU_CFLAGS="-m31" ;;
s390x)
@@ -810,7 +806,7 @@ default_target_list=""
mak_wilds=""
if [ "$linux_user" != no ]; then
-if [ "$targetos" = linux ] && [ -d
"$source_path/linux-user/include/host/$host_arch" ]; then
+if [ "$targetos" = linux ] && [ -d
"$source_path/linux-user/include/host/$cpu" ]; then
linux_user=yes
elif [ "$linux_user" = yes ]; then
error_exit "linux-user not supported on this architecture"
--
2.40.1
Re: [PATCH] configure: Fix linux-user host detection for riscv64
On Sat, 5 Aug 2023 at 18:02, Richard Henderson
wrote:
>
> Mirror the host_arch variable from meson.build, so that we
> probe for the correct linux-user/include/host/ directory.
This broke all of the linux-user targets for me on a ppc64le host.
None show up when running configure --help, and trying to select one
with --target-list errors out:
ERROR: Unknown target name 'aarch64-linux-user'
Reverting this patch restores the old behaviour.
This test is the one that fails with the patch applied:
if [ "$linux_user" != no ]; then
if [ "$targetos" = linux ] && [ -d
"$source_path/linux-user/include/host/$host_arch" ]; then
linux_user=yes
WIth your patch $host_arch is ppc64le. Previously the line was:
if [ "$linux_user" != no ]; then
if [ "$targetos" = linux ] && [ -d
"$source_path/linux-user/include/host/$cpu" ]; then
linux_user=yes
The directory needs to be /linux-user/include/host/ppc64 for even for ppc64le.
You've put the new test just above the switch statement that does
normalisation of the host CPU name. Could add riscv to that switch
statement instead of adding the host_arch variable?
@@ -508,6 +501,9 @@ case "$cpu" in
cpu="ppc64"
CPU_CFLAGS="-m64 -mlittle-endian" ;;
+ riscv*)
+cpu="riscv" ;;
+
s390)
CPU_CFLAGS="-m31" ;;
s390x)
Cheers,
Joel
>
> Fixes: e3e477c3bca0 ("configure: Fix cross-building for RISCV host")
> Signed-off-by: Richard Henderson
> ---
> configure | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index afb25fd558..98dc78280e 100755
> --- a/configure
> +++ b/configure
> @@ -469,6 +469,13 @@ else
>echo "WARNING: unrecognized host CPU, proceeding with 'uname -m' output
> '$cpu'"
> fi
>
> +case "$cpu" in
> + riscv*)
> +host_arch=riscv ;;
> + *)
> +host_arch="$cpu" ;;
> +esac
> +
> # Normalise host CPU name and set multilib cflags. The canonicalization
> # isn't really necessary, because the architectures that we check for
> # should not hit the 'uname -m' case, but better safe than sorry.
> @@ -803,7 +810,7 @@ default_target_list=""
> mak_wilds=""
>
> if [ "$linux_user" != no ]; then
> -if [ "$targetos" = linux ] && [ -d
> "$source_path/linux-user/include/host/$cpu" ]; then
> +if [ "$targetos" = linux ] && [ -d
> "$source_path/linux-user/include/host/$host_arch" ]; then
> linux_user=yes
> elif [ "$linux_user" = yes ]; then
> error_exit "linux-user not supported on this architecture"
> --
> 2.34.1
>
>
Re: [PATCH v7 00/14] linux-user: brk fixes
On Thu, 3 Aug 2023 at 13:55, Helge Deller wrote: > > 143551 brk(NULL) = 0x0009b000 > > 143551 brk(0x0009b8fc) = 0x0009b000 > > I think the problem is the brk with 9b000 here. > It's not 64k aligned (=pages size of your ppc64le). > > Please try with this patch on top of Richard's series: > > > @@ -3229,7 +3208,8 @@ static void load_elf_image(const char *image_name, > > int image_fd, > > info->end_code = 0; > > info->start_data = -1; > > info->end_data = 0; > > -info->brk = . > change that to become: > info->brk = HOST_PAGE_ALIGN(hiaddr); That stopped the crashing, and the binaries seem to run fine. I tested on two hosts: ppc64le (64K) and arm64 (16K). Cheers, Joel
Re: [PATCH v7 00/14] linux-user: brk fixes
Hi Richard, On Thu, 3 Aug 2023 at 01:53, Richard Henderson wrote: > > Builds on Helge's v6, incorporating my feedback plus > some other minor cleanup. This succeeds for the armhf static binary on ppc64le host that was previously segfaulting. However, the arm static binary on ppc64le host now segfaults: $ gdb -q -ex r --args ./build/qemu-arm -d guest_errors,page,strace ~/hello Reading symbols from ./build/qemu-arm... Starting program: /scratch/joel/qemu/build/qemu-arm -d guest_errors,page,strace /home/joel/hello [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1". [New Thread 0x7762ece0 (LWP 143553)] host mmap_min_addr=0x1 pgb_find_hole: base @ 14042 for 4294967296 bytes pgb_static: base @ 14042 for 4294967295 bytes pgb_reserved_va: base @ 0x14042 for 4294967296 bytes Locating guest address space @ 0x14042 page layout changed following mmap startend size prot 0001-0009 0008 --- 0009-0009b000 b000 --- - 0001 r-x page layout changed following mmap startend size prot 0001-0009 0008 r-x 0009-0009b000 b000 --- - 0001 r-x page layout changed following mmap startend size prot 0001-0009 0008 r-x 0009-000a 0001 rw- - 0001 r-x page layout changed following mmap startend size prot 0001-0009 0008 r-x 0009-000a 0001 rw- 4000-4081 0081 rw- - 0001 r-x page layout changed following mmap startend size prot 0001-0009 0008 r-x 0009-000a 0001 rw- 4000-4001 0001 --- 4001-40811000 00801000 rw- - 0001 r-x guest_base 0x14042 page layout changed following binary load startend size prot 0001-0009 0008 r-x 0009-000a 0001 rw- 4000-4001 0001 --- 4001-4081 0080 rw- 4081-40811000 1000 r-x - 0001 r-x end_code0x00084f7c start_code 0x0001 start_data 0x00095098 end_data0x00098394 start_stack 0x4080f410 brk 0x0009b000 entry 0x00010418 argv_start 0x4080f414 env_start 0x4080f41c auxv_start 0x4080f4a0 143551 brk(NULL) = 0x0009b000 143551 brk(0x0009b8fc) = 0x0009b000 Thread 1 "qemu-arm" received signal SIGSEGV, Segmentation fault. 0x7fffeed9bb74 in code_gen_buffer () (gdb) bt #0 0x7fffeed9bb74 in code_gen_buffer () #1 0x000100169fdc in cpu_tb_exec (cpu=cpu@entry=0x1003d4a90, itb=itb@entry=0x7fffeed9ba60 , tb_exit=tb_exit@entry=0x7fffe51c) at ../accel/tcg/cpu-exec.c:457 #2 0x00010016a704 in cpu_loop_exec_tb (tb_exit=0x7fffe51c, last_tb=, pc=, tb=0x7fffeed9ba60 , cpu=) at ../accel/tcg/cpu-exec.c:919 #3 cpu_exec_loop (cpu=cpu@entry=0x1003d4a90, sc=) at ../accel/tcg/cpu-exec.c:1040 #4 0x00010016abac in cpu_exec_setjmp (cpu=cpu@entry=0x1003d4a90, sc=) at ../accel/tcg/cpu-exec.c:1057 #5 0x00010016b270 in cpu_exec (cpu=0x1003d4a90) at ../accel/tcg/cpu-exec.c:1083 #6 0x00010004d7b0 in cpu_loop (env=0x1003d4fa0) at ../linux-user/arm/cpu_loop.c:328 #7 0x000100047548 in main (argc=, argv=0x7188, envp=) at ../linux-user/main.c:1012 (gdb) > > > r~ > > > Akihiko Odaki (6): > linux-user: Unset MAP_FIXED_NOREPLACE for host > linux-user: Fix MAP_FIXED_NOREPLACE on old kernels > linux-user: Do not call get_errno() in do_brk() > linux-user: Use MAP_FIXED_NOREPLACE for do_brk() > linux-user: Do nothing if too small brk is specified > linux-user: Do not align brk with host page size > > Helge Deller (1): > linux-user: Adjust initial brk when interpreter is close to executable > > Richard Henderson (7): > linux-user: Remove last_brk > bsd-user: Remove last_brk > linux-user: Adjust task_unmapped_base for reserved_va > linux-user: Define TASK_UNMAPPED_BASE in $guest/target_mman.h > linux-user: Add ELF_ET_DYN_BASE > linux-user: Use elf_et_dyn_base for ET_DYN with interpreter > linux-user: Properly set image_info.brk in flatload > > bsd-user/qemu.h | 1 - > linux-user/aarch64/target_mman.h | 13 > linux-user/alpha/target_mman.h | 11 > linux-user/arm/target_mman.h | 11 > linux-user/cris/target_mman.h| 12 > linux-user/hexagon/target_mman.h | 13 > linux-user/hppa/target_mman.h| 6 ++ > linux-user/i386/target_mman.h| 16 + > linux-user/loongarch64/target_mman.h | 11 > linux-user/m68k/target_mman.h| 5 ++ > linux-user/microblaze/target_mman.h | 11 > linux-user/mips/target_mman.h| 10 +++ > linux-user/nios2/target_mman.h | 10 +++ > linux-user/openrisc/target_mman.h| 10 +++ > linux-user/ppc/target_mman.h | 20 ++ > linux-user/qemu.h| 2 - > linux-user/riscv/target_mman.h
Re: [PATCH v6 0/8] linux-user: brk fixes
On Tue, 1 Aug 2023 at 23:28, Helge Deller wrote: > > This patch series is a fix-up for some current problems > regarding heap memory / brk handling in qemu which happens > on some 32-bit platforms, e.g. problems loading static > binaries. > > This series includes the 5 patches from Akihiko Odaki > with some additional fixes and cleanups by me. This has the same segfault as the branch that I previously tested, when running on a ppc64le host.. As a reminder, the ppc64le machine (normally, and does in this case) uses a 64K page size. I think this is a detail that is missing from your chroot testing. > > Akihiko Odaki (5): > linux-user: Unset MAP_FIXED_NOREPLACE for host > linux-user: Do not call get_errno() in do_brk() > linux-user: Use MAP_FIXED_NOREPLACE for do_brk() > linux-user: Do nothing if too small brk is specified > linux-user: Do not align brk with host page size > > Helge Deller (3): > linux-user: Show heap address in /proc/pid/maps > linux-user: Optimize memory layout for static and dynamic executables > linux-user: Load pie executables at upper memory > > include/exec/cpu_ldst.h | 4 +-- > linux-user/elfload.c| 59 ++ > linux-user/loader.h | 12 +++ > linux-user/main.c | 2 ++ > linux-user/mmap.c | 35 ++ > linux-user/qemu.h | 4 +-- > linux-user/syscall.c| 80 - > 7 files changed, 79 insertions(+), 117 deletions(-) > > -- > 2.41.0 >
Re: [PATCH 0/5] linux-user: brk/mmap fixes
On Mon, 31 Jul 2023 at 18:24, Helge Deller wrote: > > I re-read the thread again. As it seems Joel already tried the latest > > version from me? Sadly I can't test myself on ppc64le (static binary > > needs klibc-PupSAGgtpafMlSLXOLgje1kXFo8.so in /usr/lib which I can't > > install on a debian porterbox). > > > > I still believe we need to track host and target brk page, but I'll give > > your patch a try. > > As suggested, I've based my patches on top of yours and the tree can be > pulled from: > git pull https://github.com/hdeller/qemu-hppa/ brk-fixes-akihiko-2 > > My patches are neccessary to fix an arm-static testcase: > /usr/bin/qemu-arm-static ./fstype > > Let's try this patch series... The armhf static binary works with expected output. The arm static binary causes qemu to segfault: $ gdb -quiet --args ./build/qemu-arm -d guest_errors,page,strace ~/hello Reading symbols from ./build/qemu-arm... (gdb) r Starting program: build/qemu-arm -d guest_errors,page,strace /home/joel/hello Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1". [New Thread 0x7762ece0 (LWP 118359)] host mmap_min_addr=0x1 pgb_find_hole: base @ 14042 for 4294967296 bytes pgb_static: base @ 14042 for 4294967295 bytes pgb_reserved_va: base @ 0x14042 for 4294967296 bytes Locating guest address space @ 0x14042 page layout changed following mmap startend size prot 0001-0009 0008 --- 0009-0009b000 b000 --- - 0001 r-x page layout changed following mmap startend size prot 0001-0009 0008 r-x 0009-0009b000 b000 --- - 0001 r-x page layout changed following mmap startend size prot 0001-0009 0008 r-x 0009-000a 0001 rw- - 0001 r-x page layout changed following mmap startend size prot 0001-0009 0008 r-x 0009-000a 0001 rw- e000-e081 0081 rw- - 0001 r-x page layout changed following mmap startend size prot 0001-0009 0008 r-x 0009-000a 0001 rw- e000-e001 0001 --- e001-e0811000 00801000 rw- - 0001 r-x guest_base 0x14042 page layout changed following binary load startend size prot 0001-0009 0008 r-x 0009-000a 0001 rw- e000-e001 0001 --- e001-e081 0080 rw- e081-e0811000 1000 r-x - 0001 r-x start_brk 0x end_code0x00084f7c start_code 0x0001 start_data 0x00095098 end_data0x00098394 start_stack 0xe080f410 brk 0x0009b000 entry 0x00010418 argv_start 0xe080f414 env_start 0xe080f41c auxv_start 0xe080f4a0 118357 brk(NULL) = 0x0009b000 118357 brk(0x0009b8fc) = 0x0009b000 Thread 1 "qemu-arm" received signal SIGSEGV, Segmentation fault. 0x7fffeed9bb74 in code_gen_buffer () (gdb) (gdb) bt #0 0x7fffeed9bb74 in code_gen_buffer () #1 0x000100169e3c in cpu_tb_exec (cpu=cpu@entry=0x1003d4aa0, itb=itb@entry=0x7fffeed9ba60 , tb_exit=tb_exit@entry=0x7fffe50c) at ../accel/tcg/cpu-exec.c:457 #2 0x00010016a564 in cpu_loop_exec_tb (tb_exit=0x7fffe50c, last_tb=, pc=, tb=0x7fffeed9ba60 , cpu=) at ../accel/tcg/cpu-exec.c:919 #3 cpu_exec_loop (cpu=cpu@entry=0x1003d4aa0, sc=) at ../accel/tcg/cpu-exec.c:1040 #4 0x00010016aa0c in cpu_exec_setjmp (cpu=cpu@entry=0x1003d4aa0, sc=) at ../accel/tcg/cpu-exec.c:1057 #5 0x00010016b0d0 in cpu_exec (cpu=0x1003d4aa0) at ../accel/tcg/cpu-exec.c:1083 #6 0x00010004d780 in cpu_loop (env=0x1003d4fb0) at ../linux-user/arm/cpu_loop.c:323 #7 0x000100047534 in main (argc=, argv=0x7178, envp=) at ../linux-user/main.c:975 I tested 74a22a175c4340a01f6f860f72307093e3307681.
Re: [PATCH 0/5] linux-user: brk/mmap fixes
On Mon, 31 Jul 2023 at 09:31, Michael Tokarev wrote:
>
> 31.07.2023 11:03, Akihiko Odaki wrote:
> > linux-user was failing on M2 MacBook Air. Digging into the details, I found
> > several bugs in brk and mmap so here are fixes.
>
> There's another work in this area by Helge Deller, have you seen it?
> ("linux-user: Fix and optimize target memory layout", a v5 already).
Applying this series fixes the qemu-arm running the static armhf
binary on my ppc64le host that I reported here[1].
Tested-by: Joel Stanley
The changes conflict with Helge's patches, so it would be good to work
out which of your changes should be combined with his.
Cheers,
Joel
[1]
https://lore.kernel.org/qemu-devel/CACPK8XeyqcEDyyL3Jw2WYWs_gGdtTCf2=ly04cmgkshsmdj...@mail.gmail.com/
Re: [PATCH v5 0/3] linux-user: Fix and optimize target memory layout
On Fri, 28 Jul 2023 at 18:58, Helge Deller wrote: > > While trying to fix a bug which prevents running a static > armhf binary with linux-user, I noticed a whole bunch of > memory layout issues on various platforms. Most noteably > the free heap space was very limited in the current setup. > A large heap is important for example, if you want to > use qemu-user for building Linux packages where gcc requires > lots of space (e.g. using qemu-user as buildd for debian > packages). > > Those findings led to this patch series, which > - fixes qemu-arm to run static armhf binaries Applying this on top of master and trying to run a simple armhf binary on a ppc64le host fails: qemu$ ./build/qemu-arm -d guest_errors,page,strace ~/hello-armhf host mmap_min_addr=0x1 pgb_find_hole: base @ 1 for 4294967296 bytes pgb_static: base @ 1 for 4294967295 bytes pgb_reserved_va: base @ 0x1 for 4294967296 bytes Locating guest address space @ 0x1 page layout changed following mmap startend size prot 0001-0006 0005 --- 0006-00066000 6000 --- - 0001 r-x page layout changed following mmap startend size prot 0001-0006 0005 r-x 0006-00066000 6000 --- - 0001 r-x page layout changed following mmap startend size prot 0001-0006 0005 r-x 0006-00064000 4000 rw- 00064000-00066000 2000 --- - 0001 r-x page layout changed following mmap startend size prot 0001-0006 0005 r-x 0006-00064000 4000 rw- 00064000-00066000 2000 rw- f300-f381 0081 rw- - 0001 r-x page layout changed following mmap startend size prot 0001-0006 0005 r-x 0006-00064000 4000 rw- 00064000-00066000 2000 rw- f300-f301 0001 --- f301-f3811000 00801000 rw- - 0001 r-x guest_base 0x1 page layout changed following binary load startend size prot 0001-0006 0005 r-x 0006-00064000 4000 rw- 00064000-00066000 2000 rw- f300-f301 0001 --- f301-f381 0080 rw- f381-f3811000 1000 r-x - 0001 r-x start_brk 0x end_code0x0005f9c8 start_code 0x0001 start_data 0x00060414 end_data0x0006327c start_stack 0xf380f420 brk 0x00066000 entry 0x00010341 argv_start 0xf380f424 env_start 0xf380f42c auxv_start 0xf380f4a8 95718 brk(NULL) = 0x00066000 95718 brk(0x00066874) = 0x00066874 95718 set_tid_address(0x66068) = 95718 95718 set_robust_list(0x6606c,12) = -1 errno=38 (Function not implemented) 95718 Unknown syscall 398 95718 ugetrlimit(3,-209652764,328608,404128,401408,1) = 0 95718 readlinkat(AT_FDCWD,"/proc/self/exe",0xf380e390,4096) = 22 95718 getrandom(0x65940,4,1) = 4 95718 brk(NULL) = 0x00066874 95718 brk(0x00087874)page layout changed following mmap startend size prot 0001-0006 0005 r-x 0006-00064000 4000 rw- 00064000-00066000 2000 rw- 0007-0009 0002 rw- f300-f301 0001 --- f301-f381 0080 rw- f381-f3811000 1000 r-x - 0001 r-x = 0x00087874 95718 brk(0x00088000) = 0x00088000 95718 mprotect(0x0006,8192,PROT_READ) = 0 95718 statx(1,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0xf380f078) = 0 95718 write(1,0x66b08,14) = -1 errno=14 (Bad address) 95718 exit_group(0) A working arm binary by comparison: qemu$ ./build/qemu-arm -d guest_errors,page,strace ~/hello host mmap_min_addr=0x1 pgb_find_hole: base @ 1 for 4294967296 bytes pgb_static: base @ 1 for 4294967295 bytes pgb_reserved_va: base @ 0x1 for 4294967296 bytes Locating guest address space @ 0x1 page layout changed following mmap startend size prot 0001-0009 0008 --- 0009-0009b000 b000 --- - 0001 r-x page layout changed following mmap startend size prot 0001-0009 0008 r-x 0009-0009b000 b000 --- - 0001 r-x page layout changed following mmap startend size prot 0001-0009 0008 r-x 0009-000a 0001 rw- - 0001 r-x page layout changed following mmap startend size prot 0001-0009 0008 r-x 0009-000a 0001 rw- f300-f381 0081 rw- - 0001 r-x page layout changed following mmap startend size prot 0001-0009 0008 r-x 0009-000a 0001 rw- f300-f301 0001 --- f301-f3811000 00801000 rw- - 0001 r-x guest_base 0x1 page layout changed following binary load startend size prot 0001-0009 0008 r-x 0009-000a 0001 rw- f300-f301 0001 --- f301-f381 0080 rw- f381-f3811000 1000 r-x - 0001 r-x start_br
Re: [PATCH] gdbstub: Fix client Ctrl-C handling
On Sun, 30 Jul 2023 at 09:43, Nicholas Piggin wrote:
>
> On Wed Jul 26, 2023 at 4:35 PM AEST, Joel Stanley wrote:
> > On Wed, 12 Jul 2023 at 02:12, Nicholas Piggin wrote:
> > >
> > > On Tue Jul 11, 2023 at 9:03 PM AEST, Matheus Tavares Bernardino wrote:
> > > > > Nicholas Piggin wrote:
> > > > >
> > > > > diff --git a/gdbstub/gdbstub.c b/gdbstub/gdbstub.c
> > > > > index 6911b73c07..ce8b42eb15 100644
> > > > > --- a/gdbstub/gdbstub.c
> > > > > +++ b/gdbstub/gdbstub.c
> > > > > @@ -2051,8 +2051,17 @@ void gdb_read_byte(uint8_t ch)
> > > > > return;
> > > > > }
> > > > > if (runstate_is_running()) {
> > > > > -/* when the CPU is running, we cannot do anything except stop
> > > > > - it when receiving a char */
> > > > > +/*
> > > > > + * When the CPU is running, we cannot do anything except stop
> > > > > + * it when receiving a char. This is expected on a Ctrl-C in
> > > > > the
> > > > > + * gdb client. Because we are in all-stop mode, gdb sends a
> > > > > + * 0x03 byte which is not a usual packet, so we handle it
> > > > > specially
> > > > > + * here, but it does expect a stop reply.
> > > > > + */
> > > > > +if (ch != 0x03) {
> > > > > +warn_report("gdbstub: client sent packet while target
> > > > > running\n");
> > > > > +}
> > > > > +gdbserver_state.allow_stop_reply = true;
> > > > > vm_stop(RUN_STATE_PAUSED);
> > > > > } else
> > > > > #endif
> > > >
> > > > Makes sense to me, but shouldn't we send the stop-reply packet only for
> > > > Ctrl+C/0x03?
> > >
> > > Good question.
> > >
> > > I think if we get a character here that's not a 3, we're already in
> > > trouble, and we eat it so even worse. Since we only send a stop packet
> > > back when the vm stops, then if we don't send one now we might never
> > > send it. At least if we send one then the client might have some chance
> > > to get back to a sane state. And this does at least take us back to
> > > behaviour before the stop filtering patch.
> > >
> > > Could go further and only stop the machine if it was a 3, or send a
> > > stop packet even if we were stopped, etc. but all that get further from
> > > a minimal fix.
> >
> > I was taking a look at -rc1 and it looks like this hasn't made it in.
> > Is it something we want to propose including?
> >
> > As a user of qemu I'd vote for it to go in.
>
> I think it should, gdb is hardly usable without it.
I think I hit this issue when debugging u-boot in the aspeed arm
machines. Your patch fixed things:
Tested-by: Joel Stanley
Alex, Philippe, can we get this queued for 8.1?
Cheers,
Joel
Re: [PATCH] gdbstub: Fix client Ctrl-C handling
On Wed, 12 Jul 2023 at 02:12, Nicholas Piggin wrote:
>
> On Tue Jul 11, 2023 at 9:03 PM AEST, Matheus Tavares Bernardino wrote:
> > > Nicholas Piggin wrote:
> > >
> > > diff --git a/gdbstub/gdbstub.c b/gdbstub/gdbstub.c
> > > index 6911b73c07..ce8b42eb15 100644
> > > --- a/gdbstub/gdbstub.c
> > > +++ b/gdbstub/gdbstub.c
> > > @@ -2051,8 +2051,17 @@ void gdb_read_byte(uint8_t ch)
> > > return;
> > > }
> > > if (runstate_is_running()) {
> > > -/* when the CPU is running, we cannot do anything except stop
> > > - it when receiving a char */
> > > +/*
> > > + * When the CPU is running, we cannot do anything except stop
> > > + * it when receiving a char. This is expected on a Ctrl-C in the
> > > + * gdb client. Because we are in all-stop mode, gdb sends a
> > > + * 0x03 byte which is not a usual packet, so we handle it
> > > specially
> > > + * here, but it does expect a stop reply.
> > > + */
> > > +if (ch != 0x03) {
> > > +warn_report("gdbstub: client sent packet while target
> > > running\n");
> > > +}
> > > +gdbserver_state.allow_stop_reply = true;
> > > vm_stop(RUN_STATE_PAUSED);
> > > } else
> > > #endif
> >
> > Makes sense to me, but shouldn't we send the stop-reply packet only for
> > Ctrl+C/0x03?
>
> Good question.
>
> I think if we get a character here that's not a 3, we're already in
> trouble, and we eat it so even worse. Since we only send a stop packet
> back when the vm stops, then if we don't send one now we might never
> send it. At least if we send one then the client might have some chance
> to get back to a sane state. And this does at least take us back to
> behaviour before the stop filtering patch.
>
> Could go further and only stop the machine if it was a 3, or send a
> stop packet even if we were stopped, etc. but all that get further from
> a minimal fix.
I was taking a look at -rc1 and it looks like this hasn't made it in.
Is it something we want to propose including?
As a user of qemu I'd vote for it to go in.
Cheers,
Joel
[PATCH] ppc: Add stub implementation of TRIG SPRs
Linux sets these to control cache flush behaviour on Power9. Supervisor and hypervisor are allowed to write, and reads are noops. Add implementations to avoid noisy messages when booting Linux under the pseries machine with guest_errors enabled. Reviewed-by: Nicholas Piggin Signed-off-by: Joel Stanley --- target/ppc/cpu.h | 2 ++ target/ppc/cpu_init.c | 10 ++ 2 files changed, 12 insertions(+) diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h index 25fac9577aa4..6826702ea658 100644 --- a/target/ppc/cpu.h +++ b/target/ppc/cpu.h @@ -1897,7 +1897,9 @@ void ppc_compat_add_property(Object *obj, const char *name, #define SPR_PSSCR (0x357) #define SPR_440_INV0 (0x370) #define SPR_440_INV1 (0x371) +#define SPR_TRIG1 (0x371) #define SPR_440_INV2 (0x372) +#define SPR_TRIG2 (0x372) #define SPR_440_INV3 (0x373) #define SPR_440_ITV0 (0x374) #define SPR_440_ITV1 (0x375) diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c index 02b7aad9b0e3..3b6ccb5ea4e6 100644 --- a/target/ppc/cpu_init.c +++ b/target/ppc/cpu_init.c @@ -5660,6 +5660,16 @@ static void register_power_common_book4_sprs(CPUPPCState *env) SPR_NOACCESS, SPR_NOACCESS, &spr_read_tfmr, &spr_write_tfmr, 0x); +spr_register_hv(env, SPR_TRIG1, "TRIG1", + SPR_NOACCESS, SPR_NOACCESS, + &spr_access_nop, &spr_write_generic, + &spr_access_nop, &spr_write_generic, + 0x); +spr_register_hv(env, SPR_TRIG2, "TRIG2", + SPR_NOACCESS, SPR_NOACCESS, + &spr_access_nop, &spr_write_generic, + &spr_access_nop, &spr_write_generic, + 0x); #endif } -- 2.40.1
Re: [PATCH v2] ppc/pnv: Add QME region for P10
On Sat, 8 Jul 2023 at 01:17, Nicholas Piggin wrote:
> > --- a/include/hw/ppc/pnv_xscom.h
> > +++ b/include/hw/ppc/pnv_xscom.h
> > @@ -127,6 +127,17 @@ struct PnvXScomInterfaceClass {
> > #define PNV10_XSCOM_EC(proc)\
> > ((0x2 << 16) | ((1 << (3 - (proc))) << 12))
> >
> > +#define PNV10_XSCOM_QME(chiplet) \
> > +(PNV10_XSCOM_EQ(chiplet) | (0xE << 16))
> > +
> > +/*
> > + * Make the region larger by 0x1000 (instead of starting at an offset) so
> > the
> > + * modelled addresses start from 0
> > + */
> > +#define PNV10_XSCOM_QME_BASE(core) \
> > +((uint64_t) PNV10_XSCOM_QME(PNV10_XSCOM_EQ_CHIPLET(core)))
> > +#define PNV10_XSCOM_QME_SIZE(0x8000 + 0x1000)
>
> I couldn't work out this comment.
I was trying to describe why we have the + 0x1000.
Each core sets a bit in the xscom address space, with the first core
setting bit 12, second bit 13, etc. So there's actually no registers
at PNV10_XSCOM_QME_BASE, but so the addressing is easier to follow, I
chose to start the base where we do, and make the region 0x1000
bigger.
That was my understanding at least.
Cheers,
Joel
>
> Thanks,
> Nick
Re: [PATCH v2] ppc/pnv: Add QME region for P10
On Fri, 7 Jul 2023 at 07:30, Cédric Le Goater wrote:
>
> On 7/7/23 09:12, Joel Stanley wrote:
> > The Quad Management Engine (QME) manages power related settings for its
> > quad. The xscom region is separate from the quad xscoms, therefore a new
> > region is added. The xscoms in a QME select a given core by selecting
> > the forth nibble.
> >
> > Implement dummy reads for the stop state history (SSH) and special
> > wakeup (SPWU) registers. This quietens some sxcom errors when skiboot
> > boots on p10.
> >
> > Power9 does not have a QME.
> >
> > Signed-off-by: Joel Stanley
>
> Nice, how about these now :
>
>
> [ 24.482066616,3] Could not set special wakeup on 0:0: operation timeout.
> [ 25.022003091,3] Could not set special wakeup on 0:0: operation timeout.
> [ 25.073902795,3] Could not set special wakeup on 0:0: operation timeout.
>
> [ 1593.383133413,3] Could not set special wakeup on 0:0: timeout waiting for
> SPECIAL_WKUP_DONE.
> [ 1593.435173594,3] Could not set special wakeup on 0:0: timeout waiting for
> SPECIAL_WKUP_DONE.
Yes, something like below, except hard coding is not sufficient. We
need to pass the core state into the quad model so the qme callbacks
can keep track of the wakeup state.
From: Joel Stanley
Date: Fri, 7 Jul 2023 13:37:17 +0930
Subject: [PATCH] ppc/pnv: Implement more sleep related registers
We need to get the core object into the quad callback so we can update
the sleep state.
Signed-off-by: Joel Stanley
---
hw/ppc/pnv_core.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
index 09eb2bf94b9e..359b341c748f 100644
--- a/hw/ppc/pnv_core.c
+++ b/hw/ppc/pnv_core.c
@@ -179,6 +179,7 @@ static const MemoryRegionOps pnv_core_power9_xscom_ops = {
*/
#define PNV10_XSCOM_EC_CORE_THREAD_STATE0x412
+#define PNV10_XSCOM_EC_RAS_STATUS 0x454
static uint64_t pnv_core_power10_xscom_read(void *opaque, hwaddr addr,
unsigned int width)
@@ -190,6 +191,9 @@ static uint64_t pnv_core_power10_xscom_read(void
*opaque, hwaddr addr,
case PNV10_XSCOM_EC_CORE_THREAD_STATE:
val = 0;
break;
+case PNV10_XSCOM_EC_RAS_STATUS:
+val = -1;
+break;
default:
qemu_log_mask(LOG_UNIMP, "%s: unimp read 0x%08x\n", __func__,
offset);
@@ -494,7 +498,12 @@ static const MemoryRegionOps pnv_quad_power10_xscom_ops = {
};
#define P10_QME_SPWU_HYP 0x83c
+#define P10_SPWU_REQ PPC_BIT(0)
+#define P10_SPWU_DONE PPC_BIT(4)
+
#define P10_QME_SSH_HYP 0x82c
+#define P10_SSH_CORE_GATED PPC_BIT(0)
+#define P10_SSH_SPWU_DONE PPC_BIT(1)
static uint64_t pnv_qme_power10_xscom_read(void *opaque, hwaddr addr,
unsigned int width)
@@ -508,8 +517,11 @@ static uint64_t pnv_qme_power10_xscom_read(void
*opaque, hwaddr addr,
*/
switch (offset & ~0xf000) {
case P10_QME_SPWU_HYP:
+val = 0;
+break;
case P10_QME_SSH_HYP:
-return 0;
+val = P10_SSH_SPWU_DONE;
+break;
default:
qemu_log_mask(LOG_UNIMP, "%s: unimp read 0x%08x\n", __func__,
offset);
@@ -524,6 +536,8 @@ static void pnv_qme_power10_xscom_write(void
*opaque, hwaddr addr,
uint32_t offset = addr >> 3;
switch (offset) {
+case P10_QME_SSH_HYP:
+case P10_QME_SPWU_HYP:
default:
qemu_log_mask(LOG_UNIMP, "%s: unimp write 0x%08x\n", __func__,
offset);
--
2.40.1
[PATCH v2] ppc/pnv: Add QME region for P10
The Quad Management Engine (QME) manages power related settings for its
quad. The xscom region is separate from the quad xscoms, therefore a new
region is added. The xscoms in a QME select a given core by selecting
the forth nibble.
Implement dummy reads for the stop state history (SSH) and special
wakeup (SPWU) registers. This quietens some sxcom errors when skiboot
boots on p10.
Power9 does not have a QME.
Signed-off-by: Joel Stanley
---
v2:
Clean up extra whitespace
Make realize quad specific so power9 doesn't end up with the qme region
---
include/hw/ppc/pnv_core.h | 4 ++
include/hw/ppc/pnv_xscom.h | 11 ++
hw/ppc/pnv.c | 3 ++
hw/ppc/pnv_core.c | 78 +-
4 files changed, 94 insertions(+), 2 deletions(-)
diff --git a/include/hw/ppc/pnv_core.h b/include/hw/ppc/pnv_core.h
index 77ef00f47a72..c829a18aa9c6 100644
--- a/include/hw/ppc/pnv_core.h
+++ b/include/hw/ppc/pnv_core.h
@@ -65,6 +65,9 @@ struct PnvQuadClass {
const MemoryRegionOps *xscom_ops;
uint64_t xscom_size;
+
+const MemoryRegionOps *xscom_qme_ops;
+uint64_t xscom_qme_size;
};
#define TYPE_PNV_QUAD "powernv-cpu-quad"
@@ -79,5 +82,6 @@ struct PnvQuad {
uint32_t quad_id;
MemoryRegion xscom_regs;
+MemoryRegion xscom_qme_regs;
};
#endif /* PPC_PNV_CORE_H */
diff --git a/include/hw/ppc/pnv_xscom.h b/include/hw/ppc/pnv_xscom.h
index a4c9d95dc5d3..9bc64635471e 100644
--- a/include/hw/ppc/pnv_xscom.h
+++ b/include/hw/ppc/pnv_xscom.h
@@ -127,6 +127,17 @@ struct PnvXScomInterfaceClass {
#define PNV10_XSCOM_EC(proc)\
((0x2 << 16) | ((1 << (3 - (proc))) << 12))
+#define PNV10_XSCOM_QME(chiplet) \
+(PNV10_XSCOM_EQ(chiplet) | (0xE << 16))
+
+/*
+ * Make the region larger by 0x1000 (instead of starting at an offset) so the
+ * modelled addresses start from 0
+ */
+#define PNV10_XSCOM_QME_BASE(core) \
+((uint64_t) PNV10_XSCOM_QME(PNV10_XSCOM_EQ_CHIPLET(core)))
+#define PNV10_XSCOM_QME_SIZE(0x8000 + 0x1000)
+
#define PNV10_XSCOM_EQ_BASE(core) \
((uint64_t) PNV10_XSCOM_EQ(PNV10_XSCOM_EQ_CHIPLET(core)))
#define PNV10_XSCOM_EQ_SIZE0x2
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 23740f9d0733..eb54f93986df 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1685,6 +1685,9 @@ static void pnv_chip_power10_quad_realize(Pnv10Chip
*chip10, Error **errp)
pnv_xscom_add_subregion(chip, PNV10_XSCOM_EQ_BASE(eq->quad_id),
&eq->xscom_regs);
+
+pnv_xscom_add_subregion(chip, PNV10_XSCOM_QME_BASE(eq->quad_id),
+&eq->xscom_qme_regs);
}
}
diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
index 1f244ed181d0..09eb2bf94b9e 100644
--- a/hw/ppc/pnv_core.c
+++ b/hw/ppc/pnv_core.c
@@ -493,7 +493,67 @@ static const MemoryRegionOps pnv_quad_power10_xscom_ops = {
.endianness = DEVICE_BIG_ENDIAN,
};
-static void pnv_quad_realize(DeviceState *dev, Error **errp)
+#define P10_QME_SPWU_HYP 0x83c
+#define P10_QME_SSH_HYP 0x82c
+
+static uint64_t pnv_qme_power10_xscom_read(void *opaque, hwaddr addr,
+unsigned int width)
+{
+uint32_t offset = addr >> 3;
+uint64_t val = -1;
+
+/*
+ * Forth nibble selects the core within a quad, mask it to process read
+ * for any core.
+ */
+switch (offset & ~0xf000) {
+case P10_QME_SPWU_HYP:
+case P10_QME_SSH_HYP:
+return 0;
+default:
+qemu_log_mask(LOG_UNIMP, "%s: unimp read 0x%08x\n", __func__,
+ offset);
+}
+
+return val;
+}
+
+static void pnv_qme_power10_xscom_write(void *opaque, hwaddr addr,
+ uint64_t val, unsigned int width)
+{
+uint32_t offset = addr >> 3;
+
+switch (offset) {
+default:
+qemu_log_mask(LOG_UNIMP, "%s: unimp write 0x%08x\n", __func__,
+ offset);
+}
+}
+
+static const MemoryRegionOps pnv_qme_power10_xscom_ops = {
+.read = pnv_qme_power10_xscom_read,
+.write = pnv_qme_power10_xscom_write,
+.valid.min_access_size = 8,
+.valid.max_access_size = 8,
+.impl.min_access_size = 8,
+.impl.max_access_size = 8,
+.endianness = DEVICE_BIG_ENDIAN,
+};
+
+static void pnv_quad_power9_realize(DeviceState *dev, Error **errp)
+{
+PnvQuad *eq = PNV_QUAD(dev);
+PnvQuadClass *pqc = PNV_QUAD_GET_CLASS(eq);
+char name[32];
+
+snprintf(name, sizeof(name), "xscom-quad.%d", eq->quad_id);
+pnv_xscom_region_init(&eq->xscom_regs, OBJECT(dev),
+ pqc->xscom_ops,
+ eq, name,
+ pqc->xscom_size);
+}
+
+static void pnv_quad_power10_realize(DeviceState *dev, Error **errp)
{
PnvQuad *eq = PNV_QUAD(dev);
PnvQ
Re: [PATCH] ppc/pnv: Add QME region for P10
On Fri, 7 Jul 2023 at 05:04, Cédric Le Goater wrote:
> pnv_quad_realize realizes power9 and power10 quad objects but ...
>
> > }
> >
> > static Property pnv_quad_properties[] = {
> > @@ -528,6 +581,9 @@ static void pnv_quad_power10_class_init(ObjectClass
> > *oc, void *data)
> >
> > pqc->xscom_ops = &pnv_quad_power10_xscom_ops;
> > pqc->xscom_size = PNV10_XSCOM_EQ_SIZE;
> > +
> > +pqc->xscom_qme_ops = &pnv_qme_power10_xscom_ops;
> > +pqc->xscom_qme_size = PNV10_XSCOM_QME_SIZE;
>
> xscom_qme_size is only defined on power10 and it is 0 on power9. The region
> is nevertheless initialized on power9 and never mapped.
>
> I think we should introduce a specific realize routine for each proc now.
I overlooked the P9 behaviour, thanks for pointing that out. I'll make
the realise proc specific.
Cheers,
Joel
[PATCH] ppc/pnv: Add QME region for P10
The Quad Management Engine (QME) manages power related settings for its
quad. The xscom region is separate from the quad xscoms, therefore a new
region is added. The xscoms in a QME select a given core by selecting
the forth nibble.
Implement dummy reads for the stop state history (SSH) and special
wakeup (SPWU) registers. This quietens some sxcom errors when skiboot
boots on p10.
Signed-off-by: Joel Stanley
---
include/hw/ppc/pnv_core.h | 4 +++
include/hw/ppc/pnv_xscom.h | 11
hw/ppc/pnv.c | 5
hw/ppc/pnv_core.c | 56 ++
4 files changed, 76 insertions(+)
diff --git a/include/hw/ppc/pnv_core.h b/include/hw/ppc/pnv_core.h
index 77ef00f47a72..c829a18aa9c6 100644
--- a/include/hw/ppc/pnv_core.h
+++ b/include/hw/ppc/pnv_core.h
@@ -65,6 +65,9 @@ struct PnvQuadClass {
const MemoryRegionOps *xscom_ops;
uint64_t xscom_size;
+
+const MemoryRegionOps *xscom_qme_ops;
+uint64_t xscom_qme_size;
};
#define TYPE_PNV_QUAD "powernv-cpu-quad"
@@ -79,5 +82,6 @@ struct PnvQuad {
uint32_t quad_id;
MemoryRegion xscom_regs;
+MemoryRegion xscom_qme_regs;
};
#endif /* PPC_PNV_CORE_H */
diff --git a/include/hw/ppc/pnv_xscom.h b/include/hw/ppc/pnv_xscom.h
index a4c9d95dc5d3..9bc64635471e 100644
--- a/include/hw/ppc/pnv_xscom.h
+++ b/include/hw/ppc/pnv_xscom.h
@@ -127,6 +127,17 @@ struct PnvXScomInterfaceClass {
#define PNV10_XSCOM_EC(proc)\
((0x2 << 16) | ((1 << (3 - (proc))) << 12))
+#define PNV10_XSCOM_QME(chiplet) \
+(PNV10_XSCOM_EQ(chiplet) | (0xE << 16))
+
+/*
+ * Make the region larger by 0x1000 (instead of starting at an offset) so the
+ * modelled addresses start from 0
+ */
+#define PNV10_XSCOM_QME_BASE(core) \
+((uint64_t) PNV10_XSCOM_QME(PNV10_XSCOM_EQ_CHIPLET(core)))
+#define PNV10_XSCOM_QME_SIZE(0x8000 + 0x1000)
+
#define PNV10_XSCOM_EQ_BASE(core) \
((uint64_t) PNV10_XSCOM_EQ(PNV10_XSCOM_EQ_CHIPLET(core)))
#define PNV10_XSCOM_EQ_SIZE0x2
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 5f25fe985ab2..6da25a676a0f 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1673,6 +1673,11 @@ static void pnv_chip_power10_quad_realize(Pnv10Chip
*chip10, Error **errp)
pnv_xscom_add_subregion(chip, PNV10_XSCOM_EQ_BASE(eq->quad_id),
&eq->xscom_regs);
+
+pnv_xscom_add_subregion(chip, PNV10_XSCOM_QME_BASE(eq->quad_id),
+&eq->xscom_qme_regs);
+
+
}
}
diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
index 3eb95670d6a3..35e219387918 100644
--- a/hw/ppc/pnv_core.c
+++ b/hw/ppc/pnv_core.c
@@ -496,6 +496,53 @@ static const MemoryRegionOps pnv_quad_power10_xscom_ops = {
.endianness = DEVICE_BIG_ENDIAN,
};
+#define P10_QME_SPWU_HYP 0x83c
+#define P10_QME_SSH_HYP 0x82c
+
+static uint64_t pnv_qme_power10_xscom_read(void *opaque, hwaddr addr,
+unsigned int width)
+{
+uint32_t offset = addr >> 3;
+uint64_t val = -1;
+
+/*
+ * Forth nibble selects the core within a quad, mask it to process read
+ * for any core.
+ */
+switch (offset & ~0xf000) {
+case P10_QME_SPWU_HYP:
+case P10_QME_SSH_HYP:
+return 0;
+default:
+qemu_log_mask(LOG_UNIMP, "%s: unimp read 0x%08x\n", __func__,
+ offset);
+}
+
+return val;
+}
+
+static void pnv_qme_power10_xscom_write(void *opaque, hwaddr addr,
+ uint64_t val, unsigned int width)
+{
+uint32_t offset = addr >> 3;
+
+switch (offset) {
+default:
+qemu_log_mask(LOG_UNIMP, "%s: unimp write 0x%08x\n", __func__,
+ offset);
+}
+}
+
+static const MemoryRegionOps pnv_qme_power10_xscom_ops = {
+.read = pnv_qme_power10_xscom_read,
+.write = pnv_qme_power10_xscom_write,
+.valid.min_access_size = 8,
+.valid.max_access_size = 8,
+.impl.min_access_size = 8,
+.impl.max_access_size = 8,
+.endianness = DEVICE_BIG_ENDIAN,
+};
+
static void pnv_quad_realize(DeviceState *dev, Error **errp)
{
PnvQuad *eq = PNV_QUAD(dev);
@@ -507,6 +554,12 @@ static void pnv_quad_realize(DeviceState *dev, Error
**errp)
pqc->xscom_ops,
eq, name,
pqc->xscom_size);
+
+snprintf(name, sizeof(name), "xscom-qme.%d", eq->quad_id);
+pnv_xscom_region_init(&eq->xscom_qme_regs, OBJECT(dev),
+ pqc->xscom_qme_ops,
+ eq, name,
+ pqc->xscom_qme_size);
}
static Property pnv_quad_properties[] = {
@@ -528,6 +581,9 @@ static void pnv_quad_power10_class_init(ObjectClass *oc,
void *data)
pqc->xscom_ops = &pnv_quad_power10_xscom_
[PATCH] ppc/pnv: Log all unimp warnings with similar message
Add the function name so there's an indication as to where the message
is coming from. Change all prints to use the offset instead of the
address.
Signed-off-by: Joel Stanley
---
Happy to use the address instead of the offset (or print both), but I
like the idea of being consistent.
---
hw/ppc/pnv_core.c | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
index ffbc29cbf4f9..3eb95670d6a3 100644
--- a/hw/ppc/pnv_core.c
+++ b/hw/ppc/pnv_core.c
@@ -85,8 +85,8 @@ static uint64_t pnv_core_power8_xscom_read(void *opaque,
hwaddr addr,
val = 0x24full;
break;
default:
-qemu_log_mask(LOG_UNIMP, "Warning: reading reg=0x%" HWADDR_PRIx "\n",
- addr);
+qemu_log_mask(LOG_UNIMP, "%s: unimp read 0x%08x\n", __func__,
+ offset);
}
return val;
@@ -95,8 +95,10 @@ static uint64_t pnv_core_power8_xscom_read(void *opaque,
hwaddr addr,
static void pnv_core_power8_xscom_write(void *opaque, hwaddr addr, uint64_t
val,
unsigned int width)
{
-qemu_log_mask(LOG_UNIMP, "Warning: writing to reg=0x%" HWADDR_PRIx "\n",
- addr);
+uint32_t offset = addr >> 3;
+
+qemu_log_mask(LOG_UNIMP, "%s: unimp write 0x%08x\n", __func__,
+ offset);
}
static const MemoryRegionOps pnv_core_power8_xscom_ops = {
@@ -140,8 +142,8 @@ static uint64_t pnv_core_power9_xscom_read(void *opaque,
hwaddr addr,
val = 0;
break;
default:
-qemu_log_mask(LOG_UNIMP, "Warning: reading reg=0x%" HWADDR_PRIx "\n",
- addr);
+qemu_log_mask(LOG_UNIMP, "%s: unimp read 0x%08x\n", __func__,
+ offset);
}
return val;
@@ -157,8 +159,8 @@ static void pnv_core_power9_xscom_write(void *opaque,
hwaddr addr, uint64_t val,
case PNV9_XSCOM_EC_PPM_SPECIAL_WKUP_OTR:
break;
default:
-qemu_log_mask(LOG_UNIMP, "Warning: writing to reg=0x%" HWADDR_PRIx
"\n",
- addr);
+qemu_log_mask(LOG_UNIMP, "%s: unimp write 0x%08x\n", __func__,
+ offset);
}
}
@@ -189,8 +191,8 @@ static uint64_t pnv_core_power10_xscom_read(void *opaque,
hwaddr addr,
val = 0;
break;
default:
-qemu_log_mask(LOG_UNIMP, "Warning: reading reg=0x%" HWADDR_PRIx "\n",
- addr);
+qemu_log_mask(LOG_UNIMP, "%s: unimp read 0x%08x\n", __func__,
+ offset);
}
return val;
@@ -203,8 +205,8 @@ static void pnv_core_power10_xscom_write(void *opaque,
hwaddr addr,
switch (offset) {
default:
-qemu_log_mask(LOG_UNIMP, "Warning: writing to reg=0x%" HWADDR_PRIx
"\n",
- addr);
+qemu_log_mask(LOG_UNIMP, "%s: unimp write 0x%08x\n", __func__,
+ offset);
}
}
@@ -421,7 +423,7 @@ static uint64_t pnv_quad_power9_xscom_read(void *opaque,
hwaddr addr,
val = 0;
break;
default:
-qemu_log_mask(LOG_UNIMP, "%s: reading @0x%08x\n", __func__,
+qemu_log_mask(LOG_UNIMP, "%s: unimp read 0x%08x\n", __func__,
offset);
}
@@ -438,7 +440,7 @@ static void pnv_quad_power9_xscom_write(void *opaque,
hwaddr addr, uint64_t val,
case P9X_EX_NCU_SPEC_BAR + 0x400: /* Second EX */
break;
default:
-qemu_log_mask(LOG_UNIMP, "%s: writing @0x%08x\n", __func__,
+qemu_log_mask(LOG_UNIMP, "%s: unimp write 0x%08x\n", __func__,
offset);
}
}
@@ -465,7 +467,7 @@ static uint64_t pnv_quad_power10_xscom_read(void *opaque,
hwaddr addr,
switch (offset) {
default:
-qemu_log_mask(LOG_UNIMP, "%s: reading @0x%08x\n", __func__,
+qemu_log_mask(LOG_UNIMP, "%s: unimp read 0x%08x\n", __func__,
offset);
}
@@ -479,7 +481,7 @@ static void pnv_quad_power10_xscom_write(void *opaque,
hwaddr addr,
switch (offset) {
default:
-qemu_log_mask(LOG_UNIMP, "%s: writing @0x%08x\n", __func__,
+qemu_log_mask(LOG_UNIMP, "%s: unimp write 0x%08x\n", __func__,
offset);
}
}
--
2.40.1
Re: [PATCH] ppc/pnv: Set P10 core xscom region size to match hardware
On Wed, 5 Jul 2023 at 10:02, Cédric Le Goater wrote: > > On 7/5/23 04:05, Joel Stanley wrote: > > On Wed, 5 Jul 2023 at 01:27, Nicholas Piggin wrote: > >> > >> The P10 core xscom memory regions overlap because the size is wrong. > >> The P10 core+L2 xscom region size is allocated as 0x1000 (with some > >> unused ranges). "EC" is used as a closer match, as "EX" includes L3 > >> which has a disjoint xscom range that would require a different > >> region if it were implemented. > >> > >> Signed-off-by: Nicholas Piggin > > > > Nice, that looks better: > > > > 0001-0001000f (prio 0, i/o): xscom-quad.0: 0x10 > > 000100108000-00010010 (prio 0, i/o): xscom-core.3: 0x8000 > > 00010011-000100117fff (prio 0, i/o): xscom-core.2: 0x8000 > > 00010012-000100127fff (prio 0, i/o): xscom-core.1: 0x8000 > > 00010014-000100147fff (prio 0, i/o): xscom-core.0: 0x8000 > > 00010800-0001080f (prio 0, i/o): xscom-quad.4: 0x10 > > 000108108000-00010810 (prio 0, i/o): xscom-core.7: 0x8000 > > 00010811-000108117fff (prio 0, i/o): xscom-core.6: 0x8000 > > 00010812-000108127fff (prio 0, i/o): xscom-core.5: 0x8000 > > 00010814-000108147fff (prio 0, i/o): xscom-core.4: 0x8000 > > > > Reviewed-by: Joel Stanley > > It'd interesting to add some dummy SLW handlers to get rid of the > XSCOM errors at boot and shutdown on P10 : > > [ 4824.393446266,3] XSCOM: write error gcid=0x0 pcb_addr=0x200e883c stat=0x0 > [ 4824.393588777,5] Unable to log error > [ 4824.393650582,3] XSCOM: Write failed, ret = -6 > [ 4824.394124623,3] Could not set special wakeup on 0:0: Unable to write > QME_SPWU_HYP. > [ 4824.394368459,3] XSCOM: write error gcid=0x0 pcb_addr=0x200e883c stat=0x0 > [ 4824.394382007,5] Unable to log error > [ 4824.394384603,3] XSCOM: Write failed, ret = -6 Yes. I was looking at this yesterday. We need to figure out how to do the xscom addressing for the QME. It sets (different) bits in order to address a given core. For a -smp 4 machine, the P10_QME_SPWU_HYP read comes in on these addresses: case 0x200e883c: case 0x200e483c: case 0x200e283c: case 0x200e183c: ie, the fourth nibble selects the core. For a -smp 8 machine, the address now has bit 24 set to select the second quad, so we need to cover these addresses: case 0x210e883c: case 0x210e483c: case 0x210e283c: case 0x210e183c: I am thinking about how to map this into an address range that a model can claim. Cheers, Joel PS. For reference, this is sufficient to silence xscom errors with skiboot and -M powernv10 -smp4. A different set of hacks is required for p9. --- a/hw/ppc/pnv_xscom.c +++ b/hw/ppc/pnv_xscom.c @@ -106,6 +106,26 @@ static uint64_t xscom_read_default(PnvChip *chip, uint32_t pcba) case 0x401082a: case 0x4010828: return 0; + +/* P10_QME_SPWU_HYP */ +case 0x200e883c: +case 0x200e483c: +case 0x200e283c: +case 0x200e183c: +return 0; + +/* P10_QME_SSH_HYP */ +case 0x200e882c: +case 0x200e482c: +case 0x200e282c: +case 0x200e182c: +return 0; + +/* XPEC_P10_PCI_CPLT_CONF1 */ +case 0x0809: +case 0x0909: +return 0; + default: return -1; } @@ -152,6 +172,13 @@ static bool xscom_write_default(PnvChip *chip, uint32_t pcba, uint64_t val) case PRD_P8_IPOLL_REG_STATUS: case PRD_P9_IPOLL_REG_MASK: case PRD_P9_IPOLL_REG_STATUS: + +/* P10_QME_SPWU_HYP */ +case 0x200e883c: +case 0x200e483c: +case 0x200e283c: +case 0x200e183c: + return true; default: return false;
Re: [PATCH] ppc/pnv: Set P10 core xscom region size to match hardware
On Wed, 5 Jul 2023 at 01:27, Nicholas Piggin wrote:
>
> The P10 core xscom memory regions overlap because the size is wrong.
> The P10 core+L2 xscom region size is allocated as 0x1000 (with some
> unused ranges). "EC" is used as a closer match, as "EX" includes L3
> which has a disjoint xscom range that would require a different
> region if it were implemented.
>
> Signed-off-by: Nicholas Piggin
Nice, that looks better:
0001-0001000f (prio 0, i/o): xscom-quad.0: 0x10
000100108000-00010010 (prio 0, i/o): xscom-core.3: 0x8000
00010011-000100117fff (prio 0, i/o): xscom-core.2: 0x8000
00010012-000100127fff (prio 0, i/o): xscom-core.1: 0x8000
00010014-000100147fff (prio 0, i/o): xscom-core.0: 0x8000
00010800-0001080f (prio 0, i/o): xscom-quad.4: 0x10
000108108000-00010810 (prio 0, i/o): xscom-core.7: 0x8000
00010811-000108117fff (prio 0, i/o): xscom-core.6: 0x8000
00010812-000108127fff (prio 0, i/o): xscom-core.5: 0x8000
00010814-000108147fff (prio 0, i/o): xscom-core.4: 0x8000
Reviewed-by: Joel Stanley
> ---
> hw/ppc/pnv_core.c | 3 +--
> include/hw/ppc/pnv_xscom.h | 2 +-
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
> index b7223bb445..ffbc29cbf4 100644
> --- a/hw/ppc/pnv_core.c
> +++ b/hw/ppc/pnv_core.c
> @@ -299,9 +299,8 @@ static void pnv_core_realize(DeviceState *dev, Error
> **errp)
> }
>
> snprintf(name, sizeof(name), "xscom-core.%d", cc->core_id);
> -/* TODO: check PNV_XSCOM_EX_SIZE for p10 */
> pnv_xscom_region_init(&pc->xscom_regs, OBJECT(dev), pcc->xscom_ops,
> - pc, name, PNV_XSCOM_EX_SIZE);
> + pc, name, PNV10_XSCOM_EC_SIZE);
>
> qemu_register_reset(pnv_core_reset, pc);
> return;
> diff --git a/include/hw/ppc/pnv_xscom.h b/include/hw/ppc/pnv_xscom.h
> index f7da9a1dc6..a4c9d95dc5 100644
> --- a/include/hw/ppc/pnv_xscom.h
> +++ b/include/hw/ppc/pnv_xscom.h
> @@ -133,7 +133,7 @@ struct PnvXScomInterfaceClass {
>
> #define PNV10_XSCOM_EC_BASE(core) \
> ((uint64_t) PNV10_XSCOM_EQ_BASE(core) | PNV10_XSCOM_EC(core & 0x3))
> -#define PNV10_XSCOM_EC_SIZE0x10
> +#define PNV10_XSCOM_EC_SIZE0x1000
>
> #define PNV10_XSCOM_PSIHB_BASE 0x3011D00
> #define PNV10_XSCOM_PSIHB_SIZE 0x100
> --
> 2.40.1
>
[PATCH v2 2/5] ppc/pnv: Subclass quad xscom callbacks
Make the existing pnv_quad_xscom_read/write be P9 specific, in
preparation for a different P10 callback.
Reviewed-by: Cédric Le Goater
Signed-off-by: Joel Stanley
---
v2: Add scom region size to class
---
include/hw/ppc/pnv_core.h | 13 -
hw/ppc/pnv.c | 11 +++
hw/ppc/pnv_core.c | 40 ++-
3 files changed, 46 insertions(+), 18 deletions(-)
diff --git a/include/hw/ppc/pnv_core.h b/include/hw/ppc/pnv_core.h
index 3d75706e95da..77ef00f47a72 100644
--- a/include/hw/ppc/pnv_core.h
+++ b/include/hw/ppc/pnv_core.h
@@ -60,8 +60,19 @@ static inline PnvCPUState *pnv_cpu_state(PowerPCCPU *cpu)
return (PnvCPUState *)cpu->machine_data;
}
+struct PnvQuadClass {
+DeviceClass parent_class;
+
+const MemoryRegionOps *xscom_ops;
+uint64_t xscom_size;
+};
+
#define TYPE_PNV_QUAD "powernv-cpu-quad"
-OBJECT_DECLARE_SIMPLE_TYPE(PnvQuad, PNV_QUAD)
+
+#define PNV_QUAD_TYPE_SUFFIX "-" TYPE_PNV_QUAD
+#define PNV_QUAD_TYPE_NAME(cpu_model) cpu_model PNV_QUAD_TYPE_SUFFIX
+
+OBJECT_DECLARE_TYPE(PnvQuad, PnvQuadClass, PNV_QUAD)
struct PnvQuad {
DeviceState parent_obj;
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index fc083173f346..c77fdb6747a4 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1429,14 +1429,15 @@ static void pnv_chip_power9_instance_init(Object *obj)
}
static void pnv_chip_quad_realize_one(PnvChip *chip, PnvQuad *eq,
- PnvCore *pnv_core)
+ PnvCore *pnv_core,
+ const char *type)
{
char eq_name[32];
int core_id = CPU_CORE(pnv_core)->core_id;
snprintf(eq_name, sizeof(eq_name), "eq[%d]", core_id);
object_initialize_child_with_props(OBJECT(chip), eq_name, eq,
- sizeof(*eq), TYPE_PNV_QUAD,
+ sizeof(*eq), type,
&error_fatal, NULL);
object_property_set_int(OBJECT(eq), "quad-id", core_id, &error_fatal);
@@ -1454,7 +1455,8 @@ static void pnv_chip_quad_realize(Pnv9Chip *chip9, Error
**errp)
for (i = 0; i < chip9->nr_quads; i++) {
PnvQuad *eq = &chip9->quads[i];
-pnv_chip_quad_realize_one(chip, eq, chip->cores[i * 4]);
+pnv_chip_quad_realize_one(chip, eq, chip->cores[i * 4],
+ PNV_QUAD_TYPE_NAME("power9"));
pnv_xscom_add_subregion(chip, PNV9_XSCOM_EQ_BASE(eq->quad_id),
&eq->xscom_regs);
@@ -1666,7 +1668,8 @@ static void pnv_chip_power10_quad_realize(Pnv10Chip
*chip10, Error **errp)
for (i = 0; i < chip10->nr_quads; i++) {
PnvQuad *eq = &chip10->quads[i];
-pnv_chip_quad_realize_one(chip, eq, chip->cores[i * 4]);
+pnv_chip_quad_realize_one(chip, eq, chip->cores[i * 4],
+ PNV_QUAD_TYPE_NAME("power9"));
pnv_xscom_add_subregion(chip, PNV10_XSCOM_EQ_BASE(eq->quad_id),
&eq->xscom_regs);
diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
index 0f451b3b6e1f..73d25409c937 100644
--- a/hw/ppc/pnv_core.c
+++ b/hw/ppc/pnv_core.c
@@ -407,12 +407,14 @@ static const MemoryRegionOps pnv_quad_power9_xscom_ops = {
static void pnv_quad_realize(DeviceState *dev, Error **errp)
{
PnvQuad *eq = PNV_QUAD(dev);
+PnvQuadClass *pqc = PNV_QUAD_GET_CLASS(eq);
char name[32];
snprintf(name, sizeof(name), "xscom-quad.%d", eq->quad_id);
pnv_xscom_region_init(&eq->xscom_regs, OBJECT(dev),
- &pnv_quad_power9_xscom_ops,
- eq, name, PNV9_XSCOM_EQ_SIZE);
+ pqc->xscom_ops,
+ eq, name,
+ pqc->xscom_size);
}
static Property pnv_quad_properties[] = {
@@ -420,6 +422,14 @@ static Property pnv_quad_properties[] = {
DEFINE_PROP_END_OF_LIST(),
};
+static void pnv_quad_power9_class_init(ObjectClass *oc, void *data)
+{
+PnvQuadClass *pqc = PNV_QUAD_CLASS(oc);
+
+pqc->xscom_ops = &pnv_quad_power9_xscom_ops;
+pqc->xscom_size = PNV9_XSCOM_EQ_SIZE;
+}
+
static void pnv_quad_class_init(ObjectClass *oc, void *data)
{
DeviceClass *dc = DEVICE_CLASS(oc);
@@ -429,16 +439,20 @@ static void pnv_quad_class_init(ObjectClass *oc, void
*data)
dc->user_creatable = false;
}
-static const TypeInfo pnv_quad_info = {
-.name = TYPE_PNV_QUAD,
-.parent= TYPE_DEVICE,
-.instance_size = sizeof(PnvQuad),
-.class_init= pnv_quad_class_init,
+static const TypeInfo pnv_quad_infos[] = {
+{
+.name = TYPE_PNV_QUAD,
+.parent= TYPE_DEVICE,
+.instance_size = sizeof(PnvQuad),
+.class
[PATCH v2 1/5] ppc/pnv: quad xscom callbacks are P9 specific
Rename the functions to include P9 in the name in preparation for adding
P10 versions.
Correct the unimp read message while we're changing the function.
Reviewed-by: Cédric Le Goater
Signed-off-by: Joel Stanley
---
v2: Fix unimp print, and grammar in the commit message
---
hw/ppc/pnv_core.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
index 0bc3ad41c81c..0f451b3b6e1f 100644
--- a/hw/ppc/pnv_core.c
+++ b/hw/ppc/pnv_core.c
@@ -360,8 +360,8 @@ DEFINE_TYPES(pnv_core_infos)
#define P9X_EX_NCU_SPEC_BAR 0x11010
-static uint64_t pnv_quad_xscom_read(void *opaque, hwaddr addr,
-unsigned int width)
+static uint64_t pnv_quad_power9_xscom_read(void *opaque, hwaddr addr,
+ unsigned int width)
{
uint32_t offset = addr >> 3;
uint64_t val = -1;
@@ -372,15 +372,15 @@ static uint64_t pnv_quad_xscom_read(void *opaque, hwaddr
addr,
val = 0;
break;
default:
-qemu_log_mask(LOG_UNIMP, "%s: writing @0x%08x\n", __func__,
+qemu_log_mask(LOG_UNIMP, "%s: reading @0x%08x\n", __func__,
offset);
}
return val;
}
-static void pnv_quad_xscom_write(void *opaque, hwaddr addr, uint64_t val,
- unsigned int width)
+static void pnv_quad_power9_xscom_write(void *opaque, hwaddr addr, uint64_t
val,
+unsigned int width)
{
uint32_t offset = addr >> 3;
@@ -394,9 +394,9 @@ static void pnv_quad_xscom_write(void *opaque, hwaddr addr,
uint64_t val,
}
}
-static const MemoryRegionOps pnv_quad_xscom_ops = {
-.read = pnv_quad_xscom_read,
-.write = pnv_quad_xscom_write,
+static const MemoryRegionOps pnv_quad_power9_xscom_ops = {
+.read = pnv_quad_power9_xscom_read,
+.write = pnv_quad_power9_xscom_write,
.valid.min_access_size = 8,
.valid.max_access_size = 8,
.impl.min_access_size = 8,
@@ -410,7 +410,8 @@ static void pnv_quad_realize(DeviceState *dev, Error **errp)
char name[32];
snprintf(name, sizeof(name), "xscom-quad.%d", eq->quad_id);
-pnv_xscom_region_init(&eq->xscom_regs, OBJECT(dev), &pnv_quad_xscom_ops,
+pnv_xscom_region_init(&eq->xscom_regs, OBJECT(dev),
+ &pnv_quad_power9_xscom_ops,
eq, name, PNV9_XSCOM_EQ_SIZE);
}
--
2.40.1
[PATCH v2 0/5] ppc/pnv: Extend "quad" model for p10
The quad model implements the EC xscoms for the p9 machine, reusing the same model for p10 which isn't quite correct. This series adds a PnvQuad class and subclasses it for P9 and P10. I mistakenly thought we needed the quad model to implement the core thread state scom on p10, because the read was coming in to the address belonging to the quad. In fact the quad region was too large, overlapping with the core. This is fixed in v2, and the core thread is back where it should be in the core model. This should address Nick's feedback on the v1 cover letter. v2 also adds Cedric's r-b, fixes the s/write/read/ mistakes, and is checkpatch clean. v1: https://lore.kernel.org/qemu-devel/20230630035547.80329-1-j...@jms.id.au/ Joel Stanley (5): ppc/pnv: quad xscom callbacks are P9 specific ppc/pnv: Subclass quad xscom callbacks ppc/pnv: Add P10 quad xscom model ppc/pnv: Add P10 core xscom model ppc/pnv: Return zero for core thread state xscom include/hw/ppc/pnv_core.h | 13 ++- include/hw/ppc/pnv_xscom.h | 2 +- hw/ppc/pnv.c | 11 ++- hw/ppc/pnv_core.c | 165 +++-- 4 files changed, 162 insertions(+), 29 deletions(-) -- 2.40.1
[PATCH v2 4/5] ppc/pnv: Add P10 core xscom model
Like the quad xscoms, add a core model for P10 to allow future
differentiation from P9.
Signed-off-by: Joel Stanley
---
hw/ppc/pnv_core.c | 44 ++--
1 file changed, 42 insertions(+), 2 deletions(-)
diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
index e4df435b15e9..1eec28c88c41 100644
--- a/hw/ppc/pnv_core.c
+++ b/hw/ppc/pnv_core.c
@@ -167,6 +167,47 @@ static const MemoryRegionOps pnv_core_power9_xscom_ops = {
.endianness = DEVICE_BIG_ENDIAN,
};
+/*
+ * POWER10 core controls
+ */
+
+static uint64_t pnv_core_power10_xscom_read(void *opaque, hwaddr addr,
+ unsigned int width)
+{
+uint32_t offset = addr >> 3;
+uint64_t val = 0;
+
+switch (offset) {
+default:
+qemu_log_mask(LOG_UNIMP, "Warning: reading reg=0x%" HWADDR_PRIx "\n",
+ addr);
+}
+
+return val;
+}
+
+static void pnv_core_power10_xscom_write(void *opaque, hwaddr addr,
+ uint64_t val, unsigned int width)
+{
+uint32_t offset = addr >> 3;
+
+switch (offset) {
+default:
+qemu_log_mask(LOG_UNIMP, "Warning: writing to reg=0x%" HWADDR_PRIx
"\n",
+ addr);
+}
+}
+
+static const MemoryRegionOps pnv_core_power10_xscom_ops = {
+.read = pnv_core_power10_xscom_read,
+.write = pnv_core_power10_xscom_write,
+.valid.min_access_size = 8,
+.valid.max_access_size = 8,
+.impl.min_access_size = 8,
+.impl.max_access_size = 8,
+.endianness = DEVICE_BIG_ENDIAN,
+};
+
static void pnv_core_cpu_realize(PnvCore *pc, PowerPCCPU *cpu, Error **errp)
{
CPUPPCState *env = &cpu->env;
@@ -315,8 +356,7 @@ static void pnv_core_power10_class_init(ObjectClass *oc,
void *data)
{
PnvCoreClass *pcc = PNV_CORE_CLASS(oc);
-/* TODO: Use the P9 XSCOMs for now on P10 */
-pcc->xscom_ops = &pnv_core_power9_xscom_ops;
+pcc->xscom_ops = &pnv_core_power10_xscom_ops;
}
static void pnv_core_class_init(ObjectClass *oc, void *data)
--
2.40.1
[PATCH v2 5/5] ppc/pnv: Return zero for core thread state xscom
Firmware now warns if booting in LPAR per core mode (PPC bit 62). So
this warning doesn't trigger, report the core thread state is 0.
Reviewed-by: Cédric Le Goater
Signed-off-by: Joel Stanley
---
hw/ppc/pnv_core.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
index 1eec28c88c41..b7223bb44597 100644
--- a/hw/ppc/pnv_core.c
+++ b/hw/ppc/pnv_core.c
@@ -116,6 +116,8 @@ static const MemoryRegionOps pnv_core_power8_xscom_ops = {
#define PNV9_XSCOM_EC_PPM_SPECIAL_WKUP_HYP 0xf010d
#define PNV9_XSCOM_EC_PPM_SPECIAL_WKUP_OTR 0xf010a
+#define PNV9_XSCOM_EC_CORE_THREAD_STATE0x10ab3
+
static uint64_t pnv_core_power9_xscom_read(void *opaque, hwaddr addr,
unsigned int width)
{
@@ -134,6 +136,9 @@ static uint64_t pnv_core_power9_xscom_read(void *opaque,
hwaddr addr,
case PNV9_XSCOM_EC_PPM_SPECIAL_WKUP_OTR:
val = 0x0;
break;
+case PNV9_XSCOM_EC_CORE_THREAD_STATE:
+val = 0;
+break;
default:
qemu_log_mask(LOG_UNIMP, "Warning: reading reg=0x%" HWADDR_PRIx "\n",
addr);
@@ -171,6 +176,8 @@ static const MemoryRegionOps pnv_core_power9_xscom_ops = {
* POWER10 core controls
*/
+#define PNV10_XSCOM_EC_CORE_THREAD_STATE0x412
+
static uint64_t pnv_core_power10_xscom_read(void *opaque, hwaddr addr,
unsigned int width)
{
@@ -178,6 +185,9 @@ static uint64_t pnv_core_power10_xscom_read(void *opaque,
hwaddr addr,
uint64_t val = 0;
switch (offset) {
+case PNV10_XSCOM_EC_CORE_THREAD_STATE:
+val = 0;
+break;
default:
qemu_log_mask(LOG_UNIMP, "Warning: reading reg=0x%" HWADDR_PRIx "\n",
addr);
--
2.40.1
[PATCH v2 3/5] ppc/pnv: Add P10 quad xscom model
Add a PnvQuad class for the P10 powernv machine. No xscoms are
implemented yet, but this allows them to be added.
The size is reduced to avoid the quad region from overlapping with the
core region.
address-space: xscom-0
-0003 (prio 0, i/o): xscom-0
0001-0001000f (prio 0, i/o): xscom-quad.0
000100108000-000100907fff (prio 0, i/o): xscom-core.3
00010011-00010090 (prio 0, i/o): xscom-core.2
00010012-00010091 (prio 0, i/o): xscom-core.1
00010014-00010093 (prio 0, i/o): xscom-core.0
Signed-off-by: Joel Stanley
---
v2: Fix unimp read message
Wrap lines at 80 col
Set size
---
include/hw/ppc/pnv_xscom.h | 2 +-
hw/ppc/pnv.c | 2 +-
hw/ppc/pnv_core.c | 54 ++
3 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/include/hw/ppc/pnv_xscom.h b/include/hw/ppc/pnv_xscom.h
index cbe848d27ba0..f7da9a1dc617 100644
--- a/include/hw/ppc/pnv_xscom.h
+++ b/include/hw/ppc/pnv_xscom.h
@@ -129,7 +129,7 @@ struct PnvXScomInterfaceClass {
#define PNV10_XSCOM_EQ_BASE(core) \
((uint64_t) PNV10_XSCOM_EQ(PNV10_XSCOM_EQ_CHIPLET(core)))
-#define PNV10_XSCOM_EQ_SIZE0x10
+#define PNV10_XSCOM_EQ_SIZE0x2
#define PNV10_XSCOM_EC_BASE(core) \
((uint64_t) PNV10_XSCOM_EQ_BASE(core) | PNV10_XSCOM_EC(core & 0x3))
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index c77fdb6747a4..5f25fe985ab2 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1669,7 +1669,7 @@ static void pnv_chip_power10_quad_realize(Pnv10Chip
*chip10, Error **errp)
PnvQuad *eq = &chip10->quads[i];
pnv_chip_quad_realize_one(chip, eq, chip->cores[i * 4],
- PNV_QUAD_TYPE_NAME("power9"));
+ PNV_QUAD_TYPE_NAME("power10"));
pnv_xscom_add_subregion(chip, PNV10_XSCOM_EQ_BASE(eq->quad_id),
&eq->xscom_regs);
diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
index 73d25409c937..e4df435b15e9 100644
--- a/hw/ppc/pnv_core.c
+++ b/hw/ppc/pnv_core.c
@@ -404,6 +404,47 @@ static const MemoryRegionOps pnv_quad_power9_xscom_ops = {
.endianness = DEVICE_BIG_ENDIAN,
};
+/*
+ * POWER10 Quads
+ */
+
+static uint64_t pnv_quad_power10_xscom_read(void *opaque, hwaddr addr,
+unsigned int width)
+{
+uint32_t offset = addr >> 3;
+uint64_t val = -1;
+
+switch (offset) {
+default:
+qemu_log_mask(LOG_UNIMP, "%s: reading @0x%08x\n", __func__,
+ offset);
+}
+
+return val;
+}
+
+static void pnv_quad_power10_xscom_write(void *opaque, hwaddr addr,
+ uint64_t val, unsigned int width)
+{
+uint32_t offset = addr >> 3;
+
+switch (offset) {
+default:
+qemu_log_mask(LOG_UNIMP, "%s: writing @0x%08x\n", __func__,
+ offset);
+}
+}
+
+static const MemoryRegionOps pnv_quad_power10_xscom_ops = {
+.read = pnv_quad_power10_xscom_read,
+.write = pnv_quad_power10_xscom_write,
+.valid.min_access_size = 8,
+.valid.max_access_size = 8,
+.impl.min_access_size = 8,
+.impl.max_access_size = 8,
+.endianness = DEVICE_BIG_ENDIAN,
+};
+
static void pnv_quad_realize(DeviceState *dev, Error **errp)
{
PnvQuad *eq = PNV_QUAD(dev);
@@ -430,6 +471,14 @@ static void pnv_quad_power9_class_init(ObjectClass *oc,
void *data)
pqc->xscom_size = PNV9_XSCOM_EQ_SIZE;
}
+static void pnv_quad_power10_class_init(ObjectClass *oc, void *data)
+{
+PnvQuadClass *pqc = PNV_QUAD_CLASS(oc);
+
+pqc->xscom_ops = &pnv_quad_power10_xscom_ops;
+pqc->xscom_size = PNV10_XSCOM_EQ_SIZE;
+}
+
static void pnv_quad_class_init(ObjectClass *oc, void *data)
{
DeviceClass *dc = DEVICE_CLASS(oc);
@@ -453,6 +502,11 @@ static const TypeInfo pnv_quad_infos[] = {
.name = PNV_QUAD_TYPE_NAME("power9"),
.class_init = pnv_quad_power9_class_init,
},
+{
+.parent = TYPE_PNV_QUAD,
+.name = PNV_QUAD_TYPE_NAME("power10"),
+.class_init = pnv_quad_power10_class_init,
+},
};
DEFINE_TYPES(pnv_quad_infos);
--
2.40.1
Re: [RFC PATCH 1/3] target/ppc: Add LPAR-per-core vs per-thread mode flag
On Thu, 29 Jun 2023 at 02:17, Nicholas Piggin wrote:
>
> The Power ISA has the concept of sub-processors:
>
> Hardware is allowed to sub-divide a multi-threaded processor into
> "sub-processors" that appear to privileged programs as multi-threaded
> processors with fewer threads.
>
> POWER9 and POWER10 have two modes, either every thread is a
> sub-processor or all threads appear as one multi-threaded processor.
> In the user manuals these are known as "LPAR-per-thread" and "LPAR
> per core" (or "1LPAR"), respectively.
>
> The practical difference is in LPAR-per-thread mode, non-hypervisor SPRs
> are not shared between threads and msgsndp can not be used to message
> siblings. In 1LPAR mode some SPRs are shared and msgsndp is usable. LPPT
> allows multiple partitions to run concurrently on the same core,
> and is a requirement for KVM to run on POWER9/10.
>
> Traditionally, SMT in PAPR environments including PowerVM and the
> pseries machine with KVM acceleration beahves as in 1LPAR mode. In
behaves
> OPAL systems, LPAR-per-thread is used. When adding SMT to the powernv
> machine, it is preferable to emulate OPAL LPAR-per-thread, so to
> account for this difference a flag is added and SPRs may become either
> per-thread, per-core shared, or per-LPAR shared. Per-LPAR registers
> become either per-thread or per-core shared depending on the mode.
>
> Signed-off-by: Nicholas Piggin
Nice description.
Reviewed-by: Joel Stanley
As we make the emulation more accurate, we will want the 1LPAR state
to be reflected in the xscoms too.
> ---
> hw/ppc/spapr_cpu_core.c | 2 ++
> target/ppc/cpu.h| 3 +++
> target/ppc/cpu_init.c | 12
> target/ppc/translate.c | 16 +---
> 4 files changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
> index a4e3c2fadd..b482d9754a 100644
> --- a/hw/ppc/spapr_cpu_core.c
> +++ b/hw/ppc/spapr_cpu_core.c
> @@ -270,6 +270,8 @@ static bool spapr_realize_vcpu(PowerPCCPU *cpu,
> SpaprMachineState *spapr,
> env->spr_cb[SPR_PIR].default_value = cs->cpu_index;
> env->spr_cb[SPR_TIR].default_value = thread_index;
>
> +cpu_ppc_set_1lpar(cpu);
> +
> /* Set time-base frequency to 512 MHz. vhyp must be set first. */
> cpu_ppc_tb_init(env, SPAPR_TIMEBASE_FREQ);
>
> diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
> index 94497aa115..beddc5db5b 100644
> --- a/target/ppc/cpu.h
> +++ b/target/ppc/cpu.h
> @@ -674,6 +674,8 @@ enum {
> POWERPC_FLAG_SCV = 0x0020,
> /* Has >1 thread per core
> */
> POWERPC_FLAG_SMT = 0x0040,
> +/* Using "LPAR per core" mode (as opposed to per-thread)
> */
> +POWERPC_FLAG_1LPAR= 0x0080,
> };
>
> /*
> @@ -1435,6 +1437,7 @@ void store_booke_tsr(CPUPPCState *env, target_ulong
> val);
> void ppc_tlb_invalidate_all(CPUPPCState *env);
> void ppc_tlb_invalidate_one(CPUPPCState *env, target_ulong addr);
> void cpu_ppc_set_vhyp(PowerPCCPU *cpu, PPCVirtualHypervisor *vhyp);
> +void cpu_ppc_set_1lpar(PowerPCCPU *cpu);
> int ppcmas_tlb_check(CPUPPCState *env, ppcmas_tlb_t *tlb, hwaddr *raddrp,
> target_ulong address, uint32_t pid);
> int ppcemb_tlb_search(CPUPPCState *env, target_ulong address, uint32_t pid);
> diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c
> index aeff71d063..dc3a65a575 100644
> --- a/target/ppc/cpu_init.c
> +++ b/target/ppc/cpu_init.c
> @@ -6601,6 +6601,18 @@ void cpu_ppc_set_vhyp(PowerPCCPU *cpu,
> PPCVirtualHypervisor *vhyp)
> env->msr_mask &= ~MSR_HVB;
> }
>
> +void cpu_ppc_set_1lpar(PowerPCCPU *cpu)
> +{
> +CPUPPCState *env = &cpu->env;
> +
> +/*
> + * pseries SMT means "LPAR per core" mode, e.g., msgsndp is usable
> + * between threads.
> + */
> +if (env->flags & POWERPC_FLAG_SMT) {
> +env->flags |= POWERPC_FLAG_1LPAR;
> +}
> +}
> #endif /* !defined(CONFIG_USER_ONLY) */
>
> #endif /* defined(TARGET_PPC64) */
> diff --git a/target/ppc/translate.c b/target/ppc/translate.c
> index 372ee600b2..ef186396b4 100644
> --- a/target/ppc/translate.c
> +++ b/target/ppc/translate.c
> @@ -256,6 +256,16 @@ static inline bool gen_serialize_core(DisasContext *ctx)
> }
> #endif
>
> +static inline bool gen_serialize_core_lpar(DisasContext *ctx)
> +{
> +/* 1LPAR implies SMT */
> +if (ctx->flags & POWERPC_FLAG_1LPAR) {
> +return gen_serialize(ctx);
> +}
> +
> +return true;
> +}
> +
>
Re: [PATCH 3/4] ppc/pnv: Add P10 quad ops
On Fri, 30 Jun 2023 at 07:30, Frederic Barrat wrote: > > > > On 30/06/2023 05:55, Joel Stanley wrote: > > diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c > > index b9a57463aec4..7fff2fd9e298 100644 > > --- a/hw/ppc/pnv_core.c > > +++ b/hw/ppc/pnv_core.c > > > +static uint64_t pnv_quad_power10_xscom_read(void *opaque, hwaddr addr, > ... > > +qemu_log_mask(LOG_UNIMP, "%s: writing @0x%08x\n", __func__, > > ^^^ reading > > I'm guessing we'll need to flush out that function pretty soon, so not > worth resending. Thanks, good catch. It's incorrect in the p9 callback too. I had it fixed locally along with a re-wording to make it clear the message was for unimplemented operations, but decided not to send that.
[PATCH 2/4] ppc/pnv: Subclass quad xscom callbacks
Make the existing pnv_quad_xscom_read/write be P9 specific, in
preparation for a different P10 callback.
Signed-off-by: Joel Stanley
---
include/hw/ppc/pnv_core.h | 12 +++-
hw/ppc/pnv.c | 11 +++
hw/ppc/pnv_core.c | 36
3 files changed, 42 insertions(+), 17 deletions(-)
diff --git a/include/hw/ppc/pnv_core.h b/include/hw/ppc/pnv_core.h
index 3d75706e95da..ab3f6d6c2843 100644
--- a/include/hw/ppc/pnv_core.h
+++ b/include/hw/ppc/pnv_core.h
@@ -60,8 +60,18 @@ static inline PnvCPUState *pnv_cpu_state(PowerPCCPU *cpu)
return (PnvCPUState *)cpu->machine_data;
}
+struct PnvQuadClass {
+DeviceClass parent_class;
+
+const MemoryRegionOps *xscom_ops;
+};
+
#define TYPE_PNV_QUAD "powernv-cpu-quad"
-OBJECT_DECLARE_SIMPLE_TYPE(PnvQuad, PNV_QUAD)
+
+#define PNV_QUAD_TYPE_SUFFIX "-" TYPE_PNV_QUAD
+#define PNV_QUAD_TYPE_NAME(cpu_model) cpu_model PNV_QUAD_TYPE_SUFFIX
+
+OBJECT_DECLARE_TYPE(PnvQuad, PnvQuadClass, PNV_QUAD)
struct PnvQuad {
DeviceState parent_obj;
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index fc083173f346..c77fdb6747a4 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1429,14 +1429,15 @@ static void pnv_chip_power9_instance_init(Object *obj)
}
static void pnv_chip_quad_realize_one(PnvChip *chip, PnvQuad *eq,
- PnvCore *pnv_core)
+ PnvCore *pnv_core,
+ const char *type)
{
char eq_name[32];
int core_id = CPU_CORE(pnv_core)->core_id;
snprintf(eq_name, sizeof(eq_name), "eq[%d]", core_id);
object_initialize_child_with_props(OBJECT(chip), eq_name, eq,
- sizeof(*eq), TYPE_PNV_QUAD,
+ sizeof(*eq), type,
&error_fatal, NULL);
object_property_set_int(OBJECT(eq), "quad-id", core_id, &error_fatal);
@@ -1454,7 +1455,8 @@ static void pnv_chip_quad_realize(Pnv9Chip *chip9, Error
**errp)
for (i = 0; i < chip9->nr_quads; i++) {
PnvQuad *eq = &chip9->quads[i];
-pnv_chip_quad_realize_one(chip, eq, chip->cores[i * 4]);
+pnv_chip_quad_realize_one(chip, eq, chip->cores[i * 4],
+ PNV_QUAD_TYPE_NAME("power9"));
pnv_xscom_add_subregion(chip, PNV9_XSCOM_EQ_BASE(eq->quad_id),
&eq->xscom_regs);
@@ -1666,7 +1668,8 @@ static void pnv_chip_power10_quad_realize(Pnv10Chip
*chip10, Error **errp)
for (i = 0; i < chip10->nr_quads; i++) {
PnvQuad *eq = &chip10->quads[i];
-pnv_chip_quad_realize_one(chip, eq, chip->cores[i * 4]);
+pnv_chip_quad_realize_one(chip, eq, chip->cores[i * 4],
+ PNV_QUAD_TYPE_NAME("power9"));
pnv_xscom_add_subregion(chip, PNV10_XSCOM_EQ_BASE(eq->quad_id),
&eq->xscom_regs);
diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
index 0b1c3cccfebc..b9a57463aec4 100644
--- a/hw/ppc/pnv_core.c
+++ b/hw/ppc/pnv_core.c
@@ -407,11 +407,12 @@ static const MemoryRegionOps pnv_quad_power9_xscom_ops = {
static void pnv_quad_realize(DeviceState *dev, Error **errp)
{
PnvQuad *eq = PNV_QUAD(dev);
+PnvQuadClass *pqc = PNV_QUAD_GET_CLASS(eq);
char name[32];
snprintf(name, sizeof(name), "xscom-quad.%d", eq->quad_id);
pnv_xscom_region_init(&eq->xscom_regs, OBJECT(dev),
- &pnv_quad_power9_xscom_ops,
+ pqc->xscom_ops,
eq, name, PNV9_XSCOM_EQ_SIZE);
}
@@ -420,6 +421,13 @@ static Property pnv_quad_properties[] = {
DEFINE_PROP_END_OF_LIST(),
};
+static void pnv_quad_power9_class_init(ObjectClass *oc, void *data)
+{
+PnvQuadClass *pqc = PNV_QUAD_CLASS(oc);
+
+pqc->xscom_ops = &pnv_quad_power9_xscom_ops;
+}
+
static void pnv_quad_class_init(ObjectClass *oc, void *data)
{
DeviceClass *dc = DEVICE_CLASS(oc);
@@ -429,16 +437,20 @@ static void pnv_quad_class_init(ObjectClass *oc, void
*data)
dc->user_creatable = false;
}
-static const TypeInfo pnv_quad_info = {
-.name = TYPE_PNV_QUAD,
-.parent= TYPE_DEVICE,
-.instance_size = sizeof(PnvQuad),
-.class_init= pnv_quad_class_init,
+static const TypeInfo pnv_quad_infos[] = {
+{
+.name = TYPE_PNV_QUAD,
+.parent= TYPE_DEVICE,
+.instance_size = sizeof(PnvQuad),
+.class_size= sizeof(PnvQuadClass),
+.class_init= pnv_quad_class_init,
+.abstract = true,
+},
+{
+.parent = TYPE_PNV_QUAD,
+.name = PNV_QUAD_TYPE_NAME("power9"),
+.class_init = pnv_quad_power9_class_init,
+},
};
-static void pnv_core_register_types(void)
-{
-type_register_static(&pnv_quad_info);
-}
-
-type_init(pnv_core_register_types)
+DEFINE_TYPES(pnv_quad_infos);
--
2.40.1
[PATCH 0/4] ppc/pnv: Extend "quad" model for p10
The quad model implements the EC xscoms for the p9 machine, reusing the
same model for p10 which isn't quite correct. This series adds a PnvQuad
class and subclasses it for P9 and P10. Implement the core thread state
xscom as an example. I expect more function to be implemented in future
patches.
There's one outstanding question. Skiboot has this for the p10 scom:
#define P10_EC_CORE_THREAD_STATE0x412
However the read that comes is for 0x28412. I suspect the upper 0x28000
are addressing bits, so we're really reporting the core thread state for
the given core. Should the model instead wired so one is created for
each chiplet? Or should we report the value for all possible cores, like
the P9 code does for P9X_EX_NCU_SPEC_BAR?
switch (offset) {
case P9X_EX_NCU_SPEC_BAR:
case P9X_EX_NCU_SPEC_BAR + 0x400: /* Second EX */
Joel Stanley (4):
ppc/pnv: quad xscom callbacks are P9 specific
ppc/pnv: Subclass quad xscom callbacks
ppc/pnv: Add P10 quad ops
ppc/pnv: Return zero for core thread state xscom
include/hw/ppc/pnv_core.h | 12 +++-
hw/ppc/pnv.c | 11 ++--
hw/ppc/pnv_core.c | 114 +++---
3 files changed, 113 insertions(+), 24 deletions(-)
--
2.40.1
[PATCH 4/4] ppc/pnv: Return zero for core thread state xscom
Firmware now warns if booting in LPAR per core mode (PPC bit 62). So
this warning doesn't trigger report the core thread state is 0.
Signed-off-by: Joel Stanley
---
hw/ppc/pnv_core.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
index 7fff2fd9e298..98356d7f6538 100644
--- a/hw/ppc/pnv_core.c
+++ b/hw/ppc/pnv_core.c
@@ -116,6 +116,8 @@ static const MemoryRegionOps pnv_core_power8_xscom_ops = {
#define PNV9_XSCOM_EC_PPM_SPECIAL_WKUP_HYP 0xf010d
#define PNV9_XSCOM_EC_PPM_SPECIAL_WKUP_OTR 0xf010a
+#define PNV9_XSCOM_EC_CORE_THREAD_STATE0x10ab3
+
static uint64_t pnv_core_power9_xscom_read(void *opaque, hwaddr addr,
unsigned int width)
{
@@ -134,6 +136,9 @@ static uint64_t pnv_core_power9_xscom_read(void *opaque,
hwaddr addr,
case PNV9_XSCOM_EC_PPM_SPECIAL_WKUP_OTR:
val = 0x0;
break;
+case PNV9_XSCOM_EC_CORE_THREAD_STATE:
+val = 0;
+break;
default:
qemu_log_mask(LOG_UNIMP, "Warning: reading reg=0x%" HWADDR_PRIx "\n",
addr);
@@ -408,6 +413,8 @@ static const MemoryRegionOps pnv_quad_power9_xscom_ops = {
* POWER10 Quads
*/
+#define PNV10_XSCOM_EC_PC_PMC_CORE_THREAD_STATE 0x28412
+
static uint64_t pnv_quad_power10_xscom_read(void *opaque, hwaddr addr,
unsigned int width)
{
@@ -415,6 +422,9 @@ static uint64_t pnv_quad_power10_xscom_read(void *opaque,
hwaddr addr,
uint64_t val = -1;
switch (offset) {
+case PNV10_XSCOM_EC_PC_PMC_CORE_THREAD_STATE:
+val = 0;
+break;
default:
qemu_log_mask(LOG_UNIMP, "%s: writing @0x%08x\n", __func__,
offset);
--
2.40.1
[PATCH 1/4] ppc/pnv: quad xscom callbacks are P9 specific
Rename the to include P9 in the name in preparation for adding P10
versions.
Signed-off-by: Joel Stanley
---
hw/ppc/pnv_core.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
index 0bc3ad41c81c..0b1c3cccfebc 100644
--- a/hw/ppc/pnv_core.c
+++ b/hw/ppc/pnv_core.c
@@ -360,8 +360,8 @@ DEFINE_TYPES(pnv_core_infos)
#define P9X_EX_NCU_SPEC_BAR 0x11010
-static uint64_t pnv_quad_xscom_read(void *opaque, hwaddr addr,
-unsigned int width)
+static uint64_t pnv_quad_power9_xscom_read(void *opaque, hwaddr addr,
+ unsigned int width)
{
uint32_t offset = addr >> 3;
uint64_t val = -1;
@@ -379,8 +379,8 @@ static uint64_t pnv_quad_xscom_read(void *opaque, hwaddr
addr,
return val;
}
-static void pnv_quad_xscom_write(void *opaque, hwaddr addr, uint64_t val,
- unsigned int width)
+static void pnv_quad_power9_xscom_write(void *opaque, hwaddr addr, uint64_t
val,
+unsigned int width)
{
uint32_t offset = addr >> 3;
@@ -394,9 +394,9 @@ static void pnv_quad_xscom_write(void *opaque, hwaddr addr,
uint64_t val,
}
}
-static const MemoryRegionOps pnv_quad_xscom_ops = {
-.read = pnv_quad_xscom_read,
-.write = pnv_quad_xscom_write,
+static const MemoryRegionOps pnv_quad_power9_xscom_ops = {
+.read = pnv_quad_power9_xscom_read,
+.write = pnv_quad_power9_xscom_write,
.valid.min_access_size = 8,
.valid.max_access_size = 8,
.impl.min_access_size = 8,
@@ -410,7 +410,8 @@ static void pnv_quad_realize(DeviceState *dev, Error **errp)
char name[32];
snprintf(name, sizeof(name), "xscom-quad.%d", eq->quad_id);
-pnv_xscom_region_init(&eq->xscom_regs, OBJECT(dev), &pnv_quad_xscom_ops,
+pnv_xscom_region_init(&eq->xscom_regs, OBJECT(dev),
+ &pnv_quad_power9_xscom_ops,
eq, name, PNV9_XSCOM_EQ_SIZE);
}
--
2.40.1
[PATCH 3/4] ppc/pnv: Add P10 quad ops
Add a PnvQuad class for the P10 powernv machine. No xscoms are
implemented yet, but this allows them to be added.
Signed-off-by: Joel Stanley
---
hw/ppc/pnv.c | 2 +-
hw/ppc/pnv_core.c | 53 +++
2 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index c77fdb6747a4..5f25fe985ab2 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1669,7 +1669,7 @@ static void pnv_chip_power10_quad_realize(Pnv10Chip
*chip10, Error **errp)
PnvQuad *eq = &chip10->quads[i];
pnv_chip_quad_realize_one(chip, eq, chip->cores[i * 4],
- PNV_QUAD_TYPE_NAME("power9"));
+ PNV_QUAD_TYPE_NAME("power10"));
pnv_xscom_add_subregion(chip, PNV10_XSCOM_EQ_BASE(eq->quad_id),
&eq->xscom_regs);
diff --git a/hw/ppc/pnv_core.c b/hw/ppc/pnv_core.c
index b9a57463aec4..7fff2fd9e298 100644
--- a/hw/ppc/pnv_core.c
+++ b/hw/ppc/pnv_core.c
@@ -404,6 +404,47 @@ static const MemoryRegionOps pnv_quad_power9_xscom_ops = {
.endianness = DEVICE_BIG_ENDIAN,
};
+/*
+ * POWER10 Quads
+ */
+
+static uint64_t pnv_quad_power10_xscom_read(void *opaque, hwaddr addr,
+unsigned int width)
+{
+uint32_t offset = addr >> 3;
+uint64_t val = -1;
+
+switch (offset) {
+default:
+qemu_log_mask(LOG_UNIMP, "%s: writing @0x%08x\n", __func__,
+ offset);
+}
+
+return val;
+}
+
+static void pnv_quad_power10_xscom_write(void *opaque, hwaddr addr, uint64_t
val,
+ unsigned int width)
+{
+uint32_t offset = addr >> 3;
+
+switch (offset) {
+default:
+qemu_log_mask(LOG_UNIMP, "%s: writing @0x%08x\n", __func__,
+ offset);
+}
+}
+
+static const MemoryRegionOps pnv_quad_power10_xscom_ops = {
+.read = pnv_quad_power10_xscom_read,
+.write = pnv_quad_power10_xscom_write,
+.valid.min_access_size = 8,
+.valid.max_access_size = 8,
+.impl.min_access_size = 8,
+.impl.max_access_size = 8,
+.endianness = DEVICE_BIG_ENDIAN,
+};
+
static void pnv_quad_realize(DeviceState *dev, Error **errp)
{
PnvQuad *eq = PNV_QUAD(dev);
@@ -428,6 +469,13 @@ static void pnv_quad_power9_class_init(ObjectClass *oc,
void *data)
pqc->xscom_ops = &pnv_quad_power9_xscom_ops;
}
+static void pnv_quad_power10_class_init(ObjectClass *oc, void *data)
+{
+PnvQuadClass *pqc = PNV_QUAD_CLASS(oc);
+
+pqc->xscom_ops = &pnv_quad_power10_xscom_ops;
+}
+
static void pnv_quad_class_init(ObjectClass *oc, void *data)
{
DeviceClass *dc = DEVICE_CLASS(oc);
@@ -451,6 +499,11 @@ static const TypeInfo pnv_quad_infos[] = {
.name = PNV_QUAD_TYPE_NAME("power9"),
.class_init = pnv_quad_power9_class_init,
},
+{
+.parent = TYPE_PNV_QUAD,
+.name = PNV_QUAD_TYPE_NAME("power10"),
+.class_init = pnv_quad_power10_class_init,
+},
};
DEFINE_TYPES(pnv_quad_infos);
--
2.40.1
Re: [PATCH] sungem: Add WOL MMIO
On Sun, 25 Jun 2023 at 20:17, Nicholas Piggin wrote:
>
> Apple sungem devices are expected to have WOL MMIO registers.
> Add a region to prevent transaction failures, and implement the
> WOL-disable CSR write because the Linux driver reset writes
> this.
>
> Signed-off-by: Nicholas Piggin
Reviewed-by: Joel Stanley
> ---
> This fixes the failed MMIO error in the Linux sungem driver reset
> when it clears the WOL CSR.
>
> Thanks,
> Nick
>
> hw/net/sungem.c | 52 +
> hw/net/trace-events | 2 ++
> 2 files changed, 54 insertions(+)
>
> diff --git a/hw/net/sungem.c b/hw/net/sungem.c
> index eb01520790..e0e8e5ae41 100644
> --- a/hw/net/sungem.c
> +++ b/hw/net/sungem.c
> @@ -107,6 +107,15 @@ OBJECT_DECLARE_SIMPLE_TYPE(SunGEMState, SUNGEM)
> #define RXDMA_FTAG0x0110UL/* RX FIFO Tag */
> #define RXDMA_FSZ 0x0120UL/* RX FIFO Size */
>
> +/* WOL Registers */
> +#define SUNGEM_MMIO_WOL_SIZE 0x14
> +
> +#define WOL_MATCH00xUL
> +#define WOL_MATCH10x0004UL
> +#define WOL_MATCH20x0008UL
> +#define WOL_MCOUNT0x000CUL
> +#define WOL_WAKECSR 0x0010UL
> +
> /* MAC Registers */
> #define SUNGEM_MMIO_MAC_SIZE 0x200
>
> @@ -168,6 +177,7 @@ OBJECT_DECLARE_SIMPLE_TYPE(SunGEMState, SUNGEM)
> #define SUNGEM_MMIO_PCS_SIZE 0x60
> #define PCS_MIISTAT 0x0004UL/* PCS MII Status Register */
> #define PCS_ISTAT 0x0018UL/* PCS Interrupt Status Reg */
> +
> #define PCS_SSTATE0x005CUL/* Serialink State Register */
>
> /* Descriptors */
> @@ -200,6 +210,7 @@ struct SunGEMState {
> MemoryRegion greg;
> MemoryRegion txdma;
> MemoryRegion rxdma;
> +MemoryRegion wol;
> MemoryRegion mac;
> MemoryRegion mif;
> MemoryRegion pcs;
> @@ -1076,6 +1087,43 @@ static const MemoryRegionOps sungem_mmio_rxdma_ops = {
> },
> };
>
> +static void sungem_mmio_wol_write(void *opaque, hwaddr addr, uint64_t val,
> +unsigned size)
> +{
> +trace_sungem_mmio_wol_write(addr, val);
> +
> +switch (addr) {
> +case WOL_WAKECSR:
> +if (val != 0) {
> +qemu_log_mask(LOG_UNIMP, "sungem: WOL not supported\n");
> +}
> +break;
> +default:
> +qemu_log_mask(LOG_UNIMP, "sungem: WOL not supported\n");
> +}
> +}
> +
> +static uint64_t sungem_mmio_wol_read(void *opaque, hwaddr addr, unsigned
> size)
> +{
> +uint32_t val = -1;
> +
> +qemu_log_mask(LOG_UNIMP, "sungem: WOL not supported\n");
> +
> +trace_sungem_mmio_wol_read(addr, val);
> +
> +return val;
> +}
> +
> +static const MemoryRegionOps sungem_mmio_wol_ops = {
> +.read = sungem_mmio_wol_read,
> +.write = sungem_mmio_wol_write,
> +.endianness = DEVICE_LITTLE_ENDIAN,
> +.impl = {
> +.min_access_size = 4,
> +.max_access_size = 4,
> +},
> +};
> +
> static void sungem_mmio_mac_write(void *opaque, hwaddr addr, uint64_t val,
>unsigned size)
> {
> @@ -1344,6 +1392,10 @@ static void sungem_realize(PCIDevice *pci_dev, Error
> **errp)
>"sungem.rxdma", SUNGEM_MMIO_RXDMA_SIZE);
> memory_region_add_subregion(&s->sungem, 0x4000, &s->rxdma);
>
> +memory_region_init_io(&s->wol, OBJECT(s), &sungem_mmio_wol_ops, s,
> + "sungem.wol", SUNGEM_MMIO_WOL_SIZE);
> +memory_region_add_subregion(&s->sungem, 0x3000, &s->wol);
> +
> memory_region_init_io(&s->mac, OBJECT(s), &sungem_mmio_mac_ops, s,
>"sungem.mac", SUNGEM_MMIO_MAC_SIZE);
> memory_region_add_subregion(&s->sungem, 0x6000, &s->mac);
> diff --git a/hw/net/trace-events b/hw/net/trace-events
> index e4a98b2c7d..930e5b4293 100644
> --- a/hw/net/trace-events
> +++ b/hw/net/trace-events
> @@ -350,6 +350,8 @@ sungem_mmio_txdma_write(uint64_t addr, uint64_t val)
> "MMIO txdma write to 0x%"PR
> sungem_mmio_txdma_read(uint64_t addr, uint64_t val) "MMIO txdma read from
> 0x%"PRIx64" val=0x%"PRIx64
> sungem_mmio_rxdma_write(uint64_t addr, uint64_t val) "MMIO rxdma write to
> 0x%"PRIx64" val=0x%"PRIx64
> sungem_mmio_rxdma_read(uint64_t addr, uint64_t val) "MMIO rxdma read from
> 0x%"PRIx64" val=0x%"PRIx64
> +sungem_mmio_wol_write(uint64_t addr, uint64_t val) "MMIO wol write to
> 0x%"PRIx64" val=0x%"PRIx64
> +sungem_mmio_wol_read(uint64_t addr, uint64_t val) "MMIO wol read from
> 0x%"PRIx64" val=0x%"PRIx64
> sungem_mmio_mac_write(uint64_t addr, uint64_t val) "MMIO mac write to
> 0x%"PRIx64" val=0x%"PRIx64
> sungem_mmio_mac_read(uint64_t addr, uint64_t val) "MMIO mac read from
> 0x%"PRIx64" val=0x%"PRIx64
> sungem_mmio_mif_write(uint64_t addr, uint64_t val) "MMIO mif write to
> 0x%"PRIx64" val=0x%"PRIx64
> --
> 2.40.1
>
>
[PATCH] ppc/pnv/pci: Clean up error messages
The phb error macros add a newline for you, so remove the second one to
avoid double whitespace.
Signed-off-by: Joel Stanley
---
hw/pci-host/pnv_phb4.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c
index 542f9e293221..6232cbeee161 100644
--- a/hw/pci-host/pnv_phb4.c
+++ b/hw/pci-host/pnv_phb4.c
@@ -133,13 +133,13 @@ static void pnv_phb4_rc_config_write(PnvPHB4 *phb,
unsigned off,
PCIDevice *pdev;
if (size != 4) {
-phb_error(phb, "rc_config_write invalid size %d\n", size);
+phb_error(phb, "rc_config_write invalid size %d", size);
return;
}
pdev = pci_find_device(pci->bus, 0, 0);
if (!pdev) {
-phb_error(phb, "rc_config_write device not found\n");
+phb_error(phb, "rc_config_write device not found");
return;
}
@@ -155,13 +155,13 @@ static uint64_t pnv_phb4_rc_config_read(PnvPHB4 *phb,
unsigned off,
uint64_t val;
if (size != 4) {
-phb_error(phb, "rc_config_read invalid size %d\n", size);
+phb_error(phb, "rc_config_read invalid size %d", size);
return ~0ull;
}
pdev = pci_find_device(pci->bus, 0, 0);
if (!pdev) {
-phb_error(phb, "rc_config_read device not found\n");
+phb_error(phb, "rc_config_read device not found");
return ~0ull;
}
@@ -1039,19 +1039,19 @@ static void pnv_pec_stk_nest_xscom_write(void *opaque,
hwaddr addr,
if (phb->nest_regs[PEC_NEST_STK_BAR_EN] &
(PEC_NEST_STK_BAR_EN_MMIO0 |
PEC_NEST_STK_BAR_EN_MMIO1)) {
-phb_pec_error(pec, "Changing enabled BAR unsupported\n");
+phb_pec_error(pec, "Changing enabled BAR unsupported");
}
phb->nest_regs[reg] = val & 0xff00ull;
break;
case PEC_NEST_STK_PHB_REGS_BAR:
if (phb->nest_regs[PEC_NEST_STK_BAR_EN] & PEC_NEST_STK_BAR_EN_PHB) {
-phb_pec_error(pec, "Changing enabled BAR unsupported\n");
+phb_pec_error(pec, "Changing enabled BAR unsupported");
}
phb->nest_regs[reg] = val & 0xffc0ull;
break;
case PEC_NEST_STK_INT_BAR:
if (phb->nest_regs[PEC_NEST_STK_BAR_EN] & PEC_NEST_STK_BAR_EN_INT) {
-phb_pec_error(pec, "Changing enabled BAR unsupported\n");
+phb_pec_error(pec, "Changing enabled BAR unsupported");
}
phb->nest_regs[reg] = val & 0xfff0ull;
break;
--
2.39.2
Re: [kvm-unit-tests v4 00/12] powerpc: updates, P10, PNV support
On Thu, 15 Jun 2023 at 03:02, Nicholas Piggin wrote: > > On Wed Jun 14, 2023 at 11:09 AM AEST, Joel Stanley wrote: > > On Thu, 8 Jun 2023 at 07:58, Nicholas Piggin wrote: > > > > > > Posting again, a couple of patches were merged and accounted for review > > > comments from last time. > > > > I saw some failures in the spr tests running on a power9 powernv system: > > > > $ TESTNAME=sprs TIMEOUT=90s ACCEL= ./powerpc/run powerpc/sprs.elf -smp > > 1 |grep FAIL > > FAIL: WORT ( 895):0xc0deba80 <==> 0x > > This is just TCG machine? I'm not sure why WORT fails, AFAIKS it's the > same on POWER8 and doesn't do anything just a simple register. I think > on real hardware WORT may not have any bits implemented on POWER9 > though. Yeah, just the TCG machine. Now that you point it out all of the failures I reported are for ACCEL=, so they are running in tcg mode. run_migration timeout -k 1s --foreground 90s /usr/bin/qemu-system-ppc64 -nodefaults -machine pseries,accel=tcg -bios powerpc/boot_rom.bin -display none -serial stdio -kernel powerpc/sprs.elf -smp 1 -append -w # -initrd /tmp/tmp.61XhbvCGcb > > > $ MIGRATION=yes TESTNAME=sprs-migration TIMEOUT=90s ACCEL= > > ./powerpc/run powerpc/sprs.elf -smp 1 -append '-w' | grep FAIL > > FAIL: SRR0 ( 26):0xcafefacec0debabc <==> 0x00402244 > > FAIL: SRR1 ( 27):0xc006409ebab6 <==> 0x80001001 > > FAIL: CTRL ( 136):0x <==> 0x8001 > > FAIL: WORT ( 895):0xc0deba80 <==> 0x > > FAIL: PIR (1023):0x0010 <==> 0x0049 > > > > Linux 6.2.0-20-generic > > QEMU emulator version 7.2.0 (Debian 1:7.2+dfsg-5ubuntu2) > > > > On a power8 powernv: > > > > MIGRATION=yes TESTNAME=sprs-migration TIMEOUT=90s ACCEL= ./powerpc/run > > powerpc/sprs.elf -smp 1 -append '-w' |grep FAIL > > FAIL: SRR0 ( 26):0xcafefacec0debabc <==> 0x00402234 > > FAIL: SRR1 ( 27):0xc006409ebab6 <==> 0x80001000 > > FAIL: CTRL ( 136):0x <==> 0x8001 > > FAIL: PIR (1023):0x0060 <==> 0x0030 > > Hmm, seems we take some interrupt over migration test that is not > accounted for (could check the address in SRR0 to see where it is). > Either need to prevent that interrupt or avoid failing on SRR0/1 on > this test. > > Interesting about CTRL, I wonder if that not migrating correctly. > PIR looks like a migration issue as well, it can't be changed so > destination CPU has got a different PIR. I would be inclined to > leave those as failing to remind us to look into them. > > I'll take a look at the others though. > > Thanks, > Nick
Re: [PATCH] hw/timer/nrf51_timer: Don't lose time when timer is queried in tight loop
On Tue, 6 Jun 2023 at 13:49, Peter Maydell wrote: > > The nrf51_timer has a free-running counter which we implement using > the pattern of using two fields (update_counter_ns, counter) to track > the last point at which we calculated the counter value, and the > counter value at that time. Then we can find the current counter > value by converting the difference in wall-clock time between then > and now to a tick count that we need to add to the counter value. > > Unfortunately the nrf51_timer's implementation of this has a bug > which means it loses time every time update_counter() is called. > After updating s->counter it always sets s->update_counter_ns to > 'now', even though the actual point when s->counter hit the new value > will be some point in the past (half a tick, say). In the worst case > (guest code in a tight loop reading the counter, icount mode) the > counter is continually queried less than a tick after it was last > read, so s->counter never advances but s->update_counter_ns does, and > the guest never makes forward progress. > > The fix for this is to only advance update_counter_ns to the > timestamp of the last tick, not all the way to 'now'. (This is the > pattern used in hw/misc/mps2-fpgaio.c's counter.) > > Cc: qemu-sta...@nongnu.org > Signed-off-by: Peter Maydell > --- > The hang in icount mode was discovered by the Zephyr folks as part > of their investigation into > https://github.com/zephyrproject-rtos/zephyr/issues/57512 Did you get an image to test with? Reviewed-by: Joel Stanley > > hw/timer/nrf51_timer.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/hw/timer/nrf51_timer.c b/hw/timer/nrf51_timer.c > index 42be79c7363..50c6772383e 100644 > --- a/hw/timer/nrf51_timer.c > +++ b/hw/timer/nrf51_timer.c > @@ -45,7 +45,12 @@ static uint32_t update_counter(NRF51TimerState *s, int64_t > now) > uint32_t ticks = ns_to_ticks(s, now - s->update_counter_ns); > > s->counter = (s->counter + ticks) % BIT(bitwidths[s->bitmode]); > -s->update_counter_ns = now; > +/* > + * Only advance the sync time to the timestamp of the last tick, > + * not all the way to 'now', so we don't lose time if we do > + * multiple resyncs in a single tick. > + */ > +s->update_counter_ns += ticks_to_ns(s, ticks); > return ticks; We're still returning the number of ticks up to 'now'. Should we instead return the elapsed ticks? If not, we will expire the timer early. Cheers, Joel
Re: [PATCH v2 12/12] target/arm: Allow users to set the number of VFP registers
On Wed, 7 Jun 2023 at 04:40, Cédric Le Goater wrote:
>
> Cortex A7 CPUs with an FPU implementing VFPv4 without NEON support
> have 16 64-bit FPU registers and not 32 registers. Let users set the
> number of VFP registers with a CPU property.
>
> The primary use case of this property is for the Cortex A7 of the
> Aspeed AST2600 SoC.
>
> Signed-off-by: Cédric Le Goater
You saw a crash with a buildroot image without this change, as I recall?
The logic is a bit hard to follow but it is good to see a fix.
Reviewed-by: Joel Stanley
> ---
> target/arm/cpu.h| 2 ++
> hw/arm/aspeed_ast2600.c | 2 ++
> target/arm/cpu.c| 32
> 3 files changed, 36 insertions(+)
>
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index d469a2637b32..79f1a96ddf39 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -916,6 +916,8 @@ struct ArchCPU {
> bool has_pmu;
> /* CPU has VFP */
> bool has_vfp;
> +/* CPU has 32 VFP registers */
> +bool has_vfp_d32;
> /* CPU has Neon */
> bool has_neon;
> /* CPU has M-profile DSP extension */
> diff --git a/hw/arm/aspeed_ast2600.c b/hw/arm/aspeed_ast2600.c
> index 1bf12461481c..a8b3a8065a11 100644
> --- a/hw/arm/aspeed_ast2600.c
> +++ b/hw/arm/aspeed_ast2600.c
> @@ -316,6 +316,8 @@ static void aspeed_soc_ast2600_realize(DeviceState *dev,
> Error **errp)
> &error_abort);
> object_property_set_bool(OBJECT(&s->cpu[i]), "neon", false,
> &error_abort);
> +object_property_set_bool(OBJECT(&s->cpu[i]), "vfp-d32", false,
> +&error_abort);
> object_property_set_link(OBJECT(&s->cpu[i]), "memory",
> OBJECT(s->memory), &error_abort);
>
> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> index 5182ed0c9113..74fe6ae78192 100644
> --- a/target/arm/cpu.c
> +++ b/target/arm/cpu.c
> @@ -1275,6 +1275,9 @@ static Property arm_cpu_cfgend_property =
> static Property arm_cpu_has_vfp_property =
> DEFINE_PROP_BOOL("vfp", ARMCPU, has_vfp, true);
>
> +static Property arm_cpu_has_vfp_d32_property =
> +DEFINE_PROP_BOOL("vfp-d32", ARMCPU, has_vfp_d32, true);
> +
> static Property arm_cpu_has_neon_property =
> DEFINE_PROP_BOOL("neon", ARMCPU, has_neon, true);
>
> @@ -1406,6 +1409,22 @@ void arm_cpu_post_init(Object *obj)
> }
> }
>
> +if (cpu->has_vfp && cpu_isar_feature(aa32_simd_r32, cpu)) {
> +cpu->has_vfp_d32 = true;
> +if (!kvm_enabled()) {
> +/*
> + * The permitted values of the SIMDReg bits [3:0] on
> + * Armv8-A are either 0b and 0b0010. On such CPUs,
> + * make sure that has_vfp_d32 can not be set to false.
> + */
> +if (!(arm_feature(&cpu->env, ARM_FEATURE_V8) &&
> + !arm_feature(&cpu->env, ARM_FEATURE_M))) {
> +qdev_property_add_static(DEVICE(obj),
> + &arm_cpu_has_vfp_d32_property);
> +}
> +}
> +}
> +
> if (arm_feature(&cpu->env, ARM_FEATURE_NEON)) {
> cpu->has_neon = true;
> if (!kvm_enabled()) {
> @@ -1672,6 +1691,19 @@ static void arm_cpu_realizefn(DeviceState *dev, Error
> **errp)
> return;
> }
>
> +if (cpu->has_vfp_d32 != cpu->has_neon) {
> +error_setg(errp, "ARM CPUs must have both VFP-D32 and Neon or
> neither");
> +return;
> +}
> +
> + if (!cpu->has_vfp_d32) {
> +uint32_t u;
> +
> +u = cpu->isar.mvfr0;
> +u = FIELD_DP32(u, MVFR0, SIMDREG, 1); /* 16 registers */
> +cpu->isar.mvfr0 = u;
> +}
> +
> if (!cpu->has_vfp) {
> uint64_t t;
> uint32_t u;
> --
> 2.40.1
>
Re: [PATCH v2 11/12] aspeed: Introduce a "bmc-console" machine option
On Wed, 7 Jun 2023 at 04:40, Cédric Le Goater wrote:
>
> Most of the Aspeed machines use the UART5 device for the boot console,
> and QEMU connects the first serial Chardev to this SoC device for this
> purpose. See routine connect_serial_hds_to_uarts().
>
> Nevertheless, some machines use another boot console, such as the fuji,
> and commit 5d63d0c76c ("hw/arm/aspeed: Allow machine to set UART
> default") introduced a SoC class attribute 'uart_default' and property
> to be able to change the boot console device. It was later changed by
> commit d2b3eaefb4 ("aspeed: Refactor UART init for multi-SoC machines").
>
> The "bmc-console" machine option goes a step further and lets the user define
> the UART device from the QEMU command line without introducing a new
> machine definition. For instance, to use device UART3 (mapped on
> /dev/ttyS2 under Linux) instead of the default UART5, one would use :
>
> -M ast2500-evb,bmc-console=uart3
>
> Cc: Abhishek Singh Dagur
> Signed-off-by: Cédric Le Goater
Reviewed-by: Joel Stanley
> ---
> docs/system/arm/aspeed.rst | 11 +++
> hw/arm/aspeed.c| 40 --
> 2 files changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/docs/system/arm/aspeed.rst b/docs/system/arm/aspeed.rst
> index d4e293e7f986..80538422a1a4 100644
> --- a/docs/system/arm/aspeed.rst
> +++ b/docs/system/arm/aspeed.rst
> @@ -122,6 +122,11 @@ Options specific to Aspeed machines are :
>
> * ``spi-model`` to change the SPI Flash model.
>
> + * ``bmc-console`` to change the default console device. Most of the
> + machines use the ``UART5`` device for a boot console, which is
> + mapped on ``/dev/ttyS4`` under Linux, but it is not always the
> + case.
> +
> For instance, to start the ``ast2500-evb`` machine with a different
> FMC chip and a bigger (64M) SPI chip, use :
>
> @@ -129,6 +134,12 @@ FMC chip and a bigger (64M) SPI chip, use :
>
>-M ast2500-evb,fmc-model=mx25l25635e,spi-model=mx66u51235f
>
> +To change the boot console and use device ``UART3`` (``/dev/ttyS2``
> +under Linux), use :
> +
> +.. code-block:: bash
> +
> + -M ast2500-evb,bmc-console=uart3
>
> Aspeed minibmc family boards (``ast1030-evb``)
> ==
> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
> index 8beed0c2a66e..d3e58936e68a 100644
> --- a/hw/arm/aspeed.c
> +++ b/hw/arm/aspeed.c
> @@ -43,6 +43,7 @@ struct AspeedMachineState {
> AspeedSoCState soc;
> MemoryRegion boot_rom;
> bool mmio_exec;
> +uint32_t uart_chosen;
> char *fmc_model;
> char *spi_model;
> };
> @@ -331,10 +332,11 @@ static void
> connect_serial_hds_to_uarts(AspeedMachineState *bmc)
> AspeedMachineClass *amc = ASPEED_MACHINE_GET_CLASS(bmc);
> AspeedSoCState *s = &bmc->soc;
> AspeedSoCClass *sc = ASPEED_SOC_GET_CLASS(s);
> +int uart_chosen = bmc->uart_chosen ? bmc->uart_chosen :
> amc->uart_default;
>
> -aspeed_soc_uart_set_chr(s, amc->uart_default, serial_hd(0));
> +aspeed_soc_uart_set_chr(s, uart_chosen, serial_hd(0));
> for (int i = 1, uart = ASPEED_DEV_UART1; i < sc->uarts_num; i++, uart++)
> {
> -if (uart == amc->uart_default) {
> +if (uart == uart_chosen) {
> continue;
> }
> aspeed_soc_uart_set_chr(s, uart, serial_hd(i));
> @@ -1079,6 +1081,35 @@ static void aspeed_set_spi_model(Object *obj, const
> char *value, Error **errp)
> bmc->spi_model = g_strdup(value);
> }
>
> +static char *aspeed_get_bmc_console(Object *obj, Error **errp)
> +{
> +AspeedMachineState *bmc = ASPEED_MACHINE(obj);
> +AspeedMachineClass *amc = ASPEED_MACHINE_GET_CLASS(bmc);
> +int uart_chosen = bmc->uart_chosen ? bmc->uart_chosen :
> amc->uart_default;
> +
> +return g_strdup_printf("uart%d", uart_chosen - ASPEED_DEV_UART1 + 1);
> +}
> +
> +static void aspeed_set_bmc_console(Object *obj, const char *value, Error
> **errp)
> +{
> +AspeedMachineState *bmc = ASPEED_MACHINE(obj);
> +AspeedMachineClass *amc = ASPEED_MACHINE_GET_CLASS(bmc);
> +AspeedSoCClass *sc =
> ASPEED_SOC_CLASS(object_class_by_name(amc->soc_name));
> +int val;
> +
> +if (sscanf(value, "uart%u", &val) != 1) {
> +error_setg(errp, "Bad value for \"uart\" property");
> +return;
> +}
> +
> +/* The number of UART depends on the SoC */
> +if (val < 1 || val > sc->uarts_num) {
> +error_setg(errp, "\"uart\"
Re: [PATCH v2 10/12] aspeed: Get the BlockBackend of FMC0 from the flash device
On Wed, 7 Jun 2023 at 04:40, Cédric Le Goater wrote:
>
> and get rid of an unnecessary drive_get(IF_MTD) call.
>
> Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Cédric Le Goater
Reviewed-by: Joel Stanley
> ---
> hw/arm/aspeed.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
> index efc112ca37b0..8beed0c2a66e 100644
> --- a/hw/arm/aspeed.c
> +++ b/hw/arm/aspeed.c
> @@ -15,6 +15,7 @@
> #include "hw/arm/aspeed.h"
> #include "hw/arm/aspeed_soc.h"
> #include "hw/arm/aspeed_eeprom.h"
> +#include "hw/block/flash.h"
> #include "hw/i2c/i2c_mux_pca954x.h"
> #include "hw/i2c/smbus_eeprom.h"
> #include "hw/misc/pca9552.h"
> @@ -427,11 +428,12 @@ static void aspeed_machine_init(MachineState *machine)
> }
>
> if (!bmc->mmio_exec) {
> -DriveInfo *mtd0 = drive_get(IF_MTD, 0, 0);
> +DeviceState *dev = ssi_get_cs(bmc->soc.fmc.spi, 0);
> +BlockBackend *fmc0 = dev ? m25p80_get_blk(dev) : NULL;
>
> -if (mtd0) {
> +if (fmc0) {
> uint64_t rom_size = memory_region_size(&bmc->soc.spi_boot);
> -aspeed_install_boot_rom(bmc, blk_by_legacy_dinfo(mtd0),
> rom_size);
> +aspeed_install_boot_rom(bmc, fmc0, rom_size);
> }
> }
>
> --
> 2.40.1
>
Re: [PATCH v2 09/12] m25p80: Introduce an helper to retrieve the BlockBackend of a device
On Wed, 7 Jun 2023 at 04:40, Cédric Le Goater wrote:
>
> It will help in getting rid of some drive_get(IF_MTD) calls by
> retrieving the BlockBackend directly from the m25p80 device.
>
> Cc: Alistair Francis
> Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Cédric Le Goater
One suggestion below after reading patch 10.
Reviewed-by: Joel Stanley
> ---
> include/hw/block/flash.h | 4
> hw/block/m25p80.c| 6 ++
> 2 files changed, 10 insertions(+)
>
> diff --git a/include/hw/block/flash.h b/include/hw/block/flash.h
> index 7198953702b7..de93756cbe8f 100644
> --- a/include/hw/block/flash.h
> +++ b/include/hw/block/flash.h
> @@ -76,4 +76,8 @@ uint8_t ecc_digest(ECCState *s, uint8_t sample);
> void ecc_reset(ECCState *s);
> extern const VMStateDescription vmstate_ecc_state;
>
> +/* m25p80.c */
> +
> +BlockBackend *m25p80_get_blk(DeviceState *dev);
> +
> #endif
> diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
> index dc5ffbc4ff52..afc3fdf4d60b 100644
> --- a/hw/block/m25p80.c
> +++ b/hw/block/m25p80.c
> @@ -25,6 +25,7 @@
> #include "qemu/units.h"
> #include "sysemu/block-backend.h"
> #include "hw/block/block.h"
> +#include "hw/block/flash.h"
> #include "hw/qdev-properties.h"
> #include "hw/qdev-properties-system.h"
> #include "hw/ssi/ssi.h"
> @@ -1830,3 +1831,8 @@ static void m25p80_register_types(void)
> }
>
> type_init(m25p80_register_types)
> +
> +BlockBackend *m25p80_get_blk(DeviceState *dev)
> +{
> +return M25P80(dev)->blk;
Is it qemu convention for the caller to do the null check on dev, or
should it go in this helper?
> +}
> --
> 2.40.1
>
Re: [PATCH v2 07/12] hw/ssi: Check for duplicate addresses
On Wed, 7 Jun 2023 at 04:40, Cédric Le Goater wrote:
>
> This to avoid address conflicts on the same SSI bus. Adapt machines
> using multiple devices on the same bus to avoid breakage.
>
> Cc: "Edgar E. Iglesias"
> Cc: Alistair Francis
> Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Cédric Le Goater
One small suggestion below that we could do as a follow up.
Reviewed-by: Joel Stanley
> ---
> hw/arm/stellaris.c | 4 +++-
> hw/arm/xilinx_zynq.c| 1 +
> hw/arm/xlnx-versal-virt.c | 1 +
> hw/arm/xlnx-zcu102.c| 2 ++
> hw/microblaze/petalogix_ml605_mmu.c | 1 +
> hw/ssi/ssi.c| 21 +
> 6 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/hw/arm/stellaris.c b/hw/arm/stellaris.c
> index f7e99baf6236..6744571d55f4 100644
> --- a/hw/arm/stellaris.c
> +++ b/hw/arm/stellaris.c
> @@ -1242,7 +1242,9 @@ static void stellaris_init(MachineState *ms,
> stellaris_board_info *board)
> qdev_get_child_bus(sddev, "sd-bus"),
> &error_fatal);
>
> -ssddev = ssi_create_peripheral(bus, "ssd0323");
Should we update ssi_create_peripheral to make the chip select explicit?
> +ssddev = qdev_new("ssd0323");
> +qdev_prop_set_uint8(ssddev, "addr", 1);
> +qdev_realize_and_unref(ssddev, bus, &error_fatal);
>
> gpio_d_splitter = qdev_new(TYPE_SPLIT_IRQ);
> qdev_prop_set_uint32(gpio_d_splitter, "num-lines", 2);
> diff --git a/hw/arm/xilinx_zynq.c b/hw/arm/xilinx_zynq.c
> index 3190cc0b8dbc..28e9df684213 100644
> --- a/hw/arm/xilinx_zynq.c
> +++ b/hw/arm/xilinx_zynq.c
> @@ -164,6 +164,7 @@ static inline int zynq_init_spi_flashes(uint32_t
> base_addr, qemu_irq irq,
> blk_by_legacy_dinfo(dinfo),
> &error_fatal);
> }
> +qdev_prop_set_uint8(flash_dev, "addr", j);
> qdev_realize_and_unref(flash_dev, BUS(spi), &error_fatal);
>
> cs_line = qdev_get_gpio_in_named(flash_dev, SSI_GPIO_CS, 0);
> diff --git a/hw/arm/xlnx-versal-virt.c b/hw/arm/xlnx-versal-virt.c
> index 668a9d65a437..c90345375090 100644
> --- a/hw/arm/xlnx-versal-virt.c
> +++ b/hw/arm/xlnx-versal-virt.c
> @@ -701,6 +701,7 @@ static void versal_virt_init(MachineState *machine)
> qdev_prop_set_drive_err(flash_dev, "drive",
> blk_by_legacy_dinfo(dinfo),
> &error_fatal);
> }
> +qdev_prop_set_uint8(flash_dev, "addr", i);
> qdev_realize_and_unref(flash_dev, spi_bus, &error_fatal);
>
> cs_line = qdev_get_gpio_in_named(flash_dev, SSI_GPIO_CS, 0);
> diff --git a/hw/arm/xlnx-zcu102.c b/hw/arm/xlnx-zcu102.c
> index 4c84bb932aa0..6224b8fc1110 100644
> --- a/hw/arm/xlnx-zcu102.c
> +++ b/hw/arm/xlnx-zcu102.c
> @@ -201,6 +201,7 @@ static void xlnx_zcu102_init(MachineState *machine)
> qdev_prop_set_drive_err(flash_dev, "drive",
> blk_by_legacy_dinfo(dinfo),
> &error_fatal);
> }
> +qdev_prop_set_uint8(flash_dev, "addr", i);
> qdev_realize_and_unref(flash_dev, spi_bus, &error_fatal);
>
> cs_line = qdev_get_gpio_in_named(flash_dev, SSI_GPIO_CS, 0);
> @@ -224,6 +225,7 @@ static void xlnx_zcu102_init(MachineState *machine)
> qdev_prop_set_drive_err(flash_dev, "drive",
> blk_by_legacy_dinfo(dinfo),
> &error_fatal);
> }
> +qdev_prop_set_uint8(flash_dev, "addr", i);
> qdev_realize_and_unref(flash_dev, spi_bus, &error_fatal);
>
> cs_line = qdev_get_gpio_in_named(flash_dev, SSI_GPIO_CS, 0);
> diff --git a/hw/microblaze/petalogix_ml605_mmu.c
> b/hw/microblaze/petalogix_ml605_mmu.c
> index a24fadddcac0..4c5e4510c333 100644
> --- a/hw/microblaze/petalogix_ml605_mmu.c
> +++ b/hw/microblaze/petalogix_ml605_mmu.c
> @@ -192,6 +192,7 @@ petalogix_ml605_init(MachineState *machine)
> blk_by_legacy_dinfo(dinfo),
> &error_fatal);
> }
> +qdev_prop_set_uint8(dev, "addr", i);
> qdev_realize_and_unref(dev, BUS(spi), &error_fatal);
>
> cs_line = qdev_get_gpio_in_named(dev, SSI_GPIO_CS, 0);
> diff --git a/hw/ssi/ssi.c b/hw/ssi/ssi.c
> index 7c71fce0db90.
Re: [PATCH v2 06/12] aspeed/smc: Wire CS lines at reset
On Wed, 7 Jun 2023 at 04:40, Cédric Le Goater wrote:
>
> Currently, a set of default flash devices is created at machine init
> and drives defined on the QEMU command line are associated to the FMC
> and SPI controllers in sequence :
>
>-drive file,format=raw,if=mtd
>-drive file,format=raw,if=mtd
>
> The CS lines are wired in the same creation loop. This makes a strong
> assumption on the ordering and is not very flexible since only a
> limited set of flash devices can be defined : 1 FMC + 1 or 2 SPI,
> which is less than what the SoC really supports.
>
> A better alternative would be to define the flash devices on the
> command line using a blockdev attached to a CS line of a SSI bus :
>
> -blockdev node-name=fmc0,driver=file,filename=./flash.img
> -device mx66u51235f,addr=0x0,bus=ssi.0,drive=fmc0
I don't like the idea of making the command line more complicated.
That is not a comment on this patch though, but it would be nice if we
could head towards decreasing the complexity.
> However, user created flash devices are not correctly wired to their
> SPI controller and consequently can not be used by the machine. Fix
> that and wire the CS lines of all available devices when the SSI bus
> is reset.
>
> Signed-off-by: Cédric Le Goater
Reviewed-by: Joel Stanley
> ---
> hw/arm/aspeed.c | 5 +
> hw/ssi/aspeed_smc.c | 8
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
> index 76a1e7303de1..e5a49bb0b1a7 100644
> --- a/hw/arm/aspeed.c
> +++ b/hw/arm/aspeed.c
> @@ -299,17 +299,14 @@ void aspeed_board_init_flashes(AspeedSMCState *s, const
> char *flashtype,
>
> for (i = 0; i < count; ++i) {
> DriveInfo *dinfo = drive_get(IF_MTD, 0, unit0 + i);
> -qemu_irq cs_line;
> DeviceState *dev;
>
> dev = qdev_new(flashtype);
> if (dinfo) {
> qdev_prop_set_drive(dev, "drive", blk_by_legacy_dinfo(dinfo));
> }
> +qdev_prop_set_uint8(dev, "addr", i);
> qdev_realize_and_unref(dev, BUS(s->spi), &error_fatal);
> -
> -cs_line = qdev_get_gpio_in_named(dev, SSI_GPIO_CS, 0);
> -qdev_connect_gpio_out_named(DEVICE(s), "cs", i, cs_line);
> }
> }
>
> diff --git a/hw/ssi/aspeed_smc.c b/hw/ssi/aspeed_smc.c
> index 72811693224d..2a4001b774a2 100644
> --- a/hw/ssi/aspeed_smc.c
> +++ b/hw/ssi/aspeed_smc.c
> @@ -692,6 +692,14 @@ static void aspeed_smc_reset(DeviceState *d)
> memset(s->regs, 0, sizeof s->regs);
> }
>
> +for (i = 0; i < asc->cs_num_max; i++) {
> +DeviceState *dev = ssi_get_cs(s->spi, i);
> +if (dev) {
> +qemu_irq cs_line = qdev_get_gpio_in_named(dev, SSI_GPIO_CS, 0);
> +qdev_connect_gpio_out_named(DEVICE(s), "cs", i, cs_line);
> +}
> +}
> +
> /* Unselect all peripherals */
> for (i = 0; i < asc->cs_num_max; ++i) {
> s->regs[s->r_ctrl0 + i] |= CTRL_CE_STOP_ACTIVE;
> --
> 2.40.1
>
Re: [PATCH v2 05/12] hw/ssi: Introduce a ssi_get_cs() helper
On Wed, 7 Jun 2023 at 04:40, Cédric Le Goater wrote:
>
> Simple routine to retrieve a DeviceState object on a SPI bus using its
> address/cs. It will be useful for the board to wire the CS lines.
>
> Cc: Alistair Francis
> Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Cédric Le Goater
Reviewed-by: Joel Stanley
> ---
> include/hw/ssi/ssi.h | 2 ++
> hw/ssi/ssi.c | 15 +++
> 2 files changed, 17 insertions(+)
>
> diff --git a/include/hw/ssi/ssi.h b/include/hw/ssi/ssi.h
> index 9e0706a5248c..01662521b09a 100644
> --- a/include/hw/ssi/ssi.h
> +++ b/include/hw/ssi/ssi.h
> @@ -112,4 +112,6 @@ SSIBus *ssi_create_bus(DeviceState *parent, const char
> *name);
>
> uint32_t ssi_transfer(SSIBus *bus, uint32_t val);
>
> +DeviceState *ssi_get_cs(SSIBus *bus, uint8_t addr);
> +
> #endif
> diff --git a/hw/ssi/ssi.c b/hw/ssi/ssi.c
> index d4409535429c..7c71fce0db90 100644
> --- a/hw/ssi/ssi.c
> +++ b/hw/ssi/ssi.c
> @@ -27,6 +27,21 @@ struct SSIBus {
> #define TYPE_SSI_BUS "SSI"
> OBJECT_DECLARE_SIMPLE_TYPE(SSIBus, SSI_BUS)
>
> +DeviceState *ssi_get_cs(SSIBus *bus, uint8_t addr)
> +{
> +BusState *b = BUS(bus);
> +BusChild *kid;
> +
> +QTAILQ_FOREACH(kid, &b->children, sibling) {
> +SSIPeripheral *kid_ssi = SSI_PERIPHERAL(kid->child);
> +if (kid_ssi->addr == addr) {
> +return kid->child;
> +}
> +}
> +
> +return NULL;
> +}
> +
> static const TypeInfo ssi_bus_info = {
> .name = TYPE_SSI_BUS,
> .parent = TYPE_BUS,
> --
> 2.40.1
>
Re: [PATCH v2 04/12] hw/ssi: Add an "addr" property to SSIPeripheral
On Wed, 7 Jun 2023 at 04:40, Cédric Le Goater wrote:
>
> Boards will use this new property to identify the device CS line and
> wire the SPI controllers accordingly.
"addr" and not "cs" or even "chip-select"?
Reviewed-by: Joel Stanley
>
> Cc: Alistair Francis
> Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Cédric Le Goater
> ---
> include/hw/ssi/ssi.h | 3 +++
> hw/ssi/ssi.c | 7 +++
> 2 files changed, 10 insertions(+)
>
> diff --git a/include/hw/ssi/ssi.h b/include/hw/ssi/ssi.h
> index 6950f86810d3..9e0706a5248c 100644
> --- a/include/hw/ssi/ssi.h
> +++ b/include/hw/ssi/ssi.h
> @@ -64,6 +64,9 @@ struct SSIPeripheral {
>
> /* Chip select state */
> bool cs;
> +
> +/* Chip select address/index */
> +uint8_t addr;
> };
>
> extern const VMStateDescription vmstate_ssi_peripheral;
> diff --git a/hw/ssi/ssi.c b/hw/ssi/ssi.c
> index d54a109beeb5..d4409535429c 100644
> --- a/hw/ssi/ssi.c
> +++ b/hw/ssi/ssi.c
> @@ -13,6 +13,7 @@
> */
>
> #include "qemu/osdep.h"
> +#include "hw/qdev-properties.h"
> #include "hw/ssi/ssi.h"
> #include "migration/vmstate.h"
> #include "qemu/module.h"
> @@ -71,6 +72,11 @@ static void ssi_peripheral_realize(DeviceState *dev, Error
> **errp)
> ssc->realize(s, errp);
> }
>
> +static Property ssi_peripheral_properties[] = {
> +DEFINE_PROP_UINT8("addr", SSIPeripheral, addr, 0),
> +DEFINE_PROP_END_OF_LIST(),
> +};
> +
> static void ssi_peripheral_class_init(ObjectClass *klass, void *data)
> {
> SSIPeripheralClass *ssc = SSI_PERIPHERAL_CLASS(klass);
> @@ -81,6 +87,7 @@ static void ssi_peripheral_class_init(ObjectClass *klass,
> void *data)
> if (!ssc->transfer_raw) {
> ssc->transfer_raw = ssi_transfer_raw_default;
> }
> +device_class_set_props(dc, ssi_peripheral_properties);
> }
>
> static const TypeInfo ssi_peripheral_info = {
> --
> 2.40.1
>
Re: [PATCH v2 03/12] aspeed: Use the boot_rom region of the fby35 machine
On Wed, 7 Jun 2023 at 04:40, Cédric Le Goater wrote:
>
> This change completes commits 5aa281d757 ("aspeed: Introduce a
> spi_boot region under the SoC") and 8b744a6a47 ("aspeed: Add a
> boot_rom overlap region in the SoC spi_boot container") which
> introduced a spi_boot container at the SoC level to map the boot rom
> region as an overlap.
>
> It also fixes a Coverity report (CID 1508061) for a memory leak
> warning when the QEMU process exits by using an bmc_boot_rom
> MemoryRegion available at the machine level.
>
> Cc: Peter Delevoryas
> Signed-off-by: Cédric Le Goater
Reviewed-by: Joel Stanley
> ---
> hw/arm/fby35.c | 29 +++--
> 1 file changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/hw/arm/fby35.c b/hw/arm/fby35.c
> index f4600c290b62..f2ff6c1abfd9 100644
> --- a/hw/arm/fby35.c
> +++ b/hw/arm/fby35.c
> @@ -70,8 +70,6 @@ static void fby35_bmc_write_boot_rom(DriveInfo *dinfo,
> MemoryRegion *mr,
>
> static void fby35_bmc_init(Fby35State *s)
> {
> -DriveInfo *drive0 = drive_get(IF_MTD, 0, 0);
> -
> object_initialize_child(OBJECT(s), "bmc", &s->bmc, "ast2600-a3");
>
> memory_region_init(&s->bmc_memory, OBJECT(&s->bmc), "bmc-memory",
> @@ -95,18 +93,21 @@ static void fby35_bmc_init(Fby35State *s)
> aspeed_board_init_flashes(&s->bmc.fmc, "n25q00", 2, 0);
>
> /* Install first FMC flash content as a boot rom. */
> -if (drive0) {
> -AspeedSMCFlash *fl = &s->bmc.fmc.flashes[0];
> -MemoryRegion *boot_rom = g_new(MemoryRegion, 1);
> -uint64_t size = memory_region_size(&fl->mmio);
> -
> -if (!s->mmio_exec) {
> -memory_region_init_rom(boot_rom, NULL, "aspeed.boot_rom",
> - size, &error_abort);
> -memory_region_add_subregion(&s->bmc_memory,
> FBY35_BMC_FIRMWARE_ADDR,
> -boot_rom);
> -fby35_bmc_write_boot_rom(drive0, boot_rom,
> FBY35_BMC_FIRMWARE_ADDR,
> - size, &error_abort);
> +if (!s->mmio_exec) {
> +DriveInfo *mtd0 = drive_get(IF_MTD, 0, 0);
> +
> +if (mtd0) {
> +AspeedSoCState *bmc = &s->bmc;
> +uint64_t rom_size = memory_region_size(&bmc->spi_boot);
> +
> +memory_region_init_rom(&s->bmc_boot_rom, NULL, "aspeed.boot_rom",
> + rom_size, &error_abort);
> +memory_region_add_subregion_overlap(&bmc->spi_boot_container, 0,
> +&s->bmc_boot_rom, 1);
> +
> +fby35_bmc_write_boot_rom(mtd0, &s->bmc_boot_rom,
> + FBY35_BMC_FIRMWARE_ADDR,
> + rom_size, &error_abort);
> }
> }
> }
> --
> 2.40.1
>
Re: [PATCH v2 02/12] aspeed: Introduce a boot_rom region at the machine level
On Wed, 7 Jun 2023 at 04:40, Cédric Le Goater wrote:
>
> This should also avoid Coverity to report a memory leak warning when
> the QEMU process exits. See CID 1508061.
Ok, so now our layout is this if booted with a mtd device (rainier-bmc):
address-space: memory
- (prio 0, i/o): system
-0fff (prio 0, i/o): aspeed.spi_boot_container
-07ff (prio 1, rom): aspeed.boot_rom
-07ff (prio 0, i/o): alias
aspeed.spi_boot @aspeed.smc.flash.0 -07ff
Reviewed-by: Joel Stanley
>
> Reviewed-by: Francisco Iglesias
> Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Cédric Le Goater
> ---
> hw/arm/aspeed.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
> index bfc2070bd2ed..76a1e7303de1 100644
> --- a/hw/arm/aspeed.c
> +++ b/hw/arm/aspeed.c
> @@ -40,6 +40,7 @@ struct AspeedMachineState {
> /* Public */
>
> AspeedSoCState soc;
> +MemoryRegion boot_rom;
> bool mmio_exec;
> char *fmc_model;
> char *spi_model;
> @@ -275,15 +276,15 @@ static void write_boot_rom(BlockBackend *blk, hwaddr
> addr, size_t rom_size,
> * Create a ROM and copy the flash contents at the expected address
> * (0x0). Boots faster than execute-in-place.
> */
> -static void aspeed_install_boot_rom(AspeedSoCState *soc, BlockBackend *blk,
> +static void aspeed_install_boot_rom(AspeedMachineState *bmc, BlockBackend
> *blk,
> uint64_t rom_size)
> {
> -MemoryRegion *boot_rom = g_new(MemoryRegion, 1);
> +AspeedSoCState *soc = &bmc->soc;
>
> -memory_region_init_rom(boot_rom, NULL, "aspeed.boot_rom", rom_size,
> +memory_region_init_rom(&bmc->boot_rom, NULL, "aspeed.boot_rom", rom_size,
> &error_abort);
> memory_region_add_subregion_overlap(&soc->spi_boot_container, 0,
> -boot_rom, 1);
> +&bmc->boot_rom, 1);
> write_boot_rom(blk, ASPEED_SOC_SPI_BOOT_ADDR, rom_size, &error_abort);
> }
>
> @@ -431,8 +432,7 @@ static void aspeed_machine_init(MachineState *machine)
>
> if (mtd0) {
> uint64_t rom_size = memory_region_size(&bmc->soc.spi_boot);
> -aspeed_install_boot_rom(&bmc->soc, blk_by_legacy_dinfo(mtd0),
> -rom_size);
> +aspeed_install_boot_rom(bmc, blk_by_legacy_dinfo(mtd0),
> rom_size);
> }
> }
>
> --
> 2.40.1
>
Re: [PATCH v2 01/12] aspeed/hace: Initialize g_autofree pointer
On Wed, 7 Jun 2023 at 04:40, Cédric Le Goater wrote:
>
> As mentioned in docs/devel/style.rst "Automatic memory deallocation":
>
> * Variables declared with g_auto* MUST always be initialized,
> otherwise the cleanup function will use uninitialized stack memory
>
> This avoids QEMU to coredump when running the "hash test" command
> under Zephyr.
Reviewed-by: Joel Stanley
Was never a fan of using this magic :)
>
> Cc: Steven Lee
> Cc: Joel Stanley
> Cc: qemu-sta...@nongnu.org
> Fixes: c5475b3f9a ("hw: Model ASPEED's Hash and Crypto Engine")
> Reviewed-by: Philippe Mathieu-Daudé
> Reviewed-by: Alex Bennée
> Reviewed-by: Thomas Huth
> Reviewed-by: Francisco Iglesias
> Message-Id: <20230421131547.2177449-1-...@kaod.org>
> Signed-off-by: Cédric Le Goater
> ---
> hw/misc/aspeed_hace.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/misc/aspeed_hace.c b/hw/misc/aspeed_hace.c
> index 12a761f1f55d..b07506ec04ef 100644
> --- a/hw/misc/aspeed_hace.c
> +++ b/hw/misc/aspeed_hace.c
> @@ -189,7 +189,7 @@ static void do_hash_operation(AspeedHACEState *s, int
> algo, bool sg_mode,
>bool acc_mode)
> {
> struct iovec iov[ASPEED_HACE_MAX_SG];
> -g_autofree uint8_t *digest_buf;
> +g_autofree uint8_t *digest_buf = NULL;
> size_t digest_len = 0;
> int niov = 0;
> int i;
> --
> 2.40.1
>
Re: [PATCH] tests/avocado/tuxrun_baselines: Fix ppc64 tests for binaries without slirp
On Tue, 6 Jun 2023 at 19:28, Thomas Huth wrote:
>
> The ppc64 tuxrun tests are currently failing if "slirp" has been
> disabled in the binary since they are using "-netdev user" now.
> We have to skip the test if this network backend is missing.
Do the boot tests require networking? I doubt they do.
You could instead remove the -netdev user option if slirp is not present.
>
> Fixes: 6ee3624236 ("improve code coverage for ppc64")
> Signed-off-by: Thomas Huth
> ---
> tests/avocado/tuxrun_baselines.py | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tests/avocado/tuxrun_baselines.py
> b/tests/avocado/tuxrun_baselines.py
> index 3a46e7a745..e12250eabb 100644
> --- a/tests/avocado/tuxrun_baselines.py
> +++ b/tests/avocado/tuxrun_baselines.py
> @@ -184,6 +184,7 @@ def common_tuxrun(self,
>
> def ppc64_common_tuxrun(self, sums, prefix):
> # add device args to command line.
> +self.require_netdev('user')
> self.vm.add_args('-netdev', 'user,id=vnet,hostfwd=:127.0.0.1:0-:22',
> '-device', 'virtio-net,netdev=vnet')
> self.vm.add_args('-netdev', '{"type":"user","id":"hostnet0"}',
> --
> 2.31.1
>
>
Re: [PATCH v3 1/1] hw/arm/aspeed:Add vpd data for Rainier machine
On Wed, 24 May 2023 at 06:38, Cédric Le Goater wrote:
>
> On 5/23/23 23:45, Ninad Palsule wrote:
> > The current modeling of Rainier machine creates zero filled VPDs(EEPROMs).
> > This makes some services and applications unhappy and causing them to fail.
> > Hence this drop adds some fabricated data for system and BMC FRU so that
> > vpd services are happy and active.
> >
> > Tested:
> > - The system-vpd.service is active.
> > - VPD service related to bmc is active.
> >
> > Signed-off-by: Ninad Palsule
>
> You can keep the R-b tag when you resend, unless there are a lot of changes.
>
> Reviewed-by: Cédric Le Goater
>
> Since I am curious, I started a rainier machine under QEMU and ran some
> commands :
>
>root@p10bmc:~# hexdump -C /sys/bus/i2c/devices/i2c-8/8-0050/eeprom
> 00 00 00 00 00 00 00 00 00 00 00 84 28 00 52 54
> |(.RT|
>0010 04 56 48 44 52 56 44 02 01 00 50 54 0e 56 54 4f
> |.VHDRVD...PT.VTO|
>0020 43 00 00 37 00 4a 00 00 00 00 00 50 46 08 00 00
> |C..7.J.PF...|
>0030 00 00 00 00 00 00 00 00 46 00 52 54 04 56 54 4f
> |F.RT.VTO|
>0040 43 50 54 38 56 49 4e 49 00 00 81 00 3a 00 00 00
> |CPT8VINI:...|
>0050 00 00 56 53 59 53 00 00 bb 00 27 00 00 00 00 00
> |..VSYS'.|
>0060 56 43 45 4e 00 00 e2 00 27 00 00 00 00 00 56 53
> |VCEN'.VS|
>0070 42 50 00 00 09 01 19 00 00 00 00 00 50 46 01 00
> |BP..PF..|
>0080 00 00 36 00 52 54 04 56 49 4e 49 44 52 04 44 45
> |..6.RT.VINIDR.DE|
>0090 53 43 48 57 02 30 31 43 43 04 33 34 35 36 46 4e
> |SCHW.01CC.3456FN|
>00a0 04 46 52 34 39 53 4e 04 53 52 31 32 50 4e 04 50
> |.FR49SN.SR12PN.P|
>00b0 52 39 39 50 46 04 00 00 00 00 00 00 23 00 52 54
> |R99PF...#.RT|
>00c0 04 56 53 59 53 53 45 07 49 42 4d 53 59 53 31 54
> |.VSYSSE.IBMSYS1T|
>00d0 4d 08 32 32 32 32 2d 32 32 32 50 46 04 00 00 00
> |M.-222PF|
>00e0 00 00 00 23 00 52 54 04 56 43 45 4e 53 45 07 31
> |...#.RT.VCENSE.1|
>00f0 32 33 34 35 36 37 46 43 08 31 31 31 31 2d 31 31
> |234567FC.-11|
>0100 31 50 46 04 00 00 00 00 00 00 15 00 52 54 04 56
> |1PF.RT.V|
>0110 53 42 50 49 4d 04 50 00 10 01 50 46 04 00 00 00
> |SBPIM.P...PF|
>0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ||
>*
>2000
>root@p10bmc:~# hexdump -C /sys/bus/i2c/devices/i2c-8/8-0051/eeprom
> 00 00 00 00 00 00 00 00 00 00 00 84 28 00 52 54
> |(.RT|
>0010 04 56 48 44 52 56 44 02 01 00 50 54 0e 56 54 4f
> |.VHDRVD...PT.VTO|
>0020 43 00 00 37 00 20 00 00 00 00 00 50 46 08 00 00 |C..7.
> .PF...|
>0030 00 00 00 00 00 00 00 00 1c 00 52 54 04 56 54 4f
> |..RT.VTO|
>0040 43 50 54 0e 56 49 4e 49 00 00 57 00 1e 00 00 00
> |CPT.VINI..W.|
>0050 00 00 50 46 01 00 00 00 1a 00 52 54 04 56 49 4e
> |..PF..RT.VIN|
>0060 49 44 52 04 44 45 53 43 48 57 02 30 31 50 46 04
> |IDR.DESCHW.01PF.|
>0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ||
>
> and
>
>root@p10bmc:~# systemctl status com.ibm.VPD.Manager.service -l
>* com.ibm.VPD.Manager.service - IBM VPD Manager
> Loaded: loaded (/lib/systemd/system/com.ibm.VPD.Manager.service;
> enabled; preset: enabled)
> Active: active (running) since Wed 2023-05-24 06:26:34 UTC; 1min 28s
> ago
> Main PID: 2784 (vpd-manager)
>CPU: 101ms
> CGroup: /system.slice/com.ibm.VPD.Manager.service
> `-2784 /usr/bin/vpd-manager
When it works we should be able to do things like this, I'm told:
vpd-tool -r -O /system/chassis/motherboard -R VSYS -K TM
{
"/system/chassis/motherboard": {
"TM": "-222"
}
}
>
> But, I also got this :
>
>root@p10bmc:~# [ 91.656331] watchdog: watchdog0: watchdog did not stop!
>[ 91.734858] systemd-shutdown[1]: Using hardware watchdog 'aspeed_wdt',
> version 0, device /dev/watchdog0
>[ 91.735766] systemd-shutdown[1]: Watchdog running with a timeout of
> 1min.
>[ 91.987363] systemd-shutdown[1]: Syncing filesystems and block devices.
>[ 93.471897] systemd-shutdown[1]: Sending SIGTERM to remaining
> processes...
>
> and the machine rebooted.
>
> Joel had the same problem :
>
>https://github.com/openbmc/qemu/issues/39
>
> Is it unrelated ? I haven't started a rainier in 2 years at least so I can
> not tell.
I don't think it's related to Ninad's patches.
I am able to reproduce the issue on my old Skylake x86 machine, but it
doesn't happen on my M1 mac mini.
I suspect the emulation is moving too slowly, but the host's wall
clock is still ticking, so all of a sudden the BMC finds out that time
has passed an the watchdog bites. I could be wrong.
The rainier firmware crashes all over the place d
Re: [PATCH 00/16] i3c: aspeed: Add I3C support
On Wed, 5 Apr 2023 at 02:07, Jeremy Kerr wrote: > > Hi Joe, > > > > > Jeremy, how different is it ? Could we introduce properties or sub > > > > classes, to support both. > > > > > > The differences (at least from the view of the current Linux driver > > > implementation) are very minor; unless we want to be errata-compatible, > > > you could use the dw driver directly, plus the ast2600-specific global > > > register space. > > > > > > > This is my understanding as well from an outside look. > > From a QEMU standpoint I could split off the dwc portion into a > > dwc_i3c model, which the aspeed_i3c portion inherits from. I can do > > that in a v2 if that sounds good with everyone. > > I'm not a qemu maintainer, but for the record: I'm fine with the current > approach. I don't have access to any of the non-aspeed dw documentation, > so verifying what should go into the dw model vs. what is > ast2600-specific has been a bit tricky. > > If someone needs a non-aspeed dw model, and has a bit of documentation > about the underlying dw hardware, it should be easy enough to split back > out. Maybe just make sure any "known" divergences - like the IBI PEC > behaviour - are well commented. > > That said, if you're keen to do the split dw+aspeed models, that's also > good :) I think the split makes sense. It will help other platforms who have the designware part add it to their system in the future. Joe, when you send out the patches again please be sure to use get_maintianers.pl to send it to the appropriate reviewers. Thanks for sharing your work! Cheers, Joel
Re: [PULL 00/15] tcg patch queue
On Tue, 28 Mar 2023 at 22:59, Richard Henderson wrote: > > The following changes since commit d37158bb2425e7ebffb167d611be01f1e9e6c86f: > > Update version for v8.0.0-rc2 release (2023-03-28 20:43:21 +0100) > > are available in the Git repository at: > > https://gitlab.com/rth7680/qemu.git tags/pull-tcg-20230328 > > for you to fetch changes up to 87e303de70f93bf700f58412fb9b2c3ec918c4b5: > > softmmu: Restore use of CPU watchpoint for all accelerators (2023-03-28 > 15:24:06 -0700) > > > Use a local version of GTree [#285] > Fix page_set_flags vs the last page of the address space [#1528] > Re-enable gdbstub breakpoints under KVM > > > Emilio Cota (2): > util: import GTree as QTree > tcg: use QTree instead of GTree > > Philippe Mathieu-Daudé (3): > softmmu: Restrict cpu_check_watchpoint / address_matches to TCG accel > softmmu/watchpoint: Add missing 'qemu/error-report.h' include > softmmu: Restore use of CPU watchpoint for all accelerators > > Richard Henderson (10): > linux-user: Diagnose misaligned -R size > accel/tcg: Pass last not end to page_set_flags > accel/tcg: Pass last not end to page_reset_target_data > accel/tcg: Pass last not end to PAGE_FOR_EACH_TB > accel/tcg: Pass last not end to page_collection_lock > accel/tcg: Pass last not end to tb_invalidate_phys_page_range__locked > accel/tcg: Pass last not end to tb_invalidate_phys_range > linux-user: Pass last not end to probe_guest_base > include/exec: Change reserved_va semantics to last byte > linux-user/arm: Take more care allocating commpage Thanks for getting these fixes merged. This last one (4f5c67f8df7f26e559509c68c45e652709edd23f) causes a regression for me. On ppc64le, qemu-arm now segfaults. If I revert this one I can run executables without the assert. The segfault looks like this: #0 0x0001001e44fc in stl_he_p (v=5, ptr=0x240450ffc) at /home/joel/qemu/include/qemu/bswap.h:260 #1 stl_le_p (v=5, ptr=0x240450ffc) at /home/joel/qemu/include/qemu/bswap.h:302 #2 init_guest_commpage () at ../linux-user/elfload.c:460 #3 probe_guest_base (image_name=image_name@entry=0x1003c72e0 "/home/joel/hello", guest_loaddr=guest_loaddr@entry=65536, guest_hiaddr=guest_hiaddr@entry=17411743) at ../linux-user/elfload.c:2818 #4 0x0001001e50d4 in load_elf_image (image_name=0x1003c72e0 "/home/joel/hello", image_fd=, info=info@entry=0x7fffe7e8, pinterp_name=pinterp_name@entry=0x7fffe558, bprm_buf=bprm_buf@entry=0x7fffe8d0 "\177ELF\001\001\001") at ../linux-user/elfload.c:3108 #5 0x0001001e5434 in load_elf_binary (bprm=0x7fffe8d0, info=0x7fffe7e8) at ../linux-user/elfload.c:3548 #6 0x0001001e85bc in loader_exec (fdexec=, filename=, argv=, envp=, regs=0x7fffe888, infop=0x7fffe7e8, bprm=0x7fffe8d0) at ../linux-user/linuxload.c:155 #7 0x000100046c7c in main (argc=, argv=0x71c8, envp=) at ../linux-user/main.c:892 Cheers, Joel
[PATCH] tests/avocado/aspeed: Add TPM TIS I2C test
Add a new buildroot image based test that attaches a TPM emulator to the
I2C bus and checks for a known PCR0 value for the image that was booted.
Note that this does not tear down swtpm process when qemu execution fails.
The swtpm process will exit when qemu exits if a connection has been
made, but if the test errors before connection then the swtpm process
will still be around.
Signed-off-by: Joel Stanley
---
tests/avocado/machine_aspeed.py | 42 +++--
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/tests/avocado/machine_aspeed.py b/tests/avocado/machine_aspeed.py
index 35723af4ede0..a4485a5c4d4d 100644
--- a/tests/avocado/machine_aspeed.py
+++ b/tests/avocado/machine_aspeed.py
@@ -7,14 +7,18 @@
import time
import os
+import tempfile
+import subprocess
from avocado_qemu import QemuSystemTest
from avocado_qemu import wait_for_console_pattern
from avocado_qemu import exec_command
from avocado_qemu import exec_command_and_wait_for_pattern
from avocado_qemu import interrupt_interactive_console_until_pattern
+from avocado_qemu import has_cmd
from avocado.utils import archive
from avocado import skipIf
+from avocado import skipUnless
class AST1030Machine(QemuSystemTest):
@@ -132,7 +136,7 @@ def test_arm_ast2500_romulus_openbmc_v2_9_0(self):
self.do_test_arm_aspeed(image_path)
-def do_test_arm_aspeed_buildroot_start(self, image, cpu_id):
+def do_test_arm_aspeed_buildroot_start(self, image, cpu_id,
pattern='Aspeed EVB'):
self.require_netdev('user')
self.vm.set_console()
@@ -146,7 +150,7 @@ def do_test_arm_aspeed_buildroot_start(self, image, cpu_id):
self.wait_for_console_pattern('Booting Linux on physical CPU ' +
cpu_id)
self.wait_for_console_pattern('lease of 10.0.2.15')
# the line before login:
-self.wait_for_console_pattern('Aspeed EVB')
+self.wait_for_console_pattern(pattern)
time.sleep(0.1)
exec_command(self, 'root')
time.sleep(0.1)
@@ -229,6 +233,40 @@ def test_arm_ast2600_evb_buildroot(self):
'000 ffaa ');
self.do_test_arm_aspeed_buildroot_poweroff()
+@skipUnless(*has_cmd('swtpm'))
+def test_arm_ast2600_evb_buildroot_tpm(self):
+"""
+:avocado: tags=arch:arm
+:avocado: tags=machine:ast2600-evb
+"""
+
+image_url = ('https://github.com/legoater/qemu-aspeed-boot/raw/master/'
+ 'images/ast2600-evb/buildroot-2023.02-tpm/flash.img')
+image_hash =
('a46009ae8a5403a0826d607215e731a8c68d27c14c41e55331706b8f9c7bd997')
+image_path = self.fetch_asset(image_url, asset_hash=image_hash,
+ algorithm='sha256')
+
+socket = os.path.join(self.vm.sock_dir, 'swtpm-socket')
+
+subprocess.run(['swtpm', 'socket', '-d', '--tpm2',
+'--tpmstate', f'dir={self.vm.temp_dir}',
+'--ctrl', f'type=unixio,path={socket}'])
+
+self.vm.add_args('-chardev', f'socket,id=chrtpm,path={socket}')
+self.vm.add_args('-tpmdev', 'emulator,id=tpm0,chardev=chrtpm')
+self.vm.add_args('-device',
+
'tpm-tis-i2c,tpmdev=tpm0,bus=aspeed.i2c.bus.12,address=0x2e')
+self.do_test_arm_aspeed_buildroot_start(image_path, '0xf00', 'Aspeed
AST2600 EVB')
+exec_command(self, "passw0rd")
+
+exec_command_and_wait_for_pattern(self,
+'echo tpm_tis_i2c 0x2e > /sys/bus/i2c/devices/i2c-12/new_device',
+'tpm_tis_i2c 12-002e: 2.0 TPM (device-id 0x1, rev-id 1)');
+exec_command_and_wait_for_pattern(self,
+'cat /sys/class/tpm/tpm0/pcr-sha256/0',
+
'B804724EA13F52A9072BA87FE8FDCC497DFC9DF9AA15B9088694639C431688E0');
+
+self.do_test_arm_aspeed_buildroot_poweroff()
class AST2x00MachineSDK(QemuSystemTest):
--
2.39.2
Re: [PATCH v7 0/3] Add support for TPM devices over I2C bus
On Mon, 27 Mar 2023 at 11:11, Stefan Berger wrote: > > > > On 3/26/23 21:05, Joel Stanley wrote: > > Hi Ninad, > > > > On Sun, 26 Mar 2023 at 22:44, Ninad Palsule wrote: > >> > >> Hello, > >> > >> I have incorporated review comments from Stefan. Please review. > >> > >> This drop adds support for the TPM devices attached to the I2C bus. It > >> only supports the TPM2 protocol. You need to run it with the external > >> TPM emulator like swtpm. I have tested it with swtpm. > > > > Nice work. I tested these stop cedric's aspeed-8.0 qemu tree, using > > the rainier machine and the openbmc dev-6.1 kernel. > > > > We get this message when booting from a kernel: > > > > [0.582699] tpm_tis_i2c 12-002e: 2.0 TPM (device-id 0x1, rev-id 1) > > [0.586361] tpm tpm0: A TPM error (256) occurred attempting the self test > > [0.586623] tpm tpm0: starting up the TPM manually > > > > Do we understand why the error appears? > > The firmware did not initialize the TPM 2. Which firmware are we talking about here? In the case of these systems, we (u-boot+linux) are what would traditionally be referred to as firmware. > > # grep -r . /sys/class/tpm/tpm0/pcr-sha256/ | sort -n -k 7 -t / > > /sys/class/tpm/tpm0/pcr-sha256/0: > > /sys/class/tpm/tpm0/pcr-sha256/1: > > /sys/class/tpm/tpm0/pcr-sha256/2: > > /sys/class/tpm/tpm0/pcr-sha256/3: > > /sys/class/tpm/tpm0/pcr-sha256/4: > > /sys/class/tpm/tpm0/pcr-sha256/5: > > /sys/class/tpm/tpm0/pcr-sha256/6: > > /sys/class/tpm/tpm0/pcr-sha256/7: > > /sys/class/tpm/tpm0/pcr-sha256/8: > > /sys/class/tpm/tpm0/pcr-sha256/9: > > /sys/class/tpm/tpm0/pcr-sha256/10: > > /sys/class/tpm/tpm0/pcr-sha256/11: > > /sys/class/tpm/tpm0/pcr-sha256/12: > > /sys/class/tpm/tpm0/pcr-sha256/13: > > /sys/class/tpm/tpm0/pcr-sha256/14: > > /sys/class/tpm/tpm0/pcr-sha256/15: > > /sys/class/tpm/tpm0/pcr-sha256/16: > > /sys/class/tpm/tpm0/pcr-sha256/17: > > /sys/class/tpm/tpm0/pcr-sha256/18: > > /sys/class/tpm/tpm0/pcr-sha256/19: > > /sys/class/tpm/tpm0/pcr-sha256/20: > > /sys/class/tpm/tpm0/pcr-sha256/21: > > /sys/class/tpm/tpm0/pcr-sha256/22: > > /sys/class/tpm/tpm0/pcr-sha256/23: > > > > If I boot through the openbmc u-boot for the p10bmc machine, which > > measures things into the PCRs: > > > > [0.556713] tpm_tis_i2c 12-002e: 2.0 TPM (device-id 0x1, rev-id 1) > > In this case the firmware started up the TPM 2. Also the PCRs have been > touched by the firmware in this case. > > > > > / # grep -r . /sys/class/tpm/tpm0/pcr-sha256/ | sort -n -k 7 -t / > > /sys/class/tpm/tpm0/pcr-sha256/0:AFA13691EFC7BC6E189E92347F20676FB4523302CB957DA9A65C3430C45E8BCC > > /sys/class/tpm/tpm0/pcr-sha256/1:37F0F710A5502FAE6DB7433B36001FEE1CBF15BA2A7D6923207FF56888584714 > > /sys/class/tpm/tpm0/pcr-sha256/2:E21B703EE69C77476BCCB43EC0336A9A1B2914B378944F7B00A10214CA8FEA93 > > /sys/class/tpm/tpm0/pcr-sha256/3:E21B703EE69C77476BCCB43EC0336A9A1B2914B378944F7B00A10214CA8FEA93 > > /sys/class/tpm/tpm0/pcr-sha256/4:E21B703EE69C77476BCCB43EC0336A9A1B2914B378944F7B00A10214CA8FEA93 > > /sys/class/tpm/tpm0/p
Re: [PATCH v7 0/3] Add support for TPM devices over I2C bus
On Mon, 27 Mar 2023 at 08:21, Cédric Le Goater wrote: > > >>> However on a clean boot into the TPM, the u-boot tpm commands fail: > >>> > >>> ast# tpm info > >>> tpm@2e v2.0: VendorID 0x1014, DeviceID 0x0001, RevisionID 0x01 [closed] > >>> ast# tpINTERRUPT> > >>> ast# tpm init > >>> ast# tpm info > >>> tpm@2e v2.0: VendorID 0x1014, DeviceID 0x0001, RevisionID 0x01 [open] > >>> ast# tpm pcr_read 0 0x8100 > >>> Error: 256 > >>> ast# md.l 0x8100 16 > >>> 8100: > >>> 8110: > >>> 8120: > >>> 8130: > >>> 8140: > >>> 8150: > >>> > >>> This doesn't need to block merging into qemu, as the model works fine > >>> for pcr measurement and accessing under Linux. However it would be > >>> good to work though these issues in case there's a modelling > >>> discrepancy. > >> > >> > >> Yes, Please provide me details on how to reproduce it. I will take a look. > > > > This is the buildroot tree I've been using for testing: > > > > https://github.com/shenki/buildroot/commits/ast2600-tpm > > > > git clone https://github.com/shenki/buildroot -b ast2600-tpm > > cd buildroot > > make O=ast2600evb aspeed_ast2600evb_defconfig > > I have pushed binaries here also : > > > https://github.com/legoater/qemu-aspeed-boot/tree/master/images/ast2600-evb/buildroot-2023.02-tpm Thank you! The non-zero PCRs I see with this are: # grep -r . /sys/class/tpm/tpm0/pcr-sha256/ | sort -n -k 7 -t / /sys/class/tpm/tpm0/pcr-sha256/0:B804724EA13F52A9072BA87FE8FDCC497DFC9DF9AA15B9088694639C431688E0 /sys/class/tpm/tpm0/pcr-sha256/1:37F0F710A5502FAE6DB7433B36001FEE1CBF15BA2A7D6923207FF56888584714 /sys/class/tpm/tpm0/pcr-sha256/2:E21B703EE69C77476BCCB43EC0336A9A1B2914B378944F7B00A10214CA8FEA93 /sys/class/tpm/tpm0/pcr-sha256/3:E21B703EE69C77476BCCB43EC0336A9A1B2914B378944F7B00A10214CA8FEA93 /sys/class/tpm/tpm0/pcr-sha256/4:E21B703EE69C77476BCCB43EC0336A9A1B2914B378944F7B00A10214CA8FEA93 /sys/class/tpm/tpm0/pcr-sha256/5:E21B703EE69C77476BCCB43EC0336A9A1B2914B378944F7B00A10214CA8FEA93 /sys/class/tpm/tpm0/pcr-sha256/6:E21B703EE69C77476BCCB43EC0336A9A1B2914B378944F7B00A10214CA8FEA93 /sys/class/tpm/tpm0/pcr-sha256/7:E21B703EE69C77476BCCB43EC0336A9A1B2914B378944F7B00A10214CA8FEA93 /sys/class/tpm/tpm0/pcr-sha256/8:C840364040A0F98631A48A4C401C567226BFE5A2A30B958F1800E4849A140F69 /sys/class/tpm/tpm0/pcr-sha256/9:9D00428C528120A3F2D0D8CB0EB5D036D87C0D0F8D2990B8C1F12DEFAE3890C7 They seem to be stable across boots, which is good! We could use these images and that pcr0 value for an avocado test. Perhaps we could add an init script that binds the driver and prints the value to the console to save having to log in.
Re: [PATCH v7 0/3] Add support for TPM devices over I2C bus
On Mon, 27 Mar 2023 at 03:52, Ninad Palsule wrote: > > Hi Joel, > > On 3/26/23 8:05 PM, Joel Stanley wrote: > > Hi Ninad, > > > > On Sun, 26 Mar 2023 at 22:44, Ninad Palsule wrote: > >> Hello, > >> > >> I have incorporated review comments from Stefan. Please review. > >> > >> This drop adds support for the TPM devices attached to the I2C bus. It > >> only supports the TPM2 protocol. You need to run it with the external > >> TPM emulator like swtpm. I have tested it with swtpm. > > Nice work. I tested these stop cedric's aspeed-8.0 qemu tree, using > > the rainier machine and the openbmc dev-6.1 kernel. > > > > We get this message when booting from a kernel: > > > > [0.582699] tpm_tis_i2c 12-002e: 2.0 TPM (device-id 0x1, rev-id 1) > > [0.586361] tpm tpm0: A TPM error (256) occurred attempting the self test > > [0.586623] tpm tpm0: starting up the TPM manually > > > > Do we understand why the error appears? > > > Yes, As per kernel code this is an expected error for some emulators. > > On swtpm emulator, It returns TPM2_RC_INITIALIZE if emulator is not > initialized. I searched it in swtpm and it indicated that selftest > requested before it is initialized. I meant to ask Stefan but busy with > the review comments. The swtpm man page mentions some flags we can set. Perhaps they would help? --flags [not-need-init] [,startup-clear|startup-state|startup-deactivated|startup-none] > > This function comment in the driver mentioned below indicate that this > case possible with emulators. > > /** > * tpm2_startup - turn on the TPM > * @chip: TPM chip to use > * > * Normally the firmware should start the TPM. This function is > provided as a > * workaround if this does not happen. A legal case for this could be for > * example when a TPM emulator is used. > * > * Return: same as tpm_transmit_cmd() > */ > > static int tpm2_startup(struct tpm_chip *chip) > > > However on a clean boot into the TPM, the u-boot tpm commands fail: > > > > ast# tpm info > > tpm@2e v2.0: VendorID 0x1014, DeviceID 0x0001, RevisionID 0x01 [closed] > > ast# tpINTERRUPT> > > ast# tpm init > > ast# tpm info > > tpm@2e v2.0: VendorID 0x1014, DeviceID 0x0001, RevisionID 0x01 [open] > > ast# tpm pcr_read 0 0x8100 > > Error: 256 > > ast# md.l 0x8100 16 > > 8100: > > 8110: > > 8120: > > 8130: > > 8140: > > 8150: > > > > This doesn't need to block merging into qemu, as the model works fine > > for pcr measurement and accessing under Linux. However it would be > > good to work though these issues in case there's a modelling > > discrepancy. > > > Yes, Please provide me details on how to reproduce it. I will take a look. This is the buildroot tree I've been using for testing: https://github.com/shenki/buildroot/commits/ast2600-tpm git clone https://github.com/shenki/buildroot -b ast2600-tpm cd buildroot make O=ast2600evb aspeed_ast2600evb_defconfig I launch it with this qemu commandline: swtpm socket --tpmstate dir=$XDG_RUNTIME_DIR --ctrl type=unixio,path=$XDG_RUNTIME_DIR/swtpm-socket --tpm2 qemu-system-arm -M ast2600-evb -nographic -drive file=ast2600evb/images/flash.img,if=mtd,format=raw -chardev socket,id=chrtpm,path=$XDG_RUNTIME_DIR/swtpm-socket -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis-i2c,tpmdev=tpm0,bus=aspeed.i2c.bus.12,address=0x2e If you want to reproduce the u-boot behaviour, press any key to interrupt the boot. Booting this way, you can also test the u-boot behaviour. Once you're in userspace: # echo tpm_tis_i2c 0x2e > /sys/bus/i2c/devices/i2c-12/new_device [ 13.637081] tpm_tis_i2c 12-002e: 2.0 TPM (device-id 0x1, rev-id 1) [ 13.665239] i2c i2c-12: new_device: Instantiated device tpm_tis_i2c at 0x2e # cat /sys/class/tpm/tpm0/pcr-sha256/0 FE9A732EAA7842D77DEECFC1DC610EBEA9414BFC39BEEBC8D2F071CF030FA592
Re: [PATCH v7 1/3] docs: Add support for TPM devices over I2C bus
On Sun, 26 Mar 2023 at 22:44, Ninad Palsule wrote:
>
> This is a documentation change for I2C TPM device support.
>
> Qemu already supports devices attached to ISA and sysbus.
> This drop adds support for the I2C bus attached TPM devices.
>
> Signed-off-by: Ninad Palsule
>
> ---
> V2:
>
> Incorporated Stephen's review comments
> - Added example in the document.
>
> ---
> V4:
> Incorporate Cedric & Stefan's comments
>
> - Added example for ast2600-evb
> - Corrected statement about arm virtual machine.
>
> ---
> V6:
> Incorporated review comments from Stefan.
> ---
> docs/specs/tpm.rst | 32
> 1 file changed, 32 insertions(+)
>
> diff --git a/docs/specs/tpm.rst b/docs/specs/tpm.rst
> index 535912a92b..590e670a9a 100644
> --- a/docs/specs/tpm.rst
> +++ b/docs/specs/tpm.rst
> @@ -21,12 +21,16 @@ QEMU files related to TPM TIS interface:
> - ``hw/tpm/tpm_tis_common.c``
> - ``hw/tpm/tpm_tis_isa.c``
> - ``hw/tpm/tpm_tis_sysbus.c``
> + - ``hw/tpm/tpm_tis_i2c.c``
> - ``hw/tpm/tpm_tis.h``
>
> Both an ISA device and a sysbus device are available. The former is
> used with pc/q35 machine while the latter can be instantiated in the
> Arm virt machine.
>
> +An I2C device support is also provided which can be instantiated in the Arm
> +based emulation machines. This device only supports the TPM 2 protocol.
> +
> CRB interface
> -
>
> @@ -348,6 +352,34 @@ In case an Arm virt machine is emulated, use the
> following command line:
> -drive if=pflash,format=raw,file=flash0.img,readonly=on \
> -drive if=pflash,format=raw,file=flash1.img
>
> +In case a ast2600-evb bmc machine is emulated and want to use TPM device
> +attached to I2C bus, use the following command line:
> +
> +.. code-block:: console
> +
> + qemu-system-arm -M ast2600-evb -nographic \
> +-kernel arch/arm/boot/zImage \
> +-dtb arch/arm/boot/dts/aspeed-ast2600-evb.dtb \
> +-initrd rootfs.cpio \
> +-chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock \
> +-tpmdev emulator,id=tpm0,chardev=chrtpm \
> +-device tpm-tis-i2c,tpmdev=tpm0,bus=aspeed.i2c.bus.12,address=0x2e
For testing, use this command to load the driver to the correct address:
echo tpm_tis_i2c 0x2e > /sys/bus/i2c/devices/i2c-12/new_device
(I don't know how specific we want to make the instructions, but
adding a line like above would help others from having to re-discover
the command).
> +
> +In case a Rainier bmc machine is emulated and want to use TPM device
> +attached to I2C bus, use the following command line:
> +
> +.. code-block:: console
> +
> + qemu-system-arm -M rainier-bmc -nographic \
> +-kernel ${IMAGEPATH}/fitImage-linux.bin \
> +-dtb ${IMAGEPATH}/aspeed-bmc-ibm-rainier.dtb \
> +-initrd ${IMAGEPATH}/obmc-phosphor-initramfs.rootfs.cpio.xz \
> +-drive
> file=${IMAGEPATH}/obmc-phosphor-image.rootfs.wic.qcow2,if=sd,index=2\
> +-net nic -net
> user,hostfwd=:127.0.0.1:-:22,hostfwd=:127.0.0.1:2443-:443\
> +-chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock \
> +-tpmdev emulator,id=tpm0,chardev=chrtpm \
> +-device tpm-tis-i2c,tpmdev=tpm0,bus=aspeed.i2c.bus.12,address=0x2e
> +
I'd drop this example, the above one is enough.
> In case SeaBIOS is used as firmware, it should show the TPM menu item
> after entering the menu with 'ESC'.
>
> --
> 2.37.2
>
Re: [PATCH v7 0/3] Add support for TPM devices over I2C bus
Hi Ninad, On Sun, 26 Mar 2023 at 22:44, Ninad Palsule wrote: > > Hello, > > I have incorporated review comments from Stefan. Please review. > > This drop adds support for the TPM devices attached to the I2C bus. It > only supports the TPM2 protocol. You need to run it with the external > TPM emulator like swtpm. I have tested it with swtpm. Nice work. I tested these stop cedric's aspeed-8.0 qemu tree, using the rainier machine and the openbmc dev-6.1 kernel. We get this message when booting from a kernel: [0.582699] tpm_tis_i2c 12-002e: 2.0 TPM (device-id 0x1, rev-id 1) [0.586361] tpm tpm0: A TPM error (256) occurred attempting the self test [0.586623] tpm tpm0: starting up the TPM manually Do we understand why the error appears? # grep -r . /sys/class/tpm/tpm0/pcr-sha256/ | sort -n -k 7 -t / /sys/class/tpm/tpm0/pcr-sha256/0: /sys/class/tpm/tpm0/pcr-sha256/1: /sys/class/tpm/tpm0/pcr-sha256/2: /sys/class/tpm/tpm0/pcr-sha256/3: /sys/class/tpm/tpm0/pcr-sha256/4: /sys/class/tpm/tpm0/pcr-sha256/5: /sys/class/tpm/tpm0/pcr-sha256/6: /sys/class/tpm/tpm0/pcr-sha256/7: /sys/class/tpm/tpm0/pcr-sha256/8: /sys/class/tpm/tpm0/pcr-sha256/9: /sys/class/tpm/tpm0/pcr-sha256/10: /sys/class/tpm/tpm0/pcr-sha256/11: /sys/class/tpm/tpm0/pcr-sha256/12: /sys/class/tpm/tpm0/pcr-sha256/13: /sys/class/tpm/tpm0/pcr-sha256/14: /sys/class/tpm/tpm0/pcr-sha256/15: /sys/class/tpm/tpm0/pcr-sha256/16: /sys/class/tpm/tpm0/pcr-sha256/17: /sys/class/tpm/tpm0/pcr-sha256/18: /sys/class/tpm/tpm0/pcr-sha256/19: /sys/class/tpm/tpm0/pcr-sha256/20: /sys/class/tpm/tpm0/pcr-sha256/21: /sys/class/tpm/tpm0/pcr-sha256/22: /sys/class/tpm/tpm0/pcr-sha256/23: If I boot through the openbmc u-boot for the p10bmc machine, which measures things into the PCRs: [0.556713] tpm_tis_i2c 12-002e: 2.0 TPM (device-id 0x1, rev-id 1) / # grep -r . /sys/class/tpm/tpm0/pcr-sha256/ | sort -n -k 7 -t / /sys/class/tpm/tpm0/pcr-sha256/0:AFA13691EFC7BC6E189E92347F20676FB4523302CB957DA9A65C3430C45E8BCC /sys/class/tpm/tpm0/pcr-sha256/1:37F0F710A5502FAE6DB7433B36001FEE1CBF15BA2A7D6923207FF56888584714 /sys/class/tpm/tpm0/pcr-sha256/2:E21B703EE69C77476BCCB43EC0336A9A1B2914B378944F7B00A10214CA8FEA93 /sys/class/tpm/tpm0/pcr-sha256/3:E21B703EE69C77476BCCB43EC0336A9A1B2914B378944F7B00A10214CA8FEA93 /sys/class/tpm/tpm0/pcr-sha256/4:E21B703EE69C77476BCCB43EC0336A9A1B2914B378944F7B00A10214CA8FEA93 /sys/class/tpm/tpm0/pcr-sha256/5:E21B703EE69C77476BCCB43EC0336A9A1B2914B378944F7B00A10214CA8FEA93 /sys/class/tpm/tpm0/pcr-sha256/6:E21B703EE69C77476BCCB43EC0336A9A1B2914B378944F7B00A10214CA8FEA93 /sys/class/tpm/tpm0/pcr-sha256/7:E21B703EE69C77476BCCB43EC0336A9A1B2914B378944F7B00A10214CA8FEA93 /sys/class/tpm/tpm0/pcr-sha256/8:AE67485BD01E8D6FE0208C46C473940173F66E9C6F43C75ABB404375787E9705 /sys/class/tpm/tpm0/pcr-sha256/9:DB99D92EADBB446894CB0C062AEB673F60DDAFBC62BC2A9CA561A13B31E5357C /sys/class/tpm/tpm0/pcr-sha256/10: /sys/class/tpm/tpm0/pcr-sha256/11: /sys/class/tpm/tpm0/pcr-sha256/12: /sys/class/tpm/tpm0/pcr-sha256/13: /sys/class/tpm/tpm0/pcr-sha256/14: /sys/class/tpm/tpm0/pcr-sha256/15:
Re: [PATCH 0/9] accel/tcg: Fix page_set_flags and related [#1528]
On Mon, 6 Mar 2023 at 02:14, Richard Henderson wrote: > > The primary issue is that of overflow, where "end" for the last > page of the 32-bit address space overflows to 0. The fix is to > use "last" instead, which can always be represented. > > This requires that we adjust reserved_va as well, because of > > -/* > - * There are a number of places where we assign reserved_va to a variable > - * of type abi_ulong and expect it to fit. Avoid the last page. > - */ > -# define MAX_RESERVED_VA (0xul & TARGET_PAGE_MASK) > > and the related > > -/* > - * reserved_va must be aligned with the host page size > - * as it is used with mmap() > - */ > -reserved_va = local_max_va & qemu_host_page_mask; > > whereby we avoided the final (host | guest) page of the address space > because of said overflow. With the change in representation, we can > always use UINT32_MAX as the end of the 32-bit address space. > > This was observable on ppc64le (or any other 64k page host) not being > able to load any arm32 binary, because the COMMPAGE goes at 0x, > which violated that last host page problem above. > > The issue is resolved in patch 4, but the rest clean up other interfaces > with the same issue. I'm not touching any interfaces that use start+len > instead of start+end. Thanks for looking at this Richard. I gave it a spin on a ppc64le host and it resolved the assert. Tested-by: Joel Stanley Cheers, Joel
Re: [PATCH 1/3] hw/gpio: add PCA6414 i2c GPIO expander
On Mon, 6 Feb 2023 at 19:51, Titus Rwantare wrote:
>
> This is a simple i2c device that allows i2c capable devices to have
> GPIOs.
Nice.
In Linux this is supported by a driver called pca953x. Would it make
sense to name your model similarly (both the file and the prefixes you
use)?
If we do that then it looks like other devices from the same family
could be easily supported. (I'm not suggesting you do that work up
front)
> hw/gpio/pca_i2c_gpio.c | 362
> hw/gpio/trace-events| 5 +
> hw/i2c/Kconfig | 4 +
> include/hw/gpio/pca_i2c_gpio.h | 72 +++
> tests/qtest/meson.build | 1 +
> tests/qtest/pca_i2c_gpio-test.c | 169 +++
> 8 files changed, 615 insertions(+)
> create mode 100644 hw/gpio/pca_i2c_gpio.c
> create mode 100644 include/hw/gpio/pca_i2c_gpio.h
> create mode 100644 tests/qtest/pca_i2c_gpio-test.c
>
> diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
> index 2d157de9b8..1b533ddd76 100644
> --- a/hw/arm/Kconfig
> +++ b/hw/arm/Kconfig
> @@ -418,6 +418,7 @@ config NPCM7XX
> select SSI
> select UNIMP
> select PCA954X
> +select PCA_I2C_GPIO
>
> config FSL_IMX25
> bool
> diff --git a/hw/gpio/meson.build b/hw/gpio/meson.build
> index b726e6d27a..1e5b602002 100644
> --- a/hw/gpio/meson.build
> +++ b/hw/gpio/meson.build
> @@ -12,3 +12,4 @@ softmmu_ss.add(when: 'CONFIG_OMAP', if_true:
> files('omap_gpio.c'))
> softmmu_ss.add(when: 'CONFIG_RASPI', if_true: files('bcm2835_gpio.c'))
> softmmu_ss.add(when: 'CONFIG_ASPEED_SOC', if_true: files('aspeed_gpio.c'))
> softmmu_ss.add(when: 'CONFIG_SIFIVE_GPIO', if_true: files('sifive_gpio.c'))
> +softmmu_ss.add(when: 'CONFIG_PCA_I2C_GPIO', if_true: files('pca_i2c_gpio.c'))
> diff --git a/hw/gpio/pca_i2c_gpio.c b/hw/gpio/pca_i2c_gpio.c
> new file mode 100644
> index 00..afae497a22
> --- /dev/null
> +++ b/hw/gpio/pca_i2c_gpio.c
> @@ -0,0 +1,362 @@
> +/*
> + * NXP PCA I2C GPIO Expanders
> + *
> + * Low-voltage translating 16-bit I2C/SMBus GPIO expander with interrupt
> output,
> + * reset, and configuration registers
> + *
> + * Datasheet: https://www.nxp.com/docs/en/data-sheet/PCA6416A.pdf
+1
> + *
> + * Copyright 2023 Google LLC
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + *
> + * These devices, by default, are configured to input only. The
> configuration is
> + * settable through qom/qmp, or i2c.To set some pins as inputs before boot,
> use
> + * the following in the board file of the machine:
> + * object_property_set_uint(Object *obj, const char *name,
> + * uint64_t value, Error **errp);
> + * specifying name as "gpio_config" and the value as a bitfield of the inputs
> + * e.g. for the pca6416, a value of 0xFFF0, sets pins 0-3 as outputs and
> + * 4-15 as inputs.
> + * This value can also be set at runtime through qmp externally, or by
> + * writing to the config register using i2c.
Nice docs. I'm sure someone else will tell you if there's a better
spot, but I like that you've written this down.
Re: [PATCH 03/25] hw/net: Fix read of uninitialized memory in ftgmac100
On Thu, 19 Jan 2023 at 12:39, Cédric Le Goater wrote: > > From: Stephen Longfield > > With the `size += 4` before the call to `crc32`, the CRC calculation > would overrun the buffer. Size is used in the while loop starting on > line 1009 to determine how much data to write back, with the last > four bytes coming from `crc_ptr`, so do need to increase it, but should > do this after the computation. > > I'm unsure why this use of uninitialized memory in the CRC doesn't > result in CRC errors, but it seems clear to me that it should not be > included in the calculation. Does this affect the error counters observed under Linux? > > Signed-off-by: Stephen Longfield > Reviewed-by: Hao Wu > Message-Id: <20221220221437.3303721-1-slongfi...@google.com> > Signed-off-by: Cédric Le Goater Reviewed-by: Joel Stanley > --- > hw/net/ftgmac100.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/hw/net/ftgmac100.c b/hw/net/ftgmac100.c > index 83ef0a783e..d3bf14be53 100644 > --- a/hw/net/ftgmac100.c > +++ b/hw/net/ftgmac100.c > @@ -980,9 +980,9 @@ static ssize_t ftgmac100_receive(NetClientState *nc, > const uint8_t *buf, > return size; > } > > -/* 4 bytes for the CRC. */ > -size += 4; > crc = cpu_to_be32(crc32(~0, buf, size)); > +/* Increase size by 4, loop below reads the last 4 bytes from crc_ptr. */ > +size += 4; > crc_ptr = (uint8_t *) &crc; > > /* Huge frames are truncated. */ > -- > 2.39.0 > >
Re: [PATCH 08/25] hw/arm/boot: Export write_bootloader for Aspeed machines
On Thu, 19 Jan 2023 at 12:37, Cédric Le Goater wrote:
>
> AST2600 Aspeed machines have an home made boot loader for secondaries.
> To improve support, export the internal ARM boot loader and use it
> instead.
I didn't quite follow why we're doing this. Is it just a cleanup?
>
> Signed-off-by: Cédric Le Goater
> ---
> include/hw/arm/boot.h | 24
> hw/arm/aspeed.c | 42 ++
> hw/arm/boot.c | 34 +++---
> 3 files changed, 53 insertions(+), 47 deletions(-)
>
> diff --git a/include/hw/arm/boot.h b/include/hw/arm/boot.h
> index f18cc3064f..23edd0d31b 100644
> --- a/include/hw/arm/boot.h
> +++ b/include/hw/arm/boot.h
> @@ -183,4 +183,28 @@ void arm_write_secure_board_setup_dummy_smc(ARMCPU *cpu,
> const struct arm_boot_info *info,
> hwaddr mvbar_addr);
>
> +typedef enum {
> +FIXUP_NONE = 0, /* do nothing */
> +FIXUP_TERMINATOR, /* end of insns */
> +FIXUP_BOARDID, /* overwrite with board ID number */
> +FIXUP_BOARD_SETUP, /* overwrite with board specific setup code address
> */
> +FIXUP_ARGPTR_LO,/* overwrite with pointer to kernel args */
> +FIXUP_ARGPTR_HI,/* overwrite with pointer to kernel args (high half)
> */
> +FIXUP_ENTRYPOINT_LO, /* overwrite with kernel entry point */
> +FIXUP_ENTRYPOINT_HI, /* overwrite with kernel entry point (high half) */
> +FIXUP_GIC_CPU_IF, /* overwrite with GIC CPU interface address */
> +FIXUP_BOOTREG, /* overwrite with boot register address */
> +FIXUP_DSB, /* overwrite with correct DSB insn for cpu */
> +FIXUP_MAX,
> +} FixupType;
> +
> +typedef struct ARMInsnFixup {
> +uint32_t insn;
> +FixupType fixup;
> +} ARMInsnFixup;
> +
> +void arm_write_bootloader(const char *name, hwaddr addr,
> + const ARMInsnFixup *insns, uint32_t *fixupcontext,
> + AddressSpace *as);
> +
> #endif /* HW_ARM_BOOT_H */
> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
> index 4919a1fe9e..c373bd2851 100644
> --- a/hw/arm/aspeed.c
> +++ b/hw/arm/aspeed.c
> @@ -198,33 +198,35 @@ struct AspeedMachineState {
> static void aspeed_write_smpboot(ARMCPU *cpu,
> const struct arm_boot_info *info)
> {
> -static const uint32_t poll_mailbox_ready[] = {
> +AddressSpace *as = arm_boot_address_space(cpu, info);
> +static const ARMInsnFixup poll_mailbox_ready[] = {
> /*
> * r2 = per-cpu go sign value
> * r1 = AST_SMP_MBOX_FIELD_ENTRY
> * r0 = AST_SMP_MBOX_FIELD_GOSIGN
> */
> -0xee100fb0, /* mrc p15, 0, r0, c0, c0, 5 */
> -0xe21000ff, /* andsr0, r0, #255 */
> -0xe59f201c, /* ldr r2, [pc, #28] */
> -0xe1822000, /* orr r2, r2, r0*/
> -
> -0xe59f1018, /* ldr r1, [pc, #24] */
> -0xe59f0018, /* ldr r0, [pc, #24] */
> -
> -0xe320f002, /* wfe */
> -0xe5904000, /* ldr r4, [r0] */
> -0xe1520004, /* cmp r2, r4*/
> -0x1afb, /* bne */
> -0xe591f000, /* ldr pc, [r1] */
> -AST_SMP_MBOX_GOSIGN,
> -AST_SMP_MBOX_FIELD_ENTRY,
> -AST_SMP_MBOX_FIELD_GOSIGN,
> +{ 0xee100fb0 }, /* mrc p15, 0, r0, c0, c0, 5 */
> +{ 0xe21000ff }, /* andsr0, r0, #255 */
> +{ 0xe59f201c }, /* ldr r2, [pc, #28] */
> +{ 0xe1822000 }, /* orr r2, r2, r0*/
> +
> +{ 0xe59f1018 }, /* ldr r1, [pc, #24] */
> +{ 0xe59f0018 }, /* ldr r0, [pc, #24] */
> +
> +{ 0xe320f002 }, /* wfe */
> +{ 0xe5904000 }, /* ldr r4, [r0] */
> +{ 0xe1520004 }, /* cmp r2, r4*/
> +{ 0x1afb }, /* bne */
> +{ 0xe591f000 }, /* ldr pc, [r1] */
> +{ AST_SMP_MBOX_GOSIGN },
> +{ AST_SMP_MBOX_FIELD_ENTRY },
> +{ AST_SMP_MBOX_FIELD_GOSIGN },
> +{ 0, FIXUP_TERMINATOR }
> };
> +uint32_t fixupcontext[FIXUP_MAX] = { 0 };
>
> -rom_add_blob_fixed("aspeed.smpboot", poll_mailbox_ready,
> - sizeof(poll_mailbox_ready),
> - info->smp_loader_start);
> +arm_write_bootloader("aspeed.smpboot", info->smp_loader_start,
> + poll_mailbox_ready, fixupcontext, as);
> }
>
> static void aspeed_reset_secondary(ARMCPU *cpu,
> diff --git a/hw/arm/boot.c b/hw/arm/boot.c
> index 3d7d11f782..ed6fd7c77f 100644
> --- a/hw/arm/boot.c
> +++ b/hw/arm/boot.c
> @@ -59,26 +59,6 @@ AddressSpace *arm_boot_address_space(ARMCPU *cpu,
>
Re: [PATCH 06/25] tests/avocado/machine_aspeed.py: update buildroot tests
On Thu, 19 Jan 2023 at 12:37, Cédric Le Goater wrote:
>
> Use buildroot 2022.11 based images plus some customization :
>
> - Linux version is bumped to 6.0.9 and kernel is built with a custom
> config similar to what OpenBMC provides.
> - U-Boot is switched to the one provided by OpenBMC for better support.
> - defconfigs includes more target tools for dev.
>
> Signed-off-by: Cédric Le Goater
Reviewed-by: Joel Stanley
> ---
> tests/avocado/machine_aspeed.py | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tests/avocado/machine_aspeed.py b/tests/avocado/machine_aspeed.py
> index 1fc385e1c8..773b1ff3a9 100644
> --- a/tests/avocado/machine_aspeed.py
> +++ b/tests/avocado/machine_aspeed.py
> @@ -123,8 +123,8 @@ def test_arm_ast2500_evb_buildroot(self):
> """
>
> image_url =
> ('https://github.com/legoater/qemu-aspeed-boot/raw/master/'
> - 'images/ast2500-evb/buildroot-2022.05/flash.img')
> -image_hash =
> ('549db6e9d8cdaf4367af21c36385a68bb465779c18b5e37094fc7343decccd3f')
> +
> 'images/ast2500-evb/buildroot-2022.11-2-g15d3648df9/flash.img')
> +image_hash =
> ('f96d11db521fe7a2787745e9e391225dc3318ee0fc07c8b799b8833dd474')
> image_path = self.fetch_asset(image_url, asset_hash=image_hash,
>algorithm='sha256')
>
> @@ -151,8 +151,8 @@ def test_arm_ast2600_evb_buildroot(self):
> """
>
> image_url =
> ('https://github.com/legoater/qemu-aspeed-boot/raw/master/'
> - 'images/ast2600-evb/buildroot-2022.05/flash.img')
> -image_hash =
> ('6cc9e7d128fd4fa1fd01c883af67593cae8072c3239a0b8b6ace857f3538a92d')
> +
> 'images/ast2600-evb/buildroot-2022.11-2-g15d3648df9/flash.img')
> +image_hash =
> ('e598d86e5ea79671ca8b59212a326c911bc8bea728dec1a1f5390d717a28bb8b')
> image_path = self.fetch_asset(image_url, asset_hash=image_hash,
>algorithm='sha256')
>
> --
> 2.39.0
>
>
Re: [PATCH 07/25] tests/avocado/machine_aspeed.py: Mask systemd services to speed up SDK boot
On Thu, 19 Jan 2023 at 12:39, Cédric Le Goater wrote:
>
> Signed-off-by: Cédric Le Goater
NIce!
Reviewed-by: Joel Stanley
> ---
> tests/avocado/machine_aspeed.py | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/tests/avocado/machine_aspeed.py b/tests/avocado/machine_aspeed.py
> index 773b1ff3a9..1cab946727 100644
> --- a/tests/avocado/machine_aspeed.py
> +++ b/tests/avocado/machine_aspeed.py
> @@ -183,7 +183,14 @@ def test_arm_ast2600_evb_buildroot(self):
>
> class AST2x00MachineSDK(QemuSystemTest):
>
> -EXTRA_BOOTARGS = ' quiet'
> +EXTRA_BOOTARGS = (
> +'quiet '
> +'systemd.mask=org.openbmc.HostIpmi.service '
> +'systemd.mask=xyz.openbmc_project.Chassis.Control.Power@0.service '
> +'systemd.mask=modprobe@fuse.service '
> +'systemd.mask=rngd.service '
> +'systemd.mask=obmc-console@ttyS2.service '
> +)
>
> # FIXME: Although these tests boot a whole distro they are still
> # slower than comparable machine models. There may be some
> @@ -208,7 +215,7 @@ def do_test_arm_aspeed_sdk_start(self, image):
> interrupt_interactive_console_until_pattern(
> self, 'Hit any key to stop autoboot:', 'ast#')
> exec_command_and_wait_for_pattern(
> -self, 'setenv bootargs ${bootargs}' + self.EXTRA_BOOTARGS,
> 'ast#')
> +self, 'setenv bootargs ${bootargs} ' + self.EXTRA_BOOTARGS,
> 'ast#')
> exec_command_and_wait_for_pattern(
> self, 'boot', '## Loading kernel from FIT Image')
> self.wait_for_console_pattern('Starting kernel ...')
> --
> 2.39.0
>
>
Re: [PATCH 02/25] aspeed: Add Supermicro X11 SPI machine type
On Thu, 19 Jan 2023 at 12:36, Cédric Le Goater wrote:
>
> From: Guenter Roeck
>
> supermicrox11-bmc is configured with ast2400-a1 SoC. This does not match
> the Supermicro documentation for X11 BMCs, and it does not match the
> devicetree file in the Linux kernel.
I found this sentence confusing; AFAICT X11 doesn't name a specific
motherboard. It appears to be a marketing term for a bunch of
different things.
> As it turns out, some Supermicro X11 motherboards use AST2400 SoCs,
> while others use AST2500.
>
> Introduce new machine type supermicrox11-spi-bmc with AST2500 SoC
How about supermicro-x11spi-bmc? It would match the product name:
https://www.supermicro.com/en/products/motherboard/X11SPi-TF
as well as the device tree filename.
> to match the devicetree description in the Linux kernel. Hardware
> configuration details for this machine type are guesswork and taken
> from defaults as well as from the Linux kernel devicetree file.
>
> The new machine type was tested with aspeed-bmc-supermicro-x11spi.dts
> from the Linux kernel and with Linux versions 6.0.3 and 6.1-rc2.
> Linux booted successfully from initrd and from both SPI interfaces.
> Ethernet interfaces were confirmed to be operational.
>
> Signed-off-by: Guenter Roeck
> Reviewed-by: Philippe Mathieu-Daudé
> Link: https://lore.kernel.org/r/20221025165109.1226001-1-li...@roeck-us.net
> Message-Id: <20221025165109.1226001-1-li...@roeck-us.net>
> Signed-off-by: Cédric Le Goater
> ---
> hw/arm/aspeed.c | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
> index 55f114ef72..4919a1fe9e 100644
> --- a/hw/arm/aspeed.c
> +++ b/hw/arm/aspeed.c
> @@ -71,6 +71,16 @@ struct AspeedMachineState {
> SCU_HW_STRAP_VGA_SIZE_SET(VGA_16M_DRAM) | \
> SCU_AST2400_HW_STRAP_BOOT_MODE(AST2400_SPI_BOOT))
>
> +/* TODO: Find the actual hardware value */
> +#define SUPERMICROX11_SPI_BMC_HW_STRAP1 ( \
> +AST2500_HW_STRAP1_DEFAULTS |\
> +SCU_AST2500_HW_STRAP_SPI_AUTOFETCH_ENABLE | \
> +SCU_AST2500_HW_STRAP_GPIO_STRAP_ENABLE |\
> +SCU_AST2500_HW_STRAP_UART_DEBUG | \
> +SCU_AST2500_HW_STRAP_DDR4_ENABLE | \
> +SCU_HW_STRAP_SPI_WIDTH |\
> +SCU_HW_STRAP_SPI_MODE(SCU_HW_STRAP_SPI_M_S_EN))
> +
> /* AST2500 evb hardware value: 0xF100C2E6 */
> #define AST2500_EVB_HW_STRAP1 ((\
> AST2500_HW_STRAP1_DEFAULTS |\
> @@ -1141,6 +1151,25 @@ static void
> aspeed_machine_supermicrox11_bmc_class_init(ObjectClass *oc,
> mc->default_ram_size = 256 * MiB;
> }
>
> +static void aspeed_machine_supermicrox11_spi_bmc_class_init(ObjectClass *oc,
> +void *data)
> +{
> +MachineClass *mc = MACHINE_CLASS(oc);
> +AspeedMachineClass *amc = ASPEED_MACHINE_CLASS(oc);
> +
> +mc->desc = "Supermicro X11 SPI BMC (ARM1176)";
> +amc->soc_name = "ast2500-a1";
> +amc->hw_strap1 = SUPERMICROX11_SPI_BMC_HW_STRAP1;
> +amc->fmc_model = "mx25l25635e";
> +amc->spi_model = "mx25l25635e";
> +amc->num_cs= 1;
> +amc->macs_mask = ASPEED_MAC0_ON | ASPEED_MAC1_ON;
> +amc->i2c_init = palmetto_bmc_i2c_init;
> +mc->default_ram_size = 512 * MiB;
> +mc->default_cpus = mc->min_cpus = mc->max_cpus =
> +aspeed_soc_num_cpus(amc->soc_name);
> +}
> +
> static void aspeed_machine_ast2500_evb_class_init(ObjectClass *oc, void
> *data)
> {
> MachineClass *mc = MACHINE_CLASS(oc);
> @@ -1522,6 +1551,10 @@ static const TypeInfo aspeed_machine_types[] = {
> .name = MACHINE_TYPE_NAME("supermicrox11-bmc"),
> .parent= TYPE_ASPEED_MACHINE,
> .class_init= aspeed_machine_supermicrox11_bmc_class_init,
> +}, {
> +.name = MACHINE_TYPE_NAME("supermicrox11-spi-bmc"),
> +.parent= TYPE_ASPEED_MACHINE,
> +.class_init= aspeed_machine_supermicrox11_spi_bmc_class_init,
> }, {
> .name = MACHINE_TYPE_NAME("ast2500-evb"),
> .parent= TYPE_ASPEED_MACHINE,
> --
> 2.39.0
>
>
Re: [PATCH 04/25] avocado/boot_linux_console.py: Update ast2600 test
On Thu, 19 Jan 2023 at 12:35, Cédric Le Goater wrote:
>
> From: Joel Stanley
>
> Update the test_arm_ast2600_debian test to
>
> - the latest Debian kernel
Would you like a newer version of this patch that uses the latest kernel?
> - use the Rainier machine instead of Tacoma
>
> Both of which contains support for more hardware and thus exercises more
> of the hardware Qemu models.
>
> Signed-off-by: Joel Stanley
> Reviewed-by: Cédric Le Goater
> Message-Id: <20220607011938.1676459-1-j...@jms.id.au>
> Signed-off-by: Cédric Le Goater
> ---
> tests/avocado/boot_linux_console.py | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/tests/avocado/boot_linux_console.py
> b/tests/avocado/boot_linux_console.py
> index 8c1d981586..f3a1d00be9 100644
> --- a/tests/avocado/boot_linux_console.py
> +++ b/tests/avocado/boot_linux_console.py
> @@ -1098,18 +1098,18 @@ def test_arm_vexpressa9(self):
> def test_arm_ast2600_debian(self):
> """
> :avocado: tags=arch:arm
> -:avocado: tags=machine:tacoma-bmc
> +:avocado: tags=machine:rainier-bmc
> """
> deb_url = ('http://snapshot.debian.org/archive/debian/'
> - '20210302T203551Z/'
> + '20220606T211338Z/'
> 'pool/main/l/linux/'
> - 'linux-image-5.10.0-3-armmp_5.10.13-1_armhf.deb')
> -deb_hash =
> 'db40d32fe39255d05482bea48d72467b67d6225bb2a2a4d6f618cb8976f1e09e'
> + 'linux-image-5.17.0-2-armmp_5.17.6-1%2Bb1_armhf.deb')
> +deb_hash =
> '8acb2b4439faedc2f3ed4bdb2847ad4f6e0491f73debaeb7f660c8abe4dcdc0e'
> deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash,
> algorithm='sha256')
> -kernel_path = self.extract_from_deb(deb_path,
> '/boot/vmlinuz-5.10.0-3-armmp')
> +kernel_path = self.extract_from_deb(deb_path,
> '/boot/vmlinuz-5.17.0-2-armmp')
> dtb_path = self.extract_from_deb(deb_path,
> -
> '/usr/lib/linux-image-5.10.0-3-armmp/aspeed-bmc-opp-tacoma.dtb')
> +
> '/usr/lib/linux-image-5.17.0-2-armmp/aspeed-bmc-ibm-rainier.dtb')
>
> self.vm.set_console()
> self.vm.add_args('-kernel', kernel_path,
> --
> 2.39.0
>
Re: [PATCH 09/25] hw/core/loader: Remove declarations of option_rom_has_mr/rom_file_has_mr
On Thu, 19 Jan 2023 at 12:37, Cédric Le Goater wrote:
>
> These globals were moved to MachineClass by commit 71ae9e94d9 ("pc: Move
> option_rom_has_mr/rom_file_has_mr globals to MachineClass"). Finish cleanup.
>
> Cc: Eduardo Habkost
> Cc: Marcel Apfelbaum
> Reviewed-by: Alex Bennée
> Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Cédric Le Goater
Reviewed-by: Joel Stanley
> ---
> include/hw/loader.h | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/include/hw/loader.h b/include/hw/loader.h
> index 70248e0da7..1384796a4b 100644
> --- a/include/hw/loader.h
> +++ b/include/hw/loader.h
> @@ -251,9 +251,6 @@ void pstrcpy_targphys(const char *name,
>hwaddr dest, int buf_size,
>const char *source);
>
> -extern bool option_rom_has_mr;
> -extern bool rom_file_has_mr;
> -
> ssize_t rom_add_file(const char *file, const char *fw_dir,
> hwaddr addr, int32_t bootindex,
> bool option_rom, MemoryRegion *mr, AddressSpace *as);
> --
> 2.39.0
>
>
Re: [PATCH 20/25] hw/arm/aspeed_ast10x0: Add various unimplemented peripherals
On Thu, 19 Jan 2023 at 12:36, Cédric Le Goater wrote:
>
> From: Philippe Mathieu-Daudé
>
> Based on booting Zephyr demo from [1] running QEMU with
> '-d unimp' and checking missing devices in [2].
>
> [1] https://github.com/AspeedTech-BMC/zephyr/releases/tag/v00.01.07
> [2]
> https://github.com/AspeedTech-BMC/zephyr/blob/v00.01.08/dts/arm/aspeed/ast10x0.dtsi
>
> Signed-off-by: Philippe Mathieu-Daudé
> Reviewed-by: Peter Delevoryas
> Reviewed-by: Cédric Le Goater
> Signed-off-by: Cédric Le Goater
Reviewed-by: Joel Stanley
> ---
> include/hw/arm/aspeed_soc.h | 11 +++
> hw/arm/aspeed_ast10x0.c | 35 +++
> 2 files changed, 46 insertions(+)
>
> diff --git a/include/hw/arm/aspeed_soc.h b/include/hw/arm/aspeed_soc.h
> index 8389200b2d..9a5e3c0bac 100644
> --- a/include/hw/arm/aspeed_soc.h
> +++ b/include/hw/arm/aspeed_soc.h
> @@ -44,6 +44,7 @@
> #define ASPEED_CPUS_NUM 2
> #define ASPEED_MACS_NUM 4
> #define ASPEED_UARTS_NUM 13
> +#define ASPEED_JTAG_NUM 2
>
> struct AspeedSoCState {
> /*< private >*/
> @@ -87,6 +88,11 @@ struct AspeedSoCState {
> UnimplementedDeviceState video;
> UnimplementedDeviceState emmc_boot_controller;
> UnimplementedDeviceState dpmcu;
> +UnimplementedDeviceState pwm;
> +UnimplementedDeviceState espi;
> +UnimplementedDeviceState udc;
> +UnimplementedDeviceState sgpiom;
> +UnimplementedDeviceState jtag[ASPEED_JTAG_NUM];
> };
>
> #define TYPE_ASPEED_SOC "aspeed-soc"
> @@ -174,6 +180,11 @@ enum {
> ASPEED_DEV_DPMCU,
> ASPEED_DEV_DP,
> ASPEED_DEV_I3C,
> +ASPEED_DEV_ESPI,
> +ASPEED_DEV_UDC,
> +ASPEED_DEV_SGPIOM,
> +ASPEED_DEV_JTAG0,
> +ASPEED_DEV_JTAG1,
> };
>
> qemu_irq aspeed_soc_get_irq(AspeedSoCState *s, int dev);
> diff --git a/hw/arm/aspeed_ast10x0.c b/hw/arm/aspeed_ast10x0.c
> index b483735dc2..b970a5ea58 100644
> --- a/hw/arm/aspeed_ast10x0.c
> +++ b/hw/arm/aspeed_ast10x0.c
> @@ -27,10 +27,15 @@ static const hwaddr aspeed_soc_ast1030_memmap[] = {
> [ASPEED_DEV_FMC] = 0x7E62,
> [ASPEED_DEV_SPI1] = 0x7E63,
> [ASPEED_DEV_SPI2] = 0x7E64,
> +[ASPEED_DEV_UDC] = 0x7E6A2000,
> [ASPEED_DEV_SCU] = 0x7E6E2000,
> +[ASPEED_DEV_JTAG0] = 0x7E6E4000,
> +[ASPEED_DEV_JTAG1] = 0x7E6E4100,
> [ASPEED_DEV_ADC] = 0x7E6E9000,
> +[ASPEED_DEV_ESPI] = 0x7E6EE000,
> [ASPEED_DEV_SBC] = 0x7E6F2000,
> [ASPEED_DEV_GPIO] = 0x7E78,
> +[ASPEED_DEV_SGPIOM]= 0x7E780500,
> [ASPEED_DEV_TIMER1]= 0x7E782000,
> [ASPEED_DEV_UART1] = 0x7E783000,
> [ASPEED_DEV_UART2] = 0x7E78D000,
> @@ -78,12 +83,17 @@ static const int aspeed_soc_ast1030_irqmap[] = {
> [ASPEED_DEV_LPC] = 35,
> [ASPEED_DEV_PECI] = 38,
> [ASPEED_DEV_FMC] = 39,
> +[ASPEED_DEV_ESPI] = 42,
> [ASPEED_DEV_PWM] = 44,
> [ASPEED_DEV_ADC] = 46,
> [ASPEED_DEV_SPI1] = 65,
> [ASPEED_DEV_SPI2] = 66,
> [ASPEED_DEV_I2C] = 110, /* 110 ~ 123 */
> [ASPEED_DEV_KCS] = 138, /* 138 -> 142 */
> +[ASPEED_DEV_UDC] = 9,
> +[ASPEED_DEV_SGPIOM]= 51,
> +[ASPEED_DEV_JTAG0] = 27,
> +[ASPEED_DEV_JTAG1] = 53,
nit: The array is kind of sorted by irq number, these could probably go above?
> };
>
> static qemu_irq aspeed_soc_ast1030_get_irq(AspeedSoCState *s, int dev)
> @@ -154,6 +164,15 @@ static void aspeed_soc_ast1030_init(Object *obj)
> object_initialize_child(obj, "iomem", &s->iomem,
> TYPE_UNIMPLEMENTED_DEVICE);
> object_initialize_child(obj, "sbc-unimplemented", &s->sbc_unimplemented,
> TYPE_UNIMPLEMENTED_DEVICE);
> +object_initialize_child(obj, "pwm", &s->pwm, TYPE_UNIMPLEMENTED_DEVICE);
> +object_initialize_child(obj, "espi", &s->espi,
> TYPE_UNIMPLEMENTED_DEVICE);
> +object_initialize_child(obj, "udc", &s->udc, TYPE_UNIMPLEMENTED_DEVICE);
> +object_initialize_child(obj, "sgpiom", &s->sgpiom,
> +TYPE_UNIMPLEMENTED_DEVICE);
> +object_initialize_child(obj, "jtag[0]", &s->jtag[0],
> +TYPE_UNIMPLEMENTED_DEVICE);
> +object_initialize_child(obj, "jtag[1]", &s->jtag[1],
> +TYPE_UNIMPLEMENTED_DEVICE);
> }
>
> static void aspeed_soc_ast1030_realize(DeviceState *dev_soc, Error **errp)
> @@ -336,6 +
Re: [PATCH 05/25] m25p80: Add the is25wp256 SFPD table
On Thu, 19 Jan 2023 at 12:36, Cédric Le Goater wrote:
>
> From: Guenter Roeck
>
> Generated from hardware using the following command and then padding
> with 0xff to fill out a power-of-2:
> xxd -p /sys/bus/spi/devices/spi0.0/spi-nor/sfdp
>
> Cc: Michael Walle
> Cc: Tudor Ambarus
> Signed-off-by: Guenter Roeck
> Reviewed-by: Cédric Le Goater
> Message-Id: <20221221122213.1458540-1-li...@roeck-us.net>
> Signed-off-by: Cédric Le Goater
Reviewed-by: Joel Stanley
I wonder if we could update the code so the padding is assumed.
> ---
> hw/block/m25p80_sfdp.h | 2 ++
> hw/block/m25p80.c | 3 ++-
> hw/block/m25p80_sfdp.c | 40
> 3 files changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/hw/block/m25p80_sfdp.h b/hw/block/m25p80_sfdp.h
> index df7adfb5ce..011a880f66 100644
> --- a/hw/block/m25p80_sfdp.h
> +++ b/hw/block/m25p80_sfdp.h
> @@ -26,4 +26,6 @@ uint8_t m25p80_sfdp_w25q512jv(uint32_t addr);
>
> uint8_t m25p80_sfdp_w25q01jvq(uint32_t addr);
>
> +uint8_t m25p80_sfdp_is25wp256(uint32_t addr);
> +
> #endif
> diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
> index 68a757abf3..dc5ffbc4ff 100644
> --- a/hw/block/m25p80.c
> +++ b/hw/block/m25p80.c
> @@ -222,7 +222,8 @@ static const FlashPartInfo known_devices[] = {
> { INFO("is25wp032", 0x9d7016, 0, 64 << 10, 64, ER_4K) },
> { INFO("is25wp064", 0x9d7017, 0, 64 << 10, 128, ER_4K) },
> { INFO("is25wp128", 0x9d7018, 0, 64 << 10, 256, ER_4K) },
> -{ INFO("is25wp256", 0x9d7019, 0, 64 << 10, 512, ER_4K) },
> +{ INFO("is25wp256", 0x9d7019, 0, 64 << 10, 512, ER_4K),
> + .sfdp_read = m25p80_sfdp_is25wp256 },
>
> /* Macronix */
> { INFO("mx25l2005a", 0xc22012, 0, 64 << 10, 4, ER_4K) },
> diff --git a/hw/block/m25p80_sfdp.c b/hw/block/m25p80_sfdp.c
> index 77615fa29e..b33811a4f5 100644
> --- a/hw/block/m25p80_sfdp.c
> +++ b/hw/block/m25p80_sfdp.c
> @@ -330,3 +330,43 @@ static const uint8_t sfdp_w25q01jvq[] = {
> 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> };
> define_sfdp_read(w25q01jvq);
> +
> +/*
> + * Integrated Silicon Solution (ISSI)
> + */
> +
> +static const uint8_t sfdp_is25wp256[] = {
> +0x53, 0x46, 0x44, 0x50, 0x06, 0x01, 0x01, 0xff,
> +0x00, 0x06, 0x01, 0x10, 0x30, 0x00, 0x00, 0xff,
> +0x9d, 0x05, 0x01, 0x03, 0x80, 0x00, 0x00, 0x02,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xe5, 0x20, 0xf9, 0xff, 0xff, 0xff, 0xff, 0x0f,
> +0x44, 0xeb, 0x08, 0x6b, 0x08, 0x3b, 0x80, 0xbb,
> +0xfe, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0xff,
> +0xff, 0xff, 0x44, 0xeb, 0x0c, 0x20, 0x0f, 0x52,
> +0x10, 0xd8, 0x00, 0xff, 0x23, 0x4a, 0xc9, 0x00,
> +0x82, 0xd8, 0x11, 0xce, 0xcc, 0xcd, 0x68, 0x46,
> +0x7a, 0x75, 0x7a, 0x75, 0xf7, 0xae, 0xd5, 0x5c,
> +0x4a, 0x42, 0x2c, 0xff, 0xf0, 0x30, 0xfa, 0xa9,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0x50, 0x19, 0x50, 0x16, 0x9f, 0xf9, 0xc0, 0x64,
> +0x8f, 0xef, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> +};
> +define_sfdp_read(is25wp256);
> --
> 2.39.0
>
>
[PATCH] aspeed/sdmc: Drop unnecessary scu include
The model includes aspeed_scu.h but doesn't appear to require it. Signed-off-by: Joel Stanley --- hw/misc/aspeed_sdmc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/hw/misc/aspeed_sdmc.c b/hw/misc/aspeed_sdmc.c index d2a3931033b3..abb272793393 100644 --- a/hw/misc/aspeed_sdmc.c +++ b/hw/misc/aspeed_sdmc.c @@ -12,7 +12,6 @@ #include "qemu/module.h" #include "qemu/error-report.h" #include "hw/misc/aspeed_sdmc.h" -#include "hw/misc/aspeed_scu.h" #include "hw/qdev-properties.h" #include "migration/vmstate.h" #include "qapi/error.h" -- 2.39.0
[PATCH] hw/misc: Add basic Aspeed GFX model
Enough model to capture the pinmux writes to enable correct operation of
the parts of pinmux that depend on GFX registers.
Signed-off-by: Joel Stanley
---
include/hw/arm/aspeed_soc.h | 3 +
include/hw/misc/aspeed_gfx.h | 31 +
hw/arm/aspeed_ast2600.c | 11
hw/arm/aspeed_soc.c | 12
hw/misc/aspeed_gfx.c | 121 +++
hw/misc/meson.build | 1 +
hw/misc/trace-events | 4 ++
7 files changed, 183 insertions(+)
create mode 100644 include/hw/misc/aspeed_gfx.h
create mode 100644 hw/misc/aspeed_gfx.c
diff --git a/include/hw/arm/aspeed_soc.h b/include/hw/arm/aspeed_soc.h
index 8389200b2d01..7084e0efeb97 100644
--- a/include/hw/arm/aspeed_soc.h
+++ b/include/hw/arm/aspeed_soc.h
@@ -26,6 +26,7 @@
#include "hw/ssi/aspeed_smc.h"
#include "hw/misc/aspeed_hace.h"
#include "hw/misc/aspeed_sbc.h"
+#include "hw/misc/aspeed_gfx.h"
#include "hw/watchdog/wdt_aspeed.h"
#include "hw/net/ftgmac100.h"
#include "target/arm/cpu.h"
@@ -81,6 +82,7 @@ struct AspeedSoCState {
AspeedSDHCIState emmc;
AspeedLPCState lpc;
AspeedPECIState peci;
+AspeedGFXState gfx;
SerialMM uart[ASPEED_UARTS_NUM];
Clock *sysclk;
UnimplementedDeviceState iomem;
@@ -171,6 +173,7 @@ enum {
ASPEED_DEV_EMMC,
ASPEED_DEV_KCS,
ASPEED_DEV_HACE,
+ASPEED_DEV_GFX,
ASPEED_DEV_DPMCU,
ASPEED_DEV_DP,
ASPEED_DEV_I3C,
diff --git a/include/hw/misc/aspeed_gfx.h b/include/hw/misc/aspeed_gfx.h
new file mode 100644
index ..b0736a53f577
--- /dev/null
+++ b/include/hw/misc/aspeed_gfx.h
@@ -0,0 +1,31 @@
+/*
+ * ASPEED GFX Controller
+ *
+ * Copyright (C) 2023 IBM Corp.
+ *
+ * This code is licensed under the GPL version 2 or later. See
+ * the COPYING file in the top-level directory.
+ */
+
+#ifndef ASPEED_GFX_H
+#define ASPEED_GFX_H
+
+#include "hw/sysbus.h"
+
+#define TYPE_ASPEED_GFX "aspeed.gfx"
+#define ASPEED_GFX(obj) OBJECT_CHECK(AspeedGFXState, (obj), TYPE_ASPEED_GFX)
+
+#define ASPEED_GFX_NR_REGS (0xFC >> 2)
+
+typedef struct AspeedGFXState {
+/* */
+SysBusDevice parent;
+
+/*< public >*/
+MemoryRegion iomem;
+qemu_irq irq;
+
+uint32_t regs[ASPEED_GFX_NR_REGS];
+} AspeedGFXState;
+
+#endif /* _ASPEED_GFX_H_ */
diff --git a/hw/arm/aspeed_ast2600.c b/hw/arm/aspeed_ast2600.c
index cd75465c2bdd..10e4a13655cc 100644
--- a/hw/arm/aspeed_ast2600.c
+++ b/hw/arm/aspeed_ast2600.c
@@ -43,6 +43,7 @@ static const hwaddr aspeed_soc_ast2600_memmap[] = {
[ASPEED_DEV_HACE] = 0x1E6D,
[ASPEED_DEV_SDMC] = 0x1E6E,
[ASPEED_DEV_SCU] = 0x1E6E2000,
+[ASPEED_DEV_GFX] = 0x1E6E6000,
[ASPEED_DEV_XDMA] = 0x1E6E7000,
[ASPEED_DEV_ADC] = 0x1E6E9000,
[ASPEED_DEV_DP]= 0x1E6EB000,
@@ -255,6 +256,8 @@ static void aspeed_soc_ast2600_init(Object *obj)
object_initialize_child(obj, "sbc", &s->sbc, TYPE_ASPEED_SBC);
+object_initialize_child(obj, "gfx", &s->gfx, TYPE_ASPEED_GFX);
+
object_initialize_child(obj, "iomem", &s->iomem,
TYPE_UNIMPLEMENTED_DEVICE);
object_initialize_child(obj, "video", &s->video,
TYPE_UNIMPLEMENTED_DEVICE);
object_initialize_child(obj, "dpmcu", &s->dpmcu,
TYPE_UNIMPLEMENTED_DEVICE);
@@ -607,6 +610,14 @@ static void aspeed_soc_ast2600_realize(DeviceState *dev,
Error **errp)
return;
}
aspeed_mmio_map(s, SYS_BUS_DEVICE(&s->sbc), 0, sc->memmap[ASPEED_DEV_SBC]);
+
+/* GFX */
+if (!sysbus_realize(SYS_BUS_DEVICE(&s->gfx), errp)) {
+return;
+}
+aspeed_mmio_map(s, SYS_BUS_DEVICE(&s->gfx), 0, sc->memmap[ASPEED_DEV_GFX]);
+sysbus_connect_irq(SYS_BUS_DEVICE(&s->gfx), 0,
+ aspeed_soc_get_irq(s, ASPEED_DEV_GFX));
}
static void aspeed_soc_ast2600_class_init(ObjectClass *oc, void *data)
diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
index b05b9dd41602..053149f9ccdf 100644
--- a/hw/arm/aspeed_soc.c
+++ b/hw/arm/aspeed_soc.c
@@ -33,6 +33,7 @@ static const hwaddr aspeed_soc_ast2400_memmap[] = {
[ASPEED_DEV_SDMC] = 0x1E6E,
[ASPEED_DEV_SCU]= 0x1E6E2000,
[ASPEED_DEV_HACE] = 0x1E6E3000,
+[ASPEED_DEV_GFX]= 0x1E6E6000,
[ASPEED_DEV_XDMA] = 0x1E6E7000,
[ASPEED_DEV_VIDEO] = 0x1E70,
[ASPEED_DEV_ADC]= 0x1E6E9000,
@@ -69,6 +70,7 @@ static const hwaddr aspeed_soc_ast2500_memmap[] = {
[ASPEED_DEV_SDMC] = 0x1E6E,
[ASPEED_DEV_SCU]= 0x1E6E2000,
[ASPEED_DEV_HACE] = 0x1E6E3000,
+[ASPEED_DEV_GFX]= 0x1E6E6000,
[ASPEED_DEV_XDMA] = 0x1E6E7000,
[ASPEED_DEV_ADC]= 0x1E6E9000,
[ASPEED_DEV_VIDEO] = 0x1E70,
@@ -233,6 +235,8 @@ static void aspeed_soc_init(Object *obj)
snprintf(typename, sizeo
Re: [PATCH v2 04/11] hw/arm/aspeed: Use the IEC binary prefix definitions
On Fri, 30 Dec 2022 at 11:35, Philippe Mathieu-Daudé wrote:
>
> IEC binary prefixes ease code review: the unit is explicit.
I strongly prefer the existing code; it tells you the size without
having to do maths.
>
> Signed-off-by: Philippe Mathieu-Daudé
> Reviewed-by: Peter Delevoryas
> ---
> hw/arm/aspeed_ast10x0.c | 3 ++-
> hw/arm/aspeed_ast2600.c | 3 ++-
> hw/arm/aspeed_soc.c | 4 ++--
> 3 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/hw/arm/aspeed_ast10x0.c b/hw/arm/aspeed_ast10x0.c
> index 122b3fd3f3..3500294df7 100644
> --- a/hw/arm/aspeed_ast10x0.c
> +++ b/hw/arm/aspeed_ast10x0.c
> @@ -10,6 +10,7 @@
> */
>
> #include "qemu/osdep.h"
> +#include "qemu/units.h"
> #include "qapi/error.h"
> #include "exec/address-spaces.h"
> #include "sysemu/sysemu.h"
> @@ -348,7 +349,7 @@ static void aspeed_soc_ast1030_class_init(ObjectClass
> *klass, void *data)
> sc->name = "ast1030-a1";
> sc->cpu_type = ARM_CPU_TYPE_NAME("cortex-m4");
> sc->silicon_rev = AST1030_A1_SILICON_REV;
> -sc->sram_size = 0xc;
> +sc->sram_size = 768 * KiB;
> sc->spis_num = 2;
> sc->ehcis_num = 0;
> sc->wdts_num = 4;
> diff --git a/hw/arm/aspeed_ast2600.c b/hw/arm/aspeed_ast2600.c
> index a79e05ddbd..72df72a540 100644
> --- a/hw/arm/aspeed_ast2600.c
> +++ b/hw/arm/aspeed_ast2600.c
> @@ -8,6 +8,7 @@
> */
>
> #include "qemu/osdep.h"
> +#include "qemu/units.h"
> #include "qapi/error.h"
> #include "hw/misc/unimp.h"
> #include "hw/arm/aspeed_soc.h"
> @@ -619,7 +620,7 @@ static void aspeed_soc_ast2600_class_init(ObjectClass
> *oc, void *data)
> sc->name = "ast2600-a3";
> sc->cpu_type = ARM_CPU_TYPE_NAME("cortex-a7");
> sc->silicon_rev = AST2600_A3_SILICON_REV;
> -sc->sram_size= 0x16400;
> +sc->sram_size= 89 * KiB;
> sc->spis_num = 2;
> sc->ehcis_num= 2;
> sc->wdts_num = 4;
> diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
> index 2c0924d311..677342c9ed 100644
> --- a/hw/arm/aspeed_soc.c
> +++ b/hw/arm/aspeed_soc.c
> @@ -517,7 +517,7 @@ static void aspeed_soc_ast2400_class_init(ObjectClass
> *oc, void *data)
> sc->name = "ast2400-a1";
> sc->cpu_type = ARM_CPU_TYPE_NAME("arm926");
> sc->silicon_rev = AST2400_A1_SILICON_REV;
> -sc->sram_size= 0x8000;
> +sc->sram_size= 32 * KiB;
> sc->spis_num = 1;
> sc->ehcis_num= 1;
> sc->wdts_num = 2;
> @@ -544,7 +544,7 @@ static void aspeed_soc_ast2500_class_init(ObjectClass
> *oc, void *data)
> sc->name = "ast2500-a1";
> sc->cpu_type = ARM_CPU_TYPE_NAME("arm1176");
> sc->silicon_rev = AST2500_A1_SILICON_REV;
> -sc->sram_size= 0x9000;
> +sc->sram_size= 36 * KiB;
> sc->spis_num = 2;
> sc->ehcis_num= 2;
> sc->wdts_num = 3;
> --
> 2.38.1
>
Re: [PATCH v3 5/5] hw/nvram/eeprom_at24c: Make reset behavior more like hardware
On Tue, 17 Jan 2023 at 23:24, Peter Delevoryas wrote:
>
> EEPROM's are a form of non-volatile memory. After power-cycling an EEPROM,
> I would expect the I2C state machine to be reset to default values, but I
> wouldn't really expect the memory to change at all.
>
> The current implementation of the at24c EEPROM resets its internal memory on
> reset. This matches the specification in docs/devel/reset.rst:
>
> Cold reset is supported by every resettable object. In QEMU, it means we
> reset
> to the initial state corresponding to the start of QEMU; this might differ
> from what is a real hardware cold reset. It differs from other resets (like
> warm or bus resets) which may keep certain parts untouched.
>
> But differs from my intuition. For example, if someone writes some information
> to an EEPROM, then AC power cycles their board, they would expect the EEPROM
> to
> retain that information. It's very useful to be able to test things like this
> in QEMU as well, to verify software instrumentation like determining the cause
> of a reboot.
>
> Fixes: 5d8424dbd3e8 ("nvram: add AT24Cx i2c eeprom")
> Signed-off-by: Peter Delevoryas
Reviewed-by: Joel Stanley
> ---
> hw/nvram/eeprom_at24c.c | 22 ++
> 1 file changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/hw/nvram/eeprom_at24c.c b/hw/nvram/eeprom_at24c.c
> index f8d751fa278d..5074776bff04 100644
> --- a/hw/nvram/eeprom_at24c.c
> +++ b/hw/nvram/eeprom_at24c.c
> @@ -185,18 +185,6 @@ static void at24c_eeprom_realize(DeviceState *dev, Error
> **errp)
> }
>
> ee->mem = g_malloc0(ee->rsize);
> -
> -}
> -
> -static
> -void at24c_eeprom_reset(DeviceState *state)
> -{
> -EEPROMState *ee = AT24C_EE(state);
> -
> -ee->changed = false;
> -ee->cur = 0;
> -ee->haveaddr = 0;
> -
> memset(ee->mem, 0, ee->rsize);
>
> if (ee->init_rom) {
> @@ -214,6 +202,16 @@ void at24c_eeprom_reset(DeviceState *state)
> }
> }
>
> +static
> +void at24c_eeprom_reset(DeviceState *state)
> +{
> +EEPROMState *ee = AT24C_EE(state);
> +
> +ee->changed = false;
> +ee->cur = 0;
> +ee->haveaddr = 0;
> +}
> +
> static Property at24c_eeprom_props[] = {
> DEFINE_PROP_UINT32("rom-size", EEPROMState, rsize, 0),
> DEFINE_PROP_BOOL("writable", EEPROMState, writable, true),
> --
> 2.39.0
>
Re: [PATCH v3 4/5] hw/arm/aspeed: Add aspeed_eeprom.c
On Tue, 17 Jan 2023 at 23:24, Peter Delevoryas wrote: > > - Create aspeed_eeprom.c and aspeed_eeprom.h > - Include aspeed_eeprom.c in CONFIG_ASPEED meson source files > - Include aspeed_eeprom.h in aspeed.c > - Add fby35_bmc_fruid data > - Use new at24c_eeprom_init_rom helper to initialize BMC FRUID EEPROM with > data > from aspeed_eeprom.c > > wget > https://github.com/facebook/openbmc/releases/download/openbmc-e2294ff5d31d/fby35.mtd > qemu-system-aarch64 -machine fby35-bmc -nographic -mtdblock fby35.mtd > ... > user: root > pass: 0penBmc > ... > root@bmc-oob:~# fruid-util bb > > FRU Information : Baseboard > --- : -- > Chassis Type : Rack Mount Chassis > Chassis Part Number : N/A > Chassis Serial Number : N/A > Board Mfg Date: Fri Jan 7 10:30:00 2022 > Board Mfg : XX > Board Product : Management Board wBMC > Board Serial : X > Board Part Number : XX > Board FRU ID : 1.0 > Board Custom Data 1 : X > Board Custom Data 2 : XX > Product Manufacturer : XX > Product Name : Yosemite V3.5 EVT2 > Product Part Number : XX > Product Version : EVT2 > Product Serial: X > Product Asset Tag : XXX > Product FRU ID: 1.0 > Product Custom Data 1 : X > Product Custom Data 2 : N/A > root@bmc-oob:~# fruid-util bmc > > FRU Information : BMC > --- : -- > Board Mfg Date: Mon Jan 10 21:42:00 2022 > Board Mfg : XX > Board Product : BMC Storage Module > Board Serial : X > Board Part Number : XX > Board FRU ID : 1.0 > Board Custom Data 1 : X > Board Custom Data 2 : XX > Product Manufacturer : XX > Product Name : Yosemite V3.5 EVT2 > Product Part Number : XX > Product Version : EVT2 > Product Serial: X > Product Asset Tag : XXX > Product FRU ID: 1.0 > Product Custom Data 1 : X > Product Custom Data 2 : Config A > root@bmc-oob:~# fruid-util nic > > FRU Information : NIC > --- : -- > Board Mfg Date: Tue Nov 2 08:51:00 2021 > Board Mfg : > Board Product : Mellanox ConnectX-6 DX OCP3.0 > Board Serial : > Board Part Number : X > Board FRU ID : FRU Ver 0.02 > Product Manufacturer : > Product Name : Mellanox ConnectX-6 DX OCP3.0 > Product Part Number : X > Product Version : A9 > Product Serial: > Product Custom Data 3 : ConnectX-6 DX > > Signed-off-by: Peter Delevoryas > Reviewed-by: Cédric Le Goater Reviewed-by: Joel Stanley > --- > hw/arm/aspeed.c | 10 +++-- > hw/arm/aspeed_eeprom.c | 78 + > hw/arm/aspeed_eeprom.h | 16 +++ > hw/arm/meson.build | 1 + > include/hw/nvram/eeprom_at24c.h | 14 ++ > 5 files changed, 116 insertions(+), 3 deletions(-) > create mode 100644 hw/arm/aspeed_eeprom.c > create mode 100644 hw/arm/aspeed_eeprom.h > > diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c > index c929c61d582a..382965f82c38 100644 > --- a/hw/arm/aspeed.c > +++ b/hw/arm/aspeed.c > @@ -14,6 +14,7 @@ > #include "hw/arm/boot.h" > #include "hw/arm/aspeed.h" > #include "hw/arm/aspeed_soc.h" > +#include "hw/arm/aspeed_eeprom.h" > #include "hw/i2c/i2c_mux_pca954x.h" > #include "hw/i2c/smbus_eeprom.h" > #include "hw/misc/pca9552.h" > @@ -940,9 +941,12 @@ static void fby35_i2c_init(AspeedMachineState *bmc) > > at24c_eeprom_init(i2c[4], 0x51, 128 * KiB); > at24c_eeprom_init(i2c[6], 0x51, 128 * KiB); > -at24c_eeprom_init(i2c[8], 0x50, 32 * KiB); > -at24c_eeprom_init(i2c[11], 0x51, 128 * KiB); > -at24c_eeprom_init(i2c[11], 0x54, 128 * KiB); > +at24c_eeprom_init_rom(i2c[8], 0x50, 32 * KiB, fby35_nic_fruid, > + sizeof(fby35_nic_fruid)); > +at24c_eeprom_init_rom(i2c[11], 0x51, 128 * KiB, fby35_bb_fruid, > + sizeof(fby35_bb_fruid)); > +at24c_eeprom_init_rom(i2c[11], 0x54,
Re: [PATCH v3 3/5] hw/nvram/eeprom_at24c: Add init_rom field and at24c_eeprom_init_rom helper
On Tue, 17 Jan 2023 at 23:24, Peter Delevoryas wrote:
>
> Allows users to specify binary data to initialize an EEPROM, allowing users to
> emulate data programmed at manufacturing time.
I like it. Is there somewhere sensible to add a description to the
code base? Perhaps as a comment to your new function?
>
> - Added init_rom and init_rom_size attributes to TYPE_AT24C_EE
> - Added at24c_eeprom_init_rom helper function to initialize attributes
> - If -drive property is provided, it overrides init_rom data
>
> Signed-off-by: Peter Delevoryas
Reviewed-by: Joel Stanley
> ---
> hw/nvram/eeprom_at24c.c | 37 -
> include/hw/nvram/eeprom_at24c.h | 2 ++
> 2 files changed, 34 insertions(+), 5 deletions(-)
>
> diff --git a/hw/nvram/eeprom_at24c.c b/hw/nvram/eeprom_at24c.c
> index 98857e3626b9..f8d751fa278d 100644
> --- a/hw/nvram/eeprom_at24c.c
> +++ b/hw/nvram/eeprom_at24c.c
> @@ -50,6 +50,9 @@ struct EEPROMState {
> uint8_t *mem;
>
> BlockBackend *blk;
> +
> +const uint8_t *init_rom;
> +uint32_t init_rom_size;
> };
>
> static
> @@ -131,19 +134,38 @@ int at24c_eeprom_send(I2CSlave *s, uint8_t data)
>
> I2CSlave *at24c_eeprom_init(I2CBus *bus, uint8_t address, uint32_t rom_size)
> {
> -I2CSlave *i2c_dev = i2c_slave_new(TYPE_AT24C_EE, address);
> -DeviceState *dev = DEVICE(i2c_dev);
> +return at24c_eeprom_init_rom(bus, address, rom_size, NULL, 0);
> +}
> +
> +I2CSlave *at24c_eeprom_init_rom(I2CBus *bus, uint8_t address, uint32_t
> rom_size,
> +const uint8_t *init_rom, uint32_t
> init_rom_size)
> +{
> +EEPROMState *s;
> +
> +s = AT24C_EE(qdev_new(TYPE_AT24C_EE));
> +
> +qdev_prop_set_uint8(DEVICE(s), "address", address);
> +qdev_prop_set_uint32(DEVICE(s), "rom-size", rom_size);
>
> -qdev_prop_set_uint32(dev, "rom-size", rom_size);
> -i2c_slave_realize_and_unref(i2c_dev, bus, &error_abort);
> +/* TODO: Model init_rom with QOM properties. */
> +s->init_rom = init_rom;
> +s->init_rom_size = init_rom_size;
>
> -return i2c_dev;
> +i2c_slave_realize_and_unref(I2C_SLAVE(s), bus, &error_abort);
> +
> +return I2C_SLAVE(s);
> }
>
> static void at24c_eeprom_realize(DeviceState *dev, Error **errp)
> {
> EEPROMState *ee = AT24C_EE(dev);
>
> +if (ee->init_rom_size > ee->rsize) {
> +error_setg(errp, "%s: init rom is larger than rom: %u > %u",
> + TYPE_AT24C_EE, ee->init_rom_size, ee->rsize);
> +return;
> +}
> +
> if (ee->blk) {
> int64_t len = blk_getlength(ee->blk);
>
> @@ -163,6 +185,7 @@ static void at24c_eeprom_realize(DeviceState *dev, Error
> **errp)
> }
>
> ee->mem = g_malloc0(ee->rsize);
> +
> }
>
> static
> @@ -176,6 +199,10 @@ void at24c_eeprom_reset(DeviceState *state)
>
> memset(ee->mem, 0, ee->rsize);
>
> +if (ee->init_rom) {
> +memcpy(ee->mem, ee->init_rom, MIN(ee->init_rom_size, ee->rsize));
I like the MIN here; good usability feature. It's worth documenting too.
> +}
> +
> if (ee->blk) {
> int ret = blk_pread(ee->blk, 0, ee->rsize, ee->mem, 0);
>
> diff --git a/include/hw/nvram/eeprom_at24c.h b/include/hw/nvram/eeprom_at24c.h
> index 196db309d451..5c9149331144 100644
> --- a/include/hw/nvram/eeprom_at24c.h
> +++ b/include/hw/nvram/eeprom_at24c.h
> @@ -19,5 +19,7 @@
> * @bus, and drop the reference to it (the device is realized).
> */
> I2CSlave *at24c_eeprom_init(I2CBus *bus, uint8_t address, uint32_t rom_size);
> +I2CSlave *at24c_eeprom_init_rom(I2CBus *bus, uint8_t address, uint32_t
> rom_size,
> +const uint8_t *init_rom, uint32_t
> init_rom_size);
>
> #endif
> --
> 2.39.0
>
Re: [PATCH v3 1/5] hw/arm: Extract at24c_eeprom_init helper from Aspeed and Nuvoton boards
On Tue, 17 Jan 2023 at 23:24, Peter Delevoryas wrote:
>
> This helper is useful in board initialization because lets users initialize
> and
> realize an EEPROM on an I2C bus with a single function call.
>
> Signed-off-by: Peter Delevoryas
> Reviewed-by: Cédric Le Goater
Reviewed-by: Joel Stanley
> ---
> hw/arm/aspeed.c | 10 +-
> hw/arm/npcm7xx_boards.c | 20 +---
> hw/nvram/eeprom_at24c.c | 12
> include/hw/nvram/eeprom_at24c.h | 23 +++
> 4 files changed, 41 insertions(+), 24 deletions(-)
> create mode 100644 include/hw/nvram/eeprom_at24c.h
>
> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
> index 55f114ef729f..1f9799d4321e 100644
> --- a/hw/arm/aspeed.c
> +++ b/hw/arm/aspeed.c
> @@ -17,6 +17,7 @@
> #include "hw/i2c/i2c_mux_pca954x.h"
> #include "hw/i2c/smbus_eeprom.h"
> #include "hw/misc/pca9552.h"
> +#include "hw/nvram/eeprom_at24c.h"
> #include "hw/sensor/tmp105.h"
> #include "hw/misc/led.h"
> #include "hw/qdev-properties.h"
> @@ -429,15 +430,6 @@ static void aspeed_machine_init(MachineState *machine)
> arm_load_kernel(ARM_CPU(first_cpu), machine, &aspeed_board_binfo);
> }
>
> -static void at24c_eeprom_init(I2CBus *bus, uint8_t addr, uint32_t rsize)
> -{
> -I2CSlave *i2c_dev = i2c_slave_new("at24c-eeprom", addr);
> -DeviceState *dev = DEVICE(i2c_dev);
> -
> -qdev_prop_set_uint32(dev, "rom-size", rsize);
> -i2c_slave_realize_and_unref(i2c_dev, bus, &error_abort);
> -}
> -
> static void palmetto_bmc_i2c_init(AspeedMachineState *bmc)
> {
> AspeedSoCState *soc = &bmc->soc;
> diff --git a/hw/arm/npcm7xx_boards.c b/hw/arm/npcm7xx_boards.c
> index 6bc6f5d2fe29..9b31207a06e9 100644
> --- a/hw/arm/npcm7xx_boards.c
> +++ b/hw/arm/npcm7xx_boards.c
> @@ -21,6 +21,7 @@
> #include "hw/i2c/i2c_mux_pca954x.h"
> #include "hw/i2c/smbus_eeprom.h"
> #include "hw/loader.h"
> +#include "hw/nvram/eeprom_at24c.h"
> #include "hw/qdev-core.h"
> #include "hw/qdev-properties.h"
> #include "qapi/error.h"
> @@ -140,17 +141,6 @@ static I2CBus *npcm7xx_i2c_get_bus(NPCM7xxState *soc,
> uint32_t num)
> return I2C_BUS(qdev_get_child_bus(DEVICE(&soc->smbus[num]), "i2c-bus"));
> }
>
> -static void at24c_eeprom_init(NPCM7xxState *soc, int bus, uint8_t addr,
> - uint32_t rsize)
> -{
> -I2CBus *i2c_bus = npcm7xx_i2c_get_bus(soc, bus);
> -I2CSlave *i2c_dev = i2c_slave_new("at24c-eeprom", addr);
> -DeviceState *dev = DEVICE(i2c_dev);
> -
> -qdev_prop_set_uint32(dev, "rom-size", rsize);
> -i2c_slave_realize_and_unref(i2c_dev, i2c_bus, &error_abort);
> -}
> -
> static void npcm7xx_init_pwm_splitter(NPCM7xxMachine *machine,
>NPCM7xxState *soc, const int
> *fan_counts)
> {
> @@ -253,8 +243,8 @@ static void quanta_gsj_i2c_init(NPCM7xxState *soc)
> i2c_slave_create_simple(npcm7xx_i2c_get_bus(soc, 3), "tmp105", 0x5c);
> i2c_slave_create_simple(npcm7xx_i2c_get_bus(soc, 4), "tmp105", 0x5c);
>
> -at24c_eeprom_init(soc, 9, 0x55, 8192);
> -at24c_eeprom_init(soc, 10, 0x55, 8192);
> +at24c_eeprom_init(npcm7xx_i2c_get_bus(soc, 9), 0x55, 8192);
> +at24c_eeprom_init(npcm7xx_i2c_get_bus(soc, 10), 0x55, 8192);
>
> /*
> * i2c-11:
> @@ -360,7 +350,7 @@ static void kudo_bmc_i2c_init(NPCM7xxState *soc)
>
> i2c_slave_create_simple(npcm7xx_i2c_get_bus(soc, 4), TYPE_PCA9548, 0x77);
>
> -at24c_eeprom_init(soc, 4, 0x50, 8192); /* mbfru */
> +at24c_eeprom_init(npcm7xx_i2c_get_bus(soc, 4), 0x50, 8192); /* mbfru */
>
> i2c_mux = i2c_slave_create_simple(npcm7xx_i2c_get_bus(soc, 13),
>TYPE_PCA9548, 0x77);
> @@ -371,7 +361,7 @@ static void kudo_bmc_i2c_init(NPCM7xxState *soc)
> i2c_slave_create_simple(pca954x_i2c_get_bus(i2c_mux, 4), "tmp105", 0x48);
> i2c_slave_create_simple(pca954x_i2c_get_bus(i2c_mux, 5), "tmp105", 0x49);
>
> -at24c_eeprom_init(soc, 14, 0x55, 8192); /* bmcfru */
> +at24c_eeprom_init(npcm7xx_i2c_get_bus(soc, 14), 0x55, 8192); /* bmcfru */
>
> /* TODO: Add remaining i2c devices. */
> }
> diff --git a/hw/nvram/eeprom_at24c.c b/hw/nvram/eeprom_at24c.c
> index 2d4d8b952f38..98857e3626b9 100644
> --- a/hw/nvram/eeprom_at24c.c
> +++ b/hw/nvram/eeprom_at24c.c
> @@ -12,6 +12,7 @@
> #include "qapi/error.h"
> #include "q
Re: [PATCH v3 2/5] hw/arm/aspeed: Replace aspeed_eeprom_init with at24c_eeprom_init
On Tue, 17 Jan 2023 at 23:24, Peter Delevoryas wrote:
>
> aspeed_eeprom_init is an exact copy of at24c_eeprom_init, not needed.
>
> Signed-off-by: Peter Delevoryas
> Reviewed-by: Cédric Le Goater
> Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Joel Stanley
> ---
> hw/arm/aspeed.c | 95 ++---
> 1 file changed, 43 insertions(+), 52 deletions(-)
>
> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
> index 1f9799d4321e..c929c61d582a 100644
> --- a/hw/arm/aspeed.c
> +++ b/hw/arm/aspeed.c
> @@ -660,15 +660,6 @@ static void g220a_bmc_i2c_init(AspeedMachineState *bmc)
>eeprom_buf);
> }
>
> -static void aspeed_eeprom_init(I2CBus *bus, uint8_t addr, uint32_t rsize)
> -{
> -I2CSlave *i2c_dev = i2c_slave_new("at24c-eeprom", addr);
> -DeviceState *dev = DEVICE(i2c_dev);
> -
> -qdev_prop_set_uint32(dev, "rom-size", rsize);
> -i2c_slave_realize_and_unref(i2c_dev, bus, &error_abort);
> -}
> -
> static void fp5280g2_bmc_i2c_init(AspeedMachineState *bmc)
> {
> AspeedSoCState *soc = &bmc->soc;
> @@ -701,7 +692,7 @@ static void rainier_bmc_i2c_init(AspeedMachineState *bmc)
> AspeedSoCState *soc = &bmc->soc;
> I2CSlave *i2c_mux;
>
> -aspeed_eeprom_init(aspeed_i2c_get_bus(&soc->i2c, 0), 0x51, 32 * KiB);
> +at24c_eeprom_init(aspeed_i2c_get_bus(&soc->i2c, 0), 0x51, 32 * KiB);
>
> create_pca9552(soc, 3, 0x61);
>
> @@ -714,9 +705,9 @@ static void rainier_bmc_i2c_init(AspeedMachineState *bmc)
> 0x4a);
> i2c_mux = i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 4),
>"pca9546", 0x70);
> -aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 0), 0x50, 64 * KiB);
> -aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 1), 0x51, 64 * KiB);
> -aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 2), 0x52, 64 * KiB);
> +at24c_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 0), 0x50, 64 * KiB);
> +at24c_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 1), 0x51, 64 * KiB);
> +at24c_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 2), 0x52, 64 * KiB);
> create_pca9552(soc, 4, 0x60);
>
> i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 5), TYPE_TMP105,
> @@ -727,8 +718,8 @@ static void rainier_bmc_i2c_init(AspeedMachineState *bmc)
> create_pca9552(soc, 5, 0x61);
> i2c_mux = i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 5),
>"pca9546", 0x70);
> -aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 0), 0x50, 64 * KiB);
> -aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 1), 0x51, 64 * KiB);
> +at24c_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 0), 0x50, 64 * KiB);
> +at24c_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 1), 0x51, 64 * KiB);
>
> i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 6), TYPE_TMP105,
> 0x48);
> @@ -738,10 +729,10 @@ static void rainier_bmc_i2c_init(AspeedMachineState
> *bmc)
> 0x4b);
> i2c_mux = i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 6),
>"pca9546", 0x70);
> -aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 0), 0x50, 64 * KiB);
> -aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 1), 0x51, 64 * KiB);
> -aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 2), 0x50, 64 * KiB);
> -aspeed_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 3), 0x51, 64 * KiB);
> +at24c_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 0), 0x50, 64 * KiB);
> +at24c_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 1), 0x51, 64 * KiB);
> +at24c_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 2), 0x50, 64 * KiB);
> +at24c_eeprom_init(pca954x_i2c_get_bus(i2c_mux, 3), 0x51, 64 * KiB);
>
> create_pca9552(soc, 7, 0x30);
> create_pca9552(soc, 7, 0x31);
> @@ -754,15 +745,15 @@ static void rainier_bmc_i2c_init(AspeedMachineState
> *bmc)
> i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 7), TYPE_TMP105,
> 0x48);
> i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 7), "max31785",
> 0x52);
> -aspeed_eeprom_init(aspeed_i2c_get_bus(&soc->i2c, 7), 0x50, 64 * KiB);
> -aspeed_eeprom_init(aspeed_i2c_get_bus(&soc->i2c, 7), 0x51, 64 * KiB);
> +at24c_eeprom_init(aspeed_i2c_get_bus(&soc->i2c, 7), 0x50, 64 * KiB);
> +at24c_eeprom_init(aspeed_i2c_get_bus(&soc->i2c, 7), 0x51, 64 * KiB);
>
> i2c_slave_create_simple(aspeed_i2c_get_bus(&soc->i2c, 8), TYPE_TMP105,
> 0x48
Re: [PATCH 0/2] target/ppc: Implement Dynamic Execution Control Registers
Hi Nick,
On Thu, 24 Nov 2022 at 05:53, Nicholas Miehlbradt
wrote:
>
> Implements the Dynamic Execution Control Register (DEXCR) and the
> Hypervisor Dynamic Execution Control Register (HDEXCR) in TCG as
> defined in Power ISA 3.1B. Only aspects 5 (Non-privileged hash instruction
> enable) and 6 (Privileged hash instruction enable) have architectural
> effects. Other aspects can be manipulated but have no effect on execution.
>
> Adds checks to these registers in the hashst and hashchk instructions so
> that they are executed as nops when not enabled.
I had a look at these and they appear to follow the style of the
existing code. I am no expert on the target code though!
It might be worth mentioning to reviewers that these registers will be
exercised by the Linux kernel with some upcoming patches that you're
developing.
Cheers,
Joel
>
> Nicholas Miehlbradt (2):
> target/ppc: Implement the DEXCR and HDEXCR
> target/ppc: Check DEXCR on hash{st, chk} instructions
>
> target/ppc/cpu.h | 19 +
> target/ppc/cpu_init.c| 25 +
> target/ppc/excp_helper.c | 58 +---
> target/ppc/spr_common.h | 1 +
> target/ppc/translate.c | 9 +++
> 5 files changed, 97 insertions(+), 15 deletions(-)
>
> --
> 2.34.1
>
>
