Morpheus with Mem+ greatly exceeds that (although not by much for the Mips, using XLMM)
heater said...
1) There is no problem with sharing the SD card with the memory on the same bus, like TriBlade, DracBlade. etc. It just means that when your Linux goes to get a file sector it just has to wait until the sector is posted into RAM somewhere by the SD driver and then continue. Terrible slow but simple and would work. We are allowed to be slow. Besides arranging for Linux to continue with some other thread while the sector is being read/written from RAM implies a shared memory bus with some kind of DMA mechanism which aint going to happen and would slow everything (The XMM kernel) down anyway.
2) There is no problem with a boot loader. GRUB etc not required. Just use some Spin or C code to poke the thing into RAM and then start it. Use an uncompressed kernel for speed. Well that is a boot loader but without any complexity. That is how we used to get CP/M up and running on the Prop, no Z80 ROM boot loader code just poke it into place from Spin.
3) I'm sure a 512Kb TriBlade is not enough.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95 Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
heater said...
Yeah, but what I meant was that doing that 5MB/s into RAM basically buggers up the XMM access cycles. Plus it upsets the XMM cycles even when it's not happening as the XMM kernel probably has to check for it all the time. So, may as well halt Linux execution while moving data from SD to RAM.
I'd do SD -> cog -> HUB and raise a flag to indicate the transfer has been done.· Then when the taskswitch goes back to the blocked process, the process can do the HUB->XMM transfer.· There'd need to be some queuing somewhere in case multiple processes are accessing the SD simultaneously.
heater said...
Networking...Hmm...nice but not part of our specification. Makes the kernel bigger. The trick for development would be to arrange that the SD is shared with say an ARM running Linux so that stuff can be networked into it then used by the Prop.
No SLIP?· Even without a true ethernet driver I suspect the IP stack will still get built - too much stuff uses it internally.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObExForum
OnePinTVText driver: ObExForum
Eric: "SD -> cog -> HUB" Sounds fine. But given that Linux has probably just requested a sector to somewhere in XMM then why not just do that for it? Whatever.
As for the queuing, I'd presume that it is down to Linux to do that for itself. After all it must do so for the good old IDE drives. Isn't that what the Linux scheduler is for?
Not sure about the necessity of the network stack. After all there was no such thing when the first Unix was made. Must be able to get our minimum spec of a running BASH without it. Sounds like the sort of thing that grows once the basics are up and running.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, networking was always an after thought ... even in Unix/Linux as you know it's not a native part of the "file system model" ... perhaps the band-aid model [noparse]:)[/noparse]. My friend asked me: "Wow, wasn't it great that Bill Gates invented networking?" ... "umm, what about DARPA?" I asked, and "Have you ever heard of Marc Andreesson?"
heater: All IO (AFAIK) does not get copied to user space till after it has been pulled from the medium to kernel memory. Then a (slow) routine copies it from kernel to user space. So if the kernel buffers are in HUB then you just do HUB->XMM.
So they are emulating an instruction set that GNU tool variant produces?
Sounds like a job for heater [noparse]:)[/noparse] R3000/R4000 MIPS maybe?
Exceptions and TLBs might be a little troublesome though. One MIPS example is here. It looks pretty small and easy.
jazzed said...
So they are emulating an instruction set that GNU tool variant produces?
Sounds like a job for heater [noparse]:)[/noparse] R3000/R4000 MIPS maybe?
Exceptions and TLBs might be a little troublesome though. One MIPS example is here. It looks pretty small and easy.
Don't want to rain on the parade, and you may not be talking about this particular challenge in any case, but in the first post : -
BradC said...
- The code must be running on the bare propeller. No emulating another processor (MIPS for example).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Cluso99 said...
Have you seen this thread about Zipit Z2 in the sandbox? It has been hacked to run Linux 2.6.x
Actually, that's not quite accurate. It was already running Linux 2.6. It was "hacked" to allow you to actually access the underlying OS and allow different firmware images to be loaded.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
>> BradC says no emulations ....
Waaahhh [noparse]:)[/noparse]
It's ok. Yes I was thinking in more general terms. We shouldn't go on about it too much here ..... I looked for that exception when the thread first showed up because I knew of another possible GNU enabled emulation[noparse]:)[/noparse] The MIPS instruction set is very small (COG-able), powerful, and obviously has more address range capability than the other emulated processors (which is trading one straight jacket for another IMHO).
The thing is that we will have to emulate some instructions like jmp, push, pop, and so on. Even if the rest are native... it contains an emulator for things that are actually non-existant. It may be seen like a soft-float "package" though.
Ale: "...kernel memory....slow copy...kernel to user space."
Hey what kernel/user space?. We presumably have no MMU on this hypothetical Prop Linux, therefore nor user/kernel space divide to speak of. Just a flat EXT RAM space.
I suspect data would go from SD to HUB (normal SD low level driver stuff). Then HUB to EXT RAM to satisfy the kernel's request. Perhaps into some place that the kernel "thinks" is kernel space. After that we don't care what Linux does with it in EXT RAM.
Ale: "So if the kernel buffers are in HUB then...." Do you mean the Linux kernel or the XMM kernel?
I imaging life is easier if the all the Linux stuff is in EXT RAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Jazzed "So they (XMOS) are emulating an instruction set that GNU tool variant produces?"
No, their compiler produces code for their chips instruction set. Something that never existed before. Presumably they added a new code generator to LLMV.
"Sounds like a job for heater [noparse]:)[/noparse] R3000/R4000 MIPS maybe?" - Don't get me started, I'll end up wasting the next two years of my life as well and on top of that not be eligible for the prize.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
So is the challenge to have linux running or a posix compatible kernel that bash and other tools can run on? This might be more amenable to a micro kernel approach with the cogs doing message passing. Might fit a multi propeller implementation better as well?
No, I believe Brad's challenge is specific to running a Linux 2.6 (or later) kernel.
Running a "unix-like" or posix-compatible kernel would be easier (I believe several such developments are already underway) but this challenge is for Linux.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
BradC said...
- The code must be running on the bare propeller. No emulating another processor (MIPS for example).
It's BradC's money so it's BradC's rules for the challenge and no complaint there, but if anyone were to get Linux running via emulation I think many would still be impressed and it may be a stepping stone or driving force toward the money pot ( though I doubt the money will mean more than the accolades ).
The same applies to other ideas which won't meet the winning criteria; if you think you can and want to, simply go for it.
If I was not so darned busy, I'd write a MIPS R2000 emulator, it looks like a really cool project. Heck, if no one tackles it within six months, I'll probably do it!
hippy said...
BradC said...
- The code must be running on the bare propeller. No emulating another processor (MIPS for example).
It's BradC's money so it's BradC's rules for the challenge and no complaint there, but if anyone were to get Linux running via emulation I think many would still be impressed and it may be a stepping stone or driving force toward the money pot ( though I doubt the money will mean more than the accolades ).
The same applies to other ideas which won't meet the winning criteria; if you think you can and want to, simply go for it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95 Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Comments
Some of you may recall the old 3M spec for workstations, including running X:
1 Mips
1 Mb ram
1 Megapixel (1 bit per pixel - Morpheus can generate 1280x1024 1bpp, I just have not bothered writing the driver)
See en.wikipedia.org/wiki/3M_computer for more info.
Morpheus with Mem+ greatly exceeds that (although not by much for the Mips, using XLMM)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
As for the queuing, I'd presume that it is down to Linux to do that for itself. After all it must do so for the good old IDE drives. Isn't that what the Linux scheduler is for?
Not sure about the necessity of the network stack. After all there was no such thing when the first Unix was made. Must be able to get our minimum spec of a running BASH without it. Sounds like the sort of thing that grows once the basics are up and running.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
... Postel contributed more directly than many.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
AFAIK the people from xmos used LLMV in the port of gcc/binutils to the xmos arch.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Sounds like a job for heater [noparse]:)[/noparse] R3000/R4000 MIPS maybe?
Exceptions and TLBs might be a little troublesome though.
One MIPS example is here. It looks pretty small and easy.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Don't want to rain on the parade, and you may not be talking about this particular challenge in any case, but in the first post : - ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Actually, that's not quite accurate. It was already running Linux 2.6. It was "hacked" to allow you to actually access the underlying OS and allow different firmware images to be loaded.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Waaahhh [noparse]:)[/noparse]
It's ok. Yes I was thinking in more general terms. We shouldn't go on about it too much here ..... I looked for that exception when the thread first showed up because I knew of another possible GNU enabled emulation[noparse]:)[/noparse] The MIPS instruction set is very small (COG-able), powerful, and obviously has more address range capability than the other emulated processors (which is trading one straight jacket for another IMHO).
Post Edited (jazzed) : 12/10/2009 4:44:12 PM GMT
The thing is that we will have to emulate some instructions like jmp, push, pop, and so on. Even if the rest are native... it contains an emulator for things that are actually non-existant. It may be seen like a soft-float "package" though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Hey what kernel/user space?. We presumably have no MMU on this hypothetical Prop Linux, therefore nor user/kernel space divide to speak of. Just a flat EXT RAM space.
I suspect data would go from SD to HUB (normal SD low level driver stuff). Then HUB to EXT RAM to satisfy the kernel's request. Perhaps into some place that the kernel "thinks" is kernel space. After that we don't care what Linux does with it in EXT RAM.
Ale: "So if the kernel buffers are in HUB then...." Do you mean the Linux kernel or the XMM kernel?
I imaging life is easier if the all the Linux stuff is in EXT RAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
No, their compiler produces code for their chips instruction set. Something that never existed before. Presumably they added a new code generator to LLMV.
"Sounds like a job for heater [noparse]:)[/noparse] R3000/R4000 MIPS maybe?" - Don't get me started, I'll end up wasting the next two years of my life as well and on top of that not be eligible for the prize.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just curious?
No, I believe Brad's challenge is specific to running a Linux 2.6 (or later) kernel.
Running a "unix-like" or posix-compatible kernel would be easier (I believe several such developments are already underway) but this challenge is for Linux.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
It's BradC's money so it's BradC's rules for the challenge and no complaint there, but if anyone were to get Linux running via emulation I think many would still be impressed and it may be a stepping stone or driving force toward the money pot ( though I doubt the money will mean more than the accolades ).
The same applies to other ideas which won't meet the winning criteria; if you think you can and want to, simply go for it.
It's gotta be done! There's even a Linux type unix for the Commodore 64!
LUnix
hld.c64.org/poldi/lunix/lundoc/lng.html
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
www.linux-mips.org/wiki/Main_Page
www.home.unix-ag.org/nils/mips/linux-mips.html
If I was not so darned busy, I'd write a MIPS R2000 emulator, it looks like a really cool project. Heck, if no one tackles it within six months, I'll probably do it!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller