Boot & Initialization of Proto_Sys V1.00

[TightCoderEx]

This is the humble beginnings of what will eventually be a comprehensive X86 prototyping system. This screen shot is what I have to-date and I'm interested if my design intent does work. So far, I've tested it on Lenovo ThinkCenter, Dell OptiPlex GX1 and BOCH's. My intention is to be able to start on a 386 with a low density drive, therefore only 8 sectors of track and head zero are read in.

Code was written for NASM 2.11.08, but I believe if "%" is removed from includes, it will also assemble with FASM or MASM

1: What I'd like to know if the system will start on HD/USB/SD



Register content is only for interests sake, but I have been watching for CS in right column to be 7C0 which would be a sign of one of those quirky BIOS.

A20 Line is GREEN if gate was already active
YELLOW fast A20 gate method succeeded
RED failed and some other method will have to be implemented in boot code

E820 shows Base Address & entry length to 48 bits. Display is centered about line 13, so if there are any maps more than 24 entries, I'll have to rework in some manner.

Zip file has all sources and there is also ProtoS.img which is a 3 sector image that can be copied directly to media. I haven't had any problems with this code, but then again, without isolating critical media, I wouldn't test it on my development system.

[TightCoderEx]

I've tested image on USB & HD. I was surprised on Lenovo ThinkCenter that USB is passed to loader as a floppy. Therefore, I'm expecting some sort of error if I try reading USB beyond 2.8 meg

I've added this snippet at line 62 of boot.asm as at this point all registers are volatile except SS, SP & BP, so I don't have to worry about any implications downstream.

Code: Select all

; =============================================================================================
; Determine SMBIOS structure table entry point and save 32 bit address. 

;       LEAVE:  SMBIOS_PNTR = 32 bit pointer to table or -1 if not found
; ---------------------------------------------------------------------------------------------

   Find_SMBIOS:
        mov     ax, 0xf000
        mov     ds, ax                  ; Segment where table lives
        xor     bx, bx                  ; Initial pointer
        mov     eax, '_SM_'             ; Scan buffer for this signature

    ; Loop has maximum of 4096 interations. As table is probably at top of buffer, cycling
    ; though it backwards saves time. In my test bed, BOCH's 2.6.5 BIOS-bochs-latest it was
    ; 1,451 interations.
        
   .L0: sub     bx, 16                  ; Bump pointer to previous page
        jz      Read_Disk               ; ZF = 1, Signature was not found, SMBIOS_PNTR = -1
        cmp     [bx], eax
        jnz     .L0
        
    ; Construct a 32 bit address in ECX from DS:BX
    
        mov     cx, ds
        shl     ecx, 4
        mov     cx, bx
        mov     [SMBIOS_PNTR], ecx      ; Write 32 bit address to scratch area

[Brendan]

Hi,

I've tested image on USB & HD. I was surprised on Lenovo ThinkCenter that USB is passed to loader as a floppy. Therefore, I'm expecting some sort of error if I try reading USB beyond 2.8 meg

It'd be interesting to test this theory. Depending on how the firmware felt like doing CHS->LBA for the device (and assuming there's no BPB influencing the firmware), the limit might "63 sectors * 256 cylinders * 256 heads * 512 bytes per sector = about 2 GiB".

It'd also be interesting to see if the BIOS changes its mind (and decides the USB is a hard disk) if there's a partition table on the USB.


Cheers,

Brendan

[Octocontrabass]

Depending on how the firmware felt like doing CHS->LBA for the device (and assuming there's no BPB influencing the firmware), the limit might "63 sectors * 256 cylinders * 256 heads * 512 bytes per sector = about 2 GiB".

The limits are 255 heads and 1024 cylinders; that's about 7.8GiB. I've never tried altering the BPB, or if I did I don't remember the results, so I can't tell you what happens there.

It'd also be interesting to see if the BIOS changes its mind (and decides the USB is a hard disk) if there's a partition table on the USB.

As long as the BIOS doesn't require the user to manually choose the emulation mode, it will do this. The real trick is giving it a satisfactory partition table.

[Brendan]

Hi,

Depending on how the firmware felt like doing CHS->LBA for the device (and assuming there's no BPB influencing the firmware), the limit might "63 sectors * 256 cylinders * 256 heads * 512 bytes per sector = about 2 GiB".

The limits are 255 heads and 1024 cylinders; that's about 7.8GiB. I've never tried altering the BPB, or if I did I don't remember the results, so I can't tell you what happens there.

For "int 0x13, AH=0x02"; for hard drives the highest 2 bits of the (10-bit) cylinder number are stored in CL (giving a limit of 1024 cylinders for hard drive), while for floppy they are not (giving a limit of 256 cylinders for "floppy").


Cheers,

Brendan

[TightCoderEx]

It'd also be interesting to see if the BIOS changes its mind (and decides the USB is a hard disk) if there's a partition table on the USB.

To that end, I suspect there may be a flaw in my design by not implementing a BPB . At 15H, the BIOS is expecting to see a media descriptor and probably for USB should be EFH Super Floppy, but instead it reads 0. I will make this a priority as I think those that are interested are far more likely to be booting real hardware from USB/SD than floppy.

I've just reformatted my 512 meg SanDisk and it shows F5H (Fixed disk, 2 heads, double sided, 12 sectors / track). My guess is BIOS will return as type 80H.

[TightCoderEx]

On Lenovo ThinkCenter, it did not make any difference. DL came back as floppy. I've enclosed an image that can be used without altering existing contents of BPB

?>debug
-l 100 0 0 1 Read boot sector
-e 101 3e Change jump offset to 0x40 instead of 0x3E
-n protos.img Point to file
-l 140 Overwrite contents of memory starting @ 0x40

change media or whatever you need to do

-w 100 0 0 3 Writes image to floppy

[Brendan]

Hi,

On Lenovo ThinkCenter, it did not make any difference. DL came back as floppy. I've enclosed an image that can be used without altering existing contents of BPB

I'm not too sure what happened to this disk image; but the "bootable marker" (0xAA55) isn't where it should be (at the end of the sector):

Code: Select all

000001b0  90 90 90 90 90 90 90 90  90 ea 00 00 8a 00 55 aa  |..............U.|
000001c0  8c c8 8e d8 8e c0 b8 03  00 cd 10 6a 02 68 1e 02  |...........j.h..|
000001d0  68 60 02 e8 ee 00 6a 04  68 0a 05 50 e8 e5 00 89  |h`....j.h..P....|
000001e0  c6 bb 0f 00 b8 00 02 ba  09 05 cd 10 b8 cd 09 b9  |................|
000001f0  1b 00 cd 10 bf b3 02 ba  0a 08 8d 5e fe ad 83 f8  |...........^....|

The first 2 entries of the partition table would decode as:

Code: Select all

Partition 1:
    Status = 0x55 = INVALID
    Starting CHS: head = 0xAA, sector = 0x0C, cylinder = 0x2C8
    Partition type = 0x8E
    Ending CHS: head = 0xC0, sector = 0x38, cylinder = 0x203 = INVALID (end before start)
    Starting LBA = 0xCD0003B8
    Number of sectors = 0x10CD0003 = 0x68026A10

Partition 2:
    Status = 0x1E = INVALID
    Starting CHS: head = 0x02, sector = 0x68, cylinder = 0x160
    Partition type = 0x02
    Ending CHS: head = 0xE8, sector = 0x2E, cylinder = 0x300
    Starting LBA = 0x0A68046A
    Number of sectors = 0xE5E85005 = INVALID (overlaps with LBA+size of first partition)

I didn't decode the other 2 entries, but they don't look like sane partition table entries either.

The BPB is harder to decode (as there's multiple versions of it and half the fields are for FAT only and not used by anything else), but it begins with "Bytes per sector = 0xC000".

Basically; the "bootable marker" isn't present, the partition table doesn't look valid, and the BPB doesn't look valid. Under those conditions; a good BIOS shouldn't attempt to boot it at all, and everything else won't know if it should treat it as floppy (because there's no partition table) or as hard disk (because there's no BPB).


Cheers,

Brendan

[TightCoderEx]

Hi Brendan:

The enclosed image has the first 64 bytes striped from it. Therefore it needs to be loaded starting @ 0x40 and that way the boot signature and everything else will be in the right place. This is why in DEBUG;

-nprotos.img
-l 40

Im not familiar how to do the same thing with DD.

Most boot loaders branch to 7c3e, so the two options are to bump the jump to 3E instead of 3C, or write two NOPs at 3E and 3F.

I did this so however the media your using was formatted the BPB wouldn't be altered.