Okay I might get shot for asking this... but the thought has crossed
my mind. Has anyone ever attempted to run Linux on the Rabbit? I've
seen projects like uCLinux out there for embedded devices but didn't
know if it was a possibility or not.
Anyway... just thought I'd throw that out there :P
Kelly
Running Linux on the Rabbit?
Started by ●June 12, 2007
Reply by ●June 12, 20072007-06-12
I'd love to see this happen, and I'm thinking of doing a port
myself,
plenty of micro linux kernels to start with.
--- In r..., "knkoehn" wrote:
>
> Okay I might get shot for asking this... but the thought has crossed
> my mind. Has anyone ever attempted to run Linux on the Rabbit? I've
> seen projects like uCLinux out there for embedded devices but didn't
> know if it was a possibility or not.
>
> Anyway... just thought I'd throw that out there :P
>
> Kelly
>
plenty of micro linux kernels to start with.
--- In r..., "knkoehn" wrote:
>
> Okay I might get shot for asking this... but the thought has crossed
> my mind. Has anyone ever attempted to run Linux on the Rabbit? I've
> seen projects like uCLinux out there for embedded devices but didn't
> know if it was a possibility or not.
>
> Anyway... just thought I'd throw that out there :P
>
> Kelly
>
Reply by ●June 12, 20072007-06-12
Bang!!!
----- Original Message ----
From: knkoehn
To: r...
Sent: Tuesday, June 12, 2007 8:32:33 AM
Subject: [rabbit-semi] Running Linux on the Rabbit?
Okay I might get shot for asking this... but the thought has crossed
my mind. Has anyone ever attempted to run Linux on the Rabbit? I've
seen projects like uCLinux out there for embedded devices but didn't
know if it was a possibility or not.
Anyway... just thought I'd throw that out there :P
Kelly
----- Original Message ----
From: knkoehn
To: r...
Sent: Tuesday, June 12, 2007 8:32:33 AM
Subject: [rabbit-semi] Running Linux on the Rabbit?
Okay I might get shot for asking this... but the thought has crossed
my mind. Has anyone ever attempted to run Linux on the Rabbit? I've
seen projects like uCLinux out there for embedded devices but didn't
know if it was a possibility or not.
Anyway... just thought I'd throw that out there :P
Kelly
Reply by ●June 12, 20072007-06-12
Aw man.... I should have used my one follower as a shield ;)
Kelly
Steve Trigero wrote:
> Bang!!!
>
> ----- Original Message ----
> From: knkoehn
> To: r...
> Sent: Tuesday, June 12, 2007 8:32:33 AM
> Subject: [rabbit-semi] Running Linux on the Rabbit?
>
> Okay I might get shot for asking this... but the thought has crossed
> my mind. Has anyone ever attempted to run Linux on the Rabbit? I've
> seen projects like uCLinux out there for embedded devices but didn't
> know if it was a possibility or not.
>
> Anyway... just thought I'd throw that out there :P
>
> Kelly
>
Kelly
Steve Trigero wrote:
> Bang!!!
>
> ----- Original Message ----
> From: knkoehn
> To: r...
> Sent: Tuesday, June 12, 2007 8:32:33 AM
> Subject: [rabbit-semi] Running Linux on the Rabbit?
>
> Okay I might get shot for asking this... but the thought has crossed
> my mind. Has anyone ever attempted to run Linux on the Rabbit? I've
> seen projects like uCLinux out there for embedded devices but didn't
> know if it was a possibility or not.
>
> Anyway... just thought I'd throw that out there :P
>
> Kelly
>
Reply by ●June 12, 20072007-06-12
Kelly,
I think the first step would be porting gcc. A couple of people have
looked at in the past, but the Rabbit 2000 and 3000 didn't seem like
a good match for an "easy" gcc port. The Rabbit 4000 might be a bit
better because it has additional longer registers.
Joel
--- In r..., "knkoehn" wrote:
>
> Okay I might get shot for asking this... but the thought has crossed
> my mind. Has anyone ever attempted to run Linux on the Rabbit?
I've
> seen projects like uCLinux out there for embedded devices but didn't
> know if it was a possibility or not.
>
> Anyway... just thought I'd throw that out there :P
>
> Kelly
>
I think the first step would be porting gcc. A couple of people have
looked at in the past, but the Rabbit 2000 and 3000 didn't seem like
a good match for an "easy" gcc port. The Rabbit 4000 might be a bit
better because it has additional longer registers.
Joel
--- In r..., "knkoehn" wrote:
>
> Okay I might get shot for asking this... but the thought has crossed
> my mind. Has anyone ever attempted to run Linux on the Rabbit?
I've
> seen projects like uCLinux out there for embedded devices but didn't
> know if it was a possibility or not.
>
> Anyway... just thought I'd throw that out there :P
>
> Kelly
>
Reply by ●June 12, 20072007-06-12
> Kelly,
>
> I think the first step would be porting gcc. A couple of people have
> looked at in the past, but the Rabbit 2000 and 3000 didn't seem like
> a good match for an "easy" gcc port. The Rabbit 4000 might be a bit
> better because it has additional longer registers.
>
> Joel
Linux assumes a 32-bit CPU, the same for GCC. It also requires an ANSI
compiler.
I have used GCC on 68HC11, the GCC port took a major rewrite to get it
to work. It was 2 years before the compiler was decent.
You might be able to use Softools to compile some programs. NO way DC
will work without a major rewrite of every source file and include file
of the OS and programs.
There would be no advantage of linux on the rabbit.
>
> I think the first step would be porting gcc. A couple of people have
> looked at in the past, but the Rabbit 2000 and 3000 didn't seem like
> a good match for an "easy" gcc port. The Rabbit 4000 might be a bit
> better because it has additional longer registers.
>
> Joel
Linux assumes a 32-bit CPU, the same for GCC. It also requires an ANSI
compiler.
I have used GCC on 68HC11, the GCC port took a major rewrite to get it
to work. It was 2 years before the compiler was decent.
You might be able to use Softools to compile some programs. NO way DC
will work without a major rewrite of every source file and include file
of the OS and programs.
There would be no advantage of linux on the rabbit.
Reply by ●June 12, 20072007-06-12
--- In r..., "knkoehn" wrote:
>
> Okay I might get shot for asking this... but the thought has crossed
> my mind. Has anyone ever attempted to run Linux on the Rabbit?
I've
> seen projects like uCLinux out there for embedded devices but didn't
> know if it was a possibility or not.
>
> Anyway... just thought I'd throw that out there :P
>
> Kelly
>
Here is a copy of a posting from Comp.Arch.Embedded that sums up this
idea fairly well:
----------------------------
> Hello, everyone , is there a port of linux for Rabbit 3000
> microprocessor ?
> That would probably be a generally useful thing, but is unlikely
> to happen since the Rabbit is not binary compatible with the
> Z180. Any such system would probably be quite slow, because
> process switching in the Z180 family is not trivial.
> CBFalconer wrote:
> That would probably be a generally useful thing, but is unlikely
> to happen since the Rabbit is not binary compatible with the
> Z180. Any such system would probably be quite slow, because
> process switching in the Z180 family is not trivial.
uClinux might be portable since there's no PMMU on the rabbit.
Performance would likely suck since (a) there's only an 8-bit wide
data bus off-chip and (b) no internal memory and (c) no instruction
cache.
So the rabbit runs as fast as its byte-wide memory chips, and no
faster. A rabbit with a modern DRAM controller and/or some on-chip
fast static ram might be interesting, but I won't hold my breath -
rabbit still hasn't added FIFOs on its UARTs.
A couple of years back Zilog was hinting that they would have some
flavor of linux available shortly for their eZ80. To date, linux
hasn't appeared on it. The eZ80 would likely run uClinux slowly for
(a) and (c).
Personally, I can't think of any CPU that runs linux and maintains
binary compatibility with the Z180.
A better project, IMHO, than uClinux on a Rabbit would a quality free
C compiler that targets the Rabbit. GCC, SDCC, or LCC would be places
to start. A good companion project would be a software emulator, ala
MESS or MAME.
Kelly
----------------------------
Thought this might be useful.
Regards,
Mark
>
> Okay I might get shot for asking this... but the thought has crossed
> my mind. Has anyone ever attempted to run Linux on the Rabbit?
I've
> seen projects like uCLinux out there for embedded devices but didn't
> know if it was a possibility or not.
>
> Anyway... just thought I'd throw that out there :P
>
> Kelly
>
Here is a copy of a posting from Comp.Arch.Embedded that sums up this
idea fairly well:
----------------------------
> Hello, everyone , is there a port of linux for Rabbit 3000
> microprocessor ?
> That would probably be a generally useful thing, but is unlikely
> to happen since the Rabbit is not binary compatible with the
> Z180. Any such system would probably be quite slow, because
> process switching in the Z180 family is not trivial.
> CBFalconer wrote:
> That would probably be a generally useful thing, but is unlikely
> to happen since the Rabbit is not binary compatible with the
> Z180. Any such system would probably be quite slow, because
> process switching in the Z180 family is not trivial.
uClinux might be portable since there's no PMMU on the rabbit.
Performance would likely suck since (a) there's only an 8-bit wide
data bus off-chip and (b) no internal memory and (c) no instruction
cache.
So the rabbit runs as fast as its byte-wide memory chips, and no
faster. A rabbit with a modern DRAM controller and/or some on-chip
fast static ram might be interesting, but I won't hold my breath -
rabbit still hasn't added FIFOs on its UARTs.
A couple of years back Zilog was hinting that they would have some
flavor of linux available shortly for their eZ80. To date, linux
hasn't appeared on it. The eZ80 would likely run uClinux slowly for
(a) and (c).
Personally, I can't think of any CPU that runs linux and maintains
binary compatibility with the Z180.
A better project, IMHO, than uClinux on a Rabbit would a quality free
C compiler that targets the Rabbit. GCC, SDCC, or LCC would be places
to start. A good companion project would be a software emulator, ala
MESS or MAME.
Kelly
----------------------------
Thought this might be useful.
Regards,
Mark
Reply by ●June 12, 20072007-06-12
Personally, if you want to run uCLinux on rabbit
because its network capabilities you should give a
try to freescales Coldfire chips. As Scott mentioned,
GCC assumes a 32 bit cpu, wich Coldfire already is.
Besides, if you stop to understand this amazing
machine and its functionalities youll NEVER look
back. Just my thoughts.
Regards
--- lordgeddy2112 escreveu:
> --- In r..., "knkoehn"
> wrote:
> >
> > Okay I might get shot for asking this... but the
> thought has crossed
> > my mind. Has anyone ever attempted to run Linux
> on the Rabbit?
> I've
> > seen projects like uCLinux out there for embedded
> devices but didn't
> > know if it was a possibility or not.
> >
> > Anyway... just thought I'd throw that out there :P
> >
> > Kelly
> > Here is a copy of a posting from Comp.Arch.Embedded
> that sums up this
> idea fairly well:
----------------------------
>
> > Hello, everyone , is there a port of linux for
> Rabbit 3000
> > microprocessor ?
>
> > That would probably be a generally useful thing,
> but is unlikely
> > to happen since the Rabbit is not binary
> compatible with the
> > Z180. Any such system would probably be quite
> slow, because
> > process switching in the Z180 family is not
> trivial.
>
> > CBFalconer wrote:
> > That would probably be a generally useful thing,
> but is unlikely
> > to happen since the Rabbit is not binary
> compatible with the
> > Z180. Any such system would probably be quite
> slow, because
> > process switching in the Z180 family is not
> trivial.
>
> uClinux might be portable since there's no PMMU on
> the rabbit.
> Performance would likely suck since (a) there's only
> an 8-bit wide
> data bus off-chip and (b) no internal memory and (c)
> no instruction
> cache.
> So the rabbit runs as fast as its byte-wide memory
> chips, and no
> faster. A rabbit with a modern DRAM controller
> and/or some on-chip
> fast static ram might be interesting, but I won't
> hold my breath -
> rabbit still hasn't added FIFOs on its UARTs.
>
> A couple of years back Zilog was hinting that they
> would have some
> flavor of linux available shortly for their eZ80. To
> date, linux
> hasn't appeared on it. The eZ80 would likely run
> uClinux slowly for
> (a) and (c).
>
> Personally, I can't think of any CPU that runs linux
> and maintains
> binary compatibility with the Z180.
>
> A better project, IMHO, than uClinux on a Rabbit
> would a quality free
> C compiler that targets the Rabbit. GCC, SDCC, or
> LCC would be places
> to start. A good companion project would be a
> software emulator, ala
> MESS or MAME.
>
> Kelly
----------------------------
> Thought this might be useful.
>
> Regards,
>
> Mark
____________________________________________________________________________________
Novo Yahoo! Cad - Experimente uma nova busca.
http://yahoo.com.br/oqueeuganhocomisso
because its network capabilities you should give a
try to freescales Coldfire chips. As Scott mentioned,
GCC assumes a 32 bit cpu, wich Coldfire already is.
Besides, if you stop to understand this amazing
machine and its functionalities youll NEVER look
back. Just my thoughts.
Regards
--- lordgeddy2112 escreveu:
> --- In r..., "knkoehn"
> wrote:
> >
> > Okay I might get shot for asking this... but the
> thought has crossed
> > my mind. Has anyone ever attempted to run Linux
> on the Rabbit?
> I've
> > seen projects like uCLinux out there for embedded
> devices but didn't
> > know if it was a possibility or not.
> >
> > Anyway... just thought I'd throw that out there :P
> >
> > Kelly
> > Here is a copy of a posting from Comp.Arch.Embedded
> that sums up this
> idea fairly well:
----------------------------
>
> > Hello, everyone , is there a port of linux for
> Rabbit 3000
> > microprocessor ?
>
> > That would probably be a generally useful thing,
> but is unlikely
> > to happen since the Rabbit is not binary
> compatible with the
> > Z180. Any such system would probably be quite
> slow, because
> > process switching in the Z180 family is not
> trivial.
>
> > CBFalconer wrote:
> > That would probably be a generally useful thing,
> but is unlikely
> > to happen since the Rabbit is not binary
> compatible with the
> > Z180. Any such system would probably be quite
> slow, because
> > process switching in the Z180 family is not
> trivial.
>
> uClinux might be portable since there's no PMMU on
> the rabbit.
> Performance would likely suck since (a) there's only
> an 8-bit wide
> data bus off-chip and (b) no internal memory and (c)
> no instruction
> cache.
> So the rabbit runs as fast as its byte-wide memory
> chips, and no
> faster. A rabbit with a modern DRAM controller
> and/or some on-chip
> fast static ram might be interesting, but I won't
> hold my breath -
> rabbit still hasn't added FIFOs on its UARTs.
>
> A couple of years back Zilog was hinting that they
> would have some
> flavor of linux available shortly for their eZ80. To
> date, linux
> hasn't appeared on it. The eZ80 would likely run
> uClinux slowly for
> (a) and (c).
>
> Personally, I can't think of any CPU that runs linux
> and maintains
> binary compatibility with the Z180.
>
> A better project, IMHO, than uClinux on a Rabbit
> would a quality free
> C compiler that targets the Rabbit. GCC, SDCC, or
> LCC would be places
> to start. A good companion project would be a
> software emulator, ala
> MESS or MAME.
>
> Kelly
----------------------------
> Thought this might be useful.
>
> Regards,
>
> Mark
____________________________________________________________________________________
Novo Yahoo! Cad - Experimente uma nova busca.
http://yahoo.com.br/oqueeuganhocomisso
Reply by ●June 12, 20072007-06-12
--- In r..., Alexandre Kremer
wrote:
> As Scott mentioned,
> GCC assumes a 32 bit cpu, wich Coldfire already is.
No, GCC does not requires a 32-bit target CPU. GCC happily generates
code for the AVR (8-bit) and Hitachi H8/300 (8/16 bit) families. Of
course, either of those architectures is a whole lot more compiler-
friendly than the Rabbit.
The reason you don't want to retarget GCC for the Rabbit is because
GCC is fricking complicated to re-target. If you want to retarget a
compiler, I highly recommend starting with lcc - there's already a
backend for Gameboy which is Z80-ish enough to be a good starting
point. Plus there's a nice book all about the compiler itself.
If all you need is a decent ANSI C compiler, just shell out the bucks
for Softools - it works well, generates excellent code, and even at
$10/hr pays for itself after a week's work. Never, ever waste your
time because you don't have quality tools.
Kelly
wrote:
> As Scott mentioned,
> GCC assumes a 32 bit cpu, wich Coldfire already is.
No, GCC does not requires a 32-bit target CPU. GCC happily generates
code for the AVR (8-bit) and Hitachi H8/300 (8/16 bit) families. Of
course, either of those architectures is a whole lot more compiler-
friendly than the Rabbit.
The reason you don't want to retarget GCC for the Rabbit is because
GCC is fricking complicated to re-target. If you want to retarget a
compiler, I highly recommend starting with lcc - there's already a
backend for Gameboy which is Z80-ish enough to be a good starting
point. Plus there's a nice book all about the compiler itself.
If all you need is a decent ANSI C compiler, just shell out the bucks
for Softools - it works well, generates excellent code, and even at
$10/hr pays for itself after a week's work. Never, ever waste your
time because you don't have quality tools.
Kelly
Reply by ●June 13, 20072007-06-13
I played with an lcc port and it is probably the best documented
choice. It is a great way to learn about lexing, parsing, and
compiler technology. I am not sure that the "personal research and
instructional use..." was broad enough for comercial derived works. I
read through the full license and it may be fine, not sure.
Another candidate would be SDCC if it is still maintained. It had a
Gameboy and Z80 port.
Joel
--- In r..., "Kelly" wrote:
>
> --- In r..., Alexandre Kremer
> wrote:
> > As Scott mentioned,
> > GCC assumes a 32 bit cpu, wich Coldfire already is.
>
> No, GCC does not requires a 32-bit target CPU. GCC happily
generates
> code for the AVR (8-bit) and Hitachi H8/300 (8/16 bit) families.
Of
> course, either of those architectures is a whole lot more compiler-
> friendly than the Rabbit.
>
> The reason you don't want to retarget GCC for the Rabbit is because
> GCC is fricking complicated to re-target. If you want to retarget
a
> compiler, I highly recommend starting with lcc - there's already a
> backend for Gameboy which is Z80-ish enough to be a good starting
> point. Plus there's a nice book all about the compiler itself.
>
> If all you need is a decent ANSI C compiler, just shell out the
bucks
> for Softools - it works well, generates excellent code, and even at
> $10/hr pays for itself after a week's work. Never, ever waste your
> time because you don't have quality tools.
>
> Kelly
>
choice. It is a great way to learn about lexing, parsing, and
compiler technology. I am not sure that the "personal research and
instructional use..." was broad enough for comercial derived works. I
read through the full license and it may be fine, not sure.
Another candidate would be SDCC if it is still maintained. It had a
Gameboy and Z80 port.
Joel
--- In r..., "Kelly" wrote:
>
> --- In r..., Alexandre Kremer
> wrote:
> > As Scott mentioned,
> > GCC assumes a 32 bit cpu, wich Coldfire already is.
>
> No, GCC does not requires a 32-bit target CPU. GCC happily
generates
> code for the AVR (8-bit) and Hitachi H8/300 (8/16 bit) families.
Of
> course, either of those architectures is a whole lot more compiler-
> friendly than the Rabbit.
>
> The reason you don't want to retarget GCC for the Rabbit is because
> GCC is fricking complicated to re-target. If you want to retarget
a
> compiler, I highly recommend starting with lcc - there's already a
> backend for Gameboy which is Z80-ish enough to be a good starting
> point. Plus there's a nice book all about the compiler itself.
>
> If all you need is a decent ANSI C compiler, just shell out the
bucks
> for Softools - it works well, generates excellent code, and even at
> $10/hr pays for itself after a week's work. Never, ever waste your
> time because you don't have quality tools.
>
> Kelly
>
