[coreboot] Corruption issue in build_lb_mem()?

David Hendricks david.hendricks at gmail.com
Mon May 18 05:22:08 CEST 2009


I am having some difficulty booting a FILO (r95) payload using coreboot-v2
(r4291). My target is a via vb7001g, but I'm using the epia-cn target since
the boards are practically identical afaict. The only hardware change I've
made is using a 2MB flash chip. I was able to boot some simple payloads
using coreboot-v2 r4121, too.

So anyway, after doing some tracing using printk's, it seems the problem
occurs in build_lb_mem() in arch/i386/boot/coreboot_tables.c when it
attempts to record where memory ranges live.

Added print output in build_lb_mem():
    printk_debug("%s: entered\n", __func__);
    /* Record where the lb memory ranges will live */
    mem = lb_memory(head);
    printk_debug("%s: mem: 0x%p, mem->size = 0x%x\n", __func__, mem,
mem->size);
    printk_debug("\tmem->size: 0x%x\n", mem->size);
    mem_ranges = mem;
    printk_debug("\tmem_ranges->size: 0x%x\n", mem_ranges->size);

lb_memory() is short, so I'll print the full thing (I only added the two
printk's, the rest is unmodified):
struct lb_memory *lb_memory(struct lb_header *header)
{
    struct lb_record *rec;
    struct lb_memory *mem;
    printk_debug("%s: entered, header: 0x%p", __func__, header);
    rec = lb_new_record(header);
    mem = (struct lb_memory *)rec;
    mem->tag = LB_TAG_MEMORY;
    mem->size = sizeof(*mem);
    printk_debug("%s: exiting, mem: 0x%p, mem->size = 0x%x\n",
            __func__, mem, mem->size);
    return mem;
}

...and finally, a snippet from serial output:
build_lb_mem: entered, head: 0x3fff0800
lb_memory: entered, header: 0x3fff0800
lb_memory: exiting, mem: 0x3fff0817, mem->size = 0x8
build_lb_mem: mem: 0x3fff0817, mem->size = 0xffffffff
        mem->size: 0xffffffff
        mem_ranges->size: 0xffffffff

So that's pretty weird. But what's also weird is that if I set mem->size
manually after it returns from lb_memory() and then set mem_ranges, it
somehow gets set back to 0xffffffff. Here's build_lb_mem() with even more
printk's added to show that:
    printk_debug("%s: entered, head: 0x%p\n", __func__);
    /* Record where the lb memory ranges will live */
    mem = lb_memory(head);
    printk_debug("%s: mem: 0x%p, mem->size = 0x%x\n", __func__, mem,
mem->size);
    mem->size = 8;    /* FIXME: stupid idea */
    printk_debug("\tmem->size (after being manually set): 0x%x\n",
mem->size);
    mem_ranges = mem;
    printk_debug("\tmem->size after setting mem_ranges: 0x%x\n", mem->size);
    printk_debug("\tmem_ranges->size: 0x%x\n", mem_ranges->size);

...and the serial console output:
build_lb_mem: entered, head: 0x3fff0800
lb_memory: entered, header: 0x3fff0800
lb_memory: exiting, mem: 0x3fff0817, mem->size = 0x8
build_lb_mem: mem: 0x3fff0817, mem->size = 0xffffffff
        mem->size (after being manually set): 0x8
        mem->size after setting mem_ranges: 0xffffffff
        mem_ranges->size: 0xffffffff

Any ideas on what could be happening or where to go next for debugging?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090517/dd89276a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cbv2-4291_vb7001g.log
Type: application/octet-stream
Size: 31131 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090517/dd89276a/attachment.obj>


More information about the coreboot mailing list