How capable is ARM and am I as an x86 developer capable of adapting?
Nowadays ARM processors are considerably slower than x86 ones. But less power hungry too. Less overheating. Often work without any cooling. But with heavy load, throttling occurs (if you have it implemented, otherwise, chip burns out
), so adding a heatsink is a good idea. And DVFS code of course too!
How capable you are in adapting it, it's a different story. I found arm assembly easy to learn. It's a normal RISC ISA.
In C for arm you program the same way as on x86. Given you have learnt its specifics (i.e. alignment requirements) and don't make silly decisions disregarding them.
How hard is ARM compared to x86 and is "porting" from one to another possible? Can you port an entire OS you've created?
Not harder. Not easier. Porting is possible. The amount of porting effort depends on how x86-tied your OS was.
Is ARM documentation relatively open source?
Emmm. Documentation manuals on ARM processors (ARM ARMs - ARM Architecture Reference Manuals and company) are freely downloadable. Some, not for first needs, odd documents, require from you to be registered though. So, available just like Intel's. What do you mean by its open sourceness - is not clear. No they probably won't let you edit them.
Driving multiple LCD's with different signaling interfaces and resolutions.
ARM world for enthusiast developers is the world of SBCs - Single Board Computers. SoCs for them come mostly from smartphone/mobile/set top boxes markets. So LCD controllers are present almost always. They could drive many things. But almost always on SBCs it's an HDMI interface. This is what you will be dealing with.
A touch screen.
Always present. And screens are available as goodies.
SATA or IDE communication/interface. Mainly CD/DVD players and SSD type storage.
This is the area where SBCs have hard times to deal with. Because of the same reasons - SoC are smartphone targetting. But even here, the situation is not hopeless. I've just bought this board, see below. As an addition to one I have, Cubieboard 2. They come with Allwinner's chips, and this company has made a pleasure for hordes of DIYers adding in some of their SoCs a so desirable SATA/AHCI controller! For good NAS/media player etc DIY solutions. (Although for some obscure reasons it has a really bad write speeds on linux at least, anyway, it's still fast and this problem is yet another interesting problem to dig into for OSdevers (that might challenge themselves to try to make their SATA driver faster
))
The board, Banana Pi M2 Ultra
This is mostly an interface for 2.5'' HDDs and SSDs since these boards don't have 12V supply. But you need just an external 12 V supply if you wanna attach 3.5'' drives. As of CD/DVDs connected to SATA, I didn't hear about that scenario, but I think with a proper power supply, it should be doable too.
There is also even more SATA capable arm SBCs sporting more than 1 SATA interface, most notably EspressoBin board and the boards from Solidrun, which have Marvell Armada series processors. EspressoBin is cheap, but delivery is almost as big as the board cost. That was a showstopper for me, why I didn't buy it. And yet Marvell has zero wish to supply SoC Programming Manuals. You would need to decipher everything from their uboot/linux code. which is not the best approach, have to admit.
Full USB communication/interface.
Absolutely. Until recently this was only USB2 but the situation is changing quickly, there are USB3 capable SoCs and boards. I am planning to buy one. Rock64 with Rockchip RK3328 quad-core Cortex-A53 CPUs, 4GB of DDR3 and USB3.
Generally boards have 1-4 ports. Sometimes there are some weird design desicions when a board vendor chooses to put several USB prts on the onboard hub, while leaving another SoC port unused. But this happens rarely.
With respect of the previous point about storage interfaces, it should be noted that USB here is often used as such. And among the old and somewhat inefficient BOT protocol, UAS protocol starts to play its role. It is present on USB3 capable boards but it might be present even on some USB2 boards. Like aforementioned Allwinner SoCs boards. It is possible to use UASP with the controllers on those boards.
High resolution graphics (processor), programming and using it, real drivers and documentation?
GPUs on arm boards have nothing to do with display driving and resolutions. Nor with video encoding/decoding (for the latter, there are VPUs as much undocumented as GPUs though). GPU are plain 3D engine things. And they are horribly inaccessible to program. It's a total abysmal. Only Android generally can use their capabilities. linux can't. due to the licensing and closed nature. It is applicable in varying degrees to any GPU vendor - ARM, Imagination, Vivante, Quallcomm. Mostly GPU is a black hole for osdevers. you just gate clocks to it and turn it off. that's all about it.
Just to have an idea - the part on SGX PoverVR GPU in the CI20 manual takes up the whole ... 2 pages. Of advertisements on how cool it is.
Fancy looking graphical operating system, self made (OSDev).
But there are also some 2D "accelerators". They might or might not be documented, so you can or cannot take advantage of them in making your "fancy" looking graphical interface. On linux it's ugly and not "accelereted". On Android it's ugly and "accelerated".
But you could use ARM cpus' NEON SIMD for GUI stuff. Kinda like.
For me, my OS pretty long time is a console user interface even in my ideas. I don't even think much on GUI. Not only because of mentioned limitations. But because of lack of expertise on my side. Who knows, maybe it will change in future. Both of those I mean.
In short, you do your GUI without the help from special processing units. they are not documented.
Lots and lots and tons of GPIO ports, both input and output that an OS would be able to talk to.
tons of these are available. just look at the photos, those headers are extension headers exposing a very rich set of different things. GPIO is a strong side of these boards.
A timer of sort.
of course. a lot of them. On CI20 (mips, but on arm the same) I have 6 16-bit timers and 1 64-bit "OS" timer. they are very configurable and multifunctional.
here is a short excerpt. I wouldn't say better than they:
The TCU (Timer/Counter with PWM output) contains 8 channels of 16-bit programmable timers (timers 0 to 5). They can be used as Timer or PWM.
* There are two modes of TCU for the eight channels
* TCU1: Channel 0, 3,4, 5, 6,and 7
* TCU2: Channel 1,2
* Six independent channels, each consisting of
* Counter
* Data register (FULL and HALF)
* Control register
* Independent clock for each counter, selectable by software
* PCLK, EXTAL and RTCCLK can be used as the clock for counter
* The division ratio of the clock can be set to 1, 4, 16, 64, 256 and 1024 by software
* FULL interrupt and HALF interrupt can be generated for each channel using the compare data registers
* Timer 0-7 can be used as PWM (Set the initial signal level)
* Timer 0,3-7 can be used as a counter to count external signal (like trackball)
* Timer 5 has separated interrupt
* Timer 0-4 and timer 6-7 has one interrupt in common
* OST uses interrupt 0, Timer 5 uses interrupt 1, and Timer 1-4/ 6-7 uses interrupt 2
* The difference between TCU1 and TCU2
* TCU1: It cannot work in sleep mode, but operated easily
* TCU2: It can work in sleep mode, but operated more complicated than TCU1
so yes it is present.
Converting signals so you can talk to different microcontrollers. I guess I would need a separate circuit for this (and for lots of other things too).
not sure what you mean. but for example TI's Sitara SoCs contains so called PRUs (Programmable Real-Time Unit Subsystem and Industrial Communication Subsystem (PRU-ICSS)) controllers with its own ISA, that might be programmed to serve some specific tasks.
here how they introduce them on AM3358 SoC (found in Beagle Bone Black board I have btw
):
The Programmable Real-Time Unit Subsystem and Industrial Communication Subsystem (PRU-ICSS)
consists of dual 32-bit RISC cores (Programmable Real-Time Units, or PRUs), shared, data, and
instruction memories, internal peripheral modules, and an interrupt controller (INTC). The programmable
nature of the PRU, along with its access to pins, events and all SoC resources, provides flexibility in
implementing fast real-time responses, specialized data handling operations, custom peripheral interfaces,
and in offloading tasks from the other processor cores of the system-on-chip (SoC).
Is this that you are searching for?
WiFi and Bluetooth communication.
Many board have those. Recently it has been discussed here how "easy" it might be to get the documentation on these chips on x86. The same applies here. But hardware is present. For example CI20 has both (Realtek's I believe).
Using standard video codes.
didn't understand.
Can I use C and C++ for the kernel / OS? I guess yes.
yes.
Let me just say that I don't care about tasking really, should I? I need a specific amount of apps that would be pre-installed and no more. No additional apps, no need to be dynamic in any way.
Apps would be specifically compiled so they know where the other app is and to not use its memory space or whatever. Also protection would not be important.
Multiprocessor (SMP) and Virtual Memory system (VMSA) and there is also PMSA, Protected Memory system architecture for R cores, thus without VM just like you say if i got it right, but R series aren't found broadly, it's more embedded thing, like for broadband processors, so generally you stick up with VM, and it is as developed here as on x86 (even though it comes without annoying "legacy" in from of segmentation, don't expect of it to be easy, it's a brainf&ck thing still, but folks from the x86 realm shouldn't be affraid of that, really
).
Plus a bunch of processor modes. There is even Secure World - a very messy thing to get osdevers their hands dirty on. Interesting and challenging. Allows you to split your entire design into Secure and Nonsecure worlds, having hardware protected areas (memory, devices) even from Nonsecure privileged code. Basically Secure OS (called the Monitor there) on its own right. Parasitic technology also known as Hardware virtualization is abvailable too.
Also I don't need to target multiple systems, multiple manufacturers or anything like that. The OS itself would only be ran on that specific hardware.
Now, this is all in theory.
With this you might get somewhat limited, some other vendors could provide a better fit for you. Or one is better at one thing, other on another. See above. It's hard to choose that "only one". But yes, it's theory, you'd figure out for yourself better what exactly you want. There is a lot of ARM vendors. Both SoC vendors and board manufacturers.
Can I develop all of this on a modern desktop. Are there such tools, compilers, emulators that let you really customize the thing. I know I didn't provide enough hardware info, that is because I don't know it myself. That is why I am asking this, to look at the options I have.
Yes. There are. ARM's one is for money. Linaro toolchain is free (and bloated AF). There are free and non-free emulators, however I couldn't help with this, I hate them and don't use. x^D
I would be very grateful if a person that knows this would reply. I know this is not something small or easy. Just researching.
Do you have any experience with this? Any examples to look at?
Well, then you'd excuse me that I intruded. Since I am not that person "that knows" that much. Also doing research and only starting to do things there. My experience is not that much thus. But I do this since ~2014.)
Examples for exactly what? Boot/init sequence? Then you might want to look at uboot sources for arm boards. ARM also provides something, I even saw it somewhere.
I use uboot and manuals and different knowledge bases collected around communities, like for example
sunxi community, that one, that makes linux better on Allwinner chips.
There are books covering ARM specifically.
You just learn ARM architecture specifics, general things like ISA, registers, states modes (moods
) etc (part A of the manual), system level (part B) VMSA, exceptions, SMP, cache maintenance etc. Loads of other documents like on ABI, GIC, AXI, you easily find them on the arm site. And learn tools, assembly and arm specific C things. There is documentation on ARM tools as well as GNU made for their GCC and company.
And then you think how to do your OS on this. OS internals should be quite CPU architecture agnostic, shouldn't they? So for familiarizng with ARM you learn its manuals, tool documentation, wikis and just useful resource you find on your way of learning and cicrling around that interested people. Everything beyond the scope of architecture specifics is the same as on x86. it's your OS after all.
