HelenOS does not boot on Dell PowerEdge 3250
|Reported by:||Jakub Jermář||Owned by:|
|Blocker for:||Depends on:|
Description (last modified by )
The following commit broke HelenOS on Dell PowerEdge 3250:
63a045c41ff533abb66be65fc068415be77ad7df is the first bad commit commit 63a045c41ff533abb66be65fc068415be77ad7df Author: Jiří Zárevúcky <email@example.com> Date: Wed Oct 10 19:11:15 2018 +0200 Unify handling of compressed init data and use regular tar + gzip to achieve it There are two issues this commit solves. First is that architecture-specific code duplicates most of the init binary handling in each architecture, each with miniscule and confusing variations. After this commit, the init binary expansion is almost entirely handled by unified generic code. Second is that the way we used to generate the incorporated data is somewhat convoluted. Previously we have a Python script which generates a zip archive with individual deflate-compressed files and accompanying header and C files which contain structures describing the archive contents. The zip file is then extracted and the individual deflate-compressed files are included in the binary via assembler code. Since gas doesn't take particular care to be consistent between architectures, the assembly portions are also not uniform and the build script needs to know particulars of the architecture's assembly. Instead of doing that, after this commit we first gzip each included file, then we pack the gzipped files into a tar archive, and then we include the archive into the binary using objcopy. Linker script provides symbols for the start and end of the archive, and the payload is in a self-describing format, so there is no need for any generated code. Note that we are doing the opposite of the conventional .tar.gz format. It would be somewhat inconvenient to use .tar.gz since the uncompressed files need to be aligned to page size, so we'd have to first decompress the entire payload to determine the final position of the files (and hence the required amount of memory). :040000 040000 a958e2f86058b109d9a475191efe8b746981aad3 4b9293de1604e3ff56d2f7aed75d3140223e5b14 M boot :040000 040000 d42720be1711cb76aa4a159aa2ae8b72cfa2b2ed fd36c6d63f692b20cf87ca99ff4ac774072d08fa M kernel
The boot produces no output diagnostics, after starting elilo the screen remains blank.