Re: [ECOS] PowerPC HAL patches.

[Jesper Skov <jskov at redhat dot com>]

>>>>> "Sergei" == Sergei Organov <osv@javad.ru> writes:

Sergei> Jesper, Thank you. What you did seems to be fine for my
Sergei> target. I didn't try your patch because I've already moved a
Sergei> little bit further in my development (FPU support), and it
Sergei> seems to be simpler for me to wait until the changes appear in
Sergei> anon cvs to merge them semi-automatically.

Sergei> BTW, I don't think my platform is so special. The MPC50x
Sergei> processors have a pin that defines whether the vector table
Sergei> after reset is at 0 or at 0xfff00000, so designers can put ROM
Sergei> at 0 or at 0xfff00000. I mean that unlike other supported
Sergei> PowerPC families for MPC50x we can't simply assume ROM is at
Sergei> 0xfff0000.

Ah, it's special in a smiley-way since we don't have any of those here
:) I know quite well that boards using ROM at 0 exists.

Sergei> The only comment is about MMU support. Maybe we better
Sergei> distinguish between two situations. The first one is when
Sergei> processor has MMU but we need to disable it (the case with
Sergei> SIM). The second one is when the processor just doesn't have
Sergei> MMU (MPC50x). For the latter case all the MMU related calls
Sergei> from the HAL could be just removed. That's not very important
Sergei> though.

Sergei> Recently I've also found a few things in the HAL that I don't
Sergei> understand. In fact for me they seem to be bugs. Here are
Sergei> they:

Sergei> 1. Function 'hal_variant_init()' that is defined in most
Sergei> variants isn't actually get called. The bug doesn't show
Sergei> itself only because all these routines are currently empty.

Actually, some of the stuff in arch/hal_misc should move to
hal_variant_init because it is variant specific. It should be done in
a way similar to what's used in the MIPS HAL though - having a
sensible default in the architecture HAL (which applies to most
variants), all protected by suitable #ifdefs so the variant HAL can
override it.

The only reason it hasn't been done yet is that I always seem to get
interrupted by stuff that's more important. It's on my todo list.

Sergei> 2. 'hal_variant_load' macro isn't called in
Sergei> exception/interrupt management code while 'hal_variant_store'
Sergei> is. Again currently all of them are just empty.

This is a mistake. I've put it on my todo list as well.  But
presumably this is the macros you are using to load/restore FPU state,
so maybe you'll beat me to fixing this?!? :)

Jesper