Skip to content

Conversation

jwnrt
Copy link

@jwnrt jwnrt commented Oct 3, 2025

GPIO has a chardev interface for driving the inputs into QEMU, however we're currently clearing our memory of these lines at reset.

For bootstrapping Earlgrey we need to assert some pins and then reset the chip. I have restored the input lines on reset so we remember which pins were asserted.

Signed-off-by: James Wainwright <james.wainwright@lowrisc.org>
@rivos-eblot
Copy link

rivos-eblot commented Oct 3, 2025

I start to think that we are trying to solve these reset issues the wrong way.
I do not think it is the GPIO that should not be reset. There should be some persistent state, but that is not part of the GPIO that does get reset if I'm not mistaken.

The state is preserved on the board/chip package where some signal are maintained. On reset, the GPIO gets reset as other IPs, then samples what's on the external pins. The more we deviate from the actual HW, the more we'll get into trouble.

I think what is really needed here is a padring which should be part of the SoC and that the GPIO must be connected to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants