I know the potential of Embedded Linux. I am a VHDL designer and have seen people using Petalinux with Xilinx FPGA.

I always had some questions regarding Embedded Linux. But first, let me tell you what I know about it.

Yocto was made into Petalinux by Xilinx. It runs on Zynq(I don't know whether on APU or RPU). I know yocto also works on Beagle board hardware.

Now my questions are:

1) How many other types of Embedded Linux are there? Like yocto, petalinux, etc?

2) Which platforms( chips ) they can run on? Chip name, company name, etc.

3) How many of them are free, which means no license for use is needed?

4) Do Embedded Linux works on RPU, APU, or Microcontrollers?

5) Can I run Embedded Linux on softcore processors like NiosII, Zynq, Microblaze, etc? I am asking this because many FPGAs don't have any block processors on them.

Just share whatever knowledge you have. I want to learn it because maybe it's time to switch my professional field.

Linux is Linux, all those different names are more about the build system than the kernel and the user code. You want to run some application code on your gizmo. If you run embedded Linux, you get a huge amount of code already written for you, like file systems (if you have mass storage), USB, Ethernet, zillions of protocols (from networking to I2C) and libraries to do all sorts of things. Thus, your application development shrinks to developing your application specific code, everything else is there already.

To run embedded Linux, you need a bootloader, the Linux kernel and a bunch of libraries and utility programs that are needed for a unix system. Then you need to write the device drivers for your specific devices (you design your FPGA/ASIC to do something special, so from Linux's perspective that is a piece of hardware that it needs to drive).

You need to compile all that for your specific processor. To do that you need a cross-compiler that runs on your PC but generates code for the target CPU in your gizmo. In theory that should be enough, but life is harder, because the compiler, the Linux kernel and the standard C library on which pretty much everything depends are intertwined. So you need a compiler/kernel/library triplet, which then can be used to compile and build everything that will run on the target chip.

That is where the different embedded Linux systems come into scope. They mostly differ on how they build the above triplet and what build system they use to build the actual image that will go into your gizmo; what other libraries and programs they build and install on the target and, for some, how you can update things on your gizmo when it is already on the field (package management).

Now to answer your specific questions:

1) Lots. They all use the same compiler (gcc), the same kernel (Linux), the same (set of) C libraries. Which one you choose is mostly dependent on what your device is expected to do. If you build the Raspberry-Pi, you expect the user to write their own stuff to run on your device; after all, that's the whole point of R-Pi. If you want to build a network router, then the user does not need to be able to install stuff on or write code for the target. So you choose the one that suits your device, your resources (e.g. BuildRoot is targeted for limited systems and builds only what you really need to be there, while Yocto can build a PC equivalent system if your hardware has the resources, including compiler running on the target and the like).

2) Well, gcc can compile for zillions of cores so in theory you can build an embedded Linux for any of them, if they are able to run it. Obviously not for an 8-bit micro, but a 32-bit processor with an MMU should be ok (in fact you can build an MMU-less version of Linux as well, but that's a different topic). But again, theory and practice: building the above mentioned triplet for a new CPU from scratch is a *huge* amount of work, so build systems tend to support cores that are in common use. BuuildRoot, for example, supports ARC, ARM, ARM 64 bit, Intel x86 (all 32/64 bit variants), MIPS, MIPS64, m68k, OpenRisc, SPARC, PPC, RISCV and a bunch of others, including Microblaze (Xilinx's soft-core CPU).

3) All of them are free. The components are licenced under various terms and it would be too long to go into the details. What is important is that you can build and sell an embedded Linux gizmo where the hardware, the ASIC/FPGA and your own application code are all closed source. All you have to provide is a statement to your customer acknowledging the embedded Linux system components that you used and provide a way to the customer to get access to the source code of those components (e.g. a link to the build system's website). If you *modify* the kernel or the component libraries, then you need to publish those modifications (usually, though not all components require even that) but your own code and HW design is all your own. Chances are, your scope, router, set-top box and a bunch of other gizmos around you all run embedded Linux, all strictly clean legally and not a cent of license fees were paid for the open source stuff.

4) Those are very broad terms. Application processor, well, if you think along the lines of ARM Cortex-Axx chips, definitely. Real-time processor is a question because those usually don't have an MMU. You can build an MMU-less version of Linux, basically all processes running in the shared memory (like the Amiga did many years ago) but then you need to be very careful because then any bug in any program can crash the entire system (like on the Amiga, many years ago :-) If you have at least a memory protection unit (that most ARM RPUs do), then you can alleviate that problem. Microprocessor is very broad term, the 6502 is one and so is the 68040, as is the processor in your PC you can easy run Linux on the latter two and obviously not on the old 8-bitter.

5) Yes. BuildRoot, for example, supports Nios-II and Microblaze, as well as SPARC which is open-sourced, as are RISCV and OpenRISC, also supported.

Hope the above helps,

Zoltan

Thank you very much for the detailed reply.

What is the best way to start with embedded Linux based development, where ultimate goal will be to use Linux to handle various embedded systems related tasks?

I know VHDL, VERILOG, SYSTEMVERILOG, I know FPGAs, and porting Linux on devices will be my next step(I guess I need to learn to develop device drivers?). I don't have much experience in processors and Microcontrollers, but I am ready to learn.

The question is, how much SW background you have, and how familiar you are with Linux. If by not having much experience with processors and micros you mean you haven't much programing experience, then I think you should consider starting with something simpler.

Embedded Linux on completely custom hardware (which I assume you plan to have as you were asking about a soft-core CPU on an FPGA) is a very steep learning curve even for someone who is at home with programming bare-metal devices or using some (relatively) simple real-time kernel. No matter what embedded Linux build system you choose, you won't find a predefined configuration for your system. So you will need to create everything on your own. 

First, you will need to configure the build system. Then you configure the bootloader and write some code for it, to cater for your hardware's peculiarities. Then you'll need to configure the kernel and write pretty much all the hardware level device drivers for it. Now that is definitely not an easy task. On a bare-metal system an interrupt handler is fairly easy to write: you somehow set up the vector for your function, your function quickly serves the hardware, possibly does some work that is not worth moving to an upper level, sends some notification to the rest of the system and returns. It's more complex on Linux because everything is abstract, there are controllers, HW IRQ IDs, virtual IRQ IDs, softirq-s, tasklets and so on. Those are all concepts that you'll need to learn and, alas, there is precious little literature available to guide you. The Linux kernel is fairly fluid and a 10-year old book on device driver development is almost certainly close to useless. There is documentation that comes with the kernel sources, but that is aimed at seasoned programmers who are generally familiar with the internal concepts of the kernel.

You also need to be comfortable with working under Linux itself, as you certainly will need to use it for your development work. If you do your chip development under unix, then that's not much of an issue, but if you work with Windows, then switching to the command-line heavy unix environment will be a challenge (but possibly a real eye-opener at the same time).

Again, I don't know how much programming experience you have. But for Linux device drivers knowing C inside out is a must, including some of its more subtle points and darker corners (where the dreaded "undefined behaviour" lurks), which can bite you in the bum big time. If you are a chip designer, you probably are familiar with (Tcl) scripting and also have  used C for Verilog's PLI  and SystemVerilog's DPI, but the Linux kernel is definitely a step up and not a small one either.

So it's really up to you, but I would start with writing code for a bare-metal system first and when you are comfortable with that, you can start to dive into embedded Linux. With bare-metal you control everything, you can debug your code much easier (as soon as you can toggle GPIO pins, you can even debug with a scope or logic analyser), so in general your life is much, much simpler. Plus you need to bring your board up anyway, so it's not even wasted effort.

Alternatively or additionally to the bare metal stuff, you can buy a Raspberry Pi and start hacking that. It is dirt cheap, well documented, pretty powerful and you can use it to hone your device driver writing skills before jumping onto completely custom hardware where you must start building everything from the ground up.

Cheers,

Zoltan

Thank you again. I got your point. I am very thankful to you for your sincere suggestions and insights.

I use a lot of embedded Linux in my controllers and devices.

I played with Yocto when Intel released the Edison - but the support for that board, and the lack of interest from the manufacturer left a bad taste in y mouth re: Yocto.

For that reason I now almost exclusively use OpenWRT - despite originally being a way to open up Routers, it;s now a very good linux platform that runs on a very wide gamut of hardware. It's build system is excellent once you get to know it, and easily configures the build for your chosen hardware and software needs.