[U-Boot] [PATCHv2 3/3] A320: Add support for Faraday A320 evaluation board

[Po-Yu Chuang]

Darius Augulis,

2009/7/2 Darius Augulis <augulis.darius at gmail.com>:
> Hi Po-Yu,
> On 07/01/2009 02:13 PM, Po-Yu Chuang wrote:
>> This patch adds support for A320 development board from Faraday. This
>> board
>> uses FA526 processor by default and has 512kB and 32MB NOR flash, 64M RAM.
>> FA526 is an ARMv4 processor and uses the ARM920T source in this patch.
> It's very interesting. Please find my recent post with patch for NAS4220. It
> has CS3516 SoC with the same(?) FA526 core.
> Few comments inline below.

>> diff --git a/board/faraday/a320/config.mk b/board/faraday/a320/config.mk
>> new file mode 100644
>> index 0000000..7573bbd
>> --- /dev/null
>> +++ b/board/faraday/a320/config.mk
>> +# Faraday A320 board with FA526/FA626TE/ARM926EJ-S cpus
>> +# A320 has 1 bank of 64 MB DRAM (after remapped)
>> +#
>> +# 0000'0000 to 0400'0000
>> +#
>> +# Linux-Kernel is expected to be at 0000'8000, entry 0000'8000
>> +#
>> +# we load ourself to 03f8'0000
>> +#
>> +# download area is 0200'0000
>> +
>> +TEXT_BASE = 0x03f80000
>
> where is your physical DRAM base?
> Where does your system boot from? Does it execute code directly from Flash
> memory? I am asking, because CS351x does that very strange: some hardware(?)
> locig copies 2K from Flash base to internal SDRAM, mapped to 0x0 address.
> After that it starts execute code from SDRAM.
> This caused me to change cpu/arm920t/start.S and make linker script.
> You didn't such modifications, so I understand, this is Gemini specific, not
> Faraday FA526 core?

After power on, cpu starts from ROM (at 0x0) which is "_start" in
cpu/arm920t/start.S.
Then the "lowlevel_init" routine in my patch does the following things:
"copy_code" copies u-boot to SDRAM (at 0x10000000).
The later "remap" routine modifies the setting of the AHB controller.
SDRAM base becomes 0x0. ROM base becomes 0x80000000.

It sounds like your hardware (?) works similar to what I do in "lowlevel_init".

I have to do this strange remap because other boot loader of our
company behaves like this
and our kernel and non-OS verification programs depends on it (SDRAM base 0x0).
Therefore, TEXT_BASE is 0x03f80000 rather than 0x13f80000.


> Should be possibility to make something common for your SoC and Gemini
> processors?

Yes.
After reading your patch, I found that it looks like your SoC use
Faraday's timer IP FTTMR010.
Maybe we should do something about it.

>> diff --git a/board/faraday/a320/lowlevel_init.S
>> b/board/faraday/a320/lowlevel_init.S
>> new file mode 100644
>> index 0000000..2adb9ef
>> --- /dev/null
>> +++ b/board/faraday/a320/lowlevel_init.S
>> +.globl lowlevel_init
>> +lowlevel_init:
>> +       mov     r11, lr
>> +
>> +       led     0x0
>> +
>> +       /* if REMAP bit is set ->  memory had been initialzed */
>> +
>> +       ldr     r0, =CONFIG_SYS_AHBC_BASE
>> +       ldr     r1, [r0, #FTAHBC020_OFFSET_ICR]
>> +       tst     r1, #FTAHBC020_ICR_REMAP                @ test REMAP bit
>> +       bne     skip_remap
>> +
>> +       led     0x1
>> +
>> +       bl      init_sdmc
>> +
>> +       led     0x2
>> +
>> +       /*
>> +        * copy U-Boot to RAM
>> +        */
>> +copy_code:
>> +       ldr     r0, =ROM_DEFAULT_BASE   /* r0<- source address     */
>> +       ldr     r1, =SDRAM_DEFAULT_BASE /* r1<- target address     */
>> +
>> +       ldr     r2, .LC5
>> +       ldr     r3, .LC6
>> +       sub     r2, r3, r2              /* r2<- size of armboot
>>  */
>> +       add     r2, r0, r2              /* r2<- source end address
>> */
>> +
>> +       led     0x3
>> +
>> +copy_loop:
>> +       ldmia   r0!, {r3-r10}           /* copy from source address [r0]
>>  */
>> +       stmia   r1!, {r3-r10}           /* copy to   target address [r1]
>>  */
>> +       cmp     r0, r2                  /* until source end addreee [r2]
>>  */
>> +       ble     copy_loop
>> +
>> +       led     0x4
>
> do you really need to repeat reallocation? it is done in start.S...

explained above. I have to do this to make the later "remap" work.

>> +/*
>> + * This code will remap the memory ROM and SDRAM
>> + * ROM will be placed on 0x80000000 SDRAM will jump to 0x0
>> + */
> why are you doing this remap?

explained above.

>> +remap:
>> +       ldr     r0, =CONFIG_SYS_SDMC_BASE
>> +
>> +       /* first adjust sdram */
>> +       write32 B0_BSR_A, B0_BSR_D2
>> +
>> +       /* then remap */
>> +       ldr     r3, =CONFIG_SYS_AHBC_BASE
>> +       ldr     r4, [r3, #FTAHBC020_OFFSET_ICR]
>> +       orr     r4, r4, #FTAHBC020_ICR_REMAP            @ Set REMAP bit
>> +       str     r4, [r3, #FTAHBC020_OFFSET_ICR]
>> +
>> +       mov     pc, lr
>> diff --git a/cpu/arm920t/faraday/ftsmc020.c
>> b/cpu/arm920t/faraday/ftsmc020.c
>
> I think this should go to drivers/net

No, this is static memory controller for nor flash.

>> +/* delay x useconds AND perserve advance timstamp value */
>> +void udelay (unsigned long usec)
>> +{
>> +       long tmo = usec * (TIMER_CLOCK / 1000) / 1000;
>> +       unsigned long now, last = readl(&tmr->timer3_counter);
>> +
>> +       debug ("%s(%lu)\n", __func__, usec);
>> +       while (tmo>  0) {
>> +               now = readl(&tmr->timer3_counter);
>> +               if (now>  last) /* count down timer overflow */
>
> please check your patch with checkpatch.pl script.
> It would warn you about such code style errors.

Do you mean no braces for single statement block?
Itcomes from linux coding style.

I use Lindent -pcs which is suggested in u-boot coding style.
It adds spaces before parameters to function calls.
This causes checkpatch.pl to create a lot of warning.
checkpatch.pl from linux doesn't seem to work well with u-boot coding style,
but it is helpful still. Thanks.


regards,
Po-Yu Chuang