build/tools/amebasmart: Change KM4 version print location

[jwei5]

• Change KM4 version print location from CA32 to KM4
• KM4 version info will be printed during wifi_netmgr_utils_init, similar to rtl8721

[jwei5]

Log of KM4 version info before PR:

Manufacturer : 239 memory type : 64 capacity : 24
/dev/smart0p6 is mounted successfully @ /mnt
board_initialize: KM4_version km0_application_ver_ad855c0_2024/02/01-13:58:48
se_ameba_hal_init: [AMEBA_WRAPPER]ameba/security_ameba_wrapper_tz.c:59
[rtl_readdecrypt_factorykey] Exit form here!se_ameba_hal_read_storage: [AMEBA_WRAPPER]ameba/security_ameba_wrapper_tz.c:698
se_ameba_hal_read_storage: RTL SE failed (6)
os_do_appstart: [set_security_level] error ret : 1
[RTK] Link callback handles: registered
[OTP-I] OTP_LogicalMap_Read: data end at address=84
Initializing WIFI ...
[RTW]: ** Band = 2.4G and 5G **
System Information:
Version:
Platform: 3.1 Binary: 200204
Commit Hash: 7f2d5a9

Log of KM4 version after changing print location:

Manufacturer : 239 memory type : 64 capacity : 24
/dev/smart0p6 is mounted successfully @ /mnt
se_ameba_hal_init: [AMEBA_WRAPPER]ameba/security_ameba_wrapper_tz.c:59
[rtl_readdecrypt_factorykey] Exit form here!se_ameba_hal_read_storage: [AMEBA_WRAPPER]ameba/security_ameba_wrapper_tz.c:698
se_ameba_hal_read_storage: RTL SE failed (6)
os_do_appstart: [set_security_level] error ret : 1
[RTK] Link callback handles: registered
[OTP-I] OTP_LogicalMap_Read: data end at address=84
Initializing WIFI ...
[RTW]: ** Band = 2.4G and 5G **
System Information:
Version:
Platform: 3.1 Binary: 200204
Commit Hash: 7f2d5a9
Build User: root@jw
Build Time: 2024-02-15 14:20:21 +08
System Time: 15 Feb 2024, 00:00:00 [s] UTC Hardware RTC Support
TASH>>Hello, World!!
wm_test start
TASH>>
TASH>>[WT][T15] wifi manager test!! wm_test_main:947
[WT][T15] wait func signal wm_test_main:958
[WT][T16] --> _wt_start:290
[WM][INFO] --> wifi_manager_init 101
[WM][INFO] handle request state(UNINITIALIZED) evt(CMD_INIT)
[RTK] Link callback handles: registered
KM4 version: km4_application_ver_f98f43e_2024/02/15-14:11:28
[WT][T16] <-- _wt_start:297
[WT][T16] send func signal _wt_process:938

[sunghan-chang]

@jwei5 Could you let us know why you change the location of printing?
Even if KM4 prints the log, no log mix at all?

[jwei5]

Hi @sunghan-chang, for the current print location in TizenRT, the KM4 version info is hard coded and has to be manually changed when KM4 image is updated.
In KM4 image, the version info is automatically generated and tracked, so printing it in KM4 ensures that the version info is accurate and does not need to be manually updated. The log is only printed during wifi_netmgr_utils_init (inside wifi_on), when tested on hello config there is no issue of mixed logs.
Is there a concern for mixed logs if we print it during wifi_netmgr_utils_init?

[sunghan-chang]

@jwei5 At init time, we print some mandatory logs. They should not be corrupted. Because of this, we got many issues on RTL8721CSM. If it does not cause log mixed, anywhere is ok. Please make sure that this log does not cause log mixed.
(If km4 accesses the uart directly without critical section, definitely it will cause the issue)

[sunghan-chang]

@jwei5 Any update? and need to resolve the conflicts

[jwei5]

Hi @sunghan-chang, we have an IPC function that is able to send selected KM4 logs over to CA32 to print. To prevent mixed logs, we can use this function to print the version information in CA32 instead of printing at KM4 directly. However, this function is controlled over at CA32 TizenRT and it is currently disabled by default. It needs to enabled by calling inic_ipc_buffered_printf_set_np_enable(1). Is it ok if we enable this function by default?

[sunghan-chang]

@jwei5 I don't know what it is. Without pros and cons of enabling, I can't give you my opinion. Why do you keep it disabled until now?

[sunghan-chang]

@jwei5 Whatever it is, we should prevent log mixed. That's the most important thing.

[gexuyan]

@jwei5 Whatever it is, we should prevent log mixed. That's the most important thing.

Dear @sunghan-chang , then we will enable ipc buffered print and update the PR, thank you

[sunghan-chang]

@jwei5 @gexuyan With the ipc buffered print, no performance degradation?

[gexuyan]

@jwei5 @gexuyan With the ipc buffered print, no performance degradation?

@sunghan-chang , your concern makes sense, we will only use ipc buffered print for this km4 version print, so will not cause performance degradation.

[jwei5]

Hi @sunghan-chang , I have made the changes for printing KM4 version info to use ipc buffered print to prevent the issue of mixed logs. The KM4 version info will be printed during system boot up:

[sunghan-chang]

@jwei5 @gexuyan Thank you for update. But could you check belows?

1. Is there no other logs in KM4? I mean, is it enough to change only this to ipc for preventing log mix?
2. If there is no other logs in KM4, is it ok to check any KM4 issue? Are you able to guarantee perfect KM4?
3. If not, how will you print others?

[jwei5]

Hi @sunghan-chang , there are other logs in KM4 which are mostly warning/error logs that are only printed when there is an issue with the KM4 driver. For these logs, they are currently printed in KM4.
If mixed log is a concern after init stage, we can check if we can use IPC print for all logs in KM4.