Heap allocation begins with BIOS_HEAP_MANAGER, no need to clear
the fields individually.
Change-Id: Ia1af84bd09d1edf8f72223752557d44a96dec6e1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5659
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
While fam15 boards do not select HAVE_ACPI_RESUME, backport this
from fam14.
Implementation of this function is common across different families.
Change-Id: I222b418a0a79bbdf5f5cce6c876243ecb4912256
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5655
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
CONFIG_ARCH is a property of the cpu or soc rather than a property of the
board. Hence, move ARCH_* from every single board to respective cpu or soc
Kconfigs. Also update abuild to ignore ARCH_ from mainboards.
Change-Id: I6ec1206de5a20601c32d001a384a47f46e6ce479
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5570
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Following the reasoning of:
dbbc136 mainboard/asrock/e350m1: Avoid including early_serial.c
Change-Id: I5d729b90cf6713de2674fb00c726cd2944a3ab4e
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5597
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Convert the serial init to the generic romstage component and
corresponding boards using this sio.
Change-Id: I36bcf38c4351130be1ed924ecfe606336d0433f3
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5588
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Dumping the ACPI tables in this way has limited use, is not likely to be
used and is poorly implemented. There are much more sophisticated tools
available on Linux for debugging ACPI as such this code is outside the
scope of coreboots 'bring up the hardware only' philosophy.
A more generic implemention could be done with hexdump() in coreboot
proper following on from this cleanup.
Change-Id: Ifd3bfb76338609d18fcf7158d3c9a6d7c06c8847
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5530
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Not very popular nor useful nowadays.
Change-Id: I3dc0f7aaf188950a43f5350d3a95669fbbdcfd94
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4554
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Following boards use cimx/sb700:
amd/dinar
supermicro/h8qgi
supermicro/h8scm
tyan/s8226
Only amd/dinar had APIC_ID_OFFSET defined, thus all had 0x0.
There was a nonsense preprocessor directive (MAX_CPUS * MAX_PHYSICAL_CPUS >= 1).
Except for tyan, (MAX_CPUS * MAX_PHYSICAL_CPUS) % 256 == 0.
Together with documented 4-bit restriction for APIC ID field, this APIC ID
programming matches with MP tables and ACPI tables.
I believe this would also fix cases of cimx/sb700 with MAX_CPUS<16, which
we do not have in the tree.
Change-Id: If8d65e95788ba02fc8d331a7af03a4d0d8cf5c69
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5539
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Not all boards which use the AMD cimx/sb800 southbridge have IDE.
However, the southbridge's asl included an 'ide.asl' file which had to
be present in $(mainboard_dir)/acpi.
Address this issue by including ide.asl only in boards which have IDE,
and remove it from all other cimx/sb800 boards.
Change-Id: I57fcb4db9f85234b05ae1705ef81a576c478cee6
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5460
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
board_info.txt is a file to be used by board-status to add
some useful info to the generated table like flash chip type.
This series is autogenerated from wiki page Supported_Motherboards.
Change-Id: Ie2bda900713ef4883134477163320936c84c34f5
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4701
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This change allows Kconfig options ROM_SIZE and CBFS_SIZE to be
set with values that are not power of 2. The region programmed
as WB cacheable will include all of ROM_SIZE.
Side-effects to consider:
Memory region below flash may be tagged WRPROT cacheable. As an
example, with ROM_SIZE of 12 MB, CACHE_ROM_SIZE would be 16 MB.
Since this can overlap CAR, we add an explicit test and fail
on compile should this happen. To work around this problem, one
needs to use CACHE_ROM_SIZE_OVERRIDE in the mainboard Kconfig and
define a smaller region for WB cache.
With this change flash regions outside CBFS are also tagged WRPROT
cacheable. This covers IFD and ME and sections ChromeOS may use.
Change-Id: I5e577900ff7e91606bef6d80033caaed721ce4bf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4625
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Place this in header so it works also when raminit_f.c and
raminit_f_dqs.c are not #included in romstage.c build.
The workaround remains to be disabled for all boards.
Change-Id: Iff0271ceb21ee1e28a1a31d6bbdb97e29d76461e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4568
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Do it just to remove MEM_TRAIN_SEQ test under mainboard/ to see all
K8 rev F boards do the same things here.
Change-Id: If75035a4ef8882c2618d434d83ba59c408593d86
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4567
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
K8 Rev F raminit code cannot be built without RAMINIT_SYSINFO,
so have the option enabled together with K8_REV_F_SUPPORT.
Also move the option under AMD K8.
Change-Id: I91fa0b4ae7e3e54fbcb4a4f91eb043956cd0fb60
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4582
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
AMD fam10 raminit cannot be built without RAMINIT_SYSINFO, this
is not a true option but copy-paste remainder from AMD K8.
Change-Id: Id8edc112f3bacebd1732304ac9ee6e77cc6263b7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4581
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
K8_REV_F_SUPPORT is already set by all affected sockets, (AM2, F, S1G1).
Change-Id: If42a4178263d90a4e195fae0c78943ac9eda1ad6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4557
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This config was for AMD K8 only.
Change-Id: I76276405b676d1dd4d5dbf8c5b94194a670ccb25
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4555
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
No ROMCC involved, no need to include .c files in romstage.c.
Change-Id: I8a2aaf84276f2931d0a0557ba29e359fa06e2fba
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4501
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: I67192c8ae99e396ea4b17e03c658f31dbb5c1800
Signed-off-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-on: http://review.coreboot.org/3960
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
... and drop the wrapper on ARMv7
Change-Id: If3ffe953cee9e61d4dcbb38f4e5e2ca74b628ccc
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3639
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Thanks to Bruce's great work, we can finally drop this workaround.
Change-Id: Ie92d1e53ef867fa34aa2489ccfb682d73195b213
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3569
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
There are no files to build left under AMD nortbridge/x/root_complex
directories. For some cases, even the Kconfig file was no longer sourced.
Remove all such references and empty files.
For devicetree.cb treat component paths with "/root_complex" in them valid
even when the directory does not exists. This is because AMD boards us this
dummy chip component as the root node in their devicetree.cb.
The generated devicetree file static.c remains unchanged.
Change-Id: I9278ebb50a83cebbf149b06afb5669899a8e4d0b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3434
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
All 3 boards with AGESA_HUDSON had HAVE_HARD_RESET with the reset.c
file already placed under southbridge/.
All 15 boards with CIMX_SBx00 had HAVE_HARD_RESET with functionally
identical reset.c file under mainboard/. Move those files under
respective southbridge/.
Change-Id: Icfda51527ee62e578067a7fc9dcf60bc9860b269
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3486
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The chip component is unconditionally selected for the mainboard
so these uses are superfluous.
Change-Id: I84b053ab47f7b1f68e88d968cf305e24bc95f4da
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3485
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@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>
Here's the great news: From now on you don't have to worry about
hitting the right io.h include anymore. Just forget about romcc_io.h
and use io.h instead. This cleanup has a number of advantages, like
you don't have to guard device/ includes for SMM and pre RAM
anymore. This allows to get rid of a number of ifdefs and will
generally make the code more readable and understandable.
Potentially in the future some of the code in the io.h __PRE_RAM__
path should move to device.h or other device/ includes instead,
but that's another incremental change.
Change-Id: I356f06110e2e355e9a5b4b08c132591f36fec7d9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Changes:
- Get rid of the s8226 mainboard specific code and use the
platform generic function wrapper that was added in change
http://review.coreboot.org/#/c/2777/
AMD Fam15: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
Notes:
- The DIMM reads only happen in romstage, so the function is not
available in ramstage. Point the read-SPD callback to a generic
function in ramstage.
- select_socket() and restore_socket() started by duplicating
sp5100_set_gpio() and sp5100_restore_gpio(), which were in
dimmSpd.c. In addition to renaming the functions to more
specifically state their purpose, some cleanup and magic number
reduction was done.
Change-Id: I1eaf64986ef4fa3f89aed2b69d3f9c8c913f726f
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/2827
Tested-by: build bot (Jenkins)
Reviewed-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.
The following command was used to convert all files.
$ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/'
[1] http://www.gnu.org/licenses/gpl-2.0.txt
Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
The DSDT header contains the fields OEMID and OEM Table ID. See
for example ACPI specification 4.0a [1]
5.2.11.1 Differentiated System Description Table (DSDT)
on page 135. There Table 5-16 contains the descriptions.
Field Byte Length Byte Offset Description
===================================================
OEMID 6 10 OEM ID
OEM Table ID 8 16 The manufacture model ID.
Currently in coreboot there is no common method what to put in
these fields.
Mostly Intel based boards populate it with "CORE " ore "COREv4"
and AMD based boards populate it with the board vendor and
model number, abbreviated appropriately to fit into these fields.
On most boards the proprietary vendor BIOS seems to leave these
fields – displayed with `sudo dmidecode` under System Information –
blank
To Be Filled By O.E.M.
and fill out the Base Board Information with the board vendor and
model name.
In [2] Jens Rottmann argues that the this is really just the table
ID used for naming it and that »99% of the DSDT code is not board
specific«.
Both approaches seem to have their advantages, but using the
second one, developers often seem to forget to update them (for
example AMD Thather).
The current situation is at least not optimal. and therefore at
least unify the string in the OEM Table ID. If unifying the
OEM ID is also a good idea this should be done too.
If later on it should be decided that the board vendor and model
should be used again, this should be somehow derived from
Kconfig.
The following command was used for the change [3].
$ git grep -l '\/\* TABLE ID \*\/' | xargs sed -i '/TABLE ID/s/"\([^"]*\)"/"COREBOOT"/'
This patch is split out from [2].
[1] http://www.acpi.info/spec40a.htm
[2] http://review.coreboot.org/#/c/2464/
[3] http://stackoverflow.com/questions/5207838/sed-regex-matching-text-between-to-double-quotes-when-a-certain-text-appears-i
Change-Id: Iec98c615ce37f928abc1b500eff5aa865d772cb2
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2472
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
To reduce the differences between these file name the enabling
device function in the directory `src/mainboard` uniformly
`mainboard_enable` [1].
Thanks to the awesome help of gnomon and BlastHardcheese in the
IRC channel #sed on <irc.freenode.net>. gnomon came up with the
following command to do the actual work.
$ cd src/mainboard
$ for f in */*/mainboard.c ; \
> do src="$(awk '/\.enable_dev = /{v=$NF; sub(/,$/,"",v); print v}' "$f")" ; \
> [[ -z $src ]] && continue ; \
> printf '%s\n' "g/${src}/s/${src}\([,(]\)/mainboard_enable\1/p" w | ed -s "$f" ; \
> done
`src/mainboard/digitallogic/msm586seg/mainboard.c` and
`src/mainboard/technologic/ts5300/mainboard.c` had to be adapted
manually as no comma was used separating the struct members.
And with the following statement, gnomon is even more likable!
My pleasure entirely. Good luck with coreboot; I'm a big fan of the project.
[1] http://www.coreboot.org/pipermail/coreboot/2013-February/074548.html
Change-Id: Ife9cd0c2d9cc1ed14afc6d40063450553f06a6c6
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2493
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
At the request of Paul Menzel, I reran an
old classic of a coccinelle script:
@@
expression E;
@@
-(E + 7) & -8
+ALIGN(E, 8)
@@
expression E;
@@
-(E + 15) & -16
+ALIGN(E, 16)
Change-Id: I01da31b241585e361380f75aacf3deddb13d11c3
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2487
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The following command was used to correct the typo.
$ git grep -l @breif | xargs sed -i 's/@breif/@brief/'
Change-Id: If0b579279de3c41571b9cda643836f5748a752a2
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2473
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fix warning:
mptable.c:52, GNU Compiler 4 (gcc), Priority: Normal
passing argument 3 of 'mptable_write_buses' from incompatible pointer type [enabled by default]
mptable_write_buses is expecting a pointer to an int, so I changed the
U8 isa_bus to an int to match. A U8 doesn't make sense if the value could
be greater than 255 - certainly unlikely, but possible since the value
of isa_bus gets set to the maximum PCI bus number + 1.
Change-Id: I7ea416f48285922d6cf341382109993fd3f6405c
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2450
Tested-by: build bot (Jenkins)
Reviewed-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
Fix Warning:
sb700_cfg.c:129, GNU Compiler 4 (gcc), Priority: Normal
large integer implicitly truncated to unsigned type [-Woverflow]
The issue here was that an 8 bit value was being placed into a 2-bit
bitfield.
$ more src/vendorcode/amd/cimx/sb700/SBTYPE.h
[…]
UINT32 AzaliaSdin0 :2; //6
UINT32 AzaliaSdin1 :2; //8
UINT32 AzaliaSdin2 :2; //10
UINT32 AzaliaSdin3 :2; //12
$ more src/mainboard/tyan/s8226/sb700_cfg.h
[…]
* SDIN0 is define at BIT0 & BIT1
* 00 - GPIO PIN
* 01 - Reserved
* 10 - As a Azalia SDIN pin
* SDIN1 is define at BIT2 & BIT3
* SDIN2 is define at BIT4 & BIT5
* SDIN3 is define at BIT6 & BIT7
*/
#ifndef AZALIA_SDIN_PIN
#define AZALIA_SDIN_PIN 0x2A
#endif
[…]
$ more src/mainboard/tyan/s8226/sb700_cfg.c
[…]
sb_config->AzaliaSdin0 = AZALIA_SDIN_PIN;
[…]
The 8 bit value 0x2A (binary 00 10 10 10), was being used incorrectly
– I believe the original intent of this value was to enable the SDIN
pins 0, 1, & 2. Because it was getting truncated as it was put into
AzaliaSdin0, this wasn't happening and only SDIN0 was being enabled.
I am leaving only SDIN0 enabled at this point to as not change the
actual behavior on the platform.
Change-Id: Icaeb956926309dbfb5af25a36ccb842877e17a34
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2452
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fix 84 warnings all like this one:
agesawrapper.c:289, GNU Compiler 4 (gcc), Priority: Normal
format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'UINT32' [-Wformat]
Fixed by getting rid of the l length specifier and casting to unsigned int.
Change-Id: Ic143c1034f760fa5efb2220aa33861e399ddd708
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2451
Tested-by: build bot (Jenkins)
Reviewed-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Kyösti Mälkki