board/db410c: add missing linker map entries for efi
PATCH 1/2 board/db410c: add missing linker map entries for efi
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.
--- board/qualcomm/dragonboard410c/u-boot.lds | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
board/qualcomm/dragonboard410c/u-boot.lds +16 -0
@@ -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)
Signature · 1 line
2.9.4
PATCH 2/2 board/db410c: fix fdt address
---
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(-)
include/configs/dragonboard410c.h +1 -1
@@ -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" \
Signature · 1 line
2.9.4
PATCH 2/2 board/db410c: fix fdt address
Quoted 6 lines · Rob Clark
Signed-off-by Rob Clark <[email protected]>---
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 at0x81e00000. 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!
Signature · 8 lines
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>
PATCH 2/2 board/db410c: fix fdt address
Quoted 9 lines · Tom Rini
Quoted 6 lines · Rob Clark
Signed-off-by Rob Clark <[email protected]>---
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 at0x81e00000. 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.
Quoted 6 lines
I would assume that lk does what
Documentation/arm64/booting.txtdescribes and places the physical address in x0, so you might be able to implement asave_boot_paramsthat 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
PATCH 2/2 board/db410c: fix fdt address
Quoted 22 lines · Rob Clark
Quoted 9 lines · Tom Rini
Quoted 6 lines · Rob Clark
Signed-off-by Rob Clark <[email protected]>---
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 at0x81e00000. 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.Quoted 6 lines
I would assume that lk does what
Documentation/arm64/booting.txtdescribes and places the physical address in x0, so you might be able to implement asave_boot_paramsthat 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.
Quoted 8 lines
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
PATCH 2/2 board/db410c: fix fdt address
Quoted 31 lines · Rob Clark
Quoted 22 lines · Rob Clark
Quoted 9 lines · Tom Rini
Quoted 6 lines · Rob Clark
Signed-off-by Rob Clark <[email protected]>---
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 at0x81e00000. 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.Quoted 6 lines
I would assume that lk does what
Documentation/arm64/booting.txtdescribes and places the physical address in x0, so you might be able to implement asave_boot_paramsthat 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.Quoted 7 lines
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.
Quoted 1 line
(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!
Signature · 8 lines
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>
PATCH 1/2 board/db410c: add missing linker map entries for efi
In reply to Rob ClarkQuoted 5 lines · Rob Clark
Otherwise the loaded image would miss the
efi_runtimesections, and fall over hard when grub (for example) tried to call runtime services located in this section.Signed-off-by Rob Clark <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
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>