Например у меня уже есть большие сомнения по поводу рациональности использования загрузчика u-boot в качестве базового.
Дело в том что u-boot несмотря на все его плюсы не умеет напрямую писать ни с USB ни с LAN непосредственно в NAND, только постадийно через RAM.
На фоне того что оперативная память 64M а NAND 128M или более - это становится проблемой, нужно резать выкладываемую корневую файловую систему на кусочки. Но разрезать на кусочки и загрузить состыковав в теоретически не так сложно, а вот на практике из за особенностей NAND таких как BAD блоки можно запросто получить сдвиг адресации, и нужно вручную контролировать сколько сбойных блоков приходится на записываемый сегмент и делать поправки адреса следующего куска.
В то же время supervivi похоже умеет писать непосредственно в NAND
Добавлено спустя 32 минуты 3 секунды:
второй вопрос - по поводу файловой системы для NAND
для тех кто не в курсе поясню - этот тип флешек (как впрочем и традиционные те что мы используем в USB , и SSD)
имеют особенность в том что для записи нужно сначала стереть блок размером в страницу (у нас это 128kB) а потом записать целиком этот блок.
Из за этого нужно чтобы файловая система понимала эту особенность и не делала запись целого блока при изменении его малой части -буфферировала этот процесс, т.к. количество циклов перезаписи ограниченно и не очень велико.
Я лично имел неосторожность убить серию блоков за неделю путем размещения своп файла линукса на файловой системе не предназначенной для флеша (ext2).
Так вот, о чем это я...
Традиционно в линукс для хранения данных на флешке использовалась файловая система jffs2 а в нашем mini2440 изначально лежало всё на yaffs (про которую я лично в первый раз услышал, кроме того в официальной ветке ядра такой системы нету).
Я занялся поиском информации о сравнении yaffs мы jffs2 и обнаружил следующую страничку
Получается что китайцы ребята весьма продвинуты в этих технологиях и не стоит "мудрить" - думаю есть смысл возвращаться к оригинальным решениям.
Пока не понятно как обстоит дело с ядром.
ядро с диска в комплекте работает прекрасно, но оно "заморожено" по версии, я не нашел обновляемого репозитария этой ветки.
а вот ядро с репозитария repo.or.cz обладает пока рядом недоработок - криво работает tochscreen, совсем не управляется backlight. хотя возможно я не до конца разобрался с конфигурацией ядра.
Но смущает что методы которыми достигаются работоспособность основных уникальных устройств (инициализация борды, видео) весьма различаются.
Нужно решить- искать ли репозитарий ядра от производителей (китайцев) или разбираться с веткой repo.or.cz
Добавлено спустя 13 минут 6 секунд:
ответ на сообщение forum96/topic8361-105.html#171506
И по поводу больших файловых систем и u-boot. Я бы все-таки разделил файловую систему на две части. Первая содержит только самое необходимое (Busybox + ftp server/tftp client) и основную, в которой хранится все остальное. Первая будет объемом несколько метров и спокойно зальется в NAND на свой раздел. Да, естественно придется сделать на NAND один раздел для нее, а второй для (основной) FS. После заливки первого раздела можно загрузить линукс, примонтировать вторую часть. При первой загрузке основную FS придется создать и через FTP/ TFTP можно залить на основной раздел все необходимое. Первый раздел можно сделать ReadOnly. Преимущетсва такого подхода: даже если у вас испортится основной( RW) раздел, то система в любом случае загрузится и опять же через FTP залить туда все что нужно. Второй момент, если это коммерческое изделие, то вам придется делать сервис обновления Firmware. В нашем случае это делается довольно просто: нужно отмонтировать основной раздел, отформатировать его если нужно, и потом залить туда файлы ( хоть через WEB интерфейс). Смысл я думаю понятен, тут конечно может быть множество вариаций как все красиво сделать, но это уже зависит от конкретной задачи
То что вы Предлагаете называется initrd - именно он содержит базовый неизменяемый слепок системы и минимальный набор инструментов для подгрузки основной файловой системы.
Да, это не лишено смысле, тем более что существует механизм упаковки этого образа прямо в ядро системы.
у нас сейчас ядро порядка 2,5 МБ а раздел для ядра 5МБ - можно попробовать