On Sat, 2007-10-20 at 09:22 -0700, Sun Devil wrote:
> 1. Can we write an user level FTL and interface with NANDSim, so that,
> for the application, simulated flash appears to be a physical device,
> and I can format the same volume in what ever way possible?

Yes, I suppose you could. You could access the 'flash' through
the /dev/mtd0 character device, then provide a block device to the
kernel by using something like nbd. It's probably better to do it in the
kernel though.

> 2. Do you have any implementations of FTL at Kernel level?

Yes. We have the simplistic 'mtdblock' which doesn't really do any
translation at all, we have 'FTL' which works only on NOR flash, and we
have 'NFTL' and 'INFTL' for use on DiskOnChip devices. There is a helper
layer which is designed to make it relatively easy for you to provide
your own translation layer, without having to get too deeply involved in
how Linux block device drivers work.

> 3. Are there any NAND Flash simulators that you know of apart from NANDSim?

Well, there's a OneNAND sim too. And it's not that hard to use real NAND
flash either -- see Jörn's new 'Alauda' driver for certain USB devices.

-- 
dwmw2

출처 : http://lists.infradead.org/pipermail/linux-mtd/2007-October/019627.html

hello
    this is my first time to post email to this  list ,if I do not
follow the rules,I am sorry
    recently,I tried the nftl module in MTD,I found it could not work
well, so I debug it , and found one place that I thought it was the
wrong place.

     in the nftlcore.c file ,line 178 to 198 ,the function nftl_write
,as follows:

-- static int nftl_write(struct mtd_info *mtd, loff_t offs, size_t len,
		   --   size_t *retlen, uint8_t *buf, uint8_t *oob)
--{
	--struct mtd_oob_ops ops;
	--int res;

	--ops.mode = MTD_OOB_PLACE;

	--ops.ooboffs = offs;------------------------------------this place
,I thought i should be 0 ,or offs&(mtd->writesize-1), if the value is
offs, it will be over, and cannot work


	--ops.ooblen = mtd->oobsize;
	--ops.oobbuf = oob;
	--ops.datbuf = buf;
	--ops.len = len;

	--res = mtd->write_oob(mtd, offs & ~(mtd->writesize - 1), &ops);
	--*retlen = ops.retlen;
	--return res;
--}

  I debug it on nandsim (I made a little change on nftl to let it work
on nandsim,just change the nftl_add_mtd function, let it can
recongnize nandsim)
  I change ops.ooboffs=offs into ops.oobffs=0, it can work ;


출처 : http://lists.infradead.org/pipermail/linux-mtd/2008-October/023219.html

 anyone could give me an answer whether my change is right?

128 × 8 × 63 x 512byte = 33,030,144byte = 32,256kB = 31.5MB

그러나 이러한 물리적 CHS 수치는 최근의 하드디스크 드라이브에서는 사실상 의미가 없어졌습니다. 기록밀도의 지속적인 증가로 인해서 트랙밀도 및 트랙의 선밀도 등이 급격하게 증가했을뿐더러 하드디스크 내부의 기록방법도 표준 레코딩 기법에서 존드-비트(zoned-bit) 레코딩으로 변경되었기 때문에 CHS 수치가 실제 하드디스크 드라이브의 CHS 수치와는 큰 차이를 보이기 때문입니다.

그렇다면 이제 LBA에 대해서 알아보겠습니다.
LBA는 Logical Block Area 또는 Linear Block Addressing의 약자로 CHS와 같이 하드 디스크의 물리적 구조를 생각하지 않고 각각의 섹터가 일렬로 연결되어 있다고 가정하는 구조입니다. 왜 CHS를 사용하다가 LBA로 넘어오게 되었는가 하면, 기존 CHS 방식을 계속 사용할 경우 사용자는 ATA 방식의 하드디스크를 시스템에 연결하고, 시스템의 바이오스는 CHS 어드레싱을 사용해서 하드디스크에 접근하게 되는데, 이러한 구조 상에서 용량제한 문제가 발생하였기 때문에 이를 회피하기 위한 수단으로 새롭게 고안한 개념이기 때문입니다.

ATA 규격상에서는 실린더를 65,536개까지 지원할 수 있지만 CHS 바이오스는 1024개의 바이오스만을 인식할 수 있었습니다. 그 결과, 사용할 수 있는 실린더의 수는 1024개로 제한되어 버렸고, 마찬가지로 헤드와 섹터에 있어서도 각각 16개와 63개로 제한이 걸리게 되었습니다. 결국 하드디스크가 가질 수 있었던 한계는 실린더 1024개, 헤드 16개, 섹터 63개가 되기 때문에 이를 바탕으로 용량을 계산해보면 528MB가 됩니다.

1024 × 16 × 63 x 512byte = 528,432,304byte

1024 × 256 × 63 × 512byte = 8,455,716,864byte

이러한 장벽을 넘기 위해서 만들어진 것이 LBA 인터페이스입니다. LBA 인터페이스가 적용되면 바이오스는 기존의 CHS 방식 대신 LBA 방식을 사용해서 하드디스크 드라이브에 접근합니다. LBA는 그 이름 그대로, 물리적, 혹은 논리적(변수전환된) CHS 수치를 무시하고 하드디스크 전체를 하나의 영역으로 보면서 이 안에서 일련의 주소를 가지는 블록을 만듭니다. 그리고 이러한 블록의 주소를 지정하기 위한 정보로써 28bit를 사용합니다.
 

그 결과, 본래 바이오스가 가지고 있는 CHS 한계와는 상관없이 ATA 규격이 가지는 한계까지를 모두 사용할 수 있게 되었습니다. 28bit가 사용된 것은 ATA 규격에서 정의하고 있는 CHS 수치에 28bit의 정보가 사용되기 때문입니다. 그리고 섹터의 수는 0이 아닌 1부터 시작되기 때문에 256개가 아닌 255개가 되며, 이와 호환성을 유지하기 위해서 LBA 방식의 어드레싱에서 사용할 수 있는 주소의 총 개수는 다음과 같이 정해집니다.

216 × 24 × (28 - 1) = 220 × (28 - 1) = 267,386,880

CHS_LBA.xls

*프로그램 출처 : http://www.boot-land.net/forums/?showtopic=2959