This patch adds `_DEPRECATED_` tag to ChromeOS boot mode related event
logging types as below:
* ELOG_TYPE_CROS_RECOVERY_MODE <---- to record recovery boot reason
while booting into recovery mode
* ELOG_TYPE_CROS_DEVELOPER_MODE <--- if the platform is booted into
developer mode.
* ELOG_TYPE_CROS_DIAGNOSTICS <---- if the platform is booted into
diagnostic mode.
Drop static structure `cros_deprecated_recovery_reasons` as it has been
replaced by vb2_get_recovery_reason_string() function.
ELOG_TYPE_FW_BOOT_INFO event type is now used to record all those
related fw boot info along with ChromeOS boot mode/reason etc.
BUG=b:215615970
TEST=Build and boot google/kano to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I932952ce32337e2d54473667ce17582a90882da8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65802
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
When GPP_B2 output high, there is a leakage path. This patch fix it by
setting the pin NC.
BUG=b:233959105
BRANCH=firmware-brya-14505.B
TEST=emerge-brya coreboot
Change-Id: I3c833d5d62c715960dcb27494a0b9b93c91e8f2f
Signed-off-by: Robert Chen <robert.chen@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66382
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Building firmware for Brya is currently broken due to the RO_FWID region
for adlrvp_m_ext_ec bloating past 64 characters.
The CONFIG_MAINBOARD_PART_NUMBER is catenated onto the
CONFIG_MAINBOARD_VENDOR string, which for Intel, makes for a very long
trunk string that the kernel version will then be added to form the
RO_FWID string. For Intel, that trunk string is already pretty long at :
"Intel Corporation_Alder Lake Client Platform".
Shortening the CONFIG_MAINBOARD_PART_NUMBER should address this issue
for now.
BUG=b:241273391
TEST="emerge-brya coreboot chromeos-bootimage" and verify it builds
successfully
Change-Id: Ie862c87dd9a24743f249f1b10862ca6f3295db23
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66397
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
This function is only called from the same compilation unit, so turn it
into a static function.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5c2deaa46f69c763df9612e39415b37c60d631be
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66398
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Check return value of cbfs_truncate_space() in cbfs_truncate().
Remove return from cbfs_image_from_buffer() to inform about invalid
image region when incorrect offset header was provided.
Also change header offset provided to mentioned function in
cbfs_expand_to_region() and cbfs_truncate_space() from zero
to HEADER_OFFSET_UNKNOWN, as they do not support images with cbfs master
header.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: Ib009212692fb3594a826436df765860f54837154
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66334
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Use 0x016llx to print device resource info so that both 64bit and
32bit resources could be displayed correctly.
Signed-off-by: Gang Chen <gang.c.chen@intel.com>
Change-Id: I0ec4c47cca4a09ceb7dc929efaa5630b1f9df81c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66324
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The check was recently removed to allow callers to pass `count == 0`.
Dereferencing the `msg` array is invalid in that case, though. Linux,
where we borrowed the i2c interface from, also treats this with -EINVAL.
Change-Id: I1eec02dd3a3fcf2d477a62cc65292fca40e469d3
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66341
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
We actually want the bus driver to process the 1 zero-length write
we are passing. So set the count to 1.
Change-Id: I5a41abb68c27a83715b6baec91ece9fa90b66a8c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Tested-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66337
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Some definitions are the same in dramc_soc.h for MT8192, MT8195 and
MT8186, so we move them to dramc_soc_common.h
TEST=build pass
BUG=b:236331724
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Change-Id: I3095333e62abf98de1f2d27033baeeba7a4cad79
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66276
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- Retrieve the SKU ID for Geralt via CBI interface. If that failed
(or no data found), fall back to ADC channels for SKU ID.
- The RAM code is implemented by the resistor straps that we can read
and decode from ADC.
TEST=build pass
BUG=b:236331724
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Change-Id: I31626e44bd873a3866c9bd1d511b476737f15a20
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66275
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add new config FSP_TYPE_IOT to add the IoT FSP option so that
respective mainboard Kconfig can use IoT FSP if needed.
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: I01d891348c039269138e64290ae3d6ec75d3c687
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66367
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
The latest master adds the missing MemInfoHob.h to IOT ADL-P &
ADL-S folders.
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: I8ef998b2e414d3d63494e6177b4fde2dc26e9d55
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66366
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Set tcc_offset value to 3 in devicetree for Thermal Control Circuit
(TCC) activation feature. This value is suggested by Thermal team.
BUG=b:240600260
TEST=emerge-draco coreboot
verified by thermal team
Change-Id: I3044643d52f1d6e883beb3ec87a77f32d086f46c
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66252
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
UFS storage devices require the bRefClkFreq attribute to be set to
operate correctly in high speed mode. The correct value is determined by
what the SoC / board supports. For the ADL UFS controller, it is
19.2 MHz.
a) Introduce a new ACPI property "ref-clk-freq".
b) Add support to configure this property using an SoC Kconfig.
Kernel patch:
https://web.archive.org/web/20220801060732/https://lore.kernel.org/all/
20220715210230.1.I365d113d275117dee8fd055ce4fc7e6aebd0bce9@changeid/
BUG=b:238262674
TEST=Build,boot Nirwen and dump SSDT entries and check that the kernel
correctly parses ref-clk-freq as 19.2 MHz.
Scope (\_SB.PCI0)
{
Device (UFS)
{
Name (_ADR, 0x0000000000120007) // _ADR: Address
Name (_DDN, "UFS Controller") // _DDN: DOS Device Name
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
/* Device Properties for _DSD */,
Package (0x01)
{
Package (0x02)
{
"ref-clk-freq",
0x0124F800
}
}
})
}
}
Signed-off-by: Meera Ravindranath <meera.ravindranath@intel.com>
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Change-Id: I80c338a8a61f161b0feb6c5a3ca00cf5e0cfb36c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66051
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Switching off the pads of the internal crystal oscillator that connect
to the crystal on the board in S0i3 saves a little power, so enable it.
No measurements to quantify the power savings have been made. PPR #57243
revision 1.59 was used as a reference.
BUG=b:237647468
TEST=None
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I52f14ae5c614ad8ff0479b619de7164afa1e7648
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66336
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
- Add support for edp aux read and write.
- Update edp panel properties based on edid read.
- Configure edp controller and edp phy.
Panel details:
Manufacturer: SHP Model 1523 Serial Number 0
Made week 53 of 2020
EDID version: 1.4
Digital display
8 bits per primary color channel
DisplayPort interface
Maximum image size: 31 cm x 17 cm
Gamma: 220%
Check DPMS levels
Supported color formats: RGB 4:4:4
Default (sRGB) color space is primary color space
First detailed timing is preferred timing
Supports GTF timings within operating range
Established timings supported:
Standard timings supported:
Detailed timings
Hex of detail: 5a8780a070384d403020350035ae10000018
Detailed mode (IN HEX): Clock 346500 KHz, 135 mm x ae mm
0780 07b0 07d0 0820 hborder 0
0438 043b 0440 0485 vborder 0
-hsync -vsync
Did detailed timing
Hex of detail: 653880a070384d403020350035ae10000018
Detailed mode (IN HEX): Clock 144370 KHz, 135 mm x ae mm
0780 07b0 07d0 0820 hborder 0
0438 043b 0440 0485 vborder 0
-hsync -vsync
Hex of detail: 000000fd003090a7a7230100000000000000
Monitor ranges (bare limits): 48-144Hz V, 167-167kHz H, max dotclock
350MHz
Hex of detail: 000000fc004c513134304d314a5734390a20
Monitor name: LQ140M1JW49
Changes in V2:
- Remove Misc delays in edp code.
- Move mdss soc code to disp.c
- Update EDID read using I2C write & read.
Changes in V3:
- Remove unrelated delays.
- Misc changes.
BUG=b:182963902,b:216687885
TEST=Validated on qualcomm sc7280 development board.
Monitor name: LQ140M1JW49
Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
Change-Id: If89abb76028766b19450e756889a5d7776106f95
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61342
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
This patch adds a function to calculate best rational approximation
for a given fraction and unit tests for it.
Change-Id: I2272d9bb31cde54e65721f95662b80754eee50c2
Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66010
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
gcc 12 fails the build with the warning below:
CC romstage/lib/cbfs.o
src/lib/cbfs.c: In function 'switch_to_postram_cache':
src/lib/cbfs.c:31:32: error: comparison between two arrays [-Werror=array-compare]
31 | if (_preram_cbfs_cache != _postram_cbfs_cache)
| ^~
src/lib/cbfs.c:31:32: note: use '&_preram_cbfs_cache[0] != &_postram_cbfs_cache[0]' to compare the addresses
Instead of following gcc’s suggestion, disable the warning for gcc as
requested by Julius [1]:
> Can we just set -Wno-array-compare instead? There's nothing illegal
> about that expression and as we can see in this case, there are
> perfectly reasonable cases where you might want to do something like
> that. On the other hand, I don't really see a realistic scenario where
> this warning could prevent a real problem (anyone who doesn't know
> that array1 == array2 doesn't compare the array elements in C
> shouldn't have any business submitting code to coreboot).
[1]: https://review.coreboot.org/c/coreboot/+/62827/1
Found-by: gcc-12 (Debian 12-20220313-1) 12.0.1 20220314 (experimental) [master r12-7638-g823b3b79cd2]
Found-by: gcc (Debian 12.1.0-7) 12.1.0
Change-Id: I322f7cc57dcca713141bddaaaed9ec034898754d
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66105
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
A DDR5 DIMM internally has two channels each of width 32 bit.
But the total physical channel width is 64 bit.
BUG=b:180458099
TEST=Boot DDR5 to kernel
Signed-off-by: Meera Ravindranath <meera.ravindranath@intel.com>
Change-Id: Ic5e9c58f255bdf86a68ce90a4f853bf4e7c7ccfe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52730
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Follow latest schematic, GPP_A17 is used to enable AMP power.
BUG=b:240006200
BRANCH=firmware-brya-14505.B
TEST=Check I2C scan can see the AMP return ACK.
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: Ia6c52302a12ddec68303714ac07e96a65a8f8fb8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66325
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Use the new "detect" method instead of "probed". Fixes an uncommon issue
where i2c-hid fails to initialize the device on Linux.
Tested on: gaze15, gaze16-3060, lemp10, oryp8
Tested:
- Linux: Touchpad works across 50 reboots
- Windows: Touchpad is still detected as an I2C HID device
- Windows: Extra I2C HID devices are not shown in Device Manager
Change-Id: I6a899c64a6d77b65a2ae57ab8df81cd84b568184
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66129
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
the missing `; \` at the end of the line meant subsequent lines
were no longer run from $project_dir, so Logo.bmp was silently
failing to restore. This led to the working dir being dirty,
and on subsequent runs, any change to a different branch in the
same repo would fail.
Change-Id: I17a323bc2dda19b69d809e398b273f24e14b43af
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66321
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Copy the constraint from ADL-S to ADL-P.
Fixes the following warning in Linux on System76 oryp9, which has an
NVIDIA GPU on the bridge.
pcieport 0000:00:01.0: can't derive routing for PCI INT A
This, in turn, resolves an IRQ conflict with the PCH HDA device that
would cause a stack track on every boot.
irq 10: nobody cared (try booting with the "irqpoll" option)
<snip>
[<00000000bf549647>] azx_interrupt [snd_hda_codec]
Disabling IRQ #10
Change-Id: I550c80105ff861d051170ed748149aeb25a545db
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66285
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Configure eMMC DLL tuning values for Craask board.
BUG=b:238985924
TEST="Use the value to boot on Nivviks and Craask successfully."
Change-Id: I14f3e2329404cca94e14034d1fb52fcb99a2ddc9
Signed-off-by: Simon Yang <simon1.yang@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66218
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Henry Sun <henrysun@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
The first CSE Lite SKU is available, therefore enable the Kconfig
option to have the CSE reboot the system into its RW FW during a cold
boot.
BUG=b:240228892
TEST=TBD
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I00ef4176cf08cbeed06e446cfe68f06cb1ea27b4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66287
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch calls into vboot API (vb2api_get_fw_boot_info) to retrieve
FW slot boot information like (tries count, current boot slot, previous
boot slot, previous boot status and boot mode).
Upon retrieval of the vboot information, elog callback from ramstage
records the info into the eventlog.
Additionally, this patch refactors the existing event logging mechanism
to add newer APIs to record vboot firmware boot related information.
BUG=b:215615970
TEST=Build and boot google/kano to ChromeOS and run below command to
check the cbmem log:
Scenario 1:
localhost ~ # cbmem -c | grep VB2
[INFO ] VB2:vb2_check_recovery() Recovery reason from previous boot:
0x0 / 0x0
[INFO ] VB2:vb2api_fill_boot_config() boot_mode=`Developer boot`
VB2:vb2api_get_fw_boot_info() fw_tried=`A` fw_try_count=0
fw_prev_tried=`A` fw_prev_result=`Success`.
....
Scenario 2:
localhost ~ # crossystem recovery_request=1
localhost ~ # cbmem -c | grep VB2
[INFO ] VB2:vb2api_fill_boot_config() boot_mode=`Manual recovery boot`
VB2:vb2api_fill_boot_config() recovery_reason=0x13 / 0x00
VB2:vb2api_get_fw_boot_info() fw_tried=`A` fw_try_count=0
fw_prev_tried=`A` fw_prev_result=`Unknown`.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I6882cd1c4dbe5e24f6460388cd1af4e4a05fc4da
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65561
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add static check to ensure the reserved APOB DRAM space is the same size
as the MRC_CACHE region specified in the fmap.
Update sabrina APOB DRAM size to match the fmap.
TEST: Timeless builds identical. Test build with a larger MRC_CACHE than
APOB DRAM failed the assert as expected.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Ia14f6ef94b9062df0612fe96098b1012085ccf9c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65878
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Firmware component that does memory training already limits the memory
controller to train at 5500 Mbps for all memory parts in Sabrina. Hence
removing this interim SPD change to limit the speed.
BUG=b:238074863
TEST=Build and boot to OS in Skyrim.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I2bc82c7407a97aac282708c3e0bd56ae99a8fc31
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66290
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to pass PCIe base address to payloads, implement pcie_fill_lb()
to fill coreboot table with PCIe info.
BUG=b:182963902,b:216686574,b:181098581
TEST=Verified on Qualcomm sc7280 development board with NVMe endpoint
(Koixa NVMe, Model-KBG40ZPZ256G with FW AEGA0102). Confirmed NVMe is
getting detected in response to 'storage init' command in depthcharge
CLI prompt.
Output logs:
->dpch: storage init
Initializing NVMe controller 1e0f:0001
Identified NVMe model KBG40ZPZ256G TOSHIBA MEMORY
Added NVMe drive "NVMe Namespace 1" lbasize:512, count:0x1dcf32b0
* 0: NVMe Namespace 1
1 devices total
Also verified NVMe boot path that is depthcharge is able to load the
kernel image from NVMe storage.
Change-Id: I1ca2be55b98c8d1b86576072078cdda02ac55940
Signed-off-by: Veerabhadrarao Badiganti <quic_vbadigan@quicinc.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57614
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add 'pci_map_bus' function and PCIE_QCOM config for Qualcomm platform.
BUG=b:182963902,b:216686574,b:181098581
TEST=Verified on Qualcomm sc7280 development board with NVMe endpoint
(Koixa NVMe, Model-KBG40ZPZ256G with FW AEGA0102). Confirmed NVMe is
getting detected in response to 'storage init' command in depthcharge
CLI prompt.
Output logs:
->dpch: storage init
Initializing NVMe controller 1e0f:0001
Identified NVMe model KBG40ZPZ256G TOSHIBA MEMORY
Added NVMe drive "NVMe Namespace 1" lbasize:512, count:0x1dcf32b0
* 0: NVMe Namespace 1
1 devices total
Also verified NVMe boot path that is depthcharge is able to load the
kernel image from NVMe storage.
Change-Id: I7d1217502cbd7d4d0cdd298919ae82435630d61c
Signed-off-by: Prasad Malisetty <quic_pmaliset@quicinc.com>
Signed-off-by: Veerabhadrarao Badiganti <quic_vbadigan@quicinc.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57615
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add PCIe domain support for herobrine by enabling it in the devicetree.
BUG=b:182963902,b:216686574,b:181098581
TEST=Verified on Qualcomm sc7280 development board with NVMe card
(Koixa NVMe, Model-KBG40ZPZ256G with FW AEGA0102). Confirmed NVMe is
getting detected in response to 'storage init' command in depthcharge
CLI prompt.
Output logs:
->dpch: storage init
Initializing NVMe controller 1e0f:0001
Identified NVMe model KBG40ZPZ256G TOSHIBA MEMORY
Added NVMe drive "NVMe Namespace 1" lbasize:512, count:0x1dcf32b0
* 0: NVMe Namespace 1
1 devices total
Also verified NVMe boot path, that is depthcharge is able to load the
kernel image from NVMe storage.
Change-Id: Ied8fbbc8d20698ee081d93ba184b7d0291bb6a76
Signed-off-by: Veerabhadrarao Badiganti <quic_vbadigan@quicinc.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65137
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Subrata Banik