[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] Newbie: Running Solaris8/SPARC binaries / shared obje

From: Dennis Luehring
Subject: Re: [Qemu-discuss] Newbie: Running Solaris8/SPARC binaries / shared objects on x86-Linux Machines
Date: Wed, 17 Sep 2014 12:55:08 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

another idea is to ask Artyom Tarasenko (http://tyom.blogspot.de/)


he seems to work around bioses, sparc and ppc testing

Am 16.09.2014 22:29, schrieb Hartmut Rombach:
Hi Dennis,
sorry, but until now, I was to busy with other problems to start such a big 
Once again, thanks for your help.

Am 16.09.2014 um 10:56 schrieb Dennis Luehring:
> success with any of the given ideas/suggestions?
> Am 31.08.2014 16:54, schrieb Hartmut Rombach:
>> Hello everybody,
>> Thank you for your quick response and for the time you spent to help me find 
the best way to keep old hardware productive.
>> Perhaps, it's best to describe my situation a bit more detailed to clarify 
the situation:
>> Back in the 1980th / 1990th, our company bought several parameter test 
systems (used for in-production testing of semiconductor devices). Those systems have 
a build in computer-board (based on an 68040 microprocessor). All of those testers 
are controlled by two Sun SPARCs running Solaris 8. User Interface, program 
generation and everything else is done on the Sun. The vendor of the test systems 
supplied us with some shared object libraries, we may use in our programs to control 
the tester (make it force some voltages, measure some current and so on).  So, 
basically we develop programs on the Sun, and use the vendor-supplied lib to convert 
and transfer our commands  to the tester, wich returns the results back. Please note: 
communication from Sun to tester is done via ethernet, but they are using their own 
network protocol and not e.g. tcp/ip. Unfortunately, I have only very little 
information about that network protocol.
>> The tester-hardware is still in good condition (though out of support) and 
its performance is still sufficient for most of our products. The longer, the testers 
are usable, the more money we save.
>> On the other hand, the Sun SPARCs are out of support as well, and I am 
afraid that some time one of them breaks down leaving us in a quite difficult 
>> So I just want to check out, if it's possible to move the programs, which are 
currently running on the Sun SPARC, to an x86/Linux PC using some kind of "SPARC 
>> @Jim: thanks a lot, for showing me, which difficulties I have do deal with. 
Sounds like it will take quite a lot of time and it's definitely not sure, that it 
all ends up with a reliable system.
>> @ Tony Su: You are right: I am asking how to run a Solaris application 
compiled for SPARC hardware on an modern x86 linux computer. About your question 
concerning direct hardware access:  I am pretty sure this is not required. Although 
they use their own network protocol, it is possible to use the same network interface 
for in-house communication using tcp/ip and tester communication.
>> @Dennis: sorry, but reverse engineering is not an option for me. Maybe, it 
can be done on the network protocol itself, but this is only a small part of what has 
to be done. With almost no documentation about what's going on on the tester cpu, 
it's simply to much work for me.
>> @Jerry: please, calm down. Dennis did not start the thread, I did. He is 
trying to help me just as you do, and he tried to clarify, what I may not have said 
that clear. So please don't blame him for insulating others.
>> Once again, thank you for your answers.
>> Hartmut
>> Am 31.08.2014 um 14:56 schrieb Jerry Stuckle:
>> > On 8/31/2014 12:44 AM, Dennis Luehring wrote:
>> >> Am 30.08.2014 23:18, schrieb Tony Su:
>> >>>    Need some clarification,
>> >>> Are you really asking how to run Solaris on x86 or the other way
>> >>> around? I'm going to assume you have a Solaris application running on
>> >>> SPARC hardware and you want to explore options running on Linux
>> >>> instead because it doesn't make much sense to me that you would want
>> >>> to continue to run on ancient hardware. Even consumer grade
>> >>> contemporary hardware is probably a better economic decision than to
>> >>> run on that old hardware.
>> >> "I want to replace the SPARC by a state-of-the art Linux / x86 computer"
>> >>
>> >> isn't that clear enough - don't assume - read the email
>> >>
>> > Which didn't answer Tony's question - the same one I had. Maybe the
>> > problem is not in his reading - but your description.
>> >
>> > Of course insulting people trying to help you is a great way to
>> > encourage people to give you assistance - especially when you're not
>> > paying them for it.
>> >
>> >>> So, what are your options?
>> >>> Let's say your application only exists running on Solaris 8 and it
>> >>> requires access to, and uses SPARC hardware.
>> >>> In this case, you might consider cobbling together a SPARC environment
>> >>> using QEMU emulation.QEMU should support all Sun SPARC CPUs and most
>> >>> likely any SPARC I/O devices as well.
>> >> thats new to me - the SPARC part of qemu seems to be in an sometimes
>> >> very experimental state
>> >>
>> > I haven't tried it personally but I think a friend of mine has.
>> > Unfortunately, it's a long weekend here and he's gone to the beach, so I
>> > won't be able to talk to him until at least Tuesday or Wednesday.
>> >
>> >>> Let's say your app only runs on Solaris 8 but does not require access
>> >>> to SPARC hardware.
>> >>> In this case, you can use almost any virtualization that exists
>> >>> because various Solaris runs on x86 (I haven't checked whether Solaris
>> >>> 8 is one of them). You should be able to use KVM, VMware, VirtualBox,
>> >>> Parallels, Hyper-V(I'm guessing), Xen or anything else for better
>> >>> performance.
>> >>>
>> >> but the current system is SPARC so no x86 virtualizer can help to run
>> >> its SPARC code
>> >> on x86 - or how is that possible?
>> >>
>> >>
>> > He didn't say an x86 virtualizer.  But this goes back to the very first
>> > question.
>> >
>> > Jerry
>> >

reply via email to

[Prev in Thread] Current Thread [Next in Thread]