Date: Thu, 15 Oct 2009 19:48:23 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: arch@freebsd.org, xcllnt@mac.com Subject: Re: x86BIOS and the ISA bus and low memory in general... Message-ID: <200910151948.31334.jkim@FreeBSD.org> In-Reply-To: <20091015.134532.-1110324186.imp@bsdimp.com> References: <20091015.085910.-520412456.imp@bsdimp.com> <200910151431.53236.jkim@FreeBSD.org> <20091015.134532.-1110324186.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 15 October 2009 03:45 pm, M. Warner Losh wrote: > [[ redirected to arch@ ]] > > In message: <200910151431.53236.jkim@FreeBSD.org> > Jung-uk Kim <jkim@FreeBSD.org> writes: > <snip> > > : 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? No, you are not. It's just a non-functional prototype for non-PC architectures. :-) > 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... You mean 15-16MB ISA hole, right? It's not implemented yet. Probably I should but I haven't seen any BIOS requiring the memory hole ATM. > 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. Actually that's my goal but I wasn't sure whether it is ever usable on *non-PC* arches. Then, orm(4) debate caught my eyes. :-) > 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. Thanks, I will keep that in mind. > 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. No, I have no intention to support BDA emulation, never. :-) Only IVT will be supported, e.g., vesa(4) calls POST on non-PC arches and it sets up the INT 10h vector. Subsequent INT 10h calls are naturally emulated. > 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?) Correct. > 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.. Yes, it's the former, at least for now, e.g., using VBE calls on powerpc or sparc64. If my memory serves, NetBSD or OpenBSD can call video POST in ddb when display is corrupt, I think. Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200910151948.31334.jkim>