just cut the kitl cord and my ethernet stopped working

[remcow]

Hi All

I am developing an SH4 4.2 platform that seems to work quite well now
so thought I'd get rid of the kitl connection.

After it downloads (using a ethernet loader) it does not re-use the ip
address that the bootloader uses.

There is obviously something else I need to do, but can't quite see
what that might be.

Another question: if I made the kitl connection passive, it doesn't
need PB anymore, right? If I ever needed it again, how would I invoke
it?

Any help would be much appreciated.

Remco

[Art]

define "get rid of the kitl connection"? What did you do?

I believe unless you build a ship version of your image, the device will hang looking for a PB connection on start up. Ship version of the image removes KITL support and other debug stuff.

Also, I am not sure if you are aware, but KITl relies on ETHDBG driver to mainitain KITL connection over Ethernet. This is a debug/kernel ehternet driver. When you remove KITL, this driver is not active anymore. You need to develop/port a true NDIS mini-port Ethernet device driver for you product to get non-debug image to work on Ethernet. ETHDBG and NDIS mini-port are mutual exclusive

[remcow]

Hi Art
Thanks for the reply.
I took out enable kitl out of the settings. Before my bootloader got
an ip address that was passed along to the debug ethernet connection.
I am not exactly sure how the mechanism worked, but this ip address
was used for both debug and normal ethernet operations.
Now that I no longer have a debug connection, the normal operations
also stopped working. Actually, it appears like the normal port is
working but my device is totally headless so I have no idea what the
IP address is. (I do know it isn't the same one as the bootloader
had).
I guess the normal driver has to now re-use the bootloader's ip
address from the global area they both have in common. If that is the
correct way to do this, how would I go about doing it?
Regards,
Remco
Art <A...@discussions.microsoft.com> wrote in message news:<C4960E24-F961-4D99...@microsoft.com>...

[Andrew McGrath]

I found I needed to add a static IP address to your network card registry
settings to acheive this.

We have the following:

[HKEY_LOCAL_MACHINE\Comm\LAN91C1111\Parms\TcpIp]
"EnableDHCP"=dword:0
"DefaultGateway"="192.168.0.1"
"UseZeroBroadcast"=dword:0
"IpAddress"="192.168.0.22"
"SubnetMask"="255.255.255.0"

So if you are using an NE2000 chip, you will need to use that instead of
LAN91C1111

We use any address for downloading within the 192.168.0.xxx subnet, but then
we have a static one for when the OS gets up and running.

HTH,

Andrew McGrath
www.mcsoft.com.au

"remcow" <why...@yahoo.com> wrote in message
news:8bd95f81.04070...@posting.google.com...

[Yannick Chamming's [eMVP]]

You can have a "KitlLess" version of CE image without performing ship build
: you just need to uncheck the "Enable Kitl" in platform settings.

Concerning KitlPassive, you need to include Kitl support in the image, but
in the OAL, you have to init it without activation (InitKitl function
receives a boolean as parameter for this)

Kitl will initiate a connexion (and will halt CE till a host like PB receive
the connexion) when a kitl client will ask for it. A sample of Kitl client
is the kernel debugger : if you include the kernel debugger in your image,
it will try a Kitl connexion as soon as an unhandled exception occur. You
can also include the kernel debugger in the image without starting it so
that an unhandled exception would not automatically jump to a kitl connexion
: for this, include the kernel debugger (kd.dll) in the file section of a
BIB file, and use LoadDbg.Exe when you want to activate the kernel debugger

Yannick

--
----------------------------------------------------------------
Yannick Chamming's (eMVP)
ADESET
Windows Embedded Manager
ychammings AT adeset DOT com>
http://www.adeset.com
Tél : +33 (0)4.72.18.57.77
Fax : +33 (0)4.72.18.57.78
----------------------------------------------------------------

"Art" <A...@discussions.microsoft.com> wrote in message
news:C4960E24-F961-4D99...@microsoft.com...

[Art]

I am not sure I understand the nature of your problem and afraid to give incorrect information.

If it simply the matter of obtaining IP address information, there are a few options here.

1. Provide static IP in registry as Andrew has mentioned
2. Boot loader has a mechanism of passing DHCP-obtained information via boot args. I am not sure exacly how it is done, you would have to dig through the code.
3. I know that when you mini-port driver is loaded and TCP/IP stack is loaded, the DHCP is activated and it can re-acquire the IP address again on start up, assuming the proctocol stack is correctly bounded to the driver. I don't remember doing anything special for this, it just worked by itself.

I guess the first thing I would check if your mini-port driver completed initialization correctly. Regardless of IP address, when driver comes up it issues the ARP broadcast with its MAC address. See if you can see capture this broadcast with a protocol analyzer or just check from another PC: open console prompt and execute "arp -a" just prior to your target booting and right after. See if your a new entry with your target MAC address was added to your PC's ARP table.

Another thing to do is to configure for Static IP and take DHCP and/or IP address passing from the bootloader out of the picture. See if you can boot this way and ping your device at that static address.

Art

[remcow]

Hi Andrew
Appreciate the input -- I found those very same entries missing. I've
tried both dhcp and static, but it doesn't come up.
If KITL is turned off, doesn't the system just load the drivers
(ignoring that I might have downloaded by means of TFPT).
Now I am wondering if I am having some issue with my 111 driver..

Thanks for any thought.

Remco

"Andrew McGrath" <andrew....@mcsoft.com.au> wrote in message news:<O2IrPKWZ...@TK2MSFTNGP11.phx.gbl>...

[remcow]

Hi Yannick

Thanks -- I tried rebuilding with active/passive kitl just now by
tying to to a dip swich. I can tell it isn't hanging (it is a headless
system) when it is set to passive, but the 'product' ethernet still
didn't come to life.

Do I need to disable the vmini driver (I guess this takes care of
creating a debug and 'product' ethernet connection) when KITL is
disabled? Or can I have this in conjunction with the 'product' driver?

Regards,
Remco

"Yannick Chamming's [eMVP]" <ychammin...@adeset.com> wrote in message news:<#fDxSXbZ...@TK2MSFTNGP11.phx.gbl>...

[Art]

Remcow, as I mentioned earlier KITL over VMINI is mutual exclusive with Product Ethernet. So, yes, you should disable VMINI. You should have BSP_NOSHAREETH=1 and IMGNOSHAREETH=1. This will takle care of VMINI. DHCP services and other ethernet related suff are added if you have SYSGEN_ETHERNET=1 set.