From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Mon, 28 Dec 2015 16:52:35 +0100 Subject: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs In-Reply-To: References: <1450956123-17606-1-git-send-email-wills.wang@live.com> <201512281447.23308.marex@denx.de> Message-ID: <201512281652.35289.marex@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 ...