Date: Thu, 11 Sep 2003 22:08:07 +0000 From: Nicolas Souchu <nsouch@free.fr> To: freebsd-arch@freebsd.org Cc: Marcel Moolenaar <marcel@xcllnt.net> Subject: kgi4BSD progress report Message-ID: <20030911220807.A5528@armor.free.fr>
next in thread | raw e-mail | index | archive | help
Hi folks, Just to keep you informed about my console project. The project URL is now http://www.freebsd.org/~nsouch/kgi4BSD kgi4BSD comes to the point where the console messages are printed in 640x400x8 graphic mode using the gfb boot font. There is still no virtual terminal handling because I'm not sure about it in the kernel. Regarding this I'd be glad to have opinions about having the VTs managed outside the kernel. You'll find the current design picted at http://www.freebsd.org/~nsouch/kgi4BSD/design-notes.html for the text version. Concerning graphic mode, one should replace the ISO renderer and the TEXT16 resource by a called GFB renderer with a KGI fb resource. Blocks in the diagram interact through a flexible kobj API. Now comes the point where we all want better modes and portability. Better modes should be provided by KGI native driver which currently can only be probed during bus enumeration. Currently, the KGI drivers rely on a PCI API looking like this: #if KGI_SYS_NEED_i64 typedef __kgi_u64_t pcicfg_vaddr_t; /* the virtual address type */ #define PCICFG_64_NULL ((pcicfg_vaddr_t) 0xFFFFFFFFFFFFFFFF) #define PCICFG_NULL PCICFG_64_NULL #else typedef __kgi_u32_t pcicfg_vaddr_t; /* the virtual address type */ #define PCICFG_32_NULL ((pcicfg_vaddr_t) 0xFFFF0000) /* an invalid virtual address */ #define PCICFG_NULL PCICFG_32_NULL #endif #define PCICFG_VADDR(bus, slot, fn) \ !((bus+1 > 0) || (slot+1 > 0) || (fn+1 > 0)) \ ? PCICFG_NULL \ : ( (pcicfg_vaddr_t) \ ((((bus) & 0xFF) << 24) | (PCI_DEVFN((slot),(fn)) << 16)) ) #define PCICFG_BUS(vaddr) (((vaddr) >> 24) & 0xFF) #define PCICFG_DEV(vaddr) PCI_SLOT(((vaddr) >> 16) & 0xFF) #define PCICFG_FN(vaddr) PCI_FUNC(((vaddr) >> 16) & 0xFF) #define PCICFG_REG(vaddr) ((vaddr) & 0xFFFF) #define PCICFG_SIGNATURE(vendor, device) ((vendor << 16) | device) /* * FreeBSD specific stuff */ extern pcicfg_vaddr_t pcicfg_dev2cfg(device_t dev); extern struct pcicfg_dev *pcicfg_lookup_device(pcicfg_vaddr_t pcidev); extern device_t pcicfg_get_device(pcicfg_vaddr_t pcidev); extern int pcicfg_add_device(device_t dev); extern int pcicfg_remove_device(device_t dev); extern void pcicfg_claim_device(pcicfg_vaddr_t addr); extern void pcicfg_free_device(pcicfg_vaddr_t addr); extern int pcicfg_find_device(pcicfg_vaddr_t *addr, const __kgi_u32_t *signatures); extern int pcicfg_find_subsystem(pcicfg_vaddr_t *addr, const __kgi_u32_t *signatures); extern int pcicfg_find_class(pcicfg_vaddr_t *addr, const __kgi_u32_t *signatures); extern __kgi_u8_t pcicfg_in8 (const pcicfg_vaddr_t vaddr); extern __kgi_u16_t pcicfg_in16(const pcicfg_vaddr_t vaddr); extern __kgi_u32_t pcicfg_in32(const pcicfg_vaddr_t vaddr); extern void pcicfg_out8 (const __kgi_u8_t val, const pcicfg_vaddr_t vaddr); extern void pcicfg_out16(const __kgi_u16_t val, const pcicfg_vaddr_t vaddr); extern void pcicfg_out32(const __kgi_u32_t val, const pcicfg_vaddr_t vaddr); Currently, this API is only a wrapper to the FreeBSD pci newbus/buspace API. But, for the boot, this API could be simply implemented with arch specific code for accessing the PCI space. Then the bus enumeration could take the pcicfg structures to reserve the resources already acquired by the graphic driver during boot. Another approach could be to unload the driver after boot and reload it with the more appropriate pcicfg API then based on newbus/buspace. This second solution would enforce to use kobj for the pcicfg to enable ABI compatibility between the 2 pcicfg implementations (avoiding relinking). We have to provide a convenient way to fully use the KGI drivers even with arch specific code at boot. All ideas/remarks are welcome. Nicholas -- Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030911220807.A5528>