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

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