Festplatte trotz Hindernissen auf Watchguard Firebox einbinden

  • Da ich für eine Demo mit einem recht speziellen Rechner (es ist eine Watchguard Firebox 1000) mit Interlink (das interne Flash-Laufwerk ist nur 8MB groß, und das vom Hersteller modifizierte Phoenix BIOS lässt es nicht zu, externe HDDs zu nutzen - stattdessen geht nur ein IDE CD-ROM noch zusätzlich zu nutzen, ist aber wie gesagt eine reine BIOS-Beschränkung) arbeite, suche ich nach Alternativen zu Interlink. Mir fällt da sofort Kirschbaum-Link ein, aber ich finde da auch nach stundenlanger Google-Session nirgends die Software. Hat da jemand ein Tipp dazu?

  • Da ich für eine Demo mit einem recht speziellen Rechner (es ist eine Watchguard Firebox 1000) mit Interlink (das interne Flash-Laufwerk ist nur 8MB groß, und das vom Hersteller modifizierte Phoenix BIOS lässt es nicht zu, externe HDDs zu nutzen - stattdessen geht nur ein IDE CD-ROM noch zusätzlich zu nutzen, ist aber wie gesagt eine reine BIOS-Beschränkung) arbeite, suche ich nach Alternativen zu Interlink. Mir fällt da sofort Kirschbaum-Link ein, aber ich finde da auch nach stundenlanger Google-Session nirgends die Software. Hat da jemand ein Tipp dazu?


    FastLynx


    Besser gehts eigentlich nicht ;)


    Oder eben Norton Commander.

  • Ich suche kein Transfer-Programm, da ich sonst gerne und häufig KERMIT nutze (MSKERMIT für DOS und Kermit-95 für Windows), da wäre ich also, wenn ich so was brauchen würde, schon restlos glücklich.

    Ich brauche ein "Laufwerk" bzw. ein "Laufwerksbuchstaben" für den Client-Rechner, denn da der nur ein 8MB Flash Laufwerk (siehe meinen Beitrag #134) hat, habe ich kein Platz für das Empfangen und Abspeichern von Dateien.

    Da Kirschbaum-Link genau das Gewünschte liefern würde, war das halt mein erster Gedanke. Ich kann aber auch Interlink weiter nutzen, das funktioniert halt nur mit einer FAT12 bzw. FAT16 Partition beim Host, nicht jedoch mit einer FAT32 Partition...

  • Warum bootest du nicht einfach von CF Karte ?


    Wenn ich mich recht erinnere haben die Firebox Dinger einen CF Slot und können da auch Karten mit paar Gb aufnehmen und davon booten.

    Auf so einen Teil hatte ein Betrieb wo ich war damals IPCop laufen.

    совок

  • matze79 - keine Chance. Ich habe zwei Firebox 100, die perfekt funktionieren und auch jede Kombination an Hardware akzeptieren, kein Wunder, die haben noch ein "normales" BAT-Mainboard. Die Firebox 1000 hat *kein* normales PC-Mainboard mehr, sondern eine Art von ITX (nur gab es damals kein ITX) Board. Das "Phoenix BIOS 4.0 Release 6.0 - Diablo 0.20" ist ein vom Hersteller modifiziertes BIOS, was bei den Einstellungen keine Änderung des Bootlaufwerks in Richtung andere, zweite Festplatte erlaubt. Das interne Flash-Laufwerk kann nicht disabled werden und kann auch nicht von Primary auf Secondary gejumpert werden, es ist ja ins Mainboard integriert. Es gibt zwar einen Jumper, der angeblich das erlaubt, aber ich habe fast eine Woche Versuch und Irrtum durchlebt, bis ich aufgegeben habe. Eine Einstellung "Boote von IDE-CD-ROM" und "Primary ist das CD-ROM" geht, ich nehme mal an das war wichtig, um ein Update durchführen zu können. Ich wollte meine Website mit ausführlichen Infos zu den Watchguards mal füttern/die Seiten dort updaten, aber bisher habe ich keine Zeit dazu gefunden. Im classic-computing.de Forum hatte ich dazu auch zuletzt mal was berichtet, aber es bleibt dabei, das auf der Firebox existierende BIOS erlaubt das einfach nicht, egal was Du probierst. Habe auch auf einem anderen Rechner eine CF-Karte mit DOS und auch eine andere CF-Karte mit Linux vorbereitet gehabt, jedesmal wenn man die CF-Karte einsteckt, friert das Teil ein, zumindest wenn man den "Primary IDE" Jumper setzt. Lässt man den weg, läuft zwar der Rechner aber da das BIOS eine HDD-Einstellung des Secondary IDE nicht erlaubt, und jedesmal "NONE" beim Booten zuerst reinschreibt, bleibt es bei dem internen Flash-Laufwerk alleine, oder der Kombination CD-ROM Laufwerk + int. Flash-Laufwerk.

  • Wäre es denkbar, das BIOS mit einem Programmer auszulesen und von einem der Spezialisten für BIOS Mods überarbeiten zu lassen?

    Daily Driver: MSI X470 Gaming Plus - Ryzen 7 1700 - 32 GB - Geforce GTX 1060 6GB - 1 TB NVMe SSD - 2 x 1 TB Raid-0 SATA

    Projekt #1: ASI 486-33 - Projekt #2: PC Chips M912 486 VLB - Projekt #3: Biostar MB8500TVX-A Pentium MMX 166 - Projekt #4: ASUS TXP4 K6-III 400 - Projekt #5: Gigabyte GA-6BXDS Dual Slot 1 PIII-650 -

    Projekt #6: ASUS P2B-DS Dual Slot 1 PIII-1000 - Projekt #7: Gigabyte GA-6VXD7 Dual Sockel 370 PIII-1000 - Projekt #8: TYAN S2505T Dual Tualatin 1400

  • Das Floppy Image kann über einen bootloader mit memdisk (syslinux) auch von anderen Medien geladen werden oder via CD-Boot.

    Das wird bald ein Amiga: Bitte Kickstart Diskette einlegen! :)

    root42 auf YouTube


    80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, GUSar Lite & TNDY & SnarkBarker, PC MIDI Card + SC55 + MT-32, XT CF Lite, OSSC 1.6

  • matze79 - wäre ein Versuch wert, aber ersetzt dann das XTIDE ROM komplett alle entsprechend zum Festplattenzugriff dazugehörigen Routinen, und wenn ja, wie behält man die Einstellungen, wenn diese nicht als Default passend stehen ?


    Edit: Und auf welcher Konstellation führt man denn das "make" durch ? Linux ? Was ist "FASM" (nehme man an ein Assembler) ?


    Edit^2: Ist leider nicht brauchbar, habe den FASM Assembler mal heruntergeladen und es ist letztendlich ein Bootsector, der erzeugt wird (passend zum Ziel-Format der Diskette). Kann ich aber so nicht nutzen, müsste das erst auf den Bootsector des Flash-Laufwerks anpassen, der sieht ja ganz anders aus. Ein Floppy-Laufwerk hat das Gerät ja nicht, das wäre unendlich einfacher.


    Edit^3: Ist so oder so nicht brauchbar, weil hier keine Datei angegeben werden kann bzw. keine Datei vom Dateisystem geladen wird, d.h. das ROM muss einfach schon "da" sein. Kann da aber nichts mehr reinstecken, also auch keine weitere Karte mit ROM.

  • Falsch.


    Für 360Kb Diskette z.B.

    fasm -d bios_drive=0 -d build_date="202109261717Z" -d readblock_retries=7 -d sectors_per_track=9 -d pad_to_bytes=368640 -d include_optrom="xtide.bin" optromloader.asm fd360.img


    optromloader: IBM PC/Clone 8086+ floppy-loading of option roms.
    A few days ago, I burned the wrong image into my last EPROM, and was left unable to get XTIDE Universal BIOS working on my 486. At least until I get an eprom…
    forum.vcfed.org


    Sollst du ja auch gar nicht, du lädst das Floppy Image über einen Bootloader von deinen 8Mb Flash.

    Stichwort: memdisk, grub4dos etc.

    Dann kannst du vom CD-ROM Port bzw internen CF Slot die CF über XTIDE starten.

    Ein Floppy Laufwerk ist gar nicht nötig.

    Das XTIDE wird dann nur mit dem IDE Port configuriert über xtidecfg an dem die CF-Karte hängt und erkennt das dann als Hauptlaufwerk.


    Zum testen tut es auch erstmal eine CD-RW.

    Wie man eine Bootbare CD brennt sollte ja kein Thema sein.

  • matze79 ... kapier' ich nicht. Da auch kein Floppy-Laufwerk vorhanden ist, müsste ich ja erstmal eine Option für einen Bootsektor des Flash-Laufwerks haben, ein Bootsektor für eine 360KB Diskette nützt mir ja nichts. Könnte ich maximal von der CD mit Floppy-Boot-Emulation machen. Aber dann bräuchte ich ja dauerhaft das CD-ROM angeschlossen. Und woher wird denn das Option ROM geladen ... es wird dann trotzdem *nicht* vom Dateisystem geladen, sondern es wird einfach die ROM-Signatur im Speicher gesucht.

  • Peter z80.eu Darum schlägt Matze vor, den Bootsektor von deinem Flashdrive zu laden. Das mit dem Floppy war nur ein Syntaxbespiel von irgendwoher, das abgepasst werden muss. Ohne es zu kennen: Das Abbild vom Option ROM wird dann wohl hinter dem Bootsektor lokalisiert sein, außerhalb des Dateisystems.

  • H.EXE - habe mir nochmal den Assembler-Quellcode angeschaut.


    In Register CX steht die ROM-Länge (für den LOOP Befehl weiter unten wichtig):


    mov ah,0

    mov al,[bootblock_end+2] ;load length from ROM header

    mov di,ax ;save length (blocks) into DI

    [...]

    ;*** Read ROM image

    mov si,readblocks_str

    call printstr

    xor dx,dx ;block to read; will become 1 before reading

    mov cx,di ;recover ROM length (blocks) from DI

    cmp cl,255 ;set CF if CL under 255

    sbb cx,-1 ;add 1 if CF is set. Thus the 255 case becomes 256

    xor bx,bx ;target address

    .readrom:

    ;hlt ;delay for debugging

    inc dx ;increase target block. Needs to be 16bit, as image starts at 1

    mov ax,dx ;block to seek to and read

    call printhex16 ;block

    call readblock

    add bx,512 ;next target address += 1 blocksize

    jcc8086 jnc,.same_segment

    mov ax,es ;get segment

    add ax,$1000 ;64KB forward, in segment terms

    mov es,ax ;set new segment

    .same_segment:

    mov si,readblocksbs_str

    call printstr

    loop .readrom ;loop if there's still blocks left to read

    [...]

    readblock: ;AX blockno, [ES:BX] dest, trashes AX (reserved, retval)

    push cx ;preserve CX

    push dx ;preserve DX

    push di ;preserve DI

    ;*** CHS magic

    ;tracks>>1 is cyl, tracks&1 is head

    mov dl,sectors_per_track ;get number of tracks

    div dl ;ax/dl -> /al, %ah

    mov dh,1 ;tracks&1 is head

    and dh,al ;CHS head 0..15 (0 or 1 for floppy)

    shr al,1 ;tracks>>1 is cyl

    ;CX 0-5 sector, 6-7 cyl MSB, 8-15 cyl LSB

    mov ch,al ;CHS cyl LSB.

    inc ah ;CHS sectors start at 1

    mov cl,ah ;CHS sector in LSB, cyl MSB (zero) in MSB

    mov ah,02h ;BIOS 13h read CHS block

    mov al,1 ;sectors to read 1..128

    mov dl,bios_drive ;drive 0=A 80h=hdd0

    mov di,readblock_tries ;how many read attempts before giving up


    D.h. im Prinzip hast Du Recht, er lädt die Datei sektorenweise nach, mir ist nur nicht klar, wo die Länge (hier: bootblock_end) definiert ist - muss wohl als DEFINE beim Assemblieren von aussen kommen.

    Und natürlich darf nur und ausschließlich auf einer vorher komplett leeren Diskette die ROM-Datei abgelegt werden, und zwar als einzige Datei. Die FAT12/FAT16-Bereiche dürfen auch nicht überschrieben werden.

    Aber die ganze Logik ist auf eine Floppy abgestimmt, nicht auf ein Flash-Memory-Laufwerk. Und das ist auch nicht leer. Also geht das leider doch nicht, auch nicht nach einer Anpassung der Disk-Parameter. Da müsste ich die Logik ändern so dass der an einer von mir herauszufindenden Stelle anfängt Sektoren zu lesen. Aber nicht gleich am Anfang der Platte.


    Edit: https://lowlevel.eu/wiki/File_Allocation_Table zeigt Dir, wie kompliziert eine Logik ist, die eine (bestimmte) Datei nachladen müsste. Das kannst Du voll vergessen, passt 100% nicht in einem Bootsektor. Man müsste also zuerst ein weiteres Programm nach dem Bootsektor sektorenweise nachladen, was das leistet. Mir zu kompliziert, da kann ich gleich DOS neu schreiben.

  • Peter z80.eu Wie ich das verstanden habe:


    Da er das ROM-Image sektorenweise liest und nicht als Datei aus einer FAT-Partition, müsste nach dem MBR (Block 0 = 0 Byte Offset) direkt das ROM-Image (Block 1 = 512 Byte Offset und ff.) kommen und nach [bootblock_end+2] Bytes + Padding soll erst die 1. Primäre FAT-Partition anfangen, also Partitionstabelle händisch bearbeiten und 1. Partition neu formatieren. Nichts mit Disketten oder Dateien.


    Aber ohne Gewähr, es gibt sicherlich eine Doku.

  • matze79 ... kapier' ich nicht. Da auch kein Floppy-Laufwerk vorhanden ist, müsste ich ja erstmal eine Option für einen Bootsektor des Flash-Laufwerks haben, ein Bootsektor für eine 360KB Diskette nützt mir ja nichts. Könnte ich maximal von der CD mit Floppy-Boot-Emulation machen. Aber dann bräuchte ich ja dauerhaft das CD-ROM angeschlossen. Und woher wird denn das Option ROM geladen ... es wird dann trotzdem *nicht* vom Dateisystem geladen, sondern es wird einfach die ROM-Signatur im Speicher gesucht.

    Nein brauchst du nicht.


    Du brauchst auf deiner 8Mb Flash Disk -> Grub4dos und memdisk sowie das Image des XTIDE Optloaders.


    memdisk erlaubt es floppy images als RAM Laufwerk zu starten (Floppy Emulation)


    MEMDISK - Syslinux Wiki


    In die Config von Grub4DOS kommt dann z.B.:

    Code
     title cfcard
       kernel /memdisk
       initrd /xtide.img

    So kann man z.B. auch alle DOS Versionen Parallel nutzen ;)

  • Na das bedingt auf jeden Fall erstmal die Zerstörung des bisherigen Inhalts des Flash-Laufwerks, aber ich schau mir mal grub4dos mit memdisk genauer an, wenn ich das gemacht habe, melde ich mich nochmal...


    Edit: Verstehe noch nicht, ob und wie ich grub4dos oder zuerst memdisk auf die 8MB Partition bringe, und ob ich dann übriggebliebenen Rest des Flash-Laufwerks noch nutzen kann, oder ob das mit grub4dos und memdisk komplett belegt ist.

  • Ok, habe das Ganze mal versucht in 86Box zu testen. Ja, mit "memdisk" als Kernel bei Grub4DOS kann man tatsächlich von einem Diskettenimage booten, allerdings habe ich das "make" auf https://github.com/rvalles/optromloader bisher noch nicht ausführen können, weil ich momentan keinen Linux-Rechner zur Hand habe (es gibt aber auch Live-CDs, ich weiß).

    Vielleicht kannst Du matze79 mir auch mal eine fertige Boot-Diskette mit ide_386.bin als "optrom.bin" (im make Verzeichnis) erzeugen - im 360KB Diskettenformat wird zum Test reichen.


    grub4dos ist etwas blöde, weil der Eintrag "title back to dos" und "quit" dazu führt, dass man in der CONFIG.SYS der Platte keine Treiber laden kann (wird alles übersprungen, lädt dann direkt die AUTOEXEC.BAT), aber na ja, vielleicht kann man nicht alles erreichen.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!