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