Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization
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@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@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
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 grinberg@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@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.
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@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@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@topicproducts.com Website: www.topicproducts.com
Please consider the environment before printing this e-mail
_______________________________________________
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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 grinberg@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@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.
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 grinberg@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@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.
Thanks, Michal
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 grinberg@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@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.
participants (3)
-
Igor Grinberg -
Michal Simek -
Mike Looijmans