From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [U-Boot,2/2] board/db410c: fix fdt address
Date: Fri, 23 Jun 2017 17:17:52 -0400 [thread overview]
Message-ID: <20170623211752.GL27196@bill-the-cat> (raw)
In-Reply-To: <CAF6AEGtos99xY=OQhLcEmqn5ZwrvMyz_xs852qTHa2T=_uqPPw@mail.gmail.com>
On Fri, Jun 23, 2017 at 04:35:43PM -0400, Rob Clark wrote:
> On Fri, Jun 23, 2017 at 4:24 PM, Rob Clark <robdclark@gmail.com> wrote:
> > On Fri, Jun 23, 2017 at 10:32 AM, Tom Rini <trini@konsulko.com> wrote:
> >> On Tue, Jun 20, 2017 at 05:55:25PM -0400, Rob Clark wrote:
> >>
> >>> Signed-off-by: Rob Clark <robdclark@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)
OK, cool. I'll move 2/2 to Rejected and 1/2 is currently in my testing
queue today. Thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170623/56261f57/attachment.sig>
next prev parent reply other threads:[~2017-06-23 21:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-20 21:55 [U-Boot] [PATCH 1/2] board/db410c: add missing linker map entries for efi Rob Clark
2017-06-20 21:55 ` [U-Boot] [PATCH 2/2] board/db410c: fix fdt address Rob Clark
2017-06-23 14:32 ` [U-Boot] [U-Boot,2/2] " Tom Rini
2017-06-23 20:24 ` Rob Clark
2017-06-23 20:35 ` Rob Clark
2017-06-23 21:17 ` Tom Rini [this message]
2017-06-24 22:17 ` [U-Boot] [U-Boot, 1/2] board/db410c: add missing linker map entries for efi Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170623211752.GL27196@bill-the-cat \
--to=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox