From owner-freebsd-arch@FreeBSD.ORG Thu Oct 15 19:52:41 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 826AC106566C; Thu, 15 Oct 2009 19:52:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 24C9A8FC1F; Thu, 15 Oct 2009 19:52:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n9FJjIe1043543; Thu, 15 Oct 2009 13:45:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 15 Oct 2009 13:45:32 -0600 (MDT) Message-Id: <20091015.134532.-1110324186.imp@bsdimp.com> To: jkim@freebsd.org From: "M. Warner Losh" In-Reply-To: <200910151431.53236.jkim@FreeBSD.org> References: <20091015.085910.-520412456.imp@bsdimp.com> <200910151118.50619.jhb@freebsd.org> <200910151431.53236.jkim@FreeBSD.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, xcllnt@mac.com Subject: x86BIOS and the ISA bus and low memory in general... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 19:52:41 -0000 [[ redirected to arch@ ]] In message: <200910151431.53236.jkim@FreeBSD.org> Jung-uk Kim writes: : This is actually very interesting discussion for me because one of my : pet projects is extending x86bios to support non-PC architectures. : If anyone is interested, the current source tarball is here: : : http://people.freebsd.org/~jkim/x86bios-20091015.tar.bz2 : : Especially, please see the code around #ifdef X86BIOS_COMPAT_ARCH. : Basically, mapping I/O ports and orm(4) is missing. We don't have to : implement I/O ports but orm(4) vs. bus_space(9) is critical to make : it a reality. Please consider it as a real practical example for : orm, not just a blackhole driver. :-) I thought that most video cards had I/O ports as well as video RAM that needed to be mapped... Am I crazy? I'm looking at the code and have a few questions. It looks like you are allocating memory from 0x1000 to 0xa0000 with a contig malloc, and then redirecting the emulator's read/write into that array. But I don't see where the memory reads for the so-called ISA ROM hole are going. I was looking for that hoping I could find them so I could comment on them... orm uses bus_space today to do its read/write of the memory. I'd imagine that if you wanted to touch actual hardware, then you'd need to have drivers and/or the emulator use the same path to accomplish this. While in theory one could have multiple ISA busses in a system, as a practical matter nobody does this. Even when you have weird expansion busses on laptop docking stations, you'd have them all mapped into one space. This means we can likely make some simplifying assumptions that there is a single ISA bus on the system. I don't know if we have to make that assumption, but it is something to keep in the back of our heads. This suggests that the emulation device would have to attach somehow to the ISA bus to make sure that the right translations (wherever they happen) can happen. But there's a catch... The readw/readb macros in the atkbd.c driver likely need to change to bus space macros of some kind to make this work. I'm unsure how, exactly, to make that happen since these addresses aren't for anything on the actual ISA bus, but rather are for data that's contained in the contigmalloc'd area. They aren't really ISA bus addresses, yet they are expected to be there by the drivers. bus_space suggests itself for this as well, but it isn't at all clear how that might be accomplished because ES could point anywhere in the first MB of RAM (since 16-bit operations are limited to 1MB with segments, right?) This is a very interesting project... Is the goal to emulate the BIOS or execute the BIOS that might be loaded on the expansion cards in these weird environments. I'm guessing the former, but you never know.. Warner