Re: Write support

Re: Write support

[Patrick Higgins]

On Tue, 23 May 2000, Dvir Oren wrote:

> Patrick Higgins writes ("Re: Write support "):
> > > > So, I went back the not-so-handy dformat and now find that it fails 
> > > > after 4096 kbytes.  If this hardware is failing, it's failing like 
> > > > wildfire.  Have any of your units failed on  you? 
> 
> > Unfortunately, no.  I suppose I need to order a few more.  We ordered the
> > one I have from Flytech, and it took _forever_ to get here.  Do you know
> > of any good suppliers?  Can you buy directly from M-Systems?
> 
> I found that when this happens, I could use docpmap /e, which would erase
> the flsh _entirely_(***), and then I could use dformat, which will restore
> the flash to a usable state.
> 
> ***
> Using docpmap /e is 'prohibited' by M-Systems', and it will not be
> available in the next version.  The problem with this is that it
> erases the bad block table, which will never be restored again.
> 
> What can be done to avoid this is to do dformat /log:<filename>,
> which should save the bad block table to filename, and you can then
> restore it.
> 
> However, from my experience, and as it so happens to be, most flashes
> have 0 bad blocks.
> 
> You can take your chances if you want.

I wish I could still do this...unfortunately, I took my chances already
and used doc_loadbios to write the grub firmware onto the DoC, and now it
won't boot on my system which has a floppy (the only way I've able to get
DOS to boot), but I can still get it to boot Linux with PXE
(netboot).  Would something like:

dd if=/dev/zero of=/dev/mtd0

accomplish the same thing?

Has anyone gotten DOS to work with PXE?  If so, could you please describe
your setup?


Patrick


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Write support

[David Woodhouse]

phiggins@transzap.com said:
>  I wish I could still do this...unfortunately, I took my chances
> already and used doc_loadbios to write the grub firmware onto the DoC,
> and now it won't boot on my system which has a floppy (the only way
> I've able to get DOS to boot),

Strange. What does it do instead? What firmware did you load with 
doc_loadbios?

> but I can still get it to boot Linux with PXE (netboot). 
> Would something like:

> dd if=/dev/zero of=/dev/mtd0

> accomplish the same thing?

You don't need to set all bits to zero, and it may confuse the M-Systems 
drivers - they start at one when erased.

Stick a loop into mtd/util/erase.c if you want it to erase a whole device.



--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Write support

[Patrick Higgins]

On Mon, 22 May 2000, David Woodhouse wrote:

> > So, I went back the not-so-handy dformat and now find that it fails 
> > after 4096 kbytes.  If this hardware is failing, it's failing like 
> > wildfire.  Have any of your units failed on  you? 
> 
> I've had no failures so far. This is strange. Do you have other units you 
> can test with?

Unfortunately, no.  I suppose I need to order a few more.  We ordered the
one I have from Flytech, and it took _forever_ to get here.  Do you know
of any good suppliers?  Can you buy directly from M-Systems?

Patrick


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Write support

[Patrick Higgins]

I've finally gotten everything to compile and boot correctly, but now I
find that write support seems to have some problems.  The first is that I
can't mount the filesystem read-write in the first place--I have to mount
it read-only and then remount it read-write.  I suspect this is
intentional.  However, after remounting read-write, I start getting these
types of messages:

end_request: I/O error, dev 5d:01 (unknown), sector 4
end_request: I/O error, dev 5d:01 (unknown), sector 10
end_request: I/O error, dev 5d:01 (unknown), sector 12
end_request: I/O error, dev 5d:01 (unknown), sector 536


I find that if I create a file, it will show up in ls output until a round
of "end_request: I/O error" messages show up, after which point it will no
longer appear, but I am still able to cat the file correctly.

The driver also detects two Disk on Chips, although I only have one, as
seen in the following console output:

Main: Initialising MTD Drivers                                               
M-Systems DiskOnChip driver. (C) 1999 Machine Vision Holdings, Inc.          
Possible DiskOnChip with unknown ChipID C3 found at 0xc8000                  
DiskOnChip 2000 found at address 0xD8000                                     
3 flash chips found. Total DiskOnChip size: 24 Mb                            
DiskOnChip 2000 found at address 0xDA000                                     
3 flash chips found. Total DiskOnChip size: 24 Mb                            
M-Systems NAND Flash Translation Layer driver. (C) 1999 MVHI                 
$Id: nftl.c,v 1.29 2000/05/04 08:41:52 dwmw2 Exp $                           
NFTL capacity reduced for geometry reasons from bba0 to bb80 sectors         
Partition check:                                                             
 nftla: nftla1                                                               
NFTL capacity reduced for geometry reasons from bba0 to bb80 sectors         
 nftlb: nftlb1                                                               


Am I missing anything obvious?



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Write support

[David Woodhouse]

phiggins@transzap.com said:
> I missed the -DCONFIG_NFTL_RW option to gcc.

Hmmm. I'd quite it not to let you remount RW when write support isn't 
present. However, I can even do it with a read-only floppy disc, so I 
assume that deeper magic would be required.


>  The driver also detects two Disk on Chips, although I only have one,
> as seen in the following console output:

Hmmm. Your hardware doesn't seem to be decoding all the address lines; so
the DiskOnChip appears at both 0xd8000 and 0xda000. 

We need to eliminate duplicates - which means that the code in which you
fixed the NULL pointer dereference needs to be made stricter - it needs to 
verify not only that our potential new DiskOnChip isn't at the same 
location as any of the old ones, but also that it's not the same hardware 
in a different location.

I'm not sure how to do this off-hand - possibly by writing to an 
unimportant register in one, and seeing if it changes in the other.

If you don't want to do that right now, just remove one of the two 
addresses from the doc_locations list in your copy of docprobe.c


phiggins@transzap.com said:
> NFTL capacity reduced for geometry reasons from bba0 to bb80 sectors

Now this I disapprove of. I thought I was using exactly the same method for 
calculating geometry as they did. Could you load M-Systems' driver and tell 
me what geometry it reports, along with the geometry reported by my code?


phiggins@transzap.com said:
>  I know you said earlier that the .exb files are not straight firmware
> images.  Do you know what format they are in, and how to convert them?

IIRC the IPL ROM loads the first 0x2000 bytes of the firmware only from the 
'left-hand-side' of the first 0x4000 bytes of the actual flash - using 256 
bytes of each 512-byte page. After that, the whole of the flash is used. 

Therefore, I assume that the EXB files can be converted by something like...

u_char buf[512];
long c=0;

memset(buf,0xff, 512);

while (c<0x2000) {
  read(exbfile, buf, 256);
  write(flash, buf, 512);
}

while (!eof(exbfile)) {
 read(exbfile, buf, 512);
 write(flash, buf, 512);
}

The dd utility could also do this for you without much difficulty, allowing 
you to then feed your converted firmware file to doc_loadbios.

You could confirm this by using the DOS utility to load the firmware once, 
then using dd to read it back off the raw flash (/dev/mtd0). Even if you 
can't work out the conversion from the original EXB file, you'll then have 
a firmware image that _is_ just an image of what to put on the flash, and 
hence can be used with doc_loadbios.


phiggins@transzap.com said:
>  How much work do you estimate would be required to get grub working,
> and what advantages and disadvantages would it have in comparison to
> lilo and syslinux?

The advantage of Grub once it's done is that it would be capable of 
driving the DiskOnChip directly - you wouldn't need to work around the 
problems with the M-Systems firmware using up all your precious sub-640K 
RAM.

It's already capable of finding and driving the hardware, and scanning for 
an NFTL Media Header. All that remains is to transplant some simple 
read-only NFTL support from the existing code in nftl.c - I reckon not a 
lot more than a couple of days' work.



--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org