summaryrefslogtreecommitdiff
path: root/common
AgeCommit message (Collapse)Author
2019-06-14configs: Migrate the various SPL_BOOT_xxx choices for PowerPCTom Rini
The non-CONFIG_SPL_FRAMEWORK SPL used on some PowerPC platforms have a choice between CONFIG_SPL_NAND_BOOT, CONFIG_SPL_MMC_BOOT and CONFIG_SPL_SPI_BOOT. Migrate this to Kconfig Signed-off-by: Tom Rini <trini@konsulko.com>
2019-06-14common: Fix a typo abnove -> aboveAndy Shevchenko
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-06-11Merge tag 'u-boot-imx-20190612' of git://git.denx.de/u-boot-imxTom Rini
u-boot-imx-20190612 -------------------- - Board fixes: - imx6logic - wandboard - mx6sabre boots again - imx8qm_mek - pico-* boards - Toradex apalis / colibri - engicam imx6 (environment) - KP MX53 - opos6ul - Switch to DM: - vining2000 - dh MX6 - Toradex colibri i.MX7 - Novena - Security : fix CSF size for HAB - Other: - imx: fix building for i.mx8 without spl - pcie and switch to DM mx6sabreauto: Enable SPL SDP support
2019-06-11spl: imx6: Provide a SPL_SIZE_LIMIT defaultFabio Estevam
As explained in include/configs/imx6_spl.h. the i.MX6 SPL size limit is 68KB (4KB header + 64KB max size). Provide such limit for all i.MX6 boards that use SPL to detect SPL size overflow in build time. Signed-off-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Lukasz Majewski <lukma@denx.de>
2019-06-10Merge tag 'video-updates-for-2019.07-rc3' of git://git.denx.de/u-boot-videoTom Rini
- mxsfb DM_VIDEO conversion - splash fix for DM_VIDEO configurations - meson HDMI fix for boards without hdmi-supply regulator
2019-06-10Merge tag 'u-boot-atmel-fixes-2019.07-a' of git://git.denx.de/u-boot-atmelTom Rini
First set of u-boot-atmel fixes for 2019.07 cycle
2019-06-08spl: Correct SPL_SIZE_LIMIT Kconfig optionTom Rini
When introduced this limit was an int but was then changed to hex without noting as much in the prompt nor changing existing users. Put this back to an int. Reported-by: Fabio Estevam <festevam@gmail.com> Tested-by: Fabio Estevam <festevam@gmail.com> Fixes: 2577015dc5c4 ("spl: add overall SPL size check") Signed-off-by: Tom Rini <trini@konsulko.com>
2019-06-07spl: add overall SPL size checkSimon Goldschmidt
This adds a size check for SPL that can dynamically check generated SPL binaries (including devicetree) for a size limit that ensures this image plus global data, heap and stack fit in initial SRAM. Since some of these sizes are not available to make, a new host tool 'spl_size_limit' is added that dumps the resulting maximum size for an SPL binary to stdout. This tool is used in toplevel Makefile to implement the size check on SPL binaries. Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
2019-06-06spl: at91: add support for SPL_AT91_MCK_BYPASSEugen Hristev
By default the configuration of the PMC is to have an external crystal connected that requires driving on both XIN and XOUT pins. The bypass configuration means that only XIN will be used, the SoC will not do any driving, and the XIN needs to be provided with a proper signal. This is the MOSCXTBY bit in the PMC main clock generator register. The SPL needs to properly initialize the PMC registers before switching to external clock signal and raising the clock to the cruise speed. Also created Kconfig for this specific configuration. By default this is disabled. Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
2019-06-04splash: display splash in DM_VIDEO configurationsIgor Opaniuk
Currently for CONFIG_DM_VIDEO=y setting splashimage env variable doesn't have any effect. Introduce a common function for both dm-video/lcd stacks, that checks env("splashimage") and invokes bmp_display() accordingly. For additional details please check discussion [1]. [1] https://lists.denx.de/pipermail/u-boot/2019-May/371002.html Signed-off-by: Igor Opaniuk <igor.opaniuk@toradex.com>
2019-05-24Merge tag 'u-boot-stm32-20190523' of https://github.com/pchotard/u-bootTom Rini
- Add various STM32MP1 fixes for serial, env, clk, board, i2c ... - Add STM32MP1 DDR driver update: These update introduce the DDR interactive mode described in: https://wiki.st.com/stm32mpu/index.php/U-Boot_SPL:_DDR_interactive_mode This mode is used by the CubeMX: DDR tuning tool. https://wiki.st.com/stm32mpu/index.php/STM32CubeMX The DDR interactive mode is NOT activated by default because it increase the SPL size and slow down the boot time (200ms wait added).
2019-05-23stm32mp1: ram: add interactive mode for DDR configurationPatrick Delaunay
This debug mode is used by CubeMX DDR tuning tools or manualy for tests during board bring-up. It is simple console used to change DDR parameters and check initialization. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2019-05-23stm32mp1: migrate PREBOOT to KconfigPatrick Delaunay
Use Kconfig to activate CONFIG_PREBOOT (empty by default). Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2019-05-21common: fdt_support: Check mtdparts cell sizeStefan Mavrodiev
When using fdt_fixup_mtdparts() offset and length cell sizes are limited to 4 bytes (1 cell). However if the mtd device is bigger then 4GiB, then #address-cells and #size-cells are 8 bytes (2 cells) [1]. This patch read #size-cells and uses either fdt32_t or fdt64_t cell size. The default is fdt32_t. [1] Documentation/devicetree/bindings/mtd/partition.txt Signed-off-by: Stefan Mavrodiev <stefan@olimex.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-05-21Merge tag 'video-for-2019.07-rc3' of git://git.denx.de/u-boot-videoTom Rini
- update for using splashfile instead of location->name when loading the splash image from a FIT - updates for loading internal and external splash data from FIT - DM_GPIO/DM_VIDEO migration for mx53 cx9020 board - fix boot issue on mx6sabresd board after DM_VIDEO migration - increase the max preallocated framebuffer BPP to 32 in ipuv3 driver to prepare for configurations with higher color depth - allow to use vidconsole_put_string() in board code for text output on LCD displays
2019-05-20splash: Load internal and external data from FITLeo Ruan
The FIT image could contain the splash data in 3 different structure: - The splash data is embedded in FIT image (internal) In this case, the property 'data' presents in FIT image header. And internal information 'start' and 'end' represent the location and size of splash data inside of FIT image. - The splash data is external with absolute position in FIT image This case is made by 'mkimage -p [pos]'. The splash data is stored at the absolute position. Instead the property 'data', the properties 'data-position' and 'data-size' are used to specify the location and size of the splash data. - the splash data is external with relative offset in FIT image This case is made by 'mkimage -E'. The splash data is placed after the FIT image header with 4 byte alignment. Instead the property 'data', the properties 'data-offset' and 'data-size' are used to specify the location and size of the splash data. Currently, the splash only support to load external data with relative offset from FIT image. This commit make it possible to load the splash data embedded in FIT image or the external data with absolute position This inspiration comes from Simon Glass <sjg@chromium.org>, see common/spl_fit.c Signed-off-by: Leo Ruan <tingquan.ruan@cn.bosch.com> Signed-off-by: Mark Jonas <mark.jonas@de.bosch.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stefano Babic <sbabic@denx.de>
2019-05-20splash: Use splashfile instead of location->nameLeo Ruan
The splash image could be loaded from different sources (e.g. sf, mmc) with different formats (e.g. raw, file-system). These sources are structured by a board dependent object 'splash_location'. To decide where is the splash image loaded, following environment variables are used to select the splash source and file: - 'splashsource' is used to select the splash source by setting its value to specified name of splash location. - 'splashfile' specify the name of splash image file But, when loads the splash image from FIT, the name of splash image within FIT is specified by splash location name. Due to the splash location name is already used for the splash source, its name may conflicts with the name of splash image. To solve the conflict, the environment variable 'splashfile' is used to specify the splash image in FIT, and keeps the splash location name for the splash source. Signed-off-by: Leo Ruan <tingquan.ruan@cn.bosch.com> Signed-off-by: Mark Jonas <mark.jonas@de.bosch.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stefano Babic <sbabic@denx.de> Reviewed-by: Tomas Melin <tomas.melin@vaisala.com>
2019-05-18spl: Set spl_image->fdt_addr pointer for full fitImage configurationMarek Vasut
Set the spl_image->fdt_addr pointer both for simple fitImage configuration as well as full fitImage configuration, to let spl_perform_fixups() access the DT and perform modifications to it if necessary. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@konsulko.com>
2019-05-18CONFIG_SPL_SYS_[DI]CACHE_OFF: addTrevor Woerner
While converting CONFIG_SYS_[DI]CACHE_OFF to Kconfig, there are instances where these configuration items are conditional on SPL. This commit adds SPL variants of these configuration items, uses CONFIG_IS_ENABLED(), and updates the configurations as required. Acked-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Trevor Woerner <trevor@toganlabs.com> [trini: Make the default depend on the setting for full U-Boot, update more zynq hardware] Signed-off-by: Tom Rini <trini@konsulko.com>
2019-05-09fdt_shrink_to_minimum: do not mark fdt space reserved unconditionallySimon Goldschmidt
This function merely relocates the fdt blob, so don't let it alter it by adding reservations that didn't exist before. Instead, if the memory used for the fdt blob has been reserved before calling this function, ensure the relocated memory is marked as reserved instead. Reported-by: Keerthy <j-keerthy@ti.com> Reported-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-09Make FIT support really optionalFabrice Fontaine
Due to some mistakes in the source code, it was not possible to really turn FIT support off. This commit fixes the problem by means of the following changes: - Enclose "bootm_host_load_image" and "bootm_host_load_images" between checks for CONFIG_FIT_SIGNATURE, in common/bootm.c. - Enclose the declaration of "bootm_host_load_images" between checks for CONFIG_FIT_SIGNATURE, in common/bootm.h. - Condition the compilation and linking of fit_common.o fit_image.o image-host.o common/image-fit.o to CONFIG_FIT=y, in tools/Makefile. Signed-off-by: Carlos Santos <casantos@datacom.ind.br> [fabio: adapt for 2016.07] Signed-off-by: Fabio Estevam <festevam@gmail.com> [Ricardo: fix conditional compilation and linking of the files mentioned above for 2016.07] Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> [Jörg: adapt for 2019.01] Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks> [Retrieved from: https://git.buildroot.net/buildroot/tree/package/uboot-tools/0003-Make-FIT-support-really-optional.patch] Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
2019-05-09Fix spelling of available.Vagrant Cascadian
Signed-off-by: Vagrant Cascadian <vagrant@debian.org>
2019-05-05spl: fit: Always enable tracking of os-type if SPL_OS_BOOT is enabledJean-Jacques Hiblot
FIT_IMAGE_TINY is used to reduce the size of the SPL by removing os-type tracking and recording the loadables into the loaded FDT. When this option is enabled, it is assumed that the next stage firmware is u-boot. However this does not play well with the SPL_OS_BOOT option that enables loading different type of next stage firmware, like the OS itself. When SPL_OS_BOOT is used, do not disable os-tracking. The added footprint is about 300 Bytes. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-04-29configs: move CONFIG_SPL_TEXT_BASE to KconfigSimon Goldschmidt
Moved CONFIG_SPL_TEXT_BASE to common/spl/Kconfig and migrate existing values. Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> [trini: Re-run migration] Signed-off-by: Tom Rini <trini@konsulko.com>
2019-04-26avb: add support for named persistent valuesIgor Opaniuk
AVB 2.0 spec. revision 1.1 introduces support for named persistent values that must be tamper evident and allows AVB to store arbitrary key-value pairs [1]. Introduce implementation of two additional AVB operations read_persistent_value()/write_persistent_value() for retrieving/storing named persistent values. Correspondent pull request in the OP-TEE OS project repo [2]. [1]: https://android.googlesource.com/platform/external/avb/+/android-9.0.0_r22 [2]: https://github.com/OP-TEE/optee_os/pull/2699 Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Igor Opaniuk <igor.opaniuk@gmail.com>
2019-04-26main: add new bootstage ID for entering cli loopHeiko Schocher
adding a new bootstage ID: BOOTSTAGE_ID_ENTER_CLI_LOOP Signed-off-by: Heiko Schocher <hs@denx.de>
2019-04-26watchdog: Implement generic watchdog_reset() versionStefan Roese
This patch tries to implement a generic watchdog_reset() function that can be used by all boards that want to service the watchdog device in U-Boot. This watchdog servicing is enabled via CONFIG_WATCHDOG. Without this approach, new boards or platforms needed to implement a board specific version of this functionality, mostly copy'ing the same code over and over again into their board or platforms code base. With this new generic function, the scattered other functions are now removed to be replaced by the generic one. The new version also enables the configuration of the watchdog timeout via the DT "timeout-sec" property (if enabled via CONFIG_OF_CONTROL). This patch also adds a new flag to the GD flags, to flag that the watchdog is ready to use and adds the pointer to the watchdog device to the GD. This enables us to remove the global "watchdog_dev" variable, which was prone to cause problems because of its potentially very early use in watchdog_reset(), even before the BSS is cleared. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Heiko Schocher <hs@denx.de> Cc: Tom Rini <trini@konsulko.com> Cc: Michal Simek <michal.simek@xilinx.com> Cc: "Marek Behún" <marek.behun@nic.cz> Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Cc: Maxim Sloyko <maxims@google.com> Cc: Erik van Luijk <evanluijk@interact.nl> Cc: Ryder Lee <ryder.lee@mediatek.com> Cc: Weijie Gao <weijie.gao@mediatek.com> Cc: Simon Glass <sjg@chromium.org> Cc: "Álvaro Fernández Rojas" <noltari@gmail.com> Cc: Philippe Reynes <philippe.reynes@softathome.com> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Reviewed-by: Michal Simek <michal.simek@xilinx.com> Tested-by: Michal Simek <michal.simek@xilinx.com> (on zcu100)
2019-04-24Merge tag 'pull-24apr19' of git://git.denx.de/u-boot-dmTom Rini
Various minor sandbox iumprovements Fixes for tracing with sandbox Refactoring for boot_get_fdt()
2019-04-24image: android: fix 'iminfo' typoEugeniu Rosca
Fix below CP warning triggered by the 'iminfo' output in another patch: WARNING: 'addrress' may be misspelled - perhaps 'address'? Fixes: 4f1318b29c7a20 ("common: image: minimal android image iminfo support") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Acked-by: Marek Vasut <marek.vasut@gmail.com>
2019-04-24image: android: allow booting lz4-compressed kernelsEugeniu Rosca
According to Android image format [1], kernel image resides at 1 page offset from the boot image address. Grab the magic number from there and allow U-Boot to handle LZ4-compressed KNL binaries instead of hardcoding compression type to IH_COMP_NONE. Other compression types, if needed, can be added later. Tested on H3ULCB-KF using the image detailed in [2]. [1] Excerpt from include/android_image.h +-----------------+ | boot header | 1 page +-----------------+ | kernel | n pages +-----------------+ | ramdisk | m pages +-----------------+ | second stage | o pages +-----------------+ [2] => iminfo 4c000000 ## Checking Image at 4c000000 ... Android image found kernel size: 85b9d1 kernel address: 48080000 ramdisk size: 54ddbc ramdisk addrress: 4a180000 second size: 0 second address: 48000800 tags address: 48000100 page size: 800 os_version: 1200012a (ver: 0.9.0, level: 2018.10) name: cmdline: buildvariant=userdebug Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
2019-04-23bootstage: Allow calling bootstage_mark() before bootstage_init()Simon Glass
It is possible for this to happen if something goes wrong very early in the init sequence. Add a check for this. Signed-off-by: Simon Glass <sjg@chromium.org>
2019-04-23sandbox: Improve debugging in initcall_run_list()Simon Glass
At present if one of the initcalls fails on sandbox the address printing is not help, e.g.: initcall sequence 0000557678967c80 failed at call 00005576709dfe1f (err=-96) This is because U-Boot gets relocated high into memory and the relocation offset (gd->reloc_off) does not work correctly for sandbox. Add support for finding the base address of the text region (at least on Linux) and use that to set the relocation offset. This makes the output better: initcall sequence 0000560775957c80 failed at call 0000000000048134 (err=-96) Then you use can use grep to see which init call failed, e.g.: $ grep 0000000000048134 u-boot.map stdio_add_devices Of course another option is to run it with a debugger such as gdb: $ gdb u-boot ... (gdb) br initcall.h:41 Breakpoint 1 at 0x4db9d: initcall.h:41. (2 locations) Note that two locations are reported, since this function is used in both board_init_f() and board_init_r(). (gdb) r Starting program: /tmp/b/sandbox/u-boot [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". U-Boot 2018.09-00264-ge0c2ba9814-dirty (Sep 22 2018 - 12:21:46 -0600) DRAM: 128 MiB MMC: Breakpoint 1, initcall_run_list (init_sequence=0x5555559619e0 <init_sequence_f>) at /scratch/sglass/cosarm/src/third_party/u-boot/files/include/initcall.h:41 41 printf("initcall sequence %p failed at call %p (err=%d)\n", (gdb) print *init_fnc_ptr $1 = (const init_fnc_t) 0x55555559c114 <stdio_add_devices> (gdb) Signed-off-by: Simon Glass <sjg@chromium.org>
2019-04-23common: command: Add command execution tracer.Christoph Muellner
When using boot scripts it can become quite hard to understand which commands are actually executed during bootup (e.g. where is a kernel image loaded from or which DTB is in use). Shell scripts suffer from a similar problem and many shells address this problem with a command execution tracer (e.g. BASH has xtrace, which can be enabled by "set -x"). This patch introduces a command tracer for U-Boot, which prints every command with its arguments before it is executed. Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
2019-04-23fdt: boot_get_fdt: android: use ENV 'fdtaddr' as fallbackEugeniu Rosca
Our platform doesn't store the DTB into the Android image second area, but rather copies the DTB to RAM from a dedicated dtb.img partition [0], prior to booting the Android image by calling bootm. Similar to [1], we find it useful to just call 'bootm' and have the right DTB being passed to OS (assuming its address has been previously stored in 'fdtaddr' by calling `fdt addr <dtb-addr>`). Booting Android with DTB from 'fdtaddr' will only occur if: - No DTB is embedded in the second area of Android image - 'fdtaddr' points to a valid DTB in RAM [0] https://source.android.com/devices/architecture/dto/partitions [1] https://patchwork.ozlabs.org/patch/1046652/ ("Support boot Android image without address on bootm command") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-04-23fdt: boot_get_fdt: android: compress handling (non-functional)Eugeniu Rosca
Prepare for booting Android images which lack any DTB in the second area by using 'fdtaddr' environment variable as source/address of FDT. No functional/behavioral change expected in this patch. Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-04-23fdt: boot_get_fdt: simplify no_fdt handling (non-functional)Eugeniu Rosca
Increase the readability of boot_get_fdt(). No change in behavior is expected. Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-04-23fdt: boot_get_fdt: really boot w/o FDT when "goto no_fdt"Eugeniu Rosca
The 'no_fdt' goto label was introduced by v2015.01 commit [0] and it had two review stages [1-2]. The *documented* purpose behind commit [0] is (excerpt from commit description): > allows both FDT and non-FDT kernels to boot by making the > third parameter to the bootm/bootz optional While [1] and [2] share the same goal, they have very different implementations: - [1] was based on a very simple 'argc' check at function error out with returning success to the caller if the third parameter was NOT passed to bootm/bootz command. This approach had the downside of returning success to the caller even in case of legitimate internal errors, which should halt booting. - [2] added the "no_fdt" label and several "goto no_fdt" statements. This allowed to report the legitimate internal errors to the caller. IOW the major difference between [1] and [2] is: - [1] boot w/o FDT if FDT address is not passed to boot{m,z,*} - [2] give *freedom* to the developer to boot w/o FDT from any (more or less) arbitrary point in the function flow (and here comes the peculiar aspect, which looks to be a leftover from [1]) with the precondition that the 3rd argument (FDT address) is NOT provided to boot{m,z,*}. In practice, this means that only a subset of "goto no_fdt" end up booting w/o FDT while the other subset is returning an error to the caller. This patch removes the peculiar behavior described above, such that "goto no_fdt" performs really what it tells to the developer. The motivation of this patch is to decrease the unneeded complexity and increase the readability of boot_get_fdt(). [0] 48aead71c1ad ("fdt: Allow non-FDT kernels to boot when CONFIG_OF_LIBFDT is defined") [1] https://patchwork.ozlabs.org/patch/412923/ ("[U-Boot,v1] fdt: Allow non-FDT kernels to boot when CONFIG_OF_LIBFDT is defined") [2] https://patchwork.ozlabs.org/patch/415635/ ("[U-Boot,v2] fdt: Allow non-FDT kernels to boot when CONFIG_OF_LIBFDT is defined") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-04-23fdt: boot_get_fdt: remove redundant zeroing outEugeniu Rosca
Paranoid programming [1] lies at the foundation of proper software development, but the repetitive zeroing-out of output arguments in the context of the same function rather clutters the code and inhibits further refactoring/optimization than is doing any good. In boot_get_fdt(), we already perform zero/NULL-initialization of *of_flat_tree and *of_size at the beginning of the function, so doing the same at function error-out is redundant/superfluous. Moreover, keeping the code unchanged might encourage the developers to update *of_flat_tree and *of_size during some interim computations, which is against the current design of boot_get_fdt(). Currently, writing useful data into these arguments happens just before successfully returning from boot_get_fdt() and it should better stay so. [1] https://blog.regehr.org/archives/1106 Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-04-23bootm: Simplying cache flush codeTrent Piepho
The cache flush of the kernel load area needs to be aligned outward to the DMA cache alignment. The operations are simpler if we think of this as aligning the start down, ALIGN_DOWN(load, ARCH_DMA_MINALIGN), and aligning the end up, ALIGN(load_end, ARCH_DMA_MINALIGN), and then find the length of the flushed region by subtracting the former from the latter. Cc: Tom Rini <trini@konsulko.com> Cc: Simon Glass <sjg@chromium.org> Cc: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Trent Piepho <tpiepho@impinj.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-04-23malloc: Fix memalign not honoring alignment prior to full malloc initAndreas Dannenberg
When using memalign() in a scenario where U-Boot is configured for full malloc support with simple malloc not explicitly enabled and before the full malloc support is initialized, a memory block is being allocated and returned without the alignment parameter getting honored. Fix this issue by replacing the existing memalign pre-full malloc init logic with a call to memalign_simple() this way ensuring proper alignment of the returned memory block. Fixes: ee038c58d519 ("malloc: Use malloc simple before malloc is fully initialized in memalign()") Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-04-23spl: spl_nand.c: Add NAND loading messageStefan Roese
This patch adds a short message to the SPL NAND loader, which displays the source and destinations addresses including the size of the loaded image, like this: U-Boot SPL 2019.04-rc3-00113-g486efd8aaf (Mar 15 2019 - 14:18:02 +0100) Trying to boot from NAND Loading U-Boot from 0x00040000 (size 0x000a0000) to 0x22900000 I find this message quite helpful - hopefully others do so as well. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Heiko Schocher <hs@denx.de> Cc: Tom Rini <trini@konsulko.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2019-04-22spl: ymodem: Add support for loading full fitImagesMarek Vasut
Add support for loading fully featured fitImages over YModem in SPL. This is useful when various advanced features of full fitImages are needed in SPL. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@konsulko.com>
2019-04-22fit: load all fragments from the extra configurationsPeter Ujfalusi
Currently only the first fdt is loaded from the extra configuration of FIT image. If the configuration have multiple fdt, load them all as well. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-04-22Support boot Android image without address on bootm commandShawn Guo
It works perfectly fine to boot an Android boot.img with bootm command followed by an explicit address argument that holds the image. But if we have boot.img downloaded into default 'loadaddr', and then boot it using bootm command without the address argument, we will run into problem, because U-Boot fails to find ramdisk and fdt (second area) in boot.img. The current Android image support assumes there is always an address argument on bootm command. However just like booting any other images, 'loadaddr' should be used when address argument is missing from bootm command. It patches boot_get_ramdisk() and boot_get_fdt() a bit to support this quite common usage of bootm command for Android image. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2019-04-15Merge tag 'efi-2019-07-rc1-2' of git://git.denx.de/u-boot-efiTom Rini
Pull request for UEFI sub-system for v2019.07-rc1 (2) In the aarch64 crash dump information about the loaded EFI images is added. In README.uefi the development target is for the UEFI subsystem is described as "Embedded Base Boot Requirements (EBBR) Specification" compliance. Several bug fixes are supplied.
2019-04-15Merge tag 'video-for-2019.07-rc1' of git://git.denx.de/u-boot-videoTom Rini
- optional backlight PWM polarity config via polarity cell - bug fix for ASCII characters > 127 - ANSI sequence handling extensions (implement clear line, reverse video and relative cursor movement commands) - preparation for doing character set translations - left/right and up/down arrow keys translation to ANSI control sequences for cursor movement to fix selection with an USB keyboard in bootmenu - CONFIG_SYS_WHITE_ON_BLACK font scheme configuration for sunxi boards
2019-04-14usb: kbd: Properly translate up/down arrow keysAndre Przywara
So far arrows key pressed on an USB keyboard got translated to some low ASCII control sequences (Ctrl+N, Ctrl+P). Some programs understand these codes, but the standard for those keys is to use ANSI control sequences for cursor movement (ESC [ A). Our own boot menu is a victim of this, currently we cannot change the selection with an USB keyboard due to this. Since we already implement a queue for USB key codes, we can just insert the three character ANSI sequence into the key buffer. This fixes the bootmenu, and is more universal for other users (UEFI) as well. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-04-14Merge branch 'master' of git://git.denx.de/u-boot-spiTom Rini
Conflicts: arch/arm/dts/armada-385-amc.dts arch/arm/dts/armada-xp-theadorable.dts arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi Signed-off-by: Tom Rini <trini@konsulko.com>
2019-04-12efi_loader: move efi_save_gd() call to board_r.cHeinrich Schuchardt
The first functions of the UEFI sub-system are invoked before reaching the U-Boot shell, e.g. efi_set_bootdev(), efi_dp_from_name(), efi_dp_from_file(). We should be able to print out device paths for debugging purposes here. When printing device paths via printf("%pD\n", dp) this invokes functions defined as EFIAPI. So efi_save_gd() must be called beforehand. So let's move the efi_save_gd() call to function initr_reloc_global_data(() in board_r.c. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-04-12dm: spi: Read default speed and mode values from DTPatrick Delaunay
This patch update the behavior introduced by commit 96907c0fe50a ("dm: spi: Read default speed and mode values from DT") In case of DT boot, don't read default speed and mode for SPI from CONFIG_* but instead read from DT node. This will make sure that boards with multiple SPI/QSPI controllers can be probed at different bus frequencies and SPI modes. Remove also use in boards of the value speed=0 (no more supported) for ENV in SPI by using CONFIG_ENV_SPI_MAX_HZ=0. DT values will be always used when available (full DM support of SPI slave with available DT node) even if speed and mode are requested; for example in splash screen support (in splash_sf_read_raw) or in SPL boot (in spl_spi_load_image). The caller of spi_get_bus_and_cs() no more need to force speed=0. But the current behavior don't change if the SPI slave is not present (device with generic driver is created automatically) or if platdata is used (CONFIG_OF_PLATDATA). Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Acked-by: Jagan Teki <jagan@amarulasolutions.com>
generated by cgit (git 2.34.1) at 2024-12-24 02:12:09 +0000