[U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs

[Wills Wang]

On 12/28/2015 09:47 PM, Marek Vasut wrote:
> On Monday, December 28, 2015 at 12:17:41 PM, Wills Wang wrote:
> [...]
>>>> "lowlevel_init.S" can't be dropped.
>>> Thank you very much for all the effort you put into investigating and
>>> explaining why this SRAM area cannot be used ... not. From my side,
>>> consider this patch to be NAKed.
>>>
>>> Best regards,
>>> Marek Vasut
>> "lowlevel_init.S" can't be entirely dropped, there are three main
>> reasons for this.
> Right, so I checked how these are performed and whether these can or cannot
> be done from C code.
>
>> 1. Chip has an original issue, need reset "WLAN"  three times to avoid
>> it when power up.
>   26 /* These three wlan reset will avoid original issue,
>   27 so full chip reset isn't needed here. */
>   28     set_reg(0xb806001c, 0x00c06b30)
>   29     nop
>   30     set_reg(0xb806001c, 0x00c06330)
>   31     nop
>   32     set_reg(0xb806001c, 0x00c06b30)
>   33     nop
>   34     set_reg(0xb806001c, 0x00c06330)
>   35     nop
>   36 reset_wlan:
>   37     set_reg(0xb806001c, 0x00c06b30)
>   38     nop
>   39     set_reg(0xb806001c, 0x00c06330)
>   40     nop
>
> Yes, these can be done from C code.
>
>> 2. Need reset RTC and force to wake MAC, or chip can't work .
>   73 /* RTC reset */
>   74     set_reg(0x1810704c, 0x00000003)
>   75     nop
>   76     nop
>   77     set_reg(0x18107040, 0x00000000)
>   78     nop
>   79     nop
>   80     set_reg(0x18107040, 0x00000001)
>   81     nop
>
> DTTO.
>
>> 3. Need initialise PLL clock for CPU/DDR/AHB, the default clock is
>> 25MHz, the interval from
>> power-up to printout is about 5s.
> The PLL configuration is again a set of writes to some random registers.
> This can again be done from the C code.
>
>> So, assembler code could not be avoided even using SRAM for c stack.
> I am not convinced, see above. Please show me where exactly is the assembly
> code imperative. I simply do not see it.
>
>> Now that chipmaker don't open SRAM of this chip and recommend DDR for
>> initial stack, i think
>> that using DDR should be more consolidated.
> I do not care what the chip maker says unless there is an explicit explanation
> why they require that. Most often, these sorts of "limitations" are in place
> only because the chipmaker has incompetent software engineers.
>
> So I would like to see either the SRAM or locked cacheline used for stack and
> then lowlevel init converted into proper C code unless there is an explicit
> explanation why this can not be done. And by explicit I mean for example a
> snippet of code which cannot be converted into C code. Note that asm volatile
> can still be used to contain such small bits of assembler code if needed be.
>
> Best regards,
> Marek Vasut
>
>
I made a series of tries in this, and  i can confirm that the SRAM can be
used for c stack, but the prerequisites for this are that the above two
points (1&2) must be execute in lowlevel_init. i has converted these code
to C, and put them(1&2) at arch_cpu_init, but hardware don't work, i 
guess that
these parts may be associated with memory submodule of this chip.

-- 
Best Regards
Wills