Parvi - Open source software and patches - New pages [en]

Llfilter

2011-08-25T19:40:01Z

Jeffw: Created page with "Category:Projects __NOTOC__ ==Description== llfilter is a simple application designed to introduce latency and loss to a pair of linked TUN or TAP devices. The reasoning is ..."

[[Category:Projects]]
__NOTOC__
==Description==
llfilter is a simple application designed to introduce latency and loss to a pair of linked TUN or TAP devices. The reasoning is simple: routers in live networks are not 0ms apart (typically) and sometimes there is loss. So when simulating a network it makes sense to introduce these issues.
ly.

==Information==
All source and releases are available on [http://sf.net/projects/llfilter SourceForge].

RAQ Console FAQ

2011-08-25T19:29:40Z

Jeffw: Created page with "Category:Cobalt_FAQs ===How do I enable/disable the serial console?=== The console state can be changed via software, with the "cmos"' tool or with a special button held at s..."

[[Category:Cobalt_FAQs]]
===How do I enable/disable the serial console?===
The console state can be changed via software, with the "cmos"' tool or with a special button held at startup. To see the state of the console setting with the "cmos" tool:

# cmos -c console

To change the console setting:

# cmos -c console [on|off]

You must reboot for the change to take full effect.

===What if my system doesn't have the "cmos" command or doesn't have an OS currently?===
You can also change the console setting by holding a special button while the system powers on. For 3000 series systems, the special button is the 'Password Reset' button (the little recessed button). For 5000 series systems, the special button is the left arrow these systems do not have a 'Password Reset' button). Hold the button down, then power on the system. Keep the button pressed until you see the message "console ON" or "console OFF" appear. This process is a toggle. If you do it again, it will change the setting back.

===What serial console settings should I use?===
The serial console is set to 115200 bits per second, 8 data bits, no stop bit, 1 parity bit. These settings are hard coded.

RAQ Boot Menu FAQ

2011-08-25T19:29:07Z

Jeffw: Created page with "Category:Cobalt_FAQs ===How do I get to the LCD boot menu?=== Hold down the 'S' button while powering the system on. You will eventually be presented with a menu. Use the '..."

[[Category:Cobalt_FAQs]]
===How do I get to the LCD boot menu?===
Hold down the 'S' button while powering the system on. You will eventually be presented with a menu. Use the 'S' button or the up/down or left/right buttons to navigate the menu. Use the 'E' button to select options or sub-menus.

===What boot and root options do I have?===
That depends on your flash ROM version. The flash ROM stores the desired boot device in CMOS, but may not use it, depending on the boot option selected.

The 2.3.x flash ROMs can boot from:
* Disk: the kernel image is read from the boot device's / or /boot. The boot device is also the root device.
* ROM: the kernel image is read from flash ROM, but mounts the boot device as the root filesystem.
* Net: the kernel image is read from flash ROM, but mounts an NFS share as the root filesystem.

The 2.9.x and 2.10.x flash ROMs can boot from:
* Disk, ROM, and Net, as in 2.3.x
* Net/Net: the kernel image is read from an NFS share, which is also mounted as the root filesystem.
* Settings: the kernel is read from the specified kernel source. The specified filesystem source is mounted as the root filesystem. For example, it is possible to load a kernel from disk, but mount an NFS share as the root filesystem.

===How do I change the boot/root device?===
Either use the 'cmos' tool or the LCD boot menu. To use the 'cmos' tool:

# cmos -c bootdev [hda1|md1]

To use the LCD boot menu, navigate to the "Config boot disk" option, then select the device you want. If the device you want is not listed, you will have to use the serial console ROM interface, or the 'cmos' tool.

===How do I change the default boot method?===
Either use the 'cmos' tool or the LCD boot menu. To use the 'cmos' tool:

# cmos -c defboot [d|r|n]

To use the LCD boot menu, navigate to the "Configure boot" option, then select the method you want.

===Can I use ext3 on my Cobalt?===
Yes, but you need flash ROMs from the 2.10.x series.

RAQ Boot FAQ

2011-08-25T19:28:10Z

Jeffw: Created page with "Category:Cobalt_FAQs ===My Cobalt hangs at "Partition check:". Why is this?=== The only known cause of this is an alignment of couple things. Firstly, you put LBA48 capable..."

[[Category:Cobalt_FAQs]]
===My Cobalt hangs at "Partition check:". Why is this?===
The only known cause of this is an alignment of couple things. Firstly, you put LBA48 capable disks into your Cobalt (e.g. ATA133). Secondly, you are trying to boot a 2.4.19 kernel. The 2.4.19 kernel was the first kernel to introduce LBA48 support. However, it did not handle the case of an LBA48 disk on an LBA24 controller (such as in Cobalts) very well. The result is that the kernel is trying to send LBA48 messages to the disk, but not getting any reply, and hanging when it tries to read the disk. You can either use LBA24 (e.g. ATA100) disks, or you can revert to a kernel before 2.4.19, or you can get a kernel newer than 2.4.19, if one is available.

===My Cobalt fails to find init and the root filesystem, what gives?===
One of two things is happening here. First, you may have forgotten to compile in support for your root filesystem type. Sounds stupid, but many people do it. Second, your kernel may not know where your root filesystem is; there are two possible solutions to this...

The first solution is to go in to the ROM menu at boot time by pressing the spacebar from a serial console when prompted. You then enter "boot" and press enter. To set the root device, type the following followed by pressing enter, "set_root_dev hda4" (replacing hda4 with your root device of course). Then you need only reboot the Cobalt.

In the case where the above fails to solve the problem you'll need to pull the disk out and put in a computer, mount the partition containing your kernel image, and uncompress the image. Then, run the following command:

# rdev vmlinux /dev/hda4

Be sure to replace hda4 with your own root partition. Recompress the kernel image and you should be good to go.

===I installed (some distribution) on my Cobalt, but it hangs when starting 'init'!===
It could be that you've installed an i686 libc (or more) on a 3000 series Cobalt. The 3000 series systems need i386 binaries.

===When my Cobalt boots I get spammed with syntax errors for `setfont`, what gives?===
Not sure, but /etc/init.d/consolefont does not need to be loaded. To disable it use the following command:

# rc-update del consolefont boot

===During boot time when loading keymaps I see "Couldnt get a file descriptor referring to the console", ideas?===
Once again, a serial console based system has no need for keymaps, disable them by doing:

# rc-update del keymaps boot

RAQ Hardware FAQ

2011-08-25T19:27:28Z

Jeffw: Created page with "Category:Cobalt_FAQs ===Does this FAQ cover MIPS hardware?=== No, this document just x86 compatible hardware. That is: * RaQ 3 * RaQ 4 * Qube 3 * RaQ XTR * RaQ 550 ===What ..."

[[Category:Cobalt_FAQs]]
===Does this FAQ cover MIPS hardware?===
No, this document just x86 compatible hardware. That is:
* RaQ 3
* RaQ 4
* Qube 3
* RaQ XTR
* RaQ 550

===What hardware is in my Cobalt?===
Cobalt hardware is roughly broken into three generations: 2000 series (MIPS based), 3000 series or GEN_III (K6 based), and 5000 series or GEN_V (Pentium III based). 2000 series systems are beyond the scope of this document. 3000 series systems are: RaQ 3, RaQ 4, Qube 3. 5000 series systems are: RaQ XTR and RaQ 550.

* RaQ 3 and RaQ4 (3000 series):
** AMD K6-2 processor (300 or 450 MHz)
** ALi M1541/1533 chipset
** 2 PC100 DIMM slots
** optional NCR 53c875 SCSI
** 1 optional 32 bit PCI slot
** 1 or 2 Intel 82559ER 10/100 ethernet controllers
** 1 or 2 ATA33 disks
** 1 USB 1.1 port
** 2 RS232 serial ports

* Qube 3 (3000 series):
** AMD K6-2 processor (300 or 450 MHz)
** ALi M1541/1533 chipset
** 2 PC100 DIMM slots
** optional NCR 53c875 SCSI
** 1 32 bit PCI slot
** 2 National Semiconductor DP83815 10/100 ethernet controllers
** 1 or 2 ATA33 disks
** 1 USB 1.1 port
** 1 RS232 serial port

* RaQ XTR (5000 series):
** Intel Pentium III (Coppermine only) processor
** 1 extra CPU socket with terminator
** ServerWorks LE chipset with OSB4 south bridge
** 4 PC133 DIMM slots (registered ECC DIMMs required)
** 1 32/64 bit PCI slot
** 2 National Semiconductor DP83815 10/100 ethernet controllers
** 2 HighPoint HPT370 ATA100 IDE controllers
** 1-4 ATA100 disks
** 1 USB 1.1 port
** 2 RS232 serial ports

* RaQ 550 (5000 series):
** Intel Pentium III (Coppermine or Tualatin) processor
** ServerWorks LE chipset with CSB5 south bridge
** 2 PC133 DIMM slots (registered ECC DIMMs required)
** 1 32/64 bit PCI slot
** 2 National Semiconductor DP83815 10/100 ethernet controllers
** 1 or 2 ATA100 disks

===Can I put a second CPU in my RaQ XTR?===
Not reliably. There are issues with the chipset and motherboard that may cause the system to lockup, crash, or corrupt data. Newer flash ROM versions should support SMP, if you decide to try anyway.

===How do I restore the CMOS?===
You should never need to do this. Restoring the CMOS will return the system to it's unconfigured state. It will lose it's serial number as well as the current boot configuration. For some systems, this means it will attempt to boot from the network. If you still want to do this, power the system off, hold down the 'E' button, and power the system back on. You will eventually see a message that says "CMOS restored".

===What size disks can I put in my Cobalt?===
All Cobalt systems used LBA24 disk controllers. This means that the largest disks you can put into a Cobalt are approximately 137 GB. Even if you put LBA48 capable disks into your system, it will not work. In fact, putting LBA48 disks on an LBA24 controller may cause some kernel version not to boot at all (see 'My Cobalt hangs at "Partition check:"').

Kernel Build FAQ

2011-08-25T19:26:37Z

Jeffw: Created page with "Category:Cobalt_FAQs ===Can I run a 2.4.x kernel on my Cobalt?=== Yes! RaQ 550 systems ship with a 2.4.x kernel already, and need no special preparations. All the other sys..."

[[Category:Cobalt_FAQs]]
===Can I run a 2.4.x kernel on my Cobalt?===
Yes! RaQ 550 systems ship with a 2.4.x kernel already, and need no special preparations. All the other systems ship with a 2.2.x kernel, and need their ROMs updated to ready them for a 2.4.x kernel.

===Can I run a 2.6.x kernel on my Cobalt?===
Yes, with a little work you can. After updating your ROM you should have no problems booting a 2.6.x kernel.

===How do I patch my kernel with your patch?===
Provided the patch is in the your kernel source directory and you are too, you'd do:

# patch -p1 < [patch]

===Do I have to patch my kernel?===
Straight up? No'''*'''. If you do though, you get the LCD/front panel drivers, access to extra facilities offered by Cobalt hardware, including, but not limited to:
* System sensors
* Memory configuration
* System serial number (useless, I know)
* System type
* ACPI support

'''*''' - In kernel version 2.6.12, the eepro100 driver is broken. I've fallen back to its successor, the e100 driver. However, the e100 driver is extra strict regarding the controller ROM checksum. A kernel patch is required to remove this "behavior".

===What happens if hunks fail?===
You can try to add some fuzz to "patch", help it find what it's looking for. This is done by adding "-f 5" after "-p1". If it still fails, send me an email with the exact kernel version you're try to compile, the version of my patch you're using, and a list of any other patches you previously applied to the kernel source.

===What should I include in my kernel config?===
The answer varies for each Cobalt, and the answers are long. So, I'll be answering this in a seperate document which I've yet to write.

===I'm lazy, ok, not too lazy... I've configured my kernel, now what?===
Just do the following:

# make vmlinux modules modules_install
# strip vmlinux
# bzip2 vmlinux
# cp vmlinux.bz2 /boot/

All done.

===I'm compiling a kernel, but the build complains about "as86: Command not found"!===
Don't build a bzImage. Cobalt's boot from a gzipped or bzip2ed vmlinux.

===I've built my kernel, how should I compress it?===
bzip2 tends to offer a slightly better compression when it comes to kernels. The following command works:

# bzip2 vmlinux

===Is there any size restriction on my kernel?===
Yes, but it's workable. Your kernel can be no larger than 1800KB compressed.

===How can I get my kernel down to size?===
Start by lopping out support for devices that are not in the system. You might want to choose a specific I/O scheduler (I prefer the deadline scheduler). Build modules where possible. Every little bit helps.

LCD FAQ

2011-08-25T19:25:35Z

Jeffw: Created page with "Category:Cobalt_FAQs ===I get the message "LCD is not present". What am I missing?=== First thing's first, did you compile LCD support in with the kernel? If you did it as ..."

[[Category:Cobalt_FAQs]]
===I get the message "LCD is not present". What am I missing?===
First thing's first, did you compile LCD support in with the kernel? If you did it as a module, is the module loaded? Next, does /dev/lcd exist? If not, you'll have to create it by running:

# mknod /dev/lcd c 10 63

ROM FAQ

2011-08-25T19:25:07Z

Jeffw: Created page with "Category:Cobalt_FAQs ===How do I tell what version of the flash ROM do I have installed?=== If your system is alive, you can run the 'cmos' tool to check: # cmos -c romrev ..."

[[Category:Cobalt_FAQs]]
===How do I tell what version of the flash ROM do I have installed?===
If your system is alive, you can run the 'cmos' tool to check:

# cmos -c romrev

If your system is not alive, you'll need to attach a serial console, and check as the system boots.

===How do I upgrade the flash ROM?===
See the HowTo for instructions.

===Where can I get new flash ROM versions?===
The Cobalt ROM source was released under the GPL, and has seen some development outside of Sun/Cobalt. Check http://sourceforge.net/projects/cobalt-rom for the latest.

===Where can I get source code for the Cobalt ROM?===
http://sourceforge.net/projects/cobalt-rom

===What version of the flash ROM should I use?===
Flashing the ROM is risky business, and if it fails, the system is dead until you solder in a new flashrom.

If you want to upgrade beyond your current ROM series (the most likely case being that you want to boot a newer kernel), you should upgrade to the latest 2.10.x ROM. 2.10.x adds a few extra things over 2.9.x, like ext3 support. These should also work in all systems.

RAQ Gentoo Install

2011-08-25T19:24:01Z

Jeffw: moved RAQ Gentoo Install to Gentoo Install

[[Category:Cobalt_Guides]]
==Introduction==
Back when I first had thoughts of running Gentoo on a Cobalt RaQ 3i that was given to me, my only limit was the kernel. I was limited by the original ROM which knew not how to deal with 2.4.x and 2.6.x kernels. So, much thanks to the Cobalt ROM team over on SourceForge for pushing ahead after Sun pulled out.

Everyone said it could not be done, that the 2.6.x kernels would never run on a Cobalt. Well, I'm persistant and have time to burn. And I burned it; 8 hours of it. For 8 hours I dealt with compiler errors, kernel panics, and booting kernels over a serial console. In the end I was left with a working 2.6.8.9 linux kernel booting Gentoo on a Cobalt RaQ 3i. Here's to the ones who said it could not happen, let them gawk at where this "project" has gone.

This is a culmination of all the information needed to successfully install and boot Gentoo linux on a Sun Cobalt RaQ 3, 4, or some subversion thereof.

===Foreward===
Currently, the only method to install Gentoo to a Cobalt is to pull the Cobalt's drive(s) and put it/them in a secondary build system. While this is not ideal from a physical work aspect, it does typically speed up the build process. Work is under way to contruct an NFS netbootable LiveCD to use as a platform for a non-invasive installer.

===Assumptions===
This guide assumes you are familiar with the Gentoo Handbook covering general installation. It also assumes you have a second computer you can use to build the operating system on. Furthermore it assumes you will have no problem rebooting this second computer, unless you have a USB to IDE adapter.

==Pre-install Tasks==
Before you begin installing the operating system, you need to update your ROM image. I've written a guide on how to do this. Take heed the warnings, I'm serious.

===Pull the drive===
Once you've successfully updated the ROM image, you can pull the primary drive from the Cobalt and place it in your build system. I know this is inconvenient, but for now, it's what you need to do. Now go get that screw driver and have some fun.

===Boot the build system===
It's now time to boot up your build system using the Gentoo LiveCD, available from your local mirror service. You'll want to get the system on the internet, helps a bit when trying to download stuff.

==Installation==
===Disk Partitioning===
Partitioning of a disk for a Cobalt requires some thought and a little knowledge about how you can break things in the future. The biggest issue is updating your kernel; do it wrong, the system won't boot, and you either get to pull the drive again or send a kernel via the serial console (not fun). So, it would be prudent to have two boot partitions; one to have a known bootable kernel on, and another to have your new kernel reside on. Call it a backup, or a life saver... We'll call it a good idea.

Your boot partitions should be about 32MB each (for good measure), swap should be about two times the size of your RAM (less is fine), the rest is up to you (I would make it / since it's never fun to deal with extended partitions). If you have a second disk in your Cobalt, you can always make that /home, keep user data seperated. Or if you feel like playing with software RAID, go for it, but I'm not going to cover that here.

My RaQ 3i has two 30GB drives, here's my layout:

Device Boot Start End Blocks Id System Mount Point
/dev/hda1 1 63 31720+ 83 Linux /boot
/dev/hda2 64 126 31752 83 Linux /bootb
/dev/hda3 127 1119 500472 82 Linux swap (none)
/dev/hda4 1120 58168 28752696 83 Linux /
/dev/hdc1 1 3649 29310561 83 Linux /home

===Partitions and file systems===
The only real requirement regarding file system choice is that of your boot partitions. These MUST be ext2, there is no room for discussion on this. The bootloader kernel can only read ext2. Your root file system can be whatever your little heart desires, I like ReiserFS.

===Unpacking your stage tarball, and beyond===
At this point, you've got to make your choice on a stage file to start from. A stage 3 will go a heck of a lot faster, but you're currently limited to the x86 stage 3 (I do have a K6 version in the works). Stage 1's and 2's are almost not worth the extra time unless you really know what you're doing or enjoy stairing at your navel.

You can continue with a standard Gentoo installation all the way up to the point where you install your kernel. Don't forget to setup /etc/fstab.

===Kernel configuration, compilation, installation===
At the time of this writing the current Gentoo kernel tree version is 2.6.14-gentoo-r5, and the vanilla kernel is 2.6.14.5.

Which ever kernel you choose, you're going to want to patch the source tree with my kernel patch (for front panel LCD/LED/Button support, and motherboard device support). If your Cobalt has an Intel NIC, chances are the onboard checksum is wonky; so included with the kernel patch is my e100 driver patch; just enable CONFIG_E100_IGNORE_CSUM or choose the "Ignore Bad Checksum" option under the E100 network driver.

Regarding configuration of your kernel, I do have base configurations for the RaQ 3 and RaQ 4 that contain the required options for your system to boot. These do not include filesystem support. These should only have options added to them.

Once you've configured your kernel, issue the following commands:

# make vmlinux modules modules_install
# strip vmlinux
# bzip2 vmlinux
# cp vmlinux.bz2 /boot/

And be sure to double check the size of /boot/vmlinux.bz2. It needs to be less than 1800KB.

===Playing Suzy House Maker===
You're probably wondering, "What about lilo/grub?". Well, they're not needed. One thing about Cobalts is they don't have video cards, so Linux virtual console support is a waste of kernel space (remember we have only 1800k compressed to work with). Because of this, you need to comment some lines out of /etc/inittab and uncomment one or two others.

You will need to comment all of these lines:

c1:2345:respawn:/sbin/agetty 38400 tty1 linux
c2:2345:respawn:/sbin/agetty 38400 tty2 linux
c3:2345:respawn:/sbin/agetty 38400 tty3 linux
c4:2345:respawn:/sbin/agetty 38400 tty4 linux
c5:2345:respawn:/sbin/agetty 38400 tty5 linux
c6:2345:respawn:/sbin/agetty 38400 tty6 linux

Depending on how many serial ports your Cobalt has, you will need to uncomment one or two of these lines and change the "9600" to "115200":

#s0:12345:respawn:/sbin/agetty 9600 ttyS0 vt100
#s1:12345:respawn:/sbin/agetty 9600 ttyS1 vt100

In order to login as root via the serial console(s) you'll need to add the following to your /etc/securetty:

ttyS0
ttyS1

Also, because we have no video card we have no need of setting a console font, so:

# rc-update del consolefont

===Final Configuration===
So you can exit out of your chroot and shutdown your build system. Take hold of your drive and place it back in your Cobalt. Boot the Cobalt with a serial console attached.

When prompted to press the spacebar to enter the ROM menu, happily depress it as instructed. Enter the boot menu by typing "boot" and pressing Enter. You will need to set two devices in the ROM:

First, set your root partition via the following command (drive and partition are my own, your's may differ):

> set_root_dev hda4

Next, you'll need to tell the ROM which partition is your boot partition (drive and partition are my own, your's may differ):

> set_boot_dev hda1

==Finishing the Job==
Type "reboot" and you should be golden.

ROM Upgrade From ROM

2011-08-25T19:22:25Z

Jeffw: Created page with "Category:Cobalt_Guides '''WARNING!!!! THIS IS NOT THE IDEAL WAY TO UPDATE YOUR ROM!!!''' By doing this you are voiding your warranty, if you have one, with Sun Microsystems...."

[[Category:Cobalt_Guides]]
'''WARNING!!!! THIS IS NOT THE IDEAL WAY TO UPDATE YOUR ROM!!!'''

By doing this you are voiding your warranty, if you have one, with Sun Microsystems.

You can completely kill your RaQ or Qube by doing this! I am not responsible if you do, but I'll take credit if it works.

===Introduction===
In order to boot newer kernels (2.4.x and 2.6.x) you need to update your RaQ or Qube's ROM image. Your here because you don't have a bootable OS on the system. My first recommendation, put one on the system just for updating the ROM image. Why? You can backup the current image, so if your write of the fails you can write back the original.

===Getting Started===
First, you need a system you can use as a serial console for the RaQ or Qube. Download the image for your system from the Cobalt ROM project on SourceForge. If you don't know which image size you need, you'll have to figure it out. Count chips, search Google.

Boot the RaQ/Qube and when prompted press <space> to enter the boot menu.

Type boot and press <enter>.

===Load The New ROM Image===
For documentation purposes my ROM image file is named new_image.rom, be sure to substitute this for the name of the image you downloaded. I will also be specifying /dev/ttyS0, if this is not the serial port your are connected to on your console, make sure to change what you type to match.

Type dl_kernel and press <enter>.

Now send your ROM image over the serial console by typing cat new_image.rom > /dev/ttyS0 and press <enter>.

Wait.

===Writing The New ROM Image===
Re-enter the console.

Type main and press <enter>.

Type eeprom and press <enter>.

This is the point of no return!

Type erase_eeprom 0 and press <enter>.

Type write_eeprom 0 and press <enter>.

===Finding Out If It Worked===
Even if you don't believe in doing it, pray. Pray a lot. Reboot.

===After The Dust Settles===
I hope you succeeded. If not, you were warned.

ROM Upgrade

2011-08-25T19:16:22Z

Jeffw: Created page with "Category:Cobalt_Guides '''WARNING!!!!''' By doing this you are voiding your warranty with Sun Microsystems, if you haven't done so already. You can completely kill your RaQ..."

[[Category:Cobalt_Guides]]
'''WARNING!!!!'''

By doing this you are voiding your warranty with Sun Microsystems, if you haven't done so already.

You can completely kill your RaQ or Qube by doing this! I am not responsible if you do, but I'll take credit if works.

==Introduction==
In order to boot newer kernels (2.4.x and 2.6.x) you need to update your RaQ or Qube's ROM image. Done right you can minimize the danger of paperweighting your system. First thing's first, it's much easier if you have a booted system. If you're system does not boot to an OS you can still update the ROM, but it is much more difficult and the possibility of disaster is greatly increased. You can refer another howto for instructions on how to proceeded without a bootable OS.

==Getting Started==
For those of us with a bootable, you will need to download the flashtool to your system. You will also need a ROM image which are available via the Cobalt ROM project on SourceForge. If you don't know which image size you need, skip down to where you backup the current ROM image and look at the resulting file's size.

===Backing Up===
It's a good idea to back up your system's current ROM image to compare later on. To backup your system's ROM image, issue the following command:

# ./flashtool -r > backup.rom

Make sure this succeeds! If it doesn't, do not proceed any further as you cannot verify the newly burned image was burned correctly, which could result in a dead system!

==Writing The New ROM Image==
For documentation purposes my ROM image file is named new_image.rom, be sure to substitute this for the name of the image you downloaded. Ok. Let's get burning!

# ./flashtool -w new_image.rom

===Checking for Success===

If your write failed, you're ok, it should not have committed to memory.
If your write succeeded, we want to double check it wrote correctly.

# ./flashtool -r > new.rom
# cmp new.rom new_image.rom

If the compare comes back without noise, go ahead and breathe you're done. If it said the two different, try writing new_image.rom again, compare again.
If your write just failed, go ahead and try it again. If it fails yet again, write your backup and compare by doing:

# ./flashtool -w backup.rom
# ./flashtool -r > new.rom
# cmp new.rom backup.rom

If any of this fails, do not restart your system! This is critical!
While I've never seen a write of a backup fail, it is possible. If it did fail, it could indicate a bad chip or some other issue beyond the scope of this howto.

Q3Tables

2011-08-25T19:10:41Z

Jeffw: Created page with "Category:Projects __NOTOC__ ==Description== A wrapper to allow controlled access to iptables for remedial editing of a single table to block IPv4 addresses from a UDP game se..."

[[Category:Projects]]
__NOTOC__
==Description==
A wrapper to allow controlled access to iptables for remedial editing of a single table to block IPv4 addresses from a UDP game server.

==Information==
*'''Version:''' 0.1.1
*'''Last Update:''' Mon, December 10, 2007 at 15:21:27 GMT
*'''Language(s):''' C, Bash

==Downloads==
*Current: [http://files.parvi.us/packages/q3tables/q3tables-0.1.1.tar.gz q3tables-0.1.1.tar.gz]

==Future Changes==
*''none''

==Change Log==
*0.1.1
**Add per-user support.

*0.0.5b
**Original coding.

Cobalt Kernel Patch

2011-08-25T18:23:29Z

Jeffw:

[[Category:Projects]]
__NOTOC__
==Description==
This patch adds hardware functionality to the x86-based Sun Cobalt and Qube servers.

==Information==
*'''Version:''' 2.6.32
*'''Last Update:''' 13:44, 3 December 2009 (UTC)
*'''Language(s):''' C

==Downloads==
===Patches===
*Current: [http://files.parvi.us/gentoo-stuff/patches/cobalt-kernel-2.6.x/linux-cobalt-2.6.32-2009120301.jeffw.patch linux-cobalt-2.6.32-2009120301.jeffw.patch]
*[http://files.parvi.us/gentoo-stuff/patches/cobalt-kernel-2.6.x/ All Patches]
===Base Configurations===
*[http://files.parvi.us/gentoo-stuff/patches/cobalt-kernel-2.6.x/configs/gen_iii-minimal.config Generation III]
*[http://files.parvi.us/gentoo-stuff/patches/cobalt-kernel-2.6.x/configs/gen_v-minimal.config Generation V]

==Future Changes==
*'''Ruler Support:''' Broken right now because someone removed the ''pci_dev'' and ''busproc'' from the ''ide_hwif_t'' struct. I have to track down how this changed.

==Change Log==
*'''linux-cobalt-2.6.32-2009120301.jeffw.patch:'''
**Just fuzz this time around

*'''linux-cobalt-2.6.31-2009112901.jeffw.patch:'''
**arch/x86/kernel/traps_32.c code moved to arch/x86/kernel/traps.c
**include/asm-x86/setup.h code moved to arch/x86/include/asm/setup.h
**Huge fuzz (max offset 170 lines!)

*'''linux-cobalt-2.6.27-20081101.jeffw.patch:'''
**COBALT_MIPS_LCD no longer needed, removed from Makefiles and Kconfigs
**Fuzziness and moves

*'''linux-cobalt-2.6.26.5-20081001.jeffw.patch:'''
**Stripped the reboot code from arch/x86/kernel/process_32.c which caused reboots on core dumps
**Added COBALT_NEWCMDLINE to configuration to fix the commandline passing issue
**Stripped out the checksum ignore for the e100 driver as it's already provided, but added configuration directive to activate the option (E100_IGNORE_CSUM) when built in to the kernel
**Changed locations of a bunch of code due to constant changing of 32/64 bit code separation.

*'''linux-cobalt-2.6.24-gentoo-r4-2008050401.illogical.patch:'''
**Fixed patch hunk failures
**Changed arch/i386 to arch/x86
**Changed arch/x86 files to patch 32 bit files

*'''linux-cobalt-2.6.23-r3-2007121901.illogical.patch:'''
**Fixed patch hunk failures
**Re-arranged compiler directives in drivers/char/nvram.c
**Swapped SA_SHIRQ for IRQF_SHARED in drivers/cobalt/acpi.c as the former is deprecated
**Fixed the incompatible pointer type in drivers/cobalt/acpi.c

*'''linux-cobalt-2.6.22-r9-2007111201.jimg.patch:'''
**Repaired patch hunk failures
**Made PCI changes to reflect changes in the kernel
**Fixed 'make cobalt'
**Added default configs

*'''linux-cobalt-2.6.20-r1-2007022201.illogical.patch:'''
**Add support for /proc/cobalt/powermode. Allow GenV RaQs to power on after a power loss.

*'''linux-cobalt-2.6.20-2007021901.illogical.patch:'''
**Repaired two patch hunk failures

*'''linux-cobalt-2.6.19.2-2007012801.illogical.patch:'''
**Removed all references to include/linux/config.h
**The notifier_chain_register kernel function was renamed to atomic_notifier_chain_register
**Fixed the shutdown and reboot issues

*'''linux-cobalt-2.6.16.2006032101.illogical.patch:'''
**Silly kernel maintainers made one line into two lines, breaking arch/i386/kernel/traps.c. Oh well, fixed.

*'''linux-cobalt-2.6.15.gentoo-r1.2006020302.illogical.patch:'''
**Fixed a declaration warning for wait_for_flush()

*'''linux-cobalt-2.6.14-gentoo-r5.2005122901.illogical.patch:'''
**Restructured portions to work with changes in the kernel

*'''2.6.12-gentoo-r6.2005073002:'''
**Fixed the warning drivers/char/nvram.c:56:1: warning: "MACH" redefined

*'''2.6.12-gentoo-r6.2005073001:'''
**In 2.6.12 the eepro100 driver broke, so the move was made to the e100 driver, which had to be altered to semi-ignore back EEPROM checksums.
**Tested with gentoo-sources, runs just dandy.
**Created a minimal base config for generation III and V Cobalts.

*'''2.6.11.5.20050501:'''
**With the help of plasmaroo the last 4 warnings are gone for good.

*'''2.6.10:'''
**gcc-3.4.3 support added by cleaning up a bunch of code. Not fun, but needed.

News

2011-08-25T18:16:40Z

Jeffw:

__NOTOC__
==llfilter Released==
'''19:40, 25 August 2011 (UTC)'''

I've put the source code and a release tarball up on [http://sf.net/projects/llfilter SourceForge]. If you find it useful, cool. If you find a bug, squish it.

--[[User:Jeffw|Jeff]]

==llfilter Announced==
'''00:58, 19 April 2011 (UTC)'''

I've been so busy with work, wedding planning, and other stuff that I haven't been able to update the kernel patch, but I was finally able to "complete" a project I've been meaning to write for a long time: [[llfilter|llfilter]]. What is it? In short it creates two TUN/TAP network devices and moves packets between them after causing a specified amount of latency and loss. Makes sense when you're simulating a a network link from NYC to AMS on a single server. As soon as the code review is done I'll be posting up the source.

--[[User:Jeffw|Jeff]]

==2.6.32 is out along with a patch==
'''13:47, 3 December 2009 (UTC)'''

I think this has got to be one of my quickest turn-arounds for the [[Cobalt_Kernel_Patch|Sun Cobalt RaQ patch]]. I guess I'm just lucky this time, eh?

--[[User:Jeffw|Jeff]]

==Good News==
'''03:42, 3 December 2009 (UTC)'''

Early this morning I was contacted by a pair of lawyers who are interested in fighting my UDRP decision. I am so thankful for their willingness to help me. This will surely be a lengthy fight, and I will do my best to assist them. I want to thank Paul and John for all the time and work they're putting in to this. Also, I want to thank Stuart for pointing them in my direction.

--[[User:Jeffw|Jeffw]]

==2.6.31 patched==
'''04:17, 30 November 2009 (UTC)'''

I've been slacking, I know :-) You know what would be great? I'd love to see the main kernel developers choose, once and for all, how to organize the 32 and 64 bit code. That'd be lovely.

--[[User:Jeffw|Jeffw]]

==Finally, a decision, but not good==
'''04:38, 29 November 2009 (UTC)'''

Please update your links folks... parvi.org has been ordered transferred to the city of Paris, France. The new domain is a more local version of parvi.org, just swap the .org for .us: [http://parvi.us/ parvi.us].

--[[User:Jeffw|Jeffw]]

==Differences==
'''21:54, 20 November 2009 (UTC)'''

Apparently, the date the decision from the panel is due, is different from the decision date. Then, four to five days from the decision date for the decision to be entered in to WIPO's system and, in theory, notification be sent out.

As of now:

* '''WIPO Case Number''': D2009-1278
* '''Domain name(s)''': parvi.org
* '''Complainant''': Ville de Paris
* '''Panelist''': Christie, Andrew Frederick
* '''Decision Date''': 19-11-2009 <-- That's November 19th.
* '''Decision''': Case active

--[[User:Jeffw|Jeffw]]

==Still nothing from WIPO==
[[Image:jeffw_busted_nose.jpg|100px|thumb|left|Ouchie]]
'''10:14, 20 November 2009 (UTC)'''

Well, the decision was due on November 16th, but based on past decision dates I probably won't hear anything until the 20th or the 23rd (I hate weekends).

Also, sorry I haven't updated the patch to 2.6.32 yet-- I've been busy recently, so I haven't had much "me" time. I suppose a big part of it was my inability to concentrate thanks to a pretty well broken nose. So, note from the unfortunate, don't try to stop the bar fight before it starts, you'll just be the first on hit.

I'll be working on the patch tomorrow, and hopefully I'll be able to finish it in one go.

--[[User:Jeffw|Jeffw]]

==UDRP decision probably today==
'''08:06, 17 November 2009 (UTC)'''

So I should be hearing from WIPO regarding the decision on the Ville de Paris' UDRP filing against parvi.org today. In the event that I somehow lose parvi.org I already have a new domain waiting in the wings. I'll make an announcement on the mailing list if a change of domain is necessary.

--[[User:Jeffw|Jeffw]]

==parvi.org in the news==
'''07:05, 1 October 2009 (UTC)'''

I never though this would be so popular. [http://domainnamewire.com/2009/09/29/paris-attacks-geo-domain-name-owners/ Read on for the article].

--[[User:Jeffw|Jeffw]]

==Mailing list madness==
'''22:54, 6 November 2008 (UTC)'''

So I created a [[Mailing_List|mailing list]] for the Cobalt stuff over at GoogleGroups. Feel free to join.

--[[User:Jeffw|Jeffw]]

==2.6.27 has a patch==
'''10:26, 1 November 2008 (UTC)'''

Very few things changed from 2.6.26.5 to 2.6.27 (thankfully). The highlight was that COBALT_MIPS_LCD is no longer required, so I was able to strip all of the patch stuff for it out. Eventually I'd like to get the patch down to a real minimum, but that will undoubtedly take time, and a lot of it.

--[[User:Jeffw|Jeffw]]

==New Cobalt kernel patch for 2.6.26.5==
'''11:43, 1 October 2008 (UTC)'''

I haven't had a chance to try [[Cobalt_Kernel_Patch|this patch]] out yet as it's 4:41am localtime, but it compiles, and everything looks right. I'm going to test it this evening when I get to work (this is where I keep all my RaQs that I test with). In the mean time, if people want to try it, I'd very much appreciate it.

'''Update (11:23, 2 October 2008 (UTC)):'''
I noted the ruler driver is currently broken, and as it turns out, it's actually used for something. The RaQ XTR uses the ruler driver for the four hotswap bays, and sadly it will not boot without the driver. I'll be looking in to this in the next couple of days.

--[[User:Jeffw|Jeffw]]

==I've been putting it off...==
'''11:25, 24 September 2008 (UTC)'''

I've been putting it off because I've been so busy with other things (work, life, car (grrrrr)), but my goal in the next few days is to fix that annoying boot bug which someone so kindly sent me a patch for.

I'm sorry it's taking so long.

--[[User:Jeffw|Jeffw]]

==New layout and it's a wiki!==
'''02:22, 11 December 2007 (PST)'''

I've been thinking about doing this for a while. I've come to somewhat like MediaWiki and I've been working on this template for a while. Seems to work rather well in my opinion.

--[[User:Jeffw|Jeffw]]