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>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 15, 2012, at 9:38 AM, Rafal Jaworowski wrote: >>=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 > 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 =85. create a DTB = metadatum (as if the DTB was loaded dynamically from standalone blob = file) with sufficient space, =85. 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. Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B96FEB78-B436-41E1-8A50-C2D888A9ED2E>