[PATCH rtems-source-builder 2/2] devel/qemu-xilinx: Fix build on GCC 13.2.0

[Sam Price]

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.moore at oarcorp.com> wrote:
>
> On Wed, Feb 14, 2024 at 9:14 AM Sam Price <thesamprice at 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