[U-Boot] [PATCH 1/2] board/db410c: add missing linker map entries for efi

[U-Boot] [PATCH 1/2] board/db410c: add missing linker map entries for efi

[Rob Clark]

Otherwise the loaded image would miss the efi_runtime sections, and fall
over hard when grub (for example) tried to call runtime services located
in this section.

Signed-off-by: Rob Clark <robdclark@gmail.com>
---
 board/qualcomm/dragonboard410c/u-boot.lds | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/board/qualcomm/dragonboard410c/u-boot.lds b/board/qualcomm/dragonboard410c/u-boot.lds
index 6e1c5a8..62ac4d7 100644
--- a/board/qualcomm/dragonboard410c/u-boot.lds
+++ b/board/qualcomm/dragonboard410c/u-boot.lds
@@ -43,6 +43,22 @@ SECTIONS
 
 	. = ALIGN(8);
 
+	.efi_runtime : {
+                __efi_runtime_start = .;
+		*(efi_runtime_text)
+		*(efi_runtime_data)
+                __efi_runtime_stop = .;
+	}
+
+	.efi_runtime_rel : {
+                __efi_runtime_rel_start = .;
+		*(.relaefi_runtime_text)
+		*(.relaefi_runtime_data)
+                __efi_runtime_rel_stop = .;
+	}
+
+	. = ALIGN(8);
+
 	.image_copy_end :
 	{
 		*(.__image_copy_end)
-- 
2.9.4

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

[Rob Clark]

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.

 include/configs/dragonboard410c.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/dragonboard410c.h b/include/configs/dragonboard410c.h
index 11c842d..3b9932d 100644
--- a/include/configs/dragonboard410c.h
+++ b/include/configs/dragonboard410c.h
@@ -105,7 +105,7 @@ REFLASH(dragonboard/u-boot.img, 8)\
 	"linux_image=Image\0" \
 	"kernel_addr_r=0x81000000\0"\
 	"fdtfile=apq8016-sbc.dtb\0" \
-	"fdt_addr_r=0x83000000\0"\
+	"fdt_addr_r=0x81e00000\0"\
 	"ramdisk_addr_r=0x84000000\0"\
 	"scriptaddr=0x90000000\0"\
 	"pxefile_addr_r=0x90100000\0"\
-- 
2.9.4

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

[Tom Rini]

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!

-- 
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/6aee73c0/attachment.sig>

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

[Rob Clark]

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.

BR,
-R

[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@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)

BR,
-R

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

[Tom Rini]

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>

[U-Boot] [U-Boot, 1/2] board/db410c: add missing linker map entries for efi

[Tom Rini]

On Tue, Jun 20, 2017 at 05:55:24PM -0400, Rob Clark wrote:

> Otherwise the loaded image would miss the efi_runtime sections, and fall
> over hard when grub (for example) tried to call runtime services located
> in this section.
> 
> Signed-off-by: Rob Clark <robdclark@gmail.com>

Applied to u-boot/master, 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/20170624/dc6ed228/attachment.sig>