From owner-freebsd-embedded@FreeBSD.ORG Wed Nov 28 22:15:29 2012 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F51FC03; Wed, 28 Nov 2012 22:15:29 +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 1CE978FC13; Wed, 28 Nov 2012 22:15:28 +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 1Tdpue-000AGY-Je; Wed, 28 Nov 2012 14:15:26 -0800 Message-ID: <50B68CFA.80208@bluezbox.com> Date: Wed, 28 Nov 2012 14:15:22 -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: Rafal Jaworowski Subject: Re: FDT code fixes for ubldr References: <50B54AB7.8080301@bluezbox.com> In-Reply-To: <50B54AB7.8080301@bluezbox.com> 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/27/2012 3:20 PM, Oleksandr Tymoshenko wrote: > Hi guys, > > Here is a patch for FDT support in ubldr: > http://people.freebsd.org/~gonzo/patches/fdt.diff > Reviews are appreciated > > I also plan to add merge of memreserve and memory regions as a part of > memory fixup process. > > Changes: > - Implement "fdt mres" sub-command that prints reserved memory regions > - Add "fdt addr" subcommand that lets you specify preloaded blob address > - Do not pre-initialize blob for "fdt addr" > - Do not try to load dtb every time fdt subcommand is issued, > do it only once > - Change the way DTB is passed to kernel. With introduction of "fdt addr" > actual blob address can be not virtual but physical or reside in > area higher then 64Mb. ubldr should create copy of it in kernel area > and pass pointer to this newly allocated buffer which is > guaranteed to work > in kernel after switching on MMU. > [...] 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] Cc: arm@freebsd.org, Tim Kientzle , embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 22:15:29 -0000 On 11/27/2012 3:20 PM, Oleksandr Tymoshenko wrote: > Hi guys, > > Here is a patch for FDT support in ubldr: > http://people.freebsd.org/~gonzo/patches/fdt.diff > Reviews are appreciated > > I also plan to add merge of memreserve and memory regions as a part of > memory fixup process. > > Changes: > - Implement "fdt mres" sub-command that prints reserved memory regions > - Add "fdt addr" subcommand that lets you specify preloaded blob address > - Do not pre-initialize blob for "fdt addr" > - Do not try to load dtb every time fdt subcommand is issued, > do it only once > - Change the way DTB is passed to kernel. With introduction of "fdt addr" > actual blob address can be not virtual but physical or reside in > area higher then 64Mb. ubldr should create copy of it in kernel area > and pass pointer to this newly allocated buffer which is > guaranteed to work > in kernel after switching on MMU. > New version of this patch: http://people.freebsd.org/~gonzo/patches/fdt-memreserve.diff Additional changes: - Convert memreserv FDT info to memreserv property of root node - Handle memreserv property in initarm: exclude these regions from available memory regions With these changes I was able to boot Raspberry Pi with all hardware-specific data set correctly by firmware. If there are not objections, I'd like to commit it ASAP.