Having just released an updated version of Tribblix for x86, a little commentary on the status of the SPARC version is probably in order.
After a rather extended delay, there is an updated version of Tribblix for SPARC available for download.
This is Milestone 16, so it's at the same level as the prior x86 release. More precisely, it's built from exactly the same illumos source as the x86 Milestone 16 release was. Yes, this means that it's a bit dated, but it's consistent, and there have been a number of breaking changes for SPARC builds introduced (and fixed) in the meantime.
I did want to get a release out of the door, before bumping the version to 0m17 ready for the next x86 build. Part of this was simply to ensure that I could actually still build a release - it gets tested on x86 all the time, but as it happens I had never built a SPARC release on my current infrastructure.
In terms of additional packages, the selection is still rather sparse. I haven't had the time to build up the full list. This isn't helped by the fact that my SPARC kit is rather slow, so building anything for SPARC simply takes longer. Much longer. (Not to mention the fact that they're noisy and power-hungry.)
It's not just time that's the problem. I've had some difficulty building certain packages. I'm not talking the likes of Go and Node, which I can simply ignore as they're not ported to SPARC at all, but some reasonably common packages would fail with obscure (and unexpected) build errors. If there's a problem with one component, that blocks anything dependent on it too.
Other than expanding the breadth of available packages, the key next steps are (i) to make Tribblix on SPARC self-hosting, like the x86 version has been for a very long time, and (ii) to try and keep the SPARC release more closely aligned so it doesn't drift away from the x86 release and require additional effort to bring back in sync.
7 comments:
I appreciate your effort on this a lot. I'd like to get more involved in the illumos project but my skill level isn't quite there yet.
Thanks! Just appreciation is good.
Involvement can take many forms. Just being a user *is* being involved; better if you let people know about it. Participation in mailing lists and IRC helps build a stronger community; reporting successes and failures so we know what works and what doesn't helps build a stronger product.
Thanks for working on this!
Does the image have a Sun disk label? Trying to boot tribblix-0m17.iso under qemu I get:
Sun Fire T2000, No Keyboard
Copyright 2005 Sun Microsystems, Inc. All rights reserved.
OpenBoot 4.20.0, 256 MB memory available, Serial #1122867.
[mo23723 obp4.20.0 #0]
Ethernet address 0:80:3:de:ad:3, Host ID: 80112233.
ok boot -v
Boot device: /virtual-devices/disk@0 File and args: -v
Bad magic number in disk label
Can't open disk label package
Can't open boot device
tribblix-0m17.iso is the x86 ISO, so that won't work. The SPARC version is still at 0m16.
I've never had a successful boot under qemu myself. What version of qemu are you using, and how are you calling it, because mine doesn't show up as a T2000?
(You'll probably need to allocate more memory, probably 512M would be enough for boot, but 1G for an install.)
Indeed, I haven't noticed that 0m17 doesn't have the -sparc prefix!
> mine doesn't show up as a T2000?
Right. I haven't submitted the T2000 into the upstream. It is still WIP.
> You'll probably need to allocate more memory
Getting more than 256M is tricky: I use the pre-compiled OpenSPARC OBP, which has the value 256 hard coded. Probably this is the reason for the 0m16 failure:
ok boot -v
Boot device: /virtual-devices/disk@0 File and args: -v
hsfs-file-system
Loading: /platform/sun4v/boot_archive
ramdisk-root ufs-file-system
Loading: /platform/sun4v/kernel/sparcv9/unix
module /platform/sun4v/kernel/sparcv9/unix: text at [0x1000000, 0x10def3d] data at 0x1800000
module /platform/sun4v/kernel/sparcv9/genunix: text at [0x10def40, 0x12f581f] data at 0x1936dc0
module /platform/sun4v/kernel/misc/sparcv9/platmod: text at [0x12f5820, 0x12f5827] data at 0x198cb68
module /platform/sun4v/kernel/cpu/sparcv9/SUNW,UltraSPARC-T1: text at [0x12f5840, 0x12f9aff] data at 0x198d140
panic[cpu0]/thread=180e000: lgrp_traverse: No memory blocks found
Warning - stack not written to the dumpbuf
000000000180b710 unix:lgrp_traverse+120 (fff32000, 10d5f30, 2000, 7efefeff, 81010100, ff00)
It it possible to build an image which would start up with 256M?
Ah, right. I've tried using that OBP with the M5 simulator, and couldn't work out there how to change it to give me more memory.
That said, the ISO ought to boot on 256M. It's got essentially the same footprint as x86 (it's intrinsically a bit bigger, but that's cancelled out because there's no 32-bit kernel), and the x86 version works just fine on a 256M machine.
In fact, the error you see is coming from illumos, it's the same error I get on M5:
http://ptribble.blogspot.co.uk/2015/10/fun-with-sparc-emulators.html
and I think there's something odd about the emulated memory layout.
> and I think there's something odd about the emulated memory layout.
At a first sight I see nothing fancy in the RAM layout: a contiguous piece starting at 0x80000000. Is it possible to make illumos/Tribblix to tell what blocks is it allocating?
Post a Comment