1. 07 May, 2020 14 commits
    • Michael Gloff's avatar
    • Tom Rini's avatar
      Merge branch '2020-05-06-master-imports' · 69bf66ad
      Tom Rini authored
      - ARM Juno updates
      - Assorted bugfixes
    • Thirupathaiah Annapureddy's avatar
      menu: add support for client defined statusline function · 5168d7a6
      Thirupathaiah Annapureddy authored
      Currently displaying status line is done in a weak function
      bootmenu.c overrides the weak default function.
      It calls menu_default_choice() and interprets the data as
      struct bootmenu_entry.
      pxe boot also uses common menu code for pxe menus.
      If there is a system that enables both bootmenu and pxe,
      menu_display_statusline() defined in bootmenu.c will be called
      and it will interpret struct pxe_label as struct bootmenu_entry.
      This leads to data aborts and pxe menu corruptions.
      This patch adds support for client defined statusline function
      to resolve the above bug.
      Signed-off-by: default avatarThirupathaiah Annapureddy <thiruan@linux.microsoft.com>
    • Heiko Stuebner's avatar
      rsa: fix alignment issue when getting public exponent · fdf0819a
      Heiko Stuebner authored
      To fill the exponent field of the rsa_public_key struct, rsa_mod_exp_sw
      did a cast to uint64_t of the key_prop->public_exponent field.
      But that alignment is not guaranteed in all cases.
      This came to light when in my spl-fit-signature the key-name exceeded
      a certain length and with it the verification then started failing.
      (naming it "integrity" worked fine, "integrity-uboot" failed)
      key_prop.public_exponent itself is actually a void-pointer, fdt_getprop()
      also just returns such a void-pointer and inside the devicetree the 64bit
      exponent is represented as 2 32bit numbers, so assuming a 64bit alignment
      can lead to false reads.
      So just use the already existing rsa_convert_big_endian() to do the actual
      conversion from the dt's big-endian to the needed uint64 value.
      Fixes: fc2f4246
       ("rsa: Split the rsa-verify to separate the modular exponentiation")
      Signed-off-by: default avatarHeiko Stuebner <heiko.stuebner@theobroma-systems.com>
      Reviewed-by: default avatarPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
    • Patrice Chotard's avatar
      cmd: cache: Fix non-cached memory cachability · c2a2123e
      Patrice Chotard authored
      If dcache is switched OFF to ON state and if non-cached memory is
      used, this non-cached memory must be re-declared as uncached to mmu
      each time dcache is set ON.
      Introduce noncached_set_region() to set this non-cached region's mmu
      settings. Let architecture override it by defining it as a weak
      For ARM architecture, noncached_set_region() defines all noncached
      region as non-cacheable.
      Issue found on STM32MP1 platform using dwc_eth_qos ethernet driver,
      when going from dcache OFF to dcache ON state, ethernet driver issued
      TX timeout errors when performing dhcp or ping.
      It can be reproduced with the following sequence:
      while true ; do
        ping ;
        dcache off ;
        ping ;
        dcache on ;
      Signed-off-by: default avatarPatrice Chotard <patrice.chotard@st.com>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Joe Hershberger <joe.hershberger@ni.com>
      Cc: Ramon Fried <rfried.dev@gmail.com>
      Cc: Stephen Warren <swarren@nvidia.com>
      Reviewed-by: default avatarMarek Vasut <marex@denx.de>
    • Andre Przywara's avatar
      arm: vexpress64: Remove unneeded CONFIG_ check · af6d4c05
      Andre Przywara authored
      CONFIG_SEMIHOSTING is selected for the VFP target by the means of
      Kconfig already, there is no need to check this in the header file.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
    • Andre Przywara's avatar
      arm: juno: enable USB · 56e403d9
      Andre Przywara authored
      The Juno board features a standard compliant EHCI/OHCI USB host
      controller pair, which we can just enable.
      The platform data is taken from the device tree.
      This allows to use USB mass storage (the only storage on a Juno r0)
      for loading.
      At least on my board USB seems a bit flaky, I need two "usb reset"
      sequences after the "usb start" to detect an USB hard drive.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Acked-by: default avatarLiviu Dudau <liviu.dudau@arm.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
    • Andre Przywara's avatar
      arm: juno: Use PSCI based reset · be0d0969
      Andre Przywara authored
      So far the Juno board wasn't implementing reset. Let's just use the
      already existing PSCI_RESET based method to avoid any extra code.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Acked-by: default avatarLiviu Dudau <liviu.dudau@arm.com>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
    • Andre Przywara's avatar
      arm: juno: Enable OF_CONTROL · b3270e91
      Andre Przywara authored
      The Arm Juno board was still somewhat stuck in "hardcoded land", even
      though there are stable DTs around, and one happens to actually be on
      the memory mapped NOR flash.
      Enable the configuration options to let the board use OF_CONTROL, and
      add a routine to find the address of the DTB partition in NOR
      flash, to use that for U-Boot's own purposes.
      This can also passed on via $fdtcontroladdr to any kernel or EFI
      application, removing the need to actually load a device tree.
      Since the existing "afs" command and its flash routines require
      flash_init() to be called before being usable, and this is done much
      later in the boot process, we introduce a stripped-down partition finder
      routine in vexpress64.c, to scan the NOR flash partitions for the
      DT partition. This location is then used for U-Boot to find and probe
      The name of the partition can be configured, if needed, but defaults
      to "board.dtb", which is used by Linaro's firmware image provided.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
    • Andre Przywara's avatar
      arm: juno: Fix UART clock rate · deaa511d
      Andre Przywara authored
      The UART base clock rate was typo-ed in the header file, probably because
      the reference (the Linux .dts) was also wrong[1].
      Fix the number to make the baud rate more correct.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=39a1a8941b2
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
    • Andre Przywara's avatar
      uart: pl011: Add proper DM clock support · e3e2d662
      Andre Przywara authored
      Even though the PL011 UART driver claims to be DM compliant, it does not
      really a good job with parsing DT nodes. U-Boot seems to adhere to a
      non-standard binding, either requiring to have a "skip-init" property in
      the node, or to have an extra "clock" property holding the base
      *frequency* value for the baud rate generator.
      DTs in the U-Boot tree seem to have been hacked to match this
      The official binding does not mention any of these properties, instead
      recommends a standard "clocks" property to point to the baud base clock.
      Some boards use simple "fixed-clock" providers, which U-Boot readily
      supports, so let's add some simple DM clock code to the PL011 driver to
      learn the rate of the first clock, as described by the official binding.
      These clock nodes seem to be not ready very early in the boot process,
      so provide a fallback value, by re-using the already existing
      CONFIG_PL011_CLOCK variable.
      Signed-off-by: Andre Przywara <andre.przywara@arm.com>...
    • Andre Przywara's avatar
      arm: juno: Fix Juno address variables · 7d6dae0d
      Andre Przywara authored
      The U-Boot documentation explains that variables ending with "_r" hold
      addresses in DRAM, while those without that ending point to flash/ROM.
      The default variables for the Juno board pointing to the kernel and DTB
      load addresses were not complying with this scheme: they lack the
      extension, but point to DRAM. This is particularly confusing since the
      Juno board features parallel NOR flash, so there *is* a memory mapped
      NOR address holding a DTB, for instance.
      Fix the variables to use the proper names, changing initrd_addr to
      ramdisk_addr_r on the way, which seems to be more prevelant and
      documented. On the way adjust the FDT load address to be situated
      *before* the kernel, since users happened to overwrite the DTB by the
      kernel clearing its .BSS section during initialisation.
      Also remove the fdt_high and initrd_high variables (which were set
      to -1), to allow U-Boot moving those images around.
      This should avoid many problems in the future, but breaks loading
      Linux kernels < v4.2, since they expect the DTB to be loaded in the same
      512MB region as the kernel. If you need to load such an old kernel,
      please set fdt_high to either 0xffffffffffffffff or 0xa0000000 (if you
      load the kernel to the beginning of DRAM).
      That fixes loading debug kernels, which happened to overwrite the DTB on
      certain setups.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
    • Rasmus Villemoes's avatar
      include/eeprom.h: fix build errors · 682fef9f
      Rasmus Villemoes authored
      CMD_EEPROM and ENV_IS_IN_EEPROM can be selected independently, and
      cmd/eeprom.o gets built in either case, so whether to declare the real
      prototypes needs to follow the same logic as whether cmd/eeprom.c is
      built. Otherwise a ENV_IS_IN_EEPROM=y, CMD_EEPROM=n build fails
      cmd/eeprom.c:73:1: error: expected identifier or ‘(’ before ‘{’ token
      While at it, fix the dummy replacements (at least assuming they are
      meant to allow the code to compile) - they need to have the same type
      as the expression they replace, or one gets errors such as
      env/eeprom.c: In function ‘eeprom_bus_read’:
      env/eeprom.c:37:8: error: void value not ignored as it ought to be
        rcode = eeprom_read(dev_addr, offset, buffer, cnt);
      Signed-off-by: default avatarRasmus Villemoes <rasmus.villemoes@prevas.dk>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
    • Tom Rini's avatar
      Revert "mkimage: fit: Do not tail-pad fitImage with external data" · 7946a814
      Tom Rini authored
      This has been reported to break booting of U-Boot from SPL on a number
      of platforms due to a lack of alignment of the external data.  The
      issues this commit is addressing will need to be resolved another way.
      Re-introduce a data leak in the padding for now.
      This reverts commit 20a154f9
      Reported-by: default avatarAlex Kiernan <alex.kiernan@gmail.com>
      Reported-by: default avatarMichael Walle <michael@walle.cc>
      Tested-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
  2. 06 May, 2020 2 commits
  3. 05 May, 2020 3 commits
  4. 04 May, 2020 21 commits