Re: HaRET release planning

Hello,

On Wed, Oct 25, 2006 at 02:52:32AM +0300, Paul Sokolovsky wrote:
> Greetings HaRET users, contributors, developers!
>
> Recently, Andrew Zaobolotny, author of HaRET, passed HaRET
> maintenance to Kevin O'Connor and myself. It's time to start planning
> for the next HaRET releases and their features.
...
> And well, CVS trunk is now open for 0.4 series, which should be
> merge with HaRET fork, gnu-haret. gnu-haret has extensive fixes for
> Linux boot procedure and PXA27x support, and even more extensive
> improvements and additions to device investigation module. Hopefully,
> this will be led by Kevin, who is an active gnu-haret contributor.

I'd like to start the process of rolling out 0.4.x releases. As Paul
mentions, there are a number of features in the "gnu-haret" fork that
are useful. I plan on bringing many of these features (and some
additional ones) into the mainline haret CVS repository.

The following is my rough plan to upgrade mainline haret:

1 - Get haret to compile using gcc

2 - Introduce device detection and machine specific classes and
    backport crucial bug fixes

3 - Add "haret console" scripts

4 - Introduce a command registration capability; breakup script.cpp

5 - Add pxa specific interrupt, instruction, and memory tracing

6 - Introduce new Linux booting code

7 - Backport many of the new commands in gnu-haret

At each step, I plan to tag a release. The above steps are described
in more detail below.

One crucial feature of gnu-haret (IMO) is the ability to compile haret
using gcc. Besides being more convenient to use, gcc (and the rest of
the gnu development tools) permit significantly more sophisticated
code development. In particular, implementing memory access tracing
and similar features would be significantly more difficult with the
Microsoft toolset. The plan is to use the compiler from the "cegcc"
project at: http://cegcc.sourceforge.net/

The next step is going to be backporting of the hardware specific code
found in gnu-haret (and from my own haret development). Along with
this will be crucial bug fixes (fix cpuFlushCache; fix mmu dump).
This will be necessary, because without these changes I wont be able
to effectively debug haret on my own device.

One nice feature in gnu-haret is a set of python scripts called "haret
console". These scripts run on a user's linux desktop and telnet into
haret running on a pda. It provides readline capabilities, logging,
and the ability to post-process some commands (which is useful when
interrupt tracing is added). These scripts run on the host machine
(not the target pda) and there use is optional.

One unfortunate part of the current gnu-haret repository is that
script.cpp has become unwieldy. This is a side effect of the large
number of new commands that were added to that fork. To offset this,
a command registration system will be implemented. This will allow
one to add a new command and/or variable without needing to update
script.cpp.

The interrupt tracing capabilities in gnu-haret allow haret to "hook"
wince interrupts. It can also instruct a pxa processor to breakpoint
on instruction addresses and catch specific memory accesses. The
result is a very powerful diagnostic tool.

The new linux booting code will move much of the assembler code into
regular C code. It will also close several "windows" where the
existing code could potentially crash. Finally, it will add new
capabilities - for example, the ability to link a linux kernel into a
stripped down haret for one file/one click linux booting.

The final step will be to backport many of the useful commands in
gnu-haret into the mainline haret.

While doing this development several things should be noted:

* There will likely be some haret destabilization while this is done.
  I will, of course, test all changes on my apache pda, but I can not
  verify changes on the wide range of platforms that haret runs on.
  To offset this, I will try to tag haret at each major milestone.
  Aid in testing additional platforms will be very useful.

* All the code I write will be covered by the gpl.

* Much of the new code will be wince specific. The original haret
  code had some provisions to run on non wince pdas, but this was
  never fully realized and it will be difficult to do.

Comments are welcome.
-Kevin
Received on Mon Nov 06 2006 - 12:05:16 EST