I agree that if you only do serial comms (i.e. no local kbd/screen), or if you can do a "1 pin" keyboard and screen driver then you may get by with a single Prop. I also agree the situation may be somewhat different for other *nixes - but Brad specified Linux kernel 2.6 or greater, and in this case you would never be able to do it in 512Kb RAM.
The size of the Linux 2.6 kernel is between 600Kb and 1.5Mb (on intel - say between 1Mb and 3Mb when ported to the Prop). While you may be able to find some more parts of the kernel to dump, you also have to keep in mind that even a minimal linux system needs more than just a kernel.
That's why I think you will need somewhere between 2Mb and 4Mb physical RAM. Also worth keeping in mind is that most PCs reduce their physical RAM requirements by using virtual memory, but that's is not feasible here - even if someone had a scheme working on the Prop it probably wouldn't work on this scale due to the slow read/write speeds of SD cards - so all this has to all be physical RAM.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Yes, that was my point. I do not concur with Brads requirement. I would not be doing it for the challenge, per se. I would be doing it for a purpose with all the additional restrictions that brings
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Ale said...
Brad: Then you may be better off with 2.0.39. The lacking point is still binutils/gcc,
Not really.
A) There is no point porting an ancient kernel. (and I was using 2.0.39 in about 1997!) If you can get 2.0.39 to run, 2.6 is a small puddle jump.
The hurdle is, and has always been the toolchain.
See, *IF* and only if you can make the toolchain viable, getting a new architecture into the upstream kernel is actually not overly difficult provided the code is fairly self contained and clean. If you base on a 2.6 kernel you get all the new goodness for free and can easily keep things working for newer versions. When the next chip arrives, you'll get USB host, Networking, Frame Buffer and all the good things those bring with them for a very limited amount of ultra-low level driver code. All the upper level already exists.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
It is not only the toolchain, it is also the platform. I have such a board with enough RAM, or you can use mctrivia's latest PSRAM upgrade, but it is just there are other thing to do that may be more rewarding.
Another thread for hungry Hanno...
I ran Slackware Linux (from floppies) in '95 on my Pentium 90MHz. So yes, I think it is possible but damn hard. So, I'm not willing to eat a PropScope or even a whole ProtoBoard. I will eat a QLD Propeller if someone meets Brad's challenge.
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here), 12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
I ported the 2.0.38? kernel to one S8/300H derivative (3062? 3067?) (similar to the 68K but with some differences) and it ran at 8 MHz. That was slow!. But the toolchain was available (the port had been done just months before but was somewhat flacky) and the code for some other derivative existed already in the kernel. It took me some time and the image alone was around 700 kbytes.
I know some of the work will be used later on on the prop2 but do we need another C compiler ? we have 2 already...
I also ran Linux 2.0.26, I think, on a 486 100 MHz with 16 megs of RAM in 96/97.
I ran Coherent on an 8MHz 80286, then later Coherent/386 on a 25MHz 80386
A Prop is WAY faster than an 8MHz 80286 (except for mul & div) - but it was not Linux.
Largos is loosely modeled on an updated, message passing Unix somewhere between Bell Lab's v6 and v7, but modernized - and without fork() (but including a spawn() call)
Ale said...
I ported the 2.0.38? kernel to one S8/300H derivative (3062? 3067?) (similar to the 68K but with some differences) and it ran at 8 MHz. That was slow!. But the toolchain was available (the port had been done just months before but was somewhat flacky) and the code for some other derivative existed already in the kernel. It took me some time and the image alone was around 700 kbytes.
I know some of the work will be used later on on the prop2 but do we need another C compiler ? we have 2 already...
I also ran Linux 2.0.26, I think, on a 486 100 MHz with 16 megs of RAM in 96/97.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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
A 486 was about 20 mips - I'd guess a Prop using LMM/XMM techniques to run Linux would be about 5-10 times slower than that. This takes into account the unsuitability of the architecture for this type of application, and also the lack of some instructions (like mul & div, as Bill pointed out) which will slow things down further.
This is not a criticism of the Prop - just pointing out that there are some things the Prop will never do well, because it's architecture was not intended for this type of application. Won't stop someone doing it though!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I'm taking the challenge. This summer break I am going to try to get this working with a couple of my friends here, hopefully before 11th grade starts and the grind returns.
@Hanno-I would reconsider your promise, I have a feeling one of the superhackers here will figure this out at some point before the deadline [noparse]:)[/noparse]
Good luck SciNemo! I do hope you get it going. And like I posted, I do think it's possible, just very very hard. Since it's possible, I'm only willing to eat a QLD Propeller- crushed to little bits that shouldn't be too hard- wonder what it tastes like?
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here), 12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
Hanno said...
Good luck SciNemo! I do hope you get it going. And like I posted, I do think it's possible, just very very hard. Since it's possible, I'm only willing to eat a QLD Propeller- crushed to little bits that shouldn't be too hard- wonder what it tastes like?
Hanno
Please make sure that it is RoHS. Don't want you to get lead poisoning. BTW semiconductors do contain some arsenic.
SciNemo said...
I'm taking the challenge. This summer break I am going to try to get this working with a couple of my friends here, hopefully before 11th grade starts and the grind returns.
Good luck! I think the first step is going to be understanding what Linux requires from and assumes about the underlying hardware platform. (As you really are starting from scratch here.) You will also need to nail down your target hardware platform. I suspect a RAMBlade will be the minimum spec, and even then you may find the 512K RAM too small. Hardware in hand, you can then put together the actual PASM code - device drivers and the XMM. In parallel you then need to adapt gcc & Catalina to emit XMM code. You also will nedd to figure out how you're going to debug everything. Lots of variables, lots of things to break in very unusual ways.
<edit>You will also need to "port" one of the boot loaders (i.e. GRUB or U-Boot) to load the kernel from SD to the external memory.· This will become a part of the code loaded from the EEPROM which will initialize all of the "device driver" cogs, then load the kernel into external memory and kickstart the XMM.· Another idea I had is to put a hook into the serial driver which would stop the XMM and then dump all of external memory and HUB RAM to SD.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObExForum
OnePinTVText driver: ObExForum
As I posted in response to Cluso's earlier posts, 512Kb will probably be way too small - but it may be enough to get you started.
Also, the Catalina compiler already generates XMM code - that's why I suggested using the Catalina kernel (i.e. it's known to execute XMM code generated by an XMM-enabled C compiler on at least four platforms already, so it will give you a good start on porting GCC to an XMM target).
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
SciNemo said...
I'm taking the challenge. This summer break I am going to try to get this working with a couple of my friends here, hopefully before 11th grade starts and the grind returns.
Good luck! I think the first step is going to be understanding what Linux requires from and assumes about the underlying hardware platform. (As you really are starting from scratch here.)
Linux has very few assumptions about the underlying platform.
Here's a few random thoughts to help get you started (What!? you say, he's put money on the line *and* he's trying to help??)
Linux uses a soft interrupt for its kernel entry when issuing a syscall. You might need to factor that into your LMM kernel design to allow userspace code to issue system calls.
Without applying the uCLinux patches, the arch/m68knommu directory has quite a simple architecture for 32 bit, 68k series processors like the coldfire that have no MMU. As the Propeller has no mmu, this might be a relatively simple base to start from.
Having a look at the code in arch/m68knommu/setup.c will give you an idea as to the type of configuration required to enable different configurations or processor variants in a kernel configuration.
arch/m68knommu/entry.S will give you a good look at the system interrupts/traps you will have to implement to get a functioning kernel that can be called from userspace code.
arch/m68knommu/platform/coldfire/head.S is a good look at the platform specific assembler run at the very start of boot that sets up the hardware the way you need it.
Download the latest kernel source and have a poke around the arch/ directory tree. It will give you a good feel for how each architecture differs and how you might go about creating an architecture that would do what you need it to do.
Remember, the key is interrupts. The Kernel lives on interrupts. Outside of the hardware drivers (and I'm almost convinced there is a simple way around that) the two most critical interrupts are :
- Hardware - The timer interrupt. This sends an interrupt to the kernel every 1/HZ seconds (usually between 100 & 1000).
- Software - The Syscall interrupt. Your application code must be able to load some registers and issue a soft interrupt which will transfer operation into the kernel.
As a kludge (an *ugly* kludge, but still a valid way of operating), your hardware drivers could be run as polled kernel threads and not need hardware interrupts. You would need two of these. One for the serial port, and one for the SD/MMC interface, primarily to signal completion or pending data.
One way around the interrupt issue might be to use a port pin as a semaphore. When an interrupt is pending the interrupt vector is placed into hub ram somewhere and the port pin is toggled. The LMM kernel might check for this and commence the interrupt routine.
There is absolutely nothing that says you can't use hacky low level assembler in your drivers. For example the SD block driver might write a block number to read to a defined location in hub ram. Your SD driver running in another cog goes away, reads the data into a fixed buffer location and interrupts the kernel to say "hey, I'm done, your data is in that fixed location we both already know about". Same with the serial port. You might well have a couple of big circular buffers that the kernel knows the location of, and the serial code is off in another cog. These could be pre-loaded and configured prior to the kernel boot commencing.
Now, all this is well and good, but your first challenge will likely be getting a viable target for GCC running. On that I have very little advice to offer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
I just realized a second problem with the RAMBlade is the SD bus is shared with the SRAM. This means there would need to be some kind of interaction between the SD driver and the XMM. Thinking about it, has anyone done an external memory board with a multiplexed 16 bit data + address low / address high bus? (32 bit address, 16 bit data). Byte access would be harder (or would need extra external logic), but word/long access would be faster. This would also free up some pins for a dedicated SD interface.
If the timer interrupt & syscall interrupt are the only requirements then those could be integrated into the XMM. A timer could be implemented by checking CNT periodically then performing the "interrupt" when the delta is more than N. The syscall is a simple taskswitch / subroutine call.
I agree that device drivers could be simple HUB memory-mapped devices. Start with just the SD block driver and the serial I/O driver.
One other task will be to "port" one of the boot loaders (i.e. GRUB or U-Boot) to load the kernel from SD to the external memory. This will become a part of the code loaded from the EEPROM which will initialize all of the "device driver" cogs, then load the kernel into external memory and kickstart the XMM. Another idea I had is to put a hook into the serial driver which would stop the XMM and then dump all of external memory and HUB RAM to SD. This would be especially usefull if the XMM stored the thread state in HUB RAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObExForum
OnePinTVText driver: ObExForum
Hardware-wise, a shared 8 bit data bus 2 Propeller design would be fastest and provide a reasonable amount of memory.
* Use one Propeller as the XMM engine handling up to 8MB unlatched PSRAM.
* The other Propeller memory map selected would handle peripheral interfaces.
I have something similar on my desk. This provides much flexibility for doing code fetch/execute in the LMM external memory fetcher. Unfortunately the best performance one could get would be about 1.6 MIPS.
Still, there is the apparently unsolvable problem of porting the GNU tool chain. :<
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
It's fair to share cycles with the SD card one way or another. Performance will be limited in any event. I'm not very fond of writing images to SD card and moving them around for development (sneaker net). Having a network attached especially for Linux (as if that will ever happen on Propeller LOL) would be great but would require hardware flexibility. Now if I could only get out of this straight jacket ....
BTW: HUB access Pseudo-DMA at 5MB/s is possible with pins P0:8 assuming P8 is the Select/TerminalCount bit ... I've done this before with OctoProp.
heater said...
1) There is no problem with sharing the SD card with the memory on the same bus . . .
3) I'm sure a 512Kb TriBlade is not enough.
Fair enough, just wanted to point it out.· Either way is "workable".· But if a TriBlade isn't large enough and a different architecture is required then it might be a good idea to have a separate bus.
heater said...
2) There is no problem with a boot loader. GRUB etc not required.
It's not GRUB as a boot loader per-se, but GRUB et. al. grok the various Linux filesystems which may be required to load the kernel.· Having the Linux kernel separate from the filesystem may be possible but might also cause problems in the build chain.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObExForum
OnePinTVText driver: ObExForum
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.
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
eric: Yep, if the kernel image is in the Linux file system then the boot loader has to know something about the file system. However I have worked with PowerPC based Linux boxes where the kernel was not in the FS, just sitting somewhere in the FLASH memory. So just load it from FLASH to memory and go. No idea about the details but it is doable.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
... 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.
Assuming XMM fetches from external memory or cache (on-cog or in hub) which is possible but may not be preferred ... if the kernel has requested a service from within the Propeller, the kernel would be executing intra-cog waiting for the service request to be fulfilled.
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.
Granted easier, but what's the point of Linux without networking? May as well be running CPM or Win95 [noparse];)[/noparse]
I've worked in Linux dev environments where GRUB was not necessary for any reason at all, but it's still nice to have to avoid monolithic image loads (10 minute coffee breaks).
jazzed: "what's the point of Linux without networking"
Pretty much no point at all, but then look what we are discussing here[noparse]:)[/noparse]
"avoid monolithic image loads"
Monolithic downloads not required. The 1MByte or so kernel image on SD can be updated pretty quickly independently of the FS. A few megs of basic FS is similarly quick.
Both the kernel and Linix FS images could exist as separate files on the SD under FAT!
I don't have time to make or drink coffee while updating the 8MB CP/M images we use.
Suggest using the Minix FS for minimal kernel size, or perhaps one of the files systems intended for embedded systems. What is it, JAFFS or JFFS ?
I can feel the straps being tightened on my straight jacket as well[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
I agree that if you only do serial comms (i.e. no local kbd/screen), or if you can do a "1 pin" keyboard and screen driver then you may get by with a single Prop. I also agree the situation may be somewhat different for other *nixes - but Brad specified Linux kernel 2.6 or greater, and in this case you would never be able to do it in 512Kb RAM.
The size of the Linux 2.6 kernel is between 600Kb and 1.5Mb (on intel - say between 1Mb and 3Mb when ported to the Prop). While you may be able to find some more parts of the kernel to dump, you also have to keep in mind that even a minimal linux system needs more than just a kernel.
That's why I think you will need somewhere between 2Mb and 4Mb physical RAM. Also worth keeping in mind is that most PCs reduce their physical RAM requirements by using virtual memory, but that's is not feasible here - even if someone had a scheme working on the Prop it probably wouldn't work on this scale due to the slow read/write speeds of SD cards - so all this has to all be physical RAM.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Yes, that was my point. I do not concur with Brads requirement. I would not be doing it for the challenge, per se. I would be doing it for a purpose with all the additional restrictions that brings
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Not really.
A) There is no point porting an ancient kernel. (and I was using 2.0.39 in about 1997!)
If you can get 2.0.39 to run, 2.6 is a small puddle jump.
The hurdle is, and has always been the toolchain.
See, *IF* and only if you can make the toolchain viable, getting a new architecture into the upstream kernel is actually not overly difficult provided the code is fairly self contained and clean. If you base on a 2.6 kernel you get all the new goodness for free and can easily keep things working for newer versions. When the next chip arrives, you'll get USB host, Networking, Frame Buffer and all the good things those bring with them for a very limited amount of ultra-low level driver code. All the upper level already exists.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
// richard
I concur.
It is not only the toolchain, it is also the platform. I have such a board with enough RAM, or you can use mctrivia's latest PSRAM upgrade, but it is just there are other thing to do that may be more rewarding.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I ran Slackware Linux (from floppies) in '95 on my Pentium 90MHz. So yes, I think it is possible but damn hard. So, I'm not willing to eat a PropScope or even a whole ProtoBoard. I will eat a QLD Propeller if someone meets Brad's challenge.
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
I started out with Linux on a 486.
Seems to me Linux on a Prop would be at least 50 times slower than that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I know some of the work will be used later on on the prop2 but do we need another C compiler ? we have 2 already...
I also ran Linux 2.0.26, I think, on a 486 100 MHz with 16 megs of RAM in 96/97.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
A Prop is WAY faster than an 8MHz 80286 (except for mul & div) - but it was not Linux.
Largos is loosely modeled on an updated, message passing Unix somewhere between Bell Lab's v6 and v7, but modernized - and without fork() (but including a spawn() call)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
A 486 was about 20 mips - I'd guess a Prop using LMM/XMM techniques to run Linux would be about 5-10 times slower than that. This takes into account the unsuitability of the architecture for this type of application, and also the lack of some instructions (like mul & div, as Bill pointed out) which will slow things down further.
This is not a criticism of the Prop - just pointing out that there are some things the Prop will never do well, because it's architecture was not intended for this type of application. Won't stop someone doing it though!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
But yes, I know you are right.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I still don't think I've heard anyone accept the challenge
Rick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
NYC Area Prop Club
Prop Forum Search (Via Google)
·
@Hanno-I would reconsider your promise, I have a feeling one of the superhackers here will figure this out at some point before the deadline [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Not the fish.
sites.google.com/site/bitwinproject/
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
Please make sure that it is RoHS. Don't want you to get lead poisoning. BTW semiconductors do contain some arsenic.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Not the fish.
sites.google.com/site/bitwinproject/
here's some linux info that may be worth reading.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Arguing with myself--sometimes me, myself, and I don't always agree.
(Former) Caterpillar product support technician
<edit>You will also need to "port" one of the boot loaders (i.e. GRUB or U-Boot) to load the kernel from SD to the external memory.· This will become a part of the code loaded from the EEPROM which will initialize all of the "device driver" cogs, then load the kernel into external memory and kickstart the XMM.· Another idea I had is to put a hook into the serial driver which would stop the XMM and then dump all of external memory and HUB RAM to SD.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
Post Edited (ericball) : 12/8/2009 1:18:44 PM GMT
As I posted in response to Cluso's earlier posts, 512Kb will probably be way too small - but it may be enough to get you started.
Also, the Catalina compiler already generates XMM code - that's why I suggested using the Catalina kernel (i.e. it's known to execute XMM code generated by an XMM-enabled C compiler on at least four platforms already, so it will give you a good start on porting GCC to an XMM target).
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Linux has very few assumptions about the underlying platform.
Here's a few random thoughts to help get you started (What!? you say, he's put money on the line *and* he's trying to help??)
Linux uses a soft interrupt for its kernel entry when issuing a syscall. You might need to factor that into your LMM kernel design to allow userspace code to issue system calls.
Without applying the uCLinux patches, the arch/m68knommu directory has quite a simple architecture for 32 bit, 68k series processors like the coldfire that have no MMU. As the Propeller has no mmu, this might be a relatively simple base to start from.
Having a look at the code in arch/m68knommu/setup.c will give you an idea as to the type of configuration required to enable different configurations or processor variants in a kernel configuration.
arch/m68knommu/entry.S will give you a good look at the system interrupts/traps you will have to implement to get a functioning kernel that can be called from userspace code.
arch/m68knommu/platform/coldfire/head.S is a good look at the platform specific assembler run at the very start of boot that sets up the hardware the way you need it.
Download the latest kernel source and have a poke around the arch/ directory tree. It will give you a good feel for how each architecture differs and how you might go about creating an architecture that would do what you need it to do.
Remember, the key is interrupts. The Kernel lives on interrupts. Outside of the hardware drivers (and I'm almost convinced there is a simple way around that) the two most critical interrupts are :
- Hardware - The timer interrupt. This sends an interrupt to the kernel every 1/HZ seconds (usually between 100 & 1000).
- Software - The Syscall interrupt. Your application code must be able to load some registers and issue a soft interrupt which will transfer operation into the kernel.
As a kludge (an *ugly* kludge, but still a valid way of operating), your hardware drivers could be run as polled kernel threads and not need hardware interrupts. You would need two of these. One for the serial port, and one for the SD/MMC interface, primarily to signal completion or pending data.
One way around the interrupt issue might be to use a port pin as a semaphore. When an interrupt is pending the interrupt vector is placed into hub ram somewhere and the port pin is toggled. The LMM kernel might check for this and commence the interrupt routine.
There is absolutely nothing that says you can't use hacky low level assembler in your drivers. For example the SD block driver might write a block number to read to a defined location in hub ram. Your SD driver running in another cog goes away, reads the data into a fixed buffer location and interrupts the kernel to say "hey, I'm done, your data is in that fixed location we both already know about". Same with the serial port. You might well have a couple of big circular buffers that the kernel knows the location of, and the serial code is off in another cog. These could be pre-loaded and configured prior to the kernel boot commencing.
Now, all this is well and good, but your first challenge will likely be getting a viable target for GCC running. On that I have very little advice to offer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
If the timer interrupt & syscall interrupt are the only requirements then those could be integrated into the XMM. A timer could be implemented by checking CNT periodically then performing the "interrupt" when the delta is more than N. The syscall is a simple taskswitch / subroutine call.
I agree that device drivers could be simple HUB memory-mapped devices. Start with just the SD block driver and the serial I/O driver.
One other task will be to "port" one of the boot loaders (i.e. GRUB or U-Boot) to load the kernel from SD to the external memory. This will become a part of the code loaded from the EEPROM which will initialize all of the "device driver" cogs, then load the kernel into external memory and kickstart the XMM. Another idea I had is to put a hook into the serial driver which would stop the XMM and then dump all of external memory and HUB RAM to SD. This would be especially usefull if the XMM stored the thread state in HUB RAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
* Use one Propeller as the XMM engine handling up to 8MB unlatched PSRAM.
* The other Propeller memory map selected would handle peripheral interfaces.
I have something similar on my desk. This provides much flexibility for doing code fetch/execute in the LMM external memory fetcher. Unfortunately the best performance one could get would be about 1.6 MIPS.
Still, there is the apparently unsolvable problem of porting the GNU tool chain. :<
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
BTW: HUB access Pseudo-DMA at 5MB/s is possible with pins P0:8 assuming P8 is the Select/TerminalCount bit ... I've done this before with OctoProp.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Granted easier, but what's the point of Linux without networking? May as well be running CPM or Win95 [noparse];)[/noparse]
I've worked in Linux dev environments where GRUB was not necessary for any reason at all, but it's still nice to have to avoid monolithic image loads (10 minute coffee breaks).
Pretty much no point at all, but then look what we are discussing here[noparse]:)[/noparse]
"avoid monolithic image loads"
Monolithic downloads not required. The 1MByte or so kernel image on SD can be updated pretty quickly independently of the FS. A few megs of basic FS is similarly quick.
Both the kernel and Linix FS images could exist as separate files on the SD under FAT!
I don't have time to make or drink coffee while updating the 8MB CP/M images we use.
Suggest using the Minix FS for minimal kernel size, or perhaps one of the files systems intended for embedded systems. What is it, JAFFS or JFFS ?
I can feel the straps being tightened on my straight jacket as well[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.