The SOR is required for talking to eDP LCD panels. Add a driver for this
which will be used by the DisplayPort driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This is useful for display parameters. Add a simple decode function to read
from this device tree node.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Having this as a Kconfig allows it to be a dependent feature.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a function similar to print_size() that works for frequencies. It can
handle from Hz to GHz.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Before adding one more function, create a separate header to help reduce
the size of common.h. Add the missing function comments and tidy up.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
After syncing the sunxi dts files with the upstream kernel dm/fdt sunxi
builds would no longer boot.
The problem is that stdout-path is now set like this in the upstream dts
files: stdout-path = "serial0:115200n8". The use of options in of-paths,
either after an alias name, or after a full path, e.g. stdout-path =
"/soc@01c00000/serial@01c28000:115200", is standard of usage, but something
which the u-boot dts code so far did not handle.
This commit fixes this, adding support for both path formats.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Simon Glass <sjg@chromium.org>
There is little reason to split these two functions. Bring them together
which simplifies the init sequence.
Signed-off-by: Simon Glass <sjg@chromium.org>
The printf() in panic() adds about 1.5KB of code size to SPL when compiled
with Thumb-2. Provide a smaller version that does not support printf()-style
arguments and use it in two commonly compiled places.
Signed-off-by: Simon Glass <sjg@chromium.org>
Initial filesystem images are generally highly compressible.
Add a routine gzwrite that allows gzip-compressed images to be
written to block devices.
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
Reviewed-by: Tom Rini <trini@ti.com>
This patch is simply clean-up to make the IPv4 type that is used match
what Linux uses. It also attempts to move all variables that are IP
addresses use good naming instead of CamelCase. No functional change.
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Acked-by: Simon Glass <sjg@chromium.org>
The U-Boot device trees are slightly different in a few places. Adjust them
to remove most of the differences. Note that U-Boot does not support the
concept of interrupts as distinct from GPIOs, so this difference remains.
For sandbox, use the same keyboard file as for ARM boards and drop the
host emulation bus which seems redundant.
Signed-off-by: Simon Glass <sjg@chromium.org>
The PCH (Platform Controller Hub) is on the PCI bus, so show it as such.
The LPC (Low Pin Count) and SPI bus are inside the PCH, so put these in the
right place also.
Rename the compatible strings to be more descriptive since this board is the
only user. Once we are using driver model fully on x86, these will be
dropped.
Signed-off-by: Simon Glass <sjg@chromium.org>
In the case where the arch defines a custom map_sysmem(), make sure that
including just mapmem.h is sufficient to have these functions as they
are when the arch does not override it.
Also split the non-arch specific functions out of common.h
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Move chromebook_link over to driver model for PCI.
This involves:
- adding a uclass for platform controller hub
- removing most of the existing PCI driver
- adjusting how CPU init works to use driver model instead
- rename the lpc compatible string (it will be removed later)
This does not really take advantage of driver model fully, but it does work.
Furture work will improve the code structure to remove many of the explicit
calls to init the board.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function returns -ENOENT when the property is missing (which the caller
might forgive) and also when the property is present but incorrectly
formatted (which many callers would like to report).
Update the error return value to allow these different situations to be
distinguished.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This function is missing a prototype but is more widey useful. Add it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Panasonic's System LSI products, UniPhier SoC family, have been
transferred to Socionext Inc.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
GD_RELOCADDR, GD_RELOC_OFF & GD_START_ADDR_SP are generic members of
global data structure so why don't we allow architectures other than ARM
to use it.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@ti.com>
Acked-by: Simon Glass <sjg@chromium.org>
Remove dependency of rsa_mod_exp from CONFIG_FIT_SIGNATURE.
As rsa modular exponentiation is an independent module
and can be invoked independently.
Signed-off-by: Gaurav Rana <gaurav.rana@freescale.com>
Acked-by: Simon Glass <sjg@chromium.org>
Reviewed-by: York Sun <yorksun@freescale.com>
Support xHCI host driver used on Panasonic UniPhier platform.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Marek Vasut <marex@denx.de>
Currently only normal hashing is supported using hardware acceleration.
Added support for progressive hashing using hardware.
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
Signed-off-by: Gaurav Rana <gaurav.rana@freescale.com>
CC: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: York Sun <yorksun@freescale.com>
Add COMPAT_INTEL_QRK_MRC and "intel,quark-mrc" so that fdtdec can
decode Intel Quark MRC node.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Currently the hash functions used in RSA are called directly from the sha1
and sha256 libraries. Change the RSA checksum library to use the progressive
hash API's registered with struct hash_algo. This will allow the checksum
library to use the hardware accelerated progressive hash API's once available.
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
CC: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
(Fixed build error in am335x_boneblack_vboot due to duplicate CONFIG_DM)
Change-Id: Ic44279432f88d4e8594c6e94feb1cfcae2443a54
Kconfig option added for devices which support RSA Verification.
1. RSA_SOFTWARE_EXP
Enables driver for supporting RSA Modular Exponentiation in Software
2. RSA_FREESCALE_EXP
Enables driver for supporting RSA Modular Exponentiation using Freescale specific
driver
The above drivers use RSA uclass
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
CC: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
(Removed duplicate line in Kconfig comment)
Change-Id: I7663c4d5350e2bfc3dfa2696f70ef777d6ccc6f6
Modify rsa_verify to use the rsa driver of DM library .The tools
will continue to use the same RSA sw library.
CONFIG_RSA is now dependent on CONFIG_DM. All configurations which
enable FIT based signatures have been modified to enable CONFIG_DM
by default.
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
CC: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
For FIT signature based approach to work, RSA library needs to be selected.
The FIT_SIGNATURE option in Kconfig is modified to automatically select RSA.
Selecting RSA compiles the RSA library required for image verification.
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
CC: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
Public exponentiation which is required in rsa verify functionality is
tightly integrated with verification code in rsa_verify.c. The patch
splits the file into twp separating the modular exponentiation.
1. rsa-verify.c
- The file parses device tree keys node to fill a keyprop structure.
The keyprop structure can then be converted to implementation specific
format.
(struct rsa_pub_key for sw implementation)
- The parsed device tree node is then passed to a generic rsa_mod_exp
function.
2. rsa-mod-exp.c
Move the software specific functions related to modular exponentiation
from rsa-verify.c to this file.
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
CC: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
This has moved to driver model so we don't need the fdtdec support.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Minkyu Kang <mk7.kang@samsung.com>
Now that we support device tree GPIO bindings directly in the driver model
GPIO uclass we can remove these functions.
Signed-off-by: Simon Glass <sjg@chromium.org>
For GPIOs and other functions we want to look up a phandle and then decode
a list of arguments for that phandle. Each phandle can have a different
number of arguments, specified by a property in the target node. This is
the "#gpio-cells" property for GPIOs.
Add a function to provide this feature, taken modified from Linux 3.18.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add this to the enum so that we can use the various fdtdec functions. A
later commit will move this driver to driver model.
Signed-off-by: Simon Glass <sjg@chromium.org>
Commit 4d3b8a0d fixed a problem with lzma decompress where it would
run out of bytes to decompress. The algorithm needs to know how many
uncompressed bytes it is expected to produce.
However, the fix introduced a potential buffer overrun, and causes
the compression test to fail (test_compression command in sandbox).
The correct fix seems to be to use the minimum of the expected number
of uncompressed bytes and the amount of output space available. That
way things work normally when there is enough space, and return an
error (without overrunning available space) when there is not.
Signed-off-by: Antonios Vamporakis <ant@area128.com>
CC: Kees Cook <keescook@chromium.org>
CC: Simon Glass <sjg@chromium.org>
CC: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
CC: Luka Perkov <luka@openwrt.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
This commit adds several APIs to decode PCI device node according to
the Open Firmware PCI bus bindings, including:
- fdtdec_get_pci_addr() for encoded pci address
- fdtdec_get_pci_vendev() for vendor id and device id
- fdtdec_get_pci_bdf() for pci device bdf triplet
- fdtdec_get_pci_bar32() for pci device register bar
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
(Include <pci.h> in fdtdec.h and adjust tegra to fix build error)
Commit "initcall: Improve debugging support" makes sense and indeed
simplifies process of matching initcalls executed with static
disassembly.
Until you are debugging relocation functionality.
Existign output may make you think that at some point execution somehow
returned back to non-relocated area. And there're many reasons/problems
that may provoke this behavior.
In order to make things clear let's add explicit mention in case initall
was actually relocated like this:
--->---
initcall: 810015f8
Relocation Offset is: 0efcf000
Relocating to 8ffcf000, new gd at 8fdced3c, sp at 8fdced20
initcall: 810015b8
initcall: 8ffd093c
initcall: 8ffd0a14
initcall: 81001940 (relocated to 8ffd0940)
initcall: 81001958 (relocated to 8ffd0958)
--->---
Note "unexpected" jump from 0x8f... area to 0x81... area.
Without explanation this raises many questions: execution jumped in
relocated area right as expected and then for some reason returned back?
But I hope comment in brackets will save some time for those curious
developers who are careful enough to catch "unexpected jump to pre-reloc
area" or those unlucky ones who'll have to deal with relocation
debugging.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Add support for the PCIe controller found on some generations of Tegra.
Tegra20 has 2 root ports with a total of 4 lanes, Tegra30 has 3 root
ports with a total of 6 lanes and Tegra124 has 2 root ports with a total
of 5 lanes.
This is based on the Linux kernel driver, originally submitted upstream
by Mike Rapoport.
Signed-off-by: Mike Rapoport <mike@compulab.co.il>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This controller was introduced on Tegra114 to handle XUSB pads. On
Tegra124 it is also used for PCIe and SATA pin muxing and PHY control.
Only the Tegra124 PCIe and SATA functionality is currently implemented,
with weak symbols on Tegra114.
Tegra20 and Tegra30 also provide weak symbols for these functions so
that drivers can use the same API irrespective of which SoC they're
being built for.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
