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

Ben,

We are in the process of testing a Yocto-compatible toolchain for the MityDSP-L138 family. This release includes gcc 4.8.

I have uploaded an ALPHA version of the new MDK to this website under the "Files" tab. It includes a .sh file that installs the compiler and a .tar.bz2 that contains the updated filesystem. This is an ALPHA release that may change before final release, but it may allow you to try out the newer compiler. There is an environment setup script in the top-level of the MDK that you can source to setup the compiler.

Please note that our current kernel will not compile with this SDK. We have a fix, but it is not released yet. If you need to compile the kernel, please use an older MDK.

We plan to release the Yocto-compatible kernel, filesystem, and MDK in January 2016.

-Bob

Bob,

Thank you for the response regarding the new gcc cross-compiler for the MityDSP-L138. Now that we're back from the holidays, I was able to successfully cross compile our application on my build machine.

I'm a little unclear, however, about the procedure to get the file system contents of the mitydsp-l138-rootfs.tar.bz2 onto our target OMAP-L138 machine. When I run our newly compiled app on the system, I get:

/Test/Logger_test: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /Test/Logger_test)

Obviously, because I haven't updated the target file system, the current libstdc++ library doesn't match up with our new executable.

This is probably a dumb question, but do I simply overwrite root on our target system with the contents of the bz2 file?

Regards,

Ben

Yes, extract the tar ball onto the root filesystem, but make sure to erase the existing one first. And backup your important files of course.

Please let us know if there are any tools missing from the new filesystem that you used in the old TI one.

Also, please make sure you perform the extraction as the root user:

$ sudo tar xjvf filename.tar.bz2

We have a tool that reprograms the root FS on our target device with a jffs2 file. I saw in the Release 2010.05 there are root FS files in both the jffs2 file and a tar.gz file. Do you have a tool or procedure that can convert the mitydsp-l138-rootfs.tar.bz2 to a jffs2 file for the ALPHA Release 2016.01?

Regards,

Ben

Here is the command we run to create the jffs file for the original MDK. Where $root is the path to the extracted filesystem.

mkfs.jffs2 -x lzo --root=${root} --faketime --output=${RELEASE_DIR}/fs/`basename ${root}`.jffs2 --little-endian --eraseblock=0x20000 -n

So an example way to do this would be:

mkdir mitydsp-l138-rootfs
cd mitydsp-l138-rootfs
sudo tar xjf ../mitydsp-l138-rootfs.tar.bz2

cd ..
sudo mkfs.jffs2 -x lzo --root=mitydsp-l138-rootfs --faketime --output=mitydsp-l138-rootfs.jffs2 --little-endian --eraseblock=0x20000 -n

If you want to do this without sudo privileges you can use the fakeroot command. Replace sudo on the tar line with fakeroot and remove the sudo command on the mkfs line.

I want to set a static IP address on my target using the ALPHA Release 2016.01 file system, but I was surprised to see the /etc/network/interfaces file didn't exist in the file system image. I expected to see this file populated with something like:
iface eth0 inet dhcp

I was then going to replace the dhcp line with:
iface eth0 inet static
address 192.168.15.11
netmask 255.255.255.0
network 192.168.15.0
gateway 192.168.15.1

Is there some other way that static IPs need to be configured using the ALPHA file system? -- or do I simply add my own /etc/network/interfaces file?

Regards,

Ben

Ben,

Part of the reason this filesystem is alpha is to discover differences from the old filesystem. We hadn't noticed this so good catch. Could you try creating the interface file and report back whether it worked?

Jonathan,

I was able to load your ALPHA Linux file system onto my target, and I've had some success. The system is running, and I can establish an SSH terminal connection to it.

I've attached two dumps from the console as the system comes up. There are two issues that I have at this point:

1. There are lots of ipv6 error messages in both dumps. I don't require ipv6 at this point, so the messages are an annoyance more than anything. Is there something ipv6 requires that is missing?

2. In the 20160203LaterBoot.txt, after the boot completes, I no longer have access to ttyS1 as a login terminal. This was not the case captured in 20160203FirstBoot.txt. The problem appeared after the first time I ran "shutdown -r now" from the serial console. Now when I run "shutdown -r now" from an SSH terminal, console output appears on the ttyS1 serial port, it's just that I can't use the serial port as a login console.

Regards,

Ben

Ben Atkinson wrote:

Jonathan,

I was able to load your ALPHA Linux file system onto my target, and I've had some success. The system is running, and I can establish an SSH terminal connection to it.

I've attached two dumps from the console as the system comes up. There are two issues that I have at this point:

1. There are lots of ipv6 error messages in both dumps. I don't require ipv6 at this point, so the messages are an annoyance more than anything. Is there something ipv6 requires that is missing?

The kernel your booting doesn't match the kernel modules its trying to load. Delete the kernel modules in /lib/modules/ and replace with modules from kernel you built.

# rm -rf /lib/modules/*

2. In the 20160203LaterBoot.txt, after the boot completes, I no longer have access to ttyS1 as a login terminal. This was not the case captured in 20160203FirstBoot.txt. The problem appeared after the first time I ran "shutdown -r now" from the serial console. Now when I run "shutdown -r now" from an SSH terminal, console output appears on the ttyS1 serial port, it's just that I can't use the serial port as a login console.

Its hard to see whats going on. If you could recreate first and last log with correct kernel modules (thus removing all error messages).

Regards,

Ben

Jonathan,

Thanks for the reply. I didn't build a new kernel based on the comment from Bob Duke, above:

> Please note that our current kernel will not compile with this SDK. We have a fix,
   > but it is not released yet. If you need to compile the kernel, please use an older MDK.
   > We plan to release the Yocto-compatible kernel, filesystem, and MDK in January 2016.

So if I understand correctly, I should follow the instructions here:

https://support.criticallink.com/redmine/projects/arm9-platforms/wiki/Linux_Kernel

...using the new yocto gcc 4.8.3 that I got from the ALPHA Release 2016.01 SDK?

What is the URL for the latest kernel sources? Is it still:
> user@desktop->git clone git://support.criticallink.com/home/git/linux-davinci.git
> user@desktop->cd linux-davinci
> user@desktop->git checkout -b mitydsp-linux-v3.2 origin/mitydsp-linux-v3.2

Is the new, complete, MDK far off?

Regards,

Ben

Ben Atkinson wrote:

Jonathan,

Thanks for the reply. I didn't build a new kernel based on the comment from Bob Duke, above:

Did you build the kernel your currently booting from or was it copied from the old MDK_2014-01-13?

I did not build a new kernel. A kernel was already on my target system, and I believe it came from the MDK_2014-01-13.

The only thing I did was:
- Took the mitydsp-l138-rootfs.tar.bz2 from the ALPHA 2016.01 and added my /etc/network/interface file to it.
- Converted the resulting mitydsp-l138-rootfs.tar.bz2 to a jffs2 file.
- Used u-boot to tftp the new jffs2 file to the target, erase flash, then program flash with jffs2 file.
- Rebooted.

Regards,

Ben

Ben, I apologize for the assumptions in my original advice. Any time you change a kernel you need to bring along the asociated modules (typically located in /lib/modules) for that kernel. You would've needed to grab the /lib/modules/ directory contents and add them to the new filesystem.

Under the files tab, I uploaded the kernel that should correspond to your new filesystem. Please try this kernel.

Is your target a custom baseboard or a MityDSP development kit (Industrial IO board)?

Bob,

Thanks. Just to be clear, should I put the new uImage in /boot and re-create the jffs2 image? Currently the following is in /boot:
- uImage -> uImage-3.2.0+
- uImage-3.2.0+

My target is a custom board.

Regards,

Ben

Ben, you shouldn't have to redo your filesystem. Just copy over the kernel.

cd boot
rm uImage
cp path/to/new/uImage .

Bob,

On my target system I had: # cd /boot # ls la u*
lrwxrwxrwx 1 root root 13 Nov 13 21:13 uImage -> uImage-3.2.0+
-rw-r--r- 1 root root 2538632 Nov 13 19:50 uImage-3.2.0+

When I did a binary file comparison between the exising uImage-3.2.0+ and the new uImage, they are exactly the same. So it seems to me the problem is the kernel loaded from U-Boot, not the kernel in the Linux root file system.

But I deleted the previous contents of /boot and copied in the new uImage anyway. Rebooting gave the same problems as before: a hung /dev/ttyS1 and lots of ipv6 messages.

I then tried the following from a U-Boot netconsole:

U-Boot> tftp 0xC0700000 192.168.15.11:uImage
U-Boot> bootm 0xC0700000

...as was suggested on the Critical Link ARM9 Kernel Wiki page. Theoretically the uImage loaded from memory should match exactly with the uImage in the Linux /boot directory, and the /lib/modules should match both. The system hangs when I boot this way. The netconsole shows:

Cmd line: -l -u -p 6666

U-Boot 2009.11 (May 10 2015 - 02:02:05)
Hit any key to stop autoboot: 3
0
U-Boot >

U-Boot >

1. Booting kernel from Legacy Image at c0700000 ...
   Image Name: Linux-3.2.0+
   Image Type: ARM Linux Kernel Image (uncompressed)
   Data Size: 2538568 Bytes = 2.4 MB
   Load Address: c0008000
   Entry Point: c0008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
   OK

Starting kernel ...

I've attached the system serial console output from the boot. It shows the system coming down, U-Boot starting up, then the hang with "Uncompressing Linux... done, booting the kernel."
After that, the system doesn't respond until I cycle power.

I'm hesitant to load the uImage into U-Boot flash if I can't get it to run from memory. Any suggestions?

Regards,

Ben

Is the bootargs environment variable set when you do the tftp boot?

U-Boot > print bootargs

Jonathan,

U-Boot > print bootargs
print bootargs
bootargs=mem=96M console=ttyS1,115200n8 mtdparts=nand:128M(rootfs),-(userfs) root=/dev/mtdblock0 rw,noatime rootfstype=jffs2
U-Boot >

Regards,

Ben

Alright thanks. Sometimes the bootargs aren't set.

I tried booting the uImage Bob posted and it hung for me too. I've re-uploaded the uImage and this one appears to work. Sorry for the trouble.

You can find it on the Files tab or I've included a link to it.
https://support.criticallink.com/redmine/attachments/download/10061/uImage

I booted the alpha filesystem over nfs. I've attached my 1st and 2nd bootlog. Note in the 1st bootlog you can see what I setup to get it to boot. Note in the 2nd bootlog my tftp command stalled out and I had to ctrl-c and run boot again. I'm not sure if this is a problem with my older devkit or a timing issue with the network driver in u-boot.

See https://support.criticallink.com/redmine/projects/arm9-platforms/wiki/Linux_Root_File_System#Boot-from-an-NFS-server for nfs setup.

Looks like with the new systemd boot, network is configured in /etc/systemd/network/eth0.network. See http://www.linuxfromscratch.org/lfs/view/systemd/chapter07/network.html

Jonathan,

I think we're getting somewhere now. The newest kernel is working better. I went back to the original, unmodified Critical Link JFFS2 FS and the new uImage kernel, and I no longer get the ipv6 messages, and I the /dev/ttyS1 serial console is operational, too.

The new kernel, however, cannot get the Ethernet PHY connected. I've attached the boot-up messages, and I think the key is this:

davinci_mdio davinci_mdio.0: phy[0]: device 0:00, driver unknown

Previously, with the old kernel, I got:

davinci_mdio davinci_mdio.0: phy[0]: device 0:00, driver SMSC LAN8710/LAN8720
   ... lots of messages ...
   net eth0: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=0:00, id=7c0f1)
   ... lots of messages ...
   PHY: 0:00 - Link is Up - 100/Full

What is necessary to get the LAN8710/LAN8720 hooked into my system?

Regards,

Ben

... and here is the boot message file.

The industrialio baseboard image expects the phy id to be 0:03. Your phy id appears to be 0:00. The kernel would need to be rebuilt with the correct phy id.

arch/arm/mach-davinci/baseboard-industrialio.c

static int __init baseboard_pre_init(void)
{
    pr_info("%s: Entered\n", __func__);
    da8xx_spi_pdata[1].chip_sel = spi1_cs;
    da8xx_spi_pdata[1].num_chipselect = ARRAY_SIZE(spi1_cs);
    davinci_soc_info.emac_pdata->phy_id = "0:03";
    return 0;
}

Note that if the phy_id variable is set to NULL, the kernel will use the first phy it discovers. Alternatively you could set this to "0:00".

It looks like your previous kernel was using the dbric3 baseboard defconfig. This baseboard does have the phy_id set to 0:00.

baseboard_init [dbric3]...

Jonathan,

Yes I am using the dbric3 hardware. Do you have a kernel image for it?

Regards,

Ben

Updated dbric3 defconfig to support systemd.
http://support.criticallink.com/gitweb/?p=linux-davinci.git;a=commit;h=1c88227846c09e6d482ebcc3b898b94dc05f3ae0

I setup the toolchain and built the kernel for you. See attached.

$ chmod +x /tmp/mitydsp-l138-MDK-base-2015-11-13.sh
$ sudo /tmp/mitydsp-l138-MDK-base-2015-11-13.sh
$ export PATH=/opt/criticallink/mityomapl138_20151114/sysroots/i686-clsdk-linux/usr/bin:/opt/criticallink/mityomapl138_20151114/sysroots/i686-clsdk-linux/usr/bin/arm-criticallink-linux-gnueabi:$PATH
$ make ARCH=arm CROSS_COMPILE=arm-criticallink-linux-gnueabi- dbric3_defconfig
$ make ARCH=arm CROSS_COMPILE=arm-criticallink-linux-gnueabi- uImage