Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

There are several items here. I can answer a couple of things but I will need to get more information to you tomorrow (including links to the pre-built u-boot and kernel images).

1. The way the "stock" MityDSP-L138/F is shipped has the kernel always being loaded from SPI-NOR flash, regardless of where the root filesystem is mounted. You can see the loading of the kernel if you catch the u-Boot (hit a key) and then print the bootcmd environment variable out. It's unlikely that the Kernel can be corrupted in the SPI memory. There may be kernel image present on the NAND root-filesystem, but by default this is not the kernel that is loaded. This is done to support NFS level booting without the need to configure on-board NAND flash. Also, the u-Boot jffs2 NAND driver is not very fast, so retrieving the kernel from a JFFS2 NAND filesystem is rather slow.
2. For the nand write.jffs2 operations, the "skipping bad blocks" message is OK (even "good"). NAND will intrinsically have bad blocks, that's why it's so cheap (compared to NOR based FLASH memory). The manufacturer gaurantees a certain number of good blocks, and will mark the bad ones on the device. JFFS2 is designed to "work around" the bad blocks without file corruption by not using (skipping over) the bad blocks. The message you are seeing simply means that the u-boot writer found a bad block, but is passing over it -- and JFFS2 will be set up to deal with that. You will see different bad blocks for each different SOM module.

Now, that being said, the JFFS2 filesystem is by default being mounted as read/write and the block sizes are fairly large. That means that if you power-off your unit while it is writing to disk (FLASH - JFFS2) you can corrupt your root filesystem and the executables that live on it. So at the moment, you need to do a "poweroff" or a "shutdown" or a "reboot" to ensure that the rootfilesystem is unmounted cleanly before powering off. We're looking at ways to deal with this, though there is a lot of "google-able" material about ways to deal with this, including:

• Mounting the root filesystem as read-only (e.g., "mount -o remount,ro /" in a rc.local script). This still requires system stability while booting.
• Using an alternate filesystem for the root filesystem on the NAND or even the SPI-NOR, such as read-only CRAMFS or SQUASHFS
• configuring the kernel to mount the root filesystem read-only

Note that several ram based filesystems are used for /tmp, /var, etc., already. One quick thing that will reduce the likelyhood of corruption during boot or otherwise (in the interim) is to add the "noatime" option to the root filesystem in both the u-boot kernel command line (replace "rw" with "rw,noatime" as well as in the /etc/fstab. This will remove writing accesstimes to the filesystem for all executables that are launched during normal operation.

As for the ethernet issue, I beleive that there may be a recent bug fix in the kernel as well as the u-boot image for the PHY detection/probing logic that may apply to early delivered units. The source for this should be available on the git repositories. I will post more details on that in a follow up post.

1) I don't mind the jffs2 being read/write, it means I can easily set the board up to NFS mount the machine we are compiling on just like I would on a disk based Linux box. Thanks for the warning, I'll just treat Flash the same way I treat disk.
2) I seem to remember seeing a link on how to SPI the kernel, but I can't find it now; I've got setting up the build, building the kernel, need the download and burn instructions similar to what is given for the jffs2.
3) Trying the "git" for the 4th time. I'm up to 15%, running at 1 KiB/s; the last 3 times I've gotten a server disconnected message. git doesn't seems to have to start over at the beginning when that happens.

I added a section called Installing the Kernel in the Linux_Kernel section of the Wiki. This covers flashing a newly built kernel into SPI-NOR flash.

Any hint on the "pre-compiled Kernel tested..."?

I placed images of the precompiled u-boot and the kernel in the files section of this support site.

Please check, when your board is booted, that the PHY address reported is "0x03".

You can see this in the u-boot printout:

...
I2C:   ready
DRAM:  128 MB
NAND:  256 MiB
In:    serial
Out:   serial
Err:   serial
ARM    Clock : 300000000 Hz
DDR    Clock : 132000000 Hz
EMIFA  CLock : 100000000 Hz
DSP    Clock : 300000000 Hz
ASYNC3 Clock : 150000000 Hz
Enet config  : 2
Resetting ethernet phy
Net:   Ethernet PHY: GENERIC @ 0x03 [0x8]
...

Got the 2nd and 3rd boards up and on the network with no problem. Still having trouble with the 1st board. What I see is:

DRAM: 64 MB
... other stuff matches
Resetting ethernet phy
Net: Ethernet PHY: GENERIC @ 0x03
...
U-Boot> boot
... lots of stuff
emac-mii: probed
...
eth0: no PHY found
net eth0: Davinci EMAC: request_irq() failed

I'm missing the "[0x8]" in the uboot area
and the "no PHY found" is probably why Linux
can't find the network.

I've replaced the jffs2 (twice) and the kernel (once).
Any suggestions on how to proceed.

Dennis,
Sounds like you need up update the uboot image on that board. I think you got that one before the others and there were some changes
made to uboot for this issue. You will want to run
factoryconfig
and record the mac address and serial number before upgrading.
To upgrade the uboot image, see Das_U-Boot_Port
You will need to re-run the
factoryconfig set
factoryconfig save
and
config set
config save
commands after upgrading. Make sure the mac and s/n portion of the factoryconfig are correct, and then you can just keep
pressing enter to accept the existing/default values on the rest (including all of the config settings).
cheers
/Tim

The new uboot worked. Problem solved. I can now scp a program onto the board
and run it.