Project

General

Profile

gcc 4.8 for OMAP-L138

Added by Ben Atkinson over 4 years ago

Our group has a strong desire to use gcc 4.8 to compile for the ARM926EJ-S on the OMAP-L138. We want to take advantage of C++11 thread support that is in 4.8. The arm-angstrom-linux-gnueabi-gcc we have been using is gcc 4.5.4, and it has only limited support for C++11 threading.

Our build machine is Ubunutu 14.04 LTS, and I explored getting the gcc-arm-linux-gnueabi package from the Ubuntu repo, but the gcc you get with that is version 4.7. Gcc 4.7 is no better than version 4.5 with respect to C++11 concurrency. The Ubuntu gcc-arm-linux-gnueabihf package is gcc 4.8, but the ARM926EJ-S doesn't have an internal hardware floating point unit, so gnueabihf doesn't seem appropriate, either.

I found a how-to using crosstool-ng to build gcc 4.8 for the ARM926EJ-S, but before I go down that path, I wanted to check with you. Is there is a more straightforward way of getting open-source gcc 4.8 (and runtime libraries) for the OMAP-L138 ARM?

Thanks for your help.

Regards,

Ben


Replies (26)

RE: gcc 4.8 for OMAP-L138 - Added by Bob Duke over 4 years ago

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

RE: gcc 4.8 for OMAP-L138 - Added by Ben Atkinson over 4 years ago

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

RE: gcc 4.8 for OMAP-L138 - Added by Jonathan Cormier over 4 years ago

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.

RE: gcc 4.8 for OMAP-L138 - Added by Bob Duke over 4 years ago

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

$ sudo tar xjvf filename.tar.bz2

RE: gcc 4.8 for OMAP-L138 - Added by Ben Atkinson over 4 years ago

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

RE: gcc 4.8 for OMAP-L138 - Added by Jonathan Cormier over 4 years ago

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.

RE: gcc 4.8 for OMAP-L138 - Added by Ben Atkinson over 4 years ago

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

RE: gcc 4.8 for OMAP-L138 - Added by Jonathan Cormier over 4 years ago

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?

RE: gcc 4.8 for OMAP-L138 - Added by Ben Atkinson over 4 years ago

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

RE: gcc 4.8 for OMAP-L138 - Added by Jonathan Cormier over 4 years ago

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/*

Kernel was built with gcc version 4.5.4 according to bootlog. Modules where built using gcc 4.8 from yocto. Thus the gcc symbols don't match.

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

RE: gcc 4.8 for OMAP-L138 - Added by Ben Atkinson over 4 years ago

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

RE: gcc 4.8 for OMAP-L138 - Added by Jonathan Cormier over 4 years ago

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?

RE: gcc 4.8 for OMAP-L138 - Added by Ben Atkinson over 4 years ago

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

RE: gcc 4.8 for OMAP-L138 - Added by Bob Duke over 4 years ago

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)?

RE: gcc 4.8 for OMAP-L138 - Added by Ben Atkinson over 4 years ago

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

RE: gcc 4.8 for OMAP-L138 - Added by Bob Duke over 4 years ago

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

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

RE: gcc 4.8 for OMAP-L138 - Added by Ben Atkinson over 4 years ago

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 >

U-Boot > tftp 0xC0700000 192.168.15.11:uImage
tftp 0xC0700000 192.168.15.11:uImage
Using device
TFTP from server 192.168.15.11; our IP address is 192.168.15.10
Filename 'uImage'.
Load address: 0xc0700000
Loading: ################################################################# ################################################################# ###########################################
done
Bytes transferred = 2538632 (26bc88 hex)
U-Boot > bootm 0xC0700000
bootm 0xC0700000
  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

RE: gcc 4.8 for OMAP-L138 - Added by Jonathan Cormier over 4 years ago

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

U-Boot > print bootargs

RE: gcc 4.8 for OMAP-L138 - Added by Ben Atkinson over 4 years ago

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

RE: gcc 4.8 for OMAP-L138 - Added by Jonathan Cormier over 4 years ago

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

RE: gcc 4.8 for OMAP-L138 - Added by Ben Atkinson over 4 years ago

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

RE: gcc 4.8 for OMAP-L138 - Added by Ben Atkinson over 4 years ago

... and here is the boot message file.

RE: gcc 4.8 for OMAP-L138 - Added by Jonathan Cormier over 4 years ago

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]...

Are you using the dbric3 custom hardware?

RE: gcc 4.8 for OMAP-L138 - Added by Ben Atkinson over 4 years ago

Jonathan,

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

Regards,

Ben

RE: gcc 4.8 for OMAP-L138 - Added by Jonathan Cormier over 4 years ago

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

uImage (2.1 MB)

(1-25/26)
Add picture from clipboard (Maximum size: 500 MB)