So I am planning to do a learning project of installing embedded linux into to SoC. One from smartphone vendor Spreadtrum SC7731 and the other from generic smart devices vendor Ingenic JZ4725B. Since both SoC have different blocks (GPU, IPU, MMU ..etc). My question is, does the vendor of SoC provide any resources to allow interconnection between each blocks that can be used with generic linux kernel or the vendor provides system specific linux kernel which can be used directly?

P.S I am newbe so i dont have right wording for proper search for the answer I am looking for so will appreciate any help I can get here.


What you're looking for is multiple things:

  • some documentation that even allows you to figure out how to load a bootloader
  • said bootloader (e.g. uboot), able to fetch a Linux kernel from some storage device, which requires drivers for said storage device
  • a toolchain that can compile a kernel (and likely userland software) for the target platform
    • that primarily means that your device vendor needs to tell you which CPU architecture they use, potentially how much memory they have where etc, if that's not detectable on your platform
  • kernel drivers for all the in- and off-SoC peripherals
  • a way of building a filesystem image to put onto the storage there (e.g. Yocto/bitbake)

You'll often find that especially low-cost SoC vendors don't maintain upstreamable drivers, but resort to keeping an old (or at least, not new) kernel around that they patched until it works with their hardware.

That means you'll often be stuck with figuring out what they changed relative to the upstream kernel, and port that to the current kernel :(

Alternatively, you can use the kernel they provide, but as said, that's often an unsatisfyingly old, or patched-until-it-barely-works kernel.

I'd generally recommend starting to work with SoCs where the vendor has taken the workload of writing Linux-Mainline-quality kernels and upstreaming them from your shoulders. You might simply want to start using a Beaglebone!

  • \$\begingroup\$ This is great insight! So the SoC vendors write patches to upstream kernel for their hardware abstraction? And its the job of the toolchain to compile a custom linux kernel for the target SoC? So me as a develop have to simply define the hardware (SoC) in the toolchain so it can compile a dedicated linux kernel? \$\endgroup\$ – GENIVI-LEARNER Nov 1 '19 at 22:16
  • \$\begingroup\$ sorry, no, you've misunderstood: They don't keep with upstream kernels! (at least, not their majority) Instead, you get their vendor kernel (which is usually not a good deal). \$\endgroup\$ – Marcus Müller Nov 1 '19 at 22:28
  • \$\begingroup\$ The job of the toolchain is to provide you with the tools (e.g. a compiler) to build the kernel. You, as developer, need to configure the kernel build configuration appropriately to the SoC hardware, pick the appropriate toolchain to build, and then build the kernel and everything else. \$\endgroup\$ – Marcus Müller Nov 1 '19 at 22:29
  • \$\begingroup\$ I would prefer using low-cost patched-until-it-barely-works kernel to get first hand experience of problems in embedded world hence I didnt go with famous raspberry pi or Beaglebone. I am simply using a Chinese android smartphone which uses Spreadtrum SC7731 and trying to hack my way in, to see if I can install clean embedded linux into it. I do have to worry about the drivers though so I will also have to explore if the ROMs provided by the smartphone vendors can be hacked into to obtain drivers. \$\endgroup\$ – GENIVI-LEARNER Nov 1 '19 at 22:41
  • 1
    \$\begingroup\$ the raspberry pis are, imho, terrible devices hardware-wise, and also, the beaglebone is kind of the standard reference board for things like openembedded/yocto. It's better documented how to work with all the hardware than the Pis. \$\endgroup\$ – Marcus Müller Feb 11 '20 at 9:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.