[coreboot] DDR1 K8 boot broken too (was: Re: PC Engines apu2 boot regression)

[Ivan Ivanov]

 Just noticed your another message. Reposting it just in case it
didn't reach Jonathan:

Kyösti Mälkki wrote:

Right.. I ack the no-go.

Try if DEBUG_CAR=y (could be in menuconfig) works before/after the
regression commit.

My guess is it fails in cpu/amd/car/post_cache_as_ram.c:101, that's
about the first place where car_get_var() goes wrong on systems with
LATE_CBMEM_INIT. IMHO it should not even have built when there is any
CAR_GLOBAL symbol present.

I would rather not see any EARLY_CBMEM_INIT or LATE_CBMEM_INIT tests
added to the tree today. Those K8 were meant to be left behind last
October. Once they are all removed from master, fixing those "*.c"
includes and CAR migration can bring your board back...

2018-05-08 11:37 GMT+03:00 Ivan Ivanov <qmastery16 at gmail.com>:
> Sadly it turned out that didn't help to Jonathan:
>
> I'm skeptical this will address my issue on msi/ms7135, as it's a
> Socket 754 board that only single-core CPU packages are available for.
> Nevertheless, I'll give this change a try.
>
> Indeed, it does not fix the issue I'm having.
>
>
> 2018-05-06 8:22 GMT+03:00 Kyösti Mälkki <kyosti.malkki at gmail.com>:
>> On Fri, May 4, 2018 at 7:25 PM, Aaron Durbin via coreboot
>> <coreboot at coreboot.org> wrote:
>>> On Fri, May 4, 2018 at 10:01 AM, Jonathan A. Kollasch
>>> <jakllsch at kollasch.net> 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, try this: https://review.coreboot.org/c/coreboot/+/26120
>>
>> Kyösti
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot