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