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

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

[Christopher E Piggott]

I did something with a bit too much haste, and I erased my DOC2000-D08
chip.  
 
Before I did this, I attempted to save something that I could use later
as an backup:
 
    dd if=/dev/mtd0 of=backup.img bs=8k
 
The file I got makes sense, at least in that it has the ANAND in it at
offsets 0xC000 and 0xE000... which makes me think I saved my bad block
map.
 
My trick now is how to put it back.  Linux sees the chip, but not as a
DoC:
 
    Using configured DiskOnChip probe address 0xd0000
    DiskOnChip found at 0xd0000
    NAND device: Manufacturer ID: 0x98, Chip ID: 0xe6 (Toshiba NAND 8MiB
3,3V 8-bit)
    ECC error scanning DOC at 0xc000
    ECC error scanning DOC at 0xe000
    DiskOnChip ANAND Media Header not found.

This means that there is no /dev/mtd0 to put it back.
 
Is it even possible to do this without going back to DOS?  That is a
problem for me as the systems I have with DoC sockets don't have the
ability to boot off of a FreeDOS floppy or CD-ROM.  It MAY be possible
to do something using an external hard drive, putting freedos on that,
and going on from there ... but life would be much simpler for me if
there were a way to do this entirely from linux, considering that I
saved the image before I started.
 
Any ideas or tricks?
 
--Chris
 
 

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

[David Woodhouse]

On Tue, 2007-02-06 at 15:49 -0500, Christopher E Piggott wrote:
> I did something with a bit too much haste, and I erased my DOC2000-D08
> chip.  
>  
> Before I did this, I attempted to save something that I could use later
> as an backup:
>  
>     dd if=/dev/mtd0 of=backup.img bs=8k
>  
> The file I got makes sense, at least in that it has the ANAND in it at
> offsets 0xC000 and 0xE000... which makes me think I saved my bad block
> map.
>  
> My trick now is how to put it back.  Linux sees the chip, but not as a
> DoC:
>  
>     Using configured DiskOnChip probe address 0xd0000
>     DiskOnChip found at 0xd0000
>     NAND device: Manufacturer ID: 0x98, Chip ID: 0xe6 (Toshiba NAND 8MiB
> 3,3V 8-bit)
>     ECC error scanning DOC at 0xc000
>     ECC error scanning DOC at 0xe000
>     DiskOnChip ANAND Media Header not found.
> 
> This means that there is no /dev/mtd0 to put it back.
>  
> Is it even possible to do this without going back to DOS?  That is a
> problem for me as the systems I have with DoC sockets don't have the
> ability to boot off of a FreeDOS floppy or CD-ROM.  It MAY be possible
> to do something using an external hard drive, putting freedos on that,
> and going on from there ... but life would be much simpler for me if
> there were a way to do this entirely from linux, considering that I
> saved the image before I started.
>  
> Any ideas or tricks?

Hack drivers/mtd/nand/diskonchip.c to register the raw device even if it
doesn't find the Media Header. At about line 1349, in the function
nftl_scan_bbt() where the call to nftl_partscan() fails, make it jump to
the add_mtd_device(mtd); at the end instead of bailing out. You may also
want to set nand->options = NAND_SKIP_BBTSCAN at about line 1666 instead
of its current value.

Then write the original table back using nandwrite.

We really ought to do something about how we expose devices to userspace
-- present a 'raw device' as well as the one mapped with the BBT and
partitions. For the CAFÉ driver I've implemented a 'skipbbt' module
option, but it's something we need to fix in generic code.

-- 
dwmw2

RE: 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