Slashdot Mirror

I have the same player. It's great, but I too would like to modify the source. It would've been cool to add network functionality using the PCMCIA-slot etc.

I've downloaded the ROMFS. The root contained these files (and some images etc): fileplayer.bin, fipmodule.o, khwl.o, linux.bin.gz, minimod, mpegplayer.bin

Seems like the 'real' (custom?) system is contained in /bin/init (binary). (The strings output of that file makes me believe so)

khwl.o (using strings): EM85xx driver module /project/liteon-release/v0.02.27/uClinux-2.4/ 2.4.17-uc0 Proprietary. Copyright (c) 2002 Sigma Designs Inc. All rights reserved.

So maybe they use a stock uClinux kernel, some proprietary modules, and a custom init system?

If the init system doesn't contain any GPL-code, do they have to release it? How about the legality of including proprietary modules? If it's ok, don't they only have to say: "Get the source for the kernel at uClinux.org"? - and make it pretty much unhackable?

You can get the ROMFS I used at Kiss-Tuning's download area.
By the way, the links-section contains a list of players using embedded linux.

I've updated the player with the latest beta-driver (they had it on the website for a little while). It's great. It adds directory browsing to the system. Subtitle-support. Smoother avi-playing (think they've increased the use of buffer/cache). It can even play videos and music from the CF-card reader. (Very nice)

Linux runs on all these and more. When the going gets tough, the tough turn to Linux for embedded processors.

Seriously, sounds like it would make a great replacement for maintaining uClinux separately. iPod on linux, anyone?

Alternatives for DR-DOS (it is not Doctor-DOS; DR here once stood for Digital Research, the company who originally wrote that MS-DOS clone) are FreeDOS, Red Hat's eCos, or uCLinux to name just three. There are many others.

uClinux runs on systems without MMUs.

I only discovered this by running 'strings' on the firmware and found references to uClinux and a variety of other GPL stuff.

There is NO mention of the GPL in the product manual or on the packaging which contains the CD with a backup copy of the firmware.

I asked for copies of any GPL sources (and associated changes) which the MegaRAC G2 used - to their credit, I received a very nice diff which only covered changes to files which already exist in the uClinux distribution.

Unfortunately, those changes include the addition of header files which the modified kernel relies on - header files which I wasn't given and further requests for them have been ignored. So, even with the 'source' which I was given, I can't use it to produce an identical binary as to that contained in the firmware image which was supplied to me.

For those readers who are interested in purchasing one or more MegaRAC G2s, I suggest you ask your AMI dealer why it took them over eight weeks to patch a vulnerability which allowed *any* remote user to gain full access to the system console and also why the product is prone to frequent hangs which are not recoverable unless you unplug all power from the server and card until the onboard battery drains.

The vulnerability is so simple to exploit - start up the GTK+ remote console utility that came on the CD and point it to the IP address of any MegaRAC G2 card.... that's it. No prompt for a username or password. Nothing. Instant console access.

... then again, I suppose it just goes to show the quality of the code which their engineers are kicking out to the end-users :-(

Don't know if this is what you had in mind, but embedded *nix in general is getting big, so you might be interested in further devloping upon this project. Another valuable site is this one. If you've got some programming skills, contributing to these projects would be greatly appreciated I'm sure.

Check out Embedded Linux/Microcontoller project I've never tried it personally, but looks promissing. Don't know about support for the older platforms you're talking about though. Gives you somewhere to start though.

Some very usefull tools that I've used on newer Palm devices with net connectivity:
Top Gun SSH - Works pretty good for remote shell access.
PalmVNC - Decent VNC implementation for the Palm.

Not *nix on the Palm, but gives you good access to remote systems.

Not exactly, although this guy seems to have gotten a TCP/IP stack onto the same chip.

The MegaSquirt uses the Motorola MC68HC908GP32, which has only 512 bytes of RAM, so it's a bit tough to get much done (you try booting your linux system with "mem=512" sometime).

If you really want to run Linux on an embedded system, you might look into uClinux on a bigger processor.

There is possibility of an "independent" iPod update, which would add OGG support. This Wired article discusses a version of uClinux which runs Mad (a media player for Linux which is able to play OGG files).

Incidentally, I think understating the importance of open standards when it comes to something as ubiquitous as digital music, is a mistake.

In fact, even with non-POSIX APIs, if they had looked ahead a little and designed APIs that could have scaled up, Palm wouldn't have the problems they are having.

Note that there are small versions of the Linux kernel (here). They even run on the Dragonball Palms.

Also, if you like, you can still get 2.9BSD and even a PDP-11 emulator to run it on (here).

From the uClinux site

The Linux/Microcontroller project is a port of Linux to systems without a Memory Management Unit (MMU).

Pronounced "you-see-linux", the name uClinux comes from combining the greek letter "mu" and the english capital "C". "Mu" stands for "micro", and the "C" is for "controller". uClinux first ported to the Motorola MC68328: DragonBall Integrated Microprocessor The first target system to successfully boot is the 3Com PalmPilot using a TRG SuperPilot Board with a custom boot-loader created specifically for our Linux/PalmPilot port. It is currently maintained by co-creator D. Jeff Dionne.

It's not just that the simpler chips are more reliable, but they use less power, generate less heat, cost less and take up less space and don't weigh as much.

I have heard that the ARM chip is the most popular for embedded applications these days, and many of the ARM chips in use are quite tiny, have no cache and run in the 40 Mhz range, like the ARM7TDMI.

68000-based chips from Motorola are also very popular.

And check out uCLinux, a linux port to several microprocessors that run without a memory management unit.

Why bother with an MMU when there's no disk to swap to, and the failure of a user program would mean the failure of the whole system?

I've been thinking about getting started in embedded Linux, with the end goal of creating simple devices (little robots or whatever).

Searching Google for "embedded linux" and similar turns up alot of hits, but most are about as useful as searching for "c"

It seems like most of what I can find is either information about what devices (SBCs, etc) you can run one of the embedded linux distros on (for example, LinuxDevices mentioned in the article seems to focus on this) or assumes you're already an embedded Linux expert and can hack a kernel like Linus himself.

I've been thinking about buying something like uCsimm to play around with, but without being able to find any "getting started" type info, I'm concerned it would just be a waste of money.

So my question is, what are the good resources out there with introductory level coverage of embedded Linux such that some of us might eventually be able to use this fine toolkit? If anyone has any links I'd really appreciate some pointers.

You'll need to know the format of the binaries, calling conventions etc. but except from that, I think that you can use gcc.
The guys working with uClinux (the uClinux directory, uCdot and an Arm emulator) has a precompiled toolchain and lots of tips. Imagine glibc + gcc on a cell phone... Now I can play xbill on the train!

You'll need to know the format of the binaries, calling conventions etc. but except from that, I think that you can use gcc.
The guys working with uClinux (the uClinux directory, uCdot and an Arm emulator) has a precompiled toolchain and lots of tips. Imagine glibc + gcc on a cell phone... Now I can play xbill on the train!

I don't know if that turns it into capable of being used in practical applications - but I believe that if the bot was freely programmable (and controlled by for example CLinux) - you could enhance it's possibilities quite much.

Well, they have things smaller that can do much of the same.

Check out the uCsimm. Onboard ethernet, serial, etc. All you need is a 3.3v power supply and you are good to go!

Only limitation is 8MB of RAM and a Dragonball proc, but...

What, you mean like this?

It's not a StrongARM, it's an ARM7TDMI running at 16.78MHz. 256K RAM 240x160 LCD.

So it has more horsepower than a Palm, but still no memory manager or cache. This means it's restricted to MMU-free micro-ports of Linux like uClinux.

Like someone else posted.. not impossible, but probably not terribly satisfying as a target. Not to say it wouldn't be a satisfying, educational, or fun project, though. :)

PicoGUI's still in need of developers, authors, and artists. We need developers to write PicoGUI applications and help debug/extend/port pgserver. We need authors to write more documentation. We could even use some artists (preferably with some programming knowledge) to make some more themes. If you're interested in helping, join the pgui-devel mailing list or stop by the #picogui IRC channel on irc.openprojects.net.

Also, there is a bunch of Free and not-Free software available from the .org site.

Later, mr.

Also of interest to those building tiny apps is uClibc an embedded C library I've been putting pogether for the past year or so. It is working quite nicely these days, and since I use almost stock glibc 2.2.4 header files, porting apps is usually involved typing 'make'.

Erik
(the BusyBox guy)

If I was Jeff Dionne, the guy who actually ported Linux to run on Motorolla dragonball processors, I think I would be very pissed off to see these people claiming they are "The first Linux compatible O/S scaled down for the Motorola Dragonball CPU platform."

If I was Jeff Dionne, the guy who actually ported Linux to run on Motorolla dragonball processors, I think I would be very pissed off to see these people claiming they are "The first Linux compatible O/S scaled down for the Motorola Dragonball CPU platform."

Altogether, I'd stay away. If you want a nice, functional Linux PDA, take a look at the Agenda. HP also will be coming out with a real Linux PDA.

its based on the uCLinux project - its got 2MB flash, 8MB RAM, and its a Motorola Dragonball, all the same as the uC project.

So when is linux gonna run on PIC's and Atmel AVR's? :) It runs on D-balls, StrongArms, MIPS, I'm sure soon stable ports will exist for the PSX and the PS/2....the only thing really missing on teh embedded front at this point are development tools...that said, the GPASM and Atmel tools for Linux are quite nice.

Look here at their FAQ:
http://www.uclinux.org/pub/uClinux/FAQ.html#2-5

I can't figure out if Linux DA has the same or similiar problems though.

Does any one have the skinny on this?

What can Linux do on a Palm device that PalmOS already does admirably well?

Multitasking

Also multihreading

---

What can Linux do on a Palm device that PalmOS already does admirably well?

Multitasking

Also multihreading

---

Perhaps it's the first complete distro, or something, but I highly doubt they did all this by themselves. Remember ucLinux?

This hardware actually goes back to the Moreton Bay NETtel platform. Moreton Bay were the guys that ported Linux to the Coldfire (slashdot story) and were then acquired by Lineo. There are some pictures of Coldfire Linux based boards, including the original Moreton Bay NETtel.

The first target system to successfully boot is the 3Com PalmPilot using a TRG SuperPilot Board with a custom boot-loader created specifically for our Linux/PalmPilot port. It is currently maintained by co-creator D. Jeff Dionne.

If by "no paging hardware" you mean no MMU (memory management unit), that is not a show stopper. From uCLinux: The Linux/Microcontroller project is a port of Linux to systems without a Memory Management Unit (MMU).

Yes, the 2MB limit is pretty steep, but to say that this makes the PS1 w/ Linux worthless is pretty silly. I was able to get all manner of stuff done on my old Apple ][ with a paltry 64KB RAM (and on the //e with my bank-swappable 128KB, now that was something!) My first IBM clone had a whopping 1MB of RAM, and I hardly knew what to do with myself. The uCLinux guys have gotten the kernel down to a ~500KB working set, so this actually sounds pretty cool to me.

Yeah, yeah, I know you were trolling. Either that, or I'm just another nerd with too much time on my hands. :)

Invisible Agent

Well, there is always ELKS(Embedable Linux Kernal Subset) which runs on 8086, 8088 & 80286 (as well as some PDA called the Psion). While it's not a full-featured version of linux (hense the "subset" in the title) it does work on 16bit hardware.

You could always take a look at Minix...

Redhat's eCos is an embeded unixesque OS that runs on a number of 16/32/64bit architectures.

And, for another version of linux that runs on systems w/o MMUs, you can always take a look at uClinux(that u should be a mu, as in micro). It seems they've focused mostly on Motorola chips, but a few others (such as the i960) are supported as well.

I'm tired of doing your research for you, but I seem to remember something out QNX originally being targeted at embedded architectures, and being available on a some non-Intel patforms.

OMG, a quick check over at DMOZ.org's search engine on "embedded" gives me entire CATEGORIES dedicated about it, several of which involve Linux as well! Yahoo does too! How dare they make you -look- for information. I feel sorry for the engineer that's going to have to design the board, and look up the specs on EVERY component he puts on the board...

But don't really see what we gain by putting Linux in every toaster everywhere. Why should we fight for free software in embedded systems, where we never even get in touch with the code?

But you're wrong; We can get in touch with the code just about anywhere. If we're lucky, people will use the uCsimm, and the hacking possibilities will be endless. It really does seem like the quickest route to embedding linux in your product. Note: I am not affiliated with uClinux, or the people who make the uCsimm, but I this this is really neat.

Anyway, we've already been hacking boxes which run linux which we were Not Intended To Hack(tm). TiVo, anyone?

Of course, free software is philosophically more correct than propriatary software, even in embedded systems. But still, what does it give us in return? We can never change the software in our toasters or our stereos, so why should we go out and put Linux in there?

One day, every device will have a fairly complete operating system in it. Right now, you can get a uCsimm, a complete (somewhat slow) computer on a simm. It's a more powerful system than, say, a palmpilot, and in fact the PalmOS should be portable to it, not that I expect Palm/3Com to bother.

The uCsimm is driven by a Motorola DragonBall 68EZ328 processor, and comes well equiped with 2 MB of FLASH and 8Mb of DRAM. We have also included a 10Base-T ethernet and RS 232 high-speed serial. There is also a built-in LCD panel driver capable of displaying QVGA at a resolution of 320 x 240.

And a complete devkit is only $300. No memory protection in uClinux, but hey, life is hard. But one day, a dramatically more powerful system will come in a single-chip solution and cost significantly less. At that point, it's cheaper to put a pre-developed hardware solution into your system than to do a complete design, and your engineering cost drops to nearly nothing; You add a simm socket (or whatever) to your board, hook power up to it, and run input and/or output lines to the appropriate components. Anyone could implement it with a copy of orcad and a few days to learn how that software works; Just place a SIMM socket in your diagram, and start connecting traces and buses. It'll output a HPGL file which you can then send off to the people who will make your PCBs.

So, since every device will have an OS on it eventually, perhaps we should push for it to be something (easily) hackable, and something which we'd want to hack. Just a thought. Just remember, at some point in the future, even a basic "smart" toaster (right now there are toasters which are supposed to not overtoast your bread, and they're pretty cheap, but they suck) will want to detect bread temperature, turn banks of heating elements on and off in areas to ensure an even toast, and so on. It'll probably want to tie that in with some sort of fuzzy logic system so it knows what sort of heat patterns to toast your particular breads with. And eventually, it'll be cheap enough to drop in a predeveloped embedded system. Wouldn't you like it to be linux?

--
ALL YOUR KARMA ARE BELONG TO US

Though Linux isn't perfectly suited to handhelds, it isn't bad. The reason these things are slow is because they run X. Though it "isn't ready for prime time" yet, I and a couple others have been working on creating a usable PDA system. It will work on nearly any CPU, but the focus is on the 68EZ328. Yep, the same one in Palm computers.

The OS is uClinux, and the user interface is a project I've been working on since last March, PicoGUI. The video drivers still need lots of work, but for the most part uClinux and PicoGUI gives good results even on a little 16mhz CPU. This will allow better battery life no matter what CPU used. Smartdata has been working on a handheld computer using PicoGUI, and I have a piece of hardware or two that will run it.

I'm really don't think there's any value inherent in a Linux PDA.

Before I get flamed mercilessly, let me explain...

I started with the original Newton. then moved to Palm when the Pro came out. Then came the Palm V. After that, I got a Psion V w/ Epoc 32. Then I managed to get my hands on a prototype Newton tablet that Apple never released. Then, when I realized that wouldn't do what I needed, I built my own Linux-based PDA using the ucLinux SIMM hardware project and an LCD panel. Then I moved onto the iPaq

After going through all of these handheld devices, I still haven't found one that can be hacked to the functionality I desire, which is essentially a wide-area wireless browsing device. For all its virtues, Linux (at present) doesn't provide much beyond its coolness factor in the handheld arena. Functionally the Palm or the iPaq with their native operating systems are FAR more useful to the end user population.

When a decent UI (read: simple yet complete) UI and a stable business application suite are made available under Linux on a PDA, then they'll do better than they have. Palm compatibility for data transfer will be essential, as will battery life.

Until that time Linux on a PDA (IMO) will remain a mere curiosity for geeks to stare at (I personally am now over my staring phase... :) ).

-drin

Anyone know how many companies are working on a Linux chip?

The uCsimm is a SIMM form factor board with 2MB flash, 8MB DRAM, 10baseT ethernet and RS-232, as well as an LCD panel driver which will do "QVGA at a resolution of 320 x 240" or mono 640 by something or other.

This is a complete hardware solution for developing embedded solutions with linux. The system is fairly speedy, but unfortunately has no memory protection, so programs can step on each other freely, if you're not careful.

--
ALL YOUR KARMA ARE BELONG TO US

It'd sure be cool to make a low-cost board that could run the real linux, with real memory management (MMU), and a pretty speedy CPU. By low cost, I'm thinking able to sell at $120-$150 for board where you add a SDRAM DIMM and use a network bootstrap or add compact flash card for a local boot. So far, it's looking like the available PPC based off-the-shelf boards are quite expensive. I probably ought to do a bit more homework, but since you're here, my question is....

What are the propects for making a really low cost PPC-based embedded linux computer? Has anyone done it or tried? Is it even possible?

Actually, the 68000-series CPUs on which the Amiga was based are mostly 32-bit. The original 68000 CPU was not fully 32-bit, but the 68020 and up were. Linux requires a 68020 or higher with an MMU.

Yeah, the 68000 and 68010 were 16 bit CPUs with 24 bits of address space. The 68020 and up are 32 bits. I don't remember if the 68060 made it to 64 bit, but I don't think so, I think it was just 32 bit with 48 bit addressing or something wonky like that. You could get a 60MHz '060, though, not too shabby, especially when AmigaDOS runs suitably on a 7.14MHz 68000.

Anyway, the point of this message:

After seeing the uClinux homepage, I decided to try to apply the patches these guys made to the standard m68k subtree. This way, I thought, it'd be possible to boot a Linux kernel on old 68000 machines which have no MMU. And I was right. So if you have an old Atari ST, Amiga or Mac, you might want to look at these patches, or even help a hand...
(From http://www.esat.kuleuven.ac.be/~pcoene/atari.html)

And

What is uClinux?
uClinux is a derivative of Linux 2.0 kernel intended for microcontrollers without Memory Management Units (MMUs). (From http://www.uclinux.org/description/)

So far, uClinux runs on the Palm Pilot and on the uCsimm. Paul Coene's setup will boot on Atari ST (another 68000-based box, much like an amiga without all the cool custom chips) and in the STonX Atari ST emulator.

Actually, the 68000-series CPUs on which the Amiga was based are mostly 32-bit. The original 68000 CPU was not fully 32-bit, but the 68020 and up were. Linux requires a 68020 or higher with an MMU.

Yeah, the 68000 and 68010 were 16 bit CPUs with 24 bits of address space. The 68020 and up are 32 bits. I don't remember if the 68060 made it to 64 bit, but I don't think so, I think it was just 32 bit with 48 bit addressing or something wonky like that. You could get a 60MHz '060, though, not too shabby, especially when AmigaDOS runs suitably on a 7.14MHz 68000.

Anyway, the point of this message:

After seeing the uClinux homepage, I decided to try to apply the patches these guys made to the standard m68k subtree. This way, I thought, it'd be possible to boot a Linux kernel on old 68000 machines which have no MMU. And I was right. So if you have an old Atari ST, Amiga or Mac, you might want to look at these patches, or even help a hand...
(From http://www.esat.kuleuven.ac.be/~pcoene/atari.html)

And

What is uClinux?
uClinux is a derivative of Linux 2.0 kernel intended for microcontrollers without Memory Management Units (MMUs). (From http://www.uclinux.org/description/)

So far, uClinux runs on the Palm Pilot and on the uCsimm. Paul Coene's setup will boot on Atari ST (another 68000-based box, much like an amiga without all the cool custom chips) and in the STonX Atari ST emulator.

The uClinux source lives on http://cvs.uclinux.org... Of course Red Hat won't tell you that, since Lineo runs uclinux.org and employs nearly all the uClinux developers.

I have done a lot of work on rebuilding uClibc (the Clinux C library) the last 6 months or so to make it cross platform. Have I received even 1 stinking patch from our friends at Red Hat? I think not.

Joe deBlaquiere at Red Hat (who posts frequently on the mailing list and recently put together a nice howto on porting uClinux) is the only redhat person I have ever seen on the mailing list. Does writing a howto make it Red Hat's? I think not.

I have done a lot of work on rebuilding uClibc (the Clinux C library) the last 6 months or so to make it cross platform. Have I received even 1 stinking patch from our friends at Red Hat? I think not.

Joe deBlaquiere at Red Hat (who posts frequently on the mailing list and recently put together a nice howto on porting uClinux) is the only redhat person I have ever seen on the mailing list. Does writing a howto make it Red Hat's? I think not.

Any idea what the minimal size of eCos is when it has Posix 1003.1 support, a fully functional TCP/IP stack, ethernet driver, RAM disk? I've been using uClinux for a while, and it weighs in at around 500-600 Kb (including all buffers), but that's a fully functional Linux system with inetd, telnetd, a shell, a couple of mounted NFS shares etc. I like it a lot but if I can get one that's smaller, I'd like that better :-)

How do they license Linux for use in the embedded devices. Aside from the obvious alternatives (pocketlinux,ucLinux) why would a manufacturer rely on Red Hat to provide something that is already in existence, in which Red Hat really has no claims to 'license' a kernel that they don't own. As far as the distribution goes, if they are licensing it to commercial vendors for embedded systems is there any packages for the at-home hackers on this system?

I think that Red Hat does have a sound product, the company does seem somewhat strange. I still do not understand their primary source of long term revenue, perhaps I never will.

The stock had been way overvalued, he said, thanks to overly enthusiastic investors who "believed Red Hat was going to overtake Microsoft. They don't believe that now." Thankfully he at least said that. Best part of the article summed up right there.

Palm Pilot + GPS = most of what you want.

And uClinux runs on unmodified Palm hardware. The screen isn't colour and isn't QVGA but the processor in the Palm can do mono QVGA. Almost there. :-) I'm not 100% certain if uClinux will work with the processor in the IIIc or not; I think it will.

So depending on what you're trying to do you might be able to get away with a Palm or a Palm running uClinux (if you needed the Linux part). As far as x86 rugged hardware -- you could look to industrial electronics providers for that kind of thing. I know you can buy NEMA 4 laptops (they're expensive as hell but completely outdoor rated). If you don't need to go quite that far there is everything inbetween.

"It's also really efficiently written, and almost completely modular (as opposed to Linux' monolithic-plus-kitchen-sink approach)."

I don't suppose you've ever used Linux, since lsmod, rmmod, insmod, depmod, modprobe are all parts of the wonderful world of mapping things dynamically into kernele space. With it, I can have hot plug PCMCIA, USB, and other devices without having to have this monolitihic kernel you decry. There's even a Microkernel Linux which adds the features that the HURD and QNX have, that Linux doesn't.

QNX is targetted at embedded devices. That tight focus lets it get away with not having support for 64gb of ram, scaling to 8-way SMP, NUMA, swap space, implementation of device drivers for PC and non-PC hardware of all kinds, and other requirements of being a kernel that can be embedded in devices lacking a memory controller, to massive SMP systems, to computing clusters.

"QNX is much more suitable for PDAs and otehr small systems than is Linux."
Ever heard the phrase "jack of all trades, master of none?" Linux is the swiss-army knife kernel. It may not be as good for skinning as a proper hunting knife, but it also has a saw, a can opener, a magnifying glass, and many other useful tools that you might need some day. Think about it.

--

That's true. No multitasking, only various hacks (as dos had).
But no one says you have to run palmos on it.
ucLinux!