To fully support DM timer in SPL and TPL, we need a few things cleaned
up and normalised:
- inclusion of the uclass and drivers should be an all-or-nothing
decision for each stage and under control of $(SPL_TPL_)TIMER
instead of having the two-level configuration with TIMER and
$(SPL_TPL_)TIMER_SUPPORT
- when $(SPL_TPL_)TIMER is enabled, the ARMv8 generic timer code can
not be compiled in
This normalises configuration to $(SPL_TPL_)TIMER and moves the config
options to drivers/timer/Kconfig (and cleans up the collateral damage
to some defconfigs that had SPL_TIMER_SUPPORT enabled).
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
We can finally drop TPL_STACK, TPL_TEXT_BASE and TPL_MAX_SIZE off the
whitelist (this time it's really happening!) and migrate the setting
(only used on the RK3368-uQ7 so far) into Kconfig.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Let's clean up behind ourselves and move the (newly defined)
TPL_STACK, TPL_MAX_SIZE and TPL_TEXT_BASE into Kconfig. Given that
0x0 might be considered to be valid values for TPL_TEXT_BASE and
TPL_STACK, we need to introduce helper config options
("TPL_NEEDS_SEPARATE_...") to indicate that these symbols are used
(and not inherited from their SPL variants) for any given
target-platform.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Now that we have split up SPL_LDSCRIPT into a SPL and TPL variant and
have started to use the TPL-variant for the RK3368, it's time to clean
up behind ourselves: move both variants into Kconfig and remove them
from the whitelist.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds the TPL_DRIVER_MISC_SUPPORT option to allow activation of
DRIVER_MISC_SUPPORT for devices that need it in the TPL stage.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
To allow for a finer-grained control of features for TPL and SPL
builds all modules/boot-methods/etc. need to be consistently selected
based on the $(SPL_TPL_) macros.
This allows splitting the associated config-options in Kconfig: we
don't split the Kconfig options here and now, as this should happen on
an as-needed basis, whenever someone needs a feature/boot-method/etc.
in their TPL.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
As include/malloc.h already checks for SYS_MALLOC_SIMPLE using the
CONFIG_IS_ENABLED macro, we need to move to having separate entries
as we switch to fully separate configuration for SPL and TPL.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Even though there's now a TPL_DM configuration option, the spl logic
still checks for SPL_DM and thus does not pick up the proper config
option.
This introduces the use of CONFIG_IS_ENABLED(DM) in spl.c to always
pick up the desired configuration option instead of having a
hard-coded check for the SPL variant.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
TPL_NAND_SUPPORT, TPL_SERIAL_SUPPORT, TPL_SPI_FLASH_SUPPORT and
TPL_SPI_SUPPORT refer to SPL in their help text. This fixes up
the description to correctly reference TPL.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The (upstream) changes to break up SYS_MALLOC_F_LEN for the full
U-Boot and the SPL stage, break TPL (if simple malloc is enabled in
TPL).
This adds support for a TPL-variant of SYS_MALLOC_F_LEN:
- adds TPL_SYS_MALLOC_F_LEN
- rewrites a test for CONFIG_SPL_SYS_MALLOC_F_LEN to access
CONFIG_VAL(SYS_MALLOC_F_LEN)
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
On the RK3368, we want our TPL to use the 'return to bootrom' boot
method (to have the bootrom load up the SPL stage) and then continue
with different boot methods (MMC, SPI, etc.) from SPL.
This adds the config option needed to control the availabily of the
'return to bootrom' boot-method separately for the TPL stage.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Some devices (e.g. the RK3368) have only limited SRAM, but provide
support for loading the next boot stage after our SPL performs basic
setup (e.g. DRAM).
For target systems like these, we add a boot device BOOTROM that will
invoke a board-specific hook to return to the bootrom (if supported).
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The environment has pretty much nothing to do with just "PPC", so
rename the macros to just __UBOOT_ENV_SECTION__ which is more
readable.
In addition, only a single macro is needed: the environment now goes
either to the default section (USE_HOSTCC is defined) or in the .text
section.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
CONFIG_SYS_USE_PPCENV is no longer used anywhere. It was used to put
the environment in the special .ppcenv section, but the last
architecture using this section (SuperH) has been changed to not use
it.
Therefore, this commit drops support for CONFIG_SYS_USE_PPCENV
entirely. We only handle two cases:
- We're building the host tool tools/envcrc, in which case the
environment is place with no special section attribute (so it
depends up in .data)
- We're building U-Boot itself, in which case the environnement is
placed in the .text section.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Make reserve_mmu a weak so that it provides an option
to customize this routine as per platform need
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This is architecture-dependent early initialization hence should
be put in the platform Kconfig.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
CONFIG_BOARD_EARLY_INIT_F literally indicates board-specific codes
and should be not 'default y' for all x86 boards.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This function appears to obtain the value of the 'ranges' property rather
than 'reg'. As such it does not behave as documented or expected.
In addition it picks up the second field of the property which is the size
(with prop += naddr) rather than the first which is the address.
Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present if U-Boot proper uses driver model for MMC, then SPL has to
also. While this is desirable, it places a significant barrier to moving
to driver model in some cases. For example, with a space-constrained SPL
it may be necessary to enable CONFIG_SPL_OF_PLATDATA which involves
adjusting some drivers.
Add new SPL versions of the options for DM_MMC, DM_MMC_OPS and BLK. By
default these follow their non-SPL versions, but this can be changed by
boards which need it.
Signed-off-by: Simon Glass <sjg@chromium.org>
With driver model the serial device is often not called "serial". Mark
driver-model stdio devices so that they can be detected and we can look up
the uclass. This is a more reliable way of finding out whether the console
is connected to a serial device or not.
Signed-off-by: Simon Glass <sjg@chromium.org>
Put the check for whether a console is a serial device in a function so
that we can share the code in the two places that use it.
Signed-off-by: Simon Glass <sjg@chromium.org>
We rename the various FAT_ENV_xxx options to CONFIG_ENV_FAT_xxx so that
they can be modified via Kconfig. Migrate all existing users to the new
values.
Signed-off-by: Tom Rini <trini@konsulko.com>
After fetching hub descriptor, we need to call USB uclass operation
update_hub_device() to notify HCD to do some preparation work.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
A high speed hub has a special responsibility to handle full speed/
low speed devices connected on downstream ports. In this case, the
hub must isolate the high speed signaling environment from the full
speed/low speed signaling environment with the help of Transaction
Translator (TT). TT details are provided by hub descriptors and we
parse and save it to hub uclass_priv for later use.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
USB 3.0 hub uses a hub depth value multiplied by four as an offset
into the 'route string' to locate the bits it uses to determine the
downstream port number. We shall set the hub depth value of a USB
3.0 hub after it is configured.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
USB 3.0 hub port status field has different bit positions from 2.0
hubs. Since U-Boot only understands the old version, translate the
new one into the old one.
Since we are going to add USB 3.0 hub support, this feature is only
available with driver model USB.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Sometimes we need know if a given hub device is root hub or not.
Add a new API to test this. This removes the xHCI driver's own
version is_root_hub() and change to use the new API.
While we are here, remove the unused/commented out get_usb_device()
in the xHCI driver too.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
At present hub_port_reset() is defined in DM USB, but it is never
called hence remove it (removing another ifdefs).
While we are here, change legacy_hub_port_reset() name to
usb_hub_port_reset() to better match other function names in the
same hub module.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Use USB hub device's dev->uclass_priv to point to 'usb_hub_device'
so that with driver model usb_hub_reset() and usb_hub_allocate()
are no longer needed.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
USB 3.0 hubs have a slightly different hub descriptor than USB 2.0
hubs, with a fixed (rather than variable length) size. Change the
host controller drivers that access those last two fields
(DeviceRemovable and PortPowerCtrlMask) to use the union.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
For accuracy, we should use 'sizeof(struct usb_port_status)' as the
wLength for 'get port status' request, although it happens to be
equal to 'sizeof(struct usb_hub_status)'.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
Testing a USB 3.0 hub by connecting it to the xHCI port on Intel
MinnowMax, when issuing 'get hub descriptor' to the hub, xHCI
reports a transfer event TRB with a completion code 6 which means
'Stall Error'.
In fact super speed USB hub descriptor type is 0x2a, not 0x29.
Sending correct SETUP packet to the hub makes it not stall anymore.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
It was observed that on Intel MinnowMax board, when xHCI is enabled
in the BayTrail SoC, with a USB 3.0 device connected to the bottom
USB 3.0 port (mapped to xHCI root port #7), its PORTSC register is
always 0x201203 (CCS = 1, CSC = 0). The root cause of such behavior
is unknown yet. Connect status change bit is set on the same port
with a USB 2.0 device (mapped to xHCI port #1, which is a different
port on the root hub).
With current logic in usb_scan_port(), the enumeration process will
abort if it does not detect a connect status change on a hub port.
However since a device connection status is correctly reported, the
enumeration process can still continue.
With this change, USB device connected to the bottom blue port on
MinnowMax board can be enumerated under either SS or HS mode.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
Tested-by: Dinh Nguyen <dinguyen@kernel.org>
Current puts() and putc() have similar #ifdef / if() conditionals.
Make puts() iterate over putc() to avoid code duplication.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Some platforms have very limited SRAM to run SPL code, so there may
not be the same amount space for a malloc pool before relocation in
the SPL stage as the normal U-Boot stage.
Make SPL and (the full) U-Boot stage use independent SYS_MALLOC_F_LEN,
so the size of pre-relocation malloc pool can be configured memory
space independently.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
[fixed up commit-message:]
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
The CONFIG_ENV_IS_IN_... options which have already been converted to
Kconfig only have a small amount of help. Move the rest of it over from
the README.
Signed-off-by: Simon Glass <sjg@chromium.org>
This converts the following to Kconfig:
CONFIG_ENV_IS_IN_MMC
CONFIG_ENV_IS_IN_NAND
CONFIG_ENV_IS_IN_UBI
CONFIG_ENV_IS_NOWHERE
In fact this already exists for sunxi as a 'choice' config. However not
all the choices are available in Kconfig yet so we cannot use that. It
would lead to more than one option being set.
In addition, one purpose of this series is to allow the environment to be
stored in more than one place. So the existing choice is converted to a
normal config allowing each option to be set independently.
There are not many opportunities for Kconfig updates to reduce the size of
this patch. This was tested with
./tools/moveconfig.py -i CONFIG_ENV_IS_IN_MMC
And then manual updates. This is because for CHAIN_OF_TRUST boards they
can only have ENV_IS_NOWHERE set, so we enforce that via Kconfig logic
now.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
U-Boot has up until now built with -fpic for the MIPS architecture,
producing position independent code which uses indirection through a
global offset table, making relocation fairly straightforward as it
simply involves patching up GOT entries.
Using -fpic does however have some downsides. The biggest of these is
that generated code is bloated in various ways. For example, function
calls are indirected through the GOT & the t9 register:
8f998064 lw t9,-32668(gp)
0320f809 jalr t9
Without -fpic the call is simply:
0f803f01 jal be00fc04 <puts>
This is more compact & faster (due to the lack of the load & the
dependency the jump has on its result). It is also easier to read &
debug because the disassembly shows what function is being called,
rather than just an offset from gp which would then have to be looked up
in the ELF to discover the target function.
Another disadvantage of -fpic is that each function begins with a
sequence to calculate the value of the gp register, for example:
3c1c0004 lui gp,0x4
279c3384 addiu gp,gp,13188
0399e021 addu gp,gp,t9
Without using -fpic this sequence no longer appears at the start of each
function, reducing code size considerably.
This patch switches U-Boot from building with -fpic to building with
-fno-pic, in order to gain the benefits described above. The cost of
this is an extra step during the build process to extract relocation
data from the ELF & write it into a new .rel section in a compact
format, plus the added complexity of dealing with multiple types of
relocation rather than the single type that applied to the GOT. The
benefit is smaller, cleaner, more debuggable code. The relocate_code()
function is reimplemented in C to handle the new relocation scheme,
which also makes it easier to read & debug.
Taking maltael_defconfig as an example the size of u-boot.bin built
using the Codescape MIPS 2016.05-06 toolchain (gcc 4.9.2, binutils
2.24.90) shrinks from 254KiB to 224KiB.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: u-boot@lists.denx.de
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Tested-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
