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>