ArchlinuxARM on Raspberry Pi

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

maribu said:

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

This should be it from now on. As maribu said, changed rootfs to ext4, there were kernel problems that might have prevented updates, and update problems where the 2 config files might disappear.

Looks like midori package is broken, btw, might be something to do with libwebkit

I tried Arch yesterday but got bizarrely roadblocked running X with lxde because my mouse wouldn't respond. It's seen in

/proc/bus/input/devices as a Microsoft Basic Mouse - which it is - and this rodent works in Debian. Both udev and evdev are installed. LXDE comes up fine, it just won't move the pointer.

FWIW, installing X & lxde was somewhat error prone - if I tried it all in one hit I usually got a kernel panic relating to timers & sound. If I did an update then installed xinit then lxde it survived unscathed.

Any thoughts anyone on getting this mouse going - I've ordered a cheap & cheerful mouse plus a branded mouse from eBay to try them out but I'd like to think that the MS mouse was pretty standard.

Which image did you burn, because the panics are a symptom of the old one, see my sig for new image.

Tried both 19 April and the 27 March - will download from sig and try that this afternoon. Any thoughts on the mouse issue?

The latest image is the 29th of april. Pepedog has posted it on the 1st of may (few posts back).

Not sure why it's not on the downloads page yet. Will get onto Liz and Eben.

May want to try that