Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Nov 2012 15:24:21 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Oleksandr Tymoshenko <gonzo@bluezbox.com>
Cc:        arm@freebsd.org, embedded@freebsd.org, Tim Kientzle <tim@kientzle.com>
Subject:   Re: FDT code fixes for ubldr
Message-ID:  <E4F9D680-FEBB-4894-A70A-2C795FE14431@bsdimp.com>
In-Reply-To: <50B68CFA.80208@bluezbox.com>
References:  <50B54AB7.8080301@bluezbox.com> <50B68CFA.80208@bluezbox.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Nov 28, 2012, at 3:15 PM, Oleksandr Tymoshenko wrote:

> On 11/27/2012 3:20 PM, Oleksandr Tymoshenko wrote:
>> Hi guys,
>>=20
>> Here is a patch for FDT support in ubldr:
>> http://people.freebsd.org/~gonzo/patches/fdt.diff
>> Reviews are appreciated
>>=20
>> I also plan to add merge of memreserve and memory regions as a part =
of memory fixup process.
>>=20
>> 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.
>>=20
>=20
> New version of this patch:
> http://people.freebsd.org/~gonzo/patches/fdt-memreserve.diff
>=20
> Additional changes:
>=20
> - Convert memreserv FDT info to memreserv property of root node
> - Handle memreserv property in initarm: exclude these regions from =
available memory regions
>=20
> 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.

Nothing horrible is leaping out at me. Please do.

On a related note: any plans to have the ability to merge new =
nodes/change nodes from the loader? I know this doesn't make sense in =
the NAND environment so much, but makes a lot more sense for the SD =
environment when you may wish to monkey with the command line, or =
disable devices, or even load a set of nodes that describe some new =
custom hardware, perhaps conditionally...

Warner




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E4F9D680-FEBB-4894-A70A-2C795FE14431>