1. 07 5月, 2020 5 次提交
    • 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 32 次提交