Alien Pastures

My thoughts on Slackware, life and everything

Tag: ARM (Page 1 of 2)

Raspberry Pi and Broadcom: a birthday present

March 3, 2014 / / 2 Comments

475px-Raspberry_Pi_Logo.svg Two years ago (on 29 february 2012), the Raspberry Pi Model B went on sale. More than 2.5 million Raspberry Pis have been sold to date! An amazing number, considering that the original goal was to equip british school kids with cheap hardware for Computer Science education.

Thanks to these enormous sales numbers, the Raspberry Pi Foundation (a not-for-profit organisation) was able to sponsor several Open Source projects writing code which can be used with the hardware (XBMC, libav and many others).

And now, two years later, there is a new surprise. The Raspberry Pi has been developed as “open” as possible, however there was a part of the hardware which was not open: the VideoCore IV 3d graphics core on the Broadcom application processor for which only a “binary blob” exists and which is addressed by a thin layer of Open Source graphics kerneldriver. This is not unusual – most if not all of today’s ARM-based mobile hardware has a closed-source graphics stack and no public register-level documentation of the hardware.

This is changing now! As announced on their blog, Broadcom has decided to open up their VideoCore IV 3d core to accompany the two-year anniversary of the Raspberry Pi. The code of the graphics stack has been open-sourced under a liberal 3-clause BSD license and  it’s accompanied by complete register-level documentation for the graphics engine. This is unique for the ARM hardware platform as far as I know.

If you are an experienced hacker/programmer, you may be up to the challenge posed by the Raspberry Pi Foundation: to port the open-sourced graphics stack (for the BCM21553) to the Raspberry Pi’s processor (BCM2835). And they will pay you a bounty of $10,000 if you are the first person to demonstrate satisfactorily that you can successfully run Quake III at a playable framerate on Raspberry Pi using your ported drivers.

How cool is that? Of course I hope it will be a Slackware hacker who will reap this reward.

Have fun! Eric

Last week’s harvest

May 18, 2013 / / 13 Comments

I was a bit too busy and tired to write something on my blog during the past week, but now that it is weekend again, there is room for some updates.

Flash Player Plugin

There was yet another security update for Adobe’s Flashplayer Plugin. I updated my package to the latest version. Note that if you are using my Steam Client package, you will probably have installed the flashplayer-plugin in order to see all the news in the Steam Store. If you are on a 64-bit Slackware platform with multilib, you should not just update the 64-bit flashplayer-plugin but also convert the 32-bit package into a “compat32” version and upgrade the 32-bit package you will already have installed for Steam:

# convertpkg-compat32 -i flashplayer-plugin-11.2.202.285-i386-1alien.txz
# upgradepkg --install-new /tmp/flashplayer-plugin-compat32-11.2.202.285-x86_64-1aliencompat32.txz

KDE

The kdelibs package in my ktown repository (KDE 4.10.3) has been patched to prevent application crashes. Coincidentally this patch has also been applied to the kdelibs package in slackware-current.

Slackware Dependencies

A nice and fast tool to discover and query dependencies between Slackware packages is sbbdep which stands for “Slack Build Binary Dependencies”. Its author, a4z, released version 0.2.0 last week. I use this tool to assist me when determining the build order of packages for my ARM port.

ARM Port

Speaking of which, there is an interesting thread going on on LinuxQuestions, regarding ARMedslack and the Raspberry Pi. Someone who goes by the nick “Ahau” and comments on my blog from time to time, is working on a hard-float port to the armv6 hardware platform – the heart of the Raspberry Pi. He is using my ARM source tree for this, has given me good feedback which resulted in bug fixes, and his ultimate goal is to create a new ARM version of Porteus. The most recent part of the LQ discussion centered around my decision to split the libtinfo library (terminfo) out of the libncurses(w) library. This is the ncurses developers’ intention for the future, however it causes issues when compiling software which is not querying the system properly and assuming that only libncurses(w) is required for linking.

I had nearly decided to revert my decision and integrate libtinfo again into libncurses(w) when ponce pointed out a patch which I had already seen in Fedora’s ncurses package source. Perhaps I will apply that patch to my ncurses package because it seems to resolve all the linking issues we have been running into lately.

LibreOffice ARM?

And more good news – it took two days of compiling because I forgot to enable distcc, but I managed to create LibreOffice packages for my ARM port, using the SlackBuild script with which I already compiled LibreOffice 4.0.3 for x86 and x86_64 platforms last week (I needed one additional patch to work around the newer boost-1.53 which I have in my ARM tree). I have not had the chance to install the packages and run the LO Writer to see if I created working binaries… but the build log did not show errors which is promising!

Desktop Environments other than KDE or XFCE

Long ago, I created a package for razor-qt which is a minimal (lightweight may be the better word) desktop environment based on Qt. In other words, it looks beautiful (by not using GTK) and does not have the sluggishness people complain about when they run that other Qt based desktop environment (KDE). I was thinking about what I would have to add to a filesystem image for the ARM ChromeBook which I should finally get ready and distribute… I do have KDE packages, but KDE felt like just a bit overweight for the ChromeBook. I do not really like XFCE (don’t get me wrong, technically and functionally it’s not bad at all, but GTK does not have any visual appeal to me) and therefore I felt compelled to re-visit razor-qt.

Razor-qt does not come with its own window manager, instead it allows you to pick one of the available window managers it finds on your computer when it starts for the first time. Razor-qt will work well with KDE’s window manager KWin, but it works best with OpenBox. And since that is not part of Slackware, I added an openbox package as well to my repository (which was the moment that I found out I had never released my original razor-qt package… no idea how I could have forgotten that).

I decided that I am going to build armv7hl packages for razor-qt and openbox so that the ChromeBook has a nice and fast, good-looking desktop environment next to XFCE. They will be uploaded to my separate “alien” subdirectory of the ARM package tree, where I will upload the LibreOffice packages as well.

KDE Display Manager

The KDE Desktop Environment is transitioning to Plasma Workspaces 2. Two changes are worth mentioning because they will have a big impact: Many “user-interface centric” applications will be re-written in QML (Qt Modeling Language). More importantly, the X.Org display server of old will be abandoned for the Wayland protocol server. Wayland gives you a 3D-enabled display server from the start, instead of the current practice of running a 3D compositor (KWin, compiz) as an extension under the 2D X.Org display server. Future support of Wayland requires a rewrite of KWin (KDE’s window manager) but also forced a decision to say goodbye to the KDE Display Manager (KDM) which is the graphical login program which greets you when you boot Slackware in Runlevel 4. A blog post by Aaron Seigo gives a lot of insight in the process that preceeded this decision.

It looks like SDDM (Simple Desktop Display Manager) is a contender for replacing KDM in a future release of KDE. Initially, SDDM had a hard dependency on PAM, but thankfully the developer is friendly towards Slackware. After a short discussion on Google+ he created a preliminary “pam-less” version which I tested. Those tests went OK and the changes were added to the main source. So it is with pleasure that I announce the package which I added to my repository. You can already try it out, if you just add a couple of lines to Slackware’s “/etc/rc.d/rc.4” script. Directly below the line that says:

echo "Starting up X11 session manager..."

you add:

# ----8<----------------------------------------------------------------
# Use Simple Display Desktop Manager
 if [ -x /usr/bin/sddm ]; then
 exec /usr/bin/sddm
 fi
# ----8<----------------------------------------------------------------

Enjoy!

Eric

Call for help: Slackware on an ARM Chromebook?

March 19, 2013 / / 37 Comments

Well folks, the ARM-powered Chromebook built by Samsung can finally be bought in the Netherlands, and this raises a hairy question. Should I buy one and have a real-life target for my ARM port of Slackware which has been on the backburner for a year?

As you may remember, I started an ARM port of Slackware which is different from SlackwareARM.The design goals I have set for my own port are:

  1. it should have 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
  2. it should target modern ARM architectures. SlackwareARM targets older generations of ARM CPU’s – notably without hardware floating point support. I want to create a port which can be used on “powerful” ARM tablets, and laptops.
  3. it should be a port from scratch and the process should be documented

I bought a TrimSlice ARM computer late 2011 but unfortunately that hardware did not live up to the promise.It is a nice developer box (meaning it builds packages faster than other ARM computers) but it has not become a consumer product.

I have been thinking about buying a tablet as my new target for the ARM port, but there are no interesting hardware choices really which warrant the effort I have to spend on making Slackware work really well on a touch device. There are some tablets which are catering for Open Source OS-es, like The ZaTab, but it is relatively expensive, not too powerful and this too, never became a viable consumer product. The Vivaldi tablet created by KDE developers is still awaiting its birth and I have no idea if this tablet will be more than a gimmick or even vaporware.

And here is that ARM powered ChromeBook! With 7 hours of battery life, no moving parts, fan-less design, a real keyboard and an exceptional screen (I have held one in my hands) it does not come with any local storage of interest… because it runs ChromeOS on a 16 GB SD card, and you are supposed to store and access all your stuff online in a Google Drive. But, if this laptop would run Slackware, you could add a larger SD card, or plug in a USB hard drive and have a very interesting laptop indeed!

Well, here is the catch. I do not have the funds to buy this laptop. Financially it is looking a bit bland here at the moment. There is some donation money coming in every month, but that is a trickle and does not even pay the electricity bill for the server (which is OK since this is not my job, it is my hobby after all).And this laptop has been eyeing at me from its Google web page, and I seriously like it, and like to have one. I know that Stuart Winter (creator of SlackwareARM) bought one for himself and is working on a SlackwareARM boot.

I decided that there is only one way in which I can revive my own ARM port, and build a hard-float ARM image of Slackware with KDE for that ChromeBook. And that is to ask you people for support.



Note that I already received those 300 euros I needed to purchase the ChromeBook… in fact I received three times as much! As explained on the ARM Port page, the additional money will go into the purchase of additional hardware after I finish the ARM port, or earlier if I need more ARM computers to speed up the compiling process.

Yes, a “donate” button. What I propose is that I try to collect the 299 euros in donation money that it will cost to buy the ARM ChromeBook in the Netherlands. The “donate” button above will lead to a PayPal page where you can contribute an amount of money that you can spare. I will create a blog page http://alien.slackbook.org/blog/armport on which I will keep track of the progress and will mention everyone who made a donation to this cause. If you do not want your name listed,  you can tell me so on the donation page.

In return for the donation money, assuming I am able to collect these 299 euros:

  • 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, to start with
  • 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.

I do think that this ARM ChromeBook might be a real viable consumer product worth buying by more than just developers and geeks, and if Slackware runs on it that would be awesome!

What do you think? Am I crazy to ask you for support money? And what if I do get money, but more than 300 euros? Should I try to buy another ARM product (like, a tablet) or return the surplus money? If I fail to collect those 300 euros, people will get their donations back in any case. Feel free to spread the link to this page so it gains some more attraction.

Eric

New VLC and FlashPlayer releases

December 15, 2012 / / 7 Comments

Just a saturday afternoon post… I intended to write about these updates earlier, but I had a very busy work week which did not leave room for Slackware PR. Now that my two-week holiday has started, I have my hands free to work on software updates, my ARM port (which is again threatening to shrivel up and die, I am so much behind on -current) and I also want to put some serious work to a viable Slackware setup for Valve’s Steam client for Linux.

VLC Media player

The sixth version of VLC’s “Twoflower” (codename for the 2.x series), is “a minor update that improves the overall stability. Notable changes include improved reliability for MKV file playback, fixed MPEG2 audio and video encoding … and other fixes. It also resolves potential security issues in HTML subtitle parser, freetype renderer, AIFF demuxer and SWF demuxer.” – quoting the VideoLAN news page.

I checked the release notes page for 2.0.5 but was a bit disappointed that they just re-used the 2.0.4 release notes, changing “2.0.4” to “2.0.5” which means the release notes page is just bogus.

Can anyone tell me how the new “ogg opus” support works for you? This new codec is supposed to replace other low-bandwidth codecs like speex but I have not seen any real-life cases.

When the IRC developers channel mentioned earlier this week that the 2.0.5 release was nearing completion, I compiled the VLC “dependencies” tarballs in advance. Remember that I have to create 8 VLC packages when VideoLAN developers release a new version of their player (two Slackware releases, two architectures per release, and then restricted/unrestricted versions of each). The pre-compiled binary tarballs  of statically-compiled dependencies or “contribs” speed up the process of creating these packages a great deal. The main update to these “contribs” for the new packages is for the ffmpeg libraries: I switched to the git snapshot which is considered the best available version by both VLC and at least one MPlayer build team.

A note about BluRay support: I do not own a BluRay player, not BluRay disks or “downloaded” movies. The BluRay support in VLC (at least in my package) works only for unencrypted disks… and I do not think these exist actually – but I can not verify this. If you are able to playback BluRays please let me know about your experiences. Playback of encrypted BluRay DVD’s requires that you also install my libaacs package: http://slackware.com/~alien/slackbuilds/libaacs or http://taper.alienbase.nl/mirrors/people/alien/slackbuilds/libaacs/) and find yourself a set of AACS decryption keys (see these comments for some hints on that).

Where to find the new VLC packages:

Rsync acccess is offered by the mirror server: rsync://taper.alienbase.nl/mirrors/people/alien/restricted_slackbuilds/vlc/ .

My usual warning about patents: versions that can not only DEcode but also ENcode mp3 and aac audio can be found in my alternative repository where I keep the packages containing code that might violate stupid US software patents.

 

FlashPlayer-plugin

I also upgraded my Flash Player packages. Adobe plugged another set of critical vulnerabilities (CVE-2012-5676, CVE-2012-5677, CVE-2012-5678) and if you are using a Mozilla-compatible web browser to watch Flash content, upgrading is strongly recommended. For more details, check here: http://www.adobe.com/support/security/bulletins/apsb12-27.html .

After upgrading, use the following URL to check that you are indeed running the latest version of the Flash Player plugin: http://www.adobe.com/software/flash/about/ .

Have fun! Eric

 

Java in Slackware ARM

November 11, 2012 / / 2 Comments

I am slaving away on my ARM port. It is mostly a side activity at the moment, I am doing a lot of other things which are higher on the priority list while I am getting the core ARM package set on par with the Slackware 14 versions. But it did already enable me to build a working version of the OpenJDK packages using the same SlackBuild script (well, a teeny bit of editing was needed) which I am using for the “Intel-compatible” versions of Slackware.

MoZes (Stuart Winter, the maintainer of Slackware ARM) decided that this was a good enough time to use this SlackBuild script and finally add a working Java to Slackware ARM.

From his site comes this message:

Thanks to the work of Eric Hameleers, Slackware ARM v14.0 and -current now sports OpenJDK and OpenJRE packages. A JRE has always been absent from Slackware ARM, so I’m particularly pleased to be able to now strike one off the “missing package list”. I hope it’s useful!

Slackware 14.0 has the packages in patches and -current has them in extra/openjdk. You’ll need to install the “rhino” package as this is a run-time dependency.

This is also good news for people who want to experiment with Java on their Raspberri Pi or Pandora Box for which ARMedslack community builds are available.

Eric

« Older posts

© 2024 Alien Pastures

Theme by Anders Noren — Up ↑