Rick Chen [Tue, 2 Apr 2019 07:56:39 +0000 (15:56 +0800)]
riscv: Add a SYSCON driver for Andestech's PLIC
The Platform-Level Interrupt Controller (PLIC)
block holds memory-mapped claim and pending registers
associated with software interrupt. It is required
for handling IPI.
Lukas Auer [Sun, 17 Mar 2019 18:28:39 +0000 (19:28 +0100)]
riscv: do not rely on hart ID passed by previous boot stage
RISC-V U-Boot expects the hart ID to be passed to it via register a0 by
the previous boot stage. Machine mode firmware such as BBL and OpenSBI
do this when starting their payload (U-Boot) in supervisor mode. If
U-Boot is running in machine mode, this task must be handled by the boot
ROM. Explicitly populate register a0 with the hart ID from the mhartid
CSR to avoid possible problems on RISC-V processors with a boot ROM that
does not handle this task.
Lukas Auer [Sun, 17 Mar 2019 18:28:37 +0000 (19:28 +0100)]
riscv: add support for multi-hart systems
On RISC-V, all harts boot independently. To be able to run on a
multi-hart system, U-Boot must be extended with the functionality to
manage all harts in the system. All harts entering U-Boot are registered
in the available_harts mask stored in global data. A hart lottery system
as used in the Linux kernel selects the hart U-Boot runs on. All other
harts are halted. U-Boot can delegate functions to them using
smp_call_function().
Every hart has a valid pointer to the global data structure and a 8KiB
stack by default. The stack size is set with CONFIG_STACK_SIZE_SHIFT.
Lukas Auer [Sun, 17 Mar 2019 18:28:36 +0000 (19:28 +0100)]
riscv: save hart ID in register tp instead of s0
The hart ID passed by the previous boot stage is currently stored in
register s0. If we divert the control flow inside a function, which is
required as part of multi-hart support, the function epilog may not be
called, clobbering register s0. Save the hart ID in the unallocatable
register tp instead to protect the hart ID.
Lukas Auer [Sun, 17 Mar 2019 18:28:35 +0000 (19:28 +0100)]
riscv: delay initialization of caches and debug UART
Move the initialization of the caches and the debug UART until after
board_init_f_init_reserve. This is in preparation for SMP support, where
code prior to this point will be executed by all harts. This ensures
that initialization will only be performed once on the main hart running
U-Boot.
Lukas Auer [Sun, 17 Mar 2019 18:28:34 +0000 (19:28 +0100)]
riscv: implement IPI platform functions using SBI
The supervisor binary interface (SBI) provides the necessary functions
to implement the platform IPI functions riscv_send_ipi() and
riscv_clear_ipi(). Use it to implement them.
This adds support for inter-processor interrupts (IPIs) on RISC-V CPUs
running in supervisor mode. Support for machine mode is already
available for CPUs that include the SiFive CLINT.
Lukas Auer [Sun, 17 Mar 2019 18:28:33 +0000 (19:28 +0100)]
riscv: import the supervisor binary interface header file
Import the supervisor binary interface (SBI) header file from Linux
(arch/riscv/include/asm/sbi.h). The last change to it was in commit 6d60b6ee0c97 ("RISC-V: Device, timer, IRQs, and the SBI").
Lukas Auer [Sun, 17 Mar 2019 18:28:32 +0000 (19:28 +0100)]
riscv: add infrastructure for calling functions on other harts
Harts on RISC-V boot independently, U-Boot is responsible for managing
them. Functions are called on other harts with smp_call_function(),
which sends inter-processor interrupts (IPIs) to all other available
harts. Available harts are those marked as available in the device tree
and present in the available_harts mask stored in global data. The
available_harts mask is used to register all harts that have entered
U-Boot. Functions are specified with their address and two function
arguments (argument 2 and 3). The first function argument is always the
hart ID of the hart calling the function. On the other harts, the IPI
interrupt handler handle_ipi() must be called on software interrupts to
handle the request and call the specified function.
Functions are stored in the ipi_data data structure. Every hart has its
own data structure in global data. While this is not required at the
moment (all harts are expected to boot Linux), this does allow future
expansion, where other harts may be used for monitoring or other tasks.
Hannes Schmelzer [Fri, 29 Mar 2019 08:54:05 +0000 (09:54 +0100)]
net: phy: implement fallback mechanism for negative phy adresses
Negative phy-addresses can occour if the caller function was not able to
determine a valid phy address (from device-tree for example). In this
case we catch this here and search for ANY phy device on the given mdio-
bus.
In the extended text input protocol CTRL-A - CTRL-Z have to be signaled as
Unicode characters a-z or A-Z depending on the shift state and not as 0x01
to 0x1a.
Update Python unit test.
This patch is required for using the EFI shell `edit` command.
EFI shell command edit uses the SetInfo() methods to unset the read only
attribute of the file to be edited. So let efi_file_setinfo() return
success in this case.
Return an error if the function is called for to rename or resize a file
as we do not support this yet.
The EFI shell expects that after opening a file with EFI_FILE_MODE_CREATE
GetInfo() succeeds. Up to now we do not actually create the file when
method Open() of the EFI_FILE_PROTOCOL is called.
If method Open() of the EFI_FILE_PROTOCOL is called with
EFI_FILE_MODE_CREATE and the file does not yet exist, call fs_write() with
a buffer size of zero to actually create the file.
efi_loader: debug output file handle in efi_file_open()
For debugging it is helpful to know the address of the file handle created
by the Open() method of the EFI file protocol. So let's write it with
EFI_PRINT().
efi_loader: variables PlatformLang and PlatformLangCodes
Since TianoCore EDK2 commit d65f2cea36d1 ("ShellPkg/CommandLib: Locate
proper UnicodeCollation instance") in edk2 the UEFI Shell crashes if EFI
variable PlatformLang is not defined.
As this variable is anyway prescribed in the UEFI 2.7 spec let's define it
to L"en-US". Use the same value for PlatformLangCodes that defines the list
of all supported languages.
efi_loader: parameter checks in StartImage and Exit()
Add parameter checks in the StartImage() and Exit() boottime services:
- check that the image handle is valid and has the loaded image protocol
installed
- in StartImage() record the current image
- in Exit() check that the image is the current image
AKASHI Takahiro [Thu, 11 Oct 2018 11:09:58 +0000 (04:09 -0700)]
efi_loader: set image_base and image_size to correct values
Currently, image's image_base points to an address where the image was
temporarily uploaded for further loading. Since efi_loader relocates
the image to final destination, image_base and image_size should reflect
that.
This bug was detected in UEFI SCT, "Loaded Image Protocol Test - test 2,"
which shows that 'Unload' function doesn't fit into a range suggested by
image_base and image_size.
Changes in this patch also includes:
* reverts a patch, "efi_loader: save image relocation address
and size" since newly added fields are no longer needed.
* copy PE headers as well since those information will be needed
for module loading, in particular, at gurb.
(This bug was reported by Heinrich.)
Reported-by: Heinrich Schuchardt <[email protected]> Signed-off-by: AKASHI Takahiro <[email protected]>
Rebase patch.
Remove unused fields from struct efi_loaded_image_obj.
efi_loader: release file buffer after loading image
Commit 0e18f584de59 ("efi_loader: LoadImage: always allocate new pages")
ensured that whether we load an image from file or from memory we end up
with the same number of newly allocated buffers. But essentially we ended
up with one buffer too many in both cases:
efi_load_pe() copies and rebases the UEFI image.
We do not need the buffer with the file contents afterwards.
Fixes: 0e18f584de59 ("efi_loader: LoadImage: always allocate new pages") Signed-off-by: Heinrich Schuchardt <[email protected]>
Thomas Petazzoni [Sat, 30 Mar 2019 14:29:23 +0000 (15:29 +0100)]
tools/Makefile: build host tools with -std=gnu99
Parts of the code are using C99 constructs (such as variables declared
inside loops), but also GNU extensions (such as typeof), so using
-std=gnu99 is necessary to build with older versions of gcc that don't
default to building with gnu99.
It fixes the following build failure:
./tools/../lib/crc16.c: In function "crc16_ccitt":
./tools/../lib/crc16.c:70:2: error: "for" loop initial declarations are only allowed in C99 mode
for (int i = 0; i < len; i++)
^
./tools/../lib/crc16.c:70:2: note: use option -std=c99 or -std=gnu99 to compile your code
Neil Armstrong [Wed, 3 Apr 2019 11:46:37 +0000 (13:46 +0200)]
configs: khadas_vim2: Fix defconfig
The Khadas VIM2 defconfig was missing the USB PHY config and
two other misc configs to setup dram banks and call misc_init_r.
Align it on the other Amlogic SoC based boards defconfig.
The FEC ETH driver switched to PHY GPIO reset performed with data defined
in DTS.
For the HSC|DDC boards the GPIO reset signal is active low and hence the
wrong DTS description must be changed (otherwise the reset for ETH is not
properly setup).
Jagan Teki [Thu, 28 Mar 2019 08:16:11 +0000 (13:46 +0530)]
clk: sunxi: a10: Add CLK_AHB_GMAC
CLK_AHB_GMAC was suppose to be part of previous commit
"clk: sunxi: Implement A10 EMAC clocks" add it so-that
we can get rid of sunxi_set_gate warning on boot message.
Fabio Estevam [Wed, 27 Mar 2019 23:03:39 +0000 (20:03 -0300)]
pico-imx7d: README: Recommend the usage of a USB hub
Since commit 9e3c0174da842 ("pico-imx7d: Add LCD support") we started to
notice some hangs in U-Boot.
There is not an issue on such commit per se, but due to the LCD support
the current drawn is increased and this may cause issues when powering
pico-imx7d-pi from USB.
Some computers may be a bit strict with USB current draw and will
shut down their ports if the draw is too high.
The solution for that is to use an externally powered USB hub between the
board and the host computer.
Jagan Teki [Thu, 21 Mar 2019 08:35:53 +0000 (14:05 +0530)]
configs: icorem6: Use imx6 cratch register for bootcount
SRAM address used for bootcount on exiting code is erasing
previous count value when system reset from Linux. So use
the dedicated imx6 scratch register, GPR2 to preserve the
contents even if the system reset from Linux.
Fixes: 4eb9aa39350e ("configs: imx6qdl_icore_mmc: Enable watchdog and bootcounter") Signed-off-by: Michael Trimarchi <[email protected]> Signed-off-by: Jagan Teki <[email protected]> Tested-by: Shyam Saini <[email protected]> Reviewed-by: Stefano Babic <[email protected]>
Adam Ford [Sun, 3 Mar 2019 22:22:45 +0000 (16:22 -0600)]
ARM: imx6q_logic: Enable UUID support
With UUID support, the root can now point to UUID. This makes
swiching between mmc 0 and mmc 1 easier by simplying changing
mmcdev between 0 and 1. From there, the scripts handle the rest.
Fabio Estevam [Thu, 21 Mar 2019 13:59:06 +0000 (10:59 -0300)]
pico-imx6ul: Fix eMMC boot after DM_MMC conversion
After the DM_MMC conversion the following eMMC boot error is observed:
U-Boot SPL 2019.04-rc4 (Mar 20 2019 - 18:53:28 +0000)
Trying to boot from MMC1
MMC Device 0 not found
spl: could not find mmc device 0. error: -19
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
This happens because the SPL code does not initialize the SDHC pins
and clock.
Fix it by moving the original eMMC initialization from U-Boot proper
to SPL.
Tom Rini [Sun, 31 Mar 2019 11:25:00 +0000 (07:25 -0400)]
Merge tag 'rockchip-fixes-for-2019.04' of git://git.denx.de/u-boot-rockchip
Last-minute fixes for Rockchip for 2019.04:
- reverts the deprecation of the 'download-key' detection
(with a full solution pending for the next release)
- applies a temporary fix for the 32bit pinctrl registers on the RK3288
Marek Vasut [Sat, 30 Mar 2019 06:43:55 +0000 (07:43 +0100)]
ARM: rmobile: rcar-gen2: Activate bootm_size
Commit d245059ff797 ("ARM: rmobile: rcar-gen3: Activate bootm_size")
only fixed the superfluous CONFIG_SYS_BOOTMAPSZ for R-Car Gen3, even
though it listed all affected boards. Apply the same fix to Gen2.
Marek Vasut [Sat, 30 Mar 2019 05:10:49 +0000 (06:10 +0100)]
ARM: rmobile: alt: Remove R8A7794_ETHERNET_B
The R8A7794_ETHERNET_B config option is unused and based on the
description, this is a setting which should be fully done on a
DT level instead. Remove this config option.
Matthias Brugger [Thu, 28 Mar 2019 13:47:39 +0000 (14:47 +0100)]
RPi: Add mbrugger as board maintainer
I took over maintainership from Alex Graf with commit 3157bbfa18 ("rpi: Make Matthias maintainer")
But I forgot to update the board maintainer file.
This patch adds myself to the game.
Andrew F. Davis [Tue, 26 Mar 2019 15:12:01 +0000 (10:12 -0500)]
configs: ti: Move FIT image load address to avoid overwrite
The FIT image is loaded to 0x8700_0000 followed by extracting from that
several large images also into the 0x8x00_0000 range. Large images
can end up overwriting the FIT image as it is being extracted from.
Move the FIT load address clear out to 0x9000_0000, this will require
a board to have at least 256MB of DRAM, if less then more careful
planning will be required for that platform.
BOUGH CHEN [Tue, 26 Mar 2019 06:24:17 +0000 (06:24 +0000)]
mmc: correct the HS400 initialization process
After the commit b9a2a0e2e9c0 ("mmc: Add support for downgrading
HS200/HS400 to HS mode"), it add a parameter in mmc_set_card_speed()
which indicates that the HS200/HS400 to HS downgrade is happening.
During the HS400 initialization, first select to HS200, and config
the related clock rate, then downgrade to HS mode. So here also need
to config the downgrade value to be true for two reasons. First,
make sure in the function mmc_set_card_speed(), after switch to HS
mode, first config the clock rate, then read the EXT_CSD, avoid
receiving data of EXT_CSD in HS mode at 200MHz. Second, after issue
the MMC_CMD_SWITCH command, it need to wait a bit then switch bus
properties.
Test on i.MX8QM MEK board, some Micron eMMC will stuck in transfer
mode in this case, and USDHC will never get data transfer complete
status, cause the uboot hang.
Tom Rini [Fri, 29 Mar 2019 13:21:30 +0000 (09:21 -0400)]
Merge tag 'efi-2019-04-rc5-2' of git://git.denx.de/u-boot-efi
Pull request for UEFI system for v2019.04-rc5-2
This patch series contains a bug fix for a double free in a UEFI unit
test. The other patches are documentation only (except for the definition
of two additional constants).
David Wu [Tue, 12 Feb 2019 11:51:51 +0000 (19:51 +0800)]
pinctrl: rockchip: Add 32bit writing function for rk3288 gpio0 pinctrl
There are no higher 16 writing corresponding bits for pmu_gpio0's
iomux/drive/pull at rk3288, need to read the value from register
firstly. Add the flag to distinguish it from normal registers.
Philipp Tomsich [Fri, 29 Mar 2019 08:21:13 +0000 (09:21 +0100)]
Revert "rockchip: Drop call to rockchip_dnl_mode_check() for now"
Due to a final resolution not coming up in time for 2019.04 and
following the consensus on the discussion, we'll keep this around
for 2019.04 after all.
Tom Rini [Fri, 29 Mar 2019 01:44:49 +0000 (21:44 -0400)]
Merge tag 'arc-last-minute-for-2019.04' of git://git.denx.de/u-boot-arc
This is last minute change which fixes problems in runtime on
AXS10x board caused by some changes in NAND framework and
tiny documentation improvement.
Anyways NAND flash storage was never really used on the board for various
reasons and now we decided to drop it for good.
Note this change only touches 1 ARC board so that should be safe for others.
As usual - build tested in TravisCI, see
https://travis-ci.org/abrodkin/u-boot/builds/512041342
Jernej Skrabec [Sun, 24 Mar 2019 18:26:40 +0000 (19:26 +0100)]
sunxi: video: HDMI: Fix clock setup
Currently, HDMI driver doesn't consider minimum and maximum allowed rate
of pll3 (video PLL). It works most of the time, but not always.
Consider monitor with resolution 1920x1200, which has pixel clock rate
of 154 MHz. Current code would determine that pll3 rate has to be set to
154 MHz. However, minimum supported rate is 192 MHz. In this case video
output just won't work.
The reason why the driver is written in the way it is, is that at the
time HDMI PHY and clock configuration wasn't fully understood. But now
we have needed knowledge, so the issue can be fixed.
With this fix, clock configuration routine uses full range (1-16) for
clock divider instead of limited one (1, 2, 4, 11). It also considers
minimum and maximum allowed rate for pll3.
Eugeniy Paltsev [Wed, 27 Mar 2019 13:53:43 +0000 (16:53 +0300)]
ARC: AXS10x: drop NAND support
On AXS10x boards we have non-standard NAND controller
which was never really used a lot as there're other much more
convenient [as they are standard & removable] persistent media
like SD-card and USB mass storage.
Moreover after recent changes we face with some NAND controller
runtime issues. So instead of keeping support of yet another
non-standard peripheral we're dropping its support for good.
Patrick Delaunay [Wed, 27 Feb 2019 14:20:38 +0000 (15:20 +0100)]
Convert CONFIG_ENV_SPI_* to Kconfig
This converts the following to Kconfig:
CONFIG_ENV_SPI_BUS
CONFIG_ENV_SPI_CS
CONFIG_ENV_SPI_MAX_HZ
CONFIG_ENV_SPI_MODE
Most of time these value are not needed, CONFIG_SF_DEFAULT
with same value is used, so I introduced CONFIG_USE_ENV_SPI_*
to force the associated value for the environment.
Define the function board_spi_cs_gpio only when needed,
only called in drivers/spi/mxc_spi.c.
That avoid compilation issue for tqma6s_wru4_mmc_defconfig
when CONFIG_SF_DEFAULT_BUS and CONFIG_SF_DEFAULT_CS are not
defined (CMD_SF not defined) after migration in KConfig.
Patrick Delaunay [Wed, 27 Feb 2019 14:20:34 +0000 (15:20 +0100)]
exynos: replace CONFIG_ENV_SPI_BASE by CONFIG_SYS_SPI_BASE
Replace CONFIG_ENV_SPI_BASE by the better CONFIG_SYS_SPI_BASE
(it is not the location for environment but the location for U-Boot)
and, as it is the only platform with use this define, remove
it from whitelist.
Tom Rini [Mon, 25 Mar 2019 21:26:38 +0000 (17:26 -0400)]
Merge branch '2019-03-25-master-imports'
- 3 bugfixes:
- mmc: Align MMC_TRACE with tiny printf
- scripts/Makefile.extrawarn: Silence more DTC warnings
- rsa: check that pointer checksum isn't NULL before using it
Marek Vasut [Mon, 18 Mar 2019 22:43:10 +0000 (23:43 +0100)]
mmc: tmio: Clamp SD_SECCNT to 16bit values on 16bit IP
On 16bit variants of the TMIO SD IP, the SECCNT register can only be
programmed to 16bit values, while on the 32bit and 64bit variants it
can be programmed to 32bit values. The SECCNT register indicates the
maximum number of blocks in a continuous transfer. Hence, limit the
maximum continuous transfer block count to 65535 blocks on 16bit
variants of the TMIO IP and to BIT(32)-1 blocks on 32bit and 64bit
variants.