On Mon, Jul 31, 2017 at 7:41 AM, Derald D. Woods <[email protected]>
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 <[email protected]>
>
> ---
> 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;
> }
> --
> 2.13.3
>
>
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?
Derald
_______________________________________________
U-Boot mailing list
[email protected]
https://lists.denx.de/listinfo/u-boot