Updated the pinout to match the Pi4 datasheet, tested with the RPi4.
RPi3 Datasheet has same pinout.
Signed-off-by: Jeff Booher-Kaeding <Jeff.booher-kaeding@arm.com>
Reviewed-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Pete's review pointed out some whitespace issues in the
context of a previous patch. Since there are a number of
similar errors in the file lets fix them separately.
[ardb: use MmioOr32/MmioAnd32 instead of separate reads and writes]
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Now that we have the ability to enable an AML fan object,
allow the user to select the temperature at which the
fan cycles on.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Add a menu item that allows the user to enable GPIO based
fan control via SSDT and the previous NameObj replacement
commit. This should only be seen/enabled on RPI4
because that is what its been tested with.
Given GPIO pin current limitations its likely that a bit of
additional circuitry is required to drive a fan, and the GPIO
high/low signal can only be used as a enable/disable signal. A
search for "rpi npn gpio fan" or similar should turn up some
hits for how to do this. Alternatively there are some commercial
boards (FAN SHIM) which operate via simple GPIO control.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Hook the ACPI table install sequence and add some
basic conditional and AML NameOp update logic. If
a table has a non-zero PCD declared that pcd is
checked for a non-zero value before allowing the table
to be installed. We also add a table of NameOp to
PCD's which will be written into a DSDT/SSDT table
as part of its install process.
With this change we can declare something in
ASL like:
Name (VARN, 0x1234)
and then add a table entry like:
{"VARN", PcdToken(PcdVarn)}
and the value of PcdVarn will replace the
0x1234 declared in the ASL above.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Commit 0c2af04985 added mDriverBinding
extern module global, but did not remove the STATIC declaration, which
caused the build to break. Fix the build error by removing STATIC for
that module global variable.
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Andrei Warkentin <andrey.warkentin@gmail.com>
GOP SetMode() returns the frame buffer size in FrameBufferSize.
The value is obtained from the RPi mailbox call to AllocateBuffer
(tag RPI_MBOX_ALLOC_FB), which for a native resolution of 1920 x 1080
returns 8355840 bytes. The size should be 1920 x 1080 x 4 (bytes/pixel),
or 8294400 bytes, as defined by the UEFI Spec: "FrameBufferSize :
Amount of frame buffer needed to support the active mode as defined by
PixelsPerScanLine x VerticalResolution x PixelElementSize".
This change forces the returned FrameBufferSize to match the value
required by UEFI Spec. The actual buffer allocted by the VPU is larger
due to the alignment request when calling RPI_MBOX_ALLOC_FB
(32 bytes). A vertical resolution of 1080 aligns to 1088 on 32-bytes,
resulting in the increased buffer size (1920 x 1088 x 4 = 8355840).
This fixes the SetMode_Conf failure reported by SCT tests at
https://github.com/pftf/RPi4/issues/73
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Pete Batard <pete@akeo.ie>
Cc: Andrei Warkentin <awarkentin@vmware.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Minor code cleanup:
- Update file header to list SBBR required/recommended tables
- Rename DataSmbiosHande to DataSmbiosHandle
- Remove SMBIOS_HANDLE_PI_RESERVED from Type 11 template for
consistency. This is already done in LogSmbiosData().
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Pete Batard <pete@akeo.ie>
Cc: Andrei Warkentin <awarkentin@vmware.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Various fixes and enhancements for SMBIOS memory structures
(Types 16, 17, and 19):
- Type 16:
- Update MaximumCapacity dynamically
- Keep ExtendedMaximumCapacity at 0 (not used, per spec)
- Type 17:
- Update Size and VolatileSize dynamically
- Change FormFactor from Unknown to Chip
- Set DeviceSet to 0 (not part of set) instead of 0xFF (unknown)
- Fix the DeviceLocator, BankLocator, and Manufacturer strings
- Update MemoryType correctly for RPi4 and RPi3
- Add additional SMBIOS fields from 3.3 definition
- Type 19:
- Update MemoryArrayHandle to point to Type 16 handle
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Pete Batard <pete@akeo.ie>
Cc: Andrei Warkentin <awarkentin@vmware.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Various fixes and enhancements for SMBIOS Type 4:
- Fix ProcessorId to correctly report the Arm64 MIDR_EL1 value
- Change ProcessorUpgrade from Other to None
- Add comments for ProcessorCharacteristics fields
- Add CoreCount2, EnabledCoreCount2, and ThreadCount2
- Set LxCacheHandle to 0xFFFF
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Pete Batard <pete@akeo.ie>
Cc: Andrei Warkentin <awarkentin@vmware.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Various fixes for SMBIOS Types 2 and 3:
- Add LocationInChassis string to Type 2
- Update Type 3 NumberofPowerCords to 1
- Add ChassisHandle refernce to Type2. This requires moving the
Type 3 population to happen before Type 2
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Pete Batard <pete@akeo.ie>
Cc: Andrei Warkentin <awarkentin@vmware.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Commit 6d4fed696d added support for
reporting AssetTag in RPi SMBIOS Types 2 and 3. The default
AssetTag is an empty string. SMBIOS does not allow empty strings to be
referenced from the corresponding string field. This caused breakage in
parsing SMBIOS Types 2 and 3 fields that follow the AssetTag field.
The issue caused an FWTS test failure, as reported in:
https://github.com/pftf/RPi4/issues/75
The fix is to detect if no AssetTag is set in the UEFI variable, and if
so, change the AssetTag SMBIOS field to an empty blank space.
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Pete Batard <pete@akeo.ie>
Cc: Andrei Warkentin <awarkentin@vmware.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
According to the bug:
https://bugzilla.tianocore.org/show_bug.cgi?id=2777
the deprecated code under DISABLE_NEW_DEPRECATED_INTERFACES
will be removed, which will result in compilation breakage
of the Raspberry Pi platforms. Prevent that by switching to
the different PcdSet API.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Per SMBIOS specs, The Type 0 BIOS Release Date is not a free form field but
must be specified in a US middle-endian format (mm/dd/yyyy), so make sure
we populate it accordingly by using the recently introduced TimeBaseLib
macros. This is required for platforms like Windows, that fail to parse the
date otherwise.
Also, the system manufacturer should not be set to the same value as the
board manufacturer for the Type 1 strings, as, on the Raspberry Pi, this is
not representative of the actual manufacturer of the system, which is the
Raspberry Pi Foundation always.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
The Raspberry Pi 3 and Pi 4 platforms (with latest EEPROM) can boot
straight from USB, without the need for an SD card being present.
However, the IsCardPresent () calls from the ArasanMmcHost and SdHost
drivers are currently hardwired to return TRUE, which results in
straight to USB boot failing due to the SD drivers looping on
errors while trying to poke at a non-existent card...
Ideally, we would use the Card Detect signal from the uSD slot, to
report on the presence or absence of a card, but the Raspberry Pi
Foundation did not wire those signals in the Pi 2 and subsequent
models, leaving us with only potentially interfering SD commands
as means to perform card detection.
As a result of this, we are left with no other choice but limit
detection to occurring only once, prior to formal SD card init,
and then return the detected value for subsequent calls. This,
however, is more than good enough for the intended purpose, which
is to allow straight to USB boot. The sequence is a simplified
variant of the identification code in MmcDxe.
Tested on Raspberry Pi 2B, 3B and CM3 (for both SD controllers)
and Pi 4 (for Arasan, as that's the only controller available today)
Addresses pftf/RPi3#13, pftf/RPi3#14, pftf/RPi4#37.
Co-authored-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Tested-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
SMBIOS Type 11 (OEM Strings) is recommended in SBBR 1.2.
Add a simlpe implementation to the RPi.
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
FWTS reports an error with SMBIOS Type 9 Segment-Bus-DevFunc fields.
The SMBIOS specification requires that for non-PCIe slot devices to have
these fields reported as 0xFFFFF-0xFF-xFF. Instead, they were being
reported as 0x0000-0x00-0x00.
This fixes the FWTS SMBIOS Type 9 failure reported here:
https://github.com/pftf/RPi4/issues/75
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Add support for configuring the Chassis Asset Tag in the UI as well as
UEFI Shell, and carry the configured value as the Asset Tag string
in SMBIOS Types 2 and 3.
To configure using the UEFI Shell, use 'setvar' command to read/write
the UEFI variable with GUID = gConfigDxeFormSetGuid and Name="AssetTag".
For example:
Shell> setvar AssetTag -guid CD7CC258-31DB-22E6-9F22-63B0B8EED6B5 -bs
-rt -nv =L"ABC123" =0x0000
This resolves this Github issue: https://github.com/pftf/RPi4/issues/54
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Andrei Warkentin <andrey.warkentin@gmail.com>
The "Verbose ExitBootServices" feature was originally added to the RPi
as part of early OS enablement to show that the OS boot loader did
actually call ExitBootServices (back when OS boot used to crash shortly
after that). This is no longer needed, and should be removed as part of
cleaning the RPi PlatformBootManager to be more in-line with the ArmPkg
version.
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Pete Batard <pete@akeo.ie>
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
