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>
This feature has not been used and was never fully integrated.
In the progress of cleaning up coreboot, let's drop it.
Change-Id: Ib40acdba30aef00a4a162f2b1009bf8b7db58bbb
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3251
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The following commit
commit 05f3b117dd
Author: Paul Menzel <paulepanter@users.sourceforge.net>
Date: Tue May 14 09:28:26 2013 +0200
AMD Inagua: PlatformGnbPcie.c: Allocate exact needed size for buffer
Reviewed-on: http://review.coreboot.org/3246
changed one calculation for the size of the array PortList[] to
reflect only four elements, but neglected three additional calculations
of the size of the same table.
Correct that by setting the size for four array elements in all four
calculations.
[1] http://review.coreboot.org/#/c/3239/3/src/mainboard/amd/inagua/PlatformGnbPcie.c
Change-Id: Ib66b7b2b388d847888663e9eb6d1c8c9d50b9939
Reported-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3250
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
The following commit
commit d0790694b0
Author: Kerry Sheh <shekairui@gmail.com>
Date: Thu Jan 19 13:18:37 2012 +0800
Inagua: Inagua GNB ddi lanes and pcie lanes config update
Reviewed-on: http://review.coreboot.org/544
assigns lanes 4 and 5 to PCI device number 4, but does not
adapt the rest of the code.
After the commit above, the array `PortList []` only has four
elements, but the buffer size `AllocHeapParams.RequestedBufferSize`
is set to a size as it still has five elements.
Correct that by setting the size for four array elements.
[1] http://review.coreboot.org/#/c/3239/3/src/mainboard/amd/inagua/PlatformGnbPcie.c
Change-Id: I3ff07f308ffd417d2bf73117eda9da2a1a05f199
Reported-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3246
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@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 f90071faee [1] as
it was merged without its dependencies and therefore the source
tree currently does not build [2][3].
OPTION option_table.h
GEN build.h
SCONFIG mainboard/pcengines/alix1c/devicetree.cb
CC arch/x86/lib/cbfs_and_run.romstage.o
CC arch/x86/lib/memcpy.romstage.o
CC arch/x86/lib/memset.romstage.o
CC arch/x86/lib/rom_media.romstage.o
CC arch/x86/lib/romstage_console.romstage.o
CC console/die.romstage.o
CC console/post.romstage.o
CC console/vtxprintf.romstage.o
CC device/device_romstage.romstage.o
CC lib/cbfs.romstage.o
CC lib/compute_ip_checksum.romstage.o
CC lib/gcc.romstage.o
CC lib/lzma.romstage.o
CC lib/memchr.romstage.o
CC lib/memcmp.romstage.o
CC lib/memmove.romstage.o
CC lib/ramtest.romstage.o
CC lib/uart8250.romstage.o
CC southbridge/amd/cs5536/smbus.romstage.o
ROMCC generated/bootblock.inc
GEN generated/bootblock.ld
make: *** No rule to make target `nvramtool', needed by `coreboot-builds/pcengines_alix1c/coreboot.pre1'. Stop.
make: *** Waiting for unfinished jobs....
OPTION cmos_layout.bin
[1] http://review.coreboot.org/#/c/3229/
[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_pcengines_alix1c/
Change-Id: I4764d90c39ccdb4dc7e7a9aef7525c306614e1a8
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/3245
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This was an early bring-up reference board for ULT but it is no
longer being worked on and was never complete enough to be useful
and I no longer have a board so it is already stale and untested.
All ULT bring-up work has moved to the wtm2 mainboard instead.
Change-Id: If64d61bf7a3fc8c9e16096ffc28fa4128aa99477
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48897
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3231
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The format of this function changed but was not updated in
all mainboards. This fixes BaskingRidge and WTM2.
The int15 handler no longer takes a regs structure as an
argument and instead uses global variables. The yabel interface
is now similar enough that we can drop the duplicate handler.
Change-Id: Ia717ae14f99cee6d83ccdb1e26b9d7defe1638c4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48896
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3230
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This option has never had much if any use. It solved a problem over 10
years ago that resulted from an argument over the value or lack thereof
of including all the debug strings in a coreboot image. The answer is
in: it's a good idea to maintain the capability to print all messages,
for many reasons.
This option is also misleading people, as in a recent discussion, to
believe that log messges are controlled at build time in a way they are
not. For the record, from this day forward, we can print messages at all
log levels and the default log level is set at boot time, as directed by
DEFAULT_CONSOLE_LOGLEVEL. You can set the default to 0 at build time and
if you are having trouble override it in CMOS and get more messages.
Besides, a quick glance shows it's always set to max (9 in this case) in
the very few cases (1) in which it is set.
Change-Id: I60c4cdaf4dcd318b841a6d6c70546417c5626f21
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3188
Tested-by: build bot (Jenkins)
The macros GNB_GPP_PORTx_PORT_PRESENT, GNB_GPP_PORTx_SPEED_MODE,
GNB_GPP_PORTx_LINK_ASPM and GNB_GPP_PORTx_CHANNEL_TYPE are not used.
Change-Id: I5c7b7d45880367dba452ebcd4f01fbd0c15aac22
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3087
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Apply the following commit to all AMD boards.
commit 935850e082
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>
This option has not been enabled on any board and was considered
obsolete last time it was touched. If we need the functionality,
let's fix this in a generic way instead of a K8 specific way.
This was mostly a speedup hack back in the day.
Change-Id: Ib1ca248c56a7f6e9d0c986c35d131d5f444de0d8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3211
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
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>
it has been unused since 9 years or so, hence drop it.
Change-Id: I0706feb7b3f2ada8ecb92176a94f6a8df53eaaa1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3212
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
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
Removing the Kconfig variable STACK_SIZE to use the default results
in the following numbers of stack usage.
$ grep stack coreboot_with_patch.log
CPU1: stack_base 00287000, stack_end 00287ff8
CPU1: stack: 00287000 - 00288000, lowest used address 00287da8, stack used: 600 bytes
CPU0: stack: 00288000 - 00289000, lowest used address 0028875c, stack used: 2212 bytes
[1] http://review.coreboot.org/#/c/3154/
(comment May 2 10:21 AM)
Change-Id: Ibdb2102c86094fce3787e3b5a162ca8423de205c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3209
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This re-introduces 2fde966 (http://review.coreboot.org/#/c/3177/)
which was reverted due to unsatisfied dependencies.
time.h We Hardly Knew Ye.
This deprecates time.h which is currently only used by Exynos5250 and
Snow. The original idea was to try and unify some of the various timer
interfaces and has been supplanted by the monotonic timer API.
timer_us() is now obsolete. timer_start() is now mct_start() and
is exposed in exynos5250/clk.h.
Change-Id: I8e60105629d9da68ed622e89209b3ef6c8e2445b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3201
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
1. Move comment for console init to correct place.
2. Start output with capital letter and add full stop at the end.
3. Add missing »)« at the end of description of GPIO 10.
4. Use tabulators instead of spaces.
5. Indent the code automatically using GNU indent [1] with the `-sc`
switch adding stars in front of comment blocks as the good indent
manual documents.
$ indent -linux -sc src/mainboard/lenovo/x60/romstage.c
Leave the numbers left aligned as it is more beneficial to be
able to run indent without adapting the result afterward.
[1] http://www.coreboot.org/Development_Guidelines#Coding_Style
Change-Id: I2fa018ec28ff19d23d68754b565c13a7d7a57355
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3185
Tested-by: build bot (Jenkins)
Reviewed-by: Denis Carikli <GNUtoo@no-log.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This reverts commit 2fde9668b4
Somehow this got merged before its dependencies. 3190 must be merged first, followed by 3176. However 3190 will fail while this patch is in. So the situation can't correct itself.
Reverting this until the other two go in.
Change-Id: I176f37c12711849c96f1889eacad38c00a8142c4
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3195
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
time.h We Hardly Knew Ye.
This deprecates time.h which is currently only used by Exynos5250 and
Snow. The original idea was to try and unify some of the various timer
interfaces and has been supplanted by the monotonic timer API.
timer_us() is now obsolete. timer_start() is now mct_start() and
is exposed in exynos5250/clk.h.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I14ebf75649d101491252c9aafea12f73ccf446b5
Reviewed-on: http://review.coreboot.org/3177
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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)
The "gigabit ethernet controller" (GEC) block was added to AMD
Hudson A55E to integrate ethernet capabilities into an AMD
southbridge.
The GEC is designed to work with B50610 and B50610M gigabit PHY
chips from Broadcom. These parts may not be generally available
in small quantities for embedded development.
The GEC block requires an opaque firmware blob to function. The
GEC blob is controlled by AMD and Broadcom and is not available
from coreboot.org.
This change removes GEC support from AMD Parmer and AMD Thatcher
mainboards since these boards do not have the Broadcom PHY.
AMD has requested that the GEC be hidden for Hudson FCH since
the PHY parts are not generally available. This Kconfig option
can make it appear that this is a viable and supported way to
add Ethernet to an embedded board. It is possible to use the
Hudson GEC block with other PHYs, but this requires development
of a custom GEC blob and a custom Ethernet driver. A custom GEC
blob has been developed for a Micrel PHY, but there is no
accompanying driver.
Change-Id: I7a7bf4d41e453390ecf987c9c45ef2434fc1f1a3
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3127
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
It's fine to always start timer even in suspend/resume mode, so we can
move the timer_start() back to the very beginning of boot procedure.
That provides more precise boot time information.
With that timer change, the wake up state test procedure can be simplified.
Verified by building and booting firmware image on Google/Snow successfully,
and then suspend-resume without problem (suspend_stress_test).
Change-Id: I0d739650dbff4eb3a75acbbf1e4356f2569b487d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3151
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The firmware media source (SPI1) is already initialized by Exynos iROM.
There is no need to do it again.
Verified by building and booting Google/Snow successfully.
Change-Id: I89390506aa825397c0d7e52ad7503f1cb808f7db
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3147
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The "console_init" does initialize UART driver (which will setup peripheral and
pinmux) and print starting message. Duplicated initialization can be removed.
Also, console_init (from console.c) is always linked to bootblock (and will do
nothing if CONFIG_EARLY_CONSOLE is not defined) so it's safe to remove #ifdef.
Verified by building and booting on Google/Snow, with and without
CONFIG_EARLY_CONSOLE.
Change-Id: I0c6b4d4eb1a4e81af0f65bcb032978dfb945c63d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3150
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Enable `EARLY_CBMEM_INIT` for CBMEM console support by looking how
other boards do this.
This commit is tested by enabling the CBMEM console (`CONSOLE_CBMEM` in
Kconfig) and then in GRUB 2 (as a payload) with the cbmemc command from
the cbmemc module and in userspace with ./cbmem -c. Both worked.
Change-Id: I34618a55ded7292a411bc232eb76267eec17d91e
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3142
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
The DDR3 memory initialization (with "mem_reset" set on normal boot) will cause
resume to be unstable, especially when X is running. System may show X screen
for few seconds, then crash randomly and unable to recover - although text
console may still work for a while. Probably caused by corrupted memory pages.
'mem_reset' (which refers to RESET# in DDR3 spec) should be enabled according
to DDR3 spec. But it seems that on Exynos 5, memory can be initialized without
setting mem_reset for both normal boot and resume - at least no known failure
cases are found yet. So this can be a temporary workaround.
Verified by booting a Google/Snow device with X Window and ChromeOS, entering
browser session with fancy web pages, closing LID to suspend for 5 seconds, then
re-opening to resume. Suspend/resume worked as expected.
Also tried the "suspend_stress_test" with X running and finished 100 iterations
of suspend/resume test without failure.
Change-Id: I7185b362ce8b545fe77b35a552245736c89d465e
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3148
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add the suspend/resume feature into bootblock and romstage.
Note, resuming with X and touchpad driver may be still unstable.
Verified by building and booting successfully on Google/Snow, and then executing
the "suspend_stress_test" in text mode ("stop ui; suspend_stress_test") in
Chromium OS, passed at least 20 iterations.
Change-Id: I65681c42eeef2736e55bb906595f42a5b1dfdf11
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3102
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Move board setup procedure to snow_setup_* functions, and Snow board-specific
(wakeup) code to snow_* for better function names and comments.
Verified by successfully building and booting on Google/Snow.
Change-Id: I2942d75064135093eeb1c1da188a005fd255111d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3130
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The "wakeup" procedure will be shared by bootblock and romstage for different
types of resume processes.
Note, this commit does not include changes in romstage/bootblock to enable
suspend/resume feature. Simply adding functions to handle suspend/resume.
Verified by successfully building and booting Google/Snow firmware image.
Change-Id: I17a256afb99f2f8b5e0eac3393cdf6959b239341
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3129
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
To support suspend/resume, PHY control must be reset only on normal boot
path. So add a new param "mem_reset" to specify that.
Verified to boot successfully on Google/Snow.
Change-Id: Id49bc6c6239cf71a67ba091092dd3ebf18e83e33
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3128
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It seems that ConnectorTypeDP in DdiList supports both DP and HDMI monitors.
I tested by DP monitor and HDMI monitor connected by passive DP->HDMI adapter.
Video and audio are OK. Hot plugging is also supported.
This commit partially reverts commit >AMD Thatcher: Fix PCIE link issues< (7f23aeb0) [1].
[1] http://review.coreboot.org/3011
Change-Id: I23cf1c69a8274f47daf56f1a12aafd88bad4a128
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3088
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds support for display bring-up on Snow. It
includes framebuffer initialization and LCD enable functions.
Change-Id: I16e711c97e9d02c916824f621e2313297448732b
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3116
Tested-by: build bot (Jenkins)
Due to
$ more src/southbridge/amd/cimx/sb800/Makefile.inc
[…]
romstage-y += cfg.c
romstage-y += early.c
romstage-y += smbus.c
ramstage-y += cfg.c
ramstage-y += late.c
[…]
`src/southbridge/amd/cimx/sb800/` is passed with the switch `-I` to
the compiler, where it is also going to find the header file
`sb_cimx.h`. Therefore use `#include <sb_cimx>` everywhere, which is
what some AMD SB800 based boards already do.
The only effect is, that the compiler will not needlessly look into
directories which do not contain the header file [1].
The following command was used for the replacement.
$ git grep -l sb_cimx.h src/mainboard/ | xargs sed -i 's/#include "sb_cimx.h"/#include <sb_cimx.h>/'
[1] http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
Change-Id: I96ab34bac1524e6c38c85dfe9d99cb6ef55e6d7c
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3118
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This PLL is unused and can be disabled to save about 250mW.
Change-Id: I1be37304d6ea5ff78696e05ad1023ce3c57f636c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3109
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This just cleans up a few areas:
- Removed an unnecessary delay from exynos_dp_bridge_setup()
- The delay at the end of exynos_dp_bridge_init() is necessary, so
removed the comment suggesting that it might not be.
- Simplified exynos_dp_hotplug
Change-Id: I44150f5ef3958e333985440c1022b4f1544a93aa
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3113
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This enables clock gating to save power on unused IPs.
Change-Id: I9ab2a2535ebb91bb4110390a6f055a67146bdbf9
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3110
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch is based on >>AMD Thatcher: ConnectorTypeDP supports both DP and HDMI<< (I23cf1c6) [1]
I tested by DP monitor and HDMI monitor connected by passive DP->HDMI adapter.
Video and audio are OK. Hot plugging is also supported.
[1] http://review.coreboot.org/#/c/3088/
Change-Id: I291beff43609ecb68ece24939f2dbc7c08dd0374
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3090
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This enables the thermal management unit (TMU) on Snow.
Change-Id: Idd76af40bf0a5408baf61ef2665fd52ae4e260ba
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3108
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Same splitting as done on Persimmon and ASRock.
Moving common DSDT code to common areas and adding
new files as necessary. Boards updated are:
Inagua
Union-Station
South-Station
Change-Id: I8c9eea62996b41cea23a9c16858c4249197f6216
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/3051
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
1) The macros GNB_GPP_PORTx_PORT_PRESENT, GNB_GPP_PORTx_SPEED_MODE,
GNB_GPP_PORTx_LINK_ASPM and GNB_GPP_PORTx_CHANNEL_TYPE are not used.
This is based on >AMD Thatcher: remove unused macros in PlatformGnbPcieComplex.h< [1].
2) Disable unused PCIE port in devicetree.cb.
PCIE port 3 is not used in Parmer.
This is based on item 3 of >AMD Thatcher: Fix PCIE link issues< [2].
[1] http://review.coreboot.org/#/c/3087/
[2] http://review.coreboot.org/#/c/3011/
Change-Id: Id6f00d5e77ce5133d9ef3db07f95ad03a59e061a
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3099
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This function isn't yet used for much, or perhaps anything, but where it
appears in the code it's ored with other values. Since we're not actually
retrieving anything, it might be best to return 0 so that the other values
that are being ored in can be expressed and this function can stay dormant
until it actually has something to do.
Change-Id: I6edc222a5c2d00ece2ecfad5191a615331eeaf16
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3098
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
We need to read it to report its value to the payload. The kernel will
reconfigure it as an external interrupt, but we'll make it a regular input
for now.
Change-Id: I019bd2c2731144d3b7bb53fad0c2c903874f616c
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3096
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
These names were inherited from chromeos.c where they've already been
fixed.
Change-Id: I7ad57b979b7b8f42f6bd68d1ecf887caba3fa3f1
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3095
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
ARM doesn't use option ROMs, so this value doesn't make sense.
Change-Id: I1a0f0854e1dd4b9594ca0c147e590337520436da
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3094
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Got rid of a lot of #defines, some of which were converted to enums and
the rest which were eliminated entirely. Got rid of cruft in
get_developer_mode_switch and started using it for the dev mode GPIO.
Instead of a macro defining how many GPIOs are expected, now the code
actually counts the GPIOs as they're added.
Change-Id: I97b6b9f52a72d1276eb3cf36d7f9dd7b335b4d19
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3093
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Implement the get_recovery_mode_switch function using the newly added I2C
based Chrome EC support.
Change-Id: I9d0200629887f202edf017cba3222a7d7f5b053e
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3092
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
The comment about the lid switch was left over from when this file was copied
from another board and was incorrect. Also fixed a capitalization
inconsistency.
Change-Id: Icefd19047971e13c08f615578e4a181e82a2997f
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3091
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
The code has been taken from the google link mainboard
and modified to fit the ThinkPad X60.
Change-Id: Ie16e45163acdc651ea46699ecc33055bfd34099c
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/2998
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Google's Chrome EC can be installed on LPC or I2C bus, using different command
protocol. This commit adds I2C support for devices like Google/Snow.
Note: I2C interface cannot be automatically probed so the bus and chip number
must be explicitly set.
Verified by booting Google/Snow, with following console output:
Google Chrome EC: Hello got back 11223344 status (0)
Google Chrome EC: version:
ro: snow_v1.3.108-30f8374
rw: snow_v1.3.128-e35f60e
running image: 1
Change-Id: I8023eb96cf477755d277fd7991bdb7d9392f10f7
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3074
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These are not defined since commit »Drop HAVE_MAINBOARD_RESOURCES«
(1c5071d1) [1] but were unfortunately introduced again in new ports.
[1] http://review.coreboot.org/1414
Change-Id: I5eb61628141aefd08779615702d51ca155fa632a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/2707
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This removes the wait_ms argument from the dp_controller_init(). The
only delay involved is a constant 60ms delay that happens if
everything else goes well. This delay is derived from the LCD spec
so there's no reason it should be baked into the controller code.
(This patch also has the side-effect of fixing a bug where we were
delaying on an undefined value for wait_ms).
Change-Id: I03aa19f2ac2f720524fcb7c795e10cc57f0a226e
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3078
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add a microsecond timer, its declaration, the function to start it,
and its usage. To start it, one calls timer_start(). From that point
on, one can call timer_us() to find microseconds since the timer was
started.
We show its use in the bootblock. You want it started very early.
Finally, the delay.h change having been (ironically) delayed, we
create time.h and have it hold one declaration, for the timer_us() and
timer_start() prototype.
We feel that these two functions should become the hardware specific
functions, allowing us to finally move udelay() into src/lib where it
belongs.
Change-Id: I19cbc2bb0089a3de88cfb94276266af38b9363c5
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3073
Tested-by: build bot (Jenkins)
This reverts commit 1fde22c54c:
commit 1fde22c54c
Author: Patrick Georgi <patrick.georgi@secunet.com>
Date: Tue Apr 9 15:41:23 2013 +0200
siemens/sitemp_g1p1: Make ACPI report the right mmconf region
ACPI reported the entire space between top-of-memory and some
(relatively) arbitrary limit as useful for MMIO. Unfortunately
the HyperTransport configuration disagreed. Make them match up.
Other boards are not affected since they don't report any region
for that purpose at all (it seems).
Change-Id: I432a679481fd1c271f14ecd6fe74f0b7a15a698e
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3047
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It sneaked in without it's dependencies and, therefore, broke the build for
all amdk8 targets. Paul Menzel already commented on the issue in [1]. It
also doesn't look like the dependencies would be pulled soon [2].
[1] http://review.coreboot.org/#/c/3047/
[2] http://review.coreboot.org/#/c/2662/
Change-Id: Ica89563aae4af3f0f35cacfe37fb608782329523
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3063
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
1). Thatcher PCIE x8 slot is reverse order.
Although the PCIE slot is x16, it actually uses 8 lanes(15:8).
Because the PCIE slot is configured by PortList[0], fix this item can enable the slot.
A x1 PCIE network adapter works well in this slot.
2). Fix DdiList to detect DP monitor or HDMI monitor.
GPIO50 can be used to detect DP0/HDMI0 monitor.
If GPIO50 is 1, it is DP monitor. If GPIO50 is 0, it is HDMI monitor.
GPIO51 can be used to detect DP1/HDMI1 in the same way.
3). Disable unused PCIE port and clean up code in PlatformGnbPcie.c and devicetree.cb.
PCIE port 3 and 7 are not used in Thatcher.
Change-Id: I8524b6fc1b6cdc03ba92e7191186bfb0986767c8
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3011
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Split the Persimmon DSDT into common code areas.
For example, split the Southbridge specific code into
the Southbridge directory and CPU specific code into
the CPU directory. Also adding the superio.asl file
to the Persimmon DSDT tree. This file is empty for
the moment but will be necessary in the future. I have
also emptied the thermal.asl file in the mainboard
directory because it does not seem to perform as
intended (fan control does not change when it is
brought back into the code base) and it has been
inside a '#if 0' statement for a long time. Removing
it until it is decided that it is actually necessary.
This change was verified in three different ways:
1. Visual comparison of the compiled DSDT pulled from the
Persimmon after booting into Linux using the ACPI tools
acpidump, acpixtract, and iasl. The comparison was done
between the DSDT before and after doing the split work.
This test is somewhat difficult considering the expanse
of the changes. Blocks of code have been moved, and
others changed.
2. Linux logs were dumped before and after the DSDT split.
Logs dumped and compared include dmesg and lspci -tv.
Neither log changed significantly between the two compare
points.
3. The test suite FWTS was run on the Coreboot build both
before and after doing the DSDT split with the command
'sudo fwts -b -P -u'. The flag -b specifies all batch jobs,
-P specifies all power tests, and -u specifies utilities.
Interactive jobs were not run as most of them consist of
laptop checks. Again, there were no significant changes
between the two endpoints.
These tests lead me to believe that there was no change in
the functionality of the ACPI tables apart from what is
known and expected.
This patch is the first of a series of patches to split the DSDT.
The ASRock patch was merged before this one and breaks the ASROCK
E350M1 build (patch 8d80a3fb: http://review.coreboot.org/#/c/3050/).
Please be aware of this dependency when pulling these patches.
Other patches that depend on this patch are
'AMD Fam14: Split out the AMD Fam14 DSDT'
(http://review.coreboot.org/#/c/3051/)
and 'Fam14 DSDT: Also return for unrecognized UUID in _OSC'
(http://review.coreboot.org/#/c/3052/)
Change-Id: I53ff59909cceb30a08e8eab3d59b30b97c802726
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/3048
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
We need these to be inputs so they can be read when populating the coreboot
tables. It seems like a good idea to do this early to ensure that the input
gate capacitance has had a chance to charge, and if we decide to use
actually use that information during the ROM stage to do earlier RW
firmware selection.
It is not guarded by a ChromeOS config variable because those lines are
always intended to be input GPIOs, regardless of whether we're running
ChromeOS or not.
Change-Id: Id76008931b5081253737c6676980a1bdb476ac09
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3067
Tested-by: build bot (Jenkins)
This is the same split as was done on the Persimmon.
Change-Id: I25bd63f23417b7926232f07eaaa7917170af9d60
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/3050
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
ACPI reported the entire space between top-of-memory and some
(relatively) arbitrary limit as useful for MMIO. Unfortunately
the HyperTransport configuration disagreed. Make them match up.
Other boards are not affected since they don't report any region
for that purpose at all (it seems).
Change-Id: I432a679481fd1c271f14ecd6fe74f0b7a15a698e
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3047
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add basic edp support to the ramstage. Not working.
Change-Id: I15086e03417edca7426c214e67b51719d8ed9341
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3055
Tested-by: build bot (Jenkins)
This is a simpler device tree that is also more correct,
and has graphics settings as well.
Change-Id: I342d8be7dddb76e6992876c73f5c625c926977d3
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3053
Tested-by: build bot (Jenkins)
This re-factors the Exynos5 I2C code to be simpler and use the
new API, and updates users accordingly.
- i2c_read() and i2c_write() functions updated to take bus number
as an argument.
- Get rid of the EEPROM_ADDR_OVERFLOW stuff in i2c_read() and
i2c_write(). If a chip needs special handling we should take care
of it elsewhere, not in every low-level i2c driver.
- All the confusing bus config functions eliminated. No more
i2c_set_early_config() or i2c_set_bus() or i2c_get_bus(). All this
is handled automatically when the caller does a transaction and
specifies the desired bus number.
- i2c_probe() eliminated. We're not a command-line utility.
- Let the compiler place static variables automatically. We don't need
any of this fancy manual data placement.
- Remove dead code while we're at it. This stuff was ported early on
and much of it was left commented out in case we needed it. Some
also includes nested macros which caused gcc to complain.
- Clean up #includes (no more common.h, woohoo!), replace debug() with
printk().
Change-Id: I8e1f974ea4c6c7db9f33b77bbc4fb16008ed0d2a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3044
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The existing header was imported along with the Exynos code and left
mostly unchanged. This is the first patch in a series intended to
replace the imported u-boot I2C API with a much simpler and cleaner
interface:
- We only need to expose i2c_read() and i2c_write() in our public API.
Everything else is board/chip-dependent and should remain hidden
away.
- i2c_read and i2c_write functions will take bus number as an arg
and we'll eliminate i2c_get_bus and i2c_set_bus. Those are prone to
error and end up cluttering the code since the user needs to save
the old bus number, set the new one, do the read/write, and restore
the old value (3 added steps to do a simple transaction).
- Stop setting default values for board-specific things like SPD
and RTC bus numbers (as if we always have an SPD or RTC on I2C).
- Death to all the trivial inline wrappers. And in case there was any
doubt, we really don't care about the MPC8xx. Though if we did then
we would not pollute the public API with its idiosyncrasies.
Change-Id: I4410a3c82ed5a6b2e80e3d8c0163464a9ca7c3b0
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3043
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Originally developed by LiPPERT and after the acquisition marketed as
'LiPPERT by ADLINK', the plan is now to streamline both boards into the
ADLINK naming scheme. But AFAIK a few have already been sold and as of
this writing the website still advertises the old names. And in any case
the veteran LX products will continue to be sold by ADLINK under their
original names.
So create CONFIG_VENDOR_ADLINK, currently only telling users to look under
LiPPERT (however any future boards will be added here).
Further add an explanation to CONFIG_VENDOR_LIPPERT, and in the Mainboard
model selection show both names.
Change-Id: Iaafa88533ef4cce33243293c3d55754e7e93d003
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/3046
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This moves highly board-specific code out from the Exynos5250
power_init() into Snow's romstage.c. There's no reason the CPU-
specific code should care about which PMIC we are using and
which bus it is on.
Change-Id: I52313177395519cddcab11225fc23d5e50c4c4e3
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3034
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This was a first pass at display port support, we have
realized that it was ultimately a bad path. The display
hardware is intimately tied into a specific cpu and
mainboard combination, and the code has to be elsewhere.
The devicetree formatting is ugly, but it matters not:
it's changing soon.
Change-Id: Iddce54f9e7219a7569315565fac65afbbe0edd29
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3029
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Commit 5d741567 added a prototype to broadcom.c to fix a warning. This part
is fine.
It also changed mainboard.c to #include broadcom.c. But broadcom.c is
already in Makefile.inc, now building will fail because the linker gets
broadcom_init() twice.
Undo the change to mainboard.c but keep the change to broadcom.c.
Change-Id: Ieccc098f477ffacccf4174056998034a220a9744
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/3012
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Now that the ASRock E350M1 builds without any warnings, remove the
config option `WARNINGS_ARE_ERRORS` set to no by default from
the file `Kconfig` so warnings are treated as errors to prevent
code from being added in the future introducing warnings.
Change-Id: Idfecfb1434158969334a4b37972b5fc6fd76e72a
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3014
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
When building the ASRock E350M1, the following warnings are shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/buildOpts.romstage.o
In file included from src/mainboard/asrock/e350m1/buildOpts.c:294:0:
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2071:6: warning: "DDR1333_FREQUENCY" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2071:40: warning: "DDR1866_FREQUENCY" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2089:5: warning: "TIMING_MODE_AUTO" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2089:31: warning: "TIMING_MODE_SPECIFIC" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2113:5: warning: "QUADRANK_UNBUFFERED" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2113:33: warning: "QUADRANK_UNBUFFERED" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2127:5: warning: "POWER_DOWN_BY_CHIP_SELECT" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2127:28: warning: "POWER_DOWN_BY_CHIP_SELECT" is not defined [-Wundef]
[…]
Adding the corresponding defines as done for AMD Persimmon in
commit d7a696d0f2
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Reviewed-on: http://review.coreboot.org/137
addresses the warnings.
Change-Id: Id311b2dacdba5f2e6b4d834e43db0310213a35f9
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2962
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
The ACPI NVS region was setup in place and there was a CBMEM
table that pointed to it. In order to be able to use NVS
earlier the CBMEM region is allocated for NVS itself during
the LPC device init and the ACPI tables point to it in CBMEM.
The current cbmem region is renamed to ACPI_GNVS_PTR to
indicate that it is really a pointer to the GNVS and does
not actually contain the GNVS.
Change-Id: I31ace432411c7f825d86ca75c63dd79cd658e891
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2970
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This enables all of the SerialIO devices and sets the flag
to put them in ACPI mode.
Change-Id: I7436c47d26028e95bbefafc320854c7cc34a4d44
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2972
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/mptable.ramstage.o
src/mainboard/asrock/e350m1/mptable.c:64:12: warning: unused variable 'dev' [-Wunused-variable]
[…]
Removing the variable `dev` addresses the warning.
The same change was done in the following commit for the
AMD Persimmon board.
commit d7a696d0f2
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Reviewed-on: http://review.coreboot.org/137
Change-Id: I83f4630cb6ab1e4c95d04b4e8423850ed1858e45
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2965
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/mptable.ramstage.o
src/mainboard/asrock/e350m1/mptable.c: In function 'smp_write_config_table':
src/mainboard/asrock/e350m1/mptable.c:58:3: warning: implicit declaration of function 'get_bus_conf' [-Wimplicit-function-declaration]
[…]
Including the header file `cpu/amd/amdfam14.h` declaring the
function addresses this warning.
The same change was done in the following commit for the
AMD Persimmon board.
commit d7a696d0f2
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Reviewed-on: http://review.coreboot.org/137
Change-Id: I7912571fa57f6512b10fc9b5845427fcb6eb50c0
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2966
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/mainboard.ramstage.o
src/mainboard/asrock/e350m1/mainboard.c: In function 'mainboard_enable':
src/mainboard/asrock/e350m1/mainboard.c:63:2: warning: implicit declaration of function 'pm_iowrite' [-Wimplicit-function-declaration]
[…]
This warning was introduced by moving the initialization of the
ASF registers using `pm_iowrite` to `mainboard.c` in
commit db6c5bfd8b
Author: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Date: Thu Mar 21 22:21:28 2013 +0100
Asrock E350M1: Use SPD read code from F14 wrapper
Reviewed-on: http://review.coreboot.org/2875
and is fixed by including `southbridge/amd/cimx/cimx_util.h`
declaring `pm_iowrite`.
Note, that the other AMD SB800 based boards seem to use the
header file `southbridge/amd/sb800/sb800.h`, so no warning is shown
for those. But since the CIMx SB800 code is used, the routines
from the CIMx directory are more appropriate to declare these functions.
So delete the commented out include line for this header too.
Change-Id: I179aad5157c5a91294339a3e7b6c4c1715c6f099
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2957
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This enables the TPM device in ACPI tables so the OS is able
to probe for the TPM without needing it be force loaded.
Change-Id: I21e660ac1c12e3e1341cf266cf8f0bf03763df5a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2968
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There is a wildcard rule to include mainboard/fadt.c.
Change-Id: I7f59d6b241c683b62c2c41c5795e45184882635e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/2940
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/irq_tables.ramstage.o
src/mainboard/asrock/e350m1/irq_tables.c: In function 'write_pirq_routing_table':
src/mainboard/asrock/e350m1/irq_tables.c:64:2: warning: implicit declaration of function 'get_bus_conf' [-Wimplicit-function-declaration]
[…]
Including the header file `cpu/amd/amdfam14.h` declaring the
function addresses this warning.
The same change was done in the following commit for the
AMD Persimmon board.
commit d7a696d0f2
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Reviewed-on: http://review.coreboot.org/137
Change-Id: I40b5735feb7116961ca0c4d6940ec55cdf42d3c6
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2956
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/get_bus_conf.ramstage.o
src/mainboard/asrock/e350m1/get_bus_conf.c: In function 'get_bus_conf':
src/mainboard/asrock/e350m1/get_bus_conf.c:82:3: warning: implicit declaration of function 'agesawrapper_amdinitlate' [-Wimplicit-function-declaration]
[…]
Including the header file `agesawrapper.h` declaring the function
`agesawrapper_amdinitlate` fixes this warning.
All AMD Family 14 based boards already include that header file. For
example for the board AMD Persimmon the following patch fixed this
warning.
commit d7a696d0f2
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Reviewed-on: http://review.coreboot.org/137
Change-Id: I695420b7071e07cb7d4667b2479b9a26ea13723d
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2955
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/PlatformGnbPcie.romstage.o
CC mainboard/asrock/e350m1/agesawrapper.romstage.o
CC mainboard/asrock/e350m1/buildOpts.romstage.o
src/mainboard/asrock/e350m1/PlatformGnbPcie.c: In function 'OemCustomizeInitEarly':
src/mainboard/asrock/e350m1/PlatformGnbPcie.c:131:5: warning: 'return' with a value, in function returning void [enabled by default]
[…]
The function signature is (the return type might not be part of this though [1]),
VOID
OemCustomizeInitEarly (
IN OUT AMD_EARLY_PARAMS *InitEarly
)
so do not return anything.
All other AMD Family 14 boards already have the correct code. For example
following commit fixed this for AMD Persimmon.
commit d7a696d0f2
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Reviewed-on: http://review.coreboot.org/137
[1] http://cboard.cprogramming.com/cplusplus-programming/117286-what-exactly-function-signature.html
Change-Id: Ie60246bd9bb8452efd096e6838d8610f6364a6aa
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2954
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
This adds a call to explicitly configure L2 cache (though defaults
should be set correctly).
Change-Id: I120e29c986918c2904a0332e46fcf9f1c5380d85
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2950
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: build bot (Jenkins)
The WTM2 board has a fairly static configuration. As such
it's been tested to properly handle CACHE_ROM given the number
of MTRRs the boards' CPUs supports.
Change-Id: Ic67cd1eebce580003dc6b6655cac2b2a92dd1b5f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2964
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Now that the AMD Inagua builds without any warnigs, remove the
config option `WARNINGS_ARE_ERRORS` set to no by default from
the file `Kconfig` so warnings are treated as errors to prevent
code from being added in the future introducing warnings.
Change-Id: I0b58bd74b06dc54d180b16d6a207354b5fea0d0f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2953
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Building the AMD Inagua board, the following warning is thrown.
CC mainboard/amd/inagua/get_bus_conf.ramstage.o
src/mainboard/amd/inagua/broadcom.c:319:6: warning: no previous prototype for 'broadcom_init' [-Wmissing-prototypes]
This warning was introduced by commit 3926b4c5.
commit 3926b4c520
Author: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Date: Fri Mar 1 19:41:41 2013 +0100
AMD Inagua: add GEC firmware, document Broadcom BCM57xx Selfboot Patch format
Reviewed-on: http://review.coreboot.org/2831
Adding the prototype to `broadcom.c` and removing it from
`mainboard.c` fixes the warning.
Change-Id: I1da0c4e972e129047dd8230d573f1c43fd71eb20
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2952
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Automatically select CACHE_ROM for all Google boards.
Tested by generating a config for the link board. CACHE_ROM
was selected and was unable to unselect it using
'make oldconfig'.
Change-Id: I8e34207e3929a020bb0280657f95ba7a000ad024
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2963
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This reverts commit 9427ca151e
Looks like we were a bit too anxious to see this one get in. The devicetree.cb change seems to have broken things.
coreboot memory table:
0. 0000000050000000-000000005000ffff: RESERVED
1. 00000000bff00000-00000000bfffffff: CONFIGURATION TABLES
2. 0000014004000000-00000140044007ff: RESERVED
Before this patch:
coreboot memory table:
0. 0000000040000000-00000000bfefffff: RAM
1. 00000000bff00000-00000000bfffffff: CONFIGURATION TABLES
Change-Id: I618e4f1976265d56cfd6a61d0c5736c55a0f3cec
Reviewed-on: http://review.coreboot.org/2914
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This does NOT turn on the graphics.
The device tree has been changed enough so that, at the very least, the correct
functions are called at the correct time, with the correct paramaters. We
decided to yank the I2C entries as they did not obvious function and might
not even have been correct.
Not working, seemingly, but we need to add a 4M resource for
memory, and it seems it needs to be fixed at the address shown.
This address was chosen from current hardware.
We realized that the display code should be part of the cpu -- that's how
the hardware works!
Change-Id: Ied65a554f833566be817540702f79a02e7b6cb6e
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2615
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This adds new MMU setup code. Most notably, this version uses
cbmem_add() to determine the translation table base address, which
in turn is necessary to ensure payloads which wipe memory can tell
which regions to wipe out.
TODOs:
- Finish cleaning up references to old cache/MMU stuff
- Add L2 setup (from exynos_cache.c)
- Set up ranges dynamically rather than in ramstage's main().
Change-Id: Iba5295a801e8058a3694e4ec5b94bbe9a69d3ee6
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2877
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The Broadcom BCM5785 GbE MAC integrated in the AMD Hudson-E1 requires a
secret sauce firmware blob to work. As Broadcom wasn't willing to send us
any documentation (or a firmware adapted to our Micrel PHY) I had to figure
out everything by myself in many weeks of hard detective work.
In the end we had to settle for a different solution, the modified firmware
I devised for the Micrel KSZ9021 PHY on our early FrontRunner-AF prototypes
is no longer needed for the production version. However the information
contained here might be very useful for others who'd like to use a
competing PHY instead of Broadcom's 50610, so it should not get lost.
And of course the unmodified, but now in large parts documented Selfboot
Patch is needed to get Ethernet on AMD Inagua. The code introduced here
should make the Hudson's internal MAC usable without having to add the
proprietary firmware blob. - At least in theory.
Unfortunately we've been unable to actually test this patch on Inagua,
therefore the broadcom_init() call in mainboard.c was left commented out.
If you have the hardware and can confirm it works please enable it.
The fun thing is: as Broadcom refused to do any business with us at all,
or send us any documentation, we never had to sign an NDA with them. This
leaves me free to publish everything I have found out. :-)
Change-Id: I94868250591862b376049c76bd21cb7e85f82569
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2831
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
