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

[Stefan Agner]

Am 2014-07-31 20:21, schrieb Stephen Warren:
> On 07/31/2014 11:36 AM, Stefan Agner wrote:
>> This adds board support for the Toradex Colibri T30 module.
>>
>> Working functions:
>> - SD card boot
>> - eMMC environment and boot
>> - USB host/USB client (on the dual role port)
>> - Network (via ASIX USB)
> 
>>   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 +++++
> 
> I think in latest u-boot/master, you'll also need to add
> configs/colibri_t30_defconfig.
> 

I actually created them but forgot the git add... Next version will
contain those files too:

board/toradex/colibri_t30/Kconfig
board/toradex/colibri_t30/MAINTAINERS
configs/colibri_t30_defconfig


>> diff --git a/arch/arm/dts/tegra30-colibri.dts b/arch/arm/dts/tegra30-colibri.dts
> 
>> +	/* EHCI instance 0: USB1_DP/N -> USBC_P/N */
>> +	usb at 7d000000 {
>> +		status = "okay";
>> +		dr_mode = "otg";
>> +	};
> 
> For OTG support, VBUS needs to be able to be turned on/off. Should
> this port be host-mode, or a VBUS GPIO defined?
> 

This port is actually ment to be client by default, I will change
dr_mode to "peripheral" in the next patch.

We do not have real OTG support on that port since the ID-Pin is not
connected (the Colibri standard has all pins 3.3V level only, hence we
cannot connect the ID-Pin). This port is more a dual-role port. On the
Evaluation Board, we have a pin connected to allow automatic switching
between the two roles, while the VBUS stuff is handled by hardware
(using the ID-Pin). However, this automatic switching is currently not
implemented. Hence I would like to have that port as peripheral by
default while having the other as host.

>> diff --git a/board/toradex/colibri_t30/colibri_t30.c b/board/toradex/colibri_t30/colibri_t30.c
> 
>> +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);
>> +}
> 
> It might be nice to remove the blank lines around the udelay() call; I
> initially didn't notice that GOPIO_PDD0 was manipulated by the code
> both before and after the udelay() and hence there was already a
> comment saying what GPIO_PDD0 controlled. Nestling the lines together
> would make this more obvious.
> 

Agreed.

>> diff --git a/include/configs/colibri_t30.h b/include/configs/colibri_t30.h
> 
>> +#define CONFIG_I2C_MULTI_BUS
>> +#define CONFIG_SYS_MAX_I2C_BUS		TEGRA_I2C_NUM_CONTROLLERS
> 
> Are those needed? They aren't defined in e.g. the Beaver config header.
> 

Since we do not need to configure the PMIC, its not required no. I will
remove them.

>> +#define BOARD_EXTRA_ENV_SETTINGS \
>> +	"board_name=colibri-eval-v3\0" \
>> +	"fdtfile=tegra30-colibri-eval-v3.dtb\0"
> 
> It'd be nice to name the board the same in U-Boot as the kernel DT
> filename. Then you wouldn't need to manually override the default
> values here.

This is a somewhat complicated topic in our case. Our products are
named:

"Colibri T20"
"Colibri T30"
"Apalis T30"

Since quite a long time, we use those names, except replacing the space
by an underline character and preferable use small caps. Hence e.g. the
U-Boot configurations in the downstream tree:

colibri_t20_config
colibri_t30_config
apalis_t30_config

However, in the kernel world, since device tree was introduced there is
this reverse notation, SoC-board.dts... e.g. tegra30-colibri_t30.dts. We
descided to drop that t30, since its somewhat duplicated. Not sure this
was the right description, but its in the kernel that way right now.

Additionally, this whole carrier board (Evaluation Board v3)/module
(Colibri T30) relation is also taken into account at kernel side, hence
the full name today
tegra30-colibri-eval-v3.dts

Ok, because we don't have the unique board names as the other Tegra
devices have, we cannot just call the board in U-Boot as we did for the
kernel: "colibri" or "colibri-eval-v3" would be used twice, for the T20
and T30. To solve that, we could change tegra30-colibri-eval-v3.dts to
tegra30-colibri_t30-eval-v3.dts... 

Also, since most customers never change the boot loader for their board
design, I would like to avoid to have the carrier board in the boot
loaders board name. Frankly, quite a lot even don't change the kernel,
since they use the default pin assignment. Also we use the same boot
loader configuration for our three own Carrier Boards. (Btw. currently,
this is not the case for the Colibri T20. Lucas, in CC now, added back
then a similar Carrier Board/Module relation we have in the kernel. I
would actually prefer to squash this together the way this patch does it
for the Colibri T30.)

Hence we are not synchronized between the kernel dtb and the U-Boot
board name anyway... 

So the name scheme I see would be U-Boot:
colibri_t20
colibri_t30
apalis_t30

Kernel:
tegra20-colibri.dtsi (in case we can detect the RAM size)
tegra20-colibri-iris.dts
tegra20-colibri-eval-v3.dts
tegra30-colibri.dtsi
tegra30-colibri-iris.dts
tegra30-colibri-eval-v3.dts
tegra30-apalis.dtsi
tegra30-apalis-ixora.dts
tegra30-apalis-eval-v1.dts

What do you think? I could also agree to add the T30 again for the
kernel, hence tegra30-colibri_t30.dtsi and
tegra30-colibri_t30-eval-v3.dts. But I don't like the idea to have the
carrier board in the U-Boot name. In the end, everybody would use the
one colibri_t30_eval_v3 config...

>> +#include "tegra-common-ums.h"
> 
> Did you test this? I mostly developed the USB device mode support on
> Tegra124. While at some point I did test it on Beaver/Tegra30, it was
> early on and not very extensive. I'd love to hear that it works well
> for you too:-)
> 
> (BTW, I sent a patch to rename that file to tegra-common-usb-gadget.h,
> since I added DFU support too, so depending on what order TomW applies
> our patches, one of us will need to rebase)


Yes I tested this, and it works great! It's really a very nice way to
deploy the root file system. Create the partition table easily from your
desktop PC, format the partition, and just untar whatever distribution
you want. Slick!

Does DFU support NAND/and or eMMC? AFAIK it was designed more for NAND
devices wasn't it? If NAND is supported, we would even have a nice
solution for the Tegra 2 now.

--
Stefan