Date: Tue, 15 May 2012 18:38:48 +0200 From: Rafal Jaworowski <raj@semihalf.com> To: Tim Kientzle <tim@kientzle.com> Cc: arm@freebsd.org, freebsd-hackers@freebsd.org, Tim Kientzle <kientzle@freebsd.org>, Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: How does loader(8) decide where to load the kernel? Message-ID: <1A2C0F4D-E03E-4FC1-9ED7-07DE1D056D3E@semihalf.com> In-Reply-To: <1CCD6DAD-5B3F-431C-8A5C-A9951408AC82@kientzle.com> 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> <1CCD6DAD-5B3F-431C-8A5C-A9951408AC82@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2012-05-13, at 09:17, Tim Kientzle wrote: > 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. >=20 > 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. >=20 > So now I need to understand how to copyin() the > blob back into the kernel address space. >=20 > 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. >=20 > 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. >=20 > Is there already something like this? A given DTB (loaded dynamically or statically embedded in the kernel) = has some small amount of free space inside it so it is possible to = perform in-place modifications, adding properties / nodes until you run = our of this space (libfdt code will handle cases when exceeding this and = would fail gracefully). The fixup mechanism currently implemented does = minor modifications of the device tree in this fashion. My understanding is that if you'd like to modify the blob in a major way = you need to relocate it into a new location with more padding (there's = facility for relocation in libfdt already) and then modify it = accordingly. This won't be possible however with the statically embedded = DTB in the kernel as you cannot grow this space easily. The way to go = here would be to create a DTB metadatum (as if the DTB was loaded = dynamically from standalone blob file) with sufficient space, relocate = the statically embedded original content into this metadatum, do = modifications there and pass this new copy (as part of regular loader(8) = metadata) to the kernel for processing. The building blocks are there = (DTB loaded as metadata) and should work. Rafal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1A2C0F4D-E03E-4FC1-9ED7-07DE1D056D3E>