From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Mon, 28 Dec 2015 18:33:31 +0100 Subject: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs In-Reply-To: <56816CA4.6070506@gmail.com> References: <1450956123-17606-1-git-send-email-wills.wang@live.com> <201512281652.35289.marex@denx.de> <56816CA4.6070506@gmail.com> Message-ID: <201512281833.32031.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 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.