Печать

Пожалуйста, войдите или зарегистрируйтесь.
1 час 1 день 1 неделя 1 месяц Навсегда

[speculzzz]

Поставьте на host сетевой сканер (http://www.wireshark.org/) и посмотрите пакеты с MAC-адресом платы.

Имеем:
192.168.1.82 - комп
192.168.1.85 - девайс
Запускаем на девайсе ping 192.168.1.82. Смотрим в "Акуле":

Код: [Выделить]

No. Time Source Destination Protocol Info
1 0.000000000 ff:2b:d4:3c:fc:3b Broadcast ARP Who has 192.168.1.82?  Tell 192.168.1.85
2 0.000034000 Intel_79:2c:3a ff:2b:d4:3c:fc:3b ARP 192.168.1.82 is at 00:0c:f1:79:2c:3a
3 0.999915000 ff:2b:d4:3c:fc:3b Broadcast ARP Who has 192.168.1.82?  Tell 192.168.1.85
4 0.999942000 Intel_79:2c:3a ff:2b:d4:3c:fc:3b ARP 192.168.1.82 is at 00:0c:f1:79:2c:3a
Т.е. по какой-то причине в момент пинга вместо протокола ICMP используется ARP, и у всех в сети начинает спрашивать "Кто такой 192.168.1.82? Скажите 192.168.1.85". В ответ комп ему отвечает "192.168.1.82 имеет такой-то мак". И так по кругу...
Запускаем на компе ping 192.168.1.85. Смотрим в "Акуле":

Код: [Выделить]

No. Time Source Destination Protocol Info
5 113.765397000 192.168.1.82 192.168.1.85 ICMP Echo (ping) request
6 119.152446000 192.168.1.82 192.168.1.85 ICMP Echo (ping) request
Т.е. идет нормальный "пинг", на который никто не отвечает.

Роут на девайсе вроде нормально настроен:

Код: [Выделить]

/ # route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     0      0        0 eth1
127.0.0.0       *               255.0.0.0       U     0      0        0 lo

Я в этой "сетевой" сфере имеют только общие понятия... и где "копать", имея подобную информацию даже и не подозреваю :(. Может среди уважаемого сообщества найдется человек, который сможет указать "верное направление"...

[asv]

Тион: 86:1a:4d:99:6e:46 10.42.42.131
PC: AsustekC_2c:88:a7 10.42.42.199

1   0.000000   86:1a:4d:99:6e:46   Broadcast   ARP   Who has 10.42.42.199?  Tell 10.42.42.131
2   0.000037   AsustekC_2c:88:a7   86:1a:4d:99:6e:46   ARP   10.42.42.199 is at 00:22:15:2c:88:a7
3   0.000211   10.42.42.131   10.42.42.199   ICMP   Echo (ping) request
4   0.000245   10.42.42.199   10.42.42.131   ICMP   Echo (ping) reply

Возможно, у вас на плате пакеты не принимаются?

[speculzzz]

Т.е. два варианта:
1) физический
2) что-то не так в драйвере
????
Система на такое поведение не влияет?

Код: [Выделить]

eth1      Link encap:Ethernet  HWaddr FF:2B:D4:3C:FC:3B
          inet addr:192.168.1.85  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:50088 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3908781 (3.7 MiB)  TX bytes:756 (756.0 B)
          Interrupt:34 Memory:71000300-7100030f
Счетчик RX постоянно увеличиваетс... т.е. пакеты-то принимаются?!?!

[asv]

50088 -- откуда столько набралось? Будет по пакету в секунду, если от ping

[speculzzz]

50088 -- откуда столько набралось? Будет по пакету в секунду, если от ping

Он постоянно что-то принимает из сети... девайс подключен через хаб... так вот лампочка мигается в такт с "глобалом", заведенным в хаб. Micrel KSZ8842-32MQL - это 2-х портовый свич... что наверное накладывает такою особенность... я в этом не силен

[speculzzz]

В принципе, сеть заработала :)... Оказалось, что было 2 проблемы (еси кому-то интересно, конечно :) ).
1) Это сам макадрес.
К сетевому чипу должен подключаться EEPROM, с которого драйвер считывает макадрес. В девайсе его нет, поэтому драйвер читает всякий мусор. Я наивно полагал, что мак может быть любым - поэтому оставлял как он прочитался. Например, FF:2B:D4:3C:FC:3B. Оказалось, что с таким маком сеть не работает. И если, к примеру, адрес будет 01:23:45:67:89:AB, то все ок. Но попытки менять мак ни к чему не приводили, так как тут кроется вторая проблема.
2) Смена макадреса доступна только через 2-й сетевой порт чипа (по крайней мере в данной реализации драйвера... о чем помогли узнать принтфы, добавленные в драйвер).
Все эксперименты в основном проводил с 1-м портом. Соответсвенно, менял мак для eth1. Но он изменялся только в свойствах интерфейса, а ниже "в регистры" чипа не уходил. А если на eth2 править мак - то все ок. Вот такая вот особенность... возможно специально задуманная разрабами.

Теперь предстоит эти иходники в убут засунуть :).

P.S. Небольшое уточнение по поводу "только через 2-й сетевой порт": доступ к "железу" через интерфейс, который был открыт первым. А вот почему при запуске драйвера системой открывается автоматом только 2-й интерфейс и на него вешается udhcpc -i eth2 - непонятно... т.к. никакого упоминания eth2 (как и eth1) в системных конфигах/скриптах нет.

[speculzzz]

Всем добрый день.
Net-драйвер для свича Micrel KSZ8842 в uboot заработал :)))... это радует... но вот остался один "маленький штрих": драйвер активизируется (а следовательно и прописывает мак-адрес, заданный в uboot) только если выполнить tftpboot, ping... т.е. любую операцию, для которой необходима сеть.
А как сделать, чтобы драйвер сетки автоматом активировался при старте загрузчика???

[asv]

Это противоречит принятому в U-Boot порядку инициализации устройств -- не используется, не инициализируется.

Если очень нужно, то добавить соотв. функции в board_init() board/edb93xx/edb93xx.c

[speculzzz]

По идее нужна только функция выставления мака, заданного в убуте :)
(чтобы не переделывать драйвер сетки в ядре)
Попробуем...

[speculzzz]

Если очень нужно, то добавить соотв. функции в board_init() board/edb93xx/edb93xx.c

Добавил в конец функции

Код: [Выделить]

int board_init( void )
{
    ...
    /* init ethernet */
    eth_init(gd->bd);
    return(0);
}

Но, видимо, так делать нельзя?? Т.к. после этого загрузчик перестает в консоль писать...

[asv]

1. Совсем перестаёт?
Тогда посмотрите на BOARD_LATE_INIT

2. Вы где MAC собираетесь хранить?
На Тион, Тион-Про, Тион-Про2 он традиционно храниться в SPI-Flash M25P40 и записывается туда программой download.

При этом MAC из SPI-Flash (1) читается в U-Boot (svn890) и заменяет значение переменной ethaddr и (2) читается в Linux.

Можно передавать MAC в Linux через сер. номер платы (например, так сделано в Тион270 и Тион-Про270) и хранить его в переменных
U-Boot. Тогда в U-Boot код такой (svn886):

Код: [Выделить]

#ifdef CONFIG_SERIAL_TAG
/* Board serial number is actually the MAC address */
void get_board_serial(struct tag_serialnr *serialnr)
{
char *s, *e;
int i;

s = getenv("ethaddr");
if (!s)
return;

serialnr->low = 0;
for (i = 0; i < 4; i++) {
serialnr->low |= simple_strtoul(s, &e, 16) << (i*8);
s = e + 1;
}
serialnr->high = 0;
for (i = 0; i < 2; i++) {
serialnr->high |= simple_strtoul(s, &e, 16) << (i*8);
s = e + 1;
}
}
#endif


[speculzzz]

1. Совсем перестаёт?
Тогда посмотрите на BOARD_LATE_INIT

На скорости 9600 символ "Ё" (если память не изменяет) выплевывет и все...
board_late_init() тоже пробывал - в данном случае uboot не собирается, т.к. внутри этой функции gd уже недоступен ('gd' undeclared).

2. Вы где MAC собираетесь хранить?
На Тион, Тион-Про, Тион-Про2 он традиционно храниться в SPI-Flash M25P40 и записывается туда программой download.

При этом MAC из SPI-Flash (1) читается в U-Boot (svn890) и заменяет значение переменной ethaddr и (2) читается в Linux.

Вопрос конечно интересный... И пока по нему нет окончательного решения.
Сетку с Тиона не используем (под PHY нет места), получается ЕЕПРОМ на Тионе свободный. У нас установлен чип от Micrel 2-х портовый (MAC+PHY в одном флаконе), драйвера которого читают напрямую мак из ЕЕПРОМ (который может быть подключен к чипу, но из-за нехватки места его нет).
В данном случае наиболее удобным видется использование ethaddr в uboot. И скорее всего это будет скрипт в линухе в if-pre-up.d, который читает мак из загрузчика и выставляет его интерфейсам.
До этого использовал патч к убуту svn775... но гляжу уже svn894 есть... посмотрю его.
Как вариант, можно будет программировать мак в ЕЕПРОМ Тиона, в убуте читать это значение и прописывать в ethaddr, а в линухе читать значение ethaddr :)...

Можно передавать MAC в Linux через сер. номер платы (например, так сделано в Тион270 и Тион-Про270) и хранить его в переменных
U-Boot. Тогда в U-Boot код такой (svn886):

А как он из get_board_serial() в ядро попадет и как там разберется? Что-то про теги ядра/убута вообще не знаю...

[asv]

> внутри этой функции gd уже недоступен

DECLARE_GLOBAL_DATA_PTR


> в ядро попадет и как там разберется? Что-то про теги ядра/убута вообще не знаю

a.  Documentation/arm/Booting, 4. Setup the kernel tagged list

b.  arch/arm/kernel/setup.c, ATAG_SERIAL

c.  В ядре 2.6.22 для PXA270 drivers/net/dm9000.c можно посмотреть, как из этого получают MAC на примере DM9000.

[speculzzz]

Спасибо... посмотрим что там такое ;)

Кстати, использование тега ATAG_SERIAL вызвано какой-то необходимостью (например, мак можно передать только через данный тег) или чем-то другим??? А то может если его использовать для cirrus-а, произойдет какой-нибудь конфликт?

[asv]

ATAG_SERIAL вы вольны использовать как угодно для нумерования своих плат, он показывается в /proc/cpuinfo, где сейчас 0.
Если MAC уникальный и тем более "честный", то использовать его как номер платы вполне подходит.