I haven't looked into the cause yet, but the boot log looks a little "funny" in coreinfo. At least it's smiling.
Thanks, Myles
it's still news. You just booted our first K8 platform.
WOW! nice job!
ron
On Fri, Oct 17, 2008 at 11:35 AM, ron minnich rminnich@gmail.com wrote:
it's still news. You just booted our first K8 platform.
WOW! nice job!
Sorry to get your hopes up. The screenshot is from qemu.
SimNOW boots but I get no output on VGA still. When the VGA BIOS initializes I was hoping for some output, but still nothing.
I built coreinfo for qemu to compare logs and noticed the funny output.
Thanks, Myles
On 17/10/08 11:29 -0600, Myles Watson wrote:
I haven't looked into the cause yet, but the boot log looks a little "funny" in coreinfo. At least it's smiling.
Hmm - that is very unfortunate. I think we have boot log issues - I have also discovered that the bootlog is apparently overwriting the v3 coreboot tables. This could be a consequence of that.
Jordan
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On 17.10.2008 19:46, Jordan Crouse wrote:
On 17/10/08 11:29 -0600, Myles Watson wrote:
I haven't looked into the cause yet, but the boot log looks a little "funny" in coreinfo. At least it's smiling.
Hmm - that is very unfortunate. I think we have boot log issues - I have also discovered that the bootlog is apparently overwriting the v3 coreboot tables. This could be a consequence of that.
Is there any old version where you don't see the issues on qemu?
IIRC K8 has numerous issues in the v3 startup code which can (and probably will) interfere with printk buffers. I'm currently auditing the code to hunt all of these problems down. Please don't try using CONFIG_PRINTK_BUFFER with K8.
By the way, the v3 K8 disable_car() is very broken AFAICS and works only by sheer luck. Will send details real soon now. Hint: Throwing away the cache before backing it up is considered harmful. You really don't want that.
Regards, Carl-Daniel
On Fri, Oct 17, 2008 at 3:47 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
On 17.10.2008 19:46, Jordan Crouse wrote:
On 17/10/08 11:29 -0600, Myles Watson wrote:
I haven't looked into the cause yet, but the boot log looks a little
"funny"
in coreinfo. At least it's smiling.
Hmm - that is very unfortunate. I think we have boot log issues - I have also discovered that the bootlog is apparently overwriting the v3 coreboot tables. This could be a consequence of that.
Is there any old version where you don't see the issues on qemu?
Yes. I know when it was a new feature I tried it out and didn't see this garbage.
IIRC K8 has numerous issues in the v3 startup code which can (and probably will) interfere with printk buffers. I'm currently auditing the code to hunt all of these problems down. Please don't try using CONFIG_PRINTK_BUFFER with K8.
We should probably change the defconfigs then. It doesn't change any behavior for me, so I must just be lucky.
Thanks, Myles
On 17.10.2008 23:57, Myles Watson wrote:
On Fri, Oct 17, 2008 at 3:47 PM, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net mailto:c-d.hailfinger.devel.2006@gmx.net> wrote:
On 17.10.2008 19:46, Jordan Crouse wrote: > On 17/10/08 11:29 -0600, Myles Watson wrote: > >> I haven't looked into the cause yet, but the boot log looks a little "funny" >> in coreinfo. At least it's smiling. >> > > Hmm - that is very unfortunate. I think we have boot log issues - I have > also discovered that the bootlog is apparently overwriting the v3 > coreboot tables. This could be a consequence of that. > Is there any old version where you don't see the issues on qemu?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.
IIRC K8 has numerous issues in the v3 startup code which can (and probably will) interfere with printk buffers. I'm currently auditing the code to hunt all of these problems down. Please don't try using CONFIG_PRINTK_BUFFER with K8.We should probably change the defconfigs then. It doesn't change any behavior for me, so I must just be lucky.
I can make PRINTK_BUFFER depend on !K8.
Regards, Carl-Daniel
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 probably won't get to that very soon. Sorry.
IIRC K8 has numerous issues in the v3 startup code which can (and probably will) interfere with printk buffers. I'm currently auditing the code to hunt all of these problems down. Please don't try using CONFIG_PRINTK_BUFFER with K8.We should probably change the defconfigs then. It doesn't change any behavior for me, so I must just be lucky.
I can make PRINTK_BUFFER depend on !K8.
Which would make someone go through and change the defconfigs.
Myles
On 18/10/08 00:28 +0200, Carl-Daniel Hailfinger wrote:
On 17.10.2008 23:57, Myles Watson wrote:
On Fri, Oct 17, 2008 at 3:47 PM, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net mailto:c-d.hailfinger.devel.2006@gmx.net> wrote:
On 17.10.2008 19:46, Jordan Crouse wrote: > On 17/10/08 11:29 -0600, Myles Watson wrote: > >> I haven't looked into the cause yet, but the boot log looks a little "funny" >> in coreinfo. At least it's smiling. >> > > Hmm - that is very unfortunate. I think we have boot log issues - I have > also discovered that the bootlog is apparently overwriting the v3 > coreboot tables. This could be a consequence of that. > Is there any old version where you don't see the issues on qemu?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.
Jordan
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.
Regards, Carl-Daniel
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
-
Carl-Daniel Hailfinger -
Jordan Crouse -
Myles Watson -
ron minnich -
Ulf Jordan