From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 04:55:43 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AECFC1065673; Wed, 16 May 2012 04:55:43 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 696CC8FC0C; Wed, 16 May 2012 04:55:43 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q4G4ta7i097766; Wed, 16 May 2012 04:55:36 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id cjwceifix7u97pzjty2ewj4y5s; Wed, 16 May 2012 04:55:36 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <1A2C0F4D-E03E-4FC1-9ED7-07DE1D056D3E@semihalf.com> Date: Tue, 15 May 2012 21:55:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> <201205070957.03842.jhb@freebsd.org> <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> <1CCD6DAD-5B3F-431C-8A5C-A9951408AC82@kientzle.com> <1A2C0F4D-E03E-4FC1-9ED7-07DE1D056D3E@semihalf.com> To: Rafal Jaworowski X-Mailer: Apple Mail (2.1257) Cc: arm@freebsd.org, freebsd-hackers@freebsd.org, Marcel Moolenaar Subject: Re: How does loader(8) decide where to load the kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 04:55:43 -0000 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