Implement ota and seclink adaption about BK7239N by ziliguo · Pull Request #7146 · Samsung/TizenRT

ziliguo · 2026-02-06T07:59:22Z

1、Ota adaption to support a single binary file executes in both partition_A and partition_B;
2、Adapt the ed25519 for sec link test;
3、Clean driver code of previous chipset;
4、Tick compensation improvment during interrupt disabled as required;
5、Some bug fix and modification according to the comments of PR review.

-Resolved the 5 issues of previous PR7137:

Watchdog reset test fail;
UART 1 test fail;
OTA test fail for encrypted binaries;
seclink test;
secure storage test: when raw flash read is done in SS, crash is not happening issue.

-Notice:
BK7239N has 4 projects currently. All four projects below are for MP(mass production) chipset. The two projects for previous chipset have been removed in this PR.

"1. xip_all_mp" ==> project for MP chipset. Option C: TFM/Kernel/Common/APP1/APP2 runs on Flash;
"2. loadable_apps_mp" ==> project for MP chipset. Option B: TFM/Kernel runs on Flash, Common/APP1/APP2 runs on PSRAM;
"3. hello_mp" ==> project for MP chipset. Flat build;
"4. loadable_all_mp" ==> project for MP chipset. Option D: TFM/Kernel/Common/APP1/APP2 runs on PSRAM.

sunghan-chang · 2026-02-06T08:15:09Z

+	/* Ensure f_priv is cleared even if _files_close didn't clear it
+	 * (e.g., when filep2->f_inode was NULL)
+	 */
+	filep2->f_priv = NULL;


@Taejun-Kwon @gidori98 Please review fs changes.

looks good to me.

sunghan-chang · 2026-02-06T08:15:37Z

@@ -292,7 +292,8 @@
 											 *      erased state of the MTD cell */
 #define MTDIOC_ERASESECTORS	_MTDIOC(0x0006)	/* IN: Pointer to mtd_erase_s structure
 											 * OUT: None */
-
+#define MTDIOC_OTATESTBASE	_MTDIOC(0x0007)	/* IN:  None


@jylee9613 Could you check what this is?

It seems to necessary ioctl to read the headers of common and app1 when encryption is enabled.
But I also curious why it needs. If calling MTDIOC_OTATESTBASE ioctl, s_ota_test_flag is set, and read flash directly without flash instruction.
@CYG1124 Why this process is needed? If it is necessary process, then we need to fix binary manager process too.

Hello @jylee9613

Samsung's OTA test process is as follows:
first, copy a specified length of the image from the flash execution area (e.g., Area A) to the flash area to be activated (e.g., Area B).
During this process, the size and version number of the image to be copied must be read from the head in the flash execution area (Area A); (for non-encrypted images, this process is fine).
However, for encrypted images, the image stored in the flash execution area (Area A) is encrypted, so the head information read directly is encrypted (the image size and version number are encrypted), meaning that the obtained image size and version number are incorrect, which will ultimately affect the data copy.

Thanks

This is not allowed.
MTDIOC need to be defined if any ioctl is related to mtd operation.
OTA test is not part of mtd operation (struct mtd_dev_s)
So to test OTA in application, you should use open / read / write of block driver.
MTD Layer is totally hided from application.

Hello @Taejun-Kwon

For OTA testing of encrypted-only images, we need the upper layer to pass a status value to the lower-layer flash driver to distinguish whether the data read from the flash is plaintext or ciphertext. May I ask if there is a better way to pass parameters from the application layer to the lower layer?

ssize_t bk_flash_read(size_t addr, void *buf, size_t length)
{
// printf("func :%s, line :%d, addr :%x, length :%d\n", func, LINE, addr, length);
#if (!CONFIG_SPE)
if (bk_addr_is_kernel(addr)) {
bk_security_flash_read_bytes(addr, (uint8_t *)buf, length);
SCB_CleanInvalidateDCache();
}
#if CONFIG_BUILD_PROTECTED
#if CONFIG_FLASH_ENCRYPT_ENABLE
else if (bk_addr_is_app_or_common(addr)) {
if(s_ota_test_flag) {
bk_data_read_app_or_common(addr, (uint8_t *)buf, length);
} else {
bk_instruction_read_app_or_common(addr, (uint8_t *)buf, length);
}
}
#endif
#endif
else
#endif
{
bk_flash_read_bytes(addr, (uint8_t *)buf, length);
}

return BK_OK;

}

Thanks

Hello @jylee9613 and @Taejun-Kwon

Because there is an issue in Samsung's OTA test code regarding the upgrade of encrypted images, it cannot upgrade encrypted images.

To verify the OTA functionality for encrypted images, I made minimal modifications to Samsung's OTA test code to ensure that the Beken encrypted image upgrade function works properly. The ioctl operation is only used in the test code and is not required in the official OTA process.

Samsung colleagues in India helped verify the upgrade of encrypted images, and this modification solution is fine.

If you assess that this modification is not suitable for merging, we can revert the OTA test code changes. Samsung colleagues can maintain this OTA modification patch, and apply it when testing the encrypted OTA functionality.

Thanks

@ziliguo - You can remove OTA related changes from this PR in TizenRT test code. We will raise another PR for that after discussing with @jylee9613

sunghan-chang · 2026-02-06T08:16:13Z

@@ -241,6 +241,14 @@ def make_user_binary_header():
        file_size = fp.tell()
        fp.close()

+        if util.get_value_from_file(cfg_path, "CONFIG_ARCH_CHIP_ARMINO=").rstrip('\n') != 'None':


Please check here as well @jylee9613

Looks good to me. It is necessary to align header with 32-bytes if apply flash encryption.

sunghan-chang · 2026-02-06T08:16:32Z

@@ -33,30 +33,37 @@
    os.makedirs(output_folder)

 CONFIG_ARCH_BOARD = util.get_value_from_file(cfg_file, "CONFIG_ARCH_BOARD=").rstrip('\n')
+board_name = CONFIG_ARCH_BOARD[1:-1]


@ewoodev need to check

sunghan-chang · 2026-02-06T08:18:55Z

@aashish-l Could you review fs changes?
@amandeep-samsung Need to review samsung header script, ld script generation and other common part

jylee9613 · 2026-02-06T08:49:51Z


 #define CHECKSUM_SIZE               4
 #define BUFFER_SIZE                 512
+#define USER_SIGN_APPEND_SIZE       32


Unused value. Please remove it.

jylee9613 · 2026-02-06T08:52:25Z

+}
+#endif
+
+#if CONFIG_FLASH_ENCRYPT_ENABLE


Why is this condition needed?
CONFIG_USER_SIGN_PRETEND_SIZE is related to signature, and it's not related to encryption.

Hello @jylee9613

1、This condition is required when testing encrypted image upgrades;
2、moreover, encrypted images must be signed beforehand.
Thanks

About 2、moreover, encrypted images must be signed beforehand.
I heard that the signature is verified before decrypting the image. Then it means that image should be encrypted first and signature is created after encryption.
So I understood that signature header is not encrypted.
If I misunderstood something, please let me know.

Hello @jylee9613

According to Samsung's process, the secure image creation process is as follows:

(1) Steps to create a secure kernel image: First, sign the kernel image (and add the signature header), then encrypt the signed kernel image, and finally add Samsung's kernel_head (16 bytes) to the encrypted kernel image;

(2) Steps to create secure common/app1/app2 images: First, add Samsung's common_head/user_head to the common/app1/app2 images, then sign the images with the Samsung head added (and add the signature header); finally, encrypt the signed common/app1/app2 images;

In general: the process of creating secure images is to first complete the signing, and then encrypt the signed images; the verification process is the reverse, first decrypting and then verifying the signature. Since the decryption process is automatically performed by the hardware, it is transparent to the software, so what is observed is that the verification process is executed first;

Thanks

jylee9613 · 2026-02-06T08:53:09Z


+#ifdef CONFIG_BINARY_SIGNING
+	if ((strcmp(binary_info->name, "kernel") != 0)) {
+		ret = lseek(read_fd, CONFIG_USER_SIGN_PREPEND_SIZE, SEEK_SET);


Is kernel signature header size is same as app1/common?
Actually, CONFIG_USER_SIGN_PREPEND_SIZE is not intended for kernel.

hello @jylee9613 :

1、kernel signature header size is different form app1/common;
2、yes ,you're right .CONFIG_USER_SIGN_PREPEND_SIZE is not intended for kernel,just for common/app1/app2;
3、so , i use if ((strcmp(binary_info->name, "kernel") != 0)) control it ；

Thanks

Oh I missed !=... Thank you for explaination!

sunghan-chang · 2026-02-09T05:54:24Z

+}
+#endif
+
+#if CONFIG_FLASH_ENCRYPT_ENABLE


This uses #if instead of #ifdef. Could you confirm this config is defined 0 or 1? I mean this should be defined always regardless of the value. Then, #if is right.

Hello @sunghan-chang ,
Thanks for your suggestion. The #ifdef is better. I will update it now.
By the way, for unencrypted firmware, this CONFIG_FLASH_ENCRYPT_ENABLE macro is 'n'; for encrypted firmware, this macro is 'y'.

It is Done now.

jylee9613 · 2026-02-09T06:32:54Z

+        if util.get_value_from_file(cfg_path, "CONFIG_ARCH_CHIP_ARMINO=").rstrip('\n') != 'None':
+            padding_size = 32 - ((header_size + file_size + 4) % 32)
+            print("Beken user binary header padding")
+            print("crc_size: %d, header_size: %d, file_size: %d, padding_size: %d" % (4, header_size, file_size, padding_size))
+            if padding_size > 0:
+                data += b'\xff' * padding_size
+                file_size += padding_size
+


Why these paddings are needed in both common and app? Is it related to flash encryption?
To encrypt/decrypt the image with header?

Hello @jylee9613

Regarding this issue, it is because our hardware encryption and decryption require 32-byte alignment. Therefore, before signing the image, it needs to be aligned to 32 bytes, so that during encryption it can be encrypted directly without needing any additional padding.

Thanks

jylee9613 · 2026-02-09T07:17:47Z

+	ST_EXPECT_EQ(SECLINK_OK, sl_generate_key(g_hnd, HAL_KEY_ED_25519, SL_TEST_ECDH_KEY_SLOT_A));

-	ST_EXPECT_EQ(SECLINK_OK, sl_generate_key(g_hnd, HAL_KEY_ECC_25519, SL_TEST_ECDH_KEY_SLOT_B));
+	ST_EXPECT_EQ(SECLINK_OK, sl_generate_key(g_hnd, HAL_KEY_ED_25519, SL_TEST_ECDH_KEY_SLOT_B));


Please revert this change for x25519 test.
x25519 uses montgomery curve, so HAL_KEY_ECC_25519 is correct key type.

Please revert this change for x25519 test. x25519 uses montgomery curve, so HAL_KEY_ECC_25519 is correct key type.

we will rever it. @jylee9613

jylee9613 · 2026-02-09T07:18:15Z

+	ST_EXPECT_EQ(SECLINK_OK, sl_get_key(g_hnd, HAL_KEY_ED_25519, SL_TEST_ECDH_KEY_SLOT_A, &g_key_a));

-	ST_EXPECT_EQ(SECLINK_OK, sl_get_key(g_hnd, HAL_KEY_ECC_25519, SL_TEST_ECDH_KEY_SLOT_B, &g_key_b));
+	ST_EXPECT_EQ(SECLINK_OK, sl_get_key(g_hnd, HAL_KEY_ED_25519, SL_TEST_ECDH_KEY_SLOT_B, &g_key_b));


Same as above (please revert this change)

Same as above (please revert this change)

we will rever it. @jylee9613

jylee9613 · 2026-02-09T07:18:39Z

@@ -568,7 +568,9 @@ TESTCASE_SETUP(ed25519_sign)
 	hal_data pub_key = {&g_ed25519_pubkey, sizeof(g_ed25519_pubkey), NULL, 0};
 	hal_data priv_key = {&g_ed25519_privkey_only, sizeof(g_ed25519_privkey_only), NULL, 0};

-	ST_EXPECT_EQ(0, sl_set_key(g_hnd, HAL_KEY_ECC_25519, RW_SLOT_ENTRY, &pub_key, &priv_key));
+	ST_EXPECT_EQ(0, sl_set_key(g_hnd, HAL_KEY_ED_25519, RW_SLOT_ENTRY, &pub_key, &priv_key));
+	sl_test_print_buffer(g_ed25519_pubkey, sizeof(g_ed25519_pubkey), "yxt ed25519 pubkey");
+	sl_test_print_buffer(g_ed25519_privkey_only, sizeof(g_ed25519_privkey_only), "yxt ed25519 privkey");


Same as above (please revert this change)

Same as above (please revert this change)

I understand that this place needs to be changed to "HAL_KEY_ED_25519". Please confirm.
I will delete this debugging log, thanks @jylee9613

Hello @jylee9613 ,
I have a question:
for tp1x, you asked to change the key from HAL_KEY_ECC_25519 -> HAL_KEY_ED_25519
when we change the key, the test are passed in realtek.
So why do we have to change for tp1x plus ? shouldn't it be same for both the boards ?
I think this change should be for sign and verify api's only. please correct me if I am wrong.

Same as above (please revert this change)

I understand that this place needs to be changed to "HAL_KEY_ED_25519". Please confirm. I will delete this debugging log, thanks @jylee9613

I'm sorry this is my mistake.. ed25519_sign need to use HAL_KEY_ED_25519. Thank you!

Same as above (please revert this change)

I understand that this place needs to be changed to "HAL_KEY_ED_25519". Please confirm. I will delete this debugging log, thanks @jylee9613

I'm sorry this is my mistake.. ed25519_sign need to use HAL_KEY_ED_25519. Thank you!

Done, thank you for confirming.

Hello @jylee9613 , I have a question: for tp1x, you asked to change the key from HAL_KEY_ECC_25519 -> HAL_KEY_ED_25519 when we change the key, the test are passed in realtek. So why do we have to change for tp1x plus ? shouldn't it be same for both the boards ? I think this change should be for sign and verify api's only. please correct me if I am wrong.

I asked to change HAL_KEY_ECC_25519 to HAL_KEY_ED_25519 only for ed25519 sign/verify.
TP1x already passed the testcase for x25519 sign/verify because the key type was HAL_KEY_ECC_25519.
But ed25519 sign/verify returns HAL_BAD_KEY_PAIR in TP1x because of wrong key type.

No, it's not same.
x25519_compute uses random key generated by sl_generate_key

jylee9613 · 2026-02-09T07:41:04Z


 #define CHECKSUM_SIZE               4
 #define BUFFER_SIZE                 512
+#define USER_SIGN_APPEND_SIZE       32


Unused variable.

Got it. It is Done now.

Taejun-Kwon · 2026-02-09T08:19:59Z

@@ -292,7 +292,8 @@
 											 *      erased state of the MTD cell */
 #define MTDIOC_ERASESECTORS	_MTDIOC(0x0006)	/* IN: Pointer to mtd_erase_s structure
 											 * OUT: None */
-
+#define MTDIOC_OTATESTBASE	_MTDIOC(0x0007)	/* IN:  None


This is not allowed.
MTDIOC need to be defined if any ioctl is related to mtd operation.
OTA test is not part of mtd operation (struct mtd_dev_s)
So to test OTA in application, you should use open / read / write of block driver.
MTD Layer is totally hided from application.

Taejun-Kwon · 2026-02-09T08:24:17Z

+	/* Ensure f_priv is cleared even if _files_close didn't clear it
+	 * (e.g., when filep2->f_inode was NULL)
+	 */
+	filep2->f_priv = NULL;


looks good to me.

Taejun-Kwon · 2026-02-09T08:24:25Z

@@ -461,6 +467,7 @@ void files_release(int fd)
 		list->fl_files[fd].f_oflags = 0;
 		list->fl_files[fd].f_pos = 0;
 		list->fl_files[fd].f_inode = NULL;
+		list->fl_files[fd].f_priv = NULL;


looks good to me.

ewoodev · 2026-02-09T08:26:21Z

-        with open(output_folder + "app1_" + str(app1_ota_idx) + ".ld", "w") as ld :
-            print("OTA index in app1 ", app1_ota_idx)
-            ld.write(ld_script_content)
+        if is_rtl_mode:


Could you please let me know why it is needed?

What is difference or what point is sepecific chipset?

this changes are for support only single ota ld script? (not dual A/B) with flash controller dynanic addressing

Hello @ewoodev :

Because BEKEN's XIP solution supports position-independent upgrades, for common: only one ld file (common_0.ld) needs to be generated, so the compiled common_bk7239n_200204.trpk binary can be executed in both common region A and common region B; the same applies to app2 and app1 (only one app1_0.ld and app2_0.ld need to be generated).

However, when compiling the RTL8730E XIP project, two ld files are generated (common_0.ld & common_1.ld), and the same goes for app2 and app1 (app1_0.ld & app1_1.ld and app2_0.ld & app2_1.ld will be generated).

Therefore, I optimized the mkldscript.py script to support both BEKEN's XIP OTA upgrade solution and RTL8730E's XIP OTA upgrade solution.

Thanks

Thank you for improve script

we can have sevel chipset.
Could you please just rename is_dual_ld_mode? is_dual_image_mode?

Hello @ewoodev

Thank you for your suggestion, we will fix it right away.

Thanks

Hello @ewoodev ,
It is Done now.
We have changed it as "is_dual_ld_mode". PLease help check if anything is missed. Thank you.

ewoodev · 2026-02-10T07:05:24Z

+    if board_name == "rtl8730e":
        sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '../../build/tools/amebasmart/gnu_utility')))
        from loadable_xip_elf import get_offset
        offset_shift = get_offset()
-        offset = int(CONFIG_FLASH_VSTART_LOADABLE, 16) - int(offset_shift, 16)
-        loadable_start_offset = offset
-    elif CONFIG_ARCH_BOARD[1:-1] == "bk7239n":
+        loadable_start_offset = int(CONFIG_FLASH_VSTART_LOADABLE, 16) - int(offset_shift, 16)
+    elif board_name == "bk7239n":
        loadable_start_offset = int(CONFIG_FLASH_VSTART_LOADABLE, 16)
-        offset = loadable_start_offset
    else:
        # For other boards, use CONFIG_FLASH_VSTART_LOADABLE directly
        loadable_start_offset = int(CONFIG_FLASH_VSTART_LOADABLE, 16)
        offset = loadable_start_offset


How about set is_dual_ld_mode here?
because already this is chipset sepecific code. we want to minimize chipset sepecific code in this file.

Hello @ewoodev

Okay, thank you for your suggestion. We will make the changes right away.

Thanks

- clean source code of previous chipset - achieve location independence for app and commonfirmware - remove unused log - optimize the ota test code - fix reboot reason test fail issue - fix adv/conn ind report issue - adapt the ed25519 with libsodium

- fix ota issue - adaption for seclink test

- clean project of previous chipset - enable reboot reason test case for loadapp

- beken tfm prehandle partition python script update

- fix tick compensation issue during interrupt disbale period, with the RTC device - update the flash adaption code to optimize the ota test code

… case - In concurrent scenarios (such as the UART test and iperf running concurrently in Scenario 3), the file descriptor may be in an inconsistent state(f_priv has a value but f_inode is NULL), leading to the ASSERT at os/fs/smartfs/smartfs_smart.c:line887 problem. - Problem Flow: file_dup2 calls _files_close(filep2) (line 313) _files_close only cleans up f_priv if f_inode != NULL (lines 132-150) If filep2->f_inode is NULL, f_priv is not cleaned up. Subsequently, filep2->f_inode is set to inode (line 329) When smartfs_dup is called (line 340), the assertion fails because newp->f_priv != NULL.

- use board_name to distingush different board type - add padding for common partition

- adapt for ed25519 of security wrapper

- clean useless projects for beken BK7239N chipset in circleci/config.yml

sunghan-chang · 2026-02-11T12:17:55Z

@amandeep-samsung Could you leave test result here?
@jylee9613 Could you finish review by tomorrow morning?
@ziliguo Once @jylee9613 approves, I will merge this. And then, let's merge the branch to the master. Could you discuss it with @amandeep-samsung ?
After that, we can start to test iot features.

amandeep-samsung · 2026-02-11T12:41:23Z

Test results: 

UART test						       PASS
Log UART test						       PASS
Reboot reason test					       PASS
Watchdog RESET test				       PASS
Power Management (Power Gating)	       PASS
RTC test							       PASS
RTC (msec resolution)				       PASS

Security HAL test					       PASS
Security SECLINK test (driver)		               PASS
Wi-Fi							       PASS
BLE								       PASS
	
download speed					       PASS

Binary Encryption (secure Boot)		        PASS
Bootloader Logs						PASS

binary structure changes 			        PASS
 - XIP_ALL,
 - Loadable All and
 - Loadable Apps	
	
Secure Storage/world test			        PASS

seokhun-eom24 · 2026-02-12T00:10:04Z

+# For dual mode, initialize offset with loadable_start_offset
+# For generic mode, offset starts from 0 and will be reset when encountering first loadable partition
+if is_dual_ld_mode:
    offset = loadable_start_offset


In previous code, for every case offset is same with loadable_start_offset.
Is there any reason for excute offset = loadable_start_offset only for is_dual_ld_mode.
In line 58, even if not dual_ld_mode, we're setting offset = loadable_start_offset.

@amandeep-samsung
Could you please consider in sepearted your new PR?

@amandeep-samsung Could you please consider in sepearted your new PR?

Thank you for your suggestion. We will update it in the new PR later.

seokhun-eom24 · 2026-02-12T00:15:29Z

+            if not ld_generated["common"] and CONFIG_SUPPORT_COMMON_BINARY == 'y':
+                common_start = hex(offset + 0x10 + signing_offset)
+                common_size = hex(part_size - 0x10 - signing_offset)
+                with open(output_folder + "common_0.ld", "w") as ld :


How about print log like app1 and app2.

@amandeep-samsung
Could you please consider in sepearted your new PR?

@amandeep-samsung Could you please consider in sepearted your new PR?

We will add it in the new PR later.

jylee9613

All security features confirmed except OTA. (It'll be updated to next PR)

sunghan-chang reviewed Feb 6, 2026

View reviewed changes

jylee9613 reviewed Feb 6, 2026

View reviewed changes

ziliguo force-pushed the BK7239N_dev branch from 387dd9f to c87bbef Compare February 6, 2026 09:14

sunghan-chang reviewed Feb 9, 2026

View reviewed changes

jylee9613 reviewed Feb 9, 2026

View reviewed changes

ziliguo force-pushed the BK7239N_dev branch from c87bbef to e8ad3ab Compare February 9, 2026 08:14

jylee9613 reviewed Feb 9, 2026

View reviewed changes

Taejun-Kwon reviewed Feb 9, 2026

View reviewed changes

ewoodev reviewed Feb 9, 2026

View reviewed changes

ziliguo force-pushed the BK7239N_dev branch 2 times, most recently from f54ce2c to 43e515f Compare February 10, 2026 04:41

ewoodev reviewed Feb 10, 2026

View reviewed changes

ziliguo force-pushed the BK7239N_dev branch from 43e515f to d6755f1 Compare February 10, 2026 10:42

ziliguo added 9 commits February 11, 2026 10:46

apps/examples: adaption for seclink test and fix ota issue

9434f45

- fix ota issue - adaption for seclink test

build/configs/bk7239n: clean project of previous chipset

6f8632f

- clean project of previous chipset - enable reboot reason test case for loadapp

build/tools/armino: beken partition python script update

20729fc

- beken tfm prehandle partition python script update

os/arch/arm/src/armino: fix tick compensation and ota issue

93e942e

- fix tick compensation issue during interrupt disbale period, with the RTC device - update the flash adaption code to optimize the ota test code

os/tools: use board_name to distingush different board type

ada8745

- use board_name to distingush different board type - add padding for common partition

os/se/armino: adapt for ed25519 of security wrapper

8b80b65

- adapt for ed25519 of security wrapper

circleci/config.yml: clean useless projects for previous chipset

502ca13

- clean useless projects for beken BK7239N chipset in circleci/config.yml

ziliguo force-pushed the BK7239N_dev branch from d6755f1 to 502ca13 Compare February 11, 2026 02:54

ewoodev approved these changes Feb 11, 2026

View reviewed changes

sunghan-chang approved these changes Feb 11, 2026

View reviewed changes

amandeep-samsung approved these changes Feb 11, 2026

View reviewed changes

seokhun-eom24 reviewed Feb 12, 2026

View reviewed changes

jylee9613 approved these changes Feb 12, 2026

View reviewed changes

ewoodev merged commit a943bb7 into Samsung:BK7239N_Support Feb 12, 2026
21 checks passed

Conversation

ziliguo commented Feb 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sunghan-chang commented Feb 6, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jylee9613 Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

CYG1124 Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ziliguo Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ziliguo commented Feb 6, 2026 •

edited

Loading

jylee9613 Feb 9, 2026 •

edited

Loading

CYG1124 Feb 9, 2026 •

edited

Loading

ziliguo Feb 9, 2026 •

edited

Loading

ziliguo Feb 9, 2026 •

edited

Loading