1. 24 Apr, 2018 1 commit
  2. 06 Jul, 2017 1 commit
  3. 13 Mar, 2017 1 commit
    • Lee Leahy's avatar
      src/lib: Use tabs instead of spaces · e20a3191
      Lee Leahy authored
      Fix the following errors and warnings detected by checkpatch.pl:
      ERROR: code indent should use tabs where possible
      ERROR: switch and case should be at the same indent
      WARNING: Statements should start on a tabstop
      WARNING: please, no spaces at the start of a line
      WARNING: please, no space before tabs
      WARNING: suspect code indent for conditional statements
      WARNING: labels should not be indented
      TEST=Build and run on Galileo Gen2
      Change-Id: Iebcff26ad41ab6eb0027b871a1c06f3b52dd207c
      Signed-off-by: default avatarLee Leahy <Leroy.P.Leahy@intel.com>
      Reviewed-on: https://review.coreboot.org/18732
      Tested-by: build bot (Jenkins)
      Reviewed-by: default avatarMartin Roth <martinroth@google.com>
  4. 08 Mar, 2017 1 commit
  5. 08 Dec, 2016 1 commit
  6. 07 Dec, 2016 1 commit
  7. 06 Nov, 2016 1 commit
  8. 31 May, 2016 1 commit
  9. 17 Feb, 2016 1 commit
  10. 31 Oct, 2015 1 commit
  11. 30 Jun, 2015 1 commit
  12. 02 Jun, 2015 1 commit
    • Aaron Durbin's avatar
      cbfs: new API and better program loading · 899d13d0
      Aaron Durbin authored
      A new CBFS API is introduced to allow making CBFS access
      easier for providing multiple CBFS sources. That is achieved
      by decoupling the cbfs source from a CBFS file. A CBFS
      source is described by a descriptor. It contains the necessary
      properties for walking a CBFS to locate a file. The CBFS
      file is then decoupled from the CBFS descriptor in that it's
      no longer needed to access the contents of the file.
      All of this is accomplished using the regions infrastructure
      by repsenting CBFS sources and files as region_devices. Because
      region_devices can be chained together forming subregions this
      allows one to decouple a CBFS source from a file. This also allows
      one to provide CBFS files that came from other sources for
      payload and/or stage loading.
      The program loading takes advantage of those very properties
      by allowing multiple sources for locating a program. Because of
      this we can reduce the overhead of loading programs because
      it's all done in the common code paths. Only locating the
      program is per source.
      Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8
      Signed-off-by: default avatarAaron Durbin <adurbin@chromium.org>
      Reviewed-on: http://review.coreboot.org/9134
      Tested-by: build bot (Jenkins)
      Tested-by: default avatarRaptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
      Reviewed-by: default avatarPatrick Georgi <pgeorgi@google.com>
  13. 21 May, 2015 1 commit
    • Patrick Georgi's avatar
      Remove address from GPLv2 headers · b890a122
      Patrick Georgi authored
      As per discussion with lawyers[tm], it's not a good idea to
      shorten the license header too much - not for legal reasons
      but because there are tools that look for them, and giving
      them a standard pattern simplifies things.
      However, we got confirmation that we don't have to update
      every file ever added to coreboot whenever the FSF gets a
      new lease, but can drop the address instead.
      util/kconfig is excluded because that's imported code that
      we may want to synchronize every now and then.
      $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
      $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
      $ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
      $ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
      $ find * -type f
      	-a \! -name \*.patch \
      	-a \! -name \*_shipped \
      	-a \! -name LICENSE_GPL \
      	-a \! -name LGPL.txt \
      	-a \! -name COPYING \
      	-a \! -name DISCLAIMER \
      	-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
      Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
      Signed-off-by: default avatarPatrick Georgi <pgeorgi@chromium.org>
      Reviewed-on: http://review.coreboot.org/9233
      Tested-by: build bot (Jenkins)
      Reviewed-by: default avatarVladimir Serbinenko <phcoder@gmail.com>
  14. 23 Apr, 2015 1 commit
  15. 14 Apr, 2015 1 commit
    • Julius Werner's avatar
      timer: Reestablish init_timer(), consolidate timer initialization calls · 44cf870c
      Julius Werner authored
      We have known for a while that the old x86 model of calling init_timer()
      in ramstage doesn't make sense on other archs (and is questionable in
      general), and finally removed it with CL:219719. However, now timer
      initialization is completely buried in the platform code, and it's hard
      to ensure it is done in time to set up timestamps. For three out of four
      non-x86 SoC vendors we have brought up for now, the timers need some
      kind of SoC-specific initialization.
      This patch reintroduces init_timer() as a weak function that can be
      overridden by platform code. The call in ramstage is restricted to x86
      (and should probably eventually be removed from there as well), and
      other archs should call them at the earliest reasonable point in their
      bootblock. (Only changing arm for now since arm64 and mips bootblocks
      are still in very early state and should sync up to features in arm once
      their requirements are better understood.) This allows us to move
      timestamp_init() into arch code, so that we can rely on timestamps
      being available at a well-defined point and initialize our base value as
      early as possible. (Platforms who know that their timers start at zero
      can still safely call timestamp_init(0) again from platform code.)
      TEST=Booted Pinky, Blaze and Storm, compiled Daisy and Pit.
      Change-Id: I1b064ba3831c0c5b7965b1d88a6f4a590789c891
      Signed-off-by: default avatarPatrick Georgi <pgeorgi@chromium.org>
      Original-Commit-Id: ffaebcd3785c4ce998ac1536e9fdd46ce3f52bfa
      Original-Change-Id: Iece1614b7442d4fa9ca981010e1c8497bdea308d
      Original-Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      Original-Reviewed-on: https://chromium-review.googlesource.com/234062Original-Reviewed-by: default avatarAaron Durbin <adurbin@chromium.org>
      Reviewed-on: http://review.coreboot.org/9606
      Tested-by: build bot (Jenkins)
      Reviewed-by: default avatarStefan Reinauer <stefan.reinauer@coreboot.org>
  16. 07 Apr, 2015 1 commit
  17. 31 Mar, 2015 1 commit
  18. 21 Mar, 2015 1 commit
  19. 20 Mar, 2015 1 commit
  20. 18 Mar, 2015 1 commit
    • Aaron Durbin's avatar
      bootstate: use structure pointers for scheduling callbacks · 9ef9d859
      Aaron Durbin authored
      The GCC 4.9.2 update showed that the boot_state_init_entry
      structures were being padded and assumed to be aligned in to an
      increased size. The bootstate scheduler for static entries,
      boot_state_schedule_static_entries(), was then calculating the
      wrong values within the array. To fix this just use a pointer to
      the boot_state_init_entry structure that needs to be scheduled.
      In addition to the previous issue noted above, the .bs_init
      section was sitting in the read only portion of the image while
      the fields within it need to be writable. Also, the
      boot_state_schedule_static_entries() was using symbol comparison
      to terminate a loop which in C can lead the compiler to always
      evaluate the loop at least once since the language spec indicates
      no 2 symbols can be the same value.
      Change-Id: I6dc5331c2979d508dde3cd5c3332903d40d8048b
      Signed-off-by: default avatarAaron Durbin <adurbin@chromium.org>
      Reviewed-on: http://review.coreboot.org/8699
      Tested-by: build bot (Jenkins)
      Reviewed-by: default avatarPatrick Georgi <pgeorgi@google.com>
  21. 04 Mar, 2015 1 commit
  22. 27 Jan, 2015 1 commit
  23. 05 Jan, 2015 1 commit
  24. 19 Oct, 2014 1 commit
  25. 13 Sep, 2014 1 commit
  26. 03 Jul, 2014 1 commit
  27. 03 Mar, 2014 1 commit
  28. 26 Nov, 2013 1 commit
    • Duncan Laurie's avatar
      Clean up POST codes for Boot State machine · cb73a841
      Duncan Laurie authored
      Now that there is a clearly defined boot state machine
      we can add some useful post codes to indicate the current
      point in the state machine by having it log a post code
      before the execution of each state.
      This removes the currently defined POST codes that were
      used by hardwaremain in favor of a new contiguous range
      that are defined for each boot state.
      The reason for this is that the existing codes are mostly
      used to indicate when something is done, which is confusing
      for actual debug because POST code debugging relies on knowing
      what is about to happen (to know what may be at fault) rather
      than what has just finished.
      One additonal change is added during device init step as this
      step often does the bulk of the work, and frequently logs POST
      codes itself.  Therefore in order to keep better track of what
      device is being initialized POST_BS_DEV_INIT is logged before
      each device is initialized.
      interrupted boot with reset button and
      gathered the eventlog.  Mosys has been extended to
      decode the well-known POST codes:
      26 | 2013-06-10 10:32:48 | System boot | 120
      27 | 2013-06-10 10:32:48 | Last post code in previous boot | 0x75 | Device Initialize
      28 | 2013-06-10 10:32:48 | Extra info from previous boot | PCI | 00:16.0
      29 | 2013-06-10 10:32:48 | Reset Button
      30 | 2013-06-10 10:32:48 | System Reset
      Change-Id: Ida1e1129d274d28cbe8e49e4a01483e335a03d96
      Signed-off-by: default avatarDuncan Laurie <dlaurie@chromium.org>
      Reviewed-on: https://gerrit.chromium.org/gerrit/58106
      Reviewed-on: http://review.coreboot.org/4231
      Tested-by: build bot (Jenkins)
      Reviewed-by: default avatarAlexandru Gagniuc <mr.nuke.me@gmail.com>
  29. 08 Nov, 2013 1 commit
    • Marc Jones's avatar
      Add new finalize functions for devices and chips · 2a58ecde
      Marc Jones authored
      Many chipset devices require additional configuration after
      device init. It is not uncommmon for a device early in the devicetree
      list to need to change a setting after a device later in the tree does
      PCI init. A final function call has been added to device ops to handle
      this case. It is called prior to coreboot table setup.
      Another problem that is often seen is that the chipset or mainboard
      need to do some final cleanup just before loading the OS. The chip
      finalize has been added for this case. It is call after all coreboot
      tables are setup and the payload is ready to be called.
      Similar functionality could be implemented with the hardwaremain
      states, but those don't fit well in the device tree function pointer
      structure and should be used sparingly.
      Change-Id: Ib37cce104ae41ec225a8502942d85e54d99ea75f
      Signed-off-by: default avatarMarc Jones <marc.jones@se-eng.com>
      Reviewed-on: http://review.coreboot.org/4012
      Tested-by: build bot (Jenkins)
      Reviewed-by: default avatarAaron Durbin <adurbin@google.com>
      Reviewed-by: default avatarPaul Menzel <paulepanter@users.sourceforge.net>
      Reviewed-by: default avatarRonald G. Minnich <rminnich@gmail.com>
  30. 21 Sep, 2013 2 commits
  31. 10 Jul, 2013 2 commits
  32. 20 Jun, 2013 1 commit
  33. 14 May, 2013 1 commit
    • Aaron Durbin's avatar
      coreboot: add thread cooperative multitasking · 4409a5ee
      Aaron Durbin authored
      The cooperative multitasking support allows the boot state machine
      to be ran cooperatively with other threads of work. The main thread
      still continues to run the boot state machine
      (src/lib/hardwaremain.c).  All callbacks from the state machine are
      still ran synchronously from within the main thread's context.
      Without any other code added the only change to the boot sequence
      when cooperative multitasking is enabled is the queueing of an idlle
      thread. The idle thread is responsible for ensuring progress is made
      by calling timer callbacks.
      The main thread can yield to any other threads in the system. That
      means that anyone that spins up a thread must ensure no shared
      resources are used from 2 or more execution contexts. The support
      is originally intentioned to allow for long work itesm with busy
      loops to occur in parallel during a boot.
      Note that the intention on when to yield a thread will be on
      calls to udelay().
      Change-Id: Ia4d67a38665b12ce2643474843a93babd8a40c77
      Signed-off-by: default avatarAaron Durbin <adurbin@chromium.org>
      Reviewed-on: http://review.coreboot.org/3206
      Tested-by: build bot (Jenkins)
      Reviewed-by: default avatarRonald G. Minnich <rminnich@gmail.com>
  34. 08 May, 2013 1 commit
  35. 07 May, 2013 2 commits
  36. 01 May, 2013 2 commits