W dniu 3.03.2024 o 14:37, Atlantis pisze:
> On 3.03.2024 13:56, Jarosław Sokołowski wrote:
>
>> 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ć.
>
> 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.

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.


--
Janusz

do góry

On 03/03/2024 14:37, Atlantis wrote:
> Zamówiłem w TME
> lepsze rezonatory 25 MHz.

Rozglądnij się za generatorami. Zazwyczaj mają lepszą stabilność, a cena
+5zł nie gra roli w amatorce.

do góry

On 3.03.2024 16:17, heby wrote:

> 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ć. :)

do góry

Atlantis napisał:

> 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ć. :)

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.

--
Jarek

do góry

Atlantis <m...@w...pl> napisał(a):
> 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.

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

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On 3.03.2024 17:17, Jarosław Sokołowski wrote:

> 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.

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.

do góry

On 3.03.2024 17:26, Grzegorz Niemirowski wrote:

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

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

do góry

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.
>
> Sądząc po logach nie jest w stanie.
>
> # dmesg | grep eth
> at91_ether: Your bootloader did not configure a MAC address.

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.

> // Tutaj pobiera MAC z /etc/network/interfaces
> eth0: Setting MAC address to 00:01:20:38:00:5b
> eth0: Link now 10-FullDuplex

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 uboota mac jest widoczny. Można z poziomu uboota pobrać adres
> z DHCP i zainicjować TFTP.

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.

--
Jarek

do góry

On 3.03.2024 18:13, Jarosław Sokołowski wrote:

> 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).

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.


> 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.

Ż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)

do góry

Atlantis napisał:

> Żadnego pliku *.dtb nie widzę na karcie pamięci ani w katalogu /boot.

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:
https://en.wikipedia.org/wiki/%C3%85ngstr%C3%B6m_dis
tribution

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.

> Kernel pokazuje jednak dużo większą pamięć:
>
> at24 0-0050: 131072 byte 24c1024 EEPROM (writable)

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.

--
Jarek

do góry