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

[Igor Grinberg]

On 12/13/16 13:12, Michal Simek wrote:
> 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.

Well, if it is generic enough it really should.

-- 
Regards,
Igor.