Re: Config.in

Re: Config.in

[Michael Elizabeth Chastain]

I introduced define_tristate in the 2.3 series.

I am not following the MTD discussion, but I gather the idea is to use
the same Config.in files for both 2.2 and 2.3.  If you need to do that,
I suppose you can use define_bool and get away with it.

define_tristate exists in order to help tighten up the type system in
Config Language.  The idea is to improve the tools so that they can give
warnings and errors about things like "this variable is a boolean in
one place and a tristate in another".  If this ever actually happens,
I hope that drivers/mtd/Config.in can be edited at that time to conform.

Just some historical two cent's worth from an old has-been.  :)

Michael


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

Re: Config.in

[David Woodhouse]

mec@shout.net said:
>  I am not following the MTD discussion, but I gather the idea is to
> use the same Config.in files for both 2.2 and 2.3.  If you need to do
> that, I suppose you can use define_bool and get away with it. 

Ok. I'll leave Linus with define_tristate for now and change my copy back 
to define_bool. Hopefully I won't accidentally flush that change back to 
Linus.

Thanks.

--
dwmw2




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

Re: mtd devices & jffs

[David Woodhouse]

kayemmess@yahoo.ca said:
> Is this possible?  Looking through the JFFS code, they hardcode the
> start address for their scan at 0x0 and get the end addr based on the
> size of the total flash.  Is there a way to tell JFFS "start at this
> addr and only use this much space" without changing this code? 

Give it an MTD device which points at only the range you want it to use.
See how nora.c splits up the flash chips into four 'partitions'.



--
dwmw2




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

Re: mtd devices & jffs

[Juan Gonzo]

I guess the problem I am going to run into is that I don't
want to erase all of the flash, nor do I want JFFS to use
all of the flash.  Part of the flash will have a kernel
image burned into, and another part is being used for config
data etc.  And then the filesystem is supposed to have its
chunk of flash to use.

Is this possible?  Looking through the JFFS code, they hardcode
the start address for their scan at 0x0 and get the end addr
based on the size of the total flash.  Is there a way to tell
JFFS "start at this addr and only use this much space" without
changing this code?

Thanks,
   -- kelly


--- David Woodhouse <dwmw2@infradead.org> wrote:
> 
> kayemmess@yahoo.ca said:
> > Dirty flash memory or bad inode: hexdump(pos = 0x1098176, len =
> 128):
> 
> Looks like there were data on the flash chips before you started.
> Erase 
> them first. There's no utility to erase whole devices, but the
> 'erase' 
> program in the util/ directory will erase a single erase block at a
> time.
> 
>  for a in `seq 0 131072 16777216` ; do mtd/util/erase /dev/mtd0 $a ;
> done
> 
> ....or put a loop into the erase program. The MTDGETINFO ioctl should
> return 
> the size of the device.
> 
> 
> --
> dwmw2
> 
> 
> 
> 
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org


_______________________________________________________
Do You Yahoo!?
Get your free @yahoo.ca address at http://mail.yahoo.ca


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

Re: mtd devices & jffs

[David Woodhouse]

dwmw2@infradead.org said:
> > Is there a way to tell JFFS "start at this
> > addr and only use this much space" without changing this code? 

> Give it an MTD device which points at only the range you want it to
> use. See how nora.c splits up the flash chips into four 'partitions'. 

I just committed 'pnc2000.c' which should be clearer. Look at that instead.

--
dwmw2




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

Config.in

[Sébastien Côté]

Running make xconfig on 2.2.15, I get the following
drivers/mtd/Config.in: 14: unknown command

However, make menuconfig doesn't generate any error.  I'm not a kernel
config specialist so I don't know if define_tristate was introduced in
2.3 or why in doesn't work only with xconfig, but this is definitly a
bug of some sort.


-- 
Sébastien Côté


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

Re: Config.in

[David Woodhouse]

Hmmm. Talk to David and Michael.

scote1@matrox.com said:
> Running make xconfig on 2.2.15, I get the following
> drivers/mtd/Config.in: 14: unknown command

> However, make menuconfig doesn't generate any error.  I'm not a kernel
> config specialist so I don't know if define_tristate was introduced in
> 2.3 or why in doesn't work only with xconfig, but this is definitly a
> bug of some sort. 



--
dwmw2




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

Re: Config.in

[Sébastien Côté]

David Woodhouse wrote:
> 
> Hmmm. Talk to David and Michael.
> 
> scote1@matrox.com said:
> > Running make xconfig on 2.2.15, I get the following
> > drivers/mtd/Config.in: 14: unknown command
> 
> > However, make menuconfig doesn't generate any error.  I'm not a kernel
> > config specialist so I don't know if define_tristate was introduced in
> > 2.3 or why in doesn't work only with xconfig, but this is definitly a
> > bug of some sort.

Another thing I just noticed is that the links in linux/modules are
wrong for MTD.  They point to linux/Lost/mtd*.  But the link for jffs.o
is correct! I didn't notice this before because I linked all my JFFS and
MTD stuff directly in /lib/modules/...  I didn't use the patch to
install MTD so maybe I did something wrong but where does the kernel
look to make these links ?

-- 
Sébastien Côté


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