Hi,
I don't want to do debug on the Ethernet port, that's why I am building the retail image. I want to verify that I can build a flash-based retail build version of the webserver app (App Note:700000146), burned into Flash, that boots up and can use the Ethernet port.

So what bootline parameters to I supply after "exec 0x00101000 - "?

Do I need to change anything in the Platform\Settings\BuildOption tab in PlatformBuilder?

SDK board? I have the LoCE_A400_rel_100 BSP if that's what you mean.

Thanks,
/michel

It seems that when I build and burn a retail build linked for flash, and then boot it using similar boot parameters as I would use for a debug build that the target is waiting for the other end to finish up the KITL handshaking?

/michel

Here's the log from the terminal:

losh> ifconfig sm0 10.0.0.2 255.255.255.0 10.0.0.1 ; ifconfig sm0 up
losh> exec 0x00101000 - dbg_serial:A400_UART:dbg_enet:91C111:dbg_enet_base:0x70000000:dbg_enet_irq:0x00000007:share_eth:1:kitl:true:ip_addr:10.0.0.1
kernel cmdline: 'dbg_serial:A400_UART:dbg_enet:91C111:dbg_enet_base:0x70000000:dbg_enet_irq:0x00000007:share_eth:1:kitl:true:ip_addr:10.0.0.1' at c00c0100
disabling mmu.
LoCE start

rf: 0
Debug serial initialized. Using driver A400_UART
Windows CE Kernel for ARM (Thumb Enabled) Built on Nov 7 2003 at 18:51:43
ProcessorType=0922 Revision=0
sp_abt=ffff5000 sp_irq=ffff2800 sp_undef=ffffc800 OEMAddressTable = 801011b8


===================================================================

WinCE firmware init (LoCE).
Kernel Arguments: dbg_serial:A400_UART:dbg_enet:91C111:dbg_enet_base:0x70000000:dbg_enet_irq:0x00000007:share_eth:1:kitl:true:ip_addr:10.0.0.1.

image_size: 0x1E00000
ram_size: 0x1800000
link_for_flash: 1
relocate_from_flash: 0
rom_offset: 0x80000000

===================================================================

Cold-boot: erasing object store.
Initializing interrupts.
CPLD Revision 0x34.
Card Engine Rev-B.
Interrupt initialization complete.
Initializing system-tick.
System-tick initialized.
RTC initialized. Using driver rtc_null
Multiple XIP regions not defined or fixup failed.
Initializing KITL.
Remote host present.
Debug enet initialized. Using driver 91C111
Debug enet base read as 0x70000000
Debug enet base mapped to virtual address 0xBFE00000.
Debug enet irq read as 0x00000007
Hooking platform interrupts.
CPLD Revision 0x34.
Card Engine Rev-B.
OEMKitlInit()
SmSC Ethernet controller detected: 0xBFE00000
MAC Address: 00:08:EE:00:3F:9F
91C111: 100 Mbits full-duplex.
+pckt_list_init(): 0x82002000 : 0x00002800

Device Name: LoCE_16287, IP: 10.0.0.1, Port: 981.

KITL Buffers at 0x82005000 len 0x20000
KITL Interrupt using SysIntr: 16.
share_dbg_enet read as 0x00000001
Initializing VBridge.
VBridgeInit()...TX = [16384] bytes -- Rx = [16384] bytes
Tx buffer [0xA242EB20] to [0xA2432B20].
Rx buffer [0xA242AB00] to [0xA242EB00].
VBridge:: NK add MAC: [0-8-EE-0-3F-9F]
VBridge initialized.
KITL Ethernet transport initialized.
Send: Tx/Rx buffers full (loaded network), resetting buffers

I've done more experimenting and this behaviour onlys seems to affect retail builds that are in Flash. For instance, if I build a retail image that relocates from Flash to Ram, the retail image boots fine!

What I have determined is that:
- debug flash build boots fine and connects to PB
- retail flash build hangs (doesn't seem to complete boot, won't ping correctly)
- debug relocate-to-ram-from-flash boots fine and connects to PB
- retail relocate-to-ram-from-flash boots fine

any ideas?

/michel

michel,

You probably don't have a network connection usable by applications available. There are two ways to make a connection available:

1) VMINI
2) lpd_SmSC_91C111_async

VMINI:

VMINI stands for "Virtual Miniport." This rides on top of the Kernel Independent Transport Layer (KITL). Therefore, unless you have an active KITL connection to your desktop via Platform Builder, this will not work. When you send a boot string to the kernel with the tokens "share_eth:1", you are telling the kernel to try to launch the VMINI network adapter. This will fail unless you've connected to the kernel already via Platform Builder.

To connect to the flash image from Platform Builder, you would need to set your target connection settings to "Jump to Image Only."

Then, use LoLo to do an ifconfig followed by a bootme &. When you hit the download/connect button inside Platform Builder, you should see that LoLo reports that it received a jump to image command right away. At this point, send the exec - 0x00101000 - .... script. If you have included the correct networking components in your image, all should be well.

NOTICE! The VMINI driver is very sensitive to high traffic networks. If you've got a busy network, don't expect much from this driver. The driver has a _lot_ to do and since it isn't a full-NDIS miniport driver, it isn't very stable.


lpd_SmSC_91C111_async:

This would be the prefered driver to use. Download it from the website and install it if you haven't already. Then check out the driver's registry file in:

Wince420\public\lpd_drivers\lpd_SmSC_91C111_async_version\*.reg.

Follow the instructions in that file to ensure the interrupts are set appropriately for your revision of hardware. Then, include that driver in your platform. If you are using this driver, you don't need to include KITL, CESH, etc. You also don't need to set the "share_eth:1" in your boot-parameter string. This driver implements a complete, stand-alone NDIS miniport driver. No connection to Platform Builder is necessary and it should work well on almost any network.

Best regards,
--mikee

Hi Mike,

I am using VMINI because that's what the my_webserver whitepaper directs to use. I was trying to verify that a flashed retail image with kitl enabled and using vmini would connect to PB (just like the ram-based version does).

So if I want to build a retail version of an image (for instance, if I wanted a my_webserver sample app to boot from flash I need to):
1. put back in the LAN devices component (and choose the lpd 91c111 async driver)? do I add back the serial component?
2. make sure the BSP_NOSHAREETH and IMGNOSHAREETH are set?
3. don't boot with the share_eth:1 and none of the dbg_enet_xxx: boot nor ip_addr: boot parameters?

thanks,
/michel

Michael,
I tried using the lpd_91C111_Async in the way you described but I initially found that it didn't work. I ran an image from flash and found that it seemed to be configured correctly. The network settings in the control panel were right and if I typed ipconfig at a dos prompt it looked right as well. pinging the board or pinging other hosts from the board both failed.

I found that if I ran ifconfig first then exec then it worked. It didn't matter what IP address was assigned using ifconfig, as soon as the image booted the static IP I set in the registry took effect and I was able to ftp and http to the board. I was also able to change the IP address from the control panel and it still worked.

It feels like ifconfig is initializing something that is persisting during the OS boot and that this initialization is not performed by the lpd_91C111_Async driver.

The registry settings that I changed for the driver to set a static IP are:

[HKEY_LOCAL_MACHINE\Comm\lpd_91C111_Async1\Parms\TcpIp]
"EnableDHCP"=dword:0
"IpAddress"=multi_sz:"172.16.1.50"
; "IpAddress"=multi_sz:"0.0.0.0"
"Subnetmask"=multi_sz:"255.255.0.0"
; "DefaultGateway"=multi_sz:"192.168.2.1"
"DefaultGateway"=multi_sz:"172.16.0.1"
; "DNS"=multi_sz:"192.168.2.1"
"DNS"=multi_sz:"0.0.0.0"
; "WINS"=multi_sz:"192.168.2.1"
"WINS"=multi_sz:"0.0.0.0"
"UseZeroBroadcast"=dword:0
"DhcpMaxRetry"=dword:ffffffff
"DhcpInitDelayInterval"=dword:2710
"DhcpRetryDialog"=dword:ffffffff

otherwise I just left it as is.

Thanks
Ian

Ian,

It sounds like the driver is having trouble auto-negotiating to your network. Are you connected to a hub, or directly to your computer via a cross-cable.

The code within LoLo and the code within CE essentially do the same thing to set up the 91C111. However, I've found that auto-configuration is typically the cause of _everyones_ grief when it comes to networking problems. Especially because it can be so timing sensitive.

You might want to try forcing the driver to connect to a certain speed and duplex. This can be done via the registry file. Look in there and you should be able to figure out the proper settings.

Also, are you working with the latest version of the driver? It should be lpd_ScSC_91C111_Async_rel_100 or higher.

--mikee

Michael,
I'm connected to a DSL router and yes, I'm using the latest driver, rel 1.0.0. It worked when I disabled auto configuration and forced the driver to connect at 10/half duplex. However with auto configuration enabled and the speed/duplex set to 10/half it didn't work.

Using ifconfig in LoLo worked every time.

Ian

Ian,


Yeah, that makes sense to me. Auto-negotiation is very touchy and quite timing sensitive. When I wrote the driver, I tested it on as many hubs and switches as possible. I had to make decisions based on getting it to boot up as fast as possible, while still dealing with legacy hardware that doesn't support auto-negotiation.

So, there are two ways to fix this.

1) Get your hardware in-house and add it to the stack of switches we test against.

2) Make a couple of architecture changes within the driver to support spinning a seperate auto-negotiation thread.

My plan is to do #2 as that is the most robust and correct way to handle this problem. As you can see, solution #1 just doesn't scale well.

Unfortunately, I've no idea when I might work on this driver again. So, if you are in a hurry, and must use this router, I suggest you contact our support team and contract them to tailor the driver to work with your particular router.

This probably only makes sense if you know that router will be used in your final product. For instance, we've had clients that are shipping 10,000 of their Card-Engine enabled products to customers with a standard network configuration. In that client's case, it made sense for them to have us optimize the driver for the target hubs and switches. If you are only working with this DSL router during development, it's probably not worth it.

Also, Netgear has some really cheap little hubs that work great. So if you are just annoyed at the interaction between driver and router, maybe try one of them.

Please let me know if you have any more questions or concerns.

--mikee