[U-Boot] [U-Boot,2/2] board/db410c: fix fdt address

[Rob Clark]

On Fri, Jun 23, 2017 at 4:24 PM, Rob Clark <robdclark at gmail.com> wrote:
> On Fri, Jun 23, 2017 at 10:32 AM, Tom Rini <trini at konsulko.com> wrote:
>> On Tue, Jun 20, 2017 at 05:55:25PM -0400, Rob Clark wrote:
>>
>>> Signed-off-by: Rob Clark <robdclark at gmail.com>
>>> ---
>>> Maybe there is a better way to not hardcode this?  But at least with
>>> the build of lk that I have, the fdt table is at 0x81e00000.  I guess
>>> there must be a more robust way to do this, since presumably lk when
>>> booting the linux kernel directly somehow passes the fdt address.
>>
>> I would assume that lk does what Documentation/arm64/booting.txt
>> describes and places the physical address in x0, so you might be able to
>> implement a save_boot_params that saves this information for later use?
>> Perhaps even make this somewhat generic for armv8 as there's probably
>> other cases where U-Boot is being called in this manner?  Thanks!
>>
>
> yup.. figured this out.. I have a WIP patch to actually use the fdt
> that the fw passes to u-boot (instead of appending the fdt to
> u-boot).. haven't wired it up to setenv_hex() yet, but that should be
> trivial.
>
> fwiw, I have a WIP u-boot equiv to linux's simplefb display driver
> that can inherit the scanout setup by fw (and some related patches)
> plus lk patches to create a chosen/framebuffer simple-framebuffer
> node.. need to clean up and send out some of my pending stack of
> patches, but been buried in figuring out u-boot reloc stuff to figure
> out how to not get the vaddr space associated w/ fw configured
> framebuffer reloc'd.
>

(and just in-case that wasn't clear, ignore patch 2/2.. but 1/2 is still valid)

BR,
-R