| #
2d221489 |
| 29-Nov-2016 |
Stefano Babic <sbabic@denx.de> |
Merge branch 'master' of git://git.denx.de/u-boot
Signed-off-by: Stefano Babic <sbabic@denx.de>
|
| #
9e40ea04 |
| 17-Nov-2016 |
Tom Rini <trini@konsulko.com> |
Merge tag 'signed-efi-next' of git://github.com/agraf/u-boot
Patch queue for efi - 2016-11-17
Highlights this time around:
- x86 efi_loader support - hello world efi test case - network devi
Merge tag 'signed-efi-next' of git://github.com/agraf/u-boot
Patch queue for efi - 2016-11-17
Highlights this time around:
- x86 efi_loader support - hello world efi test case - network device name is now representative - terminal output reports modes correctly - fix psci reset for ls1043/ls1046 - fix efi_add_runtime_mmio definition for x86 - efi_loader support for ls2080
show more ...
|
| #
58ad8628 |
| 07-Nov-2016 |
Simon Glass <sjg@chromium.org> |
x86: Enable EFI loader support
Enable this so that EFI applications (notably grub) can be run under U-Boot on x86 platforms.
At present the 'hello world' EFI application is not supported for the qe
x86: Enable EFI loader support
Enable this so that EFI applications (notably grub) can be run under U-Boot on x86 platforms.
At present the 'hello world' EFI application is not supported for the qemu-x86_efi_payload64 board. That board builds a payload consisting of a 64-bit header and a 32-bit U-Boot, which is incompatible with the way the EFI loader builds its EFI application. The following error is obtained:
x86_64-linux-ld.bfd: i386 architecture of input file `lib/efi_loader/helloworld.o' is incompatible with i386:x86-64 output
This could be corrected with additional Makefile rules. For now, this feature is disabled for that board.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> [agraf: drop hello kconfig bits] Signed-off-by: Alexander Graf <agraf@suse.de>
show more ...
|
| #
456ca6ba |
| 19-Oct-2016 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
efi_loader: fix depends on line of EFI_LOADER
This line is shown as
depends on (ARM64 ||\302\240ARM) && OF_LIBFDT
on my Emacs. Use ASCII characters only.
Assuming it is (ARM64 || ARM), remove
efi_loader: fix depends on line of EFI_LOADER
This line is shown as
depends on (ARM64 ||\302\240ARM) && OF_LIBFDT
on my Emacs. Use ASCII characters only.
Assuming it is (ARM64 || ARM), remove the redundancy. Unlike Linux, CONFIG_ARM includes CONFIG_ARM64 in U-Boot.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Alexander Graf <agraf@suse.de>
show more ...
|
| #
dc557e9a |
| 18-Jun-2016 |
Stefano Babic <sbabic@denx.de> |
Merge branch 'master' of git://git.denx.de/u-boot
Signed-off-by: Stefano Babic <sbabic@denx.de>
|
| #
51735ae0 |
| 11-May-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: Add bounce buffer support
Some hardware that is supported by U-Boot can not handle DMA above 32bits. For these systems, we need to come up with a way to expose the disk interface in a sa
efi_loader: Add bounce buffer support
Some hardware that is supported by U-Boot can not handle DMA above 32bits. For these systems, we need to come up with a way to expose the disk interface in a safe way.
This patch implements EFI specific bounce buffers. For non-EFI cases, this apparently was no issue so far, since we can just define our environment variables conveniently.
Signed-off-by: Alexander Graf <agraf@suse.de>
show more ...
|
| #
ed980b8c |
| 04-Mar-2016 |
Alexander Graf <agraf@suse.de> |
efi_loader: hook up in build environment
Now that we have all the bits and pieces ready for EFI payload loading support, hook them up in Makefiles and KConfigs so that we can build.
Signed-off-by:
efi_loader: hook up in build environment
Now that we have all the bits and pieces ready for EFI payload loading support, hook them up in Makefiles and KConfigs so that we can build.
Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> [trini: Enable only when we of OF_LIBFDT, disable on kwb and colibri_pxa270] Signed-off-by: Tom Rini <trini@konsulko.com>
show more ...
|