From: Peter Delevoryas
The gpio array is declared as a dense array:
qemu_irq gpios[ASPEED_GPIO_NR_PINS];
(AST2500 has 228, AST2400 has 216, AST2600 has 208)
However, this array is used like a matrix of GPIO sets
(e.g. gpio[NR_SETS][NR_PINS_PER_SET] = gpio[8][32])
size_t offset = set *
From: Peter Delevoryas
v1: https://lore.kernel.org/qemu-devel/20210924061953.1996620-1-p...@fb.com/
v2:
- Standardized the size of the GPIOSetProperties array for each
Aspeed SOC so that we can use the constant
"ASPEED_GPIO_MAX_NR_SETS" to iterate over all of them.
for multiple engines (AST2600) ]
Signed-off-by: Cédric Le Goater
[pdel : refactored engine register struct fields to regs[] array field]
[pdel : added guest-error checking for upper-8 channel regs in AST2600]
[pdel : allow 16-bit reads of the channel data registers]
Signed-off-by: Peter Delevoryas
From: Peter Delevoryas
v1: https://lore.kernel.org/qemu-devel/20211002214414.2858382-1-p...@fbc.om/
v2: https://lore.kernel.org/qemu-devel/20211003191850.513658-1-p...@fb.com/
v3:
- Reduced the minimum access size to 2, to allow 16-bit reads
- Shifted the read value down 16 bits when
From: Andrew Jeffery
Signed-off-by: Andrew Jeffery
Signed-off-by: Cédric Le Goater
Signed-off-by: Peter Delevoryas
---
hw/arm/aspeed_ast2600.c | 11 +++
hw/arm/aspeed_soc.c | 11 +++
include/hw/arm/aspeed_soc.h | 2 ++
3 files changed, 24 insertions(+)
diff
From: Andrew Jeffery
Signed-off-by: Andrew Jeffery
Signed-off-by: Cédric Le Goater
Signed-off-by: Peter Delevoryas
---
hw/arm/aspeed_ast2600.c | 11 +++
hw/arm/aspeed_soc.c | 11 +++
include/hw/arm/aspeed_soc.h | 2 ++
3 files changed, 24 insertions(+)
diff
for multiple engines (AST2600) ]
Signed-off-by: Cédric Le Goater
[pdel : refactored engine register struct fields to regs[] array field]
[pdel : added guest-error checking for upper-8 channel regs in AST2600]
Signed-off-by: Peter Delevoryas
---
hw/adc/aspeed_adc.c | 422
From: Peter Delevoryas
v1: https://lore.kernel.org/qemu-devel/20211002214414.2858382-1-p...@fbc.om/
v2:
- Added summary of changes above signed-off-by in commit message.
- Added #define's for ADC and ADC engine memory region sizes.
- Fixed "From: p...@fbc.com"
Thanks,
Peter
Andrew Jeffery
From: Andrew Jeffery
This model implements enough behaviour to do basic functionality tests
such as device initialisation and read out of dummy sample values. The
sample value generation strategy is similar to the STM ADC already in
the tree.
This patch was originally created by Andrew Jeffery,
From: Andrew Jeffery
Signed-off-by: Andrew Jeffery
Signed-off-by: Cédric Le Goater
Signed-off-by: Peter Delevoryas
---
hw/arm/aspeed_ast2600.c | 11 +++
hw/arm/aspeed_soc.c | 11 +++
include/hw/arm/aspeed_soc.h | 2 ++
3 files changed, 24 insertions(+)
diff
From: Peter Delevoryas
Following up from
https://lore.kernel.org/qemu-devel/20210930004235.1656003-1-p...@fb.com/
This is a resubmission of Andrew Jeffery's ADC model, but with the
registers converted from typed-member-fields to a regs[] array.
Otherwise, it should be pretty much equivalent.
From: Peter Delevoryas
Hey everyone,
This patch mostly just does the basic, boilerplate setup for the ADC, so
that we can start adding more ADC feature emulation in the future.
The only device behavior that I tried to add was emulating the control
initialization sequence and the sequence for
From: Peter Delevoryas
This change sets up Aspeed SoC ADC emulation, so that most ADC drivers
will pass the initialization sequence and load successfully. In the
future, we can extend this to emulate more features.
The initialization sequence is:
1. Set `ADC00` to `0xF`.
2. Wait for
From: Peter Delevoryas
Hey everyone,
I think there might be a bug in aspeed_gpio_update, where it's selecting
a GPIO IRQ to update. The indexing that maps from GPIO pin to IRQ leads
to an out-of-bounds array access and a segfault after that.
tl;dr
There's 8 rows of 32 pins (8 * 32 == 256
From: Peter Delevoryas
The gpio array is declared as a dense array:
qemu_irq gpios[ASPEED_GPIO_NR_PINS];
(AST2500 has 228, AST2400 has 216, AST2600 has 208)
However, this array is used like a matrix of GPIO sets
(e.g. gpio[NR_SETS][NR_PINS_PER_SET] = gpio[8][32])
size_t offset = set *
From: Peter Delevoryas
Some of the pin declarations in the Aspeed GPIO module were incorrect,
probably because of confusion over which bits in the input and output
uint32_t's correspond to which groups in the label array. Since the
uint32_t literals are in big endian, it's sort of the opposite
From: Peter Delevoryas
In the Aspeed chips, the GPIO pins are mostly labeled in groups of 8,
but some of the groups only have 4 elements. Also, most pins have input
and output capabilities, but some are strictly input or strictly output
pins. We have some arrays that describe the I/O
From: Peter Delevoryas
Hey everyone,
I think there might be a bug aspeed_gpio_update, when it's selecting a
GPIO IRQ to update. I was testing booting Facebook's OpenBMC platform
"YosemiteV2" (fby2), and I was hitting a segfault in QEMU:
qemu-system-arm -machine ast2500-evb \
-drive
From: Peter Delevoryas
The gpio array is declared as a dense array:
...
qemu_irq gpios[ASPEED_GPIO_NR_PINS];
(AST2500 has 228, AST2400 has 216, AST2600 has 208)
However, this array is used like a matrix of GPIO sets
(e.g. gpio[NR_SETS][NR_PINS_PER_SET] = gpio[8][32])
size_t offset = set *
From: Peter Delevoryas
This adds a new machine type "fuji-bmc" based on the following device tree:
https://github.com/torvalds/linux/blob/40cb6373b46/arch/arm/boot/dts/aspeed-bmc-facebook-fuji.dts
Most of the i2c devices are not there, they're added here:
From: Peter Delevoryas
After fixing some commit log issues in another patch:
https://lore.kernel.org/qemu-devel/2f2f44c6-4817-4d58-a7a0-496446ac7...@fb.com/
I noticed that I had similar issues in another patch I submitted:
From: Peter Delevoryas
UART5 is typically used as the default debug UART on the AST2600, but
UART1 is also designed to be a debug UART. All the AST2600 UART's have
semi-configurable clock rates through registers in the System Control
Unit (SCU), but only UART5 works out of the box with
From: Peter Delevoryas
This adds a new machine type "fuji-bmc" based on the following device tree:
https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/aspeed-bmc-facebook-fuji.dts
Most of the i2c devices are not there, they're added here:
From: Peter Delevoryas
v2:
- Added supported i2c devices (lm75, tmp75, tmp422, 24c64, 24c02)
- Switched flash model to mx66l1g45g (128MB)
- Completely separated fuji class definition from ast2600-evb
- Removed image acceptance test
Link:
From: Peter Delevoryas
This adds a new machine type "fuji-bmc" based on the following device tree:
https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/aspeed-bmc-facebook-fuji.dts
Most of the i2c devices are not there, they're added here:
From: Peter Delevoryas
This adds a new machine type "fuji-bmc" that's equivalent to
"ast2600-evb" except that it uses MAC3 and UART1. It might be
appropriate to change other aspects of this machine type in the future,
but so far this is all the specificity necessary to get a Fuji OpenBMC
image
From: Peter Delevoryas
Adding a new Aspeed AST2600 machine type, uses MAC3 for ethernet1 and
UART1 for the serial console, which is different than the existing
ast2600-evb. Otherwise though, my usage so far hasn't required a
different set of hardware strap registers or anything, so I just
From: Peter Delevoryas
When you run QEMU with an Aspeed machine and a single serial device
using stdio like this:
qemu -machine ast2600-evb -drive ... -serial stdio
The guest OS can read and write to the UART5 registers at 0x1E784000 and
it will receive from stdin and write to stdout. The
From: Peter Delevoryas
v1: https://lore.kernel.org/qemu-devel/20210831233140.2659116-1-p...@fb.com/
v2:
- Replaced AspeedMachineClass "serial_hd0" with "uart_default"
- Removed "qdev_get_machine()" usage
- Removed unnecessary aspeed.h (machine class) includes in device files
- Added "uint32_t
From: Peter Delevoryas
This is a follow-up to a discussion in a previous series I sent:
https://lore.kernel.org/qemu-devel/20210827210417.4022054-1-p...@fb.com/
I tried to add a new machine type called Fuji that required the ability
to specify the UART connected to the first serial device on
From: Peter Delevoryas
When you run QEMU with an Aspeed machine and a single serial device
using stdio like this:
qemu -machine ast2600-evb -drive ... -serial stdio
The guest OS can read and write to the UART5 registers at 0x1E784000 and
it will receive from stdin and write to stdout. The
From: Peter Delevoryas
UART5 is typically used as the default debug UART on the AST2600, but
UART1 is also designed to be a debug UART. All the AST2600 UART's have
semi-configurable clock rates through registers in the System Control
Unit (SCU), but only UART5 works out of the box with
From: Peter Delevoryas
This change replaces the UART serial device initialization code with machine
configuration data, making it so that we have a single code path for console
UART initialization, but allowing different machines to use different
UART's. This is relevant because the Aspeed chips
From: Peter Delevoryas
The AST2500 uses different logic than the AST2600 for getting IRQ's.
This adds a virtual `get_irq` function to the Aspeed SOC class, so that
the shared initialization code in `hw/arm/aspeed.c` can retrieve IRQ's.
Signed-off-by: Peter Delevoryas
---
From: Peter Delevoryas
Fuji uses the AST2600, so it's very similar to `ast2600-evb`, but it has
a few slight differences, such as using UART1 for the serial console.
Signed-off-by: Peter Delevoryas
---
hw/arm/aspeed.c | 13 +
1 file changed, 13 insertions(+)
diff --git
From: Peter Delevoryas
This register address is not actually used anywhere, and the datasheet
specifies that it's zero-initialized by default anyways, but the address
is incorrect. This just corrects the address.
Fixes: e09cf36321f6 ("hw: aspeed_scu: Add AST2600 support")
Signed-off-by: Peter
From: Peter Delevoryas
UART5 is typically used as the default debug UART on the AST2600, but
UART1 is also designed to be a debug UART. All the AST2600 UART's have
semi-configurable clock rates through registers in the System Control
Unit (SCU), but only UART5 works out of the box with
From: Peter Delevoryas
Hello!
This patch series creates an Aspeed machine type for Facebook's OpenBMC
platform "fuji".
The first 2 commits do some refactoring, to allow Aspeed machines to
configure the first serial device. Most board configurations use UART5
for the console, but fuji uses
38 matches
Mail list logo
