[U-Boot] [PATCH 2/2] TT-01: add basic board support for HALE TT-01

[Stefano Babic]

On 10/06/2011 03:07 PM, Helmut Raiger wrote:
> Hi Stefano,
> 

Hi Helmut,

>>
>> Reading this file I do not see (except setting the AIPS) no good reason
>> to write this part in assembly. Everything can be done for example in
>> board_early_init_f, and even better we can rationalize this code and put
>> it into arch/cpu/arm1136/mx31.
> 
> As far as I understood this is called from arch/arm/cpu/arm1136/start.S
> before stack is setup. I don't know much about C-calling convention
> on the arm1136, but this might be the reason why it's done in assembly.
> I'd rather not touch start.S, so I'll copy the file over from mx31pdk?

A way I used in the past is to set up the stack in the lowlevel_init
assembly routine and then calling my own C function. Again, probably is
not needed anymore, but you can check this.

The assembly start.S ends calling board_init_f(), and this runs before
relocation. At this point, the stack pointer is already set. The
board_init_f() then calls board_early_init_f(), if
CONFIG_BOARD_EARLY_INIT_F is set, and you can add your specific
initialization here.

You can take a look at the patches I sent last month for the flea3
board. I factorized code for the mx35. I know, this does not help for
mx31, but it is very similar and both arm1136. I have not touched
start.S from the arm1136 drirectory(this is general code), and the DRAM
setup is done in C code.

> We are about to display large compressed bitmaps in u-boot, that's why
> the heap is that large. The frame buffer driver patch
> http://patchwork.ozlabs.org/patch/113341/ is still being reviewed,
> that is why I left it out here (but kept the heap size).

Ok, agreed.

> Additionally I don't care much about time and space here. The production
> units will boot from NAND and we'll use a different setup there.
> That's why I reserved 1MB for u-boot, I simply didn't want it to overwrite
> my environment when being reprogrammed.

Ok, understood, thanks for clarification.

> 
>>> +#define CONFIG_SYS_FLASH_CFI        /* Flash memory is CFI compliant */
>>> +#define CONFIG_FLASH_CFI_DRIVER        /* Use drivers/cfi_flash.c */
>>> +#define CONFIG_FLASH_SPANSION_S29WS_N
>>> +/* TODO: bluetechnix did undefine these for some purpose
>> if you do not need to undefine, you can drop this comment. Maybe there
>> is no issues with lock/unlock mechanism with the flash you have chosen.
> 
> Bluetechnix is the supplier of the SOM we are using. Their original
> version of u-boot (1.2 or so) defined these values. So the flash is
> definitely the same. I'd like to review this later, therefore the TODO.

Ok, thanks. Probably it is worth you add this explanation to the
comment, so nobody will ask you again ;-)

>>> + * on TT-01 UART1 pins are used by Audio, so we use UART2
>>> + *   make sure that the transceiver is enabled during PL=1 for testing!
>> What does it mean PL=1 ?
>>
> Nothing that concerns u-boot, it means P(ower)L(evel)=1. The TT-01
> implements a hardware that turns off components depending on
> the said power level. In PL=1 the RS232 transceiver is usually off.

Understood. Add simply these line to the comment, they complete the
explanation.

> 
>>> +/* this is currently not supported, mxc_nand.c is too incomplete for
>>> it */
>> Only for my understanding: Which is the issue with mxc_nand.c ? At the
>> moment, we have several boards using it, and I wonder it is incomplete.
>> What do you mean ?
> 
> Part of this whole mess is, that I actually wrote this board support 2
> years ago and simply rebased to finally contribute the stuff. Probably
> there is no issue with mxc_nand.c any more (and I don't remember
> what was the problem).

Ok. Probably you need only to retest NAND again, and check if there are
open issues.

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
=====================================================================