Hi,
Does the IBL initialize the SGMII registers. What I am seeing is that the emac_open function executes just fine when I run the 6657l.gel file during connection. When I run my program from NAND flash using the IBL I am stuck in the emac_open function. If I go into memory and configure the CFGPLL, CFGRXO and CFGTXO to the values found in the .gel file I exit this function and my program runs fine. Does the i2cConfig.gel file which is loaded using the steps I found on the BIOS MCSDK2.0 wiki page configure the SGMII or is this something I have to do in my code. What does the IBL configure exactly so I know what else to configure if the IBL gel file does not configure the SGMII
Thanks,
Will
I also want to add:
I have been looking through the emac_drv.c code and what I have found is a difference between the address of the TX_CFG, RX_CFG, and the AUX_CFG. In the PDK package, TX_CFG is located at 0x2c08930, RX_CFG is at 0x2c08934 and AUX_CFG is at 0x2c08938. When looking at the 6657.gel file, TX_CFG is at 0x2620348, RX_CFG is at 0x2620344, and AUX_CFG is at 0x2620340. When I fill in TX,RX,and AUX values at the gel file locations, I am able to get a lock and everything works fine. Please advise.
No, the IBL doesn't initialize EMAC. The configuration of SGMII should be done by your program unless you're specifically using EMAC boot, in which case the bootloader would configure it. You could write an IBL that configured it, but that's not what's the IBL that is being provided is doing.
Best Regards,Chad
------------------------------------------------------------------------------------------------------------
Please click the Verify Answer button on this post if it answers your question.
Hi Chad,
So I am running a ethernet program that used the client example as a starting point. It looks like the emac is attempting to configure the sgmii but I get stuck in a while 1 loop. Basically its waiting for the link to come up. It appears although the emac is configured with the correct values which match the .gel file values, the addresses are different. The emac writes to the emac memory map registers (0x2c08900) where as the .gel file writes to the chip registers (0x2620340). Shouldn't the emac registers be memory mapped to the chip registers? When I try to write to the chip registers directly, it fails. I write to the address but the value never takes. The only work-around I can think of is to write to the chip registers during the emac_open function, just prior to checking for the link. When I am in the while 1 loop in the emac_open function, I can go into the memory window and write the correct values to the chip registers and everything runs fine. My problem in making this work-around work is that I don't know how to re-build the emac driver library.
The 0x02620340 is going to have the SGMII SERDES PLL Config Registers, while the 0x02C08900 is going to part of the EMAC configurations registers. The EMAC driver wouldn't typically be configuring the SERDES PLL Config as it would expect that it was already configured (input clocks will vary from board design to board design and the PLL settings must be done specific to the board design.)
Best Regards,
Chad
So when I look at the emac_drv.c, in the emac_open function, it appears that the function is trying to configure the sgmii but the addresses point to the emac location and not the chip registers. The emac_open function also configures the emac. The way I have made this work is that prior to starting the ethernet thread, I power on the emac using the Set_PSC_State function from the 6657.gel file. I then write to the CFG_PLL, CFGRXO, and the CFG_TXO registers at 0x2620340, 344, and 348. I then run the ethernet thread and everything works. It just seems that if the emac_open function is attempting to initialize the sgmii, then the pointers should point to the chip registers and not the emac registers.
Will,
In general each IP has it's own set of registers, that are separate from the Chip Registers. In this case the EMAC registers are all with the EMAC and the SGMII PLL are part of the chip register. There is documentation which discusses the need to configure the SGMII PLL. This is going to be specific to the HW implementation (i.e. what clock inputs you used) while the EMAC driver functionality is a bit more generic and assumes the PLL's are already configured.
Sorry for any confusion.