> Hi Nick,
>
> Thanks again for testing this. The issue with Solaris not detecting the
> disks is a known one - the following guide should point you in the right
> direction:
>
> http://virtuallyfun.blogspot.com/2010/10/formatting-disks-for-solaris.html
>
> Also don't forget the "set scsi_options" part from Artyom's SPARC/QEMU
> howto here: http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html
>
> I think it may actually be possible to come up with a patch for OpenBIOS
> so that the scsi_options change isn't required - let me know how you get
> on with the above links, and if it all seems to work I'll look at
> creating the patch for you.
>
>
Okay, I got passed the issue with formatting the root filesystem.
Apparently there are some limitations on the C/H/S parameters you use
for the disk that correspond with how UFS wants to format a new
filesystem. I'm not sure what exactly those limitations are at this
point, but, by adjusting a couple of the C/H/S settings when using
format to set up the disk I was able to get it to work correctly. So, I
now have Solaris 9 installed on qemu-system-sparc with OpenBIOS! I'll
probably go back to Solaris 8 as that one has a free binary license
while Solaris 9 is a commercial license, IIRC. I do own a Solaris 9
commercial license, but I like the free idea, better.
Anyway, now I'm on to an issue with networking - I've used the following
two qemu network parameter combinations:
-net nic -net tap,ifname=tap0
-net nic -net user
In the first instance, tap0 was configured on my Linux box and added to
my bridge br0. In both cases the Solaris system is unable to obtain a
DHCP address - the DHCP client times out. Not sure if I should be using
a different parameter set, or if this is another area that needs some
work either for OpenBIOS or qemu?
-Nick
--------
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
I've got FCode routines living as a dropin in a 4.x OBP. The dropin is
fine, does its job supporting the card, but I need to install it in a
new server and no one can find the original. Is there a way to extract
the dropin so I can move it?
Once I get it, I know I can install the binary image using "add-dropin
/location/"
Can I also stick it in the card's PROM? Then I wouldn't have it add it
as a drop-in to each system I want to use the card in. How would I do that?
Thanks!
Dave
On 10/08/11 16:43, William Hahne wrote:
> Very interesting. I think this needs someone with quite strong
> Forth-fu (Stefan) to review this one. Also I can't see any related
> documentation with this patch related to locals support?
>
>
> This is an Apple specific thing. See
> http://www.openfirmware.info/How_Local_Variables_in_Forth_Work_---_Using_Ap…
Right I understand this, but I'm fairly sure there is an official spec
for Forth local variables somewhere. For something to be committed, I'd
expect the commit reference to contain a link to the source
specification and comments in the code giving an indication as to what
the level of implementation actually is (I absolutely understand that it
can be impractical to implement everything within the time available).
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
William,
Am 22.08.2011 um 05:14 schrieb William Hahne:
> This is a forth word that is required by BootX. It just fills some
> specified memory address and length with 32 bit integers. It is a
> non-standard addition and therefore isn't documented. Thanks to Segher
> Boessenkool for the corrected for loop.
This is still missing a Signed-off-by line!
Compare QEMU's http://wiki.qemu.org/Contribute/SubmitAPatch
I'd like to compile-test and commit the patch(es), but I cannot
copy&paste this from my mailer (leading spaces get stripped).
Best use git-am compatible email format or please supply me with the
patch as an attachment or download. Thanks!
Andreas
$ git am ../mac_10.eml
Applying: Adding filll Forth primitive (v2)
error: ppc/qemu/init.c (working copy): does not exist in index
Patch failed at 0001 Adding filll Forth primitive (v2)
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
> Index: arch/ppc/qemu/init.c
> ===================================================================
> --- arch/ppc/qemu/init.c (revision 1047)
> +++ arch/ppc/qemu/init.c (working copy)
> @@ -539,6 +539,7 @@
> }
>
> static void go(void);
> +static void filll(void);
>
> static void
> go(void)
> @@ -551,6 +552,23 @@
> call_elf(0, 0, addr);
> }
>
> +/* This is an Apple specific word that fills a specified location
> and length
> + of memory with 32bit integers.
> +
> + ( dest count value -- ) */
> +static void
> +filll(void)
> +{
> + uint32_t value = POP();
> + int count = POP();
> + uint32_t *dest = (uint32_t*)cell2pointer(POP());
> +
> + int i;
> + for (i = count; i > 0; i -= sizeof(uint32_t)) {
> + *dest++ = value;
> + }
> +}
> +
> static void kvm_of_init(void)
> {
> char hypercall[4 * 4];
> @@ -879,4 +897,5 @@
>
> bind_func("platform-boot", boot);
> bind_func("(go)", go);
> + bind_func("filll", filll);
> }
>
> --
> OpenBIOS http://openbios.org/
> Mailinglist: http://lists.openbios.org/mailman/listinfo
> Free your System - May the Forth be with you
One detail William.
Documentation clearly state that drivers, even if present on the partition map, ARE NOT PARTITIONS.
(I.M. Vol. 2, and a document I've forgot the name that describes the boot process extensively, present on Apple Support archives -even describes how Rhapsody boots-)
Have you checked the count does not include _FREE and _VOID in BootX?
El 22/08/2011, a las 03:15, William Hahne escribió:
> Updated commit message:
>
> Currently every entry in the Apple Partition Map is counted as a
> partition. This behavior prevents BootX from finding the boot
> partition since BootX will only check the first few partitions before
> giving up. This patch skips over entries that do not specify
> partitions such as void entries and drivers. While documentation
> doesn't say specifically that these partitions should be skipped, it
> can be inferred from BootX behavior as well as how the documentation
> doesn't refer to drivers as partitions.
>
> --
> OpenBIOS http://openbios.org/
> Mailinglist: http://lists.openbios.org/mailman/listinfo
> Free your System - May the Forth be with you
APPLE_VOID partition is just a partition entry holder, so you don't have to resize the partition table but it occupies no space on disk.
APPLE_FREE however, indicates free space on disk.
This is, if my memory don't fail, on Inside Macintosh books, Volume 2 or 4.
Sorry no link I have the books in paper :p
El 10/08/2011, a las 16:28, William Hahne escribió:
>
>
> On Wed, Aug 10, 2011 at 5:50 AM, Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> wrote:
> On 09/08/11 22:54, William Hahne wrote:
>
> The void partitions can be occasionally found on Mac OS discs (10.2 for
> example.) Previously mac-parts would just stop at the first void
> partition meaning it would never try to boot from the HFS partition.
>
> Index: packages/mac-parts.c
> ===================================================================
> --- packages/mac-parts.c (revision 1041)
> +++ packages/mac-parts.c (working copy)
> @@ -165,9 +165,12 @@
> for (parnum = 1; parnum <= __be32_to_cpu(par.pmMapBlkCnt); parnum++) {
> SEEK( bs * parnum );
> READ( &par, sizeof(par) );
> - if( __be16_to_cpu(par.pmSig) != DESC_PART_SIGNATURE ||
> - !__be32_to_cpu(par.pmPartBlkCnt) )
> + if( __be16_to_cpu(par.pmSig) != DESC_PART_SIGNATURE) {
> break;
> + }
> + if ( !__be32_to_cpu(par.pmPartBlkCnt) ) {
> + continue; /* Just a void partition, ignore it. */
> + }
> DPRINTF("found partition type: %s with status %x\n", par.pmPartType,
> __be32_to_cpu(par.pmPartStatus));
>
> Same as my comment for patch 2/10.
>
>
> This was also found through testing although I would assume it is documented. If you have a 10.2 disc (or I would assume most other early Mac OS X discs) lying around you can look at the partition table and see the void partitions.
>
> William Hahne
>
>
> ATB,
>
> Mark.
>
> --
> Mark Cave-Ayland - Senior Technical Architect
> PostgreSQL - PostGIS
> Sirius Corporation plc - control through freedom
> http://www.siriusit.co.uk
> t: +44 870 608 0063
>
> Sirius Labs: http://www.siriusit.co.uk/labs
>
> --
> OpenBIOS http://openbios.org/
> Mailinglist: http://lists.openbios.org/mailman/listinfo
> Free your System - May the Forth be with you
>
>
>
>
> --
> OpenBIOS http://openbios.org/
> Mailinglist: http://lists.openbios.org/mailman/listinfo
> Free your System - May the Forth be with you
On Tue, Aug 23, 2011 at 2:54 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote:
> On Tue, Aug 23, 2011 at 2:45 PM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote:
>> On Tue, Aug 23, 2011 at 3:34 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote:
>>> On Tue, Aug 23, 2011 at 5:35 AM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote:
>>>> On Mon, Aug 22, 2011 at 9:59 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote:
>>>>> On Mon, Aug 22, 2011 at 8:23 PM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote:
>>>>>> On Mon, Aug 22, 2011 at 7:14 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote:
>>>>>>> OpenBIOS uses traditional DPRINTFs for debugging. I was considering
>>>>>>> replacing those with tracepoints, which would output to serial device
>>>>>>> or whatever DPRINTFs are using currently. This would not be extremely
>>>>>>> useful by itself, except maybe that configuration for debugging would
>>>>>>> be concentrated to single 'trace-events' file, but this would not be a
>>>>>>> major improvement over current XML configuration.
>>>>>>>
>>>>>>> But developing this further, maybe OpenBIOS could also pass the
>>>>>>> tracepoint data back to QEMU? Then all tracepoint data would be
>>>>>>> synchronized, coherent and all gathered to single place.
>>>>>>>
>>>>>>> The implementation could be that fw_cfg would be used to pass
>>>>>>> simpletrace style data. An offset should be added to event IDs and
>>>>>>> data would then be output as usual. On OpenBIOS side, the
>>>>>>> implementation would be pretty similar to current QEMU tracepoints but
>>>>>>> in place of file output there would be fw_cfg output.
>>>>>>>
>>>>>>> Syntax for trace-events file should be augmented with include
>>>>>>> directive, so that QEMU knows also OpenBIOS tracepoints. I think the
>>>>>>> only change to simpletrace.py would be to parse this directive.
>>>>>>>
>>>>>>> Controlling OpenBIOS tracepoints from QEMU monitor would be cool too.
>>>>>>>
>>>>>>> Going even further, other targets like kernels could use something
>>>>>>> similar, probably not using fw_cfg though.
>>>>>>>
>>>>>>> What do you think?
>>>>>>
>>>>>> Dhaval showed me a demo of unified host/guest Linux tracing last week.
>>>>>> He is doing something similar except using a hypercall to pass a
>>>>>> string to the host kernel. In his case kvm.ko handles the hypercall
>>>>>> and qemu is not involved.
>>>>>
>>>>> So the events flow directly from guest kernel to host kernel?
>>>>
>>>> Yes.
>>>
>>> How is that used then, with dmesg?
>>
>> When the host processes the trace hypercall it simply forwards the
>> trace event on to host Linux's trace. It currently logs the string
>> from the guest and prefixes it with the guest program counter, I
>> believe. You can dump out the trace using the usual Linux ftrace
>> debugfs files.
>>
>> But the longer term goal, I believe, is to really integrate guest and
>> host tracing so that host userspace (e.g. perf(1)) can pull out trace
>> events from the guest and just sees them tagged as belonging to a
>> particular qemu-kvm process.
>>
>>>
>>>>>> One issue with QEMU tracing is that trace call sites are static. You
>>>>>> need to compile in a trace_*() call, which means that there are two
>>>>>> choices for how to tunnel OpenBIOS trace events:
>>>>>>
>>>>>> 1. Define a tunnel trace event:
>>>>>> openbios_event(uint64_t event_id, uint64_t arg1, uint64_t arg2, ...)
>>>>>>
>>>>>> QEMU only has one trace event to tunnel OpenBIOS trace events. Then
>>>>>> the host is unable to pretty-print OpenBIOS traces automatically and
>>>>>> the max arguments becomes 6 - 1 (for the openbios_event tunnel event
>>>>>> id).
>>>>>>
>>>>>> 2. Generate a switch statement to demultiplex trace events:
>>>>>> void hypercall(uint64_t event_id, uint64_t arg1, ...)
>>>>>> {
>>>>>> /* This is auto-generated by tracetool */
>>>>>> switch (event_id) {
>>>>>> case TRACE_EVENT_OPENBIOS_FOO:
>>>>>> trace_openbios_foo(arg1, arg2, arg3);
>>>>>> break;
>>>>>> case TRACE_EVENT_OPENBIOS_BAR:
>>>>>> trace_openbios_bar(arg1);
>>>>>> break;
>>>>>> ...
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> With this approach the user can toggle trace events at runtime and it
>>>>>> works out much nicer.
>>>>>
>>>>> Maybe I'm missing something, but why would we have to multiplex
>>>>> anything? Since the trace IDs are 64 bits, we can easily allocate a
>>>>> static range (starting from 0x8000000000000000) to non-native events
>>>>> so that QEMU IDs and OpenBIOS IDs do not overlap. QEMU would add this
>>>>> offset to IDs coming from fw_cfg. Then QEMU would just pass the data
>>>>> (8*64 bit words) to tracing back end. There obviously something needs
>>>>> to be changed so that OpenBIOS messages can be generated. For
>>>>> simpletrace this should be easy, for stderr and other back ends that
>>>>> may be more complicated.
>>>>
>>>> I meant that the interface generated by tracetool is a header file
>>>> with trace_*() functions. If you want to support any tracing backend
>>>> then you need to use this interface and cannot call simpletrace.c
>>>> trace0(), trace1(), ... directly.
>>>>
>>>> Are you thinking of only supporting the simple trace backend?
>>>
>>> That would be simplest, then fw_cfg.c (or some intermediate entity)
>>> could just call trace6().
>>>
>>> But stderr would be useful too. I think that could be done by adding
>>> code to read trace-events file to grab the format string. Then a
>>> modified vfprintf would parse it but instead of va_arg(args, type) it
>>> would just grab the uint64_t arg. Your approach would be much simpler.
>>
>> I see. I think we should avoid introducing dependencies on specific
>> trace backends, so I would go for the generated switch statement
>> above. That way you can even use DTrace/SystemTap or other backends.
>> Also if we called traceX() directly we'd have to duplicate the logic
>> to check whether the trace event is enabled/disabled, so it becomes a
>> bit messy.
>
> I see. I'll try the switch approach then.
Here's a work in progress version for the guest tracepoints. Both QEMU
and OpenBIOS compile (stderr and simpletrace backends), but because of
the recent breakage, I couldn't test the patches. At least the event
from OpenBIOS is visible to QEMU monitor:
esp_do_command [Event ID 322] : state 1
QEMU must be configured with
'--with-guest-trace-file=/src/openbios-devel/trace-events'.
There's some danger of namespace collisions. One way to avoid those
would be that the event names could be prefixed, with prefix given
during configure time.
On Tue, Aug 23, 2011 at 2:45 PM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote:
> On Tue, Aug 23, 2011 at 3:34 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote:
>> On Tue, Aug 23, 2011 at 5:35 AM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote:
>>> On Mon, Aug 22, 2011 at 9:59 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote:
>>>> On Mon, Aug 22, 2011 at 8:23 PM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote:
>>>>> On Mon, Aug 22, 2011 at 7:14 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote:
>>>>>> OpenBIOS uses traditional DPRINTFs for debugging. I was considering
>>>>>> replacing those with tracepoints, which would output to serial device
>>>>>> or whatever DPRINTFs are using currently. This would not be extremely
>>>>>> useful by itself, except maybe that configuration for debugging would
>>>>>> be concentrated to single 'trace-events' file, but this would not be a
>>>>>> major improvement over current XML configuration.
>>>>>>
>>>>>> But developing this further, maybe OpenBIOS could also pass the
>>>>>> tracepoint data back to QEMU? Then all tracepoint data would be
>>>>>> synchronized, coherent and all gathered to single place.
>>>>>>
>>>>>> The implementation could be that fw_cfg would be used to pass
>>>>>> simpletrace style data. An offset should be added to event IDs and
>>>>>> data would then be output as usual. On OpenBIOS side, the
>>>>>> implementation would be pretty similar to current QEMU tracepoints but
>>>>>> in place of file output there would be fw_cfg output.
>>>>>>
>>>>>> Syntax for trace-events file should be augmented with include
>>>>>> directive, so that QEMU knows also OpenBIOS tracepoints. I think the
>>>>>> only change to simpletrace.py would be to parse this directive.
>>>>>>
>>>>>> Controlling OpenBIOS tracepoints from QEMU monitor would be cool too.
>>>>>>
>>>>>> Going even further, other targets like kernels could use something
>>>>>> similar, probably not using fw_cfg though.
>>>>>>
>>>>>> What do you think?
>>>>>
>>>>> Dhaval showed me a demo of unified host/guest Linux tracing last week.
>>>>> He is doing something similar except using a hypercall to pass a
>>>>> string to the host kernel. In his case kvm.ko handles the hypercall
>>>>> and qemu is not involved.
>>>>
>>>> So the events flow directly from guest kernel to host kernel?
>>>
>>> Yes.
>>
>> How is that used then, with dmesg?
>
> When the host processes the trace hypercall it simply forwards the
> trace event on to host Linux's trace. It currently logs the string
> from the guest and prefixes it with the guest program counter, I
> believe. You can dump out the trace using the usual Linux ftrace
> debugfs files.
>
> But the longer term goal, I believe, is to really integrate guest and
> host tracing so that host userspace (e.g. perf(1)) can pull out trace
> events from the guest and just sees them tagged as belonging to a
> particular qemu-kvm process.
>
>>
>>>>> One issue with QEMU tracing is that trace call sites are static. You
>>>>> need to compile in a trace_*() call, which means that there are two
>>>>> choices for how to tunnel OpenBIOS trace events:
>>>>>
>>>>> 1. Define a tunnel trace event:
>>>>> openbios_event(uint64_t event_id, uint64_t arg1, uint64_t arg2, ...)
>>>>>
>>>>> QEMU only has one trace event to tunnel OpenBIOS trace events. Then
>>>>> the host is unable to pretty-print OpenBIOS traces automatically and
>>>>> the max arguments becomes 6 - 1 (for the openbios_event tunnel event
>>>>> id).
>>>>>
>>>>> 2. Generate a switch statement to demultiplex trace events:
>>>>> void hypercall(uint64_t event_id, uint64_t arg1, ...)
>>>>> {
>>>>> /* This is auto-generated by tracetool */
>>>>> switch (event_id) {
>>>>> case TRACE_EVENT_OPENBIOS_FOO:
>>>>> trace_openbios_foo(arg1, arg2, arg3);
>>>>> break;
>>>>> case TRACE_EVENT_OPENBIOS_BAR:
>>>>> trace_openbios_bar(arg1);
>>>>> break;
>>>>> ...
>>>>> }
>>>>> }
>>>>>
>>>>> With this approach the user can toggle trace events at runtime and it
>>>>> works out much nicer.
>>>>
>>>> Maybe I'm missing something, but why would we have to multiplex
>>>> anything? Since the trace IDs are 64 bits, we can easily allocate a
>>>> static range (starting from 0x8000000000000000) to non-native events
>>>> so that QEMU IDs and OpenBIOS IDs do not overlap. QEMU would add this
>>>> offset to IDs coming from fw_cfg. Then QEMU would just pass the data
>>>> (8*64 bit words) to tracing back end. There obviously something needs
>>>> to be changed so that OpenBIOS messages can be generated. For
>>>> simpletrace this should be easy, for stderr and other back ends that
>>>> may be more complicated.
>>>
>>> I meant that the interface generated by tracetool is a header file
>>> with trace_*() functions. If you want to support any tracing backend
>>> then you need to use this interface and cannot call simpletrace.c
>>> trace0(), trace1(), ... directly.
>>>
>>> Are you thinking of only supporting the simple trace backend?
>>
>> That would be simplest, then fw_cfg.c (or some intermediate entity)
>> could just call trace6().
>>
>> But stderr would be useful too. I think that could be done by adding
>> code to read trace-events file to grab the format string. Then a
>> modified vfprintf would parse it but instead of va_arg(args, type) it
>> would just grab the uint64_t arg. Your approach would be much simpler.
>
> I see. I think we should avoid introducing dependencies on specific
> trace backends, so I would go for the generated switch statement
> above. That way you can even use DTrace/SystemTap or other backends.
> Also if we called traceX() directly we'd have to duplicate the logic
> to check whether the trace event is enabled/disabled, so it becomes a
> bit messy.
I see. I'll try the switch approach then.