quick question

quick question

[Stephen Brown]

Hi all,

what do you all think about this:

http://www.m-sys.com/content/products/product.asp?PID=17&FILE=DOCIdePro&FAM=
doc

if I used this as a standard IDE device does this mean that I wouldn't
require any MTD drivers for linux and just use the standard IDE?

if so could I format this as EXT2 fs and contain my ROOT file system on it?
or would I still run the risk of power failure disk error etc?

 I mean I can load my ROOT fs into memory so thats not a problem, see the
thing is at the moment I can't get the MTD drivers to work with the onboard
'Msys D-O-C' on an Ampro p5e module, reason being is Ampro use part of the
FLASH to store the bios for the ampro board and have specific tools for
formatting etc, so I boot from a dos partition using 'LoadLin' or I can boot
from a Harddrive connected to the IDE, so in my case maybe the 'IDE PRO' is
an alternative , also to save recompiling the kernel for the p5e maybe..

anyways let me know what you think,

kind regards

stephen


________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

Re: quick question

[David Woodhouse]

On Thu, 2003-06-26 at 12:00, Stephen Brown wrote:
> Hi all,
> 
> what do you all think about this:
> 
> http://www.m-sys.com/content/products/product.asp?PID=17&FILE=DOCIdePro&FAM=
> doc
> 
> if I used this as a standard IDE device does this mean that I wouldn't
> require any MTD drivers for linux and just use the standard IDE?
> 
> if so could I format this as EXT2 fs and contain my ROOT file system on it?
> or would I still run the risk of power failure disk error etc?

You'd want EXT3 not EXT2, presumably, but yes -- it should just work. 

You still have the same fundamental problem that you're running a
journalling file system atop a journalling pseudo-filesystem which
emulates a block device, but unlike the reports I've heard about most
CompactFlash devices, I'd expect that M-Systems have at least managed to
make the firmware within the device itself reliable w.r.t.
power-failure.

>  I mean I can load my ROOT fs into memory so thats not a problem, see the
> thing is at the moment I can't get the MTD drivers to work with the onboard
> 'Msys D-O-C' on an Ampro p5e module, reason being is Ampro use part of the
> FLASH to store the bios for the ampro board and have specific tools for
> formatting etc,

That's interesting... can you describe the problems? Precisely what type
of DiskOnChip is it, is it detected correctly by the hardware driver? Is
it only the NFTL code which is unhappy? etc. 

-- 
dwmw2

Re: quick question

[Stephen Brown]

hi,

its a DOC 2000 , onboard 8 MB, it resides on the p5e module, Ampro have
specifically changed the hardware to suit their SBC, which includes a bios
copy from eprom, they provide utility tools similar to the 'm-sys' ones,
except are specifically designed for Ampro, if you use the 'm-sys' tools the
SBC won't boot as 'im assuming' the bios cannot be copied from eprom as the
first bios screen wont load, this creates a DOS partition as well as a bios
area stored close to the boot sector.

1st problem is, compiling the kernel for the Ampro p5e module takes a good
half day!!
2nd problem, the preparation for a standard 'm-sys DOC' is not the same as
in the specific tools that are written for the p5e module.

I tried quite a few different kernel compiles ( include MTD - etc etc - also
tried the ones default with kernel 2.4.4 and the latest ones from web ) to
try and make the DOC compatible with the real-time linux kernel, recompiled
with RTLinux pre-1, but couldnt get it to work, this takes up a lot of time!
so.. i opted to load the RTLinux kernel and root filesystem from the DOS
partition, that resides on the p5e module, using 'loadlin' , this loads into
memory using initrd as the p5e module has 32 MB sdram,

the system is finished and I am happy with its performance but ...  looking
ahead into the future 'if' the hardware has to stay the same it would be
nice to have a non-volatile area so to store network information etc,
instead at the moment I can change on the fly, until I power down, or... I
can create a new ROOT filesystem (*.gz) , change a few scripts etc, for
permanent changes.

I cannot recompile the kernel for Red Hat 7.2 and RTLinux to include ext3
fs, so I have learned to live with it as ext2.

This is why I have an interest in the 'IDE PRO' if maybe it can provide a
solution via the IDE bus, without a lot more time consuming kernel
compiling, the other option was a seperate DOC from 'm-sys' that could
interface with our pc-104 stack which Im assuming would require me to
recompile the kernel, which in turn would have a knock on effect to my
development PC and all modules compiled for the target p5e etc etc... blah
blah...    i dont mind doing it but obviously an alternative would be better
, while we are tied with the current hardware..

kind regards

stephen
----- Original Message -----
From: "David Woodhouse" <dwmw2@infradead.org>
To: "Stephen Brown" <sbrown@stirling-dynamics.com>
Cc: <linux-mtd@lists.infradead.org>
Sent: Thursday, June 26, 2003 12:06 PM
Subject: Re: quick question


> On Thu, 2003-06-26 at 12:00, Stephen Brown wrote:
> > Hi all,
> >
> > what do you all think about this:
> >
> >
http://www.m-sys.com/content/products/product.asp?PID=17&FILE=DOCIdePro&FAM=
> > doc
> >
> > if I used this as a standard IDE device does this mean that I wouldn't
> > require any MTD drivers for linux and just use the standard IDE?
> >
> > if so could I format this as EXT2 fs and contain my ROOT file system on
it?
> > or would I still run the risk of power failure disk error etc?
>
> You'd want EXT3 not EXT2, presumably, but yes -- it should just work.
>
> You still have the same fundamental problem that you're running a
> journalling file system atop a journalling pseudo-filesystem which
> emulates a block device, but unlike the reports I've heard about most
> CompactFlash devices, I'd expect that M-Systems have at least managed to
> make the firmware within the device itself reliable w.r.t.
> power-failure.
>
> >  I mean I can load my ROOT fs into memory so thats not a problem, see
the
> > thing is at the moment I can't get the MTD drivers to work with the
onboard
> > 'Msys D-O-C' on an Ampro p5e module, reason being is Ampro use part of
the
> > FLASH to store the bios for the ampro board and have specific tools for
> > formatting etc,
>
> That's interesting... can you describe the problems? Precisely what type
> of DiskOnChip is it, is it detected correctly by the hardware driver? Is
> it only the NFTL code which is unhappy? etc.
>
> --
> dwmw2
>
>
> ________________________________________________________________________
> This e-mail has been scanned for all viruses by Star Internet. The
> service is powered by MessageLabs. For more information on a proactive
> anti-virus service working around the clock, around the globe, visit:
> http://www.star.net.uk
> ________________________________________________________________________
>

----- Original Message -----
From: "David Woodhouse" <dwmw2@infradead.org>
To: "Stephen Brown" <sbrown@stirling-dynamics.com>
Cc: <linux-mtd@lists.infradead.org>
Sent: Thursday, June 26, 2003 12:06 PM
Subject: Re: quick question


> On Thu, 2003-06-26 at 12:00, Stephen Brown wrote:
> > Hi all,
> >
> > what do you all think about this:
> >
> >
http://www.m-sys.com/content/products/product.asp?PID=17&FILE=DOCIdePro&FAM=
> > doc
> >
> > if I used this as a standard IDE device does this mean that I wouldn't
> > require any MTD drivers for linux and just use the standard IDE?
> >
> > if so could I format this as EXT2 fs and contain my ROOT file system on
it?
> > or would I still run the risk of power failure disk error etc?
>
> You'd want EXT3 not EXT2, presumably, but yes -- it should just work.
>
> You still have the same fundamental problem that you're running a
> journalling file system atop a journalling pseudo-filesystem which
> emulates a block device, but unlike the reports I've heard about most
> CompactFlash devices, I'd expect that M-Systems have at least managed to
> make the firmware within the device itself reliable w.r.t.
> power-failure.
>
> >  I mean I can load my ROOT fs into memory so thats not a problem, see
the
> > thing is at the moment I can't get the MTD drivers to work with the
onboard
> > 'Msys D-O-C' on an Ampro p5e module, reason being is Ampro use part of
the
> > FLASH to store the bios for the ampro board and have specific tools for
> > formatting etc,
>
> That's interesting... can you describe the problems? Precisely what type
> of DiskOnChip is it, is it detected correctly by the hardware driver? Is
> it only the NFTL code which is unhappy? etc.
>
> --
> dwmw2
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
> ________________________________________________________________________
> This e-mail has been scanned for all viruses by Star Internet. The
> service is powered by MessageLabs. For more information on a proactive
> anti-virus service working around the clock, around the globe, visit:
> http://www.star.net.uk
> ________________________________________________________________________
>


________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

Re: quick question

[David Woodhouse]

Weird -- what did you do different between your reply directly to me
(which had correct References: headers) and your reply to the list
(which didn't, hence got rejected)? 

(... and then what did you do differently in your _second_ reply to the
list, which worked?)

Had you deleted the mail to which you're replying, or changed folders
and were no longer looking at the same folder, or something?

You're using Outlook and Exchange, right?

On Thu, 2003-06-26 at 13:01, Stephen Brown wrote:
> hi,
> 
> its a DOC 2000 , onboard 8 MB, it resides on the p5e module, Ampro have
> specifically changed the hardware to suit their SBC, which includes a bios
> copy from eprom, they provide utility tools similar to the 'm-sys' ones,
> except are specifically designed for Ampro, if you use the 'm-sys' tools the
> SBC won't boot as 'im assuming' the bios cannot be copied from eprom as the
> first bios screen wont load, this creates a DOS partition as well as a bios
> area stored close to the boot sector.
> 
> 1st problem is, compiling the kernel for the Ampro p5e module takes a good
> half day!!

Weird -- why? Are you building on the board itself and starting from
'make clean' each time? 

You ought to be able to make just the MTD and DiskOnChip modules to
match the kernel you're running, and shouldn't even need to reboot to
test them.

> 2nd problem, the preparation for a standard 'm-sys DOC' is not the same as
> in the specific tools that are written for the p5e module.

Interesting. Do you know what _address_ you tell the p5e DFORMAT utility
to find the DiskOnChip at? Or what address it finds it at?

> I tried quite a few different kernel compiles ( include MTD - etc etc - also
> tried the ones default with kernel 2.4.4 and the latest ones from web ) to
> try and make the DOC compatible with the real-time linux kernel, recompiled
> with RTLinux pre-1, but couldnt get it to work, this takes up a lot of time!

Can you remember details? Did the hardware driver manage to detect the
DiskOnChip and report its presence? Was it only a problem with the
_contents_ of the DiskOnChip?

> I cannot recompile the kernel for Red Hat 7.2 and RTLinux to include ext3
> fs, so I have learned to live with it as ext2.

Why so?

-- 
dwmw2

RE: Quick question.

[Gareth Williams]

Hi David.

Thankyou for the advice you gave me earlier last week.

I wonder if you would take a couple of minutes to look over the following
message the kernel gave me on booting and give your advice.

I managed to finally get the 2.4.12 linux kernel configured & compiled,
after much pratting about with upgrades to gcc & bin utils etc, here is my
kernel config which I specified for the MTD stuff:

(where I have not listed something then I have not included that in the
kernel build)

* Mem tech device support
* NFTL support
* Write support for NFTL (BETA)
NOTE: Mapping drivers for chip access menu has NO SUBMENU!! (pressing enter
on it has no effect).
*	Self contained MTD device drivers>>>>
	*M-Systems DOC & Millennium
	*Advanced detection options for DOC
	*0 - Physical address
	*Probe for 0x55 & 0xAA
	*NAND flash device drivers>>>>>
		*NAND device support
		*Enable ECC

On booting the kernel your stuff correctly detects that I have a DOC2000
with 8MB but fails to create any device special file in /dev, here is a
transcript:

DiskOnChip 2000 found at address 0xD4000
Flash Chip Found: Manufacturer ID: EC, Chip ID: E6 (Samsung KM29U64000)
1 Flash chips found.  Total DiskOnChip size: 8MiB
NFTL Driver: nftlcore.c $ Revision: 1.82 $, nftlmount.c $Revision: 1.23$
ANAND header found @ 0xC000 in mtd0, but ECC read failed (err 1)
ANAND header found @ 0xE000 in mtd0, but ECC read failed (err 1)
Could not find valid boot record.
Could not mount NFTL device.

I hope you can give some advice on this matter, it is probably just a
mistake on my behalf in configuring the kernel.

Thanks in advance.

Gareth Williams.

Re: Quick question.

[David Woodhouse]

gareth@microm-electronics.com said:
> ANAND header found @ 0xC000 in mtd0, but ECC read failed (err 1) 
> ANAND header found @ 0xE000 in mtd0, but ECC read failed (err 1)
> Could not find valid boot record.
> Could not mount NFTL device.

It's being anal and refusing to deal with the Media Header because the ECC 
failed on that block - it seems that some versions of the M-Systems 
firmware don't put ECC on the Media Header blocks.

--- drivers/mtd/nftlmount.c	2001/09/19 21:42:32	1.23
+++ drivers/mtd/nftlmount.c	2001/10/19 12:22:13
@@ -94,7 +94,7 @@
 			continue;
 		}
 
-#if 1 /* Some people seem to have devices without ECC or erase marks
+#if 0 /* Some people seem to have devices without ECC or erase marks
 	 on the Media Header blocks. There are enough other sanity
 	 checks in here that we can probably do without it.
       */



--
dwmw2