OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 10:08 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: How capable is ARM? Other ARM Questions.
PostPosted: Sat Oct 07, 2017 12:21 pm 
Offline
Member
Member
User avatar

Joined: Fri Aug 07, 2015 6:13 am
Posts: 1134
Hello everybody!

I have a very specific question that you might have not seen around a whole lot.
How capable is ARM and am I as an x86 developer capable of adapting?
First let's just say that I have a specific use case scenario for ARM and that is why is need it.

How hard is ARM compared to x86 and is "porting" from one to another possible? Can you port an entire OS you've created?
Is ARM documentation relatively open source?

Does it satisfy these requirements and most importantly can I as a developer code all these systems without too much pain?
(I am not asking about phones/tablets in here, more like standalone/DIY/custom boards)
  • Driving multiple LCD's with different signaling interfaces and resolutions.
  • A touch screen.
  • SATA or IDE communication/interface. Mainly CD/DVD players and SSD type storage.
  • Full USB communication/interface.
  • Lots and lots and tons of GPIO ports, both input and output that an OS would be able to talk to.
  • High resolution graphics (processor), programming and using it, real drivers and documentation?
  • Fancy looking graphical operating system, self made (OSDev).
  • A timer of sort.
  • 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).
  • WiFi and Bluetooth communication.
  • Using standard video codes.

So, how many items from the list above are doable?
Is ARM code something super crazy hard?
Can I use C and C++ for the kernel / OS? I guess 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.
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. 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.

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?

_________________
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader


Top
 Profile  
 
 Post subject: Re: How capable is ARM? Other ARM Questions.
PostPosted: Sat Oct 07, 2017 2:28 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
Octacone wrote:
How capable is ARM


The flippant answer is, take a look at your smartphone and tell me what it can do. If it isn't an ARM-based model, I'd be frankly shocked - something like 90% of smartphones and tablets are ARM-based, including the Apple iPhone and iPad, as well as all of the Samsung, Google, and HTC models. BTW, most of the remainder use either AVR (which is an ARM derivative) or MIPS (an unrelated RISC design which got started contemporary with the early ARM models of the mid-1980s) - the main exceptions being those by Microsoft and their affiliates - so this is one place where x86 isn't anywhere close to being the dominant ISA.

More seriously, this is going to depend on what you mean by 'capable'. In a purely abstract sense, both x86 and ARM (like pretty much every general-purpose CPU ever designed) are Turing-equivalent systems; given enough time and memory, they can in principle compute anything that can be mechanically computed. However, the same holds true of every general-purpose computer going back to things like the EDVAC and UNIVAC, just as it does with ever general-purpose programming language, so it doesn't really help in making comparisons.

Most of the other things you asked about - operating a video display, driving various other kinds of peripherals, etc. - have nothing to do with the CPU per se, and everything to do with the chipset it is used with, and the hardware it connects to. All of that will depend on the motherboard or SBC it is on, though most SoC systems (System-On-Chip, where the CPU, GPU, and chipset are all packaged into a single unit) have a lot of on-chip support for those things anyway. So the TL;DR: is, yes, but with enough hardware hackery, so can the 6502 out of a Commodore 64 or Apple II.

Thus, most of the actual comparisons come to a few things: addressable memory, clock rate, rate of instruction processing (the ratio of cycles to instructions for a given operation), number of cores on a given chip (which again isn't really specific to ARM or x86 as an architecture, but to the specific hardware you're using), and things of that nature. However, these are things which, quite frankly, can vary as much within a processor family as between them. A blanket answer just isn't possible.

While current models of ARM CPUs generally have lower clock speeds than current x86 ones, that has little to do with the ISA itself. The difference has more to do with the silicon process used (IIUC, most fabs producing ARM chips are still using 14nm, 18nm, or even 21nm processes, while Intel and AMD have both passed the 10nm mark in their x86 fabs; Apple and Samsung use 10nm ARMs in their latest phone and tablet models, but most other ARM-based hardware isn't that far yet), and the market they are targeting. ARM is mostly being used in things like phones, where both power consumption and heat generation need to be as low as possible. Conversely, x86 systems are usually either desktops, which have the space for larger heat dissipation systems, don't have significant weight considerations, and run off of wall power; or laptops, which are somewhere in between - and even those generally use versions of the CPU which have lower clock speeds, as well. The SoC versions of the x86 cores have clock speeds in the same range as most ARM cores.

Address space usually depends more on the address bit width of the specific model (e.g., 32 vs 64), and since there are both 32 and 64 bit versions of both x86 and ARM, those are pretty much the same. The chipsets also factor into it regarding how much physical memory they can actually address in terms of memory bus logic (and the maximum access speeds, and how much of the physical memory they can access at those highest available speeds), but again, they are about the same there too.

Octacone wrote:
and am I as an x86 developer capable of adapting?


That's really going to be up to you, but I would expect so. Honestly, while the ISA does have some really odd quirks to it, and is much more complex than, say, MIPS, it is still a lot simpler than x86. The x86 as an ISA is like English as a language, in that it is one of the hardest of all to master, but is so ubiquitous that you can't afford to ignore it.

Octacone wrote:
How hard is ARM compared to x86 and is "porting" from one to another possible? Can you port an entire OS you've created?


That going to depend on the OS, how much of the OS is in a HLL and how much is in hand-coded assembly, and how much effort you are willing to put into it. The general answer is yes, even if it is pure assembly (by re-writing the procedures to the different ISA), but in practice it all depends on how much work you are willing to do. There are some things which will make it easier or harder depending on how much the OS depends on specific features of the ISA and memory architecture, but most of those can be worked around with time and effort.

Octacone wrote:
Is ARM documentation relatively open source?


Ehh, about as much as Intel's is, I guess. It's not hard to get answers for the most common problems, while the answers to harder problems may not be known at all, even by the manufacturers.

Octacone wrote:
Is ARM code something super crazy hard?


That's going to depend on you, I would say. I personally would expect most to find it easier, but more tedious - as a RISC ISA, most of it's instructions are simple, highly regular, and highly orthogonal, with very few edge cases, but you usually need to use more instructions to implement a given operation than on a CISC ISA such as x86. However, part of the point of RISC was to make it easier to generate optimal code with a compiler, rather writing it by hand.

Quote:
Can I use C and C++ for the kernel / OS? I guess yes.


Certainly. The most common OS for the Raspberry Pi is Raspbian, which is based on Debian Linux; most of the other ARM and MIPS SBC systems use some flavor of Linux, and Android - which runs on nearly every smartphone and tablet not made by Apple, the majority of which are ARM or (less commonly) MIPS systems, as I already stated - is also a Linux derivative. I'd guess that at least 90% of the code for the kernel, shells, binutils, etc. is shared between the different ports of Linux, with the rest being either CPU-specific kernel code or peripheral-specific driver code. Even the major desktops and window managers are mostly portable, provided that an X or Wayland display manager is available.

How much that will apply to your own OS is going to depend on how you designed it, however. If it is working directly with the hardware in ways that don't abstract well, then porting is going to be hard even between different x86 models, never mind to a completely different ISA.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Last edited by Schol-R-LEA on Sat Oct 07, 2017 11:01 pm, edited 3 times in total.

Top
 Profile  
 
 Post subject: Re: How capable is ARM? Other ARM Questions.
PostPosted: Sat Oct 07, 2017 4:02 pm 
Offline
Member
Member
User avatar

Joined: Fri Feb 17, 2017 4:01 pm
Posts: 640
Location: Ukraine, Bachmut
Quote:
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 :mrgreen:), so adding a heatsink is a good idea. And DVFS code of course too! :D
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.
Quote:
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.

Quote:
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. :D

Quote:
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.

Quote:
A touch screen.

Always present. And screens are available as goodies.
Quote:
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
Image

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.

Quote:
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.

Quote:
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.
Quote:
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. :D
In short, you do your GUI without the help from special processing units. they are not documented.
Quote:
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.

Quote:
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:
Quote:
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.

Quote:
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 :)):
Quote:
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?

Quote:
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).

Quote:
Using standard video codes.

didn't understand.

Quote:
Can I use C and C++ for the kernel / OS? I guess yes.

yes.
Quote:
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 :D).
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.
Quote:
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.
Quote:
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
Quote:
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. :D 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 :D) 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.

_________________
ANT - NT-like OS for x64 and arm64.
efify - UEFI for a couple of boards (mips and arm). suspended due to lost of all the target park boards (russians destroyed our town).


Top
 Profile  
 
 Post subject: Re: How capable is ARM? Other ARM Questions.
PostPosted: Sat Oct 07, 2017 11:06 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
I forgot to address the emulator issue. If you are already familiar with QEMU, you're in luck, as there are ARM emulator variants of it that will run on an x86 system, which is what I assume you had in mind.

There are other ARM emulators, but I don't really know much about them.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: How capable is ARM? Other ARM Questions.
PostPosted: Mon Oct 09, 2017 3:36 am 
Offline
Member
Member
User avatar

Joined: Sun Oct 22, 2006 7:01 am
Posts: 2646
Location: Devon, UK
Hi,

Just as a bit of a sidenote, if you are specifically looking at the SBC arena and are already more comfortable with x86, there's always the UDOO x86. This is a relatively new board (which I have) and I am assured the hardware is open enough to write an OS, although I haven't tried yet.

The big drawback compared with a lot of the ARM SBC's is the cost. It comes in 4 flavours but even the most basic is pretty expensive compared, for example, to a RPi.

Cheers,
Adam


Top
 Profile  
 
 Post subject: Re: How capable is ARM? Other ARM Questions.
PostPosted: Mon Oct 09, 2017 8:51 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
Be aware that with an ARM board you will likely have to use a USB keyboard, so be sure that you are up to speed on USB. Alternatively, you may be able to use a serial terminal to connect to the board.


Top
 Profile  
 
 Post subject: Re: How capable is ARM? Other ARM Questions.
PostPosted: Mon Oct 09, 2017 12:22 pm 
Offline
Member
Member
User avatar

Joined: Fri Aug 07, 2015 6:13 am
Posts: 1134
Schol-R-LEA, zaval, AJ, iansjack thanks so much for replying. You managed to answer almost all of my dilemmas.

It is really great that you can use C and C++ the same way you do on x86. I guess there shouldn't be too much of ARM assembly involved. Except maybe a bootloader?
I don't really want to port things around, I was just wondering if I could make for e.g. drivers for x86 and make them work on ARM. Porting an entire OS would only be an option as a core but not the graphical subsystem.
Power (not) hungriness is something I like about ARM, not overheating is a nice touch too. Since the power conditions are special in my case.
I haven't heard much about alignment requirements doe. Only some discussions here on forum about how stupid ignoring that is??
Well ARM doesn't need stupid dinosaur segmentation descriptor tables and stuff. Unfortunately looks like ARM has something similar to paging...
I know that ARM processors are documented. Third party hardware is the thing I was afraid of. Same as on x86. GPU documentation is still being looked for. A quest that will never end.
I can live with HDMI but then I will need some sort of a converter board. I've seen boards with multiple monitor ports which is good.
Standard is something you can't really apply when it comes to said CD/DVD players. I am thinking of making something custom while utilizing the existing components. Some hackery black magic. Don't know what to use for custom jobs. Don't want to reinvent the wheel, I need something powerful but small that can use SATA or well known interface. But that is not the point of this topic.
Banana Pi :D, looks good on paper, questionable community.
1 SATA ports is definitely enough. Only need it for like 1 SSD.
USB 2.0 or 3.0 not that is matters as long as there is a way to code it for a custom OS.
I don't actually need any fancy 3D graphics. It would be a standard 2D interface like e.g. mac OS, Windows... It just needs to be fluid, without GUI lag. 2 whole pages! I am impressed :P
Console is not an options since this is a GUI based system.
Yup, looks like GPIOs are standardized. If I run out of them, I can hack something together.
That is one beefy timer. I only need mine to tell the time and run my scheduler. That things is OP.
Hmm, I don't know what I need for converting signals yet. Google says it is possible in my case. It is like sending commands over a port in a specific format.
I meant something like video playback but that is more software related.
x86 guys know what it feels to be crushed by memory management, it can't be that hard.
Yeah I am familiar with QEMU it shouldn't be a problem.
AJ, until you posted your reply I was really scared if I could pull this off. You showed me my savior.
That is like the exact thing I was looking for. It even has a large community and only uses 5-6 watts. It has Intel HD Graphics which is by some miracle documented.
Cost is not a problem at all, it is not even a fraction of the "projects" cost. Perfection is worth the money. Good old familiar x86.
I am just wondering how does x86 talk to non-PC hardware like there are things that are not standard, that you can't find anything about in here.
USB keyboard shouldn't be a problem. As long as there is Ben Lunt who can solve any USB problem on the planet. I just hope that USB is processor independent.
Actually I will not need a keyboard at all. Touch screen is going to be the main input.

Is anyone still reading this large chunk of text? :roll:

_________________
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader


Top
 Profile  
 
 Post subject: Re: How capable is ARM? Other ARM Questions.
PostPosted: Mon Oct 09, 2017 12:31 pm 
Offline
Member
Member
User avatar

Joined: Fri Feb 17, 2017 4:01 pm
Posts: 640
Location: Ukraine, Bachmut
Quote:
Be aware that with an ARM board you will likely have to use a USB keyboard, so be sure that you are up to speed on USB. Alternatively, you may be able to use a serial terminal to connect to the board.

but interestingly, some SoCs have PS/2 controller (8042 compatible, with pins both for mouse and keyboard). like jz4780 found on the CI20 board. one needs somehow to attach mouse and keyboard to the EJTAG header on this board.

Quote:
I haven't heard much about alignment requirements doe. Only some discussions here on forum about how stupid ignoring that is??

alignment was just an example of something, one should take into account when writing for arm.
Like stack organization (arm ISA has the ability to implement every possible stack variant - full descending, full ascending, empty descending, empty ascending - this is even encoded into instruction names! with redundancy! like for example STMDB - store multiple decrement before - for the Full Descending stack push semantics, LDMIA - load multiple increment after, the pop semantics. And the same might be called as STMFD (store multiple full descending) LDMFD (load multiple full descending) appropriately). :D
Or ABI. like how much registers are used to pass function arguments, that may be considered when fleshing out new functions.

alignment there is "natural". 1 byte entities aren't aligned, 2-byte entities are put on 2-byte aligned addresses and so on. it's what your compiler will do for you anyway, neverthless, I guess for the OS internal structures it's better to organize them properly without the compiler help, to not have "surprises" later.

_________________
ANT - NT-like OS for x64 and arm64.
efify - UEFI for a couple of boards (mips and arm). suspended due to lost of all the target park boards (russians destroyed our town).


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot], Google [Bot], Majestic-12 [Bot], Sa41848 and 63 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group