-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Set up targeting idle eth cores on BH - won't enable because of hang debug #14817
Conversation
3b0ff59
to
259a471
Compare
259a471
to
d9c8f61
Compare
8f95992
to
5ef063a
Compare
3c8dc89
to
f11c6b5
Compare
34fc134
to
778dc55
Compare
778dc55
to
7c23c0a
Compare
@@ -74,6 +74,8 @@ HalCoreInfoType create_active_eth_mem_map() { | |||
.fw_base_addr = eth_l1_mem::address_map::FIRMWARE_BASE, | |||
.local_init_addr = eth_l1_mem::address_map::FIRMWARE_BASE, // this will be uplifted in subsequent commits | |||
// enabling active erisc | |||
.fw_launch_addr = 0xFFB14008, | |||
.fw_launch_addr_value = (uint32_t)eth_l1_mem::address_map::FIRMWARE_BASE, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor: wasn't clear what "fw_launch_addr_value" was in other contexts, maybe "fw_launch_jmp_insn" (yes, ties the use to the name, but I think that's ok)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm the reason I didn't add jump
into the name is because we don't always write the jump instruction at this value. like this case above we just write FW base addr directly to the PC
7c23c0a
to
8460546
Compare
9ade451
to
de63dbe
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
… the HalJitBuildConfig
de63dbe
to
34b61de
Compare
@@ -145,7 +145,7 @@ static void RunTest(WatcherFixture* fixture, IDevice* device) { | |||
k_id_s = ""; | |||
} | |||
expected = fmt::format( | |||
"Device {} ethnet core(x={:2},y={:2}) virtual(x={:2},y={:2}): {}, X, X, X, X rmsg:* " | |||
"Device {} ethnet core(x={:2},y={:2}) virtual(x={:2},y={:2}): {}, {}, X, X, X rmsg:* " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"ethnet" typo 😬
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I saw this in a couple places in debug_tools folder, I think thats the shorthand used
Ticket
Closes #14653
No ticket, removing workaround required that was impacting p100 CI
What's changed
CI FW has been downgraded so this going back to original behaviour
09/01/25 This PR was updated to not enable BH eth cores because of a hang when running dispatch out of idle eth + async FD. This is being debugged separately and once it has been root-caused/worked around will enable targeting eth cores.
Checklist
Old CI when eth cores were enabled
09/01/25 CI without enabling eth cores