On 12-12-16 09:18, Michal Simek wrote:
On 12.12.2016 09:05, Igor Grinberg wrote:
On 12/12/16 09:13, Nathan Rossi wrote:
On 12 December 2016 at 03:11, Igor Grinberg <grinb...@compulab.co.il> wrote:
dropping the list for this one as the question seems to me irrelevant to your
patch set.
On 12/11/16 18:47, Nathan Rossi wrote:
On 12 December 2016 at 01:08, Igor Grinberg <grinb...@compulab.co.il> wrote:
Hi Nathan,
On 12/11/16 15:58, Nathan Rossi wrote:
This series adds two functions for handling the memory bank decoding and
initialization of global data for use by boards in their dram_init and
dram_init_banksize functions.
I might have missed some discussions on this meter,
can you please provide the use cases for this?
IMO, the bootloader's job is to initialize the DRAM, detect its size, and pass
the detected DRAM configuration on to an OS.
Hi Igor,
I do not think there have been any discussions on this (at least none
that I am aware of).
Some boards (like Zynq and ZynqMP ones) are using
CONFIG_SYS_SDRAM_SIZE to define the amount of memory that is available
(since detection is not possible).
May I ask why is detection not possible on these boards (may be SoCs)?
That is correct, Zynq and ZynqMP are ARM SoCs. Which in the majority
of cases are used in boards which have fixed memory device setups
(without any SPD or equivalent).
Ok. That is understood. Yet, it does not explain why the detection
cannot be done.. For example, you know which memory device setups you
_can_ have on the board, so the detection is just to figure out which
one is assembled. We are doing this on i.MXes, OMAPs, PXAs, and others.
I was working on many ARM boards w/o SPD and still we almost always develop
a detection mechanism which has some assumptions and knowledge of the board
but it is much better then using some static data like compiled in or a dtb.
Have you considered a detection mechanism at all?
If you look at my previous email as you see that topic.nl is using this.
But the question is if this will work with all cases or just for
particular configuration. All zynq/zynqmp boards requires initial
setting which is created in Xilinx design tools. Export for these uniq
configurations are in ps7_init* or psu_init* files where DDR
configuration is part of this.
Devices contain various configurations for various memory types. Also
there is an option to add memory controller to programmable logic and
use it.
And the static memory controller can probably also be used to drive SRAM...
But you could combine the two. The devicetree could set up the area's to
search, and then a detection routine to check what's really there. This has
the added value of a quick test that the memory actually works before starting
to use it.
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
