No description
ad4556f2cb
Apparently the IROM doesn't like data caches... the recently added dcache-in-bootblock makes A-A booting fail, and flushes/invalidations alone don't seem to fix it. It's pretty fast anyway, so we just disable the cache again for the duration of the IROM call. Also removes a superfluous invalidation line from the bootblock code... dcache_mmu_enable/disable already take care of that. Old-Change-Id: I35580d15664c7b4197d4ed14028720147adbf918 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/66602 Reviewed-by: Gabe Black <gabeblack@chromium.org> Reviewed-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit e9c28a6a7a88c8286e62764ee5ad2694da2e822f) exynos5: Implement booting from SDMMC media This patch augments the alternative CBFS media source implementation for Exynos5250 and Exynos5420 to allow booting from SDMMC devices (such as an SD or uSD card reader, if available). It also moves MMC initialization for the Snow, Pit and Kirby boards from romstage to ramstage (mainboard_init) to prevent it from interfering with the IROM during SDMMC boot. Old-Change-Id: Ic4adef80c28262d084a53c28ec59aa7ac3af50c8 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/66154 (cherry picked from commit 08de13b72432c076e3327c048df93d89d52b0ecc) snow and pit: turn on FET4 (for SD card) at bootup Explictly enable FET4 on Snow and Pit. Historically we haven't needed to do this because: * On snow there's a bypass around FET4 which effectively eliminates it. Even if we don't turn on FET4 the SD card is still powered. Turning on FET4 doesn't hurt though and is technically correct. * On pit the EC turns on FET4 on cold bootup. On pit we run into a problem if the kernel turns off FET4 like in <https://gerrit.chromium.org/gerrit/#/c/65332/> and then we get a software reset or warm reset. In this case the EC won't know to turn it back on. This was ported from: https://gerrit.chromium.org/gerrit/#/c/65673 Signed-off-by: David Hendricks <dhendrix@chromium.org> Old-Change-Id: I57337f12b38889e6afee8577cf8807ec4c41e91c Reviewed-on: https://gerrit.chromium.org/gerrit/66786 Commit-Queue: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Ronald G. Minnich <rminnich@chromium.org> (cherry picked from commit e910117047d898b6b1d0dc965ef2ec0237d17646) Squashed three commits for alternate cbfs SD support. Change-Id: Idbd1fd4776cbf8cb20d03e6b691104cd8540a1ec Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6530 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> |
||
---|---|---|
3rdparty@45f0c04fd7 | ||
documentation | ||
payloads | ||
src | ||
util | ||
.gitignore | ||
.gitmodules | ||
.gitreview | ||
COPYING | ||
Makefile | ||
Makefile.inc | ||
README | ||
toolchain.inc |
------------------------------------------------------------------------------- coreboot README ------------------------------------------------------------------------------- coreboot is a Free Software project aimed at replacing the proprietary BIOS (firmware) found in most computers. coreboot performs a little bit of hardware initialization and then executes additional boot logic, called a payload. With the separation of hardware initialization and later boot logic, coreboot can scale from specialized applications that run directly firmware, run operating systems in flash, load custom bootloaders, or implement firmware standards, like PC BIOS services or UEFI. This allows for systems to only include the features necessary in the target application, reducing the amount of code and flash space required. coreboot was formerly known as LinuxBIOS. Payloads -------- After the basic initialization of the hardware has been performed, any desired "payload" can be started by coreboot. See http://www.coreboot.org/Payloads for a list of supported payloads. Supported Hardware ------------------ coreboot supports a wide range of chipsets, devices, and mainboards. For details please consult: * http://www.coreboot.org/Supported_Motherboards * http://www.coreboot.org/Supported_Chipsets_and_Devices Build Requirements ------------------ * gcc / g++ * make Optional: * doxygen (for generating/viewing documentation) * iasl (for targets with ACPI support) * gdb (for better debugging facilities on some targets) * ncurses (for 'make menuconfig') * flex and bison (for regenerating parsers) Building coreboot ----------------- Please consult http://www.coreboot.org/Build_HOWTO for details. Testing coreboot Without Modifying Your Hardware ------------------------------------------------ If you want to test coreboot without any risks before you really decide to use it on your hardware, you can use the QEMU system emulator to run coreboot virtually in QEMU. Please see http://www.coreboot.org/QEMU for details. Website and Mailing List ------------------------ Further details on the project, a FAQ, many HOWTOs, news, development guidelines and more can be found on the coreboot website: http://www.coreboot.org You can contact us directly on the coreboot mailing list: http://www.coreboot.org/Mailinglist Copyright and License --------------------- The copyright on coreboot is owned by quite a large number of individual developers and companies. Please check the individual source files for details. coreboot is licensed under the terms of the GNU General Public License (GPL). Some files are licensed under the "GPL (version 2, or any later version)", and some files are licensed under the "GPL, version 2". For some parts, which were derived from other projects, other (GPL-compatible) licenses may apply. Please check the individual source files for details. This makes the resulting coreboot images licensed under the GPL, version 2.