| Message ID | 20180423055950.78818-1-agraf@suse.de |
|---|---|
| Headers | show |
| Series | riscv: Enable efi_loader support | expand |
On 23.04.18 07:59, Alexander Graf wrote: > We now have RISC-V support in U-Boot - which is great! > > However, not that we're finally making progress to converge on > efi_loader and distro boot for booting on ARM platforms, we > really want to make sure there is no technical reason not to > do the same on RISC-V as well. > > So this patch set introduces distro boot and efi_loader support > for RISC-V! > > So far, I've only tested it with the selftest and hello world > target in U-Boot, as the number of target binaries to run is > still slim. But it should at least give us a good starting point. Rick, can this go into 2018.07? Via which tree do you want to push it? I can take it via the efi one or you can take it if you like ;). Alex
On Mon, Apr 23, 2018 at 07:59:42AM +0200, Alexander Graf wrote: > We now have RISC-V support in U-Boot - which is great! > > However, not that we're finally making progress to converge on > efi_loader and distro boot for booting on ARM platforms, we > really want to make sure there is no technical reason not to > do the same on RISC-V as well. > > So this patch set introduces distro boot and efi_loader support > for RISC-V! > > So far, I've only tested it with the selftest and hello world > target in U-Boot, as the number of target binaries to run is > still slim. But it should at least give us a good starting point. Any more comments from the RISC-V team? It would be great to have this in for v2018.07, thanks! -- Tom
> -----Original Message----- > From: Alexander Graf [mailto:agraf@suse.de] > Sent: Monday, May 07, 2018 4:59 AM > To: u-boot@lists.denx.de > Cc: Heinrich Schuchardt; schwab@suse.de; Greentime Hu; Rick Jian-Zhi Chen(陳 > 建志) > Subject: Re: [U-Boot] [PATCH v3 0/8] riscv: Enable efi_loader support > > > > On 23.04.18 07:59, Alexander Graf wrote: > > We now have RISC-V support in U-Boot - which is great! > > > > However, not that we're finally making progress to converge on > > efi_loader and distro boot for booting on ARM platforms, we really > > want to make sure there is no technical reason not to do the same on > > RISC-V as well. > > > > So this patch set introduces distro boot and efi_loader support for > > RISC-V! > > > > So far, I've only tested it with the selftest and hello world target > > in U-Boot, as the number of target binaries to run is still slim. But > > it should at least give us a good starting point. > > Rick, can this go into 2018.07? > > Via which tree do you want to push it? I can take it via the efi one or you can take > it if you like ;). > > Yes I prefer to u-boot-riscv.git If this can enter main line, I will fetch it I think you can take it via the efi one. :) But when I verify the efi flow this days. I find one issue and still clarify it now. I find the auto flow can not be disabled from make menuconfig Following are the experiments I do: Currently the boot flow will auto scan *.efi file from sd card and tftp server. If I do not insert sd card and tftp server caple. The boot message will as below: U-Boot 2018.03-00351-g1dd246f-dirty (Apr 23 2018 - 15:34:32 +0800) DRAM: 1 GiB No arch specific invalidate_icache_all available! MMC: Loading Environment from SPI Flash... SF: Detected mx25u1635e with page size 256 Bytes, erase size 4 KiB, total 2 MiB *** Warning - bad CRC, using default environment Failed (-5) In: serial@f0300000 Out: serial@f0300000 Err: serial@f0300000 Net: no alias for ethernet0 Warning: mac@e0100000 (eth0) using random MAC address - 66:7d:d7:be:c0:10 eth0: mac@e0100000 Hit any key to stop autoboot: 0 No MMC device available BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 BOOTP broadcast 6 BOOTP broadcast 7 BOOTP broadcast 8 BOOTP broadcast 9 BOOTP broadcast 10 BOOTP broadcast 11 BOOTP broadcast 12 BOOTP broadcast 13 BOOTP broadcast 14 BOOTP broadcast 15 BOOTP broadcast 16 BOOTP broadcast 17 Retry time exceeded; starting again BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 BOOTP broadcast 6 BOOTP broadcast 7 BOOTP broadcast 8 BOOTP broadcast 9 BOOTP broadcast 10 BOOTP broadcast 11 BOOTP broadcast 12 BOOTP broadcast 13 BOOTP broadcast 14 BOOTP broadcast 15 BOOTP broadcast 16 BOOTP broadcast 17 Retry time exceeded; starting again RISC-V # Then I think if I don't want enter this auto flow, what can I do ? 1 Remove CONFIG_DISTRO_DEFAULTS=y from nx25-ae250_defconfig But it still enter auto flow. 2 Add #ifdef CONFIG_DISTRO_DEFAULTS to encapsulate the CONFIG_EXTRA_ENV_SETTINGS in nx25-ae250.h And Remove CONFIG_DISTRO_DEFAULTS=y from nx25-ae250_defconfig And it will NOT enter auto flow #ifdef CONFIG_DISTRO_DEFAULTS /* Enable distro boot */ #define BOOT_TARGET_DEVICES(func) \ func(MMC, mmc, 0) \ func(DHCP, dhcp, na) #include <config_distro_bootcmd.h> #define CONFIG_EXTRA_ENV_SETTINGS \ "kernel_addr_r=0x00080000\0" \ "pxefile_addr_r=0x01f00000\0" \ "scriptaddr=0x01f00000\0" \ "fdt_addr_r=0x02000000\0" \ "ramdisk_addr_r=0x02800000\0" \ BOOTENV #endif 3 Add #ifdef CONFIG_DISTRO_DEFAULTS to encapsulate the CONFIG_EXTRA_ENV_SETTINGS in nx25-ae250.h And do NOT Remove CONFIG_DISTRO_DEFAULTS=y from nx25-ae250_defconfig But disable CONFIG_DISTRO_DEFAULTS from make menuconfig General setup ---> [ ] Select defaults suitable for booting general purpose Linux distributions And it still enter auto flow Offering this information for you. Rick > Alex CONFIDENTIALITY NOTICE: This e-mail (and its attachments) may contain confidential and legally privileged information or information protected from disclosure. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein is strictly prohibited. In this case, please immediately notify the sender by return e-mail, delete the message (and any accompanying documents) and destroy all printed hard copies. Thank you for your cooperation. Copyright ANDES TECHNOLOGY CORPORATION - All Rights Reserved.
> -----Original Message----- > From: Tom Rini [mailto:trini@konsulko.com] > Sent: Monday, May 07, 2018 5:12 AM > To: Alexander Graf; Rick Jian-Zhi Chen(陳建志); Greentime Hu > Cc: u-boot@lists.denx.de; Heinrich Schuchardt; schwab@suse.de > Subject: Re: [U-Boot] [PATCH v3 0/8] riscv: Enable efi_loader support > > On Mon, Apr 23, 2018 at 07:59:42AM +0200, Alexander Graf wrote: > > > We now have RISC-V support in U-Boot - which is great! > > > > However, not that we're finally making progress to converge on > > efi_loader and distro boot for booting on ARM platforms, we really > > want to make sure there is no technical reason not to do the same on > > RISC-V as well. > > > > So this patch set introduces distro boot and efi_loader support for > > RISC-V! > > > > So far, I've only tested it with the selftest and hello world target > > in U-Boot, as the number of target binaries to run is still slim. But > > it should at least give us a good starting point. > > Any more comments from the RISC-V team? It would be great to have this in > for v2018.07, thanks! > Hi Tom I am also happy to have this in. And I have some responses to Alex. :) Rick > -- > Tom CONFIDENTIALITY NOTICE: This e-mail (and its attachments) may contain confidential and legally privileged information or information protected from disclosure. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein is strictly prohibited. In this case, please immediately notify the sender by return e-mail, delete the message (and any accompanying documents) and destroy all printed hard copies. Thank you for your cooperation. Copyright ANDES TECHNOLOGY CORPORATION - All Rights Reserved.
On 07.05.18 04:13, rick@andestech.com wrote: > > >> -----Original Message----- >> From: Alexander Graf [mailto:agraf@suse.de] >> Sent: Monday, May 07, 2018 4:59 AM >> To: u-boot@lists.denx.de >> Cc: Heinrich Schuchardt; schwab@suse.de; Greentime Hu; Rick Jian-Zhi Chen(陳 >> 建志) >> Subject: Re: [U-Boot] [PATCH v3 0/8] riscv: Enable efi_loader support >> >> >> >> On 23.04.18 07:59, Alexander Graf wrote: >>> We now have RISC-V support in U-Boot - which is great! >>> >>> However, not that we're finally making progress to converge on >>> efi_loader and distro boot for booting on ARM platforms, we really >>> want to make sure there is no technical reason not to do the same on >>> RISC-V as well. >>> >>> So this patch set introduces distro boot and efi_loader support for >>> RISC-V! >>> >>> So far, I've only tested it with the selftest and hello world target >>> in U-Boot, as the number of target binaries to run is still slim. But >>> it should at least give us a good starting point. >> >> Rick, can this go into 2018.07? >> >> Via which tree do you want to push it? I can take it via the efi one or you can take >> it if you like ;). >> >> > > Yes > I prefer to u-boot-riscv.git > If this can enter main line, I will fetch it > I think you can take it via the efi one. :) > > > But when I verify the efi flow this days. > I find one issue and still clarify it now. > > I find the auto flow can not be disabled from make menuconfig > Following are the experiments I do: > > Currently the boot flow will auto scan *.efi file from sd card and tftp server. > If I do not insert sd card and tftp server caple. > > The boot message will as below: > > U-Boot 2018.03-00351-g1dd246f-dirty (Apr 23 2018 - 15:34:32 +0800) > > DRAM: 1 GiB > No arch specific invalidate_icache_all available! > MMC: > Loading Environment from SPI Flash... SF: Detected mx25u1635e with page size 256 Bytes, erase size 4 KiB, total 2 MiB > *** Warning - bad CRC, using default environment > > Failed (-5) > In: serial@f0300000 > Out: serial@f0300000 > Err: serial@f0300000 > Net: no alias for ethernet0 > > Warning: mac@e0100000 (eth0) using random MAC address - 66:7d:d7:be:c0:10 > eth0: mac@e0100000 > Hit any key to stop autoboot: 0 > No MMC device available > BOOTP broadcast 1 > BOOTP broadcast 2 > BOOTP broadcast 3 > BOOTP broadcast 4 > BOOTP broadcast 5 > BOOTP broadcast 6 > BOOTP broadcast 7 > BOOTP broadcast 8 > BOOTP broadcast 9 > BOOTP broadcast 10 > BOOTP broadcast 11 > BOOTP broadcast 12 > BOOTP broadcast 13 > BOOTP broadcast 14 > BOOTP broadcast 15 > BOOTP broadcast 16 > BOOTP broadcast 17 > > Retry time exceeded; starting again > BOOTP broadcast 1 > BOOTP broadcast 2 > BOOTP broadcast 3 > BOOTP broadcast 4 > BOOTP broadcast 5 > BOOTP broadcast 6 > BOOTP broadcast 7 > BOOTP broadcast 8 > BOOTP broadcast 9 > BOOTP broadcast 10 > BOOTP broadcast 11 > BOOTP broadcast 12 > BOOTP broadcast 13 > BOOTP broadcast 14 > BOOTP broadcast 15 > BOOTP broadcast 16 > BOOTP broadcast 17 > > Retry time exceeded; starting again > RISC-V # > > > Then I think if I don't want enter this auto flow, what can I do ? > > 1 Remove CONFIG_DISTRO_DEFAULTS=y from nx25-ae250_defconfig > But it still enter auto flow. > > 2 Add #ifdef CONFIG_DISTRO_DEFAULTS to encapsulate the CONFIG_EXTRA_ENV_SETTINGS in nx25-ae250.h > And Remove CONFIG_DISTRO_DEFAULTS=y from nx25-ae250_defconfig > And it will NOT enter auto flow > > #ifdef CONFIG_DISTRO_DEFAULTS > /* Enable distro boot */ > #define BOOT_TARGET_DEVICES(func) \ > func(MMC, mmc, 0) \ > func(DHCP, dhcp, na) > > #include <config_distro_bootcmd.h> > > #define CONFIG_EXTRA_ENV_SETTINGS \ > "kernel_addr_r=0x00080000\0" \ > "pxefile_addr_r=0x01f00000\0" \ > "scriptaddr=0x01f00000\0" \ > "fdt_addr_r=0x02000000\0" \ > "ramdisk_addr_r=0x02800000\0" \ > BOOTENV > #endif > > 3 Add #ifdef CONFIG_DISTRO_DEFAULTS to encapsulate the CONFIG_EXTRA_ENV_SETTINGS in nx25-ae250.h > And do NOT Remove CONFIG_DISTRO_DEFAULTS=y from nx25-ae250_defconfig > But disable CONFIG_DISTRO_DEFAULTS from make menuconfig > General setup ---> > [ ] Select defaults suitable for booting general purpose Linux distributions > And it still enter auto flow > > Offering this information for you. This is the same for all distro enabled boards. The basic idea is that U-Boot ships with something that "just boots" for simple use cases. If you want something more advanced, you usually want to put something very target specific in there anyway, such as "bootm $nor_flash". In that case, you adapt the CONFIG_BOOTCOMMAND parameter to whatever you want. The boot command can also be overridden using the environment. So if you have working environment store, you can change the U-Boot variable "bootcmd" and U-Boot will run that instead when it boots. The alternative to this default behavior would be no bootcmd at all which means you just get dropped into the U-Boot prompt. While that's reasonably useful for developers, it isn't for people deploying U-Boot on real target systems :). Alex