[Itch 0]

Во многих встраиваемых устройствах требуется максимально быстро прийти к рабочему состоянию после подачи питания или перезагрузки. Обычный линукс грузится довольно таки медленно, пока он прогрузит все драйвера, проходит секунд 10-20, если не больше. Можно ли сделать так, чтобы образ работающего (полностью загруженного) линукса со всеми драйверами сохранить во флеш-памяти и при старте системы просто копировать этот образ в оперативную память? Т.е. сделать аналог Hibernate в Windows.

Хотелось бы добиться времени старта в 1-2сек максимум.

Если да, то кто будет инициализировать железо в таком случае (видео, сеть, UART...), в компе это делает частично BIOS, частично сама Windows? Использовать планирую ucLinux, но, по идее, особой разницы быть не должно.

[AlexandrY 2]

А че у вас драйвера так тормозят? По моему этот вопрос надо решать.

Боюсь у вас тормозят не драйвера, а как раз те файловые операции на которые вы хотите возложить сохранение снимка системы на диск.

Т.е. сохранение на диск образа из такой средненькой RAM в 64 Мб как раз выльется в 20 сек. Ну и восстановление в 15 сек.

 

Во многих встраиваемых устройствах требуется максимально быстро прийти к рабочему состоянию после подачи питания или перезагрузки. Обычный линукс грузится довольно таки медленно, пока он прогрузит все драйвера, проходит секунд 10-20, если не больше. Можно ли сделать так, чтобы образ работающего (полностью загруженного) линукса со всеми драйверами сохранить во флеш-памяти и при старте системы просто копировать этот образ в оперативную память? Т.е. сделать аналог Hibernate в Windows.

Хотелось бы добиться времени старта в 1-2сек максимум.

Если да, то кто будет инициализировать железо в таком случае (видео, сеть, UART...), в компе это делает частично BIOS, частично сама Windows? Использовать планирую ucLinux, но, по идее, особой разницы быть не должно.

[Itch 0]

Использовал демобоард на RM9200 от Черкашина, линукс качал с его же сайта. Я не спец в этом, да и давно это было, но там похоже что распаковывалось все из сжатого образа. Время загрузки было действительно большое, причем сама распаковка - секунд 5, потом потихоньку запускался линукс, выводя в консоль строки.

 

Если даже прикинуть, пусть образ будет хранится в отдельной последовательной флешке (SD карта). Скорость чтения с нее пусть 10МВ/sec. За 1 секунду 8MB образ можно закачать в SDRAM. Либо вообще, хранить линукс в NAND флешке, с него же пусть и работает. Тогда даже копировать ничего не надо. Вопрос в том, можно ли такое проделать с линуксом?

 

Кстати, есть автонавигатор. Там стоит 64М NAND флеши и 64М SDRAM. ОС - WinCE 5.0, полность грузится за 11 сек, картинка на экране рисуется через 3 сек. Из спящего режима вообще моментально выходит.

[AlexandrY 2]

Скорость чтения из 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 сек. Стоит подумать ;)

 

Использовал демобоард на RM9200 от Черкашина, линукс качал с его же сайта. Я не спец в этом, да и давно это было, но там похоже что распаковывалось все из сжатого образа. Время загрузки было действительно большое, причем сама распаковка - секунд 5, потом потихоньку запускался линукс, выводя в консоль строки.

 

Если даже прикинуть, пусть образ будет хранится в отдельной последовательной флешке (SD карта). Скорость чтения с нее пусть 10МВ/sec. За 1 секунду 8MB образ можно закачать в SDRAM. Либо вообще, хранить линукс в NAND флешке, с него же пусть и работает. Тогда даже копировать ничего не надо. Вопрос в том, можно ли такое проделать с линуксом?

 

Кстати, есть автонавигатор. Там стоит 64М NAND флеши и 64М SDRAM. ОС - WinCE 5.0, полность грузится за 11 сек, картинка на экране рисуется через 3 сек. Из спящего режима вообще моментально выходит.

[Itch 0]

Поwikiл слово XIP, нашел интересную pdf-ку. Оказывается, даже без XIP есть большой простор для оптимизации.

 

В навигаторе стоит Sirf Atlas III, он на основе самсунговского ARMа. В даташите, емнип, было сказано, что работа с NAND обеспечивается прозрачная, т.е. как c NOR.

[sasamy 11]

Скорость чтения из SD вы сильно преувеличили если конечно не подразумеваете самые свежие навороченные чипсеты с повышеной частотой SD контроллера.

Вообщем будет у вас в случае FAT не больше 4 МВ/sec.

все

Оптимисты вы тут ;) сомневаюсь что на RM9200 вы получите больше 1 мб/сек, а на небуферизованном посекторном чтении и того меньше - 100-150 кб/сек. Кстати - а зачем загрузчику вообще какая-то фс ?

 

Но самая досадная фигня в Линуксе это файловая система.

Тут есть дилема.

Либо вы делаете файловую систему быструю и в RAM, но тогда надо ее туда долго грузить из NAND или SD и получаете ее не персистентную, либо сразу запускаете драйвер какой либо файловой системы на Flash и стартуете файловую систему достаточно быстро, но потом имеете низкоскоростной доступ.

 

О - опять про фс :) фс в рам требуется только для устаревшего initrd, в образе initramfs никакой настоящей фс нет- там аналог tmpfs и работает действительно быстро.

 

Поскольку в Линуксе ничего без файловых операций не обходится, то скорость файловой системы на старте имеет большое значение. При объеме ядра где-то в 3 мега, файловая система будет минимум занимать 8 мег со всякими либами, busybox-ами и приложением.

 

Для старта ядра вообще фс не нужна, она нужна для корня и запуска Init, опять же с initramfs вообще никаких тормозов нет, можно хранить там все необходимые для старта а все остальное просто подмонтировать.

 

Кстати старт картинки на QNX- 0.5 сек. Стоит подумать ;)

 

я подумал - а чего так медленно ? :)

 

имхо болше всего времни при старте уходит на распаковку и на поиск-инициализацию устройств а кто будет их инициализировать при быстром старте ?

[AlexandrY 2]

Какая точно марка чипа?

Что, так и написано: "прозрачная, как с NOR"?

Сильно сомневаюсь.

Обычная практика это когда встроенный в ROM чипа первичный монитор читает во внутреннюю RAM чипа первую страницу первого блока NAND.

Там сидит уже вторичный короткий загрузчик написанный юзером

ROM монитор отдает управлением во внутренней RAM ему

Тот в свою очередь грузит из NAND третичный полнофункциональный загрузчик (типа UBoot) уже во внешнюю RAM.

И тот уже из NAND-а во внешнюю RAM грузит либо Линукс либо опять Линукс с его собственным распаковщиком.

Причем он может Линукс грузить по тому же адресу где сидит UBoot, ну тогда еще будет этап перемещения UBoot в другое место внешней RAM.

 

Вот это вот и величают "прозрачной" работой.

Т.е. тормоза еще те.

 

 

А pdf-ка найденая вами может сильно ввести в заблуждение.

Вообще нужно очень осторожно верить всем утверждениям которые идут от пользователей Линукса на PC.

Инициализация в Линуксе для каждой архитектуры во многом реализуется уникально в отдельной директории ARCH, поэтому причины задержек тоже во многом уникальны.

 

Поwikiл слово XIP, нашел интересную pdf-ку. Оказывается, даже без XIP есть большой простор для оптимизации.

 

В навигаторе стоит Sirf Atlas III, он на основе самсунговского ARMа. В даташите, емнип, было сказано, что работа с NAND обеспечивается прозрачная, т.е. как c NOR.

[Itch 0]

все

Оптимисты вы тут ;) сомневаюсь что на RM9200 вы получите больше 1 мб/сек, а на небуферизованном посекторном чтении и того меньше - 100-150 кб/сек. Кстати - а зачем загрузчику вообще какая-то фс ?

По идее, нафиг не не надо FS. Есть 8М RAM, в котором лежит запущенная ОСь. Просто сохраняем в отдельную флеш 8М и все. Когда надо стартануть просто копируем обратно в память. AT45DB642D емкостью в 8МБайт поддерживает скорость по SPI до 66МГц, т.е. ~8М/сек. Для Blackfin, на котором я собираюсь делать плату, это точно не проблема.

имхо болше всего времни при старте уходит на распаковку и на поиск-инициализацию устройств а кто будет их инициализировать при быстром старте ?

Вот и интересно. Должен быть системный вызов для переинициализации драйверов устройств. Опять же, времени на то, чтобы записать несколько регистров много не надо. Если конфигурация платы известна, ничего никогда не меняется, то никаких особых Plug'n'Play не нужно.

[AlexandrY 2]

Вы еще не поняли с чем связались ;)

 

На нормальной RTOS старт всей системы со всеми драйверами длиться не более 0.1 (cм. uCOS) сек и без всякого сохранения RAM на диск.

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

uCLinux в этой ситуации никаких преимуществ по сравнению с той же uCOS не даст.

 

А развод с uCLinux на BF меня всегда прикалывал. Там инициализировать по сути нечего, самая бедная архитектура в плане периферии, а 600 МГц платформа грузиться добрые полминуты.

А на демонстрациях этот uCLinux представляют как невероятно крутую фичу BF.

 

 

По идее, нафиг не не надо FS. Есть 8М RAM, в котором лежит запущенная ОСь. Просто сохраняем в отдельную флеш 8М и все. Когда надо стартануть просто копируем обратно в память. AT45DB642D емкостью в 8МБайт поддерживает скорость по SPI до 66МГц, т.е. ~8М/сек. Для Blackfin, на котором я собираюсь делать плату, это точно не проблема.

 

Вот и интересно. Должен быть системный вызов для переинициализации драйверов устройств. Опять же, времени на то, чтобы записать несколько регистров много не надо. Если конфигурация платы известна, ничего никогда не меняется, то никаких особых Plug'n'Play не нужно.

[sasamy 11]

Для Blackfin, на котором я собираюсь делать плату, это точно не проблема.

 

не вопрос - можно получить хорошие скорости, я просто конкретно про rm9200 ситуацию уточнил

 

Должен быть системный вызов для переинициализации драйверов устройств.

 

Видели наверно в конце загрузки ядра сообщение типа Freeing unused kernel memory: Nk freed так вот это ядро избавляется от того самого кода и данных инициализации который вы хотите вызвать повторно :) Он помечен __init в драйверах, после загрузки ядра его нет больше в памяти.

[AlexandrY 2]

Весь Analog Devices не смог решить проблему, а для вас нивапрос?

не вопрос - можно получить хорошие скорости, я просто конкретно про rm9200 ситуацию уточнил

 

В конфигурации XIP ничего не удаляется. Смотрите файл линкера *.lds

Видели наверно в конце загрузки ядра сообщение типа Freeing unused kernel memory: Nk freed так вот это ядро избавляется от того самого кода и данных инициализации который вы хотите вызвать повторно :) Он помечен __init в драйверах, после загрузки ядра его нет больше в памяти.

[Itch 0]

Какая точно марка чипа?

Что, так и написано: "прозрачная, как с 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

И еще:

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.

Т.е. только 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.

[AlexandrY 2]

Эт к щастью на этой конфе знают все.

Новость в том что у них 4K вместо 2-х, но UBoot все равно не влезет и моя 3-х...4-х ступенчатая схема для вас остается в силе.

 

Поэтому если хотите действительно быстро без NOR-ы не обойтись.

 

Т.е. только bootloader, но зато NOR'ы уже не надо.

 

 

Эт как разработчик вы тоже должны были бы знать, что во всех NAND гарантируют что первый блок всегда работоспособен.

P.S. Прикольная заметка в конце:

[Itch 0]

Эт как разработчик вы тоже должны были бы знать, что во всех NAND гарантируют что первый блок всегда работоспособен.

Кажется, всегда работоспособен в начале своей жизни. Но когда-то он также может умереть, как и любой другой блок. Хотя тут конечно вероятность много ниже, ибо бутсектор редко кто пишет больше нескольких раз.

[sasamy 11]

Весь Analog Devices не смог решить проблему, а для вас нивапрос?

 

 

В конфигурации XIP ничего не удаляется. Смотрите файл линкера *.lds

 

проблемы Analog Devices - это проблемы Analog Devices, речь шла о том что на rm9200 читать sd быстро не получится но вообще быстрое чтение с внешнего носителя - не вопрос.

При чем тут вообще xip - не путайте теплое с мягким, речь шла об аналоге hibernate в windows, он кстати вполне себе живет в linux на х86 - suspend to disk называется, используя acpi, так вот проблема в том что после восстановления образа ram с нешнего носителя нужно заново инициализировать периферию так как питание было полностью отключено, но в ram кода инициализации уже нет, так как ядро при загрузке освободилось от него.