Hi Kever,
On 21 February 2017 at 06:08, Kever Yang wrote:
> Hi Simon,
>
> On 02/14/2017 01:31 PM, Simon Glass wrote:
>>
>> Hi Kever,
>>
>> On 13 February 2017 at 01:13, Kever Yang
>> wrote:
>>>
>>> Hi Simon,
>>>
>>> On 02/08/2017 01:10 PM, Simon Glass wrote:
Hi Kever,
On 4 Fe
Hi Simon,
On 02/14/2017 01:31 PM, Simon Glass wrote:
Hi Kever,
On 13 February 2017 at 01:13, Kever Yang wrote:
Hi Simon,
On 02/08/2017 01:10 PM, Simon Glass wrote:
Hi Kever,
On 4 February 2017 at 16:30, Kever Yang wrote:
Hi Simon,
For rk3399, the data for sdram driver in dts is bi
Hi Kever,
On 13 February 2017 at 01:13, Kever Yang wrote:
> Hi Simon,
>
> On 02/08/2017 01:10 PM, Simon Glass wrote:
>>
>> Hi Kever,
>>
>> On 4 February 2017 at 16:30, Kever Yang wrote:
>>>
>>> Hi Simon,
>>>
>>> For rk3399, the data for sdram driver in dts is big, I don't want to
>>> do
>>>
Hi Simon,
On 02/08/2017 01:10 PM, Simon Glass wrote:
Hi Kever,
On 4 February 2017 at 16:30, Kever Yang wrote:
Hi Simon,
For rk3399, the data for sdram driver in dts is big, I don't want to do
the copy for it,
Are you referring to the call to fdtdec_get_int_array()? Don't you
have heaps
Hi Kever,
On 4 February 2017 at 16:30, Kever Yang wrote:
> Hi Simon,
>
> For rk3399, the data for sdram driver in dts is big, I don't want to do
> the copy for it,
Are you referring to the call to fdtdec_get_int_array()? Don't you
have heaps of SRAM though? So why does it matter? If you are
Hi Simon,
For rk3399, the data for sdram driver in dts is big, I don't want
to do the copy for it,
so I think use of-platdata is a good method, and for image size, its
smaller, then it's sooner to load.
Thanks,
- Kever
On 01/26/2017 10:22 PM, Simon Glass wrote:
Hi Kever,
On 17 January 2
Hi Kever,
On 17 January 2017 at 23:37, Kever Yang wrote:
> Hi Simon,
>
> For my rk3399(64bit) dts, the address is described as below:
> #address-cells = <2>;
> reg = <0x0 0xfe32 0x0 0x4000>;
>
> not like 32-bit soc which reg address describe like:
> reg = <0xfe32 0x4000>;
>
> Ther
7 matches
Mail list logo