Re: How to get a new palo source package into unstable?
Hi Thomas,
On 01/14/2014 10:46 AM, Thomas Schmitt wrote:
> i am the developer of xorriso, which meanwhile replaced genisoimage
> for the ISO image production of most architectures by debian-cd.
>
> Are there plans to produce new bootable ISO images for hppa ?
YES, I do have that plan.
> If so, will it be done by debian-cd ?
No idea.
> If so, are you willing to give xorriso a try ?
SURE!
> Steve McIntyre will probably be glad to switch away from genisoimage
> once more in debian-cd. But we'd need a successful test report.
>
> I have now reverse-engineered genisoimage/boot-hppa.c and verified
> my findings with the images debian-40r5-hppa-businesscard.iso
> and debian-508-hppa-businesscard.iso.
>
> ------------------------------------------------------------------------------
> This is what i figured out for libisofs/doc/boot_sectors.txt.
> Please correct me if i'm wrong:
>
>
> HP-PA via PALO
> for HP PA-RISC
>
> Sources:
> cdrkit-1.1.10/genisoimage/boot-hppa.c
> by Steve McIntyre <steve@einval.com>
> who states "Heavily inspired by palo"
>
> There are five parameters which get encoded into the first 248 bytes of the
> System Area: cmdline, bootloader, 32-bit kernel, 64-bit kernel, and ramdisk.
> They are all mandatory.
> While cmdline is simply a string of at most 127 characters, the other four
> point to data files inside the ISO image.
>
> All numbers are recorded big endian.
>
> Boot sector components:
Please take a look at the latest palo bootloader:
http://git.kernel.org/cgit/linux/kernel/git/deller/palo.git/
I changed a few things to make it more extensible.
Especially look at "struct firstblock" in
http://git.kernel.org/cgit/linux/kernel/git/deller/palo.git/tree/lib/common.h
> Byte Range | Value | Meaning
> ---------- | ---------- | ----------------------------------------------------
> 0 - 1 | 0x8000 | Magic
> 2 - 5 | "PALO" |
> 6 - 7 | 0x0004 | Version
> | |
> 8 - 11 | kern32_adr | Byte address of the "HPPA 32-bit kernel" file
> | | genisoimage option -hppa-kernel-32
> 12 - 15 | kern32_len | Byte count of the "HPPA 32-bit kernel" file
> | |
> 16 - 19 | ramdsk_adr | Byte address of the "HPPA ramdisk" file
> | | genisoimage option -hppa-ramdisk
> 20 - 23 | ramdsk_len | Byte count of the "HPPA ramdisk" file
> | |
> 24 - 141 | cmdline | "Command line"
> | | genisoimage option -hppa-cmdline
^^ that changed!
> | |
> 232 - 235 | kern64_adr | Byte address of the "HPPA 64-bit kernel" file
> | | genisoimage option -hppa-kernel-64
> 236 - 239 | kern64_len | Byte count of the "HPPA 64-bit kernel" file
> | |
> 240 - 243 | bootld_adr | Byte address of the "HPPA bootloader" file
> | | genisoimage option -hppa-bootloader
> 244 - 247 | bootld_len | Byte count of the "HPPA bootloader" file
I added fields for compressed images...
IPL entries are missing.
A checksum (required by bios) is missing (need to look again!).
> | |
> ---------- | ---------- | ----------------------------------------------------
>
> ---------------------------------------------------------------
>
> Some open questions remain.
> Is there boot firmware documentation available ?
It's somewhere on
http://parisc-linux.org/documentation/index.html
Format is somewhere in the docs below
"PA-RISC 1.1 Architecture Specifications"
I think.
> Any official terminology to respect ?
> What is due to HP-PA firmware specs, what is due to PALO ?
What do you mean by that?
> Especially i wonder whether it is really necessary to have all
> four files: kernel-32, kernel-64, bootloader, ramdisk
> or whether it would be ok to set address and length of e.g. kernel-64
> to 0 in order to indicate that the image does not have a 64 bit kernel.
If you don't include a 32- *and* 64bit kernel, it will not be a generic
installation cd. Some machines don't boot 32bit kernels and vice versa.
The palo bootloader chooses the right kernel to boot automatically.
> (genisoimage throws exit_fatal(...) if there is none in the ISO.
> So libisofs currently insists in seeing all four files if any
> of them or the command line is given.)
>
> ---------------------------------------------------------------
>
> The -hppa-* functionality of genisoimage is now implemented in
> xorriso.
>
> Uploaded as
> http://www.gnu.org/software/xorriso/xorriso-1.3.5.tar.gz
> MD5 caad39471f76dd0df224d5a7dc4688c1
>
> Build it by
> cd xorriso-1.3.5 ; ./configure ; make
> It is then executable without "make install" as
> ./xorriso/xorriso
I'll test.
> The following test mock-up delivered a plausible first sector for me:
>
> mount -o loop debian-508-hppa-businesscard.iso /mnt
>
> # Learn about the used mkisofs options
> view /mnt/.disk/mkisofs
>
> # Use them with xorriso's mkisofs emulation
> xorriso -as mkisofs \
> -r -V 'Debian 5.0.8 hppa Bin-1' \
> -o debian-508-hppa-repack.iso
> -hppa-cmdline '0/vmlinux initrd=0/ramdisk' \
> -hppa-kernel-32 install/vmlinux-2.6.26-2-parisc \
> -hppa-kernel-64 install/vmlinux-2.6.26-2-parisc64 \
> -hppa-bootloader install/iplboot \
> -hppa-ramdisk install/initrd.gz \
> /mnt
>
> (I left out the many Jigdo options. They should work too.)
>
> Now i wonder whether debian-508-hppa-repack.iso would boot.
Don't think so.
At least not yet.
> ---------------------------------------------------------------
> man "xorrisofs" describes the mkisofs emulation and now says:
>
> -hppa-cmdline text
> Set the PALO command line for HP-PA. Up to 127 characters are
> permitted.
127 is too less. We need more. Fixed in new palo (and new header).
> Note that if one of the -hppa options is given, then the other
> four must be given with valid parameters, too.
>
> -hppa-bootloader iso_rr_path
> Designate the given path as HP-PA bootloader file.
>
> -hppa-kernel-32 iso_rr_path
> Designate the given path as HP-PA 32 bit kernel file.
>
> -hppa-kernel-64 iso_rr_path
> Designate the given path as HP-PA 64 bit kernel file.
>
> -hppa-ramdisk iso_rr_path
> Designate the given path as RAM disk file.
>
> Please correct me if i stated it wrongly.
But basically looks good.
>
> (iso_rr_path is the Rock Ridge address of a file object in the ISO image.
> I.e what you will see when the ISO image gets mounted by Linux.
> This coincides with the semantics of genisoimage where that would work
> at all ... cough.)
>
> Thomas
I'll give it a try and let you know.
Helge
Reply to: