On Sun, May 17, 2009 at 8:22 PM, David Hendricks <[email protected]> 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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
