Hi,
I'm trying to generate a coreboot.rom for this AMD development board and update a board status report in order to avoid deprecation this board.
I'm using the commit f77f2c79c2bb898c123ffe89a0bd1acb5362afc5 (just one before a0a50775) and I get some compilation errors.
The first is from iasl compiling the dsdt.asl file:
Intel ACPI Component Architecture ASL+ Optimizing Compiler/Disassembler version 20191018 Copyright (c) 2000 - 2019 Intel Corporation
coreboot toolchain v547de69 2019-10-18 Error 6154 - Warnings detected during compilation (reporting warnings as errors)
dsdt.asl 403: Device(PCI0) { Warning 3073 - ^ Multiple types (Device object requires either a _HID or _ADR, but not both)
dsdt.asl 1061: Method (_CRS, 0x0, NotSerialized) { Remark 2120 - ^ Control Method should be made Serialized (due to creation of named objects within)
ASL Input: dsdt.asl - 22455 bytes 598 keywords 1154 source lines
Compilation failed. 1 Errors, 1 Warnings, 1 Remarks No AML files were generated due to compiler error(s)
The same file with the iasl tool generated by the 4.10 release toolchain works ok.
The second one is from src/commonlib/include/commonlib/helpers.h. I get the next error:
HOSTCC cbfstool/cbfstool.o In file included from <command-line>:0:0: /mnt/develop/bettong/coreboot/develop/coreboot/util/cbfstool/cbfstool.c: In function 'cbfs_add_component': /mnt/develop/bettong/coreboot/develop/coreboot/src/commonlib/include/commonlib/compiler.h:57:2: error: first argument to '__builtin_choose_expr' not a constant __builtin_choose_expr(__builtin_constant_p(expr), fallback_expr, expr)) ^ /mnt/develop/bettong/coreboot/develop/coreboot/src/commonlib/include/commonlib/helpers.h:39:2: note: in expansion of macro '__TYPEOF_UNLESS_CONST' __TYPEOF_UNLESS_CONST(a, b) var_a = (a); \ ^ /mnt/develop/bettong/coreboot/develop/coreboot/src/commonlib/include/commonlib/helpers.h:49:26: note: in expansion of macro '__CMP_SAFE' __CMP_UNSAFE(a, b, op), __CMP_SAFE(a, b, op, __TMPNAME, __TMPNAME)) ^ /mnt/develop/bettong/coreboot/develop/coreboot/src/commonlib/include/commonlib/helpers.h:56:19: note: in expansion of macro '__CMP' #define MAX(a, b) __CMP(a, b, >) ^ /mnt/develop/bettong/coreboot/develop/coreboot/util/cbfstool/cbfstool.c:560:19: note: in expansion of macro 'MAX' uint32_t size = MAX(hs, param.padding); ^ /mnt/develop/bettong/coreboot/develop/coreboot/src/commonlib/include/commonlib/compiler.h:57:2: error: first argument to '__builtin_choose_expr' not a constant __builtin_choose_expr(__builtin_constant_p(expr), fallback_expr, expr)) ^ /mnt/develop/bettong/coreboot/develop/coreboot/src/commonlib/include/commonlib/helpers.h:40:2: note: in expansion of macro '__TYPEOF_UNLESS_CONST' __TYPEOF_UNLESS_CONST(b, a) var_b = (b); \ ^ /mnt/develop/bettong/coreboot/develop/coreboot/src/commonlib/include/commonlib/helpers.h:49:26: note: in expansion of macro '__CMP_SAFE' __CMP_UNSAFE(a, b, op), __CMP_SAFE(a, b, op, __TMPNAME, __TMPNAME)) ^ /mnt/develop/bettong/coreboot/develop/coreboot/src/commonlib/include/commonlib/helpers.h:56:19: note: in expansion of macro '__CMP' #define MAX(a, b) __CMP(a, b, >) ^ /mnt/develop/bettong/coreboot/develop/coreboot/util/cbfstool/cbfstool.c:560:19: note: in expansion of macro 'MAX' uint32_t size = MAX(hs, param.padding); ^ In file included from /mnt/develop/bettong/coreboot/develop/coreboot/util/cbfstool/common.h:25:0, from /mnt/develop/bettong/coreboot/develop/coreboot/util/cbfstool/cbfstool.c:28: /mnt/develop/bettong/coreboot/develop/coreboot/src/commonlib/include/commonlib/helpers.h:47:25: error: first argument to '__builtin_choose_expr' not a constant #define __CMP(a, b, op) __builtin_choose_expr( \ ^ /mnt/develop/bettong/coreboot/develop/coreboot/src/commonlib/include/commonlib/helpers.h:56:19: note: in expansion of macro '__CMP' #define MAX(a, b) __CMP(a, b, >) ^ /mnt/develop/bettong/coreboot/develop/coreboot/util/cbfstool/cbfstool.c:560:19: note: in expansion of macro 'MAX' uint32_t size = MAX(hs, param.padding); ^ In file included from <command-line>:0:0: /mnt/develop/bettong/coreboot/develop/coreboot/util/cbfstool/cbfstool.c: In function 'cbfs_create': /mnt/develop/bettong/coreboot/develop/coreboot/src/commonlib/include/commonlib/compiler.h:57:2: error: first argument to '__builtin_choose_expr' not a constant __builtin_choose_expr(__builtin_constant_p(expr), fallback_expr, expr)) ^ /mnt/develop/bettong/coreboot/develop/coreboot/src/commonlib/include/commonlib/helpers.h:39:2: note: in expansion of macro '__TYPEOF_UNLESS_CONST' __TYPEOF_UNLESS_CONST(a, b) var_a = (a); \ ^ /mnt/develop/bettong/coreboot/develop/coreboot/src/commonlib/include/commonlib/helpers.h:49:26: note: in expansion of macro '__CMP_SAFE' __CMP_UNSAFE(a, b, op), __CMP_SAFE(a, b, op, __TMPNAME, __TMPNAME)) ^ /mnt/develop/bettong/coreboot/develop/coreboot/src/commonlib/include/commonlib/helpers.h:56:19: note: in expansion of macro '__CMP' #define MAX(a, b) __CMP(a, b, >) ^ /mnt/develop/bettong/coreboot/develop/coreboot/util/cbfstool/cbfstool.c:971:6: note: in expansion of macro 'MAX' MAX(bootblock.size, sizeof(int32_t)); ^ In file included from /mnt/develop/bettong/coreboot/develop/coreboot/util/cbfstool/common.h:25:0, from /mnt/develop/bettong/coreboot/develop/coreboot/util/cbfstool/cbfstool.c:28: /mnt/develop/bettong/coreboot/develop/coreboot/src/commonlib/include/commonlib/helpers.h:47:25: error: first argument to '__builtin_choose_expr' not a constant #define __CMP(a, b, op) __builtin_choose_expr( \ ^ /mnt/develop/bettong/coreboot/develop/coreboot/src/commonlib/include/commonlib/helpers.h:56:19: note: in expansion of macro '__CMP' #define MAX(a, b) __CMP(a, b, >) ^ /mnt/develop/bettong/coreboot/develop/coreboot/util/cbfstool/cbfstool.c:971:6: note: in expansion of macro 'MAX' MAX(bootblock.size, sizeof(int32_t)); ^ make: *** [build/util/cbfstool/cbfstool.o] Error 1
I can generate the coreboot.rom using the old iasl tool and patching helpers.h with:
@@ -50,10 +50,10 @@ #endif
#ifndef MIN -#define MIN(a, b) __CMP(a, b, <) +#define MIN(a, b) ((a) < (b) ? (a) : (b)) #endif #ifndef MAX -#define MAX(a, b) __CMP(a, b, >) +#define MAX(a, b) ((a) > (b) ? (a) : (b)) #endif
#ifndef ABS
but the board_status.sh script then complains $ ./util/board_status/board_status.sh Extracting config.txt from build/coreboot.rom Extracting payload_config from build/coreboot.rom The repository is in a dirty state. Please see the output of 'git status' below. HEAD detached at f77f2c7 Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory)
modified: src/commonlib/include/commonlib/helpers.h
no changes added to commit (use "git add" and/or "git commit -a")
How to proceed? Thanks! Jorge
Hi all,
I've been able to make it work the Bettong board again with the commit before a0a50775 as Kyösti Mälkki pointed. I've had to remove the next commit to make it work again.
bfb5c807e720761f4457d5106bb919f2aacb5535 binaryPI: Drop PSP Secure OS from build
and some minor changes. I really want to upload the board status but I'm still trying to make the git push to work, I stil can't login. I've attached the tar.gz related to the path:
util/board_status/board-status/amd/bettong/4.11-128-gb64f85d/2019-12-05T09_00_28Z
if could be useful...
Regards, Jorge
Complete minor changes patch:
diff --git a/src/commonlib/include/commonlib/helpers.h b/src/commonlib/include/commonlib/helpers.h index ca3b3c5..d980827 100644 --- a/src/commonlib/include/commonlib/helpers.h +++ b/src/commonlib/include/commonlib/helpers.h @@ -50,10 +50,10 @@ #endif
#ifndef MIN -#define MIN(a, b) __CMP(a, b, <) +#define MIN(a, b) ((a) < (b) ? (a) : (b)) #endif #ifndef MAX -#define MAX(a, b) __CMP(a, b, >) +#define MAX(a, b) ((a) > (b) ? (a) : (b)) #endif
#ifndef ABS diff --git a/src/northbridge/amd/pi/00660F01/acpi/northbridge.asl b/src/northbridge/amd/pi/00660F01/acpi/northbridge.asl index d54f985..ac44f46 100644 --- a/src/northbridge/amd/pi/00660F01/acpi/northbridge.asl +++ b/src/northbridge/amd/pi/00660F01/acpi/northbridge.asl @@ -18,7 +18,7 @@ External (TOM1) External (TOM2) Name(_HID, EISAID("PNP0A08")) /* PCI Express Root Bridge */ Name(_CID, EISAID("PNP0A03")) /* PCI Root Bridge */ -Name(_ADR, 0x00180000) /* Dev# = BSP Dev#, Func# = 0 */ +//Name(_ADR, 0x00180000) /* Dev# = BSP Dev#, Func# = 0 */
/* Describe the Northbridge devices */
diff --git a/src/southbridge/amd/pi/hudson/Makefile.inc b/src/southbridge/amd/pi/hudson/Makefile.inc index 0eccadb..33f59c7 100644 --- a/src/southbridge/amd/pi/hudson/Makefile.inc +++ b/src/southbridge/amd/pi/hudson/Makefile.inc @@ -85,10 +85,10 @@ FIRMWARE_LOCATE=$(dir $(call strip_quotes, $(CONFIG_AMD_PUBKEY_FILE))) FIRMWARE_TYPE=
PSPBTLDR_FILE=$(top)/$(FIRMWARE_LOCATE)/PspBootLoader.Bypass.sbin -#PSPRCVR_FILE=$(top)/$(FIRMWARE_LOCATE)/PspRecovery.sbin -#PSPSCUREOS_FILE=$(top)/$(FIRMWARE_LOCATE)/PspSecureOs.sbin -#PSPTRUSTLETS_FILE=$(top)/$(FIRMWARE_LOCATE)/trustlets.bin -#TRUSTLETKEY_FILE=$(top)/$(FIRMWARE_LOCATE)/Trustlet.tkn.cert +PSPRCVR_FILE=$(top)/$(FIRMWARE_LOCATE)/PspRecovery.sbin +PSPSCUREOS_FILE=$(top)/$(FIRMWARE_LOCATE)/PspSecureOs.sbin +PSPTRUSTLETS_FILE=$(top)/$(FIRMWARE_LOCATE)/trustlets.bin +TRUSTLETKEY_FILE=$(top)/$(FIRMWARE_LOCATE)/Trustlet.tkn.cert endif
ifeq ($(CONFIG_CPU_AMD_PI_00660F01), y) @@ -103,12 +103,12 @@ TRUSTLETKEY_FILE=$(top)/$(FIRMWARE_LOCATE)/TrustletKey_prod_CZ.sbin SMUFIRMWARE2_FILE=$(top)/$(FIRMWARE_LOCATE)/SmuFirmware2_prod_CZ.sbin endif
-#PUBSIGNEDKEY_FILE=$(top)/$(FIRMWARE_LOCATE)/RtmPubSigned$(FIRMWARE_TYPE).key -#PSPNVRAM_FILE=$(top)/$(FIRMWARE_LOCATE)/PspNvram$(FIRMWARE_TYPE).bin +PUBSIGNEDKEY_FILE=$(top)/$(FIRMWARE_LOCATE)/RtmPubSigned$(FIRMWARE_TYPE).key +PSPNVRAM_FILE=$(top)/$(FIRMWARE_LOCATE)/PspNvram$(FIRMWARE_TYPE).bin SMUFWM_FILE=$(top)/$(FIRMWARE_LOCATE)/SmuFirmware$(FIRMWARE_TYPE).sbin SMUFWM_FN_FILE=$(top)/$(FIRMWARE_LOCATE)/SmuFirmware$(FIRMWARE_TYPE)_FN.sbin SMUSCS_FILE=$(top)/$(FIRMWARE_LOCATE)/SmuScs$(FIRMWARE_TYPE).bin -#PSPSECUREDEBUG_FILE=$(top)/$(FIRMWARE_LOCATE)/PspSecureDebug$(FIRMWARE_TYPE).Key +PSPSECUREDEBUG_FILE=$(top)/$(FIRMWARE_LOCATE)/PspSecureDebug$(FIRMWARE_TYPE).Key
endif
On 05.12.2019 10:13, Jorge Fernandez Monteagudo wrote:
Hi all,
I've been able to make it work the Bettong board again with the commit before a0a50775 as Kyösti Mälkki pointed. I've had to remove the next commit to make it work again.
bfb5c807e720761f4457d5106bb919f2aacb5535 binaryPI: Drop PSP Secure OS from build
and some minor changes. I really want to upload the board status but I'm still trying to make the git push to work, I stil can't login. I've attached the tar.gz related to the path:
util/board_status/board-status/amd/bettong/4.11-128-gb64f85d/2019-12-05T09_00_28Z
if could be useful...
You can try setting up SSH key on the gerrit account and change the git remote to SSH instead of HTTPS.
Regards,
You can try setting up SSH key on the gerrit account and change the git remote to SSH instead of HTTPS.
Sorry, we only have access to http/https ports... maybe I have a certificate's problem...
Am Do., 5. Dez. 2019 um 12:16 Uhr schrieb Jorge Fernandez Monteagudo < jorgefm@cirsa.com>:
You can try setting up SSH key on the gerrit account and change the git
remote to SSH instead of HTTPS. Sorry, we only have access to http/https ports... maybe I have a certificate's problem...
Have you set up an account on review.coreboot.org yet?
While we provide a read-only mirror on github for the code repos, board status uploads have to happen on our infrastructure.
Patrick
Hi Patrick
Have you set up an account on review.coreboot.org yet? While we provide a read-only mirror on github for the code repos, board status uploads have to happen on our infrastructure.
I think yes... I go to https://review.coreboot.org/login/%2Fq%2Fstatus%3Aopen, then I select
GitHub OAuth2 (gerrit-oauth-provider plugin)
and automatically I go to
https://review.coreboot.org/q/status:open
and in setting I can see my GitHub user (jorgefm1900), the ID, etc... Then under 'HTTP Credentials' I've press the 'GENERATE NEW PASSWORD' button and the string I get is what I use to login with the username. I've tried creating the ~/.netrc file too with this info too but with no luck
Thanks! Jorge
Hi Jorge,
Am Do., 5. Dez. 2019 um 12:53 Uhr schrieb Jorge Fernandez Monteagudo < jorgefm@cirsa.com>:
and in setting I can see my GitHub user (jorgefm1900), the ID, etc... Then under 'HTTP Credentials' I've press
the 'GENERATE NEW PASSWORD' button and the string I get is what I use to
login with the username.
yes, that looks reasonable.
I've tried creating the ~/.netrc file too with this info too but with no
luck
Some installs (depends on libcurl, I think) require .netrc to be chmod 0600 to be considered trusted.
To see if your .netrc config works in general, you could try $ curl -n https://review.coreboot.org/a/accounts/self/avatar.change.url
which should return something like:
)]}' "https://doc.coreboot.org/community/services.html#gerrit-user-avatar"
If you get "Unauthorized", there's some issue with your configuration.
$ curl -vvvn https://review.coreboot.org/a/accounts/self/avatar.change.url will give you more details (but beware when posting that output, it contains the password with _very_ light scrambling: remove the base64 stuff in the "authorization" line before showing anybody).
(And sorry: I've been meaning to make this a whole lot more user friendly for a long time, but other issues keep popping up)
Since this is likely a configuration issue, I moved the list to bcc to keep the noise down. If there's some resolution of this that warrants wider publication, we can still do so later.
Regards, Patrick
On Thu, Dec 5, 2019 at 11:14 AM Jorge Fernandez Monteagudo jorgefm@cirsa.com wrote:
Hi all,
I've been able to make it work the Bettong board again with the commit before a0a50775 as Kyösti Mälkki pointed. I've had to remove the next commit to make it work again.
bfb5c807e720761f4457d5106bb919f2aacb5535 binaryPI: Drop PSP Secure OS from build
and some minor changes. I really want to upload the board status but I'm still trying to make the git push to work, I stil can't login. I've attached the tar.gz related to the path:
The commit hash you push to board-status with has to be one from upstream, local changes are not really useful or acceptable. The entire purpose is to have a known-good reference where board has somewhat booted. You can go to parent of the commit above.
Regarding the conflicting commit, it was there to be reviewed from Jan 24th and finally approved Sep 11th, having seen testing only on pcengines/apu2 which is a different SoC. The other error is likely a regression after two weeks of not being build-tested. Sounds like two commits you need tol land first.
Kyösti
Hi Kyösti
The commit hash you push to board-status with has to be one from upstream, local changes are not really useful or acceptable. The entire purpose is to have a known-good reference where board has somewhat booted. You can go to parent of the commit above.
Yes, I have to do a commit for the local changes to make the board_status script happy.
Regarding the conflicting commit, it was there to be reviewed from Jan 24th and finally approved Sep 11th, having seen testing only on pcengines/apu2 which is a different SoC. The other error is likely a regression after two weeks of not being build-tested. Sounds like two commits you need tol land first.
So, before I can send the board status, should I wait for someone to upload the changes to the repository?
Regards, Jorge Kyösti
On Thu, Dec 5, 2019 at 3:45 PM Jorge Fernandez Monteagudo jorgefm@cirsa.com wrote:
Regarding the conflicting commit, it was there to be reviewed from Jan 24th and finally approved Sep 11th, having seen testing only on pcengines/apu2 which is a different SoC. The other error is likely a regression after two weeks of not being build-tested. Sounds like two commits you need tol land first.
So, before I can send the board status, should I wait for someone to upload the changes to the repository?
You can wait. Keep in mind board removals for binaryPI are (currently) scheduled for 14th December.
It would be wiser to learn to contribute and upload the required fixes to gerrit yourself. Clearly, you have already managed to bisect a boot regression issue, so your previous statement of "I can only help with uploading board-status at release times" is just ... lame.
Kyösti
You can wait. Keep in mind board removals for binaryPI are (currently) scheduled for 14th December.
It would be wiser to learn to contribute and upload the required fixes to gerrit yourself. Clearly, you have already managed to bisect a boot regression issue, so your previous statement of "I can only help with uploading board-status at release times" is just ... lame.
I'm just trying to solve some problems with certs which keep me from post because I can't login...
One noob question. Can I push a change from a commit (f77f2c79c2bb898c123ffe89a0bd1acb5362afc5) not the master? From this commit I can make it boot but from the last there are a lot of changes to made...
Am Do., 5. Dez. 2019 um 15:22 Uhr schrieb Jorge Fernandez Monteagudo < jorgefm@cirsa.com>:
One noob question. Can I push a change from a commit (f77f2c79c2bb898c123ffe89a0bd1acb5362afc5) not the master? From this commit I can make it boot but from the last there are a lot of changes to made...
You can, yes. If it can't be merged, that's only for review, but it would be a start.
Patrick
So, before I can send the board status, should I wait for someone to upload the changes to the repository?
You can wait. Keep in mind board removals for binaryPI are (currently) scheduled for 14th December.
It would be wiser to learn to contribute and upload the required fixes to gerrit yourself. Clearly, you have already managed to bisect a boot regression issue, so your previous statement of "I can only help with uploading board-status at release times" is just ... lame.
Hi Kyösti,
I've been able to push a Bettong board status (commit 31848f291a5f9b8ed0cf5e7c2f6651d1b56a1086) yesterday. The patches I've sent to Gerrit still are not merged but I think we are on the right track. What's more is needed to avoid Bettong deprecation?
Regards, Jorge
I've been able to push a Bettong board status (commit 31848f291a5f9b8ed0cf5e7c2f6651d1b56a1086)
Sorry, commit edab74e8f3bddbab50fe6160da324fecf0fed329
commit edab74e8f3bddbab50fe6160da324fecf0fed329 Author: Jorge Fernandez jorgefm@cirsa.com Date: Mon Dec 9 18:04:16 2019 +0100
amd/bettong/4.11-135-gdb945ff860/2019-12-09T16_38_20Z
Dear Jorge,
On 2019-12-10 10:29, Jorge Fernandez Monteagudo wrote:
I've been able to push a Bettong board status (commit 31848f291a5f9b8ed0cf5e7c2f6651d1b56a1086)
Sorry, commit edab74e8f3bddbab50fe6160da324fecf0fed329
commit edab74e8f3bddbab50fe6160da324fecf0fed329 Author: Jorge Fernandez jorgefm@cirsa.com Date: Mon Dec 9 18:04:16 2019 +0100
amd/bettong/4.11-135-gdb945ff860/2019-12-09T16_38_20Z
Thank you for the upload. Unfortunately, the used coreboot commit db945ff860 is not in the master branch.
``` coreboot> git show db945ff860 fatal: ambiguous argument 'db945ff860': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' ```
So, nobody will be able to reproduce your result.
Kind regards,
Paul
PS: The board status script should be extended to check, if the used commit is in the master branch.
On Tue, Dec 10, 2019 at 11:19 AM Jorge Fernandez Monteagudo jorgefm@cirsa.com wrote:
So, before I can send the board status, should I wait for someone to upload the changes to the repository?
You can wait. Keep in mind board removals for binaryPI are (currently) scheduled for 14th December.
It would be wiser to learn to contribute and upload the required fixes to gerrit yourself. Clearly, you have already managed to bisect a boot regression issue, so your previous statement of "I can only help with uploading board-status at release times" is just ... lame.
Hi Kyösti,
I've been able to push a Bettong board status (commit 31848f291a5f9b8ed0cf5e7c2f6651d1b56a1086) yesterday. The patches I've sent to Gerrit still are not merged but I think we are on the right track. What's more is needed to avoid Bettong deprecation?
Regards, Jorge
Thanks
The board-status you submitted relies on local changes. Can you send output of 'git log --oneline db945ff860' so we have better record of what you had done to make it boot again?
You need to replicate [1] for NORTHBRIDGE_AMD_PI_00660F01 and [2] for mb/amd/bettong. AGESA blobs were sometimes modified in unpredictable ways, so it probably will not work out-of-the-box.
[1] https://review.coreboot.org/c/coreboot/+/32421 [2] https://review.coreboot.org/c/coreboot/+/32363
Kyösti
The board-status you submitted relies on local changes. Can you send output of 'git log --oneline db945ff860' so we have better record of what you had done to make it boot again?
Yes, sure.
db945ff860 amd/bettong: Enable SATA controller 492898593f southbridge/amd/pi/hudson : Revert partially commit bfb5c807e720761f4457d5106bb919f2aacb5535 2a6f9b229d New PCI ID for FCH SATA Controller (AHCI Mode) for AMD driver. 3a39f67087 New PCI ID for Family 15h (Models 60h-6fh) I/O Memory Management Unit 5193b19f4d domain_acpi_name function missing in 00660F01 northbridge. 73303655d8 New PCI ID for FCH SATA Controller (AHCI Mode) bcdba6ec30 Revert commit bfb5c807e720761f4457d5106bb919f2aacb5535 binaryPI: Drop PSP Secure OS from build ac6c12dcd1 {northbridge,soc,southbridge}: Don't use both of _ADR and _HID f77f2c79c2 pcengines/apu2: Switch away from BINARYPI_LEGACY_WRAPPER
from here is what you can get from the master repo.
You need to replicate [1] for NORTHBRIDGE_AMD_PI_00660F01 and [2] for mb/amd/bettong. AGESA blobs were sometimes modified in unpredictable ways, so it probably will not work out-of-the-box.
These patches could be applied onto my current branch? Or I have to use the master branch?
Regards, Jorge
You need to replicate [1] for NORTHBRIDGE_AMD_PI_00660F01 and [2] for mb/amd/bettong. AGESA blobs were sometimes modified in unpredictable ways, so it probably will not work out-of-the-box.
Attached are the changes I've used on top off my current develop branch in order to replicate the APU2 changes, with no luck.
These are the only messages I get from console:
coreboot-4.11-133-g2cc029e-dirty Tue Dec 10 18:28:13 UTC 2019 romstage starting (log level: 8)...
coreboot-4.11-133-g2cc029e-dirty Tue Dec 10 18:28:13 UTC 2019 romstage starting (log level: 8)... APIC 00: CPU Family_Model = 00660f01
APIC 00: ** Enter AmdInitReset [00028000] Fch OEM config in INIT RESET Fch OEM config in INIT RESET Done AmdInitReset() returned AGESA_SUCCESS APIC 00: Heap in LocalCache (2) at 0x00400000 APIC 00: ** Exit AmdInitReset [00028000]
APIC 00: ** Enter AmdInitEarly [00023000] Am
Regards, Jorge
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org
-
Jorge Fernandez Monteagudo -
Kyösti Mälkki -
Michal Zygowski -
Patrick Georgi -
Paul Menzel