Simon Glass [Wed, 31 May 2017 23:57:29 +0000 (17:57 -0600)]
rockchip: video: Take the vop device out of standby
On reset the standby bit is clear, but if U-Boot is chain-loaded from
another boot loader it may be set. Clear it before starting up video so
that it works correctly.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
Squashed in 'rockchip: video: fix taking the VOP device out of standby': Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Simon Glass [Wed, 31 May 2017 23:57:28 +0000 (17:57 -0600)]
rockchip: video: Add remove() methods
Add remove() methods for EDP and VOP so that U-Boot can shut down the
video on exit. This avoids leaving DMA running while booting Linux which
can cause problems if Linux uses the frame buffer for something else.
It also makes it clear what is needed to shut down video.
While we are here, make rkvop_enable() static.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
Squashed in 'rockchip: video: fix taking the VOP device out of standby': Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Simon Glass [Wed, 31 May 2017 23:57:24 +0000 (17:57 -0600)]
README: Add instructions for chain-loading U-Boot
Most Chromebooks support chain-loading U-Boot but instructions are
somewhat scattered. Add a README to hold this information within the
U-Boot tree. Also add the standard developer keys to simplify the
instructions, since they are small.
Simon Glass [Wed, 31 May 2017 23:57:22 +0000 (17:57 -0600)]
tegra: clock: Avoid a divide-by-zero error
The clock fix-up for tegra is still present in the code. It causes a
divide-by-zero bug after relocation when chain-loading U-Boot from
coreboot. Fix this by adding a check.
Signed-off-by: Simon Glass <sjg@chromium.org> Fixes: 7468676 (ARM: tegra: fix clock_get_periph_rate() for UART clocks)
Simon Glass [Wed, 31 May 2017 23:57:21 +0000 (17:57 -0600)]
tegra: Enable CP15 init
At present CP15 init is disabled on tegra. Use the correct option so that
this init is performed on boot. This enables the instruction cache, for
example, which is critical to the machine running at full speed.
Simon Glass [Wed, 31 May 2017 23:57:20 +0000 (17:57 -0600)]
tegra: video: Don't power up the SOR twice
If U-Boot is the secondary boot loader, or has been run from itself, the
SOR may already be powered up. Powering it up again causes a hang, so
detect this situation and skip it.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
Simon Glass [Wed, 31 May 2017 23:57:18 +0000 (17:57 -0600)]
tegra: spi: Wait a little after setting the clocks
For devices that need a delay between SPI transactions we seem to need an
additional delay before the first one if the CPU is running at full speed.
Add this, under control of the existing setting. At present it will only
be enabled with the Chrome OS EC.
Simon Glass [Wed, 31 May 2017 23:57:16 +0000 (17:57 -0600)]
tegra: Init clocks even when SPL did not run
At present early clock init happens in SPL. If SPL did not run (because
for example U-Boot is chain-loaded from another boot loader) then the
clocks are not set as U-Boot expects.
Add a function to detect this and call the early clock init in U-Boot
proper.
Simon Glass [Wed, 31 May 2017 23:57:14 +0000 (17:57 -0600)]
arm: Disable LPAE if not enabled
If CONFIG_ARMV7_LPAE is not defined we should make sure that the feature
is disabled. This can happen if U-Boot is chain-loaded from another boot
loader which does enable LPAE.
Simon Glass [Wed, 31 May 2017 23:57:13 +0000 (17:57 -0600)]
arm: Don't try to support CONFIG_ARMV7_LPAE on ARMv4T
At present if CONFIG_ARMV7_LPAE is defined then mmu_setup() will use
instructions which are invalid on ARMv4T. This happens on Tegra since it
has an ARMv4T boot CPU. Add a check for the architecture version to allow
the code to be built. It will not actually be executed by the boot CPU,
but needs to compile.
Simon Glass [Mon, 29 May 2017 21:31:31 +0000 (15:31 -0600)]
patman: Add a functional test
The existing test (patman --test) only covers basic checkpatch output.
We have had some problems with unicode processing and could use test
coverage for the various tags patman supports.
Add a new functional test which runs most of the patman flow on a few
test commits and checks that the results are correct.
See the documentation in the test for a description of what it does.
Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Simon Glass [Mon, 29 May 2017 21:31:29 +0000 (15:31 -0600)]
patman: Add a maintainer test feature to MakeCcFile()
Allow the add_maintainers parameter to be a list of maintainers, thus
allowing us to simulate calling the script in tests without actually
needing it to work.
Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Simon Glass [Mon, 29 May 2017 21:31:24 +0000 (15:31 -0600)]
patman: Don't convert input data to unicode
The communication filter reads data in blocks and converts each block to
unicode (if necessary) one at a time. In the unlikely event that a unicode
character in the input spans a block this will not work. We get an error
like:
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1022-1023:
unexpected end of data
There is no need to change the input to unicode, so the easiest fix is to
drop this feature.
Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Philipp Tomsich [Mon, 29 May 2017 21:31:22 +0000 (15:31 -0600)]
patman: encode CC list to UTF-8
This change encodes the CC list to UTF-8 to avoid failures on
maintainer-addresses that include non-ASCII characters (observed on
Debian 7.11 with Python 2.7.3).
Without this, I get the following failure:
Traceback (most recent call last):
File "tools/patman/patman", line 159, in <module>
options.add_maintainers)
File "[snip]/u-boot/tools/patman/series.py", line 234, in MakeCcFile
print(commit.patch, ', '.join(set(list)), file=fd)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 81: ordinal not in range(128)
from Heiko's email address:
[..., u'"Heiko St\xfcbner" <heiko@sntech.de>', ...]
While with this change added this encodes to:
"=?UTF-8?q?Heiko=20St=C3=BCbner?= <heiko@sntech.de>"
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Tested-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tom Rini [Mon, 22 May 2017 17:48:52 +0000 (13:48 -0400)]
buildman: Fix bloat option when 'new' only drops functions
In the case where a new build only decreases sizes and does not increase
any size we still want to report what functions have been dropped when
doing a bloat comparison.
Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Sun, 14 May 2017 00:11:30 +0000 (20:11 -0400)]
sandbox: Fix comparison of unsigned enum expression warning
In os_dirent_get_typename() we are checking that type falls within the
known values of the enum os_dirent_t. With clang-3.8 testing this value
as being >= 0 results in a warning as it will always be true. This
assumes of course that we are only given valid data. Given that we want
to sanity check the input, we change this to check that it falls within
the range of the first to the last entry in the given enum.
Cc: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Thu, 8 Jun 2017 16:14:11 +0000 (12:14 -0400)]
Merge git://git.denx.de/u-boot-rockchip
Here is additional rk3368 and rk3399 support, rv1108 support,
refactoring HDMI video (brought in from Anatolij's tree to resolve
conflicts), some mkimage fixes and a few other things.
Philipp Tomsich [Wed, 31 May 2017 15:59:36 +0000 (17:59 +0200)]
rockchip: board: puma_rk3399: enable BMP_16BPP, BMP_24BPP and BMP_32BPP
With video output support for the RK3399-Q7 (Puma) available, we want
CMD_BMP enabled and the support for 16bit, 24bit and 32bit BMPs
defined.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Version-changes: 2
- enable SYS_WHITE_ON_BLACK via defconfig Reviewed-by: Simon Glass <sjg@chromium.org>
Philipp Tomsich [Wed, 31 May 2017 15:59:34 +0000 (17:59 +0200)]
rockchip: video: rk3399: add HDMI TX support on the RK3399
This commit enables the RK3399 HDMI TX, which is very similar to the
one found on the RK3288. As requested by Simon, this splits the HDMI
driver into a SOC-specific portion (rk3399_hdmi.c, rk3288_hdmi.c) and
a common portion (rk_hdmi.c).
Note that the I2C communication for reading the EDID works well with
the default settings, but does not with the alternate settings used on
the RK3288... this configuration aspect is reflected by the driverdata
for the RK3399 driver.
Having some sort of DTS-based configuration for the regulator
dependencies would be nice for the future, but for now we simply use
lists of regulator names (also via driverdata) that we probe.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Philipp Tomsich [Wed, 31 May 2017 15:59:33 +0000 (17:59 +0200)]
rockchip: video: split RK3288-specific part off from rk_hdmi
To prepare for the addition of RK3399 HDMI support, the HDMI driver is
refactored and broken into a chip-specific and a generic part. This
change adds the internal interfaces, makes common/reusable functions
externally visible and splits the RK3288 driver into a separate file.
For the probing of regulators, we reuse the infrastructure created
during the VOP refactoring... i.e. we simply call into the helper
function defined for the VOP.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Philipp Tomsich [Wed, 31 May 2017 15:59:31 +0000 (17:59 +0200)]
rockchip: video: rk3399: enable HDMI output (from the rk_vop) for the RK3399
This commit adds a driver for the RK3399 VOPs capable and all the
necessary plumbing to feed the HDMI encoder. For the VOP-big, this
correctly tracks the ability to feed 10bit RGB data to the encoder.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Philipp Tomsich [Wed, 31 May 2017 15:59:30 +0000 (17:59 +0200)]
rockchip: video: refactor rk_vop and split RK3288-specific code off
To prepare for adding the RK3399 VOP driver (which shares most of its
registers and config logic with the RK3228 VOP), this change refactors
the driver and splits the RK3288-specific driver off.
The changes in detail are:
- introduces a data-structure for chip-specific drivers to register
features/callbacks with the common driver: at this time, this is
limited to a callback for setting the pin polarities (between the
VOP and the encoder modules) and a flag to signal 10bit RGB
capability
- refactors the probing of regulators into a helper function that
can take a list of regulator names to probe and autoset
- moves the priv data-structure into a (common) header file to be
used by the chip-specific drivers to provide base addresses to
the common driver
- uses a callback into the chip-specific driver to set pin polarities
(replacing the direct register accesses previously used)
- splits enabling the output (towards an encoder) into a separate
help function withint the common driver
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Philipp Tomsich [Wed, 31 May 2017 15:59:29 +0000 (17:59 +0200)]
rockchip: video: Kconfig: set MAX_XRES and MAX_YRES via Kconfig
This introduces two new Kconfig options that configure the maximum
allowable framebuffer size (i.e. the memory reservation/allocation for
the framebuffer):
- VIDEO_ROCKCHIP_MAX_XRES
- VIDEO_ROCKCHIP_MAX_YRES
The resulting memory allocation will cover 4 byte per pixel for these
resolutions.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
For the RK3399-Q7, we need spl_board_init to be called during SPL
startup to set up the pinmux for the debug UART. Enable SPL_BOARD_INIT
via defconfig to ensure this function is in fact called.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Romain Perier [Fri, 2 Jun 2017 09:19:43 +0000 (11:19 +0200)]
rockchip: rk3288: grf: Fix shift for RK3288_TXCLK_DLY_ENA_GMAC_ENABLE
RK3288_TXCLK_DLY_ENA_GMAC_ENABLE, in GRF_SOC_CON3, is supposed to be bit
0xe and not 0xf. Otherwise, it is RGMII RX clock delayline enable and
introduces random delays and data lose.
This commit fixes the issue by replacing RK3288_TXCLK_DLY_ENA_GMAC_ENABLE
with the right shift.
Signed-off-by: Romain Perier <romain.perier@collabora.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Philipp Tomsich [Tue, 6 Jun 2017 18:44:47 +0000 (20:44 +0200)]
rockchip: dts: rk3399-puma: add DTS for the DDR3-1866 timing
This adds the DDR3-1866 timing via its own DTS and wires it up. This
(currently) is not the default timing for the RK3399-Q7 and should be
selected explicitly via the config (CONFIG_DEFAULT_DEVICE_TREE).
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: Simon Glass <sjg@chromium.org>
Philipp Tomsich [Tue, 6 Jun 2017 18:44:46 +0000 (20:44 +0200)]
rockchip: dts: rk3399-puma: add DTS for the DDR3-1333 timing
This adds the DDR3-1333 timing via its own DTS and wires it up. This
is not the default timing for the RK3399-Q7 and should be selected
explicitly via the config (CONFIG_DEFAULT_DEVICE_TREE).
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: Simon Glass <sjg@chromium.org>
Philipp Tomsich [Tue, 6 Jun 2017 18:44:45 +0000 (20:44 +0200)]
rockchip: dts: rk3399-puma: refactor and rename (default) DDR3-1600 DTS
To better support different RAM timings (DDR3-1333 and DDR3-1866 are
assembly options for the RK3399-Q7), this refactors the DTS support
and renames the default DTS variant from rk3399-puma to
rk3399-puma-ddr1600:
- changes the rk3399-puma DTS into a board-specific DTSI by removing
the inclusion of the DRAM timings
- adds a new rk3399-puma-ddr1600.dts, which includes the (new) common
board DTSI and the DDR3-1600 timing DTSI
- wires this up from arch/arm/dts/Makefile and configs/puma-rk3399_defconfig
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: Simon Glass <sjg@chromium.org>
Philipp Tomsich [Tue, 6 Jun 2017 13:42:29 +0000 (15:42 +0200)]
usb: dwc2-otg: make regs_otg (in platdata) a uintptr_t
The regs_otg field in uintptr_t of the platform data structure for
dwc2-otg has thus far been an unsigned int, but will eventually be
casted into a void*.
This raises the following error with GCC 6.3 and buildman:
../drivers/usb/gadget/dwc2_udc_otg.c: In function 'dwc2_udc_probe':
../drivers/usb/gadget/dwc2_udc_otg.c:821:8: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
reg = (struct dwc2_usbotg_reg *)pdata->regs_otg;
^
This changes regs_otg to a uintptr_t to ensure that it is large enough
to hold any valid pointer (and fix the associated warning).
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Philipp Tomsich [Tue, 6 Jun 2017 07:15:15 +0000 (09:15 +0200)]
rockchip: defconfig: puma-rk3399: update defconfig with video-support
With HDMI output for the RK3399 working, this update the RK3399-Q7
(Puma) defconfig for the new functionality:
1. enables PMIC command (to check if the HDMI voltages are correct)
+CONFIG_CMD_PMIC=y
+CONFIG_CMD_REGULATOR=y
2. enables video-output (via HDMI)
+CONFIG_DM_VIDEO=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
3. turns on the 'dcache'-command (for a dcache flush) for our QA to
fill the framebuffer using 'mw.l'
+CONFIG_CMD_CACHE=y
4. turns on the 'bmp'-command
+CONFIG_CMD_BMP=y
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
When enabling CONFIG_DISPLAY_ROCKCHIP_HDMI, compile-time warning for
the following implicitly defined functions are raised due to a missing
include directive:
drivers/video/rockchip/rk_hdmi.c: In function 'rk_hdmi_probe':
drivers/video/rockchip/rk_hdmi.c:150:2: warning: implicit declaration of function 'rk_setreg' [-Wimplicit-function-declaration]
rk_setreg(&priv->grf->soc_con6, 1 << 15);
^~~~~~~~~
drivers/video/rockchip/rk_hdmi.c:153:2: warning: implicit declaration of function 'rk_clrsetreg' [-Wimplicit-function-declaration]
rk_clrsetreg(&priv->grf->soc_con6, 1 << 4,
^~~~~~~~~~~~
This change fixes this by including <asm/hardware.h> in rk_hdmi.c.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: Simon Glass <sjg@chromium.org>
The usb_gadget_handle_interrupts()-function is already implemented by
drivers/usb/gadget/dwc2_udc_otg.c, so we need to avoid defining it
in the evb-rk3328.c board-specific file.
This change fixes the following build error (from buildman):
drivers/usb/gadget/built-in.o: In function `usb_gadget_handle_interrupts':
build/../drivers/usb/gadget/dwc2_udc_otg.c:850: multiple definition of `usb_gadget_handle_interrupts'
board/rockchip/evb_rk3328/built-in.o:build/../board/rockchip/evb_rk3328/evb-rk3328.c:37: first defined here
make[1]: *** [u-boot] Error 1
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: Simon Glass <sjg@chromium.org>
Meng Dongyang [Thu, 1 Jun 2017 11:22:45 +0000 (19:22 +0800)]
rockchip: usb: host: xhci-rockchip: add support for rk3328
Add the compatible "rockchip,rk3328-xhci" in match table
for rk3328 to probe xhci controller. Use fixed regulator
to control the voltage of vbus and turn off vbus when
usb stop.
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Andy Yan [Thu, 1 Jun 2017 10:00:55 +0000 (18:00 +0800)]
rockchip: Add core Soc start-up code for rv1108
RV1108 is embedded with an ARM Cortex-A7 single core and a DSP core
from Rockchip. It is designed for varies application scenario such
as car DVR, sports DV, secure camera and UAV camera.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Andy Yan [Thu, 1 Jun 2017 09:58:31 +0000 (17:58 +0800)]
rockchip: mkimage: Add support for RV1108
Add support to mkimage for rv1108 soc, the max
spl code size for rv1108 is 6kb, and the spl
code should be packed by rksd, wether boot from
emmc or spi nor flash.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Philipp Tomsich [Wed, 31 May 2017 16:18:50 +0000 (18:18 +0200)]
rockchip: defconfig: puma-rk3399: do not filter clock-names for SPL
For the RK3399-Q7 module, we use full OF_CONTROL (i.e. not
OF_PLATDATA) for SPL. In this configuration, the rockchip_dw_mmc
driver retrieves one of its clocks via clk_get_by_name and fails if
this is not possible. For this reason, we can not filter clock-names
from the device-tree nodes used for the configuration of the SPL
stage.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Philipp Tomsich [Wed, 31 May 2017 16:18:49 +0000 (18:18 +0200)]
rockchip: defconfig: puma-rk3399: enable I2C
The RK3399-Q7 exposes I2C on its edge connector and uses it as one of
the interfaces towards the on-module STM32 (for the emulated RTC and
fan-controller).
Enable I2C and CMD_I2C support in the defconfig.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Philipp Tomsich [Wed, 31 May 2017 16:18:46 +0000 (18:18 +0200)]
rockchip: defconfig: puma-rk3399: enable RK808 support
On the RK3399-Q7, we need PMIC support (for the RK808) to enable HDMI
output, as one of the required powerrails is not enabled on boot.
For this, we need to enable the RK808 driver.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Version-changes: 3
- With the recent upstream changes to the RK808 (PMIC) driver, the
associated configuration options have been renamed to RK8XX. Track
this change in the RK3399-Q7 defconfig. Reviewed-by: Simon Glass <sjg@chromium.org>
Klaus Goger [Wed, 31 May 2017 16:17:59 +0000 (18:17 +0200)]
rockchip: dts: rk3399-puma: set spl-payload-offset
defines the spl-payload to 256k (0x40000)
Signed-off-by: Klaus Goger <klaus.goger@theobroma-systems.com> Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Philipp Tomsich [Wed, 31 May 2017 16:17:58 +0000 (18:17 +0200)]
rockchip: dts: rk3399-puma: release reset of on-module USB3 hub via vbus-gpio
On the RK3399-Q7, the on-module USB3 hub is held in reset at boot-up
to save power and needs to be woken up using GPIO4A3.
Note that this is not a negated reset-signal (due to a level shifter
being needed for this signal anyway), but a negated enable-signal:
to enable, we need to output LOW (i.e. 0)... so we mark this as an
ACTIVE_LOW signal.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Philipp Tomsich [Wed, 31 May 2017 16:16:36 +0000 (18:16 +0200)]
rockchip: dts: rk3399-puma: Add DDR3-1866 timings
With the validation done for DDR3-1866 (i.e. 933 MHz bus clock), we
can now add the timings (rk3399-sdram-ddr3-1866.dtsi) for boards built
with the DDR3-1866 option.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Philipp Tomsich [Wed, 31 May 2017 16:16:35 +0000 (18:16 +0200)]
rockchip: arm64: rk3399: support DDR3-1866 (i.e. 933MHz clock)
The RK3399 is capable of driving DDR3 at 933MHz (i.e. DDR3-1866),
if the PCB layout permits and appropriate memory timings are used.
This changes the sanity checks to allow a DTS to request DDR3-1866
operation.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Philipp Tomsich [Wed, 31 May 2017 16:16:34 +0000 (18:16 +0200)]
rockchip: arm64: rk3399: revise timeout-handling for DRAM PHY lock
Revise the loop watching for a timeout on obtaining a DRAM PHY lock to
clearly state a timeout in milliseconds and use get_timer (based on
the ARMv8 architected timer) to detect a timeout.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Philipp Tomsich [Tue, 30 May 2017 21:32:10 +0000 (23:32 +0200)]
rockchip: mkimage: set init_boot_size to avoid confusing the boot ROM
This change restores the earlier setting of init_boot_size to include
the maximum area covered by the the boot ROM of each chip for resolve
issues with back-to-bootrom functionality reported by Kever and Heiko.
To ensure that we don't run into the same issue again in the future,
I have updated the comments accordingly and added a reference to the
mailing list archive (there's some very helpful info from Andy Yan
that provides background on the BootROM requirements regarding these
fields).
See https://lists.denx.de/pipermail/u-boot/2017-May/293267.html for
some background (by Andy Yan) of how the BootROM processes this field.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Philipp Tomsich [Tue, 30 May 2017 21:32:08 +0000 (23:32 +0200)]
rockchip: mkimage: add support for verify_header/print_header
The rockchip image generation was previously missing the ability to
verify the generated header (and dump the image-type) without having
to resort to hexdump or od. Experience in our testing has showed it
to be very easy to get the rkspi and rksd images mixed up and the
lab... so we add the necessary support to have dumpimage tell us
what image type we're dealing with.
This change set adds the verify_header and print_header capability
to the rksd/rkspi image drivers (through shared code in rkcommon).
As of now, we only support images fully that are not RC4-encoded for
the SPL payload (i.e. header1 and payload). For RC4-encoded payloads,
the outer header (header0) is checked, but no detection of whether
this is a SD/MMC or SPI formatted payload takes place.
The output of dumpsys now prints the image type (spl_hdr), whether it
is a SD/MMC or SPI image, and the (padded) size of the image:
$ ./tools/dumpimage -l ./spl.img
Image Type: Rockchip RK33 (SD/MMC) boot image
^^^^^^ SD/MMC vs. SPI indication
^^^^ spl_hdr indicated by the image
Data Size: 79872 bytes
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: Simon Glass <sjg@chromium.org>
Kever Yang [Tue, 23 May 2017 07:01:13 +0000 (15:01 +0800)]
MAINTAINERS: git-mailrc: update maintainer for Rockchip
Send patch to Kever Yang instead of Lin Huang for Rockchip patches,
for Lin is not always working on upstream U-Boot.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Changed , to : in subject: Signed-off-by: Simon Glass <sjg@chromium.org>
Kever Yang [Wed, 17 May 2017 03:44:44 +0000 (11:44 +0800)]
rockchip: pinctrl: rk3328: do not set io routing
In rk3328, some function pin may have more than one choice, and muxed
with more than one IO, for example, the UART2 controller IO,
TX and RX, have 3 choice(setting in com_iomux):
- M0 which mux with GPIO1A0/GPIO1A1
- M1 which mux with GPIO2A0/GPIO2A1
- usb2phy which mux with USB2.0 DP/DM pin.
We should not decide which group to use in pinctrl driver,
for it may be different in different board, it should goes to board
file, and the pinctrl file should setting correct iomux depends on
the com_iomux value.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Acked-by: Simon Glass <sjg@chromium.org>
Andy Yan [Mon, 15 May 2017 09:54:48 +0000 (17:54 +0800)]
rockchip: rk3368: Add PX5 Evaluation board
PX5 EVB is designed by Rockchip for automotive field
with integrated CVBS (TP2825) / MIPI DSI / CSI / LVDS
HDMI video input/output interface, audio codec ES8396,
WIFI / BT (on RTL8723BS), Gsensor BMA250E and light&proximity
sensor STK3410.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Andreas Färber [Mon, 15 May 2017 09:54:26 +0000 (17:54 +0800)]
rockchip: rk3368: Add initial support for RK3368 based GeekBox
The GeekBox is a TV box from GeekBuying, based on an MXM3 module.
The module can be used with base boards such as the GeekBox Landingship.
This adds basic support to chain-load U-Boot from Rockchip's miniloader.
Signed-off-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Andy Yan [Mon, 15 May 2017 09:53:50 +0000 (17:53 +0800)]
rockchip: rk3368: add Sheep board
Sheep board is designed by Rockchip as a EVB for rk3368.
Currently it is able to boot a linux kernel and system
to console with the miniloader run as fist level loader.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Mark Kettenis [Sat, 13 May 2017 18:17:05 +0000 (20:17 +0200)]
regulator: pwm: Fix handling of missing init voltage
Since priv->init_voltage is an unsigned integer it can never be
negative. So the current code fails to detect a missing
'regulator-init-microvolt' property and instead misconfigures the
PWM device. Fix this by making the relevant members of
'struct pwm_regulator_info' signed integers.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Heiko Stübner [Sat, 6 May 2017 19:21:29 +0000 (21:21 +0200)]
power: rk808: fix ldo register offset
Till now get_ldo_reg did a return &rk808_ldo[num - 1]; to return
the ldo register offset but didn't take into account that its
calling functions already created the ldo as ldo = dev->driver_data - 1.
This resulted in the setting for ldo8 writing to the register of ldo7
and so on. So fix this and get the correct ldo register data.
Signed-off-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Simon Glass <sjg@chromium.org>
With everything in place (i.e. the new efuse driver, the clk-support
for the non-secure efuse block, and the board-specific functions to
derive 'serial#' from the cpu-id within the efuses), enable this in
the RK3399-Q7 defconfig.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: Simon Glass <sjg@chromium.org>
Klaus Goger [Fri, 5 May 2017 17:21:40 +0000 (19:21 +0200)]
rockchip: board: puma_rk3399: derive ethaddr from cpuid
Generate a MAC address based on the cpuid available in the efuse
block: Use the first 6 byte of the cpuid's SHA256 hash and set the
locally administered bits. Also ensure that the multicast bit is
cleared.
The MAC address is only generated and set if there is no ethaddr
present in the saved environment.
Signed-off-by: Klaus Goger <klaus.goger@theobroma-systems.com> Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Philipp Tomsich [Fri, 5 May 2017 17:21:39 +0000 (19:21 +0200)]
rockchip: board: puma_rk3399: add support for serial# and cpuid# via efuses
With our efuse driver for the RK3399 ready, we can add the
board-specific code that consumes the cpuid from the efuse block and
postprocesses it into the system serial (using the same CRC32 based
derivation as in Linux).
We expose the cpuid via two distinct environment variables:
serial# - the serial number, as derived in Linux
cpuid# - the raw 16 byte CPU id field from the fuse block
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: Simon Glass <sjg@chromium.org>
Philipp Tomsich [Fri, 5 May 2017 17:21:38 +0000 (19:21 +0200)]
rockchip: efuse: add (misc) driver for RK3399 non-secure efuse block
This adds a simple driver for reading the efuse block of the RK3399.
It should be easy enough to add drivers for other devices (e.g. the
RK3328, RK3368, etc.) by passing the device details via driver_data.
Unlike the kernel driver (using the nvmem subsystem), we don't expose
the efuse as multiple named cells, but rather as a linear memory that
can be read using misc_read(...).
The primary use case (as of today) is the generation of a 'serial#'
(and a 'cpuid#') environment variable for the RK3399-Q7 (Puma)
system-on-module.
Note that this adds a debug-only (i.e. only if DEBUG is defined)
command 'rk3399_dump_efuses' that dumps the efuse block's content.
N.B.: The name 'rk3399_dump_efuses' was intentionally chosen to
include a SoC-name (together with a comment in the function) to
remind whoever adds support for additional SoCs that this
function currently makes assumptions regarding the size of the
fuse-box based on the RK3399. The hope is that the function is
adjusted to reflect any changes resulting from generalising the
driver for multiple SoCs and is then renamed.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org>
projects / u-boot.git / log