какие блочные девайсы обычно создаются для NOR-флешек?

mtd

THANKS

Так для NAND те же самые вроде.

С nand все понятно - это на каждом заборе расписано. а зачем NOR сделали mtd я никак не могу понять.

а зачем NOR сделали mtd я никак не могу понять.

Так устройству пофиг, как ты его в системе то назовёшь, не? Главно major/minor numbers.

на мой взгляд NOR бы более логично смотрелся как блочный девайс чем mtd девайс.

Стоп, так их же два девайса есть: mtd и mtdblock.

хорошо - переформулируем вопрос: зачем нужна mtd прослойка между nor и блочным девайсом?

Интересный вопрос... точного ответа не знаю, но нагуглилось вот это http://www.linux-mtd.infradead.org/faq/general.html
надеюсь, немного прояснит ситуацию. Кстати, какую ФС используешь?

Интересный вопрос... точного ответа не знаю, но нагуглилось вот это http://www.linux-mtd.infradead.org/faq/general.html

мне не стало от этого ясней. я уже изучил почти весь ихний сайт

Кстати, какую ФС используешь?

покачто - никакой

Так давай тогда вернёмся к сути проблемы... Файлы устройств появляются? )

Это не прроблема. сейчас этап дизайна и собственно файлы ожидаются через несколько дней

Это не прроблема. сейчас этап дизайна и собственно файлы ожидаются через несколько дней

Прикольно. Тоже предстоит подобное скоро...

зачем нужна mtd прослойка между nor и блочным девайсом?

ну потому-что NOR совсем не похожа на блочный девайс и на символьный.

У обычных блочных девайсов есть две операции: запись/чтения, а у этих три: ещё стирание. И если у NAND оно реализовано внутри, то у этой — снаружи.

Повторная запись без стирания складывает биты, а не перезаписывает, как обычно.

У обычных блочных девайсов есть две операции: запись/чтения, а у этих три: ещё стирание. И если у NAND оно реализовано внутри, то у этой — снаружи.

Хм, я всегда считал наоборот. Если у нанд стирание внутри то зачем ей тогда MTD? ведь ради нанда собственно мтд и изобрели? или я чтото напутал?

ИМХО дело тут не столько в NOR/NAND, сколько в том, что-бы их подключать напрямую(ну почти напрямую). Для NAND прямое подключение не очень нужно, по самой её структуре (из одного AND столбика можно считать только один бит за раз), потому NAND всё равно должна быть организована особым образом, и читаться тоже по своему. Ну а вот NOR ты можешь читать как угодно, там двухмерная матрица, как в DRAM. Т.е. данные сливаются как в DRAM, читается вся линейка, и пока она сливается, читается следующая. И так сколько надо бит. NAND трёхмерная, и развернуть её в линию не получится(т.к. она ещё и на острова разделена, т.е. в одном острове несколько слоёв, между которыми надо переключаться, что-то вроде дорожек в HDD)

Обычные флешки прячут эту структуру внутри, но они и читаются не последовательно, а блоками, причём рандомно разбросанными. Для NOR такой разброс не нужен, если ты конечно программно не будешь мучить одни и те же острова. Можно писать/читать последовательно, линейка за линейкой.

С nand все понятно - это на каждом заборе расписано. а зачем NOR сделали mtd я никак не могу понять.

Значит не совсем понятно и с NAND, потому что NOR обладает теми же особенностями что и NAND - имеет ограниченное количество циклов стирания/записи и при этом стереть можно только блок целиком, при этом блок имеет относительно большой размер (от 64 кб), так что обычные ФС для блочных устройств нерациональны в плане жизненного цикла устройства. MTD - прослойка для работы специальных ФС.

А может тогда знаешь почему так само поступили с RAM, ROM и EEPROM?

А может тогда знаешь почему так само поступили с RAM, ROM и EEPROM?

Я не понял вопрос :)

почему к RAM, ROM и EEPROM устройствам доступ обычно предоставляют через mtd-драйвер? как минимум первые из этих двух не требуют стирания впринцыпе, а EEPROM какбудто можно стирать вполне разумными кусками.

почему к RAM, ROM и EEPROM устройствам доступ обычно предоставляют через mtd-драйвер?

Первый раз такое слышу. RAM - только специальные случаи типа видеопамять или память недоступная ядру через аллокаторы, второй случай - для эмуляции устройства MTD. ROM - про какую идет речь ? EEPROM - как правило к ним относят флеш память с интерфейсом i2c и очень ограниченным объемом (максимум килобайты), их с MTD я не видел чтобы кто-то использовал. http://lxr.free-electrons.com/source/drivers/misc/eeprom/

RAM - только специальные случаи типа видеопамять или память недоступная ядру через аллокаторы,

ну я собственно о этих специальных случаях и говорю. мне абсолютно непонятно почему в этих случаях выбри MTD как интерфейс.

ROM - про какую идет речь ?

обычная масочная или OTP на внешней шине

непонятно почему в этих случаях выбри MTD как интерфейс

а как ты по-другому сможешь использовать память недоступную ядру ? для rd она недоступна. По поводу эмуляции http://elinux.org/File_Systems#Mounting_JFFS2_image_on_PC_using_mtdram

обычная масочная или OTP на внешней шине

обычная OTP в моем понимании - это конфигурационные биты однократно программируемые, никакого MTD там не используют, по поводу других случаев - в основе этих ROM - NOR, какой-бы интерфейс ни был (spi dataflash или ||)

а как ты по-другому сможешь использовать память недоступную ядру ?

для меня более естественным был бы блочный девайс

По поводу эмуляции http://elinux.org/File_Systems#Mounting_JFFS2_image_on_PC_using_mtdram

Эмуляция мне не интересна

обычная OTP в моем понимании - это конфигурационные биты однократно программируемые, никакого MTD там не используют,

Хорошо, какие ты находил другие способы отдачи ROM в юзерспейс? я находил только mtd

для меня более естественным был бы блочный девайс

то что блочный девайс эмулируется в MTD - что-то меняет ? не можешь ты для этой памяти использовать RD еще раз повторяю - для него память выделяется через аллокатор ядра, в данном случае она для них недоступна

Хорошо, какие ты находил другие способы отдачи ROM в юзерспейс?

для OTP - обычный char device со своим интерфейсом, только я чую ты какой-то херней страдаешь из-за своей упертости.

то что блочный девайс эмулируется в MTD - что-то меняет ?

ты намекаешь на mtdblock?

не можешь ты для этой памяти использовать RD

о RD речь не идет - я его код уже изучил.

только я чую ты какой-то херней страдаешь из-за своей упертости.

я всего лишь пытаюсь понять мотивы выбора реализации в уже написанном коде.

для OTP - обычный char device со своим интерфейсом

можешь ткнуть в любую готовую реализацию?

ты намекаешь на mtdblock?

да, тебя видимо смущает что это все делается в mtd и наверно думаешь что надо писать какой-то специальный драйвер, но это не так, достаточно передать физический адрес памяти по которому отображается твоя RAM (или Flash - неважно) и размер http://lxr.free-electrons.com/source/drivers/mtd/devices/phram.c#L5

и включить в ядре поддержку mtdblock

можешь ткнуть в любую готовую реализацию?

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/char...

только это мало что тебе даст, там OTP - это конфигурационная память очень небольшого размера

да, тебя видимо смущает что это все делается в mtd

да я не понимаю почему именно в mtd. ram ведь не требует цикла стирания ...

наверно думаешь что надо писать какой-то специальный драйвер, но это не так, достаточно передать физический адрес памяти по которому отображается твоя RAM (или Flash - неважно) и размер http://lxr.free-electrons.com/source/drivers/mtd/devices/phram.c#L5

и включить в ядре поддержку mtdblock

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

я уже давно знаю о этих реализациях и изучил их но до сих пор не понимаю почему это реализовали именно через mtd

mtdblock появился до phram, так что не было смысла изобретать велосипед с отдельным драйвером типа brd - просто дописали модуль для готовой инфраструктуры. Собственно такой модуль о котором ты говоришь я могу минут за 15 написать, но зачем если есть готовое решение ? Поттерингам не место в ядре.

mtdblock появился до phram, так что не было смысла изобретать велосипед с отдельным драйвером типа brd - просто дописали модуль для готовой инфраструктуры.

Я обратил внимание что phram куда лаконичней чем brd. Тоесть ты считаешь что причиной такого решения была низкая трудоемкость реализации? А что мы потеряли в лишнем слое абстракции?

Я обратил внимание что phram куда лаконичней чем brd. Тоесть ты считаешь что причиной такого решения была низкая трудоемкость реализации?

Я считаю что ему в mtd самое место :) если тебе нужна простая реализация

http://blog.superpat.com/2010/05/04/a-simple-block-driver-for-linux-kernel-2-...

там Device.data = vmalloc(Device.size); vmalloc замени на ioremap() и через параметры модуля передай физический адрес участка памяти и размер - все, вот тебе простой драйвер как ты хотел :)

вот тебе простой драйвер как ты хотел :)

спасибо, было интересно, но я хотел разобратся в плюсах и минусах этой и предыдущей реализации а не получить готовый драйвер. Я достаточно хорошо разобрал brd чтобы написать такое самому - но мне до сих пор не понятны преимущества и недостатки первой и второй реализации.

впринцыпе я могу прогнать какието бенчмарки для обеих реализаций но я не думаю что это мне чтото прояснит по сути вещей.