Activity
From 01/21/2015 to 02/19/2015
02/19/2015
- JC 10:48 AM Software Development: RE: MDK_2012-08-10 default configuration
- There also may be a small time penalty in having the kernel search for the phy. But this would need to be quantified to really claim it as a problem.
- JC 10:46 AM Software Development: RE: MDK_2012-08-10 default configuration
- I believe the phy address was set in an earlier version of the kernel and it was carried forward. There is also the case where the baseboard has a switch which identifies itself as multiple phy addresses and thus you would need to speci...
- FT 09:52 AM Software Development: RE: MDK_2012-08-10 default configuration
- Thanks Mike for answer.
I did not look at section 2.2 of TLK100PHP datasheet. It is my fault.
I read section "3.3 PHY address" where it said
"Because all the PHYAD[4:0] pins have weak internal pull-down resistors,
the default s... - MW 09:18 AM Software Development: RE: MDK_2012-08-10 default configuration
- Hi François,
In the datasheet for the TLK100PHP, Section 2.2 shows that the PHYAD0 pin has an internal pull-up, which is why it is reading a '1' (there are no pullups on the DevKit card, and we are tri-stating the MII_COL and RXD0-RXD... - FT 07:33 AM Software Development: RE: MDK_2012-08-10 default configuration
- I look at U-boot code and it doesn't explain what we are seeing.
When resetting the PHY device, only GPIO5[15] is activated with pin mux. Other pins are left 3-stated.
Look at line 113 of board/davinci/mityomapl138/mityomapl138.c. Al...
02/18/2015
- FT 04:59 PM Software Development: RE: MDK_2012-08-10 default configuration
- Thanks Jonathan to told me that I am not alone with that questioning.
The first revision of our custom board had a mistake and PHYAD4 what pulled-up instead of PHYAD1.
The PHYAD0 is not pulled is any direction (as on Industrial board... - JC 04:43 PM Software Development: RE: MDK_2012-08-10 default configuration
- François,
I too was confused about this but was unable to determine why the phy id becomes 0x03.
I checked the SoM schematic and the MII_COL pin is directly connected to the SoC with no pull ups.
U-boot specifically disables p... - FT 04:21 PM Software Development: RE: MDK_2012-08-10 default configuration
- Mike,
My reply is out of date but it is about that topic: PHY address configuration.
You said that PHY address is set to 0x03 on Industrial board.
When I look at 0-000268RI schematic, only PHYAD1 pin is pulled up. There is no p... - JC 03:59 PM Software Development: RE: Write to SharedMem from DSP and read it from ARM
- Pretty sure you have to flush the DSP cache after changing values.
- FC 03:48 PM Software Development: RE: Write to SharedMem from DSP and read it from ARM
- Hi,
I am trying to get the shared memory working as well (by writing from DSP side and reading back from ARM side) using the HelloWorld as a basis. But ARM side doesn't read back correct values. I am using the same stuff from here. It...
02/17/2015
- MA 11:41 AM Software Development: RE: Alter Ethernet MAC
- Thanks Jonathan, that's exactly what I was after.
- MW 11:41 AM Software Development: RE: Alter Ethernet MAC
- You might also try this technique, though I am not sure if the current version of the 3.2 kernel has this command line option implemented:
http://developer.ridgerun.com/wiki/index.php/How_to_pass_ethernet_address_to_linux_kernel_ether... - JC 11:26 AM Software Development: RE: Alter Ethernet MAC
- Mostafa,
We store the mac address on a eeprom on the SoM. The settings stored on this can be accessed using the factoryconfig command in U-boot. Beware that you can brick the SOM if you change some of the other fields. - Hi, is it possible to alter the 'burned-in' MAC address of an L138F? I know that I can change it using 'ifconfig eth0 hw ether XX:XX:XX:XX:XX:XX' once Linux is up and running but was wondering if it's possible to make this change persist...
01/30/2015
- JM 10:35 PM PCB Development: RE: MityARM-1808F SATA connection problem
- The SW developer told me the kernel version is 2.6.34
Does that affect the quality of link?
01/23/2015
- SN 03:21 AM Software Development: RE: Write to SharedMem from DSP and read it from ARM
- Hi mike
your are rigth. I tried it before the
map= (int *)(mmap(0,MAPPED_SIZE,PROT_READ|PROT_WRITE,MAP_SHARED,_fdmem,DDR_RAM_PHYS));
and forgot to correct it back.. Its working now, thanks alot..
01/22/2015
- MW 07:32 AM Software Development: RE: Write to SharedMem from DSP and read it from ARM
- No you don't need ot use SetSharedMemCfg() or SetPoolCfg() if you are not using the tcDspInbound and tcDspOutbound message passing frameworks.
If you look at the dspapp.cpp file in the MDK, you will see the following parameters: - SN 03:57 AM Software Development: RE: Write to SharedMem from DSP and read it from ARM
- Hi
do i need to use
int tcDspApp::SetSharedMemCfg(tsSharedMemCfg* pConfig)
or
int tcDspApp::SetPoolCfg(uint32_t anNumBufPools, uint32_t *apBufSizes,
uint32_t *apNumBuf, bool abExactMatch)
to use the Iram at 0... - SN 01:59 AM Software Development: RE: Write to SharedMem from DSP and read it from ARM
- Hi thanks for the help, I still got some problems with reading on the ARM.
ARM code: