[U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Igor Grinberg]

On 12/12/16 14:05, Mike Looijmans wrote:
> On 12-12-16 09:18, Michal Simek wrote:
>> On 12.12.2016 09:05, Igor Grinberg wrote:
>>> On 12/12/16 09:13, Nathan Rossi wrote:
>>>> On 12 December 2016 at 03:11, Igor Grinberg <grinberg at compulab.co.il> wrote:
>>>>> dropping the list for this one as the question seems to me irrelevant to your patch set.
>>>>>
>>>>> On 12/11/16 18:47, Nathan Rossi wrote:
>>>>>> On 12 December 2016 at 01:08, Igor Grinberg <grinberg at compulab.co.il> wrote:
>>>>>>> Hi Nathan,
>>>>>>>
>>>>>>> On 12/11/16 15:58, Nathan Rossi wrote:
>>>>>>>> This series adds two functions for handling the memory bank decoding and
>>>>>>>> initialization of global data for use by boards in their dram_init and
>>>>>>>> dram_init_banksize functions.
>>>>>>>
>>>>>>> I might have missed some discussions on this meter,
>>>>>>> can you please provide the use cases for this?
>>>>>>> IMO, the bootloader's job is to initialize the DRAM, detect its size, and pass
>>>>>>> the detected DRAM configuration on to an OS.
>>>>>>
>>>>>> Hi Igor,
>>>>>>
>>>>>> I do not think there have been any discussions on this (at least none
>>>>>> that I am aware of).
>>>>>>
>>>>>> Some boards (like Zynq and ZynqMP ones) are using
>>>>>> CONFIG_SYS_SDRAM_SIZE to define the amount of memory that is available
>>>>>> (since detection is not possible).
>>>>>
>>>>> May I ask why is detection not possible on these boards (may be SoCs)?
>>>>
>>>> That is correct, Zynq and ZynqMP are ARM SoCs. Which in the majority
>>>> of cases are used in boards which have fixed memory device setups
>>>> (without any SPD or equivalent).
>>>
>>> Ok. That is understood. Yet, it does not explain why the detection
>>> cannot be done.. For example, you know which memory device setups you
>>> _can_ have on the board, so the detection is just to figure out which
>>> one is assembled. We are doing this on i.MXes, OMAPs, PXAs, and others.
>>>
>>> I was working on many ARM boards w/o SPD and still we almost always develop
>>> a detection mechanism which has some assumptions and knowledge of the board
>>> but it is much better then using some static data like compiled in or a dtb.
>>>
>>> Have you considered a detection mechanism at all?
>>
>> If you look at my previous email as you see that topic.nl is using this.
>>
>> But the question is if this will work with all cases or just for
>> particular configuration. All zynq/zynqmp boards requires initial
>> setting which is created in Xilinx design tools. Export for these uniq
>> configurations are in ps7_init* or psu_init* files where DDR
>> configuration is part of this.
>>
>> Devices contain various configurations for various memory types. Also
>> there is an option to add memory controller to programmable logic and
>> use it.
> 
> And the static memory controller can probably also be used to drive SRAM...
> 
> But you could combine the two. The devicetree could set up the area's to search, and then a detection routine to check what's really there. This has the added value of a quick test that the memory actually works before starting to use it.

That's exactly the point I was trying to show.
Thanks Mike.


-- 
Regards,
Igor.