1. 30 May, 2021 1 commit
    • André Przywara's avatar
      sunxi: Bring back SD card as MMC device 0 · 67854347
      André Przywara authored
      Commit 2243d19e
      
       ("mmc: mmc-uclass: Use dev_seq() to read aliases
      node's index") now actually enforces U-Boot's device enumeration policy,
      where explicitly named devices come first, then any other non-named
      devices follow, without filling gaps.
      
      For quite a while we have had an "mmc1 = &mmc2;" alias in our
      sunxi-u-boot.dtsi, which now leads to the problem that the SD card
      (which was always mmc device 0) now gets to be number 2.
      This breaks quite some boot scripts, including our own distro boot
      commands, and some other features looking at $mmc_bootdev, also
      fastboot.
      
      Just add an explicit mmc0 alias in the very same file to fix this and
      restore the old behaviour.
      Signed-off-by: André Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      Reported-by: default avatarSamuel Holland <samuel@sholland.org>
      Tested-by: default avatarSimon Baatz <gmbnomis@gmail.com>
      67854347
  2. 16 Apr, 2021 2 commits
  3. 31 Mar, 2021 1 commit
    • André Przywara's avatar
      sunxi: H616: Change TF-A load address to beginning of DRAM · c629ba85
      André Przywara authored
      
      
      Loading Trusted-Firmware's BL31 at 16KB into DRAM was originally a hack
      to allow sharing more code with the other SoCs (which use this offset
      in SRAM). However there is no longer a reason for that, as the
      problematic macros have been properly separated there.
      
      The latest (and hopefully final) TF-A code drop now changes the load
      address to the beginning of DRAM, which is also more easily protected
      by the Trustzone memory controller (code to be done).
      
      Adjust the load address of BL31 now, to avoid any issues with
      incompatible versions later on (the TF-A patches are about to be merged).
      Signed-off-by: André Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      Reviewed-by: default avatarSamuel Holland <samuel@sholland.org>
      c629ba85
  4. 25 Jan, 2021 1 commit
  5. 22 Oct, 2020 5 commits
  6. 22 Sep, 2020 2 commits
  7. 30 Jan, 2019 1 commit
    • Jagan Teki's avatar
      arm: dts: sunxi: Alter mmc2 auto-numbering to mmc1 · 708b5da3
      Jagan Teki authored
      
      
      Environment and fastboot mmc devices are configured based on the number
      of mmc slots defined on particular board configs, MMC_SUNXI_SLOT_EXTRA.
      
      If MMC_SUNXI_SLOT_EXTRA is more than 1, the default env and fastboot
      mmc devices is mmc1 by assuming mmc0 is SD and mmc1 is emmc device.
      
      But with DM_MMC the mmc devices are numbered as per the dts node
      enablement. If there is a chance of having enabling all mmc nodes
      in dts say mmc0, mmc1, mmc2 then the default env and fastboot devices
      will failed to assign proper emmc device since mmc2 is emmc in most
      of the Allwinner platforms.
      
      So, we need to alter the auto-numbering by aliasing mmc2 to mmc1 since
      aliases take precedence over auto-numbering.
      
      If the dts enables mmc0, mmc1, mmc2, then all the nodes will probe
      sequentially and auto-numbered as it is. but when aliases mmc1 with mmc2
      the resulting number should be that mmc0 is till mmc0, mmc2 become mmc1
      and mmc2 become mmc1
      
      Without aliases of mmc1 = &mmc2;
      -------------------------------
      MMC:   mmc@1c0f000: 0, mmc@1c10000: 1, mmc@1c11000: 2
      
      With aliases of mmc1 = &mmc2;
      ----------------------------
      MMC:   Device 'mmc@1c11000': seq 1 is in use by 'mmc@1c10000'
      mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1
      Loading Environment from FAT... OK
      
      Some platforms like A20 has mmc0...mmc3, but there is no usecases now
      for enabling all mmc controllers in any of A20 board dts files.
      Signed-off-by: Jagan Teki's avatarJagan Teki <jagan@amarulasolutions.com>
      708b5da3
  8. 01 Aug, 2018 1 commit
    • Simon Glass's avatar
      binman: Rename 'position' to 'offset' · 3ab9598d
      Simon Glass authored
      
      
      After some thought, I believe there is an unfortunate naming flaw in
      binman. Entries have a position and size, but now that we support
      hierarchical sections it is unclear whether a position should be an
      absolute position within the image, or a relative position within its
      parent section.
      
      At present 'position' actually means the relative position. This indicates
      a need for an 'image position' for code that wants to find the location of
      an entry without having to do calculations back through parents to
      discover this image position.
      
      A better name for the current 'position' or 'pos' is 'offset'. It is not
      always an absolute position, but it is always an offset from its parent
      offset.
      
      It is unfortunate to rename this concept now, 18 months after binman was
      introduced. However I believe it is the right thing to do. The impact is
      mostly limited to binman itself and a few changes to in-tree users to
      binman:
      
         tegra
         sunxi
         x86
      
      The change makes old binman definitions (e.g. downstream or out-of-tree)
      incompatible if they use the 'pos = <...>' property. Later work will
      adjust binman to generate an error when it is used.
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      3ab9598d
  9. 25 May, 2018 1 commit
  10. 25 Oct, 2017 1 commit
  11. 19 Dec, 2016 1 commit