aboutsummaryrefslogtreecommitdiff
path: root/hw/misc/aspeed_scu.c
AgeCommit message (Collapse)Author
2018-02-22Fix ast2500 protection register emulationHugo Landau
Some register blocks of the ast2500 are protected by protection key registers which require the right magic value to be written to those registers to allow those registers to be mutated. Register manuals indicate that writing the correct magic value to these registers should cause subsequent reads from those values to return 1, and writing any other value should cause subsequent reads to return 0. Previously, qemu implemented these registers incorrectly: the registers were handled as simple memory, meaning that writing some value x to a protection key register would result in subsequent reads from that register returning the same value x. The protection was implemented by ensuring that the current value of that register equaled the magic value. This modifies qemu to have the correct behaviour: attempts to write to a ast2500 protection register results in a transition to 1 or 0 depending on whether the written value is the correct magic. The protection logic is updated to ensure that the value of the register is nonzero. This bug caused deadlocks with u-boot HEAD: when u-boot is done with a protectable register block, it attempts to lock it by writing the bitwise inverse of the correct magic value, and then spinning forever until the register reads as zero. Since qemu implemented writes to these registers as ordinary memory writes, writing the inverse of the magic value resulted in subsequent reads returning that value, leading to u-boot spinning forever. Signed-off-by: Hugo Landau <hlandau@devever.net> Reviewed-by: Cédric Le Goater <clg@kaod.org> Acked-by: Andrew Jeffery <andrew@aj.id.au> Message-id: 20180220132627.4163-1-hlandau@devever.net [PMM: fixed incorrect code indentation] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-11-20hw/arm/aspeed: Unlock SCU when running kernelJoel Stanley
The ASPEED hardware contains a lock register for the SCU that disables any writes to the SCU when it is locked. The machine comes up with the lock enabled, but on all known hardware u-boot will unlock it and leave it unlocked when loading the kernel. This means the kernel expects the SCU to be unlocked. When booting from an emulated ROM the normal u-boot unlock path is executed. Things don't go well when booting using the -kernel command line, as u-boot does not run first. Change behaviour so that when a kernel is passed to the machine, set the reset value of the SCU to be unlocked. Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-id: 20171114122018.12204-1-joel@jms.id.au Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-12-27aspeed/scu: fix SCU region sizeCédric Le Goater
Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Message-id: 1480434248-27138-12-git-send-email-clg@kaod.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-12-27aspeed: add the definitions for the AST2400 A1 SoCCédric Le Goater
There is not much differences with the A0 revision apart from the DDR calibration. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Message-id: 1480434248-27138-10-git-send-email-clg@kaod.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-09-22aspeed: add a ast2500 SoC and support to the SCU and SDMC controllersCédric Le Goater
Based on previous work done by Andrew Jeffery <andrew@aj.id.au>. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1473438177-26079-9-git-send-email-clg@kaod.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-07-14ast2400: externalize revision numbersCédric Le Goater
AST2400_A0_SILICON_REV is defined twice. Fix this by including the definition in the header file as well as the routine to check if a silicon revision is supported. It will useful to reuse in other controllers. Let's add also AST2500_A0_SILICON_REV for future use. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-id: 1467994016-11678-5-git-send-email-clg@kaod.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-07-14hw/misc: fix typo in Aspeed SCU hw-strap2 property nameCédric Le Goater
Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-id: 1467994016-11678-2-git-send-email-clg@kaod.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-06-28misc/aspeed_scu: Fix build error caused by missing headerPranith Kumar
Tracing configurations error out currently as follows: /home/travis/build/pranith/qemu/hw/misc/aspeed_scu.c: In function ‘aspeed_scu_read’: /home/travis/build/pranith/qemu/hw/misc/aspeed_scu.c:130:9: error: implicit declaration of function ‘qemu_log_mask’ [-Werror=implicit-function-declaration] /home/travis/build/pranith/qemu/hw/misc/aspeed_scu.c:130:9: error: nested extern declaration of ‘qemu_log_mask’ [-Werror=nested-externs] /home/travis/build/pranith/qemu/hw/misc/aspeed_scu.c:130:23: error: ‘LOG_GUEST_ERROR’ undeclared (first use in this function) /home/travis/build/pranith/qemu/hw/misc/aspeed_scu.c:130:23: note: each undeclared identifier is reported only once for each function it appears in /home/travis/build/pranith/qemu/hw/misc/aspeed_scu.c: In function ‘aspeed_scu_write’: /home/travis/build/pranith/qemu/hw/misc/aspeed_scu.c:154:23: error: ‘LOG_GUEST_ERROR’ undeclared (first use in this function) This is caused by a missing header file. Fix it. Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Message-id: 20160627215304.821-1-bobby.prani@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-06-27hw/misc: Add a model for the ASPEED System Control UnitAndrew Jeffery
The SCU is a collection of chip-level control registers that manage the various functions supported by ASPEED SoCs. Typically the bits control interactions with clocks, external hardware or reset behaviour, and we can largly take a hands-off approach to reads and writes. Firmware makes heavy use of the state to determine how to boot, but the reset values vary from SoC to SoC (eg AST2400 vs AST2500). A qdev property is exposed so that the integrating SoC model can configure the silicon revision, which in-turn selects the appropriate reset values. Further qdev properties are exposed so the board model can configure the board-dependent hardware strapping. Almost all provided AST2400 reset values are specified by the datasheet. The notable exception is SOC_SCRATCH1, where we mark the DRAM as successfully initialised to avoid unnecessary dark corners in the SoC's u-boot support. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Message-id: 1466744305-23163-2-git-send-email-andrew@aj.id.au Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: drop unnecessary inttypes.h include] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>