| sasamy (Guest) |
|
|---|
|
|
Я тут еще немножко подумал - а зачем собственно вообще тут jffs2 за уши тянуть ? :) От mtd нужен только доступ к char файлу раздела с initrd. Далее покоманде сохранить изменения запускаем скрипт который создает точно такой же рамдиск, создает там фс, рекурсивно копирует директории кроме /dev (если есть mdev), /proc, /sys, /tmp - их просто создет, потом отмонтирует и упаковывает в gzip - у автора это изначально есть :). Потом пишет его в /dev/mtd(initrd) и все.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Отредактированно sasamy 29.01.2009 г. в 04:07:51 |
|
|
|
|
|
|
| repairman (Guest) |
|
|---|
|
|
Хм... такая мысль меня посетила... Почему бы не сделать работу с флеш вообще прозрачной ???
Почему это так просто не получается, потому что процедура записи на флеш ОЧЕНЬ меделнная...
Так человек, который придумывал дерево каталогов posix'а об этом подумал... ВСЕ каталоги линукс могут быть вообще read-only, кроме var.... var потому и var, что variable... Если все дерево грузить с флеш, а в ramdisk засунуть только /var - то сильно места в памяти съэкономится, а записи в флеш в процессе работы машины быть не должно, если только это не изменение системных файлов администратором.... эпизодическое изменение файлов можно напрямую в флеш пропускать... подождет админ 5 секунд... не так это часто нужно... Зато исчезает двоение фс на "прошитую" и "рабочую"...
Еще один вопрос возникает - как хранить логи ? Сейчас они пишутся в ramdisk, который при ребуте рождается заново... А вот админу нужно знать почему девайс пропадал или перегружался без причины... и КАК это сделать ? Сделать логгинг на внешнюю машину ? В моем случае это не реально....
Возможно, какого-то демона завести, чтобы в фоне в флеш сливал очередной фрагмент текста с каким-то интервалом и ротацией (???)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Отредактированно repairman 29.01.2009 г. в 17:46:55 |
|
|
|
|
|
|
| Strijar (Guest) |
|
|---|
|
|
Про JFFS все просто на самом деле - http://en.wikipedia.org/wiki/JFFS
Кратко - ее использвание продлевает жизнь флэшке.
А почему это mtd не позволяет блочные устройства - очень даже позволяет. Просто монтируется и все... |
|
|
|
|
|
|
| starterkit (Guest) |
|
|---|
|
|
Насколько я понимаю, ноги JFFS ростут от DiskOnChip, на которых был впервые применен метод статистического распределения блоков при записи, в свое вермя усиленно пользовались/пользуются ими в промышленых PC-шках PC-104, штука действительно надежная.
Но вот в свете последних "достижений", все мы пользуемся USB флешками, там ведь обычная FAT, кто-нибудь сталкивался диким износом блоков (от чего размер флешки с определеннйо скоростью будет сокращаться в зависимости от интенсивности записи на нее) на USB флешках?
Сам я к JFFS отношусь не очень позитивно, т.к. (правда это было с год назад) в автономном устройстве (когда питание может пропасть в любую минуту) со временем у нее стала "крыша ехать" и она монтировалась при включении десятками минут.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Отредактированно starterkit 29.01.2009 г. в 18:18:50 |
|
|
|
|
|
|
| Strijar (Guest) |
|
|---|
|
|
Вот насчет монтировать mtd
root@OpenWrt:/proc# cat /proc/mtd
dev: size erasesize name
mtd0: 00800000 00010000 "WebRocX NOR Flash"
mtd1: 00050000 00010000 "U-Boot"
mtd2: 00010000 00010000 "U-Boot Env"
mtd3: 007a0000 00010000 "firmware"
mtd4: 006a0000 00010000 "rootfs"
mtd5: 00360000 00010000 "rootfs_data"
root@OpenWrt:/proc# mount
rootfs on / type rootfs (rw)
/dev/root on /rom type squashfs (ro)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /tmp type tmpfs (rw,nosuid,nodev)
tmpfs on /dev type tmpfs (rw)
none on /dev/pts type devpts (rw)
/dev/mtdblock5 on /jffs type jffs2 (rw)
mini_fo:/jffs on / type mini_fo (rw)
none on /proc/bus/usb type usbfs (rw)
Сейчас есть альтернативы JFFS - JFFS2, YAFFS |
|
|
|
|
|
|
| starterkit (Guest) |
|
|---|
|
|
Под JFFS я и имел ввиду вторую версию, YAFFS2 сейчас как раз на своих платах для NAND и использую. |
|
|
|
|
|
|
| repairman (Guest) |
|
|---|
|
|
Отклонились мы от темы....
По теме: С OABI все ок, но НЕ МОГУ собрать рабочий EABI тулчейн... И мои, и собранные crosstool-ng тулчейны собираются без проблем, но производят НЕ РАБОЧИЕ бинарники...
Может кто-то уже собирал ? В чем изюминка ?
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Отредактированно repairman 29.01.2009 г. в 21:29:01 |
|
|
|
|
|
|
| sasamy (Guest) |
|
|---|
|
|
Не знаю в чем изюминка - EABI по моему еще ни у кого не работает до конца :) Я честно говоря не силен в армах - из того что знаю eabi позволяет генерироать исполняемый код вперемешку 32 бит и упакованные tumb 16 бит инструкции. |
|
|
|
|
|
|
| repairman (Guest) |
|
|---|
|
|
Неа... я давно пользовал собственный arm-elf-newlibc тулчейн для arm7tdmi (at91sam7x256) - никаким eabi там не пахнет, а смешанные бинарники arm/thumb собирал чудно... Опция thumb-interwork достаточна.... Правда, нужно знать где thumb можно применять, а где нет...
Кстати, для bootstrap, наверное самое оно... процентов на 30 с thumb размер бинарника можно зажать...
Вроде (???) EABI приводит к общему стандарту системные/библиотечные вызовы, что приводит к совместимости кода, произведенного разными компиляторами...
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Отредактированно repairman 29.01.2009 г. в 21:51:29 |
|
|
|
|
|
|
| sasamy (Guest) |
|
|---|
|
|
вот что дебиановцы говорят вернее цитируют:
"One of the key differences between the traditional GNU/Linux ABI and the EABI is that 64-bit types (like long long) are aligned differently. In the traditional ABI, these types had 4-byte alignment; in the EABI they have 8-byte alignment. As a result, if you use the same structure definitions (in a header file) and include it in code used in both the kernel and in application code, you may find that the structure size and alignment differ."
*
-- from the Codesourcery ARM GNU toolchain FAQ
http://wiki.debian.org/ArmEabiPort
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Отредактированно sasamy 29.01.2009 г. в 21:51:03 |
|
|
|
|
|
|
|
29.01.2009 03:53 
29.01.2009 03:53
