re-formatting a Disk-on-Chip without going to DOS

[Christopher E Piggott]

David Woodhouse wrote:

>Hack drivers/mtd/nand/diskonchip.c to register the raw device even if it doesn't
>find the Media Header.

Cool, that part worked.

>Then write the original table back using nandwrite.

That part claimed to work, but what I read back from it didn't match what I wrote
>From the file.  I'm not sure if this even SHOULD work, but I did this:

    dd if=neoware-backup of=/dev/mtd0 bs=8k

Which seemed to succeed.  Then I used 'cmp' to see if neoware-backup and /dev/mtd0 were identical - they were.  Then, as a final check, I did this:

    od -c /dev/mtd0 | grep "A   N   A   N   D"

Which found the media headers just like they used to be.

So this APPEARED to be a success, until I rebooted it.  At that point, the driver decided it needed
to reformat at the ntfl level:

	Formatting block 1
	Formatting Block 2

Etc. followed by:

	nftla: unknown partition table
	Creating 1 MTD partitions on "DiskOnChip Millennium":
	0x00010000-0x00800000 : " DiskOnChip BDTL partition"


This isn't a huge big deal, because I can reformat it and put the data back by copying the files.
It's just curious to me.

>We really ought to do something about how we expose devices to userspace

For now, I took the above "hack" and made it a module_param called "force_add_mtd_device" that
defaults to 0.  I did not do the other part where you sent nand->options to NAND_SKIP_BBTSCAN
yet, but I will take a look at the source and try to understand if it's necessary.

>For the CAFÉ driver I've implemented a 'skipbbt' module option, but it's something
>we need to fix in generic code.

Oops, I don't know what the CAFÉ driver is but your name for the parameter sounds better than mine.

Dunno ... I'm going to docfdisk it and proceed, and see how it goes.  Hopefully what I did restored the bad block table... Though I am obviously still finding my way through the fog here.

--Chris