From owner-freebsd-arm@FreeBSD.ORG Sun May 13 07:24:46 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5B0B1065670; Sun, 13 May 2012 07:24:46 +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 6F81B8FC08; Sun, 13 May 2012 07:24:45 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q4D7HLRv079525; Sun, 13 May 2012 07:17:21 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id af4meg9v63azpsdbvu9kdk27tn; Sun, 13 May 2012 07:17:21 +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: Date: Sun, 13 May 2012 00:17:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <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> To: Tim Kientzle X-Mailer: Apple Mail (2.1257) Cc: arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: How does loader(8) decide where to load the kernel? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 07:24:46 -0000 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. 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. So now I need to understand how to copyin() the blob back into the kernel address space. 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. 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. Is there already something like this? Tim