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

2015-12-28 Thread Wills Wang 



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

2015-12-28 Thread Marek Vasut 
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

2015-12-28 Thread 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 ...
___
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

2015-12-28 Thread Daniel Schwierzeck 


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

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

2015-12-28 Thread Marek Vasut 
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

2015-12-28 Thread Wills Wang 



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

2015-12-28 Thread Wills Wang 



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

2015-12-27 Thread Wills Wang 



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

2015-12-27 Thread 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 ?

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

2015-12-27 Thread Wills Wang 



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

2015-12-27 Thread Daniel Schwierzeck 


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

2015-12-27 Thread Wills Wang 



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

2015-12-27 Thread Marek Vasut 
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

2015-12-27 Thread Marek Vasut 
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

2015-12-27 Thread Marek Vasut 
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

2015-12-27 Thread Wills Wang 



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

2015-12-26 Thread Wills Wang 

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

2015-12-26 Thread Marek Vasut 
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

2015-12-26 Thread Marek Vasut 
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

2015-12-26 Thread Marek Vasut 
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

2015-12-26 Thread Wills Wang 



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

2015-12-26 Thread Wills Wang 



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

2015-12-26 Thread Marek Vasut 
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

2015-12-25 Thread Marek Vasut 
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

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

2015-12-24 Thread Wills Wang 
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

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

2015-12-24 Thread Marek Vasut 
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)

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

2015-12-24 Thread Wills Wang 



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

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

2015-12-24 Thread Marek Vasut 
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