Title: Regression in petalinux-config --get-hw-description: .bit and other files are not re-extracted in PetaLinux 2024.2

[tanosy263]

Describe the bug
In PetaLinux 2024.2, the petalinux-config --get-hw-description command no longer re-extracts the contents of the provided .xsa file (such as .bit, psu_init.*, and drivers/) if the hardware file has not changed, even when explicitly requested.

This behavior is a regression compared to PetaLinux 2022.2, where the same command would extract all hardware-related files from the .xsa file every time it was run, regardless of whether the .xsa had changed.

Steps to reproduce

Create a new PetaLinux project using 2024.2

Run petalinux-config --get-hw-description path/to/hw.xsa — .bit and other files are extracted into project-spec/hw-description/

Run the same command again with the same .xsa — only system.xsa is updated; all other files are deleted and not re-extracted

Expected behavior
The command should consistently extract all relevant files from the .xsa file on every invocation, or at least preserve previously extracted files if no change is detected. Deleting them without re-extracting breaks user workflows.

Actual behavior
Files like .bit, psu_init.c, and drivers/ are deleted on subsequent runs but not re-extracted unless the .xsa file is changed (MD5 checksum differs). This leads to an incomplete hardware description folder.

Impact
This change breaks existing workflows that rely on deterministic extraction of hardware contents or version-based automation. It also risks silently removing required files from the project.

Version info

PetaLinux version: 2024.2

Behavior confirmed to work correctly in: 2022.2

petalinux-config in 2024.2 is now a Python script, whereas it was a binary in 2022.2

Suggested resolution

Either restore the previous behavior by always extracting all .xsa contents

Or skip deletion of the hw-description/ folder when no change is detected (i.e., VALIDATE_HW_CHKSUM=1)

Alternatively, provide an override option such as --force to allow users to control this behavior

Let me know if you'd like this message formatted for GitHub Markdown, or if you'd like to include log output / diffs.