In need of a tour guide... For U-boot.

My goal is to insert the RTL8152 driver (which is the USB NIC for my JTX1) into U-boot.
This is because I want to PXE boot however during U-boot “ethernet is not found”.
I looked through the source files for U-boot /driver/net, and I found RTL8138 and RTL8169 but no RTL8152.
As I surfed the web I found a driver for RTL8152.c which I’m hoping to add to U-boot, so my question is how do I go about doing that?

I currently have the U-boot sources files downloaded.
What I really want to know how the U-boot source files work.
Where do I use the “make” command.
How does it build? Do i have to specify the board type, architecture and so on?

Extra information:
Board name: p2371-2180

Thanks in advance.

I was searching through previous forums and found these set of commands for building u-boot from source.

export ARCH=arm64
export CROSS_COMPILE=/usr/bin/aarch64-linux-gnu-
make distclean
make p2371-2180_defconfig
make

I got a bit confused looking at the makes files.
Once I execute the commands above do I just flash u-boot from emmc?

There is documentation related to this. Go here:
https://developer.nvidia.com/embedded/linux-tegra

Click on the “Documentation” download. Find “U-Boot Guide” listed in the top level index.html (when you unpack somewhere point your browser at “file:///where/ever/the/docs/are/index.html”). This should answer some of your questions.

One thing to look at ahead of time is if the 8152 file you found was bare metal or not…if that file is from a kernel driver it probably won’t be of much help (or at least not as directly as you’re looking for). If the file is from u-boot on another embedded system it will probably help a lot.

Well I believe it is bare metal since it does have code dealing with registers etc.
The first 20 or so lines of the driver code is below. I hope these are libraries that i can use.
It was a driver that was extracted from someone’s etherboot u-boot folder…
#include <linux/signal.h>
#include <linux/slab.h>
#include <linux/module.h>
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
#include <linux/mii.h>
#include <linux/ethtool.h>
#include <linux/usb.h>
#include <linux/crc32.h>
#include <linux/if_vlan.h>
#include <linux/uaccess.h>
#include <linux/list.h>
#include <linux/ip.h>
#include <linux/ipv6.h>
#include <net/ip6_checksum.h>
#include <uapi/linux/mdio.h>
#include <linux/mdio.h>
#include <linux/usb/cdc.h>
#include <linux/suspend.h>
#include <linux/acpi.h>

/* Information for net-next */
#define NETNEXT_VERSION “08”

/* Information for net */
#define NET_VERSION “6”

#define DRIVER_VERSION “v1.” NETNEXT_VERSION “.” NET_VERSION
#define DRIVER_AUTHOR “Realtek linux nic maintainers nic_swsd@realtek.com
#define DRIVER_DESC “Realtek RTL8152/RTL8153 Based USB Ethernet Adapters”
#define MODULENAME “r8152”

Yeah I was looking at that documentation previously and I got stuck at the first part with ./source.sync part, then I realized I needed to be in root…

That’s a kernel driver (several kernel hardware drivers have asm). I say this because the include files imply kernel functions. You won’t find “linux/slab.h”, “linux/signal.h”, so on. It’s truly bare metal.

One thing I’ve been meaning to ask but never got around to…could someone from nVidia make the JTX1 u-boot defconfig available? The current u-boot source has only “configs/jetson-tk1_defconfig”, and jetson-tx1_defconfig is needed (specifically I think the dev kit would be P2371-2180 even though L4T on the devkit names “tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb” in extlinux.conf before transferring control over to the kernel). I doubt the jtk1 defconfig setup is correct for this case.

Well I read through some forums and the config file can be found in the P2371-2180 folder. Interestingly they named JTK1 but not JTX1, instead that used that code.

Also does that mean that I need to look for a new driver?
I really thought there would be a driver already available for RTL8152 since this USB NIC should be installed on most TX1s…

Also after reflashing my Linux_4_Tegra folder disappeared so I can’t use source_sync.sh. When I go sudo-i, then ls theres nothing in the root folder…
Do you know what might have happened?

I found this as well. I’m not sure if this is bare metal but it seems like there was discussion for this driver.
http://u-boot.10912.n7.nabble.com/PATCH-1-2-checkpatch-ignore-request-to-use-ether-addr-copy-td234605.html

You will need to find a bare metal driver. Many NICs work in the Linux kernel, but not at boot loader stage. This is one of the reasons I suggest finding an inexpensive USB NIC already supported in u-boot.

The Linux_for_Tegra folder should not disappear. Perhaps the source_sync.sh was with the wrong options? I’ve not heard of that happening before.

That URL you mentioned is talking about a warning when compiling an ethernet driver which exists both for the kernel and u-boot; the warning was being removed when compiled for u-boot because the warning was irrelevant in those circumstances. This referred to one specific function. I don’t know which driver used that function, but possibly many drivers do (or just one).

Okay I found the drivers thanks to a previous post.
http://git.denx.de/?p=u-boot/u-boot-tegra.git;a=tree;f=drivers/usb/eth;h=c76d6a887e04e9abf52023c05f750a8b94bc7e17;hb=HEAD
I’m trying to download the files using git
git clone git://git.denx.de/<project_name> <your_repository_name>/
What does your repos name mean? And where can i find it?
I tried looking at the old U-boot source files for previous L4T packages but I have no luck there is as well…

It seems the git repo subdivides content by project name and repo name…custom to them. I don’t know anything about that repo.

Looks like if you go to the top level in a web browser you get some info:
http://git.denx.de

Then if you click on the u-boot link (project name), you’ll at least be part way where you want to be:
http://git.denx.de/?p=u-boot.git;a=summary

I would only be able to guess that after this either the armv8 or ARM64 descriptions apply (sorry, I am not able to read in German).

Just FYI, the mainline u-boot is not likely to contain all of the customizations that the board support of L4T’s distributed u-boot contains. Although you might find a driver in the mainline you’d still need to back port it to the L4T version of u-boot.

Would it be backporting if the driver was extracted from a L4T version of U-boot.
This is where I got the information.
https://devtalk.nvidia.com/default/topic/962946/?comment=4968417
Actually I did what you told me and I found that it supports p2371-2180. Is there a way to just flash this u-boot over the current u-boot? I think this U-boot has all the adequate files to get the TX1 running.

With the other solution you recommended, buying a support NIC. The problem with that is, I’m dealing with about 20 or more TX1s. The PXE boot is supposed to be use with Foreman to mass flash the TX1s. So it is not ideal to buy 20 NICs.

Lastly the source_sync.sh didn’t disappear, I misreported. Basically, when I went into the root directory there was a folder called Linux_for_tegra. However, After re flashing the TX1 I no longer have the folder so yeah, its something that I will have to investigate later.

I’m not where I can look at source right now, but if the driver is in L4T, it’s just a config and no porting needed. Set up for build, then run “make menuconfig” and you should be able to see drivers.

I don’t know if flashing one u-boot over the other would work. It’s possible, but if something like size differed, things might fail. You can clone your root partition first before trying something risky.

Network booting might be convenient, but to some degree flashing with a clone image might be just as useful. Clone images can be loopback mounted, and don’t you need USB in recovery mode anyway?

Sorry I got lost in your terminology, I understand clone image but what does it mean to be loopback mounted. Is it possible to set up in Foreman? e.g. could I use this technique to flash multiple boards at one time?

Yeah I tried changing the configuration but I dont understand how to say “y” to my configuration. You said use the command make menuconfig but I get the following errors.

ubuntu@tegra-ubuntu:~/Linux_for_Tegra/sources/u-boot_source$ make menuconfig

HOSTCC scripts/kconfig/mconf.o
In file included from scripts/kconfig/mconf.c:23:0:
scripts/kconfig/lxdialog/dialog.h:38:20: fatal error: curses.h: No such file or directory
compilation terminated.
scripts/Makefile.host:108: recipe for target ‘scripts/kconfig/mconf.o’ failed
make[1]: *** [scripts/kconfig/mconf.o] Error 1
Makefile:475: recipe for target ‘menuconfig’ failed
make: *** [menuconfig] Error 2

Am i doing it in the wrong directory?

This is in the Kconfig.


menuconfig NETDEVICES
bool “Network device support”
depends on NET
default y if DM_ETH
help
You must select Y to enable any network device support
Generally if you have any networking support this is a given

  If unsure, say Y

Regarding loopback, every hard drive has a device special file from which it is manipulated or mounted; a driver covering a physical hard drive is how those device special files are created. Any device special file with an API for accepting block device manipulation works with hard disk commands. Loopback is just a way to “fake” block devices based on non-disk blocks of data. A file on the file system is such a block of data, and covering it with loopback generates a device special file which the operating system cannot distinguish from a real disk. Your file can then be formatted, partitioned, mounted, read, navigated, written, fsck’d, so on.

During flash loopback covers an empty file of the exact size of your entire target Jetson root file system. The loopback device special file is formatted ext4, mounted, and then gets a recursive copy of the rootfs subdirectory (with perhaps some boot files depending on options during flash). It is this file which is transferred as an ordinary stream of file bytes onto the Jetson (which puts those bytes directly on the Jetson without any processing…the fact that those bytes together have an ext4 file system is how rootfs becomes an exact match to what the Jetson gets).

If you clone the root partition on Jetson, you get a file. If you flash that file back to Jetson with the “reuse” option ("-r"), then nothing changes…you backed up your Jetson with clone, you restored it with the clone which is an exact match. However, on your host, you could have loopback mounted that file, edited something like network address, a serial number, and host name, and then flashed it…and that would then be the image the Jetson has (only those loopback mounted edits would differ from what it had been).

Clone takes significant time but is worthwhile. It’s an incredible safety device in case of losing a Jetson. That image, while on the host, can also be updated via rsync or any other backup mechanism. When I’m interested in keeping an image I typically clone, followed by rsync if I update something like “apt-get upgrade” (I see if the upgrade works, and if it does, I rsync…which is faster than a full clone). After I’ve updated too much I generate a new/clean clone and start over.

In the original flash.sh there was no such thing as compressing the root partition image. The uncompressed “raw” image was created as “bootloader/system.img” in the Linux_for_Tegra subdirectory. Later on, to speed things up (15GB over USB2 is slow), flash began moving system.img to system.img.raw, and then instead populated system.img via system.img.raw compression. It isn’t really any complicated compression, it’s what’s called a sparse image, sort of a very simple way of sending fewer bytes. flash.sh, when it uses the “-r” reuse option does not modify or create a new system.img, nor system.img.raw. If you place the uncompressed clone in place of system.img it works perfectly.

Clones and edits to clones are a very good way to do things in mass production. Keep in mind that if a clone was intended for R24.2 but some of the original Jetson is R23.1 there might be issues from just restoring a root partition…something might not match. You could use a command line tool directly without the flash.sh script, and exactly that one partition would be flashed. If you use flash.sh with reuse option then the other files are also flashed and you shouldn’t run into that issue.

More explanation of cloning is here (this is for the JTK1, but mostly this applies):
http://elinux.org/Jetson/Cloning

More specific information for the JTX1:
https://devtalk.nvidia.com/default/topic/898999/jetson-tx1/tx1-r23-1-new-flash-structure-how-to-clone-/post/4784149/#4784149
http://elinux.org/Jetson/TX1_Cloning

For loopback, see “man losetup”. There should be an example of its use in the man page, plus lots of online examples. Do keep in mind that although non-root can use loopback, only root can create a loopback device ("/dev/loop*" might already exist, or might require automatic increment if a new loop device needs to be created…automatic increment will inform non-root what device it is, but will not create it…root would automatically create such a device without special steps).

One can cover a file with loopback, or remove loopback cover of a file already covered. Be sure to not generate an infinite list of loopback files. Check “ls /dev/loop*” for “loop0, loop1, loop2…” to see how generation and removal work.

Incidentally, “ifconfig” for network shows device “lo”, which is a loopback device pretending to be an ethernet device so local networking succeeds even if there is no network card.

Very informative, I’ll look more into it.
It seems like it will take a lot of time moving around a clone from one device to another though.

Anyways do you have any response to my other post about the make menuconfig problem?

Thanks.

Well I ended up adding the configuration to p2371-2180defconfig file so I hope that’s correct.
I just have one last problem, whilst running the flash script it looks for the rootfs folder.
However, I do not have a rootfs folder, rather all the contents are in the my computer (’/’) directory. I tried moving the folders into a rootfs folder that I made however moving folders such as “bin” gives me a message saying the device is being used. Anyway to work around it?

One thing about menuconfig is that it requires the ncurses devel package. I think on Ubuntu it is listed as “libncurses5-dev”. See if this helps with the make menuconfig issue.

I’m confused by what you mean about moving everything to ‘/’. Are you talking about on your x86_64 desktop host, or on a running Jetson? If you are talking about the driver package, then you will have a Linux_for_Tegra directory and within that the rootfs can be repopulated at any time (just make sure you use the sudo ./apply_binaries.sh as well).

Okay so I flashed my board using Jetpack, when I start it up I don’t have a folder called Linux_for_Tegra. So inside the Linux_for_Tegra folder there is a rootfs folder however everything that is supposed to be inside the rootfs folder is on my root folder.

When you installed L4T you are supposed to extract the sample root folders from the website into rootfs then run sudo ./apply_binaries.sh as you mentioned. However all my folders such as bin, dev, lib etc are in my computer directory.

When you say it will repopulate do you mean that once I run ./apply_binaries.sh it will move all the folders in my computer to Linux_for_tegra. My worry is that I will pretty much have two sets of rootfs and it might corrupt something.

Sorry my explanation is a mess, its kinda hard without showing you.