Minix3 for sparc
Jao Madn
Tomas Hruby
Unfortunatelly no. Current versions of Minix support only IA32. T.
Outback Dingo
>> Hi may i ask if minix3 is installable in sparc workstation.
>
> Unfortunatelly no. Current versions of Minix support only IA32. T.
I was actually curious about how difficult it would be to get it
ported to MIPS also......
>
> --
> You received this message because you are subscribed to the Google Groups "minix3" group.
> To post to this group, send email to min...@googlegroups.com.
> To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/minix3?hl=en.
>
>
Erik van der Kouwe
> >> Hi may i ask if minix3 is installable in sparc workstation.
>
> > Unfortunatelly no. Current versions of Minix support only IA32. T.
>
> I was actually curious about how difficult it would be to get it
> ported to MIPS also......
At the moment, porting to any other arch would be difficult as some
parts of the code base are fairly x86-specific. For example, segments
are still used. Some code will have to be fixed to stop relying on x86-
specific features and the arch-dependent and independent parts have to
be split properly.
However, we intend to start work on an ARM port soon. This should
involve fixing all of these issues and would make it easier to port
MINIX to other systems as well.
With kind regards,
Erik
Luís Friedrich
Have you already identified all these
code that relying on x86-specific features and the arch-dependent and independent parts that have to
be split properly?
If you had it could be share to all minix users/developers in order to
have much people thinking about possible solutions.
Att.
Friedrich
--
Prof. Lu�s Fernando Friedrich
Chefe do Departamento de Inform�tica e Estat�stica - INE
Tutor PET Computa��o - http://www.pet.inf.ufsc.br
Universidade Federal de Santa Catarina - UFSC
Erik van der Kouwe
> Have you already identified all these
>
> code that relying on x86-specific features and the arch-dependent and independent parts that have to
> be split properly?
>
> If you had it could be share to all minix users/developers in order to
> have much people thinking about possible solutions.
Doing such an investigation would be part of the porting project and
hasn't been done yet. However, segmentation clearly has to go and the
virtual memory system is likely to need a substantial revision. As we
focus on primarily on ARM this might still be managable as some models
actually have pagetables and TLBs fairly similar to the x86 ones, but
other architectures that have a limited MMU or a different system (for
example without pagetables) may be more difficult to squeeze into the
current design.
In addition, I'm not sure whether all code was written with the idea
that the int type could differ from long in mind. This issue (if it
does indeed exist) would affect code in various places.
With kind regards,
Erik
Tomas Hruby
> Hi,
>
> > Have you already identified all these
> >
> > code that relying on x86-specific features and the arch-dependent and independent parts that have to
> > be split properly?
> >
> > If you had it could be share to all minix users/developers in order to
> > have much people thinking about possible solutions.
>
> Doing such an investigation would be part of the porting project and
> hasn't been done yet. However, segmentation clearly has to go and the
> virtual memory system is likely to need a substantial revision. As we
> focus on primarily on ARM this might still be managable as some models
> actually have pagetables and TLBs fairly similar to the x86 ones, but
> other architectures that have a limited MMU or a different system (for
> example without pagetables) may be more difficult to squeeze into the
> current design.
VM expects that the hardware is able to walk the page tables and fill
the TLBs like x86. Luckily, ARMs do the same. This is not the case for
SPARCs and MIPSs.
T.
Antoine LECA
> Have you already identified all these
> code that relying on x86-specific features and the arch-dependent and
> independent parts that have to be split properly?
"All" not is done in this area, but a fair part of it have been done in
2006 (commit 6f77685), when Ingmar Alting was porting MINIX 3.1.2 to the
PowerPC architecture.
Unfortunately, that port --and a further attempt at porting to ARM-- did
not succeed, so there have been a significant deviation away for the
perfection in this area.
> If you had it could be share to all minix users/developers in order to
> have much people thinking about possible solutions.
I would believe that any proposition of patches against trunk to make
things better in this area might be given a suitable attention from the
core team (but remember I am not within that team ;-) .)
Unfortunately, as this thread showed, the story does not end here, there
are other themes which are real problem when it comes to portability,
but are not encountered until someone attempts to port the code to an
architecture different from i386 (without PAE) which does need the
underlying feature (page tables, long larger than int have been named;
reduced core memory could be another issue; there are certainly many
other.) So random notes like the various threads this about on the
newsgroup are the best things one can reasonably wish for.
Here again the MINIX project stumbles against its biggest blocker: there
are many wonderful ideas of things to make better, but there are very
few people actually doing the work, which creates much frustration.
Antoine
Antoine LECA
Hmmm... this would mean a breach in backward compatibility, right?
Not that I find it impossible, I am just pointing out that until now,
almost all the ACK-compiled a.out binaries need a segmented virtual
address space to work (T space not the same as D), so if segmentation
goes away, they cannot be exec'ed.
Or perhaps I am missing something?
On the other hand, since it is quite easy to do, why not making -com
(instead of -sep) the default option for acd/cc?
Antoine
Erik van der Kouwe
We will soon switch the system to be fully ELF-based, with a compiler
choice of Clang and GCC. Since we have all the packages compiling now
(due to pkgsrc) we should be able to abandon ack and a.out and break
binary compatibility. At this point, removing the segments should not
be a problem anymore, as AFAIK ELF never uses the CS/DS distinction.
With kind regards,
Erik
Luís Friedrich
> Lu�s Friedrich wrote:
>> Have you already identified all these
>> code that relying on x86-specific features and the arch-dependent and
>> independent parts that have to be split properly?
> "All" not is done in this area, but a fair part of it have been done in
> 2006 (commit 6f77685), when Ingmar Alting was porting MINIX 3.1.2 to the
> PowerPC architecture.
>
means at least been portable and configurable/flexible.
Once we have MINIX3 running only in X86, it is not portable. Flexibility
is also difficult to get at this time.
For instance, how easy it is to tailor MINIX3 to a specific application
(embedded system)?
> Unfortunately, that port --and a further attempt at porting to ARM-- did
> not succeed, so there have been a significant deviation away for the
> perfection in this area.
>
>
I understand that porting needs a lot of effort and also experience, but
it is also a necessity.
>> If you had it could be share to all minix users/developers in order to
>> have much people thinking about possible solutions.
> I would believe that any proposition of patches against trunk to make
> things better in this area might be given a suitable attention from the
> core team (but remember I am not within that team ;-) .)
>
> Unfortunately, as this thread showed, the story does not end here, there
> are other themes which are real problem when it comes to portability,
> but are not encountered until someone attempts to port the code to an
> architecture different from i386 (without PAE) which does need the
> underlying feature (page tables, long larger than int have been named;
> reduced core memory could be another issue; there are certainly many
> other.) So random notes like the various threads this about on the
> newsgroup are the best things one can reasonably wish for.
>
> Here again the MINIX project stumbles against its biggest blocker: there
> are many wonderful ideas of things to make better, but there are very
> few people actually doing the work, which creates much frustration.
>
>
The suggestion here is to select some issues, like portability, having
priority.
> Antoine
>
Att.
Friedrich
pikpik
On Nov 24, 3:01 pm, Luís Friedrich wrote:
>
> On 24-11-2011 15:57, Antoine LECA wrote:
> >
> > Luís Friedrich wrote:
> >>
> >> If you had it could be share to all minix users/developers in order to
> >> have much people thinking about possible solutions.
>
> > [...] So random notes like the various threads this about on the
> > newsgroup are the best things one can reasonably wish for.
Would it help to record these notes on the wiki?
Thank you,
pikpik
AntoineLeca
> > > However, segmentation clearly has to go
>
> > Hmmm... this would mean a breach in backward compatibility, right?
>
> choice of Clang and GCC. Since we have all the packages compiling now
> (due to pkgsrc) we should be able to abandon ack and a.out and break
> binary compatibility.
Ah! I was not aware that the possibility to exec() a.out binaries was
to be abandoned soon.
> At this point, removing the segments should not be a problem anymore,
Indeed.
I guess it is becoming urgent to either create an ACK cross-compiler
package (could be reduced to compiling 16-bit binaries), or to work on
creating some new multiboot loader able to read from MINIX
subpartitions and a MFS file system, then.
Antoine
Yana
Formerly I patched minix3_1_3a_ide_r2964.iso.bz2 for ARM, MIPS and GXemul.
http://groups.google.com/group/minix3/browse_thread/thread/b37eb23f02b65bb0
2011/11/24 Outback Dingo <outbac...@gmail.com>:
> I was actually curious about how difficult it would be to get it
> ported to MIPS also......
For example, there are the following differences of ARM and MIPS about
MINIX 3.1.3a.
* global pointer ($gp register)
In the case of ARM, global pointer will not be used.
In the case of MIPS, global pointer may be used.
To use global pointer, $gp register will be initialized before
executing main function and signal handler.
About main function, because a assembly routine (crtso) is executed by
processing of EXEC, $gp register will be initialized at this assembly
routine.
> la $gp, _gp
However, about signal handler, because a C function (signal handler)
is executed by processing of signal, $gp register will be initialized
at system task.
* interrupt mask (IM field of Status register)
In the case of ARM, the following instructions will be used to disable
interrupts.
> #define YK0A_ARM_CPSR_I (1 << 7)
> mrs r0, cpsr
> orr r0, r0, #YK0A_ARM_CPSR_I
> msr cpsr_c, r0
In the case of MIPS, about MIPS32 Release 2, DI instruction will be
used to disable interrupts.
However, about MIPS32 Release 1, DI instruction is not required.
And because IM field of Status register may be changed by processing
of interrupt, the following instructions will not be used to disable
interrupts.
> #define YK0A_MIPS_STATUS $12
> #define YK0A_MIPS_HAZARD_STATUS ssnop; ssnop
> #define YK0A_MIPS_STATUS_IE (1 << 0)
> mfc0 $2, YK0A_MIPS_STATUS
> ori $2, $2, YK0A_MIPS_STATUS_IE
> xori $2, $2, YK0A_MIPS_STATUS_IE
> mtc0 $2, YK0A_MIPS_STATUS
> YK0A_MIPS_HAZARD_STATUS
* segmented virtual memory
In the case of ARM, page tables will be changed with reference to
segment information.
In the case of MIPS, TLB entries will be changed with reference to
segment information.
Thanks,
Yana