Замутили аналог устройства at91sam9260-sk, кое-чего поменяли, кое-чего оставили. В целом, ожидалась достаточная совместимость с SK, ну, почти.

Есть процессор at91sam9260, есть две sdram как на sk. NAND получилась другая (не ту комплектуху впаяли), как и Dataflash, но он меня не волнует (потому как работает без вопросов, хоть на его 256к только плакать).

Итак, другой NAND -- это 32 мегабайтный Samsung K9F5608U0D (56, как горьким опытом выяснилось, значит 256 мбит). Стоит задача завести на девайсе хоть что-нибудь (перепаивать NAND на тот, на который влезет всё, что нужно, никто не собирается). Т.е. интересует вариант bootstrap -> uboot -> kernel в nand, корень на SD. Не работает самое первое звено -- AT91Bootstrap.

Опытным путём выяснилось, что нужно упомянуть новую флешку в nand_ids.h бутстрапа, что было сделано следующим способом:
static struct SNandInitInfo NandFlash_InitInfo[] = {
// id NbBlocks BlockSize Sector Spare Width Name
{0xec75, 0x800, 0x4000, 0x200, 0x10, 0x0, "Samsung K9F5608U0D 32Mb\0"},
{0,}
}

Числа, вроде как, взяты из соответствующего даташита (ссылки по теме -- http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=158&partnum=K9F5608U0D, http://pdf1.alldatasheet.com/datasheet-pdf/view/129676/SAMSUNG/K9F5608U0D.html). То есть, sector == page = 512 байт = 0x200, spare для каждой страницы -- 16 байт = 0x10, размер блока = 16к = 0x4000, число блоков == 32М/16к = 0x800. Подключение восьмибитное, поэтому width 0. Одна из ссылок была дана, чтобы показать, что микросхема относится к категории small block slc. Сам IDшник взял из другого мануала самсунга и из вывода сам-бы 2.6, в любом случае он находится и корректно определяется.

Хотим грузить бутстрапом u-boot по адресу 0x20000 на NAND. U-boot туда успешно попал через sam-ba 2.10 (причём, на дефолтовых конфигах для ek-платы, что до сих пор смущает -- но читается обратно вполне успешно, следовательно он там действительно записан).

Имеем следующее для at91bootstrap:
-- в режиме NAND_SMALL_BLOCKS бутстрап зависает к чертям с ошибочными чтениями страницы (проверено дебаг-выводами процесса чтения nand);
-- в режиме NAND_LARGE_BLOCKS чтения рапортуются как успешные, но вместо реальных данных приходят 0xFF (отдельный привет dbg_print бутстрапа).

Вопросы:
-- были ли у кого тонкости с поддержкой других NAND-микросхем в самом bootstrap и на уровнях выше?
-- правильно ли я посчитал параметры, которые нужно записать в nand_ids.h? Опыта нет, но по калькуляции всё сходится;
-- работает ли вообще NAND_SMALL_BLOCKS для at91bootstrap? в ченджлогах сам-бы пишут, что этот режим в самой сам-бе поправили только к 2.10; вроде как, и вправду поправили, потому как в 2.6 не работает (даже с хаками tcl), а в 2.10 работает из коробки (причём на апплетах от -ek, хоть у нас и кварц другой), причём "работает" -- значит и пишется, и читается сам-бой;
-- извечный вопрос -- что делать? read only вариант оф. форума атмела вроде как не сильно помог по этому вопросу.

зы. нашёл, что в самом бутстрапе есть ошибка в вычислениях констант nand-флешки -- дважды при подсчёте объёма учитываются spare-байты, но сам неверный результат никуда не попадает. Актуально и для 1.16, но ни на что не влияет.

трабла лежит в постоянно фейлящей проверке страницы на адекватность. закоментил вызов CheckBlock для нанда -- и вот оно заработало. :-)

мне непонятен глубинный смысл функции CheckBlock:
BOOL CheckBlock(PSNandInfo pNandInfo, unsigned int uBlockNb, char *pOutBuffer)
{
unsigned int i = 0;
PSSectorInfo pSectorInfo;
unsigned int uSectorAddr = uBlockNb * pNandInfo->uBlockNbData;

// Read first page and second page spare zone to detect if block is bad
for (i = 0; i < 2; i++)
{
AT91F_NandReadSector(pNandInfo, (uSectorAddr + i * pNandInfo->uDataNbBytes), pOutBuffer, ZONE_INFO);
pSectorInfo = (PSSectorInfo)&pOutBuffer[pNandInfo->uDataNbBytes];
if (pSectorInfo->spare[pNandInfo->uBadBlockInfoOffset] != BAD_BLOCK_TAG)
{
return FALSE;
}
}

return TRUE;
}
Выходит, если для двух страниц 5-ый (для SMALL_BLOCK) байт не равняется 0xFF, значит страница заведомо плохая. Как так? Может, наоборот надо думать было?

ладно, всё логично:
Factory-Default bad blocks

* Samsung marks the 6th OOB byte as non 0xFF in the first and/or second page in blocks that are bad

Судя по всему, 0xFF стёрся после команды scrub nand сам-бы 2.10, которая потребовалась после того, как неподходящая сам-ба пометила бэдами всё подряд. В любом случае, может кому-то это пригодится :-)

вы что в корневуху пихать собрались, что вам 32 мегабайта мало?

предполагается наличие энергонезависимого стораджа ) базы sqlite, в которые собирается инфа от GPS и т.п.

SDшка юзается уже для других целей, поэтому NAND и мучаем.

Вообще, судя по нашим объёмам, придётся ядро и загрузчики в датафлеш писать, а на нанд один большой yaffs2, чтобы проблема бэдов (которые теоретически могут быть много и где угодно) вообще не касалась