Re: [coreboot] PC Engines apu2 boot regression
On Fri, May 4, 2018 at 8:22 PM, Aaron Durbin wrote: > On Fri, May 4, 2018 at 11:16 AM, Kyösti Mälkki > wrote: >> On Fri, May 4, 2018 at 7:19 PM, Kyösti Mälkki >> wrote: >>> On Fri, May 4, 2018 at 6:37 PM, Aaron Durbin wrote: > > Any idea what can be result of such weird behavior? >> >> My current guess is AP CPUs do not see initialised memory for >> _car_region_start .. _end. That region is set up using fixed MTRRs in >> low memory and probably not synced between cores so early in romstage. >> > > Ugh. Why do we allow the APs to run through all these stages? Is this > for parallel node memory training? Can we ring fence where the APs > actually run better? > I have to check closer, but for apu2 this would be in AMD_INIT_EARLY already, so AP CPUs run way before (the only) memory controller is configured. I believe there is microcode updates and some CPU registers that are also synced during AMD_INIT_EARLY. So it is doing more than just bringing an idle AP task engine. I find it particularly hard to be civil on your first question, so trying with sarcasm instead. After 5000 or so development hours and direct support from AMD, is the boot sequence for soc/stoneyridge prototypes equally bad, that is, AP CPUs execute through bootblock and verstage? Kyösti -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PC Engines apu2 boot regression
>
> My current guess is AP CPUs do not see initialised memory for
> _car_region_start .. _end. That region is set up using fixed MTRRs in
> low memory and probably not synced between cores so early in romstage.
>
Kyosti, I haven't kept a close watch on CAR changes in the other AMD
systems, however in experimenting with CZ using ST source I found that 4
cores had a problem using CAR globals, so I think you're on the right
track. AMD's CAR setup code assumes each core only needs fixed MTRRs
configured for their own particular region of storage -- they all don't get
access to 100% of the CAR area. Going from 2 cores (ST) to 4 cores (CZ),
the higher two cores could no longer access the CAR globals at the bottom
of the region. Try this hack and see if it improves for you:
diff --git a/src/vendorcode/amd/pi/00730F01/binaryPI/gcccar.inc
b/src/vendorcode/amd/pi/00730F01/binaryPI/gcccar.inc
index 5a4f7b9..fd3bf81 100644
--- a/src/vendorcode/amd/pi/00730F01/binaryPI/gcccar.inc
+++ b/src/vendorcode/amd/pi/00730F01/binaryPI/gcccar.inc
@@ -1151,6 +1151,7 @@ SetupStack:
or %edi, %edx#
#.endif #
0:
+or $0x1e00, %eax# force 3-4 for cbmem
access
_WRMSR #
# Enable MTRR defaults as UC type
--
Ugh. Why do we allow the APs to run through all these stages? Is this
> for parallel node memory training? Can we ring fence where the APs
> actually run better?
>
Aaron, on Stoney Ridge all cores needed to be alive in order to do memory
training. It wasn't that they were used in the algorithm (as far as I've
seen); they simply had to be there to prevent the northbridge from blowing
up. I've long since forgotten what internal designs AMD used for Family
15h and 16h, but it seems likely the same limitation applies on Family 16h
too. We occasionally discuss a different methodology of shutting down the
APs immediately when they're released, and not letting them run through to
InitEarly(). It seems like that ought to allow the northbridge to behave
as expected during training in InitPost().
Thanks,
Marshall
On Fri, May 4, 2018 at 11:22 AM, Aaron Durbin via coreboot <
coreboot@coreboot.org> wrote:
> On Fri, May 4, 2018 at 11:16 AM, Kyösti Mälkki
> wrote:
> > On Fri, May 4, 2018 at 7:19 PM, Kyösti Mälkki
> wrote:
> >> On Fri, May 4, 2018 at 6:37 PM, Aaron Durbin
> wrote:
>
> Any idea what can be result of such weird behavior?
> >>>
> >
> > My current guess is AP CPUs do not see initialised memory for
> > _car_region_start .. _end. That region is set up using fixed MTRRs in
> > low memory and probably not synced between cores so early in romstage.
> >
>
> Ugh. Why do we allow the APs to run through all these stages? Is this
> for parallel node memory training? Can we ring fence where the APs
> actually run better?
>
> >
> > diff --git a/src/console/init.c b/src/console/init.c
> > index 8f71b09..4731e7e 100644
> > --- a/src/console/init.c
> > +++ b/src/console/init.c
> > @@ -35,7 +35,7 @@ static int console_loglevel = CONFIG_DEFAULT_CONSOLE_
> LOGLEVEL;
> >
> > static inline int get_log_level(void)
> > {
> > - if (car_get_var(console_inited) == 0)
> > + if (boot_cpu() && car_get_var(console_inited) == 0)
> > return -1;
> > if (CONSOLE_LEVEL_CONST)
> > return get_console_loglevel();
> >
> > Kyösti
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] FSP 2.0 headers in coreboot
On Fri, May 4, 2018 at 3:20 PM, Youness Alaoui wrote: > Hi, > > I've just pushed a commit for review on gerrit > (https://review.coreboot.org/#/c/coreboot/+/26108/) and I'm hoping to > open the discussion here on whether the public coreboot code should > have the FSP headers that match the public FSP headers or if they > should match the 'google fsp' headers. > > My understanding of the situation is that chromebooks ship with a > google-modified FSP image and the fsp headers in coreboot have been > added by google employees even before the FSP was officially made > public by Intel. I also somewhat understood that the fsp headers in > coreboot would not be updated to match the public release because it > would break everyone building coreboot for their chromebooks or > something like that. They aren't modified necessarily. It's more of different views on the same timeline of a development. Granted, the releases are definitely not coordinated. I'm not even sure how/who releases the github blobs/headers on Intel's side. > > I'm a bit tired of always having that commit that fixes the header > applied locally in all my branches, and I think that it makes much > more sense for coreboot to have the fsp headers that match the public > release and for the google/chromebook coreboot repository to have the > "non-standard header" committed to it instead. > Worst case scenario, we could add #ifdefs to determine what the > structure contents should be depending on the target platform. > > Maybe everyone will say "of course, that makes sense" or maybe > everyone will say "nope, I disagree", but hopefully we can have the > discussion here (or on gerrit) and decide how to handle this use case. > Note: I only pushed for skylake/kabylake, but apollolake/canonlake are > probably also affected by this mismatch of headers. I think we should have both that can be selected through a Kconfig such that we can bind to the headers correctly. We already had to do that for edk2 issues as well. I can't think of better alternative at the moment that supports both. > > Thanks, > Youness. > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] FSP 2.0 headers in coreboot
Hi, I've just pushed a commit for review on gerrit (https://review.coreboot.org/#/c/coreboot/+/26108/) and I'm hoping to open the discussion here on whether the public coreboot code should have the FSP headers that match the public FSP headers or if they should match the 'google fsp' headers. My understanding of the situation is that chromebooks ship with a google-modified FSP image and the fsp headers in coreboot have been added by google employees even before the FSP was officially made public by Intel. I also somewhat understood that the fsp headers in coreboot would not be updated to match the public release because it would break everyone building coreboot for their chromebooks or something like that. I'm a bit tired of always having that commit that fixes the header applied locally in all my branches, and I think that it makes much more sense for coreboot to have the fsp headers that match the public release and for the google/chromebook coreboot repository to have the "non-standard header" committed to it instead. Worst case scenario, we could add #ifdefs to determine what the structure contents should be depending on the target platform. Maybe everyone will say "of course, that makes sense" or maybe everyone will say "nope, I disagree", but hopefully we can have the discussion here (or on gerrit) and decide how to handle this use case. Note: I only pushed for skylake/kabylake, but apollolake/canonlake are probably also affected by this mismatch of headers. Thanks, Youness. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Why do we have FSP-S
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/04/2018 01:08 PM, Zaolin wrote: > You forgot Cavium Thunder X SoC support, Stefan ;) > > Finally coreboot supports it and there are no blobs > > on this platform. It's not exactly what I'd call modern desktop or server class, though :-) Its successor is better performing but completely closed. https://www.phoronix.com/scan.php?page=news_item&px=Raptor-TALOS2-Initial-Tests - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJa7LKqAAoJEK+E3vEXDOFbuzMH/23o80UMIS2r+3Dd30w02ej2 ehXxch2QfvSM8jg56KreHbBJq7xTuQE4fWLcGTIMncXILDCRsrAN6aY2wmHB4Ip9 JJoFs9uDF9TU5CwiKbM4T7nE63Cey7uJ7iGqnSojD10qP04wQK66EF53ri8mY/DP vboj6TLx+9If34Yxgrn++Uc4IRzktmNvgtbUT5o5SurX8jvaRJILwnwLbVcoEUEY mMF1deHWJ3LzA2859aYI7SZ+O3+ONfvY0OfnK3wm3pvfAV7EcRP4N6EFpqa659Md IkHmw9WIlztsd11qDz5vtxhgjsNnFdA36jJfVY5fq9Mx/bTt5Z4VPmsnbrhBWN4= =r/rU -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Why do we have FSP-S
You forgot Cavium Thunder X SoC support, Stefan ;) Finally coreboot supports it and there are no blobs on this platform. On 04.05.2018 20:01, Stefan Reinauer wrote: > * Timothy Pearson [180501 04:58]: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> All the ARM64 boards I've seen that are desktop or higher class ship >> with AMI UEFI and AMI BMC. Plus they contain their own magic blobs, >> some akin to the ME. ARM64 is not a panacea either; > It's certainly good to have more options. > > As far as AArch64 goes... > Google's Pixel C is ARM64 and running coreboot. All rk3399 devices, too. > > Stefan > > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Why do we have FSP-S
Hi Kyösti, That's a great post-mortem, thanks for writing it up! I didn't mean to imply that binary PI is a great example of how to do things, I just think Bruce's explanation is useful for answering Ivan's question of why companies don't simply open their code. As you point out binary blobs aren't a magic bullet and can end up a bitrotting mess with no salvageable value for other potential customers. Intel's done a better job with FSP so far, hopefully we can convince them that opening it up will add significant value for them by enabling more customers and more products. On that note, a shameless plug: http://www.opencompute.org/projects/open-system-firmware/ On Thu, May 3, 2018 at 1:37 AM, Kyösti Mälkki wrote: > Hi David, > > I tried to stay away from commenting, but now that you pulled this red > binaryPI card from your pocket :) > > On Wed, May 2, 2018 at 9:49 PM, David Hendricks > wrote: >> >> Bruce Griffith's e-mail about AMD's binary PI provides some great >> insights into these issues: >> https://mail.coreboot.org/pipermail/coreboot/2014-November/078892.html >> > > I did not revisit that entire thread, judging by the date it was > possibly prior to binaryPI code drops. From my perspective the only > intention with binaryPI was for SAGE to gain a monopoly consulting > position on AMD based coreboot board ports, leaving them the only ones > capable of building and debugging with the blob. I don't think any of > the advertised benefits realized and the problems with time-to-market > were not solved. I believe SAGE got the final nail on their coffin > after AMD started to lock x86 JTAG debug (aka HDT) on their new SoC's > and made SAGE EDK tool unusable. > > When referring to binaryPI below, I am ruling out ongoing development > around StoneyRidge SoC. Somewhat different team, more strict quality > goals as set by ChromeOS and much more resources and review talent put > on the task now. Or so I have been told at least. > > The aftermath of binaryPI (say, version 0.1) : > > 1. Nobody *1 can reproduce the binaryPI blob builds that were pushed > to coreboot 3rdparty repo. For most of these, I bet the source tree > revision could not be traced back either. Source repositories are > somewhere in the ruins of AMD AES and SAGE ex-personnel. > > 2. The needed binaryPI source is somewhat heavily patched version of a > package, which a commercial partner is (or was) able to get through > his AMD representative under an NDA and longish negotiations and > promises of significant purchase volumes. In other words, your AMD > reps cannot provide you with the source or the binary you need for use > with coreboot. > > 3. After the binaryPI contractor SAGE shut down and AMD AES bailed out > on coreboot (late 2015?), AMD has not granted permission to > redistribute new builds of these binaryPI blobs even if we had the > sources. And we do have the source for x86 AGESA parts, but not for > PSP. > > 4. Commits of updated blob builds mostly just referenced AMD internal > bugtracker ID numbers. For some cases, you cannot use the latest build > of these blobs as they break elsewhere. In other words, for best user > experience, you build the blob from the source you do not legally > have. > > 5. Features partially or completely known broken in pre-built blobs > (depending of SoC): ECC, HSA, IOMMU, S3 suspend, C6 boost, SPI > dual/quad, fastboot (aka MRC cache). > > 6. AMD ignored or refused requests to provide debug builds of said > blobs to create meaningful bootlogs on console, comparable to > open-source AGESA. Also built-in error backlog feature in non-debug > builds was initially broken, and once fixed, you still needed the > source to decipher the error. > > 7. Some of the PSP (aka Security Processor) firmware in 3rdparty was > modified for coreboot use. Commit message refers to which version was > submitted, but file hash does not match with one you obtained from AMD > reps. Someone with access to PSP's private key has approved the > modifications, but none of this was mentioned with the commit. > > Needless to say, with all the issues above, it's hard to attract new > industrial users on coreboot when product longevity is at risk due to > uncertanities of having no firmware evaluation. After this first > attempt of going closed-source with AGESA, there is one actively > shipping product (5 board variants) from 2015. Not counting reference > designs, there are less than five other commercially ported boards in > this group from 2015-2017. AFAICS these board boot with coreboot only > inside the companies R&D, some use custom builds of binaryPI blob > while others link original (but modified) proprietary AMD source > together with coreboot proper. I understand some would rather not ship > with proprietary UEFI, but the legalities... > > I feel disheartened to read similar issues arising with Intel FSP. > Uncertainity with matching header files with the blobs, lack of > distribution rights, vendor support channel p
Re: [coreboot] Why do we have FSP-S
* Timothy Pearson [180501 04:58]: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > All the ARM64 boards I've seen that are desktop or higher class ship > with AMI UEFI and AMI BMC. Plus they contain their own magic blobs, > some akin to the ME. ARM64 is not a panacea either; It's certainly good to have more options. As far as AArch64 goes... Google's Pixel C is ARM64 and running coreboot. All rk3399 devices, too. Stefan -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PC Engines apu2 boot regression
On Fri, May 4, 2018 at 11:16 AM, Kyösti Mälkki wrote:
> On Fri, May 4, 2018 at 7:19 PM, Kyösti Mälkki wrote:
>> On Fri, May 4, 2018 at 6:37 PM, Aaron Durbin wrote:
Any idea what can be result of such weird behavior?
>>>
>
> My current guess is AP CPUs do not see initialised memory for
> _car_region_start .. _end. That region is set up using fixed MTRRs in
> low memory and probably not synced between cores so early in romstage.
>
Ugh. Why do we allow the APs to run through all these stages? Is this
for parallel node memory training? Can we ring fence where the APs
actually run better?
>
> diff --git a/src/console/init.c b/src/console/init.c
> index 8f71b09..4731e7e 100644
> --- a/src/console/init.c
> +++ b/src/console/init.c
> @@ -35,7 +35,7 @@ static int console_loglevel =
> CONFIG_DEFAULT_CONSOLE_LOGLEVEL;
>
> static inline int get_log_level(void)
> {
> - if (car_get_var(console_inited) == 0)
> + if (boot_cpu() && car_get_var(console_inited) == 0)
> return -1;
> if (CONSOLE_LEVEL_CONST)
> return get_console_loglevel();
>
> Kyösti
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PC Engines apu2 boot regression
On Fri, May 4, 2018 at 7:19 PM, Kyösti Mälkki wrote:
> On Fri, May 4, 2018 at 6:37 PM, Aaron Durbin wrote:
>>>
>>> Any idea what can be result of such weird behavior?
>>
My current guess is AP CPUs do not see initialised memory for
_car_region_start .. _end. That region is set up using fixed MTRRs in
low memory and probably not synced between cores so early in romstage.
diff --git a/src/console/init.c b/src/console/init.c
index 8f71b09..4731e7e 100644
--- a/src/console/init.c
+++ b/src/console/init.c
@@ -35,7 +35,7 @@ static int console_loglevel = CONFIG_DEFAULT_CONSOLE_LOGLEVEL;
static inline int get_log_level(void)
{
- if (car_get_var(console_inited) == 0)
+ if (boot_cpu() && car_get_var(console_inited) == 0)
return -1;
if (CONSOLE_LEVEL_CONST)
return get_console_loglevel();
Kyösti
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] DDR1 K8 boot broken too (was: Re: PC Engines apu2 boot regression)
On Fri, May 4, 2018 at 10:01 AM, Jonathan A. Kollasch wrote: > On Fri, May 04, 2018 at 05:23:40PM +0200, Piotr Król wrote: >> Hi Aaron, >> I tried to boot PC Engines apu2 on recent master branch and discovered >> that it not boot. Bisection points to: >> >> 60320182d011 console: only allow console messages after initialization >> >> It is hard to believe that this change cause AGESA reset loop, but I >> checked 3 times. After applying above commit I end up with loop: > > I see a similar romstage boot loop starting with this commit on > msi/ms7135 (K8N Neo3), a DDR1 K8 board. I think it's the AMD boards and their weird config. CAR_GLOBAL is used, but apparently these boards fail if accessing CAR_GLOBAL at the wrong time? If you have log diffs w/ and w/o the patch it'd help with root cause. > > Jonathan Kollasch > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PC Engines apu2 boot regression
On Fri, May 4, 2018 at 6:37 PM, Aaron Durbin wrote: > On Fri, May 4, 2018 at 9:23 AM, Piotr Król wrote: >> Hi Aaron, >> I tried to boot PC Engines apu2 on recent master branch and discovered >> that it not boot. Bisection points to: >> >> 60320182d011 console: only allow console messages after initialization >> >> It is hard to believe that this change cause AGESA reset loop, but I >> checked 3 times. After applying above commit I end up with loop: >> >> coreboot-4.7-441-g60320182d0 Fri Mar 2 15:22:24 UTC 2018 romstage >> starting... >> BSP Family_Model: 00730f01 >> cpu_init_detectedx = >> agesawrapper_amdinitreset() entry >> CBFS: 'Master Header Locator' located CBFS at [200:7fffc0) >> CBFS: Locating 'AGESA' >> CBFS: Found @ offset 5ffdc0 size 7b0e0 >> CBFS: 'Master Header Locator' located CBFS at [200:7fffc0) >> CBFS: Locating 'AGESA' >> CBFS: Found @ offset 5ffdc0 size 7b0e0 >> Fch OEM config in INIT RESET Done >> >> Any idea what can be result of such weird behavior? > > I think it's because we still have boards that utilize CAR_GLOBAL, but > don't handle migration of CAR globals. Those two things combined > really makes for situations that just don't work and ramstage loading > is just lucky to work on those platforms. I was originally thinking > this patch would work, but I don't think that's the case because when > I build apu2 CONFIG_EARLY_CBMEM_INIT is already set. If you revert > that patch what does your log look like? We could be recursively > entering into car_get_var_ptr() through the printk() path, but that > would require things not marked as CAR_GLOBAL being passed to that > function. There is one way to fix all of these scenarios: remove CAR > migration by transitioning everyone to postcar stub between romstage > and ramstage. That's a lot of work, though. We can try and debug > further because I'm not clear why things aren't working. > Well I am looking at this as well now. I have not booted vanilla master on apu2 for sometime, being preparing POSTCAR_STAGE for these binaryPI boards instead.. Kyösti -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] DDR1 K8 boot broken too (was: Re: PC Engines apu2 boot regression)
On Fri, May 04, 2018 at 05:23:40PM +0200, Piotr Król wrote: > Hi Aaron, > I tried to boot PC Engines apu2 on recent master branch and discovered > that it not boot. Bisection points to: > > 60320182d011 console: only allow console messages after initialization > > It is hard to believe that this change cause AGESA reset loop, but I > checked 3 times. After applying above commit I end up with loop: I see a similar romstage boot loop starting with this commit on msi/ms7135 (K8N Neo3), a DDR1 K8 board. Jonathan Kollasch -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PC Engines apu2 boot regression
On Fri, May 4, 2018 at 9:23 AM, Piotr Król wrote:
> Hi Aaron,
> I tried to boot PC Engines apu2 on recent master branch and discovered
> that it not boot. Bisection points to:
>
> 60320182d011 console: only allow console messages after initialization
>
> It is hard to believe that this change cause AGESA reset loop, but I
> checked 3 times. After applying above commit I end up with loop:
>
> coreboot-4.7-441-g60320182d0 Fri Mar 2 15:22:24 UTC 2018 romstage
> starting...
> BSP Family_Model: 00730f01
> cpu_init_detectedx =
> agesawrapper_amdinitreset() entry
> CBFS: 'Master Header Locator' located CBFS at [200:7fffc0)
> CBFS: Locating 'AGESA'
> CBFS: Found @ offset 5ffdc0 size 7b0e0
> CBFS: 'Master Header Locator' located CBFS at [200:7fffc0)
> CBFS: Locating 'AGESA'
> CBFS: Found @ offset 5ffdc0 size 7b0e0
> Fch OEM config in INIT RESET Done
>
> Any idea what can be result of such weird behavior?
I think it's because we still have boards that utilize CAR_GLOBAL, but
don't handle migration of CAR globals. Those two things combined
really makes for situations that just don't work and ramstage loading
is just lucky to work on those platforms. I was originally thinking
this patch would work, but I don't think that's the case because when
I build apu2 CONFIG_EARLY_CBMEM_INIT is already set. If you revert
that patch what does your log look like? We could be recursively
entering into car_get_var_ptr() through the printk() path, but that
would require things not marked as CAR_GLOBAL being passed to that
function. There is one way to fix all of these scenarios: remove CAR
migration by transitioning everyone to postcar stub between romstage
and ramstage. That's a lot of work, though. We can try and debug
further because I'm not clear why things aren't working.
diff --git a/src/console/init.c b/src/console/init.c
index 8f71b09881..b5c2f792fa 100644
--- a/src/console/init.c
+++ b/src/console/init.c
@@ -35,7 +35,7 @@ static int console_loglevel = CONFIG_DEFAULT_CONSOLE_LOGLEVEL;
static inline int get_log_level(void)
{
- if (car_get_var(console_inited) == 0)
+ if (IS_ENABLED(CONFIG_EARLY_CBMEM_INIT) && !car_get_var(console_inited))
return -1;
if (CONSOLE_LEVEL_CONST)
return get_console_loglevel();
@@ -78,7 +78,8 @@ asmlinkage void console_init(void)
console_hw_init();
- car_set_var(console_inited, 1);
+ if (IS_ENABLED(CONFIG_EARLY_CBMEM_INIT))
+ car_set_var(console_inited, 1);
printk(BIOS_NOTICE, "\n\ncoreboot-%s%s %s " ENV_STRING " starting...\n",
coreboot_version, coreboot_extra_version, coreboot_build);
>
> Best Regards,
> --
> Piotr Król
> Embedded Systems Consultant
> https://3mdeb.com | @3mdeb_com
>
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] PC Engines apu2 boot regression
Hi Aaron, I tried to boot PC Engines apu2 on recent master branch and discovered that it not boot. Bisection points to: 60320182d011 console: only allow console messages after initialization It is hard to believe that this change cause AGESA reset loop, but I checked 3 times. After applying above commit I end up with loop: coreboot-4.7-441-g60320182d0 Fri Mar 2 15:22:24 UTC 2018 romstage starting... BSP Family_Model: 00730f01 cpu_init_detectedx = agesawrapper_amdinitreset() entry CBFS: 'Master Header Locator' located CBFS at [200:7fffc0) CBFS: Locating 'AGESA' CBFS: Found @ offset 5ffdc0 size 7b0e0 CBFS: 'Master Header Locator' located CBFS at [200:7fffc0) CBFS: Locating 'AGESA' CBFS: Found @ offset 5ffdc0 size 7b0e0 Fch OEM config in INIT RESET Done Any idea what can be result of such weird behavior? Best Regards, -- Piotr Król Embedded Systems Consultant https://3mdeb.com | @3mdeb_com signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
