Age | Commit message (Collapse) | Author |
|
This reverts commit eed28f97b375a9469a2872996c19eb102647052e.
For whatever reason, the dependencies were lost in Gerrit and the
commit [1] was submitted without its dependencies. As a result
buidling the ASUS F2A85-M fails now [2] and therefore commits
based on this commit fail to pass the buid tests by Jenkins.
[…]
Created CBFS image (capacity = 8387656 bytes)
LINK cbfs/fallback/romstage_null.debug
CC cbfs/fallback/coreboot_ram.debug
coreboot-builds/asus_f2a85-m/generated/coreboot_ram.o:(.data+0x16b9c): undefined reference to `GnbIommuScratchMemoryRangeInterface'
collect2: error: ld returned 1 exit status
make: *** [coreboot-builds/asus_f2a85-m/cbfs/fallback/coreboot_ram.debug] Error 1
make: *** Waiting for unfinished jobs....
coreboot-builds/asus_f2a85-m/mainboard/asus/f2a85-m/buildOpts.romstage.o:(.data+0x3d8): undefined reference to `GnbIommuScratchMemoryRangeInterface'
collect2: error: ld returned 1 exit status
make: *** [coreboot-builds/asus_f2a85-m/cbfs/fallback/romstage_null.debug] Error 1
[…]
Therefore revert the commit to get the tree working again and
submit this patch with its dependencies again.
[1] http://review.coreboot.org/#/c/3317/
[2] http://qa.coreboot.org/job/coreboot-gerrit/6618/testReport/junit/(root)/board/i386_asus_f2a85_m/
Change-Id: I911755884da09eb0a0651b8db07ee2a32e6eaaaa
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3373
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Activate the IOMMU support for the Asus F2A85-M.
Add the device to `devicetree.cb`.
$ pci -s 0.2
[…]
00:00.2 IOMMU: Advanced Micro Devices [AMD] Family 15h (Models 10h-1fh) I/O Memory Management Unit
$ dmesg
[…]
[ 0.000000] ACPI: IVRS 00000000bf144e10 00070 (v02 AMD AMDIOMMU 00000001 AMD 00000000)
[ 0.000000] ACPI: SSDT 00000000bf144e80 0051F (v02 AMD ALIB 00000001 MSFT 04000000)
[ 0.000000] ACPI: SSDT 00000000bf1453a0 006B2 (v01 AMD POWERNOW 00000001 AMD 00000001)
[ 0.000000] ACPI: SSDT 00000000bf145a52 00045 (v02 CORE COREBOOT 0000002A CORE 0000002A)
[…]
[ 0.465114] [Firmware Bug]: ACPI: no secondary bus range in _CRS
[…]
[ 0.567330] pci 0000:00:00.0: >[1022:1410] type 00 class 0x060000
[ 0.567364] pci 0000:00:00.2: >[1022:1419] type 00 class 0x080600
[ 0.567427] pci 0000:00:01.0: >[1002:9993] type 00 class 0x03000
[…]
[ 0.597731] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[ 0.597899] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PIBR._PRT]
[ 0.597933] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.SBR0._PRT]
[ 0.597972] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.SBR1._PRT]
[ 0.598073] pci0000:00: >Requesting ACPI _OSC control (0x1d)
[ 0.603808] pci0000:00: >ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1d
[ 0.612397] ACPI _OSC control for PCIe not granted, disabling ASPM
[ 0.620508] Freeing initrd memory: 14876k freed
[…]
[ 0.882674] pci 0000:00:01.0: >Boot video device
[ 0.882876] PCI: CLS 64 bytes, default 64
[ 0.897088] AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40 extended features: PreF PPR GT IA
[ 0.905816] pci 0000:00:00.2: >irq 40 for MSI/MSI-X
[ 0.917457] AMD-Vi: Lazy IO/TLB flushing enabled
[ 0.922076] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[ 0.928500] software IO TLB [mem 0xbb13d000-0xbf13cfff] (64MB) mapped at [ffff8800bb13d000-ffff8800bf13cfff]
[ 0.938535] LVT offset 0 assigned for vector 0x400
[ 0.943338] perf: AMD IBS detected (0x000000ff)
[ 0.948037] audit: initializing netlink socket (disabled)
[ 0.953432] type=2000 audit(1369659616.800:1): initialized
[ 0.977011] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[…]
[ 7.881938] radeon 0000:00:01.0: >VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used)
[ 7.881941] radeon 0000:00:01.0: >GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF
[…]
[ 7.885516] radeon 0000:00:01.0: >irq 48 for MSI/MSI-X
[ 7.885525] radeon 0000:00:01.0: >radeon: using MSI.
[…]
[ 8.276775] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae000 flags=0x0010]
[ 8.287363] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acc00 flags=0x0010]
[ 8.297945] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae200 flags=0x0010]
[ 8.308527] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae080 flags=0x0010]
[ 8.319109] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae240 flags=0x0010]
[ 8.329694] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001accc0 flags=0x0010]
[ 8.340276] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ace80 flags=0x0010]
[ 8.350858] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acd80 flags=0x0010]
[ 8.361441] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae280 flags=0x0010]
[ 8.372022] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae180 flags=0x0010]
[ 8.382605] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ace00 flags=0x0010]
[ 8.393188] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acdc0 flags=0x0010]
[ 8.403770] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ace40 flags=0x0010]
[ 8.414353] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae1c0 flags=0x0010]
[ 8.424936] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acc40 flags=0x0010]
[ 8.435518] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acc80 flags=0x0010]
[ 8.446100] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae2c0 flags=0x0010]
[ 8.456684] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae300 flags=0x0010]
[ 8.467265] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae340 flags=0x0010]
[ 8.477849] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae380 flags=0x0010]
[ 8.488431] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae3c0 flags=0x0010]
[ 8.499013] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae0c0 flags=0x0010]
[ 8.509596] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acec0 flags=0x0010]
[ 8.520179] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acd00 flags=0x0010]
[ 8.530761] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad000 flags=0x0010]
[ 8.541343] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae400 flags=0x0010]
[ 8.551925] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae440 flags=0x0010]
[ 8.562509] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acf00 flags=0x0010]
[ 8.573090] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae480 flags=0x0010]
[ 8.583675] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae100 flags=0x0010]
[ 8.594257] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae4c0 flags=0x0010]
[…]
[ 8.604840] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acf40 flags=0x0010]
[ 8.615421] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acd40 flags=0x0010]
[ 8.626004] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad140 flags=0x0010]
[ 8.636587] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad040 flags=0x0010]
[ 8.647169] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad080 flags=0x0010]
[ 8.657751] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae500 flags=0x0010]
[ 8.668335] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad100 flags=0x0010]
[ 8.678917] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad0c0 flags=0x0010]
[ 8.689499] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acf80 flags=0x0010]
[ 8.700080] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acfc0 flags=0x0010]
[ 8.710664] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae140 flags=0x0010]
[ 8.721246] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae040 flags=0x0010]
[ 8.731828] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad180 flags=0x0010]
[ 8.742412] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae540 flags=0x0010]
[ 8.752995] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad280 flags=0x0010]
[ 8.763577] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad340 flags=0x0010]
[ 8.774160] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad200 flags=0x0010]
[ 8.784741] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad300 flags=0x0010]
[ 8.795324] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae5c0 flags=0x0010]
[ 8.805906] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae640 flags=0x0010]
[ 8.816490] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad2c0 flags=0x0010]
[ 8.827072] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad1c0 flags=0x0010]
[ 8.837655] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad240 flags=0x0010]
[ 8.848238] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae580 flags=0x0010]
[ 8.858819] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae600 flags=0x0010]
[ 8.869402] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad3c0 flags=0x0010]
[ 8.879985] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad380 flags=0x0010]
[ 8.890568] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae7c0 flags=0x0010]
[ 8.901151] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae740 flags=0x0010]
[ 8.911732] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae6c0 flags=0x0010]
[ 8.922316] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae780 flags=0x0010]
[ 8.932897] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae700 flags=0x0010]
[ 8.943480] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae680 flags=0x0010]
[ 8.963011] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
[ 8.963165] radeon 0000:00:01.0: >WB enabled
[…]
It is not known, what the implications of the `IO_PAGE_FAULT` are.
Change-Id: Ic5fde609322a5fdeb1a48052c403847197752a4b
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/3317
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
After removing power and the CMOS Battery, putting it back
and booting coreboot we have:
# ./nvramtool -a
boot_option = Fallback
last_boot = Fallback
ECC_memory = Enable
baud_rate = 115200
hw_scrubber = Enable
interleave_chip_selects = Enable
max_mem_clock = 400Mhz
multi_core = Enable
power_on_after_fail = Disable
debug_level = Spew
boot_first = HDD
boot_second = Fallback_Floppy
boot_third = Fallback_Network
boot_index = 0xf
boot_countdown = 0xc
slow_cpu = off
nmi = Enable
iommu = Enable
nvramtool: Can not read coreboot parameter user_data because layout info specifies CMOS area that is too wide.
nvramtool: Warning: Coreboot CMOS checksum is bad.
Change-Id: Idea03b9bc75c5c34c7ce521ce5e5a1c1bb6dfa96
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3324
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
On Asus F2A85-M, the Linux kernel complains that the _CRS method does
not specify the number of PCI busses.
[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS
Just put there 256. This should be part of re-factoring of the whole
ACPI stuff.
The same change was already done for the AMD Brazos (SB800) boards,
based on commit »Persimmon DSDT: Add secondary bus range to PCI0«
(4733c647) [1].
[1] http://review.coreboot.org/2592
Change-Id: I06f90ec353df9198a20b2165741ea0fe94071266
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/3320
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
|
|
- SPI controller base address gets overwritten by SD controller under Linux.
- Reason for overwrite is the SPI base address isn't in a standard BAR and doesn't
get automatically reserved. Solution is to add it as a reserved memory area in
ACPI.
- This issue was found on the ASUS F2A85-M platform. Currently a workaround on this
platform was made as part of: http://review.coreboot.org/#/c/3167/3
- Once approved a follow-on patch for other southbridges using a non-standard BAR for
the spi controller.
Change-Id: I1b67da3045729a6754e245141cd83c5b3cc9009e
Signed-off-by: Steven Sherk <steven.sherk@se-eng.com>
Reviewed-on: http://review.coreboot.org/3270
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change `sizeof(type) * n`, where n is the number of array
elements, to `sizeof(variable)` to directly get the size of the
variable (struct, array). Determining the size by counting array
elements is error prone and unnecessary.
Not sure why the copy is needed instead of direct reference.
Maybe it has something to do with CAR?
These changes are based on Rudolf’s original patch »ASUS F2A85-M:
Correct and clean up PCIe config« [1], where it was just done for
the ASUS board.
[1] http://review.coreboot.org/#/c/3194/
Change-Id: I4aa4c6cde5a27b7f335a71afc21d1603f2ae814b
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3247
Tested-by: build bot (Jenkins)
Reviewed-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
|
|
Currently the code in the if statement
if (!byte)
do_smbus_write_byte(0xb20, 0x15, 0x3, byte);
only gets executed if `byte == 0x0`, that means only in the
default case where RAM voltage is 1.5 Volts. But the RAM voltage
should be changed when configured for the non-default case.
So negate the predicate to alter the RAM voltage for the
non-default cases.
To prevent the build error
OBJCOPY cbfs/fallback/coreboot_ram.elf
coreboot-builds/asus_f2a85-m/generated/crt0.romstage.o: In function `cache_as_ram_main':
/srv/jenkins/.jenkins/jobs/coreboot-gerrit/workspace/src/mainboard/asus/f2a85-m/romstage.c:106: undefined reference to `do_smbus_write_byte'
collect2: error: ld returned 1 exit status
make: *** [coreboot-builds/asus_f2a85-m/cbfs/fallback/romstage_null.debug] Error 1
add `southbridge/amd/agesa/hudson/smbus.c` providing the function
`do_smbus_write_byte` to ROM stage in `Makefile.inc`. That can
actually be used after the needed header files are included in a
previous commit.
Change-Id: I89542479c4cf6d412614bcf4586ea98e097328d6
Reported-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3200
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
|
|
These arrays are declared as `static` for AMD SB800 based boards,
so do the same for this generation.
Rudolf Marek just changed `const CODEC_TBL_LIST` to `static const`
in [1]. Adapt all Fam15tn based boards (AMD Parmer, AMD Thatcher,
ASUS F2A85-M) to keep the differences between them small.
[1] http://review.coreboot.org/#/c/3170/3/src/mainboard/asus/f2a85-m/BiosCallOuts.c
Change-Id: I353b38bd8bc77ba500a4b7fe9250e9aa3071c530
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3198
Tested-by: build bot (Jenkins)
|
|
To make it easier to fill in the values, place the table
from the BIOS and Kernel Developer’s Guide (BKDG) [1]
as a comment.
[1] http://www.coreboot.org/Datasheets#AMD_Fam15
Change-Id: I218f76e9fa2dc88d47af51ea6c062e315afb0000
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3221
Tested-by: build bot (Jenkins)
|
|
In `PlatformGnbPcie.c` AGESA functions are used to reserve memory
space to save the PCIe configuration to. This is the
With the following definitions in `AGESA.h`
$ more src/vendorcode/amd/agesa/f14/AGESA.h
[…]
/// PCIe port descriptor
typedef struct {
IN UINT32 Flags; /**< Descriptor flags
* @li @b Bit31 - last descriptor in complex
*/
IN PCIe_ENGINE_DATA EngineData; ///< Engine data
IN PCIe_PORT_DATA Port; ///< PCIe port specific configuration info
} PCIe_PORT_DESCRIPTOR;
/// DDI descriptor
typedef struct {
IN UINT32 Flags; /**< Descriptor flags
* @li @b Bit31 - last descriptor in complex
*/
IN PCIe_ENGINE_DATA EngineData; ///< Engine data
IN PCIe_DDI_DATA Ddi; ///< DDI port specific configuration info
} PCIe_DDI_DESCRIPTOR;
/// PCIe Complex descriptor
typedef struct {
IN UINT32 Flags; /**< Descriptor flags
* @li @b Bit31 - last descriptor in topology
*/
IN UINT32 SocketId; ///< Socket Id
IN PCIe_PORT_DESCRIPTOR *PciePortList; ///< Pointer to array of PCIe port descriptors or NULL (Last element of array must be terminated with DESCRIPTOR_TERMINATE_LIST).
IN PCIe_DDI_DESCRIPTOR *DdiLinkList; ///< Pointer to array DDI link descriptors (Last element of array must be terminated with DESCRIPTOR_TERMINATE_LIST).
IN VOID *Reserved; ///< Reserved for future use
} PCIe_COMPLEX_DESCRIPTOR;
[…]
memory has to be reserved for the `PCIe_COMPLEX_DESCRIPTOR` and,
as two struct members are pointers to arrays with elements of type
`PCIe_PORT_DESCRIPTOR` and `PCIe_DDI_DESCRIPTOR`, space for these
times the number of array elements have to be reserved:
a + b * 5 + c * 2.
sizeof(PCIe_COMPLEX_DESCRIPTOR)
+ sizeof(PCIe_PORT_DESCRIPTOR) * 5
+ sizeof(PCIe_DDI_DESCRIPTOR) * 2;
But for whatever reason parentheses were put in there making this
calculation incorrect and reserving too much memory.
(a + b * 5 + c) * 2
So, remove the parentheses to reserve the exact amount of memory
needed.
The ASRock E350M1 still boots with these changes. No changes were
observed as expected.
Rudolf Marek made this change as part of his patch »ASUS F2A85-M:
Correct and clean up PCIe config« [1]. Factor this hunk out as it
affects all AMD Brazos and Trinity based boards.
[1] http://review.coreboot.org/#/c/3194/
Change-Id: I32e8c8a3dfc5e87eb119eb17719d612e57e0817a
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3239
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
|
|
Revert commit b8b3e8bff32ee7dddcacec11e015f6683783eb2f [1] as
it was merged without its dependencies and therefore the source
tree currently does not build [2][3].
OPTION option_table.h
SCONFIG mainboard/asus/m4a785t-m/devicetree.cb
make: *** No rule to make target `nvramtool', needed by `coreboot-builds/asus_m4a785t-m/coreboot.pre1'. Stop.
make: *** Waiting for unfinished jobs....
OPTION cmos_layout.bin
[1] http://review.coreboot.org/3224
[2] http://www.coreboot.org/pipermail/coreboot/2013-May/075864.html
[3] http://qa.coreboot.org/job/coreboot-gerrit/6251/testReport/junit/(root)/board/i386_asus_m4a785t_m/
Change-Id: I8bf33b62b56627f0eea9440ff5e5136e4122ef01
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/3244
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
After removing power and the CMOS Battery, putting it back
and booting coreboot we have:
# ./nvramtool -a
boot_option = Fallback
last_boot = Fallback
ECC_memory = Enable
baud_rate = 115200
hw_scrubber = Enable
interleave_chip_selects = Enable
max_mem_clock = 400Mhz
multi_core = Enable
power_on_after_fail = Disable
debug_level = Spew
boot_first = HDD
boot_second = Fallback_Floppy
boot_third = Fallback_Network
boot_index = 0xf
boot_countdown = 0xc
slow_cpu = off
nmi = Enable
iommu = Enable
nvramtool: Can not read coreboot parameter user_data because layout info specifies CMOS area that is too wide.
nvramtool: Warning: Coreboot CMOS checksum is bad.
Change-Id: Ifa09c7a468e3e0713b426763266ae633e67d8397
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3224
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Apply the following commit to all AMD boards.
commit 935850e08293cec1cb27d12358b27285e780566a
Author: Stefan Reinauer <reinauer@chromium.org>
Date: Mon May 6 16:16:03 2013 -0700
asrock/e350m1: reduce default stack size
The stack used on the ASRock E350M1 is significantly less than
what we currently set (64k per core). In fact, we use about half
of the default stack size (4k) on core 0 and even less on non
BSP cores [1]:
$ grep stack coreboot_without_patch_but_monotonic_timer.log
CPU1: stack_base 002a0000, stack_end 002afff8
CPU1: stack: 002a0000 - 002b0000, lowest used address 002afda8, stack used: 600 bytes
CPU0: stack: 002b0000 - 002c0000, lowest used address 002bf75c, stack used: 2212 bytes
[…]
Reviewed-on: http://review.coreboot.org/3209
Please note that AGESA seems to define bigger stack sizes. But
these seem to be too much too.
$ git grep STACK_SIZE src/vendorcode/amd
[…]
src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14CacheDefaults.c:#define BSP_STACK_SIZE 16384
src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14CacheDefaults.c:#define CORE0_STACK_SIZE 16384
src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14CacheDefaults.c:#define CORE1_STACK_SIZE 4096
src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14CacheDefaults.c: BSP_STACK_SIZE,
src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14CacheDefaults.c: CORE0_STACK_SIZE,
src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14CacheDefaults.c: CORE1_STACK_SIZE,
[…]
The following command was used to create the patch.
$ git grep -l STACK_SIZE src/mainboard/ | xargs sed -i '/STACK_SIZE/,+3d'
Change-Id: I36b95b7a6f190b64d0639fc036ce2fb0253f3fa1
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3217
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Since this parameter is not used anymore, drop it from
all calls to copy_and_run()
Change-Id: Ifba25aff4b448c1511e26313fe35007335aa7f7a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3213
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
If the SD controller is "off" hudson.c won't disable that because,
there is no code for this yet.
The PCI device is still visible and PCI BAR will be allocated
by Linux. Unfortunately it may happen that the particular address
is used by non-standard BAR for SPI controller.
Change-Id: Ied7c581727541e2c81b0b1c2b70fd32de0014730
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/3167
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Stefan Reinauer suggested 'select UDELAY_LAPIC' did not belong in
f2a85-m/Kconfig. It got there via copy-paste from thatcher/Kconfig
so this commit removes the 'select UDELAY_LAPIC' from both and puts
it in cpu/amd/agesa/family15tn/Kconfig
Since f2a85-m is the only Thatcher board coreboot supports right
now, this should not break any other boards.
Change-Id: I811b579c31f8d259a237d3a6724ad3b17f3a6c3e
Signed-off-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
Reviewed-on: http://review.coreboot.org/3178
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
|
|
Unfortunately, an unneeded mainboard specific `pmio.h` was created
when merging the AMD Parmer and Thatcher ports.
Rudolf used the header from a more generic location
southbridge/amd/agesa/hudson/hudson.h
doing the the ASUS F2A85-M port, but did not delete the `pmio.h`
now unused `pmio.h` header file.
So adapt AMD Parmer and Thatcher to use the Hudson one as done for
the ASUS F2A85-M and delete the now unused mainboard specific header
file `pmio.h` to avoid duplication.
Change-Id: I961cd145ebc3b83e31c638ac453ac95ee19c18db
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2958
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
|
|
The patch is based on Thatcher board. So far it boots Linux (3.2/3.7),
internal network adapter works, AHCI works. External PCI/PCIe slots
works too. Power management/ACPI seems to work.
Internal VGA works with dumped ROM (VGA/DVI), but lacks GART.
PCI pref devices are being relocated by Linux, reason unknown.
This is a good start.
USB and XHCI untested but visible.
Change-Id: I1869aecb2634d548b00b3c9139517d6a0e0c9817
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/2038
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
Here's the great news: From now on you don't have to worry about
hitting the right io.h include anymore. Just forget about romcc_io.h
and use io.h instead. This cleanup has a number of advantages, like
you don't have to guard device/ includes for SMM and pre RAM
anymore. This allows to get rid of a number of ifdefs and will
generally make the code more readable and understandable.
Potentially in the future some of the code in the io.h __PRE_RAM__
path should move to device.h or other device/ includes instead,
but that's another incremental change.
Change-Id: I356f06110e2e355e9a5b4b08c132591f36fec7d9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Despite everywhere the model name M5A88-V is used, in Kconfig the
string M5A88PM-V is used. Searching for that model string on the
WWW does not return anything which is unrelated to coreboot, so
change that string to M5A88-V.
Change-Id: I25cf9d4a5fc3f9b9356e8616452066ebf873f44c
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2613
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: QingPei Wang <wangqingpei@gmail.com>
|
|
Currently for Advansus A785E-I, ASRock E350M1 and ASUS M5A88-V
despite what is chosen in Kconfig »Chipset« menu item,
$ more .config
[…]
# CONFIG_ENABLE_IDE_COMBINED_MODE is not set
CONFIG_IDE_COMBINED_MODE=0x1
# CONFIG_SB800_SATA_IDE is not set
CONFIG_SB800_SATA_AHCI=y
# CONFIG_SB800_SATA_RAID is not set
CONFIG_SB800_SATA_MODE=0x2
[…]
the SATA controller is put into IDE mode.
$ lspci -nn | grep SATA
00:11.0 SATA controller [0106]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 SATA Controller [IDE mode] [1002:4390] (rev 40)
Commit »sb800: Add sata ahci/raid mode kconfig option«
(d4a0e7d0) [1] added the options above to configure the mode
using Kconfig and some SB800 boards were adapted already. For
example commit »persimmon: sb800 sata mode configure update«
(1386fa74) [2] did so for AMD Persimmon.
Doing the same by assigning the Kconfig variable to the value in
`platform_cfg.h` integrates this with the three remaining boards
listed above.
The patch is successfully tested with the ASRock E350M1.
$ lspci -nn | grep SATA
00:11.0 SATA controller [0106]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] (rev 40)
[1] http://review.coreboot.org/225
[2] http://review.coreboot.org/227
Change-Id: I227257e2c8f04f18c27ff00fe62d42e372de67e4
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2610
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
|
|
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.
The following command was used to convert all files.
$ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/'
[1] http://www.gnu.org/licenses/gpl-2.0.txt
Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
|
|
The DSDT header contains the fields OEMID and OEM Table ID. See
for example ACPI specification 4.0a [1]
5.2.11.1 Differentiated System Description Table (DSDT)
on page 135. There Table 5-16 contains the descriptions.
Field Byte Length Byte Offset Description
===================================================
OEMID 6 10 OEM ID
OEM Table ID 8 16 The manufacture model ID.
Currently in coreboot there is no common method what to put in
these fields.
Mostly Intel based boards populate it with "CORE " ore "COREv4"
and AMD based boards populate it with the board vendor and
model number, abbreviated appropriately to fit into these fields.
On most boards the proprietary vendor BIOS seems to leave these
fields – displayed with `sudo dmidecode` under System Information –
blank
To Be Filled By O.E.M.
and fill out the Base Board Information with the board vendor and
model name.
In [2] Jens Rottmann argues that the this is really just the table
ID used for naming it and that »99% of the DSDT code is not board
specific«.
Both approaches seem to have their advantages, but using the
second one, developers often seem to forget to update them (for
example AMD Thather).
The current situation is at least not optimal. and therefore at
least unify the string in the OEM Table ID. If unifying the
OEM ID is also a good idea this should be done too.
If later on it should be decided that the board vendor and model
should be used again, this should be somehow derived from
Kconfig.
The following command was used for the change [3].
$ git grep -l '\/\* TABLE ID \*\/' | xargs sed -i '/TABLE ID/s/"\([^"]*\)"/"COREBOOT"/'
This patch is split out from [2].
[1] http://www.acpi.info/spec40a.htm
[2] http://review.coreboot.org/#/c/2464/
[3] http://stackoverflow.com/questions/5207838/sed-regex-matching-text-between-to-double-quotes-when-a-certain-text-appears-i
Change-Id: Iec98c615ce37f928abc1b500eff5aa865d772cb2
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2472
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
To reduce the differences between these file name the enabling
device function in the directory `src/mainboard` uniformly
`mainboard_enable` [1].
Thanks to the awesome help of gnomon and BlastHardcheese in the
IRC channel #sed on <irc.freenode.net>. gnomon came up with the
following command to do the actual work.
$ cd src/mainboard
$ for f in */*/mainboard.c ; \
> do src="$(awk '/\.enable_dev = /{v=$NF; sub(/,$/,"",v); print v}' "$f")" ; \
> [[ -z $src ]] && continue ; \
> printf '%s\n' "g/${src}/s/${src}\([,(]\)/mainboard_enable\1/p" w | ed -s "$f" ; \
> done
`src/mainboard/digitallogic/msm586seg/mainboard.c` and
`src/mainboard/technologic/ts5300/mainboard.c` had to be adapted
manually as no comma was used separating the struct members.
And with the following statement, gnomon is even more likable!
My pleasure entirely. Good luck with coreboot; I'm a big fan of the project.
[1] http://www.coreboot.org/pipermail/coreboot/2013-February/074548.html
Change-Id: Ife9cd0c2d9cc1ed14afc6d40063450553f06a6c6
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2493
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
`_PLATFORM_CFG_H_`
Reduce unnecessary differences between AMD based boards only
using the file `platform_cfg.h` for configuration making them
a little bit easier to compare.
Inagua & co. mention the board name in several places which are really not
that board specific. Sometimes people even forget to change it:
Union Station’s platform_cfg.h starts with "#ifndef _PERSIMMON_CFG_H_".
Funny. Change that to "_PLATFORM_CFG_H_" everywhere.
The following command was used.
$ find . -name platform_cfg.h | xargs sed -i '/_CFG_H_/s/_.*_/_PLATFORM_CFG_H_/'
More boards seem to use that kind of naming (`git grep _CFG_H_`)
but it is not certain that this will not break anything as for
example the board AMD Dinar also has header files for
configuration stuff for the north- and southbridge.
$ git grep _CFG_H_
[…]
src/mainboard/amd/dinar/platform_cfg.h:#ifndef _PLATFORM_CFG_H_
src/mainboard/amd/dinar/platform_cfg.h:#define _PLATFORM_CFG_H_
src/mainboard/amd/dinar/platform_cfg.h:#endif //_PLATFORM_CFG_H_
src/mainboard/amd/dinar/rd890_cfg.h:#ifndef _RD890_CFG_H_
src/mainboard/amd/dinar/rd890_cfg.h:#define _RD890_CFG_H_
src/mainboard/amd/dinar/rd890_cfg.h:#endif //_RD890_CFG_H_
src/mainboard/amd/dinar/sb700_cfg.h:#ifndef _SB700_CFG_H_
src/mainboard/amd/dinar/sb700_cfg.h:#define _SB700_CFG_H_
src/mainboard/amd/dinar/sb700_cfg.h:#endif //_SB700_CFG_H
[…]
Change-Id: Ida15fa6a7adfc770240ac30e795946000dae3f16
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2464
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
|
|
The following command was used to correct the typo.
$ git grep -l @breif | xargs sed -i 's/@breif/@brief/'
Change-Id: If0b579279de3c41571b9cda643836f5748a752a2
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2473
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The name lapic_cluster is a bit misleading, since the construct is not local
APIC specific by concept. As implementations and hardware change, be more
generic about our naming. This will allow us to support non-x86 systems without
adding new keywords.
Change-Id: Icd7f5fcf6f54d242eabb5e14ee151eec8d6cceb1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2377
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The name pci_domain was a bit misleading, since the construct is only
PCI specific in a particular (northbridge/cpu) implementation, but not
by concept. As implementations and hardware change, be more generic
about our naming. This will allow us to support non-PCI systems without
adding new keywords.
Change-Id: Ide885a1d5e15d37560c79b936a39252150560e85
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2376
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This commit enables the external graphics card.
In order to work, the internal graphic card has to be
disabled, that is done in src/device/device.c through:
vga_onboard->ops->disable(vga_onboard);
which calls the RS780 disable operation introduced in the following
commit: "rs780: add .disable pcie_ops"
This commit was tested with and without the following card:
02:00.0 VGA compatible controller: nVidia Corporation GT218 [GeForce 210] (rev a2)
Thanks Aladyshev for the pointer(in the #coreboot IRC channel on Freenode servers):
Dec 20 19:43:32 <Aladyshev> If you list your internal card in devicetree.cb,
coreboot will distinguish external and internal VGA and choose external one
Change-Id: I92e59dffd158db096a6e99d1ef6e2e248fef933c
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/2067
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: Idcf9349d96297b8cb0ea1e68769e02659ac16ab8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1933
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I24866142eebcb8fdbc7e21f5b2f364a8d1b264b3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1932
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This gets rid of the somewhat unstructured placement of AMD's
sysinfo structure in CAR.
We used to carve out some CAR space using a Kconfig variable,
and then put sysinfo there manually (by "virtue" of pointer magic).
Now it's a variable with the CAR_GLOBAL qualifier, and build
system magic.
For this, the following steps were done (but must happen together
since the intermediates won't build):
- Add new CAR_GLOBAL sysinfo_car
- point all sysinfo pointers to sysinfo_car instead of GLOBAL_VAR
- remove DCACHE_RAM_GLOBAL_VAR_SIZE
- from CAR setup (no need to reserve the space)
- commented out code (that was commented out for years)
- only copy sizeof(sysinfo) into RAM after ram init, where
before it copied the whole GLOBAL_VAR area.
- from Kconfig
Change-Id: I3cbcccd883ca6751326c8e32afde2eb0c91229ed
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1887
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Marc Jones <marcj303@gmail.com>
|
|
- Optionally override FSB clock detection in generic
LAPIC code with constant value.
- Override on AMD Model fxx, 10xxx, agesa CPUs with 200MHz
- compile LAPIC code for romstage, too
- Remove #include ".../apic_timer.c" in AMD based mainboards
- Remove custom udelay implementation from intel northbridges' romstages
Future work:
- remove the compile time special case
(requires some cpuid based switching)
- drop northbridge udelay implementations (i945, i5000) if
not required anymore (eg. can SMM use the LAPIC timer?)
Change-Id: I25bacaa2163f5e96ab7f3eaf1994ab6899eff054
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1618
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When dropping ramstage.a duplicate symbols in ramstage
will start breaking the build. Hence drop all the duplicate
functions implemented by mainboards that have those functions
in generic or component code already.
Change-Id: I5cf8245c67b6f0f348388db54256d28f47017a61
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1865
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
|
|
e.g.
-#if CONFIG_LOGICAL_CPUS == 1
+#if CONFIG_LOGICAL_CPUS
This will make it easier to switch over to use the config_enabled()
macro later on.
Change-Id: I0bcf223669318a7b1105534087c7675a74c1dd8a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1874
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
intel_irq_routing_table is a local structure that should not be used
globally, because it might not be there on all mainboards.
Instead, the API has to be corrected to allow passing a PIRQ table in
where needed.
Change-Id: Icf08928b67727a366639b648bf6aac8e1a87e765
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1862
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Some boards selected GENERATE_ instead of HAVE_
Change-Id: I450c22d7b044f0c88c21692246d452d516a68a83
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1841
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Change-Id: Iaaeee87d70cf052bc7980007cdf1f7dda88b3623
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch is the beginning of a Kconfig cleanup series
- drop CONFIG_HAVE_BUS_CONFIG and add get_bus_conf.c if it
exists in the mainboard directory
- drop duplicate ACPI_SSDTX_NUM from mainboard Kconfig
if it only defines the defaul value of 0
- Add mptable.c, fadt.c, reset.c and ssdtX.asl when they
exist, not based on some Kconfig magic
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ia14a7116dad6a724af7e531920fee9a51fd0b200
Reviewed-on: http://review.coreboot.org/1832
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Ibb6606fe3996e377181872a4544600f2d58c5439
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1834
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
(cosmetical)
Change-Id: I3e01d8fbf2d71abcfcbe47efedd2184566c91df7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1748
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Compose the name from Kconfig strings instead.
As the field is for debug print use only, a minor change in the output
should do no harm. The strings no longer include word "Mainboard".
Change-Id: Ifd24f408271eb5a5d1a08a317512ef00cb537ee2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1635
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The M2V-MX SE DSDT has been a copy from Asus A8V-E SE, which has VT8237R.
But the stuble change in USB interrupt routing went undetected, although
I had some USB troubles on the FOSDEM with low speed devices.
Change-Id: Ie724df440e0963f6955b3de57e4687f3ddc7f6ef
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/1505
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
|
|
A missing mptable.c file got passed jenkins, got merged
and broke the build. Hopefully finally fix this.
Deletes unused files:
src/mainboard/asus/dsbf/mptable.c
src/mainboard/supermicro/x7db8/mptable.c
Change-Id: Ie81f5a6c4c69ab381f86a243bc8874395e69ee26
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1486
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
The includes removed here were previously required for
struct lb_memory and lb_add_memory_range().
Change-Id: Ie6c0d4ef55c2225aa709cf3fbad30ff1080e3610
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1391
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
These existed to provide a hook to add reserved memory regions
in the coreboot memory table. Reserved memory are now
added as resources.
Change-Id: I9f83df33845cfa6973b018a51cf9444dbf0f8667
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1414
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
|
|
UMA region can be determined at any time after the amount
of RAM is known and before the uma_resource() call.
Change-Id: I2a0bf2d3cad55ee70e889c88846f962b7faa0c7e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1379
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
|
|
Use of uma_resource() in northbridge code created a memory
resource marked as reserved. Such resources are removed
from system memory in write_coreboot_table().
Change-Id: I14bfd560140d8d30ec156562f23072bfae747bde
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1238
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
|
|
This reverts commit 78efc4c36c68b51b3e73acdb721a12ec23ed0369.
The broadcast patch was reverted, so this commit should also
be reverted. The reason for reverting the broadcast patch:
It turned out that sending IPIs via broadcast doesn't work on
Sandybridge. We tried to come up with a solution, but didn't
found any so far. So revert the code for now until we have
a working solution.
Change-Id: I05c27dec55fa681f455215be56dcbc5f22808193
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1380
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
mainboard_config never worked right, at least not since we've had sconfig.
Hence, drop mainboard/<vendor>/<device>/chip.h and fix up the mainboards that
tried to use it anyways.
Change-Id: I7cd403ea188d8a9fd4c1ad15479fa88e02ab8e83
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1359
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|