Re: debugging using bdi2000, unable to proceed.

Re: debugging using bdi2000, unable to proceed.

[Jeff H Zhong]

The problem is this:

When I use bootp/tftp boot, on the host if I do arp then I can get
root@Jeff linuxppc_2_4_develubpatch<366>arp
Address                  HWtype  HWaddress           Flags
Mask            Iface
7.1.1.5                  ether   00:40:49:FA:43:59
C                     eth1
7.1.1.6                  ether   00:04:AC:E3:1D:62
C                     eth1
10.1.1.171               ether   00:A0:C5:E0:C4:EC
C                     eth0

Which 7.1.1.5 is my BDI2000 and is not part of our discussion.

But if I bootm directly from flash, it will be
root@Jeff linuxppc_2_4_develubpatch<366>arp
Address                  HWtype  HWaddress           Flags
Mask            Iface
7.1.1.5                  ether   00:40:49:FA:43:59
C                     eth1
7.1.1.6
(incomplete)                              eth1
10.1.1.171               ether   00:A0:C5:E0:C4:EC
C                     eth0

I doubt that when kernel brings up eth0, it doesn't broadcast MAC
address?

I am still hacking the kernel code.... and getting headache on this
problem...

--Jeff

Wolfgang Denk wrote:
>
> in message <3E9FB7FD.93947BE5@doremilabs.com> you wrote:
> >
> > Could you give me a hand to help me figure out this issue on ebony?
>
> I've read your story before, but I cannot help.
>
> > If I use "bootp" or "tftp" to load kernel image(linuxppc_2_4_devel from
> > BK) at address 0x01000000 and then issue "bootm", everything works fine.
> > I have also programmed the image into flash at 0xffe00000, but each time
> > when I issue "bootm 0xffe00000", it will get stuck at when trying to
> > mount NFS.
>
> Technically there is absolutely no difference between both cases:  in
> either  case  U-Boot  will  copy  and  uncompress  the  kernel to RAM
> starting at physical adress 0x0000, and start it there.  I  have  not
> the slightest idea whaty could cause a behaviour as described by you,
> nor have I ever seen anything like that before.

--
Jeff H. Zhong
-------------
Doremi Labs, Inc.
306 East Alameda Avenue
Burbank, CA 91502

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

Re: debugging using bdi2000, unable to proceed.

[Wolfgang Denk]

In message <3E9FD84F.2C40F0ED@doremilabs.com> you wrote:
>
> Wolfgang Denk wrote:
> >
> > in message <3E9FB7FD.93947BE5@doremilabs.com> you wrote:
> > >
> > > Could you give me a hand to help me figure out this issue on ebony?
> >
> > I've read your story before, but I cannot help.
> >
> > > If I use "bootp" or "tftp" to load kernel image(linuxppc_2_4_devel from
> > > BK) at address 0x01000000 and then issue "bootm", everything works fine.
> > > I have also programmed the image into flash at 0xffe00000, but each time
> > > when I issue "bootm 0xffe00000", it will get stuck at when trying to
> > > mount NFS.
> >
> > Technically there is absolutely no difference between both cases:  in
> > either  case  U-Boot  will  copy  and  uncompress  the  kernel to RAM
> > starting at physical adress 0x0000, and start it there.  I  have  not
> > the slightest idea whaty could cause a behaviour as described by you,
> > nor have I ever seen anything like that before.

Well, there _is_ one obvious difference: when you use "tftp" to  load
kernel  then  U-Boot  will  perform the initialization of the network
interface. You can perform a simple test for this:

Do a dummy TFTP download, and then try  to  "bootm"  the  image  from
flash. I bet it'll work.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
In C we had to code our own bugs, in C++ we can inherit them.

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

Re: debugging using bdi2000, unable to proceed.

[Jeff H Zhong]

I mean just like that on workstation(none embedded linux), user should
be able to at least ping the target at the time when it brings up the
ethernet interface, is it right?

Regards,
--Jeff

> In message <3E9FD84F.2C40F0ED@doremilabs.com> you wrote:
> >
> > Wolfgang Denk wrote:
> > >
> > > in message <3E9FB7FD.93947BE5@doremilabs.com> you wrote:
> > > >
> > > > Could you give me a hand to help me figure out this issue on ebony?
> > >
> > > I've read your story before, but I cannot help.
> > >
> > > > If I use "bootp" or "tftp" to load kernel image(linuxppc_2_4_devel from
> > > > BK) at address 0x01000000 and then issue "bootm", everything works fine.
> > > > I have also programmed the image into flash at 0xffe00000, but each time
> > > > when I issue "bootm 0xffe00000", it will get stuck at when trying to
> > > > mount NFS.
> > >
> > > Technically there is absolutely no difference between both cases:  in
> > > either  case  U-Boot  will  copy  and  uncompress  the  kernel to RAM
> > > starting at physical adress 0x0000, and start it there.  I  have  not
> > > the slightest idea whaty could cause a behaviour as described by you,
> > > nor have I ever seen anything like that before.
>
> Well, there _is_ one obvious difference: when you use "tftp" to  load
> kernel  then  U-Boot  will  perform the initialization of the network
> interface. You can perform a simple test for this:
>
> Do a dummy TFTP download, and then try  to  "bootm"  the  image  from
> flash. I bet it'll work.

--
Jeff H. Zhong
-------------
Doremi Labs, Inc.
306 East Alameda Avenue
Burbank, CA 91502

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

Re: debugging using bdi2000, unable to proceed.

[Wolfgang Denk]

In message <3EA020E5.6FAEBC0A@doremilabs.com> you wrote:
>
> I mean just like that on workstation(none embedded linux), user should
> be able to at least ping the target at the time when it brings up the
> ethernet interface, is it right?

Ummm...why? For example, U-Boot initializes the network interface and
is able to perform DHCP and TFTP downloads, but it will not reply  to
a ping as ICMP is not needed for U-Boot's purposes.

Replying to ping requests is a  non-requirement  for  most  practical
purposes, and may be blocked by any router anyway.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
All these theories, diverse as they are, have two things  in  common:
they explain the observed facts, and they are completeley and utterly
wrong.                       - Terry Pratchett, _The Light Fantastic_

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

Re: debugging using bdi2000, unable to proceed.

[Jeff H Zhong]

Wolfgang Denk wrote:
We may need one more variable to be passed to kernel and let kernel know
if we want initialize ethernet or not?

--Jeff

> > Wolfgang Denk wrote:
> > >
> > > in message <3E9FB7FD.93947BE5@doremilabs.com> you wrote:
> > > >
> > > > Could you give me a hand to help me figure out this issue on ebony?
> > >
> > > I've read your story before, but I cannot help.
> > >
> > > > If I use "bootp" or "tftp" to load kernel image(linuxppc_2_4_devel from
> > > > BK) at address 0x01000000 and then issue "bootm", everything works fine.
> > > > I have also programmed the image into flash at 0xffe00000, but each time
> > > > when I issue "bootm 0xffe00000", it will get stuck at when trying to
> > > > mount NFS.
> > >
> > > Technically there is absolutely no difference between both cases:  in
> > > either  case  U-Boot  will  copy  and  uncompress  the  kernel to RAM
> > > starting at physical adress 0x0000, and start it there.  I  have  not
> > > the slightest idea whaty could cause a behaviour as described by you,
> > > nor have I ever seen anything like that before.
>
> Well, there _is_ one obvious difference: when you use "tftp" to  load
> kernel  then  U-Boot  will  perform the initialization of the network
> interface. You can perform a simple test for this:
>
> Do a dummy TFTP download, and then try  to  "bootm"  the  image  from
> flash. I bet it'll work.

--
Jeff H. Zhong
-------------
Doremi Labs, Inc.
306 East Alameda Avenue
Burbank, CA 91502

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

Re: debugging using bdi2000, unable to proceed.

[Wolfgang Denk]

In message <3EA023F2.820B65C0@doremilabs.com> you wrote:
>
> We may need one more variable to be passed to kernel and let kernel know
> if we want initialize ethernet or not?

No, the Linux driver should always assume an uninitialized system and
perform the required steps himself.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
It is necessary to have purpose.
	-- Alice #1, "I, Mudd", stardate 4513.3

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

debugging using bdi2000, unable to proceed.

[Omanakuttan]

We are using bdi200 for debugging linux kernel (2.4.1 and 2.4.17).
our target board is mpc8260ADS, with ppcboot 2.0.0

we are using http://www.ultsol.com/PDFS/Tool%20Talk%2002-001a.pdf as a
refernce to get bdi 2000 setup running.
Connections are made as per the document.
bdisetup is run from the host. Using the configuration file.
We used format IMAGE and file zImage and the image file  loaded to
0x400000 using bdi2000.
run ppc_82xx-gdb from the host.

Output from gdb
GNU gdb 5.1.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux"...
(gdb) target remote 10.1.40.176:2001
Remote debugging using 10.1.40.176:2001
0x00404480 in ?? ()
(gdb) continue
Continuing.

Program received signal SIGSTOP, Stopped (signal).
0x00404478 in ?? ()
(gdb) pwd
Working directory /root.
(gdb) b start_here
Breakpoint 1 at 0xc0003694
(gdb) b startk\b \b_kernel
Breakpoint 2 at 0xc013e618: file init/main.c, line 527.
(gdb) continue
Continuing.

Program received signal SIGSTOP, Stopped (signal).
0x00404474 in ?? ()
(gdb) until start_kernel

Program received signal SIGSTOP, Stopped (signal).
0x00404470 in ?? ()
(gdb) until start_here

Program received signal SIGSTOP, Stopped (signal).
0x0040446c in ?? ()

</end of gdb output>

The documnetation (above referneced) says that one should connect
minicom (any serial communication
program). But when we connect the BDI JTag interface, we get the message
on BDI Telnet,

004000c0 : 3863fffc 3884fffc 38000000 94030004  8c..8...8.......
004000d0 : 7c032000 4082fff8 7c290b78 3c200040  |. .@...|).x< .@
004000e0 : 60217148 38212000 3821ff00 3840000f  `!qH8! .8!..8@..
004000f0 : 7c211078 4800012d 7d034378 7ce43b78  |!.xH..-}.Cx|.;x
- TARGET: target has entered debug mode
- TARGET: target has entered debug mode

The target is in debug mode and we cannot enter any command from
minicom/kermit.

We are struck at this point. Is there any funcamental error we are
commiting?

Any idea/poiters will be appreciated.
Thanks.
Om.


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

Re: debugging using bdi2000, unable to proceed.

[Wolfgang Denk]

In message <3E9EA7C6.2020605@tataelxsi.co.in> you wrote:
>
> We are using bdi200 for debugging linux kernel (2.4.1 and 2.4.17).
> our target board is mpc8260ADS, with ppcboot 2.0.0
>
> we are using http://www.ultsol.com/PDFS/Tool%20Talk%2002-001a.pdf as a
> refernce to get bdi 2000 setup running.
> Connections are made as per the document.
> bdisetup is run from the host. Using the configuration file.
> We used format IMAGE and file zImage and the image file  loaded to
> 0x400000 using bdi2000.

Don't do this. Build a PPCBoot image as usual using the mkimage tool,
and use PPCboot to download and start the kernel. Use the BDI2000 for
debugging only.


Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
It all seemed, he thought, to be rather a lot of  trouble  to  go  to
just sharpen a razor blade.  - Terry Pratchett, _The Light Fantastic_

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

Re: debugging using bdi2000, unable to proceed.

[Omanakuttan]

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]

Wolfgang Denk wrote:
>>we are using http://www.ultsol.com/PDFS/Tool%20Talk%2002-001a.pdf as a
>>refernce to get bdi 2000 setup running.
>>Connections are made as per the document.
>>bdisetup is run from the host. Using the configuration file.
>>We used format IMAGE and file zImage and the image file  loaded to
>>0x400000 using bdi2000.
>
>
> Don't do this. Build a PPCBoot image as usual using the mkimage tool,
> and use PPCboot to download and start the kernel. Use the BDI2000 for
> debugging only.
Hi,
We tried loading a ppcboot image of linux kernel and ramdisk referring
the document and
http://lists.linuxppc.org/linuxppc-embedded/200108/msg00188.html.
What we did is,
power up both bdi2k and target.
We got ppcboot prompt on the serial console.
Setup the bdi2000 using serial connection from the host (using bdisetup
executable) telnet to bdi2000. bdi2000 picks up the configuration file
and configures target and itself. in host, ppc_82xx-gdb <path to
vmlinux> put breakpoint at start_kernel

Now ideally we should be able to give bootm <image loc> <ramdisk loc>
from ppcboot. but bdi2k holds the target in debug mode. In this state we
are unable to enter any command into ppcboot prompt.
Same behaviour is shown in our custom board also.

we use the vads8260.cfg file provided by bdi2000.
I think there is some configuration that we need to change in the bdi
supplied file like bdimode and breakmode. Is it so? I cannot think of
any other reason.

Thanks,
Om.

[-- Attachment #2: VADS8260.CFG --]
[-- Type: application/x-unknown-content-type-CodeWarrior_cfg, Size: 5653 bytes --]

Re: debugging using bdi2000, unable to proceed.

[Wolfgang Denk]

Dear Om,

in message <3E9FE4DC.8040704@tataelxsi.co.in> you wrote:
>
> > Don't do this. Build a PPCBoot image as usual using the mkimage tool,
> > and use PPCboot to download and start the kernel. Use the BDI2000 for
> > debugging only.
> Hi,
> We tried loading a ppcboot image of linux kernel and ramdisk referring
> the document and
> http://lists.linuxppc.org/linuxppc-embedded/200108/msg00188.html.
> What we did is,
> power up both bdi2k and target.
> We got ppcboot prompt on the serial console.
> Setup the bdi2000 using serial connection from the host (using bdisetup
> executable) telnet to bdi2000. bdi2000 picks up the configuration file
> and configures target and itself. in host, ppc_82xx-gdb <path to
> vmlinux> put breakpoint at start_kernel

This sequence is wrong.  _First_  configure  and  boot  the  BDI2000.
Connect  to  the  BDI2000 over telnet. Type "reset" and "go" to start
PPCBoot.

Use PPCBoot to load the kernel etc.

_Then_ "halt" with the BDI2000, set any  breakpoints  you  need,  and
continue  execution  ("go").  The use "bootm" in PPCBoot to start the
kernel.

> Now ideally we should be able to give bootm <image loc> <ramdisk loc>
> from ppcboot. but bdi2k holds the target in debug mode. In this state we
> are unable to enter any command into ppcboot prompt.

This is because the init sequence of  the  BDI2000  will  reset  your
board.  Didn't  you  see  this  from  the  output? The BDI2000 prints
readable messages - read and try to understand them.

> I think there is some configuration that we need to change in the bdi
> supplied file like bdimode and breakmode. Is it so? I cannot think of
> any other reason.

The reason is pilot error.



Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
All I ask is a chance to prove that money can't make me happy.

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