The resource type for system memory is currently displayed as
"unknown", which is wrong.
Fixes: 51af144eb7 ("x86: Allow showing details about a HOB entry")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: Simon Glass <sjg@chromium.org>
At present the hob command usage and help messages are messed up
in a single line. They should be separated.
This was a regression introduced when [seq] and [-v] were added
to the command.
Fixes: d11544dfa9 ("x86: hob: Add way to show a single hob entry")
Fixes: 51af144eb7 ("x86: Allow showing details about a HOB entry")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: Simon Glass <sjg@chromium.org>
The size parameter of mtrr_add_request() and mtrr_set_next_var()
shall be power of 2, otherwise the logic creates a mask that does
not meet the requirement of IA32_MTRR_PHYSMASK register.
Programming such a mask value to IA32_MTRR_PHYSMASK generates #GP.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: Simon Glass <sjg@chromium.org>
At present mtrr_commit() programs the MTRR MSRs starting from
index 0, which may overwrite MSRs that were already programmed
by previous boot stage or FSP.
Switch to call mtrr_set_next_var() instead.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: Simon Glass <sjg@chromium.org>
Current mtrr_commit() logic assumes that MTRR MSRs are programmed
consecutively from index 0 to its maximum number, and whenever it
detects an unused one, it clears all other MTRRs starting from that
one. However this may not always be the case.
In fact, the clear is not much helpful because these MTRRs come out
of reset as disabled already. Drop the clear codes.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: Simon Glass <sjg@chromium.org>
If for some reason, TSC timer frequency cannot be determined from
hardware, nor is it specified in the device tree, U-Boot will panic
resulting in endless reset during boot.
Let's define a default TSC timer frequency using the Kconfig value
CONFIG_X86_TSC_TIMER_FREQ (note: #include must be used instead of
/include/ otherwise the macro is not pre-processed).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Currently there are two places to specify the x86 TSC timer frequency
with one in Kconfig used for early timer and the other one in device
tree used when the frequency cannot be determined from hardware.
This may potentially create an inconsistent config where the 2 values
do not match. Let's use the one specified in Kconfig in the device
tree as well.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
These 2 options are no longer needed as now binman is used to build
u-boot.rom.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
binman complains when binary blobs are present:
Node '/binman/rom/intel-vga': Offset 0xfff90000 (4294508544) overlaps
with previous entry '/binman/rom/u-boot-dtb-with-ucode' ending at
0xfff9204c (4294516812)
Adjust VGA rom address to 0xfffa0000 so that u-boot.rom image can be
successfully built again.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
IRQ polarity in CSRT has the same definition as by ACPI specification
chapter 19.6.64 "Interrupt (Interrupt Resource Descriptor Macro)", i.e.
ActiveHigh is 0, and ActiveLow is 1. On Intel Tangier the DMA controller
IRQ polarity is ActiveHigh.
Note, in DSDT (see southcluster.asl) it's described correctly.
Fixes: 5e99fde34a ("x86: tangier: Populate CSRT for shared DMA controller")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Except ICH7 SPI, all SPI flashes connected to ICH9 / Fast SPI should
have "m25p,fast-read" property present in their DT nodes.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Since commit 71025f013c ("mtd: spi-nor-core: Rework hwcaps selection")
SPI flash on Intel Crown Bay board does not work anymore.
Disable CONFIG_SPI_FLASH_SMART_HWCAPS until a proper fix is made to
the spi-nor core.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Since commit 43c145b8b3 ("spi: ich: Correct max-size bug in ich_spi_adjust_size()")
(in v2020.04-rc1), SPI flash read no longer works with ICH SPI controller
in software sequencer mode.
ICH controller can only transfer a small number of bytes at once.
Before commit 43c145b8b3, the logic happens to make sure data.nbytes
is limited to slave->max_write_size but after commit 43c145b8b3
data.nbytes is no longer limited because slave->max_read_size is not
initialized with a valid number.
Fixes: 43c145b8b3 ("spi: ich: Correct max-size bug in ich_spi_adjust_size()")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Parameter -W for sphinx-build turns build warnings into errors. This helps
us to avoid bad patches passing Gitlab CI.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The Hitachi tx18d42vm LCD panel driver is really just initialising the
device, using bitbanged SPI, during operation there is nothing to do.
This makes the driver self contained, so drop the bogus dependency on
the legacy CONFIG_VIDEO.
This avoids the warning when building Chuwi_V7_CW0825_defconfig, since
we switched to DM_VIDEO recently.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The U-Boot port for ST-Ericsson Ux500 is currently only used on the
"stemmy" board, where U-Boot runs after firmware that already sets up
a boot splash screen. This means that the display is already on
and we can just continue using it for U-Boot.
Add a simple driver that simplifies this by reading the display
configuration (e.g. screen size, bpp) from the hardware registers.
It also checks the configured "source synchronization" - for some
displays (usually DSI command mode displays) we need to explicitly
trigger a software sync. This is done through the video_sync()
callback that triggers the sync and wait for completion.
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
rST documentation and fixes for moveconfig
handle empty 'ranges' property in dtoc
patman warning for invalid tag
clean-ups to 'fdt add' command
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAmEG4R4RHHNqZ0BjaHJv
bWl1bS5vcmcACgkQfxc6PpAIreapJwgAtKsKWy+TReCluKdG6Rdc3vtJwE9WP0/O
ms5JE/Rxk2wP7TMhuC6Sgl8WWhxuRpo623BfbtvbcBnxN/kugQRVNMYHiPTLzR78
SUq/DxLbWz46MbYTPwgJxhMquJKAzgSh8YgHwgvFLB31EozQzXB8LYHorRQdW0TG
42dKAOO3eDRMlT/DGkUcqm7dh9oG2T0rhGgJ1eQ/6vRksz8U0adunZeLA+sQQKRQ
uwPbNbCX3mx1nVqN37bitatHYVxvJg6yVq9awcaAhk1gtlUzBvJghNFkEmLTALBd
UFRMbWZXwf+7msffWJE5IcWrZxOAHixYgRMVv+iyFHEkyiSEKUAtZA==
=4cKs
-----END PGP SIGNATURE-----
Merge tag 'dm-pull-1aug21' of https://source.denx.de/u-boot/custodians/u-boot-dm
sandbox TPM-emulator improvements
rST documentation and fixes for moveconfig
handle empty 'ranges' property in dtoc
patman warning for invalid tag
clean-ups to 'fdt add' command
At present if we see 'ranges' property (with no value) we assume it is a
boolean, as per the devicetree spec.
But another node may define 'ranges' with a value, forcing us to widen it
to an int array. At present this is not supported and causes an error.
Fix this and add some test cases.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Tom Rini <trini@konsulko.com>
An int array can hold a single int so we should not need to do anything
in the widening operation. However due to a quirk in the code, an int[3]
widened with an int produced an int[4]. Fix this and add a test.
Fix a comment typo while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Tom Rini <trini@konsulko.com>
The current name is confusing because the logic is actually backwards from
what you might expect. Rename it to needs_widening() and update the
comments.
Signed-off-by: Simon Glass <sjg@chromium.org>
The autoboot tests are a recent addition to U-Boot, providing much-needed
coverage in this area.
A side effect of the keyed autoboot test is that this feature is enabled
in sandbox always. This changes the autoboot prompt and confuses the
pytests. Some tests become slower, for example the vboot tests take about
27s now instead of 3s.
We don't actually need this feature enabled to be able to run the tests.
Add a switch to allow sandbox to turn it on and off as needed. Use this
in the one test that needs it.
Add a command-line flag in case this is desired in normal use.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 25c8b9f298 ("test: add first autoboot unit tests")
Reviewed-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
Some of the more advanced features of this tool don't work anymore since
kconfiglib was update. Update the code accordingly.
Signed-off-by: Simon Glass <sjg@chromium.org>
The examples here are a bit messed up since the command does not match
the documentation. Use a different example instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
This tool has nothing to do with testing. It is for refactoring code
automatically using a 'semantic patch' tool.
Create a new section for 'refactoring' and move it into there. It is
likely that other topics may fall under the same heading, such as
using moveconfig and search/replace tools.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this information is hidden away. Make it more visible by
putting it first, in an intro section.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Add a error in patman tool when the commit message contents an invalid
tag "Serie-.*" instead of "Series-.*".
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
It seems useful to show whether the address of the Control or Working
devicetree is being shown. Add support for this. Drop the confusing 0x
prefix since the command itself only accepts hex.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is fairly easy to handle this case and it makes the emulator more
useful, since PCRs are commonly extended several times.
Add support for this, using U-Boot's sha256 support.
For now sandbox only supports a single PCR, but that is enough for the
tests that currently exist.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is the number of PCRs, so the current check is off by one. Also the
map itself should not be checked, just the resulting pcr_index, to avoid
confusing people who read the code.
Fix these problems.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the tpm2 emulator does not support storing the device state.
Add this so we can handle the normal vboot flow through the sandbox
executables (VPL->SPL etc.) with the TPM contents staying in place.
Note: sandbox has not yet been converted to use livetree for the state
information, since livetree does not yet support writing to the tree.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add checking as to whether the current TPM state is valid, so we can
implement reading/writing the state.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function current handles the kernel case incorrectly. Fix it, and
use the shorter TPM_HDR_LEN while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for this command, moving away from the previous approach of
hard-coding the initial data in the driver, now that the kernel-space data
has to be set up by the higher-level vboot code.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this code assumes that the TPM data has been read but this may
not be the case. Refactor the code to use a separate pointer so we know
the current state of the data.
Add error checking for the data size.
Signed-off-by: Simon Glass <sjg@chromium.org>
We want to support nvdata in TPM2 as well. To avoid code duplicating the
associated code, move it into a common file.
Drop the special-case logic for the kernel space. This can be handled by
the higher-level code now, i.e. in vboot itself.
Signed-off-by: Simon Glass <sjg@chromium.org>
We should not use /dev/sda and /dev/sdb in our examples. Users might
inadvertently mess up their workstation. Use /dev/sdX instead.
Remove console output like '# ' and '> ' which makes copying hard.
Set example language to bash for correct syntax-highlighting.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
iewed-by: Bin Meng <bmeng.cn@gmail.com>
CONFIG_HEXDUMP is needed to display UEFI variables using 'printenv -e'.
Enabling CONFIG_SPL_HEXDUMP only makes sense for debugging purposes.
Hence CONFIG_SPL_HEXDUMP should not be enabled by default.
The following boards currently have CONFIG_SPL_HEXDUMP=y. This includes
boards that don't use SPL at all.
axm_defconfig
imx8mm-cl-iot-gate_defconfig
imx8mm_venice_defconfig
imxrt1020-evk_defconfig
imxrt1050-evk_defconfig
kontron_sl28_defconfig
kp_imx53_defconfig
lx2160ardb_tfa_stmm_defconfig
mt7622_rfb_defconfig
octeon_ebb7304_defconfig
octeon_nic23_defconfig
qemu_arm64_defconfig
qemu_arm_defconfig
qemu-riscv32_defconfig
qemu-riscv32_smode_defconfig
qemu-riscv64_defconfig
qemu-riscv64_smode_defconfig
qemu-x86_64_defconfig
qemu-x86_defconfig
sandbox64_defconfig
sandbox_defconfig
stm32mp15_basic_defconfig
stm32mp15_trusted_defconfig
synquacer_developerbox_defconfig
taurus_defconfig
xilinx_versal_virt_defconfig
The patch only keeps it enabled on
sandbox_spl_defconfig
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
When scrolling the TrueType console a buffer overrun occurs.
Fixes: a29b012037 ("video: Add a console driver that uses TrueType fonts")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
- Move the PSCI runtime code for H3/A23/A33 into SRAM
- Pick the environment from the actual MMC boot device (SD card vs.
eMMC)
- Plus a small improvement from Icenowy, just for good measure.
There are more Allwinner SoCs that do not have a SCP now.
When there's no SCP_ADDR macro defined, we can assume there's no SCP
available.
Drop the scp part of FIT description when SCP_ADDR does not exist.
Signed-off-by: Icenowy Zheng <icenowy@sipeed.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
So far for the H3, A23, and A33 SoCs, we use DRAM to hold the secure
monitor code (providing PSCI runtime services). And while those SoCs do
not have the secure SRAM B like older SoCs, there is enough (secure)
SRAM A2 to put the monitor code and data in there instead.
Follow the design of 64-bit SoCs and use the first part for the monitor,
and the last 16 KiB for the SCP firmware. With this change, the monitor
no longer needs to reserve a region in DRAM.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
[Andre: amend commit message, fix R40 and V3s build]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Currently, the environment is always stored in eMMC if eMMC is enabled
in the config. This means images written to SD and eMMC will cross-
contaminate their environments unless the configuration is changed.
By dropping the device number from the environment location string and
implementing mmc_get_env_dev, we will always use the environment from
the boot device when booting from SD/eMMC.
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>
