Le Goater
Acked-by: Andrew Jeffery
On Tue, 2023-12-12 at 17:29 +0100, Philippe Mathieu-Daudé wrote:
> Set the properties on the a7mpcore object to let it create and
> wire the CPU cores. Remove the redundant code.
>
> Signed-off-by: Philippe Mathieu-Daudé
Acked-by: Andrew Jeffery
For my own benefit it looks like the motivating thread for this series
is:
https://lore.kernel.org/qemu-devel/936e1ac4-cef8-08b4-c688-e5b1e0572...@linaro.org/
Anyway,
Reviewed-by: Andrew Jeffery # aspeed
ice--+--+-+
> State Low | Low | Low |
> --+--+-----+
>
> Signed-off-by: Glenn Miles
Reviewed-by: Andrew Jeffery
;
> Signed-off-by: Glenn Miles
Reviewed-by: Andrew Jeffery
On Thu, 2023-10-26 at 10:27 -0500, Ninad Palsule wrote:
> Hello Cedric,
>
>
> On 10/24/23 10:21, Cédric Le Goater wrote:
> > On 10/24/23 17:00, Ninad Palsule wrote:
> > > Hello Cedric,
> > >
> > > On 10/24/23 02:46, Cédric Le Goater wrote:
> > > > and the fsi_opb_* routines are useless to me.
>
On Wed, 2023-10-25 at 10:57 +0200, Cédric Le Goater wrote:
> On 10/24/23 11:36, Cédric Le Goater wrote:
> > On 9/25/23 08:22, Andrew Jeffery wrote:
> > > I've changed employers, have company email that deals with patch-based
> > > workflows without too much of a heada
On Wed, 2023-10-25 at 11:22 +0200, Klaus Jensen wrote:
> On Oct 25 11:14, Cédric Le Goater wrote:
> > It seems that the "at24c-eeprom" model doesn't have a maintainer. Until
> > this is sorted out, may be this change could go through the NVMe queue
> > since it is related.
> >
>
> I can, but I'm
orget to collect those on your
patches before sending out a new set. Something for next time :)
Anyway,
Reviewed-by: Andrew Jeffery
On Fri, 2023-10-20 at 13:23 -0500, Glenn Miles wrote:
> The pca9552 code was updating output GPIO states whenever
> the pin state was updated even if the state did not change.
> This commit adds a check so that we only update the GPIO
> output when the pin state actually changes.
Given this is
On Fri, 2023-10-20 at 11:32 -0500, Miles Glenn wrote:
> On Fri, 2023-10-20 at 11:42 +0200, Philippe Mathieu-Daudé wrote:
> > On 20/10/23 04:51, Andrew Jeffery wrote:
> > > On Thu, 2023-10-19 at 15:40 -0500, Glenn Miles wrote:
> > > > > The pca9552 INPUT0
On Thu, 2023-10-19 at 15:40 -0500, 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
>
sets it to a logical 1.
> > + */
> > + qemu_set_irq(s->gpio[i], 1);
> > +s->regs[input_reg] |= 1 << input_shift;
> > +break;
So the witherspoon-bmc machine was a user of the PCA9552 outputs as
LEDs. I guess its LEDs were in the w
On Mon, 25 Sep 2023, at 18:50, Cédric Le Goater wrote:
> On 9/25/23 09:54, Andrew Jeffery wrote:
>>
>>
>> On Fri, 22 Sep 2023, at 22:51, Cédric Le Goater wrote:
>>> Joel, Andrew,
>>>
>>> On 5/25/19 17:12, Cédric Le Goater wrote:
>>&g
On Mon, 25 Sep 2023, at 17:28, Cédric Le Goater wrote:
> On 9/25/23 08:22, Andrew Jeffery wrote:
>> I've changed employers, have company email that deals with patch-based
>> workflows without too much of a headache, and am trying to steer some
>> content out of my persona
chedule the timer
>> expiry as the guest requests, but if we have missed the deadline we
>> re interrupt and try again, which allows the guest to catch up.
>>
>> Provides expected behaviour with old and new guest code.
>>
>> Fixes: c04bd47db6b9 ("h
iomem);
>>
>> for (i = 0; i < ASPEED_I3C_NR_DEVICES; ++i) {
>> -Object *dev = OBJECT(>devices[i]);
>> +Object *i3c_dev = OBJECT(>devices[i]);
Maybe `s/i3c_dev/subdev`? I dunno. That bikeshed isn't gonna
I've changed employers, have company email that deals with patch-based
workflows without too much of a headache, and am trying to steer some
content out of my personal mail.
Signed-off-by: Andrew Jeffery
---
Hi Cédric, do you mind including this in your Aspeed queue?
MAINTAINERS | 2 +-
1
entation :)
Reviewed-by: Andrew Jeffery
> ---
> hw/i2c/smbus_master.c | 26 ++
> include/hw/i2c/smbus_master.h | 2 ++
> 2 files changed, 28 insertions(+)
>
> diff --git a/hw/i2c/smbus_master.c b/hw/i2c/smbus_master.c
> index 6a53c3
@huawei.com/
> [2]:
> https://lore.kernel.org/qemu-devel/20221121080445.ga29...@codeconstruct.com.au/
>
> Tested-by: Jonathan Cameron
> Reviewed-by: Jonathan Cameron
> Signed-off-by: Klaus Jensen
Nice!
Reviewed-by: Andrew Jeffery
gt; +static void nmi_reset(MCTPI2CEndpoint *mctp)
> +{
> +NMIDevice *nmi = NMI_I2C_DEVICE(mctp);
> +nmi->len = 0;
> +}
> +
> +static void nmi_handle(MCTPI2CEndpoint *mctp)
> +{
> +NMIDevice *nmi = NMI_I2C_DEVICE(mctp);
> +NMIMessage *msg
to 0h
https://nvmexpress.org/wp-content/uploads/NVM-Express-Management-Interface-Specification-1.2c-2022.10.06-Ratified.pdf
This change makes it possible to expose NVMe VPD in a manner that can be
dynamically detected by OpenBMC.
Signed-off-by: Andrew Jeffery
---
hw/nvram/eeprom_at24c.c | 18 +
Hi Klaus,
On Thu, 2023-09-14 at 08:51 +0200, Klaus Jensen wrote:
> On Sep 12 13:50, Andrew Jeffery wrote:
> > Hi Klaus,
> >
> > On Tue, 2023-09-05 at 10:38 +0200, Klaus Jensen wrote:
> > > >
> > > > +static void nmi_handle_mi_config_ge
Hi Klaus,
On Tue, 2023-09-05 at 10:38 +0200, Klaus Jensen wrote:
> >
> > +static void nmi_handle_mi_config_get(NMIDevice *nmi, NMIRequest
> > *request)
> > +{
> > + uint32_t dw0 = le32_to_cpu(request->dw0);
> > + uint8_t identifier = FIELD_EX32(dw0,
> > NMI_CMD_CONFIGURATION_GET_DW0,
> > +
On Wed, 24 May 2023, at 17:14, Joel Stanley wrote:
> On Wed, 24 May 2023 at 06:38, Cédric Le Goater wrote:
>>
>> But, I also got this :
>>
>>root@p10bmc:~# [ 91.656331] watchdog: watchdog0: watchdog did not stop!
>>[ 91.734858] systemd-shutdown[1]: Using hardware watchdog
build tested the two as a sanity check.
Cheers,
Andrew
Andrew Jeffery (2):
linux-user: elfload: s/min_mmap_addr/mmap_min_addr/
linux-user: elfload: Specify -R is an option for qemu-user binaries
linux-user/elfload.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--
2.39.2
As-is the error message can cause some confusion as the mentioned sysctl
attribute name is wrong:
https://www.kernel.org/doc/html/latest/admin-guide/sysctl/vm.html#mmap-min-addr
Signed-off-by: Andrew Jeffery
---
linux-user/elfload.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Given several different concepts are suggested for investigation, let's
not confuse e.g. ulimit's -R with what was actually intended.
Signed-off-by: Andrew Jeffery
---
linux-user/elfload.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/linux-user/elfload.c b/linux-user
On Thu, 19 Jan 2023, at 23:14, Joel Stanley wrote:
> 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
On Sun, 31 Jul 2022, at 06:48, Cédric Le Goater wrote:
> On 7/29/22 19:30, Peter Delevoryas wrote:
>> Certainly we'd like to use IRQ's instead, but she ran into correctness
>> problems. Maybe we can investigate that further and fix it.
Yes, let's not work around problems that we have the
On Mon, 25 Jul 2022, at 16:02, Cédric Le Goater wrote:
> On 7/25/22 04:08, Andrew Jeffery wrote:
>>
>>
>> On Fri, 22 Jul 2022, at 16:06, Cédric Le Goater wrote:
>>> aspeed_machine_witherspoon_class_init(ObjectClass *oc, void *data)
>>> mc-&
On Fri, 22 Jul 2022, at 16:06, Cédric Le Goater wrote:
> A mx25l25635f chip model is generally found on these machines. It's
> newer and uses 4B opcodes which is better to exercise the support in
> the Linux kernel.
>
> Signed-off-by: Cédric Le Goater
> ---
> hw/arm/aspeed.c | 6 +++---
> 1
I think we've sorted this out, but replying to finalise the conversation
On Tue, 12 Jul 2022, at 11:27, Peter Delevoryas wrote:
> On Mon, Jul 11, 2022 at 10:56:08PM +0930, Andrew Jeffery wrote:
>>
>> /*
>> @@ -607,7 +608,7 @@ static void aspeed_gpio_write(void *opaq
On Fri, 8 Jul 2022, at 04:34, Peter Delevoryas wrote:
> On Thu, Jul 07, 2022 at 10:53:57AM -0700, Peter Delevoryas wrote:
>> On Thu, Jul 07, 2022 at 10:56:02AM +0200, Cédric Le Goater wrote:
>> > On 7/7/22 09:17, Peter Delevoryas wrote:
>> > > It seems that aspeed_gpio_update is allowing the
On Thu, 7 Jul 2022, at 17:50, Joel Stanley wrote:
> On Thu, 7 Jul 2022 at 07:17, Peter Delevoryas wrote:
>>
>> It seems that aspeed_gpio_update is allowing the value for input pins to be
>> modified through register writes and QOM property modification.
>>
>> The QOM property modification is
On Mon, 16 May 2022, at 16:48, Cédric Le Goater wrote:
> On 5/16/22 08:23, Peter Delevoryas wrote:
>> v2:
>> - Rebased on Cedric's irq proposal. [1]
>> - Added "Introduce common UART init function" patch
>> - Added "Add uarts_num SoC attribute" patch
>> - Rewrote last commit's message for
On Tue, 8 Feb 2022, at 01:34, Andrew Jeffery wrote:
> Hello,
>
> This series adds support for a new register interface supported by the
> Aspeed GPIO controller, present in at least the AST2600.
>
> The new interface is a single register implementing an indirect command
>
Not sure how that got there.
Signed-off-by: Andrew Jeffery
---
hw/gpio/aspeed_gpio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/gpio/aspeed_gpio.c b/hw/gpio/aspeed_gpio.c
index 911d21c8cfbe..c63634d3d3e2 100644
--- a/hw/gpio/aspeed_gpio.c
+++ b/hw/gpio/aspeed_gpio.c
one way by poking the driver using the
libgpiod tools and then the other using devmem to drive the new
interface.
Please review!
Andrew
Andrew Jeffery (3):
hw: aspeed_gpio: Cleanup stray semicolon after switch
hw: aspeed_gpio: Split GPIOSet handling from accessors
hw: aspeed_gpio: Support
a tedious data model, but allowed efficient multi-line
bit-banging.
Either way, the hardware model in qemu becomes quite complex, though it
would have been less so had the new interface been the only one
available.
Signed-off-by: Andrew Jeffery
---
hw/gpio/aspeed_gpio.c | 202
Pave the way for implementing the new register interface for GPIO
control provided by the AST2600. We need a consistent data model, so
do some work to enable use of the AspeedGPIOReg / GPIOSets data
structures for both.
Signed-off-by: Andrew Jeffery
---
hw/gpio/aspeed_gpio.c | 105
On Wed, 3 Nov 2021, at 02:48, Peter Maydell wrote:
> On Mon, 1 Nov 2021 at 18:31, Cédric Le Goater wrote:
>>
>> I haven't done any Aspeed development for a couple of years now and
>> maintaining the Aspeed QEMU machines has been a side project since.
>> I don't have time anymore.
>
> Thanks
Hi Cédric, Peter,
On Tue, 31 Aug 2021, at 20:09, Cédric Le Goater wrote:
> On 8/28/21 5:58 PM, Peter Delevoryas wrote:
> > I think I’m a little confused on this part. What I meant by “most machines
> > just use UART5” was that most DTS’s use “stdout-path=”, but fuji uses
> > “stdout-path=”. I
set and get")
Signed-off-by: Andrew Jeffery
---
hw/misc/pca9552.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/misc/pca9552.c b/hw/misc/pca9552.c
index b7686e27d7fa..fff19e369a39 100644
--- a/hw/misc/pca9552.c
+++ b/hw/misc/pca9552.c
@@ -272,7 +272,7 @@ static void pca955
On Fri, 9 Jul 2021, at 16:59, Philippe Mathieu-Daudé wrote:
> On 7/9/21 7:31 AM, Andrew Jeffery wrote:
> > The logic in the handling for the control register required toggling the
> > enable state for writes to stick. Rework the condition chain to allow
> > sequential writ
to ensure model
behaviour reflects the hardware.
Fixes: 854123bf8d4b ("wdt: Add Aspeed watchdog device model")
Signed-off-by: Andrew Jeffery
---
hw/watchdog/wdt_aspeed.c | 24 ++--
include/hw/watchdog/wdt_aspeed.h | 1 +
2 files changed, 23 insertions(+), 2
The logic in the handling for the control register required toggling the
enable state for writes to stick. Rework the condition chain to allow
sequential writes that do not update the enable state.
Fixes: 854123bf8d4b ("wdt: Add Aspeed watchdog device model")
Signed-off-by: Andr
was that sequential writes to
control weren't sticking if the enable bit wasn't toggled, which is fixed in the
second patch.
Please review.
Andrew
Andrew Jeffery (2):
watchdog: aspeed: Sanitize control register values
watchdog: aspeed: Fix sequential control writes
hw/watchdog/wdt_aspeed.c
On Fri, 25 Jun 2021, at 14:36, Joel Stanley wrote:
> These are the devices documented by the Rainier device tree. With this
> we can see the guest discovering the multiplexers and probing the eeprom
> devices:
>
> i2c i2c-2: Added multiplexed i2c bus 16
> i2c i2c-2: Added multiplexed i2c bus
On Thu, 13 May 2021, at 22:30, Jonathan Cameron wrote:
> On Thu, 13 May 2021 14:36:27 +0200
> Philippe Mathieu-Daudé wrote:
>
> > On 5/13/21 2:23 PM, Peter Maydell wrote:
> > > On Thu, 13 May 2021 at 12:49, Jonathan Cameron
> > > wrote:
> > >> My initial suggestion was to fix this by
On Tue, 13 Apr 2021, at 00:57, Cédric Le Goater wrote:
> On 3/4/21 1:43 PM, Joel Stanley wrote:
> > This is the latest revision of the ASPEED 2600 SoC.
>
> Should we change all machines to use the new SoC ?
>
> I would prefer if we introduced an "ast2600-a3" Aspeed SoC, that we would
> use
MD5/SHA hashing, and on the ast2600's scatter gather
> engine.
>
> Co-developed-by: Klaus Heinrich Kiwi
> Reviewed-by: Cédric Le Goater
> Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Joel Stanley
Reviewed-by: Andrew Jeffery
On Fri, 12 Mar 2021, at 21:27, Joel Stanley wrote:
> The HACE (Hash and Crypto Engine) is a device that offloads MD5, SHA1,
> SHA2, RSA and other cryptographic algorithms.
>
> This initial model implements a subset of the device's functionality;
> currently only direct access (non-scatter
On Wed, 3 Mar 2021, at 17:33, Joel Stanley wrote:
> Add the hash and crypto engine model to the aspeed socs.
>
> Signed-off-by: Joel Stanley
> [ clg: documentation update ]
> Signed-off-by: Cédric Le Goater
Reviewed-by: Andrew Jeffery
On Wed, 3 Mar 2021, at 17:33, Joel Stanley wrote:
> The HACE (Hash and Crpyto Engine) is a device that offloads MD5, SHA1,
> SHA2, RSA and other cryptographic algorithms.
>
> This initial model implements a subset of the device's functionality;
> currently only direct access (non-scatter
associated with each register.
The model caters to the IRQ style of both the AST2600 and the earlier
SoCs (AST2400 and AST2500). The AST2600 allocates an IRQ for each LPC
sub-device, while there is a single IRQ shared across all subdevices on
the AST2400 and AST2500.
Signed-off-by: Andrew Jeffery
From: Cédric Le Goater
This is a very minimal framework to access registers which are used to
configure the AHB memory mapping of the flash chips on the LPC HC
Firmware address space.
Signed-off-by: Cédric Le Goater
Signed-off-by: Andrew Jeffery
---
docs/system/arm/aspeed.rst | 2 +-
hw
This appears to be a requirement of the GIC model. The AST2600 allocates
197 GIC IRQs, which we will adjust shortly.
Signed-off-by: Andrew Jeffery
Reviewed-by: Cédric Le Goater
---
hw/arm/aspeed_ast2600.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/arm
The AST2600 allocates distinct GIC IRQs for the LPC subdevices such as
the iBT device. Previously on the AST2400 and AST2500 the LPC subdevices
shared a single LPC IRQ.
Signed-off-by: Andrew Jeffery
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Cédric Le Goater
---
hw/arm/aspeed_ast2600.c
The datasheet says we have 197 IRQs allocated, and we need more than 128
to describe IRQs from LPC devices. Raise the value now to allow
modelling of the LPC devices.
Signed-off-by: Andrew Jeffery
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Cédric Le Goater
---
hw/arm/aspeed_ast2600.c
[2]
https://lore.kernel.org/openbmc/20210219142523.3464540-1-and...@aj.id.au/T/#m1e2029e7aa2be3056320e8d46b3b5b1539a776b4
Andrew Jeffery (4):
hw/arm: ast2600: Force a multiple of 32 of IRQs for the GIC
hw/arm: ast2600: Set AST2600_MAX_IRQ to value from datasheet
hw/arm: ast2600: Correct the iBT
On Mon, 1 Mar 2021, at 11:36, Andrew Jeffery wrote:
> From: Cédric Le Goater
>
> This is a very minimal framework to access registers which are used to
> configure the AHB memory mapping of the flash chips on the LPC HC
> Firmware address space.
>
> Signed-off-by: Cédri
associated with each register.
The model caters to the IRQ style of both the AST2600 and the earlier
SoCs (AST2400 and AST2500). The AST2600 allocates an IRQ for each LPC
sub-device, while there is a single IRQ shared across all subdevices on
the AST2400 and AST2500.
Signed-off-by: Andrew Jeffery
-
The AST2600 allocates distinct GIC IRQs for the LPC subdevices such as
the iBT device. Previously on the AST2400 and AST2500 the LPC subdevices
shared a single LPC IRQ.
Signed-off-by: Andrew Jeffery
---
hw/arm/aspeed_ast2600.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Cédric Le Goater
This is a very minimal framework to access registers which are used to
configure the AHB memory mapping of the flash chips on the LPC HC
Firmware address space.
Signed-off-by: Cédric Le Goater
Signed-off-by: Andrew Jeffery
---
docs/system/arm/aspeed.rst | 2 +-
hw
aj.id.au/T/#m1e2029e7aa2be3056320e8d46b3b5b1539a776b4
Andrew Jeffery (4):
arm: ast2600: Force a multiple of 32 of IRQs for the GIC
hw/arm: ast2600: Set AST2600_MAX_IRQ to value from datasheet
hw/arm: ast2600: Correct the iBT interrupt ID
hw/misc: Model KCS devices in the Aspeed LPC controller
Cédric Le Goater (1):
hw
The datasheet says we have 197 IRQs allocated, and we need more than 128
to describe IRQs from LPC devices. Raise the value now to allow
modelling of the LPC devices.
Signed-off-by: Andrew Jeffery
---
hw/arm/aspeed_ast2600.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw
This appears to be a requirement of the GIC model. The AST2600 allocates
197 GIC IRQs, which we will adjust shortly.
Signed-off-by: Andrew Jeffery
---
hw/arm/aspeed_ast2600.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/arm/aspeed_ast2600.c b/hw/arm/aspeed_ast2600
On Mon, 1 Mar 2021, at 09:37, Andrew Jeffery wrote:
>
>
> On Fri, 26 Feb 2021, at 19:26, Philippe Mathieu-Daudé wrote:
> > On 2/26/21 7:57 AM, Andrew Jeffery wrote:
> > > This appears to be a requirement of the GIC model.
> >
> > If so this should be adjus
On Fri, 26 Feb 2021, at 20:21, Cédric Le Goater wrote:
> On 2/26/21 7:57 AM, Andrew Jeffery wrote:
> > Keyboard-Controller-Style devices for IPMI purposes are exposed via LPC
> > IO cycles from the BMC to the host.
> >
> > Expose support on the BMC side by
On Fri, 26 Feb 2021, at 19:28, Philippe Mathieu-Daudé wrote:
> On 2/26/21 7:57 AM, Andrew Jeffery wrote:
> > The AST2600 allocates individual GIC IRQ lines for the LPC sub-devices.
> > This is a contrast to the AST2400 and AST2500 which use one shared VIC
> > IRQ line fo
On Fri, 26 Feb 2021, at 19:26, Philippe Mathieu-Daudé wrote:
> On 2/26/21 7:57 AM, Andrew Jeffery wrote:
> > This appears to be a requirement of the GIC model.
>
> If so this should be adjusted in the GIC or a15mp_priv_realize(),
> not in each caller, isn't it?
>
associated with each register.
The model caters to the IRQ style of both the AST2600 and the earlier
SoCs (AST2400 and AST2500). The AST2600 allocates an IRQ for each LPC
sub-device, while there is a single IRQ shared across all subdevices on
the AST2400 and AST2500.
Signed-off-by: Andrew Jeffery
-
From: Cédric Le Goater
This is a very minimal framework to access registers which are used to
configure the AHB memory mapping of the flash chips on the LPC HC
Firmware address space.
Signed-off-by: Cédric Le Goater
Signed-off-by: Andrew Jeffery
---
docs/system/arm/aspeed.rst | 2 +-
hw
This appears to be a requirement of the GIC model. The AST2600 allocates
197 GIC IRQs, which we will adjust shortly.
Signed-off-by: Andrew Jeffery
---
hw/arm/aspeed_ast2600.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/arm/aspeed_ast2600.c b/hw/arm/aspeed_ast2600
to the allocated number of IRQs
in the datasheet.
Signed-off-by: Andrew Jeffery
---
hw/arm/aspeed_ast2600.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/arm/aspeed_ast2600.c b/hw/arm/aspeed_ast2600.c
index bc0eeb058b24..2125a96ef317 100644
--- a/hw/arm/aspeed_ast2600.c
[2]
https://lore.kernel.org/openbmc/20210219142523.3464540-1-and...@aj.id.au/T/#m1e2029e7aa2be3056320e8d46b3b5b1539a776b4
Andrew Jeffery (3):
arm: ast2600: Force a multiple of 32 of IRQs for the GIC
arm: ast2600: Fix iBT IRQ ID
hw/misc: Model KCS devices in the Aspeed LPC controller
Cédric Le
On Fri, 29 Jan 2021, at 19:09, Cédric Le Goater wrote:
> On 1/28/21 11:40 PM, David Gibson wrote:
> > On Thu, Jan 28, 2021 at 08:46:01AM +0100, Cédric Le Goater wrote:
> >> On 1/28/21 1:46 AM, Joel Stanley wrote:
> >>> On Tue, 26 Jan 2021 at 17:14, Cédric Le Goater wrote:
>
> and
On Wed, 30 Sep 2020, at 19:37, Cédric Le Goater wrote:
> On 9/30/20 7:29 AM, Andrew Jeffery wrote:
> >
> >
> > On Fri, 18 Sep 2020, at 02:33, Cédric Le Goater wrote:
> >> On 9/17/20 6:57 PM, Philippe Mathieu-Daudé wrote:
> >>> On 9/16/20 7:51 AM, Cédr
On Fri, 18 Sep 2020, at 02:33, Cédric Le Goater wrote:
> On 9/17/20 6:57 PM, Philippe Mathieu-Daudé wrote:
> > On 9/16/20 7:51 AM, Cédric Le Goater wrote:
> >> On 9/15/20 7:23 PM, Philippe Mathieu-Daudé wrote:
> >>> ping?
> >>
> >> It's reviewed :
> >>
> >>
> >>
straight PRIx64 rather than
HWADDR_PRIx?
Otherwise the change seems sensible, so:
Reviewed-by: Andrew Jeffery
eed_i2c_get_bus() callers by using AspeedI2CState
> argument.
>
> Reviewed-by: Markus Armbruster
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Andrew Jeffery
On Mon, 22 Jun 2020, at 18:13, Philippe Mathieu-Daudé wrote:
> On 6/22/20 2:21 AM, Andrew Jeffery wrote:
> > On Wed, 17 Jun 2020, at 13:11, Philippe Mathieu-Daudé wrote:
> >> Hi Andrew,
> >>
> >> On 6/17/20 3:18 AM, Andrew Jeffery wrote:
> >>>
On Wed, 17 Jun 2020, at 13:11, Philippe Mathieu-Daudé wrote:
> Hi Andrew,
>
> On 6/17/20 3:18 AM, Andrew Jeffery wrote:
> > On Tue, 16 Jun 2020, at 17:21, Philippe Mathieu-Daudé wrote:
> >> The current implementation uses nano-second precision, while
> >> the
On Tue, 16 Jun 2020, at 17:21, Philippe Mathieu-Daudé wrote:
> The current implementation uses nano-second precision, while
> the watchdog can not be more precise than a micro-second.
What's the basis for this assertion? It's true for the AST2500 and AST2600, but
the AST2400 can run the
>
> >> + * Hash/Crypto Engine
> >> + * PCI-Express 1 Controller
> >> + * Graphic Display Controller
> >> + * PECI Controller
> >> + * MCTP Controller
> >> + * Mailbox Controller
> >> + * Virtual UART
> >
> > Uh what is that? :)
>
> It is the host console.
>
To explain a little more, a
On Mon, 18 May 2020, at 21:49, Cédric Le Goater wrote:
> On 5/18/20 7:03 AM, Markus Armbruster wrote:
> > These devices are optional, and controlled by @nb_nics.
> > aspeed_soc_ast2600_init() and aspeed_soc_init() create the maximum
> > supported number. aspeed_soc_ast2600_realize() and
> >
600_EVB_HW_STRAP2;
> amc->fmc_model = "w25q512jv";
> @@ -600,8 +600,8 @@ static void
> aspeed_machine_tacoma_class_init(ObjectClass *oc, void *data)
> MachineClass *mc = MACHINE_CLASS(oc);
> AspeedMachineClass *amc = ASPEED_MACHINE_CLASS(oc);
>
> - mc->desc = "Aspeed AST2600 EVB (Cortex A7)";
> -amc->soc_name = "ast2600-a0";
> +mc->desc = "OpenPOWER Tacoma BMC (Cortex A7)";
Lol, whoops.
Reviewed-by: Andrew Jeffery
On Fri, 10 Apr 2020, at 21:56, Peter Maydell wrote:
> On Fri, 10 Apr 2020 at 04:42, Andrew Jeffery wrote:
> > IIRC Phil wanted to enable sub-word accesses to the sample value
> > registers but I didn't want to spread logic dealing with different access
> > widths through
On Tue, 7 Apr 2020, at 18:20, Peter Maydell wrote:
> On Tue, 7 Apr 2020 at 09:45, Joel Stanley wrote:
> > On Tue, 7 Apr 2020 at 08:41, Peter Maydell wrote:
> > > Do you have a link to this patch, please? I had a quick search through
> > > my mailing list articles but couldn't see anything
; to avoid compile failures on mingw (see the comment in
> osdep.h where we redefine assert() for that platform).
>
> Signed-off-by: Peter Maydell
Acked-by: Andrew Jeffery
; >
> > Yes, I was wondering if you were using unaligned accesses.
> >
> > I *think* the correct fix is in the "memory: Support unaligned accesses on
> > aligned-only models" patch from Andrew Jeffery:
> > https://www.mail-archive.com/qemu-devel@nong
ect and data corruption can be
> seen on machines using two chips, witherspoon and romulus.
>
> Rework the handler setting the CEx Control Register to fix this issue.
>
> Fixes: 7c1c69bca43c ("ast2400: add SMC controllers (FMC and SPI)")
> Signed-off-by: Cédric Le Goater
Champion!
Reviewed-by: Andrew Jeffery
On Thu, 6 Feb 2020, at 21:56, Cédric Le Goater wrote:
> Signed-off-by: Cédric Le Goater
Reviewed-by: Andrew Jeffery
On Tue, 21 Jan 2020, at 12:03, Joel Stanley wrote:
> This returns a fixed but non-zero value for the chip id.
>
> Signed-off-by: Joel Stanley
Reviewed-by: Andrew Jeffery
> ---
> hw/misc/aspeed_scu.c | 13 +
> 1 file changed, 13 insertions(+)
>
&
On Tue, 21 Jan 2020, at 12:03, Joel Stanley wrote:
> This splits the common write callback into separate ast2400 and ast2500
> implementations. This makes it clearer when implementing differing
> behaviour.
>
> Signed-off-by: Joel Stanley
Reviewed-by: Andrew Jeffery
On Fri, 10 Jan 2020, at 22:26, Cédric Le Goater wrote:
> >> +
> >> + sysbus_init_child_obj(obj, "emmc", OBJECT(>emmc), sizeof(s->emmc),
> >> + TYPE_ASPEED_SDHCI);
> >> +
> >> + object_property_set_int(OBJECT(>emmc), 1, "num-slots",
> >> _abort);
> >> +
> >> +
On Wed, 18 Dec 2019, at 01:55, Peter Maydell wrote:
> On Fri, 13 Dec 2019 at 05:48, Andrew Jeffery wrote:
> >
> > Hello,
> >
> > This is a v3 of the belated follow-up from a few of my earlier attempts to
> > fix
> > up the ARM generic timer for corr
On Fri, 13 Dec 2019, at 18:03, Cédric Le Goater wrote:
> On 13/12/2019 05:28, Andrew Jeffery wrote:
> > Hello,
> >
> > The AST2600 has an additional SDHCI intended for use as an eMMC boot source.
> > These two patches rework the existing ASPEED SDHCI model to acco
This matches the configuration set by u-boot on the AST2600.
Signed-off-by: Andrew Jeffery
Reviewed-by: Richard Henderson
Reviewed-by: Cédric Le Goater
Reviewed-by: Philippe Mathieu-Daudé
---
hw/arm/aspeed_ast2600.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/arm/aspeed_ast2600
1 - 100 of 289 matches
Mail list logo
