저도 몇일전에 dm9000a를 사용해봤습니다. uboot의 경우는 tftp시 멈추는 현상이 생기더군요..원인은 귀찮아서, 쓰는데 큰지장이 없어서, 그럴러니 하고 있습니다.

리눅스에서는 전혀 그런문제는 없는것 같습니다.
리눅스에서는 ping -f로 몇백만개의 패킷을 날려봐도, drop은 하나도 없었습니다. 그리고, netperf로 벤치마크할때도, 문제가 발생하지 않았습니다.
ifconfig에서 확인한결과 모든 패킷이 정상이었습니다.

그리고, dm9000a가 16비트 버스에도 불구하고 속도가 잘나오더군요
간단한게 결과를 알려드리면, ftp로 2440의 램디스크에 있는 6메가짜리 파일을 리눅스 서버로 업로드할대 초당 4.7메가바이트가 나왔습니다. 다운로드는 업로드보단 30%~40% 정도 작게 나왔습니다.
이 속도가 나오기 위해서, 버퍼에 데이터 쓰는 루틴이 for로 되어있는것을 writesw로 고쳤습니다. 이것만해도 약 50%는 빨라지는것 같더군요
그리고, 하드웨어 crc기능을 온시켰더니, 이건 속도향상이 몇%안되더군요

uboot에서 잘안되는 부분은 계속 찝찝하네요.

dm9000b로 바꾸세요....--;

예전서부터 문제가 되던게 phy쪽 reset인데, 같은 증상인 듯 하네요...
요번에야 답을 받았는데, dm9000b로 바꾸랍니다......쩝

아래 내용은 Divcom에서 보내온 회신 내용입니다.

---------------------------------------------------

다름이 아니라 DM9000A의 Reset Fail 과 관련된

Issue에 대해서 본사로부터 회신이 왔습니다.

저의 본사로부터의 의견은 DM9000B를 사용하라는 것입니다.

DM9000B는 DM9000A와 Pin to Pin 이며 DSP PHY가 사용된다는

것입니다.

따라서 DM9000B를 사용하게 되면 하드웨어를 변경할 필요 없이

Bus driving capability (REG_38H)를 6mA로 수정해 주면 된다는

것입니다.

-----------------------------------------------------------

그 부분에 대해서 지속적으로 본사 엔지니어가 수정을 했지만 결국 회신 내용은 이렇게

나오네요.. 11월달에 나온다고 하시니 그때가지 기다리시는게 좋을것 같습니다.

앞서 말씀 드리지만... aesop 2440 -3rd보드에 처음 적용했던게 DM9000A였습니다.
하지만 문제가 발생해서 결국 3차 공제 끝나고 나서 대만 본사 엔지니어가 와서 확인하고
디버깅을 하였지만 위에 글 처럼 결국은 DM9000B로 사용하라고 왔네요.

DM9000B 역시 확인을 해봐야 알겠지만 어떻게 될지 모르겠습니다.

답변 감사 합니다 많은 도움이 되었습니다.

참 글구 웹에서 다운받은 드라이버 에서 인터럽트와 ioaddr 말구는 수정할거 없는거죠?

저는 작년말에 따로 받은 것을 가지고 했었습니다만, 크게 수정할 것은 없으리라고 생각이
되네요.

커널 드라이버는 커널 버전에 따라 platform device는 맞춰줘야 할 듯 하고요.

aesop 2440 suspend 적용된 커널에 아마 드라이버가 있을 듯 하네요....

함 dm9ks.c란 녀석이 잇으면 그 녀석을 참고해서 쓰시면 됩니다.

DM9000B 로 바꾸니까 잘 됩니다 ^^;

DM9000A 가 문제가 있나 봅니다.

도움을 주신분들께 감사드립니다.

실례지만 DM9000B는 어디서 구하셨는지요?
아직 Mass Product은 아닌 것 같은데
샘플을 얻으신 건가요?

하드웨어 하신분 한테 물어보니
대리점에서 샘플로 받았다고 하던데요