Author Topic: bootload.log  (Read 5387 times)

0 Members and 1 Guest are viewing this topic.

Offline bushing

  • Senior Member
  • Needs to get outside.
  • *****
  • Posts: 119
  • props to my peeps
bootload.log
« on: June 21, 2005, 10:58:09 pm »
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]

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

Offline A543

  • Senior Member
  • Veteran.
  • *****
  • Posts: 214
Re: bootload.log
« Reply #1 on: June 22, 2005, 12:14:13 am »
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.

Offline bushing

  • Senior Member
  • Needs to get outside.
  • *****
  • Posts: 119
  • props to my peeps
Re: bootload.log
« Reply #2 on: June 22, 2005, 04:48:53 am »
Quote
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]

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

Offline A543

  • Senior Member
  • Veteran.
  • *****
  • Posts: 214
Re: bootload.log
« Reply #3 on: June 22, 2005, 06:10:37 pm »
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?

Offline bushing

  • Senior Member
  • Needs to get outside.
  • *****
  • Posts: 119
  • props to my peeps
Re: bootload.log
« Reply #4 on: June 22, 2005, 11:08:39 pm »
Quote
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]

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