- Mar 15, 2015
-
-
Masahiro Yamada authored
Panasonic's System LSI products, UniPhier SoC family, have been transferred to Socionext Inc. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com>
-
- Mar 06, 2015
-
-
Alexey Brodkin authored
lib/asm-offsets - make GD_RELOCADDR, GD_RELOC_OFF & GD_START_ADDR_SP available for all architectures 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>
-
- Mar 05, 2015
-
-
gaurav rana authored
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>
-
- Feb 28, 2015
-
-
Masahiro Yamada authored
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>
-
- Feb 25, 2015
-
-
gaurav rana authored
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>
-
- Feb 06, 2015
-
-
Bin Meng authored
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>
-
- Jan 30, 2015
-
-
Ruchika Gupta authored
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
-
Ruchika Gupta authored
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
-
Ruchika Gupta authored
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>
-
Ruchika Gupta authored
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>
-
Ruchika Gupta authored
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>
-
Simon Glass authored
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>
-
Simon Glass authored
These have moved to driver model so we don't need the fdtdec support. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Since GPIO support has now moved to the driver model uclass, we can drop this include. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
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>
-
Simon Glass authored
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>
-
- Jan 24, 2015
-
-
Simon Glass authored
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>
-
- Jan 14, 2015
-
-
Simon Glass authored
This allows the caller to easily detect how much of the destination buffer has been used. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
This allows the caller to easily detect how much of the destination buffer has been used. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
This allows the caller to easily detect how much of the destination buffer has been used. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
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>
-
- Jan 13, 2015
-
-
Bin Meng authored
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)
-
- Dec 29, 2014
-
-
Alexey Brodkin authored
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>
-
- Dec 18, 2014
-
-
Thierry Reding authored
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>
-
Thierry Reding authored
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>
-
Thierry Reding authored
The AS3722 provides a number of DC/DC converters and LDOs as well as 8 GPIOs. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Simon Glass <sjg@chromium.org> Signed-off-by:
Tom Warren <twarren@nvidia.com>
-
- Dec 14, 2014
-
-
Bin Meng authored
Move GD_BIST from lib/asm-offsets.c to arch/x86/lib/asm-offsets.c as it is x86 arch specific stuff. Also remove GENERATED_GD_RELOC_OFF which is not referenced anymore. Signed-off-by:
Bin Meng <bmeng.cn@gmail.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
- Dec 11, 2014
-
-
Przemyslaw Marczak authored
The functions error's numbers are standarized - but the error messages are not. The errors are often handled with unclear error messages, so why not use an errno standarized messages. Advantages: - This could decrease the binary size. - Appended with a detailed information, the error message will be clear. This commit introduces new function: - const char *errno_to_str(int errno) The functions returns a pointer to the errno corresponding text message: - if errno is null or positive number - a pointer to "Success" message - if errno is negative - a pointer to errno related message Signed-off-by:
Przemyslaw Marczak <p.marczak@samsung.com> Reviewed-by:
Tom Rini <trini@ti.com>
-
Masahiro Yamada authored
Move strlcpy() definition from drivers/usb/gadget/ether.c to lib/string.c because it is a very useful function. Let's add the prototype to include/linux/string.h too. Signed-off-by:
Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
- Dec 08, 2014
-
-
Masahiro Yamada authored
Signed-off-by:
Masahiro Yamada <yamada.m@jp.panasonic.com>
-
Masahiro Yamada authored
Signed-off-by:
Masahiro Yamada <yamada.m@jp.panasonic.com>
-
Masahiro Yamada authored
Signed-off-by:
Masahiro Yamada <yamada.m@jp.panasonic.com>
-
Masahiro Yamada authored
Including <linux/compiler.h> is enough for general use. Signed-off-by:
Masahiro Yamada <yamada.m@jp.panasonic.com>
-
- Nov 27, 2014
-
-
Masahiro Yamada authored
The fdt_path_offset() checks an alias too. fdtdec_get_alias_node(blob, "foo") is equivalent to fdt_path_offset(blob, "foo"). Signed-off-by:
Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
- Nov 25, 2014
-
-
Simon Glass authored
Intel's Graphics Media Accelerator (GMA) is a generic name for a wide range of video devices. Add code to set up the hardware on ivybridge. Part of the init happens in native code, part of it happens in a 16-bit option ROM for those nostalgic for the 1970s. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Add the setup code for the CPU so that it can be used at full speed. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
Simon Glass authored
Add code to set up the SATA interfaces on boot. Signed-off-by:
Simon Glass <sjg@chromium.org>
-
- Nov 23, 2014
-
-
Thierry Reding authored
Provide a new modifier to vsprintf() to print phys_addr_t variables to avoid having to cast or #ifdef when printing them out. The %pa modifier is used for this purpose, so phys_addr_t variables need to be passed by reference, like so: phys_addr_t start = 0; printf("start: %pa\n", &start); Depending on the size of phys_addr_t this will print out the address with 8 or 16 hexadecimal digits following a 0x prefix. Signed-off-by:
Thierry Reding <treding@nvidia.com> Tested-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
Simon Glass <sjg@chromium.org>
-
- Nov 22, 2014
-
-
Simon Glass authored
Since we scan from left to right looking for the first digit, "i2c0" returns 2 instead of 0 for the alias number. Adjust the code to scan from right to left instead. Signed-off-by:
Simon Glass <sjg@chromium.org> Acked-by:
Heiko Schocher <hs@denx.de> Reviewed-by:
Tom Rini <trini@ti.com>
-
- Nov 21, 2014
-
-
Simon Glass authored
Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by:
Simon Glass <sjg@chromium.org>
-