- TF-A - lists.trustedfirmware.org

Re: [TF-A] [Question] Why are the log related macros defined in multiple of 10's

by Dan Handley

Hi > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew > via TF-A > Sent: 06 January 2020 12:34 > To: Olivier Deprez <Olivier.Deprez(a)arm.com>; tf-a(a)lists.trustedfirmware.org; > Sheetal Tigadoli <sheetal.tigadoli(a)broadcom.com> > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-A] [Question] Why are the log related macros defined in > multiple of 10's > > > Hi All, > > > > I wanted to understand the reason behind defining LOG_LEVEL_* macros > > as multiple of 10's, also same goes with LOG_MARKER_* macros. > > If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and > > division operation when printing the msgs to console. > > > > Please let me your thoughts on this. > > > > Link to this question on Phabricator - > > https://developer.trustedfirmware.org/T624 > > > > Thanks > > Sheetal > As Sandrine said in Phabricator, the reason was simply to leave space between the levels to allow adding intermediate levels without breaking compatibility. Compatibility was a possible concern if external tools used the log level and you only rebuilt some of the TF-A components (components could end up using different values). However, I suspect the actual level value is never emitted in practice (just the text prefix) so this may not be a real concern. > Hi Sheetal > I didn't quite get reason for the optimization from multiples of 10 to > consecutive numbers. The mod operation you refer to are assertions which will > be compiled out when DEBUG=0 or when ENABLE_ASSSERTIONS=0. Other than that > there is a single divide by 10 operation within the default implementation of > plat_log_get_prefix(). > > > If the logging utility is considered performance critical, removing the > single divide by 10 will not result in any gain. Usually the bottleneck for > logs are UART baudrates and the CPU spends most of time spinning in a wait > loop for UART to be free. Hence I don't see any need for change for log > levels macro if the intent is performance optimization. > +1. Unless there's an actual performance gain, this sounds like an unnecessary change. Dan. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 3 months

1
0
0 0

Re: [TF-A] [Question] Why are the log related macros defined in multiple of 10's

by Soby Mathew

On 06/01/2020 12:34, Soby Mathew via TF-A wrote: >> Hi All, >> >> I wanted to understand the reason behind defining LOG_LEVEL_* macros as >> multiple of 10's, also same goes with LOG_MARKER_* macros. >> If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and >> division operation when printing the msgs to console. >> >> Please let me your thoughts on this. >> >> Link to this question on Phabricator - >> https://developer.trustedfirmware.org/T624 >> >> Thanks >> Sheetal > > Hi Sheetal > I didn't quite get reason for the optimization from multiples of 10 to > consecutive numbers. The mod operation you refer to are assertions which > will be compiled out when DEBUG=0 or when ENABLE_ASSSERTIONS=0. Other > than that there is a single divide by 10 operation within the default > implementation of plat_log_get_prefix(). > > > If the logging utility is considered performance critical, removing the > single divide by 10 will not result in any gain. Usually the bottleneck > for logs are UART baudrates and the CPU spends most of time spinning in > a wait loop for UART to be free. Hence I don't see any need for change > for log levels macro if the intent is performance optimization. > > Best Regards > Soby Mathew > Hi Sheetal There is some discussion related to this here : https://github.com/ARM-software/tf-issues/issues/462 and see associated issues and PRs for more details. Best Regards Soby Mathew >> -- >> TF-A mailing list >> TF-A(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> >

6 years, 3 months

1
0
0 0

Re: [TF-A] [Question] Why are the log related macros defined in multiple of 10's

by Soby Mathew

> Hi All, > > I wanted to understand the reason behind defining LOG_LEVEL_* macros as > multiple of 10's, also same goes with LOG_MARKER_* macros. > If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and > division operation when printing the msgs to console. > > Please let me your thoughts on this. > > Link to this question on Phabricator - > https://developer.trustedfirmware.org/T624 > > Thanks > Sheetal Hi Sheetal I didn't quite get reason for the optimization from multiples of 10 to consecutive numbers. The mod operation you refer to are assertions which will be compiled out when DEBUG=0 or when ENABLE_ASSSERTIONS=0. Other than that there is a single divide by 10 operation within the default implementation of plat_log_get_prefix(). If the logging utility is considered performance critical, removing the single divide by 10 will not result in any gain. Usually the bottleneck for logs are UART baudrates and the CPU spends most of time spinning in a wait loop for UART to be free. Hence I don't see any need for change for log levels macro if the intent is performance optimization. Best Regards Soby Mathew > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a >

6 years, 3 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 9 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 13 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 9 of 9 defect(s) ** CID 353233: Control flow issues (NO_EFFECT) /plat/intel/soc/common/socfpga_sip_svc.c: 235 in is_address_in_ddr_range() ________________________________________________________________________________________________________ *** CID 353233: Control flow issues (NO_EFFECT) /plat/intel/soc/common/socfpga_sip_svc.c: 235 in is_address_in_ddr_range() 229 return false; 230 return true; 231 } 232 233 static bool is_address_in_ddr_range(uint64_t addr) 234 { >>> CID 353233: Control flow issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "addr >= 0ULL". 235 if (addr >= DRAM_BASE && addr <= DRAM_BASE + DRAM_SIZE) 236 return true; 237 238 return false; 239 } 240 ** CID 353232: Memory - corruptions (OVERRUN) /plat/rockchip/common/drivers/parameter/ddr_parameter.c: 124 in ddr_region_usage_parse() ________________________________________________________________________________________________________ *** CID 353232: Memory - corruptions (OVERRUN) /plat/rockchip/common/drivers/parameter/ddr_parameter.c: 124 in ddr_region_usage_parse() 118 * that means s-regions are all parsed yet, so finsh. 119 */ 120 if (p.ns_top[i] == p.boundary) 121 goto out; 122 123 /* s-region's base starts from previous ns-region's top */ >>> CID 353232: Memory - corruptions (OVERRUN) >>> Overrunning array "p.s_base" of 10 8-byte elements at element index 10 (byte offset 87) using index "p.s_nr" (which evaluates to 10). 124 p.s_base[p.s_nr] = p.ns_top[i]; 125 126 /* s-region's top ends with next ns-region's base */ 127 if (i + 1 < p.ns_nr) 128 p.s_top[p.s_nr] = p.ns_base[i + 1]; 129 else ** CID 353231: (DIVIDE_BY_ZERO) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 374 in mv_ddr4_dq_vref_calibration() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 380 in mv_ddr4_dq_vref_calibration() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 378 in mv_ddr4_dq_vref_calibration() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 376 in mv_ddr4_dq_vref_calibration() ________________________________________________________________________________________________________ *** CID 353231: (DIVIDE_BY_ZERO) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 374 in mv_ddr4_dq_vref_calibration() 368 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, subphy_num); 369 vref_avg += center_vref[if_id][subphy_num]; 370 dq_vref_vec[subphy_num] = center_vref[if_id][subphy_num]; 371 vref_subphy_num++; 372 } 373 >>> CID 353231: (DIVIDE_BY_ZERO) >>> In expression "vref_avg / vref_subphy_num", division by expression "vref_subphy_num" which may be zero has undefined behavior. 374 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 375 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_START); 376 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 377 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_END); 378 DEBUG_CALIBRATION(DEBUG_LEVEL_INFO, ("final vref average %d\n", vref_avg / vref_subphy_num)); 379 /* run centralization again with optimal vref to update global structures */ /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 380 in mv_ddr4_dq_vref_calibration() 374 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 375 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_START); 376 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 377 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_END); 378 DEBUG_CALIBRATION(DEBUG_LEVEL_INFO, ("final vref average %d\n", vref_avg / vref_subphy_num)); 379 /* run centralization again with optimal vref to update global structures */ >>> CID 353231: (DIVIDE_BY_ZERO) >>> In expression "vref_avg / vref_subphy_num", division by expression "vref_subphy_num" which may be zero has undefined behavior. 380 mv_ddr4_centralization(dev_num, pbs_tap_factor, c_opt_per_bus, pbs_res_per_bus, valid_win_size, 381 TX_DIR, vref_avg / vref_subphy_num, duty_cycle); 382 } 383 384 /* return dram from vref DRAM from vref training mode */ 385 mv_ddr4_vref_training_mode_ctrl(dev_num, 0, ACCESS_TYPE_MULTICAST, 0); /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 378 in mv_ddr4_dq_vref_calibration() 372 } 373 374 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 375 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_START); 376 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 377 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_END); >>> CID 353231: (DIVIDE_BY_ZERO) >>> In expression "vref_avg / vref_subphy_num", division by expression "vref_subphy_num" which may be zero has undefined behavior. 378 DEBUG_CALIBRATION(DEBUG_LEVEL_INFO, ("final vref average %d\n", vref_avg / vref_subphy_num)); 379 /* run centralization again with optimal vref to update global structures */ 380 mv_ddr4_centralization(dev_num, pbs_tap_factor, c_opt_per_bus, pbs_res_per_bus, valid_win_size, 381 TX_DIR, vref_avg / vref_subphy_num, duty_cycle); 382 } 383 /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 376 in mv_ddr4_dq_vref_calibration() 370 dq_vref_vec[subphy_num] = center_vref[if_id][subphy_num]; 371 vref_subphy_num++; 372 } 373 374 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 375 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_START); >>> CID 353231: (DIVIDE_BY_ZERO) >>> In expression "vref_avg / vref_subphy_num", division by expression "vref_subphy_num" which may be zero has undefined behavior. 376 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 377 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_END); 378 DEBUG_CALIBRATION(DEBUG_LEVEL_INFO, ("final vref average %d\n", vref_avg / vref_subphy_num)); 379 /* run centralization again with optimal vref to update global structures */ 380 mv_ddr4_centralization(dev_num, pbs_tap_factor, c_opt_per_bus, pbs_res_per_bus, valid_win_size, 381 TX_DIR, vref_avg / vref_subphy_num, duty_cycle); ** CID 353230: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 353230: Memory - corruptions (OVERRUN) /drivers/marvell/mv_ddr/ddr3_debug.c: 1570 in run_xsb_test() 1564 if (write_type != 0) { 1565 CHECK_STATUS(ddr3_tip_ext_write 1566 (dev_num, if_id, addr, 1, 1567 xsb_test_table[seq])); 1568 } 1569 if (read_type != 0) { >>> CID 353230: Memory - corruptions (OVERRUN) >>> Overrunning array "data_read" of 1 4-byte elements by passing it to a function which accesses it at element index 7 (byte offset 31) using argument "1U". 1570 CHECK_STATUS(ddr3_tip_ext_read 1571 (dev_num, if_id, addr, 1, 1572 data_read)); 1573 } 1574 if ((read_type != 0) && (write_type != 0)) { 1575 ret_tmp = ** CID 353229: Memory - corruptions (OVERRUN) /plat/rockchip/common/drivers/parameter/ddr_parameter.c: 130 in ddr_region_usage_parse() ________________________________________________________________________________________________________ *** CID 353229: Memory - corruptions (OVERRUN) /plat/rockchip/common/drivers/parameter/ddr_parameter.c: 130 in ddr_region_usage_parse() 124 p.s_base[p.s_nr] = p.ns_top[i]; 125 126 /* s-region's top ends with next ns-region's base */ 127 if (i + 1 < p.ns_nr) 128 p.s_top[p.s_nr] = p.ns_base[i + 1]; 129 else >>> CID 353229: Memory - corruptions (OVERRUN) >>> Overrunning array "p.s_top" of 10 8-byte elements at element index 10 (byte offset 87) using index "p.s_nr" (which evaluates to 10). 130 p.s_top[p.s_nr] = p.boundary; 131 p.s_nr++; 132 } 133 out: 134 return p; ** CID 353228: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /lib/debugfs/devfip.c: 106 in get_entry() ________________________________________________________________________________________________________ *** CID 353228: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /lib/debugfs/devfip.c: 106 in get_entry() 100 } 101 102 if (n != sizeof(struct fip_entry)) { 103 return -1; 104 } 105 >>> CID 353228: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "entry->size > 9223372036854775807L" is always false regardless of the values of its operands. This occurs as the logical first operand of "||". 106 if ((entry->size > LONG_MAX) || (entry->offset_address > LONG_MAX)) { 107 return -1; 108 } 109 110 if (entry->size == 0) { 111 return 0; ** CID 353227: Parse warnings (PARSE_ERROR) /services/std_svc/spm_mm/spm_mm_xlat.c: 26 in () ________________________________________________________________________________________________________ *** CID 353227: Parse warnings (PARSE_ERROR) /services/std_svc/spm_mm/spm_mm_xlat.c: 26 in () 20 /* Place translation tables by default along with the ones used by BL31. */ 21 #ifndef PLAT_SP_IMAGE_XLAT_SECTION_NAME 22 #define PLAT_SP_IMAGE_XLAT_SECTION_NAME "xlat_table" 23 #endif 24 25 /* Allocate and initialise the translation context for the secure partitions. */ >>> CID 353227: Parse warnings (PARSE_ERROR) >>> expected a string literal 26 REGISTER_XLAT_CONTEXT2(sp, 27 PLAT_SP_IMAGE_MMAP_REGIONS, 28 PLAT_SP_IMAGE_MAX_XLAT_TABLES, 29 PLAT_VIRT_ADDR_SPACE_SIZE, PLAT_PHY_ADDR_SPACE_SIZE, 30 EL1_EL0_REGIME, PLAT_SP_IMAGE_XLAT_SECTION_NAME); 31 ** CID 353226: (VARARGS) /lib/libc/snprintf.c: 110 in snprintf() /lib/libc/snprintf.c: 93 in snprintf() /lib/libc/snprintf.c: 114 in snprintf() ________________________________________________________________________________________________________ *** CID 353226: (VARARGS) /lib/libc/snprintf.c: 110 in snprintf() 104 unum = (unsigned int)num; 105 } 106 107 unsigned_dec_print(&s, n, &chars_printed, unum); 108 break; 109 case 's': >>> CID 353226: (VARARGS) >>> Calling va_arg on va_list "args", which has not been prepared with va_start(). 110 str = va_arg(args, char *); 111 string_print(&s, n, &chars_printed, str); 112 break; 113 case 'u': 114 unum = va_arg(args, unsigned int); 115 unsigned_dec_print(&s, n, &chars_printed, unum); /lib/libc/snprintf.c: 93 in snprintf() 87 if (*fmt == '%') { 88 fmt++; 89 /* Check the format specifier. */ 90 switch (*fmt) { 91 case 'i': 92 case 'd': >>> CID 353226: (VARARGS) >>> Calling va_arg on va_list "args", which has not been prepared with va_start(). 93 num = va_arg(args, int); 94 95 if (num < 0) { 96 if (chars_printed < n) { 97 *s = '-'; 98 s++; /lib/libc/snprintf.c: 114 in snprintf() 108 break; 109 case 's': 110 str = va_arg(args, char *); 111 string_print(&s, n, &chars_printed, str); 112 break; 113 case 'u': >>> CID 353226: (VARARGS) >>> Calling va_arg on va_list "args", which has not been prepared with va_start(). 114 unum = va_arg(args, unsigned int); 115 unsigned_dec_print(&s, n, &chars_printed, unum); 116 break; 117 default: 118 /* Panic on any other format specifier. */ 119 ERROR("snprintf: specifier with ASCII code '%d' not supported.", ** CID 353225: Control flow issues (NO_EFFECT) /plat/intel/soc/common/soc/socfpga_mailbox.c: 298 in intel_mailbox_get_config_status() ________________________________________________________________________________________________________ *** CID 353225: Control flow issues (NO_EFFECT) /plat/intel/soc/common/soc/socfpga_mailbox.c: 298 in intel_mailbox_get_config_status() 292 uint32_t status, res; 293 uint32_t response[6]; 294 295 status = mailbox_send_cmd(1, cmd, NULL, 0, 0, response, 296 sizeof(response) / sizeof(response[0])); 297 >>> CID 353225: Control flow issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "status < 0U". 298 if (status < 0) 299 return status; 300 301 res = response[RECONFIG_STATUS_STATE]; 302 if (res && res != MBOX_CFGSTAT_STATE_CONFIG) 303 return res; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

6 years, 3 months

1
0
0 0

Re: [TF-A] New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by Alexei Fedorov

Hi Varun Could you take a look at the Nvidia driver defect reported by the Coverity scan? Regards. Alexei. ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of scan-admin--- via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 03 January 2020 08:19 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 352832: Uninitialized variables (UNINIT) /plat/nvidia/tegra/soc/t194/drivers/mce/nvg.c: 197 in nvg_update_ccplex_gsc() ________________________________________________________________________________________________________ *** CID 352832: Uninitialized variables (UNINIT) /plat/nvidia/tegra/soc/t194/drivers/mce/nvg.c: 197 in nvg_update_ccplex_gsc() 191 ret = EINVAL; 192 } else { 193 nvg_set_request_data((uint64_t)TEGRA_NVG_CHANNEL_UPDATE_CCPLEX_GSC, 194 (uint64_t)gsc_idx); 195 } 196 >>> CID 352832: Uninitialized variables (UNINIT) >>> Using uninitialized value "ret". 197 return ret; 198 } 199 200 /* 201 * Cache clean operation for all CCPLEX caches. 202 */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 3 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 352832: Uninitialized variables (UNINIT) /plat/nvidia/tegra/soc/t194/drivers/mce/nvg.c: 197 in nvg_update_ccplex_gsc() ________________________________________________________________________________________________________ *** CID 352832: Uninitialized variables (UNINIT) /plat/nvidia/tegra/soc/t194/drivers/mce/nvg.c: 197 in nvg_update_ccplex_gsc() 191 ret = EINVAL; 192 } else { 193 nvg_set_request_data((uint64_t)TEGRA_NVG_CHANNEL_UPDATE_CCPLEX_GSC, 194 (uint64_t)gsc_idx); 195 } 196 >>> CID 352832: Uninitialized variables (UNINIT) >>> Using uninitialized value "ret". 197 return ret; 198 } 199 200 /* 201 * Cache clean operation for all CCPLEX caches. 202 */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

6 years, 3 months

1
0
0 0

Re: [TF-A] [Question] Why are the log related macros defined in multiple of 10's

by Olivier Deprez

Hi Sheetal, Your remark/question makes sense. The original requirement is described here: https://github.com/ARM-software/tf-issues/issues/232 We may get further update from Dan, but I sense this was to provision for intermediate log levels (as stated by Sandrine on phabricator). Will you be able to submit a patch for this? Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Sheetal Tigadoli via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 20 December 2019 15:48 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] [Question] Why are the log related macros defined in multiple of 10's Hi All, I wanted to understand the reason behind defining LOG_LEVEL_* macros as multiple of 10's, also same goes with LOG_MARKER_* macros. If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and division operation when printing the msgs to console. Please let me your thoughts on this. Link to this question on Phabricator - https://developer.trustedfirmware.org/T624 Thanks Sheetal -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 3 months

2
1
0 0

[Question] Why are the log related macros defined in multiple of 10's

by Sheetal Tigadoli

Hi All, I wanted to understand the reason behind defining LOG_LEVEL_* macros as multiple of 10's, also same goes with LOG_MARKER_* macros. If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and division operation when printing the msgs to console. Please let me your thoughts on this. Link to this question on Phabricator - https://developer.trustedfirmware.org/T624 Thanks Sheetal

6 years, 3 months

1
0
0 0

[Question] Why are the log related macros defined in multiple of 10's

by Sheetal Tigadoli

Hi All, I wanted to understand the reason behind defining LOG_LEVEL_* macros as multiple of 10's, also same goes with LOG_MARKER_* macros. If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and division operation when printing the msgs to console. Please let me your thoughts on this. Link to this question on Phabricator - https://developer.trustedfirmware.org/T624 Thanks Sheetal

6 years, 3 months

1
0
0 0

Re: [TF-A] RPi4 and CPU hotplugging

by Soby Mathew

> > Subject: [PATCH] rpi3/4: Add support for offlining CPUs > From: Jan Kiszka <jan.kiszka(a)siemens.com> > > The hooks were populated but the power down left the CPU in limbo-land. > What we need to do - until there is a way to actually power off - is to > turn off the MMU and enter the spinning loop as if we were cold-booted. > This allows the on-call to pick up the CPU again. > > Signed-off-by: Jan Kiszka <jan.kiszka(a)siemens.com> > --- > plat/rpi/common/rpi3_pm.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/plat/rpi/common/rpi3_pm.c b/plat/rpi/common/rpi3_pm.c > index 8c2d070c4..2a6bf076b 100644 > --- a/plat/rpi/common/rpi3_pm.c > +++ b/plat/rpi/common/rpi3_pm.c > @@ -123,6 +123,15 @@ static void rpi3_pwr_domain_off(const psci_power_state_t *target_state) > #endif > } > > +void __dead2 plat_secondary_cold_boot_setup(void); > + > +static void __dead2 > +rpi3_pwr_domain_pwr_down_wfi(const psci_power_state_t *target_state) > +{ > + disable_mmu_el3(); > + plat_secondary_cold_boot_setup(); > +} > + > /******************************************************************************* > * Platform handler called when a power domain is about to be turned on. The > * mpidr determines the CPU to be turned on. > @@ -224,6 +233,7 @@ static void __dead2 rpi3_system_off(void) > static const plat_psci_ops_t plat_rpi3_psci_pm_ops = { > .cpu_standby = rpi3_cpu_standby, > .pwr_domain_off = rpi3_pwr_domain_off, > + .pwr_domain_pwr_down_wfi = rpi3_pwr_domain_pwr_down_wfi, > .pwr_domain_on = rpi3_pwr_domain_on, > .pwr_domain_on_finish = rpi3_pwr_domain_on_finish, > .system_off = rpi3_system_off, > -- > 2.16.4 > Hi Jan, I have put in a suggestion for the change. Basically, if you are able to do a `reset` before spinning in `plat_secondary_cold_boot_setup()`, that would be ideal. Also, if `plat_secondary_cold_boot_setup()` can trap the primary CPU as well if it were to be offlined, then I think your changes should be good. Best Regards Soby Mathew

6 years, 3 months

2
2
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A