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>
Simon Glass [Wed, 4 Nov 2020 16:57:34 +0000 (09:57 -0700)]
x86: Define the Chrome OS GNVS region
It is not possible to boot Chrome OS properly without passing some basic
information from U-Boot. This applies even if verified boot is not being
used. Add a structure definition for 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:33 +0000 (09:57 -0700)]
acpi: Don't reset the tables with every new generation
At present if SSDT and DSDT code is created, only the latter is retained
for examination by the 'acpi items' command. Fix this by only resetting
the list when explicitly requested.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Wed, 4 Nov 2020 16:57:32 +0000 (09:57 -0700)]
x86: acpi: Put the generated code first in DSDT
The current implementation for DSDT tables is not correct for the case
where there is generated code, as the length ends up being incorrect.
Also, we want the generated code to go first in the table.
Rewrite this piece to correct these problems.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Wed, 4 Nov 2020 16:57:25 +0000 (09:57 -0700)]
x86: Allow putting some tables in the bloblist
At present all tables are placed starting at address f0000 in memory, and
can be up to 64KB in size. If the tables are very large, this may not
provide enough space.
Also if the tables point to other tables (such as console log or a ramoops
area) then we must allocate other memory anyway.
The bloblist is a nice place to put these tables since it is contiguous,
which makes it easy to reserve this memory for linux using the 820 tables.
Add an option to put some of the tables in the bloblist. For SMBIOS and
ACPI, create suitable pointers from the f0000 region to the new location
of the tables.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: squashed in http://patchwork.ozlabs.org/project/uboot/patch/ 20201105062407.1.I8091ad931cbbb5e3b6f6ababdf3f8d5db0d17bb9@changeid/] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Wed, 4 Nov 2020 16:57:21 +0000 (09:57 -0700)]
x86: coral: Drop the duplicate PCIe settings
These settings are included twice. The second lot are correct, so drop the
others.
Signed-off-by: Simon Glass <sjg@chromium.org> Reported-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Wed, 4 Nov 2020 16:57:19 +0000 (09:57 -0700)]
x86: acpi: Store the ACPI context in global_data
At present we create the ACPI context but then drop it after generation of
tables is complete. This is annoying because we have to then search for
tables later.
To fix this, allocate the context and store it in global_data.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
If u-boot gets used as coreboot payload it might be nice to get
vendor, model and bios version from smbios. I am not sure about
the output of all the read information.
With qemu target for coreboot this could look this:
CBFS: Found @ offset 14f40 size 3b188
Checking segment from ROM address 0xffc15178
Checking segment from ROM address 0xffc15194
Loading segment from ROM address 0xffc15178
code (compression=1)
New segment dstaddr 0x01110000 memsize 0x889ef srcaddr 0xffc151b0 filesize 0x3b150
Loading Segment: addr: 0x01110000 memsz: 0x00000000000889ef filesz: 0x000000000003b150
using LZMA
Loading segment from ROM address 0xffc15194
Entry Point 0x01110000
BS: BS_PAYLOAD_LOAD run times (exec / console): 77 / 1 ms
Jumping to boot code at 0x01110000(0x07fa7000)
CPU: x86_64, vendor AMD, device 663h
DRAM: 127.1 MiB
MMC:
Video: No video mode configured in coreboot!
Video: No video mode configured in coreboot!
Vendor: QEMU
Model: Standard PC (i440FX + PIIX, 1996)
Bios Version: 4.12-3152-g326a499f6f-dirty
Net: e1000: 52:54:00:12:34:56
eth0: e1000#0
No working controllers found
Finalizing coreboot
Hit any key to stop autoboot: 0
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Michal Simek [Wed, 4 Nov 2020 14:33:20 +0000 (15:33 +0100)]
arch: Move NEEDS_MANUAL_RELOC symbol to Kconfig
CONFIG_NEEDS_MANUAL_RELOC macro was out of Kconfig. Move it there to be
able to use compile-time checks to reduce the number of build paths.
Fixes: f9a882438966 ("dm: core: Convert #ifdef to if() in root.c") for Microblaze Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Heiko Schocher [Tue, 3 Nov 2020 14:22:36 +0000 (15:22 +0100)]
env: sf: fix init function behaviour
Michael wrote:
commit 92765f45bb95 ("env: Access Environment in SPI flashes before
relocation") at least breaks the Kontron sl28 board. I guess it also
breaks others which use a (late) SPI environment.
reason is, that env_init() sets the init bit, if there
is no init function defined in an environment driver,
and use default return value -ENOENT in this case
later for setting the default environment.
Change:
Environment driver can now implement an init
function and return, if this function does nothing,
simply -ENOENT.
env_init() now handles -ENOENT correct by setting the
inited bit for the environment driver. And if there
is no other environment driver whose init function
returns 0, load than the default environment.
This prevents that each environment driver needs to set the
default environment.
Fixes: 92765f45bb95 ("env: Access Environment in SPI flashes before relocation") Reported-by: Michael Walle <michael@walle.cc> Tested-by: Michael Walle <michael@walle.cc> [For the SF environment] Signed-off-by: Heiko Schocher <hs@denx.de>
Eugen Hristev [Mon, 26 Oct 2020 08:39:54 +0000 (10:39 +0200)]
ARM: dts: at91: sama5d3xmb_cmp: fix SPI bus unit address
w+arch/arm/dts/.at91sam9260ek.dtb.pre.tmp:119.21-123.7: Warning (spi_bus_reg): /ahb/apb/spi@fffc8000/mtd_dataflash@0: SPI bus unit address format error, expected "1"
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Eugen Hristev [Mon, 26 Oct 2020 08:39:53 +0000 (10:39 +0200)]
ARM: dts: at91: sam9260ek: fix SPI bus unit address
w+arch/arm/dts/.at91sam9260ek.dtb.pre.tmp:119.21-123.7: Warning (spi_bus_reg): /ahb/apb/spi@fffc8000/mtd_dataflash@0: SPI bus unit address format error, expected "1"
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Eugen Hristev [Mon, 26 Oct 2020 08:39:51 +0000 (10:39 +0200)]
ARM: dts: at91: gurnard: fix SPI bus unit address
w+arch/arm/dts/.at91sam9g45-gurnard.dtb.pre.tmp:118.21-122.7: Warning (spi_bus_reg): /ahb/apb/spi@fffa4000/mtd_dataflash@0: SPI bus unit address format error, expected "1"
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Eugen Hristev [Mon, 26 Oct 2020 08:39:50 +0000 (10:39 +0200)]
ARM: dts: at91: at91sam9g25ek: fix I2C bus unit address
w+arch/arm/dts/.at91sam9g25ek.dtb.pre.tmp:28.25-47.7: Warning (i2c_bus_reg): /ahb/apb/i2c@f8010000/camera@0x30: I2C bus unit address format error, expected "30"
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Eugen Hristev [Mon, 26 Oct 2020 08:39:49 +0000 (10:39 +0200)]
ARM: dts: at91: at91sam9g20ek_common: fix SPI bus unit address
w+arch/arm/dts/at91sam9g20ek_common.dtsi:100.21-104.7: Warning (spi_bus_reg): /ahb/apb/spi@fffc8000/mtd_dataflash@0: SPI bus unit address format error, expected "1"
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Eugen Hristev [Mon, 26 Oct 2020 08:39:48 +0000 (10:39 +0200)]
ARM: dts: at91: at91sam9g20-taurus: fix SPI bus unit address
w+arch/arm/dts/.at91sam9g20-taurus.dtb.pre.tmp:79.18-83.4: Warning (spi_bus_reg): /ahb/apb/spi@fffc8000/mtd_dataflash@0: SPI bus unit address format error, expected "1"
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Eugen Hristev [Mon, 26 Oct 2020 08:39:47 +0000 (10:39 +0200)]
ARM: dts: at91: at91sam9261ek: fix SPI unit address warning
w+arch/arm/dts/.at91sam9261ek.dtb.pre.tmp:124.15-144.7: Warning (spi_bus_reg): /ahb/apb/spi@fffc8000/tsc2046@0: SPI bus unit address format error, expected "2"
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Eugen Hristev [Mon, 26 Oct 2020 08:39:46 +0000 (10:39 +0200)]
ARM: dts: at91: vinco: fix I2C warning bus unit address
w+arch/arm/dts/.at91-vinco.dtb.pre.tmp:131.18-134.7: Warning (i2c_bus_reg): /ahb/apb/i2c@f8024000/rtc@64: I2C bus unit address format error, expected "32"
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Tom Rini [Sat, 31 Oct 2020 02:55:16 +0000 (22:55 -0400)]
Merge tag 'u-boot-rockchip-20201031' of https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip
- New PX30 board: Engicam PX30.Core;
- Fix USB HID support for rock960;
- Remove host endianness dependency for rockchip mkimage;
- dts update for rk3288-tinker;
- Enable console MUX for some ROCKPi boards;
- Add config-based ddr selection for px30;
Jagan Teki [Wed, 28 Oct 2020 13:33:44 +0000 (19:03 +0530)]
board: engicam: Attach i.MX6 common code
The existing common code for Engicam boards uses i.MX6,
so attach that into i.MX6 Engicam boards so-that adding
new SoC variants of Engicam boards become meaningful.
PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam.
General features:
- Rockchip PX30
- Up to 2GB DDR4
- eMMC 4 GB expandible
- rest of PX30 features
PX30.Core needs to mount on top of Engicam baseboards for creating
complete platform boards.
Possible baseboards are,
- EDIMM2.2
- C.TOUCH 2.0
Add support for it.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Engicam EDIMM2.2 Starter Kit is an EDIMM 2.2 Form Factor Capacitive
Evaluation Board.
Genaral features:
- LCD 7" C.Touch
- microSD slot
- Ethernet 1Gb
- Wifi/BT
- 2x LVDS Full HD interfaces
- 3x USB 2.0
- 1x USB 3.0
- HDMI Out
- Mini PCIe
- MIPI CSI
- 2x CAN
- Audio Out
SOM's like PX30.Core needs to mount on top of this Evaluation board
for creating complete PX30.Core EDIMM2.2 Starter Kit.
Add support for it.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The Rockchip boot ROM expects little-endian values in the image header.
When running mkimage on a big-endian machine, these values need to be
byteswapped before writing or verifying the header.
This change fixes cross-compiling U-Boot SPL for the RK3399 SoC from a
big-endian ppc64 host machine.
Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Kever Yang<kever.yang@rock-chips.com>
Sean Anderson [Tue, 27 Oct 2020 23:55:41 +0000 (19:55 -0400)]
doc: Update logging documentation
This updates logging documentation with some examples of the new commands
added in the previous commits. It also removes some items from the to-do
list which have been implemented.
Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Sean Anderson [Tue, 27 Oct 2020 23:55:39 +0000 (19:55 -0400)]
test: Add a test for log filter-*
This exercises a few success and failure modes of the log filter-*
commands. log filter-list is not tested because it's purely informational.
I don't think there's a good way to test it except by testing if the output
of the command exactly matches a sample run.
Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Sean Anderson [Tue, 27 Oct 2020 23:55:38 +0000 (19:55 -0400)]
cmd: log: Add commands to manipulate filters
This adds several commands to add, list, and remove log filters. Due to the
complexity of adding a filter, `log filter-list` uses options instead of
positional arguments.
These commands have been added as subcommands to log by using a dash to
join the subcommand and subsubcommand. This is stylistic, and they could be
converted to proper subsubcommands if it is wished.
Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Sean Anderson [Tue, 27 Oct 2020 23:55:37 +0000 (19:55 -0400)]
test: Add a test for getopt
A few of these tests were inspired by those in glibc. The syntax for
invoking test_getopt is a bit funky, but it's necessary so that the CPP can
parse the arguments correctly.
Sean Anderson [Tue, 27 Oct 2020 23:55:36 +0000 (19:55 -0400)]
lib: Add getopt
Some commands can get very unweildy if they have too many positional
arguments. Adding options makes them easier to read, remember, and
understand.
This implementation of getopt has been taken from barebox, which has had
option support for quite a while. I have made a few modifications to their
version, such as the removal of opterr in favor of a separate getopt_silent
function. In addition, I have moved all global variables into struct
getopt_context.
The getopt from barebox also re-orders the arguments passed to it so that
non-options are placed last. This allows users to specify options anywhere.
For example, `ls -l foo/ -R` would be re-ordered to `ls -l -R foo/` as
getopt parsed the options. However, this feature conflicts with the const
argv in cmd_tbl->cmd. This was originally added in 54841ab50c ("Make sure
that argv[] argument pointers are not modified."). The reason stated in
that commit is that hush requires argv to stay unmodified. Has this
situation changed? Barebox also uses hush, and does not have this problem.
Perhaps we could use their fix?
I have assigned maintenance of getopt to Simon Glass, as it is currently
only used by the log command. I would also be fine maintaining it.
Sean Anderson [Tue, 27 Oct 2020 23:55:35 +0000 (19:55 -0400)]
cmd: log: Make "log level" print all log levels
This makes the log level command print all valid log levels. The default
log level is annotated. This provides an easy way to see which log levels
are compiled-in.
Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Sean Anderson [Tue, 27 Oct 2020 23:55:34 +0000 (19:55 -0400)]
cmd: log: Add commands to list categories and drivers
This allows users to query which categories and drivers are available on
their system. This allows them to construct filter-add commands without
(e.g.) adjusting the log format to show categories and drivers.
Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Sean Anderson [Tue, 27 Oct 2020 23:55:33 +0000 (19:55 -0400)]
cmd: log: Split off log level parsing
Move parsing of log level into its own function so it can be re-used. This
also adds support for using log level names instead of just the integer
equivalent.
Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Sean Anderson [Tue, 27 Oct 2020 23:55:30 +0000 (19:55 -0400)]
log: Add filter flag to match greater than a log level
This is the complement of the existing behavior to match only messages with
a log level less than a threshold. This is primarily useful in conjunction
with LOGFF_DENY.
Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Sean Anderson [Tue, 27 Oct 2020 23:55:27 +0000 (19:55 -0400)]
test: log: Convert log_test from python to C
When rebasing this series I had to renumber all my log tests because
someone made another log test in the meantime. This involved updaing a
number in several places (C and python), and it wasn't checked by the
compiler. So I though "how hard could it be to just rewrite in C?" And
though it wasn't hard, it *was* tedious. Tests are numbered the same as
before to allow for easier review.
A note that if a test fails, everything after it will probably also fail.
This is because that test won't clean up its filters. There's no easy way
to do the cleanup, except perhaps removing all filters in a wrapper
function.
Sean Anderson [Tue, 27 Oct 2020 23:55:26 +0000 (19:55 -0400)]
log: Add filter flag to deny on match
Without this flag, log filters can only explicitly accept messages.
Allowing denial makes it easier to filter certain subsystems. Unlike
allow-ing filters, deny-ing filters are added to the beginning of the
filter list. This should do the Right Thing most of the time, but it's
less-universal than allowing filters to be inserted anywhere. If this
becomes a problem, then perhaps log_filter_add* should take a filter number
to insert before/after.
Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>