I only made a little bit changes to the xv6 kernel to support shared memory. After compiling, I cannot boot it under qemu. It just halts at "booting from the disk...". But I didn't do anything to the bootloader. Can somebody tell me what's wrong,please?
xv6 cannot boot
You should be more specific with what changes were made exactly.
Please include them here.
Related
I'm currently reading a Japanese book on embedded OS/RTOS es except that I am not using the recommended hardware as I already had a seeeduino microcontroller.(atmega328p) The book is about KOZOS "12 steps to making your own embedded OS" by Sakai Hiroaki(It's hiro-something)
I'm stuck at the part where I need to write into the flash ROM of the atmega328p because the author is using a different chip called H8. He uses a software called h8write and uses that in his OS, but I honestly have no idea what is going on at this point, and what the avr replacement for h8write would be. I've looked around to no avail as there is minimal documentation on what h8write does aside from the "it helps you write to flash ROM" that shows up in the book.
This is the first time I'm doing lower layer stuff and it's frankly terrifying...
I'm using ubuntu 14.04 if that helps.
If I understand correctly, the h8write program is supposed to run on your computer and transfer the compiled to the microcontroller. You are using a seeeduino, which is an Arduino compatible board, with Ubuntu. The standard way of programming on this environment is with the arduino software:
install the arduino package (sudo apt-get install aruino)
type the command arduino from a terminal emulator: this brings an IDE where you can type your code
connect the seeeduino to an USB port
click on the button with a right-pointing arrow: this will take care of everything (compiling, linking and uploading to the seeeduino)
Once you are comfortable with this workflow, you can try to get your hands dirty with low-level stuff. The Arduino IDE is built on top of smaller utilities like avr-gcc, avr-libc, avr-as and avrdude. Avrdude is the program used to transfer the compiled program to the Arduino/seeeduino, i.e. write to the flash. You can use these utilities directly, from the command line. This is however complicated by the fact that you will need to pass many command-line arguments, so I recommend you automate the process using a Makefile. Thankfully there is a generic Arduino Makefile available that makes this quite easy:
install the generic Arduino Makefile: sudo apt-get install arduino-mk
read the instructions in the comments at the top (the Makefile is at /usr/share/arduino/Arduino.mk)
write your own project-specific Makefile as per these instructions
type make to compile your program
type make upload to upload to the seeeduino (i.e. write the flash).
This application note tells you how to write the flash memory during program run.
A very good tutorial on how to use the PROGMEM attribute in AVR microcontrollers can be found here
I have an openmp code written in C. I executed the code on Intel MIC on Stampede. I want to profile the code to find the hotspots in the code so that it will be helpful for me to optimize the code further. I tried to use the profiler gprof but I read somewhere that gprof cannot be used on MIC directly. I tried to use perf by going through tutorial. I could go till a certain step after which when the perf annotate step comes and I execute the code, it gives me the error ")" unexpected. So I am not knowing how to proceed to profile my code. Can anybody please help ??
This is the site where I referred to the perf tutorial : sandsoftwaresound.net/perf/perf-tutorial-hot-spots/ .
80% of optimization for the Xeon Phi is the same as for the host (Xeon). Use gprof, printf, compiler options, and the rest of your toolkit and carry your optimization as far as you can executing your code on the host only. After you can do no more, then focus on specific Xeon Phi optimizations.
As you are on Stampede, I assume you are using the Intel compiler. The compiler has a lot of diagnostic capabilities to profile your code and even provide suggestions. I'd provide you with more specific URLs but am on vacation with limited bandwidth.
Though this isn't specific to your question, here are some other suggestions. If you aren't, you'll most likely get a substantial boost using it. Intel compilers are danged good at optimizations, especially on Intel architectures. Also, you should use Intel MKL where possible. All of MKL's routines are optimized for the different IA architectures, and the most relevant to HPC are optimized specifically for MIC.
You have a few options.
The heavyweight approach is to use Intel Vtune. Firstly add -g to your compiler flags.
I use Vtune from the host command line quite a bit, here is the command I use to profile an application on the MIC. (This is executed on the host machine, Vtune on the host uses ssh
to launch the application on the MIC.)
amplxe-cl -collect knc-hotspots -source-search-dir=/mysrc/dir -search-dir=/mybin/dir -- ssh mic0 /home/me/myapp
Assume the app on the MIC is at /home/me/myapp, and the source dir and source search dir on the host. (With Vtune update 15 at least, I need to specify both of these separately in order to get the Vtune GUI to show me symbol info)
Once your app has finished, run the Vtune GUI on the host with amplxe-gui and open your result set.
There are also some simplified open source profiling tools developed by Intel that support the MIC, Speedometer and Overhead, you can find information about them here
Hopefully this is enough info to get you started.
I am looking for Unix V6 kernel source code. Please tell me where from I get it.
I have pdf copy downloaded from http://v6.cuzuco.com/v6.pdf. Which is described in "Commentary on Unix Source- J. Lions".
Thank you.
This is an open course from MIT (http://pdos.csail.mit.edu/6.828/2012).
From this website you can get the source code of xv6 and many useful materials, including a detail document like "Commentary on Unix Source- J. Lions" to help you understand the code of xv6.
In my opinion xv6 is better than unix v6, because xv6 is written in ANSI C and AT&T assembly language, but unix v6 is designed to run on PDP machine.
I'm also learning OS by my self, and I'm looking xv6 and linux0.11 source code.
I hope these words may help you. ^_^
Nowadays you don't require to make a bootloader by hand but require to use uefi firmware (available for download free) this firmware has the required functions which can be called on demand for loading the is onto RAM from Hard Drive .... Partitioning is also managed .It is written in c/c++ ... I have been learning to try to make a is of my own ..I came across it .. It is a good point to start from in modern UEFI enabled motherboards .
I have compiled my freebsd libc source with -g option, so that now I can step in into libc functions.
But I am having trouble stepping into system calls code. I have compiled the freebsd kernel source code with -g. On setting the breakpoint, gdb informs about breakpoint on .S files. On hitting the breakpoint, gdb is unable to step into the syscall source code.
Also, I have tried: gdb$catch syscall open
but this is also not working.
Can you please suggest something?
Thanks.
You appear to have fundamental lack of understanding of how UNIX systems work.
Think about it. Suppose you were able to step into the kernel function that implements a system call, say sys_open. So now you are looking at the kernel source for sys_open in the debugger. The question is: is the kernel running at that point, or is it stopped. Since you will want to do something like next in the debugger, let's assume the kernel is stopped.
So now you press the n key, and what happens?
Normally, the kernel will react to an interrupt raised by the keyboard, figure out which key was pressed, and send that key to the right process (the one that is blocked in read(2) from the terminal that has control of the keyboard).
But your kernel is stopped, so no key press for you.
Conclusion: debugging the kernel via debugger that is running on that same machine is impossible.
In fact, when people debug the kernel, they usually do it by running debugger on another machine (this is called remote debugging).
If you really want to step into kernel, the easiest way to do that is with UML.
After you've played with UML and understand how the userspace/kernel interface works and interacts, you can try kgdb, though the setup is usually a bit more complicated. You don't actually have to have a separate machine for this, you could use VMWare or VirtualPC, or VirtualBox.
As Employed Russian already stated, gdb being in userland cannot inspect anything running in the kernel.
However, nothing prevents to implement a debugger in the kernel itself. In such case, it is possible to set breakpoints and run kernel code step by step from a local debugging session (console). With FreeBSD, such a debugger is available as ddb.
Some limitations would be the lack of connection between your gdb and ddb sessions and I'm unsure source level debugging (-g) is available for kernel code under FreeBSD/ddb.
An alternate and much less intrusive way to 'debug' the kernel from userland would be to use dtrace.
I want to use #include statements in my OpenCL kernels but it appears Apple's OpenCL compiler caches kernels, so if you change the contents of an included file but not the file doing the including, the program will not change between runs.
I've coded up an example which illustrates this:
http://github.com/enjalot/adventures_in_opencl/tree/master/experiments/inc/
If you compile and run, it should work fine. Then if you comment out the struct definition in inc.cl it will still run just fine (or change anything in lvl2.cl)
Using the NVIDIA compiler on Ubuntu you get the expected behavior.
So is there someway to force clBuildProgram to recompile the kernel?
I got an answer from the perfoptimization-dev#apple.com mailing list
sudo killall cvmsServ
Doesn't seem very graceful, but oh well