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

[Daniel Schwierzeck]

Am 28.12.2015 um 16:52 schrieb Marek Vasut:
> On Monday, December 28, 2015 at 04:48:41 PM, Wills Wang wrote:
>> 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, i configure initial stack in SRAM and
>> convert
>> these code to c, and put them in arch_cpu_init(the first available c
>> entry), but
>> hardware don't work. if i keep the above three points(RESET/RTC/PLL) in
>> lowlevel_init, put other code in arch_cpu_init, board work fine.
> 
> So let me ask the question again -- why does the C code not work ? Did you
> investigate the reason why does the C code not work ?
> 
> Can you share the change you did to convert things to C code ? There might
> be a bug in that too ...
> 

it is not a matter of C or assembly, but of the init sequence currently
implemented on MIPS. The main purpose of lowlevel_init() is to
initialize memory controllers and DRAM. This has to be done in assembly
because we have no C runtime environment available at that point.

Also compiling U-Boot as PIC requires to enable MIPS ABI function calls
in gcc (-mabicalls). This always creates function prologues and
epilogues which are utilizing the stack pointer. Thus we cannot simply
convert all lowlevel_init functions to C.

Moving code from lowlevel_init to arch_cpu_init or elsewhere will not
work because that code runs too late then. Simply moving the stack to
SRAM will also not help because lowlevel_init runs before the stack is
available.

Before Wills can convert his code to C, we need to rework the init
sequence in start.S. But that is out of the scope of this patch series.
I will try to prepare some patches in the next days. The SRAM part
should be easy. But the cache line lock need some more work and testing.

In the meantime Wills could send a new patch series, which addresses all
other issues except lowlevel_init. The function ddr_tap_init can be
already converted to C because it is called from init_dram where a C
runtime environment is available. So we could have at least a working
patch series and could finalize the review of the other patches. After I
have updated u-boot-mips/next branch, Wills can rebase and convert
lowlevel_init to C.

-- 
- Daniel