Import the device tree files from kernel 5.0-rc6 in preparation
for driver model conversion.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Otavio Salvador <otavio@ossystems.com.br>
The Ethernet controller is not able to initialise correctly without the
pinctrl driver.
This config setting was enabled in the initial version of this file,
but was removed by a savedefconfig resync because the parameter did not
actually exist at that point.
Fixes: 1bac199e8c ("configs: Resync with savedefconfig")
Signed-off-by: Chris Spencer <christopher.spencer@sea.co.uk>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Fix an error with the serial communication on boards with a very small
UART buffer which leads to a stalled system.
Provide an X86 reset driver for the UEFI runtime.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAlyGptwACgkQxIHbvCwF
GsSqfA//dksWFGNu1y2qdOjItq5wb/sEIVuL/C+5EV672KILDLgmPssJ4IgjbxG+
KfZF6xj+1uWvSH8d7Yyz9zUvNRlSijtUFE8Aze20JLuriiz51nMDuqsC37l6OFHS
Yu3vtq+scIgA2+AHPgDPBLwZh0v4KrpazZfrQ8yT8cu0YK+t+xguYBGTvPhRPmYz
wiOscD3xl5bGpBztEwUUiFf6A3DmoYjJLwlEeMVdjT0OaexMnQjUEkyDQZm9eivR
ak352RDUtBGQZZcVwe91LlzKRKmlKgZ2Z5+3FJ1kTUVzTv3gsJnAISQJ/FE5Tj9q
L1Y/69cpK+2xZiXWi48WT8V3WCMVQYOi7tG/7USfx/aGCiLx7piy4nQyXNH2H4DQ
KGCTZSorl7NxLZj0OXuAB82RWBpM1EIIrHXSBbwxYNha2fCRl67DxwtkhkJfj5VH
VE/SzaUs++TPbxtfsnQC60B3X3Xc1nq8ZnelCvAV80DtkUnJA6hwlluM6wXTrwXQ
HuttGAcAyTvilxpU28Ali6VCYVozxVCwLpNy37b1NBcgmYJbAt+wk3uRcO67xSfY
QG3H3AHchpt4eyvhJeZRiUWOtX287u6Be4liLMxZ3FXF9JWgVOtgsgQEN5BD82VP
B8NiSfXI+1tj3Q6VcrMzRGKyoxJYMqGACBHFLQgjmkHyYbJiA7U=
=JKJm
-----END PGP SIGNATURE-----
Merge tag 'efi-2019-04-rc4-2' of https://github.com/xypron2/u-boot
Pull request for UEFI system for v2019.04-rc4
Fix an error with the serial communication on boards with a very small
UART buffer which leads to a stalled system.
Provide an X86 reset driver for the UEFI runtime.
This commit enables support for I2C S3C424X0 driver.
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
Acked-by: Lukasz Majewski <lukma@denx.de>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
This is currently missing and without it the i8254 beeper driver
won't work.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The pc speaker driven by the i8254 is generic enough to deserve
a single dtsi file to be included by boards that use it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The i8254 timer control IO port (0x43) should be setup correctly
by using PIT counter 2 to generate beeps, however in U-Boot other
codes like TSC driver utilizes PIT for TSC frequency calibration
and configures the counter 2 to a different mode that does not
beep. Fix this by always ensuring the PIT counter 2 is correctly
initialized so that the i8254 beeper driver works as expected.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
CONFIG_BOARD_TYPES is necessary for Odroid X/X2/U3 boards to detect
proper revision. However building should succeed even without it.
While moving code around, document also the reference clock selection.
This fixes the build error without CONFIG_BOARD_TYPES:
board/samsung/odroid/odroid.c: In function 'board_usb_init':
board/samsung/odroid/odroid.c:473:8: error: 'gd_t' {aka 'volatile struct global_data'} has no member named 'board_type'
if (gd->board_type == ODROID_TYPE_U3)
^~
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Just add spaces around '=' sign for clarity.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Various places in the code set "boardname" env property. It was used
for booting from ITB images and choosing proper DTB file name. Instead
of duplicating it, use existing U-Boot wide - "board_name".
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
File mixed space and tab indentation. Unify it.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
When including other header from configs, use consistent <> syntax.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Last activity from Arndale (Exynos5250) board maintainer Chander Kashyap
was in January 2014 (Signed-off). Recently his samsung.com email
bounces with 550 (5.1.1 Recipient address rejected: User unknown).
Add Krzysztof Kozlowski as odd fixer for this board.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Add startup time to LDO regulators of S2MPS11 PMIC on Odroid XU3/XU4/HC1
family of boards to be sure the voltage is proper before relying on the
regulator.
The datasheet for all the S2MPS1x family is inconsistent here and does
not specify unambiguously the value of ramp delay for LDO. It mentions
30 mV/us in one timing diagram but then omits it completely in LDO
regulator characteristics table (it is specified for bucks).
However the vendor kernels for Galaxy S5 and Odroid XU3 use values of 12
mV/us or 24 mV/us.
Without the ramp delay value the consumers do not wait for voltage
settle after changing it. Although the proper value of ramp delay for
LDOs is unknown, it seems safer to use at least some value from
reference kernel than to leave it unset.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
The ADC block requires VDD supply to be on so provide one.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
According to datasheet, the output on LDO regulators will start
appearing after 10-15 us.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Changing voltage and enabling regulator might require delays so the
regulator stabilizes at expected level.
Add support for "regulator-ramp-delay" binding which can introduce
required time to both enabling the regulator and to changing the
voltage.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Fix detection of Odroid HC1 (Exynos5422) after reboot if kernel disabled
the LDO4/VDD_ADC regulator.
The LDO4 supplies both ADC block and the ADC input AIN9. Voltage on
AIN9 will rise slowly, so use delay of 5 milliseconds instead of
timers-based loop to wait for voltage stabilization.
First reads on Odroid HC1 return 305, 1207, 1297 and finally 1308
(reference value is 1309).
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Printing the "Type" of board requires proper detection of revision which
can happen only late because regulators are needed.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Detection of board revision is done early - before power setup. In case of
Odroid XU3/XU4/HC1 family, the detection is done using ADC which
is supplied by LDO4/VDD_ADC regulator. This regulator could be turned
off (e.g. by kernel before reboot). If ADC is used early, the
regulators are not yet available and the detection won't work.
Split the revision detection out of set_board_type() into separate
function called later - either when displaying board info (in late mode)
or during misc_init_r. The idea is that set_board_type() will be called
early so its method of detection are limited to flattened device tree
(exynos5-dt-types.c for Exynos5) or GPIO (odroid.c for Exynos4412). The
newly added set_board_revision() can be called only later, when
resources like regulator are available.
This is necessary to fix the detection of Odroid HC1 after reboot, if
kernel turned off the LDO4 regulator.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
When stopping the ADC_V2_CON1_STC_EN should be cleared.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Our selftest will soon test the actual runtime reset function rather than
the boot time one. For this, we need to ensure that the runtime version
actually succeeds on x86 to keep our travis tests work.
So this patch implements an x86 runtime reset function. It is missing
shutdown functionality today, but OSs usually implement that via ACPI
and this function does more than the stub from before, so it's at least
an improvement.
Eventually we will want to have full DM functionality in runtime services.
But this fixes a travis failure and doesn't clutter the code too heavily, so
we should pull it in without the amazing new RTS DM framework.
Signed-off-by: Alexander Graf <agraf@suse.de>
Function term_read_reply tries to read from the serial console until
the end_char was read. This can hang forever if we are, for some reason,
not able to read the full response (e.g. serial buffer too small,
frame error). This patch moves the timeout detection into
term_read_reply() to assure we will make progress.
Fixes: 6bb591f704 ("efi_loader: query serial console size reliably")
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Throw missing error when an incomplete reply for the cursor position is
received.
Change type of argument of term_get_char() *s32. This renders the function
reusable in efi_cin_read_key().
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Intel Edison has three UART ports, i.e.
port 0 - Bluetooth
port 1 - auxiliary, available for general purpose use
port 2 - debugging, usually console output is here
Enable all of them for future use.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The console is actually serial #2. When we would like to enable other ports,
this would be not okay to mess up with the ordering.
Thus, fix the number of default console interface to be 2.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We may not do an assumption that current console device is always a first
of UCLASS_SERIAL one.
For example, on properly described Intel Edison board the console UART
is a third one.
Use current serial device as described in global data.
Fixes: a61cbad78e ("dm: serial: Adjust serial_getinfo() to use proper API")
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Intel Tangier SoC has a general purpose DMA which can serve to speed up
communications on SPI and I2C serial buses.
Provide DMA descriptors to utilize this capability in the future.
Note, I2C6, which is available to user, has no DMA request lines connected.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Intel Tangier SoC has a general purpose DMA which can serve to speed up
communications on SPI and I2C serial buses.
Provide DMA descriptors to utilize this capability in the future.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Replace the current rather convoluted code using ad-hoc polling
mechanism with a more straightforward code. Use wait_for_bit_le32()
to poll the DDRCALSTAT register instead of local reimplementation.
It makes no sense to pull for 5 seconds before giving up and trying
to restart the EMIF, so instead wait 500 mSec for the calibration to
complete and if this fails, restart the EMIF and try again. Perform
this 32 times instead of 3 times as the original code did.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chin Liang See <chin.liang.see@intel.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tien Fong Chee <tien.fong.chee@intel.com>
The EMIF reset code can well use wait_for_bit_le32() instead of all that
convoluted polling code. Reduce the timeout from 100 seconds to 1 second,
since if the EMIF fails to reset itself in 1 second, it's unlikely longer
wait would help. Make sure to clear the EMIF reset request even if the
SEQ2CORE_INT_RESP_BIT isn't asserted.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chin Liang See <chin.liang.see@intel.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tien Fong Chee <tien.fong.chee@intel.com>
The current EMIF clear timeout handling code was applying bitwise
operations to signed data types and as it was, was extremely hard
to read. Replace it with simple wait_for_bit(). Expand the error
handling to make it more readable too.
This patch also changes the timeout for emif_clear() from 14 hours
to 1 second.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chin Liang See <chin.liang.see@intel.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tien Fong Chee <tien.fong.chee@intel.com>
The Kconfig checked for SoCFPGA Arria10 as a platform, instead of
checking for specific board configuration, which works with one
single platform in tree, but not with multiple. Fix it.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chin Liang See <chin.liang.see@intel.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tien Fong Chee <tien.fong.chee@intel.com>
The SPL size on Gen5 is 4*64kiB, but on A10 it is 4*256kiB.
Handle the difference.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chin Liang See <chin.liang.see@intel.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tien Fong Chee <tien.fong.chee@intel.com>
This is not used anywhere, so drop it.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chin Liang See <chin.liang.see@intel.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tien Fong Chee <tien.fong.chee@intel.com>
The bootrom seems to leave the D-cache in messed up state, make sure
the SPL disables it so it can not interfere with operation.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chin Liang See <chin.liang.see@intel.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tien Fong Chee <tien.fong.chee@intel.com>
The debug print is missing a newline, add it.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chin Liang See <chin.liang.see@intel.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tien Fong Chee <tien.fong.chee@intel.com>
The Altera Arria10 DDR driver was using constants in a few places
instead of reading registers associated with those constants, fix
this.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chin Liang See <chin.liang.see@intel.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tien Fong Chee <tien.fong.chee@intel.com>
The values for the data and tag latency settings on the PL310 caches
controller is an (n-1). For example, the "arm,tag-latency" is specified
as <1 1 1>, so the values that should be written to register should be
0x000. And for the "arm,data-latency" specified as <2 1 1>, the register
value should be 0x010.
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
v2019.01 commit cbff9f80ce ("ARM: dts: rmobile: Sync Gen3 DTs with
Linux 4.19.6") made the sdhi/usb nodes available in r8a77965.dtsi.
Hence, remove the SDHI/USB nodes from r8a77965-u-boot.dtsi. This is
equivalent to partially reverting below v2019.01 commits:
- f529bc551b ("ARM: dts: rmobile: Extract USB nodes on M3N")
- 830b94f768 ("ARM: dts: rmobile: Extract SDHI nodes on M3N")
Duplicating the nodes from <soc>.dtsi to <soc>-u-boot.dtsi is obviously:
- not needed if no U-boot-specific changes are needed in those nodes.
- potentially dangerous/error-prone, since the duplicated properties
override the properties originally defined in <soc>.dtsi. One
possible consequence is that <soc>.dtsi is getting an update from
Linux, while <soc>-u-boot.dtsi stays unchanged. In this situation,
the obsolete property values from <soc>-u-boot.dtsi will take
precedence masking some of the <soc>.dtsi updates, potentially
leading to all kind of obscure issues.
Below is the dtdiff of r8a77965-salvator-x-u-boot.dtb (the only "user"
of r8a77965-u-boot.dtsi) before and after the patch (slightly
reformatted to avoid 'git am/apply' issues and to reduce the width).
What below output means is there is already a mismatch in some of
SDHI/USB nodes between r8a77965.dtsi and r8a77965-u-boot.dtsi. Since no
U-Boot customization is needed in SDHI/USB DT nodes, get rid of them in
r8a77965-u-boot.dtsi.
$> dtdiff before-r8a77965-salvator-x-u-boot.dtb \
after-r8a77965-salvator-x-u-boot.dtb
--- /dev/fd/63 2019-03-09 12:57:40.877963983 +0100
+++ /dev/fd/62 2019-03-09 12:57:40.877963983 +0100
@@ -1471,7 +1471,7 @@
bus-width = <0x4>;
cd-gpios = <0x51 0xc 0x1>;
clocks = <0x6 0x1 0x13a>;
- compatible = "renesas,sdhi-r8a77965";
+ compatible = "renesas,sdhi-r8a77965", "renesas,rcar-gen3-sdhi";
interrupts = <0x0 0xa5 0x4>;
max-frequency = <0xc65d400>;
pinctrl-0 = <0x4d>;
@@ -1492,7 +1492,7 @@
sd@ee120000 {
clocks = <0x6 0x1 0x139>;
- compatible = "renesas,sdhi-r8a77965";
+ compatible = "renesas,sdhi-r8a77965", "renesas,rcar-gen3-sdhi";
interrupts = <0x0 0xa6 0x4>;
max-frequency = <0xbebc200>;
power-domains = <0x1 0x20>;
@@ -1504,7 +1504,7 @@
sd@ee140000 {
bus-width = <0x8>;
clocks = <0x6 0x1 0x138>;
- compatible = "renesas,sdhi-r8a77965";
+ compatible = "renesas,sdhi-r8a77965", "renesas,rcar-gen3-sdhi";
fixed-emmc-driver-type = <0x1>;
interrupts = <0x0 0xa7 0x4>;
max-frequency = <0xbebc200>;
@@ -1526,7 +1526,7 @@
bus-width = <0x4>;
cd-gpios = <0x5a 0xf 0x1>;
clocks = <0x6 0x1 0x137>;
- compatible = "renesas,sdhi-r8a77965";
+ compatible = "renesas,sdhi-r8a77965", "renesas,rcar-gen3-sdhi";
interrupts = <0x0 0xa8 0x4>;
max-frequency = <0xc65d400>;
pinctrl-0 = <0x56>;
@@ -1868,14 +1868,14 @@
usb-phy@ee0a0200 {
#phy-cells = <0x0>;
- clocks = <0x6 0x1 0x2be>;
+ clocks = <0x6 0x1 0x2bf>;
compatible = "renesas,usb2-phy-r8a77965", "renesas,rcar-gen3-usb2-phy";
phandle = <0x47>;
pinctrl-0 = <0x4c>;
pinctrl-names = "default";
power-domains = <0x1 0x20>;
reg = <0x0 0xee0a0200 0x0 0x700>;
- resets = <0x6 0x2be>;
+ resets = <0x6 0x2bf>;
status = "okay";
};
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
v2019.01 commit 07a8060a12 ("ARM: rmobile: Convert to bootm_size")
attempted converting to bootm_size of 256 MiB below targets:
- include/configs/alt.h
- include/configs/gose.h
- include/configs/koelsch.h
- include/configs/lager.h
- include/configs/porter.h
- include/configs/rcar-gen3-common.h
- include/configs/silk.h
- include/configs/stout.h
The update didn't fully work on R-Car3 due to the
CONFIG_SYS_BOOTMAPSZ=8MiB definition left by v2016.09 commit
e525d34b47 ("ARM: rmobile: Add support salvator-x board"),
which is explained in below README excerpt:
----8<----
CONFIG_SYS_BOOTMAPSZ:
[..] If CONFIG_SYS_BOOTMAPSZ is undefined,
then the value in "bootm_size" will be used instead.
----8<----
Allow the original commit to accomplish its purpose on R-Car3 targets
by removing the CONFIG_SYS_BOOTMAPSZ definition.
Fixes: 07a8060a12 ("ARM: rmobile: Convert to bootm_size")
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Enable DM_SPI and DM_SPI_FLASH in U-Boot on H2 Stout, M2W Porter and E3 Silk.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
U-Boot currently uses Gen2 QSPI in 1-bit mode, enforce it until
we can do better using the new SPI NOR framework.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
