[coreboot] Funny boot log in Coreinfo

[Ulf Jordan]

On Sat, 18 Oct 2008, Carl-Daniel Hailfinger wrote:

> On 18.10.2008 01:36, Jordan Crouse wrote:
>> On 18/10/08 00:28 +0200, Carl-Daniel Hailfinger wrote:
>>
>>> On 17.10.2008 23:57, Myles Watson wrote:
>>>
>>>> Yes.  I know when it was a new feature I tried it out and didn't see
>>>> this garbage.
>>>>
>>> I remember it working well some time ago. It would be great if you could
>>> do a binary search and narrow it down. I can then fix the problem.
>>>
>>
>> I don't ever remember it working exactly right.  If you look at
>> the output, it matches what ever is living at physical address 0x0 -
>> at least for the first page or so.  Clearly there is come contention here.
>>
>
> That would be indeed bad.
> However, I remember that Marc checked some time ago with an FS2 that the
> code behaved as intended.
> And I checked right now with svn HEAD that a v3 boot in qemu has the
> post-CAR printk buffer at exactly one location (0x90000) and except for
> remnants at the original CAR printk buffer location, the contents of the
> buffer don't appear anywhere else nor are they garbled.
>
> If you want t dump the low 1M of qemu from the qemu console, try this:
> memsave 0x0 0x100000 lowmem.dump
>
>
> Multiple possibilities:
> - My qemu works differently from yours
> - Your payload is broken
> - Your tree is broken
>
> Neither of them is something I'm happy about.

I've also never seen the coreinfo coreboot log display quite correctly. My 
testing has always been with coreboot-v3 in qemu (0.8.2-4etch1, which 
might be a bit outdated). The area at 0x90000 seems OK, so corruption 
takes place later.

There are several problems:

* Outputting funny/nonprintable characters, was prevented by r3621, but 
the root cause is the buffer corruption.

* the coreinfo bootlog starts 2 bytes to late ("co" is missing on the 
first line), see FIXME at coreinfo/bootlog_module.c:35

* something is corrupting coreinfo's malloced buffer by overwriting it 
with 64-bit binary numbers every 192 bits in the first two screens. 
This happens after copying from the printk area at 0x90000. There is also 
a non-finished check for NULL after malloc (coreinfo/bootlog_module.c:38), 
so even if malloc fails, the memcpy takes place anyway. Maybe not so good, 
and quite likely the reason why the buffer ends up at 0x0.


/ulf