On Fri, Jun 23, 2017 at 4:24 PM, Rob Clark <robdcl...@gmail.com> wrote: > On Fri, Jun 23, 2017 at 10:32 AM, Tom Rini <tr...@konsulko.com> wrote: >> On Tue, Jun 20, 2017 at 05:55:25PM -0400, Rob Clark wrote: >> >>> Signed-off-by: Rob Clark <robdcl...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
