Jump to content
XPEnology Community

Сборка и модификация kernel


Recommended Posts

может просто все сведется к тому что можно будет сделать свой обычный дистр с фичами синолоджи? и не нужен будет загрузчик?

 

Стесняюсь спросить, но всё же а какими фичами обладает DSM по вашему мнению?

 

Если всё выше сказанное верно, то DSM это грубо говоря просто вебморда на линуксе.

Link to comment
Share on other sites

Если всё выше сказанное верно, то DSM это грубо говоря просто вебморда на линуксе.

Грубее некуда. Учитывая, сколько их собственных бинарных утилит там задействовано.

Link to comment
Share on other sites

Если всё выше сказанное верно, то DSM это грубо говоря просто вебморда на линуксе.

Грубее некуда. Учитывая, сколько их собственных бинарных утилит там задействовано.

Плюсую. Они даже умудрились как-то расписание cron в бинари превратить, слегка был "удивлён" когда это увидел.

Link to comment
Share on other sites

и над btrfs я тк думаю они хорошо поработали. раз выпустили его в продакшен.

так что это далеко не веб морда только.

Да, в ядре хватает изменений. Но это все чистая косметика.

Arm сборки (я пробовал DS212j, 214, 414j) заводятся вообще со стоковым ядром от WD (Стоковое ядро + поддержка железа WD (arch/CPU, gpio-led, spi-flash). Никаких доп. правок.).

Косяк был только с Samba (Из-за synoacl). Ну и index.cgi отправлял систему в ребут, т.к. не мог получить данные от synobios.

Тоесть система спокойно работает на почти стоковом ядре. Из изменений - правки в synoinfo.conf, модули от моего ядра, мелкие правки в скриптах инициализации, пропатченный index.cgi. Synobios вообще отсутствует.

 

Пока ковырял ядро для портирование на другой девайс понял, что изменений там не так уж и много:

Алиасы для модулей шифрования (хз, зачем - и так работает)

Добавлены либы/драйвера расширенной криптографии OCF Linux

Мелкие правки в драйверах устройств, чтобы они определялись так, как надо самой Synology.

Много павок в btrfs (По большей части - бэкпорт с более старшей версии ядра).

Synoacl (Дополнительный бит доступа)

И правки в платформо-зависимых секциях + компоненты Synobios (Доступ к разным данным системы через /sys и /proc).

+ Правки в драйверах mtd, т.к. у большинства arm все настройки, вроде Mac и серийника хранятся на тойже флешке, что и загрузчик с ядром. + поддержка самой флешки, разумеется.

Link to comment
Share on other sites

  • 9 months later...
Внимание! Все действия, описанные в данной документации, производились в научно-познавательных целях, и не имеют цели извлечения какой-либо прибыли.

Раздел 1. Подготовка исходников и сборка проекта.

 

Шаг 1. Установка VirtualBox и Ubuntu

Установите VirtualBox (http://www.virtualbox.org/) и создайте виртуальную машину для установки Ubuntu.

Я использовал следующие параметры виртуальной машины для комфортной работы: RAM 4 gb, 2 CPU, HDD 50 Gb

В качестве операционной системы, я выбрал Ubuntu 12.10 x64 (http://www.ubuntu.com)

 

Шаг 2. Инструменты и исходные коды

Скачайте инструменты компиляции и исходные коды, предоставляемые Synology, согласно лицензии GPL (http://sourceforge.net/projects/dsgpl/files/)

Все действия производились с исходными кодами для процессоров Intel (серия Bromolow). Это не значит, что полученное ядро будет работать только на Bromolow процессорах.

Эксперименты показали, что проект успешно запускается на AMD, Atom, Cedarview, Pineview процессорах.

Вам понадобятся:

DSM 4.1 Tool Chains (gcc420_glibc236_x64_bromolow-GPL.tgz)

Synology NAS GPL Source (synogpl-2636-bromolow.tbz)

На момент написания этого руководства были актуальны версия DSM 4.1 и исходные коды ядра (2636 сборка).

 

Шаг 3. Распаковка исходных кодов

Установка инструментов и исходных кодов сводится к простой распаковке.

Распакуйте архивы.

tar -xvzf gcc420_glibc236_x64_bromolow-GPL.tgz -C /usr/local/ 

tar -xvjf synogpl-2636-bromolow.tbz -C /usr/local/x86_64-linux-gnu/

 

Важное замечание! Если вы используете 64-разрядную версию Ubuntu, необходимо установить 64-битные библиотеки.

sudo apt-get install libc6-i386

 

Для запуска конфигуратора ядра, необходимо установить Ncurses

sudo apt-get install build-essential ncurses-dev

 

Шаг 4. Сборка проекта.

Для сборки проекта необходимо:

переписать файл конфигурации "bromolow" из каталога "x86_64-linux-gnu/source/linux-3.x/synoconfigs" в каталог "x86_64-linux-gnu/source/linux-3.x" с именем ".config"

отредактировать "makefile" и установить значения переменным ARCH и CROSS_COMPILE

ARCH ?= x86_64
CROSS_COMPILE ?= /usr/local/x86_64-linux-gnu/bin/x86_64-linux-gnu-

Способ редактирования файла "makefile" не является верным. Более правильным способом является указание переменных с необходимыми значениями в командной строке вызова "make". Например: "make ARCH=x86_64 CROSS_COMPILE=/usr/local/x86_64-linux-gnu/bin/x86_64-linux-gnu- modules"

 

Перед сборкой модулей необходимо сконфигурировать ядро. Делается это командой "make menuconfig". Вам будет предложено невероятно огромное количество настроек ядра. По умолчанию загрузится конфигурация "bromolow", которую вы скопировали из каталога "x86_64-linux-gnu/source/linux-3.x/synoconfigs" с имеем ".config"

 

Стоит отметить, что на этом этапе необходимо как минимум включить поддержку сетевых контроллеров Realtek. Иначе собранное ядро будет искать только определенную модель контроллера Intel.

 

Далее выполните команду "make oldconfig". Теперь настало время собрать объектные модули. Выполните команду "make modules".

Сборка модулей достаточно затяжной процесс, и на медленных машинах может занять до 15 минут.

Если все вышеуказанные шаги были сделаны верно, сборка объектных модулей пройдет без ошибок.

 

Сборка ядра является так-же достаточно простой операцией. Введите команду "make bzImage". Результатом будет собранное ядро, находящееся в каталоге "/usr/local/x86_64-linux-gnu/source/linux-3.x/arch/x86/boot" с именем "bzImage". В последствии его нужно переименовать в "zImage".

Всё вышеперечисленное не является чем-то новым и не описанным. В сети множество описаний, достаточно подробно описывающих сборку ядра.

 

Раздел 2. Модификация ядра.

Сразу оговорюсь, я произвел модификацию на скорую руку, и вполне вероятно, она не является правильной и корректной. Однако необходимого эффекта я добился.

Предлагаю сообществу, основываясь на моих изысканиях, доработать и возможно улучшить этот проект.

 

Разработчики DSM сделали достаточно много изменений исходного кода ядра. В основном эти изменения направлены на контроль состояния дисков.

Сердцем DSM является модуль "synobios.ko". Этот модуль содержится в двух местах: 1) на RAM диске (файл rd.gz) 2) на hda1 (файл hda1.tgz)

Если попытаться запустить систему с вновь собранным ядром, модуль synobios.ko не загрузится, и запускаться не будет.

Этому есть несколько причин:

1) В ядре отсутствуют функции "funcSynoSendEboxRefreshEvent" и "funcSynoEunitPowerctlType".

Эту неприятность можно легко поправить в файлах "/usr/local/x86_64-linux-gnu/source/linux-3.x/drivers/ata/libata-core.c" и "/usr/local/x86_64-linux-gnu/source/linux-3.x/kernel/sysctl.c".

//#ifdef MY_DEF_HERE  // закомментировать
int (*funcSYNOSendEboxRefreshEvent)(int portIndex) = NULL;
EXPORT_SYMBOL(funcSYNOSendEboxRefreshEvent);
//#endif  // закомментировать

//#ifdef MY_DEF_HERE  // закомментировать
EUNIT_PWRON_TYPE (*funcSynoEunitPowerctlType)(void) = NULL;
EXPORT_SYMBOL(funcSynoEunitPowerctlType);
//#endif  // закомментировать

2) Если собрать ядро с вышеуказанными изменениями, то при загрузки ядра будет падать функция syno_sata_mv_gpio_write(), я не стал глубоко вдаваться о её назначении (на первый взгляд она занимается получением состояния SATA диска, чтобы радостно мигать светодиодом на передней панели корпуса, при обращениях к диску), а просто закомментировал её содержимое в файле "/usr/local/x86_64-linux-gnu/source/linux-3.x/drivers/ata/sata_mv.c"

#ifdef MY_ABC_HERE
/*FIXME - Too brutal and directly, should separate into levels*/
void syno_sata_mv_gpio_write(u8 blFaulty, const unsigned short hostnum)
{
/*
struct Scsi_Host *shost = scsi_host_lookup(hostnum);
struct ata_port *ap = NULL;
void __iomem *host_mmio = NULL;
u32 gpio_value = 0;
int led_idx;

if(NULL == shost) {
	goto END;
}

if(NULL == (ap = ata_shost_to_port(shost))) {
	scsi_host_put(shost);
	goto END;
}

if(NULL == (host_mmio = mv_host_base(ap->host))) {
	scsi_host_put(shost);
	goto END;
}

led_idx = ap->print_id - ap->host->ports[0]->print_id;

gpio_value = readl(host_mmio + GPIO_CTL_DATA);

if(blFaulty) {
	gpio_value |= (1 << led_idx);
}else {
	gpio_value &= ~(1 << led_idx);
}

writel(gpio_value, host_mmio + GPIO_CTL_DATA);
scsi_host_put(shost);

END:
*/
return;
}
EXPORT_SYMBOL(syno_sata_mv_gpio_write);
#endif

После пересборки ядра с новыми изменениями, модуль synobios.ko уже не будет ругаться на отсутствующие функции, и не будет падать на вызове "syno_sata_mv_gpio_write()". Однако загружаться и рапортовать о своей готовности synobios.ko также не будет. Причиной всего является отсутствие на последовательном порту COM1 разработанного компанией Synology монитора (основанного на серийном микроконтроллере). Монитор занимается включением и выключением светодиодов, подачей звуковых сигналов, контролем температуры и системы охлаждения NAS. Одной из функций монитора является идентификация оборудования.

В качестве примера, я буду рассматривать synobios.ko (размер файла 52840 байт).

.text:0000000000002370                                         public SetMicropId
.text:0000000000002370                         SetMicropId     proc near               ; DATA XREF: .data:synobios_ops_0o
.text:0000000000002370
.text:0000000000002370                         var_18          = qword ptr -18h
.text:0000000000002370
.text:0000000000002370 48 83 EC 18                             sub     rsp, 18h
.text:0000000000002374 0F B6 15 1D 33 00 00                    movzx   edx, cs:syno_module+8
.text:000000000000237B 0F B6 05 17 33 00 00                    movzx   eax, cs:syno_module+9
.text:0000000000002382 48 C7 04 24 00 00 00 00                 mov     [rsp+18h+var_18], 0
.text:000000000000238A C0 EA 04                                shr     dl, 4
.text:000000000000238D 83 E0 0F                                and     eax, 0Fh
.text:0000000000002390 48 C1 E0 04                             shl     rax, 4
.text:0000000000002394 0F B6 D2                                movzx   edx, dl
.text:0000000000002397 48 09 D0                                or      rax, rdx
.text:000000000000239A 04 01                                   add     al, 1
.text:000000000000239C 74 15                                   jz      short loc_23B3
.text:000000000000239E 31 D2                                   xor     edx, edx
.text:00000000000023A0 81 3D F2 32 00 00 FF 00+                cmp     cs:MpId_20729, 0FFh
.text:00000000000023AA 74 1C                                   jz      short loc_23C8
.text:00000000000023AC
.text:00000000000023AC                         loc_23AC:                               ; CODE XREF: SetMicropId+56j
.text:00000000000023AC                                                                 ; SetMicropId+76j ...
.text:00000000000023AC 89 D0                                   mov     eax, edx
.text:00000000000023AE 48 83 C4 18                             add     rsp, 18h
.text:00000000000023B2 C3                                      retn
.text:00000000000023B3                         ; ---------------------------------------------------------------------------
.text:00000000000023B3
.text:00000000000023B3                         loc_23B3:                               ; CODE XREF: SetMicropId+2Cj
.text:00000000000023B3 48 C7 C7 FE 45 00 00                    mov     rdi, offset aGetMicropFail ; "get microp fail\n"
.text:00000000000023BA 31 C0                                   xor     eax, eax
.text:00000000000023BC E8 9B 42 00 00                          call    printk
.text:00000000000023C1 BA FF FF FF FF                          mov     edx, 0FFFFFFFFh
.text:00000000000023C6 EB E4                                   jmp     short loc_23AC
.text:00000000000023C8                         ; ---------------------------------------------------------------------------
.text:00000000000023C8
.text:00000000000023C8                         loc_23C8:                               ; CODE XREF: SetMicropId+3Aj
.text:00000000000023C8 48 C7 C6 13 46 00 00                    mov     rsi, offset aR  ; "R"
.text:00000000000023CF 48 89 E2                                mov     rdx, rsp
.text:00000000000023D2 B9 08 00 00 00                          mov     ecx, 8
.text:00000000000023D7 48 89 F7                                mov     rdi, rsi
.text:00000000000023DA E8 81 FE FF FF                          call    ReadUart
.text:00000000000023DF 85 C0                                   test    eax, eax
.text:00000000000023E1 BA FF FF FF FF                          mov     edx, 0FFFFFFFFh
.text:00000000000023E6 75 C4                                   jnz     short loc_23AC
.text:00000000000023E8 0F BE 04 24                             movsx   eax, byte ptr [rsp+18h+var_18]
.text:00000000000023EC 31 D2                                   xor     edx, edx
.text:00000000000023EE 89 05 A8 32 00 00                       mov     cs:MpId_20729, eax
.text:00000000000023F4 EB B6                                   jmp     short loc_23AC
.text:00000000000023F4                         SetMicropId     endp
.text:00000000000023F4
.text:00000000000023F4                         ; ---------------------------------------------------------------------------
.text:00000000000023F6 66 66 66 90 66 66 90 66+                align 20h

Выше представлена функция SetMicropId в которой по адресу .text:00000000000023E8 производиться чтение из монитора ID NAS.

Результат чтения будет помещен в регистр EAX. Так как монитора у нас нет, то необходимо произвести некоторую модификацию кода.

В нашем случае мы принудительно загрузим в регистр EAX необходимое значение.

 

text:00000000000023C8 48 C7 C6 13 46 00 00                    mov     rsi, offset aR  ; "R"
.text:00000000000023CF 48 89 E2                                mov     rdx, rsp
.text:00000000000023D2 B9 08 00 00 00                          mov     ecx, 8
.text:00000000000023D7 48 89 F7                                mov     rdi, rsi
.text:00000000000023DA E8 81 FE FF FF                          call    ReadUart
.text:00000000000023DF 85 C0                                   test    eax, eax
.text:00000000000023E1 BA FF FF FF FF                          mov     edx, 0FFFFFFFFh
.text:00000000000023E6 90                                      nop
.text:00000000000023E7 B8 42 00 00 00                          mov     eax, 42h ; 'B'
.text:00000000000023EC 31 D2                                   xor     edx, edx
.text:00000000000023EE 89 05 A8 32 00 00                       mov     cs:MpId_20729, eax
.text:00000000000023F4 EB B6                                   jmp     short loc_23AC
.text:00000000000023F4                         SetMicropId     endp

P.S. Изначально этот хак был мной подсмотрен у уважаемого vortex'a, курирующего проект QNology (http://qnology.xvtx.ru/).

 

Итак, регистр EAX должен содержать код модели, который можно подсмотреть в файле "/usr/local/x86_64-linux-gnu/source/linux-3.x/include/linux/synobios.h или ниже:

typedef enum {
MICROP_ID_710p = 0x31, /* '1' */
MICROP_ID_411p = 0x33, /* '3' 411+II is the same*/
MICROP_ID_1010p = 0x32, /* '2' */
MICROP_ID_1511p = 0x36, /* '6' */
MICROP_ID_810p = 0x35, /* '5' */
MICROP_ID_810rp = 0x34, /* '4' */
MICROP_ID_2211p = 0x37, /* '7' */
MICROP_ID_2211rp = 0x38, /* '8' */
MICROP_ID_2411p = 0x39, /* '9' */
MICROP_ID_3411xs = 0x43, /* 'C' 3412xs is the same */
MICROP_ID_3411rpxs = 0x41, /* 'A' 3412rpxs is the same */
MICROP_ID_3611xs = 0x42, /* 'B' 3612xs is the same*/
MICROP_ID_712p = 0x44, /* 'D' */
MICROP_ID_412p = 0x45, /* 'E' */
MICROP_ID_1512p = 0x47, /* 'G' */
MICROP_ID_1812p = 0x46, /* 'F' */
MICROP_ID_812p = 0x48, /* 'H' */
MICROP_ID_812rp = 0x49, /* 'I' */
MICROP_ID_2212p = 0x4A, /* 'J' */
MICROP_ID_2212rp = 0x4B, /* 'K' */
MICROP_ID_2413p = 0x4C, /* 'L' */
MICROP_ID_10613xsp = 0x4d, /* 'M' */
MICROP_ID_3413xsp = 0x4e, /* 'N' */
MICROP_ID_913p = 0x4f, /* 'O' */
MICROP_ID_713p = 0x50, /* 'P' */
MICROP_ID_UNKNOW = 0xFF,
} SYNO_MICROP_ID;

Уже в процессе эксплуатации мода, я столкнулся с постоянно вываливающимся в консоль, предупреждением: "synobios: buzzer stop button pressed"

Решил проблему с ним достаточно быстро, пропатчив одну функцию

.text:0000000000000395 80 7C 24 17 00                          cmp     [rsp+28h+var_11], 0
.text:000000000000039A EB D4                                   jmp     short loc_370 // JZ изменил на JMP

 

На этом, процесс модификации ядра и модуля synobios.ko можно считать завершенным.

 

Раздел 3. Сборка комплекта для инсталляции.

Шаг 1. Модификация rd.gz и hda1.tgz

Теперь, имея исправленный synobios.ko, необходимо поместить его на своё законное место.

В качестве подопытного, я ипользовал прошивку от DS3612xs (файл DSM_DS3612xs_2668.pat). Файл, с расширением .PAT представляет собой tar архив и содержит в себе достаточно большой набор файлов некоторое количество из которых нам никогда не понадобятся. Удаляем лишнее, и получаем минимально необходимый комплект:

checksum.syno		// содержит контрольные суммы всех, перечисленных ниже файлов
grub_cksum.syno	// содержит контрольную сумму файлов zImage и rd.gz (используется в загрузчике GRUB)
hda1.tgz			// образ системы
rd.gz				// RAM диск
updater			// WEB версия установщика (вместо Synology Assistent)
VERSION			// Файл, содержащий версию DSM
zImage			// Образ ядра

 

Первым делом нужно поместить новый "synobios.ko" на RAM диск в файле "rd.gz".

Для этого его необходимо распаковать и смонтировать

gunzip /tmp/rd.gz
sudo mount -t ext2 -o loop rd /mnt/ramdisk

Перезаписываем "synobios.ko" в каталоге /mnt/ramdisk/lib/modules

 

Пакуем RAM диск

sudo umount /mnt/ramdisk
gzip /tmp/rd

 

Вторым делом, нужно заменить "synobios.ko" в образе системы (файл hda1.tgz)

Для этого я использовал вспомогательную утилиту Archivemount (http://en.wikipedia.org/wiki/Archivemount). Её необходимо предварительно установить.

Копируем hda1.tgz в /tmp и монтируем командой:

sudo archivemount /tmp/hda1.tgz /mnt/hdd

Перезаписываем "synobios.ko" в каталоге /mnt/hdd/lib/modules

Размонтируем командой:

sudo umount /mnt/hdd

В каталоге /tmp появится обновленный файл hda1.tgz

Его необходимо переименовать в hda1 и запаковать архиватором xz командой: xz -z9 hda1

Полученный файл "hda1.xz" переименовать в "hda1.tgz"

 

Шаг 2. Пересчет контрольной суммы

Теперь мы имеем собранный zImage, модифицированные rd.gz и hda1

Настало время собрать валидный PAT файл, который можно использовать для установки системы.

Чтобы PAT файл был валидным, необходимо пересчитать контрольную сумму файлов и поместить их в checksum.syno

Для этих целей есть генератор файла контрольных сумм: Раздел 4. Загрузочный диск. Модификация GRUB[/size]

Шаг 1. Структура загрузочного диска.

Загрузочный диск состоит из двух разделов. На первом разделе находится загрузчик модифицированный загрузчик GRUB.

Функции, которые производит загрузчик являются достаточно ключевыми:

1) Проверка контрольных сумм файлов ядра системы (zImage) и RAM диска (rd.gz) и сверка их со значениями, хранящимися в файле grub_cksum.syno с второго раздела загрузочного диска.

2) Идентификация оборудования (чтение из монитора, висящего на COM1) аналогично функции SetMicropId в synobios.ko

3) Чтение конфигурации железа (MAC адрес сетевых карт и серийный номер) из файла vender

 

Для корректной работы загрузчика необходимо модифицировать его код.

Описывать этот процесс не имеет смысла, так как готовый к употреблению загрузчик содержится в сборке XPEnology. Стоит отметить, что код устройства можно изменить по адресу:

seg000:0000DEF7 E8 F1 38 01 00                          call    serial_port_READ
seg000:0000DEFC B8 36 00 00 00                          mov     eax, 42h

Регистр EAX должен содержать код оборудования, согласно таблицы, представленной выше.

Эта инструкция содержится по смещению 0x5efc модуля stage2 загрузчика.

 

Для расчета контрольной суммы файлов zImage и rd.gz можно воспользоваться встроенной в загрузчик функцией проверки контрольных сумм.

Если контрольная сумма zImage не верная, загрузчик сообщит об этом и покажет корректную. Перепишите корректную в файл grub_cksum.syno и запустите загрузчик повторно. Он рассчитает соответственно вторую контрольную сумму для файла rd.gs

 

Желающие копнуть глубже могут выудить алгоритм из загрузчика (stage2). Он основан на алгоритме MD5 c небольшими изменениями.

 

Шаг 2. Изменение MAC адреса и серийного номера.

файл vender

0000000000: 00 11 32 08 D6 2A 4B 00 │ 11 32 08 D6 2B 4C 00 00   ◄2◘Ц*K ◄2◘Ц+L
0000000010: 00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00
0000000020: 42 33 4A 34 4E 30 30 30 │ 30 30 31 00 00 00 00 00  B3J4N000001
0000000030: 00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00
0000000040: 00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00
0000000050: 00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00
0000000060: 00 00 00 00 5B 00 00 00 │ 69 00 00 00 01 01 00 00      [   i   ☺☺
0000000070: 00 00 00 00 00 00 00 00 │ 00 00 00 00 01 01 01 01              ☺☺☺☺
0000000080: 00 00 00 00 00 00 00 00 │ 00 00 00 00 01 01 01 01              ☺☺☺☺
0000000090: 01 01 01 01 01 01 01 00 │ 00 01 00 00 00 00 00 00  ☺☺☺☺☺☺☺  ☺
00000000A0: 00 00 00 00 00 00 00 00 │ 00 00 00 00 01 01 01 00              ☺☺☺
00000000B0: 01 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00  ☺

Смещение 0x0001 - MAC адрес 1

Смещение 0x0008 - MAC адрес 2

Смещение 0x000F - MAC адрес 3

Смещение 0x0017 - MAC адрес 4

Смещение 0x0020 - серийный номер

 

На этом данное описание можно считать завершенным.

 

Благодарю за внимание. В ближайшие дни инструкция будет дополнена и переведена на английский.

Принимаю любые дополнения и предложения !

 

С Уважением, Andy хренолог :smile:

 

В планах:

1) Нарисовать эмулятор монитора и встроить его в ядро. Либо выполнить его в виде демона.

2) Адаптировать какой-нибудь китайский девайс, типа (http://www.aliexpress.com/item/4-Fan-Sp ... 36498.html) для вывода информации о дисках и т.д...

Мвмочки дорогие,openwrt пока научился с исходников собирать на заказ месяца два зубрил.А тут на полгода бессоных ночей.Но за то для openwrt у меня проект висит на 4pda.Будем курить. :grin:

Link to comment
Share on other sites

Мвмочки дорогие,openwrt пока научился с исходников собирать на заказ месяца два зубрил.А тут на полгода бессоных ночей.Но за то для openwrt у меня проект висит на 4pda.Будем курить. :grin:

на 4pda за такой оверквотинг зобанеле бы на пару ночей хе-хе...

на самом деле тут особо изучать нечего, с мосента написания описалова сборки уже как от сотворения мира прошло... Всё давно изменилось, ядро собирается обычно с нужными модулями, а все хаки идут в сценарии бутлодера из рамдиска т.е. защита хачится попутно, во время загрузки ядра, но эта процедура тута не описана и никто не расскажет как чего, надоть самому брать загрузчег, разбирать рамдиск и ковырять скрипты...

Link to comment
Share on other sites

  • 2 months later...

Вот тут добрый человек описал как в 1.02a дрова добавлять...

[spoiler=how to build and inject missing drivers in jun loader 1.02a]IG-88 » 25 апр 2017 01:37

kernel modules/drivers are specifically compiled for a kernel (-versions) and even distributions

it's not like windows where you can download a driver somewhere and just put it in

so don't take any *.ko file, stick it in and expect it to work

if you haven't build the *.ko yourself or don't know exactly where it came from, expect it to fail

I'm no expert but as there is no how-to here in the forum - lets start one

hopefully other will correct and help refine or take over and rewrite it

some steps are made in windows (osfmount) but will also possible in the chroot environment on linux

basic knowledge about using a linux console and command-line tools (or midnight commander) is needed, if you never used this you should not start with this how-to, choose something easier or invite someone who is able to help (do a workshop)

doing all this from scratch will take at least 1-2 hours, in most cases (re-read, google, try, google, try again, ...) much longer, maybe plan a weekend of text-adventure fun

 

 

1. building the kernel module (driver)

 

1.1 what driver/module i need

you will have to find out (google) what the name of the driver/module is that your hardware needs or you will have to know where to find the rigt option in the menu-system of the kernel when configuring it

example: nForce 630 chipset with RTL8211E, youu might expect it to be a realtek driver like rtl*.ko but it's not its "forcedeth.ko" because the RTL8211 is not a fully working PCIe Network Chip

in some cases you might be forced to find out by booting a linux distribution and look in /var/log/, use lspci or other tools

it also helps if the hardware provider has already compiled packages for specific distributions like redhat, you can look inside these packages for *.ko files

you also can look in the .config file of the kernel (more below) with a text editor to find a section where the module is mentioned, this will also give you a hint where to find it in the menu-system when configuring the kernel

 

1.2 you need the kernel source

in the case of synology that seemed sometimes difficult but at the moment there is kernel source for dsm 6.1

 

https://sourceforge.net/projects/dsgpl/ ... %20Source/

 

15047 is the version and tells you about what dsm version it is (15057 = dsm 6.1), it might change in a later version of 6.1 so always check for what version your bootloader from usb stick is made for (jun 1.02 is for 15047)

as i write this for ds3615xs it's bromolow as a platform, for ds3617xs it's broadwell and ds916+ is braswell (you usually see that name on the update files for a synology system like "synology_broadwell_3617xs.pat")

so for ds3615xs we use this:

https://sourceforge.net/projects/dsgpl/ ... z/download

 

1.3 setting up a DSM 6.1 ds3615xs test environment with virtualbox (its free) or whatever works with juns loader

look in the forum to find something that works, basics for virtualbox are

- mac of the nic (intel pro 1000 desktop) in vm and grub.conf need to be the same

- boot controller for jun's image (vmdk with reference to img file) is ide, controller for dsm disks is scsi lsi (!!!)

- choose esx server option in grub menu

 

1.4 installing chroot

put in http://packages.synocommunity.com for custom packages (http://packages.synocommunity.com) and change the setting that beside synology packages trusted ones are also to install

install debian-chroot plugin (https://synocommunity.com/package/debian-chroot) from community section

(some info's about it: https://github.com/SynoCommunity/spksrc ... e-services)

you might also install midnight commander if you are on it, makes things easier if you're not a command-line junky and more used to a graphical environment that give you clues

activate ssh in dsm

connect with ssh/putty to you dsm, login with user admin (and if you want to be root use "sudo -i")

start the chroot with:

/var/packages/debian-chroot/scripts/start-stop-status chroot

after that you are inside the chroot, check with ls and you won't see "/volume1" or other sysnology specific directory's from the dsm environment, you can leave the chroot environment with "exit" later if you want

now we have to update and install tools:

apt-get update

apt-get upgrade

apt-get install locales

dpkg-reconfigure locales

dpkg-reconfigure tzdata

apt-get install mc make gcc build-essential kernel-wedge libncurses5 libncurses5-dev libelf-dev binutils-dev kexec-tools makedumpfile locate

after that we create a directory (lets say "test")

 

1.5 copying kernel files and create kernel modules

copy the downloaded kernel (linux-3.10.x.txz) to a share on the dsm, open a 2nd putty and copy the linux-3.10.x.txz (/volume1/...) to /volume1/@appstore/debian-chroot/var/chroottarget/test/ (that's where the "test" directory of the chroot environment is located in your real system)

change back to your first putty where you are in chroot (the same way can be used to get the created files back to your shared folder on your volume1 which can be accessed from windows)

change into "test", extract the linux-3.10.x.txz to a directory named "linux-3.10.x" and change into it

the following copy's the kernel config file from synology to the right place for use/build

cp synoconfigs/bromolow .config

we make a fallback copy

make ARCH="x86_64" oldconfig

we start the ascii art menu and search for the missing driver to activate

cursor/return are your friend in navigating, space selects, we activate the driver to an "M" so its build as module (*.ko file we need)

there will be tons of descriptions how to do it, just google if needed

make ARCH="x86_64" menuconfig

on exit we save the configuration and with the following we make/create the modules (will take a while)

make ARCH="x86_64" modules

now you have to find your *.ko file (use some nice ls options, to be expanded later) usually you will have to look in /test/linux-3.10.x/drivers/scsi or block

 

copy that file to /test for easy access when we put it in the boot image

 

2. modify the "synoboot.img"

 

use osfmount (windows) to extract the "extra.lzma" (see dsm 5.2 to 6.0 guide, used there to edit grub.cfg in synoboot.img)

in "extra.lzma" are the additional *.ko files and a config file where the files to be loaded on boot are named

-> see forum thread "dsm 5.2 to 6.0" with howto to modify jun's loader for usb vid/pid and mac, its basically the same you just open the other partition (30MB) and extract the "extra.lzma"

copy the "extra.lzma" to the share of the dsm so we have local access in a putty session on dsm

in putty session #2 ("normal" session without chroot) we copy the "extra.lzma" to the "test" directory in the chroot environment

go to putty session#1 (in chroot)

decompress "extra.lzma" to "extra" ("extra.lzma" is a compressed cpio file) with:

lzma -d extra.lzma

with ls we can check that "extra.lzma" is now just ""extra" (a cpio file without the extension cpio)

create a new directory, copy the "extra" there, change into it and extract it with:

cpio -idv < extra

delete the remaining file "extra"

inside this directory we copy the *.ko file into usr/lib/modules/ and in /etc we edit the file rc.modules (easy with midnight commander, go to file, press F4, internal editor)

network drivers seems to be added under EXTRA_MODULES, storage drivers under DISK_MODULES, just go to the end of the line and fill in the name of the *.ko file without the ".ko", what you add is bsicly a blank and the name

rc.modules looks like this:

EXTRA_MODULES="mii mdio libphy atl1 atl1e atl1c alx uio ipg jme skge sky2 ptp_pch pch_gbe qla3xxx qlcnic qlge netxen_nic sfc e1000 pcnet32 vmxnet3 bnx2 libcrc32c bnx2x cnic e1000e igb ixgbe r8101 r8168 r8169 tg3 usbnet ax88179_178a button evdev ohci-hcd"

DISK_MODULES="BusLogic vmw_pvscsi megaraid_mm megaraid_mbox megaraid scsi_transport_spi mptbase mptscsih mptspi mptsas mptctl ata_piix megaraid_sas mpt2sas mpt3sas"

EXTRA_FIRMWARES="bnx2/bnx2-rv2p-09ax-6.0.17.fw bnx2/bnx2-rv2p-09-6.0.17.fw bnx2/bnx2-rv2p-06-6.0.15.fw tigon/tg3_tso5.bin tigon/tg3_tso.bin tigon/tg3.bin"

 

if your controller or nic needs a firmware, you add the file under usr/lib/modules/firmware/ and add the appropriate line in EXTRA_FIRMWARES, if a extra directory inside "firmware "is used it has to be added to the name, see the bnx2 firmware files

 

after everything is in place we recreate the cpio file, re-compress it as lzma and write it in the directory above as "extra.lzma"

the command is used inside the directory where we extracted the file "extra" (commandline taken from https://github.com/kref/scripts, its what jun uses to create it):

(find . -name modprobe && find . \! -name modprobe) | cpio --owner root:root -oH newc | lzma -8 > ../extra.lzma

 

in putty session #2 (without the chroot) we copy "extra.lzma" from the chroot position in filesystem to the location where we can access it from windows

if you still have osfmount open to the "synoboot.img" replace the "extra.lzma" with the new one, dismount and close osfmount - our new "synoboot.img" is ready to test it

 

ps: i was asked to make a video - thats much harder to change and i'm to old for this :wink:

 

Link to comment
Share on other sites

Вот тут добрый человек описал как в 1.02a дрова добавлять...

[spoiler=how to build and inject missing drivers in jun loader 1.02a]IG-88 » 25 апр 2017 01:37

kernel modules/drivers are specifically compiled for a kernel (-versions) and even distributions

it's not like windows where you can download a driver somewhere and just put it in

so don't take any *.ko file, stick it in and expect it to work

if you haven't build the *.ko yourself or don't know exactly where it came from, expect it to fail

I'm no expert but as there is no how-to here in the forum - lets start one

hopefully other will correct and help refine or take over and rewrite it

some steps are made in windows (osfmount) but will also possible in the chroot environment on linux

basic knowledge about using a linux console and command-line tools (or midnight commander) is needed, if you never used this you should not start with this how-to, choose something easier or invite someone who is able to help (do a workshop)

doing all this from scratch will take at least 1-2 hours, in most cases (re-read, google, try, google, try again, ...) much longer, maybe plan a weekend of text-adventure fun

 

 

1. building the kernel module (driver)

 

1.1 what driver/module i need

you will have to find out (google) what the name of the driver/module is that your hardware needs or you will have to know where to find the rigt option in the menu-system of the kernel when configuring it

example: nForce 630 chipset with RTL8211E, youu might expect it to be a realtek driver like rtl*.ko but it's not its "forcedeth.ko" because the RTL8211 is not a fully working PCIe Network Chip

in some cases you might be forced to find out by booting a linux distribution and look in /var/log/, use lspci or other tools

it also helps if the hardware provider has already compiled packages for specific distributions like redhat, you can look inside these packages for *.ko files

you also can look in the .config file of the kernel (more below) with a text editor to find a section where the module is mentioned, this will also give you a hint where to find it in the menu-system when configuring the kernel

 

1.2 you need the kernel source

in the case of synology that seemed sometimes difficult but at the moment there is kernel source for dsm 6.1

 

https://sourceforge.net/projects/dsgpl/ ... %20Source/

 

15047 is the version and tells you about what dsm version it is (15057 = dsm 6.1), it might change in a later version of 6.1 so always check for what version your bootloader from usb stick is made for (jun 1.02 is for 15047)

as i write this for ds3615xs it's bromolow as a platform, for ds3617xs it's broadwell and ds916+ is braswell (you usually see that name on the update files for a synology system like "synology_broadwell_3617xs.pat")

so for ds3615xs we use this:

https://sourceforge.net/projects/dsgpl/ ... z/download

 

1.3 setting up a DSM 6.1 ds3615xs test environment with virtualbox (its free) or whatever works with juns loader

look in the forum to find something that works, basics for virtualbox are

- mac of the nic (intel pro 1000 desktop) in vm and grub.conf need to be the same

- boot controller for jun's image (vmdk with reference to img file) is ide, controller for dsm disks is scsi lsi (!!!)

- choose esx server option in grub menu

 

1.4 installing chroot

put in http://packages.synocommunity.com for custom packages (http://packages.synocommunity.com) and change the setting that beside synology packages trusted ones are also to install

install debian-chroot plugin (https://synocommunity.com/package/debian-chroot) from community section

(some info's about it: https://github.com/SynoCommunity/spksrc ... e-services)

you might also install midnight commander if you are on it, makes things easier if you're not a command-line junky and more used to a graphical environment that give you clues

activate ssh in dsm

connect with ssh/putty to you dsm, login with user admin (and if you want to be root use "sudo -i")

start the chroot with:

/var/packages/debian-chroot/scripts/start-stop-status chroot

after that you are inside the chroot, check with ls and you won't see "/volume1" or other sysnology specific directory's from the dsm environment, you can leave the chroot environment with "exit" later if you want

now we have to update and install tools:

apt-get update

apt-get upgrade

apt-get install locales

dpkg-reconfigure locales

dpkg-reconfigure tzdata

apt-get install mc make gcc build-essential kernel-wedge libncurses5 libncurses5-dev libelf-dev binutils-dev kexec-tools makedumpfile locate

after that we create a directory (lets say "test")

 

1.5 copying kernel files and create kernel modules

copy the downloaded kernel (linux-3.10.x.txz) to a share on the dsm, open a 2nd putty and copy the linux-3.10.x.txz (/volume1/...) to /volume1/@appstore/debian-chroot/var/chroottarget/test/ (that's where the "test" directory of the chroot environment is located in your real system)

change back to your first putty where you are in chroot (the same way can be used to get the created files back to your shared folder on your volume1 which can be accessed from windows)

change into "test", extract the linux-3.10.x.txz to a directory named "linux-3.10.x" and change into it

the following copy's the kernel config file from synology to the right place for use/build

cp synoconfigs/bromolow .config

we make a fallback copy

make ARCH="x86_64" oldconfig

we start the ascii art menu and search for the missing driver to activate

cursor/return are your friend in navigating, space selects, we activate the driver to an "M" so its build as module (*.ko file we need)

there will be tons of descriptions how to do it, just google if needed

make ARCH="x86_64" menuconfig

on exit we save the configuration and with the following we make/create the modules (will take a while)

make ARCH="x86_64" modules

now you have to find your *.ko file (use some nice ls options, to be expanded later) usually you will have to look in /test/linux-3.10.x/drivers/scsi or block

 

copy that file to /test for easy access when we put it in the boot image

 

2. modify the "synoboot.img"

 

use osfmount (windows) to extract the "extra.lzma" (see dsm 5.2 to 6.0 guide, used there to edit grub.cfg in synoboot.img)

in "extra.lzma" are the additional *.ko files and a config file where the files to be loaded on boot are named

-> see forum thread "dsm 5.2 to 6.0" with howto to modify jun's loader for usb vid/pid and mac, its basically the same you just open the other partition (30MB) and extract the "extra.lzma"

copy the "extra.lzma" to the share of the dsm so we have local access in a putty session on dsm

in putty session #2 ("normal" session without chroot) we copy the "extra.lzma" to the "test" directory in the chroot environment

go to putty session#1 (in chroot)

decompress "extra.lzma" to "extra" ("extra.lzma" is a compressed cpio file) with:

lzma -d extra.lzma

with ls we can check that "extra.lzma" is now just ""extra" (a cpio file without the extension cpio)

create a new directory, copy the "extra" there, change into it and extract it with:

cpio -idv < extra

delete the remaining file "extra"

inside this directory we copy the *.ko file into usr/lib/modules/ and in /etc we edit the file rc.modules (easy with midnight commander, go to file, press F4, internal editor)

network drivers seems to be added under EXTRA_MODULES, storage drivers under DISK_MODULES, just go to the end of the line and fill in the name of the *.ko file without the ".ko", what you add is bsicly a blank and the name

rc.modules looks like this:

EXTRA_MODULES="mii mdio libphy atl1 atl1e atl1c alx uio ipg jme skge sky2 ptp_pch pch_gbe qla3xxx qlcnic qlge netxen_nic sfc e1000 pcnet32 vmxnet3 bnx2 libcrc32c bnx2x cnic e1000e igb ixgbe r8101 r8168 r8169 tg3 usbnet ax88179_178a button evdev ohci-hcd"

DISK_MODULES="BusLogic vmw_pvscsi megaraid_mm megaraid_mbox megaraid scsi_transport_spi mptbase mptscsih mptspi mptsas mptctl ata_piix megaraid_sas mpt2sas mpt3sas"

EXTRA_FIRMWARES="bnx2/bnx2-rv2p-09ax-6.0.17.fw bnx2/bnx2-rv2p-09-6.0.17.fw bnx2/bnx2-rv2p-06-6.0.15.fw tigon/tg3_tso5.bin tigon/tg3_tso.bin tigon/tg3.bin"

 

if your controller or nic needs a firmware, you add the file under usr/lib/modules/firmware/ and add the appropriate line in EXTRA_FIRMWARES, if a extra directory inside "firmware "is used it has to be added to the name, see the bnx2 firmware files

 

after everything is in place we recreate the cpio file, re-compress it as lzma and write it in the directory above as "extra.lzma"

the command is used inside the directory where we extracted the file "extra" (commandline taken from https://github.com/kref/scripts, its what jun uses to create it):

(find . -name modprobe && find . \! -name modprobe) | cpio --owner root:root -oH newc | lzma -8 > ../extra.lzma

 

in putty session #2 (without the chroot) we copy "extra.lzma" from the chroot position in filesystem to the location where we can access it from windows

if you still have osfmount open to the "synoboot.img" replace the "extra.lzma" with the new one, dismount and close osfmount - our new "synoboot.img" is ready to test it

 

ps: i was asked to make a video - thats much harder to change and i'm to old for this :wink:

И есть тут умельцы кто может собрать с нужными драйверами?

Link to comment
Share on other sites

  • Andy928 unpinned this topic
  • 4 months later...
  • 7 months later...
В 27.4.2017 в 10:09, b0g0m0l сказал:

И есть тут умельцы кто может собрать с нужными драйверами?

 

В 16.11.2017 в 09:33, XerSonik сказал:

Поддерживаю, дрова на сеть добавить надо.

жмакаем на клаву 'м'

 

918d99b.thumb.png.709fd1997d4c23fb2d7178c9581133ae.png

 

Edited by Архип
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...