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