- May 17, 2017
-
-
Andre Przywara authored
Some platforms require more complex U-Boot images than we can easily generate via the mkimage command line, for instance to load additional image files. Introduce a CONFIG_SPL_FIT_SOURCE and CONFIG_SPL_FIT_GENERATOR symbol, which can either hold an .its source file describing the image layout, or, in the second case, a generator tool (script) to create such a source file. This script gets passed the list of device tree files from the CONFIG_OF_LIST variable. A platform or board can define either of those in their defconfig file to allow an easy building of such an image. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
Jagan Teki <jagan@openedev.com>
-
Andre Przywara authored
For a board or platform to support FIT loading in the SPL, it has to provide a board_fit_config_name_match() routine, which helps to select one of possibly multiple DTBs contained in a FIT image. Provide a simple function which chooses the DT name U-Boot was configured with. If the DT name is one of the two Pine64 versions, determine the exact model by checking the DRAM size. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
Simon Glass <sjg@chromium.org> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by:
Jagan Teki <jagan@openedev.com> Tested-by:
Jagan Teki <jagan@openedev.com>
-
Andre Przywara authored
The sunxi SPL was holding the detected RAM size in some local variable only, so it wasn't accessible for other functions. Store the value in gd->ram_size instead, so it can be used later on. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
Simon Glass <sjg@chromium.org> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by:
Jagan Teki <jagan@openedev.com>
-
Andre Przywara authored
The SPL stack is usually located at the end of SRAM A1, where it grows towards the end of the SPL. For the really big AArch64 binaries the stack overwrites code pretty soon, so move the SPL stack to the end of SRAM A2, which is unused at this time. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
Simon Glass <sjg@chromium.org> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by:
Jagan Teki <jagan@openedev.com>
-
Andre Przywara authored
The generic ARMv8 assembly code contains routines for setting up a CCN interconnect, though the Freescale SoCs are the only user. Link this code only for Freescale targets, this saves some precious bytes in the chronically tight SPL. Signed-off-by:
Andre Przywara <andre.przywara@arm.com>
-
Andre Przywara authored
Not every SoC needs to set up the GIC interrupt controller, so link think code only when the respective config option is set. This shaves off some bytes from the SPL code size. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Jagan Teki <jagan@openedev.com>
-
Andre Przywara authored
mksunxiboot limits the size of the resulting SPL binaries to pretty conservative values to cover all SoCs and all boot media (NAND). It turns out that we have limit checks in place in the build process, so mksunxiboot can be relaxed and allow packaging binaries up to the actual 32KB the mask boot ROM actually imposes. This allows to have a bigger SPL, which is crucial for AArch64 builds. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Jagan Teki <jagan@openedev.com>
-
Andre Przywara authored
SPL_FIT obviously requires libfdt in SPL, so let Kconfig express that by selecting SPL_OF_LIBFDT. Also make the actual options that users want (SPL signature and SPL FIT loading) visible in the menu and let them select the SPL_FIT as a requirement. Also remove the now redundant SPL_OF_LIBFDT from those Kconfigs that had it in for the SPL FIT loading feature. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
Simon Glass <sjg@chromium.org> [Remove change from configs/evb-rk3399_defconfig] Signed-off-by:
Jagan Teki <jagan@openedev.com>
-
Andre Przywara authored
So far we were not using the FIT image format to its full potential: The SPL FIT loader was just loading the first image from the /images node plus one of the listed DTBs. Now with the refactored loader code it's easy to load an arbitrary number of images in addition to the two mentioned above. As described in the FIT image source file format description, iterate over all images listed at the "loadables" property in the configuration node and load every image at its desired location. This allows to load any kind of images: - firmware images to execute before U-Boot proper (for instance ARM Trusted Firmware (ATF)) - firmware images for management processors (SCP, arisc, ...) - firmware images for devices like WiFi controllers - bit files for FPGAs - additional configuration data - kernels and/or ramdisks The actual usage of this feature would be platform and/or board specific. Also update the FIT documentation to mention the new SPL feature and provide an example .its file to demonstrate its features. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
Lokesh Vutla <lokeshvuta@ti.com> Reviewed-by:
Simon Glass <sjg@chromium.org> Tested-by:
Heiko Stuebner <heiko@sntech.de> Reviewed-by:
Kever Yang <kever.yang@rock-chips.com> Tested-by:
Kever Yang <kever.yang@rock-chips.com> Tested-by:
Jagan Teki <jagan@openedev.com> Reviewed-by:
Jagan Teki <jagan@openedev.com>
-
Andre Przywara authored
At the moment we load two images from a FIT image: the actual U-Boot image and the .dtb file. Both times we have very similar code, that deals with alignment requirements the media we load from imposes upon us. Factor out this code into a new function, which we just call twice. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
Simon Glass <sjg@chromium.org> Tested-by:
Heiko Stuebner <heiko@sntech.de> Reviewed-by:
Kever Yang <kever.yang@rock-chips.com> Tested-by:
Kever Yang <kever.yang@rock-chips.com> Tested-by:
Jagan Teki <jagan@openedev.com>
-
Andre Przywara authored
At the moment we ignore any errors due to missing FIT properties, instead go ahead and calculate our addresses with the -1 return value. Fix this and bail out if any of the mandatory properties are missing. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
Simon Glass <sjg@chromium.org> Tested-by:
Heiko Stuebner <heiko@sntech.de> Reviewed-by:
Kever Yang <kever.yang@rock-chips.com> Tested-by:
Kever Yang <kever.yang@rock-chips.com> Tested-by:
Jagan Teki <jagan@openedev.com> Reviewed-by:
Jagan Teki <jagan@openedev.com>
-
Andre Przywara authored
Currently the SPL FIT loader always looks only for the first image in the /images node a FIT tree, which it loads and later executes. Generalize this by looking for a "firmware" property in the matched configuration subnode, or, if that does not exist, for the first string in the "loadables" property. Then using the string in that property, load the image of that name from the /images node. This still loads only one image at the moment, but refactors the code to allow extending this in a following patch. To simplify later re-usage, we also generalize the spl_fit_select_index() function to not return the image location, but just the node offset. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
Lokesh Vutla <lokeshvuta@ti.com> Reviewed-by:
Simon Glass <sjg@chromium.org> Tested-by:
Heiko Stuebner <heiko@sntech.de> Reviewed-by:
Kever Yang <kever.yang@rock-chips.com> Tested-by:
Kever Yang <kever.yang@rock-chips.com> Tested-by:
Jagan Teki <jagan@openedev.com>
-
Andre Przywara authored
Currently the SPL FIT loader uses the spl_fit_select_fdt() function to find the offset to the right DTB within the FIT image. For this it iterates over all subnodes of the /configuration node in the FIT tree and compares all "description" strings therein using a board specific matching function. If that finds a match, it uses the string in the "fdt" property of that subnode to locate the matching subnode in the /images node, which points to the DTB data. Now this works very well, but is quite specific to cover this particular use case. To open up the door for a more generic usage, let's split this function into: 1) a function that just returns the node offset for the matching configuration node (spl_fit_find_config_node()) 2) a function that returns the image data any given property in a given configuration node points to, additionally using a given index into a possbile list of strings (spl_fit_select_index()) This allows us to replace the specific function above by asking for the image the _first string of the "fdt" property_ in the matching configuration subnode points to. This patch introduces no functional changes, it just refactors the code to allow reusing it later. (diff is overly clever here and produces a hard-to-read patch, so I recommend to throw a look at the result instead). Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
Lokesh Vutla <lokeshvuta@ti.com> Reviewed-by:
Simon Glass <sjg@chromium.org> Tested-by:
Heiko Stuebner <heiko@sntech.de> Reviewed-by:
Kever Yang <kever.yang@rock-chips.com> Tested-by:
Kever Yang <kever.yang@rock-chips.com> Tested-by:
Jagan Teki <jagan@openedev.com>
-
- May 16, 2017
-
-
git://git.denx.de/u-boot-mmcTom Rini authored
- Add #undef CONFIG_DM_MMC_OPS to omap3_logic in the SPL build case, to match other TI platforms in the same situation. Signed-off-by:
Tom Rini <trini@konsulko.com>
-
git://git.denx.de/u-boot-videoTom Rini authored
-
- May 15, 2017
-
-
Wenyou Yang authored
To fix the timeout of sending the write command, enable the quirk SDHCI_QUIRK_WAIT_SEND_CMD. Signed-off-by:
Wenyou Yang <wenyou.yang@atmel.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
Jernej Skrabec authored
This patch adds support for TV encoder clocks which will be used later. Signed-off-by:
Jernej Skrabec <jernej.skrabec@siol.net>
-
Jernej Skrabec authored
Newer SoCs use same TV encoder unit. Split it out so it can be reused with new DM video driver. Signed-off-by:
Jernej Skrabec <jernej.skrabec@siol.net> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
Philipp Tomsich authored
Due to a typo, the 24 bit-per-pixel configuration ends in 24BMP instead of 24BPP. This change renames it throughout the source tree for consistency and to make moving these options into Kconfig easier and less error-prone. Signed-off-by:
Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Hannes Schmelzer <hannes.schmelzer@br-automation.com>
-
Philipp Tomsich authored
Instead of having drivers/video/rockchip/Kconfig point outside of its hierarchy for dw_hdmi.o, we should use a configuration-option to include the Designware HDMI support. This change introduces a new config option (not to be selected via menuconfig, but to be selected from a dependent video driver's configuration option) that enables dw_hdmi.o and selects it whenever the HDMI support for Rockchip SoCs is selected. Signed-off-by:
Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
Jernej Skrabec authored
Some DVI monitors don't work in HDMI mode. Set it only if edid data explicitly states that it is supported. Signed-off-by:
Jernej Skrabec <jernej.skrabec@siol.net> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
Jernej Skrabec authored
Some DVI monitors don't show anything in HDMI mode since audio stream confuses them. To solve this situation, this commit adds HDMI flag in timing data and sets it accordingly during edid parsing. First existence of extension block is checked. If it exists and it is CEA861 extension, then data blocks are checked for presence of HDMI vendor specific data block. If it is present, HDMI flag is set. Signed-off-by:
Jernej Skrabec <jernej.skrabec@siol.net> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
Jernej Skrabec authored
Timing flags are never set, so they may contain garbage. Since some drivers check them, video output may be broken on those drivers. Initialize them to 0 and check for few common flags. Signed-off-by:
Jernej Skrabec <jernej.skrabec@siol.net> Reviewed-by:
Simon Glass <sjg@chromium.org>
-
git://git.denx.de/u-boot-i2cTom Rini authored
-
Masahiro Yamada authored
Recent commits of DTC introduced new warnings checking PCI and simple buses, unit address formatting, and stricter node and property name checking. Disable the new DTC warnings by default. As before, warnings are enabled with W=*. The strict node and property name checks are a bit subjective, so they are only enabled for W=2. (This policy reflects the commit 8654cb8d0371 of Linux.) Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com>
-
Adam Ford authored
Enable TI_COMMON_CMD_OPTIONS and remove similar options from the defconfig. Updated with savedefconfig CMD_USB isn't enabled yet. I have some testing to do with musb. Signed-off-by:
Adam Ford <aford173@gmail.com> Reviewed-by:
Tom Rini <trini@konsulko.com>
-
Adam Ford authored
Now that CMD_POWEROFF can turn off the twl4030, let's imply that just incase someone wants to disable it. Signed-off-by:
Adam Ford <aford173@gmail.com> Reviewed-by:
Tom Rini <trini@konsulko.com>
-
Tom Rini authored
Follow the exiting logic for the i.MX options when migrating this option. Cc: Marek Vasut <marex@denx.de> Signed-off-by:
Tom Rini <trini@konsulko.com> Reviewed-by:
Marek Vasut <marex@denx.de>
-
Tom Rini authored
The following options are migrated over fully now: - USB_EHCI_ATMEL - USB_EHCI_MARVELL - USB_EHCI_MX6 - USB_EHCI_MX7 - USB_EHCI_MSM - USB_EHCI_ZYNQ - USB_EHCI_GENERIC This also requires fixing the depends on USB_EHCI_MARVELL as it's used by Orion5X and Kirkwood as well. Cc: Marek Vasut <marex@denx.de> Signed-off-by:
Tom Rini <trini@konsulko.com> Reviewed-by:
Marek Vasut <marex@denx.de>
-
Tom Rini authored
Migrate the rest of the users of CONFIG_USB_EHCI_HCD over to Kconfig. For a few SoCs, imply or default y this if USB is enabled. In some cases we had not already migrated to CONFIG_USB so do that as well. Cc: Marek Vasut <marex@denx.de> Signed-off-by:
Tom Rini <trini@konsulko.com> Reviewed-by:
Marek Vasut <marex@denx.de>
-
Tom Rini authored
In order to be able to migrate the various SoC EHCI CONFIG options we first need to finish the switch from CONFIG_USB_EHCI to CONFIG_USB_EHCI_HCD. Cc: Marek Vasut <marex@denx.de> Signed-off-by:
Tom Rini <trini@konsulko.com> Reviewed-by:
Marek Vasut <marex@denx.de>
-
Tom Rini authored
The symbol CONFIG_OMAP3_LOGIC_USE_NEW_PRODUCT_ID was recently dropped from usage and CONFIG_OMAP3_MICRON_DDR is unused in code. Signed-off-by:
Tom Rini <trini@konsulko.com>
-
Tom Rini authored
The symbol CONFIG_OMAP_VC_I2C_HS_MCODE always uses the default value. Restructure the comment and code such that if a need arises later to use another value we can address this then. Signed-off-by:
Tom Rini <trini@konsulko.com>
-
Tom Rini authored
Move this entry to Kconfig. As it is a hardware watchdog, select HW_WATCHDOG. While we could default to enabling this for all platforms, it is currently only enabled by default on AM33XX, so keep that logic today. Cc: Roger Meier <r.meier@siemens.com> Signed-off-by:
Tom Rini <trini@konsulko.com>
-
Tom Rini authored
This particular quirk is not enabled in any config files today. It does however exist and is handled correctly in device trees and via CONFIG_DM_SPI. So we drop the symbol now and add a comment to indicate that any (new) boards that require this quirk need to enable DM_SPI instead. Signed-off-by:
Tom Rini <trini@konsulko.com>
-
Tom Rini authored
The symbols CONFIG_OMAP3_GPIO_X control if we enable the clocks for a given GPIO bank in U-Boot. select the required banks for each target. In some cases we need to also migrate from CONFIG_USB_EHCI (deprecated, in include/configs/) to CONFIG_USB_EHCI_HCD as we only require the GPIO bank to be enabled if USB is also enabled. Signed-off-by:
Tom Rini <trini@konsulko.com>
-
Tom Rini authored
This driver is used often enough such that we want to have this enabled by default on any ARCH_OMAP2PLUS board, and this only compiles on ARCH_OMAP2PLUS due to required defines, so mark that as the depends. Signed-off-by:
Tom Rini <trini@konsulko.com>
-
Tom Rini authored
We no longer have a need for a per-board CONFIG_OMAP3_xxx define (we have CONFIG_TARGET_xxx when this is required), so drop these unused references. Signed-off-by:
Tom Rini <trini@konsulko.com>
-
Tom Rini authored
While there are a few different OMAP4 SoCs, today we always set CONFIG_OMAP4430 and CONFIG_OMAP44XX. Convert the few test of CONFIG_OMAP4430 to CONFIG_OMAP44XX. Cc: Marek Vasut <marex@denx.de> Cc: Paul Kocialkowski <contact@paulk.fr> Signed-off-by:
Tom Rini <trini@konsulko.com>
-
Tom Rini authored
We make use of CONFIG_OMAP3_EVM today to know when to do a specific tweak in MUSB. This can be tested on via CONFIG_TARGET_OMAP3_EVM instead, so switch there so we can drop the now unused symbol CONFIG_OMAP3_EVM. In investigating what to do about the symbol usage we see that the cairo board defines the same function, but never called it (as it does not define CONFIG_OMAP3_EVM) and was just returning anyhow, so drop that function from that board. Cc: "Albert ARIBAUD (3ADEV)" <albert.aribaud@3adev.fr> Cc: Marek Vasut <marex@denx.de> Signed-off-by:
Tom Rini <trini@konsulko.com>
-