Re: [Qemu-discuss] Qemu-system-sparc: What would I need to change to add functionality to save the nvram content between boots ?

[Maximilian H.]

Hello Everybody,

thank you for all your msgs and insights - I only saw them yesterday
because the spam filter was a bit overly excited.

Yes, I am using the original sun OBP because I wanted graphical output
with openwin on the emulated CG3 framebuffer. The openbios firmware
outputs in 1024x800 I believe and openwin wants a 1152x900, so I used
the original sun cg3 framebuffer firmware. Also I wanted to automate the
boot and not have to type "boot disk" everytime.

Sunos 4.1/Solaris 1.1.2 used scsi id 3 for the first internal disk and
scsi id 6 for the cdrom device.

Therefor I am using these command line options:
-drive file="$SYSTEM_DISK_IMAGE",media=disk,if=scsi,bus=0,unit=3 \
-drive file="$CDROM_MEDIA_IMAGE",media=cdrom,if=scsi,bus=0,unit=6

Sunos 4.1 used these SCSI addresses:
Internal HDD 1: Scsi ID 3
Internal HDD 2: Scsi ID 1
External Tape Drive 1: Scsi ID 4
External Tape Drive 2: Scsi ID 5
External HDD 1: Scsi ID 0
External HDD 2: Scsi ID 1 (if not used internally)
External HDD 3: Scsi ID 2
CDROM: Scsi ID 6
Controller: ID 7

>> Yep. We already support flash backed by a block device
>> for x86 and ARM.

> Then using that on SPARC would be much closer to solving the OPs
> problem than trying to create new code based on mmap(), ROM loading
> code etc.

Could somebody point me to an example of how this is done at this moment
in qemu. I know I could find it myself, but time is precious, so I'd
rather ask.

Thanks
BR
Max.

Re: [Qemu-discuss] Qemu-system-sparc: What would I need to change to add functionality to save the nvram content between boots ?

[Peter Maydell]

On 14 September 2015 at 15:44, Jakob Bohm  wrote:
> On 14/09/2015 11:33, Peter Maydell wrote:
>> Rather than reinventing the wheel I suggest looking at how QEMU
>> already supports file-backed ROMs for other platforms...
>
> Note that this is about *writable* persistent memory,
> such as the non-time battery backed registers in a PC
> clock or the thing that stores EFI BIOS variables such
> as those holding Linux crash dumps.

Yep. We already support flash backed by a block device
for x86 and ARM.

thanks
-- PMM

Re: [Qemu-discuss] Qemu-system-sparc: What would I need to change to add functionality to save the nvram content between boots ?

[Jakob Bohm]

On 14/09/2015 16:49, Peter Maydell wrote:

On 14 September 2015 at 15:44, Jakob Bohm  wrote:

On 14/09/2015 11:33, Peter Maydell wrote:

Rather than reinventing the wheel I suggest looking at how QEMU
already supports file-backed ROMs for other platforms...


Note that this is about *writable* persistent memory,
such as the non-time battery backed registers in a PC
clock or the thing that stores EFI BIOS variables such
as those holding Linux crash dumps.


Yep. We already support flash backed by a block device
for x86 and ARM.




Then using that on SPARC would be much closer to solving the OPs
problem than trying to create new code based on mmap(), ROM loading
code etc.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: [Qemu-discuss] Qemu-system-sparc: What would I need to change to add functionality to save the nvram content between boots ?

[Jakob Bohm]

On 14/09/2015 11:33, Peter Maydell wrote:

On 14 September 2015 at 00:25, Programmingkid  wrote:

On Sep 13, 2015, at 7:20 PM, Bodo Eggert wrote:


On Sun, 13 Sep 2015, Programmingkid wrote:

On Sep 13, 2015, at 5:50 PM, Bodo Eggert wrote:

On Sun, 13 Sep 2015, Mark Cave-Ayland wrote:

On 11/09/15 19:01, Programmingkid wrote:

Mark, do you think it is possible for a QEMU command line option to
actually load the
saved OpenBIOS settings from a file and restore them into memory? I'm
thinking something
along the lines of -prom-memory .
 From memory the reason this hasn't been done is because the NVRAM

interface is used across multiple architectures and there hasn't been a
solution devised that would work well enough for all of them. Then again
as the BIOSs involved have continued to develop, it may be now that some
of the issues can now be solved so it never hurts to ask on the -devel list.

I'm wondering, why wouldn't it be enough to memmap a nvram file instead of
mallocing (or whatever) the memory area?

What advantage does mmap() have over malloc()? I think malloc() is a lot more
familiar to use than mmap().

The advantage is that it's file-backed (optionally, but intended here).
Everything you write into that memory area will be automatically
saved and restored just like a nvram should be. At least, that's what the
documentation promises, I never used it myself, therefore I ask.

You make mmap() sound good. Maybe we should use it.

Rather than reinventing the wheel I suggest looking at how QEMU
already supports file-backed ROMs for other platforms...

Note that this is about *writable* persistent memory,
such as the non-time battery backed registers in a PC
clock or the thing that stores EFI BIOS variables such
as those holding Linux crash dumps.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: [Qemu-discuss] Qemu-system-sparc: What would I need to change to add functionality to save the nvram content between boots ?

[Peter Maydell]

On 14 September 2015 at 00:25, Programmingkid  wrote:
>
> On Sep 13, 2015, at 7:20 PM, Bodo Eggert wrote:
>
>> On Sun, 13 Sep 2015, Programmingkid wrote:
>>> On Sep 13, 2015, at 5:50 PM, Bodo Eggert wrote:
 On Sun, 13 Sep 2015, Mark Cave-Ayland wrote:
> On 11/09/15 19:01, Programmingkid wrote:
>>
>> Mark, do you think it is possible for a QEMU command line option to
>> actually load the
>> saved OpenBIOS settings from a file and restore them into memory? I'm
>> thinking something
>> along the lines of -prom-memory .

>> From memory the reason this hasn't been done is because the NVRAM
> interface is used across multiple architectures and there hasn't been a
> solution devised that would work well enough for all of them. Then again
> as the BIOSs involved have continued to develop, it may be now that some
> of the issues can now be solved so it never hurts to ask on the -devel 
> list.

 I'm wondering, why wouldn't it be enough to memmap a nvram file instead of
 mallocing (or whatever) the memory area?
>>>
>>> What advantage does mmap() have over malloc()? I think malloc() is a lot 
>>> more
>>> familiar to use than mmap().
>>
>> The advantage is that it's file-backed (optionally, but intended here).
>> Everything you write into that memory area will be automatically
>> saved and restored just like a nvram should be. At least, that's what the
>> documentation promises, I never used it myself, therefore I ask.
>
> You make mmap() sound good. Maybe we should use it.

Rather than reinventing the wheel I suggest looking at how QEMU
already supports file-backed ROMs for other platforms...

thanks
-- PMM

Re: [Qemu-discuss] Qemu-system-sparc: What would I need to change to add functionality to save the nvram content between boots ?

[Mark Cave-Ayland]

On 11/09/15 19:01, Programmingkid wrote:

> On Sep 11, 2015, at 12:00 PM, qemu-discuss-requ...@nongnu.org
>  wrote:
> 
>> On 10/09/2015 8:58 AM, Maximilian H. wrote:
>>> Hello,
>>>
>>> I was looking into what parts would need change to save and restore the
>>> nvram content for the qemu-system-sparc vm between boots.
>>>
>>> I see the code in hw/timer/m48t59.c that implements the nvram.
>>>
>>> So some questions arise, and before I spend too much time poking around
>>> the still unknown code, I'd thought I ask first.
>>>
>>> 1. Command line processing starts in vl.c in the main fct there ? Can I
>>> add a command line argument there, say "-sparcnvram" ?
>>>
>>> 2. In hw/timer/m48t59.c has no functionality that I see from having a
>>> look at it (not in depth) to save or restore the nvram's contents for
>>> sparc. Is there a general facility that qemu has that provides such a
>>> functionality - i.e. is there a general qemu save and restore framework ?
>>>
>>> 3. Is there an example somebody could point me to that implements
>>> something similar ? Imitation is the sincerest of flattery 
>>>
>>> 4. All the alarm and watchdog functionality that the m48t08 provides, is
>>> that used on sparc too ?
>>>
>>> 5. Besides what is in
>>> http://wiki.qemu.org/Documentation/GettingStartedDevelopers, is there
>>> some qemu coding documentation to make it faster for somebody unfamilar
>>> with qemu's code like me to be able to implement something ? I'd like to
>>> spend a few evenings on this, produce a patch and move on.
>>>
>>> Thanks
>>> BR
>>> Max.
>>
> 
> This sounds like a good idea. Having OpenBIOS settings actually be saved
> between boots
> would make things more real. 
> 
> Mark, do you think it is possible for a QEMU command line option to
> actually load the
> saved OpenBIOS settings from a file and restore them into memory? I'm
> thinking something
> along the lines of -prom-memory . 
> 
> Max, there is a project that you should probably look at called
> OpenBIOS. It implements
> an implementation of Open Firmware. Here is where more info can be
> found: http://www.openfirmware.info/Welcome_to_OpenBIOS. If you do want
> to implement this feature,
> it would help to know how the BIOS is implemented. 

>From memory the reason this hasn't been done is because the NVRAM
interface is used across multiple architectures and there hasn't been a
solution devised that would work well enough for all of them. Then again
as the BIOSs involved have continued to develop, it may be now that some
of the issues can now be solved so it never hurts to ask on the -devel list.

May I ask why you want to save the NVRAM state between boots on SPARC?
My guess would be that you're using a real SS-5 PROM image and looking
to avoid having to type boot commands into the terminal after every
reset. If this is the case then you may be pleasantly surprised using
QEMU 2.4 with the built-in OpenBIOS as there were fixes applied during
the last development cycle that were enough to allow SunOS 4.1.4 to boot.

If this solution works for you and you are keen use the alarm/watchdog
features then there may be some scope to add the required features to
QEMU/OpenBIOS in future.


ATB,

Mark.

Re: [Qemu-discuss] Qemu-system-sparc: What would I need to change to add functionality to save the nvram content between boots ?

[Bodo Eggert]

On Sun, 13 Sep 2015, Programmingkid wrote:
> On Sep 13, 2015, at 5:50 PM, Bodo Eggert wrote:
> > On Sun, 13 Sep 2015, Mark Cave-Ayland wrote:
> >> On 11/09/15 19:01, Programmingkid wrote:

> >>> Mark, do you think it is possible for a QEMU command line option to
> >>> actually load the
> >>> saved OpenBIOS settings from a file and restore them into memory? I'm
> >>> thinking something
> >>> along the lines of -prom-memory . 
> > 
> >>> From memory the reason this hasn't been done is because the NVRAM
> >> interface is used across multiple architectures and there hasn't been a
> >> solution devised that would work well enough for all of them. Then again
> >> as the BIOSs involved have continued to develop, it may be now that some
> >> of the issues can now be solved so it never hurts to ask on the -devel 
> >> list.
> > 
> > I'm wondering, why wouldn't it be enough to memmap a nvram file instead of 
> > mallocing (or whatever) the memory area?
> 
> What advantage does mmap() have over malloc()? I think malloc() is a lot more
> familiar to use than mmap().

The advantage is that it's file-backed (optionally, but intended here).  
Everything you write into that memory area will be automatically 
saved and restored just like a nvram should be. At least, that's what the 
documentation promises, I never used it myself, therefore I ask.

Re: [Qemu-discuss] Qemu-system-sparc: What would I need to change to add functionality to save the nvram content between boots ?

[Programmingkid]

On Sep 13, 2015, at 7:20 PM, Bodo Eggert wrote:

> On Sun, 13 Sep 2015, Programmingkid wrote:
>> On Sep 13, 2015, at 5:50 PM, Bodo Eggert wrote:
>>> On Sun, 13 Sep 2015, Mark Cave-Ayland wrote:
 On 11/09/15 19:01, Programmingkid wrote:
> 
> Mark, do you think it is possible for a QEMU command line option to
> actually load the
> saved OpenBIOS settings from a file and restore them into memory? I'm
> thinking something
> along the lines of -prom-memory . 
>>> 
> From memory the reason this hasn't been done is because the NVRAM
 interface is used across multiple architectures and there hasn't been a
 solution devised that would work well enough for all of them. Then again
 as the BIOSs involved have continued to develop, it may be now that some
 of the issues can now be solved so it never hurts to ask on the -devel 
 list.
>>> 
>>> I'm wondering, why wouldn't it be enough to memmap a nvram file instead of 
>>> mallocing (or whatever) the memory area?
>> 
>> What advantage does mmap() have over malloc()? I think malloc() is a lot more
>> familiar to use than mmap().
> 
> The advantage is that it's file-backed (optionally, but intended here).  
> Everything you write into that memory area will be automatically 
> saved and restored just like a nvram should be. At least, that's what the 
> documentation promises, I never used it myself, therefore I ask.

You make mmap() sound good. Maybe we should use it.

Re: [Qemu-discuss] Qemu-system-sparc: What would I need to change to add functionality to save the nvram content between boots ?

[Bodo Eggert]

On Sun, 13 Sep 2015, Mark Cave-Ayland wrote:
> On 11/09/15 19:01, Programmingkid wrote:

> > Mark, do you think it is possible for a QEMU command line option to
> > actually load the
> > saved OpenBIOS settings from a file and restore them into memory? I'm
> > thinking something
> > along the lines of -prom-memory . 

> >From memory the reason this hasn't been done is because the NVRAM
> interface is used across multiple architectures and there hasn't been a
> solution devised that would work well enough for all of them. Then again
> as the BIOSs involved have continued to develop, it may be now that some
> of the issues can now be solved so it never hurts to ask on the -devel list.

I'm wondering, why wouldn't it be enough to memmap a nvram file instead of 
mallocing (or whatever) the memory area?

Re: [Qemu-discuss] Qemu-system-sparc: What would I need to change to add functionality to save the nvram content between boots ?

[Jim Jarvie]

Hi Max,

What options do you need ?

Using :

-net nic,macaddr=00:80: -M SS-20 (for a 
SPARC-20)


Will get the host ID to match whatever your original SPARC box had and 
that will satisfy lmgrd.


If you need SCSI IDs properly set (e.g. disk and CD to correct place), 
normally disks are SCSI ID 3 [on my systems] and you set that with


-drive file=x,format=raw,_*unit=3*_

With that, the default NVRAM boot options should boot the disk when you 
enter boot.


For a CDROM, from recollection, it defaults to unit=2 (don't have a 
machine to verify this right now but if you run boot cdrom and check for 
the ID it's looking for and match that).


That should be all you normally need to match the NVRAM defaults (except 
for auto-boot).


Now, some old info I could find suggests :

-prom-env 'boot-device=disk1' -prom-env 'auto-boot?=true'

(change disk1 to whatever you set up)

Will do that.  I've not been able to verify this is still true though as 
there were comments about it being broken (anyone else want to jump in?)


However, if it does not, you can script booting by starting the QEMU 
process with serial console over TCP and then send a boot command to it 
using an expect script.  The example link I sent you before has the 
process started with a serial console over TCP, which should give you a 
starting point.


Jim








On 10/09/2015 8:58 AM, Maximilian H. wrote:

Hello,

I was looking into what parts would need change to save and restore the
nvram content for the qemu-system-sparc vm between boots.

I see the code in hw/timer/m48t59.c that implements the nvram.

So some questions arise, and before I spend too much time poking around
the still unknown code, I'd thought I ask first.

1. Command line processing starts in vl.c in the main fct there ? Can I
add a command line argument there, say "-sparcnvram" ?

2. In hw/timer/m48t59.c has no functionality that I see from having a
look at it (not in depth) to save or restore the nvram's contents for
sparc. Is there a general facility that qemu has that provides such a
functionality - i.e. is there a general qemu save and restore framework ?

3. Is there an example somebody could point me to that implements
something similar ? Imitation is the sincerest of flattery 

4. All the alarm and watchdog functionality that the m48t08 provides, is
that used on sparc too ?

5. Besides what is in
http://wiki.qemu.org/Documentation/GettingStartedDevelopers, is there
some qemu coding documentation to make it faster for somebody unfamilar
with qemu's code like me to be able to implement something ? I'd like to
spend a few evenings on this, produce a patch and move on.

Thanks
BR
Max.









--
All e-mail and telephone communications are subject to Suresafe Terms
And Conditions and may be monitored, recorded and processed for the
purposes contained therein and adherence to regulatory and legal
requirements.

Your further communication or reply to this e-mail indicates your
acceptance of this.

Any views or opinions expressed are the responsibility of the author
and may not reflect those of Suresafe Protection Limited.

Suresafe Protection Limited is registered in Scotland, number SC132827
The registered office is at 8 Kelvin Road, Cumbernauld, G67 2BA.
Telephone: 01236 727792Fax: 01236 723301   VAT Number: 556 6950 02