bootload.log

[bushing]

Okay, I got this figured out.  Not exactly earth-shattering, but it's neat to see and will definately come in handy trying to troubleshoot my bootloader hacks.

Create a non-empty file in the PHTSYS volume -- I just copied phatbox.ini, but it doesn't matter as long as it's non-empty and more than a few KB. The bootloader will empty out this file (but keeping the same length), and just write over it with a bootlog.

I then booted, and got:

Code Select Expand

BOOT0-0: OK
BOOT0-1: OK
BOOT0: Successful
BOOT9: Successful
BOOTB: Successful
BOOTF: Successful
BOOT*: Successful

And just to decode this, here's what that indicates:

• BOOT0-0: OK - successfully executed IDE IDENTIFY to read serial and model from drive hardware - if this fails, you get no bootload.log at all
• BOOT0-1: OK - Read in the drive signature sector , Failed: Could not read sector from drive
• BOOT0: Successful - signature verified with drive serial and model, or BOOT0-2: Failed
• BOOT9: verified rc.sh
• BOOTB: verified phatd
• BOOTF: loaded/verified linux (kernel)
• BOOT*: loaded/verified ramdisk

-b

[A543]

Is this strictly a log file or is it referenced by other code? I'm wondering if creating a copy of this and marking it read only would do anything. Assuming that the code that writes it even obeys/looks for the read only attribute.

[bushing]

Is this strictly a log file or is it referenced by other code? I'm wondering if creating a copy of this and marking it read only would do anything. Assuming that the code that writes it even obeys/looks for the read only attribute.

It's strictly a log file, and it doesn't even look at any attributes.

Let's put it this way - the bootloader is like 13k-ish (excluding the RSAREF crypto code, most of which isn't even used.)  That 13k handles initializing the hardware, copying itself into RAM, setting up the IDE controller, finding the partition table, reading it, finding the fat, reading it, then finding some files, and loading them and their signatures, checking them, etc ... its a lot packed into a little space.

The log routine literally looks like this:

Code Select Expand

void init() {
[...]
    initialize IDE adapter
    read partition table.  is it okay? find first partition
    is it FAT32? okay, read bootsector
    find fat location from bootsector
    find root directory location from fat -- store away
[...]
}

void write_bootload_log(char *step, char *status) {
   read root directory
   for each file in root directory:
        is it "BOOTLOAD.LOG"?
        yes : read address of first sector of this file
                 read first sector of file
                 search through file until I find a null (Ascii 0) char
                 write out "step status <null>"
                 return
     if any of the above fails -- give up and return to caller
}

Very simple; nothing more, nothing less.  I know for a fact it's not sophisticated to create a new file (this is why none of you have this bootload.log file), nor is it even smart enough to take an empty file and allocate more space to it (because I first tried a 0-byte file and that didn't work.)

In fact, I'd be surprised if the thing was able to log beyond one 512-byte sector (or maybe 4096-byte cluster? dunno)

It makes sense; if you build a device that's finicky about what it will boot, you need a way of troubleshooting it while you work the bugs out...

No, as far as I can tell, nothing else refers to it.

For the record, I still don't even know what uses all the mystery data before the first partition (other than the drive signature and partition table...)

-b

[A543]

So if I'm understanding what you are saying, this log isn't even generated during normal operations because there is no seed file in place to write to?
It's just a debugging tool?

[bushing]

So if I'm understanding what you are saying, this log isn't even generated during normal operations because there is no seed file in place to write to?
It's just a debugging tool?

Precisely.  Normally, it always "tries" to, fails silently, and continues booting.

FWIW, I tried replacing the drive signature with one I created using plsign, and got this output:

Code Select Expand

BOOT0-0: OK
BOOT0-1: OK
BOOT0-2: Failed