Re: Running QEMU on FreeBSD

> For what it's worth, I regularly see the same thing running Windows XP 
> in Virtual PC (Macintosh host). Not ideal, but somebody thinks it's good 
> enough for a shipping product... That somebody is Microsoft, though, so 
> take with a grain of salt. ;)

I think I read somewhere in QEMU's documentation that the actual x86 
uses a non-standard representation for floating point numbers that is 
neither faithfully represented by double nor by long double. So unless 
you are willing to sacrifice heaps of speed for perfect emulation, I 
guess we will have to live with that.

- Bartosz

Re: VGA BIOS source code

> Sounds great... Somewhere, I have the Cirrus Logic CL-GD542X/3X 
> Hardware Reference manual.

Once the patch hits the tree, I would like to help developing, improving
and bug fixing it. But unfortunately, I have no reference manual and
even hours of googling have not revealed anything of use. Is that manual
you have in actual dead tree format or is it a PDF / text file you could
mail to me?

- Bartosz

Re: VGA BIOS source code

Here's a link to the CL-GD542X reference manual (found by using yahoo & 
google):
http://ftp.leo.org/download/pub/comp/general/devices/cirruslogic/pubs/gd542xtrm.pdf.gz

There are many other CL manuals on this site in the pubs/ directory.

I hope this helps.
-Zach

>From: Bartosz Fabianowski <bartosz <at> fabianowski.de>
>Reply-To: qemu-devel <at> nongnu.org
>To: qemu-devel <at> nongnu.org
>Subject: Re: [Qemu-devel] VGA BIOS source code
>Date: Tue, 01 Jun 2004 01:23:00 +0200
>
>>Sounds great... Somewhere, I have the Cirrus Logic CL-GD542X/3X Hardware 
>>Reference manual.
>
>Once the patch hits the tree, I would like to help developing, improving
>and bug fixing it. But unfortunately, I have no reference manual and
>even hours of googling have not revealed anything of use. Is that manual
>you have in actual dead tree format or is it a PDF / text file you could
>mail to me?
>
>- Bartosz
>
>
>_______________________________________________
>Qemu-devel mailing list
>Qemu-devel <at> nongnu.org

Re: VGA BIOS source code

> Here's a link to the CL-GD542X reference manual (found by using yahoo & 
> google):

Thanks. My googling skills seem to be seriously lacking.

- Bartosz

Re: [PATCH,RFC]: PCI Host Proxy v0.1

On Mon, 2004-05-31 at 18:16 +0100, Gianni Tedesco wrote:
> Current limitations:
>  o Memory resources are not mapped in yet.

Fabrice,

Will the following work for PCI memory spaces? (I don't have any setups
which do MMIO atm to test on).

for (i=addr; i < addr + len; i+=4)
    cpu_register_io_memory(i, pciproxy_readl, pciproxy_writel);

If so, can I allow it to pass down an opaque pointer?

--

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

Re: [PATCH,RFC]: PCI Host Proxy v0.1

On Tue, 2004-06-01 at 01:04 +0100, Gianni Tedesco wrote:
> On Mon, 2004-05-31 at 18:16 +0100, Gianni Tedesco wrote:
> > Current limitations:
> >  o Memory resources are not mapped in yet.
> 
> Fabrice,
> 
> Will the following work for PCI memory spaces? (I don't have any setups
> which do MMIO atm to test on).
> 
> for (i=addr; i < addr + len; i+=4)
>     cpu_register_io_memory(i, pciproxy_readl, pciproxy_writel);

erm, i mean, actually i do:

#define IOMEM_PCIPROXY (5 << IO_MEM_SHIFT)

cpu_register_io_memory(IOMEM_PCIPROXY >> IO_MEM_SHIFT,
                       pciproxy_readl,
                       pciproxy_writel);

cpu_register_phys_mem(addr, len, IOMEM_PCIPROXY);

And can i still make the change to cpu_register_io_memory to pass down
an opaque pointer? Actually this would be nicer on the
cpu_register_phys_mem, but that'd be an impact on hot-paths i guess so
I'll just have to work around it in pciproxy.

--

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)

Re: [PATCH,RFC]: PCI Host Proxy v0.1

On Tue, 2004-06-01 at 01:12 +0100, Gianni Tedesco wrote:
> And can i still make the change to cpu_register_io_memory to pass down
> an opaque pointer? Actually this would be nicer on the
> cpu_register_phys_mem, but that'd be an impact on hot-paths i guess so
> I'll just have to work around it in pciproxy.

Actually it would be better served all round if I added an
IO_MEM_CALLBACK and added a simple infrastructure to do:

cpu_register_callback_mem(addr, len, read_cbfn, write_cbfn);

That way there'd only be a lookup cost with something that used it. I'll
hack up a patch to do that. And post it when ready.

--

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

Re: VGA BIOS source code

On Tue, 2004-06-01 at 00:23, Bartosz Fabianowski wrote:
> > Sounds great... Somewhere, I have the Cirrus Logic CL-GD542X/3X 
> > Hardware Reference manual.
> 
> Once the patch hits the tree, I would like to help developing, improving
> and bug fixing it. But unfortunately, I have no reference manual and
> even hours of googling have not revealed anything of use. Is that manual
> you have in actual dead tree format or is it a PDF / text file you could
> mail to me?

It's a dead-tree format... Once upon a time, you only had to email
Cirrus Logic and they would send the reference books free of charge.
--

-- 
Antony T Curtis <antony.t.curtis <at> ntlworld.com>

[PATCH,RFC]: Generic memory callback regions

Hi,

This patch adds an API for CONFIG_SOFTMMU mode that hardware drivers can
use to add memory regions backed by callback functions. It simply adds a
layer for storing opaque data above the basic cpu_register_io_memory /
cpu_register_physical memory functions. I used a linked list to store
the data structures, i think O(ln/2) avg. lookup time will be fine as I
don't envisage many of these regions existing.

I've tested it as far as I currently can for the pciproxy code and it
seems to do the correct thing. I could work around this manually within
the pciproxy code itself, but I figured a generic interface would be
something useful for other drivers (such as any PCI card with MMIO
resources).

Ideas / thoughts / bugs?

--

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

_______________________________________________
Qemu-devel mailing list
Qemu-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: Subject: Re: VGA BIOS source code

On Monday 31 May 2004 13:17, Bartosz Fabianowski wrote:
> Alright, after digging into QEMU's graphics card emulation and into the
> VGA BIOS source, I came to a few conclusions:
>
> a) SDD 6.53 is doing something utterly wrong. [snip]
>
> c) [snip] The entire VESA VBE
> implementation is rather broken, shaky and incomplete.
>
> b) The way the graphics card is emulated by QEMU (and Bochs and plex86
> for that matter) is totally inefficient, error-prone and overly
> complicated. [snip]

Is there a reasons for the a c b ordering?

I think you are probably a little harsh on this code.  It may be far from 
perfect, but it does (mostly) work.

> d) Finally, as a conclusion from a) to c), I believe it would be best to
> ditch the entire VGA BIOS and implement all functions of the graphics
> card in C, natively, inside QEMU. This will be more efficient and less
> error prone. Now, I haven't seen the patches mentioned by Fabrice that
> emulate a CLGD54xx. But I certainly hope it is all native and not a
> half-native half-emulated solution like the current one.

Getting something in place that pretends to be a known chipset and that can 
act like a dumb framebuffer would probably help.  That seems to be the 
direction that Fabrice and Co. are going.  

The Cirrus Logic chipset sounds like a good one for this.