From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 27 03:44:13 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 49F28D5F for ; Tue, 27 Nov 2012 03:44:13 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id DDC128FC0C for ; Tue, 27 Nov 2012 03:44:12 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TdC5h-0009SK-Ut for freebsd-hackers@freebsd.org; Mon, 26 Nov 2012 19:44:11 -0800 Message-ID: <50B43708.2000902@bluezbox.com> Date: Mon, 26 Nov 2012 19:44:08 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: FreeBSD on RaspberryPi References: <31C904E6-F230-4187-AE32-F9A7B1A7C38E@freebsd.org> <4A5E03E5-3295-4FD4-9A06-7D1C4E9E0C12@freebsd.org> <9E4DA920-BE72-4AA0-8159-43205CDEF5CD@bluezbox.com> <1E75CEAC-32E8-4048-A1FB-DD59F996E22F@freebsd.org> <3CE258BC-0A80-428A-8535-D589C50ADA86@bluezbox.com> <5020FB83-6EAA-49D5-A533-ED127AF956AB@freebsd.org> In-Reply-To: <5020FB83-6EAA-49D5-A533-ED127AF956AB@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 11/26/2012 6:53 PM, Tim Kientzle wrote: > > This all sounds good then. > > So we can put the FreeBSD .dts file on the MSDOS Boot partition, then: > * Firmware will load it into memory and add display information. > * ? ubldr will access the FDT and add memory information and MAC address info ? [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 03:44:13 -0000 On 11/26/2012 6:53 PM, Tim Kientzle wrote: > > This all sounds good then. > > So we can put the FreeBSD .dts file on the MSDOS Boot partition, then: > * Firmware will load it into memory and add display information. > * ? ubldr will access the FDT and add memory information and MAC address info ? Memory is somewhat complicated. memory node contains whole range of memory 256 or 512 Mb The VideoCore part is passed as memreserve table. memreserve is not real property. It's got own API calls in libfdt and does not fit nicely with generic OF framework we have in FreeBSD. So I'm kind of on a fence here: either we need merge memory regions and memreserve in FDT fixup procedure in ubldr. Or convert memreserve data to valid property in ubldr again. Or add hack to arm/arm/machdep.c, which is not really good. > * Kernel will then load it and use it to initialize. > > Maybe another possibility would be to script ubldr and have it load the FDT from the correct location in memory. ubldr already knows how to load an FDT and how to pass that FDT to the kernel. ubldr loads FDT only from raw file or ELF kernel. We'll need "fdt addr" subcommand.But now you mentioned it, I think it might be worth adding it instead of compile-time option.