nullnilaki

/********************************************************************

 This benchmark test program is measuring a cpu performance
 of floating point operation by a Poisson equation solver.

 If you have any question, please ask me via email.
 written by Ryutaro HIMENO, November 26, 2001.
 Version 3.0
 ----------------------------------------------
 Ryutaro Himeno, Dr. of Eng.

nullnilaki

            § ユーザ組み込みドライバ作成の手引



☆  概要


    ここでは，EWS-UX/V(Rel4.2MP) および UP-UX/V(Rel4.2MP)でサ
  ポートされる，VME バス上に接続されるデバイスに対するドライバ

nullnilaki

Reading symbols from /netbsd.gdb...done.
Load new symbol table from "/netbsd.gdb"? (y or n) y
Reading symbols from /netbsd.gdb...done.
#0  0xc05a2358 in maybe_dump (howto=260)
    at /usr/src/sys/arch/i386/i386/machdep.c:878
878                     dumpsys();
#0  0xc05a2358 in maybe_dump (howto=260) at /usr/src/sys/arch/i386/i386/machdep.c:878
#1  cpu_reboot (howto=260, bootstr=0x0) at /usr/src/sys/arch/i386/i386/machdep.c:899
#2  0xc0790a5a in vpanic (fmt=0xc0bb1c7b "uvm", ap=0xdafaab7c "")
    at /usr/src/sys/kern/subr_prf.c:308

nullnilaki

paddr_t
__C(CHIP,_mem_mmap)(
        void *v,
        bus_addr_t addr,
        off_t off, 
        int prot,
        int flags)  
{       
        printf("map addr %lx\n",addr);
        printf("map off %lx\n",off);

nullnilaki

There are a few problems with your code:
- you use WSDISPLAYIO_MODE_MAPPED, this is for mapping a known graphics chip's resources at their bus addresses, 
what you want is probably more like WSDISPLAYIO_MODE_DUMBFB which lets you map the framebuffer at offset 0. 
These have to be distinct in order to avoid overlap, for example Sun firmware likes to assign low addresses to PCI BARs, 
not a problem per se since there is no overlap in terms of physical addresses ( unlike with i386 PCs or macppc boxes ). 
Some drivers don't distinguish between _MAPPED and _DUMBFB but that's going to change.
- when switching back to terminal emulation just use WSDISPLAYIO_MODE_EMUL - avoids getting stuck in framebuffer mode.
- why do you call some ioctl()s on STDIN_FILENO and some on /dev/ttyE0? That may cause some strange problems.

nullnilaki

#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/ioctl.h>
#include <dev/wscons/wsconsio.h>
#include <dev/wscons/wsksymdef.h>

int

nullnilaki

FreeBSD/ia64 EFI boot, Revision 3.2
can't open '/boot/delay.4th': no such file or directory
Error while including /boot/loader.4th, in the line:
include /boot/delay.4th
\
/boot/kernel/kernel text=0x1056700 data=0xea390+0x248180 syms=[0x8+0xc6fa8+0x8+0xba819]
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...               
Entering /boot/kernel/kernel at 0x9ffc000000010500...
GDB: no debug ports present

nullnilaki

Consoles: EFI console

FreeBSD/ia64 EFI boot, Revision 3.2
can't open '/boot/delay.4th': no such file or directory
Error while including /boot/loader.4th, in the line:
include /boot/delay.4th
\
/boot/kernel/kernel text=0x1056700 data=0xea390+0x248180 syms=[0x8+0xc6fa8+0x8+0xba819]
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...

nullnilaki

make obj

TARGET=sgi make cross-tools

cd /usr/src/sys/arch/sgi/conf;config GENERIC-IP27

cd /usr/src/sys/arch/sgi/compile/GENERIC-IP27

make CC=/usr/cross/sgi/usr/mips64-unknown-openbsd5.4/bin/mips64-unknown-openbsd5.4-cc LD=/usr/cross/sgi/usr/mips64-unknown-openbsd5.4/bin/mips64-unknown-openbsd5.4-ld depend

nullnilaki

/**************************************************************************
 * Copyright 1995, Silicon Graphics, Inc.
 * ALL RIGHTS RESERVED
 *
 * UNPUBLISHED -- Rights reserved under the copyright laws of the United
 * States.   Use of a copyright notice is precautionary only and does not
 * imply publication or disclosure.
 *
 * U.S. GOVERNMENT RESTRICTED RIGHTS LEGEND:
 * Use, duplication or disclosure by the Government is subject to restrictions