Re: sbc-mediagx

Re: sbc-mediagx

[David Woodhouse]

ajlennon@arcom.co.uk said:
>  FlashFx implements VBF to support block access to the media and to
> provide wear levelling amongst other things (I believe). The "Variable
> Block Flash" component is *not* a filesystem. It simply translates
> logical sector requests to physical flash locations. 

Similar in principle, then, if not in implementation, to FTL.
A kind of pseudo-filesystem which is used to emulate a block device.

Does it use the concepts which are patented by M-Systems? I believe that 
the patents in this area are extremely broad, and cover almost all obvious
methods of implementing wear levelling. 



--
dwmw2




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

RE: sbc-mediagx

[Alex J Lennon]

> >  FlashFx implements VBF to support block access to the media and to
> > provide wear levelling amongst other things (I believe). The "Variable
> > Block Flash" component is *not* a filesystem. It simply translates
> > logical sector requests to physical flash locations.
>
> Similar in principle, then, if not in implementation, to FTL.
> A kind of pseudo-filesystem which is used to emulate a block device.
>
> Does it use the concepts which are patented by M-Systems? I believe that
> the patents in this area are extremely broad, and cover almost all obvious
> methods of implementing wear levelling.
>
>

There is a whitepaper discussing VBF at
www.datalight.com/wp-data-integrity.htm

Also , there is a discussion of a possible pre-cursor to FlashFx in DDJ, May
'93
- although I haven't managed to source this .

Alex




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

Re: sbc-mediagx

[David Woodhouse]

ajlennon@arcom.co.uk said:
>  There is a whitepaper discussing VBF at www.datalight.com/
> wp-data-integrity.htm 

Hmmm. Who's gonna reverse-engineer it and provide an MTD module for it then?

--
dwmw2




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

Re: sbc-mediagx

[Scott Anderson]

Alex J Lennon wrote:
> Also , there is a discussion of a possible pre-cursor to FlashFx in DDJ, May
> '93
> - although I haven't managed to source this .

You can get all the articles/source from 1988 up to now on the
Dr. Dobb's CD/Release 9:
	http://www.ddj.com/cdrom/
It's $100US though.  Here's a list of the FLASH articles that I
found on my Release 8 CD:

 May 93
 FLASH FILE SYSTEMS by Drew Gislason
 Flash memory packaged in solid-state, credit card-size PCMCIA cards is
 starting to change the face of embedded and portable systems. Drew
 examines Flash file systems and presents one that's FAT-like.

 Feb 95
 THE MICROSOFT FLASH FILE SYSTEM
 by Peter Torelli
 Peter examines flash file systems for DOS, focusing on the mechanics
 behind a flash file system based on the Microsoft data structures.

 Oct 95
 INSIDE FLASH MEMORY
 by Brian L. Dipert
 Direct-execute flash memory systems don't require the gigabyte hard
 disks and 64-Mbit DRAM arrays common in desktop systems.
 
The May 93 article has source that simply allocates a FLASH sector
for every sector of a FAT file system.  It doesn't do erases.  He
discusses that there is a better way, which he called "Byte-oriented
Flash File System", but there isn't much detail there.  What he
does say is that at Datalight (his employer) they use a linked
list of records with each header containing "approximately 12 bytes
(describing the data's owner) and a variable-length data field".
I do not see any mention of an FTL.  This last point interested
me because the article is from May 93 and the imfamous M-systems
patent was filed Mar 93.

    Scott Anderson		
    scott_anderson@mvista.com	MontaVista Software Inc.
    (408)328-9214		490 Potrero Ave.
    http://www.mvista.com	Sunnyvale, CA  94086


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

re[2]: SBC-MediaGX

[Tony Questad]

>>  My understanding (you better check this before trying anything) is that
>>   the BIOS extension only contains the VBF code needed for DOS to see the VBF 
>>  volume. If you trash it, all that will happen is that you won't be able to
>>  access the VBF volume, and you can always reinstall it from the Arcom
>>   floppy.  The BIOS itself is in another flash chip entirely. I think.

That sounds right -- on the MediaGX the BIOS is contained in a seperate BIOS ROM, and the FlashFX BIOS Extension is stored in the beginning of the flash array.  Erasing this will remove the FlashFX driver, but if this is not a concern at this time, you can always reprogram it from the original Arcom disks.

>>  >Another question: why is the BIOS extension area soo big as
>>  >the extension itself is only about 14kB? The autoexec.bat file
>>  >on the Arcom bootfloppy mentions that the extension was enlarged
>>  >some time ago to 256KB in order to accomodate the Windows CE
>>  >registry???
>>  Don't know. I stuck with 256kB on my board for the same reason you did. I 
>>  don't think it's critical; what's the maximum size for a ROM extension?
>>   16kB?  32kB?

What is the erase zone size on that board?  You would need to reserve space in erase zone sized chunks; On a flash part with 128KB erase zones, the minimum you would need to reserve would be 128KB, no matter how large your BIOS extensions are.  You do not want the area that your BIOS extension is in being moved around by FlashFX, or any wear leveling system as it would need to stay put in the beginning of the flash -- The reason for 256k escapes me at this moment, as I remember that the BIOS Extension for FlashFx is probably 16kb, but I am sure they were using the other area for CE related issues.  It may very well be that the first 128k (or 64k) was reserved as a full sector to handle the 16kb BIOS extension, and the rest was done for future growth.

****************************************************************************
 Senior Development Support Engineer   Datalight, Inc
 tel: 425 951 8086 x142                21520 30th Drive SE, Suite 110
 fax: 425 951 8094                     Bothell, WA
 email: tony.questad@datalight.com     98021


Leverage over 100 man-years of embedded system experience!  24-hour/7-day 
support is found at: http://datalight.custhelp.com/cgi-bin/datalight
****************************************************************************


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

RE: SBC-MediaGX

[Alex J Lennon]

> >>  >Another question: why is the BIOS extension area soo big as
> >>  >the extension itself is only about 14kB? The autoexec.bat file
> >>  >on the Arcom bootfloppy mentions that the extension was enlarged
> >>  >some time ago to 256KB in order to accomodate the Windows CE
> >>  >registry???
> >>  Don't know. I stuck with 256kB on my board for the same 
> reason you did. I 
> >>  don't think it's critical; what's the maximum size for a ROM 
> extension?
> >>   16kB?  32kB?
> 
> What is the erase zone size on that board?  You would need to 
> reserve space in erase zone sized chunks; On a flash part with 
> 128KB erase zones, the minimum you would need to reserve would be 
> 128KB, no matter how large your BIOS extensions are.  You do not 
> want the area that your BIOS extension is in being moved around 
> by FlashFX, or any wear leveling system as it would need to stay 
> put in the beginning of the flash -- The reason for 256k escapes 
> me at this moment, as I remember that the BIOS Extension for 
> FlashFx is probably 16kb, but I am sure they were using the other 
> area for CE related issues.  It may very well be that the first 
> 128k (or 64k) was reserved as a full sector to handle the 16kb 
> BIOS extension, and the rest was done for future growth.

True - The area at the start of the flash array is 256Kb to support
a non-volatile CE registry. No harm will come of you reducing
this to the erase zone size of 128kb (unless of course you'll
be wanting to run CE ;)


Alex 




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

SBC-MediaGX

[Michiel Ronsse]

Hi,

after checking all the messages in the archive of this
mailing list I managed to access the Intel Strataflash
chip on our Arcom SBC-MediaGX board. I 'repartitioned' the flash:
256kB for the BIOS extension, 1.5MB for DOS and the remainder
for Linux. The linux partition was formatted with JFFS.
Everything seems to work find although JFFS makes a lot
of noise when mounting the partition, moreover it finds only
13MB free and df only reports 4MB free... 

The next logical step would be to make the flash bootable
by overwriting the BIOS extension. I'm a bit reluctant to
do this as I don't want to make my board unbootable. E.g.
what happens if there is something wrong with the new BIOS?
Can you prevent somehow the BIOS on the board 
from executing the BIOS extension in the flash? 


Another question: why is the BIOS extension area soo big as
the extension itself is only about 14kB? The autoexec.bat file
on the Arcom bootfloppy mentions that the extension was enlarged
some time ago to 256KB in order to accomodate the Windows CE
registry???



Michiel Ronsse.


-- 
+- Michiel Ronsse --- michiel.ronsse@rug.ac.be -+
| Parallel Information Systems Group            |
| ELIS - Ghent University  - Ghent, Belgium     |
| Phone: +32/9/264.33.67   Fax: +32/9/264.35.94 |
+------ http://www.elis.rug.ac.be/~ronsse ------+

In a train station the train stops, in a work station ...


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

Re: SBC-MediaGX

[David Given]

>after checking all the messages in the archive of this
>mailing list I managed to access the Intel Strataflash
>chip on our Arcom SBC-MediaGX board. I 'repartitioned' the flash:
>256kB for the BIOS extension, 1.5MB for DOS and the remainder
>for Linux. The linux partition was formatted with JFFS.
>Everything seems to work find although JFFS makes a lot
>of noise when mounting the partition, moreover it finds only
>13MB free and df only reports 4MB free... 

There may be sectors needing garbage collection. Try syncing it and having 
another look. As for why it's so slow, I'm not sure, but someone posted a 
patch a few days ago that should speed things up considerably (I haven't tried 
it).

>The next logical step would be to make the flash bootable
>by overwriting the BIOS extension. I'm a bit reluctant to
>do this as I don't want to make my board unbootable. E.g.
>what happens if there is something wrong with the new BIOS?
>Can you prevent somehow the BIOS on the board 
>from executing the BIOS extension in the flash? 

My understanding (you better check this before trying anything) is that the 
BIOS extension only contains the VBF code needed for DOS to see the VBF 
volume. If you trash it, all that will happen is that you won't be able to 
access the VBF volume, and you can always reinstall it from the Arcom floppy. 
The BIOS itself is in another flash chip entirely. I think.

What do you have in mind for a boot loader?

>Another question: why is the BIOS extension area soo big as
>the extension itself is only about 14kB? The autoexec.bat file
>on the Arcom bootfloppy mentions that the extension was enlarged
>some time ago to 256KB in order to accomodate the Windows CE
>registry???

Don't know. I stuck with 256kB on my board for the same reason you did. I 
don't think it's critical; what's the maximum size for a ROM extension? 16kB? 
32kB?

-- 
David Given
dg@tao-group.com




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

Re: SBC-MediaGX

[Michiel Ronsse]

David Given wrote:
> 
> >after checking all the messages in the archive of this
> >mailing list I managed to access the Intel Strataflash
> >chip on our Arcom SBC-MediaGX board. I 'repartitioned' the flash:
> >256kB for the BIOS extension, 1.5MB for DOS and the remainder
> >for Linux. The linux partition was formatted with JFFS.
> >Everything seems to work find although JFFS makes a lot
> >of noise when mounting the partition, moreover it finds only
> >13MB free and df only reports 4MB free...
> 
> There may be sectors needing garbage collection. Try syncing it and having
> another look. As for why it's so slow, I'm not sure, but someone posted a
> patch a few days ago that should speed things up considerably (I haven't tried
> it).

It seems the JFFS image made by mk.jffs was totaly f**ked up. The
garbage
collector freaked out after a while (endless loop) and managed to erase
the first few bytes from my FlashFX-BIOS image! However after each few
reboot/
mount/garbage collections everything seems to work fine now. Actually,
it
works like a charm!


> >The next logical step would be to make the flash bootable
> >by overwriting the BIOS extension. I'm a bit reluctant to
> >do this as I don't want to make my board unbootable. E.g.
> >what happens if there is something wrong with the new BIOS?
> >Can you prevent somehow the BIOS on the board
> >from executing the BIOS extension in the flash?
> 
> My understanding (you better check this before trying anything) is that the
> BIOS extension only contains the VBF code needed for DOS to see the VBF
> volume. If you trash it, all that will happen is that you won't be able to
> access the VBF volume, and you can always reinstall it from the Arcom floppy.
> The BIOS itself is in another flash chip entirely. I think.

As I understand it, the BIOS is in the first 256kB of the flash.
Disassembling
the first few bytes surely look like the start of a BIOS extension (e.g.
it
starts with the magic numbers AA55). Actually, after the first bytes
were
wiped out by the garbage collector, I couldn't access the Flash-drive
under DOS
anymore (the FlashFX message that 'flashes' by at bootup didn't appear
=> no
BIOS extension installed.)


> 
> What do you have in mind for a boot loader?

Good question that remains to be answered...

> 
> >Another question: why is the BIOS extension area soo big as
> >the extension itself is only about 14kB? The autoexec.bat file
> >on the Arcom bootfloppy mentions that the extension was enlarged
> >some time ago to 256KB in order to accomodate the Windows CE
> >registry???
> 
> Don't know. I stuck with 256kB on my board for the same reason you did. I
> don't think it's critical; what's the maximum size for a ROM extension? 16kB?
> 32kB?

The memory window it takes up at bootup (processor in real mode) is only
16kB big,
so this seems to be the maximum.



Michiel Ronsse.


BTW: my board now works like a charm. The flash starts with a BIOS
extension of
256kB, followed by a DOS/FlashFX partition of 1MB containing
loadlin+vmnlinuz and
I have a minimal Linux-system in the last partition of around 15MB.



-- 
+- Michiel Ronsse --- michiel.ronsse@rug.ac.be -+
| Parallel Information Systems Group            |
| ELIS - Ghent University  - Ghent, Belgium     |
| Phone: +32/9/264.33.67   Fax: +32/9/264.35.94 |
+------ http://www.elis.rug.ac.be/~ronsse ------+

In a train station the train stops, in a work station ...


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

Re: sbc-mediagx

[David Given]

>Yep.  It will do.  The CFI probe stuff thinks that each chip is 2
>interleaved => it thinks the size of the chip returned is half the
>actual size.  It then looks for the second chip at two times the size
>returned ie 8*2=16Mibyte => it can't find the second chip.  I fudged
>around this by ignoring the interleave when working out the address to
>probe for a second chip.  This isn't in the CVS since it would break
>other peoples chips.  I've reasly got to think of a better solution...

I don't know enough about the way flash works to determine what's going on, 
I'm afraid.

[...]
>They're not really partition but MTD devices that are restricted to
>certain areas of the flash.
>
>The odd numbered devices are read only versions of the even numbered
>devices which is why mtd0 looks the same as mtd1.

Am I right in assuming that the partition sizes in sbc_mediagx.c are 
hard-coded and don't necessarily correspond to any particular region on the 
disk? FXINFO claims that the VBF partition starts at 256kB. Looking at 
dev/mtd/0, there's a ROM image in the bottom 8kB, and at 256kB there's 
something that looks suspiciously like a VBF header. I can certainly identify 
things like the volume serial number and various pieces of information that 
FXINFO gave me. These are then repeated every megabyte.

...

Yup, changing the partition information to:

const static PartitionInfo partition_info[]={
    {"SBC-MediaGX flash BIOS extension", 0, 256*1024},
    {"SBC-MediaGX flash VBF volume", 256*1024, 0},
};

...makes things make a whole lot more sense.

[...]
>You won't beable to have both Linux and Dos booting of the flash.  Just
>make sure you have a floppy drive to boot from...

I have one, yes. However I'm extremely wary of playing with the flash; as far 
as I can determine, the FlashFX BIOS extension and, possibly, the Award BIOS 
itself are in the flash. If I erased it all from within Linux, I might nuke 
those as well and render the board unbootable. If anyone can comfirm that this 
is not the case, I would be most grateful.

Am I right in assuming that VBF is patented and closed? Is any information on 
it at all available, even just enough to identify the start of the VBF 
partition?

>Arcom is currently in the process of producing a Linux dev. kit which
>will do all this + booting for you.

Excellent.

David Given
dg@tao-group.com




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

Re: sbc-mediagx

[Kira Brown]

On Thu, 14 Sep 2000, David Given wrote:

> >Arcom is currently in the process of producing a Linux dev. kit which
> >will do all this + booting for you.
> 
> Excellent.

Irony:  Rachel (my SO) and I wrote the Arcom website...  now I work for
the competition.

...who, incidentally, have a K6-2e+ board that's ncredibly small and
featuresome...  and which comes with Linux preloaded...

...sorry, must stop spamming now.

kira.



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

sbc-mediagx

[David Given]

I have a Arcom systems development board with a Datalight FlashFX flash device 
on it. When I heard that the new MTD system supported this, I rejoiced, 
because the Datalight binary-only FlashFX driver sucks beyond belief. (It's 
120kB. It only works on 2.2.10. When writing, it leaves interrupts off for 
long periods. It takes several minutes to write a few hundred kB --- with 
interrupts off. If you run strings on it, you discover that it seems to have a 
number of DOS executables compiled into it.)

So, I checked the latest MTD out of CVS, got 2.4.0test7 (test8 locks up on 
me), and got it working.

* MTD only works with kernels compiled with*out* MODVERSIONS. This is because 
the dynamic loading code in map.h doesn't know about the mangled symbols used 
with this option turned on.

* The device claims to see only 8MB of my flash medium.

* The device sees three partitions on the disk. DOS sees one. I suspect that 
they use different concepts of partitions.

* MTD doesn't work with devfs, so you have to create device nodes manually --- 
/dev/mtd is at c,90,0..2 and /dev/mtdblock is at b,31,0..2, right?

* There does seem to be data in the partitions. mtd0 and mtd1 seem to be 
identical, and they look suspiciously like a PC ROM --- I'm steering well 
clear of them. mtd2 is strange. There are visible strings here and there, but 
nothing that seems to make any sense. DOS thinks there's a FAT12 filesystem on 
it.

mtd0 & 1 are 640kB. mtd2 is 1.44MB. mtdblock0 is 640kB, mtdblock1 is 1.44MB, 
and mtdblock2 is 6MB. The data in them all seem to repeat after 1MB.

Would anyone like to explain to me what's going on, if anyone knows? I 
*really* don't want to go back to using flashfx.o. I don't want to experiment 
as I could easily render my board unbootable. Which would be a shame.

BTW, anyone know how frequently the kernel syncs with the CVS tree?

-- 
+- David Given ---------------McQ-+ "`Aplysia californica' is your taxonomic
|  Work: dg@tao-group.com         | nomenclature.
|  Play: dgiven@iname.com         | A slug, by any other name, is still a slug
+- http://wired.st-and.ac.uk/~dg -+ by nature." --- drushel on a.f.c           






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

Re: sbc-mediagx

[David Woodhouse]

dg@tao-group.com said:
>  * MTD only works with kernels compiled with*out* MODVERSIONS. This is
> because  the dynamic loading code in map.h doesn't know about the
> mangled symbols used  with this option turned on. 

Easy to fix - just that nobody's bothered yet. Patches accepted if you care 
enough to produce one.


dg@tao-group.com said:
>  * The device claims to see only 8MB of my flash medium. 

Odd. Please send the kernel's output while it's probing. How big _is_ the 
flash?


dg@tao-group.com said:
>  * The device sees three partitions on the disk. DOS sees one. I
> suspect that  they use different concepts of partitions. 

Yes. In hindsight, we probably shouldn't call them 'partitions'.

dg@tao-group.com said:
>  * MTD doesn't work with devfs, so you have to create device nodes
> manually ---  /dev/mtd is at c,90,0..2 and /dev/mtdblock is at
> b,31,0..2, right? 

See #1. Patches accepted if you care :)


dg@tao-group.com said:
>  Would anyone like to explain to me what's going on, if anyone knows?
> I  *really* don't want to go back to using flashfx.o. I don't want to
> experiment  as I could easily render my board unbootable. Which would
> be a shame.

Please could you bzip2 and send to me the contents of /dev/mtd[012]. I'm 
not 100% sure what translation layer is used by flashfx, but it might be 
something I recognise.


dg@tao-group.com said:
>  BTW, anyone know how frequently the kernel syncs with the CVS tree? 

Rarely at the moment. I sync to Linus' kernel frequently, but I'm not
intending to send him anything more for 2.4. Once the 2.5 series starts, 
I'll be keeping it reasonably up-to-date. 

AnonCVS access is available. I recommend you use that.



--
dwmw2




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

Re: sbc-mediagx

[David Given]

[-- Attachment #1: Type: text/plain, Size: 1900 bytes --]

[...]
>Easy to fix - just that nobody's bothered yet. Patches accepted if you care 
>enough to produce one.

Sure --- I just don't know how. Ditto with the devfs stuff. I'll have a look 
at the rest of the kernel and see how easy/difficult it is. Getting this 
working would be a great bonus for us.

>dg@tao-group.com said:
>>  * The device claims to see only 8MB of my flash medium. 
>
>Odd. Please send the kernel's output while it's probing. How big _is_ the 
>flash?

16MB.

Enclosed, via the wonders of MIME, are the kernel output *and* the output of 
FXINFO.EXE, Datalight's official flash diagnostics program. Also, the ROM 
mutters something about x8 when booting, but it flashes past so quickly I've 
never been able to read anything else.

Having booted Windows and read the documentation, FlashFX seems to use an 
encoding called VBF. The only thing I want VBF for is to boot Linux; there's 
an int13 handler in ROM, so lilo would work. Other than that I'm sure JFFS on 
bare metal would do better.

sbc_mediagx.c seems to have hard-coded `partition' sizes in it. Does it 
override these later? The layout described by FXINFO doesn't match.

[...]
>Please could you bzip2 and send to me the contents of /dev/mtd[012]. I'm 
>not 100% sure what translation layer is used by flashfx, but it might be 
>something I recognise.

Sorry --- there's too much confidential stuff on the disk. I might be able to 
send you bits of it, though.

[...]
>Rarely at the moment. I sync to Linus' kernel frequently, but I'm not
>intending to send him anything more for 2.4. Once the 2.5 series starts, 
>I'll be keeping it reasonably up-to-date. 
>
>AnonCVS access is available. I recommend you use that.

I am, but it's difficult to point other people at. I'd also really like to 
compile this into the kernel, which is hard unless it's been integrated into 
the device tree.

David Given
dg@tao-group.com

[-- Attachment #2: fxinfo.txt --]
[-- Type: text/plain , Size: 1142 bytes --]


Disk Info - Displays information about a FlashFx disk
Datalight FlashFx 
V4.02.229  386 DOS
Copyright (c) 93-99
Patent US#5860082

OEM INFORMATION
  Media Type - - - - - - - - - - - - - NOR
  Media Size - - - - - - - - - - - - - 16384K
  Erase Zone Size  - - - - - - - - - - 128K
VBF INFORMATION
  Serial Number  - - - - - - - - - - - 38bf-4a68
  Partition Start (/P Option)  - - - - 256K
  Partition End (/T Option)  - - - - - 16384K
  Partition Size - - - - - - - - - - - 16128K
  Partition Total Units  - - - - - - - 126
  Partition Spare Units (/S Option)  - 1
  Region Size  - - - - - - - - - - - - 492K
  Logical Unit Size  - - - - - - - - - 128K
  Block Size - - - - - - - - - - - - - 512 bytes
  Formatted Size - - - - - - - - - - - 15375K
  VBF Overhead - - - - - - - - - - - - 753K
    Spare Unit(s)  - - - - - - - - - - 128K
    Allocation Map - - - - - - - - - - 187K
    Cushion (/Q Option)  - - - - - - - 437K (~3%)
MEDIA USAGE INFORMATION
  Erases Per Unit  (Max, Avg, Min) - - (399, 166, 18)
  Data Used  - - - - - - - - - - - - - 14979K
  Free Space - - - - - - - - - - - - - 161K
  Recoverable Space  - - - - - - - - - 672K

[-- Attachment #3: dmesg --]
[-- Type: application/octet-stream , Size: 1312 bytes --]

INIT_MTD:
SBC-MediaGX flash: IO:0x258-0x259 MEM:0xdc000-0xdffff
SBC-MediaGX flash: Found 2 x8 CFI devices at location 0 in 8 bit mode
Primary Vendor Command Set: 0001 (Intel/Sharp Extended)
Primary Algorithm Table at 0031
Alternative Vendor Command Set: 0000 (None)
No Alternate Algorithm Table
Vcc Minimum: 4.5 V
Vcc Maximum: 5.5 V
No Vpp line
Typical byte/word write timeout: 128 µs
Maximum byte/word write timeout: 2048 µs
Typical full buffer write timeout: 128 µs
Maximum full buffer write timeout: 2048 µs
Typical block erase timeout: 1024 µs
Maximum block erase timeout: 16384 µs
Chip erase not supported
Device size: 0x800000 bytes (8 Mb)
Flash Device Interface description: 0x0002
  - supports x8 and x16 via BYTE# with asynchronous interface
Max. bytes in buffer write: 0x20
Number of Erase Block Regions: 1
  Erase Region #0: BlockSize 0x20000 bytes, 64 blocks

searching for partitions
mtd: Giving out device 0 to SBC-MediaGX flash boot partition
SBC-MediaGX flash boot partition  Offset: 0x00000000  Size: 0x000a0000
mtd: Giving out device 1 to SBC-MediaGX flash partition 1
SBC-MediaGX flash partition 1  Offset: 0x000a0000  Size: 0x00160000
mtd: Giving out device 2 to SBC-MediaGX flash partition 2
SBC-MediaGX flash partition 2  Offset: 0x00200000  Size: 0x00600000

Re: sbc-mediagx

[David Given]

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

>[...]
>>Easy to fix - just that nobody's bothered yet. Patches accepted if you care 
>>enough to produce one.
>
>Sure --- I just don't know how. Ditto with the devfs stuff. I'll have a look 
>at the rest of the kernel and see how easy/difficult it is. Getting this 
>working would be a great bonus for us.

The enclosed patch should fix the MODVERSIONS problem. I think. It compiles but I haven't tested it. Apply to include/linux/mtd/map.h.

I would have thought that something like my MANGLE_FUNCTION() would already exist in the kernel, but apparently not...

David Given
dg@tao-group.com

[-- Attachment #2: patch --]
[-- Type: application/octet-stream , Size: 1075 bytes --]

Index: map.h
===================================================================
RCS file: /home/cvs/mtd/include/linux/mtd/map.h,v
retrieving revision 1.5
diff -r1.5 map.h
79a80,86
> /* We need to properly mangle the names of functions. */
> 
> #if defined(MODVERSIONS) || !defined(CONFIG_MODVERSIONS)
> #define MANGLE_FUNCTION(s) __MODULE_STRING(s)
> #else
> #define MANGLE_FUNCTION(s) __MODULE_STRING(__VERSIONED_SYMBOL(s))
> #endif
84,87c91,94
< #define do_cfi_probe(x) do_map_probe(x, "cfi_probe", "cfi_probe")
< #define do_jedec_probe(x) do_map_probe(x, "jedec_probe", "jedec_probe")
< #define do_ram_probe(x) do_map_probe(x, "map_ram_probe", "map_ram")
< #define do_rom_probe(x) do_map_probe(x, "map_rom_probe", "map_rom")
---
> #define do_cfi_probe(x) do_map_probe(x, MANGLE_FUNCTION(cfi_probe), "cfi_probe")
> #define do_jedec_probe(x) do_map_probe(x, MANGLE_FUNCTION(jedec_probe), "jedec_probe")
> #define do_ram_probe(x) do_map_probe(x, MANGLE_FUNCTION(map_ram_probe), "map_ram")
> #define do_rom_probe(x) do_map_probe(x, MANGLE_FUNCTION(map_rom_probe), "map_rom")

Re: sbc-mediagx

[David Given]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

[...]
>Sure --- I just don't know how. Ditto with the devfs stuff. I'll have a look 
>at the rest of the kernel and see how easy/difficult it is. Getting this 
>working would be a great bonus for us.

...and here is a patch to devfsify mtdchar. I even got a chance to test it, 
and the previous patch, and it all seems to work.

This is terribly terribly basic, as three-quarters of an hour ago I knew 
nothing about devfs. It creates entries for all fifteen possible devices, 
regardless of whether they exist or not. Interestingly, on my system, 0-5 
work, despite the fact that /proc/mtd claims that only 0-2 exist. Accessing 
the others returns a normal and harmless "No such device" error.

Block devices appear to be just as easy, but as it's 19:10 here in the UK and 
I'm still at work I'll do it tomorrow. What should I call it? /dev/mtd/b%d? 
/dev/mtd/block/%d? /dev/mtdblock/%d? /dev/mtd/fnord/%d?

David Given
dg@tao-group.com

[-- Attachment #2: patch --]
[-- Type: application/octet-stream , Size: 915 bytes --]

Index: mtdchar.c
===================================================================
RCS file: /home/cvs/mtd/kernel/mtdchar.c,v
retrieving revision 1.9
diff -r1.9 mtdchar.c
14a15,17
> #include <linux/devfs_fs_kernel.h>
> 
> static devfs_handle_t devfs_handle = NULL;
365c368
< 
---
> 	owner:		THIS_MODULE,
384,385c387,390
< 	
< 	if (register_chrdev(MTD_CHAR_MAJOR,"mtd",&mtd_fops)) {
---
> 	int i;
> 	char name[8];
> 
> 	if (devfs_register_chrdev(MTD_CHAR_MAJOR, "mtd", &mtd_fops)) {
390a396,406
> 	devfs_handle = devfs_mk_dir(NULL, "mtd", NULL);
> 
> 	for (i=0; i<MAX_MTD_DEVICES; i++)
> 	{
> 		sprintf(name, "%d", i);
> 		devfs_register(devfs_handle, name,
> 				DEVFS_FL_DEFAULT, MTD_CHAR_MAJOR, i,
> 				S_IFCHR | S_IRUGO | S_IWUGO,
> 				&mtd_fops, NULL);
> 	}
> 
396c412,413
< 	unregister_chrdev(MTD_CHAR_MAJOR,"mtd");
---
> 	devfs_unregister(devfs_handle);
> 	devfs_unregister_chrdev(MTD_CHAR_MAJOR, "mtd");

Re: sbc-mediagx

[David Woodhouse]

dg@tao-group.com said:
>  ...and here is a patch to devfsify mtdchar. I even got a chance to
> test it,  and the previous patch, and it all seems to work. 

Doesn't look like it'll work on 2.2 without devfs. I've littered it with 
appropriate (but ugly) ifdefs. We should probably put the devfs stuff into 
compatmac.h

I'd go for /dev/mtdblock/%d

It'd be nice if we could get it to create the device nodes only when 
devices are present.

--
dwmw2




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

Re: sbc-mediagx

[David Given]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

>Doesn't look like it'll work on 2.2 without devfs. I've littered it with 
>appropriate (but ugly) ifdefs. We should probably put the devfs stuff into 
>compatmac.h

Not sure this is a good idea; the actual logic is different, it's not just a 
matter of changing some of the function names.

>I'd go for /dev/mtdblock/%d

Is it wise to use different top-level directory names?

>It'd be nice if we could get it to create the device nodes only when 
>devices are present.

Done. (I've also integrated the devfs changes.) I'm not sure that this is the 
right way to test to see if a device exists, though.

David Given
dg@tao-group.com


[-- Attachment #2: patch --]
[-- Type: application/octet-stream , Size: 1310 bytes --]

Index: kernel/mtdchar.c
===================================================================
RCS file: /home/cvs/mtd/kernel/mtdchar.c,v
retrieving revision 1.9
diff -r1.9 mtdchar.c
14a15,17
> #include <linux/devfs_fs_kernel.h>
> 
> static devfs_handle_t devfs_handle = NULL;
365c368
< 
---
> 	owner:		THIS_MODULE,
384,385c387,392
< 	
< 	if (register_chrdev(MTD_CHAR_MAJOR,"mtd",&mtd_fops)) {
---
> #ifdef CONFIG_DEVFS_FS
> 	int i;
> 	char name[8];
> 
> 	if (devfs_register_chrdev(MTD_CHAR_MAJOR, "mtd", &mtd_fops))
> 	{
390a398,419
> 	devfs_handle = devfs_mk_dir(NULL, "mtd", NULL);
> 
> 	for (i=0; i<MAX_MTD_DEVICES; i++)
> 	{
> 		if (get_mtd_device(NULL, i))
> 		{
> 			sprintf(name, "%d", i);
> 			devfs_register(devfs_handle, name,
> 					DEVFS_FL_DEFAULT, MTD_CHAR_MAJOR, i,
> 					S_IFCHR | S_IRUGO | S_IWUGO,
> 					&mtd_fops, NULL);
> 		}
> 	}
> #else
> 	if (register_chrdev(MTD_CHAR_MAJOR, "mtd", &mtd_fops))
> 	{
> 		printk(KERN_NOTICE "Can't allocate major number %d for Memory Technology Devices.\n",
> 		       MTD_CHAR_MAJOR);
> 		return -EAGAIN;
> 	}
> #endif
> 
396c425,430
< 	unregister_chrdev(MTD_CHAR_MAJOR,"mtd");
---
> #ifdef CONFIG_DEVFS_FS
> 	devfs_unregister(devfs_handle);
> 	devfs_unregister_chrdev(MTD_CHAR_MAJOR, "mtd");
> #else
> 	unregister_chrdev(MTD_CHAR_MAJOR, "mtd");
> #endif

Re: sbc-mediagx

[David Given]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

[...]
>Done. (I've also integrated the devfs changes.) I'm not sure that this is the 
>right way to test to see if a device exists, though.

It's not. Don't touch that patch with a barge-pole, I forgot to 
put_mtd_device() after probing for each device.

The new patch fixes that and also fixes the device numbering; you now get 
/dev/mtd/{0,0ro,1,1ro,...} for the read-only devices. Suggestions on naming, 
please.

David Given
dg@tao-group.com

[-- Attachment #2: patch --]
[-- Type: application/octet-stream , Size: 1561 bytes --]

Index: kernel/mtdchar.c
===================================================================
RCS file: /home/cvs/mtd/kernel/mtdchar.c,v
retrieving revision 1.9
diff -r1.9 mtdchar.c
14a15,17
> #include <linux/devfs_fs_kernel.h>
> 
> static devfs_handle_t devfs_handle = NULL;
365c368
< 
---
> 	owner:		THIS_MODULE,
384,385c387,393
< 	
< 	if (register_chrdev(MTD_CHAR_MAJOR,"mtd",&mtd_fops)) {
---
> #ifdef CONFIG_DEVFS_FS
> 	int i;
> 	char name[8];
> 	struct mtd_info* mtd;
> 
> 	if (devfs_register_chrdev(MTD_CHAR_MAJOR, "mtd", &mtd_fops))
> 	{
390a399,428
> 	devfs_handle = devfs_mk_dir(NULL, "mtd", NULL);
> 
> 	for (i=0; i<MAX_MTD_DEVICES; i++)
> 	{
> 		mtd = get_mtd_device(NULL, i);
> 		if (mtd)
> 		{
> 			sprintf(name, "%d", i);
> 			devfs_register(devfs_handle, name,
> 					DEVFS_FL_DEFAULT, MTD_CHAR_MAJOR, i*2,
> 					S_IFCHR | S_IRUGO | S_IWUGO,
> 					&mtd_fops, NULL);
> 			sprintf(name, "%dro", i);
> 
> 			devfs_register(devfs_handle, name,
> 					DEVFS_FL_DEFAULT, MTD_CHAR_MAJOR, i*2+1,
> 					S_IFCHR | S_IRUGO | S_IWUGO,
> 					&mtd_fops, NULL);
> 			put_mtd_device(mtd);
> 		}
> 	}
> #else
> 	if (register_chrdev(MTD_CHAR_MAJOR, "mtd", &mtd_fops))
> 	{
> 		printk(KERN_NOTICE "Can't allocate major number %d for Memory Technology Devices.\n",
> 		       MTD_CHAR_MAJOR);
> 		return -EAGAIN;
> 	}
> #endif
> 
396c434,439
< 	unregister_chrdev(MTD_CHAR_MAJOR,"mtd");
---
> #ifdef CONFIG_DEVFS_FS
> 	devfs_unregister(devfs_handle);
> 	devfs_unregister_chrdev(MTD_CHAR_MAJOR, "mtd");
> #else
> 	unregister_chrdev(MTD_CHAR_MAJOR, "mtd");
> #endif

Re: sbc-mediagx

[David Vrabel]

David Woodhouse wrote:

> dg@tao-group.com said:
> >  * The device claims to see only 8MB of my flash medium.
> 
> Odd. Please send the kernel's output while it's probing. How big _is_ the
> flash?

Yeah. I know.  It's not finding the second chip since
chip_size*interleave=8Mibyte*2=16Mibyte

I could really do with a solution to this...

David Vrabel



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