niedziałające SSH

I rujnuje. Pingi. Doczytaj wątek.

Na pierwszy rzut oka, wizualnie wszystko wygląda ok. Wymieniłem gniazdko RJ-45, na wypadek gdyby coś było nie tak z nim, albo ze zintegrowanym trafem.

Przypomniałem sobie jeszcze, że pomiędzy moja płytką i schematem jest bardzo drobne odstępstwo. Na schemacie mamy pięć rezystorów podciągających linie PHY0..PHY4 do masy oraz 3,3V. Oryginalnie mają one wartość 1.9k. Nie miałem tej wartości, więc zastosowałem najbliższą -

1.96k. Nie wydaje mi się, żeby w tym przypadku miało to krytyczne znacznie. Podczas inicjacji układu stany tych pinów określają adres układu PHY, a podczas normalnej pracy są wykorzystywane jako wyjścia sterujące diodami.

Sprawdzę jeszcze raz połączenia i na wszelki wypadek wymienię kwarc i kondensatory w pobliżu RJ44, na wypadek gdybym pomylił ich wartości.

Generalnie najwięcej wyjaśniłoby, gdyby udało mi się skończyć składać drugi egzemplarz (brakuje mi gniazdka SD oraz układu PHY) wtedy wiedziałbym czy problem również tam występuje (to wskazywałoby na software'ową przyczynę) czy nie (problem z montażem/wadliwym elementem na pierwszej płytce).

Swoją drogą zastanawia mnie jeszcze jedna kwestia. Widzę, że autor projektu zdecydował się podciągnąć linie sygnałowe I2C (za pomocą których podłaczony jest EEPROM) do 3,3V za pomocą rezystorów 1,5k. To nie za mało? Czy przypadkiem w przypadku tego interfejsu nie stosuje się zwykle 4,7k?

Na pierwszy rzut okaz wygląda to ok. Na wszelki wypadek wymieniłem złącze RJ45 (ze zintegrowanym trafem), ale też nie przyniosło to żadnej zmiany. Obejrzę jeszcze raz dokładniej połączenia, poprawię luty i wymienię kondensatory przy RJ45. Jeśli to nie pomoże i kwarc również okaże się sprawny, to nie mam pomysłu innego jak uwalony układ PHY, a innego egzemplarza niestety nie mam.

Gdyby wina leżała po stronie układu MAC w strukturze AT91, albo ewentualnie magistrali RMII, to zapewne sieć w ogóle nie chciałaby działać...

Zbiorę do plików wyniki z kilku testów i porównam je.

Jeśli sytuacja będzie wyglądała w ten sposób, to gdzie można szukać potencjalnej przyczyny?

Atlantis snipped-for-privacy@wp.pl napisał(a):

Zwykle stosuje się tyle, ale to nie jest jakaś jedyna słuszna wartość. Im wartość jest mniejsza, tym transmisja może być szybsza, bo łatwiej są przeładowywane pojemności pasożytnicze. Z drugiej strony trzeba brać pod uwagę wydajność prądową pinów podłączonych do szyny w momencie, gdy ściągają ją do masy. Odpowiednie wzory znajdziesz np. tu:

Ok, powtórzyłem test dziesięć razy, zapisując wyniki w plikach tekstowych. Diff pokazuje, że wyniki nie są identyczne. Zawartość plików zgadza się w jakichś 95%. Wynika to jednak głównie z tego, że początek jest poprawny, a od pewnego momentu zaczynają lecieć same minusy. Jednak miejsce pierwszego wystąpienia problemu wypada w różnym punkcie, a "okresy przejściowe" też się różnią między sobą.

Podpiąłem oscyloskop. Nie udało mi się zmierzyć częstotliwości na kwarcu, ale na pinie rx_clk mam 2,50557 MHz (zgodnie z dokumentacją dla

10Mbps powinno być 2,5 MHz). Czy ta odchyłka może powodować problemy z przesyłaniem większych pakietów?

Przy założeniu, że dla 100 Mbps będziemy mieć 25,0557 MHz, może to tłumaczyć problemy z wynegocjowaniem połączenia z taką prędkością?

Atlantis pisze:

Różnica około dwóch promili. Bez wdawania się w szczegóły działania ethernetu, można zauważyć, że jak trybiki jednego kółka w przekładni zębatej będą węższe o dwa promile, to na długości pięciuset ząbków nastąpi przesunięcie o jeden. Zdaje się, że przy MTU koło 500 coś się zaczyna rypać.

A tu ząbki jeszcze drobniejsze. Ja bym zaczął od próby skorygowania zegara. Jak nie przez wymianę kwarcu, to może jakąś pojemnością.

Jarek

Udało mi się wygrzebać w podręcznych zapasach inny kwarc 25 MHz. Po jego wlutowaniu częstotliwość rx_clk zmieniła się na 2.50042 MHz. Problem z połączeniem SSH zniknął, a test z pingami albo daje całkowicie pozytywny rezultat, albo przechodzi z jednym minusem pod sam koniec.

Interfejs ciągle nie zestawia jednak połączenia na 100 Mbps.

Wygląda na to, że to potwierdza winę po stronie kwarcu. Zamówiłem w TME lepsze rezonatory 25 MHz. Zobaczę czy to rozwiąże sprawę.

Czyli znalazłeś rozwiązanie, które jak widać było nietrywialne. Gratulacje :) Z tego wynika że ta transmisja jest jednak trochę skopana bo transmitując 'ciurkiem' bajty może się ona rozjeżdżać co widać na tym przykładzie, wg mnie powinny być bajty oddzielone stopem jak w rs-ie aby odbiornik mógł się synchronizować na początek bajtu, oczywiście byłaby strata na transmisji 1/8 ale za to bardziej by była odporna na fluktuacje zegara.

Rozglądnij się za generatorami. Zazwyczaj mają lepszą stabilność, a cena

+5zł nie gra roli w amatorce.

W swoich własnych projektach Ethernetem od dawna stosuję generatory SMD. Jednak tutaj cóż... Płytka jest już gotowa i wolą unikać konstrukcji "na pająka". Będę musiał poszukać lepszego rezonatora. Mam nadzieję, że któryś z tych z TME trafi już we właściwą częstotliwość i błędy znikną całkowicie oraz możliwa stanie się praca w trybie 100 Mbps.

Pozostaje jeszcze kwestia drugiego błędu - dlaczego Linux nie jest w stanie załadować adresu MAC z pamięci I2C (muszę go ręcznie podać w /etc/network/interfaces). Jedak z tym już mogę żyć. :)

Atlantis napisał:

Nie jest w stanie, czy nie żąda się tego od niego? Adres MAC może być opisany w Device Tree (plik *.dtb), definiowany przez wartość zmiennej uboota itd. To się samo nie robi.

Atlantis snipped-for-privacy@wp.pl napisał(a):

Tutaj nie trzeba nadziei, tylko kwarca o toleracji poniżej 100 ppm.

Sądząc po logach nie jest w stanie.

# dmesg | grep eth at91_ether: Your bootloader did not configure a MAC address. eth0: Link now 10-FullDuplex eth0: AT91 ethernet at 0xfefbc000 int=24 10-FullDuplex (00:00:00:00:00:00) eth0: STE100P PHY // Tutaj pobiera MAC z /etc/network/interfaces eth0: Setting MAC address to 00:01:20:38:00:5b eth0: Link now 10-FullDuplex

W zmiennej uboota mac jest widoczny. Można z poziomu uboota pobrać adres z DHCP i zainicjować TFTP.

No i te które kupiłem mają mieć 30ppm. Mam nadzieję, że rzeczywistość odpowiada deklaracjom. ;)

Atlantis napisał:

Z tego nie wynika, jakie były przyczyny. Komunikaty dmesg pochodzą już od linuksa pełną gębą, a tu chodzi o ten bootloader. Domyśliłem się, że o uboot.

Może to szczegół, technicznie na pewno bez znaczenia, ale ten MAC należy do firmy OSCILLOQUARTZ S.A. Rue Des Brevards 16, 2002 Neuchatel Switzerland. Na wstępie przeczytałem, że komputerek polski, więc zapewne MAC wyssany z palca, przypadkiem akurat na tych Szwajcarów trafiło. Jeśli nie ma się własnych adresów, lepiej trzymać się puli prywatnej -- xP:xx:xx:xx:xx:xx, gdzie P należy do zbioru (2, 6, A, E).

W zmiennej może być, ale uboot (ten konkretny) niekoniecznie musi chcieć brać akurat z tej zmiennej. Jest tam jakiś plik *.dtb? Informacje z niego można wyciągnąć poleceniem fdtdump.

Dokładnie taki adres był ustawiony w zmiennej uboota, więc po prostu przepisałem go do /etc/network/interfaces. Jak tam się znalazł, nie mam pojęcia. Może taki adres losowo wybrał autor polskiego komputerka, może sam uboot został przeniesiony z jakiegoś innego projektu, razem z adresem. Mogę go zmienić na coś z innej puli. Zresztą jest bardzo mało prawdopodobne, że urządzenie zostanie kiedykolwiek uruchomione poza moim domowym LAN-em.

Żadnego pliku *.dtb nie widzę na karcie pamięci ani w katalogu /boot. Sam u-boot jest wgrany do pamięci SPI flash i przy rozruchu ładowany do RAM-u przez bootlader niższego stopnia.

Oryginalny artykuł bardzo lakonicznie wypowiada się na temat adresu MAC i przeznaczenia pamięci I2C EEPROM:

"W mikrokomputerze wykorzystano również szeregową pamięć EEPROM z interfejsem I2C. Na rys. 3 jest to układ IC4. Linie interfejsu wymagają użycia rezystorów podciągających. Rolę tę pełnią R4 i R5 (rys. 2). Zastosowano pamięć typu AT24C08 o pojemności 1 kB. Jest ona używana m.in. do zapamiętania adresu MAC karty sieciowej."

Swoją drogą, tutaj jeszcze jedna rzecz rzuciła mi się w oczy. Wspomniany wyżej artykuł w "EP" mówi o AT24C08 i dokładnie takiego elementu użyłem. Kernel pokazuje jednak dużo większą pamięć:

at24 0-0050: 131072 byte 24c1024 EEPROM (writable)

Atlantis napisał:

Może zniknął gdzieś w ferworze walki? Na początku przeczytałem, że chodzi o "Angstrom Linux". Nazwa zupełnie nic mi nie mówi, ale doczytałem:

Producent komputerka zapewne traktował dystrybucję jako źródło binarek i z nich coś sklecił. Być może sam chip jest na tyle prosty, że bez opsania device tree może jako tako ruszyć. A może opis jest gdzie indziej? Prjektant mógł skorzystać z recept Yocto, które zapewne wtedy jeszcze były dostępne. I przygotować wszystko zgodnie z rzeczywistością wyznaczoną przez hardware. O tym Yocto zresztą niedawno coś tu wspominałem, a nawet zachęcałem do niego.

Przez "kernel pokazuje" zwykle rozumiem coś z /sys/*. To jest komunikat, który nawet nie wiem skąd pochodzi. Ale może zgodnie z moimi wcześniejszymi podejrzeniami binaria nie odpowiadają sprzętowi. To mogło zostać gdzieś (w uboot?) wkompilowane.