bridge: debug: Always try to exit debug first #60
Conversation
The Debug UART inside the BMC can be brought into a stuck state by sending a lot of requests quickly or after sending a broken command. Sending 2 exit commands at 115200 baud before trying to enter debug mode again seems to mitigate this issue. Signed-off-by: Sarah Mädel <[email protected]>
|
|
||
| // Escape character should cancel previous commands | ||
| // q will exit debug mode | ||
| rc = prompt_write(&ctx->prompt, "\x1Bq\r\n\x1Bq\r\n", strlen("\x1Bq\r\n\x1Bq\r\n")); |
There was a problem hiding this comment.
Hmm, I was trying to avoid injecting things into the BMC console if I could help it. Maybe we could add this behind a --recover or --force-quit option so we can at least control when it is run?
There was a problem hiding this comment.
Hm, yup... But now we have that problem with the command line argument parsing again 😄
Would you implement this as a flag in the main culvert.c getopt()?
There was a problem hiding this comment.
Yes, that's a fair criticism :D Maybe let's leave this to lie for a bit, I'm thinking about what we can do to improve the command line parsing experience.
There was a problem hiding this comment.
Does anyone object if I cherry-pick this patchset to #73 to improve the argument parsing with my ongoing changes? ^^
There was a problem hiding this comment.
Especially if you give it a new CLI flag, absolutely, please! 😃
The Debug UART inside the BMC can be brought into a stuck state by sending a lot of requests quickly or after sending a broken command.
Sending 2 exit commands at 115200 baud before trying to enter debug mode again seems to mitigate this issue.
Sidenote: I wonder how that Debug UART is actually realized inside the ASPEED. I'm almost guessing it's a little 8051 core or something similar, which might crash here. I would expect to see a little bit different behaviour from a hardware state machine.