Vlad1976 Posted April 19, 2016 Share #51 Posted April 19, 2016 может просто все сведется к тому что можно будет сделать свой обычный дистр с фичами синолоджи? и не нужен будет загрузчик? Стесняюсь спросить, но всё же а какими фичами обладает DSM по вашему мнению? Если всё выше сказанное верно, то DSM это грубо говоря просто вебморда на линуксе. Quote Link to comment Share on other sites More sharing options...
loderunner Posted April 20, 2016 Share #52 Posted April 20, 2016 Если всё выше сказанное верно, то DSM это грубо говоря просто вебморда на линуксе. Грубее некуда. Учитывая, сколько их собственных бинарных утилит там задействовано. Quote Link to comment Share on other sites More sharing options...
aisman Posted April 20, 2016 Share #53 Posted April 20, 2016 Если всё выше сказанное верно, то DSM это грубо говоря просто вебморда на линуксе. Грубее некуда. Учитывая, сколько их собственных бинарных утилит там задействовано. Плюсую. Они даже умудрились как-то расписание cron в бинари превратить, слегка был "удивлён" когда это увидел. Quote Link to comment Share on other sites More sharing options...
valsha Posted April 20, 2016 Share #54 Posted April 20, 2016 и над btrfs я тк думаю они хорошо поработали. раз выпустили его в продакшен. так что это далеко не веб морда только. Quote Link to comment Share on other sites More sharing options...
Fox_exe Posted April 22, 2016 Share #55 Posted April 22, 2016 и над 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 и серийника хранятся на тойже флешке, что и загрузчик с ядром. + поддержка самой флешки, разумеется. Quote Link to comment Share on other sites More sharing options...
depesh Posted February 13, 2017 Share #56 Posted February 13, 2017 Внимание! Все действия, описанные в данной документации, производились в научно-познавательных целях, и не имеют цели извлечения какой-либо прибыли. Раздел 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 хренолог В планах: 1) Нарисовать эмулятор монитора и встроить его в ядро. Либо выполнить его в виде демона. 2) Адаптировать какой-нибудь китайский девайс, типа (http://www.aliexpress.com/item/4-Fan-Sp ... 36498.html) для вывода информации о дисках и т.д... Мвмочки дорогие,openwrt пока научился с исходников собирать на заказ месяца два зубрил.А тут на полгода бессоных ночей.Но за то для openwrt у меня проект висит на 4pda.Будем курить. Quote Link to comment Share on other sites More sharing options...
A.S._id Posted February 14, 2017 Share #57 Posted February 14, 2017 Мвмочки дорогие,openwrt пока научился с исходников собирать на заказ месяца два зубрил.А тут на полгода бессоных ночей.Но за то для openwrt у меня проект висит на 4pda.Будем курить. на 4pda за такой оверквотинг зобанеле бы на пару ночей хе-хе... на самом деле тут особо изучать нечего, с мосента написания описалова сборки уже как от сотворения мира прошло... Всё давно изменилось, ядро собирается обычно с нужными модулями, а все хаки идут в сценарии бутлодера из рамдиска т.е. защита хачится попутно, во время загрузки ядра, но эта процедура тута не описана и никто не расскажет как чего, надоть самому брать загрузчег, разбирать рамдиск и ковырять скрипты... Quote Link to comment Share on other sites More sharing options...
Olegin Posted April 25, 2017 Share #58 Posted April 25, 2017 Вот тут добрый человек описал как в 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 Quote Link to comment Share on other sites More sharing options...
b0g0m0l Posted April 27, 2017 Share #59 Posted April 27, 2017 Вот тут добрый человек описал как в 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 И есть тут умельцы кто может собрать с нужными драйверами? Quote Link to comment Share on other sites More sharing options...
XerSonik Posted November 16, 2017 Share #60 Posted November 16, 2017 Поддерживаю, дрова на сеть добавить надо. Quote Link to comment Share on other sites More sharing options...
webrusik Posted June 24, 2018 Share #61 Posted June 24, 2018 Обновленного мануала случаем по сборки своего загрузчика нет? Quote Link to comment Share on other sites More sharing options...
Архип Posted June 24, 2018 Share #62 Posted June 24, 2018 (edited) В 27.4.2017 в 10:09, b0g0m0l сказал: И есть тут умельцы кто может собрать с нужными драйверами? В 16.11.2017 в 09:33, XerSonik сказал: Поддерживаю, дрова на сеть добавить надо. жмакаем на клаву 'м' Edited June 24, 2018 by Архип Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.