by Hi Everyone.
I'm using the Intel 82559ER-supporting VxWorks driver to boot a PC target from a
host on a different subnet and getting nowhere.
My target is on 10.225.0.158:ffffff00 (255.255.255.0) and the host is on
15.144.180.226:fffff000 (255.255.240.0). Both are subnetted Class A addresses.
When I add the gateway parameter, g=10.225.0.1, the bootConfig.c code adds a
route [with routeAdd()] to 15.0.0.0 through this gateway, ignoring the netmask.
When I use the BSD/SENS variant of the driver (version 1.00.05) I just get the
"Loading..." prompt and nothing else. The target doesn't respond to pings at any
time.
When I use the MUX/END variant of the driver (version 1.00.01) I get the
"Loading..." prompt, the first number (text size) then nothing. The target
responds to pings until the text size displays, then stops. I have to leave the
network cable unplugged until "Loading..." appears (see also Further Info at the
end) otherwise I get the message "Panic: where are those rfd buffers" printed
out regularly. *Very occasionally* the pings continue to get through after the
text size displays, but only every 4th ping comes back and with a response of
about 1600ms instead of the usual 0-10ms. The two times that this happened, the
TCP link used by rcmd() *eventually* loaded all the main image and started
VxWorks.
When the target and host are on the same subnet, booting over the LAN works fine
as expected.
Further Info:
- there is 30-50 packets/sec broadcast traffic on the LAN.
- the physical (ie. layer 2) network carries traffic for both logical (layer 3)
IP networks. This means we can make the gateway parameter g=10.225.0.158 - the
same as the target's IP address - so the correct 15.x.x.x packets are generated
directly on the wire by the stack. But it's a shortcut and doesn't appear to
affect the lack of bootloading.
- the symptoms are the same when using the same driver on an 82558 LAN
controller.
- I can use the WindRiver FEI END driver with the 82558 and boot successfully
with target and host on different subnets.
- although the main image is just over 2MB (2,122,344 bytes), it does boot
successfully in other scenarios.
- I've tried replacing the routeAdd() used by bootConfig.c with mRouteAdd(). The
behaviour with netmasks seems to be broken in different and confusing ways, but
it still works with another driver so this shouldn't be stopping bootloading.
I know it's close to Christmas but this scenario needs to work when we come back
next year so if you're feeling bored over the next week...
Best Regards
James.