Commits · x86-pull-20230801 · U-Boot / Custodians / x86 U-Boot Custodian Tree

Aug 01, 2023

x86: Add a little more info to cbsysinfo · db971a75
Simon Glass authored 1 year ago and Bin Meng committed 1 year ago
```
Show the number of records in the table and the total table size in
bytes.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
```
View commits for tag x86-pull-20230801 x86-pull-20230801

db971a75

x86: Return mtrr_add_request() to its old purpose · d560f7ca

Simon Glass authored 1 year ago and

Bin Meng committed 1 year ago


This function used to be for adding a list of requests to be actioned on
relocation. Revert it back to this purpose, to avoid problems with boards
which need control of their MTRRs (i.e. those which don't use FSP).

The mtrr_set_next_var() function is available when the next free
variable-MTRR must be set, so this can be used instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Fixes: 3bcd6cf8 ("x86: mtrr: Skip MSRs that were already programmed..")
Fixes: 596bd058 ("x86: mtrr: Do not clear the unused ones..")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

d560f7ca

video: vesa: Use mtrr_set_next_var() for graphics memory · bff002d4

Bin Meng authored 1 year ago


At present this uses mtrr_add_request() & mtrr_commit() combination
to program the MTRR for graphics memory. This usage has two major
issues as below:

- mtrr_commit() will re-initialize all MTRR registers from index 0,
  using the settings previously added by mtrr_add_request() and saved
  in gd->arch.mtrr_req[], which won't cause any issue but is unnecessary
- The way such combination works is based on the assumption that U-Boot
  has full control with MTRR programming (e.g.: U-Boot without any blob
  that does all low-level initialization on its own, or using FSP2 which
  does not touch MTRR), but this is not the case with FSP. FSP programs
  some MTRRs during its execution but U-Boot does not have the settings
  saved in gd->arch.mtrr_req[] and when doing mtrr_commit() it will
  corrupt what was already programmed previously.

Correct this to use mtrr_set_next_var() instead.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

bff002d4

video: ivybridge: Use mtrr_set_next_var() for graphics memory · 0f497b2b

Bin Meng authored 1 year ago


At present this uses mtrr_add_request() & mtrr_commit() combination
to program the MTRR for graphics memory. This usage has two major
issues as below:

- mtrr_commit() will re-initialize all MTRR registers from index 0,
  using the settings previously added by mtrr_add_request() and saved
  in gd->arch.mtrr_req[], which won't cause any issue but is unnecessary
- The way such combination works is based on the assumption that U-Boot
  has full control with MTRR programming (e.g.: U-Boot without any blob
  that does all low-level initialization on its own, or using FSP2 which
  does not touch MTRR), but this is not the case with FSP. FSP programs
  some MTRRs during its execution but U-Boot does not have the settings
  saved in gd->arch.mtrr_req[] and when doing mtrr_commit() it will
  corrupt what was already programmed previously.

Correct this to use mtrr_set_next_var() instead.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

0f497b2b

video: broadwell: Use mtrr_set_next_var() for graphics memory · b5126f26

Bin Meng authored 1 year ago


At present this uses mtrr_add_request() & mtrr_commit() combination
to program the MTRR for graphics memory. This usage has two major
issues as below:

- mtrr_commit() will re-initialize all MTRR registers from index 0,
  using the settings previously added by mtrr_add_request() and saved
  in gd->arch.mtrr_req[], which won't cause any issue but is unnecessary
- The way such combination works is based on the assumption that U-Boot
  has full control with MTRR programming (e.g.: U-Boot without any blob
  that does all low-level initialization on its own, or using FSP2 which
  does not touch MTRR), but this is not the case with FSP. FSP programs
  some MTRRs during its execution but U-Boot does not have the settings
  saved in gd->arch.mtrr_req[] and when doing mtrr_commit() it will
  corrupt what was already programmed previously.

Correct this to use mtrr_set_next_var() instead.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

b5126f26

x86: fsp: Use mtrr_set_next_var() for graphics memory · 3dfa4115

Bin Meng authored 1 year ago


At present this uses mtrr_add_request() & mtrr_commit() combination
to program the MTRR for graphics memory. This usage has two major
issues as below:

- mtrr_commit() will re-initialize all MTRR registers from index 0,
  using the settings previously added by mtrr_add_request() and saved
  in gd->arch.mtrr_req[], which won't cause any issue but is unnecessary
- The way such combination works is based on the assumption that U-Boot
  has full control with MTRR programming (e.g.: U-Boot without any blob
  that does all low-level initialization on its own, or using FSP2 which
  does not touch MTRR), but this is not the case with FSP. FSP programs
  some MTRRs during its execution but U-Boot does not have the settings
  saved in gd->arch.mtrr_req[] and when doing mtrr_commit() it will
  corrupt what was already programmed previously.

Correct this to use mtrr_set_next_var() instead.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

3dfa4115

x86: Change testing logic of mtrr commit · 41fbb344

Bin Meng authored 1 year ago


On Coral U-Boot SPL programs some MTRRs and FSPv2 in U-Boot proper
needs to program MTRRs too. With current testing logic of mtrr
commit in init_cache_f_r(), the mtrr commit is skipped which won't
work as the queued mtrr requests include setup for DRAM regions.

Change the logic to allow such configuration.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Tweak to put back CONFIG_FSP_VERSION2 at top:
Signed-off-by: Simon Glass <sjg@chromium.org>

41fbb344

Jul 31, 2023

Merge tag 'u-boot-rockchip-20230731' of https://source.denx.de/u-boot/custodians/u-boot-rockchip · 4e619e8d

Tom Rini authored 1 year ago

- Update dwc3 generic driver and update support for rk3568/rk3328;
- Add boards:
        rk3566: Pine64 Quartz64-A/B, SOQuartz on Model A/Blade/CM4-IO
        rk3568: Radxa E25 Carrier Board
        rk3588: Radxa ROCK5A
- Fixes and updates for chromebook veryon/jerry/speedy;
- SPI support fixes for rk3399/rk3568/rk3588;
- rk3588 usbdp phy support;
- dts and config updates for different boards;

4e619e8d

board: rockchip: Add Radxa E25 Carrier Board · 1f54f71b

Jonas Karlman authored 1 year ago and

Kever Yang committed 1 year ago


Radxa E25 is a network application carrier board for the Radxa CM3I SoM
with a RK3568 SoC. It features dual 2.5G ethernet, mini PCIe, M.2 B Key,
USB3, eMMC, SD, nano SIM card slot and a 26-pin GPIO header.

Features tested on a Radxa E25 v1.4:
- SD-card boot
- eMMC boot
- USB host
- PCIe/Ethernet adapters is detected
- SATA

Device tree is imported from linux next-20230728.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: FUKAUMI Naoki <naoki@radxa.com>