Во многих встраиваемых устройствах требуется максимально быстро прийти к рабочему состоянию после подачи питания или перезагрузки. Обычный линукс грузится довольно таки медленно, пока он прогрузит все драйвера, проходит секунд 10-20, если не больше. Можно ли сделать так, чтобы образ работающего (полностью загруженного) линукса со всеми драйверами сохранить во флеш-памяти и при старте системы просто копировать этот образ в оперативную память? Т.е. сделать аналог Hibernate в Windows.
Хотелось бы добиться времени старта в 1-2сек максимум.
Если да, то кто будет инициализировать железо в таком случае (видео, сеть, UART...), в компе это делает частично BIOS, частично сама Windows? Использовать планирую ucLinux, но, по идее, особой разницы быть не должно.
Полная версия этой страницы: Быстрая загрузка Linux - возможно ли?
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > Linux
А че у вас драйвера так тормозят? По моему этот вопрос надо решать.
Боюсь у вас тормозят не драйвера, а как раз те файловые операции на которые вы хотите возложить сохранение снимка системы на диск.
Т.е. сохранение на диск образа из такой средненькой RAM в 64 Мб как раз выльется в 20 сек. Ну и восстановление в 15 сек.
Боюсь у вас тормозят не драйвера, а как раз те файловые операции на которые вы хотите возложить сохранение снимка системы на диск.
Т.е. сохранение на диск образа из такой средненькой RAM в 64 Мб как раз выльется в 20 сек. Ну и восстановление в 15 сек.
Цитата(Itch @ Jun 18 2009, 17:48) 
Во многих встраиваемых устройствах требуется максимально быстро прийти к рабочему состоянию после подачи питания или перезагрузки. Обычный линукс грузится довольно таки медленно, пока он прогрузит все драйвера, проходит секунд 10-20, если не больше. Можно ли сделать так, чтобы образ работающего (полностью загруженного) линукса со всеми драйверами сохранить во флеш-памяти и при старте системы просто копировать этот образ в оперативную память? Т.е. сделать аналог Hibernate в Windows.
Хотелось бы добиться времени старта в 1-2сек максимум.
Если да, то кто будет инициализировать железо в таком случае (видео, сеть, UART...), в компе это делает частично BIOS, частично сама Windows? Использовать планирую ucLinux, но, по идее, особой разницы быть не должно.
Хотелось бы добиться времени старта в 1-2сек максимум.
Если да, то кто будет инициализировать железо в таком случае (видео, сеть, UART...), в компе это делает частично BIOS, частично сама Windows? Использовать планирую ucLinux, но, по идее, особой разницы быть не должно.
Использовал демобоард на RM9200 от Черкашина, линукс качал с его же сайта. Я не спец в этом, да и давно это было, но там похоже что распаковывалось все из сжатого образа. Время загрузки было действительно большое, причем сама распаковка - секунд 5, потом потихоньку запускался линукс, выводя в консоль строки.
Если даже прикинуть, пусть образ будет хранится в отдельной последовательной флешке (SD карта). Скорость чтения с нее пусть 10МВ/sec. За 1 секунду 8MB образ можно закачать в SDRAM. Либо вообще, хранить линукс в NAND флешке, с него же пусть и работает. Тогда даже копировать ничего не надо. Вопрос в том, можно ли такое проделать с линуксом?
Кстати, есть автонавигатор. Там стоит 64М NAND флеши и 64М SDRAM. ОС - WinCE 5.0, полность грузится за 11 сек, картинка на экране рисуется через 3 сек. Из спящего режима вообще моментально выходит.
Если даже прикинуть, пусть образ будет хранится в отдельной последовательной флешке (SD карта). Скорость чтения с нее пусть 10МВ/sec. За 1 секунду 8MB образ можно закачать в SDRAM. Либо вообще, хранить линукс в NAND флешке, с него же пусть и работает. Тогда даже копировать ничего не надо. Вопрос в том, можно ли такое проделать с линуксом?
Кстати, есть автонавигатор. Там стоит 64М NAND флеши и 64М SDRAM. ОС - WinCE 5.0, полность грузится за 11 сек, картинка на экране рисуется через 3 сек. Из спящего режима вообще моментально выходит.
Скорость чтения из SD вы сильно преувеличили если конечно не подразумеваете самые свежие навороченные чипсеты с повышеной частотой SD контроллера.
Вообщем будет у вас в случае FAT не больше 4 МВ/sec. На NAND не намного больше. Еще сильно зависит от кривизны драйверов которые вам достанутся из дистрибутива на чип.
Прога из NAND флеши выполняться не может, это не есть память с произвольным доступом.
Для старта из памяти нужна NOR Flash.
Ядро Линукса можно скомпилировать в конфигурации XIP (eXecution In Place) и без сжатия.
Бутлодер надо будет подточить для этого. Кстати он тож время кой-какое забирает.
Но самая досадная фигня в Линуксе это файловая система.
Тут есть дилема.
Либо вы делаете файловую систему быструю и в RAM, но тогда надо ее туда долго грузить из NAND или SD и получаете ее не персистентную, либо сразу запускаете драйвер какой либо файловой системы на Flash и стартуете файловую систему достаточно быстро, но потом имеете низкоскоростной доступ.
Кстати не всякая файловая система на Flash быстро стартует, ибо особо хитрые компактные embedded системы начинают читать весь диск для постороения базы данных для wear leveling, соответственно старт откладывается.
Еще у некоторых систем идет сжатие на лету при записи, тож тормоза дополнительные.
Поскольку в Линуксе ничего без файловых операций не обходится, то скорость файловой системы на старте имеет большое значение.
При объеме ядра где-то в 3 мега, файловая система будет минимум занимать 8 мег со всякими либами, busybox-ами и приложением.
Кстати старт картинки на QNX- 0.5 сек. Стоит подумать
Вообщем будет у вас в случае FAT не больше 4 МВ/sec. На NAND не намного больше. Еще сильно зависит от кривизны драйверов которые вам достанутся из дистрибутива на чип.
Прога из NAND флеши выполняться не может, это не есть память с произвольным доступом.
Для старта из памяти нужна NOR Flash.
Ядро Линукса можно скомпилировать в конфигурации XIP (eXecution In Place) и без сжатия.
Бутлодер надо будет подточить для этого. Кстати он тож время кой-какое забирает.
Но самая досадная фигня в Линуксе это файловая система.
Тут есть дилема.
Либо вы делаете файловую систему быструю и в RAM, но тогда надо ее туда долго грузить из NAND или SD и получаете ее не персистентную, либо сразу запускаете драйвер какой либо файловой системы на Flash и стартуете файловую систему достаточно быстро, но потом имеете низкоскоростной доступ.
Кстати не всякая файловая система на Flash быстро стартует, ибо особо хитрые компактные embedded системы начинают читать весь диск для постороения базы данных для wear leveling, соответственно старт откладывается.
Еще у некоторых систем идет сжатие на лету при записи, тож тормоза дополнительные.
Поскольку в Линуксе ничего без файловых операций не обходится, то скорость файловой системы на старте имеет большое значение.
При объеме ядра где-то в 3 мега, файловая система будет минимум занимать 8 мег со всякими либами, busybox-ами и приложением.
Кстати старт картинки на QNX- 0.5 сек. Стоит подумать
Цитата(Itch @ Jun 18 2009, 21:20)
Использовал демобоард на RM9200 от Черкашина, линукс качал с его же сайта. Я не спец в этом, да и давно это было, но там похоже что распаковывалось все из сжатого образа. Время загрузки было действительно большое, причем сама распаковка - секунд 5, потом потихоньку запускался линукс, выводя в консоль строки.
Если даже прикинуть, пусть образ будет хранится в отдельной последовательной флешке (SD карта). Скорость чтения с нее пусть 10МВ/sec. За 1 секунду 8MB образ можно закачать в SDRAM. Либо вообще, хранить линукс в NAND флешке, с него же пусть и работает. Тогда даже копировать ничего не надо. Вопрос в том, можно ли такое проделать с линуксом?
Кстати, есть автонавигатор. Там стоит 64М NAND флеши и 64М SDRAM. ОС - WinCE 5.0, полность грузится за 11 сек, картинка на экране рисуется через 3 сек. Из спящего режима вообще моментально выходит.
Если даже прикинуть, пусть образ будет хранится в отдельной последовательной флешке (SD карта). Скорость чтения с нее пусть 10МВ/sec. За 1 секунду 8MB образ можно закачать в SDRAM. Либо вообще, хранить линукс в NAND флешке, с него же пусть и работает. Тогда даже копировать ничего не надо. Вопрос в том, можно ли такое проделать с линуксом?
Кстати, есть автонавигатор. Там стоит 64М NAND флеши и 64М SDRAM. ОС - WinCE 5.0, полность грузится за 11 сек, картинка на экране рисуется через 3 сек. Из спящего режима вообще моментально выходит.
Поwikiл слово XIP, нашел интересную pdf-ку. Оказывается, даже без XIP есть большой простор для оптимизации.
В навигаторе стоит Sirf Atlas III, он на основе самсунговского ARMа. В даташите, емнип, было сказано, что работа с NAND обеспечивается прозрачная, т.е. как c NOR.
В навигаторе стоит Sirf Atlas III, он на основе самсунговского ARMа. В даташите, емнип, было сказано, что работа с NAND обеспечивается прозрачная, т.е. как c NOR.
Цитата(AlexandrY @ Jun 18 2009, 23:42)
Скорость чтения из SD вы сильно преувеличили если конечно не подразумеваете самые свежие навороченные чипсеты с повышеной частотой SD контроллера.
Вообщем будет у вас в случае FAT не больше 4 МВ/sec.
Вообщем будет у вас в случае FAT не больше 4 МВ/sec.
все
Оптимисты вы тут
сомневаюсь что на RM9200 вы получите больше 1 мб/сек, а на небуферизованном посекторном чтении и того меньше - 100-150 кб/сек. Кстати - а зачем загрузчику вообще какая-то фс ?Цитата
Но самая досадная фигня в Линуксе это файловая система.
Тут есть дилема.
Либо вы делаете файловую систему быструю и в RAM, но тогда надо ее туда долго грузить из NAND или SD и получаете ее не персистентную, либо сразу запускаете драйвер какой либо файловой системы на Flash и стартуете файловую систему достаточно быстро, но потом имеете низкоскоростной доступ.
Тут есть дилема.
Либо вы делаете файловую систему быструю и в RAM, но тогда надо ее туда долго грузить из NAND или SD и получаете ее не персистентную, либо сразу запускаете драйвер какой либо файловой системы на Flash и стартуете файловую систему достаточно быстро, но потом имеете низкоскоростной доступ.
О - опять про фс
фс в рам требуется только для устаревшего initrd, в образе initramfs никакой настоящей фс нет- там аналог tmpfs и работает действительно быстро.Цитата
Поскольку в Линуксе ничего без файловых операций не обходится, то скорость файловой системы на старте имеет большое значение. При объеме ядра где-то в 3 мега, файловая система будет минимум занимать 8 мег со всякими либами, busybox-ами и приложением.
Для старта ядра вообще фс не нужна, она нужна для корня и запуска Init, опять же с initramfs вообще никаких тормозов нет, можно хранить там все необходимые для старта а все остальное просто подмонтировать.
Цитата
Кстати старт картинки на QNX- 0.5 сек. Стоит подумать
я подумал - а чего так медленно ?
имхо болше всего времни при старте уходит на распаковку и на поиск-инициализацию устройств а кто будет их инициализировать при быстром старте ?
Какая точно марка чипа?
Что, так и написано: "прозрачная, как с NOR"?
Сильно сомневаюсь.
Обычная практика это когда встроенный в ROM чипа первичный монитор читает во внутреннюю RAM чипа первую страницу первого блока NAND.
Там сидит уже вторичный короткий загрузчик написанный юзером
ROM монитор отдает управлением во внутренней RAM ему
Тот в свою очередь грузит из NAND третичный полнофункциональный загрузчик (типа UBoot) уже во внешнюю RAM.
И тот уже из NAND-а во внешнюю RAM грузит либо Линукс либо опять Линукс с его собственным распаковщиком.
Причем он может Линукс грузить по тому же адресу где сидит UBoot, ну тогда еще будет этап перемещения UBoot в другое место внешней RAM.
Вот это вот и величают "прозрачной" работой.
Т.е. тормоза еще те.
А pdf-ка найденая вами может сильно ввести в заблуждение.
Вообще нужно очень осторожно верить всем утверждениям которые идут от пользователей Линукса на PC.
Инициализация в Линуксе для каждой архитектуры во многом реализуется уникально в отдельной директории ARCH, поэтому причины задержек тоже во многом уникальны.
Что, так и написано: "прозрачная, как с NOR"?
Сильно сомневаюсь.
Обычная практика это когда встроенный в ROM чипа первичный монитор читает во внутреннюю RAM чипа первую страницу первого блока NAND.
Там сидит уже вторичный короткий загрузчик написанный юзером
ROM монитор отдает управлением во внутренней RAM ему
Тот в свою очередь грузит из NAND третичный полнофункциональный загрузчик (типа UBoot) уже во внешнюю RAM.
И тот уже из NAND-а во внешнюю RAM грузит либо Линукс либо опять Линукс с его собственным распаковщиком.
Причем он может Линукс грузить по тому же адресу где сидит UBoot, ну тогда еще будет этап перемещения UBoot в другое место внешней RAM.
Вот это вот и величают "прозрачной" работой.
Т.е. тормоза еще те.
А pdf-ка найденая вами может сильно ввести в заблуждение.
Вообще нужно очень осторожно верить всем утверждениям которые идут от пользователей Линукса на PC.
Инициализация в Линуксе для каждой архитектуры во многом реализуется уникально в отдельной директории ARCH, поэтому причины задержек тоже во многом уникальны.
Цитата(Itch @ Jun 19 2009, 06:59)
Поwikiл слово XIP, нашел интересную pdf-ку. Оказывается, даже без XIP есть большой простор для оптимизации.
В навигаторе стоит Sirf Atlas III, он на основе самсунговского ARMа. В даташите, емнип, было сказано, что работа с NAND обеспечивается прозрачная, т.е. как c NOR.
В навигаторе стоит Sirf Atlas III, он на основе самсунговского ARMа. В даташите, емнип, было сказано, что работа с NAND обеспечивается прозрачная, т.е. как c NOR.
Цитата(sasamy @ Jun 19 2009, 12:36)
все
Оптимисты вы тут сомневаюсь что на RM9200 вы получите больше 1 мб/сек, а на небуферизованном посекторном чтении и того меньше - 100-150 кб/сек. Кстати - а зачем загрузчику вообще какая-то фс ?
Оптимисты вы тут
сомневаюсь что на RM9200 вы получите больше 1 мб/сек, а на небуферизованном посекторном чтении и того меньше - 100-150 кб/сек. Кстати - а зачем загрузчику вообще какая-то фс ?По идее, нафиг не не надо FS. Есть 8М RAM, в котором лежит запущенная ОСь. Просто сохраняем в отдельную флеш 8М и все. Когда надо стартануть просто копируем обратно в память. AT45DB642D емкостью в 8МБайт поддерживает скорость по SPI до 66МГц, т.е. ~8М/сек. Для Blackfin, на котором я собираюсь делать плату, это точно не проблема.
Цитата(sasamy @ Jun 19 2009, 12:36)
имхо болше всего времни при старте уходит на распаковку и на поиск-инициализацию устройств а кто будет их инициализировать при быстром старте ?
Вот и интересно. Должен быть системный вызов для переинициализации драйверов устройств. Опять же, времени на то, чтобы записать несколько регистров много не надо. Если конфигурация платы известна, ничего никогда не меняется, то никаких особых Plug'n'Play не нужно.
Вы еще не поняли с чем связались
На нормальной RTOS старт всей системы со всеми драйверами длиться не более 0.1 (cм. uCOS) сек и без всякого сохранения RAM на диск.
Если вы планируете обойтись всего 8 MB рама на код и на данные, значит никаких серьезных пакетов в системе запускать не собираетесь.
uCLinux в этой ситуации никаких преимуществ по сравнению с той же uCOS не даст.
А развод с uCLinux на BF меня всегда прикалывал. Там инициализировать по сути нечего, самая бедная архитектура в плане периферии, а 600 МГц платформа грузиться добрые полминуты.
А на демонстрациях этот uCLinux представляют как невероятно крутую фичу BF.
На нормальной RTOS старт всей системы со всеми драйверами длиться не более 0.1 (cм. uCOS) сек и без всякого сохранения RAM на диск.
Если вы планируете обойтись всего 8 MB рама на код и на данные, значит никаких серьезных пакетов в системе запускать не собираетесь.
uCLinux в этой ситуации никаких преимуществ по сравнению с той же uCOS не даст.
А развод с uCLinux на BF меня всегда прикалывал. Там инициализировать по сути нечего, самая бедная архитектура в плане периферии, а 600 МГц платформа грузиться добрые полминуты.
А на демонстрациях этот uCLinux представляют как невероятно крутую фичу BF.
Цитата(Itch @ Jun 19 2009, 10:03)
По идее, нафиг не не надо FS. Есть 8М RAM, в котором лежит запущенная ОСь. Просто сохраняем в отдельную флеш 8М и все. Когда надо стартануть просто копируем обратно в память. AT45DB642D емкостью в 8МБайт поддерживает скорость по SPI до 66МГц, т.е. ~8М/сек. Для Blackfin, на котором я собираюсь делать плату, это точно не проблема.
Вот и интересно. Должен быть системный вызов для переинициализации драйверов устройств. Опять же, времени на то, чтобы записать несколько регистров много не надо. Если конфигурация платы известна, ничего никогда не меняется, то никаких особых Plug'n'Play не нужно.
Вот и интересно. Должен быть системный вызов для переинициализации драйверов устройств. Опять же, времени на то, чтобы записать несколько регистров много не надо. Если конфигурация платы известна, ничего никогда не меняется, то никаких особых Plug'n'Play не нужно.
Цитата(Itch @ Jun 19 2009, 11:03)
Для Blackfin, на котором я собираюсь делать плату, это точно не проблема.
не вопрос - можно получить хорошие скорости, я просто конкретно про rm9200 ситуацию уточнил
Цитата
Должен быть системный вызов для переинициализации драйверов устройств.
Видели наверно в конце загрузки ядра сообщение типа Freeing unused kernel memory: Nk freed так вот это ядро избавляется от того самого кода и данных инициализации который вы хотите вызвать повторно
Он помечен __init в драйверах, после загрузки ядра его нет больше в памяти.
Весь Analog Devices не смог решить проблему, а для вас нивапрос? 
В конфигурации XIP ничего не удаляется. Смотрите файл линкера *.lds
Цитата(sasamy @ Jun 19 2009, 11:16)
не вопрос - можно получить хорошие скорости, я просто конкретно про rm9200 ситуацию уточнил
В конфигурации XIP ничего не удаляется. Смотрите файл линкера *.lds
Цитата(sasamy @ Jun 19 2009, 11:16)
Видели наверно в конце загрузки ядра сообщение типа Freeing unused kernel memory: Nk freed так вот это ядро избавляется от того самого кода и данных инициализации который вы хотите вызвать повторно Он помечен __init в драйверах, после загрузки ядра его нет больше в памяти.
Он помечен __init в драйверах, после загрузки ядра его нет больше в памяти.Цитата(AlexandrY @ Jun 19 2009, 13:04)
Какая точно марка чипа?
Что, так и написано: "прозрачная, как с NOR"?
Что, так и написано: "прозрачная, как с NOR"?
Samsung S3C2440A. Вот что пишут:
Цитата
NAND Flash Boot Loader
· Supports booting from NAND flash memory.
· 4KB internal buffer for booting.
· Supports storage memory for NAND flash memory
after booting.
· Supports Advanced NAND flash
· Supports booting from NAND flash memory.
· 4KB internal buffer for booting.
· Supports storage memory for NAND flash memory
after booting.
· Supports Advanced NAND flash
И еще:
Цитата
In recent times, NOR flash memory gets high in price while an SDRAM and a NAND flash memory is comparatively
economical , motivating some users to execute the boot code on a NAND flash and execute the main code on an
SDRAM.
S3C2440A boot code can be executed on an external NAND flash memory. In order to support NAND flash boot
loader, the S3C2440A is equipped with an internal SRAM buffer called ‘Steppingstone’. When booting, the first 4
KBytes of the NAND flash memory will be loaded into Steppingstone and the boot code loaded into Steppingstone
will be executed.
Generally, the boot code will copy NAND flash content to SDRAM. Using hardware ECC, the NAND flash data
validity will be checked. Upon the completion of the copy, the main program will be executed on the SDRAM.
economical , motivating some users to execute the boot code on a NAND flash and execute the main code on an
SDRAM.
S3C2440A boot code can be executed on an external NAND flash memory. In order to support NAND flash boot
loader, the S3C2440A is equipped with an internal SRAM buffer called ‘Steppingstone’. When booting, the first 4
KBytes of the NAND flash memory will be loaded into Steppingstone and the boot code loaded into Steppingstone
will be executed.
Generally, the boot code will copy NAND flash content to SDRAM. Using hardware ECC, the NAND flash data
validity will be checked. Upon the completion of the copy, the main program will be executed on the SDRAM.
Т.е. только bootloader, но зато NOR'ы уже не надо.
P.S. Прикольная заметка в конце:
Цитата
During the auto boot, the ECC is not checked. So, the first 4-KB of NAND flash should have no bit error.
Эт к щастью на этой конфе знают все.
Новость в том что у них 4K вместо 2-х, но UBoot все равно не влезет и моя 3-х...4-х ступенчатая схема для вас остается в силе.
Поэтому если хотите действительно быстро без NOR-ы не обойтись.
Эт как разработчик вы тоже должны были бы знать, что во всех NAND гарантируют что первый блок всегда работоспособен.
Новость в том что у них 4K вместо 2-х, но UBoot все равно не влезет и моя 3-х...4-х ступенчатая схема для вас остается в силе.
Поэтому если хотите действительно быстро без NOR-ы не обойтись.
Цитата(Itch @ Jun 19 2009, 11:37)
Т.е. только bootloader, но зато NOR'ы уже не надо.
Эт как разработчик вы тоже должны были бы знать, что во всех NAND гарантируют что первый блок всегда работоспособен.
Цитата(Itch @ Jun 19 2009, 11:37)
P.S. Прикольная заметка в конце:
Цитата(AlexandrY @ Jun 19 2009, 15:46)
Эт как разработчик вы тоже должны были бы знать, что во всех NAND гарантируют что первый блок всегда работоспособен.
Кажется, всегда работоспособен в начале своей жизни. Но когда-то он также может умереть, как и любой другой блок. Хотя тут конечно вероятность много ниже, ибо бутсектор редко кто пишет больше нескольких раз.
Цитата(AlexandrY @ Jun 19 2009, 11:35)
Весь Analog Devices не смог решить проблему, а для вас нивапрос?
В конфигурации XIP ничего не удаляется. Смотрите файл линкера *.lds
В конфигурации XIP ничего не удаляется. Смотрите файл линкера *.lds
проблемы Analog Devices - это проблемы Analog Devices, речь шла о том что на rm9200 читать sd быстро не получится но вообще быстрое чтение с внешнего носителя - не вопрос.
При чем тут вообще xip - не путайте теплое с мягким, речь шла об аналоге hibernate в windows, он кстати вполне себе живет в linux на х86 - suspend to disk называется, используя acpi, так вот проблема в том что после восстановления образа ram с нешнего носителя нужно заново инициализировать периферию так как питание было полностью отключено, но в ram кода инициализации уже нет, так как ядро при загрузке освободилось от него.
Цитата(sasamy @ Jun 19 2009, 15:16)
Видели наверно в конце загрузки ядра сообщение типа Freeing unused kernel memory: Nk freed так вот это ядро избавляется от того самого кода и данных инициализации который вы хотите вызвать повторно Он помечен __init в драйверах, после загрузки ядра его нет больше в памяти.
Он помечен __init в драйверах, после загрузки ядра его нет больше в памяти.Экономят на спичках. Ну освободили они пару килобайт памяти от кода инициализации, толку то? Хотя возможность отключить это действие должна быть.
Кстати, кто в PC занимается инициализацией периферии при действии, обратном suspend to disk?
Цитата(Itch @ Jun 19 2009, 13:14)
Экономят на спичках. Ну освободили они пару килобайт памяти от кода инициализации, толку то? Хотя возможность отключить это действие должна быть.
Кстати, кто в PC занимается инициализацией периферии при действии, обратном suspend to disk?
Кстати, кто в PC занимается инициализацией периферии при действии, обратном suspend to disk?
для некоторых систем 100-200 кб ram лишними не бывают... инициализацией скорей всего занимается сама bios которая предоставляет интерфейс acpi, но это имхо, я не разбирался с этим, есть еще разные программы в linux котрые якобы следят за правильным засыпанием/восстановлением системы но имхо они всего лишь пытаются правильно восстановить работу демонов в userspace.
Кстати - заново выполнить код инициализации в подавляющем большинстве случаев не получится - там выпоняются такие действия как резервирование irq, выделение памяти под буферы и кеши и тд и тп котрые при повторе просто завалят систему, так что имхо это вообще фантастика для систем не имеющих bios и acpi как в x86.
Цитата(Itch @ Jun 18 2009, 18:48)
Хотелось бы добиться времени старта в 1-2сек максимум.
Вот тут делятся сокровенными знаниями, как грузить linux побыстрее.
у меня на desktop'e мамка годичной давности asus с express gate - это linux с X'ами на vesafb - грузиться за 5 sec из SPI (!) флеша + HDD. для скоростей в < 1 sec действительно применяют suspend-to-disk с выбором storag'а с соотвтетсвующей скоростью. на x86 железе, для достижения нужной скорости, это все дело нужно прошивать всесто биоса
QNX на rm9200 из датафлэш (4 мегабайта), дрова усарта, сети, etfs, inetd грузилась секунд 10. загрузчик свой.
QNX на sam9260 из датафлэш (4 мегабайта), дрова на усарт, сеть, usb, sd/mmc, etfs, inetd с монтирование всех носителей - 10 секунд. + u-boot 3 секунды.
winCE6 на sam9260 из nand до проигрывания приветственного wav секунд 30. загрузчик 0 сек =)
linux 2.26 какой-то на sam9260 из датафлэш со всеми дровами (i2c, spi, etc.) секунд 40. + u-boot 3 секунды.
QNX на sam9260 из датафлэш (4 мегабайта), дрова на усарт, сеть, usb, sd/mmc, etfs, inetd с монтирование всех носителей - 10 секунд. + u-boot 3 секунды.
winCE6 на sam9260 из nand до проигрывания приветственного wav секунд 30. загрузчик 0 сек =)
linux 2.26 какой-то на sam9260 из датафлэш со всеми дровами (i2c, spi, etc.) секунд 40. + u-boot 3 секунды.
Цитата(RW9UAO @ Jun 25 2009, 17:58)
QNX на sam9260 из датафлэш (4 мегабайта), дрова на усарт, сеть, usb, sd/mmc, etfs, inetd с монтирование всех носителей - 10 секунд. + u-boot 3 секунды.
....
linux 2.26 какой-то на sam9260 из датафлэш со всеми дровами (i2c, spi, etc.) секунд 40. + u-boot 3 секунды.
....
linux 2.26 какой-то на sam9260 из датафлэш со всеми дровами (i2c, spi, etc.) секунд 40. + u-boot 3 секунды.
linux 2.6.29 с dataflash до строки приветсвия грузится секунд 5 не больше, загрузчик свой - переделанный из atmel bootstrap, можно еще быстрей загрузить - не было такой цели, думаю 3 секунды вполне достижимый результат, у меня в драйвере lcd большие задержки + корнеавя фс на sdhc которая сама по себе требует времени для обнаружения и инициализации. rootfs на initramfs думаю сократит время существенно.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.