[U-Boot] [PATCH 1/1] sandbox: dt: sandbox.dts set skip-localhost = <1>

Joe Hershberger joe.hershberger at ni.com
Tue Oct 16 04:42:54 UTC 2018


Hi Heinrich,

On Mon, Oct 15, 2018 at 7:20 PM Heinrich Schuchardt <xypron.glpk at 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 at 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 at 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 at 10002000 {
> >> --
> >> 2.19.1
> >>
> >> _______________________________________________
> >> U-Boot mailing list
> >> U-Boot at lists.denx.de
> >> https://lists.denx.de/listinfo/u-boot
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot


More information about the U-Boot mailing list