This may not belong in this section - except that this device doesn't have anything to do with puppy (yet...) but I wondered if anyone had looked at what this device might be capable of and how to program/boot it?
https://deals.sourceforge.net/sales/voc ... x-computer
VoCore miniature Linux computer
VoCore miniature Linux computer
- Attachments
-
- VoCore.jpg
- (28.93 KiB) Downloaded 354 times
With 32MB RAM and 8MB storage you would need a very specific purpose. Only a tiny X server would be possible. But I don't see the point. The boot loader should allow you to do what you like but as said it would want to be very specific.
My guess is that they are targeting IOT use cases.
My guess is that they are targeting IOT use cases.
Puppy Linux Blog - contact me for access
-
gcmartin
Puppy concretely cannot run on that board. We don't have a port for the MIPS architecture (yet?) -- so the SoC (System-on-Chip, basically a whole motherboard, including CPU and sometimes but not always RAM and ROM, on one chip) is 100% incompatible.
I can't find a direct "MIPS has 'x'% the speed of x86" line the way I have for a generalized ARM architecture. One ARM instruction cycle is worth ROUGHLY one-and-one-quarter x86 instruction cycles, although that is informal and hearsay from my local tech guy -- he knows his stuff, but I could easily devote a couple paragraphs to why that is an extreme generalization. The one-sentence version is that there's a TON of different kinds of ARM and they all have somewhat different performance abilities vs modern x86 CPUs (which can be considered to start with the Pentium III, and not include the Pentium 4 and Atom CPUs for likewise technical and complicated reasons).
That said, for this specific board, performance efficiency doesn't matter much. At 350MHz... you are not going to get anything useful out of that no matter what you do. Forget graphics, particularly since it doesn't have a monitor port or any hardware to drive it -- no interface, no support. You might be able to run a thin client off it (SSH/RDP/etc into it) but that totally defeats the point of using the dang thing, because the thin client not only is x86, but literally unless it is from about 1998 or so, it necessarily has better hardware than what's in the VoCore!
For two VoCores, I could put together a Wyse Cx0-series client (such as a C90LE) with an SD card, IDE-to-SD adapter and 44pin cable, DVI-to-VGA adapter, and wire up a fan from the junk box besides. Assuming the OpenChrome v.0.4.0 driver now works (which by golly it should, at this point -- I just haven't gotten up the oomph to test the dang thing) that means that with a little massaging, TahrPup 6.0.5 could run on there just fine. That, and it will run blue blazes around a VoCore... which is probably roughly comparable to a Wyse Sx0-series client (366MHz Geode) with as little RAM in it as it will boot with. You'd be better off trying to port Puppy to this project. Trust me -- I've got a Wyse Sx0, and it's positively awful.
I can't find a direct "MIPS has 'x'% the speed of x86" line the way I have for a generalized ARM architecture. One ARM instruction cycle is worth ROUGHLY one-and-one-quarter x86 instruction cycles, although that is informal and hearsay from my local tech guy -- he knows his stuff, but I could easily devote a couple paragraphs to why that is an extreme generalization. The one-sentence version is that there's a TON of different kinds of ARM and they all have somewhat different performance abilities vs modern x86 CPUs (which can be considered to start with the Pentium III, and not include the Pentium 4 and Atom CPUs for likewise technical and complicated reasons).
That said, for this specific board, performance efficiency doesn't matter much. At 350MHz... you are not going to get anything useful out of that no matter what you do. Forget graphics, particularly since it doesn't have a monitor port or any hardware to drive it -- no interface, no support. You might be able to run a thin client off it (SSH/RDP/etc into it) but that totally defeats the point of using the dang thing, because the thin client not only is x86, but literally unless it is from about 1998 or so, it necessarily has better hardware than what's in the VoCore!
For two VoCores, I could put together a Wyse Cx0-series client (such as a C90LE) with an SD card, IDE-to-SD adapter and 44pin cable, DVI-to-VGA adapter, and wire up a fan from the junk box besides. Assuming the OpenChrome v.0.4.0 driver now works (which by golly it should, at this point -- I just haven't gotten up the oomph to test the dang thing) that means that with a little massaging, TahrPup 6.0.5 could run on there just fine. That, and it will run blue blazes around a VoCore... which is probably roughly comparable to a Wyse Sx0-series client (366MHz Geode) with as little RAM in it as it will boot with. You'd be better off trying to port Puppy to this project. Trust me -- I've got a Wyse Sx0, and it's positively awful.
Wow - that is an inspirational project. Thanks for posting the link. Everyone should read that article just to get the flavour of the huge talent those hardware designers have brought to the table over the years. One of the comments there says something like "you just crossed the line from passion to insanity". I reckon that'll sound familiar to some of the puppy devsstarhawk wrote: You'd be better off trying to port Puppy to this project.
*shrug* It is a little crazy. The chip he's using is a microcontroller -- it's meant to turn lights on and off, read sensors, and spin motors. Basically.
It's a similar chip to what's on an Arduino Uno... only the Uno is running at 2/3 the speed of the chip in the article, and it has more programming to run through (because of the Arduino bootloader/environment vs Dmitry's code which runs "bare metal" -- he programmed it in assembly!), and oh by the way, only half of the internal RAM that the chip Dmitry used has. (For the record, Dmitry says he tried an ATMega 644, which has the same amount of internal RAM as an Uno -- and it apparently worked just fine, once he made some low-level adjustments...) FWIW, the ATMega1284 has more GPIO pins (general purpose input/output leads coming off the chip -- more stuff to do things with) than an Uno, by about double -- which is the only reason he could hook a 30 pin SIMM to it!
I thought about trying to hook a 72 pin SIMM up to an ATMega 2560 (which is a more capable chip used in the Arduino Mega board) but, aside from that chip only coming in surface-mount form (making it a real PITA to put down on a board -- you either need custom PCBs for that (expensive) or a DIP adapter (fiddly) -- and in both cases you need to be DAMN good at soldering), I'd use up all the GPIOs just interfacing to the RAM -- there'd be almost nothing left for SD cards or communicating with the outside world, meaning that I'd have to come up with some sort of nasty bus-arbitration thing so that some of the GPIO lines were doing double (or triple!) duty... screw that. Not to mention I can't code basically at all...
It's a similar chip to what's on an Arduino Uno... only the Uno is running at 2/3 the speed of the chip in the article, and it has more programming to run through (because of the Arduino bootloader/environment vs Dmitry's code which runs "bare metal" -- he programmed it in assembly!), and oh by the way, only half of the internal RAM that the chip Dmitry used has. (For the record, Dmitry says he tried an ATMega 644, which has the same amount of internal RAM as an Uno -- and it apparently worked just fine, once he made some low-level adjustments...) FWIW, the ATMega1284 has more GPIO pins (general purpose input/output leads coming off the chip -- more stuff to do things with) than an Uno, by about double -- which is the only reason he could hook a 30 pin SIMM to it!
I thought about trying to hook a 72 pin SIMM up to an ATMega 2560 (which is a more capable chip used in the Arduino Mega board) but, aside from that chip only coming in surface-mount form (making it a real PITA to put down on a board -- you either need custom PCBs for that (expensive) or a DIP adapter (fiddly) -- and in both cases you need to be DAMN good at soldering), I'd use up all the GPIOs just interfacing to the RAM -- there'd be almost nothing left for SD cards or communicating with the outside world, meaning that I'd have to come up with some sort of nasty bus-arbitration thing so that some of the GPIO lines were doing double (or triple!) duty... screw that. Not to mention I can't code basically at all...