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 <grinb...@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 <grinb...@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. 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
