[coreboot] Corruption issue in build_lb_mem()?

ron minnich rminnich at gmail.com
Mon May 18 16:58:09 CEST 2009


On Sun, May 17, 2009 at 8:22 PM, David Hendricks
<david.hendricks at gmail.com> wrote:
> 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?

It sure looks to me like there's no memory where the high mem tables
are pointing -- 0x3fff0800. Or, some register is limiting your access
to memory.

Simple test: after memory is turned on, dump 32 bytes at each 1M
boundary and see where it fails.

ron




More information about the coreboot mailing list