add rtc_init() to romstage

The FSP clears the bit that tells us whether or not the RTC has lost
power when it sets up memory.  Because of this, we need to initialize
the RTC in romstage instead of ramstage.

Change-Id: I158e4339fc539d32cfb2428042df6156d312a5f4
Signed-off-by: Martin Roth <gaumless@gmail.com>
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/5735
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
drivers/intel/fsp: update enable_mrc_cache with fast boot

When going from a configuration with fast boot disabled to one with
it enabled, ENABLE_MRC_CACHE was not being enabled properly.  This
forces it on with ENABLE_FSP_FAST_BOOT.

Change-Id: If7b6374e0c0a1d5403a50a1b0a958cea6f96cc88
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/5794
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
fsp_baytrail: Add the FSP version of Intel's Bay Trail-I chip

While similar to the Bay Trail-M/D code based on the MRC, there are
many differences as well:
- Obviously, uses the FSP instead of the MRC binaries.
- FSP does additional hardware setup, so coreboot doesn't need to.
- Different microcode & microcode loading method
- Uses the cache_as_ram.inc from the FSP Driver
- Various other changes in support of the FSP
Additional changes that don't have to to with the FSP vs MRC:
- Updated IRQ Routing
- Different FADT implementation.
This was validated with FSP:
BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014.fd
SHA256: d29eefbb33454bd5314bfaa38fb055d592a757de7b348ed7096cd8c2d65908a5
MD5: 9360cd915f0d3e4116bbc782233d7b91

Change-Id: Iadadf8cd6cf444ba840e0f76d3aed7825cd7aee4
Signed-off-by: Martin Roth <gaumless@gmail.com>
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/5791
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
PCI IRQs: Swizzle PCI IRQs for PCI bridges

The PCI Specification states that devices that implement
a bridge and a secondary bus must swizzle (rotate) the
interrupt pins according to the table below:
	Child Dev #     Child PIN       Parent PIN
	0,4,8,12...     A/B/C/D         A/B/C/D
	1,5,9,13...     A/B/C/D         B/C/D/A
	2,6,10,14..     A/B/C/D         C/D/A/B
	3,7,11,15..     A/B/C/D         D/A/B/C

Which is also described by this equation:
	PIN_parent = (Pin_child + Dev_child) % 4

When a device is found and its bus number is greater than 0,
it is on a bridge and needs to be swizzled.  Following the
string of parents up to the root bus and swizzling as we go
gives us the desired swizzling result.  When BIOS_SPEW is
defined, it will print out each step of the swizzling process.

Change-Id: Icafeadd01983282c86e25f560c831c9482c74e68
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/5734
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Mike Loptien <mike.loptien@se-eng.com>