Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Richard PANDION <rpandion@ca...> - 2010-07-13 12:25:03
I believe I've detected a bug in Prex 0.9.0 bootloader.
Indeed, in the load_elf() function in bsp/boot/common/elf.c, at line #75, there is the following assignment:
load_base = (vaddr_t)ptokv(phdr->p_paddr);
This seems to be wrong and should be:
load_base = (paddr_t)kvtop(phdr->p_vaddr);
This is a nasty bug as it remains silent if you stick to the default config where offset to the kernel area start address (0x80000000) from ram base (0x00000000) equals 0x80000000.
Indeed, phdr->p_paddr and phdr->p_vaddr both holds the same value as CONFIG_KERNEL_TEXT while the kernel is loaded and, in MMU-enabled default config, this value is > 0x80000000. But adding 0x80000000 (this is what ptokv() does) or substrating 0x80000000 (this is what kvtop() does) to such address actually gives the exact same result since we are here dealing with 32-bits wide unsigned longs! Now, if for any reason, offset to kernel start address from ram base does no equal 0x80000000, the bug comes out.
Hopefully, fixing this issue will help me finalize the beagleboard MMU-enabled version of Prex I'm currently working on...
(7/13/2010 8:07 PM) Richard PANDION wrote:
> Indeed, in the load_elf() function in bsp/boot/common/elf.c, at line #75, there is the following assignment:
> load_base = (vaddr_t)ptokv(phdr->p_paddr);
> This seems to be wrong and should be:
> load_base = (paddr_t)kvtop(phdr->p_vaddr);
I've applied fix.