Shop OBEX P1 Docs P2 Docs Learn Events
uclinux — Parallax Forums

uclinux

m00tykinsm00tykins Posts: 73
edited 2014-11-15 15:47 in Propeller 2
Hello again everyone,

I recently found out about uclinux, which is based on the Linux kernel but doesn't require an mmu. I think this would be a much better os port to the prop2 but will of course be much more difficult than contiki. I was wondering if anyone here would be interested in helping port uclinux. It requires several megabytes of ram so lmm will of course be necessary. Once the prop2 comes out I will set up a github for the port. Let me know if you'd like to help. Thank you!

-moot

Comments

  • David BetzDavid Betz Posts: 14,516
    edited 2014-11-10 20:40
    m00tykins wrote: »
    Hello again everyone,

    I recently found out about uclinux, which is based on the Linux kernel but doesn't require an mmu. I think this would be a much better os port to the prop2 but will of course be much more difficult than contiki. I was wondering if anyone here would be interested in helping port uclinux. It requires several megabytes of ram so lmm will of course be necessary. Once the prop2 comes out I will set up a github for the port. Let me know if you'd like to help. Thank you!

    -moot
    If it requires "several megabytes of ram" then I think you'll need XMM not LMM since LMM is limited to 32k of hub memory. How much of this memory can be essentially read-only? If it all has to be read/write then you'll need to use external RAM rather than just flash. Also, you'll need a C compiler that can generate position independent code. I think this was also mentioned in another thread that talked about some other minimalistic Unix-like OS.
  • m00tykinsm00tykins Posts: 73
    edited 2014-11-10 20:54
    Right, xmm, my mistake. Also, doesn't gcc support pic?
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2014-11-11 08:50
    Sure, the PIC supports GCC (in some cases), but so does the Propeller 1.

    The thing here is you started out wanting Linux.. which is a lot more and generally requires a SOC (system on a chip) architecture.

    In many, many situations --- Linux actually gets in the way. Writing code directly for the Propeller without the added burden of an OS can actually do many things better. But if you want GCC for the PIC or the Propeller, you will have to cross-compile in an OS (and that can be done in Linux, Windows, or iOS).
  • LeonLeon Posts: 7,620
    edited 2014-11-11 08:52
    I think he is referring to Position Independent Code, rather than the Microchip PIC.
  • Dave HeinDave Hein Posts: 6,347
    edited 2014-11-11 09:00
    GCC does have a compiler option to generate position independent code, but I'm certain that the option is not supported for the Prop.
  • Heater.Heater. Posts: 21,230
    edited 2014-11-11 14:29
    m00tykins,

    Interesting idea. An idea that has been tossed around here a few times over the years.

    RAM is not a problem. I have a GadgetGangster board here with a Propeller and 32MB of RAM. That is enough to run a Linux system. Of course making use of it will be slow as hell but logically it is doable.

    What else do we need for Linux?

    1) A memory management unit (MMU). Needed for virtual memory. No problem, we already have an interpreter fetching and executing code from external memory so adding checking for page faults and doing MMU stuff can be added there.

    2) Interrupts. At least one. The timer tick. That's how tasks get scheduled. The Propeller does not have interrupts. Again no problem. That interpreter, whilst fetching and executing instructions from external memory, can also check if it has timer tick or other interrupt.

    Of course all that will make execution speed uselessly slow. But it can be done. We know it can be done because Linux has been run on an 8 bit AVR processor. You can watch the three and a half hour video of Linux on AVR booting to the command prompt here:
    http://dmitry.gr/index.php?r=05.Projects&proj=07.+Linux+on+8bit

    Perhaps with the 32 bit P2 we can get that down to half an hour or so.
  • Brian FairchildBrian Fairchild Posts: 549
    edited 2014-11-12 01:57
    m00tykins,

    I can't help but think that you're trying to re-invent the (round) wheel using a square processor. The P1 and P2 aren't designed for CPU duties; they're designed as real-time microcontrollers and lack just about everything needed to run a full, or even cut-down, operating system.

    If you really want to build something different then why not investigate areas where the Prop ought to do well?

    Why not look at implementing a multicore operating system? One where each thread/task is launched into its own COG. One where you expand throughput by adding on additional processors. One where message passing is done as part of the hardware design.
  • kwinnkwinn Posts: 8,697
    edited 2014-11-12 10:38
    m00tykins,

    I can't help but think that you're trying to re-invent the (round) wheel using a square processor. The P1 and P2 aren't designed for CPU duties; they're designed as real-time microcontrollers and lack just about everything needed to run a full, or even cut-down, operating system.

    If you really want to build something different then why not investigate areas where the Prop ought to do well?

    Why not look at implementing a multicore operating system? One where each thread/task is launched into its own COG. One where you expand throughput by adding on additional processors. One where message passing is done as part of the hardware design.

    +1
  • Heater.Heater. Posts: 21,230
    edited 2014-11-12 11:52
    m00tykins,

    Sorry, I confused uclinux with uclibc. So when I said we need an MMU that was not exactly true.

    But the end conclusion is the same. With some huge amount of effort I'm sure one could get some kind of Linux to run on the P2. As a curiosity that might occupy your mind for a long while and keep you off the streets that's great but at the end of the day it will have no practical use.

    Linux on the 8 bit AVR is a serious curiosity because it was not about getting Linux to run on an AVR but rather writing an Intel 386 emulation for the AVR that was accurate enough to then boot Linux.

    I have no idea why anyone would want to do that, but hey, I'm crazy and it seems others are more crazy.

    Of course there was a time when I said that a C compiler for the Propeller was pointless and "impossible". Since then we have seen three C compilers for the Prop.


  • jmgjmg Posts: 15,173
    edited 2014-11-12 14:26
    Heater. wrote: »
    Linux on the 8 bit AVR is a serious curiosity because it was not about getting Linux to run on an AVR but rather writing an Intel 386 emulation for the AVR that was accurate enough to then boot Linux.

    I have no idea why anyone would want to do that, but hey, I'm crazy and it seems others are more crazy.

    Of course it is crazy, but the sort of crazy that just has to impress :)
  • m00tykinsm00tykins Posts: 73
    edited 2014-11-15 13:56
    Heater brings up a good point, and although this project is more for fun than anything it will probably still be much slower using uclinux than contiki. I think I'll settle on a contiki port instead. :)
  • Heater.Heater. Posts: 21,230
    edited 2014-11-15 15:47
    mootykins,

    I think getting contiki running on the P2 could be a lot of fun.It's even likely to attract users and perhaps contributors which would make it even more fun.

    I have not looked into contiki much but when the C compilers started to appear for the Propeller there was one idea that attracted me. contiki has a slip interface driver. That is the "Serial Line Internet Protocol". Slip is what we used to run IP over serial before PPP was invented.

    Slip is still part of Linux so one could have a direct serial connection from Linux to Propeller that looks like a network socket connection!

    Or run slip over that wireless UART adapter and server up web pages from the Prop!

    Probably not practical proposition but the idea fascinated me for a while.
Sign In or Register to comment.