Using a real CF as a HD on OpenBSD

[vext01]

Hi,

I wanted to start a hard disk (CF) install of workbench using FS-UAE. I seem to have fallen at the first hurdle. I know that device node hard disks are not officially supported, but since OpenBSD is a UNIX system, I would expect it to work.

I am unable to select the CF device node from the launcher. I see the ugen (generic usb device nodes) in the file selector, but not the nodes corresponding to the CF. These are /dev/rsd1* and /dev/sd1*. I even 777'd them.

I then manually hacked the config file to point fs-uae at /dev/rsd1c (the raw device node of the whole CF). The following was shown on the console when i loaded the hacked config:

checksumming '/dev/rsd1c'
checksum '/dev/rsd1c'

The launcher then hangs. It is a 4GB card, so it could just be taking a long time?

The same happens for the non-raw equivalent device node; /dev/sd1c

I will try leaving it a while to see if anything happens.

Note that the CF is not formatted yet. I was hoping to do that under emulated WB.

I'm using fs-uae-2.2.3 in OpenBSD ports, as ported by myself.

Cheers

[Foul]

Maybe same prob as me ? : http://eab.abime.net/support-fs-uae/...ot-access.html

[vext01]

Like I said, the device nodes are 777.

[vext01]

Right, so I kludged the launcher so that it does not checksum hard disks if they are device nodes. I am not sure if this is correct, but anyway, after launching fs-uae with this patch, the emulator crashes like so:

hd: tried to seek out of bounds! (0x0 >= 0x0)
Abort trap (core dumped)

In the log file:

hdf_close_target
hfd open: '/dev/rsd1c'
HDF '/dev/rsd1c' opened, size=0K mode=3 empty=0
Internal error; file src/od-fs/hardfile_host.cpp, line 433

Looks like fs-uae is under the impression that this is a hdf image...

I also tried:
hard_drive_0_type = rdb in the config. No joy. Am i missing something?

[vext01]

Looks like the same issue as this:
http://eab.abime.net/support-fs-uae/...-card-osx.html

$ du -h /dev/rsd1c
0B /dev/rsd1c

[FrodeSolheim]

Hi, you "fixed" the launcher yourself, I see ;-) It would presumable complete checksumming the device eventually. The problem is that the device "file size" is 0 when queried like a file on *BSD it seems, and the launcher checksums HDF files less than a certain size...

Regarding FS-UAE itself, a similar problem occurs. FS-UAE open the device as a file (yes, for all practical purposes it *is* a "HDF file", so that's not a bug) and reads the size of the file. This works on Linux, but not on OS X, and presumably neither on *BSD.

If you check od-fs/hardfile_host.cpp, you'll see there are special code for Mac OS X (#ifdef MACOSX) which uses ioctls for retrieving the size of the device (if the file is a block device). Something similar probably needs to be done on OpenBSD as well. The OS X code might even work out of the box on OpenBSD too, if it is enabled...

[vext01]

Hi Frode,

I was going to post this diff last night, but abime was down. The following diff does... well.. exactly what you said above: uses an ioctl() to determine the disk size What a coincidence! Will this be able to be committed?

(Not sure if pasting the diff in the forum will work, let's find out).

--- src/od-fs/hardfile_host.cpp.orig	Tue Jun 25 20:21:17 2013
+++ src/od-fs/hardfile_host.cpp	Tue Aug  6 23:17:45 2013
@@ -19,6 +19,14 @@
 #include <sys/disk.h>
 #endif
 
+#ifdef __OpenBSD__
+#include <sys/types.h>
+#include <sys/disklabel.h>
+#include <sys/dkio.h>
+#include <sys/ioctl.h>
+#include <fcntl.h>
+#endif
+
 #define hfd_log write_log
 static int g_debug = 0;
 
@@ -292,7 +300,7 @@ int hdf_open_target (struct hardfiledata *hfd, const c
             // determine size of hdf file
             int ret;
             off_t low;
-#ifdef MACOSX
+#if defined(MACOSX) || defined(__OpenBSD__)
             // check type of file
             struct stat st;
             ret = stat(name,&st);
@@ -300,11 +308,12 @@ int hdf_open_target (struct hardfiledata *hfd, const c
                 write_log("osx: can't stat '%s'\n", name);
                 goto end;
             }
-            // block devices need special handling on osx
+            // block devices need special handling on BSD and OSX
             if (S_ISBLK(st.st_mode) || S_ISCHR(st.st_mode)) {
+            int fh = fileno(h);
+#if defined(MACOSX)
                 uint32_t block_size;
                 uint64_t block_count;
-                int fh = fileno(h);
                 // get number of blocks
                 ret = ioctl(fh, DKIOCGETBLOCKCOUNT, &block_count);
                 if (ret) {
@@ -322,9 +331,22 @@ int hdf_open_target (struct hardfiledata *hfd, const c
                 write_log("osx: found raw device: block_size=%u "
                         "block_count=%llu\n", block_size, block_count);
                 low = block_size * block_count;
-            }
-            else {
-#endif
+#elif defined(__OpenBSD__)
+                struct disklabel label;
+
+                if (ioctl(fh, DIOCGDINFO, &label) < 0) {
+                    write_log("openbsd: can't get disklabel of '%s' (%d)\n", name, fh);
+                    goto end;
+                }
+
+                write_log("openbsd: bytes per sector: %u\n", label.d_secsize);
+                write_log("openbsd: sectors per unit: %u\n", label.d_secperunit);
+
+                low = label.d_secsize * label.d_secperunit;
+                write_log("openbsd: total bytes: %llu\n", low);
+#endif // OpenBSD
+            } else {
+#endif // OpenBSD || MACOSX
             // regular file size: seek to end and ftell
             ret = uae_fseeko64 (h, 0, SEEK_END);
             if (ret)
@@ -332,7 +354,7 @@ int hdf_open_target (struct hardfiledata *hfd, const c
             low = uae_ftello64 (h);
             if (low == -1)
                 goto end;
-#ifdef MACOSX
+#if defined(MACOSX) || defined(__OpenBSD__)
             }
 #endif
             low &= ~(hfd->blocksize - 1);

We can do something similar for the launcher using, for example, ctypes to call ioctl. This would mean that we could get an accurate disk size, which if large, woucl not be checksummed. But first can you tell me what the checksum is used for?


Cheers

[vext01]

Forgot to mention that using the above diff I was above to access the CF card under fs-uae. I actually installed workbench under fs-uae and then booted the CF in a real amiga. Sound good enough to me.

Oddly enough, I was unable to partition the CF under fs-aue. The hdtoolbox said "driver not installed". I had to do the initial partitioning on a real amiga, but then all is well.

[Foul]

you must choose uaehf.device under hdtoolbox

[vext01]

Atleast I can try to define the drive typewhen using uaehf.device, however, I cannot read the drive geometry from the disk:

"drive does not support the SCSI enquiry command"

Also tried emulating a ide device. Disk does not show atall that way...

[FrodeSolheim]

1. I haven't looked at the patch, but will later. See no reason why the OpenBSD stuff shouldn't be added to the official source

2. Before the drive is partitioned, FS-UAE will think it is a "single-partition HDF" file, not a rigid disk block. So until the drive is initialize by AmigaOS, you need to use hard_drive_0_type to tell FS-UAE to treat it like a full-blown disk.

EDIT: oh, and using the default HD controller - and uaehf.device as Foul said - is recommended!

[vext01]

Thanks for the advice frode!

I also have this other diff to prevent the launcher from hanging. I don't know if it is really suitable for general use.... What is checksumming for again? Ioctl() from Python just feels wrong...

$OpenBSD$
--- launcher/fs_uae_launcher/Config.py.orig	Thu Aug  8 21:20:29 2013
+++ launcher/fs_uae_launcher/Config.py	Thu Aug  8 21:22:17 2013
@@ -478,9 +478,15 @@ class Config:
                 # that it isn't supposed to be set..
                 return
             print("checksumming", repr(path))
-            if os.path.getsize(path) > 64 * 1024 * 1024:
+            size = os.path.getsize(path)
+            if size > 64 * 1024 * 1024:
                 # not checksumming large files righ now
                 print("not checksumming large file")
+                return
+            if size == 0:
+                # probably a device node on a BSD system. Could be large.
+                # To reliably get the size we should use ioctl...
+                print("Not checksumming zero sized file")
                 return
             if is_rom:
                 sha1 = checksum_tool.checksum_rom(path)

[FrodeSolheim]

Something like that could work fine for the launcher (and/or just return the pre-calculated SHA-1 for a 0-byte file, so it is correct in that case).

The reason files are checksummed are really because of the net play support, where compatibility validation is done before a game can be started. HDF files does not work with net play anyway, but using zips as HDs can work. The 64 MB limit is really just a hack to avoid checksumming large HDFs since the same code is used for any file selected as hard drive.

All this can be done much more elegantly of course, and I will probably "fix it" in the future. -And media could also be checksummed in the background / on demand only when net play is active, it just takes much more work to do it really nicely -right now it is done "the easy way".

[FrodeSolheim]

The launcher patch is added
EDIT: included in 2.3.4.