Dear Expert,
we are working on tegra186-p2771 uboot, and we had installed a pcie ethernet card( Broadcom tigonIII ), and we had completed driver implementation, however, when entering into tx2 uboot prompt, its default ethact is “ethernet@2490000”, however, we want to change it to our tigonIII ethernet card instead.
could you teach us how to do that ?
and our uboot dts/dtsi are as attached
Thanks a lot and Best regards,
Bryant Wu
tegra186.zip (3.69 KB)
Are you trying to make this NIC available within U-Boot for network boot load? Or does the NIC only need to be available once in Linux?
If you need this during U-Boot, then you’ll have to provide a driver within U-Boot (which is similar to the Linux driver, but not the same). Using the NIC once in Linux is usually just a case of making sure the driver exists, and then setting up user space software.
Dear Expert,
yes, we are trying to make this NIC available within U-Boot for network boot load, otherwise, we had completed the driver and built it in, however, when we try “ping” under u-boot, it will use default ethact to ping, and the default ethact is defined in tegra186.dtsi( node ethernet@2490000 ), but it is not the NIC we want, could you teach us how to add our pcie NIC node in tegra186.dtsi ?
Thanks a lot and Best regards,
Bryant Wu
I have not attempted to build a driver for U-Boot, but at minimum this is what you will have to do. You essentially have one operating system (U-Boot is a micro operating environment) which overwrites itself with another (Linux). In some cases the hardware for ethernet has to keep continuity of service as U-Boot overwrites itself with Linux. This is truly bare metal programming, so you may find you have to do a few things not normally required within the Linux kernel (e.g., allocating memory for local variables), but mostly the driver will be the same as a Linux driver.
The next question becomes whether you are simply providing a kernel and pre-boot environment (such as device tree), or if you are attempting to also serve the file system once Linux takes over. Presenting a kernel from a remote source has fewer requirements than also presenting a remote ext4 or nfs file system…the former (kernel image only) does not require continuity of service from U-Boot to the point it overwrites itself with Linux, but the latter (rootfs serving) requires continuity of service between U-Boot and the time it self-overwrites with Linux.
One thing which complicates this is that more recent releases have placed device tree content into a partition for use by CBoot and stages prior to U-Boot. Those stages may edit content before passing on to U-Boot. Thus if your pre-boot environment does not require anything which previous stages have available in eMMC your likelihood of success goes up (e.g., if you are just loading a kernel it shouldn’t be too difficult). Should you need to provide parts of device tree which earlier stages have use for, then life is going to get complicated. I don’t know of any way to provide an ethernet driver for network boot in any stage prior to U-Boot. So you should carefully answer these questions: What content do you have which must be network served? Kernel? Device tree? If device tree, what part? File system? Does the ethernet driver have to retain continuity of service when going from U-Boot to Linux?
Should you be requiring rootfs served over ethernet, then for the driver in Linux, you will have to make sure the driver is integrated and not module format (else an initrd is required, but this will greatly complicate your life). Anything causing the hardware to stop/start (such as resetting for a new driver or driver configuration) will break serving rootfs.
Dear Expert,
Thank you so much,
our Nic card can work in linux, but cannot work under u-boot,
if we want to use pcie Nic card under uboot, could you show us how to modify tegra186-p2771’s uboot’s dts files ?
Thanks a lot and Best regards,
Bryant Wu
That’s something I can’t help with. U-Boot is its own operating system…it isn’t Linux and Linux hasn’t even run yet. If you put the driver in Linux, then you still need a new driver in U-Boot and that can’t be avoided. The device tree changes help set up a driver to use the hardware, but the driver itself is actually separate. You could point the device tree at the hardware, but the hardware would remain inert. Device tree plus driver are the magic combination which works together, but neither works by itself. The only observation which I can make is that the Linux driver will be quite similar to what goes into U-Boot, but won’t be an exact copy.
Someone else here may be able to give some pointers on porting a Linux ethernet driver to U-Boot.
Dear Expert,
Thank you so much,
we had completed u-boot Nic card driver, uboot Nic card driver is ok now.
however, the dts file in u-boot also need to be modified at the same time,
could you teach us how to modify dts files ?
Thanks a lot and Best regards,
Bryant Wu
I can’t give you a specific answer, so instead I’m listing how to get started on the question. U-Boot build is described in documentation listed below, along with some information on how to find the particular file you are interested in.
Within the “Linux_for_Tegra/” directory, which is from the driver package (and which JetPack downloads and runs as a frontend), is “source_sync.sh”. This script allows downloading various “tags”, one of which is U-Boot source. Assuming as an example R28.2.1 (adjust for your version), the U-Boot source is this:
./source_sync.sh -u tegra-l4t-r28.2.1
(kernel is “-k” instead of “-u” and may be useful as well…some configuration is shared among these)
Documentation can be found here:
https://developer.nvidia.com/embedded/downloads
In particular (assuming R28.2 or R28.2.1):
https://developer.nvidia.com/embedded/dlc/l4t-documentation-28-2-ga
Within that is a “U-Boot Customization” section. I can’t help much beyond that, the device tree configuration and usage has changed in more recent releases. At this point some of the earlier boot stages use the device tree from a partition, and then pass along device tree either verbatim or edited, and I’m not sure what to tell you on that. So while I can tell you about configuration within U-Boot, I can’t be sure that I know the correct method to actually put your changes into the TX2 (you probably want to save a log of a command line flash, and then go over that for bootloader content). It may be that you need to edit the device tree while building U-Boot, and additionally within the device tree which flashes separately to a partition. Don’t know :(
About actual U-Boot configuration and build within the “u-boot/” code found after using “source_sync.sh”…extra info because others will probably be looking for help too…
Note that in the “u-boot/configs/” subdirectory there are several “_defconfig” files named after either the module or the carrier board (or both). Via “egrep -i -l ‘tegra.18.’” I see:
p2371-2180_defconfig
p2771-0000-000_defconfig
p2771-0000-500_defconfig
(the “18” is for the Tegra 18x series, where the 186 is specifically the Jetson TX2’s SoC)
The docs will actually tell you to use “p2771-0000-500” for a TX2/TX2i.
If I search in the “u-boot/” directory like this I find the relevant device tree:
> find . -name '*p2771-0000-500*'
<i><b>./arch/arm/dts/tegra186-p2771-0000-500.dts</b></i>
The particular _defconfig you want before starting the build:
<i><b>configs/p2771-0000-500_defconfig</b></i>
In this case, within the _defconfig, I see:
CONFIG_DEFAULT_DEVICE_TREE="tegra186-p2771-0000-500"
If you were to edit “arch/arm/dts/tegra210-p2371-2180.dts”, then use the “p2771-0000-500_defconfig” configuration, you should get what you are looking for.
About the particular edit…
I can’t tell you what you need within U-Boot, but it is probably the same as from the running Jetson where your network adapter is available once Linux boots. Right now it sounds like you have adjusted the device tree and drivers to work within Linux, but not yet within U-Boot…this means you probably need to transfer those same edits.
There may be additional edits if power rails need to go on, if DMA needs to be accounted for (the SMMU won’t be running in U-Boot), so on.