Date: Tue, 15 May 2012 21:55:35 -0700 From: Tim Kientzle <tim@kientzle.com> To: Rafal Jaworowski <raj@semihalf.com> 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: <B96FEB78-B436-41E1-8A50-C2D888A9ED2E@kientzle.com> In-Reply-To: <1A2C0F4D-E03E-4FC1-9ED7-07DE1D056D3E@semihalf.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> <1A2C0F4D-E03E-4FC1-9ED7-07DE1D056D3E@semihalf.com>
index | next in thread | previous in thread | raw e-mail
On May 15, 2012, at 9:38 AM, Rafal Jaworowski wrote: >> >> 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. > > 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. I've fixed the code in sys/boot/fdt/ to do all access through copyout/copyin. I'm waiting for a "make universe" to make sure I didn't break something inadvertently, and will probably commit it tomorrow. Right now, this just copies the DTB to a malloc-ed area, modifies the copy and then writes it back to the same place (either in the kernel or in a separately-loaded blob). It seems to work correctly even when copyout/copyin are doing address translations. > ... if you'd like to modify the blob in a major way you need to relocate it into a new location with more padding …. create a DTB metadatum (as if the DTB was loaded dynamically from standalone blob file) with sufficient space, …. 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. Yes, I see how that would work. Is there a real use for this? I could take a look at it once I'm finished with the current ubldr work I'm doing. Timhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B96FEB78-B436-41E1-8A50-C2D888A9ED2E>