RE: Ethernet driver for Linux kernel 2.6 running on ML403

RE: Ethernet driver for Linux kernel 2.6 running on ML403

[John Bonesio]

More comments below...

-----Original Message-----
From: linuxppc-embedded-bounces+jbonesio=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+jbonesio=3Dxilinx.com@ozlabs.org] On
Behalf Of Keith J Outwater
Sent: Thursday, September 14, 2006 11:36 AM
To: linuxppc-embedded@ozlabs.org
Subject: RE: Ethernet driver for Linux kernel 2.6 running on ML403

> Hi,
>=20
> I just saw this thread. The next version of EDK 8.2.2 will have a
temac
> v3.00a driver for linux 2.6. Our plan is to begin our code freeze
stage
> tomorrow. If people really need the driver right away, and can't wait
a
> few weeks for the release, I could possibly provide a patch (or use
some
> other distribution method) for the driver.
>=20
> Here at Xilinx, we have been in talks about having our drivers more
> readily available in the open source repositories. As far as I know,
> everyone seems to think that this would be a good thing for us. Right
> now the plan is to have a 3rd party check our drivers into the main
> repository as we have limited resources here. (Basically we're up to
our
> eyeballs in work right now.)

I know that MontaVista is you preferred Linux partner - if they do the
released, then we have to wait for them.  If individual designers can
get the driver sources, you can bet it will make it's way into the
mainline kernel.

>=20
> I do know that Xilinx would rather play a principle role in developing
> and maintaining these open source drivers, rather than having a
separate
> group go off and implement a separate set.

You may end up having to serve multiple customer bases then, to keep
things from forking.  The are lots of us who want to have lots of
fine-grained control over our source trees and the way in which we do=20
builds.

[John]
One thing that may help you, is that you can clear out the 'target_dir'
setting in xps. That will let you generate the BSP and then simply copy
over the files you need.

>=20
> << Same complaints apply for Xilinx drivers in the U-Boot bootloader.
> It is proving very difficult to get Xilinx code into U-Boot which
means
> BSPs that use the code are hard to get submitted as well.>>
>=20
> I've only touched on U-Boot a little bit. Have any thoughts on how to
> make this easier?

My perspective on this is that of a hardware designer who also develops
code.  I understand that is a good thing from the Xilinx point of view
to make it as easy as possible for designers to develop designs using
EDK with automatic BSP generation.  It's great for
doing stand alone (no OS) designs or to get "instant gratification"
as in "gee, I just booted Linux!" (a la Xilinx XAPP765).
When you do that, though, invariably
you end up having to make decisions that constrain how the design flow
works for the user and then it's hard for the user to deviate from that=20
flow.
For example, the idea of having a user auto-generate source code for a
BSP
that overwrites the bootloader or kernel source tree.  The problem
is that it's hard to "take the training wheels off" if I want or need
to have a stable source base of if I want to use the mainline kernel
or the mainline bootloader (U-Boot).  What if the source code bases
for the kernel or bootloader get re-arranged?

What I'd really like to have is "out of the box"
kernel support for all the
primary peripheral devices like communications and interface stuff
and U-Boot support for those devices as well.  I don't want to
have to generate BSPs and overwrite the source trees.

[John]
See my comment above.

The whole licensing thing is another issue.  As I stated to someone
else at Xilinx: These are just drivers, not the crown jewels. GPL it
all and make it easier for designers to incorporate the code into
open source projects.  Dual license if you have customers who have
to have things locked up.

[John]
I believe this is our intention going forward.

For U-Boot, I'm getting push-back from the maintainer on the
size and "verbosity" of the code.  Sounds like this might be an
issue for the kernel as well.

>=20
> << The Xilinx approach of overwriting the source tree just feels
wrong,
> and
> no one seems to want to do it that way.>>
>=20
> I am in the group that has control over how this is done. What would
you
> propose be done different? Keep in mind that we are trying to support
a
> process where someone builds a hardware design and the later changes
it
> with new peripherals or perhaps makes minor tweaks. We want to make
the
> updating of the Linux kernel to reflect these hardware changes easy
for
> people.

A noble goal, and clearly the right thing to do from a user-success
point
of view, but do the hardware peripherals (i.e. the IP cores) change that

much?
See my comment below: Can you create a system that allows software
drivers
to verify that they (the drivers) are compatible with a particular IP
version?  For the novice user, the "full auto" system probably works
fine, but for (some, at least) experienced users, it tends to be an
additional layer or complexity (or opacity) that would be nice to get
rid
of.

>=20
> Having the ability to make rapid hardware changes, I think, is a bit
> different from what most folks are used to.

I agree.  I think we all need to agree how best to manage the
driver code so that as IP versions change, the drivers can be properly
matched to the IP.  Also, as more and more people port Linux to their
Virtex designs, we can (hopefully) expect more "out of the box"
support for Xilinx hardware.  That's basically the situation you have
with more conventional peripheral devices.

[John]
Yep, we'd like this too.

I don't think that there are any "version" registers in the Xilinx=20
IP cores that a driver could check to determine compatibility.  That
would be very cheap to implement in hardware and you could then
develop more universal drivers.

[John]
We've examined doing this in the past, and gotten some push back due to
the use of bram or other resources. Conceptually, it's a great idea, I
just don't know if this is likely to happen any time soon.

>=20
> Cheers,
>=20
> - John
>=20
> -----Original Message-----
> From: linuxppc-embedded-bounces+jbonesio=3Dxilinx.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+jbonesio=3Dxilinx.com@ozlabs.org] On
> Behalf Of Keith J Outwater
> Sent: Thursday, September 14, 2006 9:48 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: Ethernet driver for Linux kernel 2.6 running on ML403
>=20
> Grant,
> You bring up excellent points, and I am having to deal with these
> issues in my 2.4.x kernel and U-Boot ports to VirtexII Pro FPGAs
> as well.
>=20
> > On 9/14/06, Michael Galassi <mgalassi@c-cor.com> wrote:
> > > It is also worth noting that as released in MVL pro 4.0.1 it only
> > > supports hard_temac 1.00.a and plb_temac 2.00.a, both of which are
> > > tagged as deprecated in the current version (8.2.01i) of Xilinx's
> > > EDK. The current version of {plb,hard}_temac (3.00.a) goes to
great
> > > lengths to break compatibility with older versions.  This will
> > > presumably be fixed next month when it is rumored that wonderful
new
> > > things will come from Xilinx.  In the mean-time it is possible,
> though
> > > neither simple, nor fun, to create Virtex4 designs with the older
> IP.
>=20
> I think the general case is that Xilinx IP will be constantly
evolving,=20
> and
> Xilinx driver code, when released under the GPL, will appear
> sporadically.
> Maybe it's best to resign ourselves to the fact that this situation
> probably won't change, and then try to deal with it in a way that does
> not depend so heavily on Xilinx drivers.
>=20
> >=20
> > So what direction do we (as the community) want to go for supporting
> > Xilinx IP in the Linux kernel?
>=20
> I don't know about anyone else, but running Linux on Virtex FPGAs is
> something I simply have to be able to do.  With or without Xilinx
> drivers, I think the kernel needs to support Xilinx hardware.
>=20
> >=20
> > IIRC, Xilinx intends to get drivers submitted into mainline.  (Based
> > on their cross-platform driver support code).  It is unknown which
and
> > how many drivers for different IP versions will be submitted.
>=20
> That's part of the problem: we seem to get support for some
> IP cores, but not all.  Xilinx takes a piecemeal approach
> to releasing drivers under the GPL.
>=20
> >=20
> > However, the xilinx driver code is verbose and does not match well
> > with the rest of the Linux code base.  (due to the cross platform
> > support)  Plus, the Xilinx tool work flow is geared towards the EDK
> > tool overwriting the driver code in the kernel tree with code for
the
> > generated design.  In which case, does it even make sense to accept
> > Xilinx drivers into the Linux tree when they are just going to get
> > overwritten by the toolchain anyway?  Unfortunately, regenerating
> > drivers has it's own problems considering that the license on the
> > generated code is not GPL compatible at the moment.
>=20
> Same complaints apply for Xilinx drivers in the U-Boot bootloader.
> It is proving very difficult to get Xilinx code into U-Boot which
means
> BSPs that use the code are hard to get submitted as well.
>=20
> The Xilinx approach of overwriting the source tree just feels wrong,
and
> no one seems to want to do it that way.
>=20
> >=20
> > If we reject the Xilinx driver code, then we either have to do
without
> > Xilinx support in mainline, or we need to write new drivers that
> > address the above issues (support multiple IP versions, etc).  The
> > Xilinx support in mainline right now does not use any Xilinx code.
> > (Xilinx PIC and UART).
> >=20
> > Thoughts?
>=20
> As painful as it may be, maybe we just write drivers from scratch and
> try to track changes in the IP.
>=20
> Regards,
> Keith Outwater
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20

_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: Ethernet driver for Linux kernel 2.6 running on ML403

[Keith J Outwater]

"John Bonesio" <john.bonesio@xilinx.com> wrote on 09/14/2006 10:52:16 AM:
<snip>
> 
> I don't think that there are any "version" registers in the Xilinx 
> IP cores that a driver could check to determine compatibility.  That
> would be very cheap to implement in hardware and you could then
> develop more universal drivers.
> 
> [John]
> We've examined doing this in the past, and gotten some push back due to
> the use of bram or other resources. Conceptually, it's a great idea, I
> just don't know if this is likely to happen any time soon.
> 

John,
I thinking in terms of something like a 32 bit register
(i.e. like a processor's PVR register) that has a hard-coded magic number
which a driver can read and decode to determine driver compatibility.
That does not sound resource-intensive given the size FPGAs we are talking
about.  Probably don't even need 32 bits.

Keith

Re: Ethernet driver for Linux kernel 2.6 running on ML403

[David H. Lynch Jr.]

John;

    My guess would be that as the whole xilinx drivers/edk stand, even 
with the virulent support of this list I would not bet on their being 
accepted upstream.

    Nothing in the Linux Kernel that I am aware of resembles them.
    There has been on ongoing holy war in LKML over getting reiser4 
accepted as experimental, one of the major issues being coding style. 
The style of reiser4
    is alot closer to Linux norms than the Xilinx EDK code.

    The current Xilinx approach is supposed to easily give us board 
support for varying IP's accross several platforms. I have been 
providing board support for
Pico Computing's Xilinx V4 based offerings for about a year, and I have 
been unable to take advantage of any of that. I have done board bringup 
for two OS's.
While I have been able to benefit from the work of other's on this list, 
and I have been able to occasionally use some code coming from Xilinx - 
mostly as  a reference,
I have two products supporting two operating systems, with a small 
collection of variable peripherals. None of this uses the Xilinx EDK. I 
deliberately postponed
work on the ethernet drivers in the hope they would be finished by the 
time I finished everything else. In the end I had to write my own.

I am not trying to bash Xilinx or Monta Vista. What I am questioning is 
whether the approach that Xilinx is currently using, aside from other 
problems, may actually run
counter to its goal.

If the Xilinx EDK could give us the support we need for the IP's we use. 
If it adapted easily between OS's, and IP versions. And if the code was 
as current as the IP's themselves.
Maybe the Xilinx EDK would be vindicated.

Certainly many of us would use it. While I happen to personally adhere 
to 98% of the Linux Style guidelines - I here many of my own views 
express ed in them, I am not a fanatic.
I am happy if my work improves Linux. But in the end I pay my mortgage 
and feed my family. I will use the resources that get the job done. 
Style is secondary.

But my honest expectation is that MV/Xilinx EDK support will always lag 
way behind what I am trying to do, and/or be incompatible with the goals 
and objectives of my clients.
For me the code coming from Xilinx/MV is most useful as a reference. I 
have ranted about mismatches between documentation and hardware - but 
that is not something new or specific
to Xilinx. What code has leaked out has proven useful - often after 
several days work turning it into something actually readable, as a 
reference - "Oh, that is how that bit really works"

I would be happy to be proven wrong - but I do not expect to be.






-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: Ethernet driver for Linux kernel 2.6 running on ML403

[David H. Lynch Jr.]

John;

    In a related rant. Why is it that there is so much meaningless 
variation in the IP's.

    I accept that there are reasons for sometimes mapping registers via 
dcr and in other IP's making them available directly.
    But why do the assorted bits in what is virtually the same register 
have to keep jumping all over the place ?

    As an example there are enormous similarities between the GEMAC that 
has a driver provided by GHS Integrity, and the
PLB FIFO TEMAC. It is almost possible to build the driver as either with 
just a different set of deffinitions - I spent two weeks
trying unsuccessfully to do just that.



-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

bsp for Linux kernel 2.6

[shenbagaraj]

Hi,
I ma working on Windriver powerquicc board 8260.where do i get the required
patches for linux 2.6.11.11.
regards,
shen

Linux not booting consistantly

[Jeff Stevens]

I have a custom AMCC 440SP board, with 1GB DDR2, and
32MB of flash.  I am having an issue with the linux
kernel, where I can get it to boot every once and a
while by power-cycling or pressing the reset button,
the rest of the time it hangs after uncompressing the
kernel:

## Booting image at 00200000 ...
   Image Name:   Linux-2.6.15
   Image Type:   PowerPC Linux Kernel Image (gzip
compressed)
   Data Size:    1067371 Bytes =  1 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

  Could this be a memory issue (i.e. bad memory
configuration)?  Though, if it were a memory issue,
wouldn't the kernel fail to uncompress successfully?
Does anyone have any ideas why it would work about
once every 10 - 20 resets?

Thanks,
   Jeff Stevens



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Linux not booting consistantly

[Stefan Roese]

Hi Jeff,

On Friday 22 September 2006 03:04, Jeff Stevens wrote:
> ## Booting image at 00200000 ...
>    Image Name:   Linux-2.6.15
>    Image Type:   PowerPC Linux Kernel Image (gzip
> compressed)
>    Data Size:    1067371 Bytes =  1 MB
>    Load Address: 00000000
>    Entry Point:  00000000
>    Verifying Checksum ... OK
>    Uncompressing Kernel Image ... OK
>
>   Could this be a memory issue (i.e. bad memory
> configuration)?  Though, if it were a memory issue,
> wouldn't the kernel fail to uncompress successfully?

No, not necessarily. U-Boot normally hasn't D-cache enabled on 440 platforms, 
so while uncompressing the kernel no bursts are generated to the SDRAM. And 
with the bursts the "real fun" begins. ;-)

So, yes: I also think you have a memory problem.

> Does anyone have any ideas why it would work about
> once every 10 - 20 resets?

Did you try to analyze where it crashes?

http://www.denx.de/wiki/view/DULG/LinuxPostMortemAnalysis

Best regards,
Stefan

Re: Linux not booting consistantly

[Jeff Stevens]

I have been working with the hardware guys trying to
find any issues with the memory, and we haven't seen
anything yet, and we have talked to AMCC, and they
said  they couldn't see anything wrong with the
hardware.  I did do a post-mordum dump of the log
buffer, and this is what I get:

001e40c4: 3c353e4c 696e7578 20766572 73696f6e   
<5>Linux version
001e40d4: 20322e36 2e313520 28726f6f 74406c6f    
2.6.15 (root@lo
001e40e4: 63616c68 6f73742e 6c6f6361 6c646f6d   
calhost.localdom
001e40f4: 61696e29 20286763 63207665 7273696f    ain)
(gcc versio
001e4104: 6e20342e 302e3020 2844454e 5820454c    n
4.0.0 (DENX EL
001e4114: 444b2034 2e302034 2e302e30 29292023    DK
4.0 4.0.0)) #
001e4124: 38205475 65205365 70203236 2031373a    8 Tue
Sep 26 17:
001e4134: 34393a31 33204544 54203230 30360a3c    49:13
EDT 2006.<
001e4144: 343e4a4a 533a2057 41532048 4552454a   
4>JJS: WAS HEREJ
001e4154: 4a53324a 4a53334a 4a53335f 314a4a53   
JS2JJS3JJS3_1JJS
001e4164: 345f4a4a 53345f31 5f4a4a53 345f325f   
4_JJS4_1_JJS4_2_
001e4174: 4a4a5334 5f335f4a 4a53345f 00000000   
JJS4_3_JJS4_....
001e4184: 00000000 00000000    ........

I placed a few printks in arch/ppc/kernel/start.c and
found that it crashed right after do_init_bootmem(),
right after placing the first character of "_JJS4_1".

        printk("JJS3");
        parse_early_param();
        printk("JJS3_1");
        for (i = 0; i < 1000000; i++)
        {
                if (i > 999999)
                {
                        break;
                }
        }

        printk("JJS4");
        /* set up the bootmem stuff with available
memory */
        do_init_bootmem();
        printk("_JJS4_1");
        if ( ppc_md.progress )
ppc_md.progress("setup_arch: bootmem", 0x3eab);
        printk("_JJS4_2");


When it does decide to work, most of the time it gets
through the whole kernel and everything runs fine,
though I have seen it hang after probing for PCI
devices a couple of times.  This looks like it is a
memory issue, but I don't know what else to try.  Does
anyone have any ideas?  I would appreciate any input.

Thanks,
   Jeff Stevens 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Linux not booting consistantly

[Muruga Ganapathy]

I would like to suggest to check the (quality of) clocks to memory
under  

a. normal condition ( before loading the linux)
b. during the linux booting

Usually the clock needs to be buffered if it needs to drive
more memory chips ( banks).

Another suggestion is to increase the cas latency to a higher 
value in the memory controller. ( say from 2 to 2.5 or to a higher
values.

Also there are configuration registers to introduce wait states to 
memory read and write cycles. So you may want to introduce more wait 
states by programming the memory controller register.

Thanks
G.Muruganandam



> I have been working with the hardware guys trying to
> find any issues with the memory, and we haven't seen
> anything yet, and we have talked to AMCC, and they
> said  they couldn't see anything wrong with the
> hardware.  I did do a post-mordum dump of the log
> buffer, and this is what I get:
> 
> 001e40c4: 3c353e4c 696e7578 20766572 73696f6e   
> <5>Linux version
> 001e40d4: 20322e36 2e313520 28726f6f 74406c6f    
> 2.6.15 (root@lo
> 001e40e4: 63616c68 6f73742e 6c6f6361 6c646f6d   
> calhost.localdom
> 001e40f4: 61696e29 20286763 63207665 7273696f    ain)
> (gcc versio
> 001e4104: 6e20342e 302e3020 2844454e 5820454c    n
> 4.0.0 (DENX EL
> 001e4114: 444b2034 2e302034 2e302e30 29292023    DK
> 4.0 4.0.0)) #
> 001e4124: 38205475 65205365 70203236 2031373a    8 Tue
> Sep 26 17:
> 001e4134: 34393a31 33204544 54203230 30360a3c    49:13
> EDT 2006.<
> 001e4144: 343e4a4a 533a2057 41532048 4552454a   
> 4>JJS: WAS HEREJ
> 001e4154: 4a53324a 4a53334a 4a53335f 314a4a53   
> JS2JJS3JJS3_1JJS
> 001e4164: 345f4a4a 53345f31 5f4a4a53 345f325f   
> 4_JJS4_1_JJS4_2_
> 001e4174: 4a4a5334 5f335f4a 4a53345f 00000000   
> JJS4_3_JJS4_....
> 001e4184: 00000000 00000000    ........
> 
> I placed a few printks in arch/ppc/kernel/start.c and
> found that it crashed right after do_init_bootmem(),
> right after placing the first character of "_JJS4_1".
> 
>         printk("JJS3");
>         parse_early_param();
>         printk("JJS3_1");
>         for (i = 0; i < 1000000; i++)
>         {
>                 if (i > 999999)
>                 {
>                         break;
>                 }
>         }
> 
>         printk("JJS4");
>         /* set up the bootmem stuff with available
> memory */
>         do_init_bootmem();
>         printk("_JJS4_1");
>         if ( ppc_md.progress )
> ppc_md.progress("setup_arch: bootmem", 0x3eab);
>         printk("_JJS4_2");
> 
> 
> When it does decide to work, most of the time it gets
> through the whole kernel and everything runs fine,
> though I have seen it hang after probing for PCI
> devices a couple of times.  This looks like it is a
> memory issue, but I don't know what else to try.  Does
> anyone have any ideas?  I would appreciate any input.
> 
> Thanks,
>    Jeff Stevens 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

*************************************************************
GDA Technologies, Inc.		
1010 Rincon Circle 
San Jose CA, 95131
Phone	(408) 432-3090
Fax	(408) 432-3091

Accelerate Your Innovation	
**************************************************************


=====
This message contains information from GDA Technologies Inc and 
affiliates, and is intended for the sole use of the individual and 
entity to whom it is addressed. It may contain information, including 
any attachments, that is privileged, confidential and exempt from 
disclosure under applicable law. If you are not the intended addressee, 
nor authorized to receive for the intended addressee, you are hereby 
notified that you may not use, copy, disclose or distribute to anyone 
the message or any information contained in the message. If you have 
received this electronic transmission in error, please notify the 
sender immediately by a "reply to sender only" message and destroy all 
electronic and hard copies of the communication, including attachments.
====

Re: Linux not booting consistantly

[Jeff Stevens]

Ok, my initial finding (that it was hanging after
do_init_bootmem) was incorrect.  I enabled the early
serial debug interface in the kernel, and it is
failing when initializing the PCI busses.  So I tried
typing "pci 0" in U-Boot, and I get
"pci_bus_to_hose(): failed" for busses 1 and 2 (0
returns fine).  If I comment out the board's pci_init
function, the kernel will boot every time, though it
crashes when it tries to probe the pci busses (as
expected).  So it seems to be an issue in my U-Boot
configuration or bootstrap settings.

Thanks for the help though!

--- Muruga Ganapathy <gmuruga@gdatech.com> wrote:

> 
> I would like to suggest to check the (quality of)
> clocks to memory
> under  
> 
> a. normal condition ( before loading the linux)
> b. during the linux booting
> 
> Usually the clock needs to be buffered if it needs
> to drive
> more memory chips ( banks).
> 
> Another suggestion is to increase the cas latency to
> a higher 
> value in the memory controller. ( say from 2 to 2.5
> or to a higher
> values.
> 
> Also there are configuration registers to introduce
> wait states to 
> memory read and write cycles. So you may want to
> introduce more wait 
> states by programming the memory controller
> register.
> 
> Thanks
> G.Muruganandam
> 
> 
> 
> > I have been working with the hardware guys trying
> to
> > find any issues with the memory, and we haven't
> seen
> > anything yet, and we have talked to AMCC, and they
> > said  they couldn't see anything wrong with the
> > hardware.  I did do a post-mordum dump of the log
> > buffer, and this is what I get:
> > 
> > 001e40c4: 3c353e4c 696e7578 20766572 73696f6e   
> > <5>Linux version
> > 001e40d4: 20322e36 2e313520 28726f6f 74406c6f    
> > 2.6.15 (root@lo
> > 001e40e4: 63616c68 6f73742e 6c6f6361 6c646f6d   
> > calhost.localdom
> > 001e40f4: 61696e29 20286763 63207665 7273696f   
> ain)
> > (gcc versio
> > 001e4104: 6e20342e 302e3020 2844454e 5820454c    n
> > 4.0.0 (DENX EL
> > 001e4114: 444b2034 2e302034 2e302e30 29292023   
> DK
> > 4.0 4.0.0)) #
> > 001e4124: 38205475 65205365 70203236 2031373a    8
> Tue
> > Sep 26 17:
> > 001e4134: 34393a31 33204544 54203230 30360a3c   
> 49:13
> > EDT 2006.<
> > 001e4144: 343e4a4a 533a2057 41532048 4552454a   
> > 4>JJS: WAS HEREJ
> > 001e4154: 4a53324a 4a53334a 4a53335f 314a4a53   
> > JS2JJS3JJS3_1JJS
> > 001e4164: 345f4a4a 53345f31 5f4a4a53 345f325f   
> > 4_JJS4_1_JJS4_2_
> > 001e4174: 4a4a5334 5f335f4a 4a53345f 00000000   
> > JJS4_3_JJS4_....
> > 001e4184: 00000000 00000000    ........
> > 
> > I placed a few printks in arch/ppc/kernel/start.c
> and
> > found that it crashed right after
> do_init_bootmem(),
> > right after placing the first character of
> "_JJS4_1".
> > 
> >         printk("JJS3");
> >         parse_early_param();
> >         printk("JJS3_1");
> >         for (i = 0; i < 1000000; i++)
> >         {
> >                 if (i > 999999)
> >                 {
> >                         break;
> >                 }
> >         }
> > 
> >         printk("JJS4");
> >         /* set up the bootmem stuff with available
> > memory */
> >         do_init_bootmem();
> >         printk("_JJS4_1");
> >         if ( ppc_md.progress )
> > ppc_md.progress("setup_arch: bootmem", 0x3eab);
> >         printk("_JJS4_2");
> > 
> > 
> > When it does decide to work, most of the time it
> gets
> > through the whole kernel and everything runs fine,
> > though I have seen it hang after probing for PCI
> > devices a couple of times.  This looks like it is
> a
> > memory issue, but I don't know what else to try. 
> Does
> > anyone have any ideas?  I would appreciate any
> input.
> > 
> > Thanks,
> >    Jeff Stevens 
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> > http://mail.yahoo.com 
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> >
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > 
> > 
> 
>
*************************************************************
> GDA Technologies, Inc.		
> 1010 Rincon Circle 
> San Jose CA, 95131
> Phone	(408) 432-3090
> Fax	(408) 432-3091
> 
> Accelerate Your Innovation	
>
**************************************************************
> 
> 
> =====
> This message contains information from GDA
> Technologies Inc and 
> affiliates, and is intended for the sole use of the
> individual and 
> entity to whom it is addressed. It may contain
> information, including 
> any attachments, that is privileged, confidential
> and exempt from 
> disclosure under applicable law. If you are not the
> intended addressee, 
> nor authorized to receive for the intended
> addressee, you are hereby 
> notified that you may not use, copy, disclose or
> distribute to anyone 
> the message or any information contained in the
> message. If you have 
> received this electronic transmission in error,
> please notify the 
> sender immediately by a "reply to sender only"
> message and destroy all 
> electronic and hard copies of the communication,
> including attachments.
> ====
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com