From owner-freebsd-small Fri May 22 15:12:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA00419 for freebsd-small-outgoing; Fri, 22 May 1998 15:12:54 -0700 (PDT) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from oldyeller.comtest.com (comtest.hits.net [206.127.244.117]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA00377 for ; Fri, 22 May 1998 15:12:38 -0700 (PDT) (envelope-from randal@comtest.com) Received: from graphics.comtest.com (graphics.comtest.com [206.127.245.194]) by oldyeller.comtest.com (8.8.8/8.8.8) with SMTP id MAA07511; Fri, 22 May 1998 12:03:31 -1000 (HST) (envelope-from randal@comtest.com) Message-Id: <199805222203.MAA07511@oldyeller.comtest.com> Comments: Authenticated sender is From: "Randal S. Masutani" Organization: ComTest Technologies, Inc. To: Andrzej Bialecki Date: Fri, 22 May 1998 12:21:52 -1000 Subject: Re: Embeded applications? Reply-to: randal@comtest.com CC: freebsd-small@FreeBSD.ORG References: <199805212145.LAA05174@oldyeller.comtest.com> In-reply-to: X-mailer: Pegasus Mail for Windows (v2.54) Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22 May 98 at 8:35, Andrzej Bialecki wrote: > On Thu, 21 May 1998, Randal S. Masutani wrote: > > > On 14 May 98 at 11:12, Andrzej Bialecki wrote: > > > > > It emulates a hard drive at the BIOS level. ie. it is accessed as > > drive=0x80 and has cylinders=1021, heads=1, sectors=16, ~8MB Flash. It > > has a standard partition table in c=0, h=0, s=1. The BIOS after POST > > looks for a bootable floppy disk, then a bootable hard drive. Just like > > a standard boot process. The flash drive is setup with the standard DOS > > FDISK and FORMAT commands. > > So, this looks _exactly_ like IDE drive. This means it can boot FreeBSD no > problem. No, no ... sorry if I was not clear with my statements above. Let me clarify myself. There are two major ways that manufactures implement access to Flash memory devices, Software or Hardware emulation. 1. Software BIOS emulation, INT 13H. Also identified as Flash File System. This mean that you can only access the flash through BIOS call interrupt 13H. Using INT 13H you can specify CHS(cylinder,head,sector) values to access the flash. It does not have any hardware compatibility with IDE I/O ports or registers. Since DOS commands rely only on BIOS calls to access hard drives, this type of emulation works with the standard DOS commands FDISK and FORMAT. FreeBSD kernel cannot see this type of flash since it cannot call BIOS routines. (this is the type of flash that is built onto the PC/104 CPU board I am using) 2. Hardware IDE emulation. This means hardware compatibility with IDE I/O ports and registers. It physically attaches to an IDE controller cable as a drive. The FreeBSD kernel can see this type of flash. It will show up as a 'disk wd0 at wdc0 drive 0' device in the kernel. (I do not have this type of IDE flash yet) 3. Hardware PCMCIA flash. This type of flash plugs into standard PCMCIA slots. This type of flash requires the standard PC CARD Socket Services. The PAO version of FreeBSD supports this type of flash. 4. Hardware Floppy emulation. This type of flash looks just like a floppy drive. It attaches to the floppy controller cable as a drive. FreeBSD kernel would work with this type also, as 'disk fd0 at fdc0 drive 0'. However I haven't seen this type available in the form that I need. > > I have copied over the floppy.tree/etc to mfs.tree/etc. I did take into account > > the language files and mfs.rc.xx. I had to modify the populate and stage3 > > scripts accordingly. I did get it to compile and work ok from floppy only. > > However I understand that the /etc files are static and cannot save changes. > > Not what I want. But I can work with this for now. > > Hmmm... You see, FFS takes too much space from flash (which is expensive), > so as long as you can you should avoid it. One possible solution would be > to split flash into two partitions: one big (containing bootable image on > raw partition), and the second one containing the configuration file > (single). This way, you could use the whole partition for bootable image > (no space wasted on FFS), and then you could access raw partition #2 to > get raw blocks containing configuration data (and after changing, just > write it block by block back on the raw partition). It's just an idea - it > needs testing.. :-) > > > I haven't modified the boot block yet. I am not sure which boot block > > to use. What's the difference in biosboot, dosboot, kzipboot, rawboot? > > Also what about the files in /usr/mdec/ bootfd, fdboot, bootwd, wdboot, > > boot1, boot2, rawboot? > > * biosboot: uses BIOS services to find proper disk/partition, and uses its > own knowledge of FFS to get kernel from there, > * rawboot: as above, but doesn't understand FFS. All it knows is to pull > the chain of next data blocks from the media it was started from > * dosboot: EXE program, which can load FreeBSD kernel either from DOS > partition or from FFS > * kzipboot: it's a special stub which gets appended and prepended to > kzipp'ed kernel in order to unpack it after loading. (see kzip(8)). > > And the files: > * bootfd, fdboot, bootwd, wdboot - links to so called 'stage 1 boot', i.e. > the stub that pulls the data from media. > * boot2 - the stub that actually loads the kernel (i.e. properly relocates > appropriate sections of a.out binary file, and passes control to it). > > > I am not sure what to modify in your scripts to put the right boot block info. > > Could you show me what I need to change? > > What really matters here is the 'dd if=/usr/mdec/boot1' line in 'stage3' > script. It uses biosboot stub. In order to use rawboot you'd say something > like: > cat /usr/mdec/rawboot kernel.kz >/dev/rvn0c > Of course, you loose the FFS now - the media it will be booting from can > be accessed only as raw data blocks... I will try using the rawboot, since I do not need FFS. Technically I do not have access to FFS anyway as explained above, since I am using software BIOS flash drive. > > Also once I have built the picobsd image how do I transfer that to the flash > > drive? I need some kind of utility to transfer an image file to flash? > > If you have the flash connected to FreeBSD machine, it should be detected > during bootup (see 'dmesg') as one more IDE disk. Then you access it in > quite normal way, i.e. /dev/rwdX. As for transfering the files... simply > do dd if=you_file of=/dev/rwdX - it should work. As explained above I do not have hardware IDE compatibility with this flash. So I still need to figure out once I have the kernel and MFS built. How to transfer that to the flash drive? I need some kind of program that can transfer an image to the flash drive using BIOS-INT 13H calls. I also need to figure out from what source will I get the image from. I have only a floppy drive attached to the PC/104 board. I can only boot from floppy since I do not have anything in flash drive yet. So I probably need a DOS boot floppy with a image writer program and the picobsd image. > > Can I have picobsd boot from a DOS partition using fbsdboot.exe ? > > I think - yes. I didn't try it yet... > > > Do I need to make the picobsd image differently for booting from a DOS > > partition using fbsdboot.exe? > > In normal case of GENERIC kernel, it can be booted right from DOS > partition. To be frank, I've never tried this... But I will. I plan to try > to create something like bootable FreeBSD image which could be put on DOS > partition, and be started from there... but it's still in plans only... This would be an alternative. Since I can format the flash drive as a bootable DOS FAT partition. And put the fbsdboot.exe and a bootable kernel image in it. And then boot DOS and have autoexec.bat execute fbsdboot.exe on startup. > > The IDE emulation is in hardware. So it is register level compatible. > > The IDE flash looks like a wd hard drive to the kernel. With this IDE > > emulation we can have a FFS filesystem in flash just like a standard > > hard drive. > > Yep. But as I said above, in most cases (except for development and > debugging, and just to get the project started :-) you don't want to have > FFS there - it wastes too much space. The target situation (IMHO) should > be to live without FFS, and use raw pieces of flash for kernel and config > data. > > Andrzej Bialecki > NOTE: FYI, "FFS" acronyms is used in two ways. In FreeBSD FFS stands for Fast File System. In the PC/104 industry FFS stands for Flash File System. It can get confusing at times... :) Randal Masutani ------------------------------------------------------------------------- ComTest Technologies, Inc. 3049 Ualena St., Suite 1005 Honolulu, Hawaii 96819 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message