Re: [U-Boot] [PATCH 0/2]: OMAP3 SPL updates
Hi Tom, On 10/10/11 05:01, Tom Rini wrote: On Sun, Oct 9, 2011 at 2:21 AM, Igor Grinberg grinb...@compulab.co.il wrote: On 10/07/11 02:28, Tom Rini wrote: On Tue, Oct 4, 2011 at 7:59 AM, Tom Rini tr...@ti.com wrote: Hey all, The following short series does two things. First, it re-works where we do memory initalization in SPL for OMAP3 to be board-specific. This is needed since in many cases (beagleboard, omap3evm) what timings we set depend on what hardware we detect ourself to be running on. Second, along those same lines what omap_rev_string tells us is doing to be board specific as well so provide a weak version in the common omap SPL code and lets it be replaced as needed. Please disregard this version, I need to do a full v3 with the right set of board_early_sdrc_init, sorry for the noise. While I was looking at the series, I've got similar thoughts. May be this should be facilitated by providing kind of framework for the board file only to set the right settings and not duplicate the board_early_sdrc_init() function (with changed values)? The problem is that what to do is very board specific. For example for beagleboard we need to probe the nand driver to see what package we have and then pick from at least 3, maybe 4 or 5 (I don't have the code in front of me) settings. This only means that the framework (or just a common function call) should be flexible enough to let the board choose the right configuration in runtime. After all the DRAM controller should be initialized by the same sequence just with different values. That said, perhaps a function that takes the series of values that do change would be a little clearer in the end so I'll give that a spin once I've gotten beagle and omap3evm spun up again (and maybe finally gotten NAND SPL working there, it seems to be an omap3-specific issue sadly). How about a something like board_get_dram_params() (defined weak) implemented by a board file and a call added to current DRAM controller initialization sequence? -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2]: OMAP3 SPL updates
On 10/07/11 02:28, Tom Rini wrote: On Tue, Oct 4, 2011 at 7:59 AM, Tom Rini tr...@ti.com wrote: Hey all, The following short series does two things. First, it re-works where we do memory initalization in SPL for OMAP3 to be board-specific. This is needed since in many cases (beagleboard, omap3evm) what timings we set depend on what hardware we detect ourself to be running on. Second, along those same lines what omap_rev_string tells us is doing to be board specific as well so provide a weak version in the common omap SPL code and lets it be replaced as needed. Please disregard this version, I need to do a full v3 with the right set of board_early_sdrc_init, sorry for the noise. While I was looking at the series, I've got similar thoughts. May be this should be facilitated by providing kind of framework for the board file only to set the right settings and not duplicate the board_early_sdrc_init() function (with changed values)? -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2]: OMAP3 SPL updates
On Sun, Oct 9, 2011 at 2:21 AM, Igor Grinberg grinb...@compulab.co.il wrote: On 10/07/11 02:28, Tom Rini wrote: On Tue, Oct 4, 2011 at 7:59 AM, Tom Rini tr...@ti.com wrote: Hey all, The following short series does two things. First, it re-works where we do memory initalization in SPL for OMAP3 to be board-specific. This is needed since in many cases (beagleboard, omap3evm) what timings we set depend on what hardware we detect ourself to be running on. Second, along those same lines what omap_rev_string tells us is doing to be board specific as well so provide a weak version in the common omap SPL code and lets it be replaced as needed. Please disregard this version, I need to do a full v3 with the right set of board_early_sdrc_init, sorry for the noise. While I was looking at the series, I've got similar thoughts. May be this should be facilitated by providing kind of framework for the board file only to set the right settings and not duplicate the board_early_sdrc_init() function (with changed values)? The problem is that what to do is very board specific. For example for beagleboard we need to probe the nand driver to see what package we have and then pick from at least 3, maybe 4 or 5 (I don't have the code in front of me) settings. That said, perhaps a function that takes the series of values that do change would be a little clearer in the end so I'll give that a spin once I've gotten beagle and omap3evm spun up again (and maybe finally gotten NAND SPL working there, it seems to be an omap3-specific issue sadly). -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2]: OMAP3 SPL updates
On Tue, Oct 4, 2011 at 7:59 AM, Tom Rini tr...@ti.com wrote: Hey all, The following short series does two things. First, it re-works where we do memory initalization in SPL for OMAP3 to be board-specific. This is needed since in many cases (beagleboard, omap3evm) what timings we set depend on what hardware we detect ourself to be running on. Second, along those same lines what omap_rev_string tells us is doing to be board specific as well so provide a weak version in the common omap SPL code and lets it be replaced as needed. Please disregard this version, I need to do a full v3 with the right set of board_early_sdrc_init, sorry for the noise. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
