[U-Boot] [PATCH 7/7] Tegra30: Add/enable Cardhu build (T30 reference board)

[Tom Warren]

Stephen,

On Wed, Oct 3, 2012 at 1:46 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 10/02/2012 04:45 PM, Tom Warren wrote:
>> This build is stripped down. It boots to the command prompt.
>> GPIO is the only peripheral supported. Others TBD.
>
>> diff --git a/board/nvidia/whistler/Makefile b/board/nvidia/cardhu/Makefile
>> similarity index 94%
>> copy from board/nvidia/whistler/Makefile
>> copy to board/nvidia/cardhu/Makefile
>> index 913f1ce..a910577 100644
>> --- a/board/nvidia/whistler/Makefile
>> +++ b/board/nvidia/cardhu/Makefile
>> @@ -24,6 +24,10 @@
>>
>>  include $(TOPDIR)/config.mk
>>
>> +ifneq ($(OBJTREE),$(SRCTREE))
>> +$(shell mkdir -p $(obj)../common)
>> +endif
>
> Hmm. Surely both or neither Whistler and Cardhu need this? Either this
> isn't needed, or it's wrong in Whistler before this series.

This work was done on current u-boot-tegra/next (actually on
next-before-last, then rebased before creating the patches), but this
is git-format being overzealous with -C -C - I got this Makefile from
our internal repo, IIRC. The ..common stuff isn't needed, as you say.
I'll remove it in v2. Whistler's Makefile in current /next is OK.

>
>> diff --git a/arch/arm/include/asm/arch-tegra/gp_padctrl.h b/include/configs/cardhu.h
>> similarity index 55%
>> copy from arch/arm/include/asm/arch-tegra/gp_padctrl.h
>> copy to include/configs/cardhu.h
>> index d347e97..bfadbff 100644
>
> Uggh. git format-patch is certainly being over-zealous there, and
> equally failing to find the presumably much more familiar other Tegra
> config files:-(

Yep. I wanted to use -C -C because it did get the closest source right
most of the time - without it every file just looks like a new file
w/gazillions of new lines. In this case, though (and in cardhu.c), it
got it wrong.

>
>> diff --git a/include/configs/tegra20-common.h b/include/configs/tegra30-common.h
>> similarity index 77%
>> copy from include/configs/tegra20-common.h
>> copy to include/configs/tegra30-common.h
>
> Rather than duplicating this whole file, I wonder if it wouldn't be
> better to have tegra*-common.h include tegra-common.h with all the
> common stuff, and factor it out.

It would be better, but something I was hoping to leave til later. But
I'll do it in v2 of this patch series.

>
>> -#define CONFIG_SYS_BAUDRATE_TABLE    {4800, 9600, 19200, 38400, 57600,\
>> -                                     115200}
>
> We should remove that from tegra20-common.h

I tried to avoid T20-only edits because I wanted this series to be
T30-only as much as possible. But if I'm gonna merge 'em, I can take
it out then.

>
>>  /* include default commands */
>>  #include <config_cmd_default.h>
>> -#define CONFIG_PARTITION_UUIDS
>> -#define CONFIG_CMD_PART
>
> Seems like this should be the same on all Tegra.
>
>> -#define CONFIG_LOADADDR              0x408000        /* def. location for kernel */
>> +#define CONFIG_LOADADDR              0x80408000      /* def. location for kernel */
>
>> -#define CONFIG_SYS_LOAD_ADDR         (0xA00800)      /* default */
>> +#define CONFIG_SYS_LOAD_ADDR         (0x80A00800)    /* default */
>
> Should LOADADDR and SYS_LOAD_ADDR match? Is only one of those useful?

I grepped around a bit and it seems some code uses LOADADDR and some
uses SYS_LOAD_ADDR, and some config files make one == the other. So I
left 'em both in, with new T30-compatible addresses.  If someone wants
to see if one can be dropped at a later date, that's cool.

>
>> -#define CONFIG_STACKBASE     0x2800000       /* 40MB */
>> +#define CONFIG_STACKBASE     0x82800000      /* 40MB */
>
> Oh, how long is that used for? I hope the stack is dynamically allocated
> during relocation... That (existing Tegra20) value clashes with the
> ramdisk_addr_r I picked in my recent patch "ARM: tegra: use standard
> variables to define load addresses".

Don't know how/when it's used, just ported it to T30 addressing. I can
look into it in V2.

>
>> -#define CONFIG_SYS_TEXT_BASE 0x0010c000
>> +#define CONFIG_SYS_TEXT_BASE 0x8010e000
>
> Why not 8010c0000? Is the SPL so large it doesn't fit? I suppose it's
> fine to have different SPL sizes on the two SoCs.

Yep, in my initial porting to T30, SPL was too big to fit into 16K, so
I bumped it to 24K.  I'll revisit the SPL size after commonizing cpu.c
to see if it's shrunk enough to fit now.

Thanks,

Tom