Skip to content
Snippets Groups Projects
  1. Jan 03, 2024
  2. Dec 19, 2023
  3. Dec 05, 2022
  4. May 24, 2021
  5. Feb 02, 2021
    • Simon Glass's avatar
      common: Drop asm/global_data.h from common header · 401d1c4f
      Simon Glass authored and Tom Rini's avatar Tom Rini committed
      
      Move this out of the common header and include it only where needed.  In
      a number of cases this requires adding "struct udevice;" to avoid adding
      another large header or in other cases replacing / adding missing header
      files that had been pulled in, very indirectly.   Finally, we have a few
      cases where we did not need to include <asm/global_data.h> at all, so
      remove that include.
      
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      401d1c4f
  6. Jan 05, 2021
    • Simon Glass's avatar
      dm: Rename U_BOOT_DEVICE() to U_BOOT_DRVINFO() · 20e442ab
      Simon Glass authored
      
      The current macro is a misnomer since it does not declare a device
      directly. Instead, it declares driver_info record which U-Boot uses at
      runtime to create a device.
      
      The distinction seems somewhat minor most of the time, but is becomes
      quite confusing when we actually want to declare a device, with
      of-platdata. We are left trying to distinguish between a device which
      isn't actually device, and a device that is (perhaps an 'instance'?)
      
      It seems better to rename this macro to describe what it actually is. The
      macros is not widely used, since boards should use devicetree to declare
      devices.
      
      Rename it to U_BOOT_DRVINFO(), which indicates clearly that this is
      declaring a new driver_info record, not a device.
      
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      20e442ab
  7. Dec 13, 2020
  8. May 19, 2020
  9. May 18, 2020
    • Simon Glass's avatar
      common: Drop net.h from common header · 90526e9f
      Simon Glass authored and Tom Rini's avatar Tom Rini committed
      
      Move this header out of the common header. Network support is used in
      quite a few places but it still does not warrant blanket inclusion.
      
      Note that this net.h header itself has quite a lot in it. It could be
      split into the driver-mode support, functions, structures, checksumming,
      etc.
      
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      90526e9f
  10. Jan 24, 2020
  11. Jan 17, 2020
  12. Dec 02, 2019
  13. Jun 05, 2019
  14. May 18, 2019
  15. May 07, 2018
    • Tom Rini's avatar
      SPDX: Convert all of our single license tags to Linux Kernel style · 83d290c5
      Tom Rini authored
      
      When U-Boot started using SPDX tags we were among the early adopters and
      there weren't a lot of other examples to borrow from.  So we picked the
      area of the file that usually had a full license text and replaced it
      with an appropriate SPDX-License-Identifier: entry.  Since then, the
      Linux Kernel has adopted SPDX tags and they place it as the very first
      line in a file (except where shebangs are used, then it's second line)
      and with slightly different comment styles than us.
      
      In part due to community overlap, in part due to better tag visibility
      and in part for other minor reasons, switch over to that style.
      
      This commit changes all instances where we have a single declared
      license in the tag as both the before and after are identical in tag
      contents.  There's also a few places where I found we did not have a tag
      and have introduced one.
      
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      83d290c5
  16. Jan 20, 2017
    • Heiko Schocher's avatar
      serial, ns16550: bugfix: ns16550 fifo not enabled · 17fa0326
      Heiko Schocher authored and Tom Rini's avatar Tom Rini committed
      
      commit: 65f83802 "serial: 16550: Add getfcr accessor"
      breaks u-boot commandline working with long commands
      sending to the board.
      
      Since the above patch, you have to setup the fcr register.
      
      For board/archs which enable OF_PLATDATA, the new field
      fcr in struct ns16550_platdata is not filled with a
      default value ...
      
      This leads in not setting up the uarts fifo, which ends
      in problems, when you send long commands to u-boots
      commandline.
      
      Detected this issue with automated tbot tests on am335x
      based shc board.
      
      The error does not popup, if you type commands. You need
      to copy&paste a long command to u-boots commandshell
      (or send a long command with tbot)
      
      Possible boards/plattforms with problems:
      ./arch/arm/cpu/arm926ejs/lpc32xx/devices.c
      ./arch/arm/mach-tegra/board.c
      ./board/overo/overo.c
      ./board/quipos/cairo/cairo.c
      ./board/logicpd/omap3som/omap3logic.c
      ./board/logicpd/zoom1/zoom1.c
      ./board/timll/devkit8000/devkit8000.c
      ./board/lg/sniper/sniper.c
      ./board/ti/beagle/beagle.c
      ./drivers/serial/serial_rockchip.c
      
      Signed-off-by: default avatarHeiko Schocher <hs@denx.de>
      Signed-off-by: default avatarLadislav Michl <ladis@linux-mips.org>
      Tested-by: default avatarAdam Ford <aford173@gmail.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      17fa0326
  17. Dec 05, 2015
  18. Nov 22, 2015
  19. Aug 13, 2015
    • Stephen Warren's avatar
      ARM: tegra: query_sdram_size() cleanup · a5fc3d0b
      Stephen Warren authored and Tom Warren's avatar Tom Warren committed
      
      The return value of query_sdram_size() is assigned directly to
      gd->ram_size in dram_init(). Adjust the return type to match the field
      it's assigned to. This has the beneficial effect that on 64-bit systems,
      the return value can correctly represent large RAM sizes over 4GB.
      
      For similar reasons, change the type of variable size_bytes in the same
      way.
      
      query_sdram_size() would previously clip the detected RAM size to at most
      just under 4GB in all cases, since on 32-bit systems, larger values could
      not be represented. Disable this feature on 64-bit systems since the
      representation restriction does not exist.
      
      On 64-bit systems, never call get_ram_size() to validate the detected/
      calculated RAM size. On any system with a secure OS/... carve-out, RAM
      may not have a single contiguous usable area, and this can confuse
      get_ram_size(). Ideally, we'd make this call conditional upon some other
      flag that indicates specifically that a carve-out is actually in use. At
      present, building for a 64-bit system is the best indication we have of
      this fact. In fact, the call to get_ram_size() is not useful by the time
      U-Boot runs on any system, since U-Boot (and potentially much other early
      boot software) always runs from RAM on Tegra, so any mistakes in memory
      controller register programming will already have manifested themselves
      and prevented U-Boot from running to this point. In the future, we may
      simply delete the call to get_ram_size() in all cases.
      
      Signed-off-by: Stephen Warren's avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarTom Warren <twarren@nvidia.com>
      a5fc3d0b
  20. Jul 28, 2015
  21. Jul 27, 2015
  22. May 13, 2015
  23. Mar 04, 2015
    • Stephen Warren's avatar
      ARM: tegra: support running in non-secure mode · 73c38934
      Stephen Warren authored and Tom Warren's avatar Tom Warren committed
      
      When the CPU is in non-secure (NS) mode (when running U-Boot under a
      secure monitor), certain actions cannot be taken, since they would need
      to write to secure-only registers. One example is configuring the ARM
      architectural timer's CNTFRQ register.
      
      We could support this in one of two ways:
      1) Compile twice, once for secure mode (in which case anything goes) and
         once for non-secure mode (in which case certain actions are disabled).
         This complicates things, since everyone needs to keep track of
         different U-Boot binaries for different situations.
      2) Detect NS mode at run-time, and optionally skip any impossible actions.
         This has the advantage of a single U-Boot binary working in all cases.
      
      (2) is not possible on ARM in general, since there's no architectural way
      to detect secure-vs-non-secure. However, there is a Tegra-specific way to
      detect this.
      
      This patches uses that feature to detect secure vs. NS mode on Tegra, and
      uses that to:
      
      * Skip the ARM arch timer initialization.
      
      * Set/clear an environment variable so that boot scripts can take
        different action depending on which mode the CPU is in. This might be
        something like:
        if CPU is secure:
          load secure monitor code into RAM.
          boot secure monitor.
          secure monitor will restart (a new copy of) U-Boot in NS mode.
        else:
          execute normal boot process
      
      Signed-off-by: Stephen Warren's avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarTom Warren <twarren@nvidia.com>
      73c38934
    • Stephen Warren's avatar
      ARM: tegra: support large RAM sizes · 56519c4f
      Stephen Warren authored and Tom Warren's avatar Tom Warren committed
      
      Some systems have so much RAM that the end of RAM is beyond 4GB. An
      example would be a Tegra124 system (where RAM starts at 2GB physical)
      that has more than 2GB of RAM.
      
      In this case, we want gd->ram_size to represent the actual RAM size, so
      that the actual RAM size is passed to the OS. This is useful if the OS
      implements LPAE, and can actually use the "extra" RAM.
      
      However, we can't use get_ram_size() to verify the actual amount of RAM
      present on such systems, since some of the RAM can't be accesses, which
      confuses that function. Avoid calling get_ram_size() when the RAM size
      is too large for it to work correctly. It's never actually needed anyway,
      since there's no reason for the BCT to report the wrong RAM size.
      
      In systems with >=4GB RAM, we still need to clip the reported RAM size
      since U-Boot uses a 32-bit variable to represent the RAM size in bytes.
      
      Signed-off-by: Stephen Warren's avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: default avatarTom Warren <twarren@nvidia.com>
      56519c4f
    • Stephen Warren's avatar
      ARM: tegra: fix variable naming in query_sdram_size() · 3a2cab51
      Stephen Warren authored and Tom Warren's avatar Tom Warren committed
      
      size_mb is used to hold a value that's sometimes KB, sometimes MB,
      and sometimes bytes. Use separate correctly named variables to avoid
      confusion here. Also fix indentation of a conditional statement.
      
      Signed-off-by: Stephen Warren's avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: default avatarTom Warren <twarren@nvidia.com>
      3a2cab51
  24. Feb 21, 2015
    • Masahiro Yamada's avatar
      ARM: tegra: collect SoC sources into mach-tegra · 09f455dc
      Masahiro Yamada authored and Tom Rini's avatar Tom Rini committed
      
      This commit moves files as follows:
      
       arch/arm/cpu/arm720t/tegra20/*      -> arch/arm/mach-tegra/tegra20/*
       arch/arm/cpu/arm720t/tegra30/*      -> arch/arm/mach-tegra/tegra30/*
       arch/arm/cpu/arm720t/tegra114/*     -> arch/arm/mach-tegra/tegra114/*
       arch/arm/cpu/arm720t/tegra124*      -> arch/arm/mach-tegra/tegra124/*
       arch/arm/cpu/arm720t/tegra-common/* -> arch/arm/mach-tegra/*
       arch/arm/cpu/armv7/tegra20/*        -> arch/arm/mach-tegra/tegra20/*
       arch/arm/cpu/armv7/tegra30/*        -> arch/arm/mach-tegra/tegra30/*
       arch/arm/cpu/armv7/tegra114/*       -> arch/arm/mach-tegra/tegra114/*
       arch/arm/cpu/armv7/tegra124/*       -> arch/arm/mach-tegra/tegra124/*
       arch/arm/cpu/armv7/tegra-common/*   -> arch/arm/mach-tegra/*
       arch/arm/cpu/tegra20-common/*       -> arch/arm/mach-tegra/tegra20/*
       arch/arm/cpu/tegra30-common/*       -> arch/arm/mach-tegra/tegra30/*
       arch/arm/cpu/tegra114-common/*      -> arch/arm/mach-tegra/tegra114/*
       arch/arm/cpu/tegra124-common/*      -> arch/arm/mach-tegra/tegra124/*
       arch/arm/cpu/tegra-common/*         -> arch/arm/mach-tegra/*
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      Tested-by: Simon Glass <sjg@chromium.org> [ on nyan-big ]
      Cc: Stephen Warren <swarren@nvidia.com>
      Cc: Tom Warren <twarren@nvidia.com>
      09f455dc
  25. Oct 22, 2014
  26. Aug 18, 2014
    • Stephen Warren's avatar
      ARM: tegra: Use mem size from MC rather than ODMDATA · aeb3fcb3
      Stephen Warren authored and Tom Warren's avatar Tom Warren committed
      
      In at least Tegra124, the Tegra memory controller (MC) has a register
      that controls the memory size. Read this to determine the memory size
      rather than requiring this to be redundantly encoded into the ODMDATA.
      This way, changes to the BCT (i.e. MC configuration) automatically
      updated SW's view of the memory size, without requiring manual changes
      to the ODMDATA.
      
      Future work potentially required:
      * Clip the memory size to architectural limits; U-Boot probably doesn't
        and won't support either LPAE or Tegra's "swiss cheese" memory layout,
        at least one of which would be required for >2GB RAM.
      * Subtract out any carveout required by firmware on future SoCs.
      
      Based-on-work-by: default avatarTom Warren <twarren@nvidia.com>
      Signed-off-by: Stephen Warren's avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarTom Warren <twarren@nvidia.com>
      aeb3fcb3
  27. Feb 03, 2014
  28. Jul 24, 2013
  29. Feb 11, 2013
  30. Jan 16, 2013
Loading