On 8/02/2014 1:55 am, Gedare Bloom wrote:
On Fri, Feb 7, 2014 at 3:02 AM, Sebastian Huber
<sebastian.hu...@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.hu...@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@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
