[U-Boot] [PATCH 1/1] sandbox: dt: sandbox.dts set skip-localhost = <1>
The local interface is not usable for many network operations. It has been disabled in all sandbox device trees except sandbox.dts. Let's disable it here too.
'bootefi selftest' tries to do execute DHCP. This fails on the lo device.
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de --- arch/sandbox/dts/sandbox.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts index fb866e8807..e0990352fb 100644 --- a/arch/sandbox/dts/sandbox.dts +++ b/arch/sandbox/dts/sandbox.dts @@ -49,7 +49,7 @@
ethrawbus { compatible = "sandbox,eth-raw-bus"; - skip-localhost = <0>; + skip-localhost = <1>; };
eth@10002000 {
On Sun, Oct 14, 2018 at 2:27 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
The local interface is not usable for many network operations. It has been disabled in all sandbox device trees except sandbox.dts. Let's disable it here too.
'bootefi selftest' tries to do execute DHCP. This fails on the lo device.
Shouldn't the tests be using test.dts? This is for hand testing, where it can be available, and people can use it or not by specifying ethact.
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
arch/sandbox/dts/sandbox.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts index fb866e8807..e0990352fb 100644 --- a/arch/sandbox/dts/sandbox.dts +++ b/arch/sandbox/dts/sandbox.dts @@ -49,7 +49,7 @@
ethrawbus { compatible = "sandbox,eth-raw-bus";
skip-localhost = <0>;
skip-localhost = <1>; }; eth@10002000 {-- 2.19.1
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
On 10/15/2018 11:52 PM, Joe Hershberger wrote:
On Sun, Oct 14, 2018 at 2:27 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
The local interface is not usable for many network operations. It has been disabled in all sandbox device trees except sandbox.dts. Let's disable it here too.
'bootefi selftest' tries to do execute DHCP. This fails on the lo device.
Shouldn't the tests be using test.dts?
bootefi selftest is a command inside U-Boot. It does not choose a device tree.
This is for hand testing, where
it can be available, and people can use it or not by specifying ethact.
make sandbox_defconfig make ./u-boot -D
uses sandbox.dts.
For all other sandbox*.dts we also set skip-localhost=1. Why should sandbox_dts be inconsistent with those?
Why would I want to use the cloned local interface?
board/sandbox/README.sandbox does not even mention test.dts. The only reference is in a Python test, see tools/binman/ftest.py.
The network devices defined in test.dts do not allow to access the real world. So why should I use it?
Best regards
Heinrich
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
arch/sandbox/dts/sandbox.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts index fb866e8807..e0990352fb 100644 --- a/arch/sandbox/dts/sandbox.dts +++ b/arch/sandbox/dts/sandbox.dts @@ -49,7 +49,7 @@
ethrawbus { compatible = "sandbox,eth-raw-bus";
skip-localhost = <0>;
skip-localhost = <1>; }; eth@10002000 {-- 2.19.1
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Hi Heinrich,
On Mon, Oct 15, 2018 at 7:20 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 10/15/2018 11:52 PM, Joe Hershberger wrote:
On Sun, Oct 14, 2018 at 2:27 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
The local interface is not usable for many network operations. It has been disabled in all sandbox device trees except sandbox.dts. Let's disable it here too.
'bootefi selftest' tries to do execute DHCP. This fails on the lo device.
Shouldn't the tests be using test.dts?
bootefi selftest is a command inside U-Boot. It does not choose a device tree.
This is for hand testing, where
it can be available, and people can use it or not by specifying ethact.
make sandbox_defconfig make ./u-boot -D
uses sandbox.dts.
Sure... and ./u-boot -d test/dm/test.dtb uses that device tree. Or any other you choose to build.
For all other sandbox*.dts we also set skip-localhost=1. Why should sandbox_dts be inconsistent with those?
The only one that I may consider inconsistent is sandbox64.dts (I assume that is what you mean when you say "all other", you are talking about this one file, right?), and I'm not sure where it's used. I've never used it that I remember. Unless it's magically picked somehow based on something environmental.
You seem to think that if you don't force the local interface to not show up that you have to use it. Instead you can just set the ethact U-Boot environment variable to the appropriate interface you want to use, and off you go.
Why would I want to use the cloned local interface?
So that you could test against, for instance, a TFTP server on your host machine.
board/sandbox/README.sandbox does not even mention test.dts. The only reference is in a Python test, see tools/binman/ftest.py.
You'll notice the message in test/dm/test-main.c that claims the requirement to use test.dts.
The network devices defined in test.dts do not allow to access the real world. So why should I use it?
Again, that is for the dm unit tests, not hand testing.
Cheers, -Joe
Best regards
Heinrich
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
arch/sandbox/dts/sandbox.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts index fb866e8807..e0990352fb 100644 --- a/arch/sandbox/dts/sandbox.dts +++ b/arch/sandbox/dts/sandbox.dts @@ -49,7 +49,7 @@
ethrawbus { compatible = "sandbox,eth-raw-bus";
skip-localhost = <0>;
skip-localhost = <1>; }; eth@10002000 {-- 2.19.1
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
On 10/16/2018 06:42 AM, Joe Hershberger wrote:
Hi Heinrich,
On Mon, Oct 15, 2018 at 7:20 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 10/15/2018 11:52 PM, Joe Hershberger wrote:
On Sun, Oct 14, 2018 at 2:27 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
The local interface is not usable for many network operations. It has been disabled in all sandbox device trees except sandbox.dts. Let's disable it here too.
'bootefi selftest' tries to do execute DHCP. This fails on the lo device.
Shouldn't the tests be using test.dts?
bootefi selftest is a command inside U-Boot. It does not choose a device tree.
This is for hand testing, where
it can be available, and people can use it or not by specifying ethact.
make sandbox_defconfig make ./u-boot -D
uses sandbox.dts.
Sure... and ./u-boot -d test/dm/test.dtb uses that device tree. Or any other you choose to build.
For all other sandbox*.dts we also set skip-localhost=1. Why should sandbox_dts be inconsistent with those?
The only one that I may consider inconsistent is sandbox64.dts (I assume that is what you mean when you say "all other", you are talking about this one file, right?), and I'm not sure where it's used. I've never used it that I remember. Unless it's magically picked somehow based on something environmental.
You seem to think that if you don't force the local interface to not show up that you have to use it. Instead you can just set the ethact U-Boot environment variable to the appropriate interface you want to use, and off you go.
Why would I want to use the cloned local interface?
So that you could test against, for instance, a TFTP server on your host machine.
board/sandbox/README.sandbox does not even mention test.dts. The only reference is in a Python test, see tools/binman/ftest.py.
You'll notice the message in test/dm/test-main.c that claims the requirement to use test.dts.
The network devices defined in test.dts do not allow to access the real world. So why should I use it?
Again, that is for the dm unit tests, not hand testing.
Cheers, -Joe
Thanks Joe for your valuable feedback.
I have set the patch to rejected.
Best regards
Heinrich
On Tue, Oct 16, 2018 at 11:23 AM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 10/16/2018 06:42 AM, Joe Hershberger wrote:
Hi Heinrich,
On Mon, Oct 15, 2018 at 7:20 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 10/15/2018 11:52 PM, Joe Hershberger wrote:
On Sun, Oct 14, 2018 at 2:27 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
The local interface is not usable for many network operations. It has been disabled in all sandbox device trees except sandbox.dts. Let's disable it here too.
'bootefi selftest' tries to do execute DHCP. This fails on the lo device.
Shouldn't the tests be using test.dts?
bootefi selftest is a command inside U-Boot. It does not choose a device tree.
Is this added to be used with sandbox or to be used with a real board or both?
I'm guessing this works fine if you set ethact appropriately first, right?
This is for hand testing, where
it can be available, and people can use it or not by specifying ethact.
make sandbox_defconfig make ./u-boot -D
uses sandbox.dts.
Sure... and ./u-boot -d test/dm/test.dtb uses that device tree. Or any other you choose to build.
For all other sandbox*.dts we also set skip-localhost=1. Why should sandbox_dts be inconsistent with those?
The only one that I may consider inconsistent is sandbox64.dts (I assume that is what you mean when you say "all other", you are talking about this one file, right?), and I'm not sure where it's used. I've never used it that I remember. Unless it's magically picked somehow based on something environmental.
You seem to think that if you don't force the local interface to not show up that you have to use it. Instead you can just set the ethact U-Boot environment variable to the appropriate interface you want to use, and off you go.
Why would I want to use the cloned local interface?
So that you could test against, for instance, a TFTP server on your host machine.
board/sandbox/README.sandbox does not even mention test.dts. The only reference is in a Python test, see tools/binman/ftest.py.
You'll notice the message in test/dm/test-main.c that claims the requirement to use test.dts.
The network devices defined in test.dts do not allow to access the real world. So why should I use it?
Again, that is for the dm unit tests, not hand testing.
Cheers, -Joe
Thanks Joe for your valuable feedback.
No problem. I hope you're able to make your use-case work.
I have set the patch to rejected.
Thanks.
-Joe
Best regards
Heinrich _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
participants (2)
-
Heinrich Schuchardt -
Joe Hershberger