Age | Commit message (Collapse) | Author |
|
Change-Id: I6a0752cf0c0e484e670acca97c4991b5578845fb
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11081
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
:'<,'>s,\ *$,,
Change-Id: I9fca0e12f02d6fff4644abacecd4a31cea64bbc1
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11024
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Fix up all the code that is using / to use >> for divisions instead.
Change-Id: I8a6deb0aa090e0df71d90a5509c911b295833cea
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10819
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Make the build tolerate re-definitions.
Change-Id: Ia7505837c70b1f749262508b26576e95c7865576
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8609
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
As is the case in commit:
3312ed7 amd/agesa/f1?/Lib/amdlib.c: Integer overflow in loop construct
The semantics of this loop relies on an integer overflow in Index >=0
that implies a return value of (UINT8)-1 which around wraps to 0xFF, or
VOLT_UNSUPPORTED.
Also fix an infinite loop.
Change-Id: Iced3eff3ae7b8935db3bdd6147372cf3b540883c
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7676
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
The contents of these files were guarded by a check for the _MSC_VER
macro, which we don't use.
Change-Id: Ic595c8e6284c54e1449cf21e0cebee8c9ce7c682
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/7670
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
|
|
Change-Id: Ica17b2452498f30b710533caf610c9f0c1a0452c
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7594
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
We don't actually use nor support these as our implementation
makes use of gcccar.inc. They maybe useful as a reference for
history so lets keep them in version history.
Change-Id: I388251dead449dde14283e57db39c37982d947b2
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7596
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Sync up these 'Porting.h' headers to include fixes from each
family on botched-up typedef's for primitive data types.
Fix corresponding breakage introduced by typecasts in
mainboards.
Change-Id: I003b155cc6c860f6b0cd75667083634a04814473
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7512
Tested-by: build bot (Jenkins)
|
|
Found missing '$' symbol on variable.
Change-Id: I748c315adc44598e16283f8e629be0ecfe9cb6a9
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: http://review.coreboot.org/7514
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
Change-Id: I05d568f27f610c395e2638e79a7fd6646a407955
Found-by: Clang preprocessor wizard powers
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7441
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Apply commit 283ba78415 to f12 (literally, plus one adaptation).
Change-Id: Ied7891806e269320caf968cae3de3dc792c5f8fd
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7312
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
|
|
Forward port commit:
db0e0e2 amd/agesa/*/gcc-intrin.h: Invaild inline asm
Change-Id: Ife26fb5eca5164e72b5e55eba90757253765b633
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7300
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
|
|
We already have these macros define in 'stdlib.h'. Make good use of them
here to avoid redefinition conflicts of the pre-processor depending on
header inclusion ordering. This has the nice side-effect of syncing up
AGESA families in this particular regard.
Change-Id: Icf911629a4a1a82b01062fe16af4c8f812b05717
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6199
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
|
|
Change-Id: Iace2ccfe95bd7f7e5dabbbc69ee4249d80d1cb84
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6190
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Change-Id: Ieca3358a2a459016b7a38dce7f717100b55baba5
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6186
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
_CPU_L3_FEATIRES_H -> _CPU_L3_FEATURES_H
Spotted by Clang
Change-Id: I1eabebffc7fd5e4f37b28dabcd28984bed64acd8
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5818
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
The semantics of this loop relies on an integer overflow in Index >=0
that implies a return value of (UINT8)-1 which around wraps to 0xFF, or
VOLT_UNSUPPORTED.
Change-Id: I44d68973d0a80093350b2a8a4d3b46bfbb57917a
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5801
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
The function GfxPowerPlayLocateTdp() sets MinDeltaSclk to a maximum
sentinel value and checks DeltaSclk in a loop to minimize MinDeltaSclk.
However, MinDeltaSclk incorrectly self-assigns.
Change-Id: Id01c792057681516bba411adec268769a3549aa8
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5752
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
|
|
Change-Id: I31632948ce69b2d1ff63b6c920016ed6fdf9e2f8
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5760
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Change-Id: I1d801b9d8387e267feeb95563e55910b30ebbc34
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5790
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
They don't exactly add clarity, but increase the risk
they're used at some obscure place.
Change-Id: Ic74f72dae3f9b7eb2343cb5c51bc44c888e1276c
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/5787
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
They're _not_ part of the compiler binary, so they have
no place in $(CC_*)
Change-Id: I1e1c3c0be6f75629450a824ea834e1614d48ed9b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/5785
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
With the upcoming CC/CFLAGS/CPPFLAGS split,
romcc gets more CPPFLAGS, and it's picky about
directories actually existing.
Change-Id: Ib9c525296e5be0c8ace935ab8096bc98206cbcc1
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/5784
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Make all three coreboot stages (bootblock, romstage and ramstage) aware of the
architecture specific to that stage i.e. we will have CONFIG_ARCH variables for
each of the three stages. This allows us to have an SOC with any combination of
architectures and thus every stage can be made to run on a completely different
architecture independent of others. Thus, bootblock can have an x86 arch whereas
romstage and ramstage can have arm32 and arm64 arch respectively. These stage
specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain
and compiler flags for every stage.
These options can be considered as either arch or modes eg: x86 running in
different modes or ARM having different arch types (v4, v7, v8). We have got rid
of the original CONFIG_ARCH option completely as every stage can have any
architecture of its own. Thus, almost all the components of coreboot are
identified as being part of one of the three stages (bootblock, romstage or
ramstage). The components which cannot be classified as such e.g. smm, rmodules
can have their own compiler toolset which is for now set to *_i386. Hence, all
special classes are treated in a similar way and the compiler toolset is defined
using create_class_compiler defined in Makefile.
In order to meet these requirements, changes have been made to CC, LD, OBJCOPY
and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others.
Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the
toolsets are defined using create_class_compiler.
Few additional macros have been introduced to identify the class to be used at
various points, e.g.: CC_$(class) derives the $(class) part from the name of
the stage being compiled.
We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER
as they do not make any sense for coreboot as a whole. All these attributes are
associated with each of the stages.
Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5577
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
|
|
The ROM address range is set up in the LPC PCI device, register 0x6c.
Coreboot already sets that up correctly in the bootblock, however
AGESA overrides that to 0xffffff00, which will always map the ROM from
0xff000000. This may conflict with other devices which are assigned
address space in that range.
If a device is assigned a range between 0xff000000 and the real ROM
base, accesses to that device will be diverted to the system ROM,
regardless of how other BARs are set up. Since we already need to set
up the ROM address range in the bootblock, before calling AGESA, just
remove the override from AGESA.
Note that not all AGESA versions override this mapping.
Change-Id: I592e5d087ed830c9604a04a356912c7654ce56d2
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5467
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
A comparison with a two's complement in gcccar.inc has dubious
GAS/AT&T notation. Clang miss-parses 0x-1 as an invalid hexadecimal
number.
Change-Id: I88baa5c2513f062ff309df05916a3832b9bd9bb1
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5277
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Some files have incorrect/odd permissions,
correct them: remove unnecessary +x flags.
Change-Id: I784e6e599dfee88239f85bb58323aae9e40fb21c
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/4490
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
|
|
Delete files that (were overlooked and) are probably needed to
build with Visual Studio.
Remove doxygen helper files as well.
Change-Id: I6b6cece178917ad9da1081eb6b1bb9be33066a77
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/4489
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
|
|
The bug is hard to find. We were adding the feature of fan control. We
met some strange things which could not be explained. Like, sometimes
adding printk let the error disappear. Then we traced the code by hardware
debug tool (HDT). It turned out the data in stack was overwritten.
The values of AccessWidthxx are
{ AccessWidth8 = 1,
AccessWidth16,
AccessWidth32,}
For the case of AccessWidth8, we only need to access the index/data
once. But ReadECmsg and WriteECmsg did the loop twice, 1 more time
than they are supposed to do. The data in stack next to "Value" would
be overwritten.
For all the cases, the code should be
OpFlag = OpFlag & 0x7f;
switch (OpFlag) {
case 1: /* AccessWidth8 */
OpFlag = 0;break;
case 2: /* AccessWidth16 */
OpFlag = 1;break;
case 3: /* AccessWidth32 */
OpFlag = 3;break;
case 4: /* AccessWidth64 */
OpFlag = 7;break;
default:
error;
}
Actually, the caller only takes AccessWidth8 as the parameter. We can ignore other
cases for now.
That is an AGESA bug. AMD's AGESA team own this code. They have given the
response that they are going to update this in next release. I presume let them
decide the proper way to fix that. Before that, I change the code as little
as possible to make it run without crash.
Change-Id: I566f74c242ce93f4569eedf69ca07d2fb7fb368d
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4297
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
|
|
Northbridge code includes these headers, so they all need to
have the same name to allow different combinations of northbridge
and southbridge. This changes the sb900 names to match sb700 &
sb800, and points agesa/family12 and amd/torpedo to the new file
names.
Change-Id: I7a654ce9ae591a636a56177f64fb8cb953b4b04f
Signed-off-by: Corey Osgood <corey.osgood@gmail.com>
Reviewed-on: http://review.coreboot.org/3825
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The following command was used to correct all occurences of this typo.
$ git grep -l "them implem" | xargs sed -i 's/them implem/then implem/'
Change-Id: Iebd4635867d67861aaf4d4d64ca8a67e87833f38
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3145
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
AGESA code has wrong definition of CR0_PE bit (1 instead of 0).
PE [Protected Mode Enable] is 0 bit in CR0 register
(If PE=1, system is in protected mode, else system is in real mode)
Bit 1 is MP [Monitor co-processor]
(Controls interaction of WAIT/FWAIT instructions with TS flag in CR0)
System uses CR0_PE define, but I didn't expect any consequences because of this bug.
Change-Id: I54d9a8c0ee3af0a2e0267777036f227a9e05f3e1
Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/2591
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
_RDMSR instruction loads the contents of a 64-bit model specific register (MSR)
specified in the ECX register into registers EDX:EAX.
The EDX register is loaded with the high-order 32 bits of the MSR
and the EAX register is loaded with the low-order 32 bits.
EDX:EAX = MSR[ECX]
So bit 49 will be contained in EDX register.
Buggy code instead of bit 49 (CombineCr0Cd) sets bit [49-32=17] (PfcStrideDis).
PfcStrideDis bit disables stride prefetch generation. This leads to memory
bandwidth loss.
_________
Supermicro H8QGI board
After applying this change i observed huge memory bandwidth increase in tests
that runs on small amount of cores. But unfortunately it doesn't affect
overall bandwidth results on 4P system with 48 cores.
So i think that in this system leading limiting factor is
AMD HT-ASSIST feature (Probe filter).
But right now it is not working. System stucks in Linux boot. I have done
some experiments and figured out that stuck happens when system have cores in
compute unit (CU) other than CU with BSC (boot strap core).
CU is two cores (primary and seconary) that shares some things (L2 cache, FPU ...)
So with probe filter i can boot Linux with one (BSC)
or two (BSC + secondary core in its CU) cores.
And with this configuration i can see memory bandwidth on 1 core (or two cores)
close to original bios.
Change-Id: I5a95f5b753d600c70d3c93d36fecc687610c61cd
Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/2588
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Add needed prototypes to .h files.
Remove unused variables and fix types in printk statements.
Add #IFNDEFs around #DEFINEs to keep them from being defined twice.
Fix a whole bunch of casts.
Fix undefined pre-increment behaviour in a couple of macros. These now
match the macros in the F14 tree.
Change a value of 0xFF that was getting truncated when being assigned
to a 4-bit bitfield to a value of 0x0f.
This was tested with the torpedo build.
This fixes roughly 132 of the 561 warnings in the coreboot build
so I'm not going to list them all.
Here is a sample of the warnings fixed:
In file included from src/cpu/amd/agesa/family12/model_12_init.c:35:0:
src/include/cpu/amd/amdfam12.h:52:5: warning: redundant redeclaration of 'get_initial_apicid' [-Wredundant-decls]
In file included from src/cpu/amd/agesa/family12/model_12_init.c:34:0:
src/include/cpu/amd/multicore.h:48:5: note: previous declaration of 'get_initial_apicid' was here
src/northbridge/amd/agesa/family12/northbridge.c:50:10: warning: no previous prototype for 'get_node_pci' [-Wmissing-prototypes]
src/northbridge/amd/agesa/family12/northbridge.c: In function 'get_hw_mem_hole_info':
src/northbridge/amd/agesa/family12/northbridge.c:302:13: warning: unused variable 'i' [-Wunused-variable]
src/northbridge/amd/agesa/family12/northbridge.c: In function 'domain_set_resources':
src/northbridge/amd/agesa/family12/northbridge.c:587:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'device_t' [-Wformat]
src/northbridge/amd/agesa/family12/northbridge.c:587:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'device_t' [-Wformat]
src/northbridge/amd/agesa/family12/northbridge.c:716:1: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat]
In file included from src/mainboard/amd/torpedo/agesawrapper.h:31:0,
from src/northbridge/amd/agesa/family12/northbridge.c:38:
src/vendorcode/amd/agesa/f12/AGESA.h:1282:0: warning: "TOP_MEM" redefined [enabled by default]
In file included from src/northbridge/amd/agesa/family12/northbridge.c:34:0:
src/include/cpu/amd/mtrr.h:31:0: note: this is the location of the previous definition
In file included from src/mainboard/amd/torpedo/agesawrapper.h:31:0,
from src/northbridge/amd/agesa/family12/northbridge.c:38:
src/vendorcode/amd/agesa/f12/AGESA.h:1283:0: warning: "TOP_MEM2" redefined [enabled by default]
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c: In function 'PcieInputParserGetNumberOfComplexes':
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c:99:19: warning: operation on 'ComplexList' may be undefined [-Wsequence-point]
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c: In function 'PcieInputParserGetLengthOfPcieEnginesList':
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c:126:20: warning: operation on 'PciePortList' may be undefined [-Wsequence-point]
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c: In function 'PcieInputParserGetLengthOfDdiEnginesList':
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c:153:19: warning: operation on 'DdiLinkList' may be undefined [-Wsequence-point]
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c: In function 'PcieInputParserGetComplexDescriptorOfSocket':
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c:225:17: warning: operation on 'ComplexList' may be undefined [-Wsequence-point]
src/vendorcode/amd/agesa/f12/Proc/GNB/PCIe/Family/LN/F12PciePhyServices.c:246:1: warning: no previous prototype for 'PcieFmForceDccRecalibrationCallback' [-Wmissing-prototypes]
In file included from src/vendorcode/amd/agesa/f12/Proc/GNB/PCIe/Family/LN/F12PcieComplexConfig.c:58:0:
src/vendorcode/amd/agesa/f12/Proc/GNB/PCIe/Family/LN/LlanoComplexData.h:120:5: warning: large integer implicitly truncated to unsigned type [-Woverflow]
And fixed a boatload of these types of warning:
src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c: In function 'HeapGetBaseAddress':
src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:687:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:694:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:701:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:702:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:705:23: warning: assignment makes integer from pointer without a cast [enabled by default]
src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:709:21: warning: assignment makes integer from pointer without a cast [enabled by default]
Change-Id: I97fa0b8edb453eb582e4402c66482ae9f0a8f764
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2348
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
|
|
Success return value in DMI functions GetDmiInfoMain(..) and GetType4Type7Info(...) of AGESA vendorcode is "Flag = TRUE".
This results in a failure of init late function:
"agesawrapper_amdinitlate failed: 1"
It happens because TRUE = 1 = AGESA_UNSUPPORTED.
Replacing TRUE with AGESA_SUCCESS (= 0) fixes this problem.
Only family f15tn does not have such bug.
This patch just replaces TRUE with AGESA_SUCCESS, but maybe all DMI functions should be copied from Trinity family?
Tested on Supermicro H8QGI board with 4 AMD Opteron 6234 processors (f15).
Change-Id: I51bf91333c088a825b92d4a44d1ebe4380c8026c
Signed-off-by: Aladyshev Konstantin <aladyshev@nicevt.ru>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2070
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Change source file modes from 755 to 644
The following files have been grepped for changes:
*.c
*.h
*Kconfig*
*Makefile*
Change-Id: I275f42ac7c4df894380d0492bca65c16a057376c
Signed-off-by: Alec Ari <neotheuser@ymail.com>
Reviewed-on: http://review.coreboot.org/1023
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Fixes the warnings generated in the torpedo mainboard build by AGESA.
Removing broken tests.
Change-Id: Ib444fa2bf4dd94cadb4ce33040eb5650d1c0325b
Signed-off-by: Martin L Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/667
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This change fixes the use of a macro that was
previously modified to fix a warning. The macro
was used in a manner that doubly incremented a
pointer. The pointer increment was removed from
the macro call and moved elsewhere. In addition,
an unused macro was removed from both Family 12
and Family 14 code.
Change-Id: I577794bbc55d18f21170dda1d0bbdc6d776ce392
Signed-off-by: Frank Vibrans <frank.vibrans@amd.com>
Signed-off-by: efdesign98 <efdesign98@gmail.com>
Reviewed-on: http://review.coreboot.org/217
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
This change updates the AMD Agesa code to support the Family 14
rev C0 cpus. It also fixes (again) a ton of warnings, although
not all of them are gone. The warning fixes affect code in the
Family 12 tree as well, so there are some small changes therein.
This code has been tested on a Persimmon and passes Abuild.
This is the first (and largest) of a number of commits to complete
the upgrade.
Change-Id: Id28d9bf7931f8baa2a602f6bb096a5a465ccd20d
Signed-off-by: Frank Vibrans <frank.vibrans@amd.com>
Signed-off-by: efdesign98 <efdesign98@gmail.com>
Reviewed-on: http://review.coreboot.org/131
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
This is the addition of the AMD Family 12 cpu code.
Change-Id: I3febc81e192b4e86bbd3e8d6e1da62a28598fa8c
Signed-off-by: Frank Vibrans<frank.vibrans@amd.com>
Signed-off-by: efdesign98 <efdesign98@gmail.com>
Reviewed-on: http://review.coreboot.org/40
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
|