Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Background information on the architecture: I just designed a set of instructions for a CPU that I'm going to put in an FPGA, but I want to be able to do it compatible with Linux (a simple Linux system) but I just started with this and I do not know much about this, I'm sure Linux can serve in my CPU. I think AVR supports Linux too, but I do not know if this is true but if this is true I think my CPU can also.
My CPU is 16 bits, and it has the following registers:
AX
BX
CX
DX
EX
FX
This can support up to 256 (16-bits registers), I also only put a few registers because I do not know if it will give me space for the VGA driver in my FPGA, think that 8 registers more could fit in the register file. My FPGA board has a Cyclone IV.
The program counter
or (PC) of my CPU is 16 bits.
My CPU handles data with Pointers (ARP, BRP) that point to two registers and take the value of the registers to the two outputs that can be used to put the values (A, B) of the ALU. To save data in the registers I use two pointers as well (CRP, DRP) with these I point to the registers where the values will be stored, the instructions say if the pointers are going to be used to save a value because otherwise, the value would be saved in two registers by mistake.
I do not know if this information is useful to give you an idea if I'm going to be able to use Linux in my design.
Thank you so much! ☺
Question: Is it possible to port Linux to a 16bit architecture?
Edit: After almost 3 years of gained experience with embedded systems, I see how ignorant this question is. I cannot provide an answer to this question because this question is flagged to not accept answers. But I will try to explain why porting Linux natively to a 16bit CPU is almost impossible.
Real Linux requires MMU to work, although there is uClinux which requires no MMU. MMU is required to provide userspace programs with their own memory address space without other programs interfering.
16bit address space is too limited to even run what is required. As the smaller Linux installations that I've seen need 8MB which is way off the 16bit address space (64 kilobytes).
Linux kernel needs Binutils and GCC to compile!
It will be very hacky and tricky to port GCC because GCC was designed to target 32bit architectures.
I mentioned earlier that it's almost impossible but, you can do emulation and with help of external hardware, you can emulate another architecture. But that's cheating, isn't it?
http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20on%208bit
Finally, if you really want to run Linux on your custom CPU, start with RISCV. It supports GCC and all the required tools, plus RISCV is the future!
If you really want to run an OS in your custom CPU, you can port it to the LCC compiler. Run RTOS. This is a more realistic approach. But still, it is a challenging one.
You are out of luck. Linux requires a 32 bit system to run.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I understand that the answer to this question, like most, is "it depends", but what I am looking for is not so much an answer as much as a rationale for the different things affecting the decision.
My use case is that I have an ARM Cortex A8 (TI AM335x) running an embedded device. My options are to use some embedded linux to take advantage of some prebuilt drivers and other things to make development faster, but my biggest concern for this project is the speed of the device. Memory and disk space are not much of a concern. I think it is a safe assumption that programming directly against the mpu and not using a full OS would certainly make the application faster, but gaining a 1 or 2 percent speedup is not worth the extra development time.
I imagine that the largest slowdowns are going to come from the kernel context switching and memory mapping but I do not have the knowledge to correctly assess or gauge the extent of those slowdowns. Any guidance would be greatly appreciated!
Your concerns are reasonable. Going bare metal can/will improve performance but it may only be a few percent improvement..."it depends".
Going bare metal for something that has fully functional drivers in linux but no fully functional drivers bare metal, will cost you development and possibly maintenance time, is it worth that to get the performance gain?
You have to ask yourself as well am I using the right platform, and/or am I using the right approach for whatever it is you want to do on that processor that you think or know is too slow. Are you sure you know where the bottleneck is? Are you sure your optimization is in the right place?
You have not provided any info that would give us a gut feel, so you have to go on your gut feel as to what path to take. A different embedded platform (pros and cons), bare metal or operating system. Linux or rtos or other. One programming language vs another, one peripheral vs another, and so on and so on. You wont actually know until you try each of these paths, but that can be and likely is cost and time prohibitive...
As far as the generic title question of os vs bare metal, the answer is "it depends". The differences can swing widely, from almost the same to hundreds to thousands of times faster on bare metal. But for any particular application/task/algorithm...it depends.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I would like to know Board bring up package underlaying architecture dependent? What actullay wanted to know can we have 64 bit architecture running 32 bit bsp code or BSP code always be 64 bit since BSP code is architecture specific.
Yes, absolutely. The BSP is very specific to the architecture of the procesor and the board itself. Having said that, it's possible that there aren't that many changes needed to run at 64-bit. One thing that most BSP's contain is a piece of startup code that initializes the hardware registers in the system. Some of these MAY change when you move to 64-bit.
The second part is the bootloader, which loads the kernel/OS/whatever into RAM (typically - it may just initialize the ROM region to be executable and set it up correctly). Again, this may need changing, as it probably "jumps to the OS in 32 bit", and the OS may expect a 64-bit jump.
Then you have the OS/kernel itself, which clearly needs recompiling.
How much work you actually need to do depends on what architecture the board is, the processor you're using and, most importantly, the requirements from the OS and upper layer software to operate in 64-bit mode - does the memory setup by the init-code or bootloader need to change? When does the switch from 32- to 64-bit happen - inside the OS or outside?
This may not be the answer you were looking for, but I think no one, except those who know the BSP intimately will be able to say exactly what you need to change - I'm pretty sure it's not a complete rewrite, but there may be a load of assumptions along the lines of "we know a pointer is 32 bits, so an int will hold a pointer" or "we know a pointer is four bytes, so we reserve four bytes here..."
Mats pretty much covered it. Like any other application it is a combination of the two or multiple platforms you are targeting and the desires and design of the application. The architectures may be so far apart that it makes no sense at all to try to target them with a single BSP. If the architectures are similar enough you could target them with a single BSP, but you may or may not choose to. Linux or the BSDs are a perfect example, there is a fair amount of the code that is multi-platform, with some platform specific parts. A bsp is no different, often just less complicated, most of your code is generally C or some similar language so it is whatever you compile to that is the target, the bootstrap and some other similar parts are asm and those would be target specific. FreeRTOS is probably even better of an example than Linux or the BSDs.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
Writing emulators has always fascinated me. Now I want to write an emulator for an IBM PC and run MS-DOS on it (I've got the floppy image files).
I have good experience in C++ and C and basic knowledge of assembler and the architecture of a CPU. I also know that there are thousands of emulators out there doing exactly what I want to do, but I'd be doing this for pure joy only.
How much work do I have to expect? (If my goal is to boot DOS and create a text file with it, all emulated)
What CPU should I emulate ? Where can I find documentation on how the machine code is organized and which opcodes mean what, so I can unpack and execute them correctly with my emulator?
Does MS-DOS still run on the newest generations of processors? Would it theoretically be able to natively run on a 64-bit AMD Phenom 2 processor w/ a modern mainboard, HDD, RAM, etc.?
What else, besides emulating the CPU, could be an important factor (in terms of difficulty)? I would only aim for outputting / inputting text to the system via the host system's console, no sound or other more advanced IO etc.
Have you written an emulator yet? What was your first one for? How hard was it? Do you have any special tips for me?
Thanks in advance
To know what is required from your emulator to run DOS, I think the best place would be to turn to the FreeDOS project that has reimplemented a DOS clone. By studying the source, you should be able to come up with a list of requirements.
Concerning the opcode, you can consult X86 Opcode and Instruction Reference, or the Intel documentation. You should also consider using the recent processor capabilities for virtualization.
DOS should still be able to boot a modern PC, but would probably be unable to use most of the hardware (due to lack of drivers, or to inherent limitation of the "OS").
If you want to emulate completely a PC to be able to run MS-DOS (or a clone), I think you'll have to:
decode and interpret opcode
emulate memory controller
emulate BIOS and VGA BIOS
implement required BIOS syscall
Disclaimer: I didn't write an emulator.
Since MSDOS is pure 16 bit code it can not run on a 64 bit processor natively.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
i am very new to assembly programming language. i have a little experience with MASM which works on windows. i want to know how to deal with GUI in Linux.(i have done simple programs in assembly on Linux using gcc) i would like if some one can give me any resources particularly coding samples.
Thanks !!
You'll want:
NASM: A cross platform assembler
GTK+: a C GUI library
Ubuntu: The most popular desktop Linux distribution
An example of GTK in use with NASM on Linux
If you want to go "low level", there is (or used to be) https://en.wikipedia.org/wiki/Direct_Graphics_Access on Linux + XFree86 (now called X.org).
You could map the framebuffer into user-space and draw on it with loads/stores, instead of read/write system calls on sockets (the end result of GTK+ function calls is normally talking to the X server over a socket).
Or there are various libraries that allow more or less direct access to video RAM and video modes when your program is running on a virtual console with no X server (or other display server like Wayland).
https://en.wikipedia.org/wiki/Virtual_console#Interface mentions DirectFB, DRI, SDL and the old SVGALib.
Changing video modes will normally still require a system call, but you can load/store to video RAM. Different libraries presumably have different ways for dealing with vsync / double-buffering / whatever.
This isn't necessarily faster or better: modern graphics cards are much more than dumb framebuffers. They have GPU hardware that can accelerate graphics operations, and storing directly to video RAM doesn't take advantage of it.
But if you really want to play around with direct access to video RAM, those links should be a good starting point for making it happen in user-space on a virtual console under Linux, with hopefully less risk of locking up the whole machine when your program has a bug.
(Be ready to SSH in from another machine and kill your process + chvt, though. And make sure you enable the magic SysRQ keys for killing all processes on the current console, and for "unRaw" keyboard input.
Disclaimer: I have not personally written software that does this, but there are some examples like FBI (framebuffer image viewer). I have recovered the console with ssh and/or SysRQ without rebooting after using buggy software and/or buggy drivers, though.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Programming isn't my main job, though I enjoy it and sometimes get paid for it. For many years now I've been hearing about Linux and my friends have shown to me many *nixes (or *nici?), though I stick with Mac OS.
Do you think there are any parts of the Linux kernel that I could enjoy looking at, that would help me understand what's the whole stuff about? For example, how Linux is different from Darwin?
I've grown up with assembler and DOS, so things like interrupts or low-level C shouldn't be barriers to understanding. But in the end I'm more interested in high-level concepts, like threading or networking stack - I know different operating systems do them differently. And I'm looking for something fun, easy and enjoyable, like late-night reading.
(Note: made a CW, just in case)
Update: I looked for some docs and started reading:
Unreliable Guide To Locking
I would recommend looking at LXR. It makes it easier to follow the flow of the code (you do not have to search for each function that is called — well, you have, but the site does it for you).
Some starting points, for the current version (2.6.30):
start_kernel() — think of it as the kernel equivalent of main(). This function initializes almost all the kernel subsystems; follow it to see in code what you see scrolling on the screen during the boot.
entry_32.S — system calls and interrupts (x86-32 version, which should be nearer what you know; note the use of the AT&T assembly dialect instead of the Intel dialect you might be more used to).
head_32.S — the kernel entry point. This is where the kernel starts after switching to protected mode; in the end, it will call start_kernel().
arch/x86/boot — the real-mode bootstrap code. It starts in assembly (boot/header.S), but quickly jumps into C code (starting at boot/main.c). Does the real-mode initialization (mostly BIOS calls which have to be done before switching to protected mode); it is compiled using a weird GCC trick (.code16gcc), which allows the generation of 32-bit real-mode code.
arch/x86/boot/compressed — if you ever wondered where does the "Decompressing Linux..." message comes from, it is from here.
Myself, I've always found the task scheduling code a bit of a hoot :-/
Methinks you need to get yourself a hobby outside the industry. Or a life :-)
The comments in the kernel can be pretty funny. There's some tips on where to find the best ones on kerneltrap.
arch/sparc/lib/checksum.S- /* Sun, you just can't beat me, you just can't. Stop trying,
arch/sparc/lib/checksum.S: * give up. I'm serious, I am going to kick the living shit
arch/sparc/lib/checksum.S- * out of you, game over, lights out.*/
linux-0.01.tar.gz is Historic Kernel and good for start
it is simple and tiny and better for start reading
(also it have void main(void) Instead of start_kernel() lol :D )
You might want to read or skim a book that describes the Linux Kernel before looking deep into the Linux kernel.
The books that come to mind are:
Understanding the Linux Kernel, Second Edition
Design of the UNIX Operating System
You need to re-define the word 'fun' in your context. :)
That said, the Linux kernel may be too much of a monster to take on. You may want to start with some academic or more primitive kernels to get the hang of what's going on, first. You may also want to consider the Jolix book.
You'd probably get more out of reading a book on OS theory. As far as source code goes: I've got no idea, but you could easily download the Linux kernel source and see if you can find anything that appeals.
This should turn up some interesting code when run in the src directory:
grep -ir "fixme" *
also try with other comical terms, crap, shit, f***, penguin, etc.
It's been recommended by quite a few people that v0.0.1 of linux is the easiest to understand.
Though, if your looking for good kernel source to read, I wouldn't go with linux, it's a beast of a hack(about like saying the GCC sources are "fun") Instead, you may wish to try Minix or one of the BSDs(Darwin is basically a branch of NetBSD iirc) or even one of the many free DOS clones if everything else is a little too scary..
Try reading the code that implements these character devices:
/dev/zero
/dev/null
/dev/full
And maybe the random number generators if you are inclined. The code is straightforward and simpler than all other device drivers since it does not touch any hardware.
Start at drivers/char/mem.*
kernel.h
Some simple tricks we can learn, such as
#define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
...
#define min(x, y) ...
...
#define container_of
For fun I guess you could also see Minix, it isn't exactly linux but Modern Operating systems by tenenbaum is a good read.