So yet again I had to struggle with the broadcom propriety driver (hybrid-portsrc) for my Dell 1345 wireless card (Broadcom BCM4312). Earlier, there were issues with the legacy broadcom drivers which just won’t work and won’t let the new ones work. This time, the issue was different, it just won’t work on the 2.6.34 kernel. It used to say “linux/autoconf.h” is missing. After reinstalling autoconf, make utilities, still no solution.

Finally I searched a lot, then found out that the new 2.6.34 kernel has changed the location of some of the header files. So what I had to do was to change #include to #include inside the “src/include/linuxver.h” file of the module source. And tada, it compiled perfectly. Just copied wl.ko to /lib/modules//kernel/net/wireless directory and then depmod -A . Next thing to do was to remove the older drivers from the memory: modprobe -r b43 && modprobe -r ssb and blacklist them (or better, just delete them :p ) by editing “/etc/modprobe.d/50-blacklist.conf” and adding these two lines there: blacklist ssb and blacklist b43 . Did a modprobe wl and saw the wifi LED turned on. :)

Update: Broadcom has released the patch for kernels above 2.6.33 at http://www.broadcom.com/support/802.11/linux_sta.php.

DISCLAIMER: This article is written by a wannabe kernel hacker, so don’t totally rely on this information and do your own research.

So, I have been trying to get my lappy boot with 1280×800 resolution but it will just boot with 1024×768 resolution. Now, when booting the kernel, I used to pass this parameter to kernel “VGA=0×317″ to boot with 1024x768x16 resolution. I tried to find out about more resolutions supported by putting garbage values with VGA parameter, so that the kernel stops and asks me for the resolution. It gives me an option to scan the video modes available, but it just wont show 1280×800 there. And of course, my laptop supports 1280×800 res, it works in X environment.

So, i dug deep and found out that the file  /usr/src/linux-2.6.25.20-0.4/arch/x86/boot/video.c is responsible for setting the video mode and showing that video mode menu. The 2 lines here decide the value of the video mode and then print the menu with mode id, resolution, depth etc.

1. u16 mode_id = mi->mode ? mi->mode :
(mi->y << 8)+mi->x;
2. printf(“%c %03X %4dx%-7s %-6s”,
ch, mode_id, mi->x, resbuf, card->card_name);

Here, the value in mi->y is shifted by 8 bits and added to mi->x (the horizontal lines). Then the hex value (first 3 digits) of mode_id is printed.  So, for 1280×800 resolution, the value comes out to be 0×325. May be, this is the calculation of VGA modes and not VESA modes, as for my 1024x768x16 resolution, mode_id supposedly is 0×317, which i’m not able to produce with this code. Theres another file in the same directory as this one “video-vesa.c”. Perhaps, this file has got the code which i’m looking for. I’m still hunting, hopefully I’ll catch a few deer and rabbits soon.

Though I haven’t tried the new mode_id as yet, hope it comes out to be correct, if it doesnt, then may be my BIOS support the resolution at start-up?

Alright, this comes as an inspiration from Shanky’s “what i’ve been doing” posts…

Lets start with my last post (technical), which was published in January this year. The things I have been doing since then (some tried n left)…this one focuses on the my B.Tech project. Will post about others too.

The Self Modifying Kernel

I was working on my kernel, till the end of this May. Till the final year project presentations, I was able to implement the GDT, Interrupts and a little bit of self-modification. The self-modification part should have been researched very well and needed almost all the time, but on the contrary, it got very little time but there was quite a lot of research into it. The reason being, that most of the time was spent in developing the base of the kernel. Lack of a good book or a step-by-step tutorial for developing a kernel is a necessity. Though, you’ll find many books on kernel designs esp. Linux kernel and UNIX but these things are in theory. Everyone knows the theory, but in actually trying to build it from scratch requires some extensive research and some contacts with people who have actually done it before.

In my case, initially I had none apart from my project guide’s great support and the freedom she gave me for the project. Eventually we found some things, came up with theories, tried to implement them but in vain. Many theories were proposed and scrapped. There was a new theory and a new concept every week which would look so very good and achievable. But in the end, as I said, was down to preparing the base of the kernel, which we realised kinda late. Those theories are still there and looking for a guy/gal who can get something out of them. But, we worked hard and in the end, thats what matters and we learnt a lot from it. Like I said, the self-modifying feature of the kernel got very less time, we were able to implement the base for self-traversing data structures for processes. So, it goes like this…one process is itself responsible for saving/restoring it’s own context and then shifting to the next process. This eliminates the need for a context switcher, thereby decreasing the calling time for it and other sub-routines. This is done by code injection at runtime. Though, there is still some fault in it, the processor triple-faults at it…I’ll look into it, when I get time.

Well, after the project was over (at least as college project), we were down to few points…

• We should know the full theory beforehand! That includes microprocessors in detail, all Operating System concepts, prior experience in programming with assembly language and C and familiarity with the tools we’d be using.
• We need a finalised kernel design before proceeding.
• Everything need not be from scratch . (though I like it that way)
• We should be focusing on a single module/part of the kernel at one time rather than confusing it all together.
• Follow one approach, which needs to be decided after the design.
• Try and focus more on the unique feature which makes your kernel different from others.
• Read the architecture manuals carefully again n again.
• Maintain discussion logs and don’t forget to discuss each and every new idea that comes to your mind, even a very small one..it might become BIG in future.
• Discuss and Implement (as mam says it)
• Discuss and Implement (as mam says it)
• Discuss and Implement (as mam says it)
• Then after you have implemented, test it according to your needs.

As my philosophy goes, learn things from a book/person who was responsible for that thing. For example, learning C from Yashwant Kanitkar or Dietel n Dietel is great, they teach you everything with examples and great books for beginners (I learnt C from Dietel n Dietel). But, reading Kerninghan & Ritchie is better. These guys were the makers of C language, developers of UNIX. So they know much better than anyone else in C. Likewise, its always better to read microprocessor (architecture) manuals from the makers of it.  Not going through Intel manuals  from the beginning was a big mistake.

The kernel still has numerous things that need to be done beginning from the IDT to proper PCBs, scheduling, refining current self-modification and thinking about the new runtime modifications etc. Though I’m thinking of making my own boot-loader for it, giving it a totally “from-scratch” look ( yeah, i’m diverting from my point #3, but I like it that ways). Theres a lot of work that needs to be done… Students from the university will be continuing the project under the guidance of Ms. Shipra Sharma this year also, I hope they’ll do a good job and treat it like their own child.. (like i did) :p  Till then, I’m still thinking if I should make it open source in this nascent stage? And I need a subversion server set up somewhere for collaborative development from colg and my home…

Hello Everyone,

I am starting this kernel development series for beginnners.  Will teach you how to go about developing a kernel from sratch, even if you dont know anything.

DISCLAIMER: This stuff is geeky, dont shout on me for not understanding some things, though i will try my best to explain in detail. Any comments and suggestions are invited.

Before making a kernel, we should have a kernel design. For example, take a look at the UNIX kernel:

Now, the boxes you see here are kernel modules. Every kernel has these, and they are responsible for handling or interacting with the system hardware. The arrangement of these modules (boxes) is known as kernel design. The way these modules interact with each other and the hardware accounts for the design.

But well, if you dont have the time or you cant think of any kernel design, GNU and the open source source community has provided you with many kernels with open source code. You may follow any design you like, even UNIX or Linux. You can find GNU example multiboot kernel here. A multiboot kernel is the one, which can be booted by a multiboot boot loader. A multiboot boot loader is the one which can load more than one operating system. Now this kernel is a very much working kernel which can be loaded by the GRUB boot loader. So, we will use GRUB to load this kernel to our system. Oops, we cannot use our own system to do this. You dont want to risk your system hardware, data, BIOS and other things by making it as a guniea pig for your testing and fooling around with the kernel. For this, we will use BOCHS, an x86 emulator. This emulator will run on your operating system as an application but will act as an x86 computer itself. So, we can use it as our testing platform without risking anything.

So lets compile the kernel code you just downloaded. Compilation is easy, we just need gcc, as and ld for that. GCC is pre-installed on every linux system by default, but if you cannot find as and ld on your system, you can download them from here. Compilation is easy but we need to provide some flags to gcc. For ease of use, we use linux makefiles. I am pasting the code of the simplest makefile needed to compile this kernel. Save it as “makefile” in the same directory as your code. Open terminal and type “make”.

makefile:

AS = as
LD = ld
CC = gcc
CFLAGS = -nostdlib -fno-builtin -fno-stack-protector -m32 -o kernel
LDFLAGS = #–verbose
ASFLAGS =

runkernel:
$(CC) $(CFLAGS) kernel.c boot.S

You can see the compiler flags: nostdlib; fno-builtin, we are using these flags to tell the compiler not to use the standard library while compiling. These are the few points that you need to keep in mind…that we cannot use the standard library functions like printf() etc. in our kernel, as these functions are OS dependent. Though there are many independent functions like memcpy() and sprintf() which we can use. You can find many more…google it! After executing “make” command, you will get an executable “kernel” in your folder. This is our KERNEL. Now we need to put it in some place from where we can boot it. For this, read further…

Next step is that you should know how to make virtual hard disks to use with BOCHS, because you are not using your own hard disk for this purpose as I explained above.  For making virtual hard disks on linux/unix, refer: Virtual Disks Using Loopback. And there is an interesting utility provided, when you installed BOCHS, i.e. ‘bximage’. This utility is specially designed for making virtual hard disk images. In this, you can set the number of heads, cylinders and sectors/track of the image and it’s size also. We will first make a floppy image, through which we will boot our system. After this, we will make a hard disk image also using ‘bximage’ only, in which we will put our kernel. bximage is very easy to use, just try it yourself. After you have set up your virtual disks, we now need to make the floppy image bootable. As we will be using GRUB as our boot loader, we just need to load it into our floppy disk. To install grub, do the following at shell:

# dd if=/usr/lib/grub/stage1 of=floppy_image_path bs=512 count=1

# dd if=/usr/lib/grub/stage2 of=floppy_image_path bs=512 seek=1

We have loaded GRUB into our floppy. Now, we need to make our hard disk usable by formatting it with some file system. So open the terminal and type:

# mke2fs hd_image_path

Mount the image using loopback and copy those GRUB image files (stage1 and stage2) into it. Note that, you have to copy them in /boot/grub directory of the hard disk image, otherwise GRUB wont find them. And copy the kernel image that you got after the ‘make’ command into the boot directory of the hdd image. Do umount the hdd image before proceeding.

Now, open BOCHS by typing in terminal. Edit the disk options and put the names of your images in the floppy and hard disk slots. Begin the simulation and you should now see the GRUB prompt. That means our floppy is successful in booting GRUB. Check the geometry of your hard disk image by ‘geometry (hd0)’. Note the end sector of the image. Make a primary partition on the hard disk image by:

grub> partnew (hd0,0) 0×83 0 (end_sector-1)

Here, (hd0,0) is the first partition of your first hard disk, 0×83 is the partition type (linux here) and 0 is the first sector of your partition you want to make, followed by the last sector. Now, we will set up our hard disk image for boot by installing grub onto it, so that we dont have to use the floppy next time…

grub> root (hd0,0)

grub> setup (hd0)
Now we will load our kernel and boot it…

grub> kernel /boot/kernel

grub> boot

TADA!!!

Your kernel just booted…Now play with it’s source code, study it, make your own functions etc etc. Watch out for the next post in the series soon..(hopefully) :p

We had a great time in Foss.in , here are some pic taken by Apple iPhone +Motorola E6 { IMHO , both these phones need flash }