[U-Boot] [PATCH] ARM: tegra: add Colibri T30 board support

Stefan Agner stefan at agner.ch
Sat Aug 2 15:24:59 CEST 2014


Am 2014-07-31 23:55, schrieb Simon Glass:
> Hi Stefan,
> 
> On 31 July 2014 19:00, Stefan Agner <stefan at agner.ch> wrote:
>> Hi Simon,
>>
>> Am 2014-07-31 19:41, schrieb Simon Glass:
>>> Hi Stefan,
>>>
>>> On 31 July 2014 18:36, Stefan Agner <stefan at agner.ch> wrote:
>>>>
>>>> This adds board support for the Toradex Colibri T30 module.
>>>>
>>>
>>> A few quick questions below...
>>>
>>>
>>>>
>>>> Working functions:
>>>> - SD card boot
>>>> - eMMC environment and boot
>>>> - USB host/USB client (on the dual role port)
>>>> - Network (via ASIX USB)
>>>>
>>>> Signed-off-by: Stefan Agner <stefan at agner.ch>
>>>> ---
>>>>  arch/arm/Kconfig                                   |   4 +
>>>>  arch/arm/dts/Makefile                              |   1 +
>>>>  arch/arm/dts/tegra30-colibri.dts                   |  84 +++++
>>>>  arch/arm/include/asm/mach-types.h                  |  13 +
>>>>  board/toradex/colibri_t30/Makefile                 |   6 +
>>>>  board/toradex/colibri_t30/colibri_t30.c            |  52 +++
>>>>  .../colibri_t30/pinmux-config-colibri_t30.h        | 360 +++++++++++++++++++++
>>>>  include/configs/colibri_t30.h                      |  73 +++++
>>>>  8 files changed, 593 insertions(+)
>>>>  create mode 100644 arch/arm/dts/tegra30-colibri.dts
>>>>  create mode 100644 board/toradex/colibri_t30/Makefile
>>>>  create mode 100644 board/toradex/colibri_t30/colibri_t30.c
>>>>  create mode 100644 board/toradex/colibri_t30/pinmux-config-colibri_t30.h
>>>>  create mode 100644 include/configs/colibri_t30.h
>>>>
> ...
>>>> diff --git a/arch/arm/include/asm/mach-types.h b/arch/arm/include/asm/mach-types.h
>>>> index 440b041..560924e 100644
>>>> --- a/arch/arm/include/asm/mach-types.h
>>>> +++ b/arch/arm/include/asm/mach-types.h
>>>> @@ -1106,6 +1106,7 @@ extern unsigned int __machine_arch_type;
>>>>  #define MACH_TYPE_OMAP5_SEVM           3777
>>>>  #define MACH_TYPE_ARMADILLO_800EVA     3863
>>>>  #define MACH_TYPE_KZM9G                4140
>>>> +#define MACH_TYPE_COLIBRI_T30          4493
>>>>
>>>>  #ifdef CONFIG_ARCH_EBSA110
>>>>  # ifdef machine_arch_type
>>>> @@ -14235,6 +14236,18 @@ extern unsigned int __machine_arch_type;
>>>>  # define machine_is_kzm9g()    (0)
>>>>  #endif
>>>>
>>>> +#ifdef CONFIG_MACH_COLIBRI_T30
>>>> +# ifdef machine_arch_type
>>>> +#  undef machine_arch_type
>>>> +#  define machine_arch_type    __machine_arch_type
>>>> +# else
>>>> +#  define machine_arch_type    MACH_TYPE_COLIBRI_T30
>>>> +# endif
>>>> +# define machine_is_colibri_t30()      (machine_arch_type == MACH_TYPE_COLIBRI_T30)
>>>> +#else
>>>> +# define machine_is_colibri_t30()      (0)
>>>> +#endif
>>>
>>>
>>> Do we actually need this machine type stuff anymore?
>>>
>>
>> That way we can also boot the 3.1 L4T Kernel, since this is the
>> (probably last) one where we get supported binary drivers for the
>> graphics part.
> 
> OK I see.
> 
>>
>>>>
>>>> +
>>>>  /*
>>>>   * These have not yet been registered
>>>>   */
>>>> diff --git a/board/toradex/colibri_t30/Makefile b/board/toradex/colibri_t30/Makefile
>>>> new file mode 100644
>>>> index 0000000..3d58a4b
>>>> --- /dev/null
>>>> +++ b/board/toradex/colibri_t30/Makefile
>>>> @@ -0,0 +1,6 @@
>>>> +# Copyright (c) 2013-2014 Stefan Agner
>>>> +# SPDX-License-Identifier:      GPL-2.0+
>>>> +
>>>> +include $(srctree)/board/nvidia/common/common.mk
>>>> +
>>>> +obj-y  += colibri_t30.o
>>>> diff --git a/board/toradex/colibri_t30/colibri_t30.c b/board/toradex/colibri_t30/colibri_t30.c
>>>> new file mode 100644
>>>> index 0000000..6c7c62d
>>>> --- /dev/null
>>>> +++ b/board/toradex/colibri_t30/colibri_t30.c
>>>> @@ -0,0 +1,52 @@
>>>> +/*
>>>> + *  (C) Copyright 2014
>>>> + *  Stefan Agner <stefan at agner.ch>
>>>> + *
>>>> + * SPDX-License-Identifier:    GPL-2.0+
>>>> + */
>>>> +
>>>> +#include <common.h>
>>>> +#include <asm/arch/pinmux.h>
>>>> +#include <asm/arch/gp_padctrl.h>
>>>> +#include "pinmux-config-colibri_t30.h"
>>>> +#include <i2c.h>
>>>> +#include <asm/gpio.h>
>>>> +
>>>> +#define PMU_I2C_ADDRESS                0x2D
>>>> +#define MAX_I2C_RETRY          3
>>>
>>>
>>> Are these used?
>>>
>>
>> The address is correct, but not used right now. Should I remove?
> 
> I think so.
> 
>>
>>>>
>>>> +
>>>> +/*
>>>> + * Routine: pinmux_init
>>>> + * Description: Do individual peripheral pinmux configs
>>>> + */
>>>> +void pinmux_init(void)
>>>> +{
>>>> +       pinmux_config_pingrp_table(tegra3_pinmux_common,
>>>> +                                  ARRAY_SIZE(tegra3_pinmux_common));
>>>> +
>>>> +       pinmux_config_pingrp_table(unused_pins_lowpower,
>>>> +                                  ARRAY_SIZE(unused_pins_lowpower));
>>>> +
>>>> +       /* Initialize any non-default pad configs (APB_MISC_GP regs) */
>>>> +       pinmux_config_drvgrp_table(colibri_t30_padctrl,
>>>> +                                  ARRAY_SIZE(colibri_t30_padctrl));
>>>> +}
>>>> +
>>>> +/*
>>>> + * Enable AX88772B USB to LAN controller
>>>> + */
>>>> +void pin_mux_usb(void)
>>>> +{
>>>> +       /* Enable LAN_VBUS */
>>>> +       gpio_request(GPIO_PDD2, NULL);
>>>> +       gpio_direction_output(GPIO_PDD2, 1);
>>>> +
>>>> +       /* Reset ASIX using LAN_RESET */
>>>> +       gpio_request(GPIO_PDD0, NULL);
>>>> +       gpio_direction_output(GPIO_PDD0, 0);
>>>> +
>>>> +       udelay(5);
>>>> +
>>>> +       gpio_set_value(GPIO_PDD0, 1);
>>>
>>>
>>> You are using device tree for sdhci - shouldn't we use it for USB also?
>>>
>>
>> The Colibri T30 has a ASIX USB to Ethernet chip on its board. We
>> reset/power the ASIX here. It is a very board specific reset/powering,
>> hence I put it in here.
>>
>> In my initial patches I had it in the nvidia,phy-reset-gpio and
>> nvidia,vbus-gpio properties. Technically, it would work to have this
>> GPIOs in the device tree as USB properties, but I think this would be
>> logically wrong...
> 
> For VBUS I think it would be correct to put it in the USB. For the
> reset, I'm not sure - it looks like a separate pin so putting it in
> the device tree for USB would be wrong I think.
> 
> What does the kernel do for these?
> ...

Right now, the Kernel does not touch the reset signal on that device.
I'm not sure what happens if we go in suspend mode, need to check that
on the kernel side once.

Ok, when I think about it again, it totally make sense to use the VBUS
property since this GPIO is really connected to the VBUS pin of that USB
device...

--
Stefan


More information about the U-Boot mailing list