OSDev.org

I've been doing OSDev as a hobby for some time now but I always wanted to create something that could boot on a hypothetical smartphone with a msm8916 Armv7 processor.
How would one create something that could boot and if possible send data thru the headphone jack at the least. If that's possible with a moderate amount of work, how would one implement more features to this OS?
What would be the best aproach? (Using android blobs maybe?). And can one create a basic screen driver to complete the barebones on this hypothetical device? Should first start experimenting with the raspberry pi 3 b+ and then port the OS to the smartphone?
I have been trying to find some resources about this topic and I havent been really sucessful in finding them (other than the raspberry pi tutorials ofc)
What resources would you suggest for me to look into or does a tutorial that I can follow already exists?

Thanks for the answers

Some SoCs are quite well documented, they're just a bit rare. The good ones are better-documented than any of the RPi SoCs.

Targeting the RPi and then trying to port this over to a new device would really only take care of the ARM part of the equation, and that's assuming that the RPi and your target device have a processor that shares a memory map and initialisation code. If you want a good introduction to bare-metal ARM development the RPi might not be the best place to start. As has been already noted, it's notorious for bad documentation. If you wanted another option, maybe look at some TI or STM32 boards, I've learned a lot working with them.

How would one create something that could boot...

Every device will have a different approach to bootstrapping a kernel. Some, like the STM32 devices that I'm most familiar with will load a kernel executable directly from flash memory. Some might be able to boot directly from an SD card like the RPi models. For all devices, the process is essentially compiling a kernel locally, encoding it in a format the device will recognise, and then copying that to a place that the device's inbuilt bootloader will load it from.
Typically, evaluation or development boards will be easily connected to your PC via USB. Other more complex devices might need a JTAG or other hardware interface to flash the memory.

...and if possible send data thru the headphone jack at the least. If that's possible with a moderate amount of work, how would one implement more features to this OS?

What you're talking about now is writing device drivers. You'd implement these features the same way that you'd write a VGA driver in the bare-bones tutorials. Each board will have a different set of hardware attached, such as different audio hardware, a different screen, etc. Most importantly for a smartphone, they'll all have different modems to communicate with the world.

What would be the best aproach? (Using android blobs maybe?). And can one create a basic screen driver to complete the barebones on this hypothetical device? Should first start experimenting with the raspberry pi 3 b+ and then port the OS to the smartphone?

If you're trying to learn bare-metal embedded systems development from the ground up, a great place to start is to pick one of the development boards from TI or STM32. A Cortex-M board is a good place to start if you're looking for a good introduction to ARM. Before worrying about an operating system per-se, there's lots of different aspects of embedded systems to become familiar with before you start worrying about multitasking, ui and other other things that really make an OS an OS.
Once you've picked a board ( also known as an SoC = System on Chip ), you can begin to write drivers that target the embedded hardware. It's easy to find boards, such as the STM32 Discovery boards that come with a screen already attached. This is good because you can start without needing to do any soldering ( even though that's a good topic to learn too ). Once you've got the system booting up, start by writing a display driver for integral display to blit things to the screen.

This is a very broad topic and question, but that's a good way to start.

I remembered something regarding binary blobs: a smartphone's modems may well require them. Hopefully, you could get them from the chip(set) manufacturers. I guess it's always possible to pull them from Android, but I'm not sure of the legality of it. The copyright owners might not care about individual users and developers, but if a business wants to use your product, (remotely possible,) they will care.

ajxs' post reminds me I was thinking of getting a SBC with a screen to use as a tablet, albeit a rather thick one. I'm too busy to really think about that, though.

It's a shame the old Linux Mobile forums are no longer up. They'd be perfect for finding the hardware for this, but they got replaced by a glitzy ad-heavy site years ago. I wonder where to ask about it now?

eekee wrote: It's a shame the old Linux Mobile forums are no longer up. They'd be perfect for finding the hardware for this, but they got replaced by a glitzy ad-heavy site years ago. I wonder where to ask about it now?

I just remembered that the Purism Librem 5 is a thing. It's the only consumer Linux phone I know of that's currently in production. It looks like they make the datasheets for the device publicly available: https://developer.puri.sm/Librem5/Hardw ... rence.html. This might be worth a look!
What makes this even better is that there are datasheets available for the individual components. It doesn't look like the modem datasheet is available, but since the OS they run on the phone is open source you'd be able to be do a reasonable job of reverse engineering by looking at their drivers.

So from reading you guys' replies, it seems that the best way to approach this issue is to start off with an arm development board right?

Is there any common point I could use while writing hardware drivers? Like between MTK and Qualcomm processors and stuff.
And how would I obtain those device spesific drivers? If there is a way of obtaining them without having to write my own drivers like extracting them from vendor blobs or something how do you guys think I could achieve that?
+ I am just going to experiment by myself so I probably wont find myself in a lawsuit

Thanks for the replies btw

I just looked at the phone that was in ajxs' post

ajxs wrote: I just remembered that the Purism Librem 5 is a thing. It's the only consumer Linux phone I know of that's currently in production. It looks like they make the datasheets for the device publicly available: https://developer.puri.sm/Librem5/Hardw ... rence.html. This might be worth a look!
What makes this even better is that there are datasheets available for the individual components. It doesn't look like the modem datasheet is available, but since the OS they run on the phone is open source you'd be able to be do a reasonable job of reverse engineering by looking at their drivers.

Not the only one. There is some Fairphone, also all about that "ethical" stuff. But, Pine64 is about a step from starting selling their Pinephone, with the dev kit already "available on a bespoke basis to those who are willing to develop for the platform", see here for details. They have also a tablet and even a couple of ARM laptops! I like what they do, real enthusiasts. In comparison with that Librem thing, Pinephone would be much cheaper I guess, the price for the phone is set to 149$. And there is Pine64 Single Board Computer with the same SoC, Allwinner a64, several flavors of them, with prices starting from 15$ for 512MB version. Actually - paradise for the OP dreams. He just needs to really learn. In addition to wanting.

dopamine wrote:So from reading you guys' replies, it seems that the best way to approach this issue is to start off with an arm development board right?

That's right. You're not going to get any further developing with actual phone hardware than you would with a development board. Once you've mastered that, you can move on to more complicated hardware. To reiterate: A development board gives you the advantage of having better documentation, useful components for learning, and an easier way to flash the device.

dopamine wrote: Is there any common point I could use while writing hardware drivers? Like between MTK and Qualcomm processors and stuff.
And how would I obtain those device spesific drivers? If there is a way of obtaining them without having to write my own drivers like extracting them from vendor blobs or something how do you guys think I could achieve that?

Nope. The only way you're going to get these drivers is to write them. There's no point even trying to extract drivers from Android binaries. Drivers are how your operating system talks to its hardware. Drivers from one OS will generally not work on another. Small amounts of code will of course be the same, but you'll need to write it yourself.

zaval wrote: Not the only one...

Oh wow! I knew about Pinebook, but didn't know about this. This is probably much closer to the mark. Librem 5 seems more geared towards being a usable consumer phone. This looks like hardware for developers. Very cool.

Cool links! I'd much rather pay for one of those phones than spend time and effort trying to reverse engineer closed hardware. Mostly, anyway.


As ajxs said, you will have to write drivers. What I meant was extract the firmware blobs, but you won't have to do that with open hardware or any hardware which is not completely closed. If the makers intend to allow 3rd-party developers (like us) to access the hardware, then they will supply firmware if it's needed.