On 2/17/2014 6:50 AM, Mark Cave-Ayland wrote:
> On 14/02/14 14:54, Peter Crosthwaite wrote:
>
>>> The short answer is "we don't know" because we don't have any
>>> documentation.
>>
>> Sigh This has happened quite a lot lately.
>>
>> If the kernel driver has macros, re-use them as much as poss
> > "info qtree" will always print both decimal and hex.
>
> If I try that here then with the CG3 patch applied the prom_addr
> property is always just displayed in decimal...? Or have I missed
> something obvious here?
Grammar sucks. :)
It *will* always print both decimal and hex once HEX64 is
On 14/02/14 14:54, Peter Crosthwaite wrote:
The short answer is "we don't know" because we don't have any documentation.
Sigh This has happened quite a lot lately.
If the kernel driver has macros, re-use them as much as possible. If
you have a vague idea on whats, what, a few well invente
On 10/02/14 08:20, Paolo Bonzini wrote:
Il 09/02/2014 16:24, Mark Cave-Ayland ha scritto:
Alright I can change those for the next version of the patch. Does that
mean the use of hex output is now a display option rather than a
separate property type?
"info qtree" will always print both decim
On 09/02/14 15:33, Peter Maydell wrote:
It's been a little while since I looked, however this was my interpretation
of the table 3-12 on p.66 of the SBus specification. While that particular
table refers to the acknowledgment cycle from the slave back to the master,
it seems to work here in the
On Sun, Feb 9, 2014 at 11:35 PM, Mark Cave-Ayland
wrote:
> On 09/02/14 04:14, Peter Crosthwaite wrote:
>
> Hi Peter,
>
> Thanks for the review!
>
> (cut)
>
>
>>> +/* #define DEBUG_CG3 */
>>> +
>>> +#define CG3_ROM_FILE "QEMU,cgthree.bin"
>>> +#define FCODE_MAX_ROM_SIZE 0x1
>>> +
>>> +#define
Il 09/02/2014 16:24, Mark Cave-Ayland ha scritto:
Alright I can change those for the next version of the patch. Does that
mean the use of hex output is now a display option rather than a
separate property type?
"info qtree" will always print both decimal and hex.
Paolo
Am 09.02.2014 16:24, schrieb Mark Cave-Ayland:
> One thing I'm not sure about is how the QOM stuff interacts with sysbus
> - can you quickly point me towards an existing device that does this so
> I can understand how this works?
The ARM MPCore devices come to mind. But really all you've been aske
On 9 February 2014 15:19, Mark Cave-Ayland
wrote:
> On 09/02/14 14:41, Peter Maydell wrote:
>
>> On 8 February 2014 16:38, Mark Cave-Ayland
>> wrote:
>>> +case 4:
>>> +/* This register can be written to as either a long word or a
>>> byte.
>>> + * According to the SBus specif
On 09/02/14 15:10, Andreas Färber wrote:
Hi Andreas,
Hi,
Am 08.02.2014 17:38, schrieb Mark Cave-Ayland:
+static Property cg3_properties[] = {
+DEFINE_PROP_HEX32("vram_size", CG3State, vram_size, -1),
Paolo is about to drop hex32 ...
H okay...
+DEFINE_PROP_UINT16("width",
On 09/02/14 14:41, Peter Maydell wrote:
On 8 February 2014 16:38, Mark Cave-Ayland
wrote:
The CG3 framebuffer is a simple 8-bit framebuffer for use with operating
systems such as early Solaris that do not have drivers for TCX.
+static void cg3_reg_write(void *opaque, hwaddr addr, uint64_t va
Hi,
Am 08.02.2014 17:38, schrieb Mark Cave-Ayland:
> +static Property cg3_properties[] = {
> +DEFINE_PROP_HEX32("vram_size", CG3State, vram_size, -1),
Paolo is about to drop hex32 ...
> +DEFINE_PROP_UINT16("width",CG3State, width, -1),
> +DEFINE_PROP_UINT16("height",
On 8 February 2014 16:38, Mark Cave-Ayland
wrote:
> The CG3 framebuffer is a simple 8-bit framebuffer for use with operating
> systems such as early Solaris that do not have drivers for TCX.
>
> +static void cg3_reg_write(void *opaque, hwaddr addr, uint64_t val,
> + unsign
On 09/02/14 04:14, Peter Crosthwaite wrote:
Hi Peter,
Thanks for the review!
(cut)
+/* #define DEBUG_CG3 */
+
+#define CG3_ROM_FILE "QEMU,cgthree.bin"
+#define FCODE_MAX_ROM_SIZE 0x1
+
+#define CG3_REG_SIZE 0x20
+#define CG3_VRAM_SIZE 0x10
+#define CG3_VRAM_OFFSET 0x80
+
+#ifdef
On Sun, Feb 9, 2014 at 2:38 AM, Mark Cave-Ayland
wrote:
> The CG3 framebuffer is a simple 8-bit framebuffer for use with operating
> systems such as early Solaris that do not have drivers for TCX.
>
> Signed-off-by: Mark Cave-Ayland
> CC: Blue Swirl
> CC: Anthony Liguori
> CC: Peter Maydell
>
The CG3 framebuffer is a simple 8-bit framebuffer for use with operating
systems such as early Solaris that do not have drivers for TCX.
Signed-off-by: Mark Cave-Ayland
CC: Blue Swirl
CC: Anthony Liguori
CC: Peter Maydell
CC: Bob Breuer
CC: Artyom Tarasenko
---
Makefile
16 matches
Mail list logo
