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