Date: Fri, 26 Jun 1998 14:39:08 -0700 From: Mike Smith <mike@smith.net.au> To: Andrzej Bialecki <abial@nask.pl> Cc: Mike Smith <mike@smith.net.au>, freebsd-small@FreeBSD.ORG Subject: Re: Flashes and BIOS (was Re: I'm back.) Message-ID: <199806262139.OAA09060@antipodes.cdrom.com> In-Reply-To: Your message of "Fri, 26 Jun 1998 21:46:28 %2B0200." <Pine.NEB.3.95.980626212536.25377B-100000@korin.warman.org.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Fri, 26 Jun 1998, Mike Smith wrote: > > > > * I just received a flash disk (16MB, M-Systems, ISA card), thanks to > > > Goran Hasse of Raditex, SE - I'll be experimenting with it till it starts > > > working... :-) (i.e. I want to boot from it, and somehow access it to > > > store the config data). I also plan to read the docs about Linux > > > implementation of Flash Filesystem (romfs). Any pointers appreciated! > > > > If this card has an on-board BIOS, I would be more than happy to help > > you implement a VM86-based BIOS-disk driver on -current. We have > > everything in place to make this pretty easy. > > Yes, yes!!! That was what I also intended to pursue. You see, it has it's > own BIOS which makes it accessible from DOS as an IDE drive. There is a > driver for QNX, but (obviously) binary only. From the h/w point of > view the card is seen through a 10kB memory region (no IO adresses). It doesn't make it visible from DOS as an IDE drive; it makes it visible as a BIOS drive. Big difference. 8) > As I said I just received it today, plugged it into a spare machine and > verified that it works, nothing more (in fact, I even booted FreeBSD from > it, but of course couldn't mount root). Its BIOS hooks up normal int13, I > think... so yes, if we could call its BIOS under FreeBSD, this should > just work as expected (modulo some unexpectancies :-). The real gotchas are just whether the card BIOS makes any assumptions about system and hardware state (eg. hijacking timer hardware, interrupt vectors etc.). > I have to display my total ignorance here: I'm not sure what happens to > the interrupt vectors once FreeBSD is booted - are they stored somewhere? > are they changed at all? I kind of vaguely remember them being located > somewhere near the 0:0 right after the POST completes (in real mode, just > after startup). What happens to them when freebsd switches to protected > mode? Is this memory area used at all? etc, etc... The bottom few pages of the system are left entirely alone. When a VM86 context is created, it inherits copies of these pages in order to effectively make the BIOS vectors available. What you can't guarantee is that the system hardware is not going to be abused by the BIOS, although as a general rule, BIOS writers tend to be conservative about what they plaster. Despite this, the operating systems that offer good VM86 services (eg. OS/2) still virtualise most of the hardware. We don't do this (it's hard!), which makes the hardware directly available to the code in the vm86 context (presuming it's caller has permission to access it - a user-space caller without IOPL set will still trap if it attempts to do port I/O). > As for the driver: I'm totally ignorant in writing device drivers (and > anything that must reside in kernel) - all I did thus far was to run the > scripts in /usr/share/examples, and look at the code they produced... but > I'm determined to learn, and code what I can. :-) Take something like 'wfd' and rip the guts out of it. There's a lot of ATAPI crap in there, but basically it's a nice, relatively simple driver that hasn't grown too many warts (unlike 'wd'!). You want to look at i386/i386/vm86.c:initial_bioscalls() to see how to make BIOS calls (skip the vm86_initialise() call). You'll also want to work out how to allocate a bounce buffer in extremely-low memory (below the 1MB mark) - this may involve fiddling the memory probe code or the code in machdep.c to "hide" another page down low. A single page will let you do transfers up to 4k at a time, which is reasonable. Less than that and you'll thrash, much more and you run the risk of spending too long in the BIOS. Then go get a copy of Ralf Brown's Interrupt List, and start reading up on the BIOS calls for locating and accessing BIOS disks. Initially, I would suggest abusing the ISA device model because that way you can get parameters to your driver. Take the I/O port and use it as the BIOS unit number, and ignore the rest of the parameters. One tip - normally you commit the disk transfer to hardware out of the strategy routine, which then returns. At some later stage, the interrupt handler calls your done routine, which then calls biodone() on the bp that the strategy routine started. Because you call into the BIOS to do the work, and it returns a result immediately, you will want to skip the done routine altogether. Of course, you may have to make several BIOS calls to satisfy the request in the bp (as if you're only using one page, you will only get 4K at a time). I hope this helps; I have a flash-based board on the way as well, but if you're in a strong position to work on this, supporting you is easier than finding time among all my other projects. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806262139.OAA09060>