This patch selects DM_SPI & DM_I2C for MIPS Octeon. DM_GPIO, DM_SERIAL
and DM_ETH are already selected.
Additionally the selections are now alphabetically sorted.
Signed-off-by: Stefan Roese <sr@denx.de>
Adds support for SPI controllers found on Octeon II/III and Octeon TX
TX2 SoC platforms.
Signed-off-by: Aaron Williams <awilliams@marvell.com>
Signed-off-by: Suneel Garapati <sgarapati@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Aaron Williams <awilliams@marvell.com>
Cc: Chandrakala Chavva <cchavva@marvell.com>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
This patch adds a simple clock driver for the Marvell Octeon MIPS SoC
family. Its for IO clock rate passing via DT in some of the Octeon
driver, like I2C. So that we don't need to use the non-mainline API
octeon_get_io_clock().
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Lukasz Majewski <lukma@denx.de>
Add support for GPIO controllers found on Octeon II/III and Octeon TX
TX2 SoC platforms.
Signed-off-by: Aaron Williams <awilliams@marvell.com>
Signed-off-by: Suneel Garapati <sgarapati@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
- ApolloLake: add u64 parameters support for FSP2 bindings
- ApolloLake: add missing parameters to support full configuration of
the latest FSP MR6 release
- Append appropriate suffixes in various assembly codes
This series comprises error corrections for the UEFI subsystem:
* make the memory size reserved for the U-Boot stack customizable
and reduce it for the MAIX board
* correct build dependencies for UEFI unit test
* enable read-only UEFI variable are enabled with the TEE backend
* add 10 ms wait to sysreset to fix a problem with unit testing
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAl8li/IACgkQxIHbvCwF
GsT2Ng/+Nvi034xRczd3Y4JiDf2eAHGlgTomtgtR+zVEKGA2bs5HHuG81Zf/56oU
E3HHOk14FaAxbq+L5h0d8MusShxoQYxWTytlSUpyIiYyaqUAczkUxmcfpxTF/z0B
LiuUGFAZZE53dvMTlbMydModLeKYf+4E1eGj+0PLF4Pxn6in15zZhz6QOXDZwo8E
Ht2gVDjB0Br9GGAvIs3joy98PK9W3Q0i36/rGQ4jkJKOpEZCJorgvDQjOGgMWiin
hGzg6AqoEFFfK7KFrMRYW2yWbnd8Mlo3+WsfsyeUnq7jVbPVY1oVvJxiz7Msg2Qd
wWEAGuSg+aXgJULbxKqfG55j3k32LpheaUd8VNOZKJ2eu0anmx3/S/K8qNSGFdmu
69scnf77xZSZHintjLY8SFvWAhNONCPcM3G8X/1mvn98hKIs1NBiRYD0DBSImQ76
ewl7yyLIYStayFcpMn7fi//u6dKpNETXXIoAHuyAo/ol2wGMmjohgyn12vHuP5B0
tvjzL42/6rJ1WzQEyZc50A6WoFPD4QEOq7BYznBiYdN3ACsZWiFvZGvrg6PAF1rC
l20yD7Pq3uaVI4zvr9KyfOltHgn9KXiQkMz+o5BGNEp0gE67XD/vyRfspifH+8sv
RARDLCiXDR0BfeNdzfXRede41wPPIP4+hNm2PX4FacptRucdPO8=
=ysb+
-----END PGP SIGNATURE-----
Merge tag 'efi-2020-10-rc2' of https://gitlab.denx.de/u-boot/custodians/u-boot-efi
Pull request for UEFI sub-system for efi-2020-10-rc2
This series comprises error corrections for the UEFI subsystem:
* make the memory size reserved for the U-Boot stack customizable
and reduce it for the MAIX board
* correct build dependencies for UEFI unit test
* enable read-only UEFI variable are enabled with the TEE backend
* add 10 ms wait to sysreset to fix a problem with unit testing
Assembler is not happy:
arch/x86/cpu/call32.S: Assembler messages:
arch/x86/cpu/call32.S:36: Warning: no instruction mnemonic suffix given and no register operands; using default for `retf'
Fix this by adding appropriate suffixes to the assembler commands.
Fixes: 6f92ed8f1a ("x86: Add a way to call 32-bit code from 64-bit mode")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Assembler is not happy:
arch/x86/cpu/sipi_vector.S: Assembler messages:
arch/x86/cpu/sipi_vector.S:134: Warning: no instruction mnemonic suffix given and no register operands; using default for `cmp'
arch/x86/cpu/sipi_vector.S:139: Warning: no instruction mnemonic suffix given and no register operands; using default for `bts'
arch/x86/cpu/sipi_vector.S:157: Warning: no instruction mnemonic suffix given and no register operands; using default for `cmp'
Fix this by adding appropriate suffixes to the assembler commands.
Fixes: 45b5a37836 ("x86: Add multi-processor init")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add missing parameters to support full configuration of the latest FSP
MR6 release.
Signed-off-by: Bernhard Messerklinger <bernhard.messerklinger@br-automation.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add FSP_UINT64 read support as preparation for FSP-M and FSP-S parameter
update.
Signed-off-by: Bernhard Messerklinger <bernhard.messerklinger@br-automation.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Fix some typos in arch/x86/include/asm/irq.h.
Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Do not execute the block device test if CONFIG_DOS_PARTITION=n.
Imply CONFIG_DOS_PARTITION in Kconfig.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
In our Python tests we expect to see the word "resetting". It may be
truncated if we reset before the serial console buffer is transferred.
Wait for 100 ms between the "resetting ..." message and the actual reset
like we do when powering off.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The Kconfig symbol CONFIG_STACK_SIZE is used both by ARM and Microblaze
with the same meaning. Move it to menu 'General setup' so that we can use
it for all architectures.
Use the value of CONFIG_STACK_SIZE instead of a hard coded 16 MiB value for
reserving memory in the UEFI sub-system.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Configuration variables should have the same meaning independent of the
architecture. x86 and ARM both use CONFIG_STACK_SIZE:
* x86: U-Boot's runtime stack size during reboot
* ARM: max stack size that can be used by U-Boot
Rename the x86 configuration variable to CONFIG_STACK_SIZE_REBOOT
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
We recently added functions for storing/restoring variables
from a file to a memory backed buffer marked as __efi_runtime_data
commit f1f990a8c9 ("efi_loader: memory buffer for variables")
commit 5f7dcf079d ("efi_loader: UEFI variable persistence")
Using the same idea we now can support GetVariable() and GetNextVariable()
on the OP-TEE based variables as well.
So let's re-arrange the code a bit and move the commmon code for
accessing variables out of efi_variable.c. Create common functions for
reading variables from memory that both implementations can use on
run-time. Then just use those functions in the run-time variants of the
OP-TEE based EFI variable implementation and initialize the memory
buffer on ExitBootServices()
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The current code does not trim the output buffer correctly.
In fact it doesn't trim the buffer at all, since it calculates a wrong
value for it, which isn't even applied.
So let's remove the unused temporary size variable and trim the buffer
correctly.
Since we are editing efi_get_next_variable_name_int(), fix an indentation
error along the way.
Fixes: f042e47e8f ("efi_loader: Implement EFI variable handling via OP-TEE")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Remove superfluous conversion to (u8 *) for memcpy argument.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
- Fix EFI selftest to not force setting serial# environment (and also
get the U-Boot prompt dynamically).
- Support for append only environment and other related features.
- Improved ext4 environment support
- Fix the case of fw_setenv being used on flash devices that were not
already locked.
With current implementation of fw_setenv, it is always locks u-boot-env
region if lock interface is implemented for such mtd device. You can
not control lock of this region with fw_setenv, there is no option for
it in config or in application itself. Because of this situation may
happen problems like in this thread on xilinx forum:
https://forums.xilinx.com/t5/Embedded-Linux/Flash-be-locked-after-use-fw-setenv-from-user-space
/td-p/1027851
A short summary of that link is: some person has issue with some spi
chip which has lock interface but doesn't locks properly which leads to
lock of whole flash memory on lock of u-boot-env region. As resulted
solution hack was added into spi-nor.c driver for this chip with lock
disablement.
Instead fix this problem by adding logic to fw_setenv only lock the
flash if it was already locked when we attempted to use it.
Signed-off-by: Ivan Mikhaylov <fr0st61te@gmail.com>
This option marks any U-Boot variable which does not have explicit 'w'
writeable flag set as read-only. This way the environment can be locked
down and only variables explicitly configured to be writeable can ever
be changed by either 'env import', 'env set' or loading user environment
from environment storage.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add configuration option which prevents the environment hash table to be
ever cleared and reloaded with different content. This is useful in case
the first environment loaded into the hash table contains e.g. sensitive
content which must not be dropped or reloaded.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add another custom environment flag which discerns environment coming
from external storage from environment set by U-Boot itself.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add another internal environment flag which indicates that the operation
is resetting the environment to the default one. This allows the env code
to discern between import of external environment and reset to default.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
If the ENV_ACCESS_IGNORE_FORCE is set, inform user that the variable
cannot be force-set if such attempt happens.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add support of opts erase for env in ext4,
this opts is used by command 'env erase'.
This command only fill the env file (CONFIG_ENV_EXT4_FILE)
with 0, the CRC and the saved environment becomes invalid.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Add basic test to persistent environment in ext4:
save and load in host ext4 file 'uboot.env'.
On first execution an empty EXT4 file system is created in
persistent data dir: env.ext4.img.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Add support of environment location with the new env command:
'env select' and 'env load'
The ENV backend is selected by priority order
- 0 = "nowhere" (default at boot)
- 1 = "EXT4"
To test EXT4 env support, this backend is selected by name:
> env select EXT4
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Activate ENV in EXT4 support in sandbox.
The sandbox behavior don't change; the default environment with
the nowhere backend (CONFIG_ENV_IS_NOWHERE)is still used:
the weak function env_get_location() return ENVL_NOWHERE for priority 0.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Add the new command 'env select' to force the persistent storage
of environment, saved in gd->env_load_prio.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Add the new command env load to load the environment from
the current location gd->env_load_prio.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
The ops driver load becomes mandatory in struct env_drive,
change the comment for this ops and remove unnecessary test.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Add the ops .load for nowhere ENV backend to load the
default environment.
This ops is needed for the command 'env load'
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Only update gd->env_load_prio in generic function env_load()
and no more in the weak function env_get_location() which is
called in many place (for example in env_driver_lookup, even
for ENVOP_SAVE operation).
This patch is a preliminary step to use env_driver_lookup()/
env_get_location() in new function env_select() without
updating gd->env_load_prio.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Add a missing initialization of gd->env_valid in env_ext4_load
as it is already done in some other env device.
Set gd->env_valid = ENV_VALID in env_ext4_save() and env_ext4_load().
This patch allows to have a correct information in 'env info' command.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Add the absolute path to the default value of
CONFIG_ENV_EXT4_FILE = "/uboot.env".
This patch avoid the error :
Saving Environment to EXT4... File System is consistent
Please supply Absolute path
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
This patch adds prototypes for several weak functions:
- env_ext4_get_intf
- env_ext4_get_dev_part
- env_get_location
It solves the following warnings when compiling with W=1
on stm32mp1 board:
board/st/stm32mp1/stm32mp1.c:849:19: warning: no previous prototype for 'env_get_location' [-Wmissing-prototypes]
enum env_location env_get_location(enum env_operation op, int prio)
^~~~~~~~~~~~~~~~
board/st/stm32mp1/stm32mp1.c:876:13: warning: no previous prototype for 'env_ext4_get_intf' [-Wmissing-prototypes]
const char *env_ext4_get_intf(void)
^~~~~~~~~~~~~~~~~
board/st/stm32mp1/stm32mp1.c:889:13: warning: no previous prototype for 'env_ext4_get_dev_part' [-Wmissing-prototypes]
const char *env_ext4_get_dev_part(void)
^~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
As part of the EFI self test we set and check the serial# variable.
However, we should not be forcing this setting. In the case where we
are allowed to change the variable it will change, and we will pass the
test. In the case where we cannot change it, force may or may not be
allowed, depending on further environment restrictions. Drop the -f
flag here as we do not need it.
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
In our tests we should use the customized prompt for testing.
Reported-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Tom Rini <trini@konsulko.com>
Refactor to allow any arch to create SPI-flash images
New button uclass
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAl8g33sRHHNqZ0BjaHJv
bWl1bS5vcmcACgkQfxc6PpAIreaeEgf/QhmJjd6lEE3ABncRa3texyqq7j9eu+9P
2JMCahrIzps83LLOkzNSGs1+m1hRuTcdnYNV8FxdmkAjDTYwV5RHOfwtpAr2nkH2
HBbJRA2qMPleqT8wcymouhaCIRTTCGfUkFgZ+OowwSlHnQ4d2oGU/59Z+AkbpfX0
3svA1Mlr5rUTZ3qTvdsepuZckuYOTGYZ5jgjbgr+G8F4iW4Ov+OkBxqDz9zFCveF
md5CHKP1SV+bq67Q9uqUEwatLzYpy1p24j1Qe4G08U1+XCi6r+95VEc7TWxggboj
eV/5d/sZbGESAtJiJ4TmqpGVcOLzBLI0FOunky0JNFwdcyRS/6KcCg==
=Xjil
-----END PGP SIGNATURE-----
Merge tag 'dm-pull-28jul20' of git://git.denx.de/u-boot-dm
Use binman instead of one of the Rockchip build scripts
Refactor to allow any arch to create SPI-flash images
New button uclass
