ArchlinuxARM on Raspberry Pi

Hello to everybody!

I'm still not giving up trying to boot Arch Linux on qemu with the original Raspberry Pi Kernel. First I thought it could be some driver missing, because qemu does not emulate exactly the same hardware the Raspberry Pi has. But booting with this kernel doesn't even show a kernel panic - the screen just remains black. I tried it again with the Arch Linux kernel for the Pogo Plug (or something like that) which uses the same instruction set as the Raspberry Pi (ARM v6) with the same result: Screen remains black.

Looking in the manual ("man qemu") I found out that the "-kernel" switch of qemu is expecting a bzImage of the kernel. In the PKGBUILD of the Arch Linux kernel for the Raspberry Pi I found following command:

/usr/bin/python2 imagetool-uncompressed.py

I'm not an expert, but does this mean the Kernel is not compressed and qemu doesn't boot because it is expecting an compressed Image? If so, would it be possible to "re-pack" the original kernel in an compressed image so I can boot it with qemu and even can load the kernel modules within the Arch Linux filesystem?

I just started to compile the kernel. This just take bloody ages, especially in an emulated environment. If I'm able to generate an image bootable with qemu I'll be back an tell you.

Thanks for reading,

Marian

OK, here is what I found out so far:

According to this "imagetool-uncompressed.py" is a tool do pack the uncompressed image (located after compiling the kernel in "arch/arm/boot/Image") for the Raspberry Pi hardware. This Python script generates the file "first32k.bin" and generates out "arch/arm/boot/Image" and "first32k.bin" the new Raspberry Pi kernel which is located at "arch/arm/boot/kernel.img".

So as far as I can see, all we have to do to get a qemu-Version of the Raspberry Pi Kernel is to generate a zImage by "make bzImage". I did so and because I already compiled the kernel over night it just had to repack the kernel which tooks only 5 minutes. But even with this image qemu still does not boot the kernel (screen remains black).

For now I'm out of ideas. Is there something I didn't see?

Thanks for your help,

Marian

New Build

Just thought it might be nice to give a happy update to this thread.

Yes, main changes (apart from packages being updated, but I still did rootfs a few weeks back and time marches on) -

Kernel and firmware packaged, when BCM Dom makes a change it's all painlessly taken care of.

I am running rootfs off hard drive, and using am old 32Mb card for the /boot firmware, not quite enough room. To upgrade firmware I have to delete all but the txt files and kernel.img, move kernel.img for the duration, perform upgrade and move kernel back. Hopefully not to many people won't be a cheapskate like me.

[dom]

Looks like the update to latest version removes the cmdline.txt (and config.txt).

This has the negative effect that the GPU bootloader doesn't append the extra arguments (e.g. framebuffer width/height, serial number, mac address)

This results in 800x480 framebuffer console.

Creating a suitable cmdline.txt fixes it:

echo "dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext3 rootwait" >/boot/cmdline.txt

@pepedog - can you fix this?

This worked for me. Using  Panasonic Viesa TV (32 inch). Now happily runs at 1280x720, which is the same setting as under the debian distro.

Thanks for the solution.

Looks like the update to latest version removes the cmdline.txt (and config.txt).

This has the negative effect that the GPU bootloader doesn"t append the extra arguments (e.g. framebuffer width/height, serial number, mac address)

This results in 800x480 framebuffer console.

Creating a suitable cmdline.txt fixes it:

echo "dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext3 rootwait" >/boot/cmdline.txt

@pepedog - can you fix this?

I will fix. The txt files are there but with pacsave on the end.
Thanks for pointing out

All fixed

Edit, no it"s not, will post when it is

I am making a new rootfs. Alsa working, disable obvious in /etc/rc.conf

All new kernel and firmware. Will post when done (zip -9 is the longest part of process, wish xz could be used)

Looks like new firmware takes care of some overscan problems, on my monitor area has shrunk

[dom]

Yes, latest firmware defaults to overscan of 32 for SD resolutions, and 48 for HD (width>=1280).

If you have already set overscan, you may have too much now.

disable_overscan=1 to go back to no-overscan scheme.

Hi pepedog,

Thanks for your contribution. Can you please post a link for download once done.

Regards

envy

Will do envy, I am pming you
Thank you Dom.
Dave

Just a note on updating this one time, force update with
pacman -Syuf
Sync after.
Liberal use of sync seems to help after large downloads or writes. Become a fan of sync.

I've had a little trouble with updates.  Install with archlinuxarm-01-03-2012 works great but any later kernel doesn't boot, I receive the following error:

Kernel panic - not syncing: No init found.  Try passing init= option to kernel.

Copying over the previous kernel has got me back up and running, but what could I be doing wrong?  I've done plenty of 'sync'ing before rebooting after update.

Also, is nfsd compiled into the kernel?

Setting log level to 7 has thrown some more light onto this.  It would appear that the later kernels don't like either of my sd cards (one of them being the SanDisk Ultra II 2GB 15MB/s that should be 'pi compatible'). The error during boot up is:

mmcblk0: error -84 transferring data, sector 195313, nr 8, cmd response 0x900, card status 0xc00

and on the other card:

mmcblk0: error -84 transferring data, sector 197265, nr 8, cmd response 0x900, card status 0xd00

I guess I've just been unlucky here with my cards here.  What I really don't understand is why the 3.1.9.6+ kernel boots without any problems.

I am really just keeping up with the kernel on github

https://github.com/raspberrypi/linux

Just different config options, I'm sure Dom would have told me if there was a critical change.

Just for a laugh, precompile kernel + modules and firmware are here, you could graft them in easily enough

https://github.com/raspberrypi/firmware

With my own rootfs on a sandisk 2Gb class 2 I had bad experience, burned image again and no more problems. Don't know if sync actually does anything after dd but I have taken to using it

Incidentally, because firmware packaged off github, the default start.elf only gives 128Mb ram.

cp arm192_start.elf start.elf

That will give 192Mb ram after reboot

Think you can work out how to get 224Mb ram from that

In this new rootfs I enabled alsa sound. I thought if there was any problems it would be when messing with sound, I was wrong. A panic pointed to these modules.

Disable by editing /etc/rc.conf, Look for line where it says MODULES and delete everything between brackets, sync and reboot

pepedog, any chance you could remove the hard coded mac address from cmdline.txt next time round ?

the firmware then supplies a mac address in the RPF owned range based on the serial number

I have an alpha board which doesn't have serial.

If I had a production board I would have spotted that. Yes, next rootfs will remove

Thanks for the tips.

I purchased a transcend 4GB class 4 and I'm pleased to say everything is now working great - also much faster than on the Sandisks I was using.

There is a new kernel in updates, backup /boot/config.txt and /boot/cmdline.txt first, they will disappear.
I have new rootfs ready, awaiting inclusion to downloads page.
Why new rootfs? There was a bug in kernel which might have prevented updates.
Charges are -
Rootfs now ext4
NFS and ipv6 kernel modules
Latest kernel and firmware.
Above txt files never touched on updates
Hostname is alarmpi
Mac address removed from cmdline.txt
Default (700Mhz) CPU, overscan off, 720p default hdmi in config.txt
Dave

http://downloads.raspberrypi.o.....4-2012.zip
http://downloads.raspberrypi.o.....2.zip.sha1
http://downloads.raspberrypi.o.....ip.torrent

Default login: root/root

It isn't clear to me if we must use a new image each time you release one, or a pacman -Syu is just enough.

Hi sironitomas!

Arch Linux is a rolling release, which means performing an update leads always to the newest version of Arch Linux no matter with which version you started.

But there are is a reasons why you might want to use the newest image:

The new image uses ext4 instead of ext3. Personally the first thing I did with my SD-Card was to change file format to ext4. ext4 is faster than ext3, has more features than ext3 and personally I consider it to be more stable than ext3.

Cheers,

Maribu