[PATCH] bsp/leon3_qemu: New BSP variant

Fri Feb 7 22:22:17 UTC 2014

On 8/02/2014 1:55 am, Gedare Bloom 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.
>>

Sebastian, I understand the issues with upstream qemu and I am working 
on adding support to the RSB so anyone in the project can build qemu 
with any patches RTEMS needs. This will be important when we start the 
project's centralised constant testing. At the moment it is not really 
manageable because qemu patch tracking is it's devel list and that list 
is crazy. An example is we have both posted patches to qemu-devel to fix 
the zynq reset and neither have been committed and I had no idea you had 
done this.

>> 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, this patch means we would have 2 BSPs to test the same thing on 
the leon3 giving us a total of 8 BSPs in RTEMS that have qemu in their 
cfg file name. I do not know how many are qemu work arounds and how many 
are just a bsp. I know the zynq zc702 is just a memory map change and I 
have not had the time to see why this is so and if we can get qemu to 
support the non-qemu'ed one.

If we add this bsp then who is testing which leon3 bsp ? I cannot test 
the leon3 and would only be able to test the qemu one and I suspect very 
few people have suitable hardware to test the leon3 one yet the 
important one to users is the leon3 bsp and not the qemu one. I know 
Sebastian has a leon3 board and is covering this part of the testing 
while doing the development and Joel has grsim and can test it as well 
and then there maybe a few others world wide. Given time this situation 
would change and only the qemu one would be tested which leaves the 
leon3 in an unknown state.

I understand the benefits of being able to use qemu. With the zync it 
takes around 7 minutes to run all 472 tests while it takes 100 minutes 
to run them on a real target. The problem I have is both really need to 
be tested. I cannot rely on one being built ok and then just assume the 
other is built ok. If I had a single BSP I could run on both that 
situation would change.

Soon we will have constant integration and with that will come 
continuous testing. I have been working on the rtems-tester [1] as a 
tool to be used in that testing. A result of this testing will be the 
ability for us to know which BSPs are valid and current and which are 
not. We then need to decide what we do with BSPs we cannot test. If a 
BSP cannot be tested should it stay and be maintained ? When RTEMS is 
released is the user expectation all BSPs work and are tested ? Mine 
would be.

The centralised project based testing will be mostly simulator based so 
having qemu support the standard leon3 bsp means any user with real 
hardware will be using the BSP we test as part of the project's quality 
process.

You can argue the changes are minimal and not a big deal because the 
differences are small however my view of testing, traceability and 
configuration management sees this as a large divide. You are either 
testing the BSP or you are not testing the BSP and a set of results is 
either for that BSP or it is not. Anything else makes the project's life 
difficult by adding uncertainty and that is dangerous because it starts 
to bring into question any of the test results we publish.

Yes this is a small change and could be considered minor however at some 
point in time we need to consider a shift in our views on how we manage 
and accept changes like this.

To me the key issue is about getting qemu fixed as Jiri suggested.

Chris

[1] 
http://www.rtems.org/ftp/pub/rtems/people/chrisj/rtems-tester/rtems-tester.html

>
> -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