Is this an attempt to build a custom kernel?

[dolence]

Hi! Is this an attempt to build a custom kernel for the Kronos, allowing it to be used on newer hardware?
What exactly is this? I've been accompanying the work in two well known blogs and also an YouTuber which was messing around the OMAP board (not sure what he was trying to accomplish with this, though) but everything seems to be halted for a long time ago.

[cgudrian]

This is a replacement kernel for the Kronos. It is based on Korg's published sources (which are incomplete) and has been extended with XHCI support (by kronoshacker) and reverse engineered cryptographic DRM stuff.

[GitHuhl]

I'm attempting to build it, but I'm having trouble figuring out how and where to attempt a kernel made before I was born... I don't even know what kind of installation environment I would use to attempt to build this. There isn't any given information besides a comment on OP's youtube channel saying he uses an LFS VM to do it. Can you please help some of us help ourselves by getting us some information so we can get started?

I wouldn't even be trying to build this, however Marcan didn't post his own kernel as he suggested he would, and Kronoshacker's download links to ... nearly everything relating to the patches, including a direct link to the compiled kernel image are all gone.

So please; if we don't have a binary to use (why can't one be posted here? Korg owned none of the IP in the links to the Kronoshacker blog and so if only a few people currently have that kernel binary, it's important that instructions are provided.

Additionally, what separates the "new" kernel from the default one? I am motionless right now because I don't even know where to begin.

[cgudrian]

Firstly, the current default branch might be broken. You should checkout the branch kronos-new. From within the source tree you can build the kernel like this:

$ ARCH=x86 make korg_kronos_defconfig
$ ARCH=x86 make -j bzImage

After compilation the kernel can be found at arch/x86/boot/bzImage.

Installation of this kernel without direct access to the SSD is a little bit complicated and requires the generation of a system update USB stick. You can find a working system update stick on Kronoshackers blog. Download and extract the archive to a USB stick, put it into the Kronos and perform a system update. After that you can access the Kronos via SSH (provided you've also attached a USB ethernet adapter, of course).

Alternatively you can remove the SSD from the Kronos and attach it to a Linux PC.

[GitHuhl]

I am to see if this boots on an successfully rooted Korg Nautilus. Thank you for your help :)

PS Is GCC4.9 appropriate?

[cgudrian]

I'm not sure that's going to work. Make sure you have an emergency exit in case the device doesn't boot anymore.

[cgudrian]

The kronos-new branch compiles on my Fedora 39 system with the stock GCC 13. The original Kernel has probably been built with GCC 4.5 (at least that's the version Korg provides in their source code archive). So it should compile with GCC 4.9. The Linux kernel provides dedicated compiler support headers in include/linux/compiler-*.h. Currently there's support for GCC 3, 4, 9, 11, 12 and 13 (with 11, 12 and 13 added be me).

[GitHuhl]

To begin, I started by comparison of the nautilus updaters shell scripts with those of the kronos rooter. That was similar enough for me to attempt the rooting (which works on Nautilus totally unmodified, btw!). It was successful, and I have SSH-server access on nautilus with root credentials set by the nautilus-UI. It doesn't appear they (KORG) have changed very much under the hood, software wise.

I have followed typical sysadmin procedures for backups, rest assured :). Some may note: It is really annoying to take out the miniSATA drive because, unlike Kronos, it's mounted underneath the motherboard, but another thing worth exploring is if booting from the much handier SATA3 headers (kindly, nearly the only headers left on this board by Korg.. (No ethernet header either!) (which don't require complete removal of the motherboard)) is possible. I am exploring these questions as they arise.

Thank you for your Fedora 39 recommendation, if I have any issues building here (on NixOS), I will just set that environment up and use that. I will use the Kronos-new branch as suggested.

[GitHuhl]

Interesting. I can't get the Nautilus to boot this kernel, even when compiled with the Fedora environment (which indeed is the best output I can get thus far).

Some observations:

The Kronos rooter itself doesn't appear to cause audio glitching. It can be ran completely unmodified (as if prepared for a Kronos) as an update stick. You just have to trigger it from the booted Nautilus via the typical menu.

I am using Nautilus OS 1.1.1. I cannot get the kronos-new kernel to boot. I have confirmed that /boot/grub/grub.conf is not a file that can no longer be modified, as some on other relevant forum posts online have suggested, because I can repair/damage the ability of the Nautilus to boot with simple edits to this file, including leaving it in states with additional data than it normally has. (One thing I have thought to try is to see what happens if I replace the kernel /boot/grub/grub.conf points to with an official Korg Kronos kernel. As I go there, my mind goes to ..)

Today, I attempted once again by mounting /boot via ssh, to point grub to boot the kronos-new kernel from here. It definitely did that, because that triggered a system fail to boot warning from the Nautilus. Routinely I have been able to get back to normal without a reimaging, and by only modifying grub.conf's default selection (I always choose the alternate init path so I can keep root/dropbear access).

While I was there, I also followed the steps from Marcan's blog to use the loadoa.sh script, copy out the image mount contents, etc. This step, today, I believe triggered audio distortion. I wasn't able to boot this Nautilus with the kronos-new kernel + the defanging steps on Marcan's blog, but the userspace modifications didn't prevent me from booting again when changing back to Korg's nautilus kernel. (I think all I did was rm loadmod.ko, with audio distortion having been present before and after that)

Does this maybe point to a change in the magic value programmed into the cdrom drivers from Kronos to Nautilus?

[cgudrian]

This sounds like it might be a good time increase the kernel log level, hook up a monitor and look for errors. You might also gain some insight by plugging in the SSD in your computer and look around in the file system.