Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Michal Simek]

On 15.12.2016 08:21, Michal Simek wrote:
> On 14.12.2016 16:00, Mike Looijmans wrote:
>>
>>> I am not marketing guy to say how often there are designs with only
>>> different DDR size like Mike's example but in fpga world you are not
>>> buying this chip to have only static part but you want to use fpga part
>>> and for that you need to use design tools. Because every design is
>>> unique you can generate device tree description directly from design
>>> tools which covers your target and this is what I believe people use.
>>
>> Well, I can't speak for everyone...
>>
>> Most people don't want to write (or even compile) a new bootloader for
>> each and every project. For our Miami SOMs, there are already more
>> full-custom carrier boards than evaluation boards. If we had to build a
>> bootloader for each such design, there'd be dozens of them.
>>
>> What we try to do is just use the generic bootloader to get the SOM up
>> and running, and then provide all the project hardware details in the
>> kernel's final devicetree. That includes changing pinmuxing and clocks
>> and stuff, which is easy to do.
> 
> That's nothing against what I have said. Having as much flexibility you
> need is great. We should support several method how to setup stuff and
> it is up to user if this method is suitable for you or not and doing
> these selection via Kconfig is the way we need to go.
> For all these autodetection algorithms you have to be sure that it is
> working fine on your platform based on testing.

Just a note for everybody. V2 patches contain compilation issue for
several boards. I have reported it back to Nathan to fix it.

Here is a log.
https://travis-ci.org/michalsimek-test/u-boot/jobs/184187944

Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Michal Simek]

On 14.12.2016 16:00, Mike Looijmans wrote:
> 
>> I am not marketing guy to say how often there are designs with only
>> different DDR size like Mike's example but in fpga world you are not
>> buying this chip to have only static part but you want to use fpga part
>> and for that you need to use design tools. Because every design is
>> unique you can generate device tree description directly from design
>> tools which covers your target and this is what I believe people use.
> 
> Well, I can't speak for everyone...
> 
> Most people don't want to write (or even compile) a new bootloader for
> each and every project. For our Miami SOMs, there are already more
> full-custom carrier boards than evaluation boards. If we had to build a
> bootloader for each such design, there'd be dozens of them.
> 
> What we try to do is just use the generic bootloader to get the SOM up
> and running, and then provide all the project hardware details in the
> kernel's final devicetree. That includes changing pinmuxing and clocks
> and stuff, which is easy to do.

That's nothing against what I have said. Having as much flexibility you
need is great. We should support several method how to setup stuff and
it is up to user if this method is suitable for you or not and doing
these selection via Kconfig is the way we need to go.
For all these autodetection algorithms you have to be sure that it is
working fine on your platform based on testing.

Thanks,
Michal


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Mike Looijmans]



I am not marketing guy to say how often there are designs with only
different DDR size like Mike's example but in fpga world you are not
buying this chip to have only static part but you want to use fpga part
and for that you need to use design tools. Because every design is
unique you can generate device tree description directly from design
tools which covers your target and this is what I believe people use.


Well, I can't speak for everyone...

Most people don't want to write (or even compile) a new bootloader for each 
and every project. For our Miami SOMs, there are already more full-custom 
carrier boards than evaluation boards. If we had to build a bootloader for 
each such design, there'd be dozens of them.


What we try to do is just use the generic bootloader to get the SOM up and 
running, and then provide all the project hardware details in the kernel's 
final devicetree. That includes changing pinmuxing and clocks and stuff, which 
is easy to do.





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.looijm...@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

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Igor Grinberg]

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  
>> 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  
 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

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Igor Grinberg]

On 12/13/16 13:07, Michal Simek wrote:
> On 13.12.2016 09:53, Igor Grinberg wrote:
>> On 12/12/16 13:56, Michal Simek wrote:
>>> On 12.12.2016 12:10, Igor Grinberg wrote:
 On 12/12/16 11:03, Michal Simek wrote:
> On 12.12.2016 09:54, Igor Grinberg wrote:
>> On 12/12/16 10:27, Michal Simek wrote:
>>> On 12.12.2016 09:24, Igor Grinberg wrote:
 On 12/12/16 10:02, Michal Simek wrote:
> On 12.12.2016 08:13, Nathan Rossi wrote:
>> On 12 December 2016 at 03:11, Igor Grinberg 
>>  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 
  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).
>
> For example zcu102 zynqmp development board is using modules with SPD 
> on
> it but if you look at generic SPD support then you will find out that
> FSL(drivers/ddr/fsl) is one of the major platform which is using it 
> for
> ddr size detection.
> Anyway as Nathan wrote above the majority of boards with zynq/zynqmp
> devices need to be configured at build time or at run time by DTB.
>
> There is also topic.nl boards which contain ddr configuration the same
> for different ddr sizes and Mike sent this patch to get it work
> http://lists.denx.de/pipermail/u-boot/2016-November/273385.html

 That's exactly my point. I think Mike's patch does a way better job
 detecting at run time than any compiled in or a DT based pseudo 
 detection...

>
> Anyway in general there are some ways how to configure DDR size
> - build time setup (CONFIG_SYS_SDRAM*)
> - run time setup
>   - ddr detection
>   - via SPD (like FSL)
>   - via algorithm (like topic.nl)
>   - configuration
>   - read DTB
>
> Nathan's path is trying to address last run time DTB configuration
> method to be shared across platforms because similar stuff Uniphier is
> using too. And it doesn't make sense to copy that functions everywhere
> that's why this should go core parts.

 Yep. That's exactly what I thought. I see Nathan's patch set as an
 improvement of the current situation anyway.

 Also I think Mike's patch does a much better job on this.

>>>
>>> Just keep in your mind just in case that you know that your
>>> configuration supports it. If you don't have DDR connected to hard block
>>> and you use ddr to PL you don't even know where to look for DDR.
>>> And with arm64 it is pretty huge space.
>>
>> I see this as exactly the type of information that should be provided by
>> the board code or a dtb.
>
> I tend to remove all board files for zynq/zynqmp targets. Will see how
> we can do it in future.

 This is not really related to current thread...
>>>
>>> not directly but there is a connection.
>>>
 I'm not sure how this can be done... We're in a bootloader world here...
 It should be board specific by definition...
 There should be board specific code (not static data) somewhere, and
 I think we had agreed a year or so ago... on this meter.
 I think if you go this way, we will end up having board specific middleware
 all around... and lots of tools for 

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Michal Simek]

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  
> 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  
>>> 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


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Michal Simek]

On 13.12.2016 09:53, Igor Grinberg wrote:
> On 12/12/16 13:56, Michal Simek wrote:
>> On 12.12.2016 12:10, Igor Grinberg wrote:
>>> On 12/12/16 11:03, Michal Simek wrote:
 On 12.12.2016 09:54, Igor Grinberg wrote:
> On 12/12/16 10:27, Michal Simek wrote:
>> On 12.12.2016 09:24, Igor Grinberg wrote:
>>> On 12/12/16 10:02, Michal Simek wrote:
 On 12.12.2016 08:13, Nathan Rossi wrote:
> On 12 December 2016 at 03:11, Igor Grinberg  
> 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 
>>>  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).

 For example zcu102 zynqmp development board is using modules with SPD 
 on
 it but if you look at generic SPD support then you will find out that
 FSL(drivers/ddr/fsl) is one of the major platform which is using it for
 ddr size detection.
 Anyway as Nathan wrote above the majority of boards with zynq/zynqmp
 devices need to be configured at build time or at run time by DTB.

 There is also topic.nl boards which contain ddr configuration the same
 for different ddr sizes and Mike sent this patch to get it work
 http://lists.denx.de/pipermail/u-boot/2016-November/273385.html
>>>
>>> That's exactly my point. I think Mike's patch does a way better job
>>> detecting at run time than any compiled in or a DT based pseudo 
>>> detection...
>>>

 Anyway in general there are some ways how to configure DDR size
 - build time setup (CONFIG_SYS_SDRAM*)
 - run time setup
- ddr detection
- via SPD (like FSL)
- via algorithm (like topic.nl)
- configuration
- read DTB

 Nathan's path is trying to address last run time DTB configuration
 method to be shared across platforms because similar stuff Uniphier is
 using too. And it doesn't make sense to copy that functions everywhere
 that's why this should go core parts.
>>>
>>> Yep. That's exactly what I thought. I see Nathan's patch set as an
>>> improvement of the current situation anyway.
>>>
>>> Also I think Mike's patch does a much better job on this.
>>>
>>
>> Just keep in your mind just in case that you know that your
>> configuration supports it. If you don't have DDR connected to hard block
>> and you use ddr to PL you don't even know where to look for DDR.
>> And with arm64 it is pretty huge space.
>
> I see this as exactly the type of information that should be provided by
> the board code or a dtb.

 I tend to remove all board files for zynq/zynqmp targets. Will see how
 we can do it in future.
>>>
>>> This is not really related to current thread...
>>
>> not directly but there is a connection.
>>
>>> I'm not sure how this can be done... We're in a bootloader world here...
>>> It should be board specific by definition...
>>> There should be board specific code (not static data) somewhere, and
>>> I think we had agreed a year or so ago... on this meter.
>>> I think if you go this way, we will end up having board specific middleware
>>> all around... and lots of tools for changing the static data (e.g. dtbs).
>>
>> Look at microblaze. I am not accepting any board to be added for it
>> because every configuration is different.
> 
> 

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Igor Grinberg]

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  
 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  
>> 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

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Igor Grinberg]

On 12/12/16 13:56, Michal Simek wrote:
> On 12.12.2016 12:10, Igor Grinberg wrote:
>> On 12/12/16 11:03, Michal Simek wrote:
>>> On 12.12.2016 09:54, Igor Grinberg wrote:
 On 12/12/16 10:27, Michal Simek wrote:
> On 12.12.2016 09:24, Igor Grinberg wrote:
>> On 12/12/16 10:02, Michal Simek wrote:
>>> On 12.12.2016 08:13, Nathan Rossi wrote:
 On 12 December 2016 at 03:11, Igor Grinberg  
 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 
>>  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).
>>>
>>> For example zcu102 zynqmp development board is using modules with SPD on
>>> it but if you look at generic SPD support then you will find out that
>>> FSL(drivers/ddr/fsl) is one of the major platform which is using it for
>>> ddr size detection.
>>> Anyway as Nathan wrote above the majority of boards with zynq/zynqmp
>>> devices need to be configured at build time or at run time by DTB.
>>>
>>> There is also topic.nl boards which contain ddr configuration the same
>>> for different ddr sizes and Mike sent this patch to get it work
>>> http://lists.denx.de/pipermail/u-boot/2016-November/273385.html
>>
>> That's exactly my point. I think Mike's patch does a way better job
>> detecting at run time than any compiled in or a DT based pseudo 
>> detection...
>>
>>>
>>> Anyway in general there are some ways how to configure DDR size
>>> - build time setup (CONFIG_SYS_SDRAM*)
>>> - run time setup
>>> - ddr detection
>>> - via SPD (like FSL)
>>> - via algorithm (like topic.nl)
>>> - configuration
>>> - read DTB
>>>
>>> Nathan's path is trying to address last run time DTB configuration
>>> method to be shared across platforms because similar stuff Uniphier is
>>> using too. And it doesn't make sense to copy that functions everywhere
>>> that's why this should go core parts.
>>
>> Yep. That's exactly what I thought. I see Nathan's patch set as an
>> improvement of the current situation anyway.
>>
>> Also I think Mike's patch does a much better job on this.
>>
>
> Just keep in your mind just in case that you know that your
> configuration supports it. If you don't have DDR connected to hard block
> and you use ddr to PL you don't even know where to look for DDR.
> And with arm64 it is pretty huge space.

 I see this as exactly the type of information that should be provided by
 the board code or a dtb.
>>>
>>> I tend to remove all board files for zynq/zynqmp targets. Will see how
>>> we can do it in future.
>>
>> This is not really related to current thread...
> 
> not directly but there is a connection.
> 
>> I'm not sure how this can be done... We're in a bootloader world here...
>> It should be board specific by definition...
>> There should be board specific code (not static data) somewhere, and
>> I think we had agreed a year or so ago... on this meter.
>> I think if you go this way, we will end up having board specific middleware
>> all around... and lots of tools for changing the static data (e.g. dtbs).
> 
> Look at microblaze. I am not accepting any board to be added for it
> because every configuration is different.

I'm not sure I get your point.

> The same can be done for
> zynq/zynqmp boards when we move stuff to DM.
> Then for supporting new platform you don't need to create folder in
> 

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Mike Looijmans]

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  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  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.looijm...@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



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Michal Simek]

On 12.12.2016 12:10, Igor Grinberg wrote:
> On 12/12/16 11:03, Michal Simek wrote:
>> On 12.12.2016 09:54, Igor Grinberg wrote:
>>> On 12/12/16 10:27, Michal Simek wrote:
 On 12.12.2016 09:24, Igor Grinberg wrote:
> On 12/12/16 10:02, Michal Simek wrote:
>> On 12.12.2016 08:13, Nathan Rossi wrote:
>>> On 12 December 2016 at 03:11, Igor Grinberg  
>>> 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  
> 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).
>>
>> For example zcu102 zynqmp development board is using modules with SPD on
>> it but if you look at generic SPD support then you will find out that
>> FSL(drivers/ddr/fsl) is one of the major platform which is using it for
>> ddr size detection.
>> Anyway as Nathan wrote above the majority of boards with zynq/zynqmp
>> devices need to be configured at build time or at run time by DTB.
>>
>> There is also topic.nl boards which contain ddr configuration the same
>> for different ddr sizes and Mike sent this patch to get it work
>> http://lists.denx.de/pipermail/u-boot/2016-November/273385.html
>
> That's exactly my point. I think Mike's patch does a way better job
> detecting at run time than any compiled in or a DT based pseudo 
> detection...
>
>>
>> Anyway in general there are some ways how to configure DDR size
>> - build time setup (CONFIG_SYS_SDRAM*)
>> - run time setup
>>  - ddr detection
>>  - via SPD (like FSL)
>>  - via algorithm (like topic.nl)
>>  - configuration
>>  - read DTB
>>
>> Nathan's path is trying to address last run time DTB configuration
>> method to be shared across platforms because similar stuff Uniphier is
>> using too. And it doesn't make sense to copy that functions everywhere
>> that's why this should go core parts.
>
> Yep. That's exactly what I thought. I see Nathan's patch set as an
> improvement of the current situation anyway.
>
> Also I think Mike's patch does a much better job on this.
>

 Just keep in your mind just in case that you know that your
 configuration supports it. If you don't have DDR connected to hard block
 and you use ddr to PL you don't even know where to look for DDR.
 And with arm64 it is pretty huge space.
>>>
>>> I see this as exactly the type of information that should be provided by
>>> the board code or a dtb.
>>
>> I tend to remove all board files for zynq/zynqmp targets. Will see how
>> we can do it in future.
> 
> This is not really related to current thread...

not directly but there is a connection.

> I'm not sure how this can be done... We're in a bootloader world here...
> It should be board specific by definition...
> There should be board specific code (not static data) somewhere, and
> I think we had agreed a year or so ago... on this meter.
> I think if you go this way, we will end up having board specific middleware
> all around... and lots of tools for changing the static data (e.g. dtbs).

Look at microblaze. I am not accepting any board to be added for it
because every configuration is different. The same can be done for
zynq/zynqmp boards when we move stuff to DM.
Then for supporting new platform you don't need to create folder in
board and file include/configs/ and all you need is dts file and
defconfig. In case of SPL for us we need to also put somewhere ps7*/psu*
init files.
DT is design to describe hardware and current configuration which I
believe we can.
There 

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Igor Grinberg]

On 12/12/16 11:03, Michal Simek wrote:
> On 12.12.2016 09:54, Igor Grinberg wrote:
>> On 12/12/16 10:27, Michal Simek wrote:
>>> On 12.12.2016 09:24, Igor Grinberg wrote:
 On 12/12/16 10:02, Michal Simek wrote:
> On 12.12.2016 08:13, Nathan Rossi wrote:
>> On 12 December 2016 at 03:11, Igor Grinberg  
>> 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  
 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).
>
> For example zcu102 zynqmp development board is using modules with SPD on
> it but if you look at generic SPD support then you will find out that
> FSL(drivers/ddr/fsl) is one of the major platform which is using it for
> ddr size detection.
> Anyway as Nathan wrote above the majority of boards with zynq/zynqmp
> devices need to be configured at build time or at run time by DTB.
>
> There is also topic.nl boards which contain ddr configuration the same
> for different ddr sizes and Mike sent this patch to get it work
> http://lists.denx.de/pipermail/u-boot/2016-November/273385.html

 That's exactly my point. I think Mike's patch does a way better job
 detecting at run time than any compiled in or a DT based pseudo 
 detection...

>
> Anyway in general there are some ways how to configure DDR size
> - build time setup (CONFIG_SYS_SDRAM*)
> - run time setup
>   - ddr detection
>   - via SPD (like FSL)
>   - via algorithm (like topic.nl)
>   - configuration
>   - read DTB
>
> Nathan's path is trying to address last run time DTB configuration
> method to be shared across platforms because similar stuff Uniphier is
> using too. And it doesn't make sense to copy that functions everywhere
> that's why this should go core parts.

 Yep. That's exactly what I thought. I see Nathan's patch set as an
 improvement of the current situation anyway.

 Also I think Mike's patch does a much better job on this.

>>>
>>> Just keep in your mind just in case that you know that your
>>> configuration supports it. If you don't have DDR connected to hard block
>>> and you use ddr to PL you don't even know where to look for DDR.
>>> And with arm64 it is pretty huge space.
>>
>> I see this as exactly the type of information that should be provided by
>> the board code or a dtb.
> 
> I tend to remove all board files for zynq/zynqmp targets. Will see how
> we can do it in future.

This is not really related to current thread...
I'm not sure how this can be done... We're in a bootloader world here...
It should be board specific by definition...
There should be board specific code (not static data) somewhere, and
I think we had agreed a year or so ago... on this meter.
I think if you go this way, we will end up having board specific middleware
all around... and lots of tools for changing the static data (e.g. dtbs).


-- 
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Michal Simek]

On 12.12.2016 09:54, Igor Grinberg wrote:
> On 12/12/16 10:27, Michal Simek wrote:
>> On 12.12.2016 09:24, Igor Grinberg wrote:
>>> On 12/12/16 10:02, Michal Simek wrote:
 On 12.12.2016 08:13, Nathan Rossi wrote:
> On 12 December 2016 at 03:11, Igor Grinberg  
> 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  
>>> 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).

 For example zcu102 zynqmp development board is using modules with SPD on
 it but if you look at generic SPD support then you will find out that
 FSL(drivers/ddr/fsl) is one of the major platform which is using it for
 ddr size detection.
 Anyway as Nathan wrote above the majority of boards with zynq/zynqmp
 devices need to be configured at build time or at run time by DTB.

 There is also topic.nl boards which contain ddr configuration the same
 for different ddr sizes and Mike sent this patch to get it work
 http://lists.denx.de/pipermail/u-boot/2016-November/273385.html
>>>
>>> That's exactly my point. I think Mike's patch does a way better job
>>> detecting at run time than any compiled in or a DT based pseudo detection...
>>>

 Anyway in general there are some ways how to configure DDR size
 - build time setup (CONFIG_SYS_SDRAM*)
 - run time setup
- ddr detection
- via SPD (like FSL)
- via algorithm (like topic.nl)
- configuration
- read DTB

 Nathan's path is trying to address last run time DTB configuration
 method to be shared across platforms because similar stuff Uniphier is
 using too. And it doesn't make sense to copy that functions everywhere
 that's why this should go core parts.
>>>
>>> Yep. That's exactly what I thought. I see Nathan's patch set as an
>>> improvement of the current situation anyway.
>>>
>>> Also I think Mike's patch does a much better job on this.
>>>
>>
>> Just keep in your mind just in case that you know that your
>> configuration supports it. If you don't have DDR connected to hard block
>> and you use ddr to PL you don't even know where to look for DDR.
>> And with arm64 it is pretty huge space.
> 
> I see this as exactly the type of information that should be provided by
> the board code or a dtb.

I tend to remove all board files for zynq/zynqmp targets. Will see how
we can do it in future.

Thanks,
Michal


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Igor Grinberg]

On 12/12/16 10:27, Michal Simek wrote:
> On 12.12.2016 09:24, Igor Grinberg wrote:
>> On 12/12/16 10:02, Michal Simek wrote:
>>> On 12.12.2016 08:13, Nathan Rossi wrote:
 On 12 December 2016 at 03:11, Igor Grinberg  
 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  
>> 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).
>>>
>>> For example zcu102 zynqmp development board is using modules with SPD on
>>> it but if you look at generic SPD support then you will find out that
>>> FSL(drivers/ddr/fsl) is one of the major platform which is using it for
>>> ddr size detection.
>>> Anyway as Nathan wrote above the majority of boards with zynq/zynqmp
>>> devices need to be configured at build time or at run time by DTB.
>>>
>>> There is also topic.nl boards which contain ddr configuration the same
>>> for different ddr sizes and Mike sent this patch to get it work
>>> http://lists.denx.de/pipermail/u-boot/2016-November/273385.html
>>
>> That's exactly my point. I think Mike's patch does a way better job
>> detecting at run time than any compiled in or a DT based pseudo detection...
>>
>>>
>>> Anyway in general there are some ways how to configure DDR size
>>> - build time setup (CONFIG_SYS_SDRAM*)
>>> - run time setup
>>> - ddr detection
>>> - via SPD (like FSL)
>>> - via algorithm (like topic.nl)
>>> - configuration
>>> - read DTB
>>>
>>> Nathan's path is trying to address last run time DTB configuration
>>> method to be shared across platforms because similar stuff Uniphier is
>>> using too. And it doesn't make sense to copy that functions everywhere
>>> that's why this should go core parts.
>>
>> Yep. That's exactly what I thought. I see Nathan's patch set as an
>> improvement of the current situation anyway.
>>
>> Also I think Mike's patch does a much better job on this.
>>
> 
> Just keep in your mind just in case that you know that your
> configuration supports it. If you don't have DDR connected to hard block
> and you use ddr to PL you don't even know where to look for DDR.
> And with arm64 it is pretty huge space.

I see this as exactly the type of information that should be provided by
the board code or a dtb.

> It means we really have to provide ways how to do it and these patches
> are just generic way how to do it via reading DTB instead of code
> duplication (+ bug) which we have now.

No doubt, Nathan's patch improves the situation.

-- 
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Igor Grinberg]

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  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  
> 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

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Michal Simek]

On 12.12.2016 09:24, Igor Grinberg wrote:
> On 12/12/16 10:02, Michal Simek wrote:
>> On 12.12.2016 08:13, Nathan Rossi wrote:
>>> On 12 December 2016 at 03:11, Igor Grinberg  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  
> 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).
>>
>> For example zcu102 zynqmp development board is using modules with SPD on
>> it but if you look at generic SPD support then you will find out that
>> FSL(drivers/ddr/fsl) is one of the major platform which is using it for
>> ddr size detection.
>> Anyway as Nathan wrote above the majority of boards with zynq/zynqmp
>> devices need to be configured at build time or at run time by DTB.
>>
>> There is also topic.nl boards which contain ddr configuration the same
>> for different ddr sizes and Mike sent this patch to get it work
>> http://lists.denx.de/pipermail/u-boot/2016-November/273385.html
> 
> That's exactly my point. I think Mike's patch does a way better job
> detecting at run time than any compiled in or a DT based pseudo detection...
> 
>>
>> Anyway in general there are some ways how to configure DDR size
>> - build time setup (CONFIG_SYS_SDRAM*)
>> - run time setup
>>  - ddr detection
>>  - via SPD (like FSL)
>>  - via algorithm (like topic.nl)
>>  - configuration
>>  - read DTB
>>
>> Nathan's path is trying to address last run time DTB configuration
>> method to be shared across platforms because similar stuff Uniphier is
>> using too. And it doesn't make sense to copy that functions everywhere
>> that's why this should go core parts.
> 
> Yep. That's exactly what I thought. I see Nathan's patch set as an
> improvement of the current situation anyway.
> 
> Also I think Mike's patch does a much better job on this.
> 

Just keep in your mind just in case that you know that your
configuration supports it. If you don't have DDR connected to hard block
and you use ddr to PL you don't even know where to look for DDR.
And with arm64 it is pretty huge space.
It means we really have to provide ways how to do it and these patches
are just generic way how to do it via reading DTB instead of code
duplication (+ bug) which we have now.

Thanks,
Michal


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Igor Grinberg]

On 12/12/16 10:02, Michal Simek wrote:
> On 12.12.2016 08:13, Nathan Rossi wrote:
>> On 12 December 2016 at 03:11, Igor Grinberg  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  
 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).
> 
> For example zcu102 zynqmp development board is using modules with SPD on
> it but if you look at generic SPD support then you will find out that
> FSL(drivers/ddr/fsl) is one of the major platform which is using it for
> ddr size detection.
> Anyway as Nathan wrote above the majority of boards with zynq/zynqmp
> devices need to be configured at build time or at run time by DTB.
> 
> There is also topic.nl boards which contain ddr configuration the same
> for different ddr sizes and Mike sent this patch to get it work
> http://lists.denx.de/pipermail/u-boot/2016-November/273385.html

That's exactly my point. I think Mike's patch does a way better job
detecting at run time than any compiled in or a DT based pseudo detection...

> 
> Anyway in general there are some ways how to configure DDR size
> - build time setup (CONFIG_SYS_SDRAM*)
> - run time setup
>   - ddr detection
>   - via SPD (like FSL)
>   - via algorithm (like topic.nl)
>   - configuration
>   - read DTB
> 
> Nathan's path is trying to address last run time DTB configuration
> method to be shared across platforms because similar stuff Uniphier is
> using too. And it doesn't make sense to copy that functions everywhere
> that's why this should go core parts.

Yep. That's exactly what I thought. I see Nathan's patch set as an
improvement of the current situation anyway.

Also I think Mike's patch does a much better job on this.

-- 
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Michal Simek]

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  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  
 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

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Michal Simek]

On 12.12.2016 08:13, Nathan Rossi wrote:
> On 12 December 2016 at 03:11, Igor Grinberg  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  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).

For example zcu102 zynqmp development board is using modules with SPD on
it but if you look at generic SPD support then you will find out that
FSL(drivers/ddr/fsl) is one of the major platform which is using it for
ddr size detection.
Anyway as Nathan wrote above the majority of boards with zynq/zynqmp
devices need to be configured at build time or at run time by DTB.

There is also topic.nl boards which contain ddr configuration the same
for different ddr sizes and Mike sent this patch to get it work
http://lists.denx.de/pipermail/u-boot/2016-November/273385.html

Anyway in general there are some ways how to configure DDR size
- build time setup (CONFIG_SYS_SDRAM*)
- run time setup
- ddr detection
- via SPD (like FSL)
- via algorithm (like topic.nl)
- configuration
- read DTB

Nathan's path is trying to address last run time DTB configuration
method to be shared across platforms because similar stuff Uniphier is
using too. And it doesn't make sense to copy that functions everywhere
that's why this should go core parts.

Thanks,
Michal

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Nathan Rossi]

On 12 December 2016 at 03:08, Igor Grinberg  wrote:
> On 12/11/16 18:47, Nathan Rossi wrote:
>> On 12 December 2016 at 01:08, Igor Grinberg  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). However with the introduction of
>> dtbs for some boards they are also capable of loading the size of
>> memory from the embedded/appended dtb (instead of hardcoded). This
>> allows for more of the board config to be loaded from the device tree
>> instead of from include/configs/*.h. This however is up to the
>> individual board to implement in its dram_init* functions.
>
> Thanks for the explanation!
> I assume that the key point is "detection is not possible" and therefore
> we must rely on a user or a production process to place (append) the correct 
> dtb.
> Makes sense to me now and looks like an improvement to the current situation.
>
>>
>> The first patch of the series is only adding some decoding helper
>> functions to make this generic between the Zynq and ZynqMP boards as
>> well as to allow for any other boards that may want to use the same
>> mechanism to get the memory size from the fdt. There is no requirement
>> for boards to use these functions.
>
> Can you please next time place a similar explanation in at least the cover
> letter. This way, the intent might be understood the first time ;-)

Sorry about that, I will make sure future series have more complete
descriptions in the cover letter. I have however updated the
description for this in the v2 for completeness.

> I would also like to see some parts of the above explanation in the functions
> documentation (e.g. this allows to improve the DRAM configuration mechanics
> on boards that cannot detect its DRAM size/config).

Will add in v2.

Regards,
Nathan

>
> Thanks!
>
>>
>> Regards,
>> Nathan
>>
>>>

 The series also changes the zynq and zynqmp board implementations to use
 these functions to resolve a issue with static variable use.

 Nathan Rossi (3):
   fdt: add memory bank decoding functions for board setup
   ARM: zynq: Replace board specific with generic memory bank decoding
   ARM64: zynqmp: Replace board specific with generic memory bank
 decoding

  board/xilinx/zynq/board.c| 112 
 ++-
  board/xilinx/zynqmp/zynqmp.c | 112 
 ++-
  include/fdtdec.h |  25 ++
  lib/fdtdec.c |  54 +
  4 files changed, 85 insertions(+), 218 deletions(-)

>>>
>>> --
>>> Regards,
>>> Igor.
>>
>
> --
> Regards,
> Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Igor Grinberg]

On 12/11/16 18:47, Nathan Rossi wrote:
> On 12 December 2016 at 01:08, Igor Grinberg  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). However with the introduction of
> dtbs for some boards they are also capable of loading the size of
> memory from the embedded/appended dtb (instead of hardcoded). This
> allows for more of the board config to be loaded from the device tree
> instead of from include/configs/*.h. This however is up to the
> individual board to implement in its dram_init* functions.

Thanks for the explanation!
I assume that the key point is "detection is not possible" and therefore
we must rely on a user or a production process to place (append) the correct 
dtb.
Makes sense to me now and looks like an improvement to the current situation.

> 
> The first patch of the series is only adding some decoding helper
> functions to make this generic between the Zynq and ZynqMP boards as
> well as to allow for any other boards that may want to use the same
> mechanism to get the memory size from the fdt. There is no requirement
> for boards to use these functions.

Can you please next time place a similar explanation in at least the cover
letter. This way, the intent might be understood the first time ;-)
I would also like to see some parts of the above explanation in the functions
documentation (e.g. this allows to improve the DRAM configuration mechanics
on boards that cannot detect its DRAM size/config).

Thanks!

> 
> Regards,
> Nathan
> 
>>
>>>
>>> The series also changes the zynq and zynqmp board implementations to use
>>> these functions to resolve a issue with static variable use.
>>>
>>> Nathan Rossi (3):
>>>   fdt: add memory bank decoding functions for board setup
>>>   ARM: zynq: Replace board specific with generic memory bank decoding
>>>   ARM64: zynqmp: Replace board specific with generic memory bank
>>> decoding
>>>
>>>  board/xilinx/zynq/board.c| 112 
>>> ++-
>>>  board/xilinx/zynqmp/zynqmp.c | 112 
>>> ++-
>>>  include/fdtdec.h |  25 ++
>>>  lib/fdtdec.c |  54 +
>>>  4 files changed, 85 insertions(+), 218 deletions(-)
>>>
>>
>> --
>> Regards,
>> Igor.
> 

-- 
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Nathan Rossi]

On 12 December 2016 at 01:08, Igor Grinberg  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). However with the introduction of
dtbs for some boards they are also capable of loading the size of
memory from the embedded/appended dtb (instead of hardcoded). This
allows for more of the board config to be loaded from the device tree
instead of from include/configs/*.h. This however is up to the
individual board to implement in its dram_init* functions.

The first patch of the series is only adding some decoding helper
functions to make this generic between the Zynq and ZynqMP boards as
well as to allow for any other boards that may want to use the same
mechanism to get the memory size from the fdt. There is no requirement
for boards to use these functions.

Regards,
Nathan

>
>>
>> The series also changes the zynq and zynqmp board implementations to use
>> these functions to resolve a issue with static variable use.
>>
>> Nathan Rossi (3):
>>   fdt: add memory bank decoding functions for board setup
>>   ARM: zynq: Replace board specific with generic memory bank decoding
>>   ARM64: zynqmp: Replace board specific with generic memory bank
>> decoding
>>
>>  board/xilinx/zynq/board.c| 112 
>> ++-
>>  board/xilinx/zynqmp/zynqmp.c | 112 
>> ++-
>>  include/fdtdec.h |  25 ++
>>  lib/fdtdec.c |  54 +
>>  4 files changed, 85 insertions(+), 218 deletions(-)
>>
>
> --
> Regards,
> Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Igor Grinberg]

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.

> 
> The series also changes the zynq and zynqmp board implementations to use
> these functions to resolve a issue with static variable use.
> 
> Nathan Rossi (3):
>   fdt: add memory bank decoding functions for board setup
>   ARM: zynq: Replace board specific with generic memory bank decoding
>   ARM64: zynqmp: Replace board specific with generic memory bank
> decoding
> 
>  board/xilinx/zynq/board.c| 112 
> ++-
>  board/xilinx/zynqmp/zynqmp.c | 112 
> ++-
>  include/fdtdec.h |  25 ++
>  lib/fdtdec.c |  54 +
>  4 files changed, 85 insertions(+), 218 deletions(-)
> 

-- 
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/3] Add generic FDT memory bank decoding and gd initialization

[Nathan Rossi]

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.

The series also changes the zynq and zynqmp board implementations to use
these functions to resolve a issue with static variable use.

Nathan Rossi (3):
  fdt: add memory bank decoding functions for board setup
  ARM: zynq: Replace board specific with generic memory bank decoding
  ARM64: zynqmp: Replace board specific with generic memory bank
decoding

 board/xilinx/zynq/board.c| 112 ++-
 board/xilinx/zynqmp/zynqmp.c | 112 ++-
 include/fdtdec.h |  25 ++
 lib/fdtdec.c |  54 +
 4 files changed, 85 insertions(+), 218 deletions(-)

-- 
2.10.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot