imx28evk trouble with NFS boot

[cmcqueen1975]

I'm trying to boot an imx28evk from the network. U-Boot is loading okay on the SD card. It is loading the kernel from TFTP. But I'm getting a kernel panic when trying to mount NFS:

IP-Config: Got DHCP answer from 192.168.250.106, my address is 192.168.250.110
IP-Config: Complete:
     device=eth0, addr=192.168.250.110, mask=255.255.255.0, gw=255.255.255.255,
     host=192.168.250.110, domain=, nis-domain=(none),
     bootserver=192.168.250.106, rootserver=192.168.250.106, rootpath=/home/craigm/rootfs
VFS: Cannot open root device "nfs" or unknown-block(0,255)

I think I need to enable kernel option CONFIG_NFS_ROOT. So I do so:

bitbake -c menuconfig virtual/kernel

And enable "Root file system on NFS".

Then I try to build:

bitbake -f -c compile virtual/kernel

But then I get a build error:

|   CHK     include/linux/version.h
| NOTE: make uImage CC=arm-oe-linux-gnueabi-gcc  -mno-thumb-interwork -marm --sysroot=/home/craigm/oe-core/freescale-arm/oe-core/build/tmp-eglibc/sysroots/imx28evk LD=arm-oe-linux-gnueabi-ld  --sysroot=/home/craigm/oe-core/freescale-arm/oe-core/build/tmp-eglibc/sysroots/imx28evk
|   CHK     include/linux/version.h
|   CHK     include/generated/utsrelease.h
| make[1]: `include/generated/mach-types.h' is up to date.
|   CALL    scripts/checksyscalls.sh
|   CHK     include/generated/compile.h
|   CC      fs/nfs/nfsroot.o
| In file included from include/linux/nfs_fs.h:41:0,
|                  from fs/nfs/nfsroot.c:79:
| include/linux/pagemap.h: In function 'fault_in_pages_readable':
| include/linux/pagemap.h:415:16: warning: variable 'c' set but not used [-Wunused-but-set-variable]
| fs/nfs/nfsroot.c: In function 'root_nfs_get_handle':
| fs/nfs/nfsroot.c:509:2: error: too few arguments to function 'nfs_mount'
| In file included from fs/nfs/nfsroot.c:89:0:
| fs/nfs/internal.h:121:12: note: declared here
| make[2]: *** [fs/nfs/nfsroot.o] Error 1
| make[1]: *** [fs/nfs] Error 2
| make: *** [fs] Error 2
| ERROR: oe_runmake failed

I'm a bit lost at this point. I'm fairly new to OpenEmbedded-Core and meta-fsl-arm. Am I on the right track or driving off into the bushes?

[Otavio Salvador]

On Thu, Jun 7, 2012 at 4:44 AM, cmcqueen1975 <cr...@mcqueen.id.au> wrote:

I'm trying to boot an imx28evk from the network. U-Boot is loading okay on the SD card. It is loading the kernel from TFTP. But I'm getting a kernel panic when trying to mount NFS:

you should use the unfs-server. Please look at the runqemu-exportfs script on source/poky/meta/scripts.

 

--
Otavio Salvador                             O.S. Systems
E-mail: ota...@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

[cmcqueen1975]

On Friday, June 8, 2012 3:05:20 AM UTC+10, Otavio Salvador wrote:

On Thu, Jun 7, 2012 at 4:44 AM, cmcqueen1975 wrote:

I'm trying to boot an imx28evk from the network. U-Boot is loading okay on the SD card. It is loading the kernel from TFTP. But I'm getting a kernel panic when trying to mount NFS:

you should use the unfs-server. Please look at the runqemu-exportfs script on source/poky/meta/scripts.

Wouldn't that be useful if I wanted the target board to export its rootfs via NFS? But I want to do the opposite: I want the host to export the rootfs via NFS, and I want the target to boot from it. That was working when I was trying Freescale's LTIB.

I can't find much documentation of development workflow for OpenEmbedded/-Core. E.g. I couldn't find anything showing an example development workflow using the runqemu-export-rootfs script.

[cmcqueen1975]

On Friday, June 8, 2012 3:05:20 AM UTC+10, Otavio Salvador wrote:

On Thu, Jun 7, 2012 at 4:44 AM, cmcqueen1975 wrote:

I'm trying to boot an imx28evk from the network. U-Boot is loading okay on the SD card. It is loading the kernel from TFTP. But I'm getting a kernel panic when trying to mount NFS:

you should use the unfs-server. Please look at the runqemu-exportfs script on source/poky/meta/scripts

Hmm, still trying to understand exactly what you meant by "use the unfs-server". I will have a closer look at the workflow of using runqemu-extract-sdk, runqemu-export-rootfs et al. Does this mean the kernel should be able to boot with an NFS root filesystem even though CONFIG_ROOT_NFS is not set in the kernel config?

[Otavio Salvador]

Yes; it does.

* runqemu-extract-sdk: used to extract the tar.gz image somewhere;

* runqemu-export-rootfs: run unfs-server and configure tap interfaces for use;

Passing the right params, to kernel, it ought to just work.

[cmcqueen1975]

On Friday, June 8, 2012 10:13:35 PM UTC+10, Otavio Salvador wrote:

On Thu, Jun 7, 2012 at 10:11 PM, cmcqueen1975 wrote:

On Friday, June 8, 2012 3:05:20 AM UTC+10, Otavio Salvador wrote:

On Thu, Jun 7, 2012 at 4:44 AM, cmcqueen1975 wrote:

I'm trying to boot an imx28evk from the network. U-Boot is loading okay on the SD card. It is loading the kernel from TFTP. But I'm getting a kernel panic when trying to mount NFS:

you should use the unfs-server. Please look at the runqemu-exportfs script on source/poky/meta/scripts

Hmm, still trying to understand exactly what you meant by "use the unfs-server". I will have a closer look at the workflow of using runqemu-extract-sdk, runqemu-export-rootfs et al. Does this mean the kernel should be able to boot with an NFS root filesystem even though CONFIG_ROOT_NFS is not set in the kernel config?

Yes; it does.

* runqemu-extract-sdk: used to extract the tar.gz image somewhere;

* runqemu-export-rootfs: run unfs-server and configure tap interfaces for use;

Passing the right params, to kernel, it ought to just work.

Okay, I think I understand usage of runqemu-extract-sdk, runqemu-export-rootfs on the server side. That all seems to be running fine.

I'm still getting the kernel panic at boot. With Wireshark on the server, I can see that the kernel is loading fine via TFTP server, but the imx28evk never initiates any NFS or related traffic. So I must have a problem with kernel build options or boot options.

I am using the kernel boot nfsroot options as specified by runqemu-export-rootfs verbatim. For user-mode NFS boot, what other kernel build or boot options do I need? I have root=/dev/nfs. Is that right? I can't find any documentation of user-mode NFS kernel booting. All the docs I can find for kernel booting say that kernel build option CONFIG_ROOT_NFS must be set to 'y', and kernel boot option root=/dev/nfs. So I'm not sure what to try next.

Regards,
Craig McQueen

[Otavio Salvador]

On Mon, Jun 11, 2012 at 10:38 PM, cmcqueen1975
<google...@craig.mcqueen.id.au> wrote:
> I am using the kernel boot nfsroot options as specified by
> runqemu-export-rootfs verbatim. For user-mode NFS boot, what other kernel
> build or boot options do I need? I have root=/dev/nfs. Is that right? I
> can't find any documentation of user-mode NFS kernel booting. All the docs I
> can find for kernel booting say that kernel build option CONFIG_ROOT_NFS
> must be set to 'y', and kernel boot option root=/dev/nfs. So I'm not sure
> what to try next.

I think your problem might be kernel configuration. I'd check if
devtmpfs and NFS client support are enable in the kernel config.

[cmcqueen1975]

On Tuesday, June 12, 2012 10:22:25 PM UTC+10, Otavio Salvador wrote:

On Mon, Jun 11, 2012 at 10:38 PM, cmcqueen1975 wrote:
> I am using the kernel boot nfsroot options as specified by
> runqemu-export-rootfs verbatim. For user-mode NFS boot, what other kernel
> build or boot options do I need? I have root=/dev/nfs. Is that right? I
> can't find any documentation of user-mode NFS kernel booting. All the docs I
> can find for kernel booting say that kernel build option CONFIG_ROOT_NFS
> must be set to 'y', and kernel boot option root=/dev/nfs. So I'm not sure
> what to try next.

I think your problem might be kernel configuration. I'd check if
devtmpfs and NFS client support are enable in the kernel config.

I was trying to use the default kernel config for the imx28evk target. NFS client support was already enabled. DEVTMPFS wasn't.
I've tried enabling DEVTMPFS, but it didn't help. I also tried DEVTMPFS_MOUNT, but again, no improvement.

(I checked that I was really building a new uImage, and found that I had to follow the work-around of bug 2256 comment 7 to ensure uImage was rebuilt. That's time consuming--any faster way to do it?)

Meanwhile, I still wonder if I really need to enable CONFIG_ROOT_NFS. I investigated why it's not compiling properly, and found that the patch NFS-allow-nfs-root-mount-to-use-alternate-rpc-ports.patch is causing the build error I described in my first post.

Any suggestions from here?

[cmcqueen1975]

On Thursday, June 14, 2012 3:27:22 PM UTC+10, cmcqueen1975 wrote:

Meanwhile, I still wonder if I really need to enable CONFIG_ROOT_NFS. I investigated why it's not compiling properly, and found that the patch NFS-allow-nfs-root-mount-to-use-alternate-rpc-ports.patch is causing the build error I described in my first post.

I changed meta-fsl-arm/recipes-kernel/linux/linux-imx_2.6.35.3.bb to remove NFS-allow-nfs-root-mount-to-use-alternate-rpc-ports.patch
I changed meta-fsl-arm/recipes-kernel/linux/linux-imx-2.6.35.3/imx28evk/defconfig to enable CONFIG_ROOT_NFS=y

Then, I rebuilt the kernel, and exported the root filesystem using the NFS service on the host (sudo service nfs-kernel-server start). Then, the board was able to boot up to a point:

...
eth0: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=0:00, irq=-1)
eth1: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=0:01, irq=-1)
Sending DHCP requests .
PHY: 0:00 - Link is Up - 100/Full
.., OK

IP-Config: Got DHCP answer from 192.168.250.106, my address is 192.168.250.110
IP-Config: Complete:
     device=eth0, addr=192.168.250.110, mask=255.255.255.0, gw=255.255.255.255,
     host=192.168.250.110, domain=, nis-domain=(none),
     bootserver=192.168.250.106, rootserver=192.168.250.106, rootpath=/home/craigm/rootfs

Looking up port of RPC 100003/3 on 192.168.250.106
Looking up port of RPC 100005/3 on 192.168.250.106
VFS: Mounted root (nfs filesystem) on device 0:14.
Freeing init memory: 156K

but then it stopped there.

Is there any OpenEmbedded-Core "getting started" guide for booting the imx28evk from either SD card or NFS? Or, a "getting started" guide for at least running an imx28evk build with qemu? That would be helpful. I'm still struggling to get a basic imx28evk system running.

[Fabio Estevam]

I haven't used nfs with Yocto yet. Could you please detail your steps
so that I can reproduce the same as you did?

Looks like the NFS mounted fine and maybe it`s a serial port
configuration issue.

I will be glad to investigate this if you send me your steps to reach
up to this point.

> Is there any OpenEmbedded-Core "getting started" guide for booting the
> imx28evk from either SD card or NFS? Or, a "getting started" guide for at
> least running an imx28evk build with qemu? That would be helpful. I'm still

I have only tried booting from SD card and you can follow this:
http://www.imxdev.org/wiki/index.php?title=Yoctoproject

[Otavio Salvador]

On Thu, Jun 14, 2012 at 4:42 AM, cmcqueen1975
<google...@craig.mcqueen.id.au> wrote:
> I changed meta-fsl-arm/recipes-kernel/linux/linux-imx_2.6.35.3.bb to remove
> NFS-allow-nfs-root-mount-to-use-alternate-rpc-ports.patch
> I changed
> meta-fsl-arm/recipes-kernel/linux/linux-imx-2.6.35.3/imx28evk/defconfig to
> enable CONFIG_ROOT_NFS=y

I just pushed a fix to allow it to work fine with the alternate rpc ports patch.

Please update your repositories and give it a try. It ought to work fine.

Regarding your console issue, it might be you had a previous build
system using our old tty setup. To be sure it will use the new value,
please do:

bitbake -c cleansstate sysvinit-inittab

before starting the new build.

[Fabio Estevam]

On Mon, Jun 18, 2012 at 12:20 PM, Otavio Salvador
<ota...@ossystems.com.br> wrote:
> On Thu, Jun 14, 2012 at 4:42 AM, cmcqueen1975
> <google...@craig.mcqueen.id.au> wrote:
>> I changed meta-fsl-arm/recipes-kernel/linux/linux-imx_2.6.35.3.bb to remove
>> NFS-allow-nfs-root-mount-to-use-alternate-rpc-ports.patch
>> I changed
>> meta-fsl-arm/recipes-kernel/linux/linux-imx-2.6.35.3/imx28evk/defconfig to
>> enable CONFIG_ROOT_NFS=y
>
> I just pushed a fix to allow it to work fine with the alternate rpc ports patch.

It would be nice if you could post the patch in the list first, so
people can know that there are new patches being applied.

[Otavio Salvador]

On Mon, Jun 18, 2012 at 12:29 PM, Fabio Estevam <fest...@gmail.com> wrote:
>> I just pushed a fix to allow it to work fine with the alternate rpc ports patch.
>
> It would be nice if you could post the patch in the list first, so
> people can know that there are new patches being applied.

Yes; I forgot to send it to the mailing list; sorry.

[cmcqueen1975]

I've been distracted from this for 2 months, with other corporate work. Now I'm back to it.

I'm not clear as to what the similarities/differences/relationship between Yocto and OpenEmbedded-Core are. I'm trying to do OpenEmbedded-Core, as best as I can figure from the little documentation I've found for the Freescale ARM layer (https://github.com/Freescale/meta-fsl-arm).

I've updated the latest from the OE-core and Freescale ARM layer repositories, and tried to boot via both SD card and NFS. I couldn't get either one to work.

I've put a question on StackOverflow detailing the procedure I've tried, for both SD card boot and NFS boot:
http://stackoverflow.com/questions/12135129/cant-boot-basic-openembedded-core-on-freescale-i-mx28

Any pointers on how to get SD card and/or NFS boot working on i.MX28 would be much appreciated.

[Otavio Salvador]

We have did a lot of fixes in meta-fsl-arm and we've been testing it
for quite some time now.

Please use denzil branch for all repositories as this is the one that
is known to be working; master is nicer but can have some surprises
from time to time.

Bear on mind to use proper console (ttyAMA0) and change the bootcmd
line for nfs.

I think current kernel should just work now.

[cmcqueen1975]

Thanks for the pointer to denzil. I've switched git repositories to denzil (except bitbake which doesn't have a denzil branch). Now I get a build error:

Error, TMPDIR has changed its layout version number (8 to 7) and you need to either rebuild, revert or adjust it at your own risk.

I tried:

bitbake -c clean core-image-minimal

and

bitbake -c rebuild core-image-minimal

but both gave me the same error.

Is there some way to rebuild without starting from scratch (in particular, without having to re-download the many MB of sources)?

Thanks,
Craig McQueen

[cmcqueen1975]

I tried doing a fresh build anyway, to see whether it can start. Now I'm getting thousands of warnings like:

WARNING: Variable do_populate_lic_setscene contains tabs, please remove these (/home/craigm/oe-core/freescale-arm/oe-core/meta/recipes-core/eglibc/eglibc-locale_2.15.bb)

and an error:

ERROR: Nothing PROVIDES 'pseudo-native'

Why all the warnings about tabs? Is this "normal"?

Is meta-openembedded/meta-oe a dependency when using denzil branch?

What am I missing for 'pseudo-native' dependency?

Thanks,
Craig McQueen

[Otavio Salvador]

On Mon, Aug 27, 2012 at 9:13 PM, cmcqueen1975
<google...@craig.mcqueen.id.au> wrote:
> Thanks for the pointer to denzil. I've switched git repositories to denzil
> (except bitbake which doesn't have a denzil branch). Now I get a build
> error:
>
> Error, TMPDIR has changed its layout version number (8 to 7) and you need to
> either rebuild, revert or adjust it at your own risk.
>
> I tried:
> bitbake -c clean core-image-minimal
> and
> bitbake -c rebuild core-image-minimal
>
> but both gave me the same error.
>
> Is there some way to rebuild without starting from scratch (in particular,
> without having to re-download the many MB of sources)?

You will need to rebuild from scratch but the sources, if the same,
are not going to be downloaded again.

A good thing is that denzil is a maintenance branch so you'll be with
minor changes only on it. Your build time is greatly reduced after
first build and your safety is greater.

[cmcqueen1975]

I'm still stuck at this point.

I'm trying to build on Ubuntu 12.04 32-bit (which was able to build the master branch, but not denzil).

My BBLAYERS contains:

BBLAYERS ?= " \
  /home/craigm/oe-core/freescale-arm/oe-core/meta \
  /home/craigm/oe-core/freescale-arm/oe-core/meta-openembedded/meta-oe \
  /home/craigm/oe-core/freescale-arm/meta-fsl-arm \
  "

Those 3 repositories are all on "denzil" branch, but I'm using "master" bitbake. I've tried both with and without the meta-oe line. Is meta-oe needed?

When I try to build, I get a message at the start "Pseudo is not present but is required, building this first before the main build". What is that for?

I get two errors:

ERROR: Unable to parse /home/craigm/oe-core/freescale-arm/oe-core/meta/recipes-core/eglibc/eglibc_2.15.bb
ERROR: Nothing PROVIDES 'pseudo-native'

as well as a few hundred or thousand warning messages along the lines of:

WARNING: Variable do_populate_lic_setscene contains tabs, please remove these (/home/craigm/oe-core/freescale-arm/oe-core/meta/recipes-core/expat/expat_2.0.1.bb)

(I get thousands of these when meta-oe is included in BBLAYERS; hundreds without it. Strangely, the number of warnings varies each time I run it. E.g. sometimes 201, sometimes 202, sometimes 238.)

I'm not sure what to try next, since I can't really make sense of these errors. I don't know what "pseudo" is.

At this point I'm fairly discouraged with these failures. I'm not an expert with embedded Linux, but I've been able to build LTIB for i.MX28 (but I didn't like the LTIB architecture); I've been able to build the base OE-Core and boot it in qemu; I've been able to build a commercial embedded Linux for i.MX28. But no success with this meta-fsl-arm for i.MX28 so far. It would be really helpful if there was a "getting started" guide for meta-fsl-arm + openembedded-core.

Fabio Estevam did point to a Yocto getting-started guide. But that's another thing I'm unclear about--the meta-fsl-arm README on github says meta-fsl-arm is for use with OpenEmbedded and/or Yocto, and says it depends on URI: git://git.openembedded.org/openembedded-core, branch: master, revision: HEAD. (no mention of denzil). So for i.MX28, does it work with Yocto, or OE-Core, or both? If Yocto, does it work with master branch, or denzil? I'm not sure which direction I should be going for Yocto versus OpenEmbedded-Core. It seems that Yocto/OpenEmbedded experts must know the whole story behind Yocto/OpenEmbedded/OpenEmbedded-Core, and the current state of these projects, but for me a relative newbie, it's all a bit mysterious.

[cmcqueen1975]

On Thursday, 30 August 2012 09:34:38 UTC+10, cmcqueen1975 wrote:

On Tuesday, August 28, 2012 11:12:59 AM UTC+10, cmcqueen1975 wrote:

On Tuesday, August 28, 2012 10:13:24 AM UTC+10, cmcqueen1975 wrote:

On Tuesday, August 28, 2012 6:55:06 AM UTC+10, Otavio Salvador wrote:

We have did a lot of fixes in meta-fsl-arm and we've been testing it
for quite some time now.

Please use denzil branch for all repositories as this is the one that
is known to be working; master is nicer but can have some surprises
from time to time.

Bear on mind to use proper console (ttyAMA0) and change the bootcmd
line for nfs.

I think current kernel should just work now.

Thanks for the pointer to denzil. I've switched git repositories to denzil (except bitbake which doesn't have a denzil branch). Now I get a build error:

...

I tried doing a fresh build anyway, to see whether it can start. Now I'm getting thousands of warnings like:

WARNING: Variable do_populate_lic_setscene contains tabs, please remove these (/home/craigm/oe-core/freescale-arm/oe-core/meta/recipes-core/eglibc/eglibc-locale_2.15.bb)

and an error:

ERROR: Nothing PROVIDES 'pseudo-native'

...

I'm still stuck at this point.

I'm trying to build on Ubuntu 12.04 32-bit (which was able to build the master branch, but not denzil).

...

Fabio Estevam did point to a Yocto getting-started guide. But that's another thing I'm unclear about--the meta-fsl-arm README on github says meta-fsl-arm is for use with OpenEmbedded and/or Yocto, and says it depends on URI: git://git.openembedded.org/openembedded-core, branch: master, revision: HEAD. (no mention of denzil). So for i.MX28, does it work with Yocto, or OE-Core, or both? If Yocto, does it work with master branch, or denzil? I'm not sure which direction I should be going for Yocto versus OpenEmbedded-Core. It seems that Yocto/OpenEmbedded experts must know the whole story behind Yocto/OpenEmbedded/OpenEmbedded-Core, and the current state of these projects, but for me a relative newbie, it's all a bit mysterious.

As described in a separate post, I did achieve success with Yocto + meta-fsl-arm for imx28evk, booting from the SD card (I had to reapply a patch for cpufreq, and change the U-Boot console configuration).

Now that I've got Yocto SD card boot working, I'm trying TFTP + NFS boot again. As described in a a separate post, I managed to write just U-Boot to an SD card. The board loads the kernel image via TFTP, and then mounts the NFS root filesystem. But after that, I get nothing else appearing:

...
TCP cubic registered
NET: Registered protocol family 17
can: controller area network core (rev 20090105 abi 8)
NET: Registered protocol family 29
can: raw protocol (rev 20090105)
mxs-rtc mxs-rtc.0: setting system clock to 1970-01-01 00:03:04 UTC (184)
usb 2-1: new full speed USB device using fsl-ehci and address 2

eth0: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=0:00, irq=-1)
eth1: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=0:01, irq=-1)
Sending DHCP requests .
PHY: 0:00 - Link is Up - 100/Full
., OK

IP-Config: Got DHCP answer from 192.168.250.106, my address is 192.168.250.142
IP-Config: Complete:
     device=eth0, addr=192.168.250.142, mask=255.255.255.0, gw=255.255.255.255,
     host=192.168.250.142, domain=, nis-domain=(none),

     bootserver=192.168.250.106, rootserver=192.168.250.106, rootpath=/home/craigm/rootfs
Looking up port of RPC 100003/3 on 192.168.250.106
Looking up port of RPC 100005/3 on 192.168.250.106

VFS: Mounted root (nfs filesystem) on device 0:15.
Freeing init memory: 156K

Then after that, nothing further.

I checked with Wireshark on the rootserver, and I can see NFS traffic occurring. So it looks as though NFS root filesystem may be working, but console output isn't for some reason. As for SD card boot, I set console=ttyAMA0 in U-Boot. So now I'm not sure why console might not be working.

I'm attaching text files that show the console output I'm getting for SD card boot compared to TFTP + NFS boot.

[Otavio Salvador]

On Sun, Sep 9, 2012 at 8:57 PM, cmcqueen1975
<google...@craig.mcqueen.id.au> wrote:
...

My guess is that your exported rootfs is wrong; so kernel is not
capable of running init. Checking the logs between the SD boot and NFS
boot it seems it stoped just before calling /bin/init

[Otavio Salvador]

Did you try to mount the rootfs directly on your machine?

[cmcqueen1975]

Thanks. I examined what I was doing for NFS rootfs, and found my problem. I was extracting the rootfs as follows:

runqemu-extract-sdk tmp/deploy/images/core-image-minimal-imx28evk.tar.bz2 ~/rootfs/

I was using the Linux kernel root NFS server to serve /home/craigm/rootfs (that is, I added an entry in /etc/exports and ran sudo service nfs-kernel-server start). But, it seems that runqemu-extract-sdk doesn't set up file permissions as needed--most likely the device nodes in the dev directory are the problem. I guess runqemu-extract-sdk is only suitable if we're also using the user-mode NFS server runqemu-export-rootfs.

So, I instead did this:

sudo rm -Rf ~/rootfs/*
sudo mkdir ~/rootfs         # if needed
sudo tar jxf tmp/deploy/images/core-image-minimal-imx28evk.tar.bz2 -C ~/rootfs/

Then, the NFS boot works fine.

[Otavio Salvador]

Right; it is indeed specific to the user level use.

> So, I instead did this:
>
> sudo rm -Rf ~/rootfs/*
> sudo mkdir ~/rootfs # if needed
> sudo tar jxf tmp/deploy/images/core-image-minimal-imx28evk.tar.bz2 -C
> ~/rootfs/
>
>
> Then, the NFS boot works fine.

Cool; thanks by letting us know it is working.