Flash Device Driver

Flash Device Driver

[kingseft]

 Hello,

 I found Flash Device driver related files in linux-2.4.3-pre3-2001-03-11
 I have Intel TE28F160B3(2MBytes, 16bit port size, bottom boot type) flash memory.

 Question1:
 Can I use my intel flash memory for your flash device driver?
 I got flash vendor id : CFI_VENDOR_INTEL_STANDARD
 so , I modified your code like this.
  } else if ((primary_vendor == CFI_VENDOR_INTEL_SHARP_EXTENDED) ||
           (primary_vendor == CFI_VENDOR_INTEL_STANDARD) ) {
 Is it possible ??

 Question2:
 when kernel booted, I found this messages.
 Found 1x16bit 2MBytes CFI Flash device of type Intel Standard at 0xFFE00000
 registered flash device /dev/flasha (minor 0, 4 partitions)
 and when I got shell prompt. I made like this.
 mknod /dev/flasha c 60 0
 mknod /dev/flasha1 c 60 1
 mknod /dev/flasha2 c 60 2
 mknod /dev/flaaha3 c 60 3
 mknod /dev/flasha4 c 60 4

 I tried like this.
 ls -al >> result.txt
 cat result.txt >> /dev/flasha4
 cat /dev/flasha4
 but I coudn't find my result.txt contents..
 Is it impossible??

 Questions3:
 I read your README but I had a question.
 Where can I find flash_erase ??
 W. Denx wrote flash_erase /dev/flasha start_addr end_addr
 Thanks for any comments and replyings...

 kingseft


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Stability of MontaVista's 2.4.0-test2-1.2.2-1

[Sébastien Côté]

Hi,

Did anyone have stability problem with MontaVista's kernel
2.4.0=test2-1.2.2-1 ???  I'm running  it on a board similar to Sandpoint
with a 7400 processor and sometimes it crashes because "current->mm ==
NULL" (from do_page_fault).

I'm not using any initrd but a shell (ash) instead.  This seems to
happen when I run a lot of programs in my script.  I also seems to be
related to a synchronisation problem since it gets a lot more stable
when I add "printk"s in the functions switch_mm and activate_mm.

This could also be related to the fact that I'm running in little-endian
but since it only crashes once in a while, I would doubt it!  So I'm a
bit suspicious about this test kernel, did anybody else have problems
with it??

Sébas..

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Stability of MontaVista's 2.4.0-test2-1.2.2-1

[Mark A. Greer]

That version of the kernel does have problems.  Get the latest linuxppc_2_5
source and try that.  I haven't tested the last couple weeks but before then,
it was very solid.  Sandpoint support is in it.

Mark
--

Sébastien Côté wrote:

> Hi,
>
> Did anyone have stability problem with MontaVista's kernel
> 2.4.0=test2-1.2.2-1 ???  I'm running  it on a board similar to Sandpoint
> with a 7400 processor and sometimes it crashes because "current->mm ==
> NULL" (from do_page_fault).
>
> I'm not using any initrd but a shell (ash) instead.  This seems to
> happen when I run a lot of programs in my script.  I also seems to be
> related to a synchronisation problem since it gets a lot more stable
> when I add "printk"s in the functions switch_mm and activate_mm.
>
> This could also be related to the fact that I'm running in little-endian
> but since it only crashes once in a while, I would doubt it!  So I'm a
> bit suspicious about this test kernel, did anybody else have problems
> with it??
>
> Sébas..
>

--
Mark A. Greer (mgreer@mvista.com; 480-517-0287)
MontaVista Software, Inc.
2141 E. Broadway Road, Suite 108
Tempe, AZ  85282


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Stability of MontaVista's 2.4.0-test2-1.2.2-1

[Alex Shnitman]

Hi, Mark!

On Wed, Mar 28, 2001 at 02:10:33PM -0700, you wrote the following:

> That version of the kernel does have problems.  Get the latest linuxppc_2_5
> source and try that.  I haven't tested the last couple weeks but before then,
> it was very solid.  Sandpoint support is in it.

I've just tried it. I downloaded the tree with bitkeeper, and applied
sp_patch_25, but got the following linking errors at the final stage
of the compilation:

arch/ppc/kernel/kernel.o: In function `lookup_partitions':
arch/ppc/kernel/kernel.o(.text+0x9046): undefined reference to `pmac_newworld'
arch/ppc/kernel/kernel.o(.text+0x904a): undefined reference to `pmac_newworld'
arch/ppc/kernel/kernel.o: In function `sandpoint_get_irq':
arch/ppc/kernel/kernel.o(.text+0x95fc): undefined reference to `openpic_irq'
arch/ppc/kernel/kernel.o(.text+0x95fc): relocation truncated to fit: R_PPC_REL24 openpic_irq
arch/ppc/kernel/kernel.o(.text+0x9620): undefined reference to `openpic_eoi'
arch/ppc/kernel/kernel.o(.text+0x9620): relocation truncated to fit: R_PPC_REL24 openpic_eoi
arch/ppc/kernel/kernel.o: In function `sandpoint_post_irq':
arch/ppc/kernel/kernel.o(.text+0x9670): undefined reference to `openpic_eoi'
arch/ppc/kernel/kernel.o(.text+0x9670): relocation truncated to fit: R_PPC_REL24 openpic_eoi
arch/ppc/kernel/kernel.o: In function `pmac_nvram_init':
arch/ppc/kernel/kernel.o(.text.init+0xd20): undefined reference to `find_devices'
arch/ppc/kernel/kernel.o(.text.init+0xd20): relocation truncated to fit: R_PPC_REL24 find_devices
arch/ppc/kernel/kernel.o(.text.init+0xd54): undefined reference to `device_is_compatible'
arch/ppc/kernel/kernel.o(.text.init+0xd54): relocation truncated to fit: R_PPC_REL24 device_is_compatible
arch/ppc/kernel/kernel.o(.text.init+0xe82): undefined reference to `sys_ctrler'
arch/ppc/kernel/kernel.o(.text.init+0xe86): undefined reference to `sys_ctrler'
drivers/video/video.o: In function `chips_init':
drivers/video/video.o(.text.init+0x2e48): undefined reference to `find_devices'
drivers/video/video.o(.text.init+0x2e48): relocation truncated to fit: R_PPC_REL24 find_devices
make: *** [vmlinux] Error 1


--
Alex Shnitman <alexsh@hectic.net>
http://alexsh.hectic.net/   UIN 188956
PGP 0xEC5D619D / E1 F2 7B 6C A0 31 80 28  63 B8 02 BA 65 C7 8B BA

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Stability of MontaVista's 2.4.0-test2-1.2.2-1

[Tom Rini]

On Thu, Mar 29, 2001 at 04:33:04PM +0200, Alex Shnitman wrote:
>
> Hi, Mark!
>
> On Wed, Mar 28, 2001 at 02:10:33PM -0700, you wrote the following:
>
> > That version of the kernel does have problems.  Get the latest linuxppc_2_5
> > source and try that.  I haven't tested the last couple weeks but before then,
> > it was very solid.  Sandpoint support is in it.
>
> I've just tried it. I downloaded the tree with bitkeeper, and applied
> sp_patch_25, but got the following linking errors at the final stage
> of the compilation:
[snip]

That's neat.  Can you privately email me the .config you used?

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Stability of MontaVista's 2.4.0-test2-1.2.2-1

[Sébastien Côté]

Alex Shnitman wrote:
> I've just tried it. I downloaded the tree with bitkeeper, and applied
> sp_patch_25, but got the following linking errors at the final stage
> of the compilation:
\x7f\x7f
I just downloaded 2_5 with Bitkeeper and I got the same problem.

Isn't there any daily snapshots located somewhere??  I can't download
using Bitkeeper from here because of the proxy.

Sébas..

P.S.: Here's the errors I get:
arch/ppc/kernel/kernel.o: In function `sandpoint_get_irq':
arch/ppc/kernel/kernel.o(.text+0x99b8): undefined reference to
`openpic_irq'
arch/ppc/kernel/kernel.o(.text+0x99b8): relocation truncated to fit:
R_PPC_REL24 openpic_irq
arch/ppc/kernel/kernel.o(.text+0x99dc): undefined reference to
`openpic_eoi'
arch/ppc/kernel/kernel.o(.text+0x99dc): relocation truncated to fit:
R_PPC_REL24 openpic_eoi
arch/ppc/kernel/kernel.o: In function `sandpoint_post_irq':
arch/ppc/kernel/kernel.o(.text+0x9a2c): undefined reference to
`openpic_eoi'
arch/ppc/kernel/kernel.o(.text+0x9a2c): relocation truncated to fit:
R_PPC_REL24 openpic_eoi
make: *** [vmlinux] Error 1

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Stability of MontaVista's 2.4.0-test2-1.2.2-1

[Mark A. Greer]

Sigh...  :(

Evidently, some [pmac-related] changes have gone in the last 2-3 weeks that have broken things.  I'll take a
look at it today or tomorrow.

If you can't wait, its probably not hard to fix.  Its likely nothing more than adding some stubs to
ppc_stubs.c

Mark
--

Alex Shnitman wrote:

> Hi, Mark!
>
> On Wed, Mar 28, 2001 at 02:10:33PM -0700, you wrote the following:
>
> > That version of the kernel does have problems.  Get the latest linuxppc_2_5
> > source and try that.  I haven't tested the last couple weeks but before then,
> > it was very solid.  Sandpoint support is in it.
>
> I've just tried it. I downloaded the tree with bitkeeper, and applied
> sp_patch_25, but got the following linking errors at the final stage
> of the compilation:
>
> arch/ppc/kernel/kernel.o: In function `lookup_partitions':
> arch/ppc/kernel/kernel.o(.text+0x9046): undefined reference to `pmac_newworld'
> arch/ppc/kernel/kernel.o(.text+0x904a): undefined reference to `pmac_newworld'
> arch/ppc/kernel/kernel.o: In function `sandpoint_get_irq':
> arch/ppc/kernel/kernel.o(.text+0x95fc): undefined reference to `openpic_irq'
> arch/ppc/kernel/kernel.o(.text+0x95fc): relocation truncated to fit: R_PPC_REL24 openpic_irq
> arch/ppc/kernel/kernel.o(.text+0x9620): undefined reference to `openpic_eoi'
> arch/ppc/kernel/kernel.o(.text+0x9620): relocation truncated to fit: R_PPC_REL24 openpic_eoi
> arch/ppc/kernel/kernel.o: In function `sandpoint_post_irq':
> arch/ppc/kernel/kernel.o(.text+0x9670): undefined reference to `openpic_eoi'
> arch/ppc/kernel/kernel.o(.text+0x9670): relocation truncated to fit: R_PPC_REL24 openpic_eoi
> arch/ppc/kernel/kernel.o: In function `pmac_nvram_init':
> arch/ppc/kernel/kernel.o(.text.init+0xd20): undefined reference to `find_devices'
> arch/ppc/kernel/kernel.o(.text.init+0xd20): relocation truncated to fit: R_PPC_REL24 find_devices
> arch/ppc/kernel/kernel.o(.text.init+0xd54): undefined reference to `device_is_compatible'
> arch/ppc/kernel/kernel.o(.text.init+0xd54): relocation truncated to fit: R_PPC_REL24 device_is_compatible
> arch/ppc/kernel/kernel.o(.text.init+0xe82): undefined reference to `sys_ctrler'
> arch/ppc/kernel/kernel.o(.text.init+0xe86): undefined reference to `sys_ctrler'
> drivers/video/video.o: In function `chips_init':
> drivers/video/video.o(.text.init+0x2e48): undefined reference to `find_devices'
> drivers/video/video.o(.text.init+0x2e48): relocation truncated to fit: R_PPC_REL24 find_devices
> make: *** [vmlinux] Error 1
>
> --
> Alex Shnitman <alexsh@hectic.net>
> http://alexsh.hectic.net/   UIN 188956
> PGP 0xEC5D619D / E1 F2 7B 6C A0 31 80 28  63 B8 02 BA 65 C7 8B BA
>

--
Mark A. Greer (mgreer@mvista.com; 480-517-0287)
MontaVista Software, Inc.
2141 E. Broadway Road, Suite 108
Tempe, AZ  85282


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Stability of MontaVista's 2.4.0-test2-1.2.2-1

[Mark A. Greer]

Someone "undid" the changes I put in open_pic.c that made openpic_irq() and
openpic_eoi() global (i.e., non-static).

To fix, just go in there & remove the "static" in the prototypes and on the
routines themselves.

BTW, to get a reasonable .config file, type "make sandpoint_config"

Mark
--

Sébastien Côté wrote:

> Alex Shnitman wrote:
> > I've just tried it. I downloaded the tree with bitkeeper, and applied
> > sp_patch_25, but got the following linking errors at the final stage
> > of the compilation:
> \x7f\x7f
> I just downloaded 2_5 with Bitkeeper and I got the same problem.
>
> Isn't there any daily snapshots located somewhere??  I can't download
> using Bitkeeper from here because of the proxy.
>
> Sébas..
>
> P.S.: Here's the errors I get:
> arch/ppc/kernel/kernel.o: In function `sandpoint_get_irq':
> arch/ppc/kernel/kernel.o(.text+0x99b8): undefined reference to
> `openpic_irq'
> arch/ppc/kernel/kernel.o(.text+0x99b8): relocation truncated to fit:
> R_PPC_REL24 openpic_irq
> arch/ppc/kernel/kernel.o(.text+0x99dc): undefined reference to
> `openpic_eoi'
> arch/ppc/kernel/kernel.o(.text+0x99dc): relocation truncated to fit:
> R_PPC_REL24 openpic_eoi
> arch/ppc/kernel/kernel.o: In function `sandpoint_post_irq':
> arch/ppc/kernel/kernel.o(.text+0x9a2c): undefined reference to
> `openpic_eoi'
> arch/ppc/kernel/kernel.o(.text+0x9a2c): relocation truncated to fit:
> R_PPC_REL24 openpic_eoi
> make: *** [vmlinux] Error 1
>

--
Mark A. Greer (mgreer@mvista.com; 480-517-0287)
MontaVista Software, Inc.
2141 E. Broadway Road, Suite 108
Tempe, AZ  85282

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Stability of MontaVista's 2.4.0-test2-1.2.2-1

[Alex Shnitman]

Hi, Mark!

On Thu, Mar 29, 2001 at 10:29:53AM -0700, you wrote the following:

> Evidently, some [pmac-related] changes have gone in the last 2-3
> weeks that have broken things.  I'll take a look at it today or
> tomorrow.
>
> If you can't wait, its probably not hard to fix.  Its likely nothing
> more than adding some stubs to ppc_stubs.c

At least one function (I don't remember which -- I'm not at work now
so I can't check) was declared static, while being called from other
files. These must be quite simple errors to fix. I haven't looked at
the other functions yet.


--
Alex Shnitman <alexsh@hectic.net>
http://alexsh.hectic.net/   UIN 188956
PGP 0xEC5D619D / E1 F2 7B 6C A0 31 80 28  63 B8 02 BA 65 C7 8B BA

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Stability of MontaVista's 2.4.0-test2-1.2.2-1

[Sébastien Côté]

On 2001.03.28 16:10:33 -0500 Mark A. Greer wrote:
>
> That version of the kernel does have problems.  Get the latest
> linuxppc_2_5
> source and try that.  I haven't tested the last couple weeks but before
> then,
> it was very solid.  Sandpoint support is in it.

I tried that new version and it's a bit more difficult to get running than
the one from MontaVista (remeber that I have a board -similar- to
Sandpoint).  The function time_init() was giving me problems so I decided
to take it out for the moment, but now I'm stuck in calibrate_delay()
(jiffies doesn't increase), so I guess it was a bad idea to take
time_init() out.

Anyway, I have another question.  In the header from
arch/ppc/kernel/sandpoint_setup.c,I see the following comment:
 * The firmware on the sandpoint is called DINK (not my acronym :).  This
port
 * depends on DINK to do some basic initialization (e.g., initialize the
memory
 * ctlr) and to ensure that the processor is using MAP B (CHRP map).

Since I don't really have a Sandpoint, and I don't have the DINK which
comes with it, I guess I will run into trouble.
Is there a place where I could find info on what I should do I exactly as
far as initialization goes?!?

Thanks,

Sébas..


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Stability of MontaVista's 2.4.0-test2-1.2.2-1

[Mark A. Greer]

Sébastien Côté wrote:

> On 2001.03.28 16:10:33 -0500 Mark A. Greer wrote:
> >
> > That version of the kernel does have problems.  Get the latest
> > linuxppc_2_5
> > source and try that.  I haven't tested the last couple weeks but before
> > then,
> > it was very solid.  Sandpoint support is in it.
>
> I tried that new version and it's a bit more difficult to get running than
> the one from MontaVista (remeber that I have a board -similar- to
> Sandpoint).  The function time_init() was giving me problems so I decided
> to take it out for the moment, but now I'm stuck in calibrate_delay()
> (jiffies doesn't increase), so I guess it was a bad idea to take
> time_init() out.

Hmmm, what sort of problems with time_init()?  Are you setting
ppc_md.time_init to todc_time_init and setting todc_info, etc correctly?  Is
your RTC a m48txx or mc146818?

If you find any bugs there, be sure to let me know.

> Anyway, I have another question.  In the header from
> arch/ppc/kernel/sandpoint_setup.c,I see the following comment:
>  * The firmware on the sandpoint is called DINK (not my acronym :).  This
> port
>  * depends on DINK to do some basic initialization (e.g., initialize the
> memory
>  * ctlr) and to ensure that the processor is using MAP B (CHRP map).
>
> Since I don't really have a Sandpoint, and I don't have the DINK which
> comes with it, I guess I will run into trouble.
> Is there a place where I could find info on what I should do I exactly as
> far as initialization goes?!?

No, I don't know of any place you can go that would tell you what you have to
init.  You could look at some of the open source firmwares that are out there
which should give you a good idea.  If you have a JTAG probe, you can put it
on a board similar to yours with known good firmware and look the host-bridge
regs, etc to how it sets everything up.  I dunno...

You will definitely need to have the PCI arbiter, power mgmt, memory
controller, and certain bits in HID0 and L2CR (if you have an L2 ctlr on your
processor) all set up correctly.  Maybe some board regs too.

Mark


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Stability of MontaVista's 2.4.0-test2-1.2.2-1

[Mark A. Greer]

Sébastien,

One more thing.  If your host bridge is an MPC107 or you're using an 8240 AND
the IDSEL line is hooked up on your hardware, you need to make sure that you
don't select the bridge itself when walking the PCI bus.  That is, when you scan
the PCI bus for devices, make sure you skip the device that would correspond to
your host bridge.

Make sense?

Mark


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: Stability of MontaVista's 2.4.0-test2-1.2.2-1

[Ron Bianco]

Check out:

http://www.mot.com/SPS/PowerPC/teksupport/tools/DINK32/VERSION12/dinkindex.htm

Most of DINK source code is easily downloadable, and the full source is obtainable thru a Motorola rep.
Not sure if that link is to the most current version.

Cheers, Ron

> -----Original Message-----

> > Anyway, I have another question.  In the header from
> > arch/ppc/kernel/sandpoint_setup.c,I see the following comment:
> >  * The firmware on the sandpoint is called DINK (not my acronym :).  This
> > port
> >  * depends on DINK to do some basic initialization (e.g., initialize the
> > memory
> >  * ctlr) and to ensure that the processor is using MAP B (CHRP map).
> >
> > Since I don't really have a Sandpoint, and I don't have the DINK which
> > comes with it, I guess I will run into trouble.
> > Is there a place where I could find info on what I should do I exactly as
> > far as initialization goes?!?
>
> No, I don't know of any place you can go that would tell you what you have to
> init.  You could look at some of the open source firmwares that are out there
> which should give you a good idea.  If you have a JTAG probe, you can put it
> on a board similar to yours with known good firmware and look the host-bridge
> regs, etc to how it sets everything up.  I dunno...
>
> You will definitely need to have the PCI arbiter, power mgmt, memory
> controller, and certain bits in HID0 and L2CR (if you have an L2 ctlr on your
> processor) all set up correctly.  Maybe some board regs too.
>
> Mark
>
>
>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/