Opened 14 years ago

Closed 14 years ago

Last modified 12 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:
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 by bonefish, 14 years ago

Owner: changed from axeld to phoudoin
Status: newassigned

comment:2 by phoudoin, 14 years ago

Damned. Does it happends too with gcc4hybrid anyboot?

comment:3 by vooshy, 14 years ago

occurs with gcc2hybrid 38892 cd iso also

in reply to:  3 comment:4 by idefix, 14 years ago

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.

in reply to:  2 comment:5 by idefix, 14 years ago

Replying to phoudoin:

Damned. Does it happends too with gcc4hybrid anyboot?

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

Very strange...

comment:6 by idefix, 14 years ago

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

comment:7 by phoudoin, 14 years ago

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 by idefix, 14 years ago

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 by phoudoin, 14 years ago

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 14 years ago by phoudoin (previous) (diff)

comment:10 by mmadia, 14 years ago

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

comment:11 by phoudoin, 14 years ago

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 by phoudoin, 14 years ago

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

comment:13 by phoudoin, 14 years ago

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

comment:14 by phoudoin, 14 years ago

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?

in reply to:  11 ; comment:15 by bonefish, 14 years ago

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.

in reply to:  15 ; comment:16 by phoudoin, 14 years ago

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?

in reply to:  16 comment:17 by bonefish, 14 years ago

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 by phoudoin, 14 years ago

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 by phoudoin, 14 years ago

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 by vooshy, 14 years ago

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

in reply to:  20 comment:21 by phoudoin, 12 years ago

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.