Updated Omap3530 filesystem

msj said:

Is there any user guide or wiki information to help guide me on tailoring the file system initialization?

Not necessarily to tailor the existing filesystem, but there is a good article on making a new file system which you could configure to be relatively small if that is your need, in particular see this wiki article.

You may also want to try an alternative filesystem from the SDK, there are two options in OMAP35x-PSP-SDK-02.01.02.09\images\fs for either the standard filesystem or the base filesystem, the base being notibly smaller.

Hi Bernie,

Thanks.  I was aware of the wiki page for creating a filesystem, and had used it previously to put together the file system I had been using with the previous SDK.  So are you suggesting my previous file system might work fine with the updated linux kernel?  I did have to recompile some of my code to use the newer libraries.  I guess I would just have to move the newer libraries over too.

Also thanks for pointing out the alternative nfs_base.tar in the SDK.  I hadn't noticed that yet.  From the surface it does look considerably smaller than the one I am using.  I'll give it a try.

Maybe the wiki page needs some updating to address the substantially different initialization, and configuration.

Hi Bernie,

I am trying the nfs-base file system and have run into a kernel panic:

"...

VFS: Mounted root (nfs filesystem) on device 0:12.
VFS: Mounted root (nfs filesystem) on device 0:12.
<6>Freeing init memory: 156K
Freeing init memory: 156K
<0>Kernel panic - not syncing: No init found.  Try passing init= option to kerne
l.
Kernel panic - not syncing: No init found.  Try passing init= option to kernel.
"

any thoughts on whats missing?

simon

with the full nfs file system (nfs.tar.gz)

I get this:

"...

Freeing init memory: 156K
INIT: version 2.86 booting
Starting udev<6>udevd version 124 started
udevd version 124 started

"

what INIT is it looking for that it can't find in the (nfs-base.tar.gz) fielsystem?

The INIT is the first thing the kernel runs in the newly mounted filesystem, the most common problem here is that this is a symbolic link that can be removed inadvertently if the filesystem is moved with a plain cp command. This is actually mentioned elsewhere on the forums and seems to be a relatively common point of failure, for example https://e2e.ti.com/forums/p/2343/8875.aspx#8875.

Hi Bernie,

This may be the case.  It looks like I have some problem with the nf-base.tar.gz file.  It does not seem to untar?

I am using:

[host]$  tar -xz nfs-base.tar.gz

and it seems to go off into the daisies.

I had previously removed it from the archive using 7-zip, and maybe this did not preserve the symbolic links.

Not sure why un-tarring is not working on this file?

Simon

msj said:

I had previously removed it from the archive using 7-zip, and maybe this did not preserve the symbolic links.

This is quite possible, I have never used 7-zip for filesystems.

msj said:

Not sure why un-tarring is not working on this file?

It does untar for me, note that you should probably have root privelages to be able to reconsitute the symbolic links, i.e. 'sudo tar -zxvf nfs-base.tar.gz'. If I try to untar as default user I get errors regarding 'Cannot mknod: Operation not permitted'.

Hi Bernie,

Yes I needed to tar xvzf nfs-base.tar.gz and I was root user.  I am now booting with the base-nfs filesytem.

Unfortunatly I am still seeing:

"...

<3>end_request: I/O error, dev mtdblock0, sector 0
<3>Buffer I/O error on device mtdblock0, logical block 0
Buffer I/O error on device mtdblock0, logical block 0
<3>uncorrectable error : uncorrectable error : <3>end_request: I/O error, dev mt
dblock0, sector 8
..."

errors and things like:

"...

Configuring network interfaces... udhcpc (v1.13.2) started

Sending discover...
Sending discover...
Sending discover...
No lease, failing

.."

are still included in this reduced file system.  I'm not quite sure what that is, but it looks like maybe its the wireless network trying to find dhcp server?  I do not have any wireless configured on my Mistral evm, so it is really unnecessary.

I haven't tried my previous fs from the older dvsdk;  Do you think it will work with this linux kernel?

Thanks for your help,

simon

I am glad to hear that at least part of it is working.

msj said:

Buffer I/O error on device mtdblock0, logical block 0

These errors relate to the kernel being unable to mount a flash disk properly, MTD stands for memory technology device, and usually refers to on board flash. If you are not using a flash based filesystem you could probably be rid of these by rebuilding the kernel with MTD support removed by 'make menuconfig'.

msj said:

I'm not quite sure what that is, but it looks like maybe its the wireless network trying to find dhcp server?  I do not have any wireless configured on my Mistral evm, so it is really unnecessary.

The DHCP discover stuff is coming from the network TCP/IP stack, there is no wireless on the OMAP3 EVM from Mistral, this is most likely referring to the wired network configuration unless you have some USB (potentially wireless) network adapter connected, though it is strange that this could fail while the NFS succeeds.

msj said:

I haven't tried my previous fs from the older dvsdk;  Do you think it will work with this linux kernel?

You would have to try it to see, it really depends on how old it was, I have never tried this across OMAP filesystem versions.

Ultimately I will be using the MTD flash.  In fact part of this exercise for reducing the file system is to come up with a baseline fs I can put into the nand flash.  I guess I could try burning this one in and see if that removes these errors.

I thought it was kind of strange the dhcp seems to be enabled given I am booting a statically assigned ip address, and the nfs mount is working fine. I do not have any usb networking device connected.

Are you sure this is not a trying to init a wireless device?

when I look at the /etc/network/interfaces file I see this:

"...

# Wireless interfaces
#
# Example of an unencrypted (no WEP or WPA) wireless connection
# that connects to any available access point:
#
iface wlan0 inet dhcp
    wireless_mode managed
    wireless_essid any
...

"

but this is part why I posted the original question; as I don't really understand how to configure all this new initialization, any pointers would be helpful.

Thanks again for your help.

simon

Hi Bernie,

I just noticed a subtle difference between the old and new /proc/mtd output.

was:
[root@OMAP3EVM /]# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00080000 00020000 "X-Loader"
mtd1: 001e0000 00020000 "U-Boot"
mtd2: 00020000 00020000 "U-Boot Env"
mtd3: 00400000 00020000 "Kernel"
mtd4: 0f980000 00020000 "File System"


now

root@arago:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00080000 00020000 "xloader-nand"
mtd1: 001c0000 00020000 "uboot-nand"
mtd2: 00040000 00020000 "params-nand"
mtd3: 00500000 00020000 "linux-nand"
mtd4: 0f880000 00020000 "jffs2-nand"

I'm wondering if this has something to do with the MTD errors I am seeing on boot?

I think what this means is the newer mtd now has a smaller  segment for uboot, but bigger segment for env variables, bigger segment for kernel and smaller segment for the file system.  This might also mean the starting addresses are not quite right?

How or were is this configured?

simon

And another clue that doesn't make sense is the u-boot command saveenv is reporting:

OMAP3_EVM # saveenv
Saving Environment to NAND...
Erasing Nand...
Erasing at 0x260000 -- 100% complete.
Writing to Nand... done

OMAP3_EVM #

and the linux boot shows:

<5>Creating 5 MTD partitions on "omap2-nand.0":
Creating 5 MTD partitions on "omap2-nand.0":
<5>0x000000000000-0x000000080000 : "xloader-nand"
0x000000000000-0x000000080000 : "xloader-nand"
<5>0x000000080000-0x000000240000 : "uboot-nand"
0x000000080000-0x000000240000 : "uboot-nand"
<5>0x000000240000-0x000000280000 : "params-nand"
0x000000240000-0x000000280000 : "params-nand"
<5>0x000000280000-0x000000780000 : "linux-nand"
0x000000280000-0x000000780000 : "linux-nand"
<5>0x000000780000-0x000010000000 : "jffs2-nand"
0x000000780000-0x000010000000 : "jffs2-nand"

with the params-nand starting at  0x000000240000.

which may not be at the right location?  where does u-boot get its nand address locations for saveenv?

I have found a solution/work around (?) for the mtdblock errors.

I have modified the target file:

/etc/udev/rules.d/60-persistent-storage.rules

by adding mtdblock* to the list of things udev should ignore.  just modify this line from:

# skip rules for inappropriate block devices
KERNEL=="ram*|loop*|fd*|nbd*|gnbd*|dm-*|md*", GOTO="persistent_storage_end"

to this:

# skip rules for inappropriate block devices
KERNEL=="ram*|loop*|fd*|nbd*|gnbd*|dm-*|md*|mtdblock*", GOTO="persistent_storage_end"

Although I don;t think this can be long term solution because the note at the top of the file is ominous?

# do not edit this file, it will be overwritten on update

Does anyone know the right place to make these kinds of changes?

simon

Hi Bernie,

I think the dhcp is a result of the:

/etc/network/interfaces

file.

If I change the following from:

# Wired or wireless interfaces
auto eth0

iface eth0 inet dhcp
iface eth1 inet dhcp

to:

# Wired or wireless interfaces

auto eth0
#iface eth0 inet dhcp
#iface eth1 inet dhcp

iface eth0 inet static
    address 10.10.10.4
    netmask 255.255.255.0
    network 10.10.0.0
    gateway 10.10.10.2

it no longer does the dhcp on boot.

Is this the right place to make this kind of change?