ARMedSlack and Raspberry Pi?

Some more news - last night I cross compiled a kernel for the arm 1176 from a virtual x86 machine following the really great instructions here. I also expanded one of the miniroot filesystem archives from the Slackware Arm site (thanks Stuart) and ran the whole thing in the new Qemu arm1176 emulation. It booted and ran - very cool! So, given the Raspberry is supposedly compatible with Qemu's emulation this image should work on a real Raspberry Pi - good news.
My next step is to install the entire Slackware Arm distribution on top of the miniroot filesystem image and I'll have a complete copy of Slackware Arm running on an emulated Raspberry Pi. After that it's just left to try all this on the real hardware (when it's available). I also plan to recreate the original Slackware Arm installer's initial ram disk and replace the kernel so I can run the original Slackware Arm setup from a Rspberry Pi and also put a new kernel package in place. All this will mean installing Slackware Arm to a Raspberry Pi will be very easy indeed.

Bgeddy, nice! Promising story.

I am planning on buying one or more RaspberryPi devices (the "B" type with network and more RAM) and intend to make Slackware / ARMedslack work on it. Stuart will assist with the ARM specific bits that are new to me and the both of us will undoubtedly deliver some goodies.

It would be nice to fold this back into the main Slackware tree instead of having an updated ARMedslack tree, but we'll have to look and see how Patrick responds to this. It has already been one year ago when Stuart and I discussed what seemed to be a big promise at the time: a horde of ARM netbooks which would be unleashed upon the world. I guess the rise of the Tablet computer made the launch of ARM netbooks fail completely. But now we have this cute and immensely cheap ARM device, and Stuart hinted at the TrimSlice which also looks promising.

Remember that ARMedslack targets mainly low-end ARM computers. What Debian, Arch and (to a lesser extent) Ubuntu are doing is directly targeting these new more powerful devices. I want to see a real Slackware running on them!

Eric

Thank you Eric. It would be nice if you could get support in Slackware, but if Pat says no maybe you and Stuart could get official support into ARMedSlack.

Bgeddy, nice! Promising story.

Thanks Eric. I have amended the existing Slackware Arm directories, install launch scripts and image launch scripts to include my new kernel images. As I write this reply Slackware Arm 13.37 is running a complete install on the new version of Qemu emulating an Arm 1176 inside Slackware64 on my host machine. These emulated installs take a long time, as you no doubt already know, but I'll report back when it's done.

Overall I'm very pleased with the results of all this so far and can't wait for the hardware to be available.

My next plans are to automate creating a complete install of Slackware Arm on a suitable memory card on the host. This will make setting up a Raspbery Pi for Slackware Arm very simple and I can see a lot of folks being very interested.

It would be nice if you could get support in Slackware, but if Pat says no maybe you and Stuart could get official support into ARMedSlack.

That seems a distinct possibility now the main people are involved. I have good feelings about all of this .

These emulated installs take a long time, as you no doubt already know, but I'll report back when it's done.

OK - it's done. After jumping through a few hoops I now have a complete install of Slackware Arm (aside from KDE) running under Qemu emulating an Arm 1176 - the same chips as in the Raspberry Pi - all in 256Mb of main memory! Most excellent.
I am running X with FluxBox so can browse the internet and all the usual Slackware goodness. This is really good news as the extremely cheap little board from The Raspberry Pi Foundation should now be able to run Slackware Arm. So, in effect, you can have a Slackware machine for about £25 plus an SD card and a power supply which are also very cheap. I'm really pleased with this and there are loads of possibilities for these little boards which should be available very soon . Here we have it:

excellent! well I will hopefully be purchasing one as soon as they are available, so would love to help with armedslack (even tho i have no experience on ARM), sounds like a really fun project, and i've been looking for a worthy fun project =)

Hi,

I received this email today;

Happy New Year! We've built our first small batch of production boards. Apart from a minor error in the PCB design, they work very nicely, so we've decided to make ten of them available for auction on eBay. We have parts in stock for our first 10,000 units, and expect to be in volume production by the end of January. As always, for more details, check out our website at: http://www.raspberrypi.org Eben Upton Executive Director, Raspberry Pi Foundation

So the RasPi is not to far off for a release.

My raspberry pi board arrived last week. After a bit of head scratching it's now running Slackware Arm!

I got it working thanks to the info given in this thread, and special thanks to Stuart Winter for ARMedSlack.

In case people are interested, this is what I did. My starting point was the debian6-19-04-2012 image. I loaded this onto my sd card and it came up ok.

The downloadable images, eg debian or arch use 3 partitions:

/boot /dev/mmcblk0p1 (vfat)
/ /dev/mmcblk0p2 (ext4)
swap /dev/mmcblk0p3 (optional but you will need it)

/boot contains the proprietary stuff for booting and the kernel image (thats why I needed the debian image). The boot directory in the root filesystem is ignored.

I planned to start using the debian configured kernel (I haven't got around to compiling my own kernel yet), so using a cardreader I pinched the /lib/modules/3.1.9+ directory from the sd card, as naturally this dir is on the / partition. (I also took the contents of /opt/vc which contains some multimedia stuff that I have not explored yet).
Next I resized the sd image to fill up my 8Gb card using parted (guide on the RPi wiki)
Then I deleted the entire contents of the / partition, and copied Stuart's Slackware current mini root archive there, and extracted it. At this point I modified the /etc/fstab in the miniroot filesystem to reflect the layout above. I also put the 3.1.9+ modules into /lib/modules.
Installed card into the pi, booted, and now have a minimal slack install running, and that install gives me installpkg, upgradepkg etc...

Here I had to hash out the line in /etc/inittab:
#s0:12345:respawn:/sbin/agetty 115200 ttyS0 vt100
as I was getting those "respawning too fast, disabling for 5 mins" messages

I rsynced the Slackware Arm -current branch to my main Slack box.
I guess here I could have done something clever with NFS or something, but I just reinserted the sd card into the reader and added a new directory containing a cut down version of the slackware arm package directories.

Back on the pi, and used the upgradepkg --install-new command to expand my system to a (nearly) full install.

Rebooted one more time, and I have Slackware running on the pi. I have successfully run fluxbox and xfce.

I get a warning message at boot, rc.S doesn't like the / partition being already mounted read-write, and I have to press enter to get booting to continue, I'm not sure how to fix this yet, but everything else is working fine.

If anyone was interested I would consider making an installable image for others to use, though I think bgeddy has something similar already?

tobyl

Just in case it's of interest.

http://www.linuxquestions.org/questi...review-946660/

mine is arrived too

I want to try a clean install of -current and I'm in the head scratching phase thinking on how to boot the armedslack installer (preparing a custom initrd with the debian kernel/modules?)...
any hint is appreciated (a lot ).

there is also a premade 13.37 image available.

I'm having a look at the config.txt (thanks GazL for the pointer); as I said, I would prefeer (if possible) to use/test the installer with one partition: I'm starting to think that I'm making things hard for myself on purpose.

I'll think about it later: being too impatient, I already wrote the premade image on the SD and already playing with it

$ cat /proc/cpuinfo 
Processor	: ARMv6-compatible processor rev 7 (v6l)
BogoMIPS	: 697.95
Features	: swp half thumb fastmult vfp edsp java tls 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xb76
CPU revision	: 7

Hardware	: BCM2708
Revision	: 0002
Serial		: 00000000f4935419

I used this SD (from the choices available here), seems pretty fast.

hi ponce

I read that the GPU binary contains the first stage bootloader, i.e I guess its hard coded to look for the first partition on the SD card, i.e. /dev/mmcblk0p1(which MUST be vfat - this could scupper your plans) From here it uses a binary called start.elf which I think loads whatever kernel.img it can find in the same partition. Unless you want your entire filesystem on vfat, you are a bit stuffed.
Also you/I need to think about what we want the pi to do. It makes some sense to hand off the OS stuff to a hard drive as soon as you can, because the SD card will wear worse than a usb connected hard drive, plus you will get more storage.
The enhanced multimedia capabilities of the pi's arm chip have not been ported yet as far as I know, but when this arrives, I for one am likely to want more storage than even my 16GB SD card can offer.

By the way, the aforementioned kernel.img is simply your standard vmlinuz that you get from compiling a kernel, but a script (available on the net) converts it to the img format. If you have modules, you have to place them in the /lib/modules manually. (I personally never use an initrd, I just compile-in any stuff I need early in the boot process, so I don't really know what would be involved for that).

Loads of good info here if you didn't find it already:
http://elinux.org/RPi_Advanced_Setup

Thanks for the infos/hints tobyl, I hadn't spotted that page yet: I'm having a look also to the kernel compilation guide, hoping that the needed fixes had made in time for 3.5 (I'm referring to a Greg's post).

I think for the normal use of the device the SD should be ideal, avoiding having to power also an external usb drive, but I'll test with it (now I've attached it to the usb connector of the tv, that gives it enough power), I'm planning to do some tests with NFS too.

I've tried to collect some stuff, if can be useful: the kernel config, various info from /proc, an image of the boot partition of the 13.37 install and the modules folder (here).

I'm using now armedslack-current and seems to run a little bit faster
to install it I've:
- uncompressed the latest miniroot (updated two days ago) in the root partition of the SD containing the armedslack-13.37 preassembled image, deleting before everything but the kernel modules;
- added "/usr/sbin/ntpdate pool.ntp.org &" to etc/rc.d/rc.local (no hwclock on the raspberrypi);
- modified etc/fstab and applied some small fixes to etc/rc.d/rc.S, etc/inittab and etc/hosts found in the dedicated topic on raspberypi's org forum (thanks sorinm!);
- booted the thingie from the SD;
- set the timezone with timeconfig;
- mounted via NFS the armedslack-current folder and installed the rest with "upgradepkg --install-new", as I want to try all the stuff;
- to fix fonts under X, I run pkgtool -> setup (but I think I should also have just rebooted to let the init scripts take care ot that).

and armedslack-current is up and running

I've built also some additions to enjoy it more:
- the latest LXDE desktop and qupzilla from my repository for current;
- a new kernel (following the guide above), applying the bfs and bfq patches (and using the two) and switching from SLAB to SLUB too.

now I'm having a look at distcc to ease the pain of building stuff (the kernel alone needed 6 hours ), and I'm appreciating a lot the work of Stuart Winter and the docs he has written.

Originally Posted by ponce ... now I'm having a look at distcc to ease the pain of building stuff (the kernel alone needed 6 hours ), and I'm appreciating a lot the work of Stuart Winter and the docs he has written.

distcc is very nice, I've often used it with Gentoo. But since you will need a toolchain anyway when using distcc, I'd consider to crosscompile the packages for armedslack.
Once when I ran Gentoo on three computers one of them was a netbook. I managed to configure distcc in a way that all buildingjobs were distributed from the netbook to the other two computers. But the netbook was overstressed anyway with only distributing buildjobs.

I remember I've read anywhere in the Alien Bob's blog that Linux from Scratch has a very helpful tutorial for crosscompiling.

Markus