On Thu, Aug 10, 2017 at 07:25:29AM -0500, Derald Woods wrote: > On Mon, Aug 7, 2017 at 5:19 PM, Derald Woods <woods.techni...@gmail.com> > wrote: > > > On Mon, Aug 7, 2017 at 7:41 AM, Tom Rini <tr...@konsulko.com> wrote: > > > >> On Mon, Aug 07, 2017 at 07:35:30AM -0500, Derald Woods wrote: > >> > On Mon, Jul 31, 2017 at 7:41 AM, Derald D. Woods < > >> woods.techni...@gmail.com> > >> > wrote: > >> > > >> > > Fixes: 00bbe96ebabb ("arm: omap: Unify get_device_type() function") > >> > > > >> > > The control status register value is embedded in a structure somewhere > >> > > in SRAM, with the last refactoring effort. This patch allows OMAP3 EVM > >> > > (TMDSEVM3530) to boot again using the known control register base and > >> > > offset for 'readl', for the OMAP34XX case. > >> > > > >> > > Signed-off-by: Derald D. Woods <woods.techni...@gmail.com> > >> > > > >> > > --- > >> > > Changes in v2: > >> > > - Added 'signed-off-by' > >> > > - Updated description > >> > > > >> > > --- > >> > > arch/arm/mach-omap2/sysinfo-common.c | 4 ++++ > >> > > 1 file changed, 4 insertions(+) > >> > > > >> > > diff --git a/arch/arm/mach-omap2/sysinfo-common.c > >> > > b/arch/arm/mach-omap2/sysinfo-common.c > >> > > index 1dc7051ab3..3955e803ad 100644 > >> > > --- a/arch/arm/mach-omap2/sysinfo-common.c > >> > > +++ b/arch/arm/mach-omap2/sysinfo-common.c > >> > > @@ -16,6 +16,10 @@ > >> > > */ > >> > > u32 get_device_type(void) > >> > > { > >> > > +#if defined(CONFIG_OMAP34XX) > >> > > + return (readl(OMAP34XX_CTRL_BASE + 0x2f0) & DEVICE_TYPE_MASK) > >> >> > >> > > + DEVICE_TYPE_SHIFT; > >> > > +#endif > >> > > return (readl((*ctrl)->control_status) & DEVICE_TYPE_MASK) >> > >> > > DEVICE_TYPE_SHIFT; > >> > > } > >> > > >> > Is there any comment or concern with this patch? It was the simplest > >> > means to get OMAP35XX booting again and still keep the original patch. > >> > Basically it avoids the pointer to the OMAP_SRAM_SCRATCH_SYS_CTRL > >> located > >> > structure as now defined in "arch/arm/mach-omap2/omap3/hw_data.c". > >> OMAP3 > >> > has a larger active SOC base than just OMAP36XX and greater. Was there > >> > anything really broken with 'get_device_type()' previously? > >> > >> Is the pointer value wrong for 35xx? The problem, such as it was, was > >> having the same function duplicated in a number of places, and needing > >> to make it more easily / readily available (rather than duplicated > >> again) for some additional patches. I'd really rather not introduce > >> an #if here unless we really have no other choice. Thanks! > >> > >> -- > >> Tom > >> > > > > I will examine/debug the new 'get_device_type()' source code again > > tonight. Without the patch, I have two OMAP3530 boards that do not boot at > > all. > > > > > Derald > > > In "arch/arm/mach-omap2/omap3/board.c", the following routines call > 'get_device_type': > - v7_arch_cp15_set_l2aux_ctrl (called from > "arch/arm/cpu/armv7/start.S") > - v7_arch_cp15_set_acr (called from > "arch/arm/cpu/armv7/start.S") > - omap3_invalidate_l2_cache_secure (called from "board.c" 's_init') > - try_unlock_memory (called from "board.c" 's_init') > > Each one of these calls to 'get_device_type' seems to have a purpose (i.e. > ERRATA or setup). What it highlights is the difference in usage from > OMAP36XX, AM33XX, and newer. The SRAM usage, L2 cache and call ordering are > likely factors here. Figuring out the implications for OMAP34XX will take > time. But you need to have boards that boot to address those issues. So > 'get_device_type' usage, for OMAP34XX, is not strictly a "Apples to Apples" > type comparison. For now I can proceed with an "out-of-tree" patch, since > it is small. Let me know if there is something that I am missing here.
OK, thanks for the analysis. It is indeed a bit too much overhead atm to see if we can further reconcile all of the code and should grab your patch, thanks! -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot