Using smc91111.c on powerpc and libchip/network questions

[Joel Sherrill]

Peter Dufault wrote:
> I'm bringing up a Phytec mpc5554 based on the Embedded Brains  
> mpc55xxevb bsp.  It has the SMC LAN91C111 ethernet chip, and after  
> enabling the driver it compiles.  A few questions:
>   
I hope someone else will pipe up with more feedback.
> 1. The README file in c/src/libchip/network says:
> "The reusable chip drivers do not directly access the controller.   
> They access the registers on the controller via a set of functions  
> which are provided by the BSP."
>
> This is a definition of "reusable chip drivers" and not what exists in  
> the c/src/libchip/network directory, correct?  Reading this is the  
> reason I was surprised it compiled immediately - I assumed I needed to  
> provide these hooks.
>   
This one looks different than the other drivers in this
directory.  Most are PCI drivers so adapt using the
PCI API.  The SONIC is typical of what is expected
otherwise.  See sonic.h for sonic_configuration_t.
You are assumed to provided a configuration structure.

The drivers which use the configuration method will
always compile but you will get a linking error unless
you provide the configuration structure with the appropriate
name.
> Some drivers defer to routines in board support packages but the  
> smc91111 driver uses locally defined HAL_READ_UINT16() and friends  
> macros (I just noticed HAL_READ_UINT16() is defined twice) with byte- 
> swapping appropriate for big-endian architectures only (OK for me), I  
> noticed similar hard-wired access methods in other drivers. The README  
> should be changed to make it clear it is how things should be.  Is  
> there a standard set of BSP register access functions I should use  
> instead?
>
>   
The sonic and serial drivers follow the model that they
assume a configuration table and the BSP provides
routines which are called indirectly.
> 2. The driver uses "old-style exception processing".  I'll replace the  
> set_vector() call with the appropriate BSP_install_rtems_irq_handler()  
> call,  what other changes?  Why do some of the routines have  
> conditional BSP_SHARED_HANDLER_SUPPORT to install  
> BSP_install_rtems_shared_irq_handler() instead? If that's the right  
> thing to do why isn't it done at a lower level?
>
>   
History.  And no one has either (a) figured how how to
do it or (b) not been willing/able to implement their idea. :)

If you have an idea in this area, we would be happy to
see it implemented.  It would be a great clean up.

FWIW if there an answer to this that I am not aware of,
please speak up. :)

--joel
> Thanks -
>
> Peter
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985