ЗАО «ЗЭО»
Техническая поддержка пользователей => ОС Linux, U-Boot => Тема начата: speculzzz от 14 Января, 2010, 13:25:01
-
Начало обсужения тут http://www.zao-zeo.ru/forum/index.php?topic=63.msg1162#msg1162 (http://www.zao-zeo.ru/forum/index.php?topic=63.msg1162#msg1162)
Это сообщение относиться к этому U-Boot?
## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB
Т.е. не определилась Flash, 'flinfo' что выводит?
Да... не определяет flash... CFI не отработал
CFI: Unknown command set 0x0
## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB
U-Boot 1.3.3 (Jan 12 2010 - 17:07:28)
CPU: Cirrus Logic EP9315 rev. E2
DRAM: 64 MB
Flash: 0 kB
Hit any key to stop autoboot: 0
$ flinfo
Bank # 1: missing or unknown FLASH type
$
Странно что в версии u-boot на экране отсутствует инфа о версии патча и стандартных потоках ввода/вывода, как, например, тут
U-Boot 1.3.3-svn602 (Jun 17 2009 - 17:59:21)
CPU: Cirrus Logic EP9315 rev. E2
DRAM: 64 MB
Flash: 64 MB
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
$
Возможно следует собирать uboot компилятором arm-elf- (как и redboot)?
-
> отсутствует инфа о версии патча
Потому что у вас не svn и её неоткуда взять
> стандартных потоках ввода/вывода
Насколько я помню это не выводиться при использовании SERIAL_MULTI (как это было сделано некоторое время назад для плат на EP93xx). Есть команда console.
По вопросу, возможно это проблема кода связанного с работой Flash в U-Boot, возможно проблема компилятора.
Я U-Boot собираю arm-linux-gnu-gcc (GCC) 4.2.4 (Debian 4.2.4-6). Если хотите разобраться, попробуйте собрать другим,
При сборке U-Boot'а
http://arm.cirrus.com/files/tools/arm-linux-gcc-4.1.1-920t.tar.bz2
c Flash тоже были проблемы.
-
> отсутствует инфа о версии патча
Потому что у вас не svn и её неоткуда взять
Эт я что-то ступил :)...
Щас попробую elf-компилятором...
На моей железке не выводится наружу сеть от Тиона, а используется 2-х портовка Micrel KSZ8842. На сколько сложно будет подружить загрузчик с сетью??
-
Дело скорее в версии компилятора чем в elf/неelf
> На сколько сложно будет подружить загрузчик с сетью??
Один порт, вероятно, заработает сразу, всё-таки MII, а вот со вторым будет интересней.
-
У KSZ8842 нет MII, тогда сложнее, придётся писать драйвер.
-
Для загрузчика 1 порта достаточно...
Просто для меня эти MII и PHY темный лес :(... Жаль что не получится сразу... Придется по СОМу заливать.
В ядре 2.6.32.3 есть драйвер для этой сетевухи.. По идее он подойдет для портации в убут или нет?
Р.S. у меня чип KSZ8842-32MQL. В даташите на него встречаются "Bank 45 PHY 1 MII-Register Basic Control Register (0x00): P1MBCR"... Может всеже он этот MII поддерживает? Как это точно можно в даташите посомтреть?? (точнее, как оно должно называться)
-
Дело скорее в версии компилятора чем в elf/неelf
В общем, все теперь нормально собралось/запустилось.
arm-elf-gcc-3.4.3 помог :)))
U-Boot 1.3.3 (Jan 14 2010 - 13:48:24)
CPU: Cirrus Logic EP9315 rev. E2
DRAM: 64 MB
Flash: 8 MB
Hit any key to stop autoboot: 0
$
-
> В ядре 2.6.32.3 есть драйвер для этой сетевухи.. По идее он подойдет для портации в убут или нет?
Подойдёт
Я сужу по таблице, видно что не MII интерфейс
http://www.micrel.com/page.do?page=/product-info/fastether_sw.jsp
Кроме того указано, что non-PCI, то есть интерфейс "шины адреса/данных".
-
> В ядре 2.6.32.3 есть драйвер для этой сетевухи.. По идее он подойдет для портации в убут или нет?
Подойдёт
Ясно... спасибо.
Осталось теперь найти how-to/manual нормальный по портации дров из ядра в uboot :)... бум искать.
-
> how-to/manual нормальный
Быстрее посмотреть на реализацию в U-Boot DM9000 (она также non-PCI) и на другие из drivers/net
Кроме того, в U-Boot две (или более) сетевые системы, старая и новая (NET_MULTI), на старой лучше не делать -- в официальный U-Boot на ней драйвера не принимают.
Если есть желание и возможность сделать совсем хорошо, то сейчас в U-Boot рассматриваются патчи для EP93xx (для отладочных плат Cirrus Logic), тема в рассылке "Add support for edb93xx boards" Matthias Kaehlcke
-
Сперва решил завести драйвер Micrel KSZ8842-32MQL под ядром. В комплекте идет драйвер, но что-то с ним никак. Поэтому скачал с сайта Micrel исходники драйвера для моего чипа. Поковырялся с их настройкой под платформу Тиона. Вроде драйвер запустился... ошибок нет..
/ # ifconfig eth1
eth1 Link encap:Ethernet HWaddr 7F:2B:D6:3C:5C:39
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:16431 errors:0 dropped:0 overruns:0 frame:0
TX packets:42 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1308770 (1.2 MiB) TX bytes:2268 (2.2 KiB)
Interrupt:34 Memory:71000300-7100030f
Но вот столкнулся с одним затыком, который никак не могу победить :(: пинги с девайса и на девайс не идут. При этом драйвер все отлавливает: прерывания, подключение/отключение кабеля, RX не нулевой, леды на порту мигают.
ПОставил IP адрес как у своего компа и попробовал пингануть сеть - и о чудо... на компе выскочило сообщение о конфликте адресов в сети. Таким образом, какая-то связь с внешним миром есть. Но вот заставить его общаться никак не получается.
Хелп ми... куда копать????
З.Ы.
Гружу ядро 2.6.32.3 (с патчами для тиона) + uramdisk_bb1.8.2.gz.
Драйвер сетевухи инсмодю с флешки после загрузки.
З.Ы.Ы.
При этом сам себя пингует
/ # ping 192.168.1.85
PING 192.168.1.85 (192.168.1.85): 56 data bytes
64 bytes from 192.168.1.85: seq=0 ttl=64 time=0.834 ms
64 bytes from 192.168.1.85: seq=1 ttl=64 time=0.668 ms
64 bytes from 192.168.1.85: seq=2 ttl=64 time=0.666 ms
64 bytes from 192.168.1.85: seq=3 ttl=64 time=0.674 ms
^C
--- 192.168.1.85 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.666/0.710/0.834 ms
/ #
телнетом на себя заходит
/ # telnet 192.168.1.85
Entering character mode
Escape character is '^]'.
BusyBox v1.8.2 (2008-05-04 12:22:07 EDT) built-in shell (ash)
Enter 'help' for a list of built-in commands.
/ #
А вот с внешним миром - никак :(
-
man route?
-
ping -I eth1 ?
-
/ # 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
/ #
/ # ping -I eth1 192.168.1.82
PING 192.168.1.82 (192.168.1.82): 56 data bytes
И тишина.
Если задать IP своего компа, то при попытке пингануть сеть на компе выскакивает мессага о конфликте адресов... т.е. пакеты с устройства в сеть уходят... :(
И не понятно где копать: толи в драйвере чего не так, толи в ОС что-то не настроенно, толи в ядре какой-то опции не хватает....
-
Поставьте на host сетевой сканер (http://www.wireshark.org/) и посмотрите пакеты с MAC-адресом платы.
-
Поставьте на 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
Я в этой "сетевой" сфере имеют только общие понятия... и где "копать", имея подобную информацию даже и не подозреваю :(. Может среди уважаемого сообщества найдется человек, который сможет указать "верное направление"...
-
Тион: 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
Возможно, у вас на плате пакеты не принимаются?
-
Т.е. два варианта:
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 постоянно увеличиваетс... т.е. пакеты-то принимаются?!?!
-
50088 -- откуда столько набралось? Будет по пакету в секунду, если от ping
-
50088 -- откуда столько набралось? Будет по пакету в секунду, если от ping
Он постоянно что-то принимает из сети... девайс подключен через хаб... так вот лампочка мигается в такт с "глобалом", заведенным в хаб. Micrel KSZ8842-32MQL - это 2-х портовый свич... что наверное накладывает такою особенность... я в этом не силен
-
В принципе, сеть заработала :)... Оказалось, что было 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) в системных конфигах/скриптах нет.
-
Всем добрый день.
Net-драйвер для свича Micrel KSZ8842 в uboot заработал :)))... это радует... но вот остался один "маленький штрих": драйвер активизируется (а следовательно и прописывает мак-адрес, заданный в uboot) только если выполнить tftpboot, ping... т.е. любую операцию, для которой необходима сеть.
А как сделать, чтобы драйвер сетки автоматом активировался при старте загрузчика???
-
Это противоречит принятому в U-Boot порядку инициализации устройств -- не используется, не инициализируется.
Если очень нужно, то добавить соотв. функции в board_init() board/edb93xx/edb93xx.c
-
По идее нужна только функция выставления мака, заданного в убуте :)
(чтобы не переделывать драйвер сетки в ядре)
Попробуем...
-
Если очень нужно, то добавить соотв. функции в board_init() board/edb93xx/edb93xx.c
Добавил в конец функции
int board_init( void )
{
...
/* init ethernet */
eth_init(gd->bd);
return(0);
}
Но, видимо, так делать нельзя?? Т.к. после этого загрузчик перестает в консоль писать...
-
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
-
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() в ядро попадет и как там разберется? Что-то про теги ядра/убута вообще не знаю...
-
> внутри этой функции 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.
-
Спасибо... посмотрим что там такое ;)
Кстати, использование тега ATAG_SERIAL вызвано какой-то необходимостью (например, мак можно передать только через данный тег) или чем-то другим??? А то может если его использовать для cirrus-а, произойдет какой-нибудь конфликт?
-
ATAG_SERIAL вы вольны использовать как угодно для нумерования своих плат, он показывается в /proc/cpuinfo, где сейчас 0.
Если MAC уникальный и тем более "честный", то использовать его как номер платы вполне подходит.
-
Интересная штука эти таги :)...
Посмотрел последний патч для убута. И возник вопрос: если объединить функционал чтения SPI-флеша и создания "серийного номера" платы из ethaddr, то что будет вызываться первым
board_late_init (где читаем мас из ЕЕПРОМа) или get_board_serial()... т.е. какой в итоге "серийный номер" получим?
-
Попробовал - все работает нормально:
1) в убуте читаем мак из ЕЕПРОМ и записываем в ethaddr и ATAG_SERIAL
2) в ядре (в сетевом драйвере) тег разбираем и используем по назначению
В общем, получилось симпатично ;) (благодаря Вашим патчам).
Остался только один организационный момент, решить который пока не получилось (т.к. не знаю где искать.... пока): не пойму, кто переписывает МАС-адрес для интерфейса в 00:BA:D0:0B:AD:00 ??? Происходит так:
1) Если в конфигурацию ядра включаем драйвер ep93xx-eth (становится eth0) и драйвер своей 2-х портовки (eth1 и eth2), то имеем следующее:
eth0 Link encap:Ethernet HWaddr 00:BA:D0:0B:AD:00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
/ # ifconfig eth1
eth1 Link encap:Ethernet HWaddr AA:BB:CC:DD:EE:F2
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:34 Memory:71000300-7100030f
/ # ifconfig eth2
eth2 Link encap:Ethernet HWaddr AA:BB:CC:DD:EE:F2
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:34 Memory:71000300-7100030f
/ #т.е. маки у eth1 и eth2 нормальные - осталось только IP задать и вперед.
2) Если драйвер ep93xx-eth убрать из конфигурации, что логично (т.к. этой сетки реально нет), то нам доступны только 2 интерфейса eth0 и eth1... Но в данном случае у eth0 после старта мак-адрес тоже 00:BA:D0:0B:AD:00, а у eth1 как и положено AA:BB:CC:DD:EE:F2. И теперь придется для eth0 сперва заменить мак-адрес, чтобы была по нему связь.
Кто прописывает этот 00:BA:D0:0B:AD:00 для eth0 и как от этого избавится?
-
Извините, что немного не в тему, но думаю, для этого создавать новую ветку не стоит))
Поглядел я на текущее состояние u-boot, оказывается, у нас версия полуторогодичной давности...
Из вкусного в последних версиях - это к примеру, поддержка сжатия LZMA.
Это было бы нам наверное полезно, позволяло бы место существенно экономить.
Переходить на новые версии u-boot никто не собирается?)
Можно, конечно, для поддержки lzma попробовать патч найти какой-нить...