ARMedSlack and Raspberry Pi?
 

Hi,

Does anyone know if and how I could install ARMedSlack 13.37 on a Raspberry Pi when I get one? The SoC is a Broadcom BCM2835. The Raspberry Pi cannot boot from USB, it boots from an SD card. How would I go about installing ARMedSlack on it?

Does anyone know if ARMedSlack supports the Broadcom BCM2835 SoC? I know the site says QEMU and Marvell are the two supported types, but I thought an ARM kernel would boot on any ARM architecture CPU as long as the CPU was at least the version of ARM it needed, am I wrong? Also, does anyone know how to get the installer on an SD card?

Perhaps it is wise to have a little patience and wait until the device is actually available.
We can speculate all we want, but you will only know for certain if people can get their hands dirty.

In time, the information on how to write the SD card will be available here: http://elinux.org/RaspberryPiBoardBe...ng_GNU.2FLinux

Eric

You're right Eric, I am jumping the gun a little. Do you plan on getting a Raspberry Pi? If so, do you plan to try ARMedSlack on it?

Not attempting to answer for Eric but just to let you know - I plan on getting one of these and running ArmedSlack on it. As Eric suggests, I'll maybe wait to see what reports come up on the device before splashing out - even though they are amazingly cheap!

Yeah, I will probably wait about a week or 2 after the R-pi comes out just to make sure there are no issues with the design. I hope ARMedSlack works out of the box, or with minimal changes. bgeddy, could you make a thread about it when you get one?

I see that they are going to ship this with debian. If this is stock debian you shouldn't have any real problems with armedslack, as the mainline kernel should support everything. I have had a cursory look at the project and couldn't see if they intend to run a heavily modified debian install. The reason that I point this out is some embedded devices need a drivers that are outside of the mainline kernel tree, the dream plug being a case in point. I reckon that the geeks will be out of the blocks pretty quickly on this one, so you won't need to wait long for this to be running :)

Sure thing. I installed ArmedSlack under qemu some time ago using the instructions found here and it worked fine but took quite some time. This was not on an arm1176 emulation however.
The latest version of qemu, qemu-1.0-rc3 is here and I have just downloaded and built that. This enables arm1176 emulation but unfortunately it won't boot the previous mentioned ArmedSlack install.
CNXSoft mentions problems with standard kernels on the Raspberry here and even supplies a prebuilt arm1176 kernel and Debian system. I have downloaded this and it run's in the new qemu arm1176 emulation fine. All this seems to indicate that the Raspberry may well not run the bog standard ArmedSlack kernel.
CNXSoft goes into details on building a new compatible kernel so even this won't be a show stopper.
The guy on this page mentions running a Raspberry emulation and there's more useful hints on that page.
The newer version of Ubuntu will run the latest qemu and there are pre built packages available - again linked to on this page - I have built this on Slackware and ran it on a Ubuntu VM as a test but on neither system will the ArmedSlack installation boot up.
This is by no means a show stopper but it does make initial installations a little more awkward on this machine. All these test are done under qemu though so they may not be a true indication of the real thing however other folks seem to suggest the same problems so beware.

So all that really needs to be done is just recompiling the ARMedSlack kernel to support ARM11? Also, more then likely someone will post a kernel for ARMedSlack already to run on the R-Pi, then all that needs to be done is replacing the kernel in the ARMedSlack tree that I would download, right?

Well its a little more complicated than that as you need to think about the initial install. If you are running the setup on the Rasberry itself it will mean you'll need a suitable kernel and re-jigged initial ram disk for the setup to boot to.

When compiling the kernel you may compile it on the Raspberry itself or use one of the freely available pre built kernels. You may also cross compile a kernel on a PC host as there are tools available. However think about how you are to first install Slackware on the hardware. If you plan on running the standard install on the Raspberry itself, as I mentioned, you'll need to modify the associated initial ram disk that setup boots to and a corrected kernel. This means recreating the bootable image for the device and the associated software for setup. The other way is to mount the sd card on another machine, format it and install Slackware ARM from the other host along with the corrected kernel. Again this is a little more complex than booting the install routines from the Raspberry - but all very doable. There are actually quite a few ways of achieving this.

Incidentally. I have left a message asking for any advice on the #armedslack channel on freenode.net and also sent an email asking for advice to Stuart Winter, the creator of Arm Slackware himself. I've only just made these requests for help and it's early days yet.

Myself I'm very confident it's all going to be relatively easy and I'm really looking forward to the release. I see there is to be an initial early release to Qt developers so they can cross compile their software - I wish I was one! Also - Nokia and ICS have 400 boards to give away free to Qt5 software developers.

Here's some more useful links - Slackware Arm, Raspberry Pi Forum, Raspberry Pi one eLinux.org - Embedded Linux Wiki and Raspberry Pi on Google+,CNXSoft – Embedded Software Development and the ARM company's details on the Arm1776, ICS Raspberry Pi Blog

If the installer is not able to boot (perhaps due to the amount of RAM it consumes or because it's not useful since it doesn't contain any support to install to your target device), one of the options is to use the mini root filesystems that
I provide for 13.37 or -current. When I was building the first port of Slackware to ARM I had the hard disk in and out of the ARM PC into an x86 PC to install the packages more times than I care to remember, but the miniroots remove that
necessity.

Oh - I haven't seen any!


It should be pretty easy to get ARMedslack working on it. The userland is built for the lowest common denominator (armv4) so it won't be as performant at certain tasks, compared to say Ubuntu or the Debian port that is aimed at a higher
baseline, but it'll still work. Then it's the usual case of building a new kernel.

People have already got ARMedslack running on the Sheevaplugs off an SD card.

I'd consider buying a Rasperry PI myself and just making it work - adding a new kernel and some instructions; but to be honest - I have absolutely no idea what I'd do with a Rasperry Pi! I can't use it as a build box since it has too little RAM, and I have enough ARM devices already. Hmm..

ARM doesn't work like that unfortunately - it'd be great if it did!
The ARMedslack userland will run on anything greater than an armv4 (the lowest common denominator that still exists in ARM devices in use today -- mostly), but you always need a specific kernel that knows how to address the *specific* ARM device you're using.

It's explained here:
http://www.linux-arm.org/pub/LinuxKe...ph-porting.pdf

@drmozes: Hey Stuart - great that you came in and thanks for the tips. The mini root option will certainly be a great help to a lot of people.
I posted on #armedslack around midnight (UK time) last night and sent the email around the same time to mozes@slackware.com - sorry if I've used the wrong address!

I have been looking at the Arm Slack mirror here and noticed lots of useful stuff - /armedslack-devtools/ particularly but there's loads of great resources there - thanks again for all the work.

They're not much money, and I'm sure you could figure out something to do with it. If anything, supporting R-Pi with an official build of ARMedSlack is a good reason to get one, as R-Pi is a big project, and I am sure there would be quite a few users who would use ARMedSlack if there were an official build that was easy to install and didn't need to be modified. It would really help both ARMedSlack and R-Pi if you made an official build. If you could make an official build for it, that would be great, I'm sure a lot of users would love that.

I haven't seen anything still, it's best to join the mailing list and ask there. If I'm going to answer anything that's to do with the project, it's usually beneficial to more than just the person asking it.

I've been reading a little more around the Raspberry pi. Once the devices have shipped and the support is in the kernel.org kernel source I *might* have a look at it. I won't promise anything however, as the excitement level is currently only 0.1 on a scale of 0-10; my goal is for a desktop or netbook ARM machine. I'm much more interested in the Nvidia "Trimslice" at the moment.

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.

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.
That seems a distinct possibility now the main people are involved. I have good feelings about all of this :D.

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 :D. Here we have it:
Attachment 8490

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 =)

Member response
 

Hi,

I received this email today;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 :D ).

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 ;)

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 :o ), 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

I received my pi two days ago. Ran with debian image the first day and found it a slow boot with some issues I didn't stick around long enough to figure out. After apt-get updates and loads of sudos I had wired network up and ran LXDE but it wasn't as responsive as I would have liked. The next day I ran the arch image. Very fast boot. I got wireless up and pacman'ed what I was supposed to need for LXDE but never got it up and running.

Today a downloaded the above image ponce pointed out above and ran it on my pi. What a difference! The default wm is XFCE but it was much better than the debian experience. Add a user, run netconfig then /etc/rc.d/rc.inet1 eth0 and I have a wired connection. Edit /etc/inittab to run level 4 and Bob's your uncle. I'm home.

Much better graphics out of the box with full resolution on a 20" monitor. No black framed 800 X 600 as was the case with debian.

The build script for armedslack-current's distcc toolchain is on the FTP site.
You just need to build it and then you can use distcc on the ARM machines.

thanks a lot Stuart, also for that magic script!

Announcing a boatload of Raspberry Pi goodies here: http://daves-slackbuilds.comlu.com/raspi/

There's a Slackware ARM Installer image, up to date kernel and boot packages, a package that hacks fixes for several annoying problems, some patches for xorg on -current, and XFCE 4.10 ;)

The new kernels and boot firmware are a big improvement.

I hope it all works properly. If it does, Enjoy :D

Cheers!!!

Great! I will try it as soon as possible, but in the meantime thanks a lot for your work, Dave! :)

I "expressed an interest" in Raspberry Pi ages ago (can't remember exactly when), and have heard nothing since. It might be that they're picky about email addresses. From:
http://uk.rs-online.com/web/generalD..._--_-questions

My email address isn't admin or sales@, though. I'm not desperate, anyway. Probably **** it up, like I've done with my SheevaPlug. :)

I'm trying to create a script for generating a armedslack image for the raspberry pi, it looks like everything is correct and it should boot but it doesn't. On screen only the cursor keeps blinking.


can somebody give me some pointers what needs to change to make it bootable?

I don't know if the following pointers solve everything, but here goes:

'bs=1MB' in the dd command means 1*1000*1000, not 1*1024*1024. Therefore the image is smaller than you think. You need to use 'bs=1M'.

You need to allow for the partition table overhead before partition 1. You can see the error messages when the script is run:

Best fix would be to calculate a smaller swapsize instead of setting it as a constant:

Other stuff:

arm192_start.elf gives 192 to Linux and 64 to the GPU, arm224_start.elf gives 224 to Linux and 32 to the GPU, so the comment is the wrong way round ;-)

Slackware prefers the root filesystem to be read-only until it's remounted, so add 'ro' at the end. If you're not using the serial output, change 'console=ttyAMA0,115200 kgdboc=ttyAMA0,115200' to 'console=tty1', like this:
But you have some good ideas in there too. In particular, the e2fsck.conf idea is great and I'll probably steal it! Thanks!

Edit: Damn, I forgot to mention, the ARMedslack devs package doesn't include device nodes for /dev/mmcblk*, and that might be another problem. Create the nodes like this:

Another Edit: Someone else (way above my brain level) reminds me that udev is active from very early in the boot, so the static device nodes are unlikely to be important :cool:

while i wait for a raspi, i am using qemu to "get accquainted" ..... any way to load the armedslack image into qemu? i don't have enough experience with qemu to "automagically" get the command line right.....

You can't run the Raspberry Pi boot images on qemu -- qemu is more like a different arm machine in its own right, with different 'hardware' than the Pi. The Pi boots using its GPU and SD card, but qemu doesn't have them. Also, Linux kernels for ARM are not interchangeable between machines, so you can't use a Pi kernel on qemu, you can't use a Tegra kernel on the Pi etc etc. But (apart from booting and the kernel) everything else in Slackware ARM is transferable between qemu and the Pi.

If it's any consolation, I actually found qemu more difficult -- and I'm still waiting for my Pi too, but I've borrowed one from a jammy **** who has three!

Quite a few distros have been:

http://www.google.co.uk/#hl=en&gs_nf....,cf.osb&cad=b

FYI, it looks like that farnell will open for general orders (without registering interest) on july 5th.

http://uk.farnell.com/jsp/bespoke/be...aspberryPi.jsp

Thanks, ponce. Might try to get one then.

Wellll, that's not the same thing. Those links show people running non-Pi 'versatile' kernels (which are already available in ARMedslack). Also, the two images I've prepped are partitioned in a way that's obvious for the Pi but nonobvious for qemu (the root partition is partition 2, not partition 1, because on the Pi /boot *must* be vfat, and *must* be p1, and *must* contain the closed source boot blobs). Also also, I've not included the kernel modules for 'versatile' under /lib/modules. I could, but would the extra space be justified? (Actually, thanks to your question, I'm now thinking maybe yes :) )

So, although those links purport to show people running Pi stuff on qemu, they've done it by ignoring everything that makes the Pi a Pi and using qemu-specific stuff instead.

You could get the same effect with my Pi miniroot I've prepped by adding the versatile modules and then specifying -kernel blah -append "root=/dev/sda2" etc, but if you're going to do that, you're be better off using the official ARMedslack miniroot image -- it's already got all the right stuff for qemu.

As for the installer image, again, if you want to do that in qemu, use the standard ARMedslack installer. My RasPi Installer image is quite different. Slackware's installer images, including ARMedslack, have everything in an separate initrd.gz file. Unfortunately, you can't (currently) use a separate initrd.gz file on the Pi, because the GPU based bootloader doesn't support it. You have to build the initramfs directly into the kernel image itself. That's why you can't use the Pi installer on qemu, and you can't use the qemu installer on the Pi. But really, that's the *only* structural difference between the two installers.

Except for the boot and the kernel, you aren't losing any part of the Pi experience by using standard ARMedslack on qemu -- after all, the whole point is that the Pi experience should be the *same* as standard ARMedslack.

Edit: Umm, I think I may have misunderstood the original question. Yes, you **CAN** run standard ARMedslack on qemu, and there are instructions here INSTALL_QEMU.TXT and tools in the armedslack-devtools. What you can't run directly on qemu is the Pi-specific stuff I've been cranking out. For pragmatic reasons that could change, but the definitive official standard qemu implementation is official standard ARMedslack, the original and still the best :) Sorry for the confusion!

Note that if somebody wants to install armedslack-current inside QEMU, they first need to download updated kernels from here:


http://armed.slackware.com/fixes/versatile/

Remove the same named packages/files from the -current tree that they rsynced, and replace them with those.

The next (rather large) batch of updates to -current will have this problem corrected, but until then users need those kernels.

i've been running a debian "rpi simulator" (maybe that's a better name for it, since qemu doesn't emulate pi hardware), and since some software was built specifically for the pi, it does not run in the versatilepb machine in qemu... specifically so far i have found omxplayer and the midori web browser dump with an "illegal instruction" error, and there is no sound device for qemu-system-arm, and since the pi sound device is a bcm-chip specific device, alsa complains and doesn't initialize. this is with the Sbopkg of qemu 1.0.1 installed on slack 13.37 but i haven't seen anybody else mention these problems on the rpi forums as yet...

maybe i'm missing something, but where are the makeimg and installer_launch scripts located?

In the armedslack-devtools, subdirectory qemu, subdirectory helper-scripts

http://slackware.org.uk/armedslack/a...elper-scripts/

thank you.... much appreciated