This is the mail archive of the ecos-patches@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Memec Virtex-II Pro and PowerPC 405 watchdog support


On Fri, Oct 15, 2004 at 12:29:37PM +0200, Wouter Cloetens wrote:
> Mind has decided to release its platform support for the Memec Virtex-II
> Pro FG456 evaluation board.

Would you like this incorperating into the anoncvs repository? You do
not appear to have a copyright assignment on file. Please could you
take a look at http://ecos.sourceware.org/assign.html.

We probably have access to a MOAD board so can see if you broke
anything.

> @@ -0,0 +1,39 @@
> +2004-10-14  Wouter Cloetens  <wouter@mind.be>
> +
> +        * New package - support for Memec EMAC.
> +
> +//===========================================================================
> +//####ECOSGPLCOPYRIGHTBEGIN####
> +// -------------------------------------------
> +// This file is part of eCos, the Embedded Configurable Operating System.
> +// Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc.
> +// Copyright (C) 2002, 2004 Mind n.v. <v2p@mind.be>

When this is committed to anoncvs, this Mind Copyright will have to be
removed. 

> diff --exclude CVS -Naurp ecos/ecos/packages/devs/eth/powerpc/mv2p/current/src/if_mv2p.c ecos-mv2p/ecos/packages/devs/eth/powerpc/mv2p/current/src/if_mv2p.c
> --- ecos/ecos/packages/devs/eth/powerpc/mv2p/current/src/if_mv2p.c	1970-01-01 01:00:00.000000000 +0100
> +++ ecos-mv2p/ecos/packages/devs/eth/powerpc/mv2p/current/src/if_mv2p.c	2004-10-14 17:44:27.000000000 +0200
> @@ -0,0 +1,760 @@
> +//==========================================================================
> +//
> +//      dev/if_mv2p.c
> +//
> +//      Ethernet device driver for Memec Design OPB-ETHCTRL
> +//
> +//==========================================================================
> +//####ECOSGPLCOPYRIGHTBEGIN####
> +// -------------------------------------------
> +// This file is part of eCos, the Embedded Configurable Operating System.
> +// Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc.
> +// Copyright (C) 2002, 2004 Mind n.v. <v2p@mind.be>
> +//
> +// eCos is free software; you can redistribute it and/or modify it under
> +// the terms of the GNU General Public License as published by the Free
> +// Software Foundation; either version 2 or (at your option) any later version.
> +//
> +// eCos is distributed in the hope that it will be useful, but WITHOUT ANY
> +// WARRANTY; without even the implied warranty of MERCHANTABILITY or
> +// FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> +// for more details.
> +//
> +// You should have received a copy of the GNU General Public License along
> +// with eCos; if not, write to the Free Software Foundation, Inc.,
> +// 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
> +//
> +// As a special exception, if other files instantiate templates or use macros
> +// or inline functions from this file, or you compile this file and link it
> +// with other works to produce a work based on this file, this file does not
> +// by itself cause the resulting work to be covered by the GNU General Public
> +// License. However the source code for this file must still be made available
> +// in accordance with section (3) of the GNU General Public License.
> +//
> +// This exception does not invalidate any other reasons why a work based on
> +// this file might be covered by the GNU General Public License.
> +//
> +// Alternative licenses for eCos may be arranged by contacting Red Hat, Inc.
> +// at http://sources.redhat.com/ecos/ecos-license/
> +// -------------------------------------------
> +//####ECOSGPLCOPYRIGHTEND####
> +//==========================================================================
> +//#####DESCRIPTIONBEGIN####
> +//
> +// Author(s):    gthomas
> +// Contributors: gthomas
> +// Date:         2004-10-14
> +// Purpose:
> +// Description:  hardware driver for Memec OPB-ETHCTRL
> +//
> +//
> +//####DESCRIPTIONEND####
> +//
> +//==========================================================================
> +
> +// Ethernet device driver for Memec Design OPB-ETHCTRL
> +
> +#include <pkgconf/system.h>
> +#include <pkgconf/devs_eth_powerpc_mv2p.h>
> +#include <pkgconf/io_eth_drivers.h>
> +
> +#ifdef CYGPKG_NET
> +#include <pkgconf/net.h>
> +#endif
> +
> +#include <cyg/infra/cyg_type.h>
> +#include <cyg/infra/diag.h>
> +
> +#include <cyg/hal/hal_arch.h>
> +#include <cyg/hal/hal_cache.h>
> +#include <cyg/hal/hal_intr.h>
> +#include <cyg/hal/drv_api.h>
> +#include <cyg/hal/hal_if.h>
> +#include <cyg/hal/ppc_regs.h>
> +
> +#include <cyg/io/eth/netdev.h>
> +#include <cyg/io/eth/eth_drv.h>
> +
> +#include "opb_ethctrl.h"
> +
> +// Align buffers on a cache boundary
> +static struct eth_bd mv2p_eth_rxbd[CYGNUM_DEVS_ETH_POWERPC_MV2P_RxNUM];
> +static struct eth_bd mv2p_eth_txbd[CYGNUM_DEVS_ETH_POWERPC_MV2P_TxNUM];
> +
> +static struct mv2p_eth_info mv2p_eth0_info;
> +static unsigned char _default_enaddr[] = { 0x08, 0x00, 0x3E, 0x40, 0x7A, 0xBA};
> +static unsigned char enaddr[6];
> +#ifdef CYGPKG_REDBOOT
> +#include <pkgconf/redboot.h>
> +#ifdef CYGSEM_REDBOOT_FLASH_CONFIG
> +#include <redboot.h>
> +#include <flash_config.h>
> +RedBoot_config_option("Network hardware address [MAC]",
> +                      eth_esa,
> +                      ALWAYS_ENABLED, true,
> +                      CONFIG_ESA, 0
> +    );
> +#endif
> +#endif
> +
> +#define os_printf diag_printf
> +
> +// For fetching the ESA from RedBoot
> +#include <cyg/hal/hal_if.h>
> +#ifndef CONFIG_ESA
> +#define CONFIG_ESA 6
> +#endif
> +
> +ETH_DRV_SC(mv2p_eth0_sc,
> +           &mv2p_eth0_info,    // Driver specific data
> +           "eth0",             // Name for this interface
> +           mv2p_eth_start,
> +           mv2p_eth_stop,
> +           mv2p_eth_control,
> +           mv2p_eth_can_send,
> +           mv2p_eth_send,
> +           mv2p_eth_recv,
> +           mv2p_eth_deliver,
> +           mv2p_eth_int,
> +           mv2p_eth_int_vector);
> +
> +NETDEVTAB_ENTRY(mv2p_netdev, 
> +                "mv2p_eth", 
> +                mv2p_eth_init, 
> +                &mv2p_eth0_sc);
> +
> +#ifdef CYGINT_IO_ETH_INT_SUPPORT_REQUIRED
> +static cyg_interrupt mv2p_eth_tx_interrupt;
> +static cyg_handle_t  mv2p_eth_tx_interrupt_handle;
> +static cyg_interrupt mv2p_eth_rx_interrupt;
> +static cyg_handle_t  mv2p_eth_rx_interrupt_handle;
> +#endif // CYGINT_IO_ETH_INT_SUPPORT_REQUIRED
> +static void          mv2p_eth_int(struct eth_drv_sc *data);
> +
> +// HACK
> +#define MV2P_ETH_PHY 0
> +// HACK

I start to worry when i see comments like this!


> +
> +#ifndef MV2P_ETH_PHY
> +#error  MV2P_ETH_PHY must be defined
> +#endif
> +
> +#ifndef MV2P_ETH_RESET_PHY
> +#define MV2P_ETH_RESET_PHY()
> +#endif
> +
> +#ifndef MV2P_EPPC_BD_OFFSET
> +#define MV2P_EPPC_BD_OFFSET CYGNUM_DEVS_ETH_POWERPC_MV2P_BD_OFFSET
> +#endif
> +
> +// LED activity [exclusive of hardware bits]
> +#ifndef _get_leds
> +externC int  _mv2p_get_leds(void);
> +externC void _mv2p_set_leds(int);

These should be called something like hal_get_leds() and
hal_set_leds() so you do not polute the namespace. There should also
be prototypes in something like hal_diag.h.

> +static void 
> +mv2p_eth_send(struct eth_drv_sc *sc, struct eth_drv_sg *sg_list, int sg_len, 
> +               int total_len, unsigned long key)
> +{
> +    struct mv2p_eth_info *qi = (struct mv2p_eth_info *)sc->driver_private;
> +    volatile struct eth_bd *txbd, *txfirst;
> +    char *bp;
> +    int i, txindex;
> +
> +    // Find a free buffer
> +    txbd = txfirst = qi->txbd;
> +    if ((txbd->status & BD_FREE) == 0) {
> +#ifdef CYGPKG_NET
> +        panic ("No free xmit buffers");

Is panicing the right thing to do here? I would of thought discarding
the packet would be a much better solution, so that you can keep on
running and let the higher layers do a retry.

> +
> +        cdl_option CYGNUM_IO_SERIAL_POWERPC_MV2P_SERIAL0_BAUD {
> +            display       "Baud rate for the Memec Virtex-II/Pro serial port 0 driver"
> +            flavor        data
> +            legal_values  { 115200 }
> +            default_value 115200

Does it only support one fixed baud rate?


> +    cdl_component CYGPKG_IO_SERIAL_POWERPC_MV2P_TESTING {
> +        display    "Testing parameters"
> +        flavor     bool
> +        calculated 1
> +
> +        implements CYGINT_IO_SERIAL_TEST_SKIP_38400
> +        implements CYGINT_IO_SERIAL_TEST_SKIP_57600
> +        implements CYGINT_IO_SERIAL_TEST_SKIP_PARITY_EVEN

I suspend there should be more skip interfaces here, but i've not
checked.

> +    cdl_component CYGPKG_DEVICES_WATCHDOG_POWERPC_PPC405_OPTIONS {
> +        display "ppc405 watchdog build options"
> +        flavor  none
> +        description   "
> +            Package specific build options including control over
> +            compiler flags used only in building this package,
> +            and details of which tests are built."
> +

There should be no need for this component. You can have the
CFLAGS_ADD and CLAGS_REMOVE a level up.

> +        cdl_option CYGPKG_DEVICES_WATCHDOG_POWERPC_PPC405_CFLAGS_ADD {
> +            display "Additional compiler flags"
> +            flavor  data
> +            no_define
> +            default_value { "" }
> +            description   "
> +                This option modifies the set of compiler flags for
> +                building the watchdog device. These flags are used in addition
> +                to the set of global flags."
> +        }
> +
> +        cdl_option CYGPKG_DEVICES_WATCHDOG_POWERPC_PPC405_CFLAGS_REMOVE {
> +            display "Suppressed compiler flags"
> +            flavor  data
> +            no_define
> +            default_value { "" }
> +            description   "
> +                This option modifies the set of compiler flags for
> +                building the watchdog device. These flags are removed from
> +                the set of global flags if present."
> +        }
> +
> +    }
> +}

> +## FIXME
> +##   This is a workaround to a problem which is totally unexplainable.
> +##   If ^C support is enabled, eCos applications make a call into RedBoot
> +##   to enable the serial port interrupts.  However, the call into RedBoot
> +##   fails with an illegal instruction exception every time.  There is no
> +##   understandable reason for this, but at the moment the only safe thing
> +##   is to not support this feature.
> +    requires      { (CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT == 0) }
> +## FIXME

Any new ideas why this is?

> +
> +    requires      { CYGHWR_HAL_POWERPC_PPC4XX == "405" }
> +
> +    define_proc {
> +        puts $::cdl_system_header "#define CYGBLD_HAL_TARGET_H   <pkgconf/hal_powerpc_ppc40x.h>"
> +        puts $::cdl_system_header "#define CYGBLD_HAL_PLATFORM_H <pkgconf/hal_powerpc_mv2p.h>"
> +        puts $::cdl_system_header "#define CYGBLD_HAL_PLF_IO_H   <cyg/hal/plf_io.h>"
> +
> +        puts $::cdl_header "#define HAL_PLATFORM_CPU    \"PowerPC 405\""
> +        puts $::cdl_header "#define HAL_PLATFORM_BOARD  \"Memec Virtex-II/Pro (MV2P)\""
> +        puts $::cdl_header "#define HAL_PLATFORM_EXTRA  \"\""
> +    }
> +
> +    cdl_component CYG_HAL_STARTUP {
> +        display       "Startup type"
> +        flavor        data
> +        legal_values  {"RAM" "ROM" "ROMRAM"}
> +        default_value {"RAM"}
> +        no_define
> +        define -file system.h CYG_HAL_STARTUP
> +        description   "
> +           This option is used to control where the application program will
> +           run, either from RAM or ROM (flash) memory.  ROM based applications
> +           must be self contained, while RAM applications will typically assume
> +           the existence of a debug environment, such as GDB stubs."
> +    }
> +
> +    cdl_option CYGHWR_HAL_POWERPC_CPU_SPEED {
> +        display          "Development board clock speed (MHz)"
> +        flavor           data
> +        legal_values     { 100 300 }
> +        default_value    100
> +        description      "
> +           MV2P Development Boards have various system clock speeds
> +           depending on the processor fitted.  Select the clock speed
> +           appropriate for your board so that the system can set the serial
> +           baud rate correctly, amongst other things."
> +    }
> +
> +    cdl_option CYGHWR_HAL_POWERPC_MEM_SPEED {
> +        display          "Development board memory bus speed (MHz)"
> +        flavor           data
> +        legal_values     100
> +        default_value    100
> +        description      "
> +           MV2P Development Boards have various system clock speeds
> +           depending on the processor fitted.  Select the clock speed
> +           appropriate for your board so that the system can set the serial
> +           baud rate correctly, amongst other things."

This Description does not seem correct.

I don't have time to look at the rest at the moment...

        Andrew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]