From iznogoud at nobelware.com Fri Jul 27 11:55:01 2018 From: iznogoud at nobelware.com (Iznogoud) Date: Fri, 27 Jul 2018 16:55:01 +0000 Subject: [tclug-list] Ideas/info on composing an embedded system's OS Message-ID: <20180727165501.GA25775@nobelware.com> What I am looking for is as specific and detailed information as possible on how to go about building a functional Linux OS derived from an existing distribution that will run on an embedded system (say an ARM product). Lots of related info is here: https://elinux.org/ https://elinux.org/Boot_Time I am interested in the high-level ideas nad philosophy of booting embedded systems, and on the details that follow. The web is cluttered, so I figured I'd ask here. Thanks. From andrew at lunn.ch Fri Jul 27 12:30:49 2018 From: andrew at lunn.ch (Andrew Lunn) Date: Fri, 27 Jul 2018 19:30:49 +0200 Subject: [tclug-list] Ideas/info on composing an embedded system's OS In-Reply-To: <20180727165501.GA25775@nobelware.com> References: <20180727165501.GA25775@nobelware.com> Message-ID: <20180727173049.GQ10686@lunn.ch> On Fri, Jul 27, 2018 at 04:55:01PM +0000, Iznogoud wrote: > What I am looking for is as specific and detailed information as possible on > how to go about building a functional Linux OS derived from an existing > distribution that will run on an embedded system (say an ARM product). Embedded covers a wide range of systems. Are we talking about a NAS box with lots of storage, a WIFI access point, the center console of your auto, a drone? In generally, i just run Debian on everything, making use of the bootloader which is already there, and if needed, adding extra storage via a USB stick or SD card. Andrew From iznogoud at nobelware.com Fri Jul 27 14:21:50 2018 From: iznogoud at nobelware.com (Iznogoud) Date: Fri, 27 Jul 2018 19:21:50 +0000 Subject: [tclug-list] Ideas/info on composing an embedded system's OS In-Reply-To: <20180727173049.GQ10686@lunn.ch> References: <20180727165501.GA25775@nobelware.com> <20180727173049.GQ10686@lunn.ch> Message-ID: <20180727192150.GA31003@nobelware.com> > > Embedded covers a wide range of systems. Are we talking about a NAS > box with lots of storage, a WIFI access point, the center console of > your auto, a drone? > That is an excellent follow-up question, which I should have addressed and clarified. I am looking more like the console of the auto. An example would be making a pinball machine, or generally something that does not really require to store long term data, would be expected to shutoff abruptly (main issue with keeping data integrity), and have quick boot-up times. > In generally, i just run Debian on everything, making use of the > bootloader which is already there, and if needed, adding extra storage > via a USB stick or SD card. > Everything needs a bootloader of sorts. I am more interested in additional architectural design of a robust embedded system. An example will help. This is Intel's "Euclid" depth-camera device: https://robots.ros.org/intel-euclid/ Runs some Ubuntu flavour of Linux. I played with this hardware recently. It boots Ubuntu, starts X, which it displayes through HDMi, and becomes an access point, through which one can access the main functionality of the device (the depth-sensing camera). The system has a single button to turn it on, and one would never know it runs a full-blown OS behind it if they did not care. I want to build my own embedded Linux-based OS out a different distro. I know one can use Buildroot, etc, but I would like some ideas on architecting such a solution rather than picking one. From andrew at lunn.ch Fri Jul 27 15:11:24 2018 From: andrew at lunn.ch (Andrew Lunn) Date: Fri, 27 Jul 2018 22:11:24 +0200 Subject: [tclug-list] Ideas/info on composing an embedded system's OS In-Reply-To: <20180727192150.GA31003@nobelware.com> References: <20180727165501.GA25775@nobelware.com> <20180727173049.GQ10686@lunn.ch> <20180727192150.GA31003@nobelware.com> Message-ID: <20180727201124.GA17441@lunn.ch> > I want to build my own embedded Linux-based OS out a different distro. I know > one can use Buildroot, etc, but I would like some ideas on architecting such > a solution rather than picking one. So a good start is having the requirements and available system resources. I mainly use debian because i'm a kernel developer, and it gives me all the tools i need for development on ARM based system. I normally cross compile the kernel on a big x86 box, but debian gives me the base system on the target, i can apt-get any special tools i need, and if i need to do some user space development, a toolchain can quickly be installed and used, although building anything serious on the target is slow. For your user case, how much flexibility do you need? Often embedded systems have one purpose, so you don't need the flexibility Debian gives you. buildroot will give you something much more tailored to your specific use case. Same is true for yocto, etc. Is security an issue? Embedded systems are often shipped and forgotten about. But if you want to keep it secure, you are going to have to rebuild it every few weeks/months. So you need a distribution with security updates, and a method you can either update individual packages, or rebuild the whole image and install it. You say pinball like machine. I'm assuming you mean on screen display, rather than controlling solenoids, having switch inputs for paddles, etc? What graphics toolkit do you want to use? QT is often used in embedded systems, but there are other choices, and ideally you want a distro which has what you want. Does the ARM platform you have chosen need binary blobs to make some of it work? Does it have an open source GPU driver? It can be hard getting vendor binary drivers working on anything other than what the vendor supports. So you might want to see what the ARM SoC vendor supports in terms of distributions. Andrew From iznogoud at nobelware.com Fri Jul 27 15:39:50 2018 From: iznogoud at nobelware.com (Iznogoud) Date: Fri, 27 Jul 2018 20:39:50 +0000 Subject: [tclug-list] Ideas/info on composing an embedded system's OS In-Reply-To: <20180727201124.GA17441@lunn.ch> References: <20180727165501.GA25775@nobelware.com> <20180727173049.GQ10686@lunn.ch> <20180727192150.GA31003@nobelware.com> <20180727201124.GA17441@lunn.ch> Message-ID: <20180727203950.GA1268@nobelware.com> You hit the nail on the head with your questions. Without quoting, I will just provide info. I looked at Buildroot and yocto, and those are, as you said, for single-use purposes. I want something more flexible and generic, so that multiple things (functionality) can be built using one basic configuration. More below. Security is not an issue at the prototype level, but if I move on with what I want to make, it can be a component of it. I am only seeing updates as being possible by putting the device into a particular mode, preferably when it is "tethered" to a general purpose computer to push updates in it. This is like flashing a firmware with updates, so I am not worried that it cannot be done and generalized in the future and while in production. The pinball example is simple, but think of my Intel Euclid functionality. I want to be able to drive different hardware components from the device, and this will likely be with a processor that can handle the computations. (Euclid gets pretty hot and goes through some serious power for what it does, for example.) Some of what I have in mind requires this and some not. Simple sensors will likely run on ARM, but more serious processing will have to be done on x86. In that regard, I need a unified distro and toolchain around my process, but all based on a generic "embedded distro" that is customized and customizable by me. This just about sets 50% of the requirements, and the most basic ones at that. You nailed it with the GPU question. Think of real-time 3D graphics processing on board, while networked, etc. Choices of GPU hardware are limited, but they are there to purchase for mobile systems (laptop-like). "Embedding" drivers on a custom distro may be my biggest problem. Andrew, you are my man for this brainstorming; you are asking all the right questions. Happy to see this level of expertise locally. From andrew at lunn.ch Fri Jul 27 15:48:26 2018 From: andrew at lunn.ch (Andrew Lunn) Date: Fri, 27 Jul 2018 22:48:26 +0200 Subject: [tclug-list] Ideas/info on composing an embedded system's OS In-Reply-To: <20180727203950.GA1268@nobelware.com> References: <20180727165501.GA25775@nobelware.com> <20180727173049.GQ10686@lunn.ch> <20180727192150.GA31003@nobelware.com> <20180727201124.GA17441@lunn.ch> <20180727203950.GA1268@nobelware.com> Message-ID: <20180727204826.GA19398@lunn.ch> > You nailed it with the GPU question. Think of real-time 3D graphics processing > on board, while networked, etc. Choices of GPU hardware are limited, but they > are there to purchase for mobile systems (laptop-like). "Embedding" drivers on > a custom distro may be my biggest problem. You might want to look at imx7 and depending on your time scale, imx8. imx7 recently got mainline support for the GPU. It is often used in automotive applications, and in-flight entertainment systems. Mainline kernel support for it is good, so you can avoid all the problems of a vendor kernel. Andrew From eng at pinenet.com Fri Jul 27 15:54:04 2018 From: eng at pinenet.com (Rick Engebretson) Date: Fri, 27 Jul 2018 15:54:04 -0500 Subject: [tclug-list] Ideas/info on composing an embedded system's OS In-Reply-To: <20180727165501.GA25775@nobelware.com> References: <20180727165501.GA25775@nobelware.com> Message-ID: I'm not sure Jim Hall is still in Minnesota, but he says his FreeDos will run on DOS emulators for Linux, in virtual windows. They are working on FreeDos 1.3 right now and warn it might be a little different than old MSDOS. Version 1.2 is lots of fun learning how an embedded system might be modeled even today. The IBM PC was a design masterpiece. There is also just such an embedded Linux working group referred to by Intel when I looked into the Intel Edison embedded systems. But IIRC Edison is now kaput, too. I wouldn't dare advise you. This is certainly front lines high priority technology. Best of luck. Iznogoud wrote: > What I am looking for is as specific and detailed information as possible on > how to go about building a functional Linux OS derived from an existing > distribution that will run on an embedded system (say an ARM product). > > Lots of related info is here: > https://elinux.org/ > https://elinux.org/Boot_Time > > I am interested in the high-level ideas nad philosophy of booting embedded > systems, and on the details that follow. > > The web is cluttered, so I figured I'd ask here. Thanks. > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > From iznogoud at nobelware.com Sat Jul 28 09:55:27 2018 From: iznogoud at nobelware.com (Iznogoud) Date: Sat, 28 Jul 2018 14:55:27 +0000 Subject: [tclug-list] Ideas/info on composing an embedded system's OS In-Reply-To: References: <20180727165501.GA25775@nobelware.com> Message-ID: <20180728145527.GA8689@nobelware.com> ALl ideas welcome. We can dismiss MSDOS anything right away... That is so early 90s, and other than retro-gaming, it is dead. Good back then when geeks made things happen with non-protected mode multitasking and little memory. Andrew's suggestions are spot on. My preliminary plan was to pick a distro that has an ARM clone that is almost identical to its x86 distro. Then, work out the booting and system configuration on the x86 with VMs. Then do the same on the ARM side. Final toolchaining can be left to somebody smarter than me. I need to think more and ahrd about this now. I need to put some time into it. All additional info most welcome. From eng at pinenet.com Sat Jul 28 10:49:40 2018 From: eng at pinenet.com (Rick Engebretson) Date: Sat, 28 Jul 2018 10:49:40 -0500 Subject: [tclug-list] Ideas/info on composing an embedded system's OS In-Reply-To: <20180728145527.GA8689@nobelware.com> References: <20180727165501.GA25775@nobelware.com> <20180728145527.GA8689@nobelware.com> Message-ID: <8b1d01c7-b4c9-005a-7985-2aad11f8aa54@pinenet.com> Not to question your goals, but much of DOS was simply accessing PC BIOS saved in non-volatile ROM. Yes, the BIOS was copied to RAM at boot. Maybe lots of RAM and storage is OK, but many embedded systems like ROM. Iznogoud wrote: > ALl ideas welcome. We can dismiss MSDOS anything right away... That is so early > 90s, and other than retro-gaming, it is dead. Good back then when geeks made things > happen with non-protected mode multitasking and little memory. > > Andrew's suggestions are spot on. > > My preliminary plan was to pick a distro that has an ARM clone that is almost > identical to its x86 distro. Then, work out the booting and system configuration > on the x86 with VMs. Then do the same on the ARM side. Final toolchaining can be > left to somebody smarter than me. > > I need to think more and ahrd about this now. I need to put some time into it. All > additional info most welcome. > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list >