On 12/25/2015 01:59 PM, Bryce wrote: > Jose and I spent soooo many weeks getting that to work (mostly Jose for the > assembler stuff). Unaligned access problems galore and it's not trivial to > figure out when your in the first stages of booting and have no usable > debugger > to work with.
Heh, that's how programmers always had to do it in the old days ;-). Glad you finally figured it out and thanks a lot for fixing all these issues, I was already worried about silo on sparc64: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730478 >>>> We are very close to finishing grub2 for sparc as well and once >>>> that's tested we are going to switch to grub2 for Linux for sparc >>>> so then we can do netboot > > -groan- I'm being flogged to death already about grub2 > I'd like to get grub2 to accept passing boot arguments similar to silo though. > > ie {0} ok boot linux_normal nomsi ip=dhcp ks=http://x.y.z/lazy_sod.ks So, GRUB would actually be able to get the arguments from the OpenBoot firmware if I understand correctly? Sounds pretty nifty! > rather than having to crack open the menu entry and edit it from console. It > was > nice to be able to edit boot params on the fly with eeprom from inside linux > and > reboot... but I'm lazy that way) > There are a few more items not fixed yet that relate to booting solaris from > grub2 but they're on the back burner as getting Linux going is the priority > for > the moment (which it does do) Yeah, no hurry. I am already very glad we have a working silo on sparc64 :). >> Please correct me if I'm wrong, but I think the Oracle Linux is only for >> virtualised guests so might have gotchas on bare metal. > > you're wrong 8) > it's capable of running as baremetal. In fact that how I originally started > it. > I've been driving that original baremetal box for 3 years now, so I can say > that > it's reasonably robust. Good to hear. I also expected there would be no limitations regarding real hardware since the binaries are in the end just sparcv9 binaries, just the kernel might be trimmed down for virtualization with all the unnecessary drivers removed. > There are visualization drivers fixed up/built that allow for the kernel to > run > in a Solaris driven LDM environment (in fact, thats the way we usually develop > in-house since we can toss the running LDM's and recreate a new bootable > environment from scratch inside 3 minutes flat). Wim will happily flog you a > virtualization solution for a build platform though 8) -cough- Again, great to hear. I'm very glad you guys are around on debian [email protected] so you can always chime in when we're having issues! >>> there fix like Firefox and Thunderbird which currently fail to build >>> from source. >> >> Don't know whether this is of any use but I noticed it a couple of days ago: >> https://github.com/OpenSXCE-org >> >> "FireFox-43-port-for-all-OpenSolaris-distros Runs on all distros, supports >> FlashPlugins (all versions) on fixed Illumos kernels Updated Nov 18, 2015" >> > > actually it's xulrunner that is the pita. something in the xpshell is still > unaligned and causes it to fault. From my perspective, I'm being hammered to > provide a server release so the desktop space apps like firefox are low on my > priority list. Also I'm having to work with the RedHAT/Fedora src codebase so > I'm also working with older sw that needs,.. persuasion, to vaguely work. Yeah, I guess it's xulrunner as the problem affects both Firefox and Thunderbird. From the error message it looks like there are some V8+ optimizations that fail on V9 but I'm not sure: /«PKGBUILDDIR»/ipc/chromium/src/base/singleton.h: In static member function 'static void Singleton<Type, Traits, DifferentiatingType>::OnExit(void*)': /«PKGBUILDDIR»/ipc/chromium/src/base/singleton.h:172:61: error: cannot convert 'base::subtle::AtomicWord* {aka long int*}' to 'volatile Atomic32* {aka volatile int*}' for argument '1' to 'base::subtle::Atomic32 base::subtle::NoBarrier_AtomicExchange(volatile Atomic32*, base::subtle::Atomic32)' base::subtle::NoBarrier_AtomicExchange(&instance_, 0))); > https://buildd.debian.org/status/fetch.php?pkg=iceweasel&arch=sparc64&ver=38.5.0esr-1&stamp=1450458305 >>> Btw, have all the changes mentioned in [1] been upstreamed? I'm >>> especially very interested in the changes made to gcc to enable >>> multiarch support because we are still having issues with that >>> in Debian which is why it's disabled in the Debian gcc packages >>> for sparc64 [2], line 18. > > As Wim says, that is a question more comfortably answered by Jose when the > eggnog wears off. No hurries, enjoy your holidays guys! > Mmm,.. I think I should shut up at this point before Wim smacks me around with > the toffee hammer as to the roadmap regarding L4S (linux for sparc) Haha :-). Just put Debian on SPARC on the roadmap as well and there will be many more Linux for SPARC users in no time! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - [email protected] `. `' Freie Universitaet Berlin - [email protected] `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
