Basically we just need a test that runs to completion with a normal gem5
exit.  The regression test just checks that the simulation terminates
normally and that the statistics output matches the provided reference
output. The way the Linux boot tests work is that they boot and then run a
one-line script that contains 'm5 exit', which is a binary that executes
the gem5 pseudo-instruction that causes the simulator to exit.

The process of setting up a test is somewhat convoluted; documentation is
at http://www.gem5.org/Regression_Tests.  I'd hope you'd be able to re-use
the t1000-simple-atomic configuration, but if not, that's OK.

If there are patches that need to be applied to add/fix features, please
post them on reviewboard and we can get them committed.

Please feel free to ask if you have any questions, and thanks for working
on this!

Steve


On Mon, Jan 4, 2016 at 2:09 AM Jakub Jermar <[email protected]> wrote:

> On 4.1.2016 6:30, Steve Reinhardt wrote:
> > It's great to know that SPARC is being used... not too long ago we
> > discussed pulling the plug on SPARC support since we weren't aware of any
> > users.
>
> That would have been a disaster of epic proportions for us :-) Btw,
> AFAIR, RTEMS is/was using gem5 for their sparc64 development too.
>
> > A big problem with maintaining SPARC is that the only full-system SPARC
> > regression test we have uses a proprietary Solaris boot image that can't
> be
> > distributed, meaning many people can't run the regression and can't debug
> > problems when they occur.  (That's why it took so long to fix the
> previous
> > bug.)  If you have the capability of building a simple freely
> distributable
> > full-system boot test that we could integrate with our regressions, that
> > would actually help a lot in terms of our ability to keep SPARC support
> > from rotting away.
>
> I would love to see HelenOS used like that. What exactly do you need it
> to do in this regard? Boot to some known state? Boot into a prompt? At
> this moment, one needs to apply some patches to HelenOS in order to boot
> into the shell. These patches basically switch HelenOS from using
> TICK_COMPARE to using STICK_COMPARE. But it would be better if gem5
> supported TICK_COMPARE, just as the T1000 does (I suspect they are
> actually aliases).
>
> There is also an issue that I observed in 1/5 cases when the boot
> appears to hang just before the prompt is about to be displayed.
>
> Let me know if you would be interested in obtaining an up-to-date
> HelenOS image that you could boot. The ISO image is around 3M in size.
>
> Regards,
> Jakub
>
> >
> > Thanks,
> >
> > Steve
> >
> >
> > On Fri, Jan 1, 2016 at 1:36 PM Palle Lyckegaard <[email protected]>
> wrote:
> >
> >> On Fri, 1 Jan 2016, Jakub Jermar wrote:
> >>
> >>> Thanks a lot. I hope that the sparc64 support in gem5 stays around
> >>> indefinitely because as far as I know, gem5 is the only open source
> >>> emulator capable of emulating sun4v and not requiring either a SPARC
> >>> machine or Solaris.
> >>
> >> So do I - gem5 has been a big help during my work trying to get NetBSD
> >> running on sun4v.
> >>
> >> Probably also very usefull for the other BSDs as well.
> >>
> >>>
> >>> The issue preventing the unmodified version of HelenOS functioning
> >>> properly is that for some reason gem5 panics on accesses to the
> >>> TickCompare register. Which also means that the following fix seems
> >>> incomplete:
> >>>
> >>> changeset:   11102:c77f3a9e59bb
> >>> user:        Palle Lyckegaard <[email protected]>
> >>> date:        Tue Sep 15 08:14:07 2015 -0500
> >>> summary:     sparc: writing to tick_cmpr should not cause a panic
> >>>
> >>
> >> The NetBSD porting effort hasn't reached a state yet where this issue
> >> has popped up yet, so I guess my fix is incomplete. Sorry for that -
> will
> >> have to work on this when I get to the isssue.
> >>
> >> Regards
> >> Palle
> >>
> >> _______________________________________________
> >> gem5-dev mailing list
> >> [email protected]
> >> http://m5sim.org/mailman/listinfo/gem5-dev
> >>
> > _______________________________________________
> > gem5-dev mailing list
> > [email protected]
> > http://m5sim.org/mailman/listinfo/gem5-dev
> >
>
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to