From owner-freebsd-hackers@FreeBSD.ORG Tue May 15 16:38:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E13221065674; Tue, 15 May 2012 16:38:51 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 5AA068FC17; Tue, 15 May 2012 16:38:51 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 9984FC4B2C; Tue, 15 May 2012 18:38:40 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id TkaZKmfC+lE9; Tue, 15 May 2012 18:38:39 +0200 (CEST) Received: from [10.0.0.22] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id BE14AC4B12; Tue, 15 May 2012 18:38:39 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Rafal Jaworowski In-Reply-To: <1CCD6DAD-5B3F-431C-8A5C-A9951408AC82@kientzle.com> Date: Tue, 15 May 2012 18:38:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <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> <1CCD6DAD-5B3F-431C-8A5C-A9951408AC82@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1084) Cc: arm@freebsd.org, freebsd-hackers@freebsd.org, Tim Kientzle , 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: Tue, 15 May 2012 16:38:52 -0000 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