CFI detection of x16 chips in x8 mode

CFI detection of x16 chips in x8 mode

[David Vrabel]

Hi,

Just commited some new stuff to detect x16 CFI chips which are in x8
mode.  Arcom's SBC-MediaGX now works "out of the box".  I hope I didn't
break anything...

David Vrabel



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

Re: CFI detection of x16 chips in x8 mode

[David Given]

>Just commited some new stuff to detect x16 CFI chips which are in x8
>mode.  Arcom's SBC-MediaGX now works "out of the box".  I hope I didn't
>break anything...

Yup, it works. Thanks. What was the problem?

In other news, I devfsifed mtdblock, got it all working, and tried jffs with 
your new sbc_mediagx driver. It all worked. Beautifully. I'm *really* 
impressed --- the improvement over flashfx.o is unbelievable. It's fast and 
efficient and has yet to crash on me. It is a little slow to mount a new file 
system, but I can live with that.

How does jffs work? Erasing a single sector seems to take quite a while on 
this device. How does jffs manage to be so fast?

I believe it ought to be possible to persuade FlashFX to share a device with 
jffs. The way you'd do this is to use FXFMT to create a VBF volume that only 
uses, say, half the device. You'd then have to modify the partition table in 
sbc_mediagx.c to reflect this; you'd have three partitions: the boot partition 
(256kB); the VBF volume (8MB); and everything else (8MB). jffs would live in 
/dev/mtd/3. This ought to let you boot DOS on the VBF volume and then use LILO 
or loadlin to start Linux.

However, there has *got* to be some better way of handling partitions... the 
Arcom board seems to have a 256kB block at the beginning of the flash for ROM 
extensions, so it would make sense to have that as one partition. For the 
rest, it would seem logical that since FlashFX can find the VBF volume, so 
could we, and so we should be able to autodetect it. But does anyone know how?

(Next problem: how to get all this lot into the kernel so I can use a jffs 
partition as my root file system...)

David Given
dg@tao-group.com




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

Re: CFI detection of x16 chips in x8 mode

[David Woodhouse]

dg@tao-group.com said:
>  How does jffs work? Erasing a single sector seems to take quite a
> while on  this device. How does jffs manage to be so fast?

You don't have to make the user wait while you erase a sector. You can do 
it from a kernel thread in the background, and make sure you've always got 
some space available

You can also interrupt erases on some flash chips, and read from the
filesystem even while you're waiting from an erase. We don't do that yet, 
but it's close.

> I believe it ought to be possible to persuade FlashFX to share a
> device with  jffs. The way you'd do this is to use FXFMT to create a
> VBF volume that only  uses, say, half the device. You'd then have to
> modify the partition table in  sbc_mediagx.c to reflect this; you'd
> have three partitions: the boot partition  (256kB); the VBF volume
> (8MB); and everything else (8MB). jffs would live in  /dev/mtd/3. This
> ought to let you boot DOS on the VBF volume and then use LILO  or
> loadlin to start Linux.

Theoretically possible. Probably better to get it to boot off the JFFS 
directly though, if you can. It'd be nice if someone with the source to the 
flashfx stuff could release a version which works on MTD devices.

> However, there has *got* to be some better way of handling
> partitions... the  Arcom board seems to have a 256kB block at the
> beginning of the flash for ROM  extensions, so it would make sense to
> have that as one partition. For the  rest, it would seem logical that
> since FlashFX can find the VBF volume, so  could we, and so we should
> be able to autodetect it. But does anyone know how?

Not easy to do this in a generic manner, and deal with all possible schemes 
for splitting the devices up.


--
dwmw2




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

Re: CFI detection of x16 chips in x8 mode

[Kira Brown]

On Thu, 14 Sep 2000, David Woodhouse wrote:

> Theoretically possible. Probably better to get it to boot off the JFFS 
> directly though, if you can. It'd be nice if someone with the source to the 
> flashfx stuff could release a version which works on MTD devices.

Hm? Did someone call?

I'm thinking about makinf FlashFX support jffs, but I'm afraid it's a
Copious Free Time activity.

kira.



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

Re: CFI detection of x16 chips in x8 mode

[David Given]

[...]
>> I believe it ought to be possible to persuade FlashFX to share a
>> device with  jffs. The way you'd do this is to use FXFMT to create a
>> VBF volume that only  uses, say, half the device. You'd then have to
>> modify the partition table in  sbc_mediagx.c to reflect this; you'd
>> have three partitions: the boot partition  (256kB); the VBF volume
>> (8MB); and everything else (8MB). jffs would live in  /dev/mtd/3. This
>> ought to let you boot DOS on the VBF volume and then use LILO  or
>> loadlin to start Linux.
>
>Theoretically possible. Probably better to get it to boot off the JFFS 
>directly though, if you can. It'd be nice if someone with the source to the 
>flashfx stuff could release a version which works on MTD devices.

The problem with booting off JFFS is that until Linux has loaded, the only 
means of accessing the flash is via VBF... which doesn't understand JFFS. And 
once Linux has loaded, it doesn't understand VBF.

I've managed to get a dual-personality system up and running now. It boots 
ROM-DOS off the VBF partition; then I load Linux with loadlin, and it boots 
off the network. Once the modules are loaded I can access the JFFS partition.

Oh, yes. While playing, I changed the start and length of the JFFS partition. 
The new one still overlapped part of the old one. I mounted it without erasing 
it first... and my files were still visible. Is there any way to reduce the 
startup time when you first mount the file system?

What's ffs2?

>> However, there has *got* to be some better way of handling
>> partitions... the  Arcom board seems to have a 256kB block at the
>> beginning of the flash for ROM  extensions, so it would make sense to
>> have that as one partition. For the  rest, it would seem logical that
>> since FlashFX can find the VBF volume, so  could we, and so we should
>> be able to autodetect it. But does anyone know how?
>
>Not easy to do this in a generic manner, and deal with all possible schemes 
>for splitting the devices up.

For now, it would be sufficient for the sbc_mediagx chipset driver to allocate three partitions:

0: boot partition (0-256kB)
1: VBF volume (detected)
2: everything else

After all, flash devices aren't really large enough to warrant more complex partitioning schemes. If you really need them, then waiting until there's a proper VBF driver and creating PC partitions in it would do fine.

Anyone know how FlashFX finds the VBF volume?

David Given
dg@tao-group.com




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

RE: CFI detection of x16 chips in x8 mode

[Alex J Lennon]

> The problem with booting off JFFS is that until Linux has loaded, 
> the only 
> means of accessing the flash is via VBF... which doesn't 
> understand JFFS. And 
> once Linux has loaded, it doesn't understand VBF.
> I've managed to get a dual-personality system up and running now. 
> It boots 
> ROM-DOS off the VBF partition; then I load Linux with loadlin, 
> and it boots 
> off the network. Once the modules are loaded I can access the 
> JFFS partition.

A backwards step perhaps, but its entirely feasible to hook INT19h
and load the kernel out of flash directly - no need for filesystem 
support in the loader.

Alex



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