Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64
On 25/04/2019 12:58, Thomas Schmitt wrote:
> Hi,
>
> John Paul Adrian Glaubitz wrote:
>> I have read the genisoimage manpage and I have to admit, I haven't fully understood
>> yet how it is supposed to work. It seems we have to specify the bootloader code
>> with -G, thus -G cdboot.img. But -B is apparently used to pass a whole directory
>> name which means I don't understand how genisoimage knows which is the second stage bootloader.
>
> Dumping here what i learned when Vladimir Serbinko told me how to
> do it with xorriso underneath grub-mkrescue:
>
> libisofs/doc/boot_sectors.txt has:
> =========================================================================
> GRUB2 SUN SPARC Core File Address
>
> Sources:
> Mail conversations with Vladimir Serbinenko.
>
> GRUB2 lets libisofs write after the disk label block the address and size of a
> data file in the ISO image. E.g. of /boot/grub/sparc64-ieee1275/core.img.
> This is combined with a SUN Disk Label which exposes only the single partition
> describing the overall ISO filesystem size.
>
> Byte Range | Value | Meaning
> ------------ | ---------- | --------------------------------------------------
> 512 - 551 | opaque | Code and data provided by GRUB2
> | |
> 552 - 559 | offset | Start byte number of the file. 64-bit big-endian.
> | |
> 560 - 563 | size | Number of bytes in the file. 32-bit big-endian.
> | |
> 564 - 32767 | opaque | Code and data provided by GRUB2
> | |
> ------------ | ---------- | --------------------------------------------------
>
> =========================================================================
> (There is a section "SUN Disk Label and boot images for SUN SPARC" before
> that special GRUB description.)
>
> man xorrisofs:
> =========================================================================
>
> -B disk_path[,disk_path ...]
> Cause one or more data files on disk to be written after the end
> of the ISO image. A SUN Disk Label will be written into the
> first 512 bytes of the ISO image which lists this image as
> partition 1 and the given disk_paths as partition 2 up to 8.
> The disk files should contain suitable boot images for SUN SPARC
> systems.
> The pseudo disk_path "..." causes that all empty partition
> entries become copies of the last non-empty entry. If no other
> disk_path is given before "..." then all partitions describe the
> ISO image. In this case, the boot loader code has to be imported
> by option -G.
>
> =========================================================================
>
> util/grub-mkrescue.c does
> =========================================================================
>
> if (source_dirs[GRUB_INSTALL_PLATFORM_SPARC64_IEEE1275]
> && system_area == SYS_AREA_SPARC)
> {
> ...
> xorriso_push ("-G");
> xorriso_push (sysarea_img);
> xorriso_push ("-B");
> xorriso_push (",");
> xorriso_push ("--grub2-sparc-core");
> xorriso_push ("/boot/grub/sparc64-ieee1275/core.img");
>
> =========================================================================
>
> The mkisofs emulation option --grub2-sparc-core does the stuff described
> in boot_sectors.txt.
This is a great summary! I can almost see how this works, the last piece in the
puzzle is to correlate it with what is in boot.S and diskboot.S.
What I believe should be happening is this:
- the first 32K of an ISO9660 is undefined so that a partition table can be added
for multi-format disks such as this
- boot.S and diskboot.S get built into cdboot.img (see
https://www.gnu.org/software/grub/manual/grub/html_node/Images.html for the breakdown
of grub components) which
is an a.out executable that can be loaded/executed by the PROM
- the main grub executable gets built as core.img and is included in the ISO9660
image at /boot/grub/sparc64-ieee1275/core.img
- grub should run xorisso with the following parameters:
-G cdboot.img -B "..." --grub2-sparc-core /boot/grub/sparc64-ieee1275/core.img
- what this effectively does is:
- Install a sun partition disk label to sector 0 of the ISO image
- Add the ISO9660 image as the first partition (slice)
- Create all 7 remaining partitions after the ISO9660 image
- These partitions are all small and just contain cdboot.img
- Create a special sector 1 as per above containing the offset and size of
core.img *within the ISO9660 partition* from the start of the image in bytes
This gets us to the point where the PROM can read cdboot.img and start executing it,
so far so good.
The two parts I'm still not exactly sure about:
1) How does boot.S/diskboot.S locate core.img?
>From what I can see boot.S uses the "bootpath" property as the name of the device to
open but in the example device trees I have here, this also includes the slice e.g.
"cdrom:a". This means that when the PROM opens the disk in boot.S, it is directly
opening the partition containing cdboot.img rather than the start of the whole disk -
given that the offset and size of core.img is placed in sector 1 by
--grub2-sparc-core rather than in the partition containing cdboot.img then I can't
see how this works?
Moving into diskboot.S I *think* what happens is that the layout of sector 1 directly
matches the bootlist structure with a single offset/length entry representing
core.img, but it's not particularly clear.
2) How to launch xorisso with the correct parameters?
Presumably we need to correct incantation of grub-mkinstall to make this happen, but
I couldn't quite figure out how this works. I can see above how some logic is
embedded in grub-mkrescue.c but not how this works from grub-mkinstall.c?
ATB,
Mark.
Reply to: