• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 101 subscribers
  • Views 1577 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP-L137 EVM: Disable audio/I2C, but still have Ethernet

Graeme
Prodigy 170 points
Other Parts Discussed in Thread: OMAP-L137, DA8XX, OMAP-L138

In order to avoid conflicts in the use of peripherals for a DSP audio application for the OMAP-L137 EVM, I have disabled the audio and I2C drivers as per the instructions here. Unfortunately a side effect of this is that I no longer have Ethernet connectivity. When booting, I get the following error:

MAC address is deadbeaf

...

Setting up networking ....
/etc/network/options is deprecated.
Setting up IP spoofing protection: rp_filter done.
Disabling IPv4 packet forwarding: done.
Disabling TCP/IP Explicit Congestion Notification: done.
Starting network interfaces: Error, dhcpStart: ioctl SIOCGIFHWADDR: No such device
Failed to bring up eth1.

I have not had a lot of time to look into this issue, however it would be very helpful if we could still have Ethernet on the board. Looking at the schematics for the board, there seems to be some MUXing between the Ethernet and McASP pins which might explain the problem. Also I'm not sure if I2C is used to communicate with other chips used for Ethernet.


Can someone please advise on how to have Ethernet enabled without audio/I2C, and/or if it is even possible.

  • 0
    TI__Guru** 116100 points

    Hi Graeme,

    What SDK version are you using ?

    If your board is OMAPL137 EVM board then it would work directly without any issues.

    Have you called "da8xx_register_emac()" function to initialize the EMAC (ethernet) ?

    Could you please share your complete bootup log.

  • 0 in reply to Titusrathinaraj Stalin
    Prodigy 170 points

    7838.boot.log

    Hi Titusrathinaraj,


    The SDK version that I am using is 1.00.00.11.

    How should I call da8xx_register_emac() ? Should there be a program which calls this a boot time?


    Boot log attached.

  • 0 in reply to Graeme
    TI__Guru** 116100 points

    Hi Graeme,

    Starting kernel ...
     
    Uncompressing Linux................................................................................................................... done, booting the kernel.
    Linux version 2.6.18_pro500-da830_omapl137_evm-arm_v5t_le (graeme@graeme) (gcc version 4.2.0 (MontaVista 4.2.0-16.0.32.0801914 2008-08-30)) #1 PREEMPT Tue Aug 12 12:32:04 BST 2014
    CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
    Machine: DaVinci DA8XX EVM

    From bootlog,

    You are using the very oldest SDK, so please try to use latest SDk which has default support for all the peripherals such as ethernet, SPI, etc.,

    http://software-dl.ti.com/sdoemb/sdoemb_public_sw/mcsdk/latest1/index_FDS.html

  • 0 in reply to Titusrathinaraj Stalin
    Prodigy 170 points

    The release notes for this SDK only mention support for the OMAP-L138, whereas I am using the OMAP-L137. Does this make a difference?

  • 0 in reply to Graeme
    TI__Guru** 116100 points

    This SDK supports OMAPL137 too.

    Actually it support for OMAPL13x.

    It is running on my OMAPL137 EVM board.

  • 0 in reply to Titusrathinaraj Stalin
    Prodigy 170 points

    Ok, but on the DSP side we are using the PSP drivers (hence the reason for disabling audio on the Linux side). According to the download page for the drivers the latest version is only compatible with DSP/BIOS 5.x which as far as I know is only compatible with DSPLink for inter-processor communication.


    Looking at the manifest for the updated SDK, I see that it contains only SYSLink and IPC. From what I understand, I would need to use DSPLink to communicate with the DSP, so are the kernel drivers etc compatible with this?


    Ultimately I need to be sure that I will still be able to communicate with the DSP if I use this SDK. Note also that the current test applications we have used the SIO streaming API in DSP/BIOS, which I believe has been removed in SYS/BIOS, so upgrading on the DSP side would be difficult even if there are drivers available.

    Best,


    Graeme

  • 0
    Guru 26430 points

    On the OMAP-L137 EVM, the MAC address is stored in the I2C EEPROM. You will need to get the MAC address from somewhere else. The newer kernels automatically create a random MAC address if one is not available. Your kernel is very old. As a test you can hard-code the addr to something reasonable in arch/arm/mach-davinci/i2c-emac.c. The upside of using an old kernel is that the "eth=" bootarg is still supported. So you can try add "eth" to bootargs in u-boot.

  • 0 in reply to Norman Wong
    Prodigy 170 points

    Thanks Norman, excellent suggestion. Setting the "eth" boot argument fixes the problem and is probably preferable if you have multiple EVM boards and saves recompiling the kernel for each. Although note that my attempt with an arbitrary MAC address did not work, it seems that you have to use the one which is presumably hard coded into the Ethernet chip on the board (and is retrieved via I2C). This should already be in the "ethaddr" environment variable in Uboot if it has been configured properly.

  • 0 in reply to Graeme
    Guru 26430 points

    I've been in much the same position. I started with the EVM with Montavista and 2.6.18 and updated first to CodeSourcery and 2.6.32. Updated several times after that. The newer kernels works much better. And I did use DSPBIOS and DSPLINK on the later kernels. Even 2.6.32 is considered old.

    The code in arch/arm/mach-davinci/i2c-emac.c would suggest the bootarg is "eth". The "ethaddr" is the u-boot environment variable. I believe u-boot also gets the MAC address from I2C and saves it in the "ethaddr" variable. Could be wrong. It's been a few years since I worked on this EVM.

  • 0 in reply to Norman Wong
    Prodigy 170 points

    Thanks Norman, good to know. My concern with DSPLink was that, on the download page, the link to the second newest version says 'Updated to 2.6.37 kernel, bug fixes' and the newest only seems to be a small increment from that. Going from a 2.6 kernel to a 3.x kernel seems like a big step for compatibility. What improvements have you seen with the newer kernels?


    I never realised Uboot did I2C, I just assumed this would have been hardcoded. Good to know as well, thanks, I may investigate further at a later date.

  • 0 in reply to Graeme
    Guru 26430 points

    The u-boot code for I2C MAC address retrieval appears to be in file board/davinci/dv-evm/dv_board.c, function misc_init_r(). You'll have to set the ethaddr env var manually before using network commands within u-boot. If you have a backing store (eg. NAND) for u-boot env vars, I guess you could save the MAC addr in the env vars permanently.

    In my opinion, do not update the kernel unless you are having problems. For me, the update to 2.6.18 to 2.6.32 was required to get the updated USB and GPIO drivers. Also getting support on this forum is easier with the latest kernel. The jump from 2.6.32 to 2.6.37 or 3.x kernel was not worth for me. I think the pre-built kernels only go up to 2.6.37. The 3.x are a source pull at the TI's Arago GIT. I forgotten how the linux kernel numbers map to the TI PSP version numbers.