Disable the console and save memory

This is one of the first things that I change on the first login, right after I install a new server.

Long time ago, people didnt have access to Internet. We used the console, alone at home, with some txt that we could get on a diskette, or on the CD ROM that came with some magazine. Even that, X Org was even worse than today, and we had like 128Mb of ram or so…

For that, we used the console. I mean, the VGA console, because old cards have a fast video mode called ‘text mode’ that could display only chars. Most of the time, we used the direct console to work.

To make multitasking easy, you could open several consoles, and move between them using Atl+Fn. This was very useful on that time.

But that was almost 20 years ago.

Now, it has no sense. We keep that only for historical reasons. You dont have a monitor, you dont have a console. So, dont spawn many consoles, wasting resources for nothing.

This is so old, that you have to edit /etc/inittab, something that came from unix, and comment those lines:

#1:2345:respawn:/sbin/getty 38400 tty1
#2:23:respawn:/sbin/getty 38400 tty2
#3:23:respawn:/sbin/getty 38400 tty3
#4:23:respawn:/sbin/getty 38400 tty4
#5:23:respawn:/sbin/getty 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6

if you have the server at home, you could keep the first one in case of emergency, but you can also boot in single mode and fix your computer.

And to apply this change, you have to use a very rare and arcane command:

telinit q

Buildroot

In my last post, I was talking about the idea of using an ARM machine to build my image. That sounds really slow and painful, sure, but at least it could be done without problems.

Well, I posted the blog entry on twitter, and fortunately, TheVaw, a good friend from Galicia, point me about using qemu. I knew qemu, but honestly, i never use it before.

@StaticBoards Can’t you use qemu to emulate those arm command calls?

— Javi Fontan (@thevaw) June 29, 2013

To install qemu, on debian (or similars) you can follow this simple guide on the debian wiki. Basically, i installed:

apt-get install qemu binfmt-support qemu-user-static

With this package, you can cross compile a binary using the toolchain (apt-get install gcc-4.7-arm-linux-gnueabihf in my case), and run the arm binary in your x64 machine. It works.

So, I built the required binaries and they worked.. great! Then I continue compiling things, and dependencies, downloading repos, etc.

…

But after a while, I realized that this is totally insane! I have to patch some makefiles, I got errors with static libc libraries, blah blah, and I am tired of waste my time reinventing the wheel.

Looking for a better solution, i found the buildroot package. It seems to do everything that I am doing here, compile the kernel, make a minimum root filesystem, make an sdcard image, etc. I tested it, and it works!!

And even better, on the last version from git, all the projects binaries for sunxi are included!! the cubieboard is supported, and it has the tools for the boot loader. It builds the kernel 3.4 with the sunxi  modifications. And it compiles everything.

Also, I found another great candy, a custom buildroot in github. It seems based on buildroot, but with many modifications. I am reading the logs, trying to understand the differences, etc. You can read more on the linux-sunxi wiki.

Then, at this point, My idea is continue working on buildroot. As the target is to make my own board, I forked the buildroot git repo, and created my own version on github. To do so :

touch README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin git@github.com:derethor/buildroot.git
git push -u origin master
git remote add buildroot git://git.buildroot.net/buildroot
git fetch buildroot
git merge buildroot/master
git push -u origin master

Then, you can update the buildroot repo to your local repo (it will be buildroot/master), and rebase (if you dare to do so)

This is the github repo, if you want to followmy progress  (i dont promiss any commit 🙂

 

Problem

Well, after some days of research, i found that cross compile things on my PC wont be easy. Not at all. Some binaries are impossible to cross compile, because they build an executable to actually generate files. The cross compiler can build the tool, but not run it. And it doesnt work.

So, that is the thing, i have to use an ARM machine to build things. And I have only an A13, without network, and a rpi.

The thing is that If i cross compile something on the pc (linux mint 14), and then, I copy it to the rpi, it crases. I use armhf arch, but it seems that I need to enable something, etc.

So, to make my life easier. I will compile everything on the rpi. The kernel will take hours, i am sure, but it will work (i guess). Maybe on the furure, i can buy an A31 as a build machine for images, but it is ok, i dont have to build everything all the time.

Later, i will investigate how to cross compile the kernel here, using the same architecture than the rpi. I am sure that there are losts of tutorials on internet about it.

Puff

 

My current setup

 

 

You can see, the A13 Olinuxino Micro, connected with USB (only 500 mA, so, dont connect a touch screen, etc). I upload the image with the sony card reader, using a microsd adapter to sdcard (quite a pain to plug/unplug each time), and my lovely bus pirate (a logic analyzer for 20 euros). The Bus pirate works with the 3.3v serial port.

The Bus pirate can works like a simple sniffer (no sense), or you can use it like a normal terminal. It captures also i2c and SPI.

 

Related articles

• Bus Pirate (sparkfun.com)

we have a console!!

I downloaded this config from github, and reverted the script.bin to the original one from olinuxino… and using a very simple busybox env, I can boot and run a console!!!

This is the ps output

# ps
PID USER VSZ STAT COMMAND
1 0 872 S /bin/busybox init
2 0 0 SW [kthreadd]
3 0 0 SW [ksoftirqd/0]
4 0 0 SW [kworker/0:0]
5 0 0 SW [kworker/u:0]
6 0 0 SW< [cpuset]
7 0 0 SW< [khelper]
8 0 0 SW [kdevtmpfs]
9 0 0 SW< [netns]
10 0 0 SW [sync_supers]
11 0 0 SW [bdi-default]
12 0 0 SW< [kintegrityd]
13 0 0 SW< [kblockd]
14 0 0 SW [khubd]
15 0 0 SW< [md]
16 0 0 SW [kworker/0:1]
17 0 0 SW< [cfg80211]
18 0 0 SW< [rpciod]
19 0 0 SW [khungtaskd]
20 0 0 SW [kswapd0]
21 0 0 SWN [ksmd]
22 0 0 SW [fsnotify_mark]
23 0 0 SW< [nfsiod]
24 0 0 SW< [cifsiod]
25 0 0 SW< [crypto]
38 0 0 SW< [kmpathd]
39 0 0 SW< [kmpath_handlerd]
41 0 0 SW< [deferwq]
42 0 0 SW [mmcqd/0]
43 0 0 SW [kworker/u:2]
44 0 0 SW< [ext4-dio-unwrit]
52 0 872 S -/bin/sh
53 0 872 S /bin/busybox init
54 0 872 S /bin/busybox init
55 0 872 S /bin/busybox init
56 0 0 SW [flush-179:0]
59 0 876 R ps

About Heat

quick heat dissipation

The A13 is really hot. I guess that it is because I am still builing the root image, and the kernel is running at fullspeed (1Ghz). I have some small heatsilk to cooldown a little bit the micro, but it is still hot (i didnt measure it, but you can touch it without problems… for a while)

Continue booting…

I was cleaning up the kernel… the sunxi 3.4 has a lot of drivers that i wont use, and it takes time to compile.

But the kernel crashes during boot. It seems that there are problems with the LCD, and prob the GPIO (normal, as they both use the GPIO pins).

http://pastebin.com/DjtTwEva

Lets continue working on this…

 

The kernel now boots!

After some problems setting up the environment, I can boot the kernel. You will need a serial console to read the log (i’m using the bus pirate), and see what is going on.

This is the boot log

When I bought the board, I got a 12v power supply by mistake. This board is 5v!! Fortunately, the board survived, but now I need a 5v power supply.

Something I will need to check is the A13 temperature. It is really hot. I will check it later with the fluke, but it hurst when you touch it with the finger. I tested the cpu voltage, and it is something like 1.4v, not the 1.2v. MAybe it has something to do with the fact that I plugged a 12v power supply for a while

Lets continue with this.