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

[Mike Looijmans]

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.

> 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.
>
> 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.
>
> 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.
>
> Thanks,
> Michal
>
>
>
>
>
>
>
> 

Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans at topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





_______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>