HI！
I would like to ask a question: In jetsonnano development board, the host can be pinged through in the application layer, but after entering Uboot, ip, gateway, subnet mask, service ip and pci enum are set. After a device is activated by the pci command, the ping host cannot be pinged. (The host and Jetson nano development board are in the same network segment, and the host has closed the firewall).But the results keep showing up: ARP Retry count exceeded; starting again, Is there any way to solve it?
Thanks.
Hi,
Currently, the JetsonNano connects directly to the computer via a network cable. In the Uboot state of JetsonNano, you only want to ping the host address and perform file transfer such as TFTP.
I’m sorry if that’s not clear. Thanks.
Is there something specific you want to work? Just to emphasize what @DaneLLL mentioned before, networking is not supported in the bootloader of the Nano. The bootloader is its own miniature operating system, and the driver is not set up to support this. Once the Linux kernel is loaded, that story changes. Are you trying to work with networking in the boot stages, or instead once Linux loads? There is a big difference there due to the presence or lack of drivers in the two stages.
Currently, the main board of Jetson Nano is connected to the laptop through network cable.
I’m thinking of ping the laptop’s network under JetsonNano’s uboot command during the boot phase (using UBoot). Finally, the bare computer program is written and run through Trivial File Transfer Protocol (tftp)
Set ip address, service ip, gateway, subnet mask and use pci enum on Jetson Nanoin’s startup index (Uboot command interface); After you run the pci command to Ping the Ip address of the laptop (for example, ping 192.168.1.100), the connection cannot be exceeded and Arp retry count exceeded occurs. An error is reported starting again.
As shown in the picture below:
Something to think about which is indirectly related: Some of the state of a system will be preserved if you reboot from Linux. The point here being that some drivers which don’t exist in the boot stages might still be indirectly present simply by lack of reset if the Linux kernel has been run and the system has a warm reboot run. I don’t know if your experiment is from a cold boot or after a warm boot, but it might matter.
In terms of networking I think the only reliable network you could find for a Nano in boot stages is with a USB ethernet device. I say this because USB is supported during boot stages, and possibly a driver for this would be reliable. There are certain drivers which have been present in most U-Boot installations since long ago, although some might only be 100 Mbit/s. I can’t say for certain though, you’d have to try the adapter to know. If you really need U-Boot stage ethernet, then my advice is to start with an older USB ethernet device.
PCI drivers are probably more problematic. Being able to set up PCI is likely not a problem, but introducing a driver for a PCI network device would likely require some work. However, I don’t know enough about the boot stage PCI support (other than knowing it can detect and report devices) to give you a good answer.
