(Created page with "With recent refinements of Flash and Java/AJAX, webcam chat systems may be handled, cross-platform in browsers. Like language barriers and cultural barriers, system platform b...")
 
(Added kernel testing information)
Line 1: Line 1:
−
With recent refinements of Flash and Java/AJAX, webcam chat systems may be handled, cross-platform in browsers. Like language barriers and cultural barriers, system platform barriers are starting out disappear quickly.
+
== Compiling the BeagleBone Black Kernel ==
  
−
Random video chat systems were the first apparition of the new form of online video chat, and were for the greater degree a toy. They did however provide some useful variety-rich communication and interaction environment using a high a higher level safety due to distance.
 
  
−
However, now more direct, predetermined group video chat systems have become popular. These free webcam chat sites are springing up like dandelions and therefore are becoming quite popular. Where there once had being complicated and frequently unreliable conference calls and video chat sessions create with programs committed to it, now it's much easier. These clients often never worked, or had issues between platforms, ISPs or any variety of other variables.
+
== Testing ==
  
−
The simplicity of that is helping to make the technology considerably more practical. As video compression math gets increasingly better, this trend will continue. But, have you ever wondered how fraxel treatments works, or why it turned out difficult to produce it work the way it can now until very recently?
+
=== TFTP Server ===
  
−
It's actually not that complicated. [http://www.meewii.com video chat] systems actually virtually work the same way as old streaming video which public video sites use to the day. A connection is established, along with the video data is shipped in items of data called "packets" in a finite amount. Every a lot of seconds, a particular amount of video is within the memory, known as a "buffer", and played for the screen.
+
Rather than flashing your newly created kernel to find out it doesn't work or it is not quite configured correctly, a better way to load the kernel into RAM and boot it from there. u-boot allows kernel images to be loaded via TFTP.
  
−
With free video chat services on web pages, there are simply a couple of these. One ones is capturing your video stream and sending it on the other end in the conversation. At the identical time, there is another stream coming right to the video area on your end. So really, it's just two live streams between exclusive machines.
+
To speed up development, I create an 'export' directory. A TFTP server is then configured to use this directory as the TFTP root.
  
−
But, consider the character of video. An image over cable internet takes a couple of seconds to receive and render. Double that for sending it to a new person for and view. Now, with webcam chat, you've video, that is many, many images and sound on the same time. This can be a heavy thing. Web browsers utilized to not contain the capacity to handle this. At one time, even bandwidth restrictions were present.
+
From the export directory, add symbolic links to the kernel images. This way, you can recompile the kernel and the new image is instantly available without having to move it.  
  
−
All this in mind, it isn't surprising that while the video phone concept continues to be an extended time predicted and awaited, its current incarnation wasn't really possible until near the final in the past decade. It will likely be very interesting to find out what continued improvement of bandwidth computing power and browser capacity is prone to make this able to do inside the future. Only time will tell, of course.
+
<PRE>
 +
ln -s /path to linux/arch/arm/boot/uImage-dtb.am335x-boneblack uImage-BBB-3.8.12
 +
</PRE>
 +
 
 +
=== u-boot tftpboot ===
 +
 
 +
To test your kernel, bring up a serial console to the GuruPlug. First we will need to configure the IP addresses. The ipaddr variable contains the IP address for the GuruPlug, while the serverip variable is the address of the TFTP server containing the kernel image.
 +
 
 +
<PRE>
 +
setenv ipaddr 192.168.0.250
 +
setenv serverip 192.168.0.251
 +
</PRE>
 +
 
 +
These variables can be saved to non-volatile memory to speed up development.
 +
 
 +
Next load the image into memory at 0x80200000:
 +
<PRE>
 +
tftpboot 0x80200000 uImage-BBB-3.8.12
 +
</PRE>
 +
 
 +
Let's use the existing root filesystem, and send kernel messages to ttyO0:
 +
 
 +
<PRE>
 +
setenv bootargs console=ttyO0,115200n8 quiet root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait
 +
</PRE>
 +
 
 +
And boot from the memory location:
 +
<PRE>
 +
bootm 0x80200000
 +
</PRE>
 +
 
 +
The example shown is to use the filesystem already in place (i.e. ext4 on mmcblk0p2). The preferred option is to export a root NFS filesystem. This has the added advantage as you can compile userland binaries on your development box, install them to the NFS export and have instant access to them on your target system.

Revision as of 11:50, 18 May 2013

Compiling the BeagleBone Black Kernel

Testing

TFTP Server

Rather than flashing your newly created kernel to find out it doesn't work or it is not quite configured correctly, a better way to load the kernel into RAM and boot it from there. u-boot allows kernel images to be loaded via TFTP.

To speed up development, I create an 'export' directory. A TFTP server is then configured to use this directory as the TFTP root.

From the export directory, add symbolic links to the kernel images. This way, you can recompile the kernel and the new image is instantly available without having to move it. 

ln -s /path to linux/arch/arm/boot/uImage-dtb.am335x-boneblack uImage-BBB-3.8.12

u-boot tftpboot

To test your kernel, bring up a serial console to the GuruPlug. First we will need to configure the IP addresses. The ipaddr variable contains the IP address for the GuruPlug, while the serverip variable is the address of the TFTP server containing the kernel image. 

setenv ipaddr 192.168.0.250
setenv serverip 192.168.0.251

These variables can be saved to non-volatile memory to speed up development.

Next load the image into memory at 0x80200000: 

tftpboot 0x80200000 uImage-BBB-3.8.12

Let's use the existing root filesystem, and send kernel messages to ttyO0: 

setenv bootargs console=ttyO0,115200n8 quiet root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait

And boot from the memory location: 

bootm 0x80200000

The example shown is to use the filesystem already in place (i.e. ext4 on mmcblk0p2). The preferred option is to export a root NFS filesystem. This has the added advantage as you can compile userland binaries on your development box, install them to the NFS export and have instant access to them on your target system.

Retrieved from "http://wiki.beyondlogic.org/index.php?title=BeagleBoneBlack_Building_Kernel&oldid=170"