- TF-A - lists.trustedfirmware.org

Trusted Firmware-A LTS v2.8.12 Release Announcement

by Varun Wadekar

Hello, Trusted Firmware-A LTS version 2.8.12 is now available. This release removes the Cryptocell driver support and contains fixes for the Tegra platform, the SMCCC library, and SDEI. The complete list of changes can be found here<https://ci-builds.trustedfirmware.org/static-files/DcqMVUzlEWpu-LYx_0-RuHeu…>. Thanks.

1 year, 5 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. 120 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 4 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 20 of 120 defect(s) ** CID 408744: (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 320 in mv_ddr4_dq_vref_calibration() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 254 in mv_ddr4_dq_vref_calibration() ________________________________________________________________________________________________________ *** CID 408744: (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 320 in mv_ddr4_dq_vref_calibration() 314 (BYTE_HOMOGENEOUS_LOW | BYTE_SPLIT_OUT_MIX)) == 315 (BYTE_HOMOGENEOUS_LOW | BYTE_SPLIT_OUT_MIX)) { 316 if ((dq_vref_start_win[if_id][subphy_num][vref_idx] + 317 dq_vref_end_win[if_id][subphy_num][vref_idx]) / 2 <= 31) { 318 dq_vref_start_win[if_id][subphy_num][vref_idx] += 64; 319 dq_vref_end_win[if_id][subphy_num][vref_idx] += 64; >>> CID 408744: (OVERRUN) >>> Overrunning array "valid_vref_ptr[if_id]" of 9 26-byte elements at element index 12 (byte offset 337) using index "subphy_num" (which evaluates to 12). 320 DEBUG_CALIBRATION 321 (DEBUG_LEVEL_TRACE, 322 ("%s vref_idx %d if %d subphy %d added 64 adlls to window\n", 323 __func__, valid_vref_ptr[if_id][subphy_num][vref_idx], 324 if_id, subphy_num)); 325 } /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 340 in mv_ddr4_dq_vref_calibration() 334 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, subphy_num); 335 DEBUG_CALIBRATION(DEBUG_LEVEL_INFO, 336 ("calculating center of mass for subphy %d, valid window size %d\n", 337 subphy_num, valid_win_size[if_id][subphy_num])); 338 if (valid_vref_cnt[if_id][subphy_num] > 0) { 339 /* calculate center of mass sampling point (t, v) for each subphy */ >>> CID 408744: (OVERRUN) >>> Overrunning array of 234 bytes at byte offset 312 by dereferencing pointer "valid_vref_ptr[if_id][subphy_num]". 340 status = mv_ddr4_center_of_mass_calc(dev_num, if_id, subphy_num, TX_DIR, 341 dq_vref_start_win[if_id][subphy_num], 342 dq_vref_end_win[if_id][subphy_num], 343 valid_vref_ptr[if_id][subphy_num], 344 valid_vref_cnt[if_id][subphy_num], 345 &center_vref[if_id][subphy_num], /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 254 in mv_ddr4_dq_vref_calibration() 248 if (vref_state_per_subphy[if_id][subphy_num] == MV_DDR4_VREF_SUBPHY_CAL_UNDER) 249 DEBUG_CALIBRATION(DEBUG_LEVEL_ERROR, 250 ("warning: %s: subphy %d vref tap %d voltage noise\n", 251 __func__, subphy_num, vref_tap_idx)); 252 /* window is valid; keep current vref_tap_idx value and increment counter */ 253 vref_idx = valid_vref_cnt[if_id][subphy_num]; >>> CID 408744: (OVERRUN) >>> Overrunning array "valid_vref_ptr[if_id]" of 9 26-byte elements at element index 12 (byte offset 337) using index "subphy_num" (which evaluates to 12). 254 valid_vref_ptr[if_id][subphy_num][vref_idx] = vref_tap_idx; 255 valid_vref_cnt[if_id][subphy_num]++; 256 257 /* set 0 for possible negative values */ 258 vref_byte_status[if_id][subphy_num][vref_idx] |= 259 patterns_byte_status[if_id][subphy_num]; ** CID 408743: Memory - illegal accesses (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 693 in mv_ddr4_centralization() ________________________________________________________________________________________________________ *** CID 408743: Memory - illegal accesses (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 693 in mv_ddr4_centralization() 687 * that we have already dealt with this bytes by adding 64 adlls 688 * to the low bytes 689 */ 690 if (patterns_byte_status[if_id][subphy_num] & 691 (BYTE_HOMOGENEOUS_LOW | BYTE_SPLIT_OUT_MIX)) 692 patterns_byte_status[if_id][subphy_num] = BYTE_SPLIT_OUT_MIX; >>> CID 408743: Memory - illegal accesses (OVERRUN) >>> Overrunning array "rx_vw_pos[if_id]" of 9 bytes at byte offset 12 using index "subphy_num" (which evaluates to 12). 693 if (rx_vw_pos[if_id][subphy_num] == 0) /* rx_vw_pos is initialized during tap tune */ 694 pbs_max = 31 - 0xa; 695 else 696 pbs_max = 31; 697 698 /* continue if locked */ ** CID 408742: Memory - illegal accesses (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 258 in mv_ddr4_dq_vref_calibration() ________________________________________________________________________________________________________ *** CID 408742: Memory - illegal accesses (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 258 in mv_ddr4_dq_vref_calibration() 252 /* window is valid; keep current vref_tap_idx value and increment counter */ 253 vref_idx = valid_vref_cnt[if_id][subphy_num]; 254 valid_vref_ptr[if_id][subphy_num][vref_idx] = vref_tap_idx; 255 valid_vref_cnt[if_id][subphy_num]++; 256 257 /* set 0 for possible negative values */ >>> CID 408742: Memory - illegal accesses (OVERRUN) >>> Overrunning array "patterns_byte_status[if_id]" of 9 bytes at byte offset 12 using index "subphy_num" (which evaluates to 12). 258 vref_byte_status[if_id][subphy_num][vref_idx] |= 259 patterns_byte_status[if_id][subphy_num]; 260 dq_vref_start_win[if_id][subphy_num][vref_idx] = 261 c_opt_per_bus[if_id][subphy_num] + 1 - 262 valid_win_size[if_id][subphy_num] / 2; 263 dq_vref_start_win[if_id][subphy_num][vref_idx] = ** CID 408741: Memory - illegal accesses (OVERRUN) /drivers/marvell/mv_ddr/drivers/snps/snps_fw.c: 428 in snps_mail_box_print_major_msg() ________________________________________________________________________________________________________ *** CID 408741: Memory - illegal accesses (OVERRUN) /drivers/marvell/mv_ddr/drivers/snps/snps_fw.c: 428 in snps_mail_box_print_major_msg() 422 * and print the required message string, according to it's message id. */ 423 static void snps_mail_box_print_major_msg(int msg_id) 424 { 425 int major_msg_count = sizeof(mb_major_messages) / sizeof(mb_major_messages[0]); 426 427 for (int i = 0; i <= major_msg_count; i++) >>> CID 408741: Memory - illegal accesses (OVERRUN) >>> Overrunning array "mb_major_messages" of 17 16-byte elements at element index 17 (byte offset 287) using index "i" (which evaluates to 17). 428 if (mb_major_messages[i].message_id == msg_id) { 429 pr_debug("%s\n", mb_major_messages[i].string); 430 return; 431 } 432 433 /* in case msg_id wasn't found in major messages database */ ** CID 408740: (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr_topology.c: 190 in mv_ddr_topology_map_update() /drivers/marvell/mv_ddr/mv_ddr_topology.c: 210 in mv_ddr_topology_map_update() ________________________________________________________________________________________________________ *** CID 408740: (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr_topology.c: 190 in mv_ddr_topology_map_update() 184 /* update bus bit mask in topology map */ 185 tm->bus_act_mask = mv_ddr_bus_bit_mask_get(); 186 187 /* update cs bit mask in topology map */ 188 val = mv_ddr_spd_cs_bit_mask_get(&tm->spd_data); 189 for (i = 0; i < octets_per_if_num; i++) >>> CID 408740: (OVERRUN) >>> Overrunning array "iface_params->as_bus_params" of 9 16-byte elements at element index 12 (byte offset 207) using index "i" (which evaluates to 12). 190 iface_params->as_bus_params[i].cs_bitmask = val; 191 192 /* check dram module type */ 193 val = mv_ddr_spd_module_type_get(&tm->spd_data); 194 switch (val) { 195 case MV_DDR_SPD_MODULE_TYPE_UDIMM: /drivers/marvell/mv_ddr/mv_ddr_topology.c: 210 in mv_ddr_topology_map_update() 204 return -1; 205 } 206 207 /* update mirror bit mask in topology map */ 208 val = mv_ddr_spd_mem_mirror_get(&tm->spd_data); 209 for (i = 0; i < octets_per_if_num; i++) >>> CID 408740: (OVERRUN) >>> Overrunning array "iface_params->as_bus_params" of 9 16-byte elements at element index 12 (byte offset 207) using index "i" (which evaluates to 12). 210 iface_params->as_bus_params[i].mirror_enable_bitmask = val << 1; 211 212 tclk = 1000000 / mv_ddr_freq_get(iface_params->memory_freq); 213 /* update cas write latency (cwl) */ 214 val = mv_ddr_cwl_calc(tclk); 215 if (val == 0) { ** CID 408739: (OVERRUN) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1614 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1617 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1602 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1463 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1580 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1488 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1611 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1414 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1475 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1608 in ddr3_tip_ip_training_wrapper() ________________________________________________________________________________________________________ *** CID 408739: (OVERRUN) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1614 in ddr3_tip_ip_training_wrapper() 1608 if (((l2h_adll_value[sybphy_id][bit_id] + 1609 h2l_adll_value[sybphy_id][bit_id]) / 2) > 1610 max_center_subphy_adll[sybphy_id]) 1611 max_center_subphy_adll[sybphy_id] = 1612 (l2h_adll_value[sybphy_id][bit_id] + 1613 h2l_adll_value[sybphy_id][bit_id]) / 2; >>> CID 408739: (OVERRUN) >>> Overrunning array "h2l_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1614 if (((l2h_adll_value[sybphy_id][bit_id] + 1615 h2l_adll_value[sybphy_id][bit_id]) / 2) < 1616 min_center_subphy_adll[sybphy_id]) 1617 min_center_subphy_adll[sybphy_id] = 1618 (l2h_adll_value[sybphy_id][bit_id] + 1619 h2l_adll_value[sybphy_id][bit_id]) / 2; /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1617 in ddr3_tip_ip_training_wrapper() 1611 max_center_subphy_adll[sybphy_id] = 1612 (l2h_adll_value[sybphy_id][bit_id] + 1613 h2l_adll_value[sybphy_id][bit_id]) / 2; 1614 if (((l2h_adll_value[sybphy_id][bit_id] + 1615 h2l_adll_value[sybphy_id][bit_id]) / 2) < 1616 min_center_subphy_adll[sybphy_id]) >>> CID 408739: (OVERRUN) >>> Overrunning array "h2l_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1617 min_center_subphy_adll[sybphy_id] = 1618 (l2h_adll_value[sybphy_id][bit_id] + 1619 h2l_adll_value[sybphy_id][bit_id]) / 2; 1620 } 1621 1622 /* calculate the center of the current subphy */ /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1602 in ddr3_tip_ip_training_wrapper() 1596 center_subphy_adll_window[sybphy_id] = 0; 1597 max_center_subphy_adll[sybphy_id] = 0; 1598 min_center_subphy_adll[sybphy_id] = 64; 1599 /* find the max and min center adll value in the current subphy */ 1600 for (bit_id = 0; bit_id < bit_end; bit_id++) { 1601 /* debug print all the bit edges after alignment */ >>> CID 408739: (OVERRUN) >>> Overrunning array "h2l_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1602 DEBUG_TRAINING_IP_ENGINE 1603 (DEBUG_LEVEL_TRACE, 1604 ("if_id %d sybphy_id %d bit %d l2h %d h2l %d\n", 1605 if_id, sybphy_id, bit_id, l2h_adll_value[sybphy_id][bit_id], 1606 h2l_adll_value[sybphy_id][bit_id])); 1607 /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1463 in ddr3_tip_ip_training_wrapper() 1457 /* low ui */ 1458 if (e1 <= 31 && e2 <= 31) { 1459 bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] = 1460 BIT_LOW_UI; 1461 byte_status[if_id][sybphy_id] |= BYTE_HOMOGENEOUS_LOW; 1462 l2h_adll_value[sybphy_id][bit_id] = e1; >>> CID 408739: (OVERRUN) >>> Overrunning array "h2l_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1463 h2l_adll_value[sybphy_id][bit_id] = e2; 1464 DEBUG_TRAINING_IP_ENGINE 1465 (DEBUG_LEVEL_TRACE, 1466 ("if_id %d sybphy_id %d bit %d BIT_LOW_UI\n", 1467 if_id, sybphy_id, bit_id)); 1468 } /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1580 in ddr3_tip_ip_training_wrapper() 1574 TRAINING_LOAD_OPERATION_UNLOAD, CS_SINGLE, 1575 &h2l_if_train_res, 0, cons_tap, 1); 1576 1577 if (MV_OK != status) 1578 return status; 1579 >>> CID 408739: (OVERRUN) >>> Overrunning array "h2l_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1580 h2l_adll_value[sybphy_id][bit_id] = 1581 h2l_if_train_res[sybphy_id * 1582 BUS_WIDTH_IN_BITS + bit_id] & PUP_RESULT_EDGE_1_MASK; 1583 } 1584 } 1585 } /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1488 in ddr3_tip_ip_training_wrapper() 1482 if (e1 <= 31 && e2 >= 32) { 1483 bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] = 1484 BIT_SPLIT_IN; 1485 byte_status[if_id][sybphy_id] |= 1486 BYTE_HOMOGENEOUS_SPLIT_IN; 1487 l2h_adll_value[sybphy_id][bit_id] = e1; >>> CID 408739: (OVERRUN) >>> Overrunning array "h2l_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1488 h2l_adll_value[sybphy_id][bit_id] = e2; 1489 DEBUG_TRAINING_IP_ENGINE 1490 (DEBUG_LEVEL_TRACE, 1491 ("if_id %d sybphy_id %d bit %d BIT_SPLIT_IN\n", 1492 if_id, sybphy_id, bit_id)); 1493 } /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1611 in ddr3_tip_ip_training_wrapper() 1605 if_id, sybphy_id, bit_id, l2h_adll_value[sybphy_id][bit_id], 1606 h2l_adll_value[sybphy_id][bit_id])); 1607 1608 if (((l2h_adll_value[sybphy_id][bit_id] + 1609 h2l_adll_value[sybphy_id][bit_id]) / 2) > 1610 max_center_subphy_adll[sybphy_id]) >>> CID 408739: (OVERRUN) >>> Overrunning array "h2l_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1611 max_center_subphy_adll[sybphy_id] = 1612 (l2h_adll_value[sybphy_id][bit_id] + 1613 h2l_adll_value[sybphy_id][bit_id]) / 2; 1614 if (((l2h_adll_value[sybphy_id][bit_id] + 1615 h2l_adll_value[sybphy_id][bit_id]) / 2) < 1616 min_center_subphy_adll[sybphy_id]) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1414 in ddr3_tip_ip_training_wrapper() 1408 bit_end = 0; 1409 1410 /* zero the data base */ 1411 bit_bit_mask[sybphy_id] = 0; 1412 byte_status[if_id][sybphy_id] = BYTE_NOT_DEFINED; 1413 for (bit_id = 0; bit_id < bit_end; bit_id++) { >>> CID 408739: (OVERRUN) >>> Overrunning array "h2l_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1414 h2l_adll_value[sybphy_id][bit_id] = 64; 1415 l2h_adll_value[sybphy_id][bit_id] = 0; 1416 for (search_dir_id = HWS_LOW2HIGH; search_dir_id <= HWS_HIGH2LOW; 1417 search_dir_id++) { 1418 status = ddr3_tip_read_training_result 1419 (dev_num, if_id, /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1475 in ddr3_tip_ip_training_wrapper() 1469 /* high ui */ 1470 if (e1 >= 32 && e2 >= 32) { 1471 bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] = 1472 BIT_HIGH_UI; 1473 byte_status[if_id][sybphy_id] |= BYTE_HOMOGENEOUS_HIGH; 1474 l2h_adll_value[sybphy_id][bit_id] = e1; >>> CID 408739: (OVERRUN) >>> Overrunning array "h2l_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1475 h2l_adll_value[sybphy_id][bit_id] = e2; 1476 DEBUG_TRAINING_IP_ENGINE 1477 (DEBUG_LEVEL_TRACE, 1478 ("if_id %d sybphy_id %d bit %d BIT_HIGH_UI\n", 1479 if_id, sybphy_id, bit_id)); 1480 } /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1608 in ddr3_tip_ip_training_wrapper() 1602 DEBUG_TRAINING_IP_ENGINE 1603 (DEBUG_LEVEL_TRACE, 1604 ("if_id %d sybphy_id %d bit %d l2h %d h2l %d\n", 1605 if_id, sybphy_id, bit_id, l2h_adll_value[sybphy_id][bit_id], 1606 h2l_adll_value[sybphy_id][bit_id])); 1607 >>> CID 408739: (OVERRUN) >>> Overrunning array "h2l_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1608 if (((l2h_adll_value[sybphy_id][bit_id] + 1609 h2l_adll_value[sybphy_id][bit_id]) / 2) > 1610 max_center_subphy_adll[sybphy_id]) 1611 max_center_subphy_adll[sybphy_id] = 1612 (l2h_adll_value[sybphy_id][bit_id] + 1613 h2l_adll_value[sybphy_id][bit_id]) / 2; ** CID 408738: (OVERRUN) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1617 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1462 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1614 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1611 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1602 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1474 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1608 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1544 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1487 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1415 in ddr3_tip_ip_training_wrapper() ________________________________________________________________________________________________________ *** CID 408738: (OVERRUN) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1617 in ddr3_tip_ip_training_wrapper() 1611 max_center_subphy_adll[sybphy_id] = 1612 (l2h_adll_value[sybphy_id][bit_id] + 1613 h2l_adll_value[sybphy_id][bit_id]) / 2; 1614 if (((l2h_adll_value[sybphy_id][bit_id] + 1615 h2l_adll_value[sybphy_id][bit_id]) / 2) < 1616 min_center_subphy_adll[sybphy_id]) >>> CID 408738: (OVERRUN) >>> Overrunning array "l2h_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1617 min_center_subphy_adll[sybphy_id] = 1618 (l2h_adll_value[sybphy_id][bit_id] + 1619 h2l_adll_value[sybphy_id][bit_id]) / 2; 1620 } 1621 1622 /* calculate the center of the current subphy */ /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1462 in ddr3_tip_ip_training_wrapper() 1456 } else { 1457 /* low ui */ 1458 if (e1 <= 31 && e2 <= 31) { 1459 bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] = 1460 BIT_LOW_UI; 1461 byte_status[if_id][sybphy_id] |= BYTE_HOMOGENEOUS_LOW; >>> CID 408738: (OVERRUN) >>> Overrunning array "l2h_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1462 l2h_adll_value[sybphy_id][bit_id] = e1; 1463 h2l_adll_value[sybphy_id][bit_id] = e2; 1464 DEBUG_TRAINING_IP_ENGINE 1465 (DEBUG_LEVEL_TRACE, 1466 ("if_id %d sybphy_id %d bit %d BIT_LOW_UI\n", 1467 if_id, sybphy_id, bit_id)); /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1614 in ddr3_tip_ip_training_wrapper() 1608 if (((l2h_adll_value[sybphy_id][bit_id] + 1609 h2l_adll_value[sybphy_id][bit_id]) / 2) > 1610 max_center_subphy_adll[sybphy_id]) 1611 max_center_subphy_adll[sybphy_id] = 1612 (l2h_adll_value[sybphy_id][bit_id] + 1613 h2l_adll_value[sybphy_id][bit_id]) / 2; >>> CID 408738: (OVERRUN) >>> Overrunning array "l2h_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1614 if (((l2h_adll_value[sybphy_id][bit_id] + 1615 h2l_adll_value[sybphy_id][bit_id]) / 2) < 1616 min_center_subphy_adll[sybphy_id]) 1617 min_center_subphy_adll[sybphy_id] = 1618 (l2h_adll_value[sybphy_id][bit_id] + 1619 h2l_adll_value[sybphy_id][bit_id]) / 2; /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1611 in ddr3_tip_ip_training_wrapper() 1605 if_id, sybphy_id, bit_id, l2h_adll_value[sybphy_id][bit_id], 1606 h2l_adll_value[sybphy_id][bit_id])); 1607 1608 if (((l2h_adll_value[sybphy_id][bit_id] + 1609 h2l_adll_value[sybphy_id][bit_id]) / 2) > 1610 max_center_subphy_adll[sybphy_id]) >>> CID 408738: (OVERRUN) >>> Overrunning array "l2h_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1611 max_center_subphy_adll[sybphy_id] = 1612 (l2h_adll_value[sybphy_id][bit_id] + 1613 h2l_adll_value[sybphy_id][bit_id]) / 2; 1614 if (((l2h_adll_value[sybphy_id][bit_id] + 1615 h2l_adll_value[sybphy_id][bit_id]) / 2) < 1616 min_center_subphy_adll[sybphy_id]) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1602 in ddr3_tip_ip_training_wrapper() 1596 center_subphy_adll_window[sybphy_id] = 0; 1597 max_center_subphy_adll[sybphy_id] = 0; 1598 min_center_subphy_adll[sybphy_id] = 64; 1599 /* find the max and min center adll value in the current subphy */ 1600 for (bit_id = 0; bit_id < bit_end; bit_id++) { 1601 /* debug print all the bit edges after alignment */ >>> CID 408738: (OVERRUN) >>> Overrunning array "l2h_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1602 DEBUG_TRAINING_IP_ENGINE 1603 (DEBUG_LEVEL_TRACE, 1604 ("if_id %d sybphy_id %d bit %d l2h %d h2l %d\n", 1605 if_id, sybphy_id, bit_id, l2h_adll_value[sybphy_id][bit_id], 1606 h2l_adll_value[sybphy_id][bit_id])); 1607 /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1474 in ddr3_tip_ip_training_wrapper() 1468 } 1469 /* high ui */ 1470 if (e1 >= 32 && e2 >= 32) { 1471 bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] = 1472 BIT_HIGH_UI; 1473 byte_status[if_id][sybphy_id] |= BYTE_HOMOGENEOUS_HIGH; >>> CID 408738: (OVERRUN) >>> Overrunning array "l2h_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1474 l2h_adll_value[sybphy_id][bit_id] = e1; 1475 h2l_adll_value[sybphy_id][bit_id] = e2; 1476 DEBUG_TRAINING_IP_ENGINE 1477 (DEBUG_LEVEL_TRACE, 1478 ("if_id %d sybphy_id %d bit %d BIT_HIGH_UI\n", 1479 if_id, sybphy_id, bit_id)); /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1608 in ddr3_tip_ip_training_wrapper() 1602 DEBUG_TRAINING_IP_ENGINE 1603 (DEBUG_LEVEL_TRACE, 1604 ("if_id %d sybphy_id %d bit %d l2h %d h2l %d\n", 1605 if_id, sybphy_id, bit_id, l2h_adll_value[sybphy_id][bit_id], 1606 h2l_adll_value[sybphy_id][bit_id])); 1607 >>> CID 408738: (OVERRUN) >>> Overrunning array "l2h_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1608 if (((l2h_adll_value[sybphy_id][bit_id] + 1609 h2l_adll_value[sybphy_id][bit_id]) / 2) > 1610 max_center_subphy_adll[sybphy_id]) 1611 max_center_subphy_adll[sybphy_id] = 1612 (l2h_adll_value[sybphy_id][bit_id] + 1613 h2l_adll_value[sybphy_id][bit_id]) / 2; /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1544 in ddr3_tip_ip_training_wrapper() 1538 TRAINING_LOAD_OPERATION_UNLOAD, CS_SINGLE, 1539 &l2h_if_train_res, 0, 0, 1); 1540 1541 if (MV_OK != status) 1542 return status; 1543 >>> CID 408738: (OVERRUN) >>> Overrunning array "l2h_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1544 l2h_adll_value[sybphy_id][bit_id] = 1545 l2h_if_train_res[sybphy_id * 1546 BUS_WIDTH_IN_BITS + bit_id] & PUP_RESULT_EDGE_1_MASK; 1547 } 1548 } 1549 } /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1487 in ddr3_tip_ip_training_wrapper() 1481 /* split in */ 1482 if (e1 <= 31 && e2 >= 32) { 1483 bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] = 1484 BIT_SPLIT_IN; 1485 byte_status[if_id][sybphy_id] |= 1486 BYTE_HOMOGENEOUS_SPLIT_IN; >>> CID 408738: (OVERRUN) >>> Overrunning array "l2h_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1487 l2h_adll_value[sybphy_id][bit_id] = e1; 1488 h2l_adll_value[sybphy_id][bit_id] = e2; 1489 DEBUG_TRAINING_IP_ENGINE 1490 (DEBUG_LEVEL_TRACE, 1491 ("if_id %d sybphy_id %d bit %d BIT_SPLIT_IN\n", 1492 if_id, sybphy_id, bit_id)); /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1415 in ddr3_tip_ip_training_wrapper() 1409 1410 /* zero the data base */ 1411 bit_bit_mask[sybphy_id] = 0; 1412 byte_status[if_id][sybphy_id] = BYTE_NOT_DEFINED; 1413 for (bit_id = 0; bit_id < bit_end; bit_id++) { 1414 h2l_adll_value[sybphy_id][bit_id] = 64; >>> CID 408738: (OVERRUN) >>> Overrunning array "l2h_adll_value" of 9 8-byte elements at element index 12 (byte offset 103) using index "sybphy_id" (which evaluates to 12). 1415 l2h_adll_value[sybphy_id][bit_id] = 0; 1416 for (search_dir_id = HWS_LOW2HIGH; search_dir_id <= HWS_HIGH2LOW; 1417 search_dir_id++) { 1418 status = ddr3_tip_read_training_result 1419 (dev_num, if_id, 1420 ACCESS_TYPE_UNICAST, sybphy_id, bit_id, ** CID 408737: Memory - illegal accesses (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 396 in mv_ddr4_dq_vref_calibration() ________________________________________________________________________________________________________ *** CID 408737: Memory - illegal accesses (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 396 in mv_ddr4_dq_vref_calibration() 390 for (subphy_num = 0; subphy_num < subphy_max; subphy_num++) { 391 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, subphy_num); 392 for (dq_idx = 0; dq_idx < 8; dq_idx++) { 393 pad_num = dq_map_table[dq_idx + 394 subphy_num * BUS_WIDTH_IN_BITS + 395 if_id * BUS_WIDTH_IN_BITS * subphy_max]; >>> CID 408737: Memory - illegal accesses (OVERRUN) >>> Overrunning array "pbs_res_per_bus[if_id]" of 9 8-byte elements at element index 12 (byte offset 103) using index "subphy_num" (which evaluates to 12). 396 status = ddr3_tip_bus_write(dev_num, ACCESS_TYPE_UNICAST, if_id, ACCESS_TYPE_UNICAST, 397 subphy_num, DDR_PHY_DATA, 398 0x10 + pad_num + effective_cs * 0x10, 399 pbs_res_per_bus[if_id][subphy_num][dq_idx]); 400 if (status != MV_OK) 401 return status; ** CID 408736: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 408736: Memory - corruptions (OVERRUN) /drivers/marvell/mv_ddr/apn806/mv_ddr_plat.c: 586 in mv_ddr_clk_dividers_set() 580 if_id)); 581 return -1; 582 } 583 584 if (mv_ddr_first_time_setting) { 585 /* get ddr init freq */ >>> CID 408736: Memory - corruptions (OVERRUN) >>> Overrunning callee's array of size 13 by passing argument "mv_ddr_init_freq_get()" (which evaluates to 14) in call to "mv_ddr_freq_get". 586 init_ddr_freq_val = mv_ddr_freq_get(mv_ddr_init_freq_get()); 587 588 /* get mc & ddr clk dividers values */ 589 reg = reg_read(DEV_GEN_CTRL1_REG_ADDR); 590 ddr_div = (reg >> MISC_CLKDIV_RATIO_1_OFFS) & MISC_CLKDIV_RATIO_1_MASK; 591 ** CID 408735: Data race undermines locking (LOCK_EVASION) /plat/mediatek/drivers/cpu_pm/cpcv3_2/mt_cpu_pm.c: 410 in cpupm_pwr_state_valid() ________________________________________________________________________________________________________ *** CID 408735: Data race undermines locking (LOCK_EVASION) /plat/mediatek/drivers/cpu_pm/cpcv3_2/mt_cpu_pm.c: 410 in cpupm_pwr_state_valid() 404 if (cpupm_init() != MTK_CPUPM_E_OK) { 405 return MTK_CPUPM_E_FAIL; 406 } 407 408 if (read_cntpct_el0() >= (uint64_t)CPUPM_BOOTUP_TIME_THR) { 409 plat_cpu_pm_lock(); >>> CID 408735: Data race undermines locking (LOCK_EVASION) >>> Thread1 sets "cpu_pm_status" to a new value. Now the two threads have an inconsistent view of "cpu_pm_status" and updates to fields correlated with "cpu_pm_status" may be lost. 410 cpu_pm_status |= CPU_PM_PLAT_READY; 411 plat_cpu_pm_unlock(); 412 } 413 414 if (!IS_PLAT_SYSTEM_SUSPEND(afflv) && (cpu_pm_status & CPU_PM_PLAT_READY) == 0) { 415 return MTK_CPUPM_E_FAIL; ** CID 408734: Memory - corruptions (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 1285 in mv_ddr4_tap_tuning() ________________________________________________________________________________________________________ *** CID 408734: Memory - corruptions (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 1285 in mv_ddr4_tap_tuning() 1279 pattern, EDGE_FPF, CS_SINGLE, PARAM_NOT_CARE, training_result); 1280 1281 for (iface = 0; iface < MAX_INTERFACE_NUM; iface++) { 1282 VALIDATE_IF_ACTIVE(tm->if_act_mask, iface); 1283 for (subphy = 0; subphy < subphy_max; subphy++) { 1284 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, subphy); >>> CID 408734: Memory - corruptions (OVERRUN) >>> Overrunning array "rx_vw_pos[iface]" of 9 bytes at byte offset 12 using index "subphy" (which evaluates to 12). 1285 rx_vw_pos[iface][subphy] = ALIGN_CENTER; 1286 new_pbs_per_byte[subphy] = new_pbs; /* rx init */ 1287 if ((mode == TX_DIR) && (loop == 0)) { 1288 /* read nominal wl */ 1289 ddr3_tip_bus_read(dev, iface, ACCESS_TYPE_UNICAST, subphy, 1290 DDR_PHY_DATA, WL_PHY_REG(effective_cs), ** CID 408733: (OVERRUN) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1598 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1623 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1626 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1617 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1614 in ddr3_tip_ip_training_wrapper() ________________________________________________________________________________________________________ *** CID 408733: (OVERRUN) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1598 in ddr3_tip_ip_training_wrapper() 1592 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, sybphy_id); 1593 1594 if ((byte_status[if_id][sybphy_id] != BYTE_NOT_DEFINED) && (direction == OPER_WRITE)) { 1595 /* clear the arrays and parameters */ 1596 center_subphy_adll_window[sybphy_id] = 0; 1597 max_center_subphy_adll[sybphy_id] = 0; >>> CID 408733: (OVERRUN) >>> Overrunning array "min_center_subphy_adll" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1598 min_center_subphy_adll[sybphy_id] = 64; 1599 /* find the max and min center adll value in the current subphy */ 1600 for (bit_id = 0; bit_id < bit_end; bit_id++) { 1601 /* debug print all the bit edges after alignment */ 1602 DEBUG_TRAINING_IP_ENGINE 1603 (DEBUG_LEVEL_TRACE, /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1623 in ddr3_tip_ip_training_wrapper() 1617 min_center_subphy_adll[sybphy_id] = 1618 (l2h_adll_value[sybphy_id][bit_id] + 1619 h2l_adll_value[sybphy_id][bit_id]) / 2; 1620 } 1621 1622 /* calculate the center of the current subphy */ >>> CID 408733: (OVERRUN) >>> Overrunning array "min_center_subphy_adll" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1623 center_subphy_adll_window[sybphy_id] = 1624 max_center_subphy_adll[sybphy_id] - 1625 min_center_subphy_adll[sybphy_id]; 1626 DEBUG_TRAINING_IP_ENGINE 1627 (DEBUG_LEVEL_TRACE, 1628 ("if_id %d sybphy_id %d min center %d max center %d center %d\n", /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1626 in ddr3_tip_ip_training_wrapper() 1620 } 1621 1622 /* calculate the center of the current subphy */ 1623 center_subphy_adll_window[sybphy_id] = 1624 max_center_subphy_adll[sybphy_id] - 1625 min_center_subphy_adll[sybphy_id]; >>> CID 408733: (OVERRUN) >>> Overrunning array "min_center_subphy_adll" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1626 DEBUG_TRAINING_IP_ENGINE 1627 (DEBUG_LEVEL_TRACE, 1628 ("if_id %d sybphy_id %d min center %d max center %d center %d\n", 1629 if_id, sybphy_id, min_center_subphy_adll[sybphy_id], 1630 max_center_subphy_adll[sybphy_id], 1631 center_subphy_adll_window[sybphy_id])); /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1617 in ddr3_tip_ip_training_wrapper() 1611 max_center_subphy_adll[sybphy_id] = 1612 (l2h_adll_value[sybphy_id][bit_id] + 1613 h2l_adll_value[sybphy_id][bit_id]) / 2; 1614 if (((l2h_adll_value[sybphy_id][bit_id] + 1615 h2l_adll_value[sybphy_id][bit_id]) / 2) < 1616 min_center_subphy_adll[sybphy_id]) >>> CID 408733: (OVERRUN) >>> Overrunning array "min_center_subphy_adll" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1617 min_center_subphy_adll[sybphy_id] = 1618 (l2h_adll_value[sybphy_id][bit_id] + 1619 h2l_adll_value[sybphy_id][bit_id]) / 2; 1620 } 1621 1622 /* calculate the center of the current subphy */ /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1614 in ddr3_tip_ip_training_wrapper() 1608 if (((l2h_adll_value[sybphy_id][bit_id] + 1609 h2l_adll_value[sybphy_id][bit_id]) / 2) > 1610 max_center_subphy_adll[sybphy_id]) 1611 max_center_subphy_adll[sybphy_id] = 1612 (l2h_adll_value[sybphy_id][bit_id] + 1613 h2l_adll_value[sybphy_id][bit_id]) / 2; >>> CID 408733: (OVERRUN) >>> Overrunning array "min_center_subphy_adll" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1614 if (((l2h_adll_value[sybphy_id][bit_id] + 1615 h2l_adll_value[sybphy_id][bit_id]) / 2) < 1616 min_center_subphy_adll[sybphy_id]) 1617 min_center_subphy_adll[sybphy_id] = 1618 (l2h_adll_value[sybphy_id][bit_id] + 1619 h2l_adll_value[sybphy_id][bit_id]) / 2; ** CID 408732: (OVERRUN) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1654 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1461 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1563 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1662 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1526 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1485 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1664 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1641 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1503 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1473 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1448 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1412 in ddr3_tip_ip_training_wrapper() /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1594 in ddr3_tip_ip_training_wrapper() ________________________________________________________________________________________________________ *** CID 408732: (OVERRUN) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1654 in ddr3_tip_ip_training_wrapper() 1648 /* 1649 * in case all of the bits in the current subphy are 1650 * less than 32 which will find alignment in the subphy bits 1651 * mark this subphy as homogeneous split in 1652 */ 1653 if (center_subphy_adll_window[sybphy_id] <= 31) >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1654 byte_status[if_id][sybphy_id] = BYTE_HOMOGENEOUS_SPLIT_IN; 1655 1656 /* 1657 * in case the current byte is split_out and the center is bigger than 31 1658 * the byte can be aligned. in this case add 64 to the the low ui bits aligning it 1659 * to the other ui bits /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1461 in ddr3_tip_ip_training_wrapper() 1455 if_id, sybphy_id, bit_id)); 1456 } else { 1457 /* low ui */ 1458 if (e1 <= 31 && e2 <= 31) { 1459 bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] = 1460 BIT_LOW_UI; >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1461 byte_status[if_id][sybphy_id] |= BYTE_HOMOGENEOUS_LOW; 1462 l2h_adll_value[sybphy_id][bit_id] = e1; 1463 h2l_adll_value[sybphy_id][bit_id] = e2; 1464 DEBUG_TRAINING_IP_ENGINE 1465 (DEBUG_LEVEL_TRACE, 1466 ("if_id %d sybphy_id %d bit %d BIT_LOW_UI\n", /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1563 in ddr3_tip_ip_training_wrapper() 1557 num_iter / 2, num_iter / 2, 1558 pattern, EDGE_FP, train_cs_type, 1559 cs_num, train_status); 1560 1561 for (sybphy_id = 0; sybphy_id < octets_per_if_num; sybphy_id++) { 1562 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, sybphy_id); >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1563 if (byte_status[if_id][sybphy_id] != BYTE_NOT_DEFINED) { 1564 if (bit_bit_mask[sybphy_id] == 0) 1565 continue; 1566 1567 for (bit_id = 0; bit_id < bit_end; bit_id++) { 1568 if ((bit_bit_mask[sybphy_id] & (1 << bit_id)) == 0) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1662 in ddr3_tip_ip_training_wrapper() 1656 /* 1657 * in case the current byte is split_out and the center is bigger than 31 1658 * the byte can be aligned. in this case add 64 to the the low ui bits aligning it 1659 * to the other ui bits 1660 */ 1661 if (center_subphy_adll_window[sybphy_id] >= 32) { >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1662 byte_status[if_id][sybphy_id] = BYTE_SPLIT_OUT_MIX; 1663 1664 DEBUG_TRAINING_IP_ENGINE 1665 (DEBUG_LEVEL_TRACE, 1666 ("if_id %d sybphy_id %d byte state 0x%x\n", 1667 if_id, sybphy_id, byte_status[if_id][sybphy_id])); /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1526 in ddr3_tip_ip_training_wrapper() 1520 num_iter / 2, num_iter / 2, 1521 pattern, EDGE_FP, train_cs_type, 1522 cs_num, train_status); 1523 1524 for (sybphy_id = 0; sybphy_id < octets_per_if_num; sybphy_id++) { 1525 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, sybphy_id); >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1526 if (byte_status[if_id][sybphy_id] != BYTE_NOT_DEFINED) { 1527 if (bit_bit_mask[sybphy_id] == 0) 1528 continue; /* this byte bits have no split out state */ 1529 1530 for (bit_id = 0; bit_id < bit_end; bit_id++) { 1531 if ((bit_bit_mask[sybphy_id] & (1 << bit_id)) == 0) /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1485 in ddr3_tip_ip_training_wrapper() 1479 if_id, sybphy_id, bit_id)); 1480 } 1481 /* split in */ 1482 if (e1 <= 31 && e2 >= 32) { 1483 bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] = 1484 BIT_SPLIT_IN; >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1485 byte_status[if_id][sybphy_id] |= 1486 BYTE_HOMOGENEOUS_SPLIT_IN; 1487 l2h_adll_value[sybphy_id][bit_id] = e1; 1488 h2l_adll_value[sybphy_id][bit_id] = e2; 1489 DEBUG_TRAINING_IP_ENGINE 1490 (DEBUG_LEVEL_TRACE, /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1664 in ddr3_tip_ip_training_wrapper() 1658 * the byte can be aligned. in this case add 64 to the the low ui bits aligning it 1659 * to the other ui bits 1660 */ 1661 if (center_subphy_adll_window[sybphy_id] >= 32) { 1662 byte_status[if_id][sybphy_id] = BYTE_SPLIT_OUT_MIX; 1663 >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1664 DEBUG_TRAINING_IP_ENGINE 1665 (DEBUG_LEVEL_TRACE, 1666 ("if_id %d sybphy_id %d byte state 0x%x\n", 1667 if_id, sybphy_id, byte_status[if_id][sybphy_id])); 1668 for (bit_id = 0; bit_id < bit_end; bit_id++) { 1669 if (bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] == BIT_LOW_UI) { /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1641 in ddr3_tip_ip_training_wrapper() 1635 * check byte state and fix bits state if needed 1636 * in case the level 1 and 2 above subphy results are 1637 * homogeneous continue to the next subphy 1638 */ 1639 for (sybphy_id = 0; sybphy_id < octets_per_if_num; sybphy_id++) { 1640 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, sybphy_id); >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1641 if ((byte_status[if_id][sybphy_id] == BYTE_HOMOGENEOUS_LOW) || 1642 (byte_status[if_id][sybphy_id] == BYTE_HOMOGENEOUS_HIGH) || 1643 (byte_status[if_id][sybphy_id] == BYTE_HOMOGENEOUS_SPLIT_IN) || 1644 (byte_status[if_id][sybphy_id] == BYTE_HOMOGENEOUS_SPLIT_OUT) || 1645 (byte_status[if_id][sybphy_id] == BYTE_NOT_DEFINED)) 1646 continue; /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1503 in ddr3_tip_ip_training_wrapper() 1497 (DEBUG_LEVEL_INFO, 1498 ("if_id %d sybphy_id %d bit %d l2h 0x%x (e1 0x%x)" 1499 "h2l 0x%x (e2 0x%x): bit cannot be categorized\n", 1500 if_id, sybphy_id, bit_id, result[HWS_LOW2HIGH][0], e1, 1501 result[HWS_HIGH2LOW][0], e2)); 1502 /* mark the byte as not defined */ >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1503 byte_status[if_id][sybphy_id] = BYTE_NOT_DEFINED; 1504 break; /* continue to next pup - no reason to analyze this byte */ 1505 } 1506 } /* for all bits */ 1507 } /* for all PUPs */ 1508 /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1473 in ddr3_tip_ip_training_wrapper() 1467 if_id, sybphy_id, bit_id)); 1468 } 1469 /* high ui */ 1470 if (e1 >= 32 && e2 >= 32) { 1471 bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] = 1472 BIT_HIGH_UI; >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1473 byte_status[if_id][sybphy_id] |= BYTE_HOMOGENEOUS_HIGH; 1474 l2h_adll_value[sybphy_id][bit_id] = e1; 1475 h2l_adll_value[sybphy_id][bit_id] = e2; 1476 DEBUG_TRAINING_IP_ENGINE 1477 (DEBUG_LEVEL_TRACE, 1478 ("if_id %d sybphy_id %d bit %d BIT_HIGH_UI\n", /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1448 in ddr3_tip_ip_training_wrapper() 1442 if (direction == OPER_READ) { 1443 byte_status[if_id][sybphy_id] |= BYTE_HOMOGENEOUS_LOW; 1444 } else if ((e2 - e1) > 32) { /* oper_write */ 1445 /* split out */ 1446 bit_state[sybphy_id * BUS_WIDTH_IN_BITS + bit_id] = 1447 BIT_SPLIT_OUT; >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1448 byte_status[if_id][sybphy_id] |= BYTE_HOMOGENEOUS_SPLIT_OUT; 1449 /* mark problem bits */ 1450 bit_bit_mask[sybphy_id] |= (1 << bit_id); 1451 bit_bit_mask_active = 1; 1452 DEBUG_TRAINING_IP_ENGINE 1453 (DEBUG_LEVEL_TRACE, /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1412 in ddr3_tip_ip_training_wrapper() 1406 bit_end = BUS_WIDTH_IN_BITS; 1407 else 1408 bit_end = 0; 1409 1410 /* zero the data base */ 1411 bit_bit_mask[sybphy_id] = 0; >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1412 byte_status[if_id][sybphy_id] = BYTE_NOT_DEFINED; 1413 for (bit_id = 0; bit_id < bit_end; bit_id++) { 1414 h2l_adll_value[sybphy_id][bit_id] = 64; 1415 l2h_adll_value[sybphy_id][bit_id] = 0; 1416 for (search_dir_id = HWS_LOW2HIGH; search_dir_id <= HWS_HIGH2LOW; 1417 search_dir_id++) { /drivers/marvell/mv_ddr/ddr3_training_ip_engine.c: 1594 in ddr3_tip_ip_training_wrapper() 1588 * phase 3 will occur only in write operation 1589 * find the maximum and the minimum center of each subphy 1590 */ 1591 for (sybphy_id = 0; sybphy_id < octets_per_if_num; sybphy_id++) { 1592 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, sybphy_id); 1593 >>> CID 408732: (OVERRUN) >>> Overrunning array "byte_status[if_id]" of 9 bytes at byte offset 12 using index "sybphy_id" (which evaluates to 12). 1594 if ((byte_status[if_id][sybphy_id] != BYTE_NOT_DEFINED) && (direction == OPER_WRITE)) { 1595 /* clear the arrays and parameters */ 1596 center_subphy_adll_window[sybphy_id] = 0; 1597 max_center_subphy_adll[sybphy_id] = 0; 1598 min_center_subphy_adll[sybphy_id] = 64; 1599 /* find the max and min center adll value in the current subphy */ ** CID 408731: Uninitialized variables (UNINIT) ________________________________________________________________________________________________________ *** CID 408731: Uninitialized variables (UNINIT) /drivers/marvell/mv_ddr/ddr3_training_leveling.c: 777 in ddr3_tip_dynamic_per_bit_read_leveling() 771 for (if_id = 0; if_id <= MAX_INTERFACE_NUM - 1; if_id++) { 772 VALIDATE_IF_ACTIVE(tm->if_act_mask, if_id); 773 for (bus_num = 0; bus_num < octets_per_if_num; 774 bus_num++) { 775 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, bus_num); 776 if (per_bit_rl_pup_status[if_id][bus_num] == 1) >>> CID 408731: Uninitialized variables (UNINIT) >>> Using uninitialized value "data2_write[if_id][bus_num]" when calling "ddr3_tip_bus_write". 777 ddr3_tip_bus_write(dev_num, 778 ACCESS_TYPE_UNICAST, 779 if_id, 780 ACCESS_TYPE_UNICAST, 781 bus_num, DDR_PHY_DATA, 782 RL_PHY_REG(effective_cs), ** CID 408730: (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_mpr_pda_if.c: 516 in mv_ddr4_dq_pins_mapping() /drivers/marvell/mv_ddr/mv_ddr4_mpr_pda_if.c: 508 in mv_ddr4_dq_pins_mapping() ________________________________________________________________________________________________________ *** CID 408730: (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_mpr_pda_if.c: 516 in mv_ddr4_dq_pins_mapping() 510 } 511 512 /* stage 3: map dram dq to mc dq and update database */ 513 for (subphy_num = 0; subphy_num < subphy_max; subphy_num++) { 514 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, subphy_num); 515 for (dq_num = 0; dq_num < BUS_WIDTH_IN_BITS; dq_num++) >>> CID 408730: (OVERRUN) >>> Overrunning array "dq_val" of 9 8-byte elements at element index 11 (byte offset 95) using index "subphy_num" (which evaluates to 11). 516 dram_to_mc_dq_map[subphy_num][7 - dq_val[subphy_num][dq_num]] = dq_num; 517 } 518 519 /* set dq_map_enable */ 520 dq_map_enable = 1; 521 /drivers/marvell/mv_ddr/mv_ddr4_mpr_pda_if.c: 508 in mv_ddr4_dq_pins_mapping() 502 /* extract pattern for each subphy */ 503 for (mpr_type = 0; mpr_type < MV_DDR4_MPR_READ_PATTERN_NUM; mpr_type++) 504 subphy_pattern[mpr_type] = ((mpr_pattern[mpr_type][2] >> (subphy_num * 8)) & 0xff); 505 506 for (dq_num = 0; dq_num < BUS_WIDTH_IN_BITS; dq_num++) 507 for (mpr_type = 0; mpr_type < MV_DDR4_MPR_READ_PATTERN_NUM; mpr_type++) >>> CID 408730: (OVERRUN) >>> Overrunning array "dq_val" of 9 8-byte elements at element index 11 (byte offset 95) using index "subphy_num" (which evaluates to 11). 508 dq_val[subphy_num][dq_num] += (((subphy_pattern[mpr_type] >> dq_num) & 1) * 509 (1 << mpr_type)); 510 } 511 512 /* stage 3: map dram dq to mc dq and update database */ 513 for (subphy_num = 0; subphy_num < subphy_max; subphy_num++) { ** CID 408729: (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2228 in mv_ddr4_dm_tuning() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2225 in mv_ddr4_dm_tuning() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2222 in mv_ddr4_dm_tuning() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2200 in mv_ddr4_dm_tuning() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2223 in mv_ddr4_dm_tuning() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2205 in mv_ddr4_dm_tuning() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2226 in mv_ddr4_dm_tuning() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2229 in mv_ddr4_dm_tuning() ________________________________________________________________________________________________________ *** CID 408729: (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2228 in mv_ddr4_dm_tuning() 2222 result[subphy][HWS_LOW2HIGH][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; 2223 result[subphy][HWS_HIGH2LOW][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; 2224 2225 if (result[subphy][HWS_LOW2HIGH][bit] > vw_sphy_lo_lmt[subphy]) 2226 vw_sphy_lo_lmt[subphy] = result[subphy][HWS_LOW2HIGH][bit]; 2227 >>> CID 408729: (OVERRUN) >>> Overrunning array "result" of 9 16-byte elements at element index 12 (byte offset 207) using index "subphy" (which evaluates to 12). 2228 if (result[subphy][HWS_HIGH2LOW][bit] < vw_sphy_hi_lmt[subphy]) 2229 vw_sphy_hi_lmt[subphy] = result[subphy][HWS_HIGH2LOW][bit]; 2230 } 2231 2232 DEBUG_DM_TUNING(DEBUG_LEVEL_INFO, 2233 ("loop %d, dm subphy %d, vw %d, %d\n", loop, subphy, /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2225 in mv_ddr4_dm_tuning() 2219 continue; 2220 2221 for (bit = 0; bit < BUS_WIDTH_IN_BITS; bit++) { 2222 result[subphy][HWS_LOW2HIGH][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; 2223 result[subphy][HWS_HIGH2LOW][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; 2224 >>> CID 408729: (OVERRUN) >>> Overrunning array "result" of 9 16-byte elements at element index 12 (byte offset 207) using index "subphy" (which evaluates to 12). 2225 if (result[subphy][HWS_LOW2HIGH][bit] > vw_sphy_lo_lmt[subphy]) 2226 vw_sphy_lo_lmt[subphy] = result[subphy][HWS_LOW2HIGH][bit]; 2227 2228 if (result[subphy][HWS_HIGH2LOW][bit] < vw_sphy_hi_lmt[subphy]) 2229 vw_sphy_hi_lmt[subphy] = result[subphy][HWS_HIGH2LOW][bit]; 2230 } /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2222 in mv_ddr4_dm_tuning() 2216 } 2217 2218 if (dm_status[subphy] == LOCKED) 2219 continue; 2220 2221 for (bit = 0; bit < BUS_WIDTH_IN_BITS; bit++) { >>> CID 408729: (OVERRUN) >>> Overrunning array "result" of 9 16-byte elements at element index 12 (byte offset 207) using index "subphy" (which evaluates to 12). 2222 result[subphy][HWS_LOW2HIGH][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; 2223 result[subphy][HWS_HIGH2LOW][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; 2224 2225 if (result[subphy][HWS_LOW2HIGH][bit] > vw_sphy_lo_lmt[subphy]) 2226 vw_sphy_lo_lmt[subphy] = result[subphy][HWS_LOW2HIGH][bit]; 2227 /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2200 in mv_ddr4_dm_tuning() 2194 for (subphy = 0; subphy < subphy_max; subphy++) { 2195 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, subphy); 2196 ddr3_tip_bus_write(0, ACCESS_TYPE_UNICAST, 0, ACCESS_TYPE_UNICAST, subphy, DDR_PHY_DATA, 2197 CTX_PHY_REG(cs), ctx_vector[subphy]); 2198 2199 for (search_dir = HWS_LOW2HIGH; search_dir <= HWS_HIGH2LOW; search_dir++) { >>> CID 408729: (OVERRUN) >>> "&result[subphy][search_dir]" evaluates to an address that is at byte offset 192 of an array of 144 bytes. 2200 ddr3_tip_read_training_result(0, 0, ACCESS_TYPE_UNICAST, subphy, 2201 ALL_BITS_PER_PUP, search_dir, dir, result_type, 2202 TRAINING_LOAD_OPERATION_UNLOAD, CS_SINGLE, 2203 &(result[subphy][search_dir]), 2204 1, 0, 0); 2205 DEBUG_DM_TUNING(DEBUG_LEVEL_INFO, /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2223 in mv_ddr4_dm_tuning() 2217 2218 if (dm_status[subphy] == LOCKED) 2219 continue; 2220 2221 for (bit = 0; bit < BUS_WIDTH_IN_BITS; bit++) { 2222 result[subphy][HWS_LOW2HIGH][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; >>> CID 408729: (OVERRUN) >>> Overrunning array "result" of 9 16-byte elements at element index 12 (byte offset 207) using index "subphy" (which evaluates to 12). 2223 result[subphy][HWS_HIGH2LOW][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; 2224 2225 if (result[subphy][HWS_LOW2HIGH][bit] > vw_sphy_lo_lmt[subphy]) 2226 vw_sphy_lo_lmt[subphy] = result[subphy][HWS_LOW2HIGH][bit]; 2227 2228 if (result[subphy][HWS_HIGH2LOW][bit] < vw_sphy_hi_lmt[subphy]) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2205 in mv_ddr4_dm_tuning() 2199 for (search_dir = HWS_LOW2HIGH; search_dir <= HWS_HIGH2LOW; search_dir++) { 2200 ddr3_tip_read_training_result(0, 0, ACCESS_TYPE_UNICAST, subphy, 2201 ALL_BITS_PER_PUP, search_dir, dir, result_type, 2202 TRAINING_LOAD_OPERATION_UNLOAD, CS_SINGLE, 2203 &(result[subphy][search_dir]), 2204 1, 0, 0); >>> CID 408729: (OVERRUN) >>> Overrunning array "result" of 9 16-byte elements at element index 12 (byte offset 207) using index "subphy" (which evaluates to 12). 2205 DEBUG_DM_TUNING(DEBUG_LEVEL_INFO, 2206 ("dm cs %d if %d subphy %d result: 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x\n", 2207 cs, 0, subphy, 2208 result[subphy][search_dir][0], 2209 result[subphy][search_dir][1], 2210 result[subphy][search_dir][2], /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2226 in mv_ddr4_dm_tuning() 2220 2221 for (bit = 0; bit < BUS_WIDTH_IN_BITS; bit++) { 2222 result[subphy][HWS_LOW2HIGH][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; 2223 result[subphy][HWS_HIGH2LOW][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; 2224 2225 if (result[subphy][HWS_LOW2HIGH][bit] > vw_sphy_lo_lmt[subphy]) >>> CID 408729: (OVERRUN) >>> Overrunning array "result" of 9 16-byte elements at element index 12 (byte offset 207) using index "subphy" (which evaluates to 12). 2226 vw_sphy_lo_lmt[subphy] = result[subphy][HWS_LOW2HIGH][bit]; 2227 2228 if (result[subphy][HWS_HIGH2LOW][bit] < vw_sphy_hi_lmt[subphy]) 2229 vw_sphy_hi_lmt[subphy] = result[subphy][HWS_HIGH2LOW][bit]; 2230 } 2231 /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 2229 in mv_ddr4_dm_tuning() 2223 result[subphy][HWS_HIGH2LOW][bit] &= LEAST_SIGNIFICANT_BYTE_MASK; 2224 2225 if (result[subphy][HWS_LOW2HIGH][bit] > vw_sphy_lo_lmt[subphy]) 2226 vw_sphy_lo_lmt[subphy] = result[subphy][HWS_LOW2HIGH][bit]; 2227 2228 if (result[subphy][HWS_HIGH2LOW][bit] < vw_sphy_hi_lmt[subphy]) >>> CID 408729: (OVERRUN) >>> Overrunning array "result" of 9 16-byte elements at element index 12 (byte offset 207) using index "subphy" (which evaluates to 12). 2229 vw_sphy_hi_lmt[subphy] = result[subphy][HWS_HIGH2LOW][bit]; 2230 } 2231 2232 DEBUG_DM_TUNING(DEBUG_LEVEL_INFO, 2233 ("loop %d, dm subphy %d, vw %d, %d\n", loop, subphy, 2234 vw_sphy_lo_lmt[subphy], vw_sphy_hi_lmt[subphy])); ** CID 408728: (OVERRUN) /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 606 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 412 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 605 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 370 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 291 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 285 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 648 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 440 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 332 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 677 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 394 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 554 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 517 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 487 in ddr3_tip_vref() /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 376 in ddr3_tip_vref() ________________________________________________________________________________________________________ *** CID 408728: (OVERRUN) /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 606 in ddr3_tip_vref() 600 vref_map[currrent_vref], 601 __LINE__)); 602 } 603 } else { 604 /* we change state and change step */ 605 if (pup_st[pup][if_id] == VREF_STEP_1) { >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 606 pup_st[pup][if_id] = 607 VREF_STEP_2; 608 lim_vref[pup][if_id] = 609 current_vref[pup] 610 [if_id] - initial_step; 611 last_valid_window[pup] /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 412 in ddr3_tip_vref() 406 * better Vref value 407 * define the pup as 408 * converge and step 409 * back to nominal 410 * Vref. 411 */ >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 412 pup_st[pup] 413 [if_id] = 414 VREF_CONVERGE; 415 algo_run_flag++; 416 interface_state 417 [if_id]++; /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 605 in ddr3_tip_vref() 599 (val & (~0xf)) | 600 vref_map[currrent_vref], 601 __LINE__)); 602 } 603 } else { 604 /* we change state and change step */ >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 605 if (pup_st[pup][if_id] == VREF_STEP_1) { 606 pup_st[pup][if_id] = 607 VREF_STEP_2; 608 lim_vref[pup][if_id] = 609 current_vref[pup] 610 [if_id] - initial_step; /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 370 in ddr3_tip_vref() 364 /* Compare results and respond as function of state */ 365 for (if_id = 0; if_id < MAX_INTERFACE_NUM; if_id++) { 366 VALIDATE_IF_ACTIVE(tm->if_act_mask, if_id); 367 for (pup = 0; 368 pup < octets_per_if_num; pup++) { 369 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, pup); >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 370 DEBUG_TRAINING_HW_ALG(DEBUG_LEVEL_TRACE, 371 ("I/F[ %d ], pup[ %d ] STATE #%d (%d)\n", 372 if_id, pup, 373 pup_st[pup] 374 [if_id], __LINE__)); 375 /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 291 in ddr3_tip_vref() 285 pup_st[pup][if_id] = VREF_CONVERGE; 286 DEBUG_TRAINING_HW_ALG( 287 DEBUG_LEVEL_INFO, 288 ("VREF config, IF[ %d ]pup[ %d ] - Vref tune not requered (%d)\n", 289 if_id, pup, __LINE__)); 290 } else { >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 291 pup_st[pup][if_id] = VREF_STEP_1; 292 CHECK_STATUS(ddr3_tip_bus_read 293 (dev_num, if_id, 294 ACCESS_TYPE_UNICAST, pup, 295 DDR_PHY_DATA, reg_addr, &val)); 296 CHECK_STATUS(ddr3_tip_bus_write /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 285 in ddr3_tip_vref() 279 last_vref[pup][if_id] = 0; 280 lim_vref[pup][if_id] = 0; 281 current_valid_window[pup][if_id] = 0; 282 last_valid_window[pup][if_id] = 0; 283 if (vref_window_size[if_id][pup] > 284 vref_window_size_th) { >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 285 pup_st[pup][if_id] = VREF_CONVERGE; 286 DEBUG_TRAINING_HW_ALG( 287 DEBUG_LEVEL_INFO, 288 ("VREF config, IF[ %d ]pup[ %d ] - Vref tune not requered (%d)\n", 289 if_id, pup, __LINE__)); 290 } else { /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 648 in ddr3_tip_vref() 642 if_id, pup, 643 (val & (~0xf)) | 644 vref_map[current_vref[pup] 645 [if_id]], 646 __LINE__)); 647 >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 648 } else if (pup_st[pup][if_id] == VREF_STEP_2) { 649 /* 650 * The last search was the max 651 * point set value and exit 652 */ 653 CHECK_STATUS /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 440 in ddr3_tip_vref() 434 : (current_vref[pup] 435 [if_id] + 436 initial_step); 437 if (current_vref[pup] 438 [if_id] == 439 VREF_MAX_INDEX) { >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 440 pup_st[pup] 441 [if_id] 442 = 443 VREF_STEP_2; 444 } 445 lim_vref[pup] /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 332 in ddr3_tip_vref() 326 get_valid_win_rx(dev_num, if_id, res); 327 for (pup = 0; 328 pup < octets_per_if_num; 329 pup++) { 330 VALIDATE_BUS_ACTIVE 331 (tm->bus_act_mask, pup); >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 332 if (pup_st[pup] 333 [if_id] == 334 VREF_CONVERGE) 335 continue; 336 337 current_valid_window[pup] /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 677 in ddr3_tip_vref() 671 ("VREF config, IF[ %d ]pup[ %d ] - Vref = %X (%d)\n", 672 if_id, pup, 673 (val & (~0xf)) | 674 vref_map[last_vref[pup] 675 [if_id]], 676 __LINE__)); >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 677 pup_st[pup][if_id] = 678 VREF_CONVERGE; 679 algo_run_flag++; 680 interface_state[if_id]++; 681 DEBUG_TRAINING_HW_ALG 682 (DEBUG_LEVEL_TRACE, /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 394 in ddr3_tip_vref() 388 /* 389 * The -1 is for solution resolution +/- 1 tap 390 * of ADLL 391 */ 392 if (current_valid_window[pup][if_id] + 200 >= 393 (last_valid_window[pup][if_id])) { >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 394 if (pup_st[pup][if_id] == VREF_STEP_1) { 395 /* 396 * We stay in the same state and 397 * step just update the window 398 * size (take the max) and Vref 399 */ /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 554 in ddr3_tip_vref() 548 * better Vref value 549 * define the pup as 550 * converge and step 551 * back to nominal 552 * Vref. 553 */ >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 554 pup_st[pup] 555 [if_id] = 556 VREF_CONVERGE; 557 558 algo_run_flag++; 559 interface_state /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 517 in ddr3_tip_vref() 511 * better Vref value 512 * define the pup as 513 * converge and step 514 * back to nominal 515 * Vref. 516 */ >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 517 pup_st[pup] 518 [if_id] = 519 VREF_CONVERGE; 520 algo_run_flag++; 521 522 interface_state /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 487 in ddr3_tip_vref() 481 (DEBUG_LEVEL_TRACE, 482 ("VREF config, IF[ %d ]pup[ %d ] - Vref = %X (%d)\n", 483 if_id, pup, 484 (val & (~0xf)) | 485 vref_map[currrent_vref], 486 __LINE__)); >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 487 } else if (pup_st[pup][if_id] 488 == VREF_STEP_2) { 489 /* 490 * We keep on search back with 491 * the same step size. 492 */ /drivers/marvell/mv_ddr/ddr3_training_hw_algo.c: 376 in ddr3_tip_vref() 370 DEBUG_TRAINING_HW_ALG(DEBUG_LEVEL_TRACE, 371 ("I/F[ %d ], pup[ %d ] STATE #%d (%d)\n", 372 if_id, pup, 373 pup_st[pup] 374 [if_id], __LINE__)); 375 >>> CID 408728: (OVERRUN) >>> Overrunning array "pup_st" of 9 bytes at byte offset 12 using index "pup" (which evaluates to 12). 376 if (pup_st[pup][if_id] == VREF_CONVERGE) 377 continue; 378 379 DEBUG_TRAINING_HW_ALG(DEBUG_LEVEL_TRACE, 380 ("I/F[ %d ], pup[ %d ] CHECK progress - Current %d Last %d, limit VREF %d (%d)\n", 381 if_id, pup, ** CID 408727: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/marvell/mv_ddr/drivers/snps/snps_update.c: 660 in dmem_1d_2d_rtt_nom_wr_park_get() ________________________________________________________________________________________________________ *** CID 408727: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/marvell/mv_ddr/drivers/snps/snps_update.c: 660 in dmem_1d_2d_rtt_nom_wr_park_get() 654 u16 ret_val = 0; 655 u16 rtt_park, rtt_nom, rtt_wr; 656 657 rtt_nom = mv_ddr_rtt_nom_get(); 658 rtt_park = mv_ddr_rtt_park_get(); 659 rtt_wr = mv_ddr_rtt_wr_get(); >>> CID 408727: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "rtt_nom != 4294967295U" is always true regardless of the values of its operands. This occurs as the logical first operand of "&&". 660 if (rtt_nom != PARAM_UNDEFINED && rtt_park != PARAM_UNDEFINED && rtt_wr != PARAM_UNDEFINED) { 661 ret_val = (rtt_nom & RTT_NOM_WR_PARK0_RTT_NOM_MR1_MASK) << RTT_NOM_WR_PARK0_RTT_NOM_MR1_OFFS; 662 ret_val |= (rtt_park & RTT_NOM_WR_PARK0_RTT_PARK_MR5_MASK) << RTT_NOM_WR_PARK0_RTT_PARK_MR5_OFFS; 663 ret_val |= (rtt_wr & RTT_NOM_WR_PARK0_RTT_WR_MR2_MASK) << RTT_NOM_WR_PARK0_RTT_WR_MR2_OFFS; 664 ret_val |= RTT_NOM_WR_PARK0_EN_VAL; 665 } ** CID 408726: Data race undermines locking (LOCK_EVASION) /plat/mediatek/common/lpm/mt_lp_rq.c: 152 in mt_lp_rq_get_status() ________________________________________________________________________________________________________ *** CID 408726: Data race undermines locking (LOCK_EVASION) /plat/mediatek/common/lpm/mt_lp_rq.c: 152 in mt_lp_rq_get_status() 146 for (i = 0; i < plat_mt_rqm.resource_num; i++) { 147 update_sta |= ((rs[i]->res_usage & plat_mt_rqm.user_valid) != 0) ? 148 rs[i]->res_rq : 0; 149 } 150 151 plat_mt_rqm.generic_resource_req = update_sta; >>> CID 408726: Data race undermines locking (LOCK_EVASION) >>> Thread1 sets "flag" to a new value. Now the two threads have an inconsistent view of "flag" and updates to fields correlated with "flag" may be lost. 152 plat_mt_rqm.flag = MT_LP_RQ_FLAG_DONE; 153 spin_unlock(&mt_lp_rq_lock); 154 } 155 156 switch (type) { 157 case PLAT_RQ_REQ_USAGE: ** CID 408725: (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 350 in mv_ddr4_dq_vref_calibration() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 370 in mv_ddr4_dq_vref_calibration() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 369 in mv_ddr4_dq_vref_calibration() ________________________________________________________________________________________________________ *** CID 408725: (OVERRUN) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 350 in mv_ddr4_dq_vref_calibration() 344 valid_vref_cnt[if_id][subphy_num], 345 &center_vref[if_id][subphy_num], 346 &center_adll[if_id][subphy_num]); 347 if (status != MV_OK) 348 return status; 349 >>> CID 408725: (OVERRUN) >>> Overrunning array "center_vref[if_id]" of 9 bytes at byte offset 12 using index "subphy_num" (which evaluates to 12). 350 DEBUG_CALIBRATION(DEBUG_LEVEL_INFO, 351 ("center of mass results: vref %d, adll %d\n", 352 center_vref[if_id][subphy_num], center_adll[if_id][subphy_num])); 353 } else { 354 DEBUG_CALIBRATION(DEBUG_LEVEL_ERROR, 355 ("%s subphy %d no vref results to calculate the center of mass\n", /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 340 in mv_ddr4_dq_vref_calibration() 334 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, subphy_num); 335 DEBUG_CALIBRATION(DEBUG_LEVEL_INFO, 336 ("calculating center of mass for subphy %d, valid window size %d\n", 337 subphy_num, valid_win_size[if_id][subphy_num])); 338 if (valid_vref_cnt[if_id][subphy_num] > 0) { 339 /* calculate center of mass sampling point (t, v) for each subphy */ >>> CID 408725: (OVERRUN) >>> Overrunning array of 9 bytes at byte offset 12 by dereferencing pointer "&center_vref[if_id][subphy_num]". 340 status = mv_ddr4_center_of_mass_calc(dev_num, if_id, subphy_num, TX_DIR, 341 dq_vref_start_win[if_id][subphy_num], 342 dq_vref_end_win[if_id][subphy_num], 343 valid_vref_ptr[if_id][subphy_num], 344 valid_vref_cnt[if_id][subphy_num], 345 &center_vref[if_id][subphy_num], /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 370 in mv_ddr4_dq_vref_calibration() 364 VALIDATE_IF_ACTIVE(tm->if_act_mask, if_id); 365 vref_avg = 0; 366 vref_subphy_num = 0; 367 for (subphy_num = 0; subphy_num < subphy_max; subphy_num++) { 368 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, subphy_num); 369 vref_avg += center_vref[if_id][subphy_num]; >>> CID 408725: (OVERRUN) >>> Overrunning array "center_vref[if_id]" of 9 bytes at byte offset 12 using index "subphy_num" (which evaluates to 12). 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); /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 369 in mv_ddr4_dq_vref_calibration() 363 for (if_id = 0; if_id < MAX_INTERFACE_NUM; if_id++) { 364 VALIDATE_IF_ACTIVE(tm->if_act_mask, if_id); 365 vref_avg = 0; 366 vref_subphy_num = 0; 367 for (subphy_num = 0; subphy_num < subphy_max; subphy_num++) { 368 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, subphy_num); >>> CID 408725: (OVERRUN) >>> Overrunning array "center_vref[if_id]" of 9 bytes at byte offset 12 using index "subphy_num" (which evaluates to 12). 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 374 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 year, 5 months

1
0
0 0

We cannot force Arm features for platforms

by Marcin Juszkiewicz

TL;DR: move Mandatory features to be runtime checked (value 2) Month ago there was changeset from Govindraj Raja merged [1]. The plan was to enable all mandatory features based on architecture version set by plaform (using ARM_ARCH_{MAJOR,MINOR} variables). 1. https://review.trustedfirmware.org/q/topic:%22gr/build_refactor%22 The idea is nice. But only for final products. If you are working on silicon bring up or on virtualization platform (QEMU or other) then you got hit badly... I am working on SBSA Reference Platform in QEMU. It can have one of several cpu models. From old v8.0 cores up to v9.0 ones. And then there is also 'max' core which cannot be mapped to any architecture level because it contains all Arm cpu features QEMU can emulate. We need to support all of them in one TF-A binary. Whenever something fails we have some cpu cores in non-bootable state. We had to enable FGT to get 'max' boot Linux. Now we have to move DIT to be runtime checked to boot anything below Neoverse-V1 at all. And HCX to get 'max' boot Linux again. At current state of TF-A we cannot handle it. Toplevel Makefile includes platform.mk which sets ARM_ARCH_{MAJOR,MINOR} and then make_helpers/arch_features.mk enables mandatory options by setting them to value "1" which means "present, no need to check". Due to this we have those changes in Gerrit: DIT: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/24870 TRF: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/23648 And instead of sending another one to switch FGT, RNG and HCX I decided to write this email. I have spent half of day today bisecting TF-A, booting several tools and operating systems to check how we are and where the problem is. Still have to get Neoverse-N2 booting properly but other than then I got to the point where all cpu cores boot into Linux. We need to change make_helpers/arch_features.mk to stop enabling mandatory features as "present, no need to check" (value '1') but to use runtime check (value '2') instead. This way any platform which contains CPU not yet fully developed can boot TF-A. Or platform where one firmware can boot different cpu models. I am sorry that I bring it so late in release cycle but was unable to use computer for a development for some time.

1 year, 6 months

5
8
0 0

Stack usage

by kbhuvanacbe＠gmail.com

We have executed below command on terminal to get stack size using ARMCLANG compiler. but we are getting "undefined symbol". armclang --target=arm-arm-none-eabi -march=armv8-a -c -g file.c -o file.o armlink file.o --info=stack armlink file.o --callgraph -o FileImage.axf Could anyone answer me that how to get stack size using ARMCLANG compiler for TFA code.

1 year, 6 months

3
10
0 0

Canceled event with note: TF-A Tech Forum @ Thu Nov 16, 2023 5pm - 6pm (CET) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, Cancelling this week as no topic. Thanks & Regards, Olivier." TF-A Tech Forum Thursday Nov 16, 2023 ⋅ 5pm – 6pm Central European Time - Paris We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

1 year, 6 months

1
0
0 0

Trusted Firmware-A LTS v2.8.11 Release Announcement

by Varun Wadekar

Hello, Trusted Firmware-A LTS version 2.8.11 is now available. This release contains the workarounds for CPU errata, platform errata, and fixes for Versal/Versal-NET security vulnerabilities. The complete list of changes can be found here<https://ci-builds.trustedfirmware.org/static-files/NdY070C96xYcXq0KeqQzbFaI…>. Thanks.

1 year, 6 months

1
0
0 0

Changelog for v2.10 Release

by Juan Pablo Conde

Hello everyone, Please take a look at the changelog for your respective platforms ahead of the TF-A v2.10 release. The changelog is autogenerated from the commit messages of the patches that have been merged since the v2.9 release. Here's your chance to give us guidance on any small manual adjustments you would like to see. Patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/24865 Rendered Version: https://ci-builds.trustedfirmware.org/static-files/cUYrGRM_T04eS_lYaTNfWT13… Thanks, Juan Pablo

1 year, 6 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. 3 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 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 3 of 3 defect(s) ** CID 405370: Memory - illegal accesses (OVERRUN) /lib/psci/psci_stat.c: 210 in psci_get_stat() ________________________________________________________________________________________________________ *** CID 405370: Memory - illegal accesses (OVERRUN) /lib/psci/psci_stat.c: 210 in psci_get_stat() 204 /* Get the index into the stats array */ 205 local_state = state_info.pwr_domain_state[pwrlvl]; 206 stat_idx = get_stat_idx(local_state, pwrlvl); 207 208 if (pwrlvl > PSCI_CPU_PWR_LVL) { 209 /* Get the power domain index */ >>> CID 405370: Memory - illegal accesses (OVERRUN) >>> Overrunning array "psci_cpu_pd_nodes" of 16 16-byte elements at element index 4294967295 (byte offset 68719476735) using index "target_idx" (which evaluates to 4294967295). 210 parent_idx = SPECULATION_SAFE_VALUE(psci_cpu_pd_nodes[target_idx].parent_node); 211 for (lvl = PSCI_CPU_PWR_LVL + 1U; lvl < pwrlvl; lvl++) 212 parent_idx = SPECULATION_SAFE_VALUE(psci_non_cpu_pd_nodes[parent_idx].parent_node); 213 214 /* Get the non cpu power domain stats */ 215 *psci_stat = psci_non_cpu_stat[parent_idx][stat_idx]; ** CID 405369: Memory - illegal accesses (OVERRUN) /lib/psci/psci_stat.c: 218 in psci_get_stat() ________________________________________________________________________________________________________ *** CID 405369: Memory - illegal accesses (OVERRUN) /lib/psci/psci_stat.c: 218 in psci_get_stat() 212 parent_idx = SPECULATION_SAFE_VALUE(psci_non_cpu_pd_nodes[parent_idx].parent_node); 213 214 /* Get the non cpu power domain stats */ 215 *psci_stat = psci_non_cpu_stat[parent_idx][stat_idx]; 216 } else { 217 /* Get the cpu power domain stats */ >>> CID 405369: Memory - illegal accesses (OVERRUN) >>> Overrunning array "psci_cpu_stat" of 16 32-byte elements at element index 4294967295 (byte offset 137438953471) using index "target_idx" (which evaluates to 4294967295). 218 *psci_stat = psci_cpu_stat[target_idx][stat_idx]; 219 } 220 221 return PSCI_E_SUCCESS; 222 } 223 ** CID 405368: (NEGATIVE_RETURNS) /lib/psci/psci_stat.c: 210 in psci_get_stat() /lib/psci/psci_stat.c: 218 in psci_get_stat() ________________________________________________________________________________________________________ *** CID 405368: (NEGATIVE_RETURNS) /lib/psci/psci_stat.c: 210 in psci_get_stat() 204 /* Get the index into the stats array */ 205 local_state = state_info.pwr_domain_state[pwrlvl]; 206 stat_idx = get_stat_idx(local_state, pwrlvl); 207 208 if (pwrlvl > PSCI_CPU_PWR_LVL) { 209 /* Get the power domain index */ >>> CID 405368: (NEGATIVE_RETURNS) >>> Using variable "target_idx" as an index to array "psci_cpu_pd_nodes". 210 parent_idx = SPECULATION_SAFE_VALUE(psci_cpu_pd_nodes[target_idx].parent_node); 211 for (lvl = PSCI_CPU_PWR_LVL + 1U; lvl < pwrlvl; lvl++) 212 parent_idx = SPECULATION_SAFE_VALUE(psci_non_cpu_pd_nodes[parent_idx].parent_node); 213 214 /* Get the non cpu power domain stats */ 215 *psci_stat = psci_non_cpu_stat[parent_idx][stat_idx]; /lib/psci/psci_stat.c: 218 in psci_get_stat() 212 parent_idx = SPECULATION_SAFE_VALUE(psci_non_cpu_pd_nodes[parent_idx].parent_node); 213 214 /* Get the non cpu power domain stats */ 215 *psci_stat = psci_non_cpu_stat[parent_idx][stat_idx]; 216 } else { 217 /* Get the cpu power domain stats */ >>> CID 405368: (NEGATIVE_RETURNS) >>> Using variable "target_idx" as an index to array "psci_cpu_stat". 218 *psci_stat = psci_cpu_stat[target_idx][stat_idx]; 219 } 220 221 return PSCI_E_SUCCESS; 222 } 223 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 year, 6 months

1
0
0 0

Minor update to Platform ports requirements

by Govindraj Raja

Hi All / Platform owners, There is a minor update to Platform ports requirements based on patches merged recently. https://trustedfirmware-a.readthedocs.io/en/latest/porting-guide.html#build… So please use correct ARM_ARCH_MAJOR and ARM_ARCH_MINOR from platform makefile or from build options to utilize the 'arch_features.mk' to enable all mandatory features by default. Enabling of optional features remain unchanged and based on availability and need can be enabled from platform makefile. Some of platform port convert examples are as below: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/23463/20/pla… https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/23670/21/pla… -- Thanks, Govindraj.R & Manish Pandey

1 year, 6 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Nov 2, 2023 5pm - 6pm (CET) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

This event has been canceled with a note: "Hi, The TF-A Tech Forum is cancelled this week as no topic planned. Regards, Olivier." TF-A Tech Forum Thursday Nov 2, 2023 ⋅ 5pm – 6pm Central European Time - Paris We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

1 year, 6 months

1
0
0 0

TF-A Hang on NXP i.MX 8M Plus QuadLite

by Marcel Ziswiler

Hi there We recently got our first batch of i.MX 8M Plus QuadLite based SoMs. While NXP downstream works just fine on them they just hang booting with latest upstream U-Boot (and TF-A). Replacing TF-A with the downstream NXP one made upstream U-Boot work as well. Further debugging TF-A showed imx_gpc_pm_domain_enable() to be the culprit. Looking more specifically I discovered the following so far downstream-only commit [1]. So it looks like in downstream NXP is limiting the to-be-enabled power management domains to HSIOMIX, USB1_PHY and USB2_PHY. Anybody knows why exactly this is done and why this got never upstreamed? Thank you very much for any insights into this matter. [1] https://github.com/nxp-imx/imx-atf/commit/47759cfca10b2286a218062915d4a2808… Cheers Marcel

1 year, 6 months

1
0
0 0

Suspend to RAM support for K3 J7200

by Thomas Richard

Hello, I just sent a series to gerrit: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/23992. I'm writing this email to add more context to this series, as I didn't find how to to it with gerrit. This series is only the TF-A part to add suspend to RAM support for the TI K3 J7200 target. Some modifications are also needed in Linux kernel, U-Boot (R5 SPL) and DM-Firmware. During the suspend sequence, TF-A save itself in DRAM, in a reserved memory region dedicated to lpm. TF-A will be restored by R5 SPL. We need to save it in DRAM (which will be in retention mode during suspend) because as it runs in SRAM, it will be lost once the SOC is powered-off by the PMIC. Best Regards, -- Thomas Richard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com

1 year, 6 months

4
3
0 0

Trusted Firmware-A LTS v2.8.10 Release Announcement

by Yann GAUTIER - foss

Hello, Trusted Firmware-A LTS version 2.8.10 is now available. This release contains the support for MbedTLS v2.28.5, and documentation updates. The complete list can be found here<https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.10/change-log.html>. Thanks.

1 year, 6 months

1
0
0 0

TF-A Tech Forum on Oct 19th 2023

by Olivier Deprez

Hi, For the TF-A Tech forum on Oct, 19th Manish Badarkhe from Arm TF-A team will present: Migration to PSA Crypto API Agenda: Existing Crypto Mechanism - using legacy Crypto API What is PSA? Design of PSA Crypto API Use of PSA Crypto API in TF-A PSA Crypto API verification using CI Future Scope: MbedTLS with PSA Crypto driver Regards, Olivier. ________________________________________ From: Trusted Firmware Public Meetings Sent: 14 June 2020 19:21 To: Trusted Firmware Public Meetings; tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) When: 19 October 2023 17:00-18:00. Where: You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.

1 year, 7 months

1
0
0 0

Compile error when SAVE_KEYS=1 in tf-a v2.9.0

by xtaens＠qq.com

Hello everyone, When I used TF-A 2.9.0 (commit b06b509eb2b7f0f4dce1b4133500cf30aa0dcd4a) to compile FVP, I opened the SAVE_KEYS=1 and modified the relevant code to save the key, but the compilation failed. The error message is as follows, SAVE_KEYS=0 compile is normal. It is also normal in lts-v2.8.9. Is this question not configured or TF-A has bugs? //Compile information MBEDTLS_VERSION_MAJOR is [2] MBEDTLS_VERSION_MINOR is [28] Including drivers/auth/mbedtls/mbedtls_crypto.mk Building fvp Selected OpenSSL version: 3.0.2 Built tools/cert_create/cert_create successfully Selected OpenSSL version: 3.0.2 NOTICE: CoT Generation Tool: Built : 16:00:52, Oct 13 2023 NOTICE: Target platform: TBBR Generic NOTICE: Creating new key for 'Root Of Trust key' WARNING: Cannot open file /mnt/sdb/tanwc/linux/tf-a/build/fvp/debug/trusted_rsa2048.pem ERROR: Cannot load key from /mnt/sdb/tanwc/linux/tf-a/build/fvp/debug/trusted_rsa2048.pem ERROR: Error loading '/mnt/sdb/tanwc/linux/tf-a/build/fvp/debug/trusted_rsa2048.pem' make: *** [Makefile:1652: certificates] Error 1 //File modification: Define the specified macro diff --git a/plat/arm/common/arm_common.mk b/plat/arm/common/arm_common.mk index 41d1b66c1..216659835 100644 --- a/plat/arm/common/arm_common.mk +++ b/plat/arm/common/arm_common.mk @@ -377,6 +377,22 @@ ifneq (${TRUSTED_BOARD_BOOT},0) # Include common TBB sources AUTH_SOURCES := drivers/auth/auth_mod.c \ drivers/auth/img_parser_mod.c + ifeq (${GENERATE_COT},1) + TFW_NVCTR_VAL ?= 0 + NTFW_NVCTR_VAL ?= 0 + KEY_SIZE ?= + HASH_ALG ?= sha256 + KEY_ALG ?= ecdsa + TF_MBEDTLS_KEY_ALG := ${KEY_ALG} + + ifeq (${SAVE_KEYS},1) + TRUSTED_WORLD_KEY ?= ${BUILD_PLAT}/trusted_${KEY_ALG}${KEY_SIZE}.pem + NON_TRUSTED_WORLD_KEY ?= ${BUILD_PLAT}/non-trusted_${KEY_ALG}${KEY_SIZE}.pem + BL31_KEY ?= ${BUILD_PLAT}/soc_${KEY_ALG}${KEY_SIZE}.pem + BL32_KEY ?= ${BUILD_PLAT}/trusted_os_${KEY_ALG}${KEY_SIZE}.pem + BL33_KEY ?= ${BUILD_PLAT}/non-trusted_os_${KEY_ALG}${KEY_SIZE}.pem + endif + endif # Include the selected chain of trust sources. ifeq (${COT},tbbr) //The compilation command I use make -j ARM_ARCH_MAJOR=8 \ ARCH=aarch64 \ CROSS_COMPILE=aarch64-linux-gnu- \ DEBUG=1 \ PLAT=fvp \ TRUSTED_BOARD_BOOT=1 \ GENERATE_COT=1 \ SAVE_KEYS=1 \ ARM_ROTPK_LOCATION=devel_rsa \ MBEDTLS_DIR=/mbedtls \ BL33=/mnt/uboot.bin \ all fip Thanks

1 year, 7 months

2
2
0 0

Usage of assert functions in TFA Code

by Nithin S

Hello, There are multiple occurrences in TFA Code where assert statements are used to handle function arguments. But these assert statements are currently enabled only in debug mode. So, I wanted to know that will there be any harm in continuing to use assert statements in production code as well for handling failures? Regards, Nithin S

1 year, 7 months

3
3
0 0

Trusted Firmware-A LTS v2.8.9 Release Announcement

by Varun Wadekar

Hello, Trusted Firmware-A LTS version 2.8.9 is now available. This release contains the support for the new Errata ABI and Errata Framework along with the conversion patches for all CPUs. The complete list can be found here<https://ci-builds.trustedfirmware.org/static-files/_5qFfMg2QdoFuFBk6-0oB6Jm…>. We will update the official readthedocs page shortly. Thanks.

1 year, 7 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. 5 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 5 of 5 defect(s) ** CID 395749: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto.c: 7945 in psa_pake_input() ________________________________________________________________________________________________________ *** CID 395749: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto.c: 7945 in psa_pake_input() 7939 default: 7940 (void) step; 7941 status = PSA_ERROR_NOT_SUPPORTED; 7942 goto exit; 7943 } 7944 >>> CID 395749: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "status = psa_driver_wrapper...". 7945 status = psa_driver_wrapper_pake_input(operation, driver_step, 7946 input, input_length); 7947 7948 if (status != PSA_SUCCESS) { 7949 goto exit; 7950 } ** CID 395684: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto.c: 7344 in psa_pake_setup() ________________________________________________________________________________________________________ *** CID 395684: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto.c: 7344 in psa_pake_setup() 7338 #endif /* PSA_WANT_ALG_JPAKE */ 7339 { 7340 status = PSA_ERROR_NOT_SUPPORTED; 7341 goto exit; 7342 } 7343 >>> CID 395684: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "operation->stage = 1;". 7344 operation->stage = PSA_PAKE_OPERATION_STAGE_COLLECT_INPUTS; 7345 7346 return PSA_SUCCESS; 7347 exit: 7348 psa_pake_abort(operation); 7349 return status; ** CID 395609: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto.c: 8002 in psa_pake_get_implicit_key() ________________________________________________________________________________________________________ *** CID 395609: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto.c: 8002 in psa_pake_get_implicit_key() 7996 #endif /* PSA_WANT_ALG_JPAKE */ 7997 { 7998 status = PSA_ERROR_NOT_SUPPORTED; 7999 goto exit; 8000 } 8001 >>> CID 395609: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "status = psa_driver_wrapper...". 8002 status = psa_driver_wrapper_pake_get_implicit_key(operation, 8003 shared_key, 8004 sizeof(shared_key), 8005 &shared_key_len); 8006 8007 if (status != PSA_SUCCESS) { ** CID 395586: Control flow issues (DEADCODE) /mbedtls/library/psa_crypto.c: 8019 in psa_pake_get_implicit_key() ________________________________________________________________________________________________________ *** CID 395586: Control flow issues (DEADCODE) /mbedtls/library/psa_crypto.c: 8019 in psa_pake_get_implicit_key() 8013 shared_key, 8014 shared_key_len); 8015 8016 mbedtls_platform_zeroize(shared_key, sizeof(shared_key)); 8017 exit: 8018 abort_status = psa_pake_abort(operation); >>> CID 395586: Control flow issues (DEADCODE) >>> Execution cannot reach the expression "abort_status" inside this statement: "return (status == 0) ? abor...". 8019 return status == PSA_SUCCESS ? abort_status : status; 8020 } 8021 8022 psa_status_t psa_pake_abort( 8023 psa_pake_operation_t *operation) 8024 { ** CID 395567: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto.c: 7781 in psa_pake_output() ________________________________________________________________________________________________________ *** CID 395567: Control flow issues (UNREACHABLE) /mbedtls/library/psa_crypto.c: 7781 in psa_pake_output() 7775 default: 7776 (void) step; 7777 status = PSA_ERROR_NOT_SUPPORTED; 7778 goto exit; 7779 } 7780 >>> CID 395567: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "status = psa_driver_wrapper...". 7781 status = psa_driver_wrapper_pake_output(operation, driver_step, 7782 output, output_size, output_length); 7783 7784 if (status != PSA_SUCCESS) { 7785 goto exit; 7786 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 year, 7 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Oct 5, 2023 5pm - 6pm (CEST) (tf-a@lists.trustedfirmware.org)

by olivier.deprez＠arm.com

This event has been canceled with a note: "Hi, Cancelling as no topic proposed for this instance. Regards, Olivier." TF-A Tech Forum Thursday Oct 5, 2023 ⋅ 5pm – 6pm Central European Time - Paris We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

1 year, 7 months

1
0
0 0

Deprecated platforms in TF-A

by Manish Badarkhe

Hi All, We are currently in the process of preparing for an upcoming release v2.10 [1] and are actively seeking out any deprecated platforms within the TF-A source code. We kindly request all platform owners and contributors to dedicate some time to review the TF-A source code for any platforms that may have been deprecated. If you encounter any platforms that require deprecation but have not yet been labelled as such, we kindly request that you contribute by submitting the required changes to officially mark them as deprecated. You can follow the example provided in [2]. Thank you for your cooperation. [1]: https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio… [2]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17710 Regards, Manish Badarkhe

1 year, 7 months

1
0
0 0

#ifdef PLAT_XLAT_TABLES_DYNAMIC in xlat_tables_context.c

by Nagal, Amit

Hi , When I grep for PLAT_XLAT_TABLES_DYNAMIC in /lib/lib/xlat_tables_v2/ , I see most references for PLAT_XLAT_TABLES_DYNAMIC are enclosed in #if directive. Is there any specific reason why only below mentioned reference for PLAT_XLAT_TABLES_DYNAMIC is covered with #ifdef and not under #if . https://github.com/Xilinx/arm-trusted-firmware/blob/master/lib/xlat_tables_… #ifdef PLAT_XLAT_TABLES_DYNAMIC #define MAX_PHYS_ADDR tf_xlat_ctx.pa_max_address #else #define MAX_PHYS_ADDR tf_xlat_ctx.max_pa #endif Regards Amit

1 year, 7 months

2
2
0 0

Platforms without NS-EL2 component

by Manish Pandey2

Hi, I am writing this email to find out any legacy platforms supports in TF-A (upstream or downstream) which does not have any NS-EL2 component running. Because NS-EL2 is present but unused EL3 also need to do a minimal initialization of EL2. The side effect of this is, TF-A currently has extra code in generic path (e.g. cm_prepare_el3_exit() ) to cater for these platforms which is not required for most others. The most likely reason why TF-A introduced support for systems without NS-EL2 was because of UEFI implementation for Windows which didn't initialize NS-EL2 properly. Given that the UEFI spec has said "Use the highest 64 bit non secure privilege level available" for a long time now we are safe to assume that any UEFI implementation will handover to windows at NS-EL2. (similar to Linux) Considering that there are very few platforms which need this code and to keep backward compatibility, we propose to introduce a macro like "INIT_UNUSED_NS_EL2" and guard the code under this[1]. Keep this flag default disabled and get rid of it( along with code) altogether in next couple of releases, if we are certain that none of the platforms using it. Please let me know if you are aware of any such platform configuration. [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/22716 Thanks Manish

1 year, 7 months

2
2
0 0

EHF + OP-TEE

by brian.neely＠analog.com

Hello, Are EHF and OP-TEE (opteed) designed to work together? I'm seeing some strange behavior when NS interrupts are routed to EL3 as FIQs (due to EHF), but before I dig into it further I wanted to confirm if EHF + OP-TEE is a valid combination. Some background: Our system, which uses OP-TEE, has some "aggregated interrupts" that contain both secure and non-secure sources, for which we wanted to use SDEI to filter and dispatch to Linux (and SDEI requires EHF). Thanks! -Brian

1 year, 7 months

4
4
0 0

Console getc() callback

by Sandrine Bailleux

Hi everyone, As you may know, console drivers in TF-A are required to provide a number of callbacks. One of them is getc() (to read a character from the console). Even though most platform ports provide a valid implementation of it, it does not seem to be called anywhere in the code base today, effectively qualifying it as dead code. I did a bit of git history digging and from what I've seen, the very first public version of TF-A (v0.2!) already had a getc() callback in the Arm PL011 UART driver. So my guess is that all subsequent UART drivers added after that followed the same approach. When the multi-console framework was introduced, it naturally catered for this feature as well. However, taking a step back, I wonder why we introduced getc() in the first place... Unlike other firmwares (like U-boot or EDK2), TF-A does not implement any kind of interactive user shell. And from a security point of view, getc() constitutes an attack vector into TF-A, which might allow an attacker to inject arbitrary data. So keeping this functionality without any valid use case sounds like a bad idea to me. Now, even though getc() is not used in upstream TF-A code right now, I realize there might be downstream / internal test setups which need it. For example, for firmware recovery purposes (receiving a backup firmware over a serial interface) or automated tests setups (some script driving a test session using some communication protocol over a serial interface). Is anyone depending on such use cases? If not, then I suggest we consider removing getc() feature altogether. We could always bring it back when there is a real use case for it (it will survive through git history). At the very least, I would like to disable getc() by default. Enabling it would require setting a build flag. Any thoughts or concerns? Best regards, Sandrine

1 year, 7 months

4
6
0 0

Convert fiptool to Python script

by Varun Wadekar

Hello, We use fiptool extensively to generate the FIP blobs for NVIDIA platforms. But, we encountered the following issues during deployment. 1. fiptool has a dependency on the host machine for OpenSSL and gcc. 2. fiptool resides under the TF-A repo and is used by Hafnium and SPs. This creates a cross-repository dependency. As a workaround, we ship a prebuilt fiptool. But, due to OS dependency, this approach is not scalable across OS versions. E.g. One OS distribution might be using a lower OpenSSL version compared another, creating an incompatibility. I was thinking if converting fiptool to a python script might help resolve these issues. Sptool was converted into a Python script, so was wondering if anyone has tried converting fiptool to a Python script too. -Varun

1 year, 7 months

3
9
0 0

Re: Workaround for ARM Cortex-A78AE Erratum 1941500 is not enabled

by Matthias Rosenfelder

Hi, the code is still incorrect after half a year. It has been changed twice, without fixing it. There was no response to the report I created [1]. If there is no interest / lack of response I may get the impression that my contributions are not welcomed at TF-A. Thus, I decided to not report any issues in the future. Sadly, this is how the open source idea dies - at least for this project. Best Regards, Matthias [1] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… [Banner]<http://www.nio.io> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. You may NOT use, disclose, copy or disseminate this information. If you have received this email in error, please notify the sender and destroy all copies of the original message and all attachments. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

1 year, 7 months

4
5
0 0

SME support in RMM

by Arunachalam Ganapathy

Hi All, Please review the patch-set that adds the functionality in RMM to manage Scalable Matrix Extension (SME) context. If the CPU supports SME and if Realm accesses FPU/SVE functionality then NS SME state is saved to allow Realm to use FPU/SVE register state. https://review.trustedfirmware.org/q/topic:%22rmm_sme%22+(status:open%20OR%… Brief summary of changes made in different components: RMM: - Introduces SIMD context and exports APIs to the runtime component of RMM to initialize, save, restore, and switch SIMD context. - Adds SME support in RMM to manage NS SME context. Supports SVE+SME config and SME only config. - Handles SVE hint bit passed in RMI SMCs - Handles SME exceptions from Realms https://review.trustedfirmware.org/q/topic:%22rmm_sme%22+(status:open%20OR%… TF-A: - Enables FEAT_SME for RMM - Passes SMCCCv1.3 SVE hint bit in SMC function ID to RMM tf-a-tests: - There are changes in common lib routines for sve, sme so that testcases running in NS-EL2, S-EL1, R-EL1 can use these helper routines. - Adds helper routines to read, write, compare FPU and SVE Z, P, FFR registers - Adds SMCCCv1.3 SVE hint bit support in TFTF framework - Enables SME/SME2 during arch init - Adds SME helper routines and extends SVE lib routines to support streaming SVE mode. https://review.trustedfirmware.org/q/topic:%22rmm_sme%22+(status:open%20OR%… Thanks, Arun

1 year, 7 months

1
0
0 0

Console scope flags/ console switch state - understanding

by Michal Simek

Hi, I am looking at how console flags are used and setup. In porting guide I see Function : bl31_plat_runtime_setup() [optional] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ :: Argument : void Return : void The purpose of this function is allow the platform to perform any BL31 runtime setup just prior to BL31 exit during cold boot. The default weak implementation of this function will invoke ``console_switch_state()`` to switch console output to consoles marked for use in the ``runtime`` state. Some platform are calling it but some of them not (like our Xilinx one). Tegra has in tegra_pwr_domain_power_down_wfi() console_flush(); console_switch_state(0); which is what none other has. Should console_flush() be called by default all the time when console is switched and also disabled when system goes down? Why console_switch_state(CONSOLE_FLAG_RUNTIME) is not called from bl31_main() when before bl31_plat_runtime_setup() is called we have console_flush() already? The second part of this how console scope is setup. Implementation is clear and set. void console_set_scope(console_t *console, unsigned int scope) { assert(console != NULL); console->flags = (console->flags & ~CONSOLE_FLAG_SCOPE_MASK) | scope; } The commit cc5859ca19ff ("Multi-console: Deprecate the `finish_console_register` macro") when finish_console_register is called (DCC is exception here) is setting up CONSOLE_FLAG_BOOT and CONSOLE_FLAG_CRASH by default. And most of platforms is calling console registration with calling console_set_scope() where new flags are recorded BOOT only, BOOT/RUNTIME, RUNTIME only or BOOT/RUNTIME/CRASH. I would like to understand what should be the right behavior. Why are platforms removing CRASH flag after registration? (I see that a lot of platforms are having private plat_crash_console_init() but pretty much crash console is the same with regular console). Why runtime console is setup directly in bl31_early_platform_setup2 when guidance is saying that it should be done much later? Also commit 63c52d0071ef ("plat/common/crash_console_helpers.S: Fix MULTI_CONSOLE_API support") removed CONSOLE_FLAG_CRASH from plat_crash_console_init but only from 64bit version. In 32bit version there is still there. It suggest that any C code should be called. Do we really need CONSOLE_FLAG_CRASH? Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs

1 year, 7 months

4
5
0 0

Re: Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

Hi, The TF-A Tech Forum instance on Sep 21st 2023 is cancelled due to lack of topic. Thanks & Regards, Olivier. ________________________________ From: Trusted Firmware Public Meetings Sent: 14 June 2020 19:21 To: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) When: 21 September 2023 17:00-18:00. Where: You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.

1 year, 7 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Sep 21, 2023 5pm - 6pm (CEST) (tf-a@lists.trustedfirmware.org)

by olivier.deprez＠arm.com

This event has been canceled with a note: "Hi, The TF-A Tech Forum instance on Sep 21st 2023 is cancelled due to lack of topic. Thanks & Regards, Olivier. " TF-A Tech Forum Thursday Sep 21, 2023 ⋅ 5pm – 6pm Central European Time - Paris We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

1 year, 7 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 401729: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/ddr/stm32mp_ddr_test.c: 134 in stm32mp_ddr_check_size() ________________________________________________________________________________________________________ *** CID 401729: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /drivers/st/ddr/stm32mp_ddr_test.c: 134 in stm32mp_ddr_check_size() 128 uint32_t stm32mp_ddr_check_size(void) 129 { 130 uint32_t offset = sizeof(uint32_t); 131 132 mmio_write_32(STM32MP_DDR_BASE, DDR_PATTERN); 133 >>> CID 401729: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "offset < 4294967296UL" is always true regardless of the values of its operands. This occurs as the logical operand of "while". 134 while (offset < STM32MP_DDR_MAX_SIZE) { 135 mmio_write_32(STM32MP_DDR_BASE + offset, DDR_ANTIPATTERN); 136 dsb(); 137 138 if (mmio_read_32(STM32MP_DDR_BASE) != DDR_PATTERN) { 139 break; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 year, 8 months

2
1
0 0

Plan for RME support in QEMU

by Jean-Philippe Brucker

Hello, QEMU 8.1 added support for FEAT_RME. It is experimental, enabled with '-cpu max,x-rme=on', and requires fixes that will be available in QEMU 8.2. I'm working on adding support to TF-A and TF-RMM. I just submitted some TF-A patches for review (topic qemu-rme) that enable the feature for the virt platform, and intend to send the necessary changes for TF-RMM within a week or so. Without RMM, the Test Realm Payload is included into the FIP for light testing. After the TF-A and TF-RMM changes, I'd like to add support for the SBSA platform as well, which should be a relatively small change once the common QEMU support is merged. Thanks, Jean --- Building TF-A for QEMU with RME support: make -j CROSS_COMPILE=aarch64-linux-gnu- PLAT=qemu DEBUG=1 RMM=path/to/rmm/build/Debug/rmm.img ENABLE_RME=1 BL33=path/to/QEMU_EFI.fd QEMU_USE_GIC_DRIVER=QEMU_GICV3 all fip dd if=tf-a/build/qemu/debug/bl1.bin of=flash.bin bs=4096 conv=notrunc dd if=tf-a//build/qemu/debug/fip.bin of=flash.bin seek=64 bs=4096 conv=notrunc Running QEMU, for example: qemu-system-aarch64 -cpu max,x-rme=on,sme=off -m 3G -smp 8 -M virt,gic-version=3,virtualization=on,secure=on,acpi=off -bios flash.bin -kernel linux/arch/arm64/boot/Image -initrd path/to/initrd -append console=ttyAMA0 -nographic ... [ 0.825891] kvm [1]: Using prototype RMM support (version 66.0) SMC_RMM_FEATURES 0 > RMI_SUCCESS 33403e30

1 year, 8 months

2
2
0 0

New Member

by Nicholas Vonza

Dear Sir/Madam, Just Join the Forum To Learn and Experience More. Regards, Nicholas Vonza

1 year, 8 months

1
0
0 0

Questions about memory encryption in FVP & TF-A

by Chenxu Wang

Hi all, I find that the latest Arm A-profile manual (DDI0487_J_a) mention several registers/instructions related to memory encryption (e.g., MECID-related registers). So can I ask two questions about it? 1. Is the FVP (I use the Base RevC AEM) support Memory Encryption Context (MEC) and Memory Protection Engine (MPE)? They are critical to memory encryption. If no, do we have some solutions to simulate them and verify memory encryption? 2. Does current TF-A support managing MPE, or other hardware related to memory encryption? Besides that, one problem for curiosity (only related to FVP). 3. I find some PCI-E device can use hardware encryption (example, NVIDIA H100 GPU). Can we attach this device to FVP's PCI-E port? Assume it has already connected to my Host PC via PCI-E. Sincerely, WANG Chenxu

1 year, 8 months

2
1
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. 3 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 400208: Performance inefficiencies (PASS_BY_VALUE) /include/services/el3_spmd_logical_sp.h: 108 in ffa_partition_info_regs_get_last_idx() ________________________________________________________________________________________________________ *** CID 400208: Performance inefficiencies (PASS_BY_VALUE) /include/services/el3_spmd_logical_sp.h: 108 in ffa_partition_info_regs_get_last_idx() 102 { 103 return (retval->func == FFA_MSG_SEND_DIRECT_RESP_SMC32) || 104 (retval->func == FFA_MSG_SEND_DIRECT_RESP_SMC64); 105 } 106 107 static inline uint16_t ffa_partition_info_regs_get_last_idx( >>> CID 400208: Performance inefficiencies (PASS_BY_VALUE) >>> Passing parameter args of type "struct ffa_value" (size 144 bytes) by value, which exceeds the low threshold of 128 bytes. 108 struct ffa_value args) 109 { 110 return (uint16_t)(args.arg2 & 0xFFFFU); 111 } 112 113 static inline uint16_t ffa_partition_info_regs_get_curr_idx( ** CID 400207: Performance inefficiencies (PASS_BY_VALUE) /services/std_svc/spmd/spmd_logical_sp.c: 359 in ffa_partition_info_regs_get_part_info() ________________________________________________________________________________________________________ *** CID 400207: Performance inefficiencies (PASS_BY_VALUE) /services/std_svc/spmd/spmd_logical_sp.c: 359 in ffa_partition_info_regs_get_part_info() 353 * This function takes an ffa_value structure populated with partition 354 * information from an FFA_PARTITION_INFO_GET_REGS ABI call, extracts 355 * the values and writes it into a ffa_partition_info_v1_1 structure for 356 * other code to consume. 357 */ 358 bool ffa_partition_info_regs_get_part_info( >>> CID 400207: Performance inefficiencies (PASS_BY_VALUE) >>> Passing parameter args of type "struct ffa_value" (size 144 bytes) by value, which exceeds the low threshold of 128 bytes. 359 struct ffa_value args, uint8_t idx, 360 struct ffa_partition_info_v1_1 *partition_info) 361 { 362 uint64_t *arg_ptrs; 363 uint64_t info, uuid_lo, uuid_high; 364 ** CID 400206: Control flow issues (UNREACHABLE) /plat/xilinx/common/plat_fdt.c: 28 in prepare_dtb() ________________________________________________________________________________________________________ *** CID 400206: Control flow issues (UNREACHABLE) /plat/xilinx/common/plat_fdt.c: 28 in prepare_dtb() 22 dtb = (void *)XILINX_OF_BOARD_DTB_ADDR; 23 #endif 24 if (IS_TFA_IN_OCM(BL31_BASE)) 25 return; 26 27 /* Return if no device tree is detected */ >>> CID 400206: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "if (fdt_check_header(dtb) !...". 28 if (fdt_check_header(dtb) != 0) { 29 NOTICE("Can't read DT at %p\n", dtb); 30 return; 31 } 32 33 ret = fdt_open_into(dtb, dtb, XILINX_OF_BOARD_DTB_MAX_SIZE); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 year, 8 months

3
3
0 0

New TrustedFirmware Discord Server

by Don Harbin

Hi All, Note you may have received another instance of this note but when I attempted to send to all TF ML's simultaneously it seemed to fail, so sending to each one at a time. Sorry about that. :/ We've created a Discord Server for real time chats/sharing. This solution comes at no cost to the project, is set up with channels for each project, includes a #general channel, and supports direct 1-1 chats between members, all with the goal of improving collaboration between trustedfirmware.org developers. We encourage all to join! :) Instructions for joining can be found on the TF.org FAQ page <https://www.trustedfirmware.org/faq/>. See you all there and please don't hesitate to reach out if you have any questions! Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

1 year, 8 months

1
0
0 0

New TrustedFirmware Discord Server

by don.harbin＠linaro.org

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

1 year, 8 months

1
0
0 0

MISRA-C violation for unused functions in Trusted Firmware-A(TFA) code

by nithing1999＠gmail.com

It is observed that several unused functions are present in Trusted Firmware-A code, is it possible to mask those unused functions or leave them as it is to fix MISRA-C Violations? If these functions are not appearing in symbol table, then no need to take actions on violations reported in these functions? Please suggest.

1 year, 8 months

4
6
0 0

Canceled event: TF-A Tech Forum @ Thu Sep 7, 2023 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled. TF-A Tech Forum Thursday Sep 7, 2023 ⋅ 4pm – 5pm United Kingdom Time We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

1 year, 8 months

1
0
0 0

Re: Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

Hi, Please consider the TF-A Tech Forum cancelled for tomorrow Thu Sep, 7th as no topic was raised. Thanks. Regards, Olivier. ________________________________ From: Trusted Firmware Public Meetings Sent: 14 June 2020 19:21 To: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) When: 07 September 2023 17:00-18:00. Where: You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.

1 year, 8 months

1
0
0 0

External Abort and SError Handling with RAS enabled

by Bharat Bhushan

Hi All, SCR_EL3.EA define whether to route External Abort and SError Interrupt to EL3 or EL2/1. ATF have a compile time flag to HANDLE_EA_EL3_FIRST_NS to program SCR_EL3.EA. Below text from ATF documentation. - ``HANDLE_EA_EL3_FIRST_NS``: When set to ``1``, External Aborts and SError Interrupts, resulting from errors in NS world, will be always trapped in EL3 i.e. in BL31 at runtime. When set to ``0`` (default), these exceptions will be trapped in the current exception level (or in EL1 if the current exception level is EL0). Have question related to forwarding of these errors when External Abort and SError Interrupt are routed to EL3. In this case will ATF forward Asynchronous SError Interrupt to Linux via RAS? Thanks -Bharat

1 year, 8 months

2
3
0 0

MISRA-C Violations for function like macros in Trusted Firmware-A(TFA) code

by nithing1999＠gmail.com

It is observed that functions like macros like NOTICE, WARN and assert are present in the Trusted Firmware-A code. MISRA-C standard treats these as violations. shall we take these as deviation? please suggest. TFA Guidelines recommends using logging macros. So can we make deviations or need to change the MACRO into function.

1 year, 8 months

3
2
0 0

MISRA-C violation for Device Tree (FDT) in Trusted Firmware-A (TFA) code.

by Nithin G

Hello, It is observed that device tree functions are present under lib/libfdt/... in Trusted Firmware-A code, but this device tree are not present in symbol table and also if we remove this device tree functions in code, board was successfully booting. However, while doing Coverity build to fix MISRA-C violations getting violations from this device tree code. So, is it possible to leave those violations please suggest? And when it will be enabled, please suggest. Thanks & Regards Nithin G

1 year, 8 months

2
2
0 0

Techforum for 24th August CANCELLED

by Joanna Farley

Hi Everyone, I have cancelled the TF-A techforum for latter today as we have no topic scheduled to be discussed. Calendar cancellations have been sent. Apologies for the late notification. Joanna

1 year, 8 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Aug 24, 2023 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with a note: "Cancelling as we have no topics for today. Apologies for the late cancellation. Joanna" TF-A Tech Forum Thursday Aug 24, 2023 ⋅ 4pm – 5pm United Kingdom Time We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

1 year, 8 months

1
0
0 0

Question about Secondary CPU boot with spintable

by 빈성욱

Hi I ported TF-A and OPTEE on multi-core SoC, and I checked that xtest passed on CPU0 without failure. However, I'm failing in secondary CPU boot, and I'd like to get some help. I'm using ARMv8, and I'm using spintable as CPU enable method (not using PSCI FW). TF-A is in EL3. What I did ... 1. I released secondary CPU reset from bl31_early_platform_setup2() during primary CPU cold booting - set secondary CPU's RVBAR to bl31_entrypoint - release secondary CPU reset 2. I implemeneted plat_secondary_cold_boot_setup(), which is spining until linux kernel updates cpu-release-addr. Once linux kernel updates cpu-release-addr, then it changes EL to EL1 and jumps to secondary_startup() in linux 3. But secondary core goes to panic. It seems to happen when linux invokes optee_probe() Should I initialize some contexts (e.g. optee ..)? If so, where should I implement the corresponding codes? I'm wondering if I'm missing something, and I'd like to get some advice Thanks, --Bin

1 year, 8 months

6
7
0 0

Canceled event with note: TF-A Tech Forum @ Thu Aug 10, 2023 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with a note: "Cancelling this weeks TF-A Tech Forum. No topics ready to present and many people out on vacation." TF-A Tech Forum Thursday Aug 10, 2023 ⋅ 4pm – 5pm United Kingdom Time We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

1 year, 9 months

1
0
0 0

Trusted Firmware-A LTS v2.8.8 Release Announcement

by Varun Wadekar

Hello, Trusted Firmware-A LTS version 2.8.8 is now available. This release contains the following patches. * ec3fafa24 fix(cpus): workaround for Neoverse V2 erratum 2801372 The readthedocs update can be found at https://trustedfirmware-a.readthedocs.io/en/lts-v2.8/change-log.html. Thanks.

1 year, 9 months

1
0
0 0

About erratum in TF-A

by Ming Huang

Hi Boyan, Some questions about erratum in TF-A: 1 Why workaround's flag is 0? In my mind, all flag should be 1 because there is func to check cpu revisions, such as check_errata_2326639. 43438ad1a patch: +ERRATA_N2_2326639 ?=0 2 After e444763d6(shorten errata flag defines) patch, introduce CPU_FLAG_LIST, Is the workaround's flag change to 1? e444763d6 patch: -ERRATA_N2_2326639 ?=0 +CPU_FLAG_LIST += ERRATA_N2_2326639 Regards, Ming

1 year, 9 months

2
2
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. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 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 2 of 2 defect(s) ** CID 397932: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /lib/extensions/amu/aarch64/amu.c: 212 in amu_init_el3() ________________________________________________________________________________________________________ *** CID 397932: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /lib/extensions/amu/aarch64/amu.c: 212 in amu_init_el3() 206 } 207 } 208 209 void amu_init_el3(void) 210 { 211 uint64_t group0_impl_ctr = read_amcgcr_el0_cg0nc(); >>> CID 397932: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "1 << group0_impl_ctr" with type "int" (32 bits, signed) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 212 uint64_t group0_en_mask = (1 << (group0_impl_ctr)) - 1U; 213 uint64_t num_ctr_groups = read_amcfgr_el0_ncg(); 214 215 /* Enable all architected counters by default */ 216 write_amcntenset0_el0_px(group0_en_mask); 217 ** CID 397931: (DEADCODE) /plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c: 153 in bl31_early_platform_setup2() /plat/imx/imx8m/imx8mn/imx8mn_bl31_setup.c: 150 in bl31_early_platform_setup2() /plat/imx/imx8m/imx8mp/imx8mp_bl31_setup.c: 146 in bl31_early_platform_setup2() ________________________________________________________________________________________________________ *** CID 397931: (DEADCODE) /plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c: 153 in bl31_early_platform_setup2() 147 imx_csu_init(csu_cfg); 148 149 #if IMX_BOOT_UART_BASE 150 console_base = IMX_BOOT_UART_BASE; 151 #endif 152 if (console_base == 0U) { >>> CID 397931: (DEADCODE) >>> Execution cannot reach this statement: "console_base = imx8m_uart_g...". 153 console_base = imx8m_uart_get_base(); 154 } 155 156 console_imx_uart_register(console_base, IMX_BOOT_UART_CLK_IN_HZ, 157 IMX_CONSOLE_BAUDRATE, &console); 158 /* This console is only used for boot stage */ /plat/imx/imx8m/imx8mn/imx8mn_bl31_setup.c: 150 in bl31_early_platform_setup2() 144 mmio_write_32(IMX_IOMUX_GPR_BASE + 0x2c, val | 0x3DFF0000); 145 146 #if IMX_BOOT_UART_BASE 147 console_base = IMX_BOOT_UART_BASE; 148 #endif 149 if (console_base == 0U) { >>> CID 397931: (DEADCODE) >>> Execution cannot reach this statement: "console_base = imx8m_uart_g...". 150 console_base = imx8m_uart_get_base(); 151 } 152 153 console_imx_uart_register(console_base, IMX_BOOT_UART_CLK_IN_HZ, 154 IMX_CONSOLE_BAUDRATE, &console); 155 /* This console is only used for boot stage */ /plat/imx/imx8m/imx8mp/imx8mp_bl31_setup.c: 146 in bl31_early_platform_setup2() 140 mmio_write_32(IMX_IOMUX_GPR_BASE + 0x2c, val | 0x3DFF0000); 141 142 #if IMX_BOOT_UART_BASE 143 console_base = IMX_BOOT_UART_BASE; 144 #endif 145 if (console_base == 0U) { >>> CID 397931: (DEADCODE) >>> Execution cannot reach this statement: "console_base = imx8m_uart_g...". 146 console_base = imx8m_uart_get_base(); 147 } 148 149 console_imx_uart_register(console_base, IMX_BOOT_UART_CLK_IN_HZ, 150 IMX_CONSOLE_BAUDRATE, &console); 151 /* This console is only used for boot stage */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 year, 9 months

1
0
0 0

FYI: Session on OpenCI and MISRA

by Don Harbin

Hi All, I wanted to let you know that next Thursday, July 27th, the TF-A Tech Forum will be hosting a presentation on OpenCI and MISRA presented by Paul Sokolovski of Linaro and Roberto Bagnara from Bugseng. MISRA is being enabled on both TF-A and TF-M in OpenCI, so sending this out to both lists since users in both domains may be interested in the session. Meeting time and dial up info can be found in the TF community calendar located here: https://www.trustedfirmware.org/meetings/ Best Regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

1 year, 10 months

1
0
0 0

The increasing size of BL31

by Okash Khawaja

Hi, Typically, BL31 runs in SRAM which tends to be limited. As we add support for newer architectural features e.g. CCA, general features and standards, the size of BL31 image will grow and become harder to fit in most SRAMs. This email is to share ideas on how to address this problem. A simple approach will be to identify parts of NOBITS ELF sections of BL31 which can be moved out to DRAM. Since NOBITS sections aren't part of the file image, loading and authentication code doesn't have to change. The challenge will be to come up with some criteria to help decide what kind of buffers can be kept in DRAM vs SRAM. Other ideas are also welcome. Please share your thoughts. Thanks, Okash

1 year, 10 months

3
2
0 0

Trusted Firmware-A LTS v2.8.7 Release Announcement

by Okash Khawaja

Hello, Trusted Firmware-A LTS version 2.8.7 is now available. This release contains the following patches. 37bee4983 fix(build): allow warnings when using lld [1] 8782b8849 build(makefile): add helper to detect linker options [2] 1fdc9797f feat(build): add support for new binutils versions [3] bb9d6faa4 feat(errata_abi): errata management firmware interface [4] 4a001ffb6 refactor(errata_abi): factor in non-arm interconnect [5] f718c8723 fix(cpus): workaround platforms non-arm interconnect [6] b8bb1e347 feat(fvp): enable errata management interface [7] 66dab5c69 docs(errata_abi): document the errata abi changes [8] [1] https://review.trustedfirmware.org/q/I70503ad03b3be7a18ffe29ef6f2127c3f4d54… [2] https://review.trustedfirmware.org/q/I236800852ece49948ff53a0b91fddba53c8f0… [3] https://review.trustedfirmware.org/q/I9430f5fa5036ca88da46cd3b945754d62616b… [4] https://review.trustedfirmware.org/q/I70f0e2569cf92e6e02ad82e3e77874546232b… [5] https://review.trustedfirmware.org/q/I47b03eaee5a0a763056ae71883fa30dfacb9b… [6] https://review.trustedfirmware.org/q/I35bd69d812dba37410dd8bc2bbde20d4955b0… [7] https://review.trustedfirmware.org/q/I30877a22ac1348906a6ddfb26f9e8839912d3… [8] https://review.trustedfirmware.org/q/Ieb2144a1bc38f4ed684fda8280842a18964ba… Thanks, Okash

1 year, 10 months

1
0
0 0

Re: Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a@lists.trustedfirmware.org)

by Olivier Deprez

Hi, We have two topics for the upcoming TF-A Tech Forum on Jul, 13th: Certificate signer-id retrieval - Manish Badarkhe * Quick recap * Authentication Mechanism * Role of public key * What is signer ID and its usage? * Design of signer ID retrieval for attestation Updates to EL3 vector entry path to cater for async EA(SError) exceptions - Manish Pandey * Description of error synchronization during EL3 entry. * Go through the implementation of handling of these errors in EL3 for Firmware First Handling (FFH) scenarios. * Reflecting it back in Kernel First Handling (KFH) scenario. * Description of the test scenarios introduced. Regards, Olivier. ________________________________ From: Trusted Firmware Public Meetings Sent: 14 June 2020 19:21 To: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) When: 13 July 2023 17:00-18:00. Where: You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.

1 year, 10 months

1
1
0 0

TF-A Tech Forum Jul 13th

by Olivier Deprez

Olivier Deprez is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://armltd.zoom.us/j/95599443425?pwd=UTRIZ2xSSHJ3K1EreHpkRmlDWmppdz09&f… Meeting ID: 955 9944 3425 Passcode: 572750 --- One tap mobile +442034815240,,95599443425#,,,,*572750# United Kingdom --- Dial by your location • +44 203 481 5240 United Kingdom • +1 408 638 0968 US (San Jose) • +1 646 518 9805 US (New York) • +1 346 248 7799 US (Houston) • +91 806 480 2722 India • +91 116 480 2722 India • +91 224 879 8012 India • +91 406 480 2722 India • +852 5803 3730 Hong Kong SAR • +46 8 4468 2488 Sweden • +47 2400 4735 Norway • +972 3 978 6688 Israel • +353 1 536 9320 Ireland • +36 1 408 8456 Hungary • +49 69 3807 9883 Germany • +33 1 7037 2246 France • +358 3 4109 2129 Finland • +45 32 70 12 06 Denmark • +1 438 809 7799 Canada • +82 2 3143 9611 Korea, Republic of • +65 3158 7288 Singapore • +27 87 550 3946 South Africa • +32 1579 5132 Belgium • +48 22 307 3488 Poland • +386 1600 3102 Slovenia • +60 3 3099 2229 Malaysia • +886 (2) 7741 7473 Taiwan • +81 3 4578 1488 Japan Meeting ID: 955 9944 3425 Passcode: 572750 Find your local number: https://armltd.zoom.us/u/as6SKF17s --- Join by SIP • 95599443425(a)zoomcrc.com --- Join by H.323 • 162.255.37.11 (US West) • 162.255.36.11 (US East) • 115.114.131.7 (India Mumbai) • 115.114.115.7 (India Hyderabad) • 213.19.144.110 (Amsterdam Netherlands) • 213.244.140.110 (Germany) • 103.122.166.55 (Australia Sydney) • 103.122.167.55 (Australia Melbourne) • 209.9.211.110 (Hong Kong SAR) • 149.137.40.110 (Singapore) • 64.211.144.160 (Brazil) • 69.174.57.160 (Canada Toronto) • 65.39.152.160 (Canada Vancouver) • 207.226.132.110 (Japan Tokyo) • 149.137.24.110 (Japan Osaka) Meeting ID: 955 9944 3425 Passcode: 572750

1 year, 10 months

1
0
0 0

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

by Sandrine Bailleux

Hi Manish, I'll answer on behalf of Benjamin and Sieu because I think they are offline now. I reached out to these guys privately this morning and they said they will post patches to fix these defects. Cheers, Sandrine

1 year, 10 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. 5 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 5 of 5 defect(s) ** CID 395330: Code maintainability issues (UNUSED_VALUE) /plat/intel/soc/agilex5/soc/agilex5_clock_manager.c: 182 in get_clk_freq() ________________________________________________________________________________________________________ *** CID 395330: Code maintainability issues (UNUSED_VALUE) /plat/intel/soc/agilex5/soc/agilex5_clock_manager.c: 182 in get_clk_freq() 176 case 0: 177 pllm_reg = CLKMGR_MAINPLL + CLKMGR_MAINPLL_PLLM; 178 pllc_reg = CLKMGR_MAINPLL + main_pllc; 179 pllglob_reg = CLKMGR_MAINPLL + CLKMGR_MAINPLL_PLLGLOB; 180 break; 181 case CLKMGR_PSRC_PER: >>> CID 395330: Code maintainability issues (UNUSED_VALUE) >>> Assigning value "282132672U" to "pllm_reg" here, but that stored value is overwritten before it can be used. 182 pllm_reg = CLKMGR_PERPLL + CLKMGR_PERPLL_PLLM; 183 pllc_reg = CLKMGR_PERPLL + per_pllc; 184 pllglob_reg = CLKMGR_PERPLL + CLKMGR_PERPLL_PLLGLOB; 185 break; 186 default: 187 return 0; ** CID 395329: Code maintainability issues (UNUSED_VALUE) /plat/intel/soc/agilex5/soc/agilex5_clock_manager.c: 183 in get_clk_freq() ________________________________________________________________________________________________________ *** CID 395329: Code maintainability issues (UNUSED_VALUE) /plat/intel/soc/agilex5/soc/agilex5_clock_manager.c: 183 in get_clk_freq() 177 pllm_reg = CLKMGR_MAINPLL + CLKMGR_MAINPLL_PLLM; 178 pllc_reg = CLKMGR_MAINPLL + main_pllc; 179 pllglob_reg = CLKMGR_MAINPLL + CLKMGR_MAINPLL_PLLGLOB; 180 break; 181 case CLKMGR_PSRC_PER: 182 pllm_reg = CLKMGR_PERPLL + CLKMGR_PERPLL_PLLM; >>> CID 395329: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "282132604U + per_pllc" to "pllc_reg" here, but that stored value is overwritten before it can be used. 183 pllc_reg = CLKMGR_PERPLL + per_pllc; 184 pllglob_reg = CLKMGR_PERPLL + CLKMGR_PERPLL_PLLGLOB; 185 break; 186 default: 187 return 0; 188 } ** CID 395328: Control flow issues (DEADCODE) /plat/intel/soc/agilex5/soc/agilex5_clock_manager.c: 181 in get_clk_freq() ________________________________________________________________________________________________________ *** CID 395328: Control flow issues (DEADCODE) /plat/intel/soc/agilex5/soc/agilex5_clock_manager.c: 181 in get_clk_freq() 175 switch (clk_psrc) { 176 case 0: 177 pllm_reg = CLKMGR_MAINPLL + CLKMGR_MAINPLL_PLLM; 178 pllc_reg = CLKMGR_MAINPLL + main_pllc; 179 pllglob_reg = CLKMGR_MAINPLL + CLKMGR_MAINPLL_PLLGLOB; 180 break; >>> CID 395328: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "case 1U:". 181 case CLKMGR_PSRC_PER: 182 pllm_reg = CLKMGR_PERPLL + CLKMGR_PERPLL_PLLM; 183 pllc_reg = CLKMGR_PERPLL + per_pllc; 184 pllglob_reg = CLKMGR_PERPLL + CLKMGR_PERPLL_PLLGLOB; 185 break; 186 default: ** CID 395327: Code maintainability issues (UNUSED_VALUE) /plat/intel/soc/agilex5/soc/agilex5_clock_manager.c: 184 in get_clk_freq() ________________________________________________________________________________________________________ *** CID 395327: Code maintainability issues (UNUSED_VALUE) /plat/intel/soc/agilex5/soc/agilex5_clock_manager.c: 184 in get_clk_freq() 178 pllc_reg = CLKMGR_MAINPLL + main_pllc; 179 pllglob_reg = CLKMGR_MAINPLL + CLKMGR_MAINPLL_PLLGLOB; 180 break; 181 case CLKMGR_PSRC_PER: 182 pllm_reg = CLKMGR_PERPLL + CLKMGR_PERPLL_PLLM; 183 pllc_reg = CLKMGR_PERPLL + per_pllc; >>> CID 395327: Code maintainability issues (UNUSED_VALUE) >>> Assigning value "282132636U" to "pllglob_reg" here, but that stored value is overwritten before it can be used. 184 pllglob_reg = CLKMGR_PERPLL + CLKMGR_PERPLL_PLLGLOB; 185 break; 186 default: 187 return 0; 188 } 189 pllm_reg = CLKMGR_MAINPLL + CLKMGR_MAINPLL_PLLM; ** CID 395326: Uninitialized variables (UNINIT) ________________________________________________________________________________________________________ *** CID 395326: Uninitialized variables (UNINIT) /plat/intel/soc/agilex5/bl2_plat_setup.c: 74 in bl2_el3_early_platform_setup() 68 { 69 static console_t console; 70 71 handoff reverse_handoff_ptr; 72 73 generic_delay_timer_init(); >>> CID 395326: Uninitialized variables (UNINIT) >>> Using uninitialized value "reverse_handoff_ptr.hps_osc_clk_hz" when calling "config_clkmgr_handoff". 74 config_clkmgr_handoff(&reverse_handoff_ptr); 75 mailbox_init(); 76 enable_nonsecure_access(); 77 78 deassert_peripheral_reset(); 79 if (combo_phy_init(&reverse_handoff_ptr) != 0) { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 year, 10 months

2
1
0 0

Abandon inactive patches

by Manish Badarkhe

Hi All, It has happened in the past that developers have posted patches for review, but have been unable to respond to the comments on those patches for a long time and hence, maintainers pitched in and abandoned the patches in such cases. I created a patch [1] to make this official because the coding-review guidelines didn't mention it today. I would appreciate your help in reviewing this patch. Please let us know if you disagree about this approach. If you'd like, we can discuss this upcoming tech-forum. [1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/21848 Thanks, Manish Badarkhe

1 year, 10 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. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 2 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 2 of 2 defect(s) ** CID 394601: Integer handling issues (NO_EFFECT) /lib/xlat_tables_v2/aarch64/xlat_tables_arch.c: 30 in xlat_arch_is_granule_size_supported() ________________________________________________________________________________________________________ *** CID 394601: Integer handling issues (NO_EFFECT) /lib/xlat_tables_v2/aarch64/xlat_tables_arch.c: 30 in xlat_arch_is_granule_size_supported() 24 { 25 unsigned int tgranx; 26 27 if (size == PAGE_SIZE_4KB) { 28 tgranx = read_id_aa64mmfr0_el0_tgran4_field(); 29 /* MSB of TGRAN4 field will be '1' for unsupported feature */ >>> CID 394601: Integer handling issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "tgranx >= 0ULL". 30 return ((tgranx >= ID_AA64MMFR0_EL1_TGRAN4_SUPPORTED) && 31 (tgranx < 8U)); 32 } else if (size == PAGE_SIZE_16KB) { 33 tgranx = read_id_aa64mmfr0_el0_tgran16_field(); 34 return (tgranx >= ID_AA64MMFR0_EL1_TGRAN16_SUPPORTED); 35 } else if (size == PAGE_SIZE_64KB) { ** CID 394600: (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 394600: (NULL_RETURNS) /plat/qemu/qemu_sbsa/sbsa_sip_svc.c: 104 in read_platform_version() 98 int node; 99 100 node = fdt_path_offset(dtb, "/"); 101 if (node >= 0) { 102 platform_version_major = fdt32_ld(fdt_getprop(dtb, node, 103 "machine-version-major", NULL)); >>> CID 394600: (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "fdt_getprop(dtb, node, "machine-version-minor", NULL)" when calling "fdt32_ld". 104 platform_version_minor = fdt32_ld(fdt_getprop(dtb, node, 105 "machine-version-minor", NULL)); 106 } 107 } 108 109 void sip_svc_init(void) /plat/qemu/qemu_sbsa/sbsa_sip_svc.c: 102 in read_platform_version() 96 void read_platform_version(void *dtb) 97 { 98 int node; 99 100 node = fdt_path_offset(dtb, "/"); 101 if (node >= 0) { >>> CID 394600: (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "fdt_getprop(dtb, node, "machine-version-major", NULL)" when calling "fdt32_ld". 102 platform_version_major = fdt32_ld(fdt_getprop(dtb, node, 103 "machine-version-major", NULL)); 104 platform_version_minor = fdt32_ld(fdt_getprop(dtb, node, 105 "machine-version-minor", NULL)); 106 } 107 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 year, 10 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Jun 29, 2023 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with a note: "No topic this week. Cancelling. Please, if anybody has topics to present in other future TF-A Techforums please do reach out to me." TF-A Tech Forum Thursday Jun 29, 2023 ⋅ 4pm – 5pm United Kingdom Time We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

1 year, 10 months

1
0
0 0

Fwd: [Tf-openci-triage] FYI; Cambridge Lab Down

by Don Harbin

FYI to all TF dev teams leveraging Open CI. Best regards, Don ---------- Forwarded message --------- From: Glen Valante via Tf-openci-triage < tf-openci-triage(a)lists.trustedfirmware.org> Date: Fri, 23 Jun 2023 at 08:41 Subject: [Tf-openci-triage] FYI; Cambridge Lab Down To: tf-openci-triage(a)lists.trustedfirmware.org < tf-openci-triage(a)lists.trustedfirmware.org> Hello All; FYI; the Cambridge lab took a serious power hit and is down. They are scrambling to get things back up, but it may take all weekend. Expect LAVA failures and other strange results. Thanks; -g -- [image: Linaro] <http://www.linaro.org> Glen Valante | *Director Program & Project Management* T: +1.508.517.3461 <1617-320-5000> glen.valante(a)linaro.org | Skype: gvalante <callto:gvalante> -- Tf-openci-triage mailing list -- tf-openci-triage(a)lists.trustedfirmware.org To unsubscribe send an email to tf-openci-triage-leave(a)lists.trustedfirmware.org

1 year, 10 months

1
0
0 0

Updated invitation with note: TF-A Tech Forum @ Thu Jul 27, 2023 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated with a note: "Session for 27th July 2023." Changed: description TF-A Tech Forum Thursday Jul 27, 2023 ⋅ 4pm – 5pm United Kingdom Time Topic:MISRA testing in the OpenCI with BUGSENG's ECLAIR Software Verification PlatformPresenters:Roberto Bagnara (BUGSENG) and Paul Sokolovskyy (Linaro)Summary:Overview of MISRA C, BUGSENG's ECLAIR Software Verification Platformand the challenges and solutions for its deployment in the OpenCIContinuous Integration System for the TF-A and TF-M TrustedFirmwareOpensource community projects.We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org lavinia.battaglia(a)bugseng.com paul.sokolovsky(a)linaro.org roberto.bagnara(a)bugseng.com valentina.loggini(a)bugseng.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

1 year, 11 months

1
0
0 0

Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a@lists.trustedfirmware.org)

by Joanna Farley

Currently no topic for this coming week for 15th June. If no topics by Wed 14th I will cancel. Please do reach out to me if there is a topic you would like to present about this week. Joanna From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com When: 16:00 - 17:00 15 June 2023 Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) Regular bi weekly Trustedfirmware.org TF-A TechForum. I host this and its where we go to our community and present/discuss things live in public. Past sessions listed here https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ Mailing list here if you want to subscribe. https://lists.trustedfirmware.org/mailman/listinfo/tf-a Project page here: https://www.trustedfirmware.org/projects/tf-a/ Abhishek never attended any of these. Cancelled if there is no topic to present. From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com When: 16:00 - 17:00 18 June 2020 Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>. ________________________________ From: Trusted Firmware Public Meetings Sent: Sunday, June 14, 2020 5:21:25 PM (UTC) Coordinated Universal Time To: Trusted Firmware Public Meetings; tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) When: Occurs on Thursday every other week from 4:00 PM to 5:00 PM effective 6/18/2020. Europe/London Where: You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.

1 year, 11 months

1
1
0 0

Canceled event: TF-A Tech Forum @ Thu Jun 15, 2023 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled. TF-A Tech Forum Thursday Jun 15, 2023 ⋅ 4pm – 5pm United Kingdom Time We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

1 year, 11 months

1
0
0 0

Re: EHF and SPMD G0 interrupt handling issues

by Olivier Deprez

Hi Varun, * for platforms with SPMD_SPM_AT_SEL2=1. These platforms already use EHF for servicing RAS interrupts today. Can you please have a look at https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16047 ? and https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16047/6/docs… The model, by the FF-A specification, is to permit G0 interrupts to trap to EL3 when NWd runs. A G0 interrupt is routed to a SP through the SPMD/SPMC by the use of EL3-SP direct messages: https://review.trustedfirmware.org/q/topic:%22el3_direct_msg%22+(status:ope… When SEL1/0 runs, G0 interrupts are first trapped to SEL2 and forwarded to EL3 by the FFA_EL3_INTR_HANDLE ABI. I appreciate the legacy capability to let G0 interrupts trap to EL3 while SWd runs is not possible/recommended with this design. This might indeed break earlier implementations; would it make sense aligning SW stacks to the latest of the FF-A spec recommendations? I let Raghu chime in if need be. Regards, Olivier. ________________________________ From: Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 06 June 2023 13:12 To: TF-A Mailing List <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] EHF and SPMD G0 interrupt handling issues Hi, We are in the process of upgrading the downstream TF-A to v2.9 for platforms with SPMD_SPM_AT_SEL2=1. These platforms already use EHF for servicing RAS interrupts today. I noticed that v2.9 has added G0 interrupt handling support to the SPMD. But I think the SPMD support still needs some work as it does not play nicely with EHF. I have found the following issues with the implementation. 1. SPMD and EHF both register handlers for G0 interrupts. But the interrupt management framework only allows one handler for INTR_TYPE_EL3. 2. The RAS framework still uses EHF and the SPMD interrupt handler breaks that functionality. 3. The SPMD handler calls into the platform which does not have any means to invoke the RAS interrupt handler. IMO, we should make SPMD a client of the EHF instead of creating yet another way for interrupt handling. For now, I register SPMD's G0 interrupt handler only if EL3_EXCEPTION_HANDLING=0, as a workaround. Thoughts?

1 year, 11 months

3
9
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. 5 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 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 5 of 5 defect(s) ** CID 385350: Control flow issues (DEADCODE) /plat/xilinx/zynqmp/zynqmp_sdei.c: 19 in arm_validate_ns_entrypoint() ________________________________________________________________________________________________________ *** CID 385350: Control flow issues (DEADCODE) /plat/xilinx/zynqmp/zynqmp_sdei.c: 19 in arm_validate_ns_entrypoint() 13 14 #include <plat/common/platform.h> 15 #include <platform_def.h> 16 17 int arm_validate_ns_entrypoint(uintptr_t entrypoint) 18 { >>> CID 385350: Control flow issues (DEADCODE) >>> Execution cannot reach the expression "-1" inside this statement: "return (entrypoint >= 42947...". 19 return ((entrypoint >= BL31_BASE) && (entrypoint < BL31_LIMIT)) ? -1 : 0; 20 } 21 22 /* Private event mappings */ 23 static sdei_ev_map_t zynqmp_sdei_private[] = { 24 SDEI_DEFINE_EVENT_0(ZYNQMP_SDEI_SGI_PRIVATE), ** CID 385349: (OVERRUN) /plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1404 in intel_fcs_ecdsa_hash_sign_finalize() ________________________________________________________________________________________________________ *** CID 385349: (OVERRUN) /plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1409 in intel_fcs_ecdsa_hash_sign_finalize() 1403 1404 memcpy((uint8_t *) &payload[i], (uint8_t *) hash_data_addr, 1405 src_size); 1406 1407 i += src_size / MBOX_WORD_BYTE; 1408 >>> CID 385349: (OVERRUN) >>> Overrunning array "payload" of 17 4-byte elements by passing it to a function which accesses it at element index 134217732 (byte offset 536870931) using argument "i" (which evaluates to 134217733). 1409 status = mailbox_send_cmd(MBOX_JOB_ID, MBOX_FCS_ECDSA_HASH_SIGN_REQ, 1410 payload, i, CMD_CASUAL, (uint32_t *) dst_addr, 1411 &resp_len); 1412 1413 memset((void *) &fcs_ecdsa_hash_sign_param, 1414 0, sizeof(fcs_crypto_service_data)); /plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1404 in intel_fcs_ecdsa_hash_sign_finalize() 1398 1399 if ((i + ((src_size) / MBOX_WORD_BYTE)) > 1400 FCS_ECDSA_HASH_SIGN_CMD_MAX_WORD_SIZE) { 1401 return INTEL_SIP_SMC_STATUS_REJECTED; 1402 } 1403 >>> CID 385349: (OVERRUN) >>> Overrunning buffer pointed to by "(uint8_t *)&payload[i]" of 68 bytes by passing it to a function which accesses it at byte offset 536870931 using argument "src_size" (which evaluates to 536870912). [Note: The source code implementation of the function has been overridden by a builtin model.] 1404 memcpy((uint8_t *) &payload[i], (uint8_t *) hash_data_addr, 1405 src_size); 1406 1407 i += src_size / MBOX_WORD_BYTE; 1408 1409 status = mailbox_send_cmd(MBOX_JOB_ID, MBOX_FCS_ECDSA_HASH_SIGN_REQ, ** CID 385348: (OVERRUN) /plat/intel/soc/common/sip/socfpga_sip_fcs.c: 2144 in intel_fcs_ecdh_request_finalize() ________________________________________________________________________________________________________ *** CID 385348: (OVERRUN) /plat/intel/soc/common/sip/socfpga_sip_fcs.c: 2144 in intel_fcs_ecdh_request_finalize() 2138 2139 if ((i + ((src_size) / MBOX_WORD_BYTE)) > 2140 FCS_ECDH_REQUEST_CMD_MAX_WORD_SIZE) { 2141 return INTEL_SIP_SMC_STATUS_REJECTED; 2142 } 2143 >>> CID 385348: (OVERRUN) >>> Overrunning buffer pointed to by "(uint8_t *)&payload[i]" of 116 bytes by passing it to a function which accesses it at byte offset 536870931 using argument "src_size" (which evaluates to 536870912). [Note: The source code implementation of the function has been overridden by a builtin model.] 2144 memcpy((uint8_t *) &payload[i], (uint8_t *) pubkey, src_size); 2145 i += src_size / MBOX_WORD_BYTE; 2146 2147 status = mailbox_send_cmd(MBOX_JOB_ID, MBOX_FCS_ECDH_REQUEST, 2148 payload, i, CMD_CASUAL, (uint32_t *) dst_addr, 2149 &resp_len); /plat/intel/soc/common/sip/socfpga_sip_fcs.c: 2147 in intel_fcs_ecdh_request_finalize() 2141 return INTEL_SIP_SMC_STATUS_REJECTED; 2142 } 2143 2144 memcpy((uint8_t *) &payload[i], (uint8_t *) pubkey, src_size); 2145 i += src_size / MBOX_WORD_BYTE; 2146 >>> CID 385348: (OVERRUN) >>> Overrunning array "payload" of 29 4-byte elements by passing it to a function which accesses it at element index 134217732 (byte offset 536870931) using argument "i" (which evaluates to 134217733). 2147 status = mailbox_send_cmd(MBOX_JOB_ID, MBOX_FCS_ECDH_REQUEST, 2148 payload, i, CMD_CASUAL, (uint32_t *) dst_addr, 2149 &resp_len); 2150 2151 memset((void *)&fcs_ecdh_request_param, 0, 2152 sizeof(fcs_crypto_service_data)); ** CID 385347: Control flow issues (NO_EFFECT) /plat/xilinx/zynqmp/zynqmp_sdei.c: 19 in arm_validate_ns_entrypoint() ________________________________________________________________________________________________________ *** CID 385347: Control flow issues (NO_EFFECT) /plat/xilinx/zynqmp/zynqmp_sdei.c: 19 in arm_validate_ns_entrypoint() 13 14 #include <plat/common/platform.h> 15 #include <platform_def.h> 16 17 int arm_validate_ns_entrypoint(uintptr_t entrypoint) 18 { >>> CID 385347: Control flow issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "entrypoint < 0UL". 19 return ((entrypoint >= BL31_BASE) && (entrypoint < BL31_LIMIT)) ? -1 : 0; 20 } 21 22 /* Private event mappings */ 23 static sdei_ev_map_t zynqmp_sdei_private[] = { 24 SDEI_DEFINE_EVENT_0(ZYNQMP_SDEI_SGI_PRIVATE), ** CID 385346: (OVERRUN) /plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1505 in intel_fcs_ecdsa_hash_sig_verify_finalize() ________________________________________________________________________________________________________ *** CID 385346: (OVERRUN) /plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1510 in intel_fcs_ecdsa_hash_sig_verify_finalize() 1504 1505 memcpy((uint8_t *) &payload[i], 1506 (uint8_t *) hash_sig_pubkey_addr, src_size); 1507 1508 i += (src_size / MBOX_WORD_BYTE); 1509 >>> CID 385346: (OVERRUN) >>> Overrunning array "payload" of 52 4-byte elements by passing it to a function which accesses it at element index 134217732 (byte offset 536870931) using argument "i" (which evaluates to 134217733). 1510 status = mailbox_send_cmd(MBOX_JOB_ID, MBOX_FCS_ECDSA_HASH_SIG_VERIFY, 1511 payload, i, CMD_CASUAL, (uint32_t *) dst_addr, 1512 &resp_len); 1513 1514 memset((void *)&fcs_ecdsa_hash_sig_verify_param, 1515 0, sizeof(fcs_crypto_service_data)); /plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1505 in intel_fcs_ecdsa_hash_sig_verify_finalize() 1499 1500 if ((i + ((src_size) / MBOX_WORD_BYTE)) > 1501 FCS_ECDSA_HASH_SIG_VERIFY_CMD_MAX_WORD_SIZE) { 1502 return INTEL_SIP_SMC_STATUS_REJECTED; 1503 } 1504 >>> CID 385346: (OVERRUN) >>> Overrunning buffer pointed to by "(uint8_t *)&payload[i]" of 208 bytes by passing it to a function which accesses it at byte offset 536870931 using argument "src_size" (which evaluates to 536870912). [Note: The source code implementation of the function has been overridden by a builtin model.] 1505 memcpy((uint8_t *) &payload[i], 1506 (uint8_t *) hash_sig_pubkey_addr, src_size); 1507 1508 i += (src_size / MBOX_WORD_BYTE); 1509 1510 status = mailbox_send_cmd(MBOX_JOB_ID, MBOX_FCS_ECDSA_HASH_SIG_VERIFY, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 year, 11 months

1
0
0 0

EHF and SPMD G0 interrupt handling issues

by Varun Wadekar

Hi, We are in the process of upgrading the downstream TF-A to v2.9 for platforms with SPMD_SPM_AT_SEL2=1. These platforms already use EHF for servicing RAS interrupts today. I noticed that v2.9 has added G0 interrupt handling support to the SPMD. But I think the SPMD support still needs some work as it does not play nicely with EHF. I have found the following issues with the implementation. 1. SPMD and EHF both register handlers for G0 interrupts. But the interrupt management framework only allows one handler for INTR_TYPE_EL3. 2. The RAS framework still uses EHF and the SPMD interrupt handler breaks that functionality. 3. The SPMD handler calls into the platform which does not have any means to invoke the RAS interrupt handler. IMO, we should make SPMD a client of the EHF instead of creating yet another way for interrupt handling. For now, I register SPMD's G0 interrupt handler only if EL3_EXCEPTION_HANDLING=0, as a workaround. Thoughts?

1 year, 11 months

1
0
0 0

[CI] New source files have been identified in your patch..

by Marcin Juszkiewicz

I am working on qemu_sbsa platform. We are now adding a way to share data from QEMU via TF-A to EDK2. Standard Arm way - using Secure Monitor Calls. I checked how other platforms do it and wrote a patch [1]. It got reviews, went through CI and all is fine except one thing: New source files have been identified in your patch.. plat/qemu/qemu_sbsa/sbsa_sip_svc.c 1. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/20871 I have read TF-A documentation linked to CI report. This new file is covered already by PLAT=qemu_sbsa build because it is not optional. How to make CI pass? Same problem is with second patch [2] where I added another new source file. 2. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/20953

1 year, 11 months

2
2
0 0

Updated invitation with note: TF-A Tech Forum @ Thu Jun 1, 2023 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated with a note: "Update for Techforum tomorrow...." Changed: description TF-A Tech Forum Thursday Jun 1, 2023 ⋅ 4pm – 5pm United Kingdom Time Topic: SVE Enablement in RMM for Realms. Presenter: Arunachalam GanapathyOverview: This discussion will cover the design and implementation details on how SVE and FP/AdvSIMD state of Non secure world and Realms are managed by RMM.=====================We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org tf-rmm(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

1 year, 11 months

1
0
0 0

TF-A V2.9 Bundle Release

by Joanna Farley

Hi All, We are pleased to announce the formal release of Trusted Firmware-A version 2.9 bundle of project deliverables. This includes Trusted Firmware-A, Trusted Firmware-A Tests, Hafnium and TF-A OpenCI Scripts/Jobs 2.9 releases involving the tagging of multiple repositories. Aligned but not yet part of the release is Trusted Firmware-A Realm Management Monitor v0.3.0. These went live on 23rd May 2023. I would like to thank all of the contributors for their excellent work and achievements since the last release. Thanks Joanna Notable Features of the Version 2.9 Release are as follows: TF-A/EL3 Root World * New Features: * Support for PSCI OS initiated mode * Architecture feature support for FEAT_TCR2, FEAT_GCS, FEAT_HCX, FEAT_SME2, FEAT_PIE/POR, FEAT_MPAM. * System registers access trap handler * Introduction to dynamic detection of features * Refactoring: * Context management * RAS extension exception handling and crash reporting. * Distinguish between BL2 as TF-A entry point or BL2 running at EL3 exception level. * General Support * CPU Support for Chaberton and Blackhawk for TC2023 * Eighteen (18) Errata Mitigations for Cortex X2/X3/A710/A510/A78/A78C and Neoverse N2/V1 family CPU’S * Errata Management Firmware Interface implementation supported for version 1.0 of the public specification TF-A Boot BL1/BL2 * New Feature/Support * Support for Trusted Boot rooted into RSS RoT on TC2022 platform. * Support for PSA attestation scheme with Measured Boot rooted into RSS on TC2022 platform * Migration to mbedTLS 3.x as the default cryptography library retaining backwards compatibility with mbedTLS 2.x * Improvements and hardening of Arm CCA boot and attestation support. * Hardening efforts in the X.509 certificate parser, including a security fix (TFV-10 CVE-2022-47630) Hafnium/SEL2 SPM * FF-A v1.2 ALP0 Specification Early Adoption Support * Implemented ppartition info get ABI using GP registers. * Group0 secure interrupt handling delegation. * Improved console log ABI. * FF-A v1.1 REL0 Specification Support * Interrupt handling (S-EL0 partition signalling, added action to Other-S-Int, allow a physical interrupt to be routed to a specified PE). * Memory sharing (structures updates supporting FF-A backwards compatibility, share/lend/donate memory to multiple borrowers, normal/secure fragmented memory sharing). * Power management (events relayed to the SPMC and removed limitations). * Indirect messaging (buffer synchronization and ownership transfer rules). * General Support * SPMC manifest to declare non-secure and secure system memory address ranges. * Hardened SP manifest memory regions boot time validation. * CI migration to LLVM/clang 15.0.6 * Removal of non-VHE build and test configurations. * Added EL3 SPMC test configurations using the Hafnium's CI infrastructure. TF-A Tests * New Test Support * Errata Management Firmware Interface testing * FF-A v1.1 feature testing * Realm Management Extension feature testing * New Architecture Specific feature testing related to v8.8 * 1 new platform port (RD-N2-Cfg3) TF-RMM/REL2 * New Feature/Support * Added support to create Realms which can make use of SVE, if present in hardware. * Refactor and improved the Stage 1 translation table library lib/xlat API to better fit RMM usage. * Add PMU support for Realms as described by RMM v1.0 Beta0 specification. * Support getting DRAM info from the Boot manifest dynamically at runtime. * RMM can now support the 2nd DDR bank on FVP * Define a unit test framework using CppUTest for RMM. * Added unit tests for granule, slot-buffer and Stage 1 translation table lib xlat. * Improvements to fake-host and unit tests framework. * Build improvements in RMM Platform Support * 1 new platform added, the Allwinner T507 SoC * 26 platforms updated from 14 providers * 17 different driver updates OpenCI * First release done solely relying on Trustedfirmware.org OpenCI Patch Statistics Across all Repositories * 1403 Patches merged since v2.8 November 2022 release Please refer to the TF-A [1], Hafnium [2] and TF-A Tests [3] changelogs for the complete summary of changes from the previous release. TF-A [4], TF-A Test [5], Hafnium [6], TF-A OpenCI Scripts [7] and TF-A OpenCI Jobs [8] repositories are available along with the compatible TF-RMM repository [9] and changelog [10]. [1] https://trustedfirmware-a.readthedocs.io/en/v2.9/change-log.html#id1 [2] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d… [3] https://trustedfirmware-a-tests.readthedocs.io/en/v2.9/change-log.html#vers… [4] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.9 [5] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.9 [6] https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.9 [7] https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.9 [8] https://git.trustedfirmware.org/ci/tf-a-job-configs.git/tag/?h=v2.9 [9] https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/tag/?h=tf-rmm-v0.3.0 [10] https://tf-rmm.readthedocs.io/en/tf-rmm-v0.3.0/about/change-log.html#v0-3-0

1 year, 11 months

1
0
0 0

Welcoming Yann Gautier as a new TF-A maintainer!

by Sandrine Bailleux

Hi, I am pleased to announce that Yann Gautier has now become one of the maintainers for TF-A. This decision is based on Yann's continued efforts and involvement in the project over the years. A patch is under review to reflect this in TF-A documentation: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/21060 Best regards, Sandrine (on behalf of all TF-A maintainers)

1 year, 12 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Jun 1, 2023 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated Changed: description TF-A Tech Forum Thursday Jun 1, 2023 ⋅ 4pm – 5pm United Kingdom Time Provisional topic: SVE enablement for Realms. More details on this nearer the time....=====================We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years

1
0
0 0

Cancellation for TF-A Tech Forum today

by Joanna Farley

Apologies for late notice but the TF-A TechForum is cancelled today. We were hoping a topic would be ready however that is not the case. I try to send notifications a day before but over looked that last night. I will be provisionally updating the session on 2nd June with a topic. Thanks Joanna

2 years

1
0
0 0

Canceled event: TF-A Tech Forum @ Thu May 18, 2023 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled. TF-A Tech Forum Thursday May 18, 2023 ⋅ 4pm – 5pm United Kingdom Time We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years

1
0
0 0

Changelog for v2.9 Release

by Juan Pablo Conde

Hello everyone, Please take a look at the changelog for your respective platforms ahead of the TF-A v2.9 release. The changelog is autogenerated from the commit messages of the patches that have been merged since the v2.8 release. Here's your chance to give us guidance on any small manual adjustments you would like to see. Patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/20975 Rendered Version: https://ci-builds.trustedfirmware.org/static-files/7aZOCOLylZ7jd48oTAPxMxyU… Thanks, Juan Pablo

2 years

2
1
0 0

TF-A v2.9 Release Schedule

by Joanna Farley

TF-A Community, This is to notify that we are planning to target the Trusted Firmware-A 2.9 release during the middle of May 2023 as part of the regular 6 month cadence. The aim is to consolidate all TF-A work since the 2.8 release. As part of this, a release candidate tag is targeted to be created and release activities commence from 10th May 2023 across all TF-A repositories. Essentially we will not merge any major enhancements from this date until the release is made. Please ensure any patches desired to make the 2.9 release are submitted in good time to be complete by 9th May 2023. Any major enhancement patches still open after that date will not be merged until after the release. This will involve the various repositories making up the broader TF-A project including the TF-A mainline, TF-A Tests, Hafnium, TF-A CI Scripts and TF-A CI Job. In addition a TF-RMM repository release will be made that is compatible with v2.9. We will endeavour minimise the disruption on patch merging and complete release activities ASAP after we start normally completing within 7-10 working days. Regards Joanna Farley

2 years

2
1
0 0

Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a@lists.trustedfirmware.org)

by Joanna Farley

Hi Everyone, We cancelled the last TF-A Tech Forum meeting on 4th May as we had no topics. We also at this time don’t have a topic for this coming week TF-A Tech Forum on 18th May. So if anybody has a topic to discuss they can lead please reach out to me. Thanks Joanna From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com When: 16:00 - 17:00 18 May 2023 Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) Regular bi weekly Trustedfirmware.org TF-A TechForum. I host this and its where we go to our community and present/discuss things live in public. Past sessions listed here https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ Mailing list here if you want to subscribe. https://lists.trustedfirmware.org/mailman/listinfo/tf-a Project page here: https://www.trustedfirmware.org/projects/tf-a/ Abhishek never attended any of these. Cancelled if there is no topic to present. From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com When: 16:00 - 17:00 18 June 2020 Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>. ________________________________ From: Trusted Firmware Public Meetings Sent: Sunday, June 14, 2020 5:21:25 PM (UTC) Coordinated Universal Time To: Trusted Firmware Public Meetings; tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) When: Occurs on Thursday every other week from 4:00 PM to 5:00 PM effective 6/18/2020. Europe/London Where: You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.

2 years

1
0
0 0

[RFC] Common API to retrieve pre-allocated share memory for Transfer List

by Raymond Mao

Hi, I am currently doing research to implement the Transfer List to comply with Arm's firmware handoff spec ( https://github.com/FirmwareHandoff/firmware_handoff) in order to have a standardized handoff approach between different firmware stages during boot. The idea is to create a Transfer List in BL2 and cache it into a pre-allocated memory in SRAM that can be shared between BL2 and BL3x. A prototype currently available is creating APIs under qemu platform code to retrieve the pre-defined memory address (The shared memory region is defined in platform_def.h). But I think we need to define a common API for this purpose to support all platforms. Please share your views or any suggestions. Thanks. Regards, Raymond

2 years

3
2
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 384887: Uninitialized variables (UNINIT) /mbedtls/library/x509.c: 1396 in mbedtls_x509_parse_subject_alt_name() ________________________________________________________________________________________________________ *** CID 384887: Uninitialized variables (UNINIT) /mbedtls/library/x509.c: 1396 in mbedtls_x509_parse_subject_alt_name() 1390 if (ret != 0) { 1391 return ret; 1392 } 1393 1394 memset(san, 0, sizeof(mbedtls_x509_subject_alternative_name)); 1395 san->type = MBEDTLS_X509_SAN_OTHER_NAME; >>> CID 384887: Uninitialized variables (UNINIT) >>> Using uninitialized value "other_name". Field "other_name.type_id" is uninitialized when calling "memcpy". [Note: The source code implementation of the function has been overridden by a builtin model.] 1396 memcpy(&san->san.other_name, 1397 &other_name, sizeof(other_name)); 1398 1399 } 1400 break; 1401 /* ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

2 years

1
0
0 0

[RFC] Proposed location to host the firmware handoff specification.

by Jose Marinho

Hi, Arm worked to draft a firmware handoff [1] specification, evolving it based on community feedback. This activity followed the request of some members of the Arm ecosystem [2]. The spec (still at ALP – feedback/comments welcome!) standardizes how information is propagated between different firmware components during boot. The spec hopes to remove the reliance on bespoke/platform-specific information handoff mechanisms, thus reducing the code maintenance burden. The concept of entry types is present in the spec – these are data structure layouts that carry a specific type of data. New types are meant to be added, following the needs and use-cases of the different communities. Thus, these communities should be empowered to request new types! To enable community contributions, the specification must be hosted in a location that is friendly to change requests. We propose to host the spec in trustedfirmware.org (tf.org). Tf.org hosts several open-source projects and already has an open governance model. TF-A, and the associated community, rely on tf.org, and thus are already well equipped to maintain this specification and keep it up to date. Tf.org is agnostic of any downstream projects that would adopt this specification (e.g. U-boot, EDK2, etc.). We welcome the views of the communities and want to understand if there are any strong objections to what’s being proposed! If anyone has objections, we are happy to consider alternatives and associated trade-offs. Regards [1] https://developer.arm.com/documentation/den0135/latest [2] Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages - TF-A - lists.trustedfirmware.org<https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…>

2 years

10
32
1 0

Canceled event: TF-A Tech Forum @ Thu May 4, 2023 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled. TF-A Tech Forum Thursday May 4, 2023 ⋅ 4pm – 5pm United Kingdom Time We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years

1
0
0 0

Allow platforms to deny CPU power off request

by Varun Wadekar

Hello, We have a use case where we want to deny the CPU power off from a certain PE. The current lib/psci does not provide a way for a platform to do this. We have support to return an error from svc_off, but this does not cover the scenario where svc_off is NULL. There are multiple ways of handling this scenario. 1. Introduce a new platform function to check if CPU_OFF is allowed on the core 2. Return an error code from the pwr_domain_off() handler and unwind the CPU_OFF request 3. Something else. Any suggestions? -Varun

2 years

3
4
0 0

Canceled event with note: TF-A Tech Forum @ Thu Apr 20, 2023 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with a note: "The original topic for this TechForum will be held on a future date. No alternative topic has been identified for this session so cancelling." TF-A Tech Forum Thursday Apr 20, 2023 ⋅ 4pm – 5pm United Kingdom Time This session will no longer take place on this date. It will be rescheduled.This slot is now free for another session although nothing has yet been identified.======================================Reserving for a discussion on Signer-id Extraction Design for Manish Badarkhe. More details of this session will be sent closer to the session date.-----------------We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org don.harbin(a)linaro.org moritzf(a)google.com ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years

1
0
0 0

Deprecation of Arm CryptoCell-712/713 drivers

by Sandrine Bailleux

Hello, This is a courtesy notification that we plan to deprecate Arm CryptoCell-712 and CryptoCell-713 drivers in TF-A release v2.9, with the goal to remove their source code from the tree in the following TF-A release after that. This won't affect any upstream platforms beyond Arm Ltd platforms (under plat/arm/ folder). If you have any concerns with this, please raise them by Monday, April 24th. Best regards, Sandrine

2 years

1
0
0 0

TF-A with TRUSTED_BOARD_BOOT failed when using mbedtls-3.4.0

by Chen-Yu Yang

Hi, I'm using TF-A 2.8 on mt7986 board, enable TRUSTED_BOARD_BOOT using mbedtls-3.4.0, TF-A BL2 hanged when loading BL31, it seems that BL2 failed to get correct oid in function get_ext(drivers/auth/mbedtls/mbedtls_x509_parser.c) after calling mbedtls_oid_get_numeric_string mbedtls_oid_get_numeric_string in 3.4.0 uses %c to print part of oid, (https://github.com/Mbed-TLS/mbedtls/blob/v3.4.0/library/oid.c#L864) but seems that ATF libc's snprintf doesn't support %c format, which causes mbedtls_oid_get_numeric_string to return incorrect oid oid_str dump in get_ext oid_str=%c.49.6.1.4.1.4128.2100.1 (mbedtls_oid_get_numeric_string) oid_str=1.3.6.1.4.1.4128.2100.1 (TRUSTED_FW_NVCOUNTER_OID) I try to change snprintf format %c to %u in mbedtls_oid_get_numeric_string, TF-A boots successfully Thanks

2 years, 1 month

3
3
0 0

Re: Question about the Memory Encryption Engine on FVP

by Sandrine Bailleux

Hi, Concerning the following Fast Model Component: https://developer.arm.com/documentation/100964/1121/Fast-Models-components/… This component is already publicly documented although it is not integrated yet into the AEM FVP. The main usage is to identify software mis-programming, where the same Physical address is accessed through more than one Physical Address Space (PAS). As such, it is intended as a development / debugging tool only. If such a mis-programming scenario happened then the memory page corresponding to the accessed physical address would get corrupted. Notice memory encryption is not yet supported in TF-A's SW stacks. You won't find a reference for this feature in TF-A / TF-a-tests just now. Best regards, Sandrine

2 years, 1 month

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Apr 20, 2023 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated Changed: description TF-A Tech Forum Thursday Apr 20, 2023 ⋅ 4pm – 5pm United Kingdom Time This session will no longer take place on this date. It will be rescheduled.This slot is now free for another session although nothing has yet been identified.======================================Reserving for a discussion on Signer-id Extraction Design for Manish Badarkhe. More details of this session will be sent closer to the session date.-----------------We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org don.harbin(a)linaro.org moritzf(a)google.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 1 month

1
0
0 0

Is TF-A going to support MBEDTLS_AESCE_C option in mbedtls-3.4.0?

by Chen-Yu Yang

Hi, I'm working in TF-A 2.8 with mbedtls, I notice that mbedtls-3.4.0 starts to support AES crypto extension(MBEDTLS_AESCE_C) for some security reasons, I upgrade mbedtls from 2.28.0 to 3.4.0, and try to enable MBEDTLS_AESCE_C in TF-A. I fail to compile mbedtls aesce.c in TF-A build environment. I use CROSS_COMPILE=aarch64-gcc-7.5.0. It seems that AESCE needs some std libraries(e.g. arm_neon.h) supported by aarch64 gcc, while TF-A disables std libraries, and some compile flags(e.g. -mgeneral-regs-only) are conflict with current TF-A. I wonder is TF-A going to support MBEDTLS_AESCE_C option? Thanks

2 years, 1 month

2
2
0 0

Question about the Memory Encryption Engine on FVP

by Chenxu Wang

Hi all, I want to test the memory encryption functions in Arm CCA. Currently, I find that Arm FVP supports a PVMemoryProtectionEngine. Thus, can I use this engine in current TF-A or TF-A-Tests? If yes, how to use this engine? Sincerely, WANG Chenxu

2 years, 1 month

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Apr 20, 2023 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated Changed: description TF-A Tech Forum Thursday Apr 20, 2023 ⋅ 4pm – 5pm United Kingdom Time Reserving for a discussion on Signer-id Extraction Design for Manish Badarkhe. More details of this session will be sent closer to the session date.-----------------We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 1 month

1
0
0 0

TF-A code documentation

by Michal Simek

Hi, I have talked to a couple of people to figure out what TF-A project is using for code documentation. Because I see at least in our platform that our documentation is somewhere between doxygen and kernel-doc but actually with a lot of mismatches. Sanbrine mentioned sending an email to the mailing list to start to have discussion about it. That's why I want to know the official code documentation format and how we should be checking that everything matches to make sure that documentation is not out of sync from code itself. When this is clear I will ask my team to fix all these issues. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

2 years, 1 month

5
8
0 0

FEAT_SVE enablement in TF-A

by Jayanth Dodderi Chidanand

Hello all, We are sending this note to notify you of one of the breaking changes related to the enablement of FEAT_SVE in TF-A. This mainly impacts platforms which are configurable (FVP, QEMU, Total Compute). FEAT_SVE has now been moved under the Feature detection mechanism wherein a CPU feature macro can have 3 possible states * 0: FEAT_STATE_DISABLED * 1: FEAT_STATE_ALWAYS ( Always enabled, no runtime check) * 2: FEAT_STATE_CHECK (Dynamically check based on ID registers, done each time when feature registers are being accessed) For platforms which have a single configuration, it's better to choose either disabled or enabled (as it is a bit faster as there is no dynamic check). For platforms which can have different HW configurations, it makes sense to put them under FEAT_STATE_CHECK(=2), so that they will boot with any configuration of HW. Keeping this in mind, all configurable platforms (FVP, QEMU, TC) have been modified to adopt dynamic detection(FEAT_STATE_CHECK) for FEAT_SVE. [1] SVE Patch Reference: [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/20306 Best regards, Jayanth

2 years, 1 month

1
0
0 0

rk3399 issue: no DMA in Linux with mainline TF-A and U-Boot SPL

by Christoph Fritz

Hello Kever, on a rk3399, booting current U-Boot SPL with mainline TF-A leads to missing DMA (and no sound) on Linux. However, when using rockchip its so called mini-loader (rk3399_miniloader_v1.26.bin) and their BL31 (rk3399_bl31_v1.35.elf) to boot, DMA works perfectly fine. Tested on a custom rk3399 board and on ROCK Pi4. Attached to this mail are two boot logs with some debug prints: - good_amba_log.txt (DMA works) - no_amba_log.txt (no DMA device) The main difference I can spot between the two logs is that on Linux (drivers/amba/bus.c) AMBA_CID (0xb105f00d) cannot be found. Instead, only some CORESIGHT_CIDs (presumably for debugging) and four 0x00000000 CIDs are detected. As a result, the "PL330 DMAC-241330" driver does not load. My theory is that DMA needs to be allowed somewhere in the undocumented syscon- registers, similar to what U-Boot is already doing for eMMC in arch_cpu_init() (arch/arm/mach-rockchip/rk3399/rk3399.c). Any ideas? Or maybe I'm just missing some configuration? Since multiple software projects are involved (TF-A, OP-TEE, U-Boot, Linux), I Cc'ed a bit. Thanks -- Christoph

2 years, 1 month

3
4
0 0

Canceled event with note: TF-A Tech Forum @ Thu Apr 6, 2023 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with a note: "No topics this week so cancelling." TF-A Tech Forum Thursday Apr 6, 2023 ⋅ 4pm – 5pm United Kingdom Time We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 1 month

1
0
0 0

TF-A TechForum 6th April

by Joanna Farley

Hi Folks, I’ve just updated the Techforum session information (Slides and Recording) from the RAS Handing session last week on https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ which will be deployed soon once the patch is approved. The next TF-A Tech forum is due on Thursday 6th April at 4pm BST. At this time I don’t have any topics for that session. If anybody in the community has anything they would like to present please do reach out to me. Thanks Joanna

2 years, 1 month

1
0
0 0

Workaround for ARM Cortex-A78AE Erratum 1941500 is not enabled

by matthias.rosenfelder＠nio.io

Hi, according to the current erratum document for the ARM Cortex-A78AE [0], the workaround for erratum 1941500 says: "This erratum can be avoided by setting CPUECTLR_EL1[8] to 1." However, the current code on branch "master" (git hash 5906d97a832b6f6 ) at https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/cpus/a… executes a "bic" instruction with an immediate, which is a synthetic instruction to clear the bit, instead of setting it. Moreover, the comment above says "Set bit 8 in ECTLR_EL1", which is inconsistent to the code. The equivalent workaround for the Cortex-A78 non-AE (erratum 1941498) uses the correct "orr" (bitwise-or) instruction to set the bit: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/cpus/a… Please confirm if this is an error. Thank you. Best Regards, Matthias [0] "Arm Cortex-A78AE (MP105) Software Developer Errata Notice", Document version: v14.0, Document ID: SDEN-1707912, https://developer.arm.com/documentation/SDEN1707912/latest

2 years, 1 month

1
0
0 0

Question about configuring Juno R2 GPU SMMU in TF-A

by Chenxu Wang

Hi all, I try to enable the smmu of Juno R2 development board but face two great challenges. I am working on them and I still need some hints. Here are my problems: 1. By reading the SMMUv1 manuals I find that several registers are related to secure state (e.g., SMMU_sCR0). But in my TF-A and the latest version I can only find the SMMUv3 configurations, not SMMUv1/2. Thus, how to config these registers? Any reference? 2. For the non-secure GPU SMMU regs, I try to map and read them based on the Juno R2 manual. I know the GPU SMMU is a MMU-400, and its mmio is in 0x2b40_0000 - 0x2b40_ffff. Then in EL1 I first do ioremap(0x2b400000,0x10000) and then ioread32(). However I get the SError as "Bad mode in Error handler detected on CPU1, code 0xbf000002". I also try to do it in EL2 (with a hvc call and reading in the handler), but cannot get any valid number and still get SError when exiting EL2. But when I access the other smmus (e.g., a PCIe SMMU, in 0x2b50_0000), it works fine. Thus, is there something to prevent the Non-secure World from accessing the GPU SMMU MMIO? My source codes are downloaded from the arm-reference-platforms, in which Linux is v4.14.59 and TF-A is v2.1. Can someone help me? Sincerely, WANG Chenxu

2 years, 1 month

1
1
0 0

Updated invitation with note: TF-A Tech Forum @ Thu Mar 23, 2023 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated with a note: "Updated agenda" Changed: description TF-A Tech Forum Thursday Mar 23, 2023 ⋅ 4pm – 5pm United Kingdom Time Discussion Topic: RAS Refactoring Presented by: Manish Pandey and Soby MathewTopics to be discussed 1. Introduction to philosophies of handling RAS errors(FFH/KFH) 2. Discussing exceptions caused by synchronization barriers at execption boundries 3. Refactoring and enhancements in TF-A(along with various build macros) 4. Tests introduced 5. Future work----------------We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org don.harbin(a)linaro.org bpeckham(a)google.com moritzf(a)google.com kh3195(a)columbia.edu View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 1 month

1
0
0 0

About Unmask the SError in serror_aarch64

by Ming Huang

Hi Jeenu, vector_entry serror_aarch64 + msr daifclr, #DAIF_ABT_BIT Why the SError must be unmask in serror_arrch64? We found unmask SError will lead TF-A panic with output "Unhandled Exception in EL3". --------------------------------------------------------------------------------------log: Detected DPC, skip AER core[64] mm(925) return: 2 [ 109.883159] pcieport 0000:b0:00.0: DPC: containment event, status:0x0005 source:0xb000 [ 109.891195] pcieport 0000:b0:00.0: DPC: ERR_FATAL detected [ 109.896776] igb 0000:b1:00.0 ens51f0: PCIe link lost [root(a)localhost.localdomain /root/hm] #[ 110.068410] pcieport 0000:b0:00.0: pciehp: Slot(51): Link Down/Up ignored (recovered by DPC) [ 110.076988] igb 0000:b1:00.0: enabling device (0000 -> 0002) Unhandled Exception in EL3. x30 = 0x00000000ff013b84 x0 = 0x0000000000000000 x1 = 0xffff800011e7500c x2 = 0x0000000000000000 x3 = 0xffff800011e75004 x4 = 0xffff800011a82000 x5 = 0x000000000000000c x6 = 0x00000000000000fb x7 = 0xffff800011441e80 x8 = 0x0000000000000000 x9 = 0xffff800010655270 x10 = 0x00000000ffff8000 x11 = 0xffff800011701e80 x12 = 0x0000000000000001 x13 = 0xffff800010c08cc0 x14 = 0x0000000000000c80 x15 = 0x0000000000000001 x16 = 0x67692070552f6e77 x17 = 0x7228206465726f6e x18 = 0x0000000000000030 x19 = 0xffff04000032de80 x20 = 0xffff04000032dea0 x21 = 0xffff040002c2f000 x22 = 0xffff000809280000 x23 = 0xffff00080a217800 x24 = 0xffff800011853f80 x25 = 0xffff040002c2e0c8 x26 = 0xffff800011923de8 x27 = 0xffff000817fc8740 x28 = 0x0000000000000000 x29 = 0xffff80001e9ebb00 scr_el3 = 0x000000000403073d sctlr_el3 = 0x0000000030cd183f cptr_el3 = 0x0000000000000100 tcr_el3 = 0x0000000080843514 daif = 0x00000000000003c0 mair_el3 = 0x00000000004404ff spsr_el3 = 0x00000000624002cd elr_el3 = 0x00000000ff013d84 ttbr0_el3 = 0x00000000ff093001 esr_el3 = 0x00000000be000011 far_el3 = 0x7abce97e90b5fee1 spsr_el1 = 0x0000000000000000 elr_el1 = 0x0000000000000000 spsr_abt = 0x0000000000000000 spsr_und = 0x0000000000000000 spsr_irq = 0x0000000000000000 spsr_fiq = 0x0000000000000000 sctlr_el1 = 0x0000000030d00800 actlr_el1 = 0x0000000000000000 cpacr_el1 = 0x0000000000000000 csselr_el1 = 0x0000000000000002 sp_el1 = 0x0000000000000000 esr_el1 = 0x0000000000000000 ttbr0_el1 = 0x0000000000000000 ttbr1_el1 = 0x0000000000000000 mair_el1 = 0x0000000000000000 amair_el1 = 0x0000000000000000 tcr_el1 = 0x0000000000000000 tpidr_el1 = 0xffff800f6e6f1000 tpidr_el0 = 0x00000000f6e1ede0 tpidrro_el0 = 0x0000000000000000 par_el1 = 0xff000000f4214b80 mpidr_el1 = 0x0000000081000000 afsr0_el1 = 0x0000000000000000 afsr1_el1 = 0x0000000000000000 contextidr_el1 = 0x0000000000000000 vbar_el1 = 0x0000000000000000 cntp_ctl_el0 = 0x0000000000000000 cntp_cval_el0 = 0x000000010b938e04 cntv_ctl_el0 = 0x0000000000000000 cntv_cval_el0 = 0x0000000000000000 cntkctl_el1 = 0x0000000000000000 sp_el0 = 0xffff000809280000 isr_el1 = 0x0000000000000040 cpupwrctlr_el1 = 0x0000000000000000 -------------------------------------------------------------------------------------- Remove the above line(mask SError), TF-A continue execute with some useful output. --------------------------------------------------------------------------------------log: Detected DPC, skip AER core[64] mm(925) return: 2 [ 278.193642] pcieport 0000:b0:00.0: DPC: containment event, status:0x0005 source:0xb000 [ 278.201680] pcieport 0000:b0:00.0: DPC: ERR_FATAL detected [ 278.207262] igb 0000:b1:00.0 ens51f0: PCIe link lost [root(a)localhost.localdomain /root/hm] #[ 278.378416] pcieport 0000:b0:00.0: pciehp: Slot(51): Link Down/Up ignored (recovered by DPC) [ 278.386993] igb 0000:b1:00.0: enabling device (0000 -> 0002) ERROR: Excepton received on 0x81000000, spsr_el3:82401009,reason:0 esr_el3:0xbe000411 ue_cnt:0x0 Exception Class = 2f: SError interrupt. Print cpu register: |-elr_el3: ffff8000106550f8 |-far_el3: 7abce97e92b57fe1 |-scr_el3: 403073d |-sctlr_el3: 30cd183f |-LR: ffff800010655270 |-SP: ffff0008091d1200 |-x0: 0000000000000000 x1: ffff800011e7500c |-x2: 0000000000000000 x3: ffff800011e75004 |-x4: ffff800011a82000 x5: 000000000000000c |-x6: 00000000000000fb x7: ffff800011441e80 |-x8: 0000000000000000 x9: ffff800010655270 |-x10: 00000000ffff8000 x11: ffff800011701e80 |-x12: 0000000000000001 x13: ffff800010c08cc0 |-x14: 0000000000000c80 x15: 0000000000000001 |-x16: 67692070552f6e77 x17: 7228206465726f6e |-x18: 0000000000000030 x19: ffff040005a7e100 |-x20: ffff040005a7e120 x21: ffff040001e9f000 |-x22: ffff0008091d1200 x23: ffff000809cdf800 |-x24: ffff800011853f80 x25: ffff040001e9e0c8 |-x26: ffff800011923de8 x27: ffff000807549140 |-x28: 0000000000000000 x29: ffff80001cc9bb00 INFO: mpidr:81000000, stop s-wtd. Return to lower EL by SDEI ->Core[0](0x81000000) received intr=0(exception), cnt=0x1 RTC: 2023-03-08 10:15:38 ERROR: Excepton received on 0x81000000, spsr_el3:620003c5,reason:2 esr_el3:0x80000011 ue_cnt:0x0 Exception Class = 17: SMC instruction execution in AArch64 state, when SMC is not disabled. Print cpu register: |-elr_el3: ff01a430 |-far_el3: 7abce97e92b57fe1 |-scr_el3: 4000e3c |-sctlr_el3: 30cd183f |-LR: ff208570 |-SP: ff631d80 |-x0: 00000000c4000061 x1: 0000000000000000 |-x2: 0000000000000000 x3: 0000000000000000 |-x4: 0000000000000000 x5: 0000000000000000 |-x6: 0000000000000000 x7: 0000000000000000 |-x8: 0000000000000000 x9: 0000000000000002 |-x10: 0000000000000002 x11: 0000000000000000 |-x12: 0000000000000002 x13: 0000000000000002 |-x14: 0000000000000001 x15: 00000000000000ff |-x16: 00000000ffa97650 x17: 00000000000000f8 |-x18: 0000000000000000 x19: 0000000000000001 |-x20: 0000000000000000 x21: 00000000ff20c240 |-x22: 00000000ff20c25a x23: 8000000000000009 |-x24: 0000000076726473 x25: 00000000ff20d1e0 |-x26: 00000000ffbdcc10 x27: 00000000ff631ef8 |-x28: 00000000ffbff328 x29: 00000000ff631d80 INFO: mpidr:81000000, stop s-wtd. Have report fatal Exception Class = 17: SMC instruction execution in AArch64 state, when SMC is not disabled. Print cpu register: -------------------------------------------------------------------------------------- Regards, Ming

2 years, 1 month

3
4
0 0

commit to tf-a-ci-scripts

by Ruth Glushkin

I have already created patch in tf-a for review, added plat Nuvoton npcm845x, gerrit topic No. 20088. How should I upload a scripts patch to support new added platform? In documentation I didn't found how exactly should I send a scripts patch. Thank you in advance. Margarita Glushkin

2 years, 1 month

3
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A