Организация FreeBSD Foundation объявила (http://freebsdfoundation.blogspot.com/2012/03/new-project-na...) о выделении компании Semihalf (http://www.semihalf.com/) денежного гранта на выполнение работы по интеграции в состав FreeBSD созданных данной фирмой файловой системы и стека хранения данных для накопителей NAND Flash. Указанные технологии будут открыты под лицензией BSD и позволят обеспечить во FreeBSD прямое управление устройствами NAND Flash, удовлетворив ключевые потребности многих приложений в быстром, надёжном и энергонезависимом хранилище. Ожидается, что интеграция стека с поддержкой NAND Flash откроет новые возможности по применению FreeBSD в области встраиваемых устройств.
В состав передаваемой проекту FreeBSD подсистемы NAND Flash входят следующие компоненты:
- Фреймворк для создания драйверов и набор драйверов для контроллеров NAND и чипов памяти;
- Cимулятор NAND-устройств;
- Устойчивая к сбоям файловая система, основанная на механизме п...URL: http://freebsdfoundation.blogspot.com/2012/03/new-project-na...
Новость: https://www.opennet.ru/opennews/art.shtml?num=33248
Это пример что *НЕ ОСНОВНЫЕ* проекты можно выгодно передавать в OpenSource и под BSD. Только мало компаний действительно серьезно развивают не ключевые технологии.Получается, что BSD это лицензия для того, что напрямую денег компании не приносит.
Вопрос под какой лицензией и как открывать *ОСНОВНЫЕ* проекты компании?
<irony>
EULA?
</irony>
А вообще Juniper молодцы, вместо того чтоб каждый раз вкладывать деньги в развитие поддержки NAND в заточенном под себя дистрибутиве, просто передали исходники и обеспечили себе экономию средств в дальнейшем.
>А вообще Juniper молодцы, вместо того чтоб каждый раз вкладывать деньги в развитие поддержки NAND в заточенном под себя дистрибутивеДа - молодцы, только нужность голой nand в embedded начинает стремиться к нулю, их используют в основном на микроконтроллерах где и Linux не нужен, не то что какие-то xBSD. Сейчас активно начинают использовать e-MMC - с ним не нужно заботиться о геометрии чипов, следить за износом блоков - этим контроллер занимается и ставить там можно любую ФС для блочных устройств. При этом потребление не сильно выше голых nand (они автоматически в low power переходят и переинициализация не требуется), скорость чтения/записи высокая и объемы с SSD сравнимые. Например у SunDisk:
http://sandisk.com/business-solutions/inand-embedded-flash-d...
> Да - молодцы, только нужность голой nand в embedded начинает стремиться к
> нулю, их используют в основном на микроконтроллерах где и Linux не
> нужен, не то что какие-то xBSD.Не скажите, всякие omap и подобные по смыслу грузятся в том числе и с NAND. А микроконтроллеры обычно содержат внутри себя и некоторое количество флеша. Нанд для мелких применений неудобен многолапостью, там SPI-флехи рулят или SD карты (в режиме SPI опять же, например).
>Не скажите, всякие omap и подобные по смыслу грузятся в том числе и с NAND.Единственный смысл этого - историческое наследие и то что стОит nand в индустриальном исполнении как грязь.
>А микроконтроллеры обычно содержат внутри себя и некоторое количество флеша.
И многие могут сами себя перепрограммировать ?
>там SPI-флехи рулят или SD карты (в режиме SPI опять же, например).
spi флеши сильно ограничены в объеме а sd/mmc не все могут в spi работать да и в индустриальном исполнении цена в разы вырастает.
> Единственный смысл этого - историческое наследиеЧто значит - историческое наследие? Почти все современные мобильники и все похожие по калибру системы с NAND грузятся. Выпускаемые вот прям ща. Ну удобно иногда прицепить нанд в лобовую на контроллер нанда мелкого проца и бутявиться прямо вот оттуда. Загрузку именно с e-mmc умеет намного меньше процессоров чем с нанда кстати. Просто потому что первое проще реализуемо на уровне жесткой логики и как максимум минималистского накристального ROM. eMMC там обычно как стораж под жирные данные юзера, а загрузка системы - таки с отдельного NAND чаще всего, хотя некоторые процы вроде уже обучили и с eMMC грузиться.
Другое дело что технологии эволюционируют и тот же jffs уже пришлось разок переделать, когда с прихолдом MLC старые полухакерские трюки использующие механику флеша на свое благо не то чтобы перестали работать совсем но стали работать по другой логике, что связано с тем что в 1 ячейке теперь хранится не 1 бит а несколько и старая логика поштучного спуска битов без стирания работать перестала, по поводу чего им пришлось перейти от инвалидирования блоков путем поштучного спуска битов (этот трюк позволяет множественную запись без стирания) к инвалидированию по принципу "валидный тот блок у кого максимальный счетчик" (в таком виде не приходится делать допущение о возможности писать несколько раз без стирания путем постепенного спуска битов, что для MLC работать перестало).
Что-то мне подсказывает что если до бсдунов в 2012 году дошло что оказывается, в природе есть флеш (при том что интел его придумал в конце 70-х прошлого века), пока они это внедрят - в природе начнет царить уже что-то типа MRAM не страдающее проблемами флеша типа очень жесткого лимита на число циклов (буквально единицы тысяч перезаписей для высокоплотного MLC).
> и то что стОит nand в индустриальном исполнении как грязь.
С него чисто технически грузиться проще - реализуемо даже жесткой логикой или примитивным boot ROM. А сложные там как-то и некуда особо засунуть, и вообще чем сложнее - тем больше шансов что партия процов с конвеера пойдет под пресс из-за тупого бага в этой логике, чего никому разумеется не надо.
>>А микроконтроллеры обычно содержат внутри себя и некоторое количество флеша.
> И многие могут сами себя перепрограммировать ?Из современных - практически все. Более того - обычно можно зашить девайс с нуля самим собой по принципу Мюнхаузена и вытаскивания за волосы из болота. Обычно или в boot ROM вшит нестираемый boot loader обеспечивающий начальное программирование, или есть простой аппаратный интерфейс по которому оно шьется.
Ну вот так навскидку, из относительно мелких:
STM32: начальная зашивка: есть boot loader и JTAG (через который проц тоже можно потенциально проинструктировать сделать что-то, даже когда софта в нем еще нет). Умеет шить флеш на ходу из выполняющейся программы.
AVR: начальная зашивка: простой SPI-образный аппаратный интерфейс описанный в даташите. У старших камней также есть JTAG, через который проц можно проинструктировать что-либо делать. Умеет шить флеш из выполняемой программы.
MSP430: начальная зашивка: встроен boot loader + опять же есть JTAG. Умеет шить себя сам...За остальных пусть кто-то другой скажет. Кстати JTAG довольно универсальная штука, через него стандартно de-brick'ают системы где boot loader был в флехе, проц не снабжен своим ROM или ROM непригоден в текущей конфигурации системы или неизвестно как его активировать. Так оживляют и более крупные системы типа роутеров, точек доступа и некоторых мобил (почему-то наиболее критичные блоки типа boot loaders будучи записанными в врайтабельный носитель имеют обыкновение слетать, а будучи в ридонли - демонстрировать фатальные баги делающие их бесполезными в критичной ситуации - такая дилемма... :D).
>>там SPI-флехи рулят или SD карты (в режиме SPI опять же, например).
> spi флеши сильно ограничены в объеме а sd/mmc не все могут в
> spi работать да и в индустриальном исполнении цена в разы вырастает.SD все могут - у них это стандарт требует, как mandatory. Если кто не может, он грубо нарушает стандарт и идет лесом как несовместимое нечто. MMC - да, там это было optional... но MMC проиграл войну стандартов и на данный момент остался только SD. Поэтому who cares? Более того - eMMC то же самое, только зачем-то в довольно странном исполнении. И кстати я бы так уж восторженно не относился к этой технологии. Оно подразумевает многочиповую сборку, с своим умным контроллером с своей собственной фирмварой с своими багами, возможностями ее слета и прочих внезапных факапов. Вплоть до того что кус фирмвары может храниться в основном массиве флеша и если тот потек - вся *mmc становится очень непредсказуемой. С другой стороны отказы NAND можно достаточно вменяемо обрабатывать - если ECC не сошелся и удалось починить - упс, блок начинает течь, спасти данные и ремапнуть. Если совсем uncorrectable - не повезло. Заремамить если не фатально и кинуть еррор диска. А если у emmc внезапно и быстро откинет коньки контроллер и как ему перелить внутреннюю фирмвару никто не знает - во радости сразу приваливает... тут даже спецы по data recovery могут обломаться потом данные из такой сборки вынуть. В отличие от простого нанда.
>Просто потому что первое проще реализуемо на уровне жесткой логики и как максимум минималистского накристального ROM.Не надо мне мозг пудрить :) Чего тут проще - как предполагается такой жесткой логике знать - какая блин у nand вашей запаяной геометрия чипа и технология, или что завтра выпустят nand по технологии о которой загрузчик не знает ? а за bbt дядя вася будет следить ? или предпочитаете при первом bad block в загрузочной области перепаивать nand :) это прям дискеты и MS-DOS напомнило.. у каждого производителя есть списки - это я могу а это не могу, нет таких которые поддерживали бы все технологии NAND - slc/mlc с различной геометрией, так что nand для загрузки вообще _очень плохо_ подходит, недаром на PC BIOS хранят в параллельной NOR или SPI flash.
> Не надо мне мозг пудрить :)Да никто вроде и не пытается. Я так, немного капитаню, сугубо глядя на ВЫПУСКАЕМЫЕ СЕЙЧАС реализации железок и даташиты разных проциков, не более.
> Чего тут проще - как предполагается такой жесткой логике знать - какая блин
> у nand вашей запаяной геометрия чипа и технология,Да, по этому поводу есть некая попаболь, факт. И поэтому часто делают boot ROM в котором логика не столь деревянная, однако с более нового типа оно вполне может обломаться грузиться, факт. Вот только в случае с eMMC вообще надо аж чтение FAT32 делать. И там ограничений на формат карты, ФС на ней и прочая обычно два вагона. Получается крайне дебильное уродство. Эти штуки заточены на откровенный накопитель с данными который на ходу демонтируется и вывешивается большому писюку как FAT32 диск. Вот только грузить пингвин с такой штуки - еще тот изврат.
> или что завтра выпустят nand по технологии о которой загрузчик не знает ?
С таким же успехом загрузчик не знающий о emmc с него обломается загрузиться. Более того, даже те которые знают - накладывают зиллион ограничений на то как все это должно быть скроено. Если честно, грузить пингвин с FAT32 носителя - изврат полный. А eMMC заточен как раз на то чтобы легко монтироваться к большому брату, чем он и удобен: отцепил от встроенного линя и отдал писюку весь диск со всеми потрохами как просто FAT32 карту. Но вот идея бутявить оттуда линукс со всеми этими начинаниями довольно сильно клещится и возникает куча технических трудностей. В принципе конечно преодолимых, но фанатеть от столь уродливых франкенштейнов - как-то странно.
> а за bbt дядя вася будет следить ?
Boot ROM или аппаратная логика опять же - не так уж и сложно оно. Могут быть некие ограничения, например у Ti OMAP - надо чтобы хотя-бы 1 из первых 4 блоков был исправен (делается попытка читать 4 блока, если все 4 плохие, ROM забивает на дальшейшие потуги).
> или предпочитаете при первом bad block в загрузочной
> области перепаивать nand :)У OMAP например допускается до 4 битых блоков в начале, они будту заскипаны. Хотя вообще-то флеш всегда был ERROR-FREE памятью, а вылезание 1 бэда было признаком скорого умирания памяти. А то что с недавних пор коммерсы в погоне за красивыми цифрами гигабайтов сильно желают продавать даже полубрак, у которого прям с фабрики бэды - ну оно конечно предсказуемо, но это прозрачно намекает что срок службы и надежность этого откровенно "флопповодные". Т.е. вылезание бэдов прям в процессе работы считается нормальным, даже круче чем на дискетах. Странно испытывать восторг по этому поводу. Ну разве что если вам наплевать на ваши данные ;).
> это прям дискеты и MS-DOS напомнило..
Да, вы правы. Сыпучие чипы NAND-MLC которые после пары тыщ циклов дохнут нафиг, прям с фабрики идут с кучей бэдов, могут прямо при работе словить новые - по надежности примерно как флопики, да. И что самое веселое, в eMMC используются те же самые чипы. И вся разница - в том что все это отработает встроенный контроллер. Насколько он лучше это отработает - вопрос интересный. Ну налетел допустим контроллер eMMC на нечитаемый (ECC uncorrectable) сектор флехи. Вы знаете что он и его фирмвара по этому поводу сделает? Если так из основного проца нарваться - вы по крайней мере узнаете что сектор сдох. А вот eMMC в меру дурости может вернуть полураздестроенные данные например, ремапнув на резервный сектор втихаря. Насколько там прямо или криво фирмвара этого контроллера сделана - да кто ж ее знает? Более того - если оно такое умрет, данные с такой хрени врядли смогут снять даже спецы по дата рекавери. Если нанд можно выпаять и прочесть то вот если у такой штуки отлетит в мир иной что-то касающееся ее контроллера, выцепить данные из eMMC будет крайне проблематично. Хотя с учетом отношения как к расходнику - кого волнует чужое горе... ;]
> у каждого производителя есть списки - это я могу а это не могу,
Более того, у каждого производителя есть указание как единственно правильным образом грузиться с eMMC и подобных носителей. И к тому же оно у всех по разному. Там тоже тот еще прыг на костылях с кучей ограничений и подпорок.
> нет таких которые поддерживали бы все технологии NAND -
> slc/mlc с различной геометрией, так что nand для загрузки вообще _очень
> плохо_ подходит,В основном он плохо подходит потому что не умеет напрямую выполнять код и допускает бэд-сектора. Но производители современных SoC более-менее преодолели подобные грабли путем внедрежа накристальных boot ROM или довольно продвинутых контроллеров внешней шины с аппаратными подпорками для всех типов нанда которые есть на момент дезигна проца.
> недаром на PC BIOS хранят в параллельной NOR или SPI flash.
В параллельной уже никто не хранит ничего - закончилась их эра. Потому что здоровые, многолапые, а за современными CPU всяко не поспевают по шине и приходится как-то миррорить или виртуализовывать доступ железячными приблудами.
А вот в SPI-NOR да, часто. Правда оно тоже процам для загрузки не на 100% удобно т.к. выполнение напрямую из флехи не поддерживается в отличие от параллельных флех, но зато мелкий чип (==дешевле и меньше места занимает) а реализовать логику которая позволит грузиться с этого - не слишком сложно (NOR не предполагает дефектных секторов и прочих грабель и приятнее NAND в этом отношении). Ну так и плотность у этих чипов - ну максимум мегов 16 они бывают (из того что я видел). Сравните с гигабайтами нанда, да? :)
> Вот только в случае с eMMC вообще надо аж чтение FAT32 делать.Не обязательно:
http://ru.wikipedia.org/wiki/MBRхотя на практике чаще с fat грузят - это намного удобней да и только для чтения кода в ROM - кот наплакаль
> И там ограничений на формат карты, ФС на ней и прочая обычно два вагона ...
> Вот только грузить пингвин с такой штуки - еще тот изврат.Первый раздел с fat - вот и все ограничение и грузят загрузчик а не ОС напрямую - внешняя память еще не проинициализирована а SRAM чтобы ядро напрямую загрузить надо столько что это нереально дорого будет.
> С таким же успехом загрузчик не знающий о emmc с него обломается загрузиться.
Давным давно уже все знают, правда стандарт новый вышел - не знаю как у них с совместимостью.
> В параллельной уже никто не хранит ничего - закончилась их эра.
Хз - помоему XIP рулит и вряд ли кто откажется от такой возможности в embedded где нет BIOS и нужно предварительно инициализировать память.
Для любого производителя железа софт не основное направление.
Примеров море: iXsystems (PC-BSD), HP (webOS), SGI (XFS), Intel (Tizen/MeeGo)
Facepalm.jpgЭто HP - "производитель железа"? Или, может быть, Intel? Для вас мир делится на "производителей железа" и "производителей софта"?
А самый главный производитель Железа -- Майкрософт же!! Всемирно известные мышки -- такие самому Ксероксу не снились.
> Facepalm.jpg
> Это HP - "производитель железа"? Или, может быть, Intel? Для вас мир
> делится на "производителей железа" и "производителей софта"?Удивлю - у HP есть стопка решений - когда железо разработано строго под них.
пример HP SFS серия.
Работаю в HP, со мной в баскетбол играл китаец, который разрабатывает новые типы памяти. В производство они их не запускают, но это позволяет им закупать память ниже себестоимости. Да и в HP labs не бездари сидят это уж точно.
>Работаю в HP, со мной в баскетбол играл китаец, который разрабатывает новые типы памяти.вы можете играть хоть с пигмеями-баскетболистами но основные игроки - toshiba/sundisk intel/micron.
>>Работаю в HP, со мной в баскетбол играл китаец, который разрабатывает новые типы памяти.
> вы можете играть хоть с пигмеями-баскетболистами но основные игроки - toshiba/sundisk intel/micron.Они не откажутся от золотой дойной коровы NAND в пользу M-RAM.
> Они не откажутся от золотой дойной коровы NAND в пользу M-RAM.Чего бы ради? Они очень грамотно ща все сделают. Сперва вы у них накупите SSD которые дохнут как мухи, а когда они начнут вымирать - как раз новый, крутой и вроде как не умирающий MRAM подоспеет как избавление от геморроя с вычислением циклов записи. И вот вы уже идете покупать новые нокопители. По перегретой за новизну технологии цене. Или меняете пачками SSD в кешах и где там еще по мере протирания, зато типа дешевле т.к. отработанная максимально удешевленная технология, лол :]
<кто здесь всё удаляет?>Продублирую свою мысль.
Как же так, ведь Столлман говорит, что проприерасты только берут и нужно сделать
так, чтобы они были вынуждены отдавать. Так появилась GPL, которая "поощряет" (палкой) отдачу.И тут, как чёртик из табакерки, вдруг появилось исключение из правила FSF: оказывается
проприерасты могут _просто_так_ отдать целый фреймворк — матрицу решений для
будущего наполнения её "мясом" проприетарного (закрытого) кода. И эти решения купят те,
кому действительно необходимо определённое "мясо" в обмен на "сотни нефти", и
одновременно с этим будут использовать свободный фреймворк, исключающий насилие и
принуждение к чему-либо. Обязательства минимальны: делай с этим что хочешь, но не называй
чужое своим и всё. Потрясающе!
> Продублирую свою мысль.
> И тут, как чёртик из табакерки, вдруг появилось исключение из правила FSF:
> оказывается
> проприерасты могут _просто_так_ отдать целый фреймворк — матрицу решений дляДублируйте подробнее: о чём это Вы??
Хорошая новость, молодцы, что сумели договориться.
>Semihalf"Полуполовина"? Хорошенькое название
>>Semihalf
> "Полуполовина"?Недополовина :)
II [ˈsemɪ]
сущ.; разг.; сокр. от semi-erection
неполная эрекцияSemihalf - ну, видимо, еще более неполная.
Спасибо ABBYY, не выпускающему словари под *nix и StarDict, не обламывающемуся их использовать ;)
лучше бы bhyvee делали. а то совсем заброшен походу
> лучше бы bhyvee делали. а то совсем заброшен походуШутите? К ближайшему bsdcan-у обещают стабильную версию. Отдельные части, такие как pv-драйвера, уже в current
вы думаете? очень на это надеюсь.
просто в svn'е уже 3-4 месяца не было значимых коммитов
>Шутите? К ближайшему bsdcan-у обещают стабильную версию. Отдельные части, такие как pv-драйвера, уже в currentСтранно. Я тоже давно в их репе комитов не видел. Можно подробнее?
http://svnweb.freebsd.org/base?view=revision&revision=227652
http://lists.freebsd.org/pipermail/freebsd-virtualization/20...
Спасибо большое!
Если с неё ещё и грузиться можно будет - так это ващще будет щястье!