Pandaboard ES: How to get 1 GByte RAM

Some colleagues told me they have only ~750 MByte RAM available on their PandaBoards.  So I checked my PandaBoard ES and it was the same there. As first I tried to set mem=1024M in boot.scr, but this didn't help. After some research I found that our kernel from the openSUSE:Factory:ARM repository wasn't build with HIGHMEM support. But the kernel need HIGHMEM-support to access the memory above 768MB on ARM/OMAP.


I changed the kernel config for the omap2plus package and build a new kernel RPM locally.

As soon as I installed the new kernel and rebooted, I got this:

root@pandboardES:/ # free 
             total  used   free shared buffers cached
Mem:       1010680 54604 956076      0    3516  29384
-/+ buffers/cache: 21704 988976
Swap:            0     0      0

I'll submit a new kernel package, but for now you can get the RPMs here.

PandaBoard ES ... got it up and running openSUSE

I finally found some time the last days to play with my new PandaBoard ES. As first Dirk Müller helped me by providing an image for my SD-card with an image that worked with the normal PandaBord. Thanks! Unfortunately we couldn't get the machine running with this image.

Later I tried a Linaro Android build and the machine booted. As I copied some of the files from the boot partition to the SD-card with the openSUSE installation it booted into openSUSE. After a hint from Alexander Graf (to change the console in u-boot to ttyO2) I could also access the serial console.

I could now play around and build on the board to find a fix for the openSUSE image Dirk provided to me: Since it didn't boot with the latest u-boot/x-loader git code from mainline, I tired the u-boot git from Linaro. This step finally solved the issue. I created a new u-boot package for openSUSE: u-boot-linaro-omap4panda. While the upstream u-boot package deletes the MLO file at the end of make, the Linaro u-boot doesn't. Therefore the new RPM should obsolete x-loader-omap4panda at openSUSE. 

You can get the Factory RPM (temporary) here. I already made a submit request for Base:System ... we will see if and when it gets in.

New PandaBoard ES arrived

Today finally my new PandaBoard ES arrived from Digi-Key. Here the new features compared to the former PandaBoard:

• Dual-core 1.2 GHz ARM® Cortex™-A9 MPCore™ (OMAP4460) with SMP from Texas Instruments
• provides 25% increase in graphics performance over OMAP4430 (but use a Imagination Technologies’ POWERVR™ SGX540 graphics core as the PandaBoard)
• DSI Support
• Bluetooth Low Energy Capable
• Sysboot switch available on board

The rest of the board should be the same as on the OMAP4430 based PandaBoard. Here some pictures:

Let's start to get an openSUSE running on the machine ... I'll post updates as soon as I found the time to play around with this tiny thing. 

Git trouble shooting: none-bare repository

I had some trouble with my git repositories at freedesktop.org in the past, as you may remember [1,2]. Last week I run in some trouble again. As it looks, they updated the git server to a new version, since the update I got the following error message on push:

[...]
error: refusing to update checked out branch: refs/heads/master
error: By default, updating the current branch in a non-bare repository
error: is denied, because it will make the index and work tree inconsistent
error: with what you pushed, and will require 'git reset --hard' to match
error: the work tree to HEAD.
error:
error: You can set 'receive.denyCurrentBranch' configuration variable to
error: 'ignore' or 'warn' in the remote repository to allow pushing into
error: its current branch; however, this is not recommended unless you
error: arranged to update its work tree to match what you pushed in some
error: other way.
error:
error: To squelch this message and still keep the default behaviour, set
error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To ssh://dkukawka@people.freedesktop.org/~dkukawka/hal.git
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'ssh://dkukawka@people.freedesktop.org/~dkukawka/hal.git'

Unfortunately the instructions from the error didn't help me to make push work again. I tried 'git reset --hard'and also to clone the repo again from the server, apply the new patches etc. but it didn't work. Here is what I had to do to get it work again:

login to the remote server with the git repository

go to the repository directory

call  'git config --bool core.bare true'

I don't know how it happened in the first place to be non-bare, but this should set the remote repository again to a bare repo and you are able to push again.

How to get your full disc space back on ext filesystems

You may have already wondered why you can't use the full disc space on an ext2/3/4 partition? You already seen something like this, where the used and available blocks don't fit the number of blocks on the device/partition:

Filesystem 1K-blocks   Used    Available Use%  Mounted on
/dev/sdc1   15391664  38184   14571608      1%  /mnt

The reason is: if you create an ext filesystem (no matter if with mkfs or YaST), 5 % of the filesystem get reserved for the super-user to allow e.g. root daemons to continue to write to the partition after unprivileged processes stopped because the partition is full.

While this perfectly make sense on system partitions as '/', it makes no sense on data partitions or external media (in the most cases). By this you get e.g. on an external 2TB/1.8TiB drive 100GByte/~92GiB, which you can't use as normal user. But you can get this space back. Either you set the number of reserved blocks to zero when you create the file system:

mkfs -t ext4 -m 0 /dev/sdc1

or you do it later:

# make sure partition is unmounted
umount /mnt
tune2fs -m 0 /dev/sdc1

On a LUKS encrypted  you have to do this:

# on a LUKS device
umount /media/disk
tune2fs -m 0 /dev/mapper/udisks-luks-uuid-X

 You should see this output:

tune2fs 1.41.14 (22-Dec-2010)
Setting reserved blocks percentage to 0% (0 blocks)

 And if you mount the device again, you can see with df that you have the full space available:

 Filesystem 1K-blocks   Used    Available Use%  Mounted on
 /dev/sdc1   15391664  38184   15353480      1%  /mnt

Update for extundelete

Today I've submitted a new extundelete package to my repo with following fixes:

• added man(8) page to the package
• fixed --help output to print also info about --restore-directory
• added --dump-names option to search for - and print the full name of - deleted and (potentially fully) recoverable files on a given partition 

Feel free to test and report problems back. The package is now also part of the filesystems project.

How to undelete files from ext3/ext4

Sometimes, especially on the command line, it happens that you delete a file or directory you didn't really plan to delete. A second after hit enter you realize what you have done, maybe you are fast enough to stop the deletion process and save some files, but in the most cases it's already to late, at least for some files.  If you have no or a too old backup you're screwed. 

If you use ext3/ext4 you may be able to recover the file with ext3grep or extundelete with information from the file system journal if the content of the file wasn't already overwritten by new data. 

The first step should be to stop all writing processes on the related partition and unmount that partition as soon as possible. Now you have the choice: if your partition uses ext4 you have to use extundelete, if it's ext3 you can use also ext3grep. Personally, I prefer extundelete, since it supports both file systems and seems on one hand much faster to me than ext3grep and it's also easier to use on the other hand. Due to that, the following examples are for extundelete (you can find a ext3grep How-To here).

If you know the path and the name of the file (let's assume it's /home/tux/cv.tex and /dev/sda4 is mounted to /home) you deleted, switch to root and go to a partition with enough free space to store the deleted files. Then:

# extundelete need the relative file path 
me:/tmp # extundelete --restore-file tux/cv.tex /dev/sda4

As soon as extundelete finished, you'll find the recovered file in /tmp/RECOVERED_FILES/tux/ .

If you deleted more than one file in a directory or a directory itself, you can use --restore-directory :

# extundelete need the relative dir path 
me:/tmp # extundelete --restore-directory tux/Documents/tex/ /dev/sda4

There are some more useful options as --restore-all , --restore-files, --after 'dtime' or --before 'dtime', but in the most cases the two examples above should be enough. You can find both tools in my buildservice repository.

Updated xinput_calibrator packages

Today I found some time to update the xinput_calibrator packages in my buildservice repository. The new version is 0.7.5. And since someone asked in my last post for 11.4 rpms, I've activated the build also for openSUSE 11.4. 

Feel free to test and report back if you have any trouble with the updated version.