app: smc: sample.yaml: add fixes for app.recovery and pinctrl#938
app: smc: sample.yaml: add fixes for app.recovery and pinctrl#938ShLiTT wants to merge 3 commits intotenstorrent:mainfrom
Conversation
Upstream uart driver checks `clock-frequency` first, and if present, it uses it directly and skips the `clocks` property path. Before the driver expects an array with a valid `CLK_ID`, but `sysclk` has `#clock-cells = <0>` (no cells). Signed-off-by: Sherry Li <xiaoruli@tenstorrent.com>
`recovery.conf` has been moved under `sysbuild/` Signed-off-by: Sherry Li <xiaoruli@tenstorrent.com>
add a new workflow to test smc app build-only tests Signed-off-by: Sherry Li <xiaoruli@tenstorrent.com>
|
I'm trying to think if this PR is actually hiding a problem. If we have code in SMC that doesn't compile, then why do we even have that code in the first place? |
The goal is to introduce a smc build only workflow that can test tracing and shell.
|
|
Maybe we can add this build test to the |
|
I like the idea of putting it under build-fw workflow. @alexapostolu has a good point though- we do want to test compilation of certain options we enable with firmware for debugging/recovery firmware itself, but we don't need to compile esoteric configurations for the sake of it. We currently have pinctrl off in the production application, right? So may be no need to keep the code around to enable it until we decide to switch it in in production. |
3 participants
Before we didn't check build-only tests under
app/smcin our ci workflows, and there are bugs inapp.recoveryandpinctrl.Changes in this PR: