1. 07 5月, 2020 9 次提交
    • A
      arm: juno: Use PSCI based reset · be0d0969
      Andre Przywara 提交于
      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: NAndre Przywara <andre.przywara@arm.com>
      Acked-by: NLiviu Dudau <liviu.dudau@arm.com>
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      be0d0969
    • A
      arm: juno: Enable OF_CONTROL · b3270e91
      Andre Przywara 提交于
      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
      devices.
      
      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: NAndre Przywara <andre.przywara@arm.com>
      Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      b3270e91
    • A
      arm: juno: Fix UART clock rate · deaa511d
      Andre Przywara 提交于
      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: NAndre Przywara <andre.przywara@arm.com>
      Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
      
      [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=39a1a8941b2Reviewed-by: NSimon Glass <sjg@chromium.org>
      deaa511d
    • A
      uart: pl011: Add proper DM clock support · e3e2d662
      Andre Przywara 提交于
      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
      requirement.
      
      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: NAndre Przywara <andre.przywara@arm.com>
      [trini: Add <clock_legacy.h> for get_bus_freq() for layerscape
      platforms]
      Signed-off-by: NTom Rini <trini@konsulko.com>
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      e3e2d662
    • A
      arm: juno: Fix Juno address variables · 7d6dae0d
      Andre Przywara 提交于
      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: NAndre Przywara <andre.przywara@arm.com>
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      7d6dae0d
    • R
      include/eeprom.h: fix build errors · 682fef9f
      Rasmus Villemoes 提交于
      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: NRasmus Villemoes <rasmus.villemoes@prevas.dk>
      Reviewed-by: NTom Rini <trini@konsulko.com>
      682fef9f
    • T
      Revert "mkimage: fit: Do not tail-pad fitImage with external data" · 7946a814
      Tom Rini 提交于
      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: NAlex Kiernan <alex.kiernan@gmail.com>
      Reported-by: NMichael Walle <michael@walle.cc>
      Tested-by: NJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: NTom Rini <trini@konsulko.com>
      7946a814
    • L
      cache: l2x0: Fix missing write to Auxiliary Control Register · 653f7c44
      Ley Foon Tan 提交于
      In commit f62782fb ("cache: l2x0: Fix write to incorrect shared-override
      bit") we removed writel to regs->pl310_aux_ctrl by accident.  This
      commit restores it back.
      
      Fixes: f62782fb ("cache: l2x0: Fix write to incorrect shared-override bit")
      Signed-off-by: NLey Foon Tan <ley.foon.tan@intel.com>
      653f7c44
    • R
      scripts/get_default_envs.sh: preserve order of multiple entries for same variable · 15c16030
      Rasmus Villemoes 提交于
      It's possible that the default_environment[] array contains multiple
      entries for the same variable, e.g. a setting from env_default.h based
      on some CONFIG_* variable, and another from
      CONFIG_EXTRA_ENV_SETTINGS. In such a case, the last setting takes
      effect.
      
      Hence, in order to be able to use the output from this script as an
      CONFIG_DEFAULT_ENV_FILE and get the same default environment as one
      currently has, we need to preserve the order. So only sort by the
      variable name, and disable the last-resort comparison.
      
      We could pipe the result through uniq to remove duplicate lines, but I
      think there's some value in seeing that certain variables are defined
      multiple times.
      Signed-off-by: NRasmus Villemoes <rasmus.villemoes@prevas.dk>
      Reviewed-by: NLukasz Majewski <lukma@denx.de>
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      15c16030
  2. 06 5月, 2020 2 次提交
  3. 05 5月, 2020 1 次提交
  4. 04 5月, 2020 28 次提交