Icenowy Zheng [Mon, 26 Oct 2020 14:19:34 +0000 (22:19 +0800)]
sunxi: allow to use AXP20[39] attached to I2C0 on V3 series
The reference design of Allwinner V3 series uses an
AXP203 or AXP209 PMIC attached to the I2C0 bus of the SoC, although the
first community-available V3s board, Lichee Pi Zero, omitted it.
Allow to introduce support for the PMIC on boards with it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Icenowy Zheng [Mon, 26 Oct 2020 14:15:59 +0000 (22:15 +0800)]
sunxi: add V3/S3 support
Allwinner V3/Sochip S3 uses the same die with Allwinner V3s/S3L, but V3 comes
with no co-packaged DDR (DDR3 is usually used externally), and S3L comes
with co-packaged DDR3.
Add support for Allwinner V3/S3 chips by add SoC names to original V3s
choice, and allow to select DDR3.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Samuel Holland [Tue, 3 Nov 2020 03:32:50 +0000 (21:32 -0600)]
sunxi: a64: Add a defconfig for the PinePhone
The PinePhone is a smartphone produced by Pine64, with an A64 SoC,
2 or 3 GiB LPDDR3 RAM, 16 or 32 GiB eMMC, 720x1440 MIPI-DSI panel,
and Quectel EG25-G modem.
There are two main board revisions: 1.1 for early adopters, and 1.2
for mass production. Since there is code to detect the board revision
at boot, one config/image can support both boards.
Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Samuel Holland [Sat, 24 Oct 2020 15:21:55 +0000 (10:21 -0500)]
sunxi: DT: A64: update device tree files
Import updated device trees from Linux tag v5.9. This picks up new
hardware (PinePhone, PineTab); and it drops the U-Boot specific DTSI
files for the Pinebook and the Teres-I, since the ANX6345 bridge is
now supported upstream.
A couple of headers needed updates for recently-added hardware support.
Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Samuel Holland [Sat, 24 Oct 2020 15:21:54 +0000 (10:21 -0500)]
sunxi: board: Set fdtfile to match the DT chosen by SPL
Previously, fdtfile was always the value in CONFIG_DEFAULT_DEVICE_TREE.
This meant that, regardless of the DT chosen by SPL (either by changing
the header in the image or by the selection code at runtime), Linux
always used the default DT.
By using the name from the SPL header (which, because of the previous
commit, always matches the DT used by U-Boot proper), Linux also sees
the same board as U-Boot/SPL, even if the boot script later loads a DT
from disk.
Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
[Andre: remove no longer needed CONFIG_SPL_LOAD_FIT guards] Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Samuel Holland [Sat, 24 Oct 2020 15:21:53 +0000 (10:21 -0500)]
sunxi: board: Save the chosen DT name in the SPL header
This overwrites the name loaded from the SPL image. It will be different
if there was previously no name provided, or if a more accurate name was
determined by the board variant selection logic. This means that the DT
name in the SPL header now always matches the DT appended to U-Boot.
Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
[Andre: move function under CONFIG_SPL_LOAD_FIT guard] Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Samuel Holland [Sat, 24 Oct 2020 15:21:52 +0000 (10:21 -0500)]
sunxi: board: Add PinePhone DT selection logic
There are two different publicly-released revisions of the PinePhone
hardware, versions 1.1 and 1.2; and they need different device trees.
Since some GPIO pins were rerouted, we can use that to distinguish
between them.
Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Samuel Holland [Sat, 24 Oct 2020 15:21:51 +0000 (10:21 -0500)]
sunxi: board: Simplify Pine A64 DT selection logic
Instead of using an entirely separate matching algorithm, simply update
the name of the DT we want to match. Enabling this logic does not depend
on the FIT config name, only on the initial guess of the board name.
Importantly, the initial guess must be "sun50i-a64-pine64-plus", because
otherwise the logic would trigger when "sun50i-a64-pine64-lts" was
written to the SPL header.
Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Samuel Holland [Sat, 24 Oct 2020 15:21:50 +0000 (10:21 -0500)]
sunxi: board: Add a helper to get the SPL DT name
This moves the validity checking and typecasts all to one place away
from the string comparison logic, and it detangles the compile-time
and runtime control flow.
The new helper will also be used by U-Boot proper in a future commit.
Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
[Andre: protect new function with CONFIG_SPL_LOAD_FIT] Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Samuel Holland [Sat, 24 Oct 2020 15:21:49 +0000 (10:21 -0500)]
sunxi: board: Use a more descriptive variable name
The variable "cmp_str" always leaves me wondering if it is the DT name
of the current board (yes) or DT name in the FIT config entry (no).
In preparation for expanding the functionality here, rename it to
something that obviously means "this is the DT name we are looking for".
Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tom Rini [Mon, 16 Nov 2020 15:50:32 +0000 (10:50 -0500)]
Merge tag 'u-boot-amlogic-20201116' of https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic
- Clock fix MMC driver for SM1 based platforms
- sync SOC Ids from Linux 5.10-rc1
- fix potential build warning on meson_dw_hdmi and meson-g12a-usb2 phy
Tom Rini [Mon, 16 Nov 2020 14:50:21 +0000 (09:50 -0500)]
Merge tag 'u-boot-rockchip-20201113' of https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip
- Fix USB support for rk3399 Pinebook Pro;
- Fix SPI boot for rk3399 boards other than Bob;
- Fix 32bit boards firmware build without SPL_OPTEE support;
- Fix rockchip display driver license;
Pali Rohár [Sat, 31 Oct 2020 16:32:48 +0000 (17:32 +0100)]
Nokia RX-51: Update test script
Include emmc/nand suffix into bootmenu script names and fix leaking sleep
processes when asynchronously waiting for them. 'wait -n' is not provided
by /bin/sh, so run script under bash.
Pali Rohár [Sat, 31 Oct 2020 16:32:47 +0000 (17:32 +0100)]
Nokia RX-51: During init disable lp5523 led instead of resetting it
After commit d5243359e1af ("OMAP24xx I2C: Add support for set-speed")
U-Boot is unstable to reset lp5523 led. That commit added pooling for i2c
poll ARDY bit which apparently is never set. It is not known what is
happening here.
Purpose of resetting lp5523 led in Nokia RX-51 code is just to turn off
very bright led which is powered on by NOLO and expects next boot image
(kernel or U-Boot) to turn it off.
After testing we observed that just disabling lp5523 led is working fine.
So as a workaround to this ARDY bit i2c issue we disable lp5523 led instead
of resetting it.
Pali Rohár [Sat, 31 Oct 2020 16:32:46 +0000 (17:32 +0100)]
Nokia RX-51: Fix crashing in U-Boot mmc function omap_hsmmc_stop_clock()
After commit 04a2ea248f58 ("mmc: disable UHS modes if Vcc cannot be
switched on and off") U-Boot started crashing on Nokia RX-51 while
initializing mmc and caused reboot loop.
It looks like that some clocks were not enabled and this patch fixes U-Boot
mmc crash.
Roger Quadros [Fri, 30 Oct 2020 13:00:24 +0000 (15:00 +0200)]
configs: am65/j72x: Set CONFIG_LOGLEVEL to 7
By default CONFIG_LOGLEVEL seems to be set to 4 which is
too low and doesn't show dev_info/dev_notice/dev_warn
messages on console. This has been deliberately set low
globally to be conservative setting across the board due to
primary bootloader size limitations. It is best to tune
per board config as per user needs.
On K3 we have separate SPL and u-boot configs so we
can afford to set u-boot CONFIG_LOGLEVEL to 7.
On AM65 this patch causes u-boot.img size to change from
932KB to 940KB with 1 line additional print during
MMC boot. i.e. details of Net subsystem
With commit 690079767803 ("cros_ec: Support keyboard scanning with
EC_CMD_GET_NEXT_EVENT") check_for_keys() tries to read keyboard
strokes using EC_CMD_GET_NEXT_EVENT. But the sandbox driver does
not understand this command. We need to reply with
-EC_RES_INVALID_COMMAND to force check_for_keys() to fall back to
use EC_CMD_MKBP_STATE. Currently the driver prints
** Unknown EC command 0x67
in this case. With the patch the message is suppressed.
In a future patch we should upgrade the sandbox driver to provide
EC_CMD_GET_NEXT_EVENT support.
Fixes: 690079767803 ("cros_ec: Support keyboard scanning with EC_CMD_GET_NEXT_EVENT") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Simon Glass [Mon, 9 Nov 2020 14:14:44 +0000 (07:14 -0700)]
cros_ec: Increase command timeout for flash erase
Erasing the flash can take over a second on some devices and the EC is
not responsive during this time. Update the timeout to 5 seconds to cope
with this.
Simon Glass [Mon, 9 Nov 2020 14:14:43 +0000 (07:14 -0700)]
cros_ec: Correct collection of EC hash
The EC now requires that the offset field be set correctly when checking
on hash status. Update the code to handle this. Use the same message
struct in both functions to reduce stack space.
Simon Glass [Tue, 3 Nov 2020 20:54:16 +0000 (13:54 -0700)]
patman: Add a Series-patchwork-url option
Add a commit tag to allow the Patchwork URL to be specified in a commit.
This can be handy for when you submit code to multiple projects but don't
want to use the -p option.
Simon Glass [Tue, 3 Nov 2020 20:54:15 +0000 (13:54 -0700)]
patman: Add a setting for the Patchwork URL
Add an argument to allow specifying the the patchwork URL. This also adds
this feature to the settings file, either globally, or on a per-project
basis.
Simon Glass [Tue, 3 Nov 2020 20:54:14 +0000 (13:54 -0700)]
patman: Allow specifying the patchwork URL
Add a new argument to allow the URL of the patchwork server to be
speciified. For now this is hard-coded in the main file, but future
patches will move it to the settings file.
Simon Glass [Tue, 3 Nov 2020 20:54:10 +0000 (13:54 -0700)]
patman: Refactor how the default subcommand works
At present patman tries to assume a default subcommand of 'send', to
maintain backwards compatibility. However it does not cope with
arguments added to the default command, so for example 'patman -t'
does not work.
Update the logic to handle this. Also update the CC command to use 'send'
explicitly, since otherwise patman gets confused with the patch-filename
argument.
Tom Rini [Sat, 14 Nov 2020 14:47:33 +0000 (09:47 -0500)]
Merge tag 'efi-2021-01-rc3' of https://gitlab.denx.de/u-boot/custodians/u-boot-efi
Pull request for UEFI sub-system for efi-2021-01-rc3
A part of the EFI_TCG2_PROTOCOL is implemented.
A unit test is supplied.
The following bugs are fixed:
* incorrect buffer size in efi_file_setinfo() leading to creash in SCT
* a crash in UEFI selftest on the sandbox due to removed drivers
* missing newlines in log message for the UEFI RNG driver
Ilias Apalodimas [Wed, 11 Nov 2020 09:18:11 +0000 (11:18 +0200)]
efi_loader: Add basic EFI_TCG2_PROTOCOL support
Since U-boot EFI implementation is getting richer it makes sense to
add support for EFI_TCG2_PROTOCOL taking advantage of any hardware TPM
available on the device.
This is the initial implementation of the protocol which only adds
support for GetCapability(). It's limited in the newer and safer
TPMv2 devices.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Kever Yang [Tue, 10 Nov 2020 03:43:32 +0000 (11:43 +0800)]
rockchip: Enable BINMAN for boards enable SPL_OPTEE
Rockchip has many 32bit SoCs and some of them are support SPL_OPTEE now,
only boards with SPL_OPTEE support can fit BINMAN well, other boards
will fail at initr_binman() in U-Boot proper after below patch,
eg. rv1108 board. 83187546ae binman: Support multiple images in the library
Fixes: 79030a4861 ("rockchip: Add Single boot image (with binman, pad_cat)") Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Hugh Cole-Baker [Sun, 8 Nov 2020 14:00:23 +0000 (14:00 +0000)]
rockchip: rockpro64: fix boot from SPI flash on spi1
Commit c4cea2bbf995 ("rockchip: Enable building a SPI ROM image on bob")
added an alias spi1 referring to spi@ff1d0000, however there was already
an alias spi0 referring to the same node in rockpro64's u-boot.dtsi, and
having both aliases present broke booting from SPI flash for this board.
Remove the spi0 alias, set the default bus for SPI flash to 1, and
enable support for numbered aliases in SPL so that it uses the same bus
numbering as U-Boot proper. This fixes booting from U-Boot in SPI flash
on the rockpro64 board.
Signed-off-by: Hugh Cole-Baker <sigmaris@gmail.com> Suggested-by: Simon Glass <sjg@chromium.org> Fixes: c4cea2bbf995 ("rockchip: Enable building a SPI ROM image on bob") Reviewed-by: Kever Yang<kever.yang@rock-chips.com>
Restrict the licenses to match coreboot's so that changes from coreboot
can be imported to U-Boot as necessary. HDMI files are already 2.0+
there and rk_lvds.c has no counterpart, so keep them as is.
Cc: Simon Glass <sjg@chromium.org> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: Eric Gao <eric.gao@rock-chips.com> Cc: Jacob Chen <jacob-chen@iotwrt.com> Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Kever Yang<kever.yang@rock-chips.com>
rockchip: gru: Allow setting up clocks in U-Boot proper
Commit fe974716326c ("rockchip: rk3288: Allow setting up clocks in
U-Boot proper") fixes some clock issues when chainloading U-Boot on
rk3288 chromebooks. Part of that change is still available in veyron's
board_early_init_r() function. Since chain-loading U-Boot proper from
vendor firmware is possible on gru boards as well, do the same thing for
them too.
On rk3399, this needs to detect whether SPL was run via handoff, so
enable that and bloblist kconfigs it needs for chromebook_bob.
rockchip: rk3399: Init clocks in U-Boot proper if SPL was not run
It's possible to chainload U-Boot proper from the vendor firmware in
rk3399 chromebooks, but the way the vendor firmware sets up clocks is
somehow different than what U-Boot expects. This causes the display to
stay devoid of content even though vidconsole claims to work (with
patches in process of being upstreamed).
This is meant to be a rk3399 version of commit d3cb46aa8c41 ("rockchip:
Init clocks again when chain-loading") which can detect the discrepancy,
but this patch instead checks whether SPL (and therefore the clock init)
was run via the handoff functionality and runs the init if it was not.
Neil Armstrong [Tue, 10 Nov 2020 23:22:10 +0000 (08:22 +0900)]
mmc: meson-gx: change clock phase value on SM1 SoCs
Amlogic SM1 SoCs doesn't work over 50MHz. When phase sets to 270', it's
working fine over 50MHz on Amlogic SM1 SoCs.
Since Other Amlogic SoCs doens't report an issue, phase value is using
to 180' by default.
To distinguish which value is used adds an u-boot only sm1 compatible.
In future, it needs to find what value is a proper about each SoCs.
Andre Przywara [Fri, 16 Oct 2020 14:42:50 +0000 (15:42 +0100)]
libfdt: Fix signedness comparison warnings
This is a combination of upstream libfdt commits to fix warnings about
comparing signed and unsigned integers:
==========
scripts/dtc/libfdt/fdt.c: In function ‘fdt_offset_ptr’:
scripts/dtc/libfdt/fdt.c:137:18: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if ((absoffset < offset)
...
==========
For a detailed description of the fixes, see the dtc repo:
https://git.kernel.org/pub/scm/utils/dtc/dtc.git/log/?id=73e0f143b73d808
For this patch the commits between 73e0f143b73d8088 and ca19c3db2bf62000
have been combined and adjusted for the slight differences in U-Boot's
libfdt code base.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
- Avoid using hardcoded number of variable range MTRRs in mtrr_commit()
- coral: Correct max98357 file
- coral: Update smbios tables to latest definition
Bin Meng [Mon, 9 Nov 2020 07:55:49 +0000 (15:55 +0800)]
x86: Avoid using hardcoded number of variable range MTRRs in mtrr_commit()
Since commit 29d2d64ed55f ("x86: Add support for more than 8 MTRRs"),
the maximum number of variable range MTRRs was increased from 8 to 10.
On the BayTrail platform there are only 8 variable range MTRRs. In
mtrr_commit() it still uses MTRR_MAX_COUNT which caused a #GP during
VESA video driver probe. It should have been updated to use dynamically
probed number.
This fixes the boot failure seen on Intel Minnow Max board.
Fixes: 29d2d64ed55f ("x86: Add support for more than 8 MTRRs") Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
after commit 4ab3817ff16a ("clk: fixed-rate: Enable DM_FLAG_PRE_RELOC flag")
Cubieboard7 (based on actions S700 SoC) fails to boot.
It is due to the fact that the default value of CONFIG_SYS_MALLOC_F_LEN (0x400)
would not provide enough memory for clock device to probe (before relocation)
well.
This commit fixes it, by increasing SYS_MALLOC_F_LEN to value 0x2000.
Suggested-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
Marek Vasut [Thu, 8 Oct 2020 13:14:17 +0000 (15:14 +0200)]
net: ks8851: Implement EEPROM MAC address readout
In case there is an EEPROM attached to the KS8851 MAC and the EEPROM
contains a valid MAC address, the MAC address is loaded into the NIC
registers on power on. Read the MAC address out of the NIC registers
and provide it to U-Boot.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Eugen Hristev <eugen.hristev@microchip.com> Cc: Joe Hershberger <joe.hershberger@ni.com>
For validating the fixed up device tree we need a tool to need to save it
to a file.
dtbdump.efi copies the configuration table with the device tree to a file
on the same partition from which dtbdump.efi was invoked. The file name can
be entered on the console.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
efi_loader: non-volatile variable not deleted from file
When deleting a non-volatile variable it was deleted from memory but the
deletion was not persisted to the file system.
SetVariable() may be called with attributes == 0 to delete a variable. To
determine if the deletion shall be persisted we have to consider the
non-volatile flag in the attributes of the deleted variable and not the
value passed in the call parameter.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
input: add support for FN1 - FN10 on crosswire kbd
Chromebooks and the sandbox use a crosswire keyboard with function keys
FN1 - FN10. These keys are needed when running UEFI applications like GRUB
or the UEFI SCT.
Add support for these keys when translating from key codes to
ECMA-48 (or withdrawn ANSI 3.64) escape sequences.
All escape sequences start with 0x1b. So we should not repeat this
byte in the kbd_to_ansi364 table.
For testing use:
sandbox_defconfig + CONFIG_EFI_SELFTEST=y
$ ./u-boot -D -l
=> setenv efi_selftest extended text input
=> bootefi selftest
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Fri, 6 Nov 2020 16:27:14 +0000 (11:27 -0500)]
Merge tag 'dm-pull5nov20' of git://git.denx.de/u-boot-dm
patman status subcommand to collect tags from Patchwork
patman showing email replies from Patchwork
sandbox poweroff command
minor fixes in binman, tests
Tom Rini [Fri, 6 Nov 2020 13:42:11 +0000 (08:42 -0500)]
Merge tag 'u-boot-amlogic-20201105' of https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic
- meson64_android: don't show logo on ROM USB boot
- doc: update support matrix and fix vim3/l build instructions
- meson64: relocate config_distro_bootcmmd header
- Add a new SMBIOS parser and enable it when booting from coreboot
- Fix up various driver names to avoid dtoc warnings
- Fully enable ACPI support on Google Chromebook Coral
- Add a way to set SMBIOS properties using the devicetree
- Update existing boards to use devicetree for SMBIOS using a new
default sysinfo driver
Simon Glass [Thu, 5 Nov 2020 13:32:17 +0000 (06:32 -0700)]
x86: Provide default SMBIOS manufacturer/product
Add a file containing defaults for these, using the existing CONFIG
options. This file must be included with #include since it needs to
be passed through the C preprocessor.
Enable the driver for all x86 boards that generate SMBIOS tables.
Disable it for coral since it has its own driver.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: reword the commit message a little bit] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Thu, 5 Nov 2020 13:32:09 +0000 (06:32 -0700)]
smbios: Add more properties
The current tables only support a subset of the available fields defined
by the SMBIOS spec. Add a few more.
We could use CONFIG_SYS_CPU or CONFIG_SYS_SOC as a default for family, but
the meaning of that value relates more to the whole system rather than
just the SoC.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Thu, 5 Nov 2020 13:32:05 +0000 (06:32 -0700)]
board: Rename uclass to sysinfo
This uclass is intended to provide a way to obtain information about a
U-Boot board. But the concept of a U-Boot 'board' is the whole system,
not just one circuit board, meaning that 'board' is something of a
misnomer for this uclass.
In addition, the name 'board' is a bit overused in U-Boot and we want to
use the same uclass to provide SMBIOS information.
The obvious name is 'system' but that is so vague as to be meaningless.
Use 'sysinfo' instead, since this uclass is aimed at providing information
on the system.
Rename everything accordingly.
Note: Due to the patch delta caused by the symbol renames, this patch
shows some renamed files as being deleted in one place and created in
another.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Wed, 4 Nov 2020 16:59:14 +0000 (09:59 -0700)]
x86: zimage: Sanity-check the kernel version before printing it
With Chrome OS the kernel setup block is stored in a separate place from
the kernel, so it is not possible to access the kernel version string.
At present, garbage is printed.
Add a sanity check to avoid this.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Wed, 4 Nov 2020 16:57:43 +0000 (09:57 -0700)]
x86: fsp: Adjust calculations for MTRR range and DRAM top
At present the top of available DRAM is the same as the top of the range
of the low-memory MTRR.
In fact, U-Boot is allowed to use memory up until the start of the FSP
reserved memory. Use that value for low_end, since it makes more memory
available.
Keep the same calculation as before for mtrr_top, i.e. the top of
reserved memory.
A side-effect of this change is that the E820 tables have a single entry
that extends from the bottom of the memory used by U-Boot to the bottom
of the FSP reserved memory. This includes the bloblist, if ACPI tables
are placed there.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Wed, 4 Nov 2020 16:57:42 +0000 (09:57 -0700)]
x86: pinctrl: Silence the warning when a pin is not found
This does not necessarily indicate a problem, since some pins are
optional. Let the caller show an error if necessary. Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Wed, 4 Nov 2020 16:57:35 +0000 (09:57 -0700)]
x86: Use CONFIG_CHROMEOS_VBOOT for verified boot
At present CONFIG_CHROMEOS is used to determine whether verified boot is
in use. The code to implement that is not in U-Boot mainline.
However, it is useful to be able to boot a Chromebook in developer mode
in U-Boot mainline without needing the verified boot code.
To allow this, use CONFIG_CHROMEOS_VBOOT to indicate that verified boot
should be used, and CONFIG_CHROMEOS to indicate that the board supports
Chrome OS. That allows us to define CONFIG_CHROMEOS on coral.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
projects / u-boot.git / log
![4 years agosunxi: allow to use AXP20[39] attached to I2C0 on V3 series](/img/sics.gif?p=u-boot.git;a=commit;h=8c51c65273628a3da3c18b258cecb27835e52727){kind=link}
