arm: omap: Fix 'get_device_type()' for OMAP34XX
Subsystems (3)
PATCH 1/1 arm: omap: Fix 'get_device_type()' for OMAP34XX
Fixes 00bbe96ebabb (arm: omap: Unify get_device_type() function) where the control status register value is embedded in a structure somewhere in SRAM. This patch allows OMAP3 EVM (TMDSEVM3530) to boot again using a known global constant and offset for 'readl'.
--- arch/arm/mach-omap2/sysinfo-common.c | 4 ++++ 1 file changed, 4 insertions(+)
arch/arm/mach-omap2/sysinfo-common.c +4 -0
@@ -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 ; }
Signature · 1 line
2.13.3
PATCH v2 1/1 arm: omap: Fix 'get_device_type()' for OMAP34XX
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.
---
Changes in v2:
- Added 'signed-off-by'
- Updated description
--- arch/arm/mach-omap2/sysinfo-common.c | 4 ++++ 1 file changed, 4 insertions(+)
arch/arm/mach-omap2/sysinfo-common.c +4 -0
@@ -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 ; }
Signature · 1 line
2.13.3
PATCH v2 1/1 arm: omap: Fix 'get_device_type()' for OMAP34XX
Quoted 35 lines · Derald D. Woods
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(+)arch/arm/mach-omap2/sysinfo-common.c +4
-1@@ -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 ; } --
Quoted 3 lines
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
PATCH v2 1/1 arm: omap: Fix 'get_device_type()' for OMAP34XX
Quoted 36 lines · Derald Woods
Quoted 33 lines · Derald D. Woods
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(+)arch/arm/mach-omap2/sysinfo-common.c +4
-0@@ -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 ;
Quoted 8 lines
arch/arm/mach-omap2/sysinfo-common.c line 25
Quoted 1 line
arch/arm/mach-omap2/sysinfo-common.c +0
-0}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_CTRLlocated 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!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170807/221c168b/attachment.sig>
PATCH v2 1/1 arm: omap: Fix 'get_device_type()' for OMAP34XX
Quoted 48 lines · Tom Rini
Quoted 1 line · Derald Woods
On Mon, Jul 31, 2017 at 7:41 AM, Derald D. Woods <
woods.technical at gmail.com>
Quoted 32 lines
Quoted 30 lines · 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(+)arch/arm/mach-omap2/sysinfo-common.c +2
-0@@ -16,6 +16,10 @@*/ u32 get_device_type (void ) { +#if defined(CONFIG_OMAP34XX ) +return (readl (OMAP34XX_CTRL_BASE +0x2f0 ) &DEVICE_TYPE_MASK )Quoted 12 lines
Quoted 5 lines
arch/arm/mach-omap2/sysinfo-common.c +2
-0+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_CTRLlocated 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?
Quoted 9 lines
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
PATCH v2 1/1 arm: omap: Fix 'get_device_type()' for OMAP34XX
Quoted 58 lines · Derald Woods
Quoted 56 lines · Tom Rini
Quoted 1 line · Derald Woods
On Mon, Jul 31, 2017 at 7:41 AM, Derald D. Woods <
woods.technical at gmail.com>
Quoted 32 lines
Quoted 30 lines · 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(+)arch/arm/mach-omap2/sysinfo-common.c +2
-0@@ -16,6 +16,10 @@*/ u32 get_device_type (void ) { +#if defined(CONFIG_OMAP34XX ) +return (readl (OMAP34XX_CTRL_BASE +0x2f0 ) &DEVICE_TYPE_MASK )Quoted 9 lines
Quoted 5 lines
arch/arm/mach-omap2/sysinfo-common.c +2
-0+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_CTRLlocated
Quoted 1 line
structure as now defined in "
arch/arm/mach-omap2/omap3/hw_data.c".OMAP3
Quoted 2 lines
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!
Quoted 8 lines
Quoted 3 lines
--
TomI 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.
Derald
PATCH v2 1/1 arm: omap: Fix 'get_device_type()' for OMAP34XX
Quoted 95 lines · Derald Woods
Quoted 61 lines · Derald Woods
Quoted 59 lines · Tom Rini
Quoted 1 line · Derald Woods
On Mon, Jul 31, 2017 at 7:41 AM, Derald D. Woods <
woods.technical at gmail.com>
Quoted 5 lines
Quoted 3 lines · wrote:
Fixes 00bbe96ebabb ("arm: omap: Unify get_device_type() function")The control status register value is embedded in a structure
somewhere
Quoted 1 line
Quoted 1 line
in SRAM, with the last refactoring effort. This patch allows OMAP3
EVM
Quoted 14 lines
Quoted 14 lines
(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(+)Quoted 11 lines
arch/arm/mach-omap2/sysinfo-common.c line 20
Quoted 11 lines
arch/arm/mach-omap2/sysinfo-common.c +2
-0@@ -16,6 +16,10 @@*/ u32 get_device_type (void ) { +#if defined(CONFIG_OMAP34XX ) + return (readl(OMAP34XX_CTRL_BASE + 0x2f0) &
DEVICE_TYPE_MASK) >>Quoted 10 lines
Quoted 6 lines
arch/arm/mach-omap2/sysinfo-common.c +2
-0+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_CTRLlocated
Quoted 1 line
structure as now defined in "
arch/arm/mach-omap2/omap3/hw_data.c".OMAP3
Quoted 2 lines
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!
Quoted 8 lines
Quoted 3 lines
--
TomI 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.
Quoted 2 lines
Derald
Based on all of the above, I think the "#if" is still the simplest path to booting.
Derald
PATCH v2 1/1 arm: omap: Fix 'get_device_type()' for OMAP34XX
Quoted 99 lines · Derald Woods
Quoted 96 lines · Derald Woods
Quoted 62 lines · Derald Woods
Quoted 60 lines · Tom Rini
Quoted 1 line · Derald Woods
On Mon, Jul 31, 2017 at 7:41 AM, Derald D. Woods <
woods.technical at gmail.com>
Quoted 5 lines
Quoted 3 lines · wrote:
Fixes 00bbe96ebabb ("arm: omap: Unify get_device_type() function")The control status register value is embedded in a structure
somewhere
Quoted 1 line
Quoted 1 line
in SRAM, with the last refactoring effort. This patch allows OMAP3
EVM
Quoted 1 line
Quoted 1 line
(TMDSEVM3530) to boot again using the known control register base
and
Quoted 13 lines
Quoted 13 lines
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(+)Quoted 11 lines
arch/arm/mach-omap2/sysinfo-common.c line 20
Quoted 11 lines
arch/arm/mach-omap2/sysinfo-common.c +2
-0@@ -16,6 +16,10 @@*/ u32 get_device_type (void ) { +#if defined(CONFIG_OMAP34XX ) + return (readl(OMAP34XX_CTRL_BASE + 0x2f0) &
DEVICE_TYPE_MASK) >>Quoted 10 lines
Quoted 6 lines
arch/arm/mach-omap2/sysinfo-common.c +2
-0+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_CTRLlocated
Quoted 1 line
structure as now defined in "
arch/arm/mach-omap2/omap3/hw_data.c".OMAP3
Quoted 2 lines
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!
Quoted 8 lines
Quoted 3 lines
--
TomI 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.
Quoted 11 lines
Quoted 2 lines
Derald
Based on all of the above, I think the "#if" is still the simplest path to booting.Derald
Are there any further thoughts about OMAP34XX calling 'get_device_type()' from "start.S"?
Derald
PATCH v2 1/1 arm: omap: Fix 'get_device_type()' for OMAP34XX
In reply to Derald WoodsQuoted 83 lines · Derald Woods
Quoted 58 lines · Derald Woods
Quoted 56 lines · Tom Rini
Quoted 1 line · Derald Woods
On Mon, Jul 31, 2017 at 7:41 AM, Derald D. Woods <
woods.technical at gmail.com>
Quoted 32 lines
Quoted 30 lines · 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(+)arch/arm/mach-omap2/sysinfo-common.c +2
-0@@ -16,6 +16,10 @@*/ u32 get_device_type (void ) { +#if defined(CONFIG_OMAP34XX ) +return (readl (OMAP34XX_CTRL_BASE +0x2f0 ) &DEVICE_TYPE_MASK )Quoted 9 lines
Quoted 5 lines
arch/arm/mach-omap2/sysinfo-common.c +2
-0+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_CTRLlocated
Quoted 1 line
structure as now defined in "
arch/arm/mach-omap2/omap3/hw_data.c".OMAP3
Quoted 2 lines
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!
Quoted 8 lines
Quoted 3 lines
--
TomI 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')
Quoted 8 lines
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!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170812/df32cf9c/attachment.sig>
PATCH v2 1/1 arm: omap: Fix 'get_device_type()' for OMAP34XX
In reply to Derald D. WoodsQuoted 8 lines · Derald D. Woods
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]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170812/559a7580/attachment.sig>