Shaohui Xie [Thu, 21 Jan 2016 09:14:53 +0000 (17:14 +0800)]
armv8/ls1043aqds: Select lpuart pins of various muxes
Set Board Configuration Register to select the lpuart pins of various
muxes.
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com> Signed-off-by: Mingkai Hu <Mingkai.Hu@freescale.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: York Sun <york.sun@nxp.com>
Yangbo Lu [Wed, 30 Dec 2015 06:19:30 +0000 (14:19 +0800)]
mmc: fsl_esdhc: increase data transaction timeout to 500ms
The MMC spec says "It is strongly recommended for hosts to implement
more than 500ms timeout value even if the card indicates the 250ms
maximum busy length." Even the previous value of 300ms is known to
be insufficient for some cards. So, increase the timeout to 500ms.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
Management Complex firmware 9.0 has fixed the issue of
dprc_destroy_container i.e. the used portal is not return to the
free pool. Which was resulting in error ethernet driver want to
use this portal via either DPL or dynamically in Linux.
Hard-coding of portal id is removed.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com> Reviewed-by: York Sun <york.sun@nxp.com>
driver: net: ldpaa: Add debug info of printing DPMAC stats
Add debug information prints to provide DPMAC statistics
- Number of bytes received
- Number of received and discard frames
- Number of bytes transferred
- Number of frames transferred
etc.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com> Reviewed-by: York Sun <york.sun@nxp.com>
driver: net: ldpaa: Increase num of buffers for a pool
Management Complex FW 9.0 set the hardware depletion to be 20
buffers in order to support multiple pools in DPNI. This requires
driver to fill the pool with at least 21 to be able to receive
frames. So, Increase number of buffers for a pool.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com> Reviewed-by: York Sun <york.sun@nxp.com>
driver: net: fsl-mc: Prepare extended cfg for DPNI create
Management Complex FW 9.0 puts a new requirement to prepare extended
parameters which should be provided as input in dpni_create. extended
parameters includes traffic class and IP reassembly configurations.
So prepare extended parameters with default "0" as input for
dpni_create.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com> Reviewed-by: York Sun <york.sun@nxp.com>
Aneesh Bansal [Fri, 22 Jan 2016 11:07:28 +0000 (16:37 +0530)]
secure_boot: change error handler for esbc_validate
In case of error while executing esbc_validate command, SNVS
transition and issue of reset is required only for secure-boot.
If boot mode is non-secure, this is not required.
Similarly, esbc_halt command which puts the core in Spin Loop
is applicable only for Secure Boot.
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com> Acked-by: Ruchika Gupta <ruchika.gupta@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
Aneesh Bansal [Fri, 22 Jan 2016 11:07:27 +0000 (16:37 +0530)]
secure_boot: enable chain of trust for PowerPC platforms
Chain of Trust is enabled for PowerPC platforms for Secure Boot.
CONFIG_BOARD_LATE_INIT is defined.
In board_late_init(), fsl_setenv_chain_of_trust() is called which
will perform the following:
- If boot mode is non-secure, return (No Change)
- If boot mode is secure, set the following environmet variables:
bootdelay = 0 (To disable Boot Prompt)
bootcmd = CONFIG_CHAIN_BOOT_CMD (Validate and execute Boot script)
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com> Acked-by: Ruchika Gupta <ruchika.gupta@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
Aneesh Bansal [Fri, 22 Jan 2016 11:07:26 +0000 (16:37 +0530)]
secure_boot: enable chain of trust for ARM platforms
Chain of Trust is enabled for ARM platforms (LS1021 and LS1043).
In board_late_init(), fsl_setenv_chain_of_trust() is called which
will perform the following:
- If boot mode is non-secure, return (No Change)
- If boot mode is secure, set the following environmet variables:
bootdelay = 0 (To disable Boot Prompt)
bootcmd = CONFIG_CHAIN_BOOT_CMD (Validate and execute Boot script)
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com> Acked-by: Ruchika Gupta <ruchika.gupta@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
Aneesh Bansal [Fri, 22 Jan 2016 11:07:24 +0000 (16:37 +0530)]
secure_boot: split the secure boot functionality in two parts
There are two phases in Secure Boot
1. ISBC: In BootROM, validate the BootLoader (U-Boot).
2. ESBC: In U-Boot, continuing the Chain of Trust by
validating and booting LINUX.
For ESBC phase, there is no difference in SoC's based on ARM or
PowerPC cores.
But the exit conditions after ISBC phase i.e. entry conditions for
U-Boot are different for ARM and PowerPC.
PowerPC:
If Secure Boot is executed, a separate U-Boot target is required
which must be compiled with a diffrent Text Base as compared to
Non-Secure Boot. There are some LAW and TLB settings which are
required specifically for Secure Boot scenario.
ARM:
ARM based SoC's have a fixed memory map and exit conditions from
BootROM are same irrespective of boot mode (Secure or Non-Secure).
Thus the current Secure Boot functionlity has been split into
two parts:
CONFIG_CHAIN_OF_TRUST
This will have the following functionality as part of U-Boot:
1. Enable commands like esbc_validate, esbc_halt
2. Change the environment settings based on bootmode, determined
at run time:
- If bootmode is non-secure, no change
- If bootmode is secure, set the following:
- bootdelay = 0 (Don't give boot prompt)
- bootcmd = Validate and execute the bootscript.
CONFIG_SECURE_BOOT
This is defined only for creating a different compile time target
for secure boot.
Traditionally, both these functionalities were defined under
CONFIG_SECURE_BOOT. This patch is aimed at removing the requirement
for a separate Secure Boot target for ARM based SoC's.
CONFIG_CHAIN_OF_TRUST will be defined and boot mode will be
determine at run time.
Another Security Requirement for running CHAIN_OF_TRUST is that
U-Boot environemnt must not be picked from flash/external memory.
This cannot be done based on bootmode at run time in current U-Boot
architecture. Once this dependency is resolved, no separate
SECURE_BOOT target will be required for ARM based SoC's.
Currently, the only code under CONFIG_SECURE_BOOT for ARM SoC's is
defining CONFIG_ENV_IS_NOWHERE
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com> Acked-by: Ruchika Gupta <ruchika.gupta@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
Aneesh Bansal [Fri, 22 Jan 2016 11:07:23 +0000 (16:37 +0530)]
secure_boot: include/configs: move definition of CONFIG_CMD_BLOB
CONFIG_CMD_BLOB must be defined in case of Secure Boot. It was
earlier defined in all config files. The definition has been
moved to a common file which is included by all configs.
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com> Acked-by: Ruchika Gupta <ruchika.gupta@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
Aneesh Bansal [Fri, 22 Jan 2016 11:07:22 +0000 (16:37 +0530)]
secure_boot: include/configs: make secure boot header file uniform
The file fsl_secure_boot.h must be included in config file for
Secure Boot. This is not required to be protected by any macro.
CONFIG_FSL_CAAM must be defined and CONFIG_CMD_HASH should be
turned on.
The above was missing in some config files and all files have been
made uniform in this respect.
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com> Acked-by: Ruchika Gupta <ruchika.gupta@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
Aneesh Bansal [Tue, 8 Dec 2015 08:44:15 +0000 (14:14 +0530)]
SECURE BOOT: support for validation of dynamic image
Some images to be validated are relocated to a dynamic
address at run time. So, these addresses cannot be known
befor hand while signing the images and creating the header
offline.
So, support is required to pass the image address to the
validate function as an argument.
If an address is provided to the function, the address
field in Header is not read and is treated as a reserved
field.
Signed-off-by: Saksham Jain <saksham@freescale.com> Signed-off-by: Aneesh Bansal <aneesh.bansal@freescale.com> Acked-by: Ruchika Gupta <ruchika.gupta@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
Aneesh Bansal [Tue, 8 Dec 2015 08:44:13 +0000 (14:14 +0530)]
SECURE BOOT: separate functions for reading keys
Separate functions are created for reading and checking the
sanity of Public keys:
- read_validate_single_key
- read_validate_ie_tbl
- read_validate_srk_table
Signed-off-by: Saksham Jain <saksham@freescale.com> Signed-off-by: Aneesh Bansal <aneesh.bansal@freescale.com> Acked-by: Ruchika Gupta <ruchika.gupta@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
Aneesh Bansal [Tue, 8 Dec 2015 08:44:12 +0000 (14:14 +0530)]
SECURE BOOT: change prototype of fsl_secboot_validate function
The prototype and defination of function fsl_secboot_validate
has been changed to support calling this function from another
function within u-boot.
Only two aruments needed:
1) header address - Mandatory
2) SHA256 string - optional
Signed-off-by: Saksham Jain <saksham@freescale.com> Signed-off-by: Aneesh Bansal <aneesh.bansal@freescale.com> Acked-by: Ruchika Gupta <ruchika.gupta@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
Erratum A-009663 workaround requires to set DDR_INTERVAL[BSTOPRE] to 0
before setting DDR_SDRAM_CFG[MEM_EN] and set DDR_INTERVAL[BSTOPRE]
to the desired value after DDR initialization has completed.
When DDR controller is configured to operate in auto-precharge
mode(DDR_INTERVAL[BSTOPRE]=0), this workaround is not needed.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com> Reviewed-by: York Sun <york.sun@nxp.com>
Gong Qianyu [Thu, 31 Dec 2015 10:29:02 +0000 (18:29 +0800)]
freescale/qixis: Add support for booting from SD/QSPI
1.Use "qixis_reset sd" to boot from SD
2.Use "qixis_reset sd_qspi" to boot from SD with QSPI support
3.Use "qixis_reset qspi" to boot from QSPI flash
On some SoCs such as LS1021A and LS1043A, IFC and QSPI could be
pin-multiplexed. So the switches are different between SD boot with
IFC support and SD boot with QSPI support. The default booting from
SD is with IFC support.
Once QSPI is enabled(IFC disabled), only use I2C to access QIXIS.
Signed-off-by: Gong Qianyu <Qianyu.Gong@freescale.com> Reviewed-by: York Sun <york.sun@nxp.com>
Simon Glass [Fri, 22 Jan 2016 02:45:25 +0000 (19:45 -0700)]
rockchip: Update the README
GPIO, I2C, LCD and HDMI are now implemented. We have more than one PMIC.
There is an implementation to run the CPU at full speed although it does
not seem to make much difference.
Simon Glass [Fri, 22 Jan 2016 02:45:19 +0000 (19:45 -0700)]
rockchip: jerry: Enable EDP and HDMI video output
Enable these devices using the VOPL video output device. We explicitly
disable VOPB in the device tree to avoid it taking over. Since this device
has an LCD display this comes up by default. If the display fails for some
reason then it will attempt to use HDMI. It is possible to force it to fail
(and thus fall back to HDMI) by puting 'return -EPERM' at the top of
rk_edp_probe(). For now there is no easy way to select between the two.
Simon Glass [Fri, 22 Jan 2016 02:45:08 +0000 (19:45 -0700)]
rockchip: Add a script to parse datasheets
This script has proved useful for parsing datasheets and creating register
shift/mask values for use in header files. Include it in case it is useful
for others.
Simon Glass [Fri, 22 Jan 2016 02:45:05 +0000 (19:45 -0700)]
rockchip: video: Add a video-output driver
Some rockchip SoCs include video output (VOP). Add a driver to support this.
It can output via a display driver (UCLASS_DISPLAY) and currently HDMI and
eDP are supported.
Simon Glass [Fri, 22 Jan 2016 02:45:03 +0000 (19:45 -0700)]
rockchip: video: Add a display driver for rockchip HDMI
Some Rockchip SoCs support HDMI output. Add a display driver for this so
that these displays can be used on supported boards.
Unfortunately this driver is not fully functional. It cannot reliably read
EDID information over HDMI. This seems to be due to the clocks being
incorrect - the I2C bus speed appears to be up to 100x slower than the
clock settings indicate. The root cause may be in the clock logic.
Simon Glass [Fri, 22 Jan 2016 02:45:00 +0000 (19:45 -0700)]
dm: video: Repurpose the 'displayport' uclass to 'display'
The current DisplayPort uclass is too specific. The operations it provides
are shared with other types of output devices, such as HDMI and LVDS LCD
displays.
Generalise the uclass so that it can be used with these devices as well.
Adjust the uclass to handle the EDID reading and conversion to
display_timing internally.
Simon Glass [Fri, 22 Jan 2016 02:44:59 +0000 (19:44 -0700)]
video: panel: Add a simple panel driver
Most panels are very simple - they just have a power supply and a backlight.
Add a driver which supports this and implements the enable_backlight()
method.
Simon Glass [Fri, 22 Jan 2016 02:44:58 +0000 (19:44 -0700)]
dm: panel: Add a panel uclass
LCD panels can usefully be modelled as their own uclass. They can be probed
(which powers them up ready for use). If they have a backlight, this can be
enabled.
Simon Glass [Fri, 22 Jan 2016 02:44:56 +0000 (19:44 -0700)]
dm: backlight: Add a backlight uclass
LCD panels normally have a backlight which can be controlled to illuminate
the LCD contents. Add a uclass to support this. Initially it only has a
method to enable the backlight.
Simon Glass [Fri, 22 Jan 2016 02:44:51 +0000 (19:44 -0700)]
video: Name consoles by their number
We must use the console name in the 'stdout' variable to select the one
we want. At present the name is formed from the driver name with a suffix
indicating the rotation value.
It seems better to name them sequentially since this can be controlled by
driver order. So adjust the code to use 'vidconsole' for the first,
'vidconsole1' for the second, etc.
Simon Glass [Fri, 22 Jan 2016 02:44:50 +0000 (19:44 -0700)]
gpio: Warn about invalid GPIOs used with the 'gpio' command
At present there is no indication that an invalid GPIO is used except that
the GPIO status is not displayed. Make the error more explicit to avoid
confusion.
Simon Glass [Fri, 22 Jan 2016 02:44:12 +0000 (19:44 -0700)]
rockchip: spi: Remove the explicit pinctrl setting
The correct pinctrl is handled automatically so we don't need to do it in
the driver. The exception is when we want to use a different chip select
(other than 0). But this isn't used at present.
Simon Glass [Fri, 22 Jan 2016 02:44:11 +0000 (19:44 -0700)]
rockchip: spi: Correct chip-enable code
At present there is an incorrect call to rkspi_enable_chip(). It should
be disabling the chip, not enabling it. Correct this and ensure that the
chip is disabled when releasing the bus.
Simon Glass [Fri, 22 Jan 2016 02:44:05 +0000 (19:44 -0700)]
rockchip: clk: Make rkclk_get_clk() SoC-specific
The current method assumes that clocks are numbered from 0 and we can
determine a clock by its number. It is safer to use an ID in the clock's
platform data to avoid the situation where another clock is bound before
the one we expect.
Move the existing code into rk3036 since it still works there. Add a new
implementation for rk3288.
Simon Glass [Fri, 22 Jan 2016 02:43:59 +0000 (19:43 -0700)]
dm: power: Allow regulators to not implement all operations
Some regulators will not implement any operations (e.g. fixed regulators).
This is not an error, so allow the autoset process to continue when one
of these regulators is found.
Simon Glass [Fri, 22 Jan 2016 02:43:58 +0000 (19:43 -0700)]
dm: power: Tidy up debugging output and return values
The currect PMIC debugging is a little confusing. Adjust it so that it is
clear whether the operation succeeded or failed. Also, avoid creating a new
error return value when a perfectly good one is already available.
Simon Glass [Fri, 22 Jan 2016 02:43:56 +0000 (19:43 -0700)]
dm: pinctrl: Add a way for a GPIO driver to obtain a pin function
GPIO drivers want to be able to show if a pin is enabled for input, output,
or is being used by another function. Some drivers can easily find this
and the code is included in the driver. For some SoCs this is more complex.
Conceptually this should be handled by pinctrl rather than GPIO. Most
pinctrl drivers will have this feature anyway.
Add a method by which a GPIO driver can obtain the pin mux value given a
GPIO reference. This avoids repeating the code in two places.
Simon Glass [Fri, 22 Jan 2016 02:43:55 +0000 (19:43 -0700)]
dm: power: Allow regulators to be omitted from SPL
For some boards the pmic interface is useful but the regulator interface
(which comes with it) is too large. Allow them to be separated such that
SPL can decide which it needs.
Simon Glass [Fri, 22 Jan 2016 02:43:54 +0000 (19:43 -0700)]
spi: Correct device tree usage in spi_flash_decode_fdt()
This function currently searches the entire device tree for a node that
it thinks is relevant. But the node is known and is passed in. Correct the
code and enable it only with driver model, since only driver-model boards
will use it.
This avoids bringing in a large number of strings from fdtdec.