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

[Michal Simek]

On 13.12.2016 09:56, Igor Grinberg wrote:
> 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.

No problem with this but for me this is generic configuration option.
It means this should be covered by Kconfig to be selected for specific
platform. This code should go to common folder not to board folder or
arm-mach folder.

Thanks,
Michal