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>
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.
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>
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>
When trying to open a protocol exclusively attached drivers have to be
removed. This removes entries in the open protocol information linked list
over which we are looping. As additionally child controllers may have been
removed the only safe thing to do is to restart the loop over the linked
list when a driver is removed.
By observing the return code of DisconnectController() we can eliminate a
loop.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
efi_loader: factor out efi_check_register_notify_event()
The code to check if a registration key is a valid key returned by
RegisterProtocolNotify() can be reused. So let us factor it out into a new
function efi_check_register_notify_event().
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
efi_loader: correct notification of protocol installation
When a protocol is installed the handle should be queued for the
registration key of each registered event. LocateHandle() should return the
first handle from the queue for the registration key and delete it from the
queue.
Implement the queueing.
Correct the selftest.
With the patch the UEFI SCT tests for LocateHandle() are passed without
failure.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tom Rini [Fri, 31 May 2019 11:17:09 +0000 (07:17 -0400)]
Merge tag 'rockchip-for-v2019.07-rc3' of git://git.denx.de/u-boot-rockchip
- some fix for rk3399-puma;
- rockchip script make_fit_atf.py cleanup
- Enable TPL for rk3399 orangepi and nanopi4;
- add support for rk3399 boards: Nanopi NEO4, Rockpro64, Rock PI 4;
Tom Rini [Fri, 31 May 2019 11:16:28 +0000 (07:16 -0400)]
Merge tag 'u-boot-amlogic-20190531' of git://git.denx.de/u-boot-amlogic
- Sync DT with Linux 5.2-rc1 for G12A
- Add USB clock support that was introduced in 5.2-rc1 bindings
- Add currently in-review for Linux eMMC & USB DT for G12A in -u-boot.dtsi
- Fix PHY routing to external PHY when chainloading from a misconfigred bootloader
- Remove useless PHY GPIO reset from q200 board file
- Enable USB support for Amlogic U200 reference board
Neil Armstrong [Tue, 28 May 2019 08:50:38 +0000 (10:50 +0200)]
ARM: dts: Add missing DT for Meson G12A support
The following DT nodes in the process on review for Linux 5.3,
until Linux 5.3 is tagged, add the missing DT nodes in u-boot specific
DTSI files that will be dropped when the v5.3-rc1 DT is synced again.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Jagan Teki [Fri, 17 May 2019 10:29:41 +0000 (15:59 +0530)]
rockchip: rk3399: Add Rock PI 4 support
Add initial support for Rock PI 4 board.
Specification
- Rockchip RK3399
- LPDDR4
- eMMC
- SD card slot
- RTL8211E 1Gbps
- HDMI In/Out, DP, MIPI DSI/CSI
- PCIe M.2
- USB 2.0, USB-3.0
- USB C Type
Commit details of rk3399-rock-pi-4.dts sync from Linux 5.1-rc2:
"arm64: dts: rockchip: add ROCK Pi 4 DTS support"
(sha1: 1b5715c602fda7b812af0e190eddcce2812e5417)
Signed-off-by: Akash Gajjar <akash@openedev.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jagan Teki [Fri, 17 May 2019 10:29:40 +0000 (15:59 +0530)]
rockchip: rk3399: Add Rockpro64 board support
Add initial support for Rockpro64 board.
Specification
- Rockchip RK3399
- 2/4GB Dual-Channel LPDDR3
- SD card slot
- eMMC socket
- 128Mb SPI Flash
- Gigabit ethernet
- PCIe 4X slot
- WiFI/BT module socket
- HDMI In/Out, DP, MIPI DSI/CSI, eDP
- USB 3.0, 2.0
- USB Type C power and data
- GPIO expansion ports
- DC 12V/2A
Commit details of rk3399-rockpro64.dts sync from Linux 5.1-rc2:
"arm64: dts: rockchip: rockpro64 dts add usb regulator"
(sha1: 6db644c79c8d45d73b56bc389aebd85fc3679beb)
'Akash' has sent an initial patch before, so I keep him as board
maintainer and I'm co-maintainer based on our conversation.
Signed-off-by: Akash Gajjar <akash@openedev.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
This patch cleans up make_fit_atf.py in the following way:
* Fix all issues reported by pylint
* Move copyright notice from file-to-generate to script
* Fix of-by-one bugs in loadables property
* Remove commented-out (dead) code.
Besides the bugfix no intended changes.
Tested on RK3399-Q7 with TF-A v2.1 as BL31.
Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
rockchip: clk: rk3399: allow requests for all UART clocks
This patch adds the rate for UART1 and UART3 the same way
as already implemented for UART0 and UART2.
This is required for boards, which have their console output
on these UARTs.
Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The RK3399 SPL does not use a pinctrl driver to setup the UART pins.
Instead it works based on config macros, which set the base address
of the actual UART block.
Currently the RK3399 SPL support UART0 and UART2.
This patch adds UART3 in the same way as UART0.
Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
This patch adds the missing GRF bit definitions for UART3 on the RK3399.
Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
rockchip: rk3399-puma: Move ENV_OFFSET to end of SPI NOR.
Puma SoMs have a 4 MB SPI NOR flash.
Therefore we can move the environment to the end of the flash
(4 MiB - 16 kiB) in order to not overlap with SPL.
Reported-by: Jakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com> Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
AKASHI Takahiro [Fri, 24 May 2019 05:10:37 +0000 (14:10 +0900)]
fs: fat: allocate a new cluster for root directory of fat32
Contrary to fat12/16, fat32 can have root directory at any location
and its size can be expanded.
Without this patch, root directory won't grow properly and so we will
eventually fail to add files under root directory. Please note that this
can happen even if you delete many files as deleted directory entries
are not reclaimed but just marked as "deleted" under the current
implementation.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
AKASHI Takahiro [Fri, 24 May 2019 05:10:36 +0000 (14:10 +0900)]
fs: fat: flush a directory cluster properly
When a long name directory entry is created, multiple directory entries
may be occupied across a directory cluster boundary. Since only one
directory cluster is cached in a directory iterator, a first cluster must
be written back to device before switching over a second cluster.
Without this patch, some added files may be lost even if you don't see
any failures on write operation.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
AKASHI Takahiro [Fri, 24 May 2019 05:10:35 +0000 (14:10 +0900)]
fs: fat: write to non-cluster-aligned root directory
With the commit below, fat now correctly handles a file read under
a non-cluster-aligned root directory of fat12/16.
Write operation should be fixed in the same manner.
For bcm7445 and bcm7260, this patch enables CONFIG_DM_MMC and updates
the bcmstb SDHCI driver to use the new driver model. This allows
removal of SDHCI configuration handling from bcmstb.c, and eliminates
a board removal compile warning.
Signed-off-by: Thomas Fitzsimmons <fitzsim@fitzsim.org> Reviewed-by: Stefan Roese <sr@denx.de>
This board still doesn't select CONFIG_DM and seems to be umaintained.
As it makes progress on modernizing several DaVinci drivers more
difficult and the maintainer has not expressed interest in updating
it, this patch proposes to remove it.
This board still doesn't select CONFIG_DM and seems to be umaintained.
As it makes progress on modernizing several DaVinci drivers more
difficult and the maintainer has not expressed interest in updating
it, this patch proposes to remove it.
This board still doesn't select CONFIG_DM and seems to be umaintained.
As it makes progress on modernizing several DaVinci drivers more
difficult and the maintainer has not expressed interest in updating
it, this patch proposes to remove it.
This board still doesn't select CONFIG_DM and seems to be umaintained.
As it makes progress on modernizing several DaVinci drivers more
difficult and the maintainer has not expressed interest in updating
it, this patch proposes to remove it.
projects / u-boot.git / log