I am trying to boot i.MX8MM Som using TFTP/NFS. I am successfully able to load the kernel and the dtb from a TFTP server (Ubuntu 20.04 LTS Machine), however, I am unable to mount the RFS on from the NFS server (which happens to be the same machine as the TFTP server). On trying to load the rfs, I get the following error:
VFS: Unable to mount rootfs via NFS, trying floppy
VFS: Cannot open root device "nfs" or unknown-block(2,0): error -6
The NFS folder on the server is owned by root. I am not sure if that might be causing an issue. However, I am unable to even execute the following:
nfs 1000000 <serverip>:<path_to_rootfs>
The above command times out. I have just one eth device and that is eth0. ip_dyn is off and ip=<board_ip>:<serverip>:<gateway>:<netmask>:::off
It would be very helpful if someone can point me towards a possible solution.
Solved! Go to Solution.
Hi @nxf65420 , The above solution is for loading an initrd through tftp, but my issue was with loading an initramfs through NFS specifically. However, I was able to resolve the NFS issue. It turns out I only had to fix the NFS version to 4 in the u-boot bootargs and set the ip to be static. This worked because the Kernel defconfig has the following fields set:
CONFIG_NFS_V4=y
CONFIG_NFS_V4_1=y
CONFIG_NFS_V4_2=y
By default, u-boot uses NFS V3 requests and I had configured by host to include only V3. Change the uboot bootargs to include `nfsvers=4` and allow NFS V3+, NFS V4+ requests on the server solved the issue.
For the sake of clarity I will post the bootargs below:
setenv ip_dyn no
setenv ipaddr <host_ip_addr>
setenv serverip <server_ip>
setenv bootargs console=${console} root=/dev/nfs rw nfsroot=${serverip}:${nfsroot},nfsvers=4,tcp ip=${ipaddr}:${serverip}:<gateway_addr>:<netmask>::eth0(or your device):off
My NFS Server is Ubuntu 20.04 LTS and the directory is owned by root. The following are the contents of the /etc/exports file:
/home/<user>/rootfs <client_ip>(rw,sync,no_root_squash,no_all_squash,no_subtree_check)
Hi harsh1621,
We tried with the L4.14.98 prebuilds and we were able to successfully boot the root file system using NFS.
The following link would be useful we believe:
https://variwiki.com/index.php?title=Yocto_Setup_TFTP/NFS
We kept the location of the root file system at /home/<xyz>/rootfs
Let us know if you find any concerns after following the above steps.
Regards,
Karan Gajjar
*** (second version) ***
Since I encounter problems in getting nfs boot running at all, I tried several things. I also followed the "solved" solution of this thread. Initially nfsvers=4 was the problem(!), because I didn't realize that v4 uses a pseudo root path. Finally it operates on v4 after /srv/nfsv4 was stripped in $nfsroot. Further, I took notice of the instructions here: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Yocto-NFS-TFTP-boot/ta-p/1103671
But this information seems somewhat outdated. Further, this text applied only partially to i.MX8, because the zImage mentioned here is said to be no longer used with arm64: https://community.nxp.com/t5/i-MX-Processors/how-to-build-zImage-for-i-mx8mq/td-p/813439
I was a bit confused regarding this, because zImage is mentioned in the official i.MX Linux User's Guide LF 5.10.9_1.0.0.
Meanwhile, NFS does its job, but a number of init errors occur after the kernel has finished its init. A log file from the start of the run netboot command is attached.
BTW: if I bitbake core-image-base or fsl-image-machine-test, the rootfs is shown as if it (and its content) were generated 2018. Only after executing
bitbake fsl-image-machine-test -c rootfs -f
(with -f), ...build-xwayland/tmp/work/imx8mmevk-poky-linux/fsl-image-machine-test/1.0-r0/rootfs seems really freshly generated. However, the errors as documented in the attachment are still persistent.
I'd appreciate any help gratefully..
BTW: I would also appreciate some hints of how to load a compressed image, since the log shows that this takes quite some seconds. This means: how can I instruct u-boot to extract the image in the process of netboot?
Even when I use a rootfs grabbed from eMMC and execute appropriate u-boot commands such that Image & .dtb-file are read from eMMC and the grabbed "FAILED" occurs on several instances, e.g. Failed to start User Login Management.
U-boot commands for this:
u-boot=> mmc dev 2
switch to partitions #0, OK
mmc2(part 0) is current device
u-boot=> run loadimage
29280768 bytes read in 132 ms (211.5 MiB/s)
u-boot=> run loadfdt
46889 bytes read in 10 ms (4.5 MiB/s)
u-boot=> setenv nfsroot /rootfs_mmc
u-boot=> run netargs
u-boot=> booti $loadaddr - $fdt_addr
And kernel command line:
[ 0.000000] Kernel command line: console=ttymxc1,115200 root=/dev/nfs rootwait rw nfsroot=192.168.1.64:/rootfs_mmc,tcp,nfsvers=4 ip=192.168.1.78:192.168.1.64:192.168.1.1:255.255.255.0
The reason for the reported failures is related to the ownership of all files in rootfs. If I say
sudo chown root:root -R /srv/nfsv4/rootfs
Then netboot runs without problems (tested with imx-image-core). In order to clarify things: Of course, the root ownership shouldn't be a problem because root has full access also to UID 1000. A run netboot comparison on an older uClinux-based platform (at hand here) shows that the above command principally shouldn't be necessary. Without ownership changes, in both cases UID and GID is shown as 1000 upon doing ls -als commands.
BTW: The problem with root ownership is that it would result in bitbake build errors. So, prior to starting bitbake, I'd have to restore the original ownership of the rootfs directory...
Please find attached a bash script that is run as build postprocess. It copies the Image and dtb-file to the TFTP-server directory and also mounts the rootfs-directory to /srv/nfsv4/rootfs.
I just added the above command to the end of this script ;-).
Hi @nxf65420 , I have referred to the steps here: https://variwiki.com/index.php?title=Yocto_Setup_TFTP/NFS but still I am unable to mount the rfs via nfs. The kernel and the dtb are getting loaded just fine, but it is the NFS that is not working. I am using a custom Debian 64 ramdisk as my rootfs. The behaviour on entering the run netboot is as follows:
1. Kernel and DTB Images are successfully downloaded
2. Kernel starts, hits random: crng init done
3. After about 5 mins, the VFS throws an error and there is kernel panic. I am using NFS Vers=3 on the host file system and the directory is owned by root.
Also, the following command in the uboot prompt fails with a timeout:
nfs <addr> <serverip>:<path>
I am not sure what is going wrong.
Hi harsh1621,
Have you tried using the rebuild rootfs and changing the owner of the directory to the user? This will help us narrow down the issue.
Let me know the result with the above two changes.
Regards,
Karan Gajjar
Yes @nxf65420 , I did try it. I set the owner of the rootfs on the host machine as the current user. I also freshly build the rootfs. But I am facing the same issue. I tried using nfsvers=3 as well, but same issue of unable to mount on NFS.
I am able to mount this NFS file system on my board after normal (eMMC) booting has been done, but unable to access it during boot.
For more details on the NFS Server, the following is my exports file:
/home/<user>/rootfs <board_ip>(rw,sync,no_root_squash,no_all_squash,no_subtree_check)
The host supports NFS Version +3, +4, +4.1.
Hi harsh1621,
We followed the below steps to build the image file:
https://community.nxp.com/t5/i-MX-Processors/Yocto-initramfs/m-p/382750/highlight/true#M55235
After getting the image, we converted that using below command:
mkimage -A arm -O linux -T ramdisk -C gzip -n "Build Root File System" -d <rootfs.gz> rootfs.ext2.gz.uboot
After copying the Image(kernel image), dtb file and the rootfs converted using the above commands to /tftpboot folder in the host machine we executed below steps to boot:
|
For more reference you can follow the below link:
https://imxdev.gitlab.io/tutorial/How_to_boot_imx_using_ramdisk/
Please check if the above steps work for you.
Regards,
Karan Gajjar
Hi @nxf65420 , The above solution is for loading an initrd through tftp, but my issue was with loading an initramfs through NFS specifically. However, I was able to resolve the NFS issue. It turns out I only had to fix the NFS version to 4 in the u-boot bootargs and set the ip to be static. This worked because the Kernel defconfig has the following fields set:
CONFIG_NFS_V4=y
CONFIG_NFS_V4_1=y
CONFIG_NFS_V4_2=y
By default, u-boot uses NFS V3 requests and I had configured by host to include only V3. Change the uboot bootargs to include `nfsvers=4` and allow NFS V3+, NFS V4+ requests on the server solved the issue.
For the sake of clarity I will post the bootargs below:
setenv ip_dyn no
setenv ipaddr <host_ip_addr>
setenv serverip <server_ip>
setenv bootargs console=${console} root=/dev/nfs rw nfsroot=${serverip}:${nfsroot},nfsvers=4,tcp ip=${ipaddr}:${serverip}:<gateway_addr>:<netmask>::eth0(or your device):off
My NFS Server is Ubuntu 20.04 LTS and the directory is owned by root. The following are the contents of the /etc/exports file:
/home/<user>/rootfs <client_ip>(rw,sync,no_root_squash,no_all_squash,no_subtree_check)
Hi harsh1621,
We are glad you were able to resolve your issue.
Regards,
Karan Gajjar