How to add eth1 to test device tree?

[Simon Glass]

+Tom Rini +Heinrich Schuchardt too

Hi Ehsan,

On Wed, 29 Mar 2023 at 04:15, Ehsan Mohandesi <emohandesi at microsoft.com> wrote:
>
> Hi Simon,
>
> > -----Original Message-----
> > From: Simon Glass <sjg at chromium.org>
> > Sent: Monday, March 27, 2023 3:15 PM
> > To: Ehsan Mohandesi <emohandesi at linux.microsoft.com>
> > Cc: u-boot at lists.denx.de; swarren at nvidia.com; michal.simek at xilinx.com;
> > guillaume.gardet at free.fr
> > Subject: [EXTERNAL] Re: How to add eth1 to test device tree?
> >
> > Hi Ehsan,
> >
> > On Tue, 28 Mar 2023 at 08:58, Ehsan Mohandesi
> > <emohandesi at linux.microsoft.com> wrote:
> > >
> > > Hi All,
> > >
> > > When running the sandbox tests, I want to know how to enable eth1 in
> > > order to be able to test network features.
> > >
> > > The following command is used to run sandbox tests.
> > >
> > > ./test/py/test.py -k testname.py
> > >
> > > I am specifically interested in running the network tests.
> > >
> > > ./test/py/test.py -k test_net.py
> > >
> > > These Python tests use test.dts device tree which does not have eth1
> > > in it. I can replace the test.dts file with sandbox.dts to enable eth1
> > > and run the network tests; however, I think there should be a better
> > > way to do it.
> > >
> > > Can anyone help me with this issue?
> > >
> > > When running U-Boot, the -T option could be used to tell it to use the
> > > test.dts or -D to use sandbox.dts; however, there is no such option
> > > when running test.py.
> > >
> > > Eth1 is needed in order to enable the network. Enabling the sandbox
> > > network is explained after line 250 in doc/arch/sandbox.rst.
> > >
> > > For more information, the following is the list of network interfaces
> > > when each device tree is used.
> > >
> > > **
> > >
> > > *arch/sandbox/dts/sandbox.dts**
> > > *Net:   eth0: host_lo, *eth1: host_eth0*, eth2: host_br1, eth3: eth at 10002000
> > >
> > > *arch/sandbox/dts/test.dts*
> > >
> > > Net:   eth0: eth at 10002000, eth5: eth at 10003000, eth3: sbe5, eth6:
> > > eth at 10004000, eth4: dsa-test-eth, eth2: lan0, eth7: lan1
> > >
> >
> > You should write tests in C where possible. See [1].
> >
> > If you are just trying to try something out locally, then you can run a sandbox
> > test without Python. See [2]. You can use the -D flag as usual. Of course you
> > can't
> >
> > Network tests should generate their own traffic and check it internally, rather
> > than relying on the real network features of the host machine. You can see
> > test/dm/eth.c for that
> >
> > For local hacking you can change u_boot_console_sandbox.py.get_spawn()
> > to pass -D instead of the -d xxx it currently does.
> >
> > So it depends on what you are trying to do.
> >
> > Regards,
> > Simon
> >
> > [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fu-
> > boot.readthedocs.io%2Fen%2Flatest%2Fdevelop%2Ftests_writing.html&data=0
> > 5%7C01%7Cemohandesi%40microsoft.com%7Ccb2205b7fa56490d6b0008db2ef
> > ff21e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63815544908078
> > 1196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> > iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qi8G4i64eXd
> > S4VpzMz9F5LL3BcEh0C87%2BvsTBg4IRic%3D&reserved=0
> > [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fu-
> > boot.readthedocs.io%2Fen%2Flatest%2Fdevelop%2Ftests_sandbox.html%23run
> > ning-sandbox-tests-
> > directly&data=05%7C01%7Cemohandesi%40microsoft.com%7Ccb2205b7fa564
> > 90d6b0008db2efff21e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
> > 638155449080781196%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
> > data=YiBTpwZ4sjvKAu9H%2B4%2BBGFJUjoe3zT5pERDtBA5oDms%3D&reserved
> > =0
>
> Let me add a little bit of information on my change and how I want to test it.
> I have implemented the IPv6 network discovery and have sent it upstream. Now I am working on writing the sandbox tests. I have implemented some tests in C and one in Python when using C was not possible.
> Tests written in C are in test/dm/eth.c and they use fake networks as you have instructed.
> Test written in Python is in test/py/tests/test_net.py. The Python test is similar to the DHCP and TFTP tests where they deal with real network traffic. My question is how those tests succeed. Do they use eth1? For them to succeed, they need to be connected to a DHCP server or other servers. How do the users run such tests?

OK I understand now. There is a u-boot-test-hooks repo [1] which
provides these details, as they are specific to the environment you
are using. For example, in
'travis-ci/u_boot_boardenv_qemu_x86_64_na.py' you will see:

import os
import travis_tftp

env__net_uses_pci = True
env__net_dhcp_server = True
env__net_tftp_readable_file = travis_tftp.file2env('u-boot')
env__efi_loader_helloworld_file =
travis_tftp.file2env('lib/efi_loader/helloworld.efi')
env__efi_loader_check_smbios = True
env__efi_loader_grub_file = travis_tftp.file2env('grub_x64.efi')
env__efi_fit_tftp_file = {
    "dn" : os.environ['UBOOT_TRAVIS_BUILD_DIR'],
}

This sets up some environment vars which are read by the test in conftest.py

You can see an example that uses USB ethernet in the swarren-lx1 directory.

Note that these tests use 'real' boards, not sandbox. That's because
we don't have emulation of a TFTP server, etc. in sandbox, at least so
far. They do run in CI, e.g. see qemu-x86_64, and you can run them
locally, either by setting up the test hooks, or by manually running
qemu with suitable args taken from conf.qemu-x86_64_na for example.

Regards,
Simon

[1] https://source.denx.de/u-boot/u-boot-test-hooks