sbc-mediagx

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

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

kernel syncs

[Alice Hennessy]

Hello,

This was asked in mid September:

>>  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.

Can you tell me when the last kernel sync was and when the next one is
planned?

Alice



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

Re: kernel syncs

[David Woodhouse]

On Thu, 26 Oct 2000, Alice Hennessy wrote:

> >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.
> 
> Can you tell me when the last kernel sync was and when the next one is
> planned?

As far as I know, the current code in CVS should work against
2.4.0-test10-pre5. So there's no sync required.

As I said, I'm not intending to send anything in the other direction until
2.5, with the exception of a handful of bugfixes.


-- 
dwmw2




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