Organelle - linux upgrade project

Organelle Hacking
1

EDIT: ok, to be clear, to end users this topic is not really that interesting…

but just so I dont come across as a complete geek, that is doing this for kicks, a quick explanation as to why Im doing this project.

the purpose of this ‘project’ is to upgrade the underlying OS used by Organelle from a system that is pretty dated to a new version of Linux that is fully supported, and much easier to continue upgrading.
as such, the user (rightly) never even notices Organelle running Linux, so why do they care?

the short answer is, in itself they don’t, they are only interested the potential it brings… which is more up to date software, and then with that patching possibilities … i.e. this is solely an ‘enabling project’

secondarily, newer versions of linux have much improved hardware support, so this is also a factor.
(hmm, depending on your other hardware perhaps this is the primary benefit :wink: )

anyway… thats it, from here on in the rest gets pretty geeky…

so I was looking at Kernels again… and decided to try a different tack!

and to cut to the chase,
Ive got a 4.14.6 kernel/system running on my Organelle, a fully up to date linux system :slight_smile:

… just to manage expectations, im in early testing still, but its looking promising.

what I decided to try, was to see if there was a distro that would work with the Organelle/Cubox,

  • Initially i tried using solid runs ‘attempts’ including ignition, and that failed , as did there manual install of ArchLinux.
  • I then tried ArchLinux (arm) (cubox) , that also failed… (but this might not be a dead horse yet :wink: )
  • so I moved to Armbian - BINGO… both the cut down debian 9 stretch and desktop ubuntu xenai, both boot successful.

so Armbian is doing something very useful…
tested and working : sound (both sgtl5000 & hdmi), graphics , wifi , usb stick
I upgraded the deb 9 minimum release, and no issues… so really its all current.
(only one issue Ive had, is it shutting down when playing youtube… not quite sure why yet)
only config i had to do so far (except wifi etc) was to select the correct DTB, otherwise it didnt see the sgtl5000

so why is this good?
well if its stable, then we know the 4.14 kernel does work , and we also have an example of u-boot successfully booting it, moving to a later kernel, and also up to date packages/distro all makes support easier.

@AndyCap has notice the perils of using older distros this, whilst trying to get the SCIDE working :wink:
Im quite excited to see if we can get the accelerated graphics work, and so get some more performance for OTC/ETC.

ok, so I need to think about where to go next?! or whats the goal?

I think there are a couple of options:
a) switch to debian/Armbian, perhaps use the Minimal install , and strip it back further even, install X with Lightweight WM.

b) look at what Armbian is doing with u-boot/kernel , and see if that can give us clues as to why ArchLinux(arm) is not booting.

c) switch to Ubuntu - strip it down - not really an option, but worth mentioning , as out of the box its so close.
(perhaps I might keep for a dev environment ;))

whats your thoughts @oweno? push with ArchLinux , or consider Debian?

from previous discussions, perhaps ArchLinux is not the best for this kind of application, because the rolling release idea could be problematic for specialist SoC.

having been playing/developing with Organelle_UI/PD etc, I suspect it wouldn’t take much to switch to a different distro (and end users wont see/care)… I think an hour or two.

of course… these is all a bit premature, my next step is to put mother host, pd and also otc on the debian release, and then run it for a bit, and see how it feels, check no audio drop outs etc.

once this is done, I will also rebuild the kernel (we have the kernel configs, yippee!), to change it to pre-emptive, and check the sgtl5000 code, to see if the previous fix is still needed.

the main thing to test though is stability, as ‘new kernels’ , can always have quirks :wink:

anyway, quite happy to have got this far today :boom::

11 Likes
2

Wow, yeah have a shandy and a sit down!

1 Like
3

Most of this post went well over my head but I know it’s good and exciting news!
Thank you @thetechnobear!!

4

Wow nice job, thanks for the snow :slight_smile:

My bet would be Debian/Ambian over Arch. If you can get the pre-emptive kernel going it has to be a better bet.

I did try with the most recent 3.x solid run debian image today to have look at the EGL stuff, and at a cursory glance the GPU EGL stuff didn’t crash but didn’t seem to work that well.

Moving to 4.x would be a much better bet in the long run.

5

Ok mother is running, launch patches, patches work as they should do…
fun included :

  • getting it to select the right soundcard
  • adapting a couple of scripts - due to either difference in distro (or more likely just newer versions of sh/bash)

Ive also got a lightweight (ish) X on it too, that was more painful than expected.

Ive got some audio anomalies, but that was expected, and should be down to fine tune the kernel, and checking the sgtl5000 driver code - if the kernel compiles correctly (which it should!) then hopefully thats not too big a task, as i already know whats needed.

apart from that, I need to tweak the alsa midi setup, and sort out the ‘auto startup of mother’ (thats easy… might do under systemctl)

that should allow me to check the system in a proper musical setup to see how it behaves.
(that testing will take a while, just to make sure its really ok… I also need to test the image on my other organelle)

then there are other components to install, things like cherrypi, thats a matter of just installing the equivalent package via apt rather than pacman… that’ll enable me to test the web server/python and otc :slight_smile:

… then I’ll be back to the point of it being the Organelle it was yesterday , just a bit different under the covers :wink:

3 Likes
6

nice job, this is exciting. good to hear it is finally running with a more recent kernel.

I was never married to Arch. at the time it was a good choice being stripped down and flexible and the audio was working better, during my initial tests with Debian I noticed some glitches in the audio…but the whole rolling release thing is a real pain and has caused more trouble than it was worth during development, so I’d be happier with a standard release distro…

it should be fairly easy getting all the same packages installed, as it sound like you mostly did already. the window manager is jwm. I was able to get pretty much same X experience in Debian with the following

apt-get install jwm 
apt-get install xinit 
apt-get install lxterminal

there was a bug (or feature) in the SGTL5000 driver that caused a nasty click on the right channel when Pd started or stopped, but this might be fixed in the more recent kernel. if you haven’t noticed it, then it probably is no longer a problem. that was the only change I made, besides enabling preempt in the config (never tried installing the preemption patch, as I understand most of its benefits are in the stock kernel). you can also turn off the cpu governor to force 1GHz all the time (in the power save section somewhere)

also, starting mother with systemctl would be better… staring with .bash_profile is just crazy! but the reason for it initially was if the Organelle boots headless (and starts mother from systemctl) and then you start X to edit patches, then mother is not able to launch Pd in gui mode. but this can probably be solved, I just did the more hackish approach of using .bash_profile to launch mother, then shutting it down before starting the X session which would then relaunch its own mother

1 Like
7

Good stuff.

If you need someone else to check the image over once you are happy with it just get in contact and I can give it a go as well. I have plenty of memory cards :slight_smile:

8

first bit of good news… hdmi support is much better :slight_smile:

my waveshare 7" lcd touchscreen works ‘out of the box’ , something i couldn’t get working at all with arch linux.
this bodes well for ETC , for supporting other projectors/displays better.

next step… building new kernels etc.
on armbian this is really cool, basically it has a completely guided image builder, using cross compiler, which can be customised. (it can then rebuild the whole image, or just the kernel)
initially I’m just going to build an image, with the required changes to the kernel - but for C&G this might be an easy way to make customised builds for their products (current and future) that are ‘repeatable’

have to say so far I’m impressed with Armbian

** EDIT: some dev/research notes, while im waiting for compilation of the kernel/image… that others may be interested in.**

Customising images with Armbian

Build options : https://docs.armbian.com/Developer-Guide_Build-Options/
Customised builds: (eg patching) https://docs.armbian.com/Developer-Guide_User-Configurations/

FIXED_IMAGE_SIZE , allows image to be a fixed size, rather than rootfs grow to card side.
simple idea… is to have an 8gb image, with 4gb RO filesystem for root
however, interestingly, Armbian is able to grow filesystem on booting image for first time, so ideally /sdcards partition would grow to available space.

read only fs

read only filesystem… better to use overlay FS.
this way the rootfs on the card is read only, but an overlay fs is held in ram… this is consider more 'compatible’
my belief is this is allows temporary unwritten changes, which is probably useful for ~/root
there is still a mechanism to make the rootfs writable as required, using overlayroot-chroot
some talk of it on armbian forum here though not totally conclusive

other notes

Im taking notes, as i go along, whilst researching this - so know what im doing on the custom image.
though just scribbles in a notebook for now.
once Im happy with ‘build’

… once its formalised Im going to see what I can automate, and probably publish some of the notes where needed.

Im not doing the customisation, or read-only things , until Ive proven (to myself) that the performance is where it needs to be

1 Like
9

bit more progress today…

i now have a custom build running, with a kernel with preempt enabled, and also performance governor by default.

still gets some audio artifacts though…
and its (likely) because of an error i get when starting PD

priority 6 scheduling failed; running at normal priority
priority 8 scheduling failed.

this is pretty odd, since usually this is if your non-root (and im running, like currently, PD as root).
I tried to adding root to the audio group, and add the audio.conf for the limits - but no change.
( I also tried running as a user in audio group, and same issue)

im at a bit of a loss, given limits.conf seems to be the only suggestion offered by the internet :wink:

any ideas? - I need to get this fixed before the next ‘build’

another oddity, but does not seem to be an issue…
if you look at the current Organelle , you will see in audio settings it used ‘onboard codec (hardware)’.
similar in this build there is SGTL5000 (hardware) and SGTL5000 (plugin) … the odd thing is, SGTL5000(hardware) gives some strange weird glitchy noise, whereas SGTL5000(plugin) works absolutely fine.
what is the difference?
(Ive still not patched the sgtl5000.c, so perhaps this is the issue thats already been raised, and so we have a simple fix !?)

anyway, some good news to finish…

Ive got X with jwm working…
so I now know the full package list i need for the custom install
Ive added the script changes need (or at least that ive noticed so far) to a branch on my Organelle_UI fork, so thats easy to now deploy to new images.

also I tested the wifi card that doesn’t work on the current OS, and its works fine on this build, so again looks like there will be better hardware support.

SO… after Ive fixed the above ‘pure data’ issue, I’ll do another build
primary changes are :

  • add required packages to custom build , so i dont need to manually install
  • add snd_seq for alsa midi in kernel modules

also I want to review https://wiki.linuxaudio.org/wiki/system_configuration , but thats probably for the phase after the above… when I start looking at what can be removed.

1 Like
10

ok, some coffee, some sleep, some more snow…

Ive determined the issue with scheduling priority, its to do with CGroups.
a temp fix is to use

sysctl -w kernel.sched_rt_runtime_us=-1

but I can fix at the kernel level with

CONFIG_RT_GROUP_SCHED=n

doing this means the audio appears not to be glitching , so its looking pretty good now…

4 Likes
11

Looking like really good progress there, great job.

I had that Priority issue on a tinker board I have here, I never got to the bottom of it and then the Organelle arrived so I haven’t gone back to it. I will look at the CGroups stuff on that as well.

I also had the hardware/plugin issue on the tinkerboard. At the time the only difference I could see between them was the plugin versions allow resampling while the hardware ones only work at the sample rate/bit depth of the hardware. But on the tinker board even running at the correct values the hardware version would glitch while the plugin one worked fine.

1 Like
12

hmm interesting about the tinkerboard soundcard…
( funny, ive got one and was considering doing an armbian build for it ;))

have you found any info about the ‘plugin vs hardware’ its seems to be a PD thing, as aplay doesn’t show the 2 variants…
my current avenue of investigation is comparing an organelle running this build and one running arch Linux - handy having 2 organelles side by side - so far though, id come to the same conclusions as you.
( i also have another possibility, its failing on setting the hardware parameters in the alsa code, so i can write a small C program to do this, and see if i can get more info… this is actually how i solved the cgroup issue)

another interesting thing about armbian vs Arch Linux…
the Arch Linux version runs fine with the same DTB with the quad and solo (like), i.e. my upgraded organelle and a vanilla one - in my armbian build, you have to specify which , and they are not compatible.
my guess is that, the Armbian build is actually targeting specific features better, so its important which dtb is in use.
(its not an issue, you can simply switch between the two dtbs … though harder if you don’t have one of each :wink: )
does mean I need to do some more testing on the solo lite though.

anyway things have moved on …

status update…

so Ive now worked out Armbians system better, and I’m able to build an image that has all the required packages , and patches sgtl5000
this build is ready to use, all i had to do was install the mother host, and bang it worked, both in headless and X mode.

the ‘ultimate’ goal it to have an armbian build, that will build a full organelle image , that once ‘etched’ to a sdcard, just works.

so to get there, ive got the following left to do: (all relatively easy stuff)

  • set up root access correctly (passwd etc)

  • ensure usbdrive and sdcard are present, and functioning correctly

  • make mother boot on startup

  • add some more packages (including python-pip, and then pip install cherry pi etc) and test web/setup functionality.

  • build a organelle_UI debian package , and have the 3.0 install by default.
    (this make upgrade easier)

  • build a factory patches debian package
    i want it so that the default sdcard image, has all the factory patches installed to /sdcard, so that a new user literally can etch the image, and has a fully functioning organelle even without a usbstick plugged in.
    also i think providing an option for allowing users to upgrade all factory patches in a one click install could be super cool.
    these will go into /sdcard/Patches/Critter , from there of course users can edit/move as they wish)

as you can see its pretty close to being a useable build from there, we then need to do performance checks and tuning , and can also look to see if there are packages that we want to add/remove.
(its this stage, that we can probably sound out the current soundcard ‘niggles’)

p.s. a full armbian build takes me about 2 hours, though i can short cut this for some testing e.g. just to replace the kernel, or adding more packages - but it does mean i have to do these kind of changes in ‘phases’ to try to minimise the number of image builds i need to do.

the end result for me would be:

  • a full image to test… with features as above
  • updated organelle_UI to support armbian
  • a new repo (or perhaps in organelle_UI) containing all ‘userpatches’, packages needed for a user to build an image from scratch, open sourced, so others can contribute to its development.
    (if C&G are happy with it, then they would be the owner… so organelle_ui might be the right place)

anyway, I’m pretty happy, its been a bit more time consuming than I expected, but the end result could be really cool :slight_smile:

3 Likes
13

I don’t thing the plugin/hardware thing is a PD thing, it is an ALSA thing. You can list all devices in a different way using -L or --list-pcms, then you see the HW and plugin devices. I didn’t really get much further that this with it, the plugin versions worked so at that moment I was happy with that!

I had a look at Armbian and could only see support for the 2/4 core, where did you get the 1 core from?

I’m running a build for the tinker board at the moment, standard but with preempt turned on. I’ll let you know how it goes, it’s hammering my CPUs as I type this.

You seem to be making very good progress, it is very good of you to sort all of this out. Once you have an image let me know and I will test it out. It would be really good to get EGL running on the GPU. Also if we have the GPU working then I think there is a OpenCL EP build that could be used for some heavy lifting.

14

once you’ve created and installed an image, you can use armbian-config to switch the dtb, and then various combos of dual/quad, solo/dual lite and hummingboard 1/2 , cubox-i are all available.
Ive not determined if this can be done at ‘build image’ time yet… i suspect you can, either with a config option - or by a customisation step.

(if not, then what i’ll do is… install on the quad, switch it to solo , then create a new image from it… its an extra step, but possible… the issue is you need a dual/quad to be able to do this - or perhaps you can mount the image on a another Linux box and do it?!)

as i said, i’ll publish more details, and and such like later, but for the moment what I’m using is:

board=cubox-i, release = stretch, no-desktop , release=next,

in armbian-config, dtb , hummingbird board quad/dual or hummingboard solo/dual lite

after that is mainly been tuning kernel params things like preempt, performance governor, snd-seq etc.
(and as i say, now adding packages and patches as needed… that’s the cool thing with armbian its easy to customise)

btw… one other avenue of investigation, ive noticed the arch linux build seems to have OSS emulation, so I’m going to try to turn that on as well.

15

Hi There,

Playing around today I have built an Armbian system for the organelle using your info. PD works, sound works, preempt on etc.

I have supercollider installed as well but for the life of me I can’t get jackd working, do you have any pointers.

Cheers

Andy

1 Like
16

building the kernel with the sgtl5000 as built in rather than a module seems to fix the jackd problem, weird.

1 Like
17

yeah, I gave it a bit of a rest - other projects :slight_smile:

glad you got it working… what id ideally like to know is, can we get the ‘alsa hardware’ working , and what is the compromise of hardware vs plugin mode working, do we know there if there is a performance penalty?

the key thing here is… is the performance on this build the same (or better) than the current release… if not, whats the penalty?
obviously, end users wont care about a newer OS etc, if the performance is not at least the same.

p.s. its a starter to know on our quad cores, but we need to know (for general release) on vanilla organelles

Ive got a few other things I want to work on this week, but perhaps will get back to this during the week… its pretty close now :slight_smile:

18

Actually the jackd problem is still there, version 2 seems to have a problem, version 1works fine. Supercollider wants version 2 when installed with apt :frowning:

One thing that I do have that is annoying is a pop/click when the audio is initialised, do you get this?

I also have to use the hummingbird dtb to get the audio working, even when having it built as a non module. Not sure why this is. Are you doing this as well?

I will carry on looking at it from the supercollider side, also OpenGl/OpenCL and hopefully this can be some help when you get a chance to spend more time on it.

19

There is also a way around the newer sclangs dependence on X, I have it written down, not near the desk now.

Concerning performance the startup here is definitely slower, I can see that being an issue for the average user. I have the original board back in the cubox box, once I get somewhere with SC I will look at the impact of using the newer build on cpu and memory. I’m guessing there will be a memory hit at best.

20

yeah, startup… a lot more services are started up, so we can stop that… I doubt thats a real issue.

pop/click, I need to check this again - I think this stopped once i used the patched codec…

I also have to use the hummingbird dtb to get the audio working
yes, I think this is ‘normal’ ,the hummingbird i think has the codec, sg codec the cubox-i does not … at least thats my working assumption.

supercollider, my ‘issue’ is if we can have a command line form running without X - then this is cool (and what I built) , we do not want to be obliged to run X to run SC patches.
(imho, whilst running X/scide is cool for development, you do not want it for running ‘finished’ patches, we just dont have the spare resources to have that luxury)
… in the end, if that requires a separate SC build, so be it :wink:

is there a reason jackd 2 cannot be used? after all , we want to be using the latest distro/kernel so we can use the latest software? (is jack2 not available via apt?)
anyway, perhaps a low priority issue for now?