Tom Rini [Sat, 8 Jun 2019 13:10:31 +0000 (09:10 -0400)]
Merge branch 'master' of git://git.denx.de/u-boot-tegra
The bulk of these changes are an effort to unify Tegra186 builds with
builds of prior 64-bit Tegra generations. On top of that there are
various improvements that allow data (such as the MAC address and boot
arguments) to be passed through from early firmware to the kernel on
boot.
Tom Rini [Sat, 8 Jun 2019 00:39:32 +0000 (20:39 -0400)]
spl: Correct SPL_SIZE_LIMIT Kconfig option
When introduced this limit was an int but was then changed to hex
without noting as much in the prompt nor changing existing users. Put
this back to an int.
Tom Rini [Fri, 7 Jun 2019 22:03:18 +0000 (18:03 -0400)]
Merge branch '2019-06-07-master-imports'
- Include Heinrich's series to move the i.MX board size check function
to be more widely available.
- Include Simon Goldschmidt's patch to make it possible to have a more
accurate SPL size check applied.
This adds a size check for SPL that can dynamically check generated
SPL binaries (including devicetree) for a size limit that ensures
this image plus global data, heap and stack fit in initial SRAM.
Since some of these sizes are not available to make, a new host tool
'spl_size_limit' is added that dumps the resulting maximum size for
an SPL binary to stdout. This tool is used in toplevel Makefile to
implement the size check on SPL binaries.
Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
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>
Eugen Hristev [Fri, 24 May 2019 06:38:10 +0000 (09:38 +0300)]
spl: at91: add support for SPL_AT91_MCK_BYPASS
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>
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>
ARM: tegra: Enable position independent build for 64-bit
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>
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>
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 86cf1c82850f ("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 a9819b9e33bd ("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>
ARM: tegra: Workaround UDC boot issues only if necessary
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>
Some devices may restrict access to the PMC to TrustZone software only.
Non-TZ software can detect this and use SMC calls to the firmware that
runs in the TrustZone to perform accesses to PMC registers.
Note that this also fixes reset_cpu() and the enterrcm command on
Tegra186 where they were previously trying to access the PMC at a wrong
physical address.
Based on work by Kalyani Chidambaram <kalyanic@nvidia.com> and Tom
Warren <twarren@nvidia.com>.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
ARM: tegra: Allow boards to override boot target devices
Boards may not support all the boot target devices in the default list
for Tegra devices. Allow a board to override the list and default to the
standard list only if the board hasn't specified one itself.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
The save_boot_params() function takes as its first four arguments the
first four registers. On 32-bit ARM these are r0, r1, r2 and r3, all of
which are 32 bits wide. However, on 64-bit ARM thene registers are x0,
x1, x2 and x3, all of which are 64 bits wide. In order to allow reusing
the save_boot_params() implementation on 64-bit ARM, change it to take
unsigned long parameters rather than the fixed size 32-bit integers.
This ensures that the correct values are passed.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
ARM: tegra: Guard pin controller code with a Kconfig symbol
Pin controller code is not relevant on all Tegra SoC generations, so
guard it with a Kconfig symbol that can be selected by the generations
that need it.
This is in preparation for unifying Tegra186 code with the code used on
older generations.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
ARM: tegra: Guard memory controller code with a Kconfig symbol
Memory controller code is not relevant on all Tegra SoC generations, so
guard it with a Kconfig symbol that can be selected by the generations
that need it.
This is in preparation for unifying Tegra186 code with the code used on
older generations.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
ARM: tegra: Guard GP pad control code with a Kconfig symbol
The GP pad control code is not relevant on all Tegra SoC generations, so
guard it with a Kconfig symbol that can be selected by the generations
that need it.
This is in preparation for unifying Tegra186 code with the code used on
older generations.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
ARM: tegra: Remove disp1 clock initialization on Tegra210
pll_c is not a valid parent for the disp1 clock, so trying to set it
will fail. Given that display is not used in U-Boot, remove the init
table entry so that disp1 will keep its default parent (clk_m).
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
ARM: tegra: Fix mux type for disp1 and disp2 clocks on Tegra210
On Tegra210 the parents for the disp1 and disp2 clocks are slightly
different from earlier chips. Only pll_p, pll_d_out0, pll_d2_out0 and
clk_m are valid parents (technically pll_d_out is as well, but U-Boot
doesn't know anything about it). Fix up the type name and the mux
definition.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
This function can be used to set the local MAC address for the default
Ethernet interface in its device tree node. The default interface is
identified by the "ethernet" alias.
One case where this is useful is for devices that store their MAC
address in a custom location. Once extracted, board code can store the
MAC address in U-Boot's control DTB so that it will automatically be
used by the Ethernet uclass.
Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Heiko Schocher [Mon, 27 May 2019 06:14:16 +0000 (08:14 +0200)]
cmd/led: check subcommand "list" instead "l"
current implementation for checking if "led list"
command is called checks only if "l" is passed to the
led command. This prevents switching leds with name
which starts also with a "l". So check for passing
"list".
While at it, also fix a typo in led command usage.
David Lechner [Wed, 29 May 2019 08:01:59 +0000 (10:01 +0200)]
configs/legoev3: define CONFIG_SKIP_LOWLEVEL_INIT
This adds a define for CONFIG_SKIP_LOWLEVEL_INIT in the legoev3 config.
On the EV3, U-Boot is loaded into RAM by another bootloader, so we
don't need the lowlevel init in U-Boot.
Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Adam Ford [Wed, 29 May 2019 14:36:58 +0000 (09:36 -0500)]
ARM: da850evm: Fix reading MAC from SPI
The MAC address is located at at the last 64K of SPI Flash, and
it's 6 bytes long. This patch corrects both the length and
starting byte of the MAC address.
Adam Ford [Wed, 29 May 2019 20:42:53 +0000 (15:42 -0500)]
arm: omap3: Manually initialize GPIO if OF_CONTROL doesn't
The commong initialization code manually initializes the GPIO
even when OF_CONTROL does it, so we can reduce the code size a
bit by not doing it manually when we have device tree support.
Using the omap3_logic board (dm3730), the sizes shrunk:
Before:
text data bss dec hex filename
561066 28596 116880 706542 ac7ee u-boot
55245 1605 1888 58738 e572 spl/u-boot-spl
After
text data bss dec hex filename
560898 28548 116872 706318 ac70e u-boot
55121 1557 1888 58566 e4c6 spl/u-boot-spl
Sekhar Nori [Thu, 30 May 2019 13:34:55 +0000 (19:04 +0530)]
ARM: davinci: SPL: fix BSS initialization
U-Boot README recommends initializing SDRAM in board_init_f(). DA850
was doing it as part of board_init_r() (through call to spl_board_init()
which calls arch_cpu_init() which calls da850_ddr_setup())
This worked fine till commit 15b8c7505819 ("davinci:
da850evm/omapl138-lcdk: Move BSS to SDRAM because SRAM is full") moved
BSS to SDRAM.
Functions like mmc_initialize() called in board_init_r() assume BSS is
available. Since SDRAM was not initialized when arch/arm/lib/crt0.S tried
to initialize BSS to 0, BSS is not initialized correctly.
Fix this by simply calling arch_cpu_init() from board_init_f(). Also move
preloader_console_init() there to help debug issues with board_init_r().
With this spl_board_init() is no longer needed, we remove it.
Tested using MMC/SD boot on OMAP-L138 LCDK board.
Tested-by: Adam Ford <aford173@gmail.com> #da850evm Signed-off-by: Sekhar Nori <nsekhar@ti.com> Tested-by: Peter Howard <phoward@gme.net.au> #omapl138_lcdk
Sekhar Nori [Thu, 30 May 2019 13:34:54 +0000 (19:04 +0530)]
ARM: davinci: omal138_lcdk: fix MMC boot breakage due to driver model conversion
commit 21af33ed0319 ("ARM: davinci: omapl138_lcdk: Enable DM_MMC")
wanted to enable DM_MMC only for U-Boot and not for SPL.
But CONFIG_DM_MMC is defined for SPL build too. Because of this
MMC device was not getting registered for SPL causing MMC/SD
boot breakage.
Instead use CONFIG_IS_ENABLED(DM_MMC) which will remain false until
CONFIG_SPL_DM_MMC is defined.
Tested-by: Adam Ford <aford173@gmail.com> #da850evm Signed-off-by: Sekhar Nori <nsekhar@ti.com> Tested-by: Peter Howard <phoward@gme.net.au> #omapl138_lcdk
Tom Rini [Wed, 5 Jun 2019 14:07:31 +0000 (10:07 -0400)]
Merge git://git.denx.de/u-boot-riscv
- Support Microchip MPFS Icicle board.
- Enable e1000 and nvme support for qemu.
- Enable PCI host ECAM generic driver for qemu.
- Increase the environment size to 128kB for qemu.
Maxime Jourdan [Tue, 4 Jun 2019 20:26:19 +0000 (22:26 +0200)]
video: meson: hdmi-supply regulator should be optional
Some boards don't have such a regulator, and don't need one to enable
HDMI display. Make it optional, fixing hdmi display for those boards.
Also surround the regulator code with a config check on DM_REGULATOR.
Reported-by: Mohammad Rasim <mohammad.rasim96@gmail.com> Signed-off-by: Maxime Jourdan <mjourdan@baylibre.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Tested-by: Mohammad Rasim <mohammad.rasim96@gmail.com>
Padmarao Begari [Tue, 28 May 2019 10:17:51 +0000 (15:47 +0530)]
riscv: Add Microchip MPFS Icicle board support
This patch adds Microchip MPFS Icicle board support.
For now, NS16550 serial driver is only enabled.
The Microchip MPFS Icicle defconfig by default builds
U-Boot for M-Mode with SMP support.
Bin Meng [Wed, 15 May 2019 15:42:59 +0000 (08:42 -0700)]
riscv: qemu: Enable e1000 and nvme support
Since we have added the PCI support to the 'virt' target, enable
e1000 and NVME as alternate network and storage devices for these
virtio based devices.
Karsten Merker [Sun, 5 May 2019 21:36:29 +0000 (23:36 +0200)]
riscv: increase the environment size for the qemu-riscv platform to 128kB
The existing default size of 4kB is too small as the default environment
has already nearly that size and defining a single additional environment
variable can exceed the available space.
Signed-off-by: Karsten Merker <merker@debian.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Igor Opaniuk [Mon, 3 Jun 2019 21:05:59 +0000 (00:05 +0300)]
video: mxsfb: add DM_VIDEO support
Extend the driver to build with DM_VIDEO enabled. DTS files
must additionally include 'u-boot,dm-pre-reloc' property in
soc and child nodes to enable driver binding to mxsfb device.
Signed-off-by: Igor Opaniuk <igor.opaniuk@toradex.com>
Igor Opaniuk [Mon, 3 Jun 2019 21:05:58 +0000 (00:05 +0300)]
video: mxsfb: refactor video_hw_init()
Refactor video_hw_init() function, and introduce an independent function
for the common procedure of initialization.
Currently video_hw_init() is only in charge of parsing configuration from
env("videomode") and filling struct GraphicPanel, and new
mxs_probe_common() does hw specific initialization (invocation of
mxs_lcd_init() etc.)
Signed-off-by: Igor Opaniuk <igor.opaniuk@toradex.com>
Igor Opaniuk [Wed, 29 May 2019 09:01:43 +0000 (09:01 +0000)]
splash: display splash in DM_VIDEO configurations
Currently for CONFIG_DM_VIDEO=y setting splashimage env variable doesn't
have any effect. Introduce a common function for both dm-video/lcd stacks,
that checks env("splashimage") and invokes bmp_display() accordingly.
For additional details please check discussion [1].
When a protocol is opened the open protocol information must be updated.
The key fields of the open protocol information records are ImageHandle,
ControllerHandle, and Attributes.
Consider the Attributes field when determining if an open protocol
information record has to be updated or a new one has to be created.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The UEFI specification requires that when a protocol is opened via
HandleProtocol() the agent handle is the image handle of the EFI firmware
(see chapter on EFI_BOOT_SERVICES.OpenProtocol()).
Let efi_handle_protocol() pass efi_root as agent handle to
efi_open_protocol().
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Vladimir Oltean [Thu, 30 May 2019 00:08:32 +0000 (03:08 +0300)]
cmd: mdio: Fix access to arbitrary PHY addresses
Alex reported the following:
"
I'm doing some MDIO work on a freescale/NXP platform and I bumped into
errors with this command:
=> mdio r emdio#3 5 3
Reading from bus emdio#3
"Synchronous Abort" handler, esr 0x8600000e
elr: ffffffff862b8000 lr : 000000008200cce4 (reloc)
...
mdio list does not list any PHYs currently because ethernet is using DM
and the interfaces are not probed at this time. The PHY does exist
on the bus though.
The above scenario works with this commit reverted: e55047ec51a662c12ed53ff543ec7cdf158b2137 cmd: mdio: Switch to generic
helpers when accessing the registers
The current code using generic helpers only works for PHYs that have
been registered and show up in bus->phymap and crashes for arbitrary
IDs. I find it useful to allow reading from other addresses over MDIO
too, certainly helpful for people debugging MDIO on various boards.
"
Fix this by reverting to use the raw MDIO bus operations in case there
is no PHY probed based on DT at the specified address.
This restores the old behavior for these PHYs, which means that the
newly introduced MMD-over-C22 helpers won't be available for them, but
at least they will be accessible again without crashing the system.
Fixes: commit e55047ec51a6 ("cmd: mdio: Switch to generic helpers when accessing the registers") Reported-by: Alex Marginean <alexm.osslist@gmail.com> Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Alex Marginean <alexm.osslist@gmail.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Bin Meng [Wed, 22 May 2019 07:09:46 +0000 (00:09 -0700)]
dm: net: macb: Implement link speed change callback
At present the link speed change callback is a nop. According to
macb device tree bindings, an optional "tx_clk" is used to clock
the ethernet controller's TX_CLK under different link speed.
In 10/100 MII mode, transmit logic must be clocked from a free
running clock generated by the external PHY. In gigabit GMII mode,
the controller, not the external PHY, must generate the 125 MHz
transmit clock towards the PHY.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Tested-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Thierry Reding [Mon, 20 May 2019 15:59:57 +0000 (17:59 +0200)]
net: eth-uclass: Support device tree MAC addresses
Add the standard Ethernet device tree bindings (imported from v5.0 of
the Linux kernel) and implement support for reading the MAC address for
Ethernet devices in the Ethernet uclass. If the "mac-address" property
exists, the MAC address will be parsed from that. If that property does
not exist, the "local-mac-address" property will be tried as fallback.
MAC addresses from device tree take precedence over the ones stored in
a network interface card's ROM.
Thierry Reding [Mon, 20 May 2019 15:59:56 +0000 (17:59 +0200)]
net: eth-uclass: Write MAC address to hardware after probe
In order for the device to use the proper MAC address, which can have
been configured in the environment prior to the device being registered,
ensure that the MAC address is written after the device has been probed.
For devices that are registered before the network stack is initialized,
this is already done during eth_initialize(). If the Ethernet device is
on a bus that is not initialized on early boot, such as PCI, the device
is not available at the time eth_initialize() is called, so we need the
MAC address programming to also happen after probe.
Acked-by: Joe Hershberger <joe.hershberger@ni.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
When uninstalling a protocol the following steps are needed:
* request all drivers to disconnect
* close protocol for all non-drivers
* check if any open instance of the protocol exists on the handle and
return EFI_ACCESS_DENIED in this case
* remove the protocol interface
By tort we tested for remaining open protocol instances already after
requesting drivers to disconnect.
With this correction the UEFI SCT II tests for UninstallProtocolInterface()
and ReinstallProtocolInterface are passed.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
projects / u-boot.git / log
