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

[Marek Vasut <marex@denx.de>]

On Monday, December 28, 2015 at 06:08:52 PM, Daniel Schwierzeck wrote:
> 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.

We do this in C on ARM, so I see no problem with this.

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

I am not saying all, but a list of register writes should be easy to convert.

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

We have SRAM to place stack in, so 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.