Closing Ethernet

[Ed Sutter]

>>>> This sounds similar to what I just solved, but maybe in the opposite
>>>> direction. Bootloader (uMon) running ethernet/UDP loads RTEMS and
>>>> branches to RTEMS at startup. Eth driver in bootloader was still doing
>>>> DMA to RAM and caused RTEMS to re-init ethernet and crash while it was
>>>> starting up. Had to reset ethernet hardware on entering RTEMS (start.S)
>>>> (or could do same thing before leaving bootloader). So adding code to
>>>> reset the mac and phy at beginning of start.S stopped ethernet activity
>>>> and fixed it. There may be better way but this worked for me but is
>>>> definitely not a "graceful" shutdown.
>>> Gene, thank you a lot!
>>> I shall consider this issue too, as I also run uMon.
>>>
>>> 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...
> 
> True, no intrs. But eth controller still does DMA to memory which keeps 
> going unless you reset it.

Right.
Bottom line is this... because uMon has API hooks that support the application's
ability to use its Ethernet interface, uMon can't just shut off Ethernet prior
to turning over control to the application.  So, it has to be left up to the user
to do this (or not).

>>> 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.

Generally speaking uMon can be entered three different ways:
1. At reset/powerup...
    Kinda obvious.
2. At an unhandled exception taken by the application...
    The intent here is that uMon has installed a set of exception handlers, all of
    which simply store away all the important system registers, then jump into the
    warmtart code of uMon to re-init the console and ethernet drivers.  RAM is not
    re-initialized; hence, if the proper symbol table file was put in TFS prior, you
    now have the ability to dump a stack trace and observe the core.  This can all
    be done manually or through a pre-established exception handling script.
3. At application exit...
    This is the case I believe you're working with.  This code is quite similar to
    that which is executed by the exception, but without any register storage.  It
    leaves RAM alone, and attempts to re-init console/ethernet drivers.  Then just
    stops at the uMON> prompt.

If, you're worried about RTEMS taking an interrupt after you've called mon_appexit(),
then you can probably just enter a critical section or some other non-interruptible
state and then call mon_appexit().  Right?

>>> 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.
> 
> Sure, but if autobooting you can't issue any prompts. Possibly an 
> autobooting/running script could do this which then loads RTEMS elf. But 
> rather not go that deep. 
That's not deep, that's a good way to boot up.  If you're autobooting you can
do whatever you want.  Just DON'T do it in monrc.  Actually, this is a common way
to boot up... Use an autoboot script (not monrc) to do some environment setup that
is specific to your appliation, then start the app.
> Would be nice if uMon had a user defined 
> "pre_autoboot_hook() that would be called to, e.g., shut down ethernet 
> before loading the app.

There is, refer to the #define PRE_TFSAUTOBOOT_HOOK (in start.c).  This is a function
call you can put into your build of the monitor (via config.h) to do whatever you want
just prior to uMon calling the autoboot code.


hth
Ed