Repository navigation
Fix the Renode test: working dmlog_monitor, attached from the start of the boot - #102
Merged
Merged
Conversation
The Renode test builds dmlog_monitor for the host, and that no longer linked: dmod made Dmod_Malloc/Dmod_Free macros (requiring DMOD_CURRENT_ALLOCATOR on the system side) and dropped the plain functions, while the monitor used them without including dmod.h. The monitor never started, so no firmware logs were captured and the test reported "DMOD-Boot started ... NOT FOUND". The bump also brings dmlog's switch to dmtty 1.1's ioctl numbers for Dmod_Stdin_Get/SetFlags. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JWVYTSBnZLbpDqp7X1sknv
monitor-gdb built the host monitor itself (FetchContent of dmod plus a full build), so it attached about a minute after Renode had started the firmware. The boot log is far larger than the 8 KiB dmlog ring by then, so "DMOD-Boot started" had already been overwritten. Build the monitor together with the firmware, so it attaches right after Renode starts and follows the boot from the first line. Also bump dmlog for the monitor's GDB polling fix: it used to interrupt the target every 10 ms, which under Renode kept the boot from progressing at all once the monitor had caught up with the ring. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JWVYTSBnZLbpDqp7X1sknv
JohnAmadis
changed the title
choco-technologies/dmlog#56 is merged; fb05e82 is its merge commit, with the same tree as the branch commit tested here. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JWVYTSBnZLbpDqp7X1sknv
Building the monitor up front was not enough: on the CI runners Renode boots the firmware far enough in the ~5 s before monitor-gdb attaches to wrap the 8 KiB dmlog ring, so "DMOD-Boot started" was already gone. Add DMBOOT_RENODE_WAIT_FOR_GDB (default OFF): the generated Renode script then leaves out 'start', so the machine stays paused until a GDB client continues it. The Renode test turns it on, so the monitor follows the boot from its first line no matter how fast the runner is. The default connect workflow still starts the firmware right away. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JWVYTSBnZLbpDqp7X1sknv
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Test Renode Simulationhas been red on master. Three things stacked up:dmlog_monitordid not link. dmod'sDmod_Malloc/Dmod_Freebecame macros requiringDMOD_CURRENT_ALLOCATOR, and the monitor used them without includingdmod.h. Result:undefined reference to 'Dmod_Malloc', and no logs at all.DMOD-Boot started, mostly dmdevfs progress lines, and the dmlog ring is 8 KiB. Renode started the firmware immediately.monitor-gdbattached only after building the monitor (about a minute), and even with the monitor pre-built, the CI runner wraps the ring in the ~5 s before the monitor attaches.Fix
lib/dmlogto dmlog masterfb05e82, the merge of Fix the monitor for the current dmod API and for Renode's GDB server dmlog#56, which fixes (1) and (3). The bump also brings dmlog master's switch to dmtty 1.1 ioctl numbers.DMBOOT_RENODE_WAIT_FOR_GDB(defaultOFF). When it is on, the generatedrenode.rescleaves outstart, so the machine stays paused until a GDB client continues it;monitor-gdbdoes that when it connects. The defaultconnectworkflow is unchanged.scripts/run_renode_tests.shturns the option on, and buildsbuild_dmlog_monitorandextract_ring_buffer_configtogether with the firmware. The monitor then follows the boot from its first line, no matter how fast the runner is. This fixes (2).The Docker image (
chocotechnologies/dmboot:1.0.0) does not need rebuilding.Verification
scripts/run_renode_tests.shrun locally insidechocotechnologies/dmboot:1.0.0on this branch passes twice:DMOD-Boot started ... ✓ FOUND,Renode emulation tests PASSED. The captured log starts at== dmlog ver. 1.0 ==, the firmware's first line. The generatedrenode.rescstill ends withstartwhen the option is OFF.Two local-only workarounds, not part of the diff: dmf-get and Renode traffic went through the local proxy's CA, and Renode's SVD download from
dl.antmicro.comis blocked in that sandbox, so theApplySVDline was stripped from the container's platform file.Not addressed here, since it's not part of this failure: the emulated boot also logs
Stack overflow detected in task: consoleanddmdma: stream 3 already open.🤖 Generated with Claude Code
https://claude.ai/code/session_01JWVYTSBnZLbpDqp7X1sknv