We currently have duplicate definitions for BOARD_SIZE_CHECK in Makefile
and arch/arm/mach-imx/Makefile.
Move the board size check from arch/arm/mach-imx/Makefile to Makefile.
Depending on the value of CONFIG_BOARD_SIZE_LIMIT an error like an error
like the following is thrown:
u-boot-dtb.imx exceeds file size limit:
limit: 503696 bytes
actual: 509720 bytes
excess: 6024 bytes
make: *** [Makefile:1051: u-boot-dtb.imx] Error 1
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Carve out function size_check from macro BOARD_SIZE_CHECK. This will allow
us to reuse the function for other file size checks.
Depending on the value of CONFIG_BOARD_SIZE_LIMIT an error like the
following is thrown:
u-boot-dtb.img exceeds file size limit:
limit: 409516 bytes
actual: 444346 bytes
excess: 34830 bytes
make: *** [Makefile:1212: u-boot-dtb.img] Error 1
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
In the UEFI context GUIDs are expected to be rendered in upper case.
The patch uses the formerly unused bit 1 of the parameter str_format
of function uuid_bin_to_str() to indicate if we need upper or lower case
output.
Function uuid_string() in vsprint.c is adjusted to correctly set the bit
depending on the print format code.
%pUb: 01020304-0506-0708-090a-0b0c0d0e0f10
%pUB: 01020304-0506-0708-090A-0B0C0D0E0F10
%pUl: 04030201-0605-0807-090a-0b0c0d0e0f10
%pUL: 04030201-0605-0807-090A-0B0C0D0E0F10
Up to this point only a diagnostic message in mount_ubifs() using '%pUB' is
concerned by the change. Further patches are needed to adjust the UEFI
subsystem.
A unit test is provided inside the ut_print command.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This allows to enable Ethernet and use driver for
Synopsys Ethernet QoS device
Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Synopsys GMAC 4.20 is used. And Phy mode for eval and disco is RMII
with PHY Realtek RTL8211 (RGMII)
We also support some other PHY config on stm32mp157c
PHY_MODE (MII,GMII, RMII, RGMII) and in normal,
PHY wo crystal (25Mhz and 50Mhz), No 125Mhz from PHY config
Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Called to configure Ethernet PHY interface selection and
configure clock selection in RCC Ethernet clock tree.
Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
ETHCK_K is the identifier the kernel clock for ETH in kernel
binding, selected by ETHKSELR / gated by ETHCKEN = BIT(7).
U-Boot driver need to use the same identifier, so change ETHCK
to ETHCK_K.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
Add 2 new checks:
- detect when USB TYPE-C cable is not plugged correctly.
In this case, GND and VBUS pins are connected but not CC1
and CC2 pins.
- detect is an USB Type-C charger supplies more than 3 Amps
which is not compliant with the USB Type-C specification
In these 2 situations, stop the boot process and let red led
blinks forever.
V cc1 | V cc2 | power supply | red led | console message
range (Volts) |range (Volts)| (Amps) | blinks |
--------------|-------------|--------------|---------|-----------------------------------
> 2.15 | < 0.2 | > 3 | for ever| USB TYPE-C charger not compliant with specification
[2.15 - 1.23[ | < 0.2 | 3 | NO | NO
[1.23 - 0.66[ | < 0.2 | 1.5 | 3 times | WARNING 1.5A power supply detected
[0.66 - 0] | < 0.2 | 0.5 | 2 times | WARNING 500mA power supply detected
< 0.2 | < 0.2 | | for ever| ERROR USB TYPE-C connection in unattached mode
> 0.2 | > 0.2 | | for ever| ERROR USB TYPE-C connection in unattached mode
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
This allows to enable WATCHDOG and WDT flags to
be able to reset the watchdog and to support watchdog driver
model.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
This patch adds independent watchdog support for stm32mp157c
in SPL.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
To make adding new entry easier, sort Kconfig entries in
alphabetical order.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Update env_get_location() to be able to save environment into
NOR (SPI_FLASH).
Series-cc: pde, cke, pch, uboot-stm32
Cover-letter:
Add saveenv support for STM32MP1
This series adds saveenv support for STM32MP1 on several boot
devices. STM32MP1 is able to boot on eMMC, sdcard and NOR
(NAND support is not fully supported).
On eMMC and sdcard, environment is saved in EXT4 partition
On NOR, environment is saved in a dedicated partition
On NAND, environment is saved in a UBI volume.
This series:
- enables NAND and NOR support on ev1 board
- enables ENV_IS_IN_SPI_FLASH, ENV_IS_IN_UBI, ENV_IS_IN_EXT4
flags
- fixes get_mtdparts()
- allows to override interface, device and partition for ext4
environment
- updates rule to set ENV_IS_NOWHERE value
- introduce ENV_IS_IN_DEVICE
END
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Add all relative flags needed by ENV_IS_IN_SPI_FLASH
Reserved a 256KB partition in NOR to save the U-Boot
environment.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
When ENV_IS_IN_UBI is enable, get_mtdparts is called before relocation.
During first get_mtdparts() call, mtdparts is not available in environment,
it can be retrieved by calling board_mtdparts_default(), but following
env_set() do nothing as we are before relocation. Finally mtdparts is
still not available in environment.
At second get_mtdparts() call, use_defaults is false, but mtdparts is still
not in environment and is NULL.
Remove use_defaults bool, only mtdparts criteria is useful.
Fixes: commit 5ffcd50612 ("mtd: Use default mtdparts/mtids when not defined
in the environment")
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
In case of several environment location support, env_get_location
is needed to select the correct location depending of the boot
device .
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Enable ENV_IS_IN_EXT4 and all relative flags to be able to
load/save environment in EXT4 partition.
This will allows to load/save environment on both sdcard and eMMC.
As for stm32mp15, bootfs has not the same partition number on sdcard
and on eMMC, we use "auto" key which allows to find the first
partition in device with bootable flag which is partition 4 on sdcard
and partition 2 on eMMC.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Introduce ENV_IS_IN_DEVICE to test if one the
CONFIG_ENV_IS_IN_ is defined and support the command
saveenv even if CONFIG_ENV_IS_NOWHERE is activated
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Allow U-Boot to get default environment for some boot mode
(USB for example), and to select storage location when it is
booting from flash device;
ENVL_NOWHERE is present in env_locations with other one.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
This allows to :
- select the current device to save the environment file
- select the correct EXT4 boot device instance
and partition to save the environment file.
For EXT4, device is mmc, device instance is 0 for sdcard or 1 for eMMC.
The partition is set to "auto" to select the first partition with
bootable flag.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
For platform which can boot on different device, this allows
to override interface, device and partition from board code.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
This patch configure the default value for mtdids and mtparts
dynamically according the presence of nor and nand in
the board device tree
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Christophe Kerello <christophe.kerello@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Add the necessary configuration to have NAND and NOR support on ev1 board
for BASIC boot (with SPL) or for TRUSTED boot (with TF-A).
STM32MP> nand info
Device 0: nand0, sector size 256 KiB
Page size 4096 b
OOB size 224 b
Erase size 262144 b
subpagesize 4096 b
options 0x00184200
bbt options 0x00060000
STM32MP> sf probe
SF: Detected mx66l51235l with page size 256 Bytes, erase size 64 KiB, total 64 MiB
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Without newline, the error message appears for non prgrammed OTP boards
looks messsy. Hence add it to look more clean.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Add support for Avenger96 board from Arrow Electronics based on STM32MP157
MPU. This board is one of the Consumer Edition (CE) boards of the 96Boards
family and has the following features:
SoC: STM32MP157AAC
PMIC: STPMIC1A
RAM: 1024 Mbyte @ 533MHz
Storage: eMMC v4.51: 8 Gbyte
microSD Socket: UHS-1 v3.01
Ethernet Port: 10/100/1000 Mbit/s, IEEE 802.3 Compliant
Wireless: WiFi 5 GHz & 2.4GHz IEEE 802.11a/b/g/n/ac
Bluetooth®v4.2 (BR/EDR/BLE)
USB: 2x Type A (USB 2.0) Host and 1x Micro B (USB 2.0) OTG
Display: HDMI: WXGA (1366x768)@ 60 fps, HDMI 1.4
LED: 4x User LED, 1x WiFi LED, 1x BT LED
More information about this board can be found in 96Boards website:
https://www.96boards.org/product/avenger96/
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
By default the configuration of the PMC is to have an external crystal
connected that requires driving on both XIN and XOUT pins.
The bypass configuration means that only XIN will be used, the SoC will not
do any driving, and the XIN needs to be provided with a proper signal.
This is the MOSCXTBY bit in the PMC main clock generator register.
The SPL needs to properly initialize the PMC registers before switching
to external clock signal and raising the clock to the cruise speed.
Also created Kconfig for this specific configuration.
By default this is disabled.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Support for managing the non-volatile attribute of UEFI variables
is added though we do not have a backend for persistence yet.
Error messages for changes of UEFI variables are provided.
UEFI boottime service implementations are corrected.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAlz3mYcACgkQxIHbvCwF
GsTNgw/8DSxiFXvOF6eTWd2POYfu9wjZXCcMtpsfuLA3b58AjF0VfYhoXgQoel1B
BnP6wzaIajIM8yafvia38EBloa2ZkBPjqUD/dtvs/hYe9x9kMCqLpsbOgHmjKF4b
X6w4j4OOvOaEuKnsi6faWmXfsOWA5laYz6/u1Ewau+0P5SMnt/0piVMqkLofFO1i
TcUzzn8MyfuCOu6UH+nqMZMguPaLkiCZX+aS6Q6tDfd5wfVRDtGTMGrMO/X42tLB
vqAgW6qRV8U4H08gBx8u2+xiO67soiH+7AVuhc+/6inMCPyAXBwVlr79YihNi75o
FOftPJ3hcJ+YkLNSVpwayKzrPa9GCCB2PGVDPCWQMwejIgQMkLPq2xRbFCPmLC4N
WM4E11lqLSDL4xUTqhn+bJfRofaIpV9t79VVNAOkwHD7Wj0mnOVWjnpY+bB3n3hN
LAneXPiUoQXSy9d3F2dd6J3emQMSTK4TPchGwWyfFwTe8VszynvHbWU8AGyCjbop
/XAlBHYfuTLjvB+j8WLfua7ocmMtvIAU3CLC8OJ6bvga/VIPtG17rGAiQ1RP9W0u
JZ4QKOnU2M8NiOrq45GIQEUV/UocNDJ2g5fZshLIzNk1it90RFEQ7kR6WYZZg4Hq
zHSVjKijqxUcqKfQbSukJInDYI8xS1F+jKgB3HdGCg49ZZb/y74=
=mCc9
-----END PGP SIGNATURE-----
Merge tag 'efi-2019-07-rc4-2' of git://git.denx.de/u-boot-efi
Pull request for UEFI sub-system for v2019.07-rc4-2
Support for managing the non-volatile attribute of UEFI variables
is added though we do not have a backend for persistence yet.
Error messages for changes of UEFI variables are provided.
UEFI boottime service implementations are corrected.
Add an "ethernet" alias that points to the default network interface,
which is the built-in EQoS on Jetson TX2.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Recent versions of DTC have checks for PCI host bridge device tree nodes
that are named something other than "pci" or "pcie". Fix all occurrences
of such nodes for Tegra boards to avoid potential warnings from DTC.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
If early firmware initialized the display hardware and the display
controllers are scanning out a framebuffer (e.g. a splash screen), make
sure to pass information about the memory location of that framebuffer
to the kernel before booting to avoid the kernel from using that memory
for the buddy allocator.
This same mechanism can also be used in the kernel to set up early SMMU
mappings and avoid SMMU faults caused by the display controller reading
from memory for which it has no mapping.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
If early firmware initialized the display hardware and the display
controllers are scanning out a framebuffer (e.g. a splash screen), make
sure to pass information about the memory location of that framebuffer
to the kernel before booting to avoid the kernel from using that memory
for the buddy allocator.
This same mechanism can also be used in the kernel to set up early SMMU
mappings and avoid SMMU faults caused by the display controller reading
from memory for which it has no mapping.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Pass the ethernet MAC address to the kernel upon boot. This passes both
the local-mac-address property (as passed to U-Boot from cboot) and the
currently set MAC address via the mac-address property. The latter will
only be set if it is different from the address that was already passed
via the local-mac-address property.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Pass the ethernet MAC address to the kernel upon boot. This passes both
the local-mac-address property (as passed to U-Boot from cboot) and the
currently set MAC address via the mac-address property. The latter will
only be set if it is different from the address that was already passed
via the local-mac-address property.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Note that U-Boot is always chainloaded from cboot starting with L4T
release 28. cboot always loads U-Boot to a fixed address, so making
the builds position independent isn't strictly necessary. However,
position independent builds can be convenient because if U-Boot is
ever loaded to an address different from its link address, it will
still be able to boot.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Read the boot arguments passed by cboot via the /chosen/bootargs
property and store it in the cbootargs environment variable.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This function will attempt to look up an Ethernet address in the DTB
that was passed in from cboot. It does so by first trying to locate the
default Ethernet device for the board (identified by the "ethernet"
alias) and if found, reads the "local-mac-address" property. If the
"ethernet" alias does not exist, or if it points to a device tree node
that doesn't exist, or if the device tree node that it points to does
not have a "local-mac-address" property or if the value is invalid, it
will fall back to the legacy mechanism of looking for the MAC address
stored in the "nvidia,ethernet-mac" or "nvidia,ether-mac" properties of
the "/chosen" node.
The MAC address is then written to the default Ethernet device for the
board (again identified by the "ethernet" alias) in U-Boot's control
DTB. This allows the device driver for that device to read the MAC
address from the standard location in device tree.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This is easier to deal with and works just as well for this simple
function.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Tegra186 build are currently dealt with in very special ways, which is
because Tegra186 is fundamentally different in many respects. It is no
longer necessary to do many of the low-level programming because early
boot firmware will already have taken care of it.
Unfortunately, separating Tegra186 builds from the rest in this way
makes it difficult to share code with prior generations of Tegra. With
all of the low-level programming code behind Kconfig guards, the build
for Tegra186 can again be unified.
As a side-effect, and partial reason for this change, other Tegra SoC
generations can now make use of the code that deals with taking over a
boot from earlier bootloaders. This used to be nvtboot, but has been
replaced by cboot nowadays. Rename the files and functions related to
this to avoid confusion. The implemented protocols are unchanged.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Commit 86cf1c8285 ("configs: Migrate CONFIG_NR_DRAM_BANKS") reduced
the number of DRAM banks supported by U-Boot from 1026 to 8 on P2771-000
boards.
However, as explained in commit a9819b9e33 ("ARM: tegra: p2771-000:
increase max DRAM bank count"), the platform can have a large number of
unusable chunks of memory (up to 1024), so a total of 1026 DRAM banks
are needed to describe the worst-case situation.
In practice the number of DRAM banks needed will typically be much
lower, but we should be prepared to properly deal with the worst case.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Resetting the USB device controller on boot is only necessary if the SoC
actually has a UDC controller and U-Boot enables support for it. All the
Tegra boards support UDC via the ChipIdea UDC driver, so make the UDC on
boot workaround depend on the ChipIdea UDC driver.
This prevents a crash on Tegra186 which does not have the ChipIdea UDC.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
