FDT code fixes for ubldr
Warner Losh
imp at bsdimp.com
Wed Nov 28 22:24:28 UTC 2012
On Nov 28, 2012, at 3:15 PM, Oleksandr Tymoshenko wrote:
> 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.
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
More information about the freebsd-embedded
mailing list