Large sized boot logos can prevent booting.

[idefix]

Recent anyboot nightlies (burned to cdrom) reboot immediately after loading the bootimage (dots appearing). Holding shift won't get it to the boot options. There is no serial output.

• hrev38882 (​haiku-nightly-r38882-x86gcc2hybrid-anyboot.zip) boots fine.
• hrev38892 (​haiku-nightly-r38892-x86gcc2hybrid-anyboot.zip) reboots immediately after all the dots appeared.

Probably caused by changeset:38890 and/or changeset:38891.

Note, see #comment:9

[phoudoin]

Damned. Does it happends too with gcc4hybrid anyboot?

[vooshy]

occurs with gcc2hybrid 38892 cd iso also

[idefix]

Replying to vooshy:

occurs with gcc2hybrid 38892 cd iso also

Yup, ​haiku-nightly-r38882-x86gcc2hybrid-cd.zip boots fine, while ​haiku-nightly-r38892-x86gcc2hybrid-cd.zip reboots immediately.

[idefix]

Replying to phoudoin:

Damned. Does it happends too with gcc4hybrid anyboot?

No, ​haiku-nightly-r38892-x86gcc4hybrid-anyboot.zip boots fine.

Very strange...

[phoudoin]

Could it be an issue with haiker_loader size, the development boot splash image is quitte bigger than the release one (and way bigger than the 1x1 one for non official build ;-) )

But that won't explain that gcc4 anyboot is not affected.

[idefix]

Well it's definitely a gcc2 issue.

​haiku-nightly-r38892-x86gcc4-anyboot.zip also boots fine, while ​haiku-nightly-r38892-x86gcc2-anyboot.zip reboots immediately.

[phoudoin]

for info, gcc4's haiker_loader is 297kb. As the boot archive image offset is set to 300kb, I feel some size limit issue here.

[phoudoin]

I'm thinking to modify BuildFloppyBootImage1 actions to fail when haiku loader size is greater than ARCHIVE_IMAGE_OFFSET kb, which will at least make this case detected earlier, by BOM.

A smart solution will be to *compute* at build time this offset. But I'm not Jam fluent enough to see how to do that in correct order: both boot loader and tarfs add-on needs this info at build time, way before haik_loader is built and BuildFloppyBootImage1 called... Or at least that what I understood so far.

[phoudoin]

I've added the size sanity check in BuildFloppyBootImage1 in hrev38945.

[phoudoin]

And update for a more compact (and less *redish*) boot splash image for development build in hrev38946.

[phoudoin]

Since hrev38945, the anyboot/iso image build will failed if haiku_loader size can't fit in HAIKU_ARCHIVE_IMAGE_OFFSET, which prevents building broken boot image, whatever the reason for haiku_loader being too large (the most obvious reason being boot splash image size, indeed).

May I suggest we change this ticket into an enhancement one to research a way for build system to automatically compute the best image offset fitting under total image size constraint?

[bonefish]

Replying to phoudoin:

A smart solution will be to *compute* at build time this offset. But I'm not Jam fluent enough to see how to do that in correct order: both boot loader and tarfs add-on needs this info at build time, way before haik_loader is built and BuildFloppyBootImage1 called... Or at least that what I understood so far.

It seems the linker script for the boot loader already defines a symbol _end (should really have a better name and definitely two underscores) for the aligned end of the code, so it should be rather simple to get the code size from within the boot loader. No jam/build magic needed.

[phoudoin]

Replying to bonefish:

It seems the linker script for the boot loader already defines a symbol _end (should really have a better name and definitely two underscores) for the aligned end of the code, so it should be rather simple to get the code size from within the boot loader. No jam/build magic needed.

Would be smart, indeed. The archive could be just added right after haiku_loader. In order to do that, I guess I must modify tarfs to get haiku_loader end and compute the archive offset itself instead of the hardcode kFloppyArchiveOffset ? Or did I miss something?

[bonefish]

Replying to phoudoin:

Would be smart, indeed. The archive could be just added right after haiku_loader. In order to do that, I guess I must modify tarfs to get haiku_loader end and compute the archive offset itself instead of the hardcode kFloppyArchiveOffset ? Or did I miss something?

Nope, that's the way to do it. Defining kFloppyArchiveOffset could probably be as simple as:

extern uint8 _end;
static const uint32 kFloppyArchiveOffset = (uint32)(addr_t)&_end;

[phoudoin]

While it doesn't fix definitively the issue, the switch done in hrev40215 to zlib-compressed boot splash images reduces haiku_loader size by some factor.

[phoudoin]

There will *always* a limit to boot splash images, but since hrev40215 way larger/complex images can now be used. As these images should accomadates low screen resolution, this should give enough freedom now for more complex boot splash images.

So, I consider the main issue resolved. It could always be reopened in the future...

[vooshy]

did anyone implement what was written in comment 17 & 16 - as I thought this would have also resolved the issue.

[phoudoin]

Replying to vooshy:

did anyone implement what was written in comment 17 & 16 - as I thought this would have also resolved the issue.

Seems not. Maybe I'll do that soon.