How to get started on making this mobile OS?

[maybeJosiah]

Hey , as in title, looking to make a 64 bit Arm OS, how to start a mobile operating system? To be more specific, now that I know basic Zig and Arm Assembly, other than becoming an advanced user of those, how to make an OS nearly from scratch with that? If it were not for licensing issues with your wiki, yours for sure, but I am unsure, can you recommend anything good or say current licensing states? Also, what would you like in a mobile OS?

I am okay using GNU/Grub 2 maybe but other than that, not using Linux including Android or *BSD or proprietary things, I know QEMU, Zig, Arm Assembly, an Assembler, an eventual test device, and a computer will be needed to make an OS, what else? Sorry if this forum is only for people who are already experts and I disrupt that but I really want to learn, good luck with your advanced OS building, where can I learn in depth?

[Octocontrabass]

how to start a mobile operating system?

Most of what makes a mobile operating system special is the user interface. Android is a custom userspace running on top of a fairly normal Linux kernel, for example.

The parts that will give you the most trouble are hardware-specific: booting your kernel and writing drivers for your mobile device's hardware. Documentation is almost entirely nonexistent, though there are some exceptions.

If it were not for licensing issues with your wiki,

Don't worry, once you understand what you're doing, you won't want to copy any of the code in the wiki anyway.

I am okay using GNU/Grub 2 maybe

I think U-Boot is pretty common for mobile devices.

Arm Assembly, an Assembler, an eventual test device, and a computer will be needed to make an OS, what else?

A virtual machine and a lot of studying.

[maybeJosiah]

I think OSDev.org wiki is a great start but where to study in depth, there are plenty of slightly modified OS tutorials, not much how to build a full usable one like this, so thanks but lots of study means something to study, so what? I guess I will read wiki before asking many more questions and U-Boot is good maybe or maybe not, maybe.

[zaval]

concentrate on the things that really will give you the required knowledge, forgetting about licensing bs. I don't know what is Zig, but I feel, it's also something, that won't help at least to say. up to you anyway. like writing an OS isn't enough of challenge. learning to write system code for arm64 doesn't differ from learning the same for x86. "mobile" platforms are also personal computers, their OSs are the same as with other PCs in the core. UI differences and underlying differences in the middleware won't be your first concerns.

so thanks but lots of study means something to study, so what?

its name is ARM ARM: ARM architecture reference manual. this is one HUUUGE 455 source for "something" to study. plus, again, books on algorithms, data structures and how to write an OS and endless specifications for needed standards (UEFI, ACPI, different HCI, USB, network, file systems, executable formats etc). just like with x86. arm specific would be, apart from the mentioned ARM and following TRMs and specs (GIC, Cortexes), also TRMs for common ARM SoCs, found in SBCs like Bananas, Oranges, Pine etc. There are leaked rockchip TRMs, they will give some info on SoC internals. In short, it's the same sources as with x86. and about tools again, the same.

It's doable. I got back to my effort lately and here is my successful jump into the kernel. Exactly on arm64. It was painful in comparison with the light breeze of ia32 and x64, partly because of the overdesigned arm architecture and bizzare manual, but mostly because I made many miserable mistakes. still, it was successful.
It's Qemu, but, this code would run on real hardware too, maybe. I don't have such, except my personal phone LG Thinq, for which renegade project hackers ported EDK2 (to run Windows). But unlike an open PC platform, it's not trivial to make a gewgle screwed mobile phone run a third party code, rearranging it to put a normal firmware and open the room for running your code is risky, so I decided to get back at it, when my OS gets a bit meatier. Personally, I'd buy a rk3588 board, for which there is EDK2 port, like Orange Pi 5 and tested on it along with the so helpful emulators, Qemu in the arm case is the saver.

[maybeJosiah]

Ah, hurray, something to study, also, https://ziglang.org, Zig, possibly fastest programming language to date, I had no idea that manual existed, any other great tips ?

[zaval]

Yeah, oddly enough, arm also provides manuals. In fact, they seem to like it so much, that they have produced hundreds of them, many of which are several thousands pages long.

I think, you knew about this manual, you just neglected it. I wanted to emphasize, that it's a wrong choice if one really wants to create an OS for the arm dominated platform.

Zig, possibly fastest programming language to date.

Well, then my feeling was right.

[eekee]

One feature I want from a mobile OS (or indeed any OS) may best be designed into an OS from the start: Any app may be suspended at any time, flushed to permanent storage, and resumed without losing its state. This has pros and cons. It's particularly good when RAM is in short supply; a rare issue these days but might be the case if you want good battery life in a lightweight device. Even the Raspberry Pi 0 wants a battery which is uncomfortably heavy for some people. I want it for that reason and because my thoughts are easily disrupted. I need apps to open with no delays, showing what I was last doing. It also makes process migration easier; more of a server feature. On the other hand, it makes app development confusing to some and you will probably end up wanting background processes which stay resident anyway, (e.g. for downloading in the background,) so you do you.

If you do want this feature, you may want to have all userspace memory allocation based on mmap(), though it could also be done with swap space. I'm targeting devices without an MMU, so I'm using an old Forth feature; "blocks" get loaded into RAM on request, may be marked "updated" by the userspace code, and are automatically or manually written back to disk as needed. From an OS design perspective, this block feature isn't very simple. It's simpler with cooperative multitasking because there's nothing stopping a program using the block buffer from the time it calls `block` to the next system call. With preemptive multitasking, it's nicer to have a MMU.

Yeah, oddly enough, arm also provides manuals. In fact, they seem to like it so much, that they have produced hundreds of them, many of which are several thousands pages long.

I think, you knew about this manual, you just neglected it. I wanted to emphasize, that it's a wrong choice if one really wants to create an OS for the arm dominated platform.

I was very slow to develop the habit of looking in the obvious places for manuals because I found it difficult to navigate many companies' sites. Manuals were often hidden behind menus (which always give me a headache) with attention-grabbing info-lite perhaps to distract you from finding the real info before you buy stuff. All this trained me to ask and not look. But ARM are very good about making it easy to find manuals.

Zig, possibly fastest programming language to date.

Well, then my feeling was right.

Uh... yeah, I guess. I always remember the reasoning that higher-level languages are easier to optimise, but Zig is no higher level than C if I read right, possibly lower.

@maybeJosiah: Speaking from experience, never get overly excited about your tools. I'm sure there's no harm in using and liking Zig, but "possibly fastest programming language to date" is hardly worth repeating. It's not going to be much faster than C, and your OS is not going to be as fast as Linux without you making hundreds of optimizations which will make it painfully hard to maintain your code.

I can think of a few maybe-issues with Zig. You'll have to translate example code before using it, but that will help you understand it so it might be a good thing. It's just not for the impatient. (OS development is not for the impatient.) Its core libraries APIs might not be settled yet, so you might have to stick to a particular version of the libraries and compiler.

Perhaps the biggest potential issue is that because it's not as popular as C, there's a higher chance of compiler and library bugs. You may have to stick to a version for this reason too, relying on your experience with that version's bugs rather than the unknown bugs of the latest version.

[maybeJosiah]

https://codeforum.org/threads/what-do-y ... stem.8100/ Here are some high level ideas, just ideas, but I know 3+ dimensional navigation I can do and have a library for, and seriously, I never found those reference manuals until I knew what they were called from you people, and probably some of these features just can't be done. Last suggestion before this was a good one, I might also have custom desktop navigations for like weird space graphics like hyperbolic, I guess make it modular, allow other modules, and obviously all this odd space could be confusing, 2d option too definitely. Off to study these new to me materials, thanks, and maybe I may use either zfs file system or a custom one, I know I can't stand not getting everything in backups for mobiles without something like bootloader unlock (which voids warantees) in normal devices, I want one that I can fully clone to another local drive I don't have to pay for every time interval. I should get a design document and all features I want and of those all I can feasibly do seemingly, but like I know what can be done so keep that all features I want document. X E.

[eekee]

I may use either zfs file system

what

lol zfs is huge! when the freebsd devs implemented it, they didn't get it working properly for years. filesystems are generally trouble to get working well. the fewer the features, the better you can test them.

you might want to look at venti and maybe fossil from plan 9. venti is a deduplicated block store. you can send "venti scores" from one system to another for cloning. fossil builds a filesystem on top of venti, but you could make your own simpler one more suited to your os if you like. (venti is relatively simple, fossil is huge.) what you won't get with venti is the ability to delete things you wish hadn't got saved to permanent storage... but i think you can make a fresh disk image with scores (or a score) which has the files you want.

plan 9 source code is mit licensed and compiles as c99 if i remember right.
https://9p.io/plan9/

[maybeJosiah]

Yeah, like I know how to do this, zfs might be huge but it was what powers postmarketOS which is rather major, but anyway, like I know, I guess maybe just follow advice until I know better but that full clonable by default thing is really something I want and I prefer in raw form if possible. I should probably do something like rsync on Linux or even port that. Newbie here, beginners make uninformed mistakes. Thanks. X E.

[maybeJosiah]

Does anyone know if I start on ARMv8-A, first 64 bit ARM as far as I can tell, whether it should be forward compatible if it is 64 bit?

[Octocontrabass]

I don't know if it's guaranteed to be 100% forward-compatible, but it should be close enough, and it's a good place to start anyway since there's so much ARMv8-A hardware is out there.

[maybeJosiah]

I am still stumped as to what to study. https://developer.arm.com/documentation/ddi0487/fc/ (ARMv8-A reference manuals) is getting me precisely nowhere, I don't even know ARM Assembly yet and can't find good reference stuff, etc.. Call me dumb but I don't know where to start. I downloaded ARM Development Studio on a Linux machine and have picked a suitable device, Revvl 7 (I can get it for like $70 used). I am now thinking call this thing OnwardOS. At this point it seems your wiki is for x86-64 and has inadequate stuff to build a bootloader less an operating system for mobile. I am finding legitimate OSes on Aarch64 with no stuff like A20 line. ARM is apparently a whole other ball park from x86-64 as you people seem to mostly do. No expert opinions here. Of course you would be experts, not me. Also, apparently there are some minimal extra features between ARMv8 and ARMv9. X E.

[maybeJosiah]

https://www.udemy.com/course/raspberry- ... p-by-step/
https://www.udemy.com/course/arm-64-bit ... pberry-pi/
These are for ARM64, well, I guess I start then. X E.

[Octocontrabass]

At this point it seems your wiki is for x86-64 and has inadequate stuff to build a bootloader less an operating system for mobile.

That's because most ARM devices don't have standard firmware or hardware. It's not like an x86(-64) PC where everything is pretty similar from device to device. (U-Boot helps with the firmware: it can provide a partial UEFI implementation so you can start on top of UEFI the same way you would on a PC.)

These are for ARM64, well, I guess I start then.

Those are for Raspberry Pi. Some of the information will apply to all ARMv8-A devices, but some of the information will only apply to Raspberry Pi.