On getting Free Support

On getting Free Support

Most of the things I know about Software and Hardware I have from reading books, looking at sourcecode but most importantly people willing to answer my questions on IRC and giving me a direction I could look for answers.

Now it seems to be my part to give back and help others to gain knowledge, but some things have changed. Free Software has made it to the mainstream, so besides hackers that want to understand things, we do have paid programmers that don’t want to understand but still need to make it work.

So the other day I was finding me in a IRC query. His target board was a Freescale i.MX27 ADS and his mission was to make it boot from NAND. He was using the OpenEmbedded “mx27ads” machine and had successfully build a kernel and rootfs. Now the problem is that Freescale is not particulary liked in the Free and Open Source Software Community and that Freescale prefers to be on an isolated island. After about 8 hours of spending my time on this, i decided to get back to paid work and carry on.

If you are searching for support on mailinglists, irc channels and irc queries be prepared to think, giving Free Support means that you will be helped to understand the problem and have to pick a solution yourself. If you don’t like that, don’t want to think, don’t have the time to think, you should consider getting someone from the irc channel as consultant.

So here is a list of things that work when paying a consultant but not when you are paid to do your job and you need someone else to do it for you:

  1. Pasting your log somewhere and then ask what is wrong with it. In case of compile failures with GNU make you have to search for ‘***’ in the error log, in case of an early failure of a bitbake run it tells you what software to install, in case of configure failures read the config.log, in case of other failures search the log for ‘Error’, ‘rror’, ‘Failure’, ‘ailure’. And most importantly think before you post it.

    At OpenEmbedded we check for Software being installed on the system. This includes checking for GIT, CVS, SVN and other projects needed to bootstrap. If you don’t have it installed OpenEmbedded will tell you “Error… you don’t have installed:” and the output will be finished by “You will have to install….”. If you paste such an error and ask what the problem is you are really embarassing yourself, your parents, your teachers and your country. The Error message tells you which binaries it searched for and couldn’t find, and it points you to common package names for them. I don’t think it can be any easier for a Software Engineer.

  2. Knowing your hardware. Remember, you have the hardware in front of you, you have it connected somewhere, you have something compiled on your system. So if you are asked about the system specification you will have to point to a PDF, website that names the SoC, the used flash chip (NAND, NOR, erase size, name of it), the SDRAM used and whatever else is used on the system. If you paste a FAQ of something like Buildroot you have clearly failed. Know the stuff that is on your desk, if you don’t nobody can help you.
  3. Pasting unrelated information. When you are asked to paste the output of something. Do not just write that oneline by hand. In many cases we humans apply interpretation to things. When you are asking for help it is an indication that you are not able to interpret the result in a way that lead to a result. Paste the full log, it is saving everyone a lot of time.
  4. Listen/Read to what people tell you. If you have a kernel without NAND support, but want to boot from NAND. You will have to enable NAND and the MXC NAND driver in your kernel. You will have to compile the kernel again, and you will need to boot that kernel. Now we are all humans and have done mistakes before.

    One of the most common mistakes is to not change the config, or not to boot the kernel you have built.

    For the config, check .config after you have built if it is the one you expected it to be, in case of OpenEmbedded copy the .config back to the defconfig (recipes/linux/${PN}-${PV}/${MACHINE}/defconfig). You should copy it back to have a backup in the case you are rebuilding the kernel or such.

    For the second thing it is rather easy. The kernel does contain the TIME it was built and it contains the number of times you have built it from the same directory. So if you rebuild the kernel the TIME and the NUMBER will go up. The kernel does print this information at bootup. If you are asked to check that, don’t paste the log, but check it for yourself. Last but not least, if the NUMBER did not go up or the TIME did not change you have either not rebuilt it, or not from the same directory… And if you didn’t rebuild from the same directory then you are likely to not use the right config…

  5. Don’t do crazy things while people spend their time to help you. Do not remove your build directories and just start over. No, even after your next rebuild the kernel will lack NAND support. That is because it is not enabled in the defconfig for your machine, and the build process is deterministic… You have someone on the other side that decided he wants to help you, if you are not focused, why should he?

And for all of you, that have read until the end. If you decide to seek help in an open forum. First do your homework by having some idea about the problem, have information ready (hardware spec, build logs, whatever), be prepared to think, formulate a hypothesis and try it.

With Free Software you are in the fortunate situation that you can talk to the guys who build the stuff you are using, all you need to do is to be focused on receiving help and be prepared to think.

Comments are closed.