Re: How to get a new palo source package into unstable?
Hi Thomas,
On 01/14/2014 02:56 PM, Thomas Schmitt wrote:
> it is to early for a new description.
> I have lots of questions after reading
> http://git.kernel.org/cgit/linux/kernel/git/deller/palo.git/tree/lib/common.h
>
> - Will there be a binary template for the first sectors
> of the ISO image into which the struct firstblock shall
> patched ?
Is it needed?
After looking at your code it might be sufficient what you have already.
> - Shall xorriso allow kern_sz = 0 or rd_sz = 0 ?
No. (At least not both = 0)
> - Increment PALOHDRVERSION to 5 ?
Yes, I think we should do that.
For that the new palo should be in the repo though...
> - What to write into cmdline_old ?
If version==5, then you should leave it empty.
Instead write the cmdline to the end of the struct (which allows max. 1023 bytes).
> - How to determine the uncompressed kernel sizes ?
> kern32_native_sz , kern64_native_sz
I think we should not take care of the possibility that
you can feed compressed binaries in there.
Just leave those new fields at zero and use the ones you
already implemented.
My goal is to rewrite the kernel make process so that it
creates a self-extracting kernel image (like other arches do)
so that this logic can go away from palo again.
That said, I think you can leave your code as-is and put in zeroes here.
> - What value to write into flags ?
Seems 0 is OK.
> - How to determine the value of ipl_entry ?
It's the entry point in the IPL (bootloader) code.
It's stored in the ipl file.
I need to take a closer look at that again...
> - What block ranges shall be claimed by how many partitions ?
The partition table is only relevant if the firstblock is on hard disc.
(The same struct is used for tftp-boot, hard-disc boot and CD boot!).
Since you target a bootable CD image it's not relevant and leave it 0.
> - You mentioned a "checksum (required by bios)" but i cannot
> spot a trace of it.
> What checksum algorithm will be used ?
My fault. Checksum is needed for IPL code, not in the firstblock.
Just ignore it...
> -------------------------------------------------------------
> The questions stem from this discussing with myself:
>
>
>> The "magic" number is the assembly-language branch needed to skip over the
>> rest of the structure.
No.
The firmware checks those two bytes.
If they are not 0x80/0x00, then it will not boot from that media.
> To what address does it jump and how does the code get
> there which shall be executed ?
Those fields define what the firmware loads (from where on media(=ipl_addr),
length(=ipl_size) and the offset into the loaded region where it should
jump to(=ipl_entry)):
int ipl_addr; /* offset 0xf0 */
int ipl_size;
int ipl_entry;
ipl_addr needs to be 2k aligned on media.
ipl_size needs to be a multiple of 4k (I think - needs checking).
ipl_entry is offset into that file.
"ipl" is the generic name.
For parisc-linux this is what palo provides ("iplboot" file generated
during make).
> Will the user submit to xorriso a kindof boot block template
> which contains that code at some higher address ?
> (ISO 9660 allows up to 32768 user defined bytes at the start
> of the filesystem.)
>
>
>> * kern_sz = 0 or rd_sz = 0 means no kern or ramdisk respectively.
>
> Shall xorriso allow such values ?
No, I think it should not allow that.
We target a bootable install-image. For that kernel and ramdisk is needed, right?
>> #define PALOHDRVERSION 4
>
> Shouldn't this become 5 now ?
> Version 4 is already used in the ISOs of Debian 4 and 5.
yes.
>> struct firstblock
>> char cmdline_old[128]; /* OLD: Up to 127 bytes of text plus a \0 */
>
> So this is not used any more and should be 0s ?
Yes.
>> unsigned char pad1[0xf0 - 8 - 9 * sizeof (int) - 128];
>
> /Start nagging mode/
>
> I understand this is a file format. But the reader has no means
> to determine the writer's sizeof(int).
> So one will have to fixate the size of the integers rather than
> accommodating the file format to it.
> How about using 4 here, and to declare all applicable variables
> as int32_t resp. uint32_t ?
I would like to change it in the palo code, but if you have a copy
that's ok.
> Do you really need the offsets as signed integers ?
> xorriso will by default put the boot files at low block addresses
> in the ISO. Nevertheless this can be influenced by the user.
> Maybe there are valid reasons to put other files before the
> boot files.
> So xorriso has to test whether the resulting byte offsets exceed
> the field size. Unsigned would double the chance that they fit.
IIRC all files need to be stored inside the first 2GB of the media.
Give me a few days and I will actually test your code and send you
necessary patches (if needed).
Helge
Reply to: