Closing Ethernet

[Ed Sutter]

>>> Hmmm... AFAIK, as uMon does only polling, there should be no problems
>>> with Ethernet still "active", no? Well, only if you use the uMon RAM for
>>> the application...
>>> What I do is: I leave 0-64KB RAM for uMon purposes and load the
>>> application to the 0x10000 address. Thus DMA may continue to write its
>>> data.
>>>
>>> But I have the problem returning to uMon from the application - the RTEMS
>>> driver does use interrupts.
>>>
>>> As for just now, I simply zero some FEC registers before exiting in the
>>> application, but this is not good, as this work must be done by the
>>> driver.
>> Fellers,
>> Prior to running your application, issued the command "ether off" at the
>> uMon prompt.  That will turn down the ethernet interface (assuming the
>> driver is written properly) and then, if you're using the uMon API within
>> RTEMS, it will not interfere with the RTEMS driver.
>> Or, if you are using the uMon api in RTEMS, you can do this:
>> mon_docommand("ether off",0);
>> from within your application at startup.
>> Ed
> 
> Hello, Ed.
> 
> 1.Just curious: taking into account my memory distribution, do you think that 
> there still may be a problem?

Sorry, haven't been reading the list in that level of detail.
You'll have to gimme a second shot at what your memory distribution is.

> 2. Using this opportunity: I think about adding to uMon the ability to manage 
> the non-cached RAM. I mean, that when the RAM is divided into cached and 
> non-cached, and uMon already uses non-cached for its drivers purposes, it 
> seems to be natural for uMon to continue to manage all the non-cached RAM for 
> application too (via mon_portcmd, for example).

Sorry again, I'm not sure I understand what you mean by "manage non-cached RAM".
Please explain.
Ed