All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Babic <sbabic@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/4] arm, omap3: Add support for TechNexion modules
Date: Mon, 21 Nov 2011 10:59:18 +0100	[thread overview]
Message-ID: <4ECA20F6.1070503@denx.de> (raw)
In-Reply-To: <20111121164401.5b816ce0@myhost>

On 21/11/2011 09:44, Tapani Utriainen wrote:
> 
> Add support for TechNexion TAM3517 SoM
> 
> Signed-off-by: Tapani Utriainen <tapani@technexion.com>
> CC: Sandeep Paulraj <s-paulraj@ti.com>

Hi Tapani,

> ---
>  arch/arm/include/asm/mach-types.h  |    1 
>  board/technexion/tam3517/Makefile  |   49 ++++
>  board/technexion/tam3517/tam3517.c |  150 ++++++++++++
>  board/technexion/tam3517/tam3517.h |  388 +++++++++++++++++++++++++++++++++
>  boards.cfg                         |    1 
>  include/configs/tam3517.h          |  427 +++++++++++++++++++++++++++++++++++++
>  6 files changed, 1016 insertions(+)
> 

I am also porting a TAM3517 based custom board to U-Boot mainline. Maybe
we can share some experiences ;-)

> diff --git a/arch/arm/include/asm/mach-types.h b/arch/arm/include/asm/mach-types.h
> index 2d5c3bc..685b46f 100644
> --- a/arch/arm/include/asm/mach-types.h
> +++ b/arch/arm/include/asm/mach-types.h
> @@ -467,6 +467,7 @@ extern unsigned int __machine_arch_type;
>  #define MACH_TYPE_OMAP4_PANDA          2791
>  #define MACH_TYPE_TI8168EVM            2800
>  #define MACH_TYPE_TETON_BGA            2816
> +#define MACH_TYPE_TAM3517              2818

This is wrong. The mach-types.h is taken from Linux and the rule is to
always be in sync with tthe kernel. If the MACH-TYPE is not set, it must
be set in the board configuration file.


> diff --git a/board/technexion/tam3517/tam3517.c b/board/technexion/tam3517/tam3517.c
> new file mode 100644

As I said, I am also porting a similar board and I am facing the problem
to support multiple board using the same module (TAM3517). My idea was
to have a common include/configs/tam3517.h file, that is included by all
boards using the module, such as the twister and a custom boards. This
allows to factorize most of common setup.

Then we could have a board/technexion/twister board in parallel with
other boards using only the module. What do you think about ?

> +#include <asm/mach-types.h>

We do not need mach-types.h

> +#include "tam3517.h"
> +
> +#define AM3517_IP_SW_RESET	0x48002598
> +#define CPGMACSS_SW_RST		(1 << 1)

These are obsolete, too. It is (or it will be soon) common code. See
previous patches for AM 3517 (mcx board).

> +
> +/*
> + * Routine: board_init
> + * Description: Early hardware init.
> + */
> +int board_init(void)
> +{
> +	DECLARE_GLOBAL_DATA_PTR;
> +
> +	gpmc_init(); /* in SRAM or SDRAM, finish GPMC */
> +	/* board id for Linux */
> +	gd->bd->bi_arch_number = MACH_TYPE_TAM3517;

This should be removed, it is part of generic arm library.

> +#if defined(CONFIG_XR16L2751)

If I have understood the schematics, the twister board (because this
code corresponds to this board) has always a XR16L2751 UART. Should we
not drop the #ifdef ?

> +/*
> + * Routine: misc_init_r
> + */
> +int misc_init_r(void)
> +{
> +	int ctr = 0;
> +
> +	i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
> +#ifdef CONFIG_BOOT_FROM_MMC
> +	omap_set_gpio_direction(TAM3517_SW3_PIN8, 1);

This is obsolete - use the standard GPIO framework.

> +#if defined(CONFIG_DRIVER_TI_EMAC)
> +	/* allow the PHY to stabilize and settle down */
> +	do {
> +		udelay(1000);
> +		ctr++;
> +	} while (ctr < 300);
> +
> +	/*ensure that the module is out of reset*/
> +	reset = readl(AM3517_IP_SW_RESET);
> +	reset &= (~CPGMACSS_SW_RST);
> +	writel(reset, AM3517_IP_SW_RESET);
> +#endif

Drop this part - it is in EMAC initialization, not needed in board code.

> +	if (smc911x_initialize(0, CONFIG_SMC911X_BASE) <= 0)
> +		n_eth--;

Why do we need to count the interfaces ? This is already done by the
network subsystem.

> diff --git a/board/technexion/tam3517/tam3517.h b/board/technexion/tam3517/tam3517.h
> new file mode 10064

> +	/* ETK (ES2 onwards) */\
> +	MUX_VAL(CP(ETK_CLK_ES2),	(IDIS | PTU | EN  | M0)) \
> +	MUX_VAL(CP(ETK_CTL_ES2),	(IDIS | PTD | DIS | M0)) \
> +	MUX_VAL(CP(ETK_D0_ES2),		(IEN  | PTD | DIS | M0)) \
> +	MUX_VAL(CP(ETK_D1_ES2),		(IEN  | PTD | DIS | M0)) \
> +	MUX_VAL(CP(ETK_D2_ES2),		(IEN  | PTD | EN  | M0)) \

..but the pins for ETK are used as USB for EHCI-OMAP, are'nt they ? This
setup seems to me wrong.


> diff --git a/include/configs/tam3517.h b/include/configs/tam3517.h

See my previous comment regarding a common configuration file for the
module and a specific file for the boards.

> +/*
> + * High Level Configuration Options
> + */
> +#define CONFIG_ARMV7		1	/* This is an ARM V7 CPU core */

"1" is not needed, this must fixed globally.

> +
> +#define CONFIG_CMDLINE_TAG		1	/* enable passing of ATAGs */
> +#define CONFIG_SETUP_MEMORY_TAGS	1
> +#define CONFIG_INITRD_TAG		1
> +#define CONFIG_REVISION_TAG		1

Ditto.

> +#if CONFIG_DRAM_BUS_WIDTH == 16
> +#define _CONFIG_DRAM_BUS_WIDTH	"16"
> +#else
> +#ifndef CONFIG_DRAM_BUS_WIDTH
> +#define CONFIG_DRAM_BUS_WIDTH	32
> +#endif
> +#define _CONFIG_DRAM_BUS_WIDTH	"32"
> +#endif

I have not used any of these CONFIG_DRAM_BUS_WIDTH. Why do we need it ?
And I do not see code in u-boot using it. IMHO it is dead code.

> +/* USB
> + * Enable CONFIG_MUSB_HCD for Host functionalities MSC, keyboard
> + * Enable CONFIG_MUSB_UDD for Device functionalities.
> + */
> +#define CONFIG_USB_AM35X		1
> +#define CONFIG_MUSB_HCD			1

Is it working ? I do not understand. I have USB working on the twister
board, but using EHCI-OMAP and with another configuration for the pin
multiplexer.


> +/*-----------------------------------------------------------------------
> + * CFI FLASH driver setup
> + */
> +/* timeout values are in ticks */
> +#define CONFIG_SYS_FLASH_ERASE_TOUT	(100 * CONFIG_SYS_HZ)
> +#define CONFIG_SYS_FLASH_WRITE_TOUT	(100 * CONFIG_SYS_HZ)

Which CFI has the board ? I suposed none.

> +/*-----------------------------------------------------
> + * ethernet support for TAM3517
> + *-----------------------------------------------------
> + */
> +#define CONFIG_MII
> +
> +#if defined(CONFIG_CMD_NET)
> +/* Disable u-boot support for EMAC LAN, due compile problems
> +   Linux kernel support is enough to enable the interface
> +*/
> +/*
> +#define CONFIG_DRIVER_TI_EMAC
> +#define CONFIG_DRIVER_TI_EMAC_USE_RMII
> +#define CONFIG_EMAC_MDIO_PHY_NUM   0
> +#define CONFIG_ARM926EJS	1
> +*/
> +#define CONFIG_NET_RETRY_COUNT 10
> +#define CONFIG_NET_MULTI
> +
> +#define CONFIG_SMC911X          1
> +#define CONFIG_SMC911X_16_BIT	1
> +#define CONFIG_SMC911X_BASE     0x2C000000
> +#define CONFIG_SMC911X_NO_EEPROM	1
> +

The whole setup for SPL is missing. I have already implemented and
tested, and I am asking you how we can proceed at the best. Should I
post my patches (only for TAM3517), too, and then check together what is
still missing ? I can add you in the Signed-off and put you as board
maintainer, as you suggest (by the way, I have not seen a change in the
MAINTAINER file...)

Let me know what you think

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

      parent reply	other threads:[~2011-11-21  9:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-21  8:44 [U-Boot] [PATCH 2/4] arm, omap3: Add support for TechNexion modules Tapani Utriainen
2011-11-21  9:19 ` Igor Grinberg
2011-11-21  9:45 ` Wolfgang Denk
2011-11-21  9:59 ` Stefano Babic [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ECA20F6.1070503@denx.de \
    --to=sbabic@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.