site  contact  subhomenews

The return of Pyro64

October 22, 2017 — BarryK

Every now and again, I get frustrated by the bloatedness and weirdness of Ubuntu and Debian DEBs, that I am using in Quirky and Easy builds. I did play with Pyro64, packages compiled from source in OpenEmbedded, but only briefly.

But have just completed a compile in OE, for the x86_64 architecture (not x32), and built a new Pyro64, and it sure is looking good.

The difference in size of deployed distro is incredible. Quirky Pyro64 (now at version 0.3.3) is 274MB, and that includes LibreOffice, whereas Quirky Xerus 8.3 is 331MB. These have about the same functionality. Furthermore, I will probably be able to reduce the size of the Pyro64 build, as this is an early pre-alpha build.

If Pyro64 is so good, why did I previously go back to building with Ubuntu DEBs?

Well, there were some issues at the time, for example with the video. However, I have tackled some of these, and things are looking very good.

Then there is the Ubuntu DEB repository. I guess that is the big thing, so convenient. With Pyro64, everything has to be compiled. Almost, there is a small repo of packages that I compiled, and we can add to it.

So, 'oe-qky-src' is active again:

Oh, one other thing. SeaMonkey is running without spitting out heaps of complaints to stderr -- that is very reassuring. I am wondering if I am just imagining things, but everything seems faster, including SeaMonkey.

The Pyro64 binary packages can be used for building Quirky and Easy. I am thinking, will bring out another Quirky, and if testers like it, might go the same way for Easy.

Tags: oe

Intel sna and uxa video acceleration

October 21, 2017 — BarryK

About four months ago, when I released Pyro64 0.2, built from binary packages compiled in OE, there was feedback about video rendering problems with Intel video hardware.

Blog post announcing Pyro64 0.2:

Forum feedback:

Today I investigated this, and found that OE has set the video acceleration to "sna", without support for "uxa". sna is intended to replace uxa, and has superior performance, but still has serious issues. The recipe file in OE:

The interesting parts are:

PACKAGECONFIG ??= "xvmc sna udev ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'dri dri1 dri2', '', d)}"

[sna] = "--enable-sna,--disable-sna" PACKAGECONFIG[uxa] = "--enable-uxa,--disable-uxa"

I am using the "pyro" release of OE. Looking in the github repo, I found that the recipe has been changed recently:

Which has this:

-PACKAGECONFIG ??= "xvmc sna udev ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'dri dri1 dri2', '', d)}"
+PACKAGECONFIG ??= "xvmc uxa udev ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'dri dri1 dri2', '', d)}"

The problem is, as far as I can understand how these recipes work, that change will have the effect of enabling uxa but disabling sna. Really, I want both to be enabled.

Linux From Scratch explains that both can be enabled:

Note, there is also another hardware accelerator called "glamor":

glamor is enabled in xorg-server, see meta/recipes-graphics/xorg-xserver/

Anyway, I have created recipes-graphics/xorg-driver/xf86-video-intel_git.bbappend in my OE-Quirky overlay, with this in it:

PACKAGECONFIG_append = " uxa"

...which, again, as far as I understand how these recipes are evaluated, should cause "--enable-uxa", and we will also get "--enable-sna", although LFS explains the latter is the default.

Tags: oe

Change core2 to nocona for x86-64

October 20, 2017 — BarryK

About four months ago, I released a build of Quirky built with binary packages compiled in OpenEmbedded, for x86_64 CPUs.

It was codenamed "Pyro64" and was version 0.2. Here is the announcement:

There is a link to a thread on the Puppy Forum. One of the testers reported failure due to a missing CPU instruction.

Yeah, the baseline x86_64 in OpenEmbedded/Yocto is defined as "core2". This refers to an early Intel x86_64 CPU introduced in 2006:

However, there are earlier x86_64 CPUs from Intel and AMD, and these had less instructions. Quoting from here:

The first processor to implement Intel 64 was the multi-socket processor Xeon code-named Nocona in June 2004.

Quoting some more:

Due to a lack of success with Intel's Itanium and Itanium 2 processors, AMD was able to introduce x86-64, a 64-bit extension to the x86 architecture. Intel followed suit by including Intel 64 (formerly EM64T; it is almost identical to AMD64) in the 90 nm version of the Pentium 4 ("Prescott"), and a Xeon version codenamed "Nocona" with 1 MB L2 cache was released in 2004.

Now, looking at what CPU options are available to configure gcc:

This option for '-march' is what I want:

Improved version of Intel Pentium 4 CPU with 64-bit extensions, MMX, SSE, SSE2 and SSE3 instruction set support

I have modified my fork of OE to use "-march=nocona" instead of "-march=core2".

Basically, what I have done is create "", based on "", see here:

Curious, you can see in above link, "-march=core2 -mtune=core2 -msse3 -mfpmath=sse", but there is redundency, as those settings for -mtune -msse3 and -mfpmath are the default for "-march=core2". Hmmm, anyway, I have retained that redundancy, and now have "-march=nocona -mtune=nocona -mno-sse3 -mfpmath=sse" -- I have explicitly disabled sse3, as I think there are some early x86_64 CPUs that do not have those instructions.

I have not yet submitted this to my OE github repo, want to see if it works first.

Tags: oe

OpenEmbedded x86_64 x32

October 18, 2017 — BarryK

I recently received an email from Jorge, asking if I was still interested in x86_64 x32 mode. He has been playing with a x32 port of Debian.

I did briefly look at OE and x32 mid-2016:

At first I thought, don't really want to get back into that. For a speed gain and smaller binaries, there are a lot of hassles. Some packages will not compile, some will need patches, some might compile then not work properly.

Nevertheless, I got intrigued and decided to see how far a x32 build will get in my latest OE port.

My blog posts on OE:

My port of OE:

Debian x32 port:

More useful links:

Jorge has reported difficulty with compiling SeaMonkey, but he has some patches, in case I want to tackle it.

Don't know yet. Just playing. OE is rocketing along right now, showing 18% complete, no compile failures so far.

EDIT 2017-10-19:

Got up this morning, examined the overnight compile. OE has completed the build, 650 packages successfully compiled (18 of those are no-arch, not needing compilation), only 6 failures.

The failures are:

kodi, hiawatha, xf86-video-sis, notecase, xine-lib, firefox

This is very good. Even the big guy, LibreOffice, succeeded.

EDIT 2017-10-20:

I imported the binary packages into woofQ, then stopped. This is too much of a diversion. It is going to bring with it a heap of issues. Nah, backing off. I am interested in revisiting OpenEmbedded, but only for x86_64, x86 and arm builds.

Tags: oe

No video at first, Pi2 and Pi3

July 04, 2017 — BarryK
Testing my new Pyro build on the Pi, currently at version 0.3.2, X fails to start and it stays at the commandline. Then, I type "xwin" and X starts.

So, what's the problem? I found from /var/log/Xorg.0.log, that '/dev/dri/card0' is missing. Or rather it takes awhile to appear.
I put a wait-loop at the end of /etc/rc.d/rc.sysinit, and found that it takes 4 seconds for /dev/dri/card0 to appear!!!!

I discovered why, not the delay, but why we have this new issue. Pyro is compiled in OpenEmbedded with support for VC4 video acceleration. Read about it here:

In 'config.txt':
# Enable VC4 Graphics

So, looks like I need to put in a permanent wait-loop somewhere, before starting X.


oe-qky-src on github

June 23, 2017 — BarryK
'oe-qky-src' is my custom layer for OpenEmbedded, to compile from source all the packages required for a typical Quirky, Puppy, or other Puppy-derivative.

Furthermore, it is now on github:

There is a nice "readme".

If you look in quirky/meta-quirky/recipes-quirky, there are about 140 recipes, packages that I have imported to OE.
The reason that I had to do all this work, is partly because OE targets embedded systems rather than a generic Linux distribution. Also partly because Puppy and derivatives are different from other Linuxes, with a different selection of packages, and many unique to Puppy.

You will also see folder 'downloads-oe'. This has snapshot tarballs of OpenEmbedded, taken just when the Pyro release was announced. I have provided the snapshots so that anyone building oe-quirky will get the exact same result as me.

To help me manage the github site, I have brought back SmartGit. This is a very nice GUI git manager tool, that I experimented with about a year ago:

...seem to recall, forum member 'gcmartin' put those instructions together into a single file.

Here is my original blog post about SmartGit, April 2016:

I have got SmartGit installed on my mid-tower desktop PC, as well as the Adobe JRE version 8u131.

I did briefly look at some others, for example Gitkraken, Git-tool and GitAhead, but each one had problems.
SmartGit is very sophisticated, and above all "just works". It is free for non-commercial use.

If anyone downloads 'oe-qky-src' and does a build, they will have binary packages, but then what? They will need woofQ to build a distro. Currently I am only providing woofQ as tarballs, and will upload the latest soon. However, maybe should put that on github also (?).
The woof-CE guys could also import the packages from oe-qky-src, they will need my script '0pre-oe', that will be in the next upload of woofQ.

SmartGit website:


OE build underway

June 21, 2017 — BarryK
As reported yesterday, I got through the long list of packages to be imported into OpenEmbedded:

To round it off, I also imported lots of xf86-video-* (Xorg video drivers) packages. However, several are cross-compiler unfriendly -- those are all exhibiting the same problem in the configure script, so I could probably figure out a fix.
For now though, will probably compile them in the target system and create PETs.

This evening have commenced the x86_64 target build, and am timing it. The previous build took about 9.5 hours.
This time there are many more packages, however that does not necessarily mean the build will take longer, as previously the last couple of hours was just libreoffice compiling, when all others had finished -- with a multicore CPU, those extra cores can be kept busy if there are more packages to compile.

Tags: oe