stdio.h and kernel space

stdio.h and kernel space

[Munira Ahmed]

I believe that stdio.h is used only in user space. If I am correct that
can anybody please tell me why lld.c, low level driver for AMD CFI
flash, contains stdio.h as header file?


-- 
Munira Ahmed

Re: stdio.h and kernel space

[Ralph Siemsen]

Munira Ahmed wrote:
> I believe that stdio.h is used only in user space. If I am correct that
> can anybody please tell me why lld.c, low level driver for AMD CFI
> flash, contains stdio.h as header file?

You are correct, stdio.h is for userspace.  However I do not see the 
file lld.c in any standard kernel tree, either version 2.4 or 2.6. 
Where did you get your kernel source from, which version is it, and what 
patches have been applied to it?

-R

Re: stdio.h and kernel space

[Munira Ahmed]

They are not part of the kernel. I downloaded then from AMD's website
and would like to know how to use them



On Mon, 2005-05-16 at 09:02 -0400, Ralph Siemsen wrote:
> Munira Ahmed wrote:
> > I believe that stdio.h is used only in user space. If I am correct that
> > can anybody please tell me why lld.c, low level driver for AMD CFI
> > flash, contains stdio.h as header file?
> 
> You are correct, stdio.h is for userspace.  However I do not see the 
> file lld.c in any standard kernel tree, either version 2.4 or 2.6. 
> Where did you get your kernel source from, which version is it, and what 
> patches have been applied to it?
> 
> -R
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 
-- 
Munira Ahmed
Senior Embedded Specialist

Radixs Pte Ltd
Email:munira.ahmed@radixs.com


Main: +65 6335 8600
Fax: +65 6335 8601
URL: www.radixs.com 

1 Temasek Avenue, #21-01, Millenia Tower, Singapore 039192

Disclaimer Notice: This email, its content and any files transmitted
with it are intended solely for the addressee(s) and may be confidential
and privileged. Any unauthorised disclosure or use or dissemination of
the information contained herein, either whole or partial, is
prohibited. Radixs Pte Ltd (Radixs) cannot accept liability for any
statements made which are clearly the sender's own and not expressly
made on behalf of Radixs or one of its agents. If you have received this
message in error, please notify the sender immediately, and delete this
email from your computer system. Radixs has taken reasonable precaution
to ensure no viruses are present in this email, however Radixs does not
accept responsibility for any loss or damage arising from the use of
this email or attachments.

Co. Reg. 200104892Z

Re: stdio.h and kernel space

[Ralph Siemsen]

Munira Ahmed wrote:
> They are not part of the kernel. I downloaded then from AMD's website
> and would like to know how to use them

Okay that explains why I didn't have them :)

There is a good chance that the MTD code in the linux kernel already 
supports whatever chip you have (not sure if you mentioned its type)... 
the CFI support is pretty solid.

-R

Re: stdio.h and kernel space

[Munira Ahmed]

S29WSxxxN. Does not seem to be supported



On Wed, 2005-05-18 at 18:24 -0400, Ralph Siemsen wrote:
> Munira Ahmed wrote:
> > They are not part of the kernel. I downloaded then from AMD's website
> > and would like to know how to use them
> 
> Okay that explains why I didn't have them :)
> 
> There is a good chance that the MTD code in the linux kernel already 
> supports whatever chip you have (not sure if you mentioned its type)... 
> the CFI support is pretty solid.
> 
> -R
> 
-- 
Munira Ahmed

Re: stdio.h and kernel space

[Ralph Siemsen]

Munira Ahmed wrote:
> S29WSxxxN. Does not seem to be supported

According to datasheet the programming sequence looks rather like the 
JEDEC standard method found in drivers/mtd/chips/jedec_probe.c, 
particularly the jedec_reset() function matches the code shown on page 
28 of the datasheet.

Datasheet i'm looking at is 
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/s29ws-n_00_g0_e.pdf 
hopefully this is the right one ;)

So the standard driver might just need an extra entry for vendor/device 
codes.  Maybe ;)

-R

Re: stdio.h and kernel space

[Munira Ahmed]

Hi Ralph

The datasheet you are referring to is the right one and S29WSxxxN is
using JEDEC 42.4 command set standard.

I am not sure which JEDEC standard is impelmented by jedec_prob.c.

Further if a separate driver is provided on AMD's website it must
significantly be different otherwise they could simply have mentioned
about the one in jedec_probe.c

I believe that S29WSxxxN's MirrirBit technology provides many more
security features as yet not available in other flash technologies.


Recently they have sent me even a new version so now I have to study
that one and see how could that one be used.

Thanks for taking the trouble of going through the specs and the kernel
as well.

It really amazes me how keen people are to help each other.
I have got many problems solved by the wonderful community help.

Regards and thanks to all



On Thu, 2005-05-19 at 07:47 -0400, Ralph Siemsen wrote:
> Munira Ahmed wrote:
> > S29WSxxxN. Does not seem to be supported
> 
> According to datasheet the programming sequence looks rather like the 
> JEDEC standard method found in drivers/mtd/chips/jedec_probe.c, 
> particularly the jedec_reset() function matches the code shown on page 
> 28 of the datasheet.
> 
> Datasheet i'm looking at is 
> http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/s29ws-n_00_g0_e.pdf 
> hopefully this is the right one ;)
> 
> So the standard driver might just need an extra entry for vendor/device 
> codes.  Maybe ;)
> 
> -R
> 
-- 
Munira Ahmed

Re: stdio.h and kernel space

[Eric W. Biederman]

Munira Ahmed <munira.ahmed@radixs.com> writes:

> Hi Ralph
> 
> The datasheet you are referring to is the right one and S29WSxxxN is
> using JEDEC 42.4 command set standard.
> 
> I am not sure which JEDEC standard is impelmented by jedec_prob.c.
> 
> Further if a separate driver is provided on AMD's website it must
> significantly be different otherwise they could simply have mentioned
> about the one in jedec_probe.c

jedec_probe is not a ``driver'' it is a method of identify the kind
of device you have.  Like a pci bus scan just a little less reliable.
Unless something is very strange it is almost certain either jedec_probe
or cfi_probe will be able to recognize the id on your part, and direct
the mtd code to the appropriate driver.  Which is almost certainly
cfi_cmdset_0002.c.  If the command set really is different or provides
significant new features writing a new chip driver may be in order.

> I believe that S29WSxxxN's MirrirBit technology provides many more
> security features as yet not available in other flash technologies.

Possibly.  Although I don't quite see how more silicon to audit translates
into more security.  In any event audit the code I have mentioned and see
if it appears to be doing the correct thing for your chip.  

Eric

Re: stdio.h and kernel space

[Munira Ahmed]

Hang on

I am confused now

cfi_cmdset_0002.c implements CFI or a flash driver?

What I understand from is that

there is one cfi command set just to find out which chip is being used
and what driver to use.

The other one is the software command set to tell the flash what to
do.This command set would essentially constitute the driver.

earlier there used to be a JEDEC standard before CFI came in vogue. It
used to do the same thing which is now done by CFI albeit in some old
fashioned or may be in not so efficient way. there must be something
missing in there that's why it is getting out of use. jedec_probe.c 
if I am not wrong implements this standard which is almost obsolete.

Now this S29WSxxxN is CFI compliant and uses a software command set
called JEDEC 42.4 standard to instruct the flash. So  CFI in the kernel
should be able to identify that which chip is used. 

No which file in the kernel implements CFI?

how to tell this CFI to use a new driver?

which file if any in the kerenl implements JEDEC 42.2 command set to
instruct a flash?



Please clearify



On Thu, 2005-05-19 at 21:16 -0600, Eric W. Biederman wrote:
> Munira Ahmed <munira.ahmed@radixs.com> writes:
> 
> > Hi Ralph
> > 
> > The datasheet you are referring to is the right one and S29WSxxxN is
> > using JEDEC 42.4 command set standard.
> > 
> > I am not sure which JEDEC standard is impelmented by jedec_prob.c.
> > 
> > Further if a separate driver is provided on AMD's website it must
> > significantly be different otherwise they could simply have mentioned
> > about the one in jedec_probe.c
> 
> jedec_probe is not a ``driver'' it is a method of identify the kind
> of device you have.  Like a pci bus scan just a little less reliable.
> Unless something is very strange it is almost certain either jedec_probe
> or cfi_probe will be able to recognize the id on your part, and direct
> the mtd code to the appropriate driver.  Which is almost certainly
> cfi_cmdset_0002.c.  If the command set really is different or provides
> significant new features writing a new chip driver may be in order.
> 
> > I believe that S29WSxxxN's MirrirBit technology provides many more
> > security features as yet not available in other flash technologies.
> 
> Possibly.  Although I don't quite see how more silicon to audit translates
> into more security.  In any event audit the code I have mentioned and see
> if it appears to be doing the correct thing for your chip.  
> 
> Eric
> 
-- 
Munira Ahmed

Re: stdio.h and kernel space

[Eric W. Biederman]

Munira Ahmed <munira.ahmed@radixs.com> writes:

> Hang on
> 
> I am confused now
> 
> cfi_cmdset_0002.c implements CFI or a flash driver?

Breaking things down a little more, in the mtd stack there are 3 kinds of drivers.
map drivers that describe how to talk to a given flash chip.
probe drivers that identify what kind of chip you have.
chip drivers that know how to speak a command set and let you flash your chip.

> What I understand from is that
> 
> there is one cfi command set just to find out which chip is being used
> and what driver to use.

There is a probe driver.  Not a really a command set, but you have
the idea.

There are two JEDEC standard probe methods the original
which simply gives vendor/device id bytes.  And the CFI
probe which gives you a little more and means you don't need
a table of devices.
 
> The other one is the software command set to tell the flash what to
> do.This command set would essentially constitute the driver.

Yes.
 
> earlier there used to be a JEDEC standard before CFI came in vogue. It
> used to do the same thing which is now done by CFI albeit in some old
> fashioned or may be in not so efficient way. there must be something
> missing in there that's why it is getting out of use. jedec_probe.c 
> if I am not wrong implements this standard which is almost obsolete.

The CFI standard seems to be a reaction to the observation that the largest
part of a flash driver that supports multiple chips is the lookup table
by vendor/device that reports the commands set and chip size.  After
that everything tends to use either the intel (cfi_cmdset_0001) or the 
amd (cfi_cmdset_0002) command set.

It really depends on which market segment you are in which probe methods
are supported.  In addition most CFI chips also support the older style
jedec probe as well.

> Now this S29WSxxxN is CFI compliant and uses a software command set
> called JEDEC 42.4 standard to instruct the flash. So  CFI in the kernel
> should be able to identify that which chip is used. 
> 
> No which file in the kernel implements CFI?

cfi_probe.

> how to tell this CFI to use a new driver?

cfi_probe should run on the chip find it and then complain that
it can't find some property.  So as long as you have an appropriate
map driver that calls cfi_probe you should be 90% of the way there
and the error messages should be able to guide you in.
 
> which file if any in the kerenl implements JEDEC 42.2 command set to
> instruct a flash?

JEDEC 42.2 is not a clear reference to me, but I do know that JEDEC has
a standard command set that is very similar to what AMD uses.  CFI
enumerates several known commands sets.  Which enumeration value does
it describe your command set with.  My hunch is that the CFI probe
data returns the value 0002.    Once you know which value the
CFI probe data returns then we can talk about adding code.

Eric

Re: stdio.h and kernel space

[Munira Ahmed]

which module in the kernel calls cfi_probe driver to get the chip
details.

when I do probe with a device with intel flash using

mtdptr = do_map_probe("cfi_probe", mapptr);



this is what I get

genprobe_new_chip called with unsupported buswidth 0
CFI: Found no <NULL> device at location zero
 

and mtdptr is returned NULL 

what does it signify?

?



On Thu, 2005-05-19 at 23:00 -0600, Eric W. Biederman wrote:
> Munira Ahmed <munira.ahmed@radixs.com> writes:
> 
> > Hang on
> > 
> > I am confused now
> > 
> > cfi_cmdset_0002.c implements CFI or a flash driver?
> 
> Breaking things down a little more, in the mtd stack there are 3 kinds of drivers.
> map drivers that describe how to talk to a given flash chip.
> probe drivers that identify what kind of chip you have.
> chip drivers that know how to speak a command set and let you flash your chip.
> 
> > What I understand from is that
> > 
> > there is one cfi command set just to find out which chip is being used
> > and what driver to use.
> 
> There is a probe driver.  Not a really a command set, but you have
> the idea.
> 
> There are two JEDEC standard probe methods the original
> which simply gives vendor/device id bytes.  And the CFI
> probe which gives you a little more and means you don't need
> a table of devices.
>  
> > The other one is the software command set to tell the flash what to
> > do.This command set would essentially constitute the driver.
> 
> Yes.
>  
> > earlier there used to be a JEDEC standard before CFI came in vogue. It
> > used to do the same thing which is now done by CFI albeit in some old
> > fashioned or may be in not so efficient way. there must be something
> > missing in there that's why it is getting out of use. jedec_probe.c 
> > if I am not wrong implements this standard which is almost obsolete.
> 
> The CFI standard seems to be a reaction to the observation that the largest
> part of a flash driver that supports multiple chips is the lookup table
> by vendor/device that reports the commands set and chip size.  After
> that everything tends to use either the intel (cfi_cmdset_0001) or the 
> amd (cfi_cmdset_0002) command set.
> 
> It really depends on which market segment you are in which probe methods
> are supported.  In addition most CFI chips also support the older style
> jedec probe as well.
> 
> > Now this S29WSxxxN is CFI compliant and uses a software command set
> > called JEDEC 42.4 standard to instruct the flash. So  CFI in the kernel
> > should be able to identify that which chip is used. 
> > 
> > No which file in the kernel implements CFI?
> 
> cfi_probe.
> 
> > how to tell this CFI to use a new driver?
> 
> cfi_probe should run on the chip find it and then complain that
> it can't find some property.  So as long as you have an appropriate
> map driver that calls cfi_probe you should be 90% of the way there
> and the error messages should be able to guide you in.
>  
> > which file if any in the kerenl implements JEDEC 42.2 command set to
> > instruct a flash?
> 
> JEDEC 42.2 is not a clear reference to me, but I do know that JEDEC has
> a standard command set that is very similar to what AMD uses.  CFI
> enumerates several known commands sets.  Which enumeration value does
> it describe your command set with.  My hunch is that the CFI probe
> data returns the value 0002.    Once you know which value the
> CFI probe data returns then we can talk about adding code.
> 
> Eric
> 
-- 
Munira Ahmed
Senior Embedded Specialist

Radixs Pte Ltd
Email:munira.ahmed@radixs.com


Main: +65 6335 8600
Fax: +65 6335 8601
URL: www.radixs.com 

1 Temasek Avenue, #21-01, Millenia Tower, Singapore 039192

Disclaimer Notice: This email, its content and any files transmitted
with it are intended solely for the addressee(s) and may be confidential
and privileged. Any unauthorised disclosure or use or dissemination of
the information contained herein, either whole or partial, is
prohibited. Radixs Pte Ltd (Radixs) cannot accept liability for any
statements made which are clearly the sender's own and not expressly
made on behalf of Radixs or one of its agents. If you have received this
message in error, please notify the sender immediately, and delete this
email from your computer system. Radixs has taken reasonable precaution
to ensure no viruses are present in this email, however Radixs does not
accept responsibility for any loss or damage arising from the use of
this email or attachments.

Co. Reg. 200104892Z