Re: Creating sparc64 installation images
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
sparc@l.d.o 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 - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: