#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 )
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
Change History (21)
comment:1 by , 14 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
follow-up: 5 comment:2 by , 14 years ago
comment:4 by , 14 years ago
Summary: | Anyboot nightly immediately reboots → Anyboot / 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 by , 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 , 14 years ago
Summary: | Anyboot / CD nightly immediately reboots → Anyboot / CD gcc2(hybrid) nightly immediately reboots |
---|
comment:7 by , 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 , 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 , 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.
comment:10 by , 14 years ago
Description: | modified (diff) |
---|---|
Summary: | Anyboot / CD gcc2(hybrid) nightly immediately reboots → Large sized boot logos can prevent booting. |
follow-up: 15 comment:11 by , 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 , 14 years ago
I've added the size sanity check in BuildFloppyBootImage1 in hrev38945.
comment:13 by , 14 years ago
And update for a more compact (and less *redish*) boot splash image for development build in hrev38946.
comment:14 by , 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?
follow-up: 16 comment:15 by , 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.
follow-up: 17 comment:16 by , 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?
comment:17 by , 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 , 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 , 14 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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...
follow-up: 21 comment:20 by , 14 years ago
did anyone implement what was written in comment 17 & 16 - as I thought this would have also resolved the issue.
comment:21 by , 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.
Damned. Does it happends too with gcc4hybrid anyboot?