Date: Sun, 13 May 2012 00:17:18 -0700 From: Tim Kientzle <tim@kientzle.com> To: Tim Kientzle <kientzle@freebsd.org> Cc: arm@freebsd.org, freebsd-hackers@freebsd.org, Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: How does loader(8) decide where to load the kernel? Message-ID: <1CCD6DAD-5B3F-431C-8A5C-A9951408AC82@kientzle.com> In-Reply-To: <AB807672-C394-49F1-BAC1-C9BCF109410C@freebsd.org> References: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> <201205070957.03842.jhb@freebsd.org> <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> <B09F2C7F-7EAD-4194-BAA2-79319554100A@xcllnt.net> <AB807672-C394-49F1-BAC1-C9BCF109410C@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 12, 2012, at 4:36 PM, Tim Kientzle wrote: >=20 > On May 10, 2012, at 5:32 AM, Marcel Moolenaar wrote: >=20 >> On May 8, 2012, at 1:32 AM, Tim Kientzle wrote: >>>=20 >>> On the AM3358, the DRAM starts at 0x8000 0000 >>> on boot, so I'm trying to find a clean way to convince >>> the loader's ELF code to put the kernel there. >>=20 >> Look at what I did for ia64. All that frobbing should be done >> in the machine specific implementation of arch_copyin, arch_copyout >> and arch_readin. It's a kluge to do it in elf_loadimage. >=20 > That sounds like a reasonable approach. I've started > working down that path=85 but it looks like I'll have to fix > a lot of the FDT code along the way. I'm getting close. In particular, I've reworked the FDT code so that it correctly uses copyout() to parse data in the kernel. Of course, in order to use libfdt to actually manipulate the device tree, I have to copyout() the entire blob into a malloc'ed buffer. So now I need to understand how to copyin() the blob back into the kernel address space. Should I overwrite the FDT in the kernel with the edited FDT? That doesn't feel quite right, but it's essentially what the FDT code here was trying to do before. I could also implement something similar to file_loadraw() that would allow me to create a new module from an in-memory buffer. I think that might be a little cleaner. Is there already something like this? Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1CCD6DAD-5B3F-431C-8A5C-A9951408AC82>