Message ID | 20200729154235.90766-1-xypron.glpk@gmx.de |
---|---|
Headers | show |
Series | efi_selftest: allow UEFI testing on MAIX | expand |
On 29.07.20 17:42, Heinrich Schuchardt wrote: > For RISC-V testing on real hardware the Sipeed MAIX boards provides an > affordable solution. > > UEFI testing fails on the MAIX BiT with Mic because the UEFI sub-system > reserves 16 MiB for the stack though the board only has 8 MiB. > > The first two patches make the size of the memory reserved for the stack > customizable on all boards defaulting to 16 MiB. > > The value on the the MAIX BiT with Mic is set to 1 MiB. > > Missing default load addresses for the MAIX BiT with Mic are added. > > The sysreset driver is fixed to output the full reset message. > > The UEFI network and block device unit tests are only built if the > configuration provides the prerequisites. > > > Heinrich Schuchardt (6): > efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system > configs: reduce stack size of Sipeed MAIX > riscv: load addresses for Sipeed MAIX > dm: sysreset: wait after reset message > efi_selftest: SNP test depends on network > efi_selftest: block device test requires CONFIG_DOS_PARTITION This patch is prerequisite for the series: https://lists.denx.de/pipermail/u-boot/2020-July/421925.html x86: rename CONFIG_STACK_SIZE Best regards Heinrich > > Kconfig | 10 ++++++++++ > arch/arm/Kconfig | 17 ----------------- > arch/microblaze/Kconfig | 8 -------- > configs/sipeed_maix_bitm_defconfig | 1 + > drivers/sysreset/sysreset-uclass.c | 1 + > include/configs/sipeed-maix.h | 9 +++++++++ > lib/efi_loader/efi_memory.c | 2 +- > lib/efi_selftest/Kconfig | 2 ++ > lib/efi_selftest/Makefile | 5 +++-- > 9 files changed, 27 insertions(+), 28 deletions(-) > > -- > 2.27.0 >
On 7/29/20 11:42 AM, Heinrich Schuchardt wrote: > For RISC-V testing on real hardware the Sipeed MAIX boards provides an > affordable solution. > > UEFI testing fails on the MAIX BiT with Mic because the UEFI sub-system > reserves 16 MiB for the stack though the board only has 8 MiB. > > The first two patches make the size of the memory reserved for the stack > customizable on all boards defaulting to 16 MiB. > > The value on the the MAIX BiT with Mic is set to 1 MiB. > > Missing default load addresses for the MAIX BiT with Mic are added. > > The sysreset driver is fixed to output the full reset message. > > The UEFI network and block device unit tests are only built if the > configuration provides the prerequisites. > > > Heinrich Schuchardt (6): > efi_loader: use CONFIG_STACK_SIZE in the UEFI sub-system > configs: reduce stack size of Sipeed MAIX > riscv: load addresses for Sipeed MAIX > dm: sysreset: wait after reset message > efi_selftest: SNP test depends on network > efi_selftest: block device test requires CONFIG_DOS_PARTITION > > Kconfig | 10 ++++++++++ > arch/arm/Kconfig | 17 ----------------- > arch/microblaze/Kconfig | 8 -------- > configs/sipeed_maix_bitm_defconfig | 1 + > drivers/sysreset/sysreset-uclass.c | 1 + > include/configs/sipeed-maix.h | 9 +++++++++ > lib/efi_loader/efi_memory.c | 2 +- > lib/efi_selftest/Kconfig | 2 ++ > lib/efi_selftest/Makefile | 5 +++-- > 9 files changed, 27 insertions(+), 28 deletions(-) > > -- > 2.27.0 When testing this series, after completing the self test the board does not reset automatically, even after pressing a key. Here is an (abbreviated) log => bootefi selftest Testing EFI API implementation Number of tests to execute: 32 <snip> Summary: 0 failures Preparing for reset. Press any key... And after this I need to manually reset the board. Running the reset command from within the U-Boot shell works fine. Is this intended behavior? In addition, the self test changes the default terminal colors and does not change them back. This is most noticeable when using a terminal which does not default to white text on a black background. As an example, I have configured my terminal to use black text on a white background in [1]. However, once the test has completed, the terminal colors are not returned to their defaults [2]. (in this example, I manually reset the board). Is this expected behavior? [1] https://imgur.com/AUuVLFI.png [2] https://imgur.com/6YGtK9n.png --Sean