A bit of Context
When in the course of 2011 it became apparent that Netbooks saw interesting sales figures, especially the low-powered Atom netbooks, often running some form of Linux, it was only natural that hardware vendors started talking about even lower-power portable devices. I was thrilled by the fact that an ARM powered laptop could be launched in 2012, and when the Raspberry Pi story began in earnest at the end of that year, I decided that I needed to do a port of Slackware to the ARM architecure in order to be prepared for the flood of cool devices. But hey! I hear you say… an ARM port of Slackware already exists! Yes indeed, Stuart Winter had been developing his SlackwareARM (formerly ARMedslack) port for a long time. In fact, the characteristics of the ARM based devices were so different from regular Intel-compatible computers that ARMedslack package build scripts had to be vastly modified and the sources heavily patched to produce working packages. Also, since Stuart is working alone on the port, he chose for a large degree of automation of his build environent and -scripts which made the source tree of the ARMedslack port pretty much incompatible with the official Slackware source tree in terms of interchangeability. But my goals were different:
- I wanted to create a port using SlackBuild scripts which are compatible with official Slackware – i.e. Pat Volkerding should be able to just grab an unaltered script for the ARM port and build a 64-bit Slackware package with it. And eventually, the ARM port would be able to merge with official Slackware sources
- I want to target modern ARM architectures. SlackwareARM targets older generations of ARM CPU’s – notably those are small embedded devices (like your home NAS, or WAN router) that lack hardware floating point support or with a somewhat older ARMv6 CPU (the Raspberry Pi). But I wanted to use my port on “powerful” ARM tablets, and/or laptops and squeeze every bit of performance out of those. While Stuart’s SlackwareARM will work on the new devices, my port will not work on those older devices!
- For me this was going to be a learning experience. I knew very little about ARM architecture, and I felt that I had to get intimately familiar with the many differences between a regular Intel-compatible computer and an ARM based device. Therefore I wanted to build a new Slackware from scratch, not re-using Stuart’s work unless to help me get the concepts clear. I did pick Stuart’s brains a lot though!
- Because I am an old and forgetful guy, the whole process should be properly documented. Creating the 64-bit port of Slackware in 2008/2009 took me a lot of time but I did not write down all that I did, and I have regrets about that.
So, I bought a TrimSlice computer, which is a small-formfactor fanless desktop computer basically, sporting one GB of RAM, a 32 GB SSD harddisk and a dual-core ARM CPU. I did use the donation money which had been slowly accumulating up to that point and shelled out 350 euros. Unfortunately, the little computer never became the hit I expected it to be (it is a real cool bit of hardware) and eventually my porting effort stalled for lack of motivation… I was not going to spend hundreds of hours on a port for a device which would be used by only one Slackware user… me.
I almost convinced myself to kick some new life into the port when ZaReason launched the ZaTab, a tablet which allows full root access and had fairly open hardware (unlike most tablets which are inaccessible pieces of shi^H^H^Htech). But again, the specs were not so great, and it never became the hit which would have convinced me I should spend hundreds of hours on getting Slackware running on it… let alone giving it a proper touch interface using KDE’s Plasma Active. So, that idea dried up as well.
And since this week, the Samsung ChromeBook can be bought in dutch shops. I had held a few of these laptops in my hands when friends and collegues brought them to the office. All of those were imported from the US, and they looked/felt/handled great. But, ChromeOS? They should be running Slackware, is what I am convinced of. Unfortunately, being the sole provider of income for my family and with a job that pays average, and without pay raises for a long time, I just do not have the financial room to buy a 300 euro laptop just to hack on it. That’s when I decided to ask for some financial backing.
Raising the Money to buy a real Device
What I did not expect to happen… I asked for 300 euros and lots of people donated in the 24 hours that followed. One of those donations was 299 euros (!) which was in itself enough to reach my goal. The supporters who left me a message basically said “do what you like with the money” which means that I have quite a bit left (more than 600 euros!) now that I have actually ordered a ChromeBook. That money will go into the purchase of additional hardware. I am going to finish an ARM port first, and then decide if the new hardware should be an ARM tablet, or another ARM based computer for which there is enough interest to make the work worthwhile. However, if any of you decides that you do need your money back, I will of course comply, without hard feelings.
I want to mention the people who made it possible for me to buy this computer. Some of them asked to remain anonymous and I will respect that. I will also not mention the amounts of money – I value all of your contributions equally. People paid what they could afford and that alone, gives me a warm feeling about our little community. Big thanks go out to (and I will keep this list updated):
- Daniel Cash
- Gudkov Ilya
- Abdur-Rahman Rozell
- Willy Sudiarto Raharjo
- GREGORY ZAYACHUK
- Gabriel Yong
- Michael Stewart
- Jaime Lee
- Andreas Vögele
- Patrick Volkerding
- Grzegorz Gibas
- FERENC KURUCZ
- Thomas Løcke
- Korneliusz Jarz?bski
- Etienne Casaert
- Gil ANDRE
- Phillip Bevan
- Matthias Hambach
- Thiago Diniz Macena Silvino
- Didier COURTAUD
- Aurelio Bignoli
- Peter Vajo
- Ventrice Humphrey
- Guido Ascioti
- Corey Wells
- Henry Fanson
- Jason Laprade
- Roberto Puzzanghera
- Laurent Chamontin
- Christophe NGUYEN MINH TAN
- Neil Dick
- Chekkizhar N
- christian laubscher
- Jeff Ruby
- Andrew Conway
- Ger Wesselink
- Tomasz Ratajczak
- Ioan Szentpali
- Gunnar Florus
- Charles Coffee
- Isaque Galdino de Araujo
- Giovanni Milanesi
- John Johnson
- Marcin Herda
- g miller
- ISIS Productions, LLC
- Scott Searcy
And 4 further anonymous backers.
The Plan
- I will resume my ARM hard-float porting effort (yes, this may affect the update frequency of other packages I maintain).
- That porting effort will not be “behind the curtains” like it has been so far. I will upload packages and scripts and will welcome ideas and feedback
- The Chromebook will be the target hardware to build a bootable Slackware image.
- I will upload the from-scratch cross-compiler and minirootfs which I created already
- I am going to document on docs.slackware.com about porting to a new architecture from scratch.
- I will also tickle Pat Volkerding’s interest in the ARM port – seeing that he too, donated, tells me he is interested 🙂
The Tools
I am going to work on cleaning up my existing set of scripts, and then build a place to host all of that. I had been thinking about setting up a repository on GitHub, but since I still need to host my binaries and packages, so I think I may just setup a GIT server on taper.alienbase.nl. After all it already is my primary package mirror, and it also hosts the Slackware Documentation Project. I have to wait for the delivery of the laptop anyway, and I should at least attempt to boot my current half-way port on the TrimSlice before continuing on the ChromeBook (the TrimSlice has been running SlackwareARM until this moment…)
26-march-2013:
Update: I have not had the time to play a lot with the ChromeBook yet. What I have been concentrating on instead, is preparing a git repository for the cross-compiler & rootfs scripts, and for the package source tree: I am running way behind slackware-current but still, I have 876 packages compiled already… and their SlackBuild source directories will go public through a git repository as well. My git-fu was quite rusty, and I have been reading the git book chapters on setting up a git server. I am now playing around with commit access versus read-only cloning and getting a feel of managing it all. I will not be using a commercial provider like GitHub, as I simply consider this another learning experience 🙂
The Device
21-march-2013:
Well, here it is, right after running through the initial configuration.
I did not have much time at work, where I had it delivered this morning. However I made sure that I did a hard reset of the local configuration in order to bring it into “developer mode” where you get root console access to the underlying ChromeOS. The instructions for entering developer mode can be found on the Samsung Chromebook specific page on the Chromium OS Wiki (Chromium OS is the Open Source variant of the ChromeOS which runs on the laptop).
There is no more time today, but this weekend I am going to dump my ARM rootfs on a SD card and see if the ChromeOS kernel will actually boot my binaries. Fedora and ARM community have a page on that topic and Arch has a bootable image even, which I could inspect. I’ll talk to Stuart too.
The Goods
The scripts, patches and tools are maintained in a GIT repository: http://taper.alienbase.nl/gitweb/
Source tarballs, tools and scripts can also be found here: http://taper.alienbase.nl/mirrors/alienarm/bootstrap/
I also uploaded the packages which were created from those sources: http://taper.alienbase.nl/mirrors/alienarm/slackware/
If you want to play with a small root filesystem containing armv7hl binaries (the one that gets created by the “stage1.sh” bootstrapping script) you can download one here: http://taper.alienbase.nl/mirrors/alienarm/rootfs/armv7hl/tegra/
Cheers, Eric
Slackware is the *perfect* distro for the RaspPi! The next best distro to be had for it is Arch, but a little arm board doesn’t need automatic updates, etc… etc… Just slap on Slackware and you are good to go. Thanks Eric!
wow..great… I must buy, when it comes to India, for 2 reasons,
1. to learn slackware porting
2. want to have a laptop, without Window$ key. [ System76, emperror linux systems are toooo costly for me 🙂 ]
god speed, Eric 😉
Awesome news !
Hope you’ll buy a Pandora with the extra money ;^).
My brother is traveling at the end of this month so he’ll be bringing mine when returning… I’ll have to wait until april 🙁
I’ve been running a bunch of java benchmarks on my asus netbook and apparently this arm chromebook is packed with twice the juice. Benchmarks numbers vary depending of the desktop environment that launches the browser but afik, the arm chromebook run over 3000 mark on octane while this asus netbook haven’t pass the 1200 for that particular test… so i really can’t wait to see what’s slackware can do on this platform… specially hardware graphics acceleration.
Not half bad,
Which hardware parts can be changed?
i.e can you install more RAM or a diff CPU on it?
Excellent news, and very timely for me. I’m halfway into porting slackware for armv6 hard float and was not looking forward to reproducing that effort for armv7. I’m happy to contribute via testing, debugging, updating slackbuilds, building packages, etc. What’s your estimated time frame for posting a mini rootfs?
-Ahau
Hi weput
Stuart Winter was already complaining that he was unable to even start X… the driver for the Mali T604 was not working.
We’ll see about that later. First I want to have some console Slackware running on it! But getting a git repository up and running is first priority. and I have to read up on gitolite.
Eric
cmyster,
No hardware can be changed at all! That makes it interesting as a target for development, you know exactly what you are building for.
Eric
Ahau,
When I see Slackware booting on the Chromebook, I will post the SD card image I used for that, plus instructions for creating that SD card image using the rootfs I will also upload. Won’t be this weekend I guess.
Eric
i know the hardware aceleration graphics is a midterm goal cause as this moment about 98% of the arm chromebook hacks i’ve found are related to installing ubuntu on it…
and ubuntu has no hardware acceleration yet. anyways, i like the machine for what it is…
as soon as workable linux distro is available, with libreoffice and the whole sheebang there is a world of cheap yet powerfull modern devices ready to be produced at mass scale.
twice the procesing power at half weigth/power consumption and cheapo… that’s what the platform promises
Just bought a Samsung Chromebook and I’m looking forward to run Slackware in it!
Hi Eric,
I am reading up on your http://taper.alienbase.nl/mirrors/alienarm/bootstrap/doc/bootstrap.txt .
I have a question about your last sentence: “When that is done, your rootfs will be in good shape to build a complete ARM Slackware distro package tree from scratch.”
To my understanding, the rootfs is the slackware distro that will be built during stage1.sh (and stage2 ?) execution. So why do you say that the ARM slackware distro will be build Aftewards (and how?). Thank you very much for your help.
The “rootfs” contains a very limited set of software. It contains the minimum set which is needed to bootstrap the remainder of the distribution on an ARM platform.
The stage1.sh script is executed on a Slackware machine (32-bit or 64-bit) and cross-compiles a very minimal rootfs. That rootfs plus the stage2.sh script is then copied to an ARM computer. The stage2.sh script will then compile additional packages directly on the ARM computer to create a more functional rootfs.
If you look inside the “recipe.d/” directory, you will see the packages that get natively compiled on the ARM comptuer into the ARM rootfs: all those that do not start with XX. That’s 31 packages out of Slackware’s 1000+ package set.
The purpose of the rootfs is that you transfer it to an ARM computer and build the rest of the packages on the native platform instead of cross-compiling them. The rootfs itself can be considered as a very barebones Slackware distro if you want.
Eric
I was already wondering when someone would notice that “alienarm” directory. I was preparing a git repository and wanted that finished before announcing anything. The “alienarm” is the work I did so far, but it is way behind slackware-current and needs a lot of touch-ups.
I will also upload the ready-built rootfs for people to play with, somewhere in the Easter weekend when I have time. But first I want to load that rootfs onto my ChromeBook and see what happens…
Eric
we are all waiting for your rootfs report…
I have to admit i’m sort off getting the cold feet on buying the machine… I work for my country government and they told me they’ll get me a new corei5 based ultrabook… but that may never get in my hands anyways..
I just wanted to extend a big “thank you” for the scripts and sources you have put together in alienarm — I understand they’re still behind slackware-current, but with them I was able to surpass my previous two weeks of effort in about two hours 🙂 I’m about halfway through compiling stage 2 at the moment. I’ve modified the scripts so they build for an arm1176jzf-s (Raspberry Pi) target.
Cheers!
Hi Ahau
Good to hear that the rootfs scripts are compiling packages for Raspberry Pi. I hope you did not have to change anything else than the CFLAGS?
Eric
Hi, I tried commenting last night but for some reason it didn’t post (maybe too long?). Yes, I changed the CFLAGS and the gcc options for cpu and tuning. I jiggered a couple things since I didn’t add an armv6zk kernel config and I just used the local sources you provided, but that’s it.
I’m having some issues recompiling gcc at the moment, I probably need to add something else or build it with a more restrictive config than the slackbuild that assumes a full system…
Hi Ahau
That is a bug of the sqlite driver which I use for my blog. The “feedback” page of this blog states the following:
“””
If the blog refuses to accept your post, then perhaps you are affected by a bug in the QSLite plugin. Check if your post contains a string of text which is enclosed by the characters ( ). Is there a pipe symbol or a comma inside those round brackets? Try to remove those and re-post your comment.
“””
Perhaps it was that which prevented you from posting. I saw the empty posts in my log but that does not mention the IP adress or who was the poster.
So, the stage1 gcc compiles but the full gcc (using the SlackBuild) fails? Perhaps that SlackBuild needs tweaks for armv6 jst lke I had to tweak it for arm7.
If you find a working patch I can incorporate it into my script. Would be nice if the stage1/stage2 scripts work out of the box for Raspberry Pi.
Cheers, Eric
I have been updating the SlackBuild scripts of the A and AP series, because I want to upload a working rootfs and an initial set of armv7hl packages this weekend. I will see what else I can polish and build, preferably kernel-headers, glibc, gcc, llvm and as many packages in L series that I can manage.
I have been running my own SlackARM on the ChromeBook this week, but unfortunately it looks like I need a newer X.Org. My first try was with the X.Org that was part of Slackware 13.37 but that refused to start. A partial upgrade of X.Org related packages made X.Org at least try to move some pixels but after a few seconds a series of FBDEV errors would abort the X startup.
I guess I need the X.Org of Slackware 14 or -current for this ARM laptop.
Eric
Nice to hear you’re busy on that !
I’m impatient to boot your rootfs on Open Pandora.
Why aren’t you simply on -current as the core of the work ?
Because Pat changes slackware-current so often that I would end up re-doing a lot of what I already did.
I tried following -current for a while but I can assure you that once you get behind only a few days, you will not be able to catch up unless you are unemployed. An ARMv7 CPU like the one in my TrimSlice “simply” is not as fast as a quadcore AMD processor.
So, I try to create a stable basis somewhere between 14.0 and current, and then start closing the gap by upgrading/compiling the remainder.
Eric
Parentheses were probably the problem, I usually use a healthy dose of them!
I have tweaked the slackbuild for armv6zk, but when I include –with-cpu= and tuning, the compile fails stating the selected processor wasn’t valid. When I take those options out it compiles a binary that won’t compile anything, compaining of an unknown option for -march=armv6zk or something similar. I used your kernel source and config to generate the kernel headers– are they sub-arch specific? Should I be using raspberry pi sources/config from the beginning? That’s the only thing I can think of atm.
Thanks!
Yes, you do need a kernel config for the hardware you are targeting. And the kernel-headers which are generated out of that, are required by gcc and glibc.
Check out one of slackwarearm’s kernel configurations for the Raspberry Pi perhaps.
Eric
Ok, I’ll start over on Monday. I have some kernel sources for the Raspberry Pi, which Ponce prepared and I patched with aufs. Might be better to start with something more generic, though.
When I was following Cross Linux From Scratch, they didn’t apply a kernel config before building the headers (and run make distclean before as well) so I made the assumption a config wasn’t required. The question I have is why it builds fine in a crosscompile (against the wrong headers) but then fails out on the native compile. I guess I’ll be happy to drop that question if changing to armv6 headers makes it work for me lol. As always, thanks for your help!
Any news about the development ?
Will the rootfs be announced on this page ?
DEF,
Like Ahau did, you can do too. Grab the bootstrap files and compile your own rootfs !
If you are having difficulties in understanding how the stage1.sh script works, I will write some documentation about how to use that script. In the meantime I uploaded a rootfs which I created for my TrimSlice (Nvidia Tegra powered): http://taper.alienbase.nl//mirrors/alienarm/rootfs/armv7hl/tegra/ , so that you can be happy too.
Currently I am in the midst of updating the ARM toolchain (gcc,glibc, kernel) and I assure you that it is _not_ trivial to get a working SlackBuild for the updated versions. I have setup distcc and a cross-compiler on my Quad-Core server to speed up the compilation because compiling llvm alone took 9 hours yesterday.
I understand that you are eager to start experimenting, but ARM and speed are two things. ARM and Intel are sufficiently incompatible that every package update requires inspection of the compilation results.
Eric
Well, like as you said about Patrick, it’s nice to have some news about how things are going ;^).
Yeah, i can imagine it’s a lot of time to port to another arch.
Although i’m impatient, don’t take that as harassment :D.
Thx for the rootfs, will try soon.
So it boots on the Pandora, with the custom kernel.
Pretty much naked distro huh ;^D.
Ok, I pulled the 3.2 series kernel from the Raspberry Pi website, grabbed the headers, and rebuilt stage1 and stage2, built and installed pkgtools and tar (so pkgtools won’t complain about missing tar-1.13) and this time, gcc has accepted the –with-cpu=arm1176jzf-s parameter. Hopefully everything will work this time (compiling will take an hour or three lol). However, there’s still room for doubt — What I found is that on my previous attempt, the gcc binary itself was viable — if I copied it by itself into /usr/bin, it would compile a test file properly. However, when I installed the full package, it broke, citing unknown options.
Also, on my end, a couple of packages in stage2 are failing to build. I assume this was the case in my previous attempt but I didn’t catch them. db44 and glib2 both failed to configure. The final error message in db44’s config.log was a statement that it was unable to build RPC support: rpcgen failed. There were other errors while building conftests, but I’m assuming they’re normal.
glib2’s config.log shows an error stating that the pkg-config script could not be found or is not in the PATH.
Are these building successfully on your end? I do see that pkg-config is set to build right after glib2 (maybe their order should be reversed?). I’m guessing the db44 issue is related to rpc headers in glibc but I haven’t looked into these any deeper. Assuming gcc works when it’s done, I’ll start building slack packages and installing them over the top of the rootfs, in the same order the stage1/stage2 scripts built them, and these issues will likely dissapear but I thought it worth mentioning.
@DEF, naked is beautiful 🙂
I feel just a little bit of Eric’s pain when it comes to sorting out glibc and gcc — Slackware adds something like 20 patches to each of these, the patches change by version and different ones are required for different architectures. On even on a newer arm device it might take an hour or more to compile and see if your changes have fixed and/or caused problems. It is bad enough to manually apply the patches and try to get the configuration right. I can’t even imagine the task of sorting out which patches to add and which not to, and I’m incredibly grateful that there are other folks who know more than me that are taking on that task!
About compile time, Patrick upgraded -current distcc to 3.1, which brings the pump option that boost a lot distributed compilations.
Trust me, compile time will not be the biggest issue when developing a port from scratch!
I have been fighting all weekend with getting packages built which have no issues at all on Intel platforms: icu4c needed the latest clang, a new gcc 4.8.0 refuses to compile binaries and I broke my compilation environment by upgrading to glibc-2.17 which caused segfaults in all other binaries…
No fun.
Eric
Hi
I have been looking for an ARM hard float port of Slackware for a while. I really appreciate your effort, and I think many more are interested in your work Slack ARM hard float. I hope your port will also run on TrimSlice. I have a Toshiba AC100, that use the same SOC as Trimslice. Currently it is running an other distro, but it would be great to uppgrade it running Slack. There is an active community hacking AC100, that also have their own IRC channel at freenode. I bet there are other AC100 users that also will be interested in your port.
Compile time is a bit of an issue for me, I don’t use distcc at this point because I’m usually compiling stuff on my tablet while away from home.
That said, I finally got a working natively compiled gcc! Among other things, what I realized is that when multithreading my builds with -j4 on a dual-core machine, c++ code would hang, get terminated, fail to build a piece of code and error out, but the other threads continued and completed the rest of the build, with the SlackBuild completing (apparently successfully). I’ve scaled back to -j2 and have been tee’ing and grepping logs for errors and things seem to be working now, thought it did take 8 hours for the bootstrap build of gcc to complete!
@pekka — Not to jump in the middle here, but Eric’s port is being built to be compatible with ARM cortex-8 processors and up. If memory serves, the Trimslice and AC100 are both Tegra2 which runs cortex-a9, so it should run on your devices.
Since I am compiling all of my stuff on my TrimSlice, certainly it will work there!
Eric
Now that I’ve got gcc running, I’m plowing through recompiling stage1/2 packages and soon I’ll install everything in a clean directory to avoid some header issues I’m seeing. I’ve noticed that pth also didn’t compile during the initial stage2 — it needs a patch before it will compile on ARM, which I pulled from slackwarearm – source/n/pth/sources/ftbfs-arm.diff.xz. Now that I’ve recompiled my way up to it, db44 compiled fine this time around.
I also have a question — lots of the slackbuilds in your alieanarm repo have armv7 CFLAGS set, but there are also plenty of them that do not (early packages like xz, bzip2, gzip) — were these just not updated in your previous efforts, or are the CFLAGS not really useful (or problematic)? I’m following your SlackBuilds pretty closely, so I’m leaving them off in those instances for now.
Thanks!
Armv7 CFLAGS are usually safe.
I compile tons of packages and had no problem so far.
Only noticeable are some mandatory -fPIC on arm, but it’s not common.
I have compiled over 400 packages in the past few days. I have come large aligned with slackware-current. Things I have not touched yet are KDE, the kernel, gcc and glibc versions in slackware-current. And there will still be packages I have to recompile but those should not be too important I hope.
I was aiming for a run of XFCE on the ChromeBook yesterday, but the copy of files to SD card took too much time.
This morning I booted Slackware on the ChromeBook right before going to work but to my frustration, X.Org drivers had ABI errors. Which means I have to recompile X again tonight and then test the resulting packages on the ChromeBook.
If that works, and I see a XFCE desktop, then I will create a SD card image and upload it.
The sources will be uploaded to taper tonight hopefully.
Eric
Sounds great!
I’m up to about 100 packages for armv6zk, here’s my current rootfs if anyone is interested: http://porteus-arm.googlecode.com/files/slackware-armv6zk-minirootfs-13-4-5.tar.xz
Eric, do you know offhand if your slackbuild for x11 will do a bootstrap build (slackwarearm’s build script indicates it probably won’t)? If not, do you have a script that you used to bootstrap it?
Hi Ahau
The x11.SlackBuild script which I currently have in my repository at http://taper.alienbase.nl/mirrors/alienarm/bootstrap/ will not bootstrap X.Org. Neither does the new x11.SlackBuild in Slackware-current (which is almost the same, except it has an additional line “upgradepkg –install-new” so that freshly built packages are immediately installed).
By adding “upgradepkg –install-new” you can build all, or almost all, packages in two iterations of running ./x11.SlackBuild . Note that you need to have built libdrm, glew, glu and mesa before starting x11.SlackBuild and that you have to rebuild mesa afterwards. Then after mesa, run x11.SlackBuild another time to make sure all dependencies are picked up.
Also noteworthy is that many ARM devices seem to benefit from the fbdev driver (xf86-video-fbdev) but that one is _not_ part of the x1..SlackBuild. Instead, look for that one in extra/source .
Stuart Winter (MoZes) documented his bootstrap build on SlackwareArm here: http://slackware.org.uk/slackwarearm/slackwarearm-current/source/x/x11/bootstrap-build
Eric
Perfect, thank you! I was hoping iterative runs through the slackbuild would do. I’ll add upgradepkg –install-new and give it a shot once I’ve built the dependencies. I had started on them but found out that libgomp didn’t get built on my last run throuh gcc (nor did libquadmath and libitm) so I’m building gcc…again 🙂
I deleted xf86-video-fbdev from package-blacklist, and if that’s not good enough, I’ll follow your advice to pull it from extra. My tablet uses this driver so it’s a *must* for me 🙂
XFCE works!
Now at least I know that I didn’t do all of this for nothing.
Tomorrow will be cleanup time, fixing some annoying bugs and then I will first get the source code uploaded to taper and try to dump the SD card into a downloadable image.
Just for fun: here is a 1’13” video of me logging in as “alienarm” and starting X, then loading up this blog in firefox: http://dl.dropbox.com/u/2329942/VIDEO0006.3gp .
VLC will be able to play this .3gp video which I shot with my phone (hence the shaky images).
Eric
This is very exciting. I’ve just purchased a second-hand Asus Transformer TF700 tablet. I hope to give your port a try on there.
I am curious, however, how the Tegra3’s Quad+battery saver cores will work out. Will i need to recompile everything with different options to reap the benefits of this architecture? (I, also, am an ARM n00b)
My TrimSlice computer, the one where I compile all packages, has a Tegra2 CPU, so the binaries I create should work on your Tegra3.
Usually, the one thing you need to do for another device is create its own new kernel. The rest of the packages will be re-usable.
Eric
Awesome. Thanks.
What are some mods that I should look for in the kernel? Would looking at the kernel in an Android ROM for my device be a good starting point?
You should always take the ROM kernels as a starting point. Usual with ARM tablets and phones is that their kernels need lots of patches. A Slackware kernel is built from unpatched sources which means you can not build a working kernel for your device unless you apply the vendor patches.
Eric
Meisjohn, also try looking through the “android development” section for your device on the xda developers forum, and read all the threads discussing native linux. Looks like they have Arch and Debian on the TF700 at least, and patched linux kernels– their prebuilt kernels would probably work for slackware, or you could use their source and config with a little modification. That’s what I’ve done for my Acer Iconia A500. Good luck 🙂
I have refreshed all of my source packages on http://taper.alienbase.nl/mirrors/alienarm/bootstrap/source.local/ – I do not know if the stage1.sh bootstrap script still works with all the new sources, I have fixed at least the coreutils build though.
I’ll write up a proper blog article about it. I wanted to work on my ChromeBook installation but I have been debugging a KDE linking error all day. I found ad fixed that and the fix is part of the updated sources on taper.
Eric
Glad to hear the progression !
Admitting i want to build the full distro, but directly on Slackware ARM, how would you recommend me to proceed ?
I am afraid do not understand your question. You want to build all the sources I made available on a Slackware ARM computer in a chroot? That’s how I am doing it, using slackwarearm-14.0 as the host OS on my TrimSlice.
Eric
Ah ok, thought you used some x86 server of yours !
What I did was bootstrap the ARM port on my AMD64 server, using the cross-compiling script (the stage1.sh) and then copied the resulting rootfs (containing actual ARM binaries) to my TrimSlice ARM computer running ARMedslack. I setup a chroot for that foorts and ran the stage2.sh script there to compile the rest of the binaries that are needed to start the actual Slackware bootstrap (i.e. creating real packages).
But I am still using the AMD64 server for compilations. The cross-compiler which is created as a “by-product” of the stage1.sh script is actually very useful. I am using the “install” directory’s content with the distcc daemon so that I have an additional 4 cores on a fast machine, and not just a dual-core Tegra2 CPU for the compilation.
Eric
Ok so back to my original question, i wanted to know if i can run the stage 1 on my ARM.
I’m not in a hurry, and it eats only 1 Watt per hour.
I’ll use actual Pandora flags, i.e.:
-DPANDORA -O2 -march=armv7-a -mcpu=cortex-a8 -mfpu=neon
So it seems the answer is yes.
I have noticed that the ARM kernel does not concern itself with the userspace ABI. That is why I can run my hard-float binaries in a chroot on a soft-float ARMedslack OS without any issues..
So, you should not have any problem in using the rootfs which is the result of the stage1 script.
You can put your Pandora CFLAGS in /etc/slackbuild/machine.conf and most SlackBuild scripts will pick that up. There are only very few SlackBuild scripts left which do not read the machine.conf. Mostly those are the scripts that are not using fancy CFLAGS anyway.
Eric
Oh, i wasn’t aware of this /etc/slackbuild/machine.conf.
I made myself this piggy thing:
#!/bin/sh
find /var/lib/sbopkg/SBo/*/*/*/ -iname “*.SlackBuild” -printf ‘cp %p %p\n’ \
| sed ‘s/\.SlackBuild$/\.SlackBuild.sbopkg/’ \
| while read l; do eval $l; done
sed -i -e “s/\$SLKCFLAGS/-DPANDORA -O2 -pipe -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp/g” /var/lib/sbopkg/SBo/*/*/*/*.SlackBuild.sbopkg
sed -i -e “s/\${SLKCFLAGS}/-DPANDORA -O2 -pipe -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp/g” /var/lib/sbopkg/SBo/*/*/*/*.SlackBuild.sbopkg
Well maybe SBo does’t use machine.conf anyway ?
I suppose /etc/slackbuild/machine.conf _inside_ the chroot ?
It’s inside the chroot, yes. Once you chroot there is no way you can read stuff outside it.
My recently modified SlackBuild scripts all have this bit of code which lets you use a “machine.conf” file for custom variables:
# ——————————————————————-
if [ -e $CWD/machine.conf ]; then
. $CWD/machine.conf ]
elif [ -e /etc/slackbuild/machine.conf ]; then
. /etc/slackbuild/machine.conf ]
else
# Automatically determine the architecture we’re building on:
if [ -z “$ARCH” ]; then
case “$( uname -m )” in
i?86) export ARCH=i486 ;;
arm*) export ARCH=arm ;;
# Unless $ARCH is already set, use uname -m for all other archs:
*) export ARCH=$( uname -m ) ;;
esac
fi
# Set CFLAGS/CXXFLAGS and LIBDIRSUFFIX:
if [ “$ARCH” = “i486″ ]; then
SLKCFLAGS=”-O2 -march=i486 -mtune=i686″
LIBDIRSUFFIX=””
elif [ “$ARCH” = “s390″ ]; then
SLKCFLAGS=”-O2″
LIBDIRSUFFIX=””
elif [ “$ARCH” = “x86_64″ ]; then
SLKCFLAGS=”-O2 -fPIC”
LIBDIRSUFFIX=”64″
else
SLKCFLAGS=”-O2″
LIBDIRSUFFIX=””
fi
fi
case “$ARCH” in
arm*) TARGET=$ARCH-slackware-linux-gnueabi ;;
*) TARGET=$ARCH-slackware-linux ;;
esac
# ——————————————————————-
I thought I had updated “most” of the scripts… but actually, the majority of the software in A and a lot of AP still waits for its SlackBuild scripts to be updated. So be careful when starting a compilation.
Eric
Ok, thanks for your explanations.
How’d you resolve the issue of the new glibc segfaulting everything? Did you have to install it into a sysroot and build a new rootfs from scratch against it? If that’s the case, I’ll probably start over with the stage1 and 2 scripts and test them on the new sources. This is awesome progress, btw — congrats on getting X working with the chromebook 🙂
Yeah, that was fast and furious !
Maybe you should update distcc to 3.x, as -current did, because with the “pump” option, the pre-processing is offloaded to the servers, and it can dramatically reduce the build times.
Everything happens in my free time, so I make the decisions on what comes first… and a newer distcc is not on my priority list.
You can grab the sources and start working on them, that is why I made them available.
Eric
Ahau, for now I think it is wiser to stay away from glibc-2.17.
The “minimum kernel version” setting for glibc in slackwarearm-current is something I did not want to apply in my own ARM tree anyway. Lots of ARM devices run kernels that are in the 3.4.x or older range and the slackware-current minimum of 3.8.4 is undesired. I think that even the slackwarearm-current value of 3.4.0 is set too high. I will stick with the 2.6.32 I am using at the moment.
Eric
I’ve installed the packages and booted on my Pandora.
It works. Started Xfce, etc.
Can’t really compare with Slackware ARM for now.
At a first glance, it boots a little faster, and seems to better multitask.
Ah, I see now. And, I completely agree. Linux4tegra (nVidia provided kernel sources for tegra devices) is still at 3.1, and a lot of other arm kernels I see out there are at 3.2.
I’m apparently not done battling gcc. I built it again to get libgomp –had to exclude java, go, objc and fortran because their libs failed and stopped libgomp and libitm from being installed– and am having the same “unknown option” problems with the new gcc. However, I’ve tracked it down to the specs file. I can compile with the new gcc if I copy over the specs file from my previous install. So freaking weird. Only change in headers is that I created a package out of the headers, moving asm to asm-arm and symlinking asm. I manually deleted the symlink and copied asm-arm to asm and I’m trying again. I have had issues with other header files and I’m wondering if there’s sometghing in my toolchain that can’t handle symlinks 🙁
Emacs, with or without X, makes the system unstable, it even crashed it.
Also had a crash during a removepkg.
Apart this, well, all seems fine.
I was surprised to see that many softfp binaries from the Pandora repo are working well.
Using the stage1, i ran into this:
config.status: creating po/POTFILES
config.status: creating po/Makefile
configure: WARNING: unrecognized options: –enable-werror, –enable-cxx, –with-cpu, –with-tune, –with-arch, –with-float, –with-fpu, –with-abi, –enable-languages, –disable-libssp
touch: cannot touch ‘man/arch.1’: No such file or directory
Module coreutils failed
bash-4.2$
Checked the presence of the faulty touch in the SlackBuild, but saw nothing :/ .
DEF,
this looks to me like it’s coming right from the stage1 script (SlackBuilds aren’t run in stage1 or stage2, they pull config options out of those scripts):
for i in $(cd $SLACKSOURCE/coreutils/coreutils-*/man; echo *.x)
do
base=echo $i | sed ‘s/\.x//’
touch man/$base.1
done
I’m guessing there’s no “man” directory inside the current build directory ($BUILDDIR/coreutils). not sure why that’s the case, but maybe it helps 🙂
@alienbob, I got gcc sorted out (again) — I had foolishly disabled bootstrapping, and gcc.SlackBuild expects to find the specs file inside a directory named “stage1” which doesn’t exist if you’re not bootstrapping. However, I am still having issues with packages not finding ncurses libraries (libtinfo primarily) — I saw one of your SlackBuilds adds LDFLAGS for this same reason, I wonder if it’s an armhf specific issue? I’ve run into 5 or 6 other packages like this.
Also, I ran into an interesting issue with openssl. The config script goes searching for a $MACHINE variable independently of the supplied CFLAGS, and sets it based on uname. Since I’m building armv6 binaries on an armv7 machine inside a chroot, openssl was trying (and failing) to build as armv7. As a workaround, I added a line to the slackbuild, “export MACHINE=$ARCH”, which set the MACHINE variable to armv6zk. The compile completed, though no arch-specific CFLAGS were used while it was compiling. This may not affect any of what you’re doing, but it took me a while to sort it out, so I’m posting it here in case it’s helpful to anyone.
Where do i put this code ?
DEF, That code is inside the stage1.sh script, I just copied it to show you where in the script it was looking for “man/*.1” I have not run stage1.sh since Eric updated his sources to current (I am building the new packages natively on my ARM device using the mini-rootfs I produced from the older sources) so I haven’t reproduced the error or found a fix for it.
If it were me, I would look inside the coreutils build directory, looking for ‘man’ which appears to be missing, and try to run that build manually following the script, to see where it goes wrong. Of course, Eric might know immediately what the issue is since he wrote the script 🙂
Ah ok.
Thx.
I’ve inserted a
mkdir man/
before the touch, and now i have a cannot create directory ‘man/’: file exists
Use mkdir -p man
It worked !
Why ?
from http://linux.die.net/man/1/mkdir
“-p, –parents
no error if existing, make parent directories as needed ”
The p switch won’t issue an error if the directory is already there. Since you put ‘mkdir’ inside a for loop, it was trying to run ‘mkdir man’ over and over again.
I suppose the deeper question is whether or not this actually built the man pages for the coreutils package rather than just allowing the script to complete with empty data. Of course, you’ll get the man pages after you finish bootstrapping and rebuild coreutils from a slackbuild.
Ok, thanks 4ll.
Another failure:
make[1]: Leaving directory /home/def/alien-custom/bootstrap/builds/gawk/test’
Running: ./stage1.sh patch
Date: Tue Apr 9 23:29:07 CEST 2013
Cwd: /home/def/alien-custom/bootstrap
./stage1.sh: line 162: [: too many arguments
find: /home/def/alien-custom/bootstrap/slackware/source’: No such file or directory
Module patch failed
bash-4.2$
Hint:
If you run into errors, post patches that make it work, instead of posting the errors because you can not figure it out.
The fix for the “man” error in coreutils was in my private repository since last week, but I only pushed the updates to source.local to the public repository.
Try applying this and do not answer with “how should I apply it?”. You want to be on the bleeding edge… it’s time to bleed:
< $SLACKSOURCE/coreutils/coreutils-*/configure $TCONFIGARGS --- > cat < config.cache
> fu_cv_sys_stat_statfs2_bsize=yes
> gl_cv_func_working_mkstemp=yes
> EOF
> $SLACKSOURCE/coreutils/coreutils-*/configure $TCONFIGARGS –cache-file=config.cache PERL=NO
704a710
> mkdir -p man
Eric
@alienbob,
Thanks again for the info regarding bootstrapping X. It’s taking me more than 2 passes but I’m making progress. For prosperity’s sake, here’s my rough build order:
I started with a minirootfs with a package list similar to the minirootfs prepared by slackwarearm, plus development tools. then:
x11-skel
freetype
fontconfig
then, I ran x11.SlackBuild for the first time. This will only succeed on “proto” packages, and a few others that don’t require many libs, including libpthread-stubs which is required for libdrm. I did not let the script finish, I stopped it after libpthread-stubs.
libdrm
run x11.SlackBuild -2nd pass — rebuild proto packages, build a few of the Xlib packages – stopped the script after it was done building “lib” packages
ran x11.SlackBuild -3rd pass– to pick up a few more X libs, again stopping it after it was done building “lib” packages — after this, I was still missing libXmu, which is needed for mesa and requires libXt. A fourth pass of x11.SlackBuild here would pick it up but since it was just one lib, I manually configured, made, and installed it.
mesa –Stuart built glew before mesa but glew would not compile for me here
glew
glu
xaw3d –probably not needed yet but it did compile
sdl
x11.SlackBuild -4th pass
I’m in the middle of the 4th pass currently, I expect most of X11 will get built here; after that completes, I’ll build llvm, then rebuild mesa and glew to wrap in X support, and then at least one more pass through x11.Slackbuild.
It’s probably possible to do this in fewer passes, but I’m lazy and working on a touchscreen.
As you mentioned you weren’t sure the bootstrap still works, i posted these outputs to help you knowing where it failed.
Of course if you already solved the thing in your private repo that was useless…
Hi DEF
Your issue with “./stage1.sh: line 162: [: too many arguments” and “find: /home/def/alien-custom/bootstrap/slackware/source’: No such file or directory” seems to be caused by not having the proper directory structure in place. Check the documentation inside the script to see how it works and what you must prepare before your run it.
Eric
Hi DEF
Your issue with “./stage1.sh: line 162 was caused by the fact that I added the KDE sources… and that introduced a second “patch” directory.
I have uploaded an updated version of the script and accompanying “source.local” directory (git updated as well).
I will also upload the crosscompilers tonight which are created by the script.
Eric
As of earlier today, I have Xfce up and running for armv6zk on my tablet 🙂
Eric, I have a couple of suggestions, but feel free to disregard them (I’m happy to keep applying these tweaks myself if you want to keep them out of your port):
1) update-pango-querymodules and update-gtk-immodules didn’t work out of the box on armv6 — I believe this case statement would cover both arch’s and any subsets, though I don’t really understand what setting hostqq is doing here:
# Fix $host for arm arch:
case “$host” in
armv[6,7]*) hostqq=$(uname -m)-slackware-linux-gnueabi
unset tgt_arch && tgt_arch=readelf /usr/bin/file -A|grep “Tag_CPU_name”|cut -d\” -f2|tr “[A-Z]” “[a-z]”
readelf /usr/bin/file -A | grep -q “Tag_FP_arch” && host=armv${tgt_arch}-slackware-linux-gnueabi
;;
arm*) host=arm-slackware-linux-gnueabi ;;
esac
2) Some of your slackbuilds (e.g. util-linux) add -ltinfo to LDFLAGS. With armv6 in /etc/slackbuild/machine.conf, keeping the arch specific to armv7hl causes these builds to fail. I’d suggest a similar case statement with armv[6,7]* so that all hard-float builds pick up these flags.
Thanks!
Hi Ahau
I have made a change to all SlackBuild scripts which mention libtinfo. Those changes should make the use of ‘-ltinfo’ in LDFLAGS independent of ARCH, and applied only when needed.
The repository has already been updated.
I will have a look at the gtk and pango update scripts. Can you post the full output of “readelf /usr/bin/file -A” here? I need to be able to distinguish between slackwarearm’s softfloat binaries and our FPU-supporting binaries.
Eric
… and by the way, “hostqq” was probably a vi editing issue. That should be “host”, thanks for noticing and reporting.
Eric
Sure thing, here it is:
root@porteus:/mnt/mmcblk1p3/usr/bin# readelf -A file
Attribute Section: aeabi
File Attributes
Tag_CPU_name: “6ZK”
Tag_CPU_arch: v6KZ
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_FP_arch: VFPv2
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_ABI_HardFP_use: SP and DP
Tag_ABI_VFP_args: VFP registers
Tag_CPU_unaligned_access: v6
Tag_Virtualization_use: TrustZone
Thanks for taking a look at this!
Are you using “armv6-slackware-linux-gnueabi”, i.e. ARCH being “armv6”? I would have expected “armv6l” as the output of “uname -m”.
The deal with hardfloat versus softfloat distros is the naming of the host triplet. You will see that debian uses “arm-linux-gnueabihf”, Archlinux uses “armv7l-unknown-linux-gnueabihf”, Gentoo uses “arm-hardfloat-linux-gnueabi”,and I am following Fedora by using “armv7hl” as the ARCH in “armv7hl-slackware-linux-gnueabi”.
If you compile your binaries with hardfloat support, then your host triplet should show that.
I have learned in the meantime that the distinguishing element in readelf -A output for hardfloat binaries is the line:
Tag_ABI_VFP_args: VFP registers
Eric
What I wanted to use is something like:
# Fix $host for arm arch:case "$host" in
armv[6,7,8]*)
if readelf /usr/bin/file -A | grep -q "Tag_ABI_VFP_args: VFP registers" ; then
# Hardfloat, rewrite armv7l -> armv7hl
host="$(echo $host | sed -e 's/\(armv.\)/\1h/')"
fi
host=$host-slackware-linux-gnueabi
;;
arm*)
# Softfloat:
host=arm-slackware-linux-gnueabi
;;
esac
Eric
My triplet is armv6zk-slackware-linux-gnueabi. So based on your comments, this should be armv6hzk-slackware-linux-gnueabi, with the ‘h’ representing hard float, or ditch ‘zk’ for raspberry pi- specific and go with ‘armv6h’ or ‘armv6hl’ and set mcpu to armv6 when I compile gcc?
Other than my triplet screw-up, the concern I have with the way you have the case statement framed is that it assumes the user is running a port specific to the machine architecture, when someone could be running armv6 an armv6 port on an armv7 machine like I am, so uname gives armv7l when the host needs to reflect armv6.
Thanks again!
I do think that ‘armv6hl’ would be better in line with my own port, if your intention is to keep using my bootstrap repository.
You do have a point with your second point: I fully agree that it should be possible to run an ‘armv6hl’ port on armv7 hardware. Some re-writing of the triplet detection code is needed then. I’ll have a look at your original proposition and see how I can use that.
Eric
Ok, I did some googling and I have a better grasp on what ‘hl’ is all about –hard float, little-endian– and I’ll rebuild as armv6hl. I’m hoping I can do this over the top of my existing system so I don’t have to start totally from scratch, but knowing how these things go, that’s probably wishful thinking lol.
Regarding the “second point”, I imagine use of armv6 software on armv7 machines will be relatively rare since your port is making armv7 software available. But once armv8 machines are more prevalent, we may see use of armv7 software there until a new port is established.
You should be able to rebuild your packages with a new host triplet on top of your existing installation. I did that for slackware64 once. It will save you a lot of time.
If I remember correctly, you should rebuild these packages first, in this order (including repeated builds) after fixing your scripts: gcc, glibc, binutils, oprofile, libtool, kernel, gcc, glibc, binutils.
And then the rest of course.
Eric
What about this:
# Fix $host for arm arch:case "$host" in
armv[6,7,8]*)
if readelf /usr/bin/file -A | grep -q "Tag_ABI_VFP_args: VFP registers" ; then
# Hardfloat, rewrite armv7l -> armv7hl
type=$(readelf -A /usr/bin/file | grep Tag_CPU_name |cut -d\" -f2 |cut -c1)
host="$(echo $host | sed -e 's/\(armv\)\(.\)/\1'$type'h/')"
fi
host=$host-slackware-linux-gnueabi
;;
arm*)
# Softfloat:
host=arm-slackware-linux-gnueabi
;;
esac
Eric
Ok, thanks. I’m keeping –march=armv6zk rather than armv6 to try and retain binary compatibility and I don’t really care about other armv6 hardware. Do you recall if the first gcc build should be static, unlinked to glibc, or can I use the slackbuild and just change cflags and alter the target?
I believe you can just rebuild the full packages. The new triplet will gradually trickle through to all binaries.
Eric
I missed the case statement before, that looks like it should do the trick, and I’ll try it out once I’ve rebuilt everything with the new triplet 🙂
he he he…
can I install it on my tablet before the end of this years sir?
oh yeah, I use ainol novo 7 crystal. he he he…. I use Slackware since on junior school. and I wish can install it on my tablet to.
first read post in this blog about slackwarearm I was very happy. at first I think to build it from scratch. but after asking to many of my friend who’s usually selling computer by preorder can get an arm based like chrome book or other brand I stop think that I can feel the early release of slackwarearm. he he he…
OK. I will waiting for the stable release. hahaha… nice to read the progress from the middle jungle of east Borneo.
@cilang, alienbob has already published packages that will run on the ainal novo 7 crystal, as it uses an armv7 processor. However, what you need is a functioning linux kernel and the associated firmware for it, and that is outside the scope of what has been prepared here. You’ll need to find a kernel and learn how to install linux natively on that tablet. Your other option is to run alienbob’s packages in a chroot within android. That will require rooting your tablet and putting together a script to chroot and open the chroot in a vnc client — google will be your friend here 🙂
@alienbob – I wasn’t able to compile gcc by only changing the target in the build script. I had to change the configuration to look a lot more like the LFS guide, with newlib and disabling libraries, etc; after that, I was able to get cross-binutils and glibc built, but my rebuild of binutils failed out, probably because I wasn’t building inside a separate directory to keep everything clean and separate. To speed things up and make life a little easier for me, I pulled your updated sources and ran stage1 again, which worked perfectly fine by the way. I then put that stage1 in a separate chroot on my ARM device and installed the stage2 packages from my existing armv6zk package repo to avoid compiling stage2. It’s up and running and I’m compiling packages for binutils, glibc and gcc, etc in that chroot. When done, I’ll install those packages with the new triplet over the top of my existing install with the old triplet and I should be in fine business to resume building where I left off without having to bootstrap everything from scratch again.
Hi Eric, two notes and a question:
1) the case section for update-pango-querymodules/update-gtk-immodules-*, etc seems to require one modification:
host=$host-slackware-linux-gnueabi
should be:
host=$host-gnueabi
When I ran it, it was looking for “armv6hl-slackware-linux-slackware-linux-gnueabi”. Of course, this wouldn’t be necessary if you’ve changed how host is defined above this section.
2) I think you need to update gobject-introspection to 1.34, otherwise it won’t compile against glib2-2.34
question — did you have to pass any additional arguments to clang for icu4c? On armv6, it’s failing to configure stating the C compiler won’t produce binaries. config.log shows it fails to link because a.out uses VFP but the other object doesn’t — I haven’t reinserted icu4c into my build process yet, but passing “-mfloat-abi=hard” appears to get clang working with a dummy file. I’m curious to know if this is only happening here.
Thanks!
@Ahau, thanks. after read some article it seem i will do it after i got the package. Hehehe…. downloading a full package of slackware arm will spend a week with cellular network here. But thanks for the information.
But i still wish that someday there is an easy way to install it.
Hi Ahau
You are right with regard to the update-* scripts… I have fixed those (slightly differently than your proposal) in git and in the source tree, thanks for spotting it.
I think I did not yet recompile gobject-introspection. I will get to that later.
Currently the clisp package (which I never managed to compile so far because I wanted to add FFI support) is trying to break my determination, I have been fighting it since monday. I think a decent LISP must be part of the port.
Coïncidentally, the addition “-mfloat-abi=hard” to the CFLAGS is required for compiling clisp as well. I got the exact same error message you see.
Perhaps it should become part of the default CFLAGS for hardfloat ports.
Eric
Thanks 🙂
Hang in there with clisp, I’m sure you’ll get it soon! There’s never any shortage of things to work on in Linux, but it is frustrating when they take a long time to sort out. I lost a couple of days to seamonkey — after compiling for 7 hours it kept failing to link libxul. Turns out it needs a lot of RAM; I kept adding more swap files until I had them spread across 3 partitions, and then it took five hours to link up. All that because I wanted nss-libs so I could build rpm, and I only needed that so that I wouldn’t have to manually run rpm2cpio from my host to get linuxdoc-tools to build in my chroot. It’s a good thing I derive some sort of sick pleasure from this, otherwise I’d never have the patience to finish.
I built a clisp package – finally. But a buddy of mine insists that I should try adding the ASDF module, since that is what gives clisp its versatility (used by quicklisp for easy downloading and installation of software dependencies).
In the end my SlackBuild looks surprisingly similiar to Stuart’s slackwarearm version 🙂 Apparently there is only one way to get clisp to compile error-free on ARM.
About rpm … that is why I added mozilla-nss since that is so much easier to build than seamonkey (and has less dependencies)… and mozilla-nss provides the same nss libraries.
Eric
Yeah, I figured that out AFTER I built seamonkey and realized rpm still wouldn’t build–I had to symlink some pkgconfig files to make it work. Then I realized that you must have been using another package. I think I started with seamonkey because the solibs package was listed as a prereq in the standard slackware build scripts somewhere.
glad you got clisp built!
I’ve found a couple of other tweaks that are needed for some packages, should I continue posting stuff here or is there a better place? for example, xfig needs a simple patch for xaw3d. It’s not tough to sort this stuff out but it can consume a little time. I want to be helpful without being annoying lol.
You can alsways send patches directly to my @slackware.com email address. If you needed a patch for the armv6 port, then it’s good to have that in my git repository.
Eric
Hi Eric, I’m just checking for updates. Last time I heard from you, you were trying to make KDE to work with it.
Oh, KDE Is running fine here with the patch to Qt that went in a little while ago.
You can find all those packages at http://taper.alienbase.nl/mirrors/alienarm/slackware/
I have been busy with work and am on holiday currently, so nothing much is happening. The things that change, can most easily be tracked through git: http://taper.alienbase.nl/gitweb/?p=bootstrap.git;a=summary
I want to upload a SD card image for the Chromebook, but I am still finding a proper way of generating one. I really want to create a small image with just the GPT partition layout and chrome kernels, which is easy to download and “dd” onto a SD card, which will allow people to copy Slackware binaries into the data partition more easily. But that requires additional documentation / instructions.
Or else I have to create an image of a 8 GB SD card (compressed, that would still measure several GB to download) and let people “dd” that complete image to a SD card. Cumbersome and I would have to re-create the image for every change, and people would have to overwrite their installation with every new image file.
Eric
Sorry for little interference.
I meanwhile run Slackware ARM on a armv7 device of chinese production ( 7 inch netbook with wm8850 S0C from Wondermedia ).
Thanks for the work.
Alas : beside lynx no browser at this moment…
I have a version of midori but it requests a
libicuin18.so.49 and a 51 is delivered 🙁 😉
alienbob, I wait anxiously for your SD card image. Thank you for all your work!
Just booted your mini rootfs on an Atmel devkit with Cortex A5 CPU 🙂
Very thanks for your job
Regards
Hi Eric.
These days I played with your stage1.sh script. I think that there is a bug in ./source.local/k/k.SlackBuild
PLATFORM=${1:-tegra} should be PLATFORM=${PLATFORM:-tegra}
Also, the ‘kernel’ stage didn’t build until I added in stage1.sh the path to mkimage (otherwise linux-3.8.4/scripts/mkuboot.sh can’t see it):
PATH=$BUILDDIR/u-boot/tools:$PATH
With these modifications everything run fine. I built it in VirtualBox Slackware64-13.37 using your git repository and symlink to the Slackware64-14.0 sources.
Note: on real (non virtual) Slackware64-current I had gcc segfault (I didn’t investigate it, probably a bug with the latest gcc?)
Hello Eric,
I am posting about some adventures and some problems I am having with alienarm while trying to make my Samsung Chromebook 303 into a real computer.
First a disclaimer. I probably did not start with installing alienarm in a standard manner.. I mean, the disk partitioning and most particularly where to put the kernel and how to boot it. In fact, I was not sure how exactly to go about that. So I started out with an Arch installation and followed their instructions to the letter. Starting with their skeleton root filesystem and 3.4.0-ARCH kernel, I got to a boot prompt. Then (no surprise because I am quite committed to Slackware) I concluded that I did not like Arch very much after getting a close look. The reasons are several. One of them is they are using systemd,.
So I blew away the Arch root filesystem and replaced it with the alienarm packages. For reasons which will become clear, though, I did keep the Arch modules (/lib/modules/3.4.0-ARCH) and their /usr/lib/firmware/*
This works, well enough, except:
1. I cannot boot the kernel which comes from the a/kernel* files. I can only boot from the Arch 3.4.0 kernel. Not sure why.
2. I cannot make X to work using the alienarm x/* packages. There is a complaint about a version mismatch between the armsoc driver and the xorg server. and an immediate crash. Since everyone else here seems to thing that X is working nicely, this may for all I know be a bogus error message caused by not using the alienarm kernel.
3. Blowing away the x/* files by using upgradepkg to replace them all with the corresponding files from slackarm-current does allow X to start, using fbdev . But there is no mouse support at all.
More on the positive side:
The touchpad works in the console using gpm -t evdev -m /dev/input/event1.
An external mouse comes up as event6 when plugged in. There is no kind of /dev/mouse or /dev/input/mouse* or /dev/input/mice after the machiine boots. But there seems to be something screwy with udev. It is always shutting down and restarting the mouse. It was even trying every time to check whether the mouse is an MTD device (!) until I blacklisted that, but it still re-starts the mouse all the time. The mouse does sort of work with gpm, though.
One of the obviously bad things about Arch was that the system is mounted rw. I managed to fix that. The booting script is kept in /dev/mmcblk1p12 (pretty standard, AFAIK) and I was able to take their script, shave off all the binary bytes on the top line, change the rw to ro, and re-run mkimage in order to get a bootup into an ro filesystem.
I should explain what is happening with the Arch booting. First, they want to use nv_uboot. The “nv” means “no verification” so it is possible to boot any kernel even if it is not “signed.” At least this is the theory, which is why I have kept struggling with this in spite of the problems listed above. The procedure is
1. partition the SD card. They suggest to do this with the tools in Chromeos, but it clearly does not need to be. Partition 1 will have the nv_boot code dd’ed onto it.
Partition 2 (ext2) is for the kernel. The kernel has to be called vmlinux.uimg. I understand. A symlink pointing to the name vmlinux.uimg does work.
Partition 3 (ext4) is the root partition containing the Linux filesystem.
Partition 12 (fat32) will contain a directory called u-boot containing (a) boot script(s).
This actually seems to provide a nice booting scheme, which as I said continues to tempt me to keep trying.
Also as I said I am not sure exactly what alternatives are recommended. In particular, I notice that there is a uinitrd file and I don’t know if it is required, or merely useful in some situations, and also I am not quite sure how to set up a boot script which calls upon it. So this is one obvious question about what is going on.
In any event, if one puts the alienarm kernel in partition 2 and renames it or symlinks it to vmlinux.uimg, the boot process does find the file and starts to boot from it. Then messages scroll past too fast to read them until one gets to the bottom of the screen. At that point the screen goes blank and stays that way. No network access, either; apparently the boot just stopped and it isn’t a matter of putting in some different script options to keep the screen alive. Based upon past experience, I would not analyse this problem as due to the “missing” uinitrd file, because what happened on all such occasions I got a normal boot until there was a kernel panic message. Here, there is no such message. The boot process just falls off the side of the earth with no visible messages at all.
I would be very interested if someone can pass on suggestions about how to get out of some of these problems. In particular, an alternative setup which might make it possible to use the alienarm kernel might be interesting. I do have another SD card.
Now, while I am posting a long post anyway, I will conclude with a somewhat unrelated question.
@wkt
How did you make that 7″ WM8850 netbook boot from the SD card? Mine seems not to want to do that at all. No matter what I do, it just goes on to boot up in Android. I have begun to suspect that it is blocked and the device needs to be rooted or put into “developer mode” before SD booting is permitted, but there is absolutely no documentation which says so. Do you know anything about this?
Theodore Kilgore
Hello,
I lern howto use Your bootstrap for ARM port, but it doesn’t run without errors.
I would like to know, if You will update it to slackware-14.1 ? I will use it with cubietruck and cortex-a7 A20 processor
Hi,
Great work! Used this to get my Beaglebone Black to run Slackware 14.1
Regards
Casper Mogensen
Are there any updates on this project? I love the hardware but not so much the OS, can’t wait to see Slackware up and operational on it.
Hi,
I have been working with Slackware and the trimslice platform trying to do some changes in the bootstrap to build a Slackware 14.1 version with hard float. You can check it on: $URL/en/scripts/slackwarearm-trimslice-hard-float
Many thanks Eric,
Regards
Any updates?
Hey Eric, any chance you could compile a Watchdog package for Slackware Arm?
Thanks! in advance!
Following the discussion closely, as I want Slack to run on my Jetson-TK1, and this is a good starting point.
Thanks alienbob, this helped me get my head around cross-compiling and building other packages for ARM.
BTW if anyone’s bored do a search for “alien arm”.
Hi Eric, you may be interested in http://www.raspberrypi.org/raspberry-pi-2-on-sale/
This has arm7 and more ram, so should be suitable for the arm work you have done.
Yes, looking at that board with interest.
The link to ” TrimSlice” took me to a malware site.
Hi Jack,
Apparently they let the domain expire, the TrimSlice computer has reached EoL.
I have updated that bad trimslice.com link with a link to the actual company that’s selling them.
Eric,
I found a device called odroid, it’s based in raspberry, but I think it’s more powerful at the same price.
And… Great work!
Awesome just installed thank you! Also I updated another chip i had lying around with arch arm and it works good so far. I didn’t use it for five months. shrugs maybe theres something going on with it though…. 🙂
Hi Eric,
I can provide several root file systems for ARM devices for you. These systems already have GCC, LLVM, and almost all utilities for development. Please look at ftp://ftp.radix.pro/radix/platform/releases/1.1.672/ directory. Package lists you can find in *.pkglist files (for example: ftp://ftp.radix.pro/radix/platform/releases/1.1.672/s9xx-glibc/khadas-vim/khadas-vim.pkglist). If you will install Slackware package utilites I think you will can to build Slackware packages on small devices such as China OTT boxes (Khadas, Nexbox, etc.)
Best Regards,
Andrey K.
i have a khadas vim that seems usuable i would REAlly love to see an iso!! or instructions to use slackware on this hardware.
Cool work! And, I also hope my arm devices can run slackware, but I have not have a complete try so far. If there is a development document for build a usable arm slackware? If so, I will try it for my Raspberry Pi 3b, 4b, and other tda series arm devices. Thanks
i stopped developing my ARM port many years ago, because I could not wrap my head around the ‘alien’ architecture. Nowadays you stand a much better chance at using Slackware ARM by using the information and downloads from the SARPi project: https://sarpi.penthux.net/ . This is an effort to make it easier using Slackware ARM from https://arm.slackware.com/
Thanks. I use your plasma live version for 3 years. Thanks for you cool work!