block device for 2.0

block device for 2.0

[Erwin Authried]

I have now got all important modules running to
support ROM, CFI and RAM with uClinux. I have
used an old version of mtdblk.c (1.14) for block
access, for several reasons:
*The current driver uses kernel_thread. I don't know
  if/how that could be used in 2.0
* Caching is used. In uClinux, where RAM is valuable,
  RAM with the size of one erase sector would be wasted.
  With flashes that have 64KB or 128KB erase sectors,
  thats a lot of wasted memory.
* When the block driver is used as replacement for
  the blkmem.c ROM driver, caching isn't of any use at all.
  I think that will be the main (or the only?) purpose
  of the blockdriver in uClinux.

I thought it might be best to have the choice between the
old, uncached block block driver (for uClinux) or the new driver
as a configuration option. Are there any better ideas?

Regards,

Erwin




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

Re: block device for 2.0

[David Woodhouse]

On Thu, 16 Nov 2000, Erwin Authried wrote:

> I thought it might be best to have the choice between the
> old, uncached block block driver (for uClinux) or the new driver
> as a configuration option. Are there any better ideas?

Makes sense. How about having CONFIG_MTD_BLOCK and CONFIG_MTD_BLOCK_RW
just like we currently have for NFTL?

-- 
dwmw2




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

Re: block device for 2.0

[Nicolas Pitre]

On Thu, 16 Nov 2000, David Woodhouse wrote:

> On Thu, 16 Nov 2000, Erwin Authried wrote:
>
> > I thought it might be best to have the choice between the
> > old, uncached block block driver (for uClinux) or the new driver
> > as a configuration option. Are there any better ideas?
>
> Makes sense. How about having CONFIG_MTD_BLOCK and CONFIG_MTD_BLOCK_RW
> just like we currently have for NFTL?

Why not the other way around, i.e. CONFIG_MTD_BLOCK and CONFIG_MTD_BLOCK_RO?
The read-only one is more the "special case" than the read-write one...


Nicolas



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

Re: block device for 2.0

[David Woodhouse]

On Thu, 16 Nov 2000, Nicolas Pitre wrote:

> Why not the other way around, i.e. CONFIG_MTD_BLOCK and CONFIG_MTD_BLOCK_RO?
> The read-only one is more the "special case" than the read-write one...

Yep, fine. Erwin, feel free to commit this change if you want to.

-- 
dwmw2




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

Re: block device for 2.0

[Erwin Authried]

Nicolas Pitre[SMTP:nico@cam.org] wrote:
> 
> Why not the other way around, i.e. CONFIG_MTD_BLOCK and CONFIG_MTD_BLOCK_RO?
> The read-only one is more the "special case" than the read-write one...
> 
> 
> Nicolas
> 
Ok., I have modified it this way. I don't know in detail what kind of changes are planned
for module support, thus I'd like to know if it's ok. to modify cfi_probe.c to be able to
compile without module support before I commit that:

-Erwin


#ifdef CONFIG_MODULES
        sprintf(probename, "cfi_cmdset_%4.4X", type);
        probe_function = (void *)get_module_symbol(NULL, probename);
        if (!probe_function) {
                request_module(probename);

                probe_function = (void *)get_module_symbol(NULL, probename);
        }

        if (probe_function) {
                (*probe_function)(map, primary, base);
                put_module_symbol((unsigned long)probe_function);
                return;
        }
#else
        switch(type){
#ifdef CONFIG_MTD_CFI_INTELEXT
        case 0x0001:
                cfi_cmdset_0001(map,primary,base);
                return;
#endif
#ifdef CONFIG_MTD_CFI_AMDSTD
        case 0x0002:
                cfi_cmdset_0002(map,primary,base);
                return;
#endif
        }
#endif  /* CONFIG_MODULES */






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

Re: block device for 2.0

[David Woodhouse]

eauth@softsys.co.at said:
> Ok., I have modified it this way. I don't know in detail what kind of
> changes are planned for module support, thus I'd like to know if it's
> ok. to modify cfi_probe.c to be able to compile without module support
> before I commit that: 

I think we need to rewrite the part that load/calls the command set code.
It's fairly horrible. 

--
dwmw2




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