[coreboot] Funny boot log in Coreinfo
jordan at chalmers.se
Sat Oct 18 10:10:24 CEST 2008
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.
More information about the coreboot