Re: Custom boot loader stub

[Sad Clouds <cryintothebluesky%gmail.com@localhost>]

On Thu, 16 Oct 2025 12:45:15 +0200
Martin Husemann <martin%duskware.de@localhost> wrote:

> On Thu, Oct 16, 2025 at 01:32:39PM +0300, Valery Ushakov wrote:
> > On Wed, Oct 15, 2025 at 08:24:05 +0100, Sad Clouds wrote:
> > 
> > > 2. Binary format
> > > 
> > > Some information I've read states that the binary OpenBoot loads must
> > > be in the old a.out format. This may have been the case for older
> > > 32-bit sparc hardware, but for sun4u/sun4v does anyone know if OpenBoot
> > > also supports elf32 or elf64 formats?
> > 
> > From a sparc64 nfs root:
> > 
> > $ file /export/root/aurinko/usr/mdec/ofwboot
> > /export/root/aurinko/usr/mdec/ofwboot: ELF 64-bit MSB executable, SPARC V9, relaxed memory ordering, version 1 (SYSV), statically linked, not stripped
> 
> Just curious - this is loaded via the primary boot block (from
> src/sys/arch/sparc/stand/bootblk/bootblk.fth) from the proper partition
> and file system, and evaluate'd, but would it also work (if small
> enough and what have you) as primary boot block?
> 
> My guess is: yes - but I don't really know.
> 
> Martin

Hi Valery + Martin,

I've been digging into this and as far as I understand:

1. OpenBoot first loads bootblk from the second sector on boot disk.
ChatGPT tells me this must be a flat binary, as ELF32/ELF64 are not
supported by OpenBoot. Also OpenBoot runs in 32-bit mode, so bootblk
must be 32-bit code?

2. The bootblk then loads ofwboot, which can be any format, including
ELF64. I am primarily interested in bootblk, which is the primary boot
loader and is executed directly by OpenBoot.

The layout of blocks on disk should look like this:

        1                 2 - 8           => 512-byte sector/block numbers
+----------------+---------------------+
| Sun Disk Label | bootblk flat binary |
+----------------+---------------------+
 0            511 512              8191   => LBA offsets in bytes


The first sector (1) is occupied by Sun disk label, which is padded to
512 bytes. This must have the correct magic value, etc, otherwise
OpenBoot reports errors.

Sectors 2 - 8 contain bootblk binary, which can be maximum 7.5 KiB in
size. Although I'm not sure how OpenBoot figures out its size so it can
correctly map text and data segments in memory for execution.

I'm reading IEEE Draft Std P1275.1/D14a which covers boot firmware and
it talks about specific header fields which are parsed by OpenBoot and
seem to be in a.out format: bf_magic, bf_text, bf_data, bf_bss, etc.
However I wonder if this documentation refers to obsolete OpenBoot
firmware, which is no longer relevant to sun4u/sun4v?

I think once I finish developing a small utility to generate a fake Sun
disk label, I will then try various binary formats and see which one is
executed correctly by OpenBoot.