How to debug the linux kernel?

How to debug the linux kernel?

[Gong Zhuo]

Hi:
  If I want to change the kernel of linux , how can I debug the kernel ? Any
kind of tools can I use? Any URL I can read?

Gong Zhuo


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

Re: How to debug the linux kernel?

[Murray Jensen]

On Fri, 7 Jul 2000 17:01:46 +0800, "Gong Zhuo" <gongzhuo@163.net> writes:
>
>Hi:
>  If I want to change the kernel of linux , how can I debug the kernel ? Any
>kind of tools can I use? Any URL I can read?
>
>Gong Zhuo

The best way is to use kgdb. Hunt around on the archives for this list, or
look at the HOWTOs, for pointers on how to do this. Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing Sci & Tech,         Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen@cmst.csiro.au  (old address was mjj@mlb.dmt.csiro.au)

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

Re: How to debug the linux kernel?

[Tom Roberts]

Gong Zhuo wrote:
>   If I want to change the kernel of linux , how can I debug the kernel ? Any
> kind of tools can I use?

This may be a different problem than what you are asking about. THis
is how I got Linux working on our proprietary PowerPC board.

I had the problem that initially I had _NO_ I/O devices whatsoever;
the only thing I could do was read and write on-board memory from
the host (my system is a PCI board which plugs into a PC running
Linux). So I could load the Linux kernel and an initrd image, and
start it executing. I of course wrote a serial I/O and console
driver with corresponding host-side driver, but they were undebugged
also....

I mocked-up versions of my console driver using the proprietary OS
we currently run on this board, and debugged both the console driver
and its host-side counterpart (along with the program and driver
used to download programs and boot the board). This covered ~95% of
that code. Then I compiled the driver into the Linux kernel and
started on that.

	This was the key step, IMHO -- without a known-working
	console driver it would be VERY difficult to know when
	Linux got to the point of doing a printk().

Initially I had to get the Linux kernel to thread its way through
head.S, even though none of the configuration options correspond
at all to my hardware (so I created a CONFIG_LSPS....). This is well
before any printk() can work, of course. So I grep-ed head.S and
found two registers which were essentially unused, and set one to 0
as the first instruction of head.S. Then to trace the execution
through head.S I loaded the other with some unique constant and did
a stwu using the other one -- this overwrites the initial few words
of head.S with markers which essentially told me "I got here"; I
could dump memory from the host and see where it got. It took me
about four days of this until a printk() came out [half of that was
due to hardware problems unrelated to Linux -- I had unknowingly
used an early-revision of our board on which multi-beat memory
transactions did not work -- enabling the cache killed the program;
switching to a working board solved it]. Once the first printk()
appeared, in a few hours I had a bash prompt from the initrd image.

Then I wrote a network driver for the board and a corresponding
driver for the host. With printk() working this took me about
a week to get the first ping of the board, and another few days
to mount the root via NFS. I then built up a full root image from
the Suse PowerPC distribution beta CDROM I got as a door prize. I
now have 4 boards all running Linux quite well, including native
compilers.

	Note that this is the first point at which using gdb or
	some other debugging program would have worked for me.
	All the hard work came long before any such program could
	possibly be used....

All-in-all I spent about a month from the time I started seriously
to get Linux up on the board until I had it working reasonably
well. As you can tell, my method relied heavily on my experience
in writing and implementing our proprietary OS, and on my knowledge
and abilities as a low-level PowerPC assembly programmer. YMMV.


Tom Roberts	tjroberts@lucent.com

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

pci bridge in 8260

[Kim, Jin Young]

Does anybody know when 8260 has pci bridge in it?
If there is no schedule in the near future, which pci bridge chip is
best fit to 8260, in the view of hw design and linux porting aspect?

Jin

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

Re: pci bridge in 8260

[Steve Tarr]

My understanding is not to expect it any time soon (<12months).
As to a good alternative, I have no experience



"Kim, Jin Young" wrote:
>
> Does anybody know when 8260 has pci bridge in it?
> If there is no schedule in the near future, which pci bridge chip is
> best fit to 8260, in the view of hw design and linux porting aspect?
>
> Jin
>

--
Steven Tarr
Lucent Technologies - Bell Labs
303-538-4056
tarr@lucent.com

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

Re: pci bridge in 8260

[Dan Malek]

Steve Tarr wrote:
>
> My understanding is not to expect it any time soon (<12months).
> As to a good alternative, I have no experience

Well, its a standard 60x bus.  Anything that worked on those should
work on the 8260.  I have seen/used 8260s with Tundra PowerSpan......


	-- Dan

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

Re: How to debug the linux kernel?

[Graham Stoney]

Gong Zhuo writes:
>   If I want to change the kernel of linux , how can I debug the kernel ? Any
> kind of tools can I use? Any URL I can read?

Try the debugging section of the HOWTO at:
    http://members.xoom.com/greyhams/linux/PowerPC-Embedded-HOWTO-18.html

Regards,
Graham
--
Graham Stoney
Principal Hardware/Software Engineer
Canon Information Systems Research Australia
Ph: +61 2 9805 2909  Fax: +61 2 9805 2929

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