diff mbox

[U-Boot,2/2] Enable PXE boot on meson-gxbb.

Message ID 20170416220133.31043-3-vagrant@debian.org
State Superseded
Delegated to: Minkyu Kang
Headers show

Commit Message

Vagrant Cascadian April 16, 2017, 10:01 p.m. UTC
Enable distro_bootcmd PXE functions on meson-gxbb systems.

While DHCP boot is already supported, the format is fairly u-boot
specific, while PXE boot supports the widely used syslinux style boot
configuration format.

Signed-off-by: Vagrant Cascadian <vagrant@debian.org>
---

 include/configs/meson-gxbb-common.h | 1 +
 1 file changed, 1 insertion(+)

Comments

Andreas Färber April 16, 2017, 10:04 p.m. UTC | #1
Am 17.04.2017 um 00:01 schrieb Vagrant Cascadian:
> Enable distro_bootcmd PXE functions on meson-gxbb systems.
> 
> While DHCP boot is already supported, the format is fairly u-boot
> specific, while PXE boot supports the widely used syslinux style boot
> configuration format.
> 
> Signed-off-by: Vagrant Cascadian <vagrant@debian.org>
> ---
> 
>  include/configs/meson-gxbb-common.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/configs/meson-gxbb-common.h b/include/configs/meson-gxbb-common.h
> index c3229ea2cf..0339feaed9 100644
> --- a/include/configs/meson-gxbb-common.h
> +++ b/include/configs/meson-gxbb-common.h
> @@ -41,6 +41,7 @@
>  #define BOOT_TARGET_DEVICES(func) \
>  	func(MMC, mmc, 0) \
>  	func(MMC, mmc, 1) \
> +	func(PXE, pxe, na) \
>  	func(DHCP, dhcp, na)
>  
>  #include <config_distro_bootcmd.h>

This should go after DHCP as discussed a while ago.
PXE has a lengthy list of fallbacks and I fail to see what is U-Boot
specific about DHCP.

Regards,
Andreas
Vagrant Cascadian April 17, 2017, 10:26 p.m. UTC | #2
On 2017-04-16, Andreas Färber wrote:
> Am 17.04.2017 um 00:01 schrieb Vagrant Cascadian:
>> Enable distro_bootcmd PXE functions on meson-gxbb systems.
>> 
>> While DHCP boot is already supported, the format is fairly u-boot
>> specific, while PXE boot supports the widely used syslinux style boot
>> configuration format.
...
>> diff --git a/include/configs/meson-gxbb-common.h b/include/configs/meson-gxbb-common.h
>> index c3229ea2cf..0339feaed9 100644
>> --- a/include/configs/meson-gxbb-common.h
>> +++ b/include/configs/meson-gxbb-common.h
>> @@ -41,6 +41,7 @@
>>  #define BOOT_TARGET_DEVICES(func) \
>>  	func(MMC, mmc, 0) \
>>  	func(MMC, mmc, 1) \
>> +	func(PXE, pxe, na) \
>>  	func(DHCP, dhcp, na)
>>  
>>  #include <config_distro_bootcmd.h>
>
> This should go after DHCP as discussed a while ago.

Apologies, I'm not subscribed to the list and must have missed that
discussion.


> PXE has a lengthy list of fallbacks and I fail to see what is U-Boot
> specific about DHCP.

DHCP the protocol is not at all u-boot specific, sure, but the boot
method:

#define BOOTENV_DEV_DHCP(devtypeu, devtypel, instance) \
	"bootcmd_dhcp=" \
		BOOTENV_RUN_NET_USB_START \
		BOOTENV_RUN_NET_PCI_ENUM \
		"if dhcp ${scriptaddr} ${boot_script_dhcp}; then " \
			"source ${scriptaddr}; " \
		"fi;" \
		BOOTENV_EFI_RUN_DHCP \
		"\0"

I guess I was referring to "source ${scriptaddr}; " line, which is quite
u-boot specific. I didn't realize that "DHCP" also had support for EFI
loaded over the network.

It seems unforunate that the EFI network boot is only a fallback to
loading a boot script over the network, as boot scripts and EFI boot
seem to me like two unrelated features.

When loading from MMC, I think the order goes something like EFI,
extlinux, u-boot boot scripts. With the current implementation, it
appears a similar ordering is not possible with general cases of network
boot. Which kind of reduces the consistancy for config_distro_bootcmd
for different boot methods. Hrm.

That said, I'm fine to resubmit the patch to put PXE boot after DHCP
boot...


live well,
  vagrant
Andreas Färber April 17, 2017, 10:42 p.m. UTC | #3
Am 18.04.2017 um 00:26 schrieb Vagrant Cascadian:
> DHCP the protocol is not at all u-boot specific, sure, but the boot
> method:
> 
> #define BOOTENV_DEV_DHCP(devtypeu, devtypel, instance) \
> 	"bootcmd_dhcp=" \
> 		BOOTENV_RUN_NET_USB_START \
> 		BOOTENV_RUN_NET_PCI_ENUM \
> 		"if dhcp ${scriptaddr} ${boot_script_dhcp}; then " \
> 			"source ${scriptaddr}; " \
> 		"fi;" \
> 		BOOTENV_EFI_RUN_DHCP \
> 		"\0"
> 
> I guess I was referring to "source ${scriptaddr}; " line, which is quite
> u-boot specific. I didn't realize that "DHCP" also had support for EFI
> loaded over the network.

DHCP just sets a filename that we can then load. What differs is where
it gets loaded and what gets done with it next.

> It seems unforunate that the EFI network boot is only a fallback to
> loading a boot script over the network, as boot scripts and EFI boot
> seem to me like two unrelated features.
> 
> When loading from MMC, I think the order goes something like EFI,
> extlinux, u-boot boot scripts.

Nope, boot.scr goes before EFI also in the MMC case. That way I can have
a boot.scr script on SD that applies overlays with fdt apply and then
calls bootefi manually. And if anything goes wrong with the overlay, a
simple exit from the GRUB prompt still boots me into a working system
via the default EFI boot.

Cheers,
Andreas
Vagrant Cascadian April 17, 2017, 11:05 p.m. UTC | #4
On 2017-04-17, Andreas Färber wrote:
> Am 18.04.2017 um 00:26 schrieb Vagrant Cascadian:
>> I guess I was referring to "source ${scriptaddr}; " line, which is quite
>> u-boot specific. I didn't realize that "DHCP" also had support for EFI
>> loaded over the network.
>
> DHCP just sets a filename that we can then load. What differs is where
> it gets loaded and what gets done with it next.

Sure, I see that.


>> It seems unforunate that the EFI network boot is only a fallback to
>> loading a boot script over the network, as boot scripts and EFI boot
>> seem to me like two unrelated features.
>> 
>> When loading from MMC, I think the order goes something like EFI,
>> extlinux, u-boot boot scripts.
>
> Nope, boot.scr goes before EFI also in the MMC case. That way I can have
> a boot.scr script on SD that applies overlays with fdt apply and then
> calls bootefi manually. And if anything goes wrong with the overlay, a
> simple exit from the GRUB prompt still boots me into a working system
> via the default EFI boot.

But not before the exlinux configuration in config_distro_bootcmd.h:

    "scan_dev_for_boot="                                              \
        "echo Scanning ${devtype} "                               \
                "${devnum}:${distro_bootpart}...; "       \
        "for prefix in ${boot_prefixes}; do "                     \
            "run scan_dev_for_extlinux; "                     \
            "run scan_dev_for_scripts; "                      \
        "done;"                                                   \
        SCAN_DEV_FOR_EFI                                          \

This loads the extlinux configuration before the boot scripts, and I'm
fairly sure that was intentional.

To me, the PXE boot is similar to the extlinux support; it loads the
same style configuration file, only one is over the network and one over
local media. To me, this looks like an inconsistancy in network boot
vs. local media boot with the order of which type of files are used to
boot.

Admittedly, the PXE boot method loads from so many fallback
locations it can be quite annoying.

Maybe I'm rehashing arguments already decided, and if so, perhaps these
should be documented in README.distro so there's a reference to point
to?


live well,
  vagrant
Andreas Färber May 1, 2017, 4:56 p.m. UTC | #5
Am 17.04.2017 um 00:04 schrieb Andreas Färber:
> Am 17.04.2017 um 00:01 schrieb Vagrant Cascadian:
>> Enable distro_bootcmd PXE functions on meson-gxbb systems.
>>
>> While DHCP boot is already supported, the format is fairly u-boot
>> specific, while PXE boot supports the widely used syslinux style boot
>> configuration format.
>>
>> Signed-off-by: Vagrant Cascadian <vagrant@debian.org>
>> ---
>>
>>  include/configs/meson-gxbb-common.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/include/configs/meson-gxbb-common.h b/include/configs/meson-gxbb-common.h
>> index c3229ea2cf..0339feaed9 100644
>> --- a/include/configs/meson-gxbb-common.h
>> +++ b/include/configs/meson-gxbb-common.h
>> @@ -41,6 +41,7 @@
>>  #define BOOT_TARGET_DEVICES(func) \
>>  	func(MMC, mmc, 0) \
>>  	func(MMC, mmc, 1) \
>> +	func(PXE, pxe, na) \
>>  	func(DHCP, dhcp, na)
>>  
>>  #include <config_distro_bootcmd.h>
> 
> This should go after DHCP as discussed a while ago.

MMC distro boot has now been merged, so you could rebase.

Somehow I do not see replies to your previous suggestion in January,
where I thought Alex and others had commented on it (we did discuss that
somewhere...), and checking

git grep -C 1 "func(PXE" -- include/configs/

indeed all boards that do enable PXE have it before DHCP, although there
are quite a few that have DHCP only:

git grep -C 1 "func(DHCP" -- include/configs/

So I won't object to you adding it here, but my concerns about the
timeouts incurred by the per-byte config fallbacks still remain.

Regards,
Andreas
diff mbox

Patch

diff --git a/include/configs/meson-gxbb-common.h b/include/configs/meson-gxbb-common.h
index c3229ea2cf..0339feaed9 100644
--- a/include/configs/meson-gxbb-common.h
+++ b/include/configs/meson-gxbb-common.h
@@ -41,6 +41,7 @@ 
 #define BOOT_TARGET_DEVICES(func) \
 	func(MMC, mmc, 0) \
 	func(MMC, mmc, 1) \
+	func(PXE, pxe, na) \
 	func(DHCP, dhcp, na)
 
 #include <config_distro_bootcmd.h>