AM335x: Beaglebone stops to boot with current git kernel
Subsystems (5)
Hello,
Beaglebone boot process is broken with the current git kernel. I use omap2plus_defconfig for tests.
It looks like the boot process stops due to the last changes in the AM33xx clock sysbsystem. A following patch resolves this issue:
arch/arm/mach-omap2/omap_hwmod_33xx_data.c +1 -1
@@ -586,7 +586,7 @@ static struct omap_hwmod am33xx_smartreflex0_hwmod = { .class = &am33xx_smartreflex_hwmod_class, .clkdm_name = "l4_wkup_clkdm", .mpu_irqs = am33xx_smartreflex0_irqs, - .main_clk = "smartreflex0_fck", + .main_clk = "smartreflex_mpu_fck", .prcm = { .omap4 = { .clkctrl_offs =
AM33XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET,
@@ -606,7 +606,7 @@ static struct omap_hwmod am33xx_smartreflex1_hwmod = {
.class = &am33xx_smartreflex_hwmod_class,
.clkdm_name = "l4_wkup_clkdm",
.mpu_irqs = am33xx_smartreflex1_irqs,
- .main_clk = "smartreflex1_fck",
+ .main_clk = "smartreflex_core_fck",
.prcm = {
.omap4 = { .clkctrl_offs =AM33XX_CM_WKUP_SMARTREFLEX1_CLKCTRL_OFFSET,
Regards,
Igor.
Hi,
Quoted 32 lines · Igor Mazanov
Hello,
Beaglebone boot process is broken with the current git kernel. I use
omap2plus_defconfigfor tests.It looks like the boot process stops due to the last changes in the AM33xx clock sysbsystem. A following patch resolves this issue:
arch/arm/mach-omap2/omap_hwmod_33xx_data.c +1
-1@@ -586,7 +586,7 @@ static struct omap_hwmod am33xx_smartreflex0_hwmod = { .class = &am33xx_smartreflex_hwmod_class, .clkdm_name = "l4_wkup_clkdm", .mpu_irqs = am33xx_smartreflex0_irqs, - .main_clk = "smartreflex0_fck", + .main_clk = "smartreflex_mpu_fck", .prcm = { .omap4 = { .clkctrl_offs =
AM33XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET,arch/arm/mach-omap2/omap_hwmod_33xx_data.c +1
-1@@ -606,7 +606,7 @@ static struct omap_hwmod am33xx_smartreflex1_hwmod = { .class = &am33xx_smartreflex_hwmod_class, .clkdm_name = "l4_wkup_clkdm", .mpu_irqs = am33xx_smartreflex1_irqs, - .main_clk = "smartreflex1_fck", + .main_clk = "smartreflex_core_fck", .prcm = { .omap4 = { .clkctrl_offs =
Quoted 2 lines
AM33XX_CM_WKUP_SMARTREFLEX1_CLKCTRL_OFFSET,
About the name field in the hwmod entry: the SR code checks on the value of "smartreflex_mpu_iva" to differentiate the SR IP blocks and to apply the correct parameters to each of them. Cf. the function sr_set_regfields in drivers/power/avs/smartreflex.c.
The patch should change the name of the hwmod entry as well, can you fold this change in the current patch?
Note: I know the name "smartreflex_mpu_iva" is not perfect since it does not apply to all OMAP3 variants, maybe we could change the SR code to be more generic.
Nishant, what do you think?
Regards,
Jean
Quoted 8 lines
Regards,
Igor.--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 43 lines · Jean Pihet
Hi,
Quoted 32 lines · Igor Mazanov
Hello,
Beaglebone boot process is broken with the current git kernel. I use
omap2plus_defconfigfor tests.It looks like the boot process stops due to the last changes in the AM33xx clock sysbsystem. A following patch resolves this issue:
arch/arm/mach-omap2/omap_hwmod_33xx_data.c +1
-1@@ -586,7 +586,7 @@ static struct omap_hwmod am33xx_smartreflex0_hwmod = { .class = &am33xx_smartreflex_hwmod_class, .clkdm_name = "l4_wkup_clkdm", .mpu_irqs = am33xx_smartreflex0_irqs, - .main_clk = "smartreflex0_fck", + .main_clk = "smartreflex_mpu_fck", .prcm = { .omap4 = { .clkctrl_offs =
AM33XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET,arch/arm/mach-omap2/omap_hwmod_33xx_data.c +1
-1@@ -606,7 +606,7 @@ static struct omap_hwmod am33xx_smartreflex1_hwmod = { .class = &am33xx_smartreflex_hwmod_class, .clkdm_name = "l4_wkup_clkdm", .mpu_irqs = am33xx_smartreflex1_irqs, - .main_clk = "smartreflex1_fck", + .main_clk = "smartreflex_core_fck", .prcm = { .omap4 = { .clkctrl_offs =Quoted 2 lines
AM33XX_CM_WKUP_SMARTREFLEX1_CLKCTRL_OFFSET,About the name field in the hwmod entry: the SR code checks on the value of "
smartreflex_mpu_iva" to differentiate the SR IP blocks and to apply the correct parameters to each of them. Cf. the functionsr_set_regfieldsindrivers/power/avs/smartreflex.c.
Quoted 9 lines
The patch should change the name of the hwmod entry as well, can you fold this change in the current patch?
Note: I know the name "
smartreflex_mpu_iva" is not perfect since it does not apply to all OMAP3 variants, maybe we could change the SR code to be more generic.Nishant, what do you think?
Might be an better idea to remove the entire function sr_set_regfields instead provide the err_weight, max_limit, accum_data, avgweights to platform_data. --
Regards,
Nishanth Menon
Tony Lindgren
maintainerQuoted 3 lines · Jean Pihet
The patch should change the name of the hwmod entry as well, can you fold this change in the current patch?
This was caused by the merge of omap-for-v3.8/pm into omap-for-v3.8/clock. I noticed a smilar issue for omap3, but missed at least this one.
Jean, can you please check omap-for-v3.8/clock for the smartreflex clock names in case there are more issues like this remaining?
Regards,
Tony
Hi Tony,
Quoted 10 lines · Tony Lindgren
Quoted 3 lines · Jean Pihet
The patch should change the name of the hwmod entry as well, can you fold this change in the current patch?
This was caused by the merge of omap-for-v3.8/pm into omap-for-v3.8/clock. I noticed a smilar issue for omap3, but missed at least this one.
Jean, can you please check omap-for-v3.8/clock for the smartreflex clock names in case there are more issues like this remaining?
The hwmod clock names are OK for 3xxx, 36xx, 33xx and 44xx. The hwmod names are OK excepted for 33xx where they respectively should be "smartreflex_mpu_iva" and ""smartreflex_core".
This issue is caused by 99e7938d "ARM: OMAP3: clock: Add 3xxx data using common struct clk" in omap-for-v3.8/clock.
Quoted 3 lines
Regards,
Tony
Regards,
Jean
Tony Lindgren
maintainerQuoted 11 lines · Jean Pihet
Hi Tony,
Quoted 8 lines · Tony Lindgren
Quoted 3 lines · Jean Pihet
The patch should change the name of the hwmod entry as well, can you fold this change in the current patch?
This was caused by the merge of omap-for-v3.8/pm into omap-for-v3.8/clock. I noticed a smilar issue for omap3, but missed at least this one.
Quoted 8 lines
Quoted 2 lines
Jean, can you please check omap-for-v3.8/clock for the smartreflex clock names in case there are more issues like this remaining?
The hwmod clock names are OK for 3xxx, 36xx, 33xx and 44xx. The hwmod names are OK excepted for 33xx where they respectively should be "
smartreflex_mpu_iva" and ""smartreflex_core".This issue is caused by
99e7938d"ARM: OMAP3: clock: Add 3xxx data using common struct clk" in omap-for-v3.8/clock.
OK thanks for checking.
Regards,
Tony
Tony Lindgren
maintainerQuoted 7 lines · Jean Pihet
Quoted 6 lines · Igor Mazanov
Beaglebone boot process is broken with the current git kernel. I use
omap2plus_defconfigfor tests.It looks like the boot process stops due to the last changes in the AM33xx clock sysbsystem. A following patch resolves this issue:
...
Quoted 2 lines
The patch should change the name of the hwmod entry as well, can you fold this change in the current patch?
Any news on updating this?
Regards,
Tony
Quoted 6 lines · Tony Lindgren
Quoted 5 lines · Jean Pihet
Quoted 4 lines · Igor Mazanov
Beaglebone boot process is broken with the current git kernel. I use
omap2plus_defconfigfor tests.
Quoted 8 lines
Quoted 2 lines
Quoted 2 lines
It looks like the boot process stops due to the last changes in the AM33xx clock sysbsystem. A following patch resolves this issue:
...
Quoted 2 lines
The patch should change the name of the hwmod entry as well, can you fold this change in the current patch?
Any news on updating this?
The current kernel boots, but after a switching to CCF doesn't work the debugss - it's just disabled in the current hwmod code. So, it looks like we can't use JTAG to connect to the running kernel.
Regards,
Igor.
Quoted 3 lines
Regards,
Tony
Quoted 11 lines · Igor Mazanov
Quoted 10 lines · Tony Lindgren
Quoted 7 lines · Jean Pihet
Quoted 6 lines · Igor Mazanov
Beaglebone boot process is broken with the current git kernel. I use
omap2plus_defconfigfor tests.It looks like the boot process stops due to the last changes in the AM33xx clock sysbsystem. A following patch resolves this issue:
...
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
The patch should change the name of the hwmod entry as well, can you fold this change in the current patch?
Any news on updating this?
The current kernel boots, but after a switching to CCF doesn't work the debugss - it's just disabled in the current hwmod code. So, it looks like we can't use JTAG to connect to the running kernel.
just resumed from vacation...
JTAG clock will get disabled because, CONFIG_OMAP_RESET_CLOCKS will disable unused clocks, so as debugss clock.
There is another thread started by Joel on the similar issue,
http://www.mail-archive.com/[email protected]/msg80863.html
Something below should be done for debugss on AM33xx,
(quoted diff) +0 -0
b/arch/arm/mach-omap2/clock33xx_data.c
index 17e3de5..60e0b53 100644
arch/arm/mach-omap2/clock33xx_data.c +3 -0
@@ -584,6 +584,9 @@ static struct clk debugss_ick = { .clkdm_name = "l3_aon_clkdm", .parent = &dpll_core_m4_ck, .ops = &clkops_omap2_dflt, +#ifdef CONFIG_DEBUG_KERNEL + .flags = ENABLE_ON_INIT, +#endif .enable_reg =AM33XX_CM_WKUP_DEBUGSS_CLKCTRL , .enable_bit = AM33XX_MODULEMODE_SWCTRL, .recalc = &followparent_recalc,
Thanks,
Vaibhav
Quoted 11 lines
Regards,
Igor.Quoted 3 lines
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 41 lines · Vaibhav Hiremath
Quoted 11 lines · Igor Mazanov
Quoted 10 lines · Tony Lindgren
Quoted 7 lines · Jean Pihet
Quoted 6 lines · Igor Mazanov
Beaglebone boot process is broken with the current git kernel. I use
omap2plus_defconfigfor tests.It looks like the boot process stops due to the last changes in the AM33xx clock sysbsystem. A following patch resolves this issue:
...
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
The patch should change the name of the hwmod entry as well, can you fold this change in the current patch?
Any news on updating this?
The current kernel boots, but after a switching to CCF doesn't work the debugss - it's just disabled in the current hwmod code. So, it looks like we can't use JTAG to connect to the running kernel.
just resumed from vacation...
JTAG clock will get disabled because,
CONFIG_OMAP_RESET_CLOCKSwill disable unused clocks, so as debugss clock.There is another thread started by Joel on the similar issue,
http://www.mail-archive.com/[email protected]/msg80863.html
Something below should be done for debugss on AM33xx,
arch/arm/mach-omap2/clock33xx_data.c +0
-0
arch/arm/mach-omap2/clock33xx_data.c static struct clk debugss_ick = { · line 592
Quoted 9 lines
arch/arm/mach-omap2/clock33xx_data.c +3
-0@@ -584,6 +584,9 @@ static struct clk debugss_ick = { .clkdm_name = "l3_aon_clkdm", .parent = &dpll_core_m4_ck, .ops = &clkops_omap2_dflt, +#ifdef CONFIG_DEBUG_KERNEL + .flags = ENABLE_ON_INIT, +#endif .enable_reg =AM33XX_CM_WKUP_DEBUGSS_CLKCTRL , .enable_bit = AM33XX_MODULEMODE_SWCTRL, .recalc = &followparent_recalc,
Yes, I noticed this thread. But now a clock subsystem in the current kernel is switched to Common Clock Framework and debugss (and several another modules) is disabled (#if 0 .... #endif) in omap_hwmod_33xx_data.c.
Quoted 1 line
From
omap_hwmod_33xx_data.c:
/*
* Modules omap_hwmod structures
*
* The following IPs are excluded for the moment because:
* - They do not need an explicit SW control using omap_hwmod API.
* - They still need to be validated with the driver
* properly adapted to omap_hwmod / omap_device
*
* - cEFUSE (doesn't fall under any ocp_if) * - clkdiv32k * - debugss * - ocmc ram * - ocp watch point * - aes0 * - sha0
*/
I uncommented the debugss entry in the omap_hwmod settings, but only got a warning like:
CC arch/arm/mach-omap2/omap_hwmod_33xx_data.oarch/arm/mach-omap2/omap_hwmod_33xx_data.c:472:26: warning:
'am33xx_debugss_hwmod' defined but not used [-Wunused-variable]
By the way, I need to use JTAG to trace a problem described in this thread:
http://marc.info/?l=linux-omap&m=135307646415429&w=2
May be, it's the clocks related issue too...
Quoted 14 lines
Thanks,
VaibhavQuoted 11 lines
Regards,
Igor.Quoted 3 lines
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 203 lines · Vaibhav
Quoted 47 lines · Igor Mazanov
Quoted 46 lines · Vaibhav Hiremath
Quoted 11 lines · Igor Mazanov
Quoted 10 lines · Tony Lindgren
Quoted 7 lines · Jean Pihet
Quoted 6 lines · Igor Mazanov
Beaglebone boot process is broken with the current git kernel. I use
omap2plus_defconfigfor tests.It looks like the boot process stops due to the last changes in the AM33xx clock sysbsystem. A following patch resolves this issue:
...
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
The patch should change the name of the hwmod entry as well, can you fold this change in the current patch?
Any news on updating this?
The current kernel boots, but after a switching to CCF doesn't work the debugss - it's just disabled in the current hwmod code. So, it looks like we can't use JTAG to connect to the running kernel.
just resumed from vacation...
JTAG clock will get disabled because,
CONFIG_OMAP_RESET_CLOCKSwill disable unused clocks, so as debugss clock.There is another thread started by Joel on the similar issue,
http://www.mail-archive.com/[email protected]/msg80863.html
Something below should be done for debugss on AM33xx,
arch/arm/mach-omap2/clock33xx_data.c +2
-0@@ -584,6 +584,9 @@ static struct clk debugss_ick = { .clkdm_name = "l3_aon_clkdm", .parent = &dpll_core_m4_ck, .ops = &clkops_omap2_dflt, +#ifdef CONFIG_DEBUG_KERNEL + .flags = ENABLE_ON_INIT,Quoted 8 lines
arch/arm/mach-omap2/clock33xx_data.c static struct clk debugss_ick = { · line 592
Quoted 4 lines
arch/arm/mach-omap2/clock33xx_data.c +1
-0+#endif .enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL, .enable_bit = AM33XX_MODULEMODE_SWCTRL, .recalc = &followparent_recalc,Yes, I noticed this thread. But now a clock subsystem in the current kernel is switched to Common Clock Framework and debugss (and several another modules) is disabled
Still this can be handled and enabled during init.
Quoted 29 lines
(#if 0 .... #endif) in
omap_hwmod_33xx_data.c.From
omap_hwmod_33xx_data.c:/*
* Modulesomap_hwmodstructures
*
* The following IPs are excluded for the moment because:
* - They do not need an explicit SW control usingomap_hwmodAPI.
* - They still need to be validated with the driver
* properly adapted toomap_hwmod/omap_device
** - cEFUSE (doesn't fall under any ocp_if) * - clkdiv32k * - debugss * - ocmc ram * - ocp watch point * - aes0 * - sha0*/
I uncommented the debugss entry in the
omap_hwmodsettings, but only got a warning like:CC
arch/arm/mach-omap2/omap_hwmod_33xx_data.oarch/arm/mach-omap2/omap_hwmod_33xx_data.c:472:26: warning:
'am33xx_debugss_hwmod' defined but not used [-Wunused-variable]Quoted 6 lines
By the way, I need to use JTAG to trace a problem described in this thread:
http://marc.info/?l=linux-omap&m=135307646415429&w=2
May be, it's the clocks related issue too...
I have quickly created patch for you, can you try below patch and let me know?
arch/arm/mach-omap2/cclock33xx_data.c +1
-0@@ -920,6 +920,7 @@ static const char *enable_init_clks[] = {"l4hs_gclk" ,"l4fw_gclk" ,"l4ls_gclk" , + "debugss_ick", };int __init am33xx_clk_init (void )arch/arm/mach-omap2/omap_hwmod_33xx_data.c +40
-21@@ -460,27 +460,6 @@ static struct omap_hwmod am33xx_clkdiv32k_hwmod = { }, }; -/* -* 'debugss' class -* debug sub system -*/ -static struct omap_hwmod_class am33xx_debugss_hwmod_class = { - .name ="debugss" , -}; - -static struct omap_hwmod am33xx_debugss_hwmod = { - .name ="debugss" , - .class = &am33xx_debugss_hwmod_class, - .clkdm_name ="l3_aon_clkdm" , - .main_clk ="debugss_ick" , - .prcm = { - .omap4 = { - .clkctrl_offs =AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET , - .modulemode =MODULEMODE_SWCTRL , - }, - }, -}; -/* ocmcram */ static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = { .name ="ocmcram" ,@@ -570,6 +549,28 @@ static struct omap_hwmod am33xx_sha0_hwmod = {#endif +/* +* 'debugss' class +* debug sub system +*/ +static struct omap_hwmod_class am33xx_debugss_hwmod_class = { + .name ="debugss" , +}; + +static struct omap_hwmod am33xx_debugss_hwmod = { + .name ="debugss" , + .class = &am33xx_debugss_hwmod_class, + .clkdm_name ="l3_aon_clkdm" , + .main_clk ="debugss_ick" , + .flags = (HWMOD_INIT_NO_IDLE |HWMOD_INIT_NO_RESET ), + .prcm = { + .omap4 = { + .clkctrl_offs =AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET , + .modulemode =MODULEMODE_SWCTRL , + }, + }, +}; +/* 'smartreflex' class */ static struct omap_hwmod_class am33xx_smartreflex_hwmod_class = { .name ="smartreflex" ,@@ -2261,6 +2262,24 @@ static struct omap_hwmod_ocp_if am33xx_l3_main__gfx = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +/* l3_main -> debugss */ +static struct omap_hwmod_addr_space am33xx_debugss_addrs[] = { + { + .pa_start =0x4b000000 , + .pa_end =0x4b000000 +SZ_16M -1 , + .flags =ADDR_TYPE_RT + }, + { } +}; + +static struct omap_hwmod_ocp_if am33xx_l3_main__debugss = { + .master = &am33xx_l3_main_hwmod, + .slave = &am33xx_debugss_hwmod, + .clk ="debugss_ick" , + .addr = am33xx_debugss_addrs, + .user =OCP_USER_MPU , +}; +/* l4 wkup -> smartreflex0 */ static struct omap_hwmod_addr_space am33xx_smartreflex0_addrs[] = { {
arch/arm/mach-omap2/omap_hwmod_33xx_data.c static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = { · line 3340
Quoted 7 lines
arch/arm/mach-omap2/omap_hwmod_33xx_data.c +1
-0@@ -3315,6 +3334,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = { &am33xx_pruss__l3_main, &am33xx_wkup_m3__l4_wkup, &am33xx_gfx__l3_main, + &am33xx_l3_main__debugss, &am33xx_l4_wkup__wkup_m3, &am33xx_l4_wkup__control, &am33xx_l4_wkup__smartreflex0,
Missed to mention that,
I have boot tested it on Bone platform and made sure that debugs module stays enabled after boot (after applying this patch).
Thanks,
Vaibhav
Quoted 216 lines · Vaibhav
Quoted 203 lines · Vaibhav
Quoted 47 lines · Igor Mazanov
Quoted 46 lines · Vaibhav Hiremath
Quoted 11 lines · Igor Mazanov
Quoted 10 lines · Tony Lindgren
Quoted 7 lines · Jean Pihet
Quoted 6 lines · Igor Mazanov
Beaglebone boot process is broken with the current git kernel. I use
omap2plus_defconfigfor tests.It looks like the boot process stops due to the last changes in the AM33xx clock sysbsystem. A following patch resolves this issue:
...
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
The patch should change the name of the hwmod entry as well, can you fold this change in the current patch?
Any news on updating this?
The current kernel boots, but after a switching to CCF doesn't work the debugss - it's just disabled in the current hwmod code. So, it looks like we can't use JTAG to connect to the running kernel.
just resumed from vacation...
JTAG clock will get disabled because,
CONFIG_OMAP_RESET_CLOCKSwill disable unused clocks, so as debugss clock.There is another thread started by Joel on the similar issue,
http://www.mail-archive.com/[email protected]/msg80863.html
Something below should be done for debugss on AM33xx,
arch/arm/mach-omap2/clock33xx_data.c +2
-0@@ -584,6 +584,9 @@ static struct clk debugss_ick = { .clkdm_name = "l3_aon_clkdm", .parent = &dpll_core_m4_ck, .ops = &clkops_omap2_dflt, +#ifdef CONFIG_DEBUG_KERNEL + .flags = ENABLE_ON_INIT,Quoted 8 lines
arch/arm/mach-omap2/clock33xx_data.c static struct clk debugss_ick = { · line 592
Quoted 4 lines
arch/arm/mach-omap2/clock33xx_data.c +1
-0+#endif .enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL, .enable_bit = AM33XX_MODULEMODE_SWCTRL, .recalc = &followparent_recalc,Yes, I noticed this thread. But now a clock subsystem in the current kernel is switched to Common Clock Framework and debugss (and several another modules) is disabled
Still this can be handled and enabled during init.
Quoted 29 lines
(#if 0 .... #endif) in
omap_hwmod_33xx_data.c.From
omap_hwmod_33xx_data.c:/*
* Modulesomap_hwmodstructures
*
* The following IPs are excluded for the moment because:
* - They do not need an explicit SW control usingomap_hwmodAPI.
* - They still need to be validated with the driver
* properly adapted toomap_hwmod/omap_device
** - cEFUSE (doesn't fall under any ocp_if) * - clkdiv32k * - debugss * - ocmc ram * - ocp watch point * - aes0 * - sha0*/
I uncommented the debugss entry in the
omap_hwmodsettings, but only got a warning like:CC
arch/arm/mach-omap2/omap_hwmod_33xx_data.oarch/arm/mach-omap2/omap_hwmod_33xx_data.c:472:26: warning:
'am33xx_debugss_hwmod' defined but not used [-Wunused-variable]Quoted 6 lines
By the way, I need to use JTAG to trace a problem described in this thread:
http://marc.info/?l=linux-omap&m=135307646415429&w=2
May be, it's the clocks related issue too...
I have quickly created patch for you, can you try below patch and let me know?
arch/arm/mach-omap2/cclock33xx_data.c +1
-0@@ -920,6 +920,7 @@ static const char *enable_init_clks[] = {"l4hs_gclk" ,"l4fw_gclk" ,"l4ls_gclk" , + "debugss_ick", };int __init am33xx_clk_init (void )arch/arm/mach-omap2/omap_hwmod_33xx_data.c +40
-21@@ -460,27 +460,6 @@ static struct omap_hwmod am33xx_clkdiv32k_hwmod = { }, }; -/* -* 'debugss' class -* debug sub system -*/ -static struct omap_hwmod_class am33xx_debugss_hwmod_class = { - .name ="debugss" , -}; - -static struct omap_hwmod am33xx_debugss_hwmod = { - .name ="debugss" , - .class = &am33xx_debugss_hwmod_class, - .clkdm_name ="l3_aon_clkdm" , - .main_clk ="debugss_ick" , - .prcm = { - .omap4 = { - .clkctrl_offs =AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET , - .modulemode =MODULEMODE_SWCTRL , - }, - }, -}; -/* ocmcram */ static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = { .name ="ocmcram" ,@@ -570,6 +549,28 @@ static struct omap_hwmod am33xx_sha0_hwmod = {#endif +/* +* 'debugss' class +* debug sub system +*/ +static struct omap_hwmod_class am33xx_debugss_hwmod_class = { + .name ="debugss" , +}; + +static struct omap_hwmod am33xx_debugss_hwmod = { + .name ="debugss" , + .class = &am33xx_debugss_hwmod_class, + .clkdm_name ="l3_aon_clkdm" , + .main_clk ="debugss_ick" , + .flags = (HWMOD_INIT_NO_IDLE |HWMOD_INIT_NO_RESET ), + .prcm = { + .omap4 = { + .clkctrl_offs =AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET , + .modulemode =MODULEMODE_SWCTRL , + }, + }, +}; +/* 'smartreflex' class */ static struct omap_hwmod_class am33xx_smartreflex_hwmod_class = { .name ="smartreflex" ,@@ -2261,6 +2262,24 @@ static struct omap_hwmod_ocp_if am33xx_l3_main__gfx = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +/* l3_main -> debugss */ +static struct omap_hwmod_addr_space am33xx_debugss_addrs[] = { + { + .pa_start =0x4b000000 , + .pa_end =0x4b000000 +SZ_16M -1 , + .flags =ADDR_TYPE_RT + }, + { } +}; + +static struct omap_hwmod_ocp_if am33xx_l3_main__debugss = { + .master = &am33xx_l3_main_hwmod, + .slave = &am33xx_debugss_hwmod, + .clk ="debugss_ick" , + .addr = am33xx_debugss_addrs, + .user =OCP_USER_MPU , +}; +/* l4 wkup -> smartreflex0 */ static struct omap_hwmod_addr_space am33xx_smartreflex0_addrs[] = { {arch/arm/mach-omap2/omap_hwmod_33xx_data.c static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = { · line 3340
Quoted 7 lines
arch/arm/mach-omap2/omap_hwmod_33xx_data.c +1
-0@@ -3315,6 +3334,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = { &am33xx_pruss__l3_main, &am33xx_wkup_m3__l4_wkup, &am33xx_gfx__l3_main, + &am33xx_l3_main__debugss, &am33xx_l4_wkup__wkup_m3, &am33xx_l4_wkup__control, &am33xx_l4_wkup__smartreflex0,Missed to mention that,
Quoted 3 lines
I have boot tested it on Bone platform and made sure that debugs module stays enabled after boot (after applying this patch).
I applied your patch and it works for me too. JTAG interface is working now. Thanks!
Regards,
Igor.
Quoted 2 lines
Thanks,
Vaibhav
Hi Vaibhav, Igor,
On and off due to vacation time too,..
Not sure but I missed the below patch from Vaibhav as it probably wasn't copied to linux-omap so I got confused which patch was Igor testing, whether it was the one in which we set ENABLE_ON_INIT or the one in which hwmod data is changed.
I think Igor tried the latter and it works. In that case, I guess we can drop the ENABLE_ON_INIT patch if this is a better fix. I had some comments though...
Quoted 1 line · Igor Mazanov
On Thu, Nov 22, 2012 at 6:49 PM, Hiremath, Vaibhav <[email protected]> wrote:
[..]
Quoted 53 lines
Quoted 53 lines
Quoted 53 lines
I have quickly created patch for you, can you try below patch and let me know?
arch/arm/mach-omap2/cclock33xx_data.c +1
-0@@ -920,6 +920,7 @@ static const char *enable_init_clks[] = {"l4hs_gclk" ,"l4fw_gclk" ,"l4ls_gclk" , + "debugss_ick", };int __init am33xx_clk_init (void )arch/arm/mach-omap2/omap_hwmod_33xx_data.c +0
-21@@ -460,27 +460,6 @@ static struct omap_hwmod am33xx_clkdiv32k_hwmod = { }, }; -/* -* 'debugss' class -* debug sub system -*/ -static struct omap_hwmod_class am33xx_debugss_hwmod_class = { - .name ="debugss" , -}; - -static struct omap_hwmod am33xx_debugss_hwmod = { - .name ="debugss" , - .class = &am33xx_debugss_hwmod_class, - .clkdm_name ="l3_aon_clkdm" , - .main_clk ="debugss_ick" , - .prcm = { - .omap4 = { - .clkctrl_offs =AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET , - .modulemode =MODULEMODE_SWCTRL , - }, - }, -}; -/* ocmcram */ static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = { .name ="ocmcram" ,@@ -570,6 +549,28 @@ static struct omap_hwmod am33xx_sha0_hwmod = {#endif
Quoted 14 lines
Quoted 6 lines
Quoted 6 lines
arch/arm/mach-omap2/omap_hwmod_33xx_data.c +6
-0+/* +* 'debugss' class +* debug sub system +*/ +static struct omap_hwmod_class am33xx_debugss_hwmod_class = { + .name ="debugss" ,Quoted 8 lines
arch/arm/mach-omap2/omap_hwmod_33xx_data.c static struct omap_hwmod am33xx_sha0_hwmod = { · line 565
Quoted 8 lines
arch/arm/mach-omap2/omap_hwmod_33xx_data.c +8
-0+}; + +static struct omap_hwmod am33xx_debugss_hwmod = { + .name ="debugss" , + .class = &am33xx_debugss_hwmod_class, + .clkdm_name ="l3_aon_clkdm" , + .main_clk ="debugss_ick" , + .flags = (HWMOD_INIT_NO_IDLE |HWMOD_INIT_NO_RESET ),
Setting these flags would still leave the problem where JTAG clocks are on when its not required no? In that case, what is the advantage of this patch?
Regards,
Joel
Quoted 4 lines · Joel A Fernandes
Hi Vaibhav, Igor,
On and off due to vacation time too,..
Quoted 9 lines
Not sure but I missed the below patch from Vaibhav as it probably wasn't copied to linux-omap so I got confused which patch was Igor testing, whether it was the one in which we set
ENABLE_ON_INITor the one in which hwmod data is changed.I think Igor tried the latter and it works. In that case, I guess we can drop the
ENABLE_ON_INITpatch if this is a better fix. I had some comments though...
Let try to explain why we should go with hwmod patches,
When I submitted clock tree patch, we decided to remove all leaf-nodes from the data, but since modules like debugs were not enabled in hwmod (as done for omap) I had explicitly keep these nodes in clock-tree to disable them with RESET_CLOCKS flag.
Please refer to the comment in file clock33xx_data.c
567 /*
568 * Modules clock nodes 569 * 570 * The following clock leaf nodes are added for the moment because: 571 * 572 * - hwmod data is not present for these modules, either hwmod 573 * control is not required or its not populated. 574 * - Driver code is not yet migrated to use hwmod/runtime pm 575 * - Modules outside kernel access (to disable them by default) 576 * 577 * - debugss 578 * - mmu (gfx domain) 579 * - cefuse 580 * - usbotg_fck (its additional clock and not really a modulemode) 581 * - ieee5000 582 */
Ideally (and to keep consistency with existing implementation), we should enable hwmod node and remove clock-tree node.
Quoted 66 lines · Igor Mazanov
Quoted 1 line · Vaibhav
[..]
Quoted 63 lines
Quoted 63 lines
Quoted 63 lines
I have quickly created patch for you, can you try below patch and let me know?
arch/arm/mach-omap2/cclock33xx_data.c +1
-0@@ -920,6 +920,7 @@ static const char *enable_init_clks[] = {"l4hs_gclk" ,"l4fw_gclk" ,"l4ls_gclk" , + "debugss_ick", };int __init am33xx_clk_init (void )arch/arm/mach-omap2/omap_hwmod_33xx_data.c +10
-21@@ -460,27 +460,6 @@ static struct omap_hwmod am33xx_clkdiv32k_hwmod = { }, }; -/* -* 'debugss' class -* debug sub system -*/ -static struct omap_hwmod_class am33xx_debugss_hwmod_class = { - .name ="debugss" , -}; - -static struct omap_hwmod am33xx_debugss_hwmod = { - .name ="debugss" , - .class = &am33xx_debugss_hwmod_class, - .clkdm_name ="l3_aon_clkdm" , - .main_clk ="debugss_ick" , - .prcm = { - .omap4 = { - .clkctrl_offs =AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET , - .modulemode =MODULEMODE_SWCTRL , - }, - }, -}; -/* ocmcram */ static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = { .name ="ocmcram" ,@@ -570,6 +549,28 @@ static struct omap_hwmod am33xx_sha0_hwmod = {#endif +/* +* 'debugss' class +* debug sub system +*/ +static struct omap_hwmod_class am33xx_debugss_hwmod_class = { + .name ="debugss" , +}; + +static struct omap_hwmod am33xx_debugss_hwmod = { + .name ="debugss" ,
Quoted 9 lines
Quoted 4 lines
Quoted 4 lines
arch/arm/mach-omap2/omap_hwmod_33xx_data.c static struct omap_hwmod am33xx_sha0_hwmod = { · line 565
Quoted 4 lines
arch/arm/mach-omap2/omap_hwmod_33xx_data.c +4
-0+ .class = &am33xx_debugss_hwmod_class, + .clkdm_name = "l3_aon_clkdm", + .main_clk = "debugss_ick", + .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),Setting these flags would still leave the problem where JTAG clocks are on when its not required no? In that case, what is the advantage of this patch?
I missed to wrap it around #ifdef CONFIG_DEBUG_KERNEL. I will submit the formal patch shortly.
Thanks,
Vaibhav
Quoted 7 lines · Vaibhav
Quoted 7 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
(quoted diff) +6
-0+static struct omap_hwmod am33xx_debugss_hwmod = { + .name = "debugss", + .class = &am33xx_debugss_hwmod_class, + .clkdm_name = "l3_aon_clkdm", + .main_clk = "debugss_ick", + .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
Quoted 7 lines
Quoted 4 lines
Setting these flags would still leave the problem where JTAG clocks are on when its not required no? In that case, what is the advantage of this patch?
I missed to wrap it around #ifdef
CONFIG_DEBUG_KERNEL. I will submit the formal patch shortly.
IMO, this should not be handled in the data at all (neither clock nor hwmod), and should be handled at runtime/boot-time, not compile time.
The solution to this is to rather to have a small bit of code that requests the debugss clocks that are needed for JTAG debug, so the kernel knows they are in use.
That code could then be enabled at boot time via command-line or DT option.
Kevin
Quoted 14 lines · Kevin Hilman
Quoted 12 lines · Vaibhav
Quoted 11 lines
Quoted 6 lines
Quoted 6 lines
Review
Quoted 6 lines
(quoted diff) +6
-0+static struct omap_hwmod am33xx_debugss_hwmod = { + .name = "debugss", + .class = &am33xx_debugss_hwmod_class, + .clkdm_name = "l3_aon_clkdm", + .main_clk = "debugss_ick", + .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),Setting these flags would still leave the problem where JTAG clocks are on when its not required no? In that case, what is the advantage of this patch?
Quoted 6 lines
Quoted 2 lines
I missed to wrap it around #ifdef
CONFIG_DEBUG_KERNEL. I will submit the formal patch shortly.IMO, this should not be handled in the data at all (neither clock nor hwmod), and should be handled at runtime/boot-time, not compile time.
Wouldn't that become another interface/control for debug? We already have various (standard) debug kernel parameters available.
But I see your point, compile-time option will force users to rebuild kernel just in order to disable JTAG/Debug clock.
Quoted 7 lines
The solution to this is to rather to have a small bit of code that requests the debugss clocks that are needed for JTAG debug, so the kernel knows they are in use.
That code could then be enabled at boot time via command-line or DT option.
In case of command-line, something like below???
static int __init omap2_debug_clk_enable(char *str)
{
if (!str)
return 0;
if (!strcmp(str, "debug"))
<enable debug clock>
return 0;
}early_param("debug", omap2_debug_clk_enable);
In case of DT, one thought,
It can be part of omap_generic_init() in board-generic.c file, We can parse there for debug node and required property to enable debug module.
Any thought? Or Other options???
Thanks,
Vaibhav
Quoted 52 lines · Vaibhav
Quoted 15 lines · Kevin Hilman
Quoted 13 lines · Vaibhav
Quoted 12 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
(quoted diff) +6
-0+static struct omap_hwmod am33xx_debugss_hwmod = { + .name = "debugss", + .class = &am33xx_debugss_hwmod_class, + .clkdm_name = "l3_aon_clkdm", + .main_clk = "debugss_ick", + .flags = (HWMOD_INIT_NO_IDLE |
HWMOD_INIT_NO_RESET),Setting these flags would still leave the problem where JTAG clocks are on when its not required no? In that case, what is the advantage of this patch?
Quoted 7 lines
Quoted 3 lines
I missed to wrap it around #ifdef
CONFIG_DEBUG_KERNEL. I will submit the
formal patch shortly.IMO, this should not be handled in the data at all (neither clock nor hwmod), and should be handled at runtime/boot-time, not compile time.
Wouldn't that become another interface/control for debug? We already have various (standard) debug kernel parameters available.
But I see your point, compile-time option will force users to rebuild kernel
just in order to disable JTAG/Debug clock.Quoted 7 lines
The solution to this is to rather to have a small bit of code that requests the debugss clocks that are needed for JTAG debug, so the kernel knows they are in use.
That code could then be enabled at boot time via command-line or DT option.
In case of command-line, something like below???
static int
__initomap2_debug_clk_enable(char *str){ if (!str) return 0; if (!strcmp(str, "debug")) <enable debug clock> return 0; }
Quoted 2 lines
early_param("debug", omap2_debug_clk_enable);
This approach looks , I wrote similar code replacing "enable debug clock" with:
jtag_clk = clk_get(NULL, "debugss_ick");
if(!IS_ERR_OR_NULL(jtag_clk))
clk_enable(jtag_clk);
Quoted 8 lines
In case of DT, one thought,
It can be part of
omap_generic_init()inboard-generic.cfile, We can parse there for debug node and required property to enable debug module.Any thought? Or Other options???
Not sure, but can we append to bootargs from DT itself thus the above cmdline code can be used to enable debugss for both regular bootargs as well DT?
Regards,
Joel
Quoted 48 lines · Vaibhav
Quoted 14 lines · Kevin Hilman
Quoted 12 lines · Vaibhav
Quoted 11 lines
Quoted 6 lines
Quoted 6 lines
Review
Quoted 6 lines
(quoted diff) +6
-0+static struct omap_hwmod am33xx_debugss_hwmod = { + .name = "debugss", + .class = &am33xx_debugss_hwmod_class, + .clkdm_name = "l3_aon_clkdm", + .main_clk = "debugss_ick", + .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),Setting these flags would still leave the problem where JTAG clocks are on when its not required no? In that case, what is the advantage of this patch?
Quoted 6 lines
Quoted 2 lines
I missed to wrap it around #ifdef
CONFIG_DEBUG_KERNEL. I will submit the formal patch shortly.IMO, this should not be handled in the data at all (neither clock nor hwmod), and should be handled at runtime/boot-time, not compile time.
Wouldn't that become another interface/control for debug? We already have various (standard) debug kernel parameters available.
But I see your point, compile-time option will force users to rebuild kernel just in order to disable JTAG/Debug clock.
Quoted 7 lines
The solution to this is to rather to have a small bit of code that requests the debugss clocks that are needed for JTAG debug, so the kernel knows they are in use.
That code could then be enabled at boot time via command-line or DT option.
In case of command-line, something like below???
static int
__initomap2_debug_clk_enable(char *str){ if (!str) return 0; if (!strcmp(str, "debug")) <enable debug clock> return 0; }
Quoted 1 line
early_param("debug", omap2_debug_clk_enable);
Yes, that's the idea I had in mind. Though you don't want to override "debug" here. The debug option is specifically about default log levels for the console and isn't really related to clocks.
Kevin
Quoted 217 lines · Igor Mazanov
Quoted 216 lines · Vaibhav
Quoted 203 lines · Vaibhav
Quoted 47 lines · Igor Mazanov
Quoted 46 lines · Vaibhav Hiremath
Quoted 11 lines · Igor Mazanov
Quoted 10 lines · Tony Lindgren
Quoted 7 lines · Jean Pihet
Quoted 6 lines · Igor Mazanov
Beaglebone boot process is broken with the current git kernel. I use
omap2plus_defconfigfor tests.It looks like the boot process stops due to the last changes in the AM33xx clock sysbsystem. A following patch resolves this issue:
...
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
The patch should change the name of the hwmod entry as well, can you fold this change in the current patch?
Any news on updating this?
The current kernel boots, but after a switching to CCF doesn't work the debugss - it's just disabled in the current hwmod code. So, it looks like we can't use JTAG to connect to the running kernel.
just resumed from vacation...
JTAG clock will get disabled because,
CONFIG_OMAP_RESET_CLOCKSwill disable unused clocks, so as debugss clock.There is another thread started by Joel on the similar issue,
http://www.mail-archive.com/[email protected]/msg80863.html
Something below should be done for debugss on AM33xx,
arch/arm/mach-omap2/clock33xx_data.c +2
-0@@ -584,6 +584,9 @@ static struct clk debugss_ick = { .clkdm_name = "l3_aon_clkdm", .parent = &dpll_core_m4_ck, .ops = &clkops_omap2_dflt, +#ifdef CONFIG_DEBUG_KERNEL + .flags = ENABLE_ON_INIT,Quoted 8 lines
arch/arm/mach-omap2/clock33xx_data.c static struct clk debugss_ick = { · line 592
Quoted 4 lines
arch/arm/mach-omap2/clock33xx_data.c +1
-0+#endif .enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL, .enable_bit = AM33XX_MODULEMODE_SWCTRL, .recalc = &followparent_recalc,Yes, I noticed this thread. But now a clock subsystem in the current kernel is switched to Common Clock Framework and debugss (and several another modules) is disabled
Still this can be handled and enabled during init.
Quoted 29 lines
(#if 0 .... #endif) in
omap_hwmod_33xx_data.c.From
omap_hwmod_33xx_data.c:/*
* Modulesomap_hwmodstructures
*
* The following IPs are excluded for the moment because:
* - They do not need an explicit SW control usingomap_hwmodAPI.
* - They still need to be validated with the driver
* properly adapted toomap_hwmod/omap_device
** - cEFUSE (doesn't fall under any ocp_if) * - clkdiv32k * - debugss * - ocmc ram * - ocp watch point * - aes0 * - sha0*/
I uncommented the debugss entry in the
omap_hwmodsettings, but only got a warning like:CC
arch/arm/mach-omap2/omap_hwmod_33xx_data.oarch/arm/mach-omap2/omap_hwmod_33xx_data.c:472:26: warning:
'am33xx_debugss_hwmod' defined but not used [-Wunused-variable]Quoted 6 lines
By the way, I need to use JTAG to trace a problem described in this thread:
http://marc.info/?l=linux-omap&m=135307646415429&w=2
May be, it's the clocks related issue too...
I have quickly created patch for you, can you try below patch and let me know?
arch/arm/mach-omap2/cclock33xx_data.c +1
-0@@ -920,6 +920,7 @@ static const char *enable_init_clks[] = {"l4hs_gclk" ,"l4fw_gclk" ,"l4ls_gclk" , + "debugss_ick", };int __init am33xx_clk_init (void )arch/arm/mach-omap2/omap_hwmod_33xx_data.c +40
-21@@ -460,27 +460,6 @@ static struct omap_hwmod am33xx_clkdiv32k_hwmod = { }, }; -/* -* 'debugss' class -* debug sub system -*/ -static struct omap_hwmod_class am33xx_debugss_hwmod_class = { - .name ="debugss" , -}; - -static struct omap_hwmod am33xx_debugss_hwmod = { - .name ="debugss" , - .class = &am33xx_debugss_hwmod_class, - .clkdm_name ="l3_aon_clkdm" , - .main_clk ="debugss_ick" , - .prcm = { - .omap4 = { - .clkctrl_offs =AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET , - .modulemode =MODULEMODE_SWCTRL , - }, - }, -}; -/* ocmcram */ static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = { .name ="ocmcram" ,@@ -570,6 +549,28 @@ static struct omap_hwmod am33xx_sha0_hwmod = {#endif +/* +* 'debugss' class +* debug sub system +*/ +static struct omap_hwmod_class am33xx_debugss_hwmod_class = { + .name ="debugss" , +}; + +static struct omap_hwmod am33xx_debugss_hwmod = { + .name ="debugss" , + .class = &am33xx_debugss_hwmod_class, + .clkdm_name ="l3_aon_clkdm" , + .main_clk ="debugss_ick" , + .flags = (HWMOD_INIT_NO_IDLE |HWMOD_INIT_NO_RESET ), + .prcm = { + .omap4 = { + .clkctrl_offs =AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET , + .modulemode =MODULEMODE_SWCTRL , + }, + }, +}; +/* 'smartreflex' class */ static struct omap_hwmod_class am33xx_smartreflex_hwmod_class = { .name ="smartreflex" ,@@ -2261,6 +2262,24 @@ static struct omap_hwmod_ocp_if am33xx_l3_main__gfx = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +/* l3_main -> debugss */ +static struct omap_hwmod_addr_space am33xx_debugss_addrs[] = { + { + .pa_start =0x4b000000 , + .pa_end =0x4b000000 +SZ_16M -1 , + .flags =ADDR_TYPE_RT + }, + { } +}; + +static struct omap_hwmod_ocp_if am33xx_l3_main__debugss = { + .master = &am33xx_l3_main_hwmod, + .slave = &am33xx_debugss_hwmod, + .clk ="debugss_ick" , + .addr = am33xx_debugss_addrs, + .user =OCP_USER_MPU , +}; +/* l4 wkup -> smartreflex0 */ static struct omap_hwmod_addr_space am33xx_smartreflex0_addrs[] = { {arch/arm/mach-omap2/omap_hwmod_33xx_data.c static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = { · line 3340
Quoted 7 lines
arch/arm/mach-omap2/omap_hwmod_33xx_data.c +1
-0@@ -3315,6 +3334,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = { &am33xx_pruss__l3_main, &am33xx_wkup_m3__l4_wkup, &am33xx_gfx__l3_main, + &am33xx_l3_main__debugss, &am33xx_l4_wkup__wkup_m3, &am33xx_l4_wkup__control, &am33xx_l4_wkup__smartreflex0,Missed to mention that,
Quoted 7 lines
Quoted 3 lines
I have boot tested it on Bone platform and made sure that debugs module stays enabled after boot (after applying this patch).
I applied your patch and it works for me too. JTAG interface is working now. Thanks!
Thanks Igor,
I will submit formal patch shortly, care to test and review/ack it.
Thanks,
Vaibhav
Quoted 47 lines · Igor Mazanov
Quoted 46 lines · Vaibhav Hiremath
Quoted 11 lines · Igor Mazanov
Quoted 10 lines · Tony Lindgren
Quoted 7 lines · Jean Pihet
Quoted 6 lines · Igor Mazanov
Beaglebone boot process is broken with the current git kernel. I use
omap2plus_defconfigfor tests.It looks like the boot process stops due to the last changes in the AM33xx clock sysbsystem. A following patch resolves this issue:
...
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
The patch should change the name of the hwmod entry as well, can you fold this change in the current patch?
Any news on updating this?
The current kernel boots, but after a switching to CCF doesn't work the debugss - it's just disabled in the current hwmod code. So, it looks like we can't use JTAG to connect to the running kernel.
just resumed from vacation...
JTAG clock will get disabled because,
CONFIG_OMAP_RESET_CLOCKSwill disable unused clocks, so as debugss clock.There is another thread started by Joel on the similar issue,
http://www.mail-archive.com/[email protected]/msg80863.html
Something below should be done for debugss on AM33xx,
arch/arm/mach-omap2/clock33xx_data.c +2
-0@@ -584,6 +584,9 @@ static struct clk debugss_ick = { .clkdm_name = "l3_aon_clkdm", .parent = &dpll_core_m4_ck, .ops = &clkops_omap2_dflt, +#ifdef CONFIG_DEBUG_KERNEL + .flags = ENABLE_ON_INIT,
Quoted 8 lines
arch/arm/mach-omap2/clock33xx_data.c static struct clk debugss_ick = { · line 592
Quoted 4 lines
arch/arm/mach-omap2/clock33xx_data.c +1
-0+#endif .enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL, .enable_bit = AM33XX_MODULEMODE_SWCTRL, .recalc = &followparent_recalc,Yes, I noticed this thread. But now a clock subsystem in the current kernel is switched to Common Clock Framework and debugss (and several another modules) is disabled
Still this can be handled and enabled during init.
Quoted 29 lines
(#if 0 .... #endif) in
omap_hwmod_33xx_data.c.From
omap_hwmod_33xx_data.c:/*
* Modulesomap_hwmodstructures
*
* The following IPs are excluded for the moment because:
* - They do not need an explicit SW control usingomap_hwmodAPI.
* - They still need to be validated with the driver
* properly adapted toomap_hwmod/omap_device
** - cEFUSE (doesn't fall under any ocp_if) * - clkdiv32k * - debugss * - ocmc ram * - ocp watch point * - aes0 * - sha0*/
I uncommented the debugss entry in the
omap_hwmodsettings, but only got a warning like:CC
arch/arm/mach-omap2/omap_hwmod_33xx_data.oarch/arm/mach-omap2/omap_hwmod_33xx_data.c:472:26: warning:
'am33xx_debugss_hwmod' defined but not used [-Wunused-variable]
Quoted 6 lines
By the way, I need to use JTAG to trace a problem described in this thread:
http://marc.info/?l=linux-omap&m=135307646415429&w=2
May be, it's the clocks related issue too...
I have quickly created patch for you, can you try below patch and let me know?
arch/arm/mach-omap2/cclock33xx_data.c +1 -0
@@ -920,6 +920,7 @@ static const char *enable_init_clks[] = {"l4hs_gclk" ,"l4fw_gclk" ,"l4ls_gclk" , + "debugss_ick", };int __init am33xx_clk_init (void )
arch/arm/mach-omap2/omap_hwmod_33xx_data.c +0 -21
@@ -460,27 +460,6 @@ static struct omap_hwmod am33xx_clkdiv32k_hwmod = { }, }; -/* -* 'debugss' class -* debug sub system -*/ -static struct omap_hwmod_class am33xx_debugss_hwmod_class = { - .name ="debugss" , -}; - -static struct omap_hwmod am33xx_debugss_hwmod = { - .name ="debugss" , - .class = &am33xx_debugss_hwmod_class, - .clkdm_name ="l3_aon_clkdm" , - .main_clk ="debugss_ick" , - .prcm = { - .omap4 = { - .clkctrl_offs =AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET , - .modulemode =MODULEMODE_SWCTRL , - }, - }, -}; -
/* ocmcram */
static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = {
.name = "ocmcram",@@ -570,6 +549,28 @@ static struct omap_hwmod am33xx_sha0_hwmod = {
#endif
+/*
+ * 'debugss' class
+ * debug sub system
+ */
+static struct omap_hwmod_class am33xx_debugss_hwmod_class = {
+ .name = "debugss",
+};
+
+static struct omap_hwmod am33xx_debugss_hwmod = {
+ .name = "debugss",
+ .class = &am33xx_debugss_hwmod_class,
+ .clkdm_name = "l3_aon_clkdm",
+ .main_clk = "debugss_ick",
+ .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,+ },
+ },
+};
+
/* 'smartreflex' class */
static struct omap_hwmod_class am33xx_smartreflex_hwmod_class = {
.name = "smartreflex",
@@ -2261,6 +2262,24 @@ static struct omap_hwmod_ocp_if am33xx_l3_main__gfx = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l3_main -> debugss */
+static struct omap_hwmod_addr_space am33xx_debugss_addrs[] = {
+ {
+ .pa_start = 0x4b000000, + .pa_end = 0x4b000000 + SZ_16M - 1, + .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+static struct omap_hwmod_ocp_if am33xx_l3_main__debugss = {
+ .master = &am33xx_l3_main_hwmod,
+ .slave = &am33xx_debugss_hwmod,
+ .clk = "debugss_ick",
+ .addr = am33xx_debugss_addrs,
+ .user = OCP_USER_MPU,
+};
+
/* l4 wkup -> smartreflex0 */
static struct omap_hwmod_addr_space am33xx_smartreflex0_addrs[] = {
{
@@ -3315,6 +3334,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
&am33xx_pruss__l3_main,
&am33xx_wkup_m3__l4_wkup,
&am33xx_gfx__l3_main,
+ &am33xx_l3_main__debugss,
&am33xx_l4_wkup__wkup_m3,
&am33xx_l4_wkup__control,
&am33xx_l4_wkup__smartreflex0,Thanks,
Vaibhav