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