Я купил Routerboard 750GL и сейчас жду поставки нескольких Routerboard на базе PPC. Меня сильно интересует функциональность Metarouter, описанная здесь: http://wiki.mikrotik.com/wiki/Manual:Metarouter#OpenWRT_as_virtual_machine. Я создал патч для последней стабильной версии OpenWRT (attitude_adjustment), который компилирует MIPS и PPC без проблем на последней ревизии attitude_adjustment/12.09 (r37811). Я обновил патчи ядра для PPC и MIPS, чтобы они поддерживали версию ядра Linux 3.3.8. Когда я загружаю образ MIPS (RouterOS 6.2 на 750GL), Metarouter сообщает, что машина "работает", и вот вывод ядра из консоли: [ 0.000000] Linux version 3.3.8-svn37266 (kris@kkdesk) (gcc version 4.6.3 20120201 (prerelease) (Linaro GCC 4.6-2012.02)) #2 Sun Aug 18 14:52:02 EDT 2013 [ 0.000000] Revision CPU: 0001800a (MIPS 4Kc) [ 0.000000] Определенная физическая карта ОЗУ: [ 0.000000] память: 00029000 @ 003fc000 (доступна после инициализации) [ 0.000000] Пользовательская физическая карта ОЗУ: [ 0.000000] память: 01000000 @ 00000000 (доступна) [ 0.000000] Диапазоны PFN зоны: [ 0.000000] Обычная 0x00000000 → 0x00001000 [ 0.000000] Начало PFN перемещаемой зоны для каждого узла [ 0.000000] Ранние диапазоны PFN памяти [ 0.000000] 0: 0x00000000 → 0x00001000 [ 0.000000] Создано 1 список зон в порядке зон, группировка мобильности отключена. Всего страниц: 4064 [ 0.000000] Командная строка ядра: console=hvc0 board=vm mem=16M [ 0.000000] Записи хеш-таблицы PID: 64 (порядок: -4, 256 байт) [ 0.000000] Записи хеш-таблицы кэша Dentry: 2048 (порядок: 1, 8192 байта) [ 0.000000] Записи хеш-таблицы кэша inode: 1024 (порядок: 0, 4096 байт) [ 0.000000] Первичный кэш инструкций 64кБ, VIPT, 4-канальный, размер строки 32 байта. [ 0.000000] Первичный кэш данных 32кБ, 4-канальный, VIPT, алиасы кэша, размер строки 32 байта [ 0.000000] Память: 11716к/16384к доступна (2612к код ядра, 4668к зарезервировано, 437к данных, 164к инициализация, 0к высокопамяти) [ 0.000000] SLUB: Genslabs=9, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] NR_IRQS:128 [ 0.000000] Консоль: цветное устройство-заглушка 80x25 [ 0.000000] консоль [hvc0] включена [ 0.000000] Калибровка цикла задержки... Здесь все зависает... Я предполагаю, что PPC может "просто работать", потому что мне пришлось делать гораздо меньше хитрых штучек, чтобы портировать его на Linux 3.3.8. К сожалению, я не могу это протестировать, потому что у меня нет оборудования! Буду признателен за любую помощь, поддержку или советы. У меня есть патч и бинарные образы здесь: http://www.kriskinc.com/mikrotik-metarouter Спасибо! – Кристиан Кильхофнер
Ядра MikroTik всегда настраивались/патчились так, чтобы не выводить сообщения при загрузке. Они делают это, переопределяя предобработочную константу DEFAULT_CONSOLE_LOGLEVEL в printk.c с 7 на 1. Это довольно интересно, потому что я оставил этот патч, но, похоже, на консоли у меня полные сообщения. Я искренне считаю, что моя предыдущая проблема была связана с тем, что я вручную изменял .config, добавляя опции по одной, чтобы сборка работала, и не делал чистую переcборку каждый раз, из-за чего некоторые последние изменения касались HVC и VIRTIO. Однако это не объясняет, почему я вижу лог-сообщения! Я чуть позже на это более внимательно посмотрю. Я смог собрать и запустить чистое ядро 3.3.8, сейчас я борюсь с OpenWRT и огромным количеством их патчей, которые влияют на ядро MikroTik. Ли.
Ок… не уверен, что произошло с консолью, но теперь она работает как нужно. У меня есть сборка OpenWRT с работающим ядром 3.3.8, к сожалению, еще остаются проблемы, которые нужно решить. Режим failsafe работает нормально, но как только начинается загрузка модулей, возникает вот это: [ 0.000000] ------------[ cut here ]------------ [ 0.000000] WARNING: at mm/vmalloc.c:1465 0xc010e084() [ 0.000000] Пытаемся vfree() по неправильному адресу (c0e80e00) [ 0.000000] След трассировки: [] 0xc03385b4 [ 0.000000] [] 0xc03385b4 [ 0.000000] [] 0xc011836c [ 0.000000] [] 0xc010e084 [ 0.000000] [] 0xc0118420 [ 0.000000] [] 0xc010e084 [ 0.000000] [] 0xc0156510 [ 0.000000] [] 0xc010e6f0 [ 0.000000] [ 0.000000] —[ end trace a766b1004ee7c11b ]— Не скажу, что я удивлен, потому что весь код module.c для перемещения модулей выглядит совершенно иначе. Есть патч openwrt (305-mips_module_reloc.patch), который, похоже, содержит все, что был в основном патче Mikrotik, так что я убрал большую часть вещей от Mikrotik... возможно, это был не самый правильный подход. [EDIT] Я исправил эту проблему, это была функция is_phys_addr(). Теперь она просто зависает после загрузки нескольких модулей. Нужно копать глубже… [EDIT] Это тоже теперь в порядке (ошибка новичка)... теперь у меня есть "ошибка ядра", когда настроен интерфейс. Делаю успехи! Ли.
Ок… теперь кажется, что всё работает… Я удалил много из патча MikroTik, что немного жаль, но теперь у меня есть полностью функциональная (по крайней мере, в пределах моего тестирования) сборка mips Attitude Adjustment. Попробую вернуть всё в контролируемое состояние и выложить патч завтра. С уважением, Ли.
Вот начальный патч… несколько комментариев: Это против Attitude Adjustment (12.09) r39154. Я только посмотрел на mips, код ppc там присутствует, но я не тестировал сборку и не создавал целевые файлы для него (у меня нет системы ppc, поэтому я не могу это протестировать). Это основано на патче MikroTik 3_3_5 (но применено к 3_3_8). Я убрал некоторые элементы из патча 3_3_5, но здесь все еще много лишнего, что не нужно для metarouter, поэтому он в настоящее время намного больше, чем должен быть, но разбирать это займет некоторое время, так как есть много зависимостей. Мой план на данный момент — упростить все, что возможно, и затем посмотреть, смогу ли я это портировать в trunk. Очень интересно узнать, удастся ли это кому-то еще! С уважением, Ли. openwrt_aa_mips.patch.gz (378 KB)
ОК, это последний пост на некоторое время (надеюсь)… Я фактически начал снова, добавив только необходимые части патча 3_3_5, так что все лишнее теперь удалено, это значительно более простой патч и гораздо ближе по духу к оригинальному патчу 1.2 от Mikrotik. Я подготовил два патча: один для Attitude Adjustment 12.09 (r39154) и один для текущей ветки (r39218), которая основана на ядре 3.10.24. Есть некоторые нюансы: это только для mips, на данный момент я тестировал только на RB951G. Я провел очень базовое тестирование… проверил, что он загружается и распознает интерфейс. Я не эксперт по ядрам или mips, так что мог что-то поломать, особенно в патче для ветки. Наслаждайтесь и дайте знать, как дела. С уважением, Ли. openwrt_metarouter_trunk.patch.gz (31.7 KB) openwrt_metarouter_1209.patch.gz (31.7 KB)
Я пытаюсь работать с патчем для 1209 вместо официального metarouter-1.2, но когда я запускаю make menuconfig, не могу найти Mikrotik MetaROUTER MIPS в разделе Target System. Я что-то делаю не так?
Привет, тебе нужно скачать релиз 12.09 из OpenWRT, используя git или svn… git clone git://git.openwrt.org/12.09/openwrt.git Затем нужно применить патч… (замени patch_file на полный или относительный путь к патчу)… cd openwrt patch -p1 < patch_file После этого ты сможешь использовать “make menuconfig” и увидишь “Mikrotik MetaROUTER MIPS” в списке целевых систем. С уважением, Ли.
Это, возможно, не связано с тем, что Кристиан что-то неправильно сделал со своим патчем, а может быть из-за ошибки в PPC RouterOS, которая предотвращает загрузку любого пользовательского ядра под RouterOS 6 MetaROUTER (тикет 2013100466000193; см. http://forum.mikrotik.com/t/bug-custom-metarouter-kernels-no-longer-work-on-ppc-w-ros6/70244/1). Ты пробовал загрузить образ PPC Кристиана под 5.26? – Натан
Я только что воспроизвел эту проблему, протестировав RB951G сначала на 5.25, а потом на 6.7. Официальный образ от MikroTik работает нормально, самодельный образ из OpenWRT svn (по рекомендациям MikroTik) и патч 1.2 тоже работают без проблем, но патч 1.3 с attitude adjustment вообще не выдает никакого вывода. Я смотрел различные патчи с намерением перенести их на гораздо более новую версию ядра OpenWRT, и мне кажется, что это не так просто, как просто перенести патч 1.2, так как есть довольно много значительных изменений в дереве mips и даже в том, как структурированы различные опции mips. Если посмотреть на патч 3.3.5, который якобы использует Mikrotik, то можно увидеть несколько различных способов выполнения задач для типа платы "vm". Если взглянуть на секции внутри CONFIG_MAPPED_KERNEL, то увидите много нового, чего не было в патче 1.2, предположительно для учета изменений в реализации mips. Я думаю, что ответ будет заключаться в комбинации частей патча 1.2 и патча 3.3.5. Я собираюсь попробовать собрать «ванильное» ядро 3.3.5 с патчем 3.3.5 и просто вмешать его в образ OpenWRT, так я увижу, будет ли оно загружаться... Я знаю, что оно не будет работать впоследствии, но станет ясно, стоит ли пытаться перенести части 3.3.5 на 3.3.8 или новее. Ли.
Хорошо, я продвинулся немного вперед... У меня теперь есть ядро 3.3.5, которое, похоже, загружается. Консоль работает некорректно, поэтому я не получаю никаких сообщений загрузки, но вижу следующее: [Ctrl-A — это клавиша префикса]
init started: BusyBox v1.16.1 (2010-04-13 10:25:42 EEST) /etc/init.d/rcS: line 17: can't open '/dev/null' На данный момент я предполагаю, что сообщения при старте скрыты, так как такое же поведение у стандартных мета-роутеров, не использующих openWRT, или просто я как-то неправильно использую виртуальную консоль в своем .config... Буду дальше разбираться. Не думаю, что портировать это на 3.3.8 будет слишком сложно, но сначала хочу разобраться с проблемой консоли. Ли.
Собственные ядра MikroTik всегда настраивались/патчились так, чтобы не выводить сообщения при загрузке. Это достигается путём переопределения предобработочной константы DEFAULT_CONSOLE_LOGLEVEL в файле printk.c с 7 на 1. (Они делают это только в своих полных наборах патчей ядра, а не в тех, которые содержат только подмножество MetaROUTER.) Традиционно я просто выбрасывал их целый патч на printk.c, так как, насколько я понимаю, остальные изменения связаны с предоставлением хука для RouterOS, чтобы перехватывать сообщения printk (возможно, с целью их сбора и, например, сохранения внутри файлов SUPOUT?), что, очевидно, не нужно в OpenWRT. Поэтому ваш опыт интересен. Возможно, DEFAULT_CONSOLE_LOGLEVEL можно переопределить в .config, в этом случае я не совсем понимаю, почему MikroTik утруждает себя патчингом исходного кода напрямую. (Тем, кто следит за этой темой, стоит заметить, что проблемы с загрузкой ядер MetaROUTER на PowerPC RouterOS не имеют отношения к этому, и этот 'фикс' консоли не является решением для этой проблемы. Мы говорим только о порте ядра MIPS.) – Нэйтан