Opened 9 years ago

Closed 8 years ago

Last modified 6 years ago

#6710 closed bug (fixed)

Large sized boot logos can prevent booting.

Reported by: idefix Owned by: phoudoin
Priority: normal Milestone: R1
Component: System/Boot Loader Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description (last modified by mmadia)

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.

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

Note, see #comment:9

Change History (21)

comment:1 Changed 9 years ago by bonefish

Owner: changed from axeld to phoudoin
Status: newassigned

comment:2 Changed 9 years ago by phoudoin

Damned. Does it happends too with gcc4hybrid anyboot?

comment:3 Changed 9 years ago by vooshy

occurs with gcc2hybrid 38892 cd iso also

comment:4 in reply to:  3 Changed 9 years ago by idefix

Summary: Anyboot nightly immediately rebootsAnyboot / CD nightly immediately reboots

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.

comment:5 in reply to:  2 Changed 9 years ago by idefix

Replying to phoudoin:

Damned. Does it happends too with gcc4hybrid anyboot?

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

Very strange...

comment:6 Changed 9 years ago by idefix

Summary: Anyboot / CD nightly immediately rebootsAnyboot / CD gcc2(hybrid) nightly immediately reboots

comment:7 Changed 9 years ago by 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.

comment:8 Changed 9 years ago by 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.

comment:9 Changed 9 years ago by phoudoin

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

Last edited 8 years ago by phoudoin (previous) (diff)

comment:10 Changed 9 years ago by mmadia

Description: modified (diff)
Summary: Anyboot / CD gcc2(hybrid) nightly immediately rebootsLarge sized boot logos can prevent booting.

comment:11 Changed 9 years ago by 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.

comment:12 Changed 9 years ago by phoudoin

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

comment:13 Changed 9 years ago by phoudoin

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

comment:14 Changed 9 years ago by 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?

comment:15 in reply to:  11 ; Changed 9 years ago by 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.

comment:16 in reply to:  15 ; Changed 9 years ago by 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?

comment:17 in reply to:  16 Changed 9 years ago by 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;

comment:18 Changed 8 years ago by 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.

comment:19 Changed 8 years ago by phoudoin

Resolution: fixed
Status: assignedclosed

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...

comment:20 Changed 8 years ago by vooshy

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

comment:21 in reply to:  20 Changed 6 years ago by 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.

Note: See TracTickets for help on using tickets.