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.
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 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.
I am a non CS/IT student, but having knowledge of C, Java, DS and Algorithms. Now-a-days I am focusing on operating system and had gained some of its concepts. But I want some practical knowledge of it. Merely writing algo code in java/c has no fun in doing. I have gone through many articles where they mentioned we can customize source code of Linux-kernel.
I want to start customizing the kernel as I move ahead in the learning of OS concepts and apply the same. It will make two goals achievable 1. I will gain practical idea of the operating system 2. I will have a project.
Problem which I face-
1. From where to get the source code? Which source code should I download? Also the documentation if possible.
https://www.kernel.org/
I went in there but there are so many of them which one will be better?
2. How will I customize the code once I have it?
Please give me suggestions with detail about how I should start this journey (of changing source code to customize Linux).
Moreover I am using Windows 8.
I recommend first reading several books on OSes and on programming. You need a broad CS culture (if possible get a CS degree)
I am a non CS/IT student,
You'll better become one, or else spend years of work to learn all the stuff a CS graduate student has learnt.
First, you need to be very familiar with Linux programming on user side (application programs). So read at least Advanced Linux Programming and study the source code of several programs, including shells (and some kind of servers). Read also carefully syscalls(2). Explore the state of your kernel (e.g. thru proc(5)...). Look into https://kernelnewbies.org/
I also recommend learning several programming languages. You should in particular read SICP, an excellent introduction to programming. Read also some book like programming language pragmatics. Read something about continuation and continuation passing style. Read the Dragon book. Read some Introduction to Algorithms. Read something about computer architecture and instruction set architecture
Merely writing algo code in java/c has no fun in doing.
But the kernel is also written in C (mostly) and full of algorithmic code. What makes you think you'll get more fun in it?
I want to start customizing the kernel as I move ahead in the learning of OS concepts and apply the same.
But why? Why don't you also consider studying and contributing to some user-level code
I would recommend first reading a good book on OSes in general, notably Operating Systems: Three Easy Pieces. Look also on OSdev.
At last, the general advice about kernel programming is don't. A common mistake is to try adding code inside the kernel to solve some issue that can and should be solved in user-land.
How will I customize the code once I have it?
You probably should not customize the kernel, but if you did you'll use familiar tools (a good source code editor like emacs or vim, a compiler and linker on the command line, a build automation tool like make). Patching the kernel is similar to patching some other free software. But testing your kernel is harder (because you'll often reboot).
You'll also find several books explaining the Linux kernel.
If you still want to customize the kernel you should first try to code some kernel module.
Moreover I am using Windows 8.
This is a huge mistake. You first need to be an advanced Linux user. So wipe out Windows from your computer, and install some Linux distribution -I recommend Debian- (and use only Linux, no more Windows). Become familiar with command line.
I seriously recommend to avoid working on the kernel as your first project.
I strongly recommend looking at some existing user-land free software project first (there are thousands of them, notably on github, e.g. choose some package in your distribution, study its source code, work on it, propose the patch to the community). Be able to build from source code a lot of things.
A wise man once said you "must act your way into right thinking, as you cannot think your way into right acting". In your case, you'll need to act as an experienced programmer would act, which means before we write any code, we need to answer some questions.
What do we want to change?
Why do we want to change it?
What are the repercussions of this change (ie what other functions - out of all the 10's of millions of lines of source code - call this function)?
After we've made the change, how are we going to compile it? In other words, there is a defined process for this. What is it?
After we compile our new kernel/module, how are we going to test it?
A good start, in addition to the answer that was just posted, would be to run LFS (Linux from Scratch). Get a successful install of that and use it as a starting point.
Now, since we're experienced programmers, we know that tinkering with a 10M+ line codebase is a recipe for trouble; we need a bit more direction than that. Here's a list of bugs that need to be fixed: https://bugzilla.kernel.org/buglist.cgi?chfield=%5BBug%20creation%5D&chfieldfrom=7d
I, for one, would be glad to see the one called "AUFS hangs on fanotify" go away, as I use AUFS with Docker on a daily basis.
If, down the line, you decide you'd rather hack on something besides the kernel, there are plenty of other options.
From your question it follows that you've already gained some concepts of an operating system. However, if you feel that it's still insufficient, it is OK to spend more time on learning. An operating system (mainly, a kernel) has certain tasks to perform like memory management (or memory protection), multiprogramming, hardware abstraction and so on. Neither of the topics may be neglected - they are all as important. So, if you have some time, you may refer to such useful books as "Modern Operating Systems" by Andrew Tanenbaum. Special books like that will shed much light on all important aspects of a modern OS. Suffice it to say, Linux kernel itself was started by Linus Torvalds because of a strong inspiration by MINIX - an educational project by A. Tanenbaum.
Such a cumbersome project like an OS kernel (BSD, Linux, etc.) contains lots of code. Many people are collaborating to write or enhance whatever parts of the kernel. So, there is a common and inevitable need to use a version control system. So, if you have an intention to submit your code to the kernel in future, you also have to have hands on with version control. Particularly, Linux relies on Git SCM (software configuration management - a synonym for version control).
So, once you have some knowledge of Git, you can install it on your computer and download Linux source code: git clone https://github.com/torvalds/linux.git
Determine your goals at Linux kernel modification. What do you want to achieve? Perhaps, you have a network card which you suspect to miss some features in Linux? Take a look at the other vendors' drivers and make an attempt to fix the driver of interest to include the features. Of course, this will require some knowledge of the HW, and, if the features are HW dependent, you will unlikely succeed to elaborate your code without special knowledge. But, in general, - if you are trying to make an enhancement, it assumes that you are an experienced Linux user yourself. Otherwise, how will you understand that some fixes/enhancements/etc. are required? So, I can't help but agree with the proposal to postpone Windows 8 for a while and start using some Linux distribution (eg. Debian).
If you succeed to determine your goals (eg. if you find a paper describing some desired changes in Linux kernel or if you decide to enhance some device drivers / write your own), you will be able to try it hands on. However, you still might need some helpful books, but, in this case, some Linux-specific ones. Also, writing C code for the kernel itself will require one important detail - you will need to comply with a so called coding standard, otherwise Linux kernel maintainers will not be able to accept your patches.
So, I made an attempt to outline some tips based on your current question. Of course, the job of kernel development has far more broad prerequisites, but these are which are just obvious.
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 9 years ago.
I'm trying to migrate an application from linux to Win and already I'm having a lot of difficulties with heap size, ram and ...
what is it about Ram that most people prefer to work on linux instead of Win?
The only reason I know of is: you have a bug in your original code.
There are two main differences in managing memory:
1) Linear
Under Unix systems, you grow your heap as required and the addresses are therefore allocated linearly, increasing from the end of your data segment up. In most cases that is transparent. However, if you do reinterpret_cast<>() (or C-like casting) between pointers and integers, you may have problems there too (if you went from Linux 32 to Windows 64, for example.)
2) Clear
Windows clear the RAM (set it to all zeroes) in a different way than Linux. That's in most cases what causes grieves as you describe. This also applies to stack data.
In debug mode, also, Windows debug libraries, on purpose, set the RAM to different values (such as 0xCC or 0xFE). This is useful to detect bugs and it could very well be that you have bugs in your Linux version, only it "works" just because.
Also in regard to the stack, because the cl and gcc compilers do it completely differently, the stack is completely different. So the only thing you're seeing is that you have a bug in your original code...
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'm not sure how to ask this question so here goes...
Software sometimes says available on all "*nix" and that means osx and linux, or it may say available on linux and not mac or vice versa. So when I ask what makes them similar/different, I guess I'm asking what are these operating systems made up of and what allows them to be different and similar at the same time. I read somewhere that mac osx is based on bsd and something about debian and kernels and window managers and..... I'm just very confused.
OS X is not Linux. OS X is UNIX.
The lower level system APIs are very similar (identical in many cases) - C, 'nix, POSIX, and so on. A program using these interfaces can be ported easily to the other (consider the of libraries which are compatible on both and require little to no platform specific features).
There are of course differences. The OS X kernel is a microkernel (Darwin), while Linux is monolithic. Divergence beyond core user-land layers happens pretty quickly, particularly wrt the user interfaces.
Linux is not the general variant, Unix is. Linux is a form of Unix, as are the BSD derivatives (including OS X), Solaris, AIX, and a number of others.
What makes a Unix, officially, is compliance with (and, preferably, certification of) the Open Group's Unix specification. Most Unixes also provide functionality (and standard functions) beyond that specification, however, and it's in that area that you most often run into compatibility questions, although questions of device driver availability and other things not directly related to OS interfaces come in to it as well.
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.