Xen devel - Aug 2006 - Getting a console on the Intel mac / ioremap

On 13/8/06 4:47 pm, "Marco Gerards" <mgerards@xs4all.nl> wrote:
> Currently booting is done from EFI in graphics mode.  The chipset is
> not running in a VGA compatible mode so I can not switch back to text
> mode using the code in xen/drivers/char/console.c:init_vga.  I think
> this can be solved by switching back to VGA mode by programming some
> registers on the card.
Do you definitely need to poke some of the mmio registers to do this, or
might it be possible via the I/O ports?
> 
> The problem I ran into is that only the first 4 MB (see
> IOREMAP_MBYTES) is usable when using ioremap().  For example, the
> videocard I am using does memory mapped IO at 0x90380000, thus above
> this 4MB.  Changing IOREMAP_MBYTES just like that isn''t possible
> either, it seems.
There isn''t a proper ioremap() any more, because it wasn''t
being used for
x86.
> What would be the right way to change the way ioremap will work, or is
> there an alternative way I can use to get access to this IO memory?
For now you could add some fixmap entries and use those to map the vga
registers. Alternatively, since you''re only doing this at start of day,
you
could use some lowmem virtual address to map the registers just for long
enough to reset to vga mode, and then throw away those mappings.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi,

As you might have noticed by now, I am working to get Xen working on
the Intel Mac, this is for Google''s Summer of Code.  I am trying to
get Xen booting from EFI now.  In order to do some debugging and of
course for a proper port, I need to have a console.

Currently booting is done from EFI in graphics mode.  The chipset is
not running in a VGA compatible mode so I can not switch back to text
mode using the code in xen/drivers/char/console.c:init_vga.  I think
this can be solved by switching back to VGA mode by programming some
registers on the card.

The problem I ran into is that only the first 4 MB (see
IOREMAP_MBYTES) is usable when using ioremap().  For example, the
videocard I am using does memory mapped IO at 0x90380000, thus above
this 4MB.  Changing IOREMAP_MBYTES just like that isn''t possible
either, it seems.

What would be the right way to change the way ioremap will work, or is
there an alternative way I can use to get access to this IO memory?

Thanks,
Marco


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 13/8/06 5:11 pm, "Marco Gerards" <mgerards@xs4all.nl> wrote:
>> For now you could add some fixmap entries and use those to map the vga
>> registers. Alternatively, since you''re only doing this at
start of day, you
>> could use some lowmem virtual address to map the registers just for
long
>> enough to reset to vga mode, and then throw away those mappings.
> 
> Right.  What would be the right place and method to add these fixmap
> entries to do this the right way?  I am not yet too familiar with
> Xen''s memory layout.  As I see it, I just have to add something to
> "enum fixed_addresses" and write code similar to the
__acpi_map_table
> function to get this right.  Am I correct?
Yes, that''s right. Remember the numbering is backwards (bigger indexes
in
the enum take you backwards through the virtual address space because fixmap
grows downwards). If the scheme works out we can maybe find a better place
for this temporary mapping, but it''ll do for now.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser <Keir.Fraser@cl.cam.ac.uk> writes:
> On 13/8/06 4:47 pm, "Marco Gerards" <mgerards@xs4all.nl>
wrote:
>
>> Currently booting is done from EFI in graphics mode.  The chipset is
>> not running in a VGA compatible mode so I can not switch back to text
>> mode using the code in xen/drivers/char/console.c:init_vga.  I think
>> this can be solved by switching back to VGA mode by programming some
>> registers on the card.
>
> Do you definitely need to poke some of the mmio registers to do this, or
> might it be possible via the I/O ports?
Right, mmio only as it seems.
>> The problem I ran into is that only the first 4 MB (see
>> IOREMAP_MBYTES) is usable when using ioremap().  For example, the
>> videocard I am using does memory mapped IO at 0x90380000, thus above
>> this 4MB.  Changing IOREMAP_MBYTES just like that isn''t
possible
>> either, it seems.
>
> There isn''t a proper ioremap() any more, because it
wasn''t being used for
> x86.
Right, ioremap just adds an offset to the pointer you provide it
with.  Which is this 4MB region.
>> What would be the right way to change the way ioremap will work, or is
>> there an alternative way I can use to get access to this IO memory?
>
> For now you could add some fixmap entries and use those to map the vga
> registers. Alternatively, since you''re only doing this at start of
day, you
> could use some lowmem virtual address to map the registers just for long
> enough to reset to vga mode, and then throw away those mappings.
Right.  What would be the right place and method to add these fixmap
entries to do this the right way?  I am not yet too familiar with
Xen''s memory layout.  As I see it, I just have to add something to
"enum fixed_addresses" and write code similar to the __acpi_map_table
function to get this right.  Am I correct?

Thanks,
Marco


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Sun, Aug 13, 2006 at 04:44:53PM +0100, Keir Fraser wrote:
> > The problem I ran into is that only the first 4 MB (see
> > IOREMAP_MBYTES) is usable when using ioremap().  For example, the
> > videocard I am using does memory mapped IO at 0x90380000, thus above
> > this 4MB.  Changing IOREMAP_MBYTES just like that isn''t
possible
> > either, it seems.
> 
> There isn''t a proper ioremap() any more, because it
wasn''t being used for
> x86.
FWIW, I''m been using the attached patch for ioremap() support on
x86-64 for a while for the IOMMU work. It should work on x86 as well,
but I haven''t tested it.

diff -r 0340e579f065 xen/arch/x86/x86_64/Makefile
--- a/xen/arch/x86/x86_64/Makefile	Sat Aug 12 16:18:08 2006 +0100
+++ b/xen/arch/x86/x86_64/Makefile	Mon Aug 14 10:00:57 2006 +0300
@@ -1,3 +1,4 @@ obj-y += entry.o
 obj-y += entry.o
 obj-y += mm.o
+obj-y += ioremap.o
 obj-y += traps.o
diff -r 0340e579f065 xen/arch/x86/x86_64/ioremap.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/arch/x86/x86_64/ioremap.c	Mon Aug 14 10:01:02 2006 +0300
@@ -0,0 +1,72 @@
+/*
+ * ioremap support for x86-64
+ *
+ * Copyright (C) IBM Corporation, 2006
+ * Based on Linux code (C) Copyright 1995 1996 Linus Torvalds
+ *
+ * Author: Muli Ben-Yehuda <muli@il.ibm.com>
+ */
+
+#include <xen/lib.h>
+#include <asm/config.h>
+#include <asm/io.h>
+
+static unsigned long remap_base = IOREMAP_VIRT_START;
+
+#define PAGE_ALIGN(addr)    (((addr) + PAGE_SIZE - 1) & PAGE_MASK)
+
+void* ioremap(unsigned long phys_addr, unsigned long size)
+{
+    unsigned long vaddr;
+    unsigned long offset, last_addr;
+    unsigned long mfn, nr_mfns, flags;
+
+    /* Don''t allow wraparound or zero size */
+    last_addr = phys_addr + size - 1;
+    if ( (size == 0) || (last_addr < phys_addr) )
+        return NULL;
+
+    /* Don''t remap the low PCI/ISA area: it''s always mapped.
*/
+    if ( (phys_addr >= 0xA0000) && (last_addr < 0x100000) )
+        return __va(phys_addr);
+
+    /*
+     * We don''t printk before this point - it ends up being called in
very early
+     * boot before printk is safe to use.
+     */
+
+    if ( (remap_base + size) > (IOREMAP_VIRT_END - 1) )
+    {
+        printk("ioremap: going past end of reserved space!\n");
+        return NULL;
+    }
+
+    /* Mappings have to be page-aligned. */
+    offset = phys_addr & ~PAGE_MASK;
+    phys_addr &= PAGE_MASK;
+    size = PAGE_ALIGN(last_addr) - phys_addr;
+
+    /* Ok, go for it. */
+    vaddr = remap_base;
+    remap_base += size;
+
+    mfn = phys_addr >> PAGE_SHIFT;
+    nr_mfns = size >> PAGE_SHIFT;
+    flags = PAGE_HYPERVISOR_NOCACHE;
+ 
+    map_pages_to_xen(vaddr, mfn, nr_mfns, flags);
+
+    vaddr |= offset;
+
+    return (void *)(vaddr);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff -r 0340e579f065 xen/include/asm-x86/io.h
--- a/xen/include/asm-x86/io.h	Sat Aug 12 16:18:08 2006 +0100
+++ b/xen/include/asm-x86/io.h	Mon Aug 14 10:00:57 2006 +0300
@@ -5,8 +5,14 @@
 #include <xen/types.h>
 #include <asm/page.h>
 
-/* We don''t need real ioremap() on Xen/x86. */
+#if defined(__i386__)
+/* We don''t need real ioremap() on x86-32. */
 #define ioremap(x,l) (__va(x))
+#elif defined(__x86_64__)
+extern void* ioremap(unsigned long physaddr, unsigned long size);
+#else
+#error "please provide ioremap for your platform"
+#endif
 
 #define readb(x) (*(volatile char *)(x))
 #define readw(x) (*(volatile short *)(x))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser <Keir.Fraser@cl.cam.ac.uk> writes:
> On 13/8/06 5:11 pm, "Marco Gerards" <mgerards@xs4all.nl>
wrote:
>
>>> For now you could add some fixmap entries and use those to map the
vga
>>> registers. Alternatively, since you''re only doing this at
start of day, you
>>> could use some lowmem virtual address to map the registers just for
long
>>> enough to reset to vga mode, and then throw away those mappings.
>> 
>> Right.  What would be the right place and method to add these fixmap
>> entries to do this the right way?  I am not yet too familiar with
>> Xen''s memory layout.  As I see it, I just have to add
something to
>> "enum fixed_addresses" and write code similar to the
__acpi_map_table
>> function to get this right.  Am I correct?
>
> Yes, that''s right. Remember the numbering is backwards (bigger
indexes in
> the enum take you backwards through the virtual address space because
fixmap
> grows downwards). If the scheme works out we can maybe find a better place
> for this temporary mapping, but it''ll do for now.
This works perfectly for me.  Thanks again!

--
Marco


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel