Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
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, 0x0003) > >>> 75 nop > >>> 76 nop > >>> 77 set_reg(0x18107040, 0x) > >>> 78 nop > >>> 79 nop > >>> 80 set_reg(0x18107040, 0x0001) > >>> 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.
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
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, 0x0003) >>> 75 nop >>> 76 nop >>> 77 set_reg(0x18107040, 0x) >>> 78 nop >>> 79 nop >>> 80 set_reg(0x18107040, 0x0001) >>> 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 update
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
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, 0x0003) > > 75 nop > > 76 nop > > 77 set_reg(0x18107040, 0x) > > 78 nop > > 79 nop > > 80 set_reg(0x18107040, 0x0001) > > 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 ... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
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, 0x0003) 75 nop 76 nop 77 set_reg(0x18107040, 0x) 78 nop 79 nop 80 set_reg(0x18107040, 0x0001) 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. -- Best Regards Wills ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
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, 0x0003) 75 nop 76 nop 77 set_reg(0x18107040, 0x) 78 nop 79 nop 80 set_reg(0x18107040, 0x0001) 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, and i can confirm that the SRAM can be used for c stack, but the prerequisites for this are that the above two points (1&2) must be execute in lowlevel_init. i has converted these code to C, and put them(1&2) at arch_cpu_init, but hardware don't work, i guess that these parts may be associated with memory submodule of this chip. -- Best Regards Wills ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
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, 0x0003) 75 nop 76 nop 77 set_reg(0x18107040, 0x) 78 nop 79 nop 80 set_reg(0x18107040, 0x0001) 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
On 12/27/2015 08:27 PM, Marek Vasut wrote: On Sunday, December 27, 2015 at 12:37:16 PM, Wills Wang wrote: On 12/27/2015 07:04 PM, Marek Vasut wrote: On Sunday, December 27, 2015 at 11:18:25 AM, Wills Wang wrote: On 12/27/2015 06:09 PM, Marek Vasut wrote: On Sunday, December 27, 2015 at 09:07:36 AM, Wills Wang wrote: On 12/27/2015 03:38 PM, Marek Vasut wrote: On Sunday, December 27, 2015 at 08:33:26 AM, Wills Wang wrote: On 12/27/2015 02:37 AM, Marek Vasut wrote: On Saturday, December 26, 2015 at 07:29:51 PM, Wills Wang wrote: WASP is ar9341. Please do not top post. Did you try if the memory is accessible on your platform ? AR9331 I have here has the SRAM at 0xbd007000 , just like that machine in [1] . I found there is a memory segment at 0xbd00...0xbd007fff. it's independent of DDR physical memory, can be read and wrote, but hardware can't boot up if don't execute lowlevel_init.S when define CONFIG_SYS_INIT_SP_ADDR=0xbd007000 to set C stack into SRAM. Stack grows down, so of course if you put stack at the beginning of SRAM, that cannot work ;-) Put it at the end , 0xbd008000. This memory segment was mapped circularly at 0xbd00...0xbdff. So is this area at 0xbd008000 usable for stack or not ? Same times board can boot up, but in a very unstable. i use the following setting: #define CONFIG_SYS_INIT_RAM_ADDR0xbd00 Should be 0xbd007000 #define CONFIG_SYS_INIT_RAM_SIZE(32 * SZ_1K) Should be 4 KiB large. #define CONFIG_SYS_INIT_SP_OFFSET \ (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) #define CONFIG_SYS_INIT_SP_ADDR \ (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET) Did you investigate why the board has problems ? "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. 1. Chip has an original issue, need reset "WLAN" three times to avoid it when power up. 2. Need reset RTC and force to wake MAC, or chip can't work . 3. Need initialise PLL clock for CPU/DDR/AHB, the default clock is 25MHz, the interval from power-up to printout is about 5s. So, assembler code could not be avoided even using SRAM for c stack. 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. -- Best Regards Wills ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
On 12/27/2015 07:37 PM, Daniel Schwierzeck wrote: Am 27.12.2015 um 12:04 schrieb Marek Vasut: On Sunday, December 27, 2015 at 11:18:25 AM, Wills Wang wrote: On 12/27/2015 06:09 PM, Marek Vasut wrote: On Sunday, December 27, 2015 at 09:07:36 AM, Wills Wang wrote: On 12/27/2015 03:38 PM, Marek Vasut wrote: On Sunday, December 27, 2015 at 08:33:26 AM, Wills Wang wrote: On 12/27/2015 02:37 AM, Marek Vasut wrote: On Saturday, December 26, 2015 at 07:29:51 PM, Wills Wang wrote: WASP is ar9341. Please do not top post. Did you try if the memory is accessible on your platform ? AR9331 I have here has the SRAM at 0xbd007000 , just like that machine in [1] . I found there is a memory segment at 0xbd00...0xbd007fff. it's independent of DDR physical memory, can be read and wrote, but hardware can't boot up if don't execute lowlevel_init.S when define CONFIG_SYS_INIT_SP_ADDR=0xbd007000 to set C stack into SRAM. Stack grows down, so of course if you put stack at the beginning of SRAM, that cannot work ;-) Put it at the end , 0xbd008000. This memory segment was mapped circularly at 0xbd00...0xbdff. So is this area at 0xbd008000 usable for stack or not ? Same times board can boot up, but in a very unstable. i use the following setting: #define CONFIG_SYS_INIT_RAM_ADDR0xbd00 Should be 0xbd007000 #define CONFIG_SYS_INIT_RAM_SIZE(32 * SZ_1K) Should be 4 KiB large. #define CONFIG_SYS_INIT_SP_OFFSET \ (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) #define CONFIG_SYS_INIT_SP_ADDR \ (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET) Did you investigate why the board has problems ? according to the description above by Wills those three defines setup the values correctly for start.S: #define CONFIG_SYS_INIT_RAM_ADDR0xbd00 #define CONFIG_SYS_INIT_RAM_SIZE(32 * SZ_1K) #define CONFIG_SYS_INIT_SP_ADDR \ (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE) The stack pointer will then be set to the end of the SRAM area with a 16 Byte alignment. The resulting address should be 0xbd007ff0. From this address, the size of gd_t and CONFIG_SYS_MALLOC_F_LEN will be subtracted. The remaining space is available for the initial stack. Which value did you chose for CONFIG_SYS_MALLOC_F_LEN? It must be big enough to satisfy all malloc requests by the DM stack and small enough to fit in 32k minus stack size and gd_t size. Important note: do net set CONFIG_SKIP_LOWLEVEL_INIT yet because that leaves you without initialized RAM or caches. If the setup does not work yet, you likely need to init some extra bits to make the SRAM working. #define CONFIG_SYS_MALLOC_F_LEN 0x2000 I don't set CONFIG_SKIP_LOWLEVEL_INIT -- Best Regards Wills ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
On Sunday, December 27, 2015 at 12:37:16 PM, Wills Wang wrote: > On 12/27/2015 07:04 PM, Marek Vasut wrote: > > On Sunday, December 27, 2015 at 11:18:25 AM, Wills Wang wrote: > >> On 12/27/2015 06:09 PM, Marek Vasut wrote: > >>> On Sunday, December 27, 2015 at 09:07:36 AM, Wills Wang wrote: > On 12/27/2015 03:38 PM, Marek Vasut wrote: > > On Sunday, December 27, 2015 at 08:33:26 AM, Wills Wang wrote: > >> On 12/27/2015 02:37 AM, Marek Vasut wrote: > >>> On Saturday, December 26, 2015 at 07:29:51 PM, Wills Wang wrote: > WASP is ar9341. > >>> > >>> Please do not top post. > >>> > >>> Did you try if the memory is accessible on your platform ? AR9331 I > >>> have here has the SRAM at 0xbd007000 , just like that machine in > >>> [1] . > >> > >> I found there is a memory segment at 0xbd00...0xbd007fff. it's > >> independent of DDR physical memory, can be read and wrote, but > >> hardware can't boot up if don't execute lowlevel_init.S when define > >> CONFIG_SYS_INIT_SP_ADDR=0xbd007000 to set C stack into SRAM. > > > > Stack grows down, so of course if you put stack at the beginning of > > SRAM, that cannot work ;-) Put it at the end , 0xbd008000. > > This memory segment was mapped circularly at 0xbd00...0xbdff. > >>> > >>> So is this area at 0xbd008000 usable for stack or not ? > >> > >> Same times board can boot up, but in a very unstable. i use the > >> following setting: > >> > >> #define CONFIG_SYS_INIT_RAM_ADDR0xbd00 > > > > Should be 0xbd007000 > > > >> #define CONFIG_SYS_INIT_RAM_SIZE(32 * SZ_1K) > > > > Should be 4 KiB large. > > > >> #define CONFIG_SYS_INIT_SP_OFFSET \ > >> > >> (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) > >> > >> #define CONFIG_SYS_INIT_SP_ADDR \ > >> > >> (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET) > > > > Did you investigate why the board has problems ? > > "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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
On Sunday, December 27, 2015 at 12:37:37 PM, Daniel Schwierzeck wrote: > Am 27.12.2015 um 12:04 schrieb Marek Vasut: > > On Sunday, December 27, 2015 at 11:18:25 AM, Wills Wang wrote: > >> On 12/27/2015 06:09 PM, Marek Vasut wrote: > >>> On Sunday, December 27, 2015 at 09:07:36 AM, Wills Wang wrote: > On 12/27/2015 03:38 PM, Marek Vasut wrote: > > On Sunday, December 27, 2015 at 08:33:26 AM, Wills Wang wrote: > >> On 12/27/2015 02:37 AM, Marek Vasut wrote: > >>> On Saturday, December 26, 2015 at 07:29:51 PM, Wills Wang wrote: > WASP is ar9341. > >>> > >>> Please do not top post. > >>> > >>> Did you try if the memory is accessible on your platform ? AR9331 I > >>> have here has the SRAM at 0xbd007000 , just like that machine in > >>> [1] . > >> > >> I found there is a memory segment at 0xbd00...0xbd007fff. it's > >> independent of DDR physical memory, can be read and wrote, but > >> hardware can't boot up if don't execute lowlevel_init.S when define > >> CONFIG_SYS_INIT_SP_ADDR=0xbd007000 to set C stack into SRAM. > > > > Stack grows down, so of course if you put stack at the beginning of > > SRAM, that cannot work ;-) Put it at the end , 0xbd008000. > > This memory segment was mapped circularly at 0xbd00...0xbdff. > >>> > >>> So is this area at 0xbd008000 usable for stack or not ? > >> > >> Same times board can boot up, but in a very unstable. i use the > >> following setting: > >> > >> #define CONFIG_SYS_INIT_RAM_ADDR0xbd00 > > > > Should be 0xbd007000 > > > >> #define CONFIG_SYS_INIT_RAM_SIZE(32 * SZ_1K) > > > > Should be 4 KiB large. > > > >> #define CONFIG_SYS_INIT_SP_OFFSET \ > >> > >> (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) > >> > >> #define CONFIG_SYS_INIT_SP_ADDR \ > >> > >> (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET) > > > > Did you investigate why the board has problems ? > > according to the description above by Wills those three defines setup > the values correctly for start.S: > > #define CONFIG_SYS_INIT_RAM_ADDR0xbd00 > #define CONFIG_SYS_INIT_RAM_SIZE(32 * SZ_1K) > #define CONFIG_SYS_INIT_SP_ADDR \ > (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE) > > The stack pointer will then be set to the end of the SRAM area with a 16 > Byte alignment. The resulting address should be 0xbd007ff0. From this > address, the size of gd_t and CONFIG_SYS_MALLOC_F_LEN will be > subtracted. The remaining space is available for the initial stack. > > Which value did you chose for CONFIG_SYS_MALLOC_F_LEN? It must be big > enough to satisfy all malloc requests by the DM stack and small enough > to fit in 32k minus stack size and gd_t size. Careful about those 32k, I think the code which I referenced only uses 4k area. > Important note: do net set CONFIG_SKIP_LOWLEVEL_INIT yet because that > leaves you without initialized RAM or caches. If the setup does not work > yet, you likely need to init some extra bits to make the SRAM working. Best regards, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
Am 27.12.2015 um 12:04 schrieb Marek Vasut: > On Sunday, December 27, 2015 at 11:18:25 AM, Wills Wang wrote: >> On 12/27/2015 06:09 PM, Marek Vasut wrote: >>> On Sunday, December 27, 2015 at 09:07:36 AM, Wills Wang wrote: On 12/27/2015 03:38 PM, Marek Vasut wrote: > On Sunday, December 27, 2015 at 08:33:26 AM, Wills Wang wrote: >> On 12/27/2015 02:37 AM, Marek Vasut wrote: >>> On Saturday, December 26, 2015 at 07:29:51 PM, Wills Wang wrote: WASP is ar9341. >>> >>> Please do not top post. >>> >>> Did you try if the memory is accessible on your platform ? AR9331 I >>> have here has the SRAM at 0xbd007000 , just like that machine in [1] >>> . >> >> I found there is a memory segment at 0xbd00...0xbd007fff. it's >> independent of DDR physical memory, can be read and wrote, but >> hardware can't boot up if don't execute lowlevel_init.S when define >> CONFIG_SYS_INIT_SP_ADDR=0xbd007000 to set C stack into SRAM. > > Stack grows down, so of course if you put stack at the beginning of > SRAM, that cannot work ;-) Put it at the end , 0xbd008000. This memory segment was mapped circularly at 0xbd00...0xbdff. >>> >>> So is this area at 0xbd008000 usable for stack or not ? >> >> Same times board can boot up, but in a very unstable. i use the >> following setting: >> >> #define CONFIG_SYS_INIT_RAM_ADDR0xbd00 > > Should be 0xbd007000 > >> #define CONFIG_SYS_INIT_RAM_SIZE(32 * SZ_1K) > > Should be 4 KiB large. > >> #define CONFIG_SYS_INIT_SP_OFFSET \ >> (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) >> #define CONFIG_SYS_INIT_SP_ADDR \ >> (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET) > > Did you investigate why the board has problems ? > according to the description above by Wills those three defines setup the values correctly for start.S: #define CONFIG_SYS_INIT_RAM_ADDR0xbd00 #define CONFIG_SYS_INIT_RAM_SIZE(32 * SZ_1K) #define CONFIG_SYS_INIT_SP_ADDR \ (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE) The stack pointer will then be set to the end of the SRAM area with a 16 Byte alignment. The resulting address should be 0xbd007ff0. From this address, the size of gd_t and CONFIG_SYS_MALLOC_F_LEN will be subtracted. The remaining space is available for the initial stack. Which value did you chose for CONFIG_SYS_MALLOC_F_LEN? It must be big enough to satisfy all malloc requests by the DM stack and small enough to fit in 32k minus stack size and gd_t size. Important note: do net set CONFIG_SKIP_LOWLEVEL_INIT yet because that leaves you without initialized RAM or caches. If the setup does not work yet, you likely need to init some extra bits to make the SRAM working. -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
On 12/27/2015 07:04 PM, Marek Vasut wrote: On Sunday, December 27, 2015 at 11:18:25 AM, Wills Wang wrote: On 12/27/2015 06:09 PM, Marek Vasut wrote: On Sunday, December 27, 2015 at 09:07:36 AM, Wills Wang wrote: On 12/27/2015 03:38 PM, Marek Vasut wrote: On Sunday, December 27, 2015 at 08:33:26 AM, Wills Wang wrote: On 12/27/2015 02:37 AM, Marek Vasut wrote: On Saturday, December 26, 2015 at 07:29:51 PM, Wills Wang wrote: WASP is ar9341. Please do not top post. Did you try if the memory is accessible on your platform ? AR9331 I have here has the SRAM at 0xbd007000 , just like that machine in [1] . I found there is a memory segment at 0xbd00...0xbd007fff. it's independent of DDR physical memory, can be read and wrote, but hardware can't boot up if don't execute lowlevel_init.S when define CONFIG_SYS_INIT_SP_ADDR=0xbd007000 to set C stack into SRAM. Stack grows down, so of course if you put stack at the beginning of SRAM, that cannot work ;-) Put it at the end , 0xbd008000. This memory segment was mapped circularly at 0xbd00...0xbdff. So is this area at 0xbd008000 usable for stack or not ? Same times board can boot up, but in a very unstable. i use the following setting: #define CONFIG_SYS_INIT_RAM_ADDR0xbd00 Should be 0xbd007000 #define CONFIG_SYS_INIT_RAM_SIZE(32 * SZ_1K) Should be 4 KiB large. #define CONFIG_SYS_INIT_SP_OFFSET \ (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) #define CONFIG_SYS_INIT_SP_ADDR \ (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET) Did you investigate why the board has problems ? "lowlevel_init.S" can't be dropped. Best regards, Marek Vasut -- Best Regards Wills ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
On Sunday, December 27, 2015 at 11:18:25 AM, Wills Wang wrote: > On 12/27/2015 06:09 PM, Marek Vasut wrote: > > On Sunday, December 27, 2015 at 09:07:36 AM, Wills Wang wrote: > >> On 12/27/2015 03:38 PM, Marek Vasut wrote: > >>> On Sunday, December 27, 2015 at 08:33:26 AM, Wills Wang wrote: > On 12/27/2015 02:37 AM, Marek Vasut wrote: > > On Saturday, December 26, 2015 at 07:29:51 PM, Wills Wang wrote: > >> WASP is ar9341. > > > > Please do not top post. > > > > Did you try if the memory is accessible on your platform ? AR9331 I > > have here has the SRAM at 0xbd007000 , just like that machine in [1] > > . > > I found there is a memory segment at 0xbd00...0xbd007fff. it's > independent of DDR physical memory, can be read and wrote, but > hardware can't boot up if don't execute lowlevel_init.S when define > CONFIG_SYS_INIT_SP_ADDR=0xbd007000 to set C stack into SRAM. > >>> > >>> Stack grows down, so of course if you put stack at the beginning of > >>> SRAM, that cannot work ;-) Put it at the end , 0xbd008000. > >> > >> This memory segment was mapped circularly at 0xbd00...0xbdff. > > > > So is this area at 0xbd008000 usable for stack or not ? > > Same times board can boot up, but in a very unstable. i use the > following setting: > > #define CONFIG_SYS_INIT_RAM_ADDR0xbd00 Should be 0xbd007000 > #define CONFIG_SYS_INIT_RAM_SIZE(32 * SZ_1K) Should be 4 KiB large. > #define CONFIG_SYS_INIT_SP_OFFSET \ > (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) > #define CONFIG_SYS_INIT_SP_ADDR \ > (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET) Did you investigate why the board has problems ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
On 12/27/2015 06:09 PM, Marek Vasut wrote: On Sunday, December 27, 2015 at 09:07:36 AM, Wills Wang wrote: On 12/27/2015 03:38 PM, Marek Vasut wrote: On Sunday, December 27, 2015 at 08:33:26 AM, Wills Wang wrote: On 12/27/2015 02:37 AM, Marek Vasut wrote: On Saturday, December 26, 2015 at 07:29:51 PM, Wills Wang wrote: WASP is ar9341. Please do not top post. Did you try if the memory is accessible on your platform ? AR9331 I have here has the SRAM at 0xbd007000 , just like that machine in [1] . I found there is a memory segment at 0xbd00...0xbd007fff. it's independent of DDR physical memory, can be read and wrote, but hardware can't boot up if don't execute lowlevel_init.S when define CONFIG_SYS_INIT_SP_ADDR=0xbd007000 to set C stack into SRAM. Stack grows down, so of course if you put stack at the beginning of SRAM, that cannot work ;-) Put it at the end , 0xbd008000. This memory segment was mapped circularly at 0xbd00...0xbdff. So is this area at 0xbd008000 usable for stack or not ? Same times board can boot up, but in a very unstable. i use the following setting: #define CONFIG_SYS_INIT_RAM_ADDR0xbd00 #define CONFIG_SYS_INIT_RAM_SIZE(32 * SZ_1K) #define CONFIG_SYS_INIT_SP_OFFSET \ (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) #define CONFIG_SYS_INIT_SP_ADDR \ (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET) Best regards, Marek Vasut -- Best Regards Wills ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
On Sunday, December 27, 2015 at 09:07:36 AM, Wills Wang wrote: > On 12/27/2015 03:38 PM, Marek Vasut wrote: > > On Sunday, December 27, 2015 at 08:33:26 AM, Wills Wang wrote: > >> On 12/27/2015 02:37 AM, Marek Vasut wrote: > >>> On Saturday, December 26, 2015 at 07:29:51 PM, Wills Wang wrote: > WASP is ar9341. > >>> > >>> Please do not top post. > >>> > >>> Did you try if the memory is accessible on your platform ? AR9331 I > >>> have here has the SRAM at 0xbd007000 , just like that machine in [1] . > >> > >> I found there is a memory segment at 0xbd00...0xbd007fff. it's > >> independent of DDR physical memory, can be read and wrote, but > >> hardware can't boot up if don't execute lowlevel_init.S when define > >> CONFIG_SYS_INIT_SP_ADDR=0xbd007000 to set C stack into SRAM. > > > > Stack grows down, so of course if you put stack at the beginning of SRAM, > > that cannot work ;-) Put it at the end , 0xbd008000. > > This memory segment was mapped circularly at 0xbd00...0xbdff. So is this area at 0xbd008000 usable for stack or not ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
On 12/27/2015 03:38 PM, Marek Vasut wrote: On Sunday, December 27, 2015 at 08:33:26 AM, Wills Wang wrote: On 12/27/2015 02:37 AM, Marek Vasut wrote: On Saturday, December 26, 2015 at 07:29:51 PM, Wills Wang wrote: WASP is ar9341. Please do not top post. Did you try if the memory is accessible on your platform ? AR9331 I have here has the SRAM at 0xbd007000 , just like that machine in [1] . I found there is a memory segment at 0xbd00...0xbd007fff. it's independent of DDR physical memory, can be read and wrote, but hardware can't boot up if don't execute lowlevel_init.S when define CONFIG_SYS_INIT_SP_ADDR=0xbd007000 to set C stack into SRAM. Stack grows down, so of course if you put stack at the beginning of SRAM, that cannot work ;-) Put it at the end , 0xbd008000. This memory segment was mapped circularly at 0xbd00...0xbdff. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
On Sunday, December 27, 2015 at 08:33:26 AM, Wills Wang wrote: > On 12/27/2015 02:37 AM, Marek Vasut wrote: > > On Saturday, December 26, 2015 at 07:29:51 PM, Wills Wang wrote: > >> WASP is ar9341. > > > > Please do not top post. > > > > Did you try if the memory is accessible on your platform ? AR9331 I have > > here has the SRAM at 0xbd007000 , just like that machine in [1] . > > I found there is a memory segment at 0xbd00...0xbd007fff. it's > independent of DDR physical memory, can be read and wrote, but > hardware can't boot up if don't execute lowlevel_init.S when define > CONFIG_SYS_INIT_SP_ADDR=0xbd007000 to set C stack into SRAM. Stack grows down, so of course if you put stack at the beginning of SRAM, that cannot work ;-) Put it at the end , 0xbd008000. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
On 12/27/2015 02:37 AM, Marek Vasut wrote: On Saturday, December 26, 2015 at 07:29:51 PM, Wills Wang wrote: WASP is ar9341. Please do not top post. Did you try if the memory is accessible on your platform ? AR9331 I have here has the SRAM at 0xbd007000 , just like that machine in [1] . I found there is a memory segment at 0xbd00...0xbd007fff. it's independent of DDR physical memory, can be read and wrote, but hardware can't boot up if don't execute lowlevel_init.S when define CONFIG_SYS_INIT_SP_ADDR=0xbd007000 to set C stack into SRAM. Best Regards Wills ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
On Saturday, December 26, 2015 at 07:29:51 PM, Wills Wang wrote: > WASP is ar9341. Please do not top post. Did you try if the memory is accessible on your platform ? AR9331 I have here has the SRAM at 0xbd007000 , just like that machine in [1] . > On 12/27/2015 02:17 AM, Marek Vasut wrote: > > On Saturday, December 26, 2015 at 06:35:35 PM, Marek Vasut wrote: > >> On Saturday, December 26, 2015 at 04:48:57 PM, Wills Wang wrote: > >> > >> [...] > >> > The SPI flash is an IP block which just maps the SPI NOR into the > address space, it doesn't use the CPU cache at all. > > Maybe you don't even need to lock cachelines though, the AR9331 should > have some internal SRAM, so just use that for stack. Do you have a > proper datasheet for the Atheros MIPS chips ? I have some 320 pages > datasheet for AR9331. > >>> > >>> I don't find any description about internal SRAM in public datasheet. > >>> About mapping SPI flash, there is a doubt, who fetch the instruction > >>> from the SPI Nor flash to CPU pipe line when chip boot from SPI flash? > >>> I guess that ROM code handle cache exception and load instruction/date > >>> from SPI flash into cache. > >> > >> I just pulled out the SPI NOR from the Arduino Yun I have here and > >> connected an FPGA with SPI NOR emulator in there. All the chip does is > >> it issues the fastread opcode to the SPI NOR when it boots. It does the > >> same thing if you access the 0x9f00..0x9fxx address range from > >> the ancient U-Boot 1.1.x. > >> > >> My impression is that the SPI NOR controller in the chip does a mapping > >> between the SPI NOR and the memory mapped access to the 0x9fxx > >> range. There is no caching involved in that, all of this is done > >> internally in the SPI NOR block. > >> > >> The mips24kc core should support locking cache lines , so if the SRAM is > >> not available, this would have to do. > > > > Ha, look at this [1]. risk @ #openwrt-devel at freenode pointed this > > location out (thanks!) > > > > [1] https://github.com/pepe2k/u-boot_mod/blob/master/u- > > boot/cpu/mips/start.S#L652 > > > > Best regards, > > Marek Vasut Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
WASP is ar9341. On 12/27/2015 02:17 AM, Marek Vasut wrote: On Saturday, December 26, 2015 at 06:35:35 PM, Marek Vasut wrote: On Saturday, December 26, 2015 at 04:48:57 PM, Wills Wang wrote: [...] The SPI flash is an IP block which just maps the SPI NOR into the address space, it doesn't use the CPU cache at all. Maybe you don't even need to lock cachelines though, the AR9331 should have some internal SRAM, so just use that for stack. Do you have a proper datasheet for the Atheros MIPS chips ? I have some 320 pages datasheet for AR9331. I don't find any description about internal SRAM in public datasheet. About mapping SPI flash, there is a doubt, who fetch the instruction from the SPI Nor flash to CPU pipe line when chip boot from SPI flash? I guess that ROM code handle cache exception and load instruction/date from SPI flash into cache. I just pulled out the SPI NOR from the Arduino Yun I have here and connected an FPGA with SPI NOR emulator in there. All the chip does is it issues the fastread opcode to the SPI NOR when it boots. It does the same thing if you access the 0x9f00..0x9fxx address range from the ancient U-Boot 1.1.x. My impression is that the SPI NOR controller in the chip does a mapping between the SPI NOR and the memory mapped access to the 0x9fxx range. There is no caching involved in that, all of this is done internally in the SPI NOR block. The mips24kc core should support locking cache lines , so if the SRAM is not available, this would have to do. Ha, look at this [1]. risk @ #openwrt-devel at freenode pointed this location out (thanks!) [1] https://github.com/pepe2k/u-boot_mod/blob/master/u- boot/cpu/mips/start.S#L652 Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
On Saturday, December 26, 2015 at 06:35:35 PM, Marek Vasut wrote: > On Saturday, December 26, 2015 at 04:48:57 PM, Wills Wang wrote: > > [...] > > > > The SPI flash is an IP block which just maps the SPI NOR into the > > > address space, it doesn't use the CPU cache at all. > > > > > > Maybe you don't even need to lock cachelines though, the AR9331 should > > > have some internal SRAM, so just use that for stack. Do you have a > > > proper datasheet for the Atheros MIPS chips ? I have some 320 pages > > > datasheet for AR9331. > > > > I don't find any description about internal SRAM in public datasheet. > > About mapping SPI flash, there is a doubt, who fetch the instruction from > > the SPI Nor flash to CPU pipe line when chip boot from SPI flash? > > I guess that ROM code handle cache exception and load instruction/date > > from SPI flash into cache. > > I just pulled out the SPI NOR from the Arduino Yun I have here and > connected an FPGA with SPI NOR emulator in there. All the chip does is it > issues the fastread opcode to the SPI NOR when it boots. It does the same > thing if you access the 0x9f00..0x9fxx address range from the > ancient U-Boot 1.1.x. > > My impression is that the SPI NOR controller in the chip does a mapping > between the SPI NOR and the memory mapped access to the 0x9fxx range. > There is no caching involved in that, all of this is done internally in > the SPI NOR block. > > The mips24kc core should support locking cache lines , so if the SRAM is > not available, this would have to do. Ha, look at this [1]. risk @ #openwrt-devel at freenode pointed this location out (thanks!) [1] https://github.com/pepe2k/u-boot_mod/blob/master/u- boot/cpu/mips/start.S#L652 Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
On Saturday, December 26, 2015 at 04:48:57 PM, Wills Wang wrote: [...] > > The SPI flash is an IP block which just maps the SPI NOR into the address > > space, it doesn't use the CPU cache at all. > > > > Maybe you don't even need to lock cachelines though, the AR9331 should > > have some internal SRAM, so just use that for stack. Do you have a > > proper datasheet for the Atheros MIPS chips ? I have some 320 pages > > datasheet for AR9331. > > I don't find any description about internal SRAM in public datasheet. > About mapping SPI flash, there is a doubt, who fetch the instruction from > the SPI Nor flash to CPU pipe line when chip boot from SPI flash? > I guess that ROM code handle cache exception and load instruction/date from > SPI flash into cache. I just pulled out the SPI NOR from the Arduino Yun I have here and connected an FPGA with SPI NOR emulator in there. All the chip does is it issues the fastread opcode to the SPI NOR when it boots. It does the same thing if you access the 0x9f00..0x9fxx address range from the ancient U-Boot 1.1.x. My impression is that the SPI NOR controller in the chip does a mapping between the SPI NOR and the memory mapped access to the 0x9fxx range. There is no caching involved in that, all of this is done internally in the SPI NOR block. The mips24kc core should support locking cache lines , so if the SRAM is not available, this would have to do. > >>> [...] > >>> > >> +phys_size_t initdram(int board_type) > >> +{ > >> + uint8_t *addr, *p; > >> + int i; > >> + > >> + ddr_tap_init(); > >> + addr = (uint8_t *)KSEG1; > >> + *addr = 0x77; > >> + for (i = 0, p = addr; p < (uint8_t *)KSEG2; i++) { > >> + p += 0x100; > >> + *p = i; > >> + if (*addr != 0x77) > >> + break; > >> + } > > > > What is this and how does it work ? > > Physical memory was mapped circularly for this chip. > >>> > >>> Can you please expand on that ? I am not as deep in this chip as you > >>> are, so please explain it to me in a bit more detail. > > > > Well ... ? > > There is 64MB DDR on my board, the 64MB memory was mapped circularly into > 0x-0x03ff, 0x0400-0x07ff, 0x0800-0x0bff,... > the address 0x, 0x0400 and 0x0800 was mapped to the same > physical memory. their corresponding KSEG1 address is 0xA000, > 0xA400, > 0xA800, when write a value into 0xA000, we can read the same value > from address 0xA400 and 0xA800. So this is some sort of poor man's memory size detection mechanism ? See common/memsize.c , function get_ram_size() . That might help instead. > >> + return (phys_size_t)(p - addr); > >> +} > >>> > >>> [...] > >>> > >> + if (reg) { > >> + val = RST_READ(reg); > >> + val |= AR71XX_RESET_FULL_CHIP; > >> + RST_WRITE(reg, val); > > > > setbits_le32() please. > > Macro setbits_le32() is not available for MIPS architecture. > >>> > >>> You can always add them :) > >>> > Other, I don't think there is better in being so explicit and using > little-endian. > >>> > >>> I believe your register accesses should have correct endianness exactly > >>> beause mips can be both endian. > >> > >> What is the advantage of using setbits_le32()? > > > > You don't have these constant repeating patterns of: > > > > var = read() > > var |= BIT > > write(var) > > > > It makes things a bit less confusing. > > ok, AR9331 use big-endian. setbits_be32() then, same thing. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
On 12/26/2015 02:02 PM, Marek Vasut wrote: On Friday, December 25, 2015 at 12:38:39 PM, Wills Wang wrote: On 12/24/2015 11:12 PM, Marek Vasut wrote: On Thursday, December 24, 2015 at 02:51:06 PM, Wills Wang wrote: [...] +LEAF(lowlevel_init) + /* These three WLAN_RESET will avoid original issue */ +li t3, 0x03 +1: +li t0, KSEG1ADDR(AR71XX_RESET_BASE) +lw t1, AR933X_RESET_REG_RESET_MODULE(t0) +ori t1, t1, 0x0800 +sw t1, AR933X_RESET_REG_RESET_MODULE(t0) +nop +lw t1, AR933X_RESET_REG_RESET_MODULE(t0) +li t2, 0xf7ff +and t1, t1, t2 +sw t1, AR933X_RESET_REG_RESET_MODULE(t0) +nop +addit3, t3, -1 +bnezt3, 1b + nop This should be also easy to rewrite into C , right ? C runtime environment is not available. C stack is not ready before DDR has initialized. Just point the stack into a locked cacheline or some onchip RAM and there you have a C runtime. That should be pretty easy :) How to lock cacheline? You'd have to check the MIPS core manual, I don't know the details, sorry. My guess is that cache memory may be use to map SPI flash at 0x9f00 by ROM code. The SPI flash is an IP block which just maps the SPI NOR into the address space, it doesn't use the CPU cache at all. Maybe you don't even need to lock cachelines though, the AR9331 should have some internal SRAM, so just use that for stack. Do you have a proper datasheet for the Atheros MIPS chips ? I have some 320 pages datasheet for AR9331. I don't find any description about internal SRAM in public datasheet. About mapping SPI flash, there is a doubt, who fetch the instruction from the SPI Nor flash to CPU pipe line when chip boot from SPI flash? I guess that ROM code handle cache exception and load instruction/date from SPI flash into cache. [...] +phys_size_t initdram(int board_type) +{ + uint8_t *addr, *p; + int i; + + ddr_tap_init(); + addr = (uint8_t *)KSEG1; + *addr = 0x77; + for (i = 0, p = addr; p < (uint8_t *)KSEG2; i++) { + p += 0x100; + *p = i; + if (*addr != 0x77) + break; + } What is this and how does it work ? Physical memory was mapped circularly for this chip. Can you please expand on that ? I am not as deep in this chip as you are, so please explain it to me in a bit more detail. Well ... ? There is 64MB DDR on my board, the 64MB memory was mapped circularly into 0x-0x03ff, 0x0400-0x07ff, 0x0800-0x0bff,... the address 0x, 0x0400 and 0x0800 was mapped to the same physical memory. their corresponding KSEG1 address is 0xA000, 0xA400, 0xA800, when write a value into 0xA000, we can read the same value from address 0xA400 and 0xA800. + return (phys_size_t)(p - addr); +} [...] + if (reg) { + val = RST_READ(reg); + val |= AR71XX_RESET_FULL_CHIP; + RST_WRITE(reg, val); setbits_le32() please. Macro setbits_le32() is not available for MIPS architecture. You can always add them :) Other, I don't think there is better in being so explicit and using little-endian. I believe your register accesses should have correct endianness exactly beause mips can be both endian. What is the advantage of using setbits_le32()? You don't have these constant repeating patterns of: var = read() var |= BIT write(var) It makes things a bit less confusing. ok, AR9331 use big-endian. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
On Friday, December 25, 2015 at 12:38:39 PM, Wills Wang wrote: > On 12/24/2015 11:12 PM, Marek Vasut wrote: > > On Thursday, December 24, 2015 at 02:51:06 PM, Wills Wang wrote: > > > > [...] > > > +LEAF(lowlevel_init) > + /* These three WLAN_RESET will avoid original issue */ > +li t3, 0x03 > +1: > +li t0, KSEG1ADDR(AR71XX_RESET_BASE) > +lw t1, AR933X_RESET_REG_RESET_MODULE(t0) > +ori t1, t1, 0x0800 > +sw t1, AR933X_RESET_REG_RESET_MODULE(t0) > +nop > +lw t1, AR933X_RESET_REG_RESET_MODULE(t0) > +li t2, 0xf7ff > +and t1, t1, t2 > +sw t1, AR933X_RESET_REG_RESET_MODULE(t0) > +nop > +addit3, t3, -1 > +bnezt3, 1b > + nop > >>> > >>> This should be also easy to rewrite into C , right ? > >> > >> C runtime environment is not available. > >> C stack is not ready before DDR has initialized. > > > > Just point the stack into a locked cacheline or some onchip RAM and there > > you have a C runtime. That should be pretty easy :) > > How to lock cacheline? You'd have to check the MIPS core manual, I don't know the details, sorry. > My guess is that cache memory may be use to map SPI flash at 0x9f00 > by ROM code. The SPI flash is an IP block which just maps the SPI NOR into the address space, it doesn't use the CPU cache at all. Maybe you don't even need to lock cachelines though, the AR9331 should have some internal SRAM, so just use that for stack. Do you have a proper datasheet for the Atheros MIPS chips ? I have some 320 pages datasheet for AR9331. > > [...] > > > +phys_size_t initdram(int board_type) > +{ > +uint8_t *addr, *p; > +int i; > + > +ddr_tap_init(); > +addr = (uint8_t *)KSEG1; > +*addr = 0x77; > +for (i = 0, p = addr; p < (uint8_t *)KSEG2; i++) { > +p += 0x100; > +*p = i; > +if (*addr != 0x77) > +break; > +} > >>> > >>> What is this and how does it work ? > >> > >> Physical memory was mapped circularly for this chip. > > > > Can you please expand on that ? I am not as deep in this chip as you are, > > so please explain it to me in a bit more detail. Well ... ? > +return (phys_size_t)(p - addr); > +} > > > > [...] > > > +if (reg) { > +val = RST_READ(reg); > +val |= AR71XX_RESET_FULL_CHIP; > +RST_WRITE(reg, val); > >>> > >>> setbits_le32() please. > >> > >> Macro setbits_le32() is not available for MIPS architecture. > > > > You can always add them :) > > > >> Other, I don't think there is better in being so explicit and using > >> little-endian. > > > > I believe your register accesses should have correct endianness exactly > > beause mips can be both endian. > > What is the advantage of using setbits_le32()? You don't have these constant repeating patterns of: var = read() var |= BIT write(var) It makes things a bit less confusing. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
On 12/24/2015 11:12 PM, Marek Vasut wrote: On Thursday, December 24, 2015 at 02:51:06 PM, Wills Wang wrote: [...] +LEAF(lowlevel_init) + /* These three WLAN_RESET will avoid original issue */ +li t3, 0x03 +1: +li t0, KSEG1ADDR(AR71XX_RESET_BASE) +lw t1, AR933X_RESET_REG_RESET_MODULE(t0) +ori t1, t1, 0x0800 +sw t1, AR933X_RESET_REG_RESET_MODULE(t0) +nop +lw t1, AR933X_RESET_REG_RESET_MODULE(t0) +li t2, 0xf7ff +and t1, t1, t2 +sw t1, AR933X_RESET_REG_RESET_MODULE(t0) +nop +addit3, t3, -1 +bnezt3, 1b + nop This should be also easy to rewrite into C , right ? C runtime environment is not available. C stack is not ready before DDR has initialized. Just point the stack into a locked cacheline or some onchip RAM and there you have a C runtime. That should be pretty easy :) How to lock cacheline? My guess is that cache memory may be use to map SPI flash at 0x9f00 by ROM code. [...] +phys_size_t initdram(int board_type) +{ + uint8_t *addr, *p; + int i; + + ddr_tap_init(); + addr = (uint8_t *)KSEG1; + *addr = 0x77; + for (i = 0, p = addr; p < (uint8_t *)KSEG2; i++) { + p += 0x100; + *p = i; + if (*addr != 0x77) + break; + } What is this and how does it work ? Physical memory was mapped circularly for this chip. Can you please expand on that ? I am not as deep in this chip as you are, so please explain it to me in a bit more detail. + return (phys_size_t)(p - addr); +} [...] + if (reg) { + val = RST_READ(reg); + val |= AR71XX_RESET_FULL_CHIP; + RST_WRITE(reg, val); setbits_le32() please. Macro setbits_le32() is not available for MIPS architecture. You can always add them :) Other, I don't think there is better in being so explicit and using little-endian. I believe your register accesses should have correct endianness exactly beause mips can be both endian. What is the advantage of using setbits_le32()? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
On Thursday, December 24, 2015 at 02:51:06 PM, Wills Wang wrote: [...] > >> +LEAF(lowlevel_init) > >> + /* These three WLAN_RESET will avoid original issue */ > >> +li t3, 0x03 > >> +1: > >> +li t0, KSEG1ADDR(AR71XX_RESET_BASE) > >> +lw t1, AR933X_RESET_REG_RESET_MODULE(t0) > >> +ori t1, t1, 0x0800 > >> +sw t1, AR933X_RESET_REG_RESET_MODULE(t0) > >> +nop > >> +lw t1, AR933X_RESET_REG_RESET_MODULE(t0) > >> +li t2, 0xf7ff > >> +and t1, t1, t2 > >> +sw t1, AR933X_RESET_REG_RESET_MODULE(t0) > >> +nop > >> +addit3, t3, -1 > >> +bnezt3, 1b > >> + nop > > > > This should be also easy to rewrite into C , right ? > > C runtime environment is not available. > C stack is not ready before DDR has initialized. Just point the stack into a locked cacheline or some onchip RAM and there you have a C runtime. That should be pretty easy :) [...] > >> +phys_size_t initdram(int board_type) > >> +{ > >> + uint8_t *addr, *p; > >> + int i; > >> + > >> + ddr_tap_init(); > >> + addr = (uint8_t *)KSEG1; > >> + *addr = 0x77; > >> + for (i = 0, p = addr; p < (uint8_t *)KSEG2; i++) { > >> + p += 0x100; > >> + *p = i; > >> + if (*addr != 0x77) > >> + break; > >> + } > > > > What is this and how does it work ? > > Physical memory was mapped circularly for this chip. Can you please expand on that ? I am not as deep in this chip as you are, so please explain it to me in a bit more detail. > >> + return (phys_size_t)(p - addr); > >> +} > > [...] > >> + if (reg) { > >> + val = RST_READ(reg); > >> + val |= AR71XX_RESET_FULL_CHIP; > >> + RST_WRITE(reg, val); > > > > setbits_le32() please. > > Macro setbits_le32() is not available for MIPS architecture. You can always add them :) > Other, I don't think there is better in being so explicit and using > little-endian. I believe your register accesses should have correct endianness exactly beause mips can be both endian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
On 12/24/2015 07:52 PM, Marek Vasut wrote: On Thursday, December 24, 2015 at 12:22:00 PM, Wills Wang wrote: This patch enable work for ar933x SOC, tested on ar9331 board. Signed-off-by: Wills Wang [...] diff --git a/arch/mips/config.mk b/arch/mips/config.mk index 3ebc202..fd50909 100644 --- a/arch/mips/config.mk +++ b/arch/mips/config.mk @@ -39,6 +39,7 @@ cpuflags-$(CONFIG_CPU_MIPS32_R1) += -march=mips32 -Wa,-mips32 cpuflags-$(CONFIG_CPU_MIPS32_R2) += -march=mips32r2 -Wa,-mips32r2 cpuflags-$(CONFIG_CPU_MIPS64_R1) += -march=mips64 -Wa,-mips64 cpuflags-$(CONFIG_CPU_MIPS64_R2) += -march=mips64r2 -Wa,-mips64r2 +cpuflags-$(CONFIG_ARCH_ATH79) += -mtune=24kc You can just tune it for MIPS32_R2 , it will be compatible with older toolchains too. I don't think there is much benefit in being so explicit and using mips24kc tuning. PLATFORM_CPPFLAGS += $(cpuflags-y) PLATFORM_CPPFLAGS += -D__MIPS__ [...] diff --git a/arch/mips/mach-ath79/ar933x/ddr_tap.S b/arch/mips/mach-ath79/ar933x/ddr_tap.S new file mode 100644 index 000..18c57de --- /dev/null +++ b/arch/mips/mach-ath79/ar933x/ddr_tap.S @@ -0,0 +1,268 @@ +/* + * (C) Copyright 2015 + * Wills Wang, + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include +#include +#include +#include +#include +#include + +#define DRAM_K0(x) KSEG0ADDR(x) +#define DRAM_K1(x) KSEG1ADDR(x) + + .text + .set noreorder + +LEAF(ddr_tap_init) + /* Tap settings for the DDR */ + li t0, 0x + li t1, DRAM_K0(0x50) + sw t0, 0x0(t1) + sw t0, 0x4(t1) + sw t0, 0x8(t1) + sw t0, 0xc(t1) + nop + nop + + li t8, DRAM_K1(0x2000) + li t0, 0x00 + li t1, 0x100 +0: + andit2, t0, 0x03 + li t3, 0x00 + bne t2, t3,1f +nop + li t9, 0x + sw t9, 0x0(t8) + b 2f +nop Please rewrite this into C, I believe it should be pretty easy. [...] diff --git a/arch/mips/mach-ath79/ar933x/lowlevel_init.S b/arch/mips/mach-ath79/ar933x/lowlevel_init.S new file mode 100644 index 000..72509ca --- /dev/null +++ b/arch/mips/mach-ath79/ar933x/lowlevel_init.S @@ -0,0 +1,460 @@ +/* + * (C) Copyright 2015 + * Wills Wang, + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include +#include +#include +#include + +#define SET_BIT(val, bit) ((val) | (1 << (bit))) +#define SET_PLL_PD(val) SET_BIT(val, 30) +#define AHB_DIV_TO_4(val) SET_BIT(SET_BIT(val, 15), 16) +#define PLL_BYPASS(val) SET_BIT(val, 2) + +#define MK_PLL_CONF(divint, refdiv, range, outdiv) \ + (((0x3F & divint) << 10) | \ + ((0x1F & refdiv) << 16) | \ + ((0x1 & range) << 21) | \ + ((0x7 & outdiv) << 23) ) + +#define MK_CLK_CNTL(cpudiv, ddrdiv, ahbdiv) \ +(((0x3 & (cpudiv - 1)) << 5) | \ +((0x3 & (ddrdiv - 1)) << 10) | \ +((0x3 & (ahbdiv - 1)) << 15) ) + +/* + * PLL_CPU_CONFIG_VAL + * + * Bit30 is set (CPU_PLLPWD = 1 -> power down control for CPU PLL) + * After PLL configuration we need to clear this bit + * + * Values written into CPU PLL Configuration (CPU_PLL_CONFIG) + * + * bits 10..15 (6bit) DIV_INT (Integer part of the DIV to CPU PLL) + * => 32 (0x20) VCOOUT = XTAL * DIV_INT + * bits 16..20 (5bit) REFDIV (Reference clock divider) + * => 1 (0x1) [Must start at values 1] + * bits 21 (1bit) RANGE (VCO frequency range of the CPU PLL) + * => 0 (0x0) [Doesn't impact clock values] + * bits 23..25 (3bit) OUTDIV (Ratio between VCO and PLL output) + * => 1 (0x1) [0 is illegal!] + * PLLOUT = VCOOUT * (1/2^OUTDIV) + */ +/* DIV_INT=32 (25MHz*32/2=400MHz), REFDIV=1, RANGE=0, OUTDIV=1 */ +#define PLL_CPU_CONFIG_VAL_40M MK_PLL_CONF(20, 1, 0, 1) +/* DIV_INT=20 (40MHz*20/2=400MHz), REFDIV=1, RANGE=0, OUTDIV=1 */ +#define PLL_CPU_CONFIG_VAL_25M MK_PLL_CONF(32, 1, 0, 1) + +/* + * PLL_CLK_CONTROL_VAL + * + * In PLL_CLK_CONTROL_VAL bit 2 is set (BYPASS = 1 -> bypass PLL) + * After PLL configuration we need to clear this bit + * + * Values written into CPU Clock Control Register CLOCK_CONTROL + * + * bits 2 (1bit) BYPASS (Bypass PLL. This defaults to 1 for test. + * Software must enable the CPU PLL for normal and + * then set this bit to 0) + * bits 5..6(2bit) CPU_POST_DIV=> 0 (DEFAULT, Ratio = 1) + * CPU_CLK = PLLOUT / CPU_POST_DIV + * bits 10..11 (2bit) DDR_POST_DIV=> 0 (DEFAULT, Ratio = 1) + * DDR_CLK = PLLOUT / DDR_POST_DIV + * bits 15..16 (2bit) AHB_POST_DIV=> 1 (DEFAULT, Ratio = 2) + * AHB_CLK = PLLOUT / AHB_POST_DIV + * + */ +#define PLL_CLK_CONTROL_VAL MK_CLK_CNTL(1, 1, 2) + +.text +.set noreorder + +LEAF(lowlevel_init) + /* These three WLAN_RESET
Re: [U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
On Thursday, December 24, 2015 at 12:22:00 PM, Wills Wang wrote: > This patch enable work for ar933x SOC, tested on ar9331 board. > > Signed-off-by: Wills Wang [...] > diff --git a/arch/mips/config.mk b/arch/mips/config.mk > index 3ebc202..fd50909 100644 > --- a/arch/mips/config.mk > +++ b/arch/mips/config.mk > @@ -39,6 +39,7 @@ cpuflags-$(CONFIG_CPU_MIPS32_R1) += -march=mips32 > -Wa,-mips32 cpuflags-$(CONFIG_CPU_MIPS32_R2) += -march=mips32r2 > -Wa,-mips32r2 cpuflags-$(CONFIG_CPU_MIPS64_R1) += -march=mips64 > -Wa,-mips64 > cpuflags-$(CONFIG_CPU_MIPS64_R2) += -march=mips64r2 -Wa,-mips64r2 > +cpuflags-$(CONFIG_ARCH_ATH79) += -mtune=24kc You can just tune it for MIPS32_R2 , it will be compatible with older toolchains too. I don't think there is much benefit in being so explicit and using mips24kc tuning. > PLATFORM_CPPFLAGS += $(cpuflags-y) > > PLATFORM_CPPFLAGS += -D__MIPS__ [...] > diff --git a/arch/mips/mach-ath79/ar933x/ddr_tap.S > b/arch/mips/mach-ath79/ar933x/ddr_tap.S new file mode 100644 > index 000..18c57de > --- /dev/null > +++ b/arch/mips/mach-ath79/ar933x/ddr_tap.S > @@ -0,0 +1,268 @@ > +/* > + * (C) Copyright 2015 > + * Wills Wang, > + * > + * SPDX-License-Identifier: GPL-2.0+ > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define DRAM_K0(x) KSEG0ADDR(x) > +#define DRAM_K1(x) KSEG1ADDR(x) > + > + .text > + .set noreorder > + > +LEAF(ddr_tap_init) > + /* Tap settings for the DDR */ > + li t0, 0x > + li t1, DRAM_K0(0x50) > + sw t0, 0x0(t1) > + sw t0, 0x4(t1) > + sw t0, 0x8(t1) > + sw t0, 0xc(t1) > + nop > + nop > + > + li t8, DRAM_K1(0x2000) > + li t0, 0x00 > + li t1, 0x100 > +0: > + andit2, t0, 0x03 > + li t3, 0x00 > + bne t2, t3,1f > + nop > + li t9, 0x > + sw t9, 0x0(t8) > + b 2f > + nop Please rewrite this into C, I believe it should be pretty easy. [...] > diff --git a/arch/mips/mach-ath79/ar933x/lowlevel_init.S > b/arch/mips/mach-ath79/ar933x/lowlevel_init.S new file mode 100644 > index 000..72509ca > --- /dev/null > +++ b/arch/mips/mach-ath79/ar933x/lowlevel_init.S > @@ -0,0 +1,460 @@ > +/* > + * (C) Copyright 2015 > + * Wills Wang, > + * > + * SPDX-License-Identifier: GPL-2.0+ > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define SET_BIT(val, bit) ((val) | (1 << (bit))) > +#define SET_PLL_PD(val) SET_BIT(val, 30) > +#define AHB_DIV_TO_4(val) SET_BIT(SET_BIT(val, 15), 16) > +#define PLL_BYPASS(val) SET_BIT(val, 2) > + > +#define MK_PLL_CONF(divint, refdiv, range, outdiv) \ > + (((0x3F & divint) << 10) | \ > + ((0x1F & refdiv) << 16) | \ > + ((0x1 & range) << 21) | \ > + ((0x7 & outdiv) << 23) ) > + > +#define MK_CLK_CNTL(cpudiv, ddrdiv, ahbdiv) \ > +(((0x3 & (cpudiv - 1)) << 5) | \ > +((0x3 & (ddrdiv - 1)) << 10) | \ > +((0x3 & (ahbdiv - 1)) << 15) ) > + > +/* > + * PLL_CPU_CONFIG_VAL > + * > + * Bit30 is set (CPU_PLLPWD = 1 -> power down control for CPU PLL) > + * After PLL configuration we need to clear this bit > + * > + * Values written into CPU PLL Configuration (CPU_PLL_CONFIG) > + * > + * bits 10..15 (6bit) DIV_INT (Integer part of the DIV to CPU PLL) > + * => 32 (0x20) VCOOUT = XTAL * DIV_INT > + * bits 16..20 (5bit) REFDIV (Reference clock divider) > + * => 1 (0x1) [Must start at values 1] > + * bits 21 (1bit) RANGE (VCO frequency range of the CPU PLL) > + * => 0 (0x0) [Doesn't impact clock values] > + * bits 23..25 (3bit) OUTDIV (Ratio between VCO and PLL output) > + * => 1 (0x1) [0 is illegal!] > + * PLLOUT = VCOOUT * (1/2^OUTDIV) > + */ > +/* DIV_INT=32 (25MHz*32/2=400MHz), REFDIV=1, RANGE=0, OUTDIV=1 */ > +#define PLL_CPU_CONFIG_VAL_40M MK_PLL_CONF(20, 1, 0, 1) > +/* DIV_INT=20 (40MHz*20/2=400MHz), REFDIV=1, RANGE=0, OUTDIV=1 */ > +#define PLL_CPU_CONFIG_VAL_25M MK_PLL_CONF(32, 1, 0, 1) > + > +/* > + * PLL_CLK_CONTROL_VAL > + * > + * In PLL_CLK_CONTROL_VAL bit 2 is set (BYPASS = 1 -> bypass PLL) > + * After PLL configuration we need to clear this bit > + * > + * Values written into CPU Clock Control Register CLOCK_CONTROL > + * > + * bits 2 (1bit) BYPASS (Bypass PLL. This defaults to 1 for test. > + * Software must enable the CPU PLL for normal and > + * then set this bit to 0) > + * bits 5..6(2bit) CPU_POST_DIV=> 0 (DEFAULT, Ratio = 1) > + * CPU_CLK = PLLOUT / CPU_POST_DIV > + * bits 10..11 (2bit) DDR_POST_DIV=> 0 (DEFAULT, Ratio = 1) > + * DDR_CLK = PLLOUT / DDR_POST_DIV > + * bits 15..16 (2bit) AHB_POST_DIV=> 1 (DEFAULT, Ratio = 2) > + *
[U-Boot] [PATCH v3 1/4] mips: add base support for atheros ath79 based SOCs
This patch enable work for ar933x SOC, tested on ar9331 board. Signed-off-by: Wills Wang --- Changes in v3: None Changes in v2: None arch/mips/Makefile |1 + arch/mips/config.mk |1 + arch/mips/mach-ath79/Makefile |9 + arch/mips/mach-ath79/ar933x/Makefile|6 + arch/mips/mach-ath79/ar933x/ddr_tap.S | 268 ++ arch/mips/mach-ath79/ar933x/lowlevel_init.S | 460 + arch/mips/mach-ath79/cpu.c | 269 ++ arch/mips/mach-ath79/dram.c | 27 + arch/mips/mach-ath79/include/mach/ar71xx_regs.h | 1144 +++ arch/mips/mach-ath79/include/mach/ar933x_uart.h | 66 ++ arch/mips/mach-ath79/include/mach/ath79.h | 143 +++ arch/mips/mach-ath79/include/mach/ddr.h | 13 + arch/mips/mach-ath79/reset.c| 55 ++ 13 files changed, 2462 insertions(+) create mode 100644 arch/mips/mach-ath79/Makefile create mode 100644 arch/mips/mach-ath79/ar933x/Makefile create mode 100644 arch/mips/mach-ath79/ar933x/ddr_tap.S create mode 100644 arch/mips/mach-ath79/ar933x/lowlevel_init.S create mode 100644 arch/mips/mach-ath79/cpu.c create mode 100644 arch/mips/mach-ath79/dram.c create mode 100644 arch/mips/mach-ath79/include/mach/ar71xx_regs.h create mode 100644 arch/mips/mach-ath79/include/mach/ar933x_uart.h create mode 100644 arch/mips/mach-ath79/include/mach/ath79.h create mode 100644 arch/mips/mach-ath79/include/mach/ddr.h create mode 100644 arch/mips/mach-ath79/reset.c diff --git a/arch/mips/Makefile b/arch/mips/Makefile index 6a9f798..da5fa72 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -8,6 +8,7 @@ libs-y += arch/mips/cpu/ libs-y += arch/mips/lib/ machine-$(CONFIG_SOC_AU1X00) += au1x00 +machine-$(CONFIG_ARCH_ATH79) += ath79 machdirs := $(patsubst %,arch/mips/mach-%/,$(machine-y)) libs-y += $(machdirs) diff --git a/arch/mips/config.mk b/arch/mips/config.mk index 3ebc202..fd50909 100644 --- a/arch/mips/config.mk +++ b/arch/mips/config.mk @@ -39,6 +39,7 @@ cpuflags-$(CONFIG_CPU_MIPS32_R1) += -march=mips32 -Wa,-mips32 cpuflags-$(CONFIG_CPU_MIPS32_R2) += -march=mips32r2 -Wa,-mips32r2 cpuflags-$(CONFIG_CPU_MIPS64_R1) += -march=mips64 -Wa,-mips64 cpuflags-$(CONFIG_CPU_MIPS64_R2) += -march=mips64r2 -Wa,-mips64r2 +cpuflags-$(CONFIG_ARCH_ATH79) += -mtune=24kc PLATFORM_CPPFLAGS += $(cpuflags-y) PLATFORM_CPPFLAGS += -D__MIPS__ diff --git a/arch/mips/mach-ath79/Makefile b/arch/mips/mach-ath79/Makefile new file mode 100644 index 000..bc0a41f --- /dev/null +++ b/arch/mips/mach-ath79/Makefile @@ -0,0 +1,9 @@ +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y += reset.o +obj-y += cpu.o +obj-y += dram.o + +obj-$(CONFIG_SOC_AR933X) += ar933x/ diff --git a/arch/mips/mach-ath79/ar933x/Makefile b/arch/mips/mach-ath79/ar933x/Makefile new file mode 100644 index 000..0da8fd4 --- /dev/null +++ b/arch/mips/mach-ath79/ar933x/Makefile @@ -0,0 +1,6 @@ +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y += lowlevel_init.o +obj-y += ddr_tap.o diff --git a/arch/mips/mach-ath79/ar933x/ddr_tap.S b/arch/mips/mach-ath79/ar933x/ddr_tap.S new file mode 100644 index 000..18c57de --- /dev/null +++ b/arch/mips/mach-ath79/ar933x/ddr_tap.S @@ -0,0 +1,268 @@ +/* + * (C) Copyright 2015 + * Wills Wang, + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include +#include +#include +#include +#include +#include + +#define DRAM_K0(x) KSEG0ADDR(x) +#define DRAM_K1(x) KSEG1ADDR(x) + + .text + .set noreorder + +LEAF(ddr_tap_init) + /* Tap settings for the DDR */ + li t0, 0x + li t1, DRAM_K0(0x50) + sw t0, 0x0(t1) + sw t0, 0x4(t1) + sw t0, 0x8(t1) + sw t0, 0xc(t1) + nop + nop + + li t8, DRAM_K1(0x2000) + li t0, 0x00 + li t1, 0x100 +0: + andit2, t0, 0x03 + li t3, 0x00 + bne t2, t3,1f +nop + li t9, 0x + sw t9, 0x0(t8) + b 2f +nop +1: + li t3, 0x01 + bne t2, t3,1f +nop + li t9, 0x + sw t9, 0x0(t8) + b 2f +nop +1: + li t3, 0x02 + bne t2, t3,1f +nop + li t9, 0x + sw t9, 0x0(t8) + b 2f +nop +1: + li t3, 0x03 + bne t2, t3,2f +nop + li t9, 0x + sw t9, 0x0(t8) +2: + andit2, t0, 0x0c + li t3, 0x00 + bne t2, t3,1f +nop + li t9, 0x + sw t9, 0x4(t8) + b 2f +nop +1: + li t3, 0x04 + bne t2, t3,1f +nop + li t9, 0x + sw t9, 0x4(t8) + b 2f +nop +1: + li t3, 0x08 + bne