Steve, Thanks for all your time on this subject. I know this very detailed, but as you said the NSP is complicated and not very straight forward with what needs to be modified, or what are the ramification to some changes. Nimu_eth.c We both agree no changes are necessary to this file. However, I believe the documentation is again out of date. Section 1.5 in the Design Driver Guide maps how the calls flow down through the layers. This appears to be outdated. Below I'll list what is in the Design Driver Guide, and then what I see in the NSP code. Even though you say EMAC_timerTick( ) only gets called in polling mode, based on what I see below, I don't see how EMAC_timerTick( ) ever gets called. Not an issue right now, as I'll stay with interrupt mode, but something isn't right. Guide: EmacInit -> HwPktInit Code: EmacInit -> HwPktInit -> EMAC_getConfig Guide: EmacStart-> HwPktOpen -> EMAC_open and MDIO_open Code: EmacStart -> HwPktOpen -> EMAC_open and MDIO_open and EMAC_initialize Guide: Emacioctrl -> HwPktSetRx -> EMAC_setReceiverFilter plus five other routines Code: Emacioctrl -> HwPktSetRx -> EMAC_setReceiverFilter Guide: EmacSend -> HwPktTxNext -> EMAC_sendPacket and EMAC_TxServiceCheck Code: EmacSend -> HwPktTxNext -> EMAC_sendPacket Guide: EmacPktService -> HwRxInt -> EMAC_RxServiceCheck Code: EmacPktService -> PBMQ_deq -> NIMUReceivePacket Guide: EmacPoll -> _HwPktPoll -> EMAC_TimerTick and MDIO_timerTick and MDIO_getStatus Code: EmacPoll -> _HwPktPoll -> MDIO_timerTick Ethdriver.c CORENUM. Still don't understand what this really does and why it needs to be 1 for the C6748. I looked briefly at the C6748 Tech Manual, and the EMAC section does define these "cores". There are three of them, and appear to be related to how the EMAC controller interrupts the DSP. Too far down the EMAC rabbit hole for me. I'll just take your word for it that it should be 1. EXTERNAL_MEMORY and EXTMEM. These two bother me. They are defined at the top of Ethdriver.c, thus the code in these routines are "trying" to do something. I can see on the BUFFERS tab from the *.cfg file where the PBM Buffers are defined. By default frames is 192, and size is 1536. Since this is buffer pool is larger than the L3 internal memory, it can't go there. The data section defined is indeed being placed in DDR2. Furthermore, the way the code is written, it appears that OEMCacheClean( ) will be called if the data section is placed in L3(0x80000000) or DDR2(0xC0000000). I can only speculate that these two variables are only for when the PBM Buffer will fit within L1D or L2, and of course you must force the PBM Buffer to reside in either of these memory sections. Bottom line, these appear to be very important and shouldn't be touched. PKT_MAX. Our application is going in a mission critical location. Therefore dropped RX or TX Ethernet frames need to be avoided. The links you provided don't really help me understand what are the downsides to increasing this number (aside from more memory used). I want to increase this number, but there must be some relation between this number and the frames + size you define in the PBM Bufffers *.cfg. With frames currently defined to be 192, and PKT_MAX defined to be 64, I'm not seeing the relationship. PKT_PREPAD. I understand your explanation. I agree I should just leave it alone, as memory space isn't an issue. RAM_MCST, HASH_MCST, and PKT_MAX_MCST. According to the Driver Design Guide, these appear to very hardware specific. Since this NSP was based on the OMAPL138, and I'm using the C6748, I'll just leave them alone and hope for the best. csl_emac.c I would still like some more explanation on EMAC_timerTick( ). Based on what I see from the NSP code, I can't see any way this gets called, even if the NDK is configured for polling mode. The good news, is it appears no code changes are necessary. csl_mdio.c Please continue to ask around about the variable macsel, and the VBUSCLK definition. The code that uses macsel appears to only care about GMII and RGMII, which seems odd. The code clearly loads a MDIO register with the VBUSCLK number, so it must be somewhat important. According to the C6748 Tech Manual, it looks like it may control the MDIO CLK frequency. Since the MDIO clock is only rated to run up to 2.5MHz, this divider could make the difference between MDIO working or not. emacHooks.c We haven't talked about this file yet, but I believe modifications are necessary. Remember this file was pulled (somewhat randomly) from one of the NSP example projects. EMAC_initialize( ) needs to be modified. I really don't understand what GPIO_CONTROL_REG and TIMER_GLOBAL_REG are doing. The pinmux stuff can go, as that is defined in our project in the GEL file or with the boot ROM (via the AISgen tool). Basically we define all our pinmux stuff up front, and don't change it during run time. Load CFGCHIP[3] is how you tell the EMAC you want MII or RMII (plus the proper pinmux settings). Hey, we found an important change location. This routine would also be a good location to make sure we fired a HW RESET pulse to the Ethernet PHY chip. We control the RESET via a GPIO pin, so we can setup the pulse here. EMAC_getConfig( ) needs to be modified. Basically this routine is poorly named, as all it really does is fetch the MAC address from our application. Where ever we store the MAC address, we should copy it into pMacAddr. Finally EMAC_linkStatus( ) needs to be modified. This tells our application when the Ethernet cable gets plugged / unplugged. Our application can react accordingly to those events. Thanks, Dean
↧