Add APU device apc driver and set up permissions.
APU has its own device apc for control access by domains.
For Domain 0, the access to the following slaves are restricted to
security read and write:
apusys_ao-2, apusys_ao-4, apusys_ao-5, apu_sctrl_reviser,
apu_iommu0_r1 apu_iommu0_r2, apu_iommu0_r3, apu_iommu0_r4
apu_iommu1_r1, apu_iommu1_r2, apu_iommu1_r3,apu_iommu1_r4
For VPU, D0/D5 are set as no protection, other domains are forbidden.
For other slaves, the D0 is no protection, other domains are forbidden.
BUG=b:203145462
BRANCH=cherry
TEST=boot cherry, check dump log and test permissions
Signed-off-by: Flora Fu <flora.fu@mediatek.com>
Change-Id: If92d3b02ac4966332315b85d68e0f48c6a9fce85
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58969
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
FSP-S is normally memmapped and then decompressed. There are about 7 ms
between starting ramstage, and loading FSP-S. By preloading we can
ensure the fsps.bin is already in RAM by the time we need it. This
reduces boot time by about 7 ms.
BUG=b:
TEST=Boot nipperkin and see ~7ms reduction in boot time
| 10 - start of ramstage | 0.044 | 0.044 Δ( 0.00, 0.00%) |
| 30 - device enumeration | 1.899 | 2.073 Δ( 0.17, 0.01%) |
| 971 - loading FSP-S | 6.645 | 6.628 Δ( -0.02, -0.00%) |
| 15 - starting LZMA decompress (ignore for x86) | 0.016 | 0.01 Δ( -0.01, -0.00%) |
| 16 - finished LZMA decompress (ignore for x86) | 15.266 | 8.316 Δ( -6.95, -0.47%) |
| 954 - calling FspSiliconInit | 0.08 | 0.09 Δ( 0.01, 0.00%) |
CBFS DEBUG: _cbfs_alloc(name='fsps.bin', alloc=0xc9761e5c(0xc97a3f0c), force_ro=false, type=-1)
CBFS: Found 'fsps.bin' @0x1a1fc0 size 0x102cd in mcache @0xc97dd208
waiting for thread
took 1 us <-- fsps.bin was preloaded
CBFS DEBUG: get_preload_rdev(name='fsps.bin') preload successful
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I5a728047b8ad92d70bba8485017579aa3df48d95
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59025
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Rob Barnes <robbarnes@google.com>
This will enable reading FSP-S/M using the SPI DMA controller.
BUG=B:179699789
TEST=Build guybrush with SPI DMA enabled and verify alignment is set
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I282b9989d8e95c93603c6f69616a8f236a4e2e35
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59130
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Used H1 firmware where the last version number is 0.0.22, 0.3.22 or
less to production that will need to disable autonomous GPIO power
management and then can get H1 version by gsctool -a -f -M
BUG=b:201054849
TEST=USE="project_primus emerge-brya coreboot" and verify it builds
without error.
Change-Id: If5a99a96e5d4b84be3f2c1165283ce249ca75d58
Signed-off-by: Casper Chang <casper_chang@wistron.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59079
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Make the `codec_init()` function non-static so that it can be used in
other places. Rename it to `azalia_codec_init()` for consistency with
the other functions of the API.
Also, update the function's signature to make it more flexible. Remove
the unused `dev` parameter and allow callers to pass the verb table to
use. Update the original call site to preserve behavior.
Change-Id: I5343796242065b5fedc78cd95bcf010c9e2623dd
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59117
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Make the `codecs_init()` function non-static so that it can be used in
other places. Rename it to `azalia_codecs_init()` to avoid name clashes
with static definitions in southbridge code (which will be removed in
subsequent commits).
Change-Id: I080a73102b0c4f9f8a283cd93bba9b3b23169be0
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59108
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
For consistency with other Intel southbridges, program PC BEEP verbs.
None of the boards in the tree using this southbridge provide PC BEEP
verbs, so this change makes no difference.
Change-Id: I94d24999af819cf3951510586fd4864d1ed3f2f1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59106
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Use the `azalia_program_verb_table()` function in preparation to
deduplicate Azalia init code.
With this change, the "Azalia: verb loaded." message is now printed when
programming the verbs failed. This will be addressed once `codec_init()`
has been deduplicated.
Change-Id: I5d9e0f19429620166f2a6ef48ec7c963ee64b59c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59105
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Currently all the power sequencing for FPMCU is done explicitly in
different stages of coreboot. This can all be done by adding ACPI power
resources for FPMCU and clean up the unused code. Here is the expected
power sequence:
PowerUp : Assert EN_PWR_FP -> 3 ms delay -> De-assert FPMCU_RST_ODL
Shutdown : De-assert EN_PWR_FP -> Assert FPMCU_RST_ODL
Reboot : Shutdown -> 200 ms delay -> PowerUp
BUG=None
TEST=Build and boot to OS in Guybrush. Ensure that the FP is able to
unlock the system after the first login attempt. Ensure that the FP is
able to wakeup the system. Observed that the power resource is added
correctly in the FPMCU ACPI object
Name (_PR0, Package (0x01) // _PR0: Power Resources for D0
{
PR01
})
Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot
{
PR01
})
PowerResource (PR01, 0x00, 0x0000)
{
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x01)
}
Method (_ON, 0, Serialized) // _ON_: Power On
{
\_SB.CTXS (0x0B)
\_SB.STXS (0x20)
\_SB.STXS (0x0B)
}
Method (_OFF, 0, Serialized) // _OFF: Power Off
{
\_SB.CTXS (0x0B)
\_SB.CTXS (0x20)
}
}
Change-Id: I52322eaecf6961ff9a196ca9ab2d58b7d4599d4f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58705
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
We need to put USB setting in mux order.
BUG=b:204230406
TEST=Type C mux configuration is correct.
Wrong:
added type-c port0 info to cbmem: usb2:2 usb3:2 sbu:0 data:0
added type-c port1 info to cbmem: usb2:3 usb3:3 sbu:0 data:0
Correct:
added type-c port0 info to cbmem: usb2:3 usb3:3 sbu:0 data:0
added type-c port1 info to cbmem: usb2:2 usb3:2 sbu:0 data:0
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: I19338e162db6145dbeb5830de1a372cf98f779a0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59012
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Add wifi sar for galtic/galtic360/galith360
Using convertible mode of SKU ID to load wifi table.
Each Project and SKU ID correspond as below
galtic (sku id:0x120000)
galith (sku id:0x130000)
gallop (sku id:0x150000)
galtic360 (sku id:0x260000)
galith360 (sku id:0x270000)
BUG=b:203741126
TEST=emerge-dedede coreboot chromeos-bootimage \
coreboot-private-files-baseboard-dedede
verify the SAR table is correct in each project
Signed-off-by: FrankChu <frank_chu@pegatron.corp-partner.google.com>
Change-Id: If4203d176dd717fa62c88d9b4fab8a53847213fe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58734
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marco Chen <marcochen@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
List of changes:
1. Create Module Type macros as per Memory Type
(i.e. DDR2/DDR3/DDR4/DDR5/LPDDR4/LPDDR5) and fix compilation
issue due to renaming of existing macros due to scoping the Memory
Type.
2. Use dedicated Memory Type and Module type for `Form Factor`
and `TypeDetail` conversion using `get_spd_info()` function.
3. Create a new API (convert_form_factor_to_module_type()) for
`Form Factor` to 'Module type' conversion as per `Memory Type`.
4. Add new argument as `Memory Type` to
smbios_form_factor_to_spd_mod_type() so that it can internally
call convert_form_factor_to_module_type() for `Module Type`
conversion.
5. Update `test_smbios_form_factor_to_spd_mod_type()` to
accommodate different memory types.
6. Skip fixed module type to form factor conversion using DDR2 SPD4
specification (inside dimm_info_fill()).
Refer to datasheet SPD4.1.2.M-1 for LPDDRx and SPD4.1.2.L-3 for DDRx.
BUG=b:194659789
TEST=Refer to dmidecode -t 17 output as below:
Without this code change:
Handle 0x0012, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 16 bits
Data Width: 16 bits
Size: 2048 MB
Form Factor: Unknown
....
With this code change:
Handle 0x0012, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 16 bits
Data Width: 16 bits
Size: 2048 MB
Form Factor: Row Of Chips
....
Change-Id: Ia337ac8f50b61ae78d86a07c7a86aa9c248bad50
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56628
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
