coreboot.git - my copy of coreboot

Age	Commit message (Collapse)	Author
2019-06-06	soc/amd/stoneyridge: Relocate MMIO access of ACPI registers	Marshall Dawson
	The AcpiMmio block allowing direct access to the ACPI registers has remained consistent across AMD models. Move the support from soc//stoneyridge to soc//common. BUG=b:131682806 Change-Id: I0e017a71f8efb4b614986cb327de398644599853 Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32655 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-05-16	soc/amd/common: Create AcpiMmio functionality from stoneyridge	Marshall Dawson
	Move the stoneyridge AcpiMmio code into soc/amd/common. The SB800 southbridge introduced the MMIO hardware blocks at 0xfed80000 commonly known as AcpiMmio. Implementations beginning with Mullins enable decode in PMx04. Older designs use PMx24 and allow for configuring the base address. Future work may support the older version. Comparing the documentation for AMD's RRGs and BKDGs, it is evident that the block locations have not been reassigned across products. In some cases, address locations are deprecated and new ones consumed, e.g. the early GPIO blocks were simpler at offset 0x100 and the newer GPIO banks are now at 0x1500, 0x1600, and 0x1700. Note: Do not infer the definitions within the hardware blocks are consistent across family/model products. BUG=b:131682806 Change-Id: I083b6339cd29e72289e63c9331a815c46d71600d Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32649 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-02-01	soc/amd/stoneyridge: Add generic PM1 register clear function	Marshall Dawson
	Convert vboot_platform_prepare_reboot() to call a function in soc//stoneyridge. A subsequent patch will add another call to the new function, and this change removes any inference of a dependency on vboot. BUG=b:122725586 Change-Id: I634fcd030e206c790bda697a3dbef4e8cc21b3a8 Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/c/31159 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2018-12-03	soc/amd/stoneyridge: Use new ACPI MMIO functions	Richard Spiegel
	Replace IO access to ACPI registers with the new MMIO access functions. BUG=b:118049037 TEST=Build and boot grunt. Test ACPI related functionality. Change-Id: I7544169bb21982fcf7b1c07ab7c19c6f5e65ad56 Signed-off-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-on: https://review.coreboot.org/c/29296 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2018-10-04	amd/stoneyridge: Prepare for vboot rebooting system	Marshall Dawson
	Implement the function vboot_platform_prepare_reboot() which is normally a weak function. The SlpTyp field of the PM1 register is not reset to its default value when the APU restarts. This change prevents a failing condition if vboot decides to reset the system instead of allowing an S3 resume to continue. TEST=Resume Grunt when vboot attempts a reset, verify a fresh boot instead BUG=b:117089826 Change-Id: I6e0e3e541bad89ca5b23d6ddb6e5c0df7f762f10 Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/28877 Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-04-02	src/soc/stoneyridge: Add a check for CMOS failure	Martin Roth
	BUG=b:77345148 TEST=Pull power from grunt, verify CMOS power failure is detected. Reboot and verify that CMOS power failure is not detected. Change-Id: Idbf0254e197a6d282e618a98bced52ea5a44917f Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/25468 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Marc Jones <marc@marcjonesconsulting.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2017-11-10	amd/stoneyridge: Implement vboot_platform_is_resuming	Marshall Dawson
	Change-Id: I23882ad8cd93fbc25acd8a07eca6a78b6bafc191 Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/22414 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marc Jones <marc@marcjonesconsulting.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-10-22	security/vboot: Move vboot2 to security kconfig section	Philipp Deppenwiese
	This commit just moves the vboot sources into the security directory and fixes kconfig/makefile paths. Fix vboot2 headers Change-Id: Icd87f95640186f7a625242a3937e1dd13347eb60 Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org> Reviewed-on: https://review.coreboot.org/22074 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2017-09-20	vboot: reset vbnv in cmos when cmos failure occurs	Aaron Durbin
	There's an occasional issue on machines which use CMOS for their vbnv storage. The machine that just powers up from complete G3 would have had their RTC rail not held up. The contents of vbnv in CMOS could pass the crc8 though the values could be bad. In order to fix this introduce two functions: 1. vbnv_init_cmos() 2. vbnv_cmos_failed() At the start of vboot the CMOS is queried for failure. If there is a failure indicated then the vbnv data is restored from flash backup or reset to known values when there is no flash backup. BUG=b:63054105 Change-Id: I8bd6f28f64a116b84a08ce4779cd4dc73c0f2f3d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/21560 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>