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

[Igor Grinberg]

On 12/12/16 10: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.

No, I sent it before seeing the email and Mike's patches.

> 
> 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.

Well, I think the board can provide the configuration as the board maintainer
probably knows it. I can be with the vendor provided tools or some other ways.
Once the configuration is provided, a common code should be able to do
the detection.

> 
> Devices contain various configurations for various memory types. Also
> there is an option to add memory controller to programmable logic and
> use it.
> At the end of the day we won't be able to find out generic way for all
> zynq/zynqmp boards which will simply work everywhere.

That's sounds correct. You can abstract the configuration process
and each board should provide its configuration data.

> 
> Just a summary of this. If you have one line of products which you have
> tested and you know how they work then topic.nl solution is a way to go.
> But I don't think I want to risk to have this only one method for all
> zynq/zynqmp SoC.

I don't think you need to.

> 
> Maybe thinking a little bit to the future. U-Boot is using linked-lists
> more than before and we could provide all options as I described (and
> maybe more) call them in loop. Limit this via Kconfig etc.

Yep. All the above sounds sane to me.


-- 
Regards,
Igor.