This adds R-Car Generation 4 (Gen4) support as Renesas ARM64 SoC.
In this version, reusing R-Car Gen3 lowlevel initialize routine [1]
and R-Car Gen3 memory map tables [2] .
[1] arch/arm/mach-rmobile/lowlevel_init_gen3.S
[2] arch/arm/mach-rmobile/memmap-gen3.c
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[Marek: - Enable DTO support by default
- Sort the Kconfig lists
- Select RCAR_64 Kconfig option to pull in all the shared
Kconfig options with Gen3, and use where applicable to
deduplicate entries.
- Fix reference [2] typo in commit message
- Drop config options moved to Kconfig, rename rest to CFG_
accordingly to synchronize with upstream changes. Drop
removed CONFIG_VERY_BIG_RAM.
- Move board size limit to arch/Kconfig
- Move GICR_BASE to headers instead of common config]
This configuration setting is only relevant if the board supports USB.
It should not be in the main menu but in the USB menu.
The setting is only relevant in USB host mode.
Fixes: 5454dea313 ("usb: hub: allow to increase HUB_DEBOUNCE_TIMEOUT")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
We can use this feature in VPL, so add some options for it. Also fix a
typo in the SPL help while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
As platforms which require this hook need this hook enabled, in order to
function, or do not need this hook, it doesn't make sense to prompt the
user. As all platforms that need this hook now select the symbol, remove
the prompt text.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
While it is true that for some Samsung platforms, we call
get_board_type() the main usage of this CONFIG switch is to enable
board_types in global data, which is then used by various platforms.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
We can enforce the dependencies of this module via Kconfig now, so do so
rather than with #error statements. Further, we can ensure that all
required values are set to their defaults in Kconfig, and in fact
already do so, so remove the tests here. The exception is
CONFIG_UPDATE_LOAD_ADDR which needed to be migrated to Kconfig in the
first place.
Signed-off-by: Tom Rini <trini@konsulko.com>
The event framework is just that, a framework. Enabling it by itself
does nothing, so we shouldn't ask the user about it. Reword (and correct
typos) around this the option and help text. This also applies to
DM_EVENT and EVENT_DYNAMIC. Only EVENT_DEBUG and CMD_EVENT should be
visible to the user to select, when EVENT is selected.
With this, it's time to address the larger problems. When functionality
uses events, typically via EVENT_SPY, the appropriate framework then
must be select'd and NOT imply'd. As the functionality will cease to
work (and so, platforms will fail to boot) this is non-optional and
where select is appropriate. Audit the current users of EVENT_SPY to
have a more fine-grained approach to select'ing the framework where
used. Also ensure the current users of event_register and also select
EVENT_DYNAMIC.
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reported-by: Oliver Graute <Oliver.Graute@kococonnector.com>
Reported-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Fixes: 7fe32b3442 ("event: Convert arch_cpu_init_dm() to use events")
Fixes: 42fdcebf85 ("event: Convert misc_init_f() to use events")
Fixes: c5ef202557 ("dm: fix DM_EVENT dependencies")
Signed-off-by: Tom Rini <trini@konsulko.com>
Tested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Add a new CONFIG_USB_HUB_DEBOUNCE_TIMEOUT to increase the
HUB_DEBOUNCE_TIMEOUT value, for example to 2s because some usb device
needs around 1.5s or more to make the hub port status to be
connected steadily after being powered off and powered on.
This 2s value is aligned with Linux driver and avoids to configure
"usb_pgood_delay" as a workaround for connection timeout on
some USB device; normally the env variable "usb_pgood_delay" is used
to delay the first query after power ON and thus the device answer,
but this variable not used to increase the connection timeout delay.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Add a config-option which forces the console to stay silent until the
proper environment is loaded from flash.
This is important when the default environment does not silence the
console but no output must be printed when 'silent' is set in the flash
environment.
After the environment from flash is loaded, the console will be
silenced/unsilenced depending on it. If PRE_CONSOLE_BUFFER is also
used, the buffer will now be flushed if the console should not be
silenced.
Signed-off-by: Harald Seiler <hws@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
This is only used on sandbox, so select it there.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add an option to allow silent console to be controlled separately in SPL,
so that boot progress can be shown. Disable it by default for sandbox
since it is useful to see what is going on there.
Signed-off-by: Simon Glass <sjg@chromium.org>
On certain places it is required to flush output print buffers to ensure
that text strings were sent to console or serial devices. For example when
printing message that U-Boot is going to boot kernel or when U-Boot is
going to change baudrate of terminal device.
Therefore introduce a new flush() and fflush() functions into console code.
These functions will call .flush callback of associated stdio_dev device.
As this function may increase U-Boot side, allow to compile U-Boot without
this function. For this purpose there is a new config CONSOLE_FLUSH_SUPPORT
which is enabled by default and can be disabled. It is a good idea to have
this option enabled for all boards which have enough space for it.
When option is disabled when U-Boot defines just empty static inline
function fflush() to avoid ifdefs in other code.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add the basic infrastructure to periodically execute code, e.g. all
100ms. Examples for such functions might be LED blinking etc. The
functions that are hooked into this cyclic list should be small timewise
as otherwise the execution of the other code that relies on a high
frequent polling (e.g. UART rx char ready check) might be delayed too
much. This patch also adds the Kconfig option
CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time
for such a cyclic function. If it's execution time exceeds this time,
this cyclic function will get removed from the cyclic list.
How is this cyclic functionality executed?
The following patch integrates the main function responsible for
calling all registered cyclic functions cyclic_run() into the
common WATCHDOG_RESET macro. This guarantees that cyclic_run() is
executed very often, which is necessary for the cyclic functions to
get scheduled and executed at their configured periods.
This cyclic infrastructure will be used by a board specific function on
the NIC23 MIPS Octeon board, which needs to check periodically, if a
PCIe FLR has occurred.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
A recurring theme on LKML is the boot process deadlocking due to some
process blocking waiting for random numbers, while the kernel's
Cryptographic Random Number Generator (crng) is not initalized yet,
but that very blocking means no activity happens that would generate
the entropy necessary to finalize seeding the crng.
This is not a problem on boards that have a good hwrng (when the
kernel is configured to trust it), whether in the CPU or in a TPM or
elsewhere. However, that's far from all boards out there. Moreover,
there are consumers in the kernel that try to obtain random numbers
very early, before the kernel has had any chance to initialize any
hwrng or other peripherals.
Allow a board to provide a board_rng_seed() function, which is
responsible for providing a value to be put into the rng-seed property
under the /chosen node.
The board code is responsible for how to actually obtain those
bytes.
- One possibility is for the board to load a seed "file" from
somewhere (it need not be a file in a filesystem of course), and
then ensure that that the same seed file does not get used on
subsequent boots.
* One way to do that is to delete the file, or otherwise mark it as
invalid, then rely on userspace to create a new one, and living
with the possibility of not finding a seed file during some boots.
* Another is to use the scheme used by systemd-boot and create a new
seed file immediately, but in a way that the seed passed to the
kernel and the new (i.e. next) seed cannot be deduced from each
other, see the explanation at
https://lore.kernel.org/lkml/20190929090512.GB13049@gardel-login/
and the current code at
https://github.com/systemd/systemd/blob/main/src/boot/efi/random-seed.c
- The board may have an hwrng from which some bytes can be read; while
the kernel can also do that, doing it in U-Boot and providing a seed
ensures that even very early users in the kernel get good random
numbers.
- If the board has a sensor of some sort (temperature, humidity, GPS,
RTC, whatever), mixing in a reading of that doesn't hurt.
- etc. etc.
These can of course be combined.
The rng-seed property is mixed into the pool used by the linux
kernel's CRNG very early during boot. Whether it then actually
contributes towards the kernel considering the CRNG initialized
depends on whether the kernel has been configured with
CONFIG_RANDOM_TRUST_BOOTLOADER (nowadays overridable via the
random.trust_bootloader command line option). But that's for the BSP
developer to ultimately decide.
So, if the board needs to have all that logic, why not also just have
it do the actual population of /chosen/rng-seed in ft_board_setup(),
which is not that many extra lines of code?
I considered that, but decided handling this logically belongs in
fdt_chosen(). Also, apart from saving the board code from the few
lines of boilerplate, doing it in ft_board_setup() is too late for at
least some use cases. For example, I want to allow the board logic to
decide
ok, let's pass back this buffer and use that as seed, but also let's
set random.trust_bootloader=n so no entropy is credited.
This requires the rng-seed handling to happen before bootargs
handling. For example, during the very first boot, the board might not
have a proper seed file, but the board could still return (a hash of)
some CPU serial# or whatnot, so that at least no two boards ever get
the same seed - the kernel always mixes in the value passed in
rng-seed, but if it is not "trusted", the kernel would still go
through the same motions as it would if no rng-seed was passed before
considering its CRNG initialized. I.e., by returning that
unique-to-this-board value and setting random.trust_bootloader=n, the
board would be no worse off than if board_rng_seed() returned nothing
at all.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
This converts the following to Kconfig:
CONFIG_SYS_I2C_EEPROM_CCID
CONFIG_SYS_I2C_EEPROM_NXID
CONFIG_SYS_EEPROM_BUS_NUM
Signed-off-by: Tom Rini <trini@konsulko.com>
Tighten up symbol dependencies in a number of places. Ensure that a SPL
specific option has at least a direct dependency on SPL. In places
where it's clear that we depend on something more specific, use that
dependency instead. This means in a very small number of places we can
drop redundant dependencies.
Reported-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Tighten up symbol dependencies in a number of places. Ensure that a VPL
specific option has at least a direct dependency on VPL. In places
where it's clear that we depend on something more specific, use that
dependency instead.
Reported-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Tighten up symbol dependencies in a number of places. Ensure that a TPL
specific option has at least a direct dependency on TPL. In places
where it's clear that we depend on something more specific, use that
dependency instead.
Reported-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
This feature is not available in SPL unless common/ and lib/ are built.
Update the Kconfig to avoid build errors.
Signed-off-by: Simon Glass <sjg@chromium.org>
This hook can be implmented using events, for the three boards that
actually use it.
Add the event type and event handlers. Drop CONFIG_MISC_INIT_F since we
can just use CONFIG_EVENT to control this. Since sandbox always enables
CONFIG_EVENT, we can drop the defconfig lines there too.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a way to create and dispatch events without needing to allocate
memory. Also add a way to 'spy' on events, thus allowing 'hooks' to be
created.
Use a linker list for static events, which we can use to replace functions
like arch_cpu_init_f(). Allow an EVENT_DEBUG option which makes it
easier to see what is going on at runtime, but uses more code space.
Dynamic events allow the creation of a spy at runtime. This is not always
necessary, but can be enabled with EVENT_DYNAMIC if needed.
A 'test' event is the only option for now.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present we do support allocating the bloblist but the Kconfig is a bit
strange, since we still have to specify an address in that case. Partly
this is because it is a pain to have CONFIG options that disappears when
its dependency is enabled. It means that we must have #ifdefs in the code,
either in the C code or header file.
Make use of IF_ENABLED_INT() and its friend to solve that problem, so we
can separate out the location of bloblist into a choice. Put the address
and size into variables so we can log the result.
Add the options for SPL as well, so we can use CONFIG_IS_ENABLED().
Signed-off-by: Simon Glass <sjg@chromium.org>
We typically refer to the different U-Boot builds that a board runs
through as phases. This avoids confusion with the word 'stage' which is
used with bootstage, for example. Fix up some bloblist Kconfig help
which uses the wrong term.
Signed-off-by: Simon Glass <sjg@chromium.org>
This converts the following to Kconfig:
CONFIG_SYS_FSL_CLK
We move the exiting option to common/Kconfig near the other options to
control the contents of board_init_f() and note that this is a legacy
option. We further restrict this to where the call is going to be
non-empty, for the SoCs that had only been using this for some
MMC-related clocks.
Signed-off-by: Tom Rini <trini@konsulko.com>
Typically the bloblist is positioned at a fixed address in memory until
relocation. This is convenient when it is set up in SPL or before
relocation.
But for EFI we want to set it up only when U-Boot proper is running. Add
a way to allocate it using malloc() and update the documentation to cover
this aspect of bloblist.
Note there are no tests of this feature at present, nor any direct testing
of bloblist_init().
This can be added, e.g. by making this option controllable at runtime.
Signed-off-by: Simon Glass <sjg@chromium.org>
This converts the following to Kconfig:
CONFIG_LCD_DT_SIMPLEFB
This patch also renames this config to CONFIG_FDT_SIMPLEFB as the code in
common/lcd_simplefb.c support CONFIG_LCD and CONFIG_VIDEO.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Before relocation there is generally not as much available memory and not
that much console output. At present the console-output buffer is the same
side before and after relocation. Add a separate Kconfig option to remove
this limitation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Quite a lot of the code in common/relates to booting and images. Before
adding more it seems like a good time to move the code into its own
directory.
Most files with 'boot' or 'image' in them are moved, except:
- autoboot.c which relates to U-Boot automatically running a script
- bootstage.c which relates to U-Boot timing
Drop the removal of boot* files from the output directory, since this
interfers with the symlinks created by tools and there does not appear
to be any such file from my brief testing.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Artem Lapkin <email2tema@gmail.com>
Tested-by: Artem Lapkin <email2tema@gmail.com>
After DM_VIDEO conversion the 'vidconsole' is the correct name
for the frame buffer console. 'video' will not work, so update
the description of the config option.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
default n/no doesn't need to be specified. It is default option anyway.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
[trini: Rework FSP_USE_UPD portion]
Signed-off-by: Tom Rini <trini@konsulko.com>
At present when function names are logged, the output is a little hard to
read since every function is a different length. Add a way to pad the
names so that the log messages line up vertically. This doesn't work if
the function name is very long, but it makes a big difference in most
cases.
Use 20 characters as a default since this covers the vast majority of
functions.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for stack protector for UBOOT, SPL, and TPL
as well as new pytest for stackprotector
Signed-off-by: Joel Peshkin <joel.peshkin@broadcom.com>
Adjust UEFI build flags.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This Trusted Application allows enabling SCP03 as well as provisioning
the keys on TEE controlled secure element (ie, NXP SE050).
All the information flowing on buses (ie I2C) between the processor
and the secure element must be encrypted. Secure elements are
pre-provisioned with a set of keys known to the user so that the
secure channel protocol (encryption) can be enforced on the first
boot. This situation is however unsafe since the keys are publically
available.
For example, in the case of the NXP SE050, these keys would be
available in the OP-TEE source tree [2] and of course in the
documentation corresponding to the part.
To address that, users are required to rotate/provision those keys
(ie, generate new keys and write them in the secure element's
persistent memory).
For information on SCP03, check the Global Platform HomePage and
google for that term [1]
[1] globalplatform.org
[2] https://github.com/OP-TEE/optee_os/
check:
core/drivers/crypto/se050/adaptors/utils/scp_config.c
Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Reviewed-by: Simon Glass <sjg@chromium.org>
