summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2013-07-10exynos5420: Replace the 5250 clock logic with 5420.Gabe Black
The new code is stolen from U-Boot with little or no understanding of how it works. Change-Id: I3de7d25174072f6068d9d4fdaa308c0462296737 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3658 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10exynos5420: Make the ps_hold_setup function public.Gabe Black
This function had been declared in a public header file, but was marked static when actually defined. Change-Id: Ia551a5a12e7dbaf7bc00861e085695145ab7b91a Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3657 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Exynos5420: Clean up console codeStefan Reinauer
- Don't initialize console twice in the bootblock - remove printk in memory init that would mess up the UART - unconditionally run console_init() in romstage, as it is also unconditionally run in the bootblock. Change-Id: I983d011c6ca602445f447d17799c1b2a33e8bd1d Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3656 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ec: Remove hardcoded GPI offset in EC SCIDuncan Laurie
With LynxPoint-LP the SCI GPE is no longer a GPIO that is offset by 16. Remove the Add and fix up the link definition so it is still accurate. Change-Id: I091141183a09345b5ffe28365583e48019f9f5e5 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/3742 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10exynos5250: Clear the framebuffer before making it uncacheable.Gabe Black
If we clear the framebuffer and then flush it back to memory using cache operations, the writes are going to be full cachelines at a time. If we make it uncacheable first, the writes will be serialized writes of whatever sized chunks memset uses, probably 4 bytes or less. Change-Id: I1b81731cfed00ae091ba6357451ab186d16f559e Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3655 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10exynos5250: Don't disable and re-enable the MMU when uncaching the framebuffer.Gabe Black
At one time it seemed to be necessary to disable and then re-enable the MMU when setting the framebuffer to be uncache-able due to bugs in the MMU management code. Since those bugs have been fixed, this is no longer necessary. Change-Id: I5f7b9bd14dc9929efe1834ec9a258d388b8c94e9 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3654 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ARM: Fix up page table/cachability management.Gabe Black
When modifying the page tables, use writel to ensure the writes happen, flush the page tables themselves to ensure they're visible to the MMU if it doesn't look at the caches, and invalidate the right TLB entries. The first two changes are probably safer but may not be strictly necessary. The third change is necessary because we were invalidating the TLB using i which was in megabytes but using an instruction that expects an address in bytes. One symptom of this problem was that the framebuffer, which was supposed to be marked uncacheable, was only being partially updated since some of the updates were still in the cache. With this change the graphics show up correctly. Change-Id: I5475df29690371459b0d37a304eebc62f81dd76b Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3653 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10exynos5250: Simplify the graphics code by eliminating the unused color map.Gabe Black
The code that allocated space for the framebuffer was adding space for a vestigial color map which was never used. It was also passing around a structure which was used to calculate a single value which was already known when that structure was put together. Eliminate the extra space, and pass the single value instead of the structure. Change-Id: Ia6a41cefdf8b29fe7d68f9596a156eced6eb5df8 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3652 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10snow: Make coreboot set up pins for busses it knows are hooked up as suchGabe Black
Coreboot knows that, for the snow board, certain pins are to be connected to bus controllers in the SOC and to the wires of a bus external to the SOC. It can configure them as such and free its payload from having to know how to set everything up. Change-Id: I1bb127c810e9ee077afc4227a6f316eaa53d6498 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3650 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-07-10drivers: Fix spellingMartin Roth
Change-Id: Ib0d98e3ab5b2943c36f88765587e8963a4f49604 Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/3754 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ec: Fix spellingMartin Roth
Change-Id: I5e4d35572c43f07bec5ec0bcd75c717723228e2f Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/3757 Reviewed-by: Dave Frodin <dave.frodin@se-eng.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10lib: Fix spellingMartin Roth
Change-Id: I999987af9cb44906e3c3135c0351a0cd6eb210ff Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/3756 Reviewed-by: Dave Frodin <dave.frodin@se-eng.com> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10device: Fix spellingMartin Roth
Change-Id: I53a40d114aa2da76398c5b97443d4096809dcf36 Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/3730 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10console: Fix spellingMartin Roth
Change-Id: I1fef27c4a16ee4358ace8014a8d6e9fa92c4f790 Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/3728 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10arch: Fix spellingMartin Roth
Change-Id: Ifea10f0180c0c4b684030a168402a95fadf1a9db Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/3727 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ARM: Fix the way the space for the page tables is allocated.Gabe Black
The page tables need to be aligned to a 16KB boundary and are 16KB in size. The CBMEM allocator only guarantees 512 byte alignment, so to make sure things are where they're supposed to be, the code was allocating extra space and then adjusting the pointer upwards. Unfortunately, it was adding the size of the table to the pointer first, then aligning it. Since it allocated twice the space of the table, this had the effect of moving past the first table size region of bytes, and then aligning upwards, pushing the end of the table out of the space allocated for it. You can get away with this if you push things you don't care about off the end, and it happened to be the case that we were allocating a color map we weren't using at the start of the next part of cbmem. Change-Id: I6b196fc573801b02f27f2e667acbf06163266651 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3651 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10exynos5250: When enabling the I2S pins, turn off pull ups/downs.Gabe Black
These pins will be driven by the internal controller which shouldn't have pull ups or downs in the pin fighting with them. Change-Id: I579aed84ace45d8f5f1d3ca64c064d98de842b57 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3649 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10exynos5420: Replace the 5250 GPIO code with code that should work on 5420.Gabe Black
Change-Id: Iac6615240e94c74037afc801169c32d3ebc4ac03 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3648 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ARMv7: Clean up console codeStefan Reinauer
- Guard console_init() with CONFIG_EARLY_CONSOLE in bootblock - Don't initialize console twice in the bootblock - remove printk in memory init that would mess up the UART - unconditionally run console_init() in romstage, as it is also unconditionally run in the bootblock. Change-Id: I8f0d60877433162367074d0e55e01f935fd81f8e Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3647 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10pit: Add a "pit" mainboard which is mostly a copy of "snow".Gabe Black
This change adds a pit mainboard which is mostly a copy of snow, except that mentions of the 5250 were replaced with the 5420, and mentions of snow were replaced with pit. Change-Id: I8eb0ce379eb2fa353bb88d5656a0c5e2290afbf0 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3646 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10pit: Fix some settings for the exynos5420 CPU.Gabe Black
Some of the settings which were defaulted to or automatically selected for the exynos5420 which were inherited from the exynos5250 were not correct for this SOC. Change-Id: I11ffd8a6b80628405ac493fe2139f79c05d15d7e Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3645 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10pit: Create an exynos5420 directory which is nearly a copy of exynos5250.Gabe Black
This change creates an exynos5420 directory with code that will eventually implement support for the exynos5420 cpu from Samsung. Currently it's a copy of the exynos5250 directory with the name changed. There are going to be some problems where headers in src/cpu/samsung/exynos-common include headers in the exynos5250 directory directly. Change-Id: Ia8d7244310d32499238bbc171c0c668ec48178e1 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3644 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ARMv7: De-uboot-ify Exynos5250 GPIO codeStefan Reinauer
The Exynos GPIO code has three different APIs that, unfortunately, were widely used throughout the code base. This patch is cleaning up the mess. Change-Id: I09ccc7819fb892dbace9693c786dacc62f3f8eac Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3643 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ARMv7: De-uboot-ify Exynos5250 codeStefan Reinauer
When starting the Exynos5250 port, a lot of unneeded u-boot code was imported. This is an attempt to get rid of a lot of unneeded code before the port is used as a basis for further ARM ports. There is a lot more that can be done, including cleaning up the 5250's Kconfig file. Change-Id: I2d88676c436eea4b21bcb62f40018af9fabb3016 Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3642 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Update 3rdparty hash for latest ARM BL1 binariesStefan Reinauer
Change-Id: Ice28114e5f53f510d305cd85d095044e2f4bd7b2 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3740 Reviewed-by: Gabe Black <gabeblack@chromium.org> Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins)
2013-07-10w83627hf/acpi: Fix endianess error in floppy drive enumeration codeChristoph Grenz
The enumeration results are stored as five DWORDs in one 20 byte buffer. Bytes 3, 7, 11 and 15 were used to set the lowest bit of each DWORD. ACPI uses little endian, so 1, 4, 8 and 12 are the correct indices. Change-Id: I793225cb1bb62fd148ecfa1e61e02f5d7be62cdb Signed-off-by: Christoph Grenz <christophg+cb@grenz-bonn.de> Reviewed-on: http://review.coreboot.org/3602 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-07-10samsung/exynos5250: unify codeStefan Reinauer
It turns out that the exynos5-common code previously imported from u-boot is not common code at all but very specific to the 5250 and not compatible with the 5450. Hence, unify the directories exynos5250 and exynos5-common. We will try to factor out common code while progressing with the 5450 port. Change-Id: Iab595e66fcd01eda8365c96fb8bef896f7602f03 Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3641 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Wield battle axe at ARM portStefan Reinauer
This patch unfortunately incorporates a number of changes, all of which are making future ARM ports easier. - drop cruft that came in with u-boot - move serial console from mainboard Kconfig to Exynos Kconfig - factor out non-board specific wakeup code - move generic bootblock code from mainboard to Exynos - actually call arch_cpu_init() - remove dead code - fix up copyright messages - remove snow_ prefix from a lot of code to reduce the noise when creating a new mainboard based on that code. Change-Id: Ic05326edf5a7e1a691c5ff841a604cb9e351b562 Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3640 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Rename hardwaremain() to main()Stefan Reinauer
... and drop the wrapper on ARMv7 Change-Id: If3ffe953cee9e61d4dcbb38f4e5e2ca74b628ccc Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3639 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ARMv7: normalize ramstage code flowStefan Reinauer
In ram stage, all code flow should be tied to the resource allocator. Stuff that has to happen before everything else goes into the mainboard enable function in mainboard.c. This patch empties the main() wrapper around hardwaremain.c, allowing to get rid of this special case in the ARM port. Change-Id: Ide91a23f1043b64acf64471f180a2297f0f40d97 Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3638 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10FUI: reorganize include filesRonald G. Minnich
We've got enough of a handle on this to realize some things: drm_dp_helper.h is by design device and architecture independent i915.h is common to most intel graphics chipsets going back several years i915_reg.h is as well Move these files to src/include/device, and adjust the .c files accordingly. Change-Id: I07512b3695fea0b22949074b467986420783d62a Signed-off-by: Ronald G. Minnich <rminnich@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3637 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Provide support for setting up the framebuffer from EDIDRonald G. Minnich
Add three functions to edid.c: void set_vbe_mode_info_valid(struct edid *edid, uintptr_t fb_addr) takes an edid and uintptr_t, and fills in a static lb_framebuffer struct as well as setting the static vbe_valid to 1 unless some problem is found in the edid. The intent here is that this could be called from the native graphics setup code on both ARM and x86. int vbe_mode_info_valid(void) returns value of the static vbe_valid. void fill_lb_framebuffer(struct lb_framebuffer *framebuffer) copies the static edid_fb to lb_framebuffer. There is now a common vbe.h in src/include, removed the two special ones. In general, graphics in coreboot is a mess, but graphics is always a mess. We don't have a clean way to try two different ways to turn on a device and use the one that works. One battle at a time. Overall, things are much better. The best part: this code would also work for ARM, which also uses EDID. Change-Id: Id23eb61498b331d44ab064b8fb4cb10f07cff7f3 Signed-off-by: Ronald G. Minnich <rminnich@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3636 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ChromeEC: Fix the default, depends for EC_GOOGLE_CHROMEEC_I2C.Gabe Black
The default for this variable should be n, it should only depend on EC_GOOGLE_CHROMEEC, and it should be (and is) explicitly enabled when needed. This prevents it from being turned on when the EC bus is SPI. Change-Id: Idc6651a764be4f055341a36b9b4a58990f050b0c Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3737 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Drop some duplicates of PCI-e config functionsKyösti Mälkki
These are not specific to Intel. Further work needs to be done to combine these with MMCONF_SUPPORT in arch/io.h. Change-Id: Id429db2df8d47433117c21133d80fc985b3e11e4 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3502 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Fix MMCONF_SUPPORT_DEFAULT for ramstageKyösti Mälkki
Define at one place whether to use IO 0xcf8/0xcfc or MMIO via MMCONF_BASE_ADDRESS for PCI configuration access funtions in ramstage. The implementation of pci_default_config() always returned with pci_cf8_conf1. This means any PCI configuration access that did not target bus 0 used PCI IO config operations, if PCI MMIO config was not explicitly requested. Change-Id: I3b04f570fe88d022cd60dde8bb98e76bd00fe612 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3606 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com> Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-07-10southbridge/intel/i82801gx: Make compilation possible with CONFIG_SMM_TSEGDenis 'GNUtoo' Carikli
Without that fix, and with CONFIG_SMM_TSEG, we have: src/southbridge/intel/i82801gx/smihandler.c: In function 'southbridge_smi_sleep': src/southbridge/intel/i82801gx/smihandler.c:340:3: error: implicit declaration of function 'smi_release_lock' [-Werror=implicit-function-declaration] cc1: all warnings being treated as errors make: *** [build/southbridge/intel/i82801gx/smihandler.smm.o] Error 1 The fix is modelled after src/cpu/x86/smm/smihandler.c which ifdefs smi_release_lock(). Change-Id: Icdc6d039b34a1d95d0e607419bba2484d21abc5e Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Reviewed-on: http://review.coreboot.org/3281 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10i82801gx: smihandle: sync with southbridge/intel/bd82x6x/smihandler.cDenis 'GNUtoo' Carikli
Change-Id: Ic725b169061bd426aa8206dc1d6d31e67cc639f2 Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Reviewed-on: http://review.coreboot.org/3304 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10southbridge: i82801gx: smihandler.c: Correct outl->outw mistake.Denis 'GNUtoo' Carikli
This mistake was spoted by comparison with the src/southbridge/intel/bd82x6x/smihandler.c file. Change-Id: I1516f0131d524bd7d001e6780e9a45402d1814d1 Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Reviewed-on: http://review.coreboot.org/3303 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10sandybridge: Add option to lock SPI regions on resumeNico Huber
Add an option to mark all SPI regions write protected on each S3 resume. We were used to lock the SPI interface in the payload which isn't run on the resume path. So we have to do it here. For the write protection to be effective, all write opcodes in the opmenu have to be marked correctly (as write operations) and the whole SPI interface has to be locked. Both is already done. Change-Id: I5c268ae8850642f5e82f18c28c71cf1ae248dbff Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: http://review.coreboot.org/3594 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-09fox_wtm2: First step support for coreboot-based graphics startupRonald G. Minnich
This code is the initial version of FUI for haswell and wtm2. The code is simplified from before in many ways. I've gotten rid of the opcode table, because it obscured meaning and I don't think it is needed any more. Register sets, mainly used for reset, are just lines of code -- not many of them. There are a bunch of not-yet-documented registers here; the VBIOS seemed to think they were necessary and testing shows they seem to be right. As a bit of added paranoia, we always include the VBIOS code as our emergency recovery path. You have to run it now anyways, so this is no regression from our current situation; and, if all goes well, in a week (or so), you'll never have to run it again, but like the Force and nose hair, it will be with you always. The code can return in three ways. The first, best way is success: panel is up and the VBIOS need not run. The second mode is that we tried to light up the panel but could not, for some reason, but will return with the panel partly up. In this case, it's ok not to power cycle the panel. The third, worst case, which will NEVER happen, ha ha, is that we have to turn the panel off and wait the required 600ms for it to cycle. Life sucks sometimes. This failure mode is in the 'hang on we're going to fix it' category now that we have ramstage in RW. The Big Goal here is to create something other coreboot ports can use as well. The guys doing the x60 report that the link FUI works, without too many mods, on that chipset, so it seems Intel is keeping things from changing too much over time. Also, again, please note: this and the next 3 versions will ALWAYS fail. The goal is to verify the correctness of the recovery path. The bizarre tab-space formatting in drm_dp_helper.h is from the original, as in i915_reg.h Change-Id: I6ecf454633029d185c29d470980b5a0f3114a8ce Signed-off-by: Ronald G. Minnich <rminnich@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3635 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-09FOX_WTM2: First pass at FUI.Ronald G. Minnich
This lights up the display. We don't get graphics but we are missing the gttsetup at this point, so that is no shock. The real shock is that anything works at all. Change-Id: I03fc470334e96878aeb8465044b3cc9c90378735 Signed-off-by: Ronald G. Minnich <rminnich@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3634 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-08msrtool: Fix verbose ignored by cpuid().Benoît Legat
This is a trivial patch moving cpuid() call after reading argv so that verbose is set. Change-Id: Ic621191ef650495614a041413c1a0f707d4469e6 Signed-off-by: Benoît Legat <benoit.legat@gmail.com> Reviewed-on: http://review.coreboot.org/3627 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-07-08Fix Vortex86EX devicetree.cb indentation.Andrew Wu
Change-Id: If357b55b91618ee2438e6c6b2efb7018c56d26d0 Signed-off-by: Andrew Wu <arw@dmp.com.tw> Reviewed-on: http://review.coreboot.org/3628 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-07-08Revert "Radio and dock support in EC on X60 and X201"Peter Stuge
This reverts commit 7d1ebbff5ad224591a2d1972737611f96a13145c Change-Id: I4a9d0cd31a3df3d1e092193953f334697ca65167 Signed-off-by: Peter Stuge <peter@stuge.se> Reviewed-on: http://review.coreboot.org/3616 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-07-06am335x: Implement support for the UART.Gabe Black
This patch was started by Dave Hendricks and implements the procedure for setting up the UART as described in the manual. Some unused code was removed. Change-Id: If26a424cac401ef3eafaec081147f41184fbcee9 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3490 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-07-05Add support for DMP Vortex86EX PCI mainboard.Andrew Wu
Change-Id: I8d42f765519e356d8f0cc6ed339d9b74f0a3e4d7 Signed-off-by: Andrew Wu <arw@dmp.com.tw> Reviewed-on: http://review.coreboot.org/3610 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-07-04w83627hf/acpi: Fix offset of logical device activationNico Huber
The PnP's logical device activation normally resides at 0x30. This might have been overlooked as 0x29 looks very close to 0x30 in human eyes. Change-Id: Id5d5a92f2683ebe1808b943f686c062151d216da Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: http://review.coreboot.org/3592 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-07-04w83627hf/acpi: Fix type error in floppy drive enumeration codeChristoph Grenz
The enumeration method tried to evaluate an one-byte OperationRegion instead of a field in this OperationRegion, which resulted in an AE_TYPE error at runtime. Indexing the OperationRegion with a single field fixes this error. Change-Id: I15dd7aa6ecafb3a215d165d2b721003446815025 Signed-off-by: Christoph Grenz <christophg+cb@grenz-bonn.de> Reviewed-on: http://review.coreboot.org/3603 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-07-04intel/i5000: Use MMCONF_SUPPORT_DEFAULTKyösti Mälkki
Change all PCI configuration accesses to MMIO on two boards with i5000 chipset. To enable MMIO style access, add explicit PCI IO config write in the bootblock. Change-Id: I26f1c2da5ae98aeeda78bdcae0fb1e8c711a3586 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3601 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-07-04Move select MMCONF_SUPPORT under northbridge (fix)Kyösti Mälkki
I missed the board with gm45 when I moved MMCONF_SUPPORT lines. Also, the intel/i3100 does not have MMCONF_SUPPORT implemented even though it was previously selected for intel/eagleheights board. Change-Id: I9c7f6b0a150b4d54288a1e015277b9d98467fca4 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3598 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>