По поводу кодов. Построить бы график перехода 1/N в 1/sqrt(N) как функции ошибки по доплеру. Ведь 50Гц при хорошей энергетике - это очень много. Что будет при 1-5 Гц?
50 Гц - это не ошибка слежения за сигналом. Это разность частот принимаемого сигнала и другого сигнала из той же системы, который создаёт внутрисистемную помеху. Частоты этих сигналов могут отличаться независимо от энергетики. Это определяется взаимным движением спутников и положением потребителя.
Графики такие я строил, у меня сейчас просто под рукой его нет.
Я бы сказал по-другому. Дело не в языках. Невозможно изучить программирование. А если умеешь программировать, уже не столь важно, какой язык использовать. Я Pascal и C именно так изучил - читал книги по пути в институт (не притрагиваясь к компьютеру в период чтения). Но тогда я уже умел главное - программировать. И переход от одного языка к другому в этом случае - это всего лишь новый синтаксис и пара-тройка ;) новых фичей.
Я всё это к тому пишу, что ты отрицаешь необходимость чтения литературы, а я именно так многому и научился. Вот программировать - этому можно только на практике научиться. А языки - я по Паскалю тогда книжку прочитал и сразу начал программы писать, причём первая программа не таблицу умножения на экран выводила, а это был сетевой чат с настройкой цветов для разных пользователей. Идея была не моя, я видел исходники своего товарища, но я тогда я переписал всё с нуля заново (поняв лишь саму идею, заложенную в образец).
А вот если программировать не умеешь (не понимаешь принципа), то хоть учи, хоть практикуйся - всё будет бестолку. Я видел такие примеры.
"Отрицаешь необходимость чтения литературы" - это ты несколько преувеличил)) Я утверждаю малоэффективность обучения в отсутствии потребности в знании/навыках. Поэтому, на мой взгляд, оптимальная схема обучения любому языку/средствам разработки при "умении программировать в общем": постановка задачи -> разбиение задачи на мелкие шаги -> поиск решения мелкой задачи на основе литературы/товарищей/интуиции/методе тыка -> profit
У нас появилось два новых бакалавра. Один уже схватил ПЛИСину и побежал разбираться. Второй пока думает. Завтра придут.
Да, это было бы просто, за 4 т.р. решить кучу проблем...
Как бы сказать - я тоже ничего подходящего не нашёл!
Понимаешь, всё это нам не подходит. Все эти отладочные платы имеют кучу различной периферии - аудио, видео, экраны сенсорные и прочее, что нам не нужно.
А что нам нужно? Сделать приёмник. А основная часть приёмника - это не процессор, а блок цифровой обработки, который мы будем делать на ПЛИС. Для общения с ПЛИС нужна шина. Мне бы сейчас хотелось бы видеть PCI-Express, т.к. это многое бы упростило, но если параллельную шину - то 32 разрядную.
Из всех готовых модулей вообще мало в каких есть шина в принципе. Среди тех, что приведены в заметке, внешная шина есть у плат VAR-SOM-AM35 и VAR-SOM-ОM37. У топового модуля Varicate внешней шины уже нет - они там напихали ещё больше периферии, на шину места не осталось, а обычно она никому не нужна, всем нужно навешивать много периферии. Эти модули - они, как готовые навигационные приёмники, продукт почти для конечного потребителя. Они мультимедийно-ориентированные.
Так вот, в перечисленных платах шина данных нам не подходит. Там 16 разрядов данных и 10 разрядов адреса. 10 разрядов адреса пережить можно (в Альпаке была 21 линия). Но вот 16 линий данных - это уже через чур. У нас внутренние регистры - принципиально 32-разрядные. И процессор 32-разрядный. Значит, чтобы преодолеть "бутылочное горлышко" из 16 разрядов, придётся поработать.
В принципе, это возможно, но стоит ли на это закладываться?
Отсутствие PCI-E и 16-разрядные данные меня тоже огорчили. Но не обязательно же вешать ПЛИС на шину процессорную. Помимо PCI-E есть и другие интерфейсы. SPI, I2C, Ethernet. Всякие electronix да хабры говорят, что их можно вместо PCI-E использовать. Но так ли это - тебе виднее.
Судя по сарказму, скорости по SPI не хватит... I2C, я так понимаю, ещё медленнее. Нужен PCI-E и только он (акромя полноценной шины данных)? Буду тогда искать PCI-E платы. Обойдемся без SO-DIMM, воткнем в PCI-E слот.
SPI и I2C - последовательные шины, не предназначенные для применений, подобных нашим. Даже если не принимать во внимание полосу, с ними просто сложно будет работать.
Про полноценные - нет, не только PCI-Express. Откуда PCI-Express возник? Аппаратная поддержка PCI-Express есть и в MPC8640 с одной стороны, и в Xilinx Xpartan6 с другой. Т.е. не нужно городить ничего лишнего.
А чем интересна PCI-Express вообще, почему не обычная параллельная шина? Меньше проводов. Для PCI-Express 1x достаточно развести две дифференциальные пары - четыре провода. А параллельная шина - в Альпаке сейчас шина - это 32+21+4=57 проводов.
Больше проводов - это и больше сложностей при разводке, больше шансов накосячить. И потом, дифференциальные линии позволяют "проще" гонять высокоскоростные потоки данных, для обычных линий больше шансов нарваться на звон фронтов и прочие прелести жизни.
Но PCI-Express - не единственная подобная шина, просто это стандарт сегодня. Есть в Spartan6 ещё выскоскоростной последовательный приёмо-передатчик GTP, из которого, в частности, можно PCI-Express, Ethernet, DisplayPort и другие интерфейсы сделать - но такой штуки нет на стороне процессора.
На счёт LVDS - это слишком общее название, электрический интерфейс на физическом уровне. PCI-Express - это тоже LVDS, как и USB, HDMI и куча всёго другого. Нам нужена именно процессорная шина. Тут надо конкретнее смотреть. Я посмотрел - там они LVDS-ом называют интерфейс с LCD.
Картинка с профитом (Profit -> profit -> profit) позабавила. Этот подход больше подходит для экспериментальных макетов, как у нас. При производстве серий на продажу это уже совсем не то. Но нам бы как раз подошло.
Ещё, насчёт QNX - я против. Ты не поверишь, мы занимаемся коммерческой деятельностью! QNX Non-commercal быть может, можно ещё применить в учебном процессе - но и тогда, скорее всего, придётся приобретать какую-нибудь академическую лицензию. На западе учебный процесс - это тоже коммерческая деятельность! А нам НИРы и ОКРы сдавать.
QNX - это ДОРОГО.
А потом, она хоть и реального времени, но уже тяготеет к полудесктоповой, даже к десктоповой системе.
Зато:
1) Будет возможность получить полноценную поддержку от развитого сообщества
2) Мы и наши студенты поимеем опыт работы с одной из самых распространенных RTOS
3) Системная часть заработает "из коробки", а не после года приседаний
Да, идея взять всё на готовенькое была ещё во времена первой Альпаки, но и тогда ничего не нашлось :( Думаю, мы заходим не с того бока. PCI-Express сейчас есть в любом PC. Обработка прерываний наверняка есть в прототипе драйвера устройства PCI-Express под Линукс. Девайсов с FPGA+PCI-Express, подобных вот этому: http://www.hitechglobal.com/Boards/Stratix4GX.htm много. Необходимо выбрать такой, у которого на I/O заведены GCLK для тактирования от фронтенда. Наша задача сведётся к созданию мезонинного модуля с фронтендом.
Да, можно так, я думал об этом. Но хочется, чтобы устройство было переносимым, а не плата, вставляемая в компьютер. Можно ли что-нибудь подходящее отыскать?
В логе он пытается подмонтировать файловую систему из mmcblk0. Судя по названию, это карточка mmc, которой нет.
А ведь rootfs в соответствии с параметрами ядра должна лежать в /dev/mtdblock4.
Похоже, ядро игнорирует параметры, которые ему передаются. В логах написано:
error: no MAC address on cmd. line, set to F8:DC:7A:00:00:00
хотя в параметрах ядра указано:
ethaddr=F8:DC:7A:00:00:00
Может, там должно быть macaddr?
rootfs должен быть записан в nand, вот сюда:
0x000000780000-0x000010000000 : "jffs2-nand"
Так пишет ядро. rootfs удалось записать в nand по этому адресу?
Да, туда закинуты 70 метров Angstrom root fs. Но не от этого ядра, а pre-build jffs2 файл с FTP'шника Veriscite'a. Я пока не разобрался, как собрать root fs.
Т. е. в параметрах ядра указано правильно, rootfs лежит в /dev/mtdblock4. mtd - memory technology devices, разделы нумеруются с нуля, поэтому наш раздел как раз четвёртый.
Вообще, рута он новерное подмонтировал:
VFS: Mounted root (jffs2 filesystem) on device 31:4.
Обращаю внимание на последнюю цифру - это номер раздела (4), minor number устройства /dev/mtdblock4. 31, стало быть, major number.
То, что дальше - относится к карточке SD/MMC, нам это сейчас неинтересно. Впрочем, можешь попробовать карточку вставить и посмотреть, что он напишет, но это просто так, ради любопытства, проблему это не решит.
Ну, так и есть, modprobe ищет модули в неправильном месте.
Попробуй загрузить указанные модули через insmod - эта команда воспринимает полный путь к модулю, а не пытается его искать в месте по-умолчанию.
А ещё, если rootfs у тебя доступен для записи, можно сделать ссылку из 2.6.37+ в 2.6.37. Или вообще просто каталог переименовать.
Но если модули от одного ядра, а само ядро - другое - может начать ругаться, будет писать UNKNOWN SYMBOL ...
Надо честно ядро вместе с модулями собрать, сделать свой rootfs. Все файлы можно взять от старого, а поменять только модули ядра. Если с JFFS2 работать не получится, никто не запрещает rootfs в обычном ext2 сделать.
Ну, теперь точно нужны исходники ядра для этой системы, надо собрать ядро и модули. Образ ядра перевести в формат u-boot/PPC (не знаю, как, надо искать утилиту). Модули закинуть в образ rootfs.
Только стоит ли бодаться из-за этого? omapfb - модуль framebuffer, он бесполезен, пока мы работаем через uart, он может понадобиться (не обязательно), если к этой плате графический дисплей подключить, по HDMI, например, или телевизор тот же. Там просто больше символов на экране помещаться будет и шрифны погламурнее, а в остальном то же самое.
Или ты сейчас так и работаешь? Клавиатуру и монитор подцепил? Ведь сначала порт был неправильный.
[ Хронологический вид ]Комментарии
Четвёртая фотка - это, что ли, он в образе Saint IGNUcius из Church of Emacs?
Google подсказывает, что ты прав!
Жень, тут специально для тебя, почти все о чем он говорил =)
http://lenta.ru/articles/2011/12/03/stallman/
По поводу кодов. Построить бы график перехода 1/N в 1/sqrt(N) как функции ошибки по доплеру. Ведь 50Гц при хорошей энергетике - это очень много. Что будет при 1-5 Гц?
50 Гц - это не ошибка слежения за сигналом. Это разность частот принимаемого сигнала и другого сигнала из той же системы, который создаёт внутрисистемную помеху. Частоты этих сигналов могут отличаться независимо от энергетики. Это определяется взаимным движением спутников и положением потребителя. Графики такие я строил, у меня сейчас просто под рукой его нет.
Понял)) Что-то я чушь сказал, какие 1/N в режиме слежения)
Я бы сказал по-другому. Дело не в языках. Невозможно изучить программирование. А если умеешь программировать, уже не столь важно, какой язык использовать. Я Pascal и C именно так изучил - читал книги по пути в институт (не притрагиваясь к компьютеру в период чтения). Но тогда я уже умел главное - программировать. И переход от одного языка к другому в этом случае - это всего лишь новый синтаксис и пара-тройка ;) новых фичей.
Я всё это к тому пишу, что ты отрицаешь необходимость чтения литературы, а я именно так многому и научился. Вот программировать - этому можно только на практике научиться. А языки - я по Паскалю тогда книжку прочитал и сразу начал программы писать, причём первая программа не таблицу умножения на экран выводила, а это был сетевой чат с настройкой цветов для разных пользователей. Идея была не моя, я видел исходники своего товарища, но я тогда я переписал всё с нуля заново (поняв лишь саму идею, заложенную в образец). А вот если программировать не умеешь (не понимаешь принципа), то хоть учи, хоть практикуйся - всё будет бестолку. Я видел такие примеры.
"Отрицаешь необходимость чтения литературы" - это ты несколько преувеличил)) Я утверждаю малоэффективность обучения в отсутствии потребности в знании/навыках. Поэтому, на мой взгляд, оптимальная схема обучения любому языку/средствам разработки при "умении программировать в общем": постановка задачи -> разбиение задачи на мелкие шаги -> поиск решения мелкой задачи на основе литературы/товарищей/интуиции/методе тыка -> profit
У нас появилось два новых бакалавра. Один уже схватил ПЛИСину и побежал разбираться. Второй пока думает. Завтра придут.
Кого бы этим нагрузить... У нас, в принципе, две линуховых машины в лаборатории РС стоят. Можно и студентов посадить за них.
А что за огромные выбросы периодические?
А вот это и есть косяк. Это выбросы на 1 мс. Сначала в плюс, следующий отсчёт в минус. В среднем - правильно, но их не должно быть.
А нарастающий шум - это то, что вызвано ограниченной разрядностью и это, видимо, нормально.
Надо придумать какую-то систему, отображающую правку в блогах. Я только сегодня заметил, что ты добавил новые результаты.
Посмотри h'ник, там могут стоят настройки для BigIronFrontEnd
Само собой, посмотрел, там всё было не так. Но несколько спутников он в результате поймал, так что сейчас всё правильно.
Да, это было бы просто, за 4 т.р. решить кучу проблем...
Как бы сказать - я тоже ничего подходящего не нашёл! Понимаешь, всё это нам не подходит. Все эти отладочные платы имеют кучу различной периферии - аудио, видео, экраны сенсорные и прочее, что нам не нужно.
А что нам нужно? Сделать приёмник. А основная часть приёмника - это не процессор, а блок цифровой обработки, который мы будем делать на ПЛИС. Для общения с ПЛИС нужна шина. Мне бы сейчас хотелось бы видеть PCI-Express, т.к. это многое бы упростило, но если параллельную шину - то 32 разрядную.
Из всех готовых модулей вообще мало в каких есть шина в принципе. Среди тех, что приведены в заметке, внешная шина есть у плат VAR-SOM-AM35 и VAR-SOM-ОM37. У топового модуля Varicate внешней шины уже нет - они там напихали ещё больше периферии, на шину места не осталось, а обычно она никому не нужна, всем нужно навешивать много периферии. Эти модули - они, как готовые навигационные приёмники, продукт почти для конечного потребителя. Они мультимедийно-ориентированные.
Так вот, в перечисленных платах шина данных нам не подходит. Там 16 разрядов данных и 10 разрядов адреса. 10 разрядов адреса пережить можно (в Альпаке была 21 линия). Но вот 16 линий данных - это уже через чур. У нас внутренние регистры - принципиально 32-разрядные. И процессор 32-разрядный. Значит, чтобы преодолеть "бутылочное горлышко" из 16 разрядов, придётся поработать.
В принципе, это возможно, но стоит ли на это закладываться?
Отсутствие PCI-E и 16-разрядные данные меня тоже огорчили. Но не обязательно же вешать ПЛИС на шину процессорную. Помимо PCI-E есть и другие интерфейсы. SPI, I2C, Ethernet. Всякие electronix да хабры говорят, что их можно вместо PCI-E использовать. Но так ли это - тебе виднее.
Все шины - они для обмена данными. Но ты предлагаешь общаться с коррелятором по SPI?!
Судя по сарказму, скорости по SPI не хватит... I2C, я так понимаю, ещё медленнее. Нужен PCI-E и только он (акромя полноценной шины данных)? Буду тогда искать PCI-E платы. Обойдемся без SO-DIMM, воткнем в PCI-E слот.
Или как насчет LVDS? В BlueShark есть.
SPI и I2C - последовательные шины, не предназначенные для применений, подобных нашим. Даже если не принимать во внимание полосу, с ними просто сложно будет работать.
Про полноценные - нет, не только PCI-Express. Откуда PCI-Express возник? Аппаратная поддержка PCI-Express есть и в MPC8640 с одной стороны, и в Xilinx Xpartan6 с другой. Т.е. не нужно городить ничего лишнего. А чем интересна PCI-Express вообще, почему не обычная параллельная шина? Меньше проводов. Для PCI-Express 1x достаточно развести две дифференциальные пары - четыре провода. А параллельная шина - в Альпаке сейчас шина - это 32+21+4=57 проводов. Больше проводов - это и больше сложностей при разводке, больше шансов накосячить. И потом, дифференциальные линии позволяют "проще" гонять высокоскоростные потоки данных, для обычных линий больше шансов нарваться на звон фронтов и прочие прелести жизни. Но PCI-Express - не единственная подобная шина, просто это стандарт сегодня. Есть в Spartan6 ещё выскоскоростной последовательный приёмо-передатчик GTP, из которого, в частности, можно PCI-Express, Ethernet, DisplayPort и другие интерфейсы сделать - но такой штуки нет на стороне процессора.
На счёт LVDS - это слишком общее название, электрический интерфейс на физическом уровне. PCI-Express - это тоже LVDS, как и USB, HDMI и куча всёго другого. Нам нужена именно процессорная шина. Тут надо конкретнее смотреть. Я посмотрел - там они LVDS-ом называют интерфейс с LCD.
А что они подразумевают под Ethernet?
Ну как - Ethernet и подразумевают. Практически у всех 10/100 МБит/с. На мой взгляд, очень полезная фича для нашего макета.
К сожалению, сколько я не смотрел в сети, на данный момент я не нашёл подходящего нам готового модуля. Они все ориентированны на другое применение.
PS Был там ещё вариант с PC104 - это вообще 8-разрядная шина ISA из IBM PC/XT 1981 года. На это закладываться - уже совсем ни к чему.
Картинка с профитом (Profit -> profit -> profit) позабавила. Этот подход больше подходит для экспериментальных макетов, как у нас. При производстве серий на продажу это уже совсем не то. Но нам бы как раз подошло.
Ещё, насчёт QNX - я против. Ты не поверишь, мы занимаемся коммерческой деятельностью! QNX Non-commercal быть может, можно ещё применить в учебном процессе - но и тогда, скорее всего, придётся приобретать какую-нибудь академическую лицензию. На западе учебный процесс - это тоже коммерческая деятельность! А нам НИРы и ОКРы сдавать. QNX - это ДОРОГО.
А потом, она хоть и реального времени, но уже тяготеет к полудесктоповой, даже к десктоповой системе.
Зато: 1) Будет возможность получить полноценную поддержку от развитого сообщества 2) Мы и наши студенты поимеем опыт работы с одной из самых распространенных RTOS 3) Системная часть заработает "из коробки", а не после года приседаний
О лицензиях: http://qnx.org.ru/wiki/QNX_license
Да, идея взять всё на готовенькое была ещё во времена первой Альпаки, но и тогда ничего не нашлось :( Думаю, мы заходим не с того бока. PCI-Express сейчас есть в любом PC. Обработка прерываний наверняка есть в прототипе драйвера устройства PCI-Express под Линукс. Девайсов с FPGA+PCI-Express, подобных вот этому: http://www.hitechglobal.com/Boards/Stratix4GX.htm много. Необходимо выбрать такой, у которого на I/O заведены GCLK для тактирования от фронтенда. Наша задача сведётся к созданию мезонинного модуля с фронтендом.
Да, можно так, я думал об этом. Но хочется, чтобы устройство было переносимым, а не плата, вставляемая в компьютер. Можно ли что-нибудь подходящее отыскать?
Круто! Так а что с ядром линуха? Грузится?
В процессе)) Хитрые евреи не стали выкладывать bsp и toolchain в открытый доступ. Только что выпросил логин/пароль на ftp, выкачиваю
Ну так как там хитрые евреи? Ждём BSP с нетерпением...
Ну, самое главное, ядро загрузилось, а дальше - дело понятное, что дело ясное ;)
В логе он пытается подмонтировать файловую систему из mmcblk0. Судя по названию, это карточка mmc, которой нет. А ведь rootfs в соответствии с параметрами ядра должна лежать в /dev/mtdblock4.
Похоже, ядро игнорирует параметры, которые ему передаются. В логах написано: error: no MAC address on cmd. line, set to F8:DC:7A:00:00:00 хотя в параметрах ядра указано: ethaddr=F8:DC:7A:00:00:00 Может, там должно быть macaddr?
rootfs должен быть записан в nand, вот сюда: 0x000000780000-0x000010000000 : "jffs2-nand" Так пишет ядро. rootfs удалось записать в nand по этому адресу?
Да, туда закинуты 70 метров Angstrom root fs. Но не от этого ядра, а pre-build jffs2 файл с FTP'шника Veriscite'a. Я пока не разобрался, как собрать root fs.
Из лога:
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xca (Micron )
Creating 5 MTD partitions on "omap2-nand.0":
0x000000000000-0x000000080000 : "xloader-nand"
0x000000080000-0x000000240000 : "uboot-nand"
0x000000240000-0x000000280000 : "params-nand"
0x000000280000-0x000000780000 : "linux-nand"
0x000000780000-0x000010000000 : "jffs2-nand"
Т. е. в параметрах ядра указано правильно, rootfs лежит в /dev/mtdblock4. mtd - memory technology devices, разделы нумеруются с нуля, поэтому наш раздел как раз четвёртый.
Вообще, рута он новерное подмонтировал: VFS: Mounted root (jffs2 filesystem) on device 31:4. Обращаю внимание на последнюю цифру - это номер раздела (4), minor number устройства /dev/mtdblock4. 31, стало быть, major number.
То, что дальше - относится к карточке SD/MMC, нам это сейчас неинтересно. Впрочем, можешь попробовать карточку вставить и посмотреть, что он напишет, но это просто так, ради любопытства, проблему это не решит.
Самое главное здесь: FATAL: Module omaplfb not found. Т.е. на rootfs где-то в каталоге /lib/modules/2.6.37/, но его там нет.
Надо посмотреть, что есть в образе rootfs!!!
root fs у нас от 2.6.37, а ядро теперь 2.6.37+. Добавил в текст содержимое каталогов. У тебя есть идеи как посмотреть кишки jffs2 файла?
Дай команду
>> uname -r
она выдаст точное название ядра. Может быть, она ищет файлы в каталоге /lib/modules/2.6.27+, или ещё где. Должно совпадать с выводом uname -r
root@am3517-evm:~# uname -r
2.6.37+
Тот модуль, что он ищет, находится в 2.6.37. См. выше
Ну, так и есть, modprobe ищет модули в неправильном месте.
Попробуй загрузить указанные модули через insmod - эта команда воспринимает полный путь к модулю, а не пытается его искать в месте по-умолчанию.
А ещё, если rootfs у тебя доступен для записи, можно сделать ссылку из 2.6.37+ в 2.6.37. Или вообще просто каталог переименовать.
Но если модули от одного ядра, а само ядро - другое - может начать ругаться, будет писать UNKNOWN SYMBOL ...
Надо честно ядро вместе с модулями собрать, сделать свой rootfs. Все файлы можно взять от старого, а поменять только модули ядра. Если с JFFS2 работать не получится, никто не запрещает rootfs в обычном ext2 сделать.
Ну, теперь точно нужны исходники ядра для этой системы, надо собрать ядро и модули. Образ ядра перевести в формат u-boot/PPC (не знаю, как, надо искать утилиту). Модули закинуть в образ rootfs.
Ядро я уже собрал, без этого оно не запускалось. Сейчас пытаюсь осмыслить как собрать rootfs.
Можно подмонировать образ rootfs, как я описывал ниже, и записать туда модули ядра, а все остальне оставить прежним.
Только стоит ли бодаться из-за этого? omapfb - модуль framebuffer, он бесполезен, пока мы работаем через uart, он может понадобиться (не обязательно), если к этой плате графический дисплей подключить, по HDMI, например, или телевизор тот же. Там просто больше символов на экране помещаться будет и шрифны погламурнее, а в остальном то же самое.
Или ты сейчас так и работаешь? Клавиатуру и монитор подцепил? Ведь сначала порт был неправильный.
Работаю через UART, посредством kermit'a
Забей тогда на omapfb. Попробуй что-нибудь ещё. Hello world уже работает, это главное.
Попробуй сетку, что-ли поднять.
>> ifconfig -a
Эта команда выдаст все сетевые устройства. Должно быть eth0.
>> ifconfig eth0 192.168.0.15 netmask 255.255.255.0 up
Эта команда запускает сетевой интерфейс.
>> route add default gw 192.168.0.1 eth0
Эта команда добавляет путь к шлюзу 192.168.0.1 (если он у тебя есть, конечно)
>> echo nameserver 8.8.8.8 > /etc/resolv.conf
Эта команда задаёт адрес сервера имён.
>> ping www.ya.ru
Может и заработать! По крайней мере, у нас в центре.
Заработает, куда он денется) Только до роутера надо кабелек кинуть от платы.
Войдите, чтобы комментировать.