Building for Transmeta Crusoe (or simply i586 in general)? about os HOT 5 CLOSED

Wow, I'd never heard of this machine before. Yes, the x86q port should build appropriately for an i586 machine. It's worth a try. The only things that might get sticky are that we need an APIC, and appropriate ACPI tables (FADT and MADT mostly). In my extremely brief googling of this device I also noticed what looks like a patch to upgrade the machine to i686:

http://www.techeye.net/software/patch-turns-transmeta-crusoe-into-a-full-i686

from os.

If I understand the article correctly, that trick is catching the wrong opcode (via exception or similar digital magic) and triggers a routine in the kernel to emulate the correct behaviour.

For Minoca this means, it would need to have this routine in the kernel too...

That's beyond my knowledge (as of today) and probably not worth the effort. And for porting the x86q stuff over to the Crusoe I definitely know far too less about ACPI and friends.

I will extend my RasPI fleet to dive into Minoca and will give the Crusoes other stuff to play with... ;-)

from os.

I tried to add a variant for an architecture like x86 but using an i586 toolchain.

So far the result still doesn't like my Crusoe systems, but it happily runs in Qemu with -cpu pentium and accepts i586 packages from Minoca's packages server.

I named VARIANT=v to let 'V' like roman five hint to Pentium.

Probably I have totally screwed the Windows specific parts of the build by trying to guess what's expected in there. The current state only was tested on Debian-8.6/AMD64.

The diffs for "os" and "third party": x86v.diffs.zip

from os.

I glanced at the diffs. Correct me if I'm wrong, but it looks like you derived 'x86v' by looking at how 'x86q' works. Is there any difference between the two other than the 'os/images/Makefile' using '-ql pc' rather than '-ql galileo'?

While this is a good start, the easier route would probably be to extend 'x86q' to include a '-ql pc' image. Or just rename 'x86q' to your more generic 'x86v' and then add the '-ql pc' image. There is no real reason to have two build variants that target 'i586'.

That said, the boot is probably getting tripped up by what Evan pointed out earlier. The Crusoe does not have an I/O APIC, which Minoca requires. You'd have to support for the Cursoe's interrupt controller in 'os/kernel/hl/x86'. And then you'd have to check to see what ACPI tables the firmware is exposing.

from os.

While this is a good start, the easier route would probably be to extend 'x86q' to include a '-ql pc' image.

I just didn't dare to mix up 'x86q' directly and I wasn't expecting that adding the PC image would be all that needs to be done.

That said, the boot is probably getting tripped up by what Evan pointed out earlier. The Crusoe does not have an I/O APIC, which Minoca requires.

I'm not sure about Crusoe still being my target but I think, having a VM springboard for other 'i586' based systems is a good thing.

Or just rename 'x86q' to your more generic 'x86v' and then add the '-ql pc' image. There is no real reason to have two build variants that target 'i586'.

Ok.
So can you please add the PC image to the "Quark port"?

The naming question is a different dimension.

Why is the 'i686' port named 'x86'? That gives the illusion that it might run on all 86ers which definitely is not the case. It wants at least 'i686' aka Pentium-Pro.

Same with 'x86q' requiring at least 'i586' instead of some 86er.

So if both ports could be renamed to 'i686' and 'i586' would give a stronger connection between names and requirements and as with 'armv6' and 'armv7' the name directly would map to the arch part of the packages' names ('minoca-$ARCH').

Some IFs less in install scripts... I like that idea...

But probably 'x86' and 'x86q' already are burned in too many brains and scripts. That change would not be as cheap as just adding the PC image... :-(

Maybe add i?86 names as aliases now and fade out the x-names slowly?

from os.