I was trying to debug while only some of the uart interrupt vectors seem to work on the microblaze. I thought it would be nice to compile qemu with debug flags.
Also eventually I would like to develop my own firmware driver emulation for qemu. Which would probably require me to have my own qemu fork anyways. I think just integrating all the rtems patches into a fork and changing the remote would work, but maybe im am missing something. Thanks for the reply. If I get some free time to hack on this and figure anything out i will let you know. Sam. On Wed, Feb 14, 2024 at 2:37 PM Kinsey Moore <kinsey.mo...@oarcorp.com> wrote: > > On Wed, Feb 14, 2024 at 9:14 AM Sam Price <thesampr...@gmail.com> wrote: >> >> I was wondering if you had any notes on your process of working with >> qemu in the rtems builder. >> I imagine you have your own xilinx qemu forked to work on, and then >> take the patches and integrate them into the rsb builder? > > > Nothing so fancy. Here's my current setup for this: > * have a checkout of the qemu-xilinx repo to generate patches > * copy generated patches into the rsb/rtems/patches directory > * set up the RSB recipe to pull in the patch with appropriate SHA512 > * attempt build > > This lets me pull in a custom patch for testing without actually hosting it > somewhere. I've been wanting an easier way to do this since it's a pain to > push patches elsewhere for test hosting before actually pushing it to the > ticket, but this is the compromise I've settled on that smooths out the > workflow just enough. Ideally, I'd be able to specify a local file path for a > patch for test purposes, but that would necessitate some very verbose flag to > sb-set-builder like --really-allow-local-patches-just-for-test-purposes > because we really don't want to host these patches within RSB. > > Kinsey -- Sincerely, Sam Price _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
