[PATCH] bsp/leon3_qemu: New BSP variant

[Gedare Bloom]

Well, I see Sebastian reverted the BSP. Is there a plan to actually
fix Qemu, or do you expect to just use the BSP outside the tree?

On Fri, Feb 7, 2014 at 9:55 AM, Gedare Bloom <gedare at rtems.org> wrote:
> On Fri, Feb 7, 2014 at 3:02 AM, Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
>> On 2014-02-06 22:43, Chris Johns wrote:
>>>
>>> On 7/02/2014 2:00 am, Sebastian Huber wrote:
>>>>
>>>> On 2014-02-06 15:52, Jiri Gaisler wrote:
>>>>>
>>>>>
>>>>> On 02/06/2014 03:37 PM, Sebastian Huber wrote:
>>>>>>
>>>>>> >On 2014-02-06 15:35, Gedare Bloom wrote:
>>>>>>>
>>>>>>> >>Thanks Sebastian. Is there some sim-script support or
>>>>>>> documentation on
>>>>>>> >>using this BSP with Qemu?
>>>>>>
>>>>>> >
>>>>>> >Yes, I will commit this tomorrow.  Can't switch branches currently
>>>>>> due to active test runs.
>>>>>> >
>>>>>
>>>>> It seems that this patch is necessary because qemu/leon3 does
>>>>> not implement the plug&play feature of leon3, and does not
>>>>> pre-initialize timers and UARTs. Wouldn't it be simpler to
>>>>> add the missing features to qemu, rather than add an extra bsp?
>>>>
>>>>
>>>> Yes, this solution would be better.
>>>
>>>
>>> I agree.
>>>
>>>> The problem is that this requires
>>>> more work and I don't have a budget for this.
>>>
>>>
>>> That may be the case but it is not really a concern for the project.
>>
>>
>> It is a concern for the project since if I work on QEMU then I cannot work
>> on RTEMS.
>>
>>
>>>
>>>> We can of course remove this BSP if QEMU is capable enough some time in
>>>> the future.
>>>
>>>
>>> This is correct however rejecting the patch means fixing qemu is the best
>>> solution and that is in the interest of the project. Adding a bsp is much
>>> easier than removing one even when clearly stated it is temporary. Hiding
>>> issues in work arounds like this is not a good idea.
>>
>>
>> I considered to add the support to QEMU, but my estimate was that this takes
>> several days.  Adding this BSP was a matter of one hour or so.  It is good
>> enough to run the RTEMS and GCC test suites.  My main goal was to be able to
>> test the CAS instruction.  This is not available on SIS.  Since QEMU has
>> some benefits over SIS I decided to add the support for it to QEMU instead
>> of SIS:
>>
>> http://lists.gnu.org/archive/html/qemu-devel/2013-11/msg03718.html
>>
>> This patch is still not included in QEMU.  Imagine how much time and
>> patience you need to integrate larger changes sets.
>>
>> If you don't like the BSP, then we can remove it.
>>
>>
>>>
>>> I prefer seeing qemu get fixed.
>>
>>
>> I prefer this too, but how will do it?  Its not me.
>>
> Please consider making an open project page for the effort to fix Qemu
> on the rtems wiki. Perhaps someone will kindly volunteer some time, or
> it might be doable as a portion of a GSOC/SOCIS.
>
> I consider adding the BSP as OK, but it is a concern that we just
> never fix Qemu as a result. However, it is better to have something
> that works for the community to use to test Leon3 with Qemu.
>
> -Gedare
>
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone   : +49 89 189 47 41-16
>> Fax     : +49 89 189 47 41-09
>> E-Mail  : sebastian.huber at embedded-brains.de
>> PGP     : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel