Welcome to my personal web page
Not sure if this is a common bug for everyone using a hand-built OpenWRT on Ubiquiti RouterStation Pro platforms, but at least I notice it on all the boards I have in my possession. When booting the OpenWRT kernel and watching the printk() output, rubbish data can be seen in the kernel command line parameters - in normal cases. Usually this does not break anything, but as we know, RedBoot in Ubiquiti boards passes board-specific parameters to the kernel command line with information such as board type, ethernet MAC address etc. Sometimes those parameters are not passed and parsed correctly because of this. I did a small investigation why this happens.
First of all, it is best to understand how the Linux kernel fetches the command line in case of MIPS AR71xx boards. In the OpenWRT kernel 2.6.37, all boot-specific parameters are passed through the a0, a1, a2, a3 processor registers during start-up, which are then copied to respective kernel variables from fw_arg0 up to fw_arg3 - and used in this form later on. We are interested in the three first variables. Their meaning is similar to how normal GNU/Linux applications fetch information from the system:
When in RedBoot, a call to exec executes the loaded program, setting the environment and allowing passing additional kernel arguments to the cmdline (through the -c option). We need to remember that calls to the RedBoot go command only execute the kernel, while exec also sets all the platform-specific parameters in the environment beforehand. Information such as the aforementioned board type, ethernet address etc. are passed through the environment, so in our case through fw_arg2. The variables fw_arg0 and fw_arg1 are used only in the case of passing additional arguments through the exec -c command. The problem lies in how these two variables are used by the bootloader. Anyway, first the command line arguments are pasted into the kernel, and then concatenated with the environment parameters.
cmdline=[User command line arguments] [Environment variables]
It seems the Ubiqiti-modified RedBoot, whose sources aren't available - but should, passes always a constant number as the number of cmdline arguments = 2. fw_arg1 is always an empty, NULL-terminated string and all the other, actual arguments are squeezed inside of fw_arg1 as a single string. Besides being strange and illogical, up utill now there is no real problem. But sadly, Ubiquiti's RedBoot (at least version 0.9.00318M.0905121200 - built 12:01:38, May 12 2009 which is on all my RouterStation Pro boards) seems not to initialize the fw_arg1 memory area during boot sequence. It only does so when we explicitly pass some additional kernel arguments like exec -c "blah" or even exec -c "" (for no parameters). But before that, there's nothing but chaos in our cmdline.
Some might be thinking - "But wait! If this is how it is, why does the firmware still work correctly most of the time? Shouldn't rubbish in the cmdline make the environment also unreadable?". Yes, that's true. Since the first part of the cmdline that is passed to the kernel is made out of fw_arg1 and then with the environment glued onto it, the important parameters should not be visible because of all the invalid data. But since the memory area is uninitialized, there is also some chance that sooner or later in that big buffer allocated for the command line a 0 byte from that rubbish will appear. So there still is a chance that the environment will be appended and visible. The kernel ignores most of the chaos, since he is unable to parse it, and simply moves to the environment variables. Or at least that's how I explain it.
At least that seems to be the case on my boards. The fastest way to deal with this problem is either using exec -c "" instead of exec in your bootscripts, or modifying the kernel source to ignore the user-given command line arguments (or adding a magic-sequence mechanism perhaps?).
Lately I'm a bit busy with different work and research stuff, so I don't have much time to spend on my hobby projects. But expect some Haiku OS related posts soon, since I intend to get back to Toku Toku as soon as possible.