* Makes the case where the loader and the install differ by
release type, so that the icons are rendered in the same
position
Change-Id: I01e48109ce127b202ce5e05544aa2d5a495ed53e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4162
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
This also keeps the functionality of hrev53848, which simplifies the
list of disks searched for bootable partitions; however, it maintains
the previous behaviour of platform_get_boot_partitions that continues
to iterate over a list of possible boot partitions, which should
allow finding a bootable BFS partition better in more circumstances.
Particularly, there are numerous reports of the UEFI loader entering
the boot menu despite it finding a bootable partition, which this
should address.
EFI's device_contains_partition is also structured such that it
compares the disk GPT table of the partition the loader is
querying of the EFI disk's GPT table, in the case that there are
multiple disks, as the most reliable method of comparison, with
a generic fallback for non-GPT disks, which will be less reliable.
This reverts commit 0d932a49ad.
Change-Id: I5fac8608035d56b8bb4dc6c3d495ec6db42fa9b7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4149
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Various projects, both commercial and OSS, began to use inclusive
terminology. There is no reason to not do it.
In Haiku, bootloader uses Blacklist, which is recommended to replace
with Denylist or Blocklist. I think Blocklist is appropriate here,
since it's a list used to block offending driver at boot.
Some strings remain unchanged for compatibility with previous naming,
but this change prepares for later removal of these (once everyone has
updated their kernel and bootloader).
Change-Id: Id9105ff5e9fcb866000355089b5ef97bf63ee854
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3145
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
It was bumped for bios and efi from previously very low values, but
other architectures did not follow.
Change-Id: I6ce92e2cdb0261d4d0637753e77d555d407073fc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3575
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: Id050fad59ede444f2eab7eca681c6ec44612aaf9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3160
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: François Revol <revol@free.fr>
* Migrate some platform agnostic architecture code into
boot/arch from efi/arch. This helps to avoid conflicts
between kernel and boot sources as well.
* Conflicts between arch_cpu in efi and kernel code means
bootcode really should *never* directly use kernel arch
headers. (other platforms don't, which is why they don't
have this same issue)
* We carefully thread any needed kernel headers (namely
assembly helper macros) into the bootloader headers without
mixing in the whole conflicting kernel/arch headers.
* ARM now properly get its cpu init code called, and we
progress further into the EFI bootloader.
Change-Id: If67ec9758b5ce68563ebd9eb45d5196401911c67
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2975
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The memory map may be unordered and include overlapping ranges. To make
sure that nothing gets included as usable that should actually be
excluded, first scan for all usable ranges and add them, then remove
anything unusable from these ranges again.
To calculate the amount of unusable memory, count the total after the
first pass and then subtract the total after the second. This way, only
unusable ranges that actually overlap physical memory (and therefore
reduce the amount of usable memory) get excluded.
Note that the explicit ignore of the ACPI reclaim memory is subsumed by
the above. We still don't want to add this region to the usable memory
map, as that would allow the kernel to allocate pages into that region,
possibly corrupting ACPI tables before they were used. We also don't
want to add it as an allocated range, as it is not guaranteed that ACPI
is done with the tables before the unused bootloader ranges are freed in
the kernel.
Also add the missing unusable memory amount from ignoring the first MiB
of memory in the EFI loader.
May fix#16056 although it is not certain that graphics memory ranges
are actually included in the memory map.
Change-Id: Ie7991d2c4dcd988edac2995b3a7efc509fa0f4a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2814
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Previous version of the patch was broken by the EFI refactoring.
Change-Id: I6dd125100b22b2461c531bfd8f81b3dd28e2b751
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2409
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Change-Id: I0d6d2f8db2bc86c08d5ba2648f1cf46d85b54a5e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2267
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* arm efi additions
* cleanup some cpu headers which were oddly
split between efi and bios_ia32
* Move calculate_cpu_conversion_factor over to
arch_timer since it is timerish, and x86 only
* Drop some duplicated code from efi start. Move
hpet init code into efi timer/hpet code
Change-Id: Ia4264a5690ba8c09417b06788febc4f572f111ce
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2259
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* This is the bulk of the work. Anything else should be
minor cleanups and tweaking.
* riscv64 isn't a viable EFI platform yet.. just acting
as a stand-in to test a non-x86 EFI haiku_loader
Change-Id: Ib03de81e2b562e693987b86d7b4318209fb1c792
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2256
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This issue was initially detected by PVS Studio (issue number V547) and fixed
as part of Google Code-in 2019.
The initial problem was the calculate_cpu_conversion_factor function
which had been copied in the BIOS and EFI versions of the boot code.
Further investigation led to more duplicated or very similar functions
being identified.
Introduce an arch_cpu.h for the x86 boot platform to group these things
in a single place, and adjust the BIOS and EFI code to call into that.
Note that the BIOS and EFI code is still a little platform specific,
ideally there should be a boot_arch_cpu_init() function for each
architecture as already done for openfirmware and u-boot.
Also remove some irrelevant comments from copypasted files for other
architectures, as that was filling my git grep with useless noise.
Change-Id: I16d815f0bf015cec0b4e03cc14f3cc447c7164c5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1985
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
For #15515
As mentionned in the ticket, we may also want to hide the symbols
altogether from libroot for newer API/ABI versions, unless we still want
to provide C89/C99/C++98/C++11 compatibility, in which case we still
need them around.
Change-Id: I0ee267fb6c4c2f4bae9b1ba6f68e2bcefc399a7f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2061
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Move x86 hpet behind timer interface.
* Add a few if x86,x86_64 macros to start.cpp.
Change-Id: I583ec1b064785182e6d48dfbcd91b1bb2ead4b44
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1929
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Change-Id: I88afad6d071e8b577c23da9c60392c60b3726514
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1895
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Sparcv9 runs Openboot in 64 bit mode, which means the cell size is
64bit. Use intptr_t where appropriate to make the open firmware calls
work.
Beware, some values are still 32bit, this matters for example for
of_getprop, if you get 32bits into a 64bit variables it will be in the
MSB of it (big endian only weakness...) and confuse things. See for
example in console.cpp, where the input and output handles are retrieved
as 32bit values. It seems wise to check the expected size when using
of_getprop in these cases, instead of just checking for errors.
Change-Id: Ie72ebc4afe7c6d7602a47478f0bfb6b8247004b8
Reviewed-on: https://review.haiku-os.org/c/1369
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Add a platform cleanup hook before starting the kernel. The openfirmware
and PXE loaders clean up their network stack there, while the other
loaders currently do nothing.
This closes ticket #6166
Change-Id: I34765892dfd9b2310c6af97c9ff7d414afae49e5
Reviewed-on: https://review.haiku-os.org/c/50
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
memset uses rep stosb on x86 during boot, with memory
not set to write-combining, which makes it slow.
Instead we do aligned writes of 2 x four bytes at once.
Only clear the minimum of size and width * height * 4
UEFI framebuffer size can be huge, upto 512MB here,
and rep stosb seems to be around 25-30MB/s
This is written as generic as possible to work on
old compilers and different platforms, without
expecting boot memset to be optimized.
This makes it almost unnoticable compared to not
clearing.
Writes to videomem is slow without memory remapping
Can't do the mapping without leaving UEFI, so skipping
the clear. Afaict it should always be cleared by UEFI
This saves ~10 seconds of booting on my machine
(1920*1080*4 bytes)
EFI video mode (should have been it's own commit)
* Only do strcmp if there are enough params
* break when found
The UDP service does not own the UDP sockets. When shutting down,
inform the bound sockets that the service is no longer available.
This allows subsequent method calls to error out cleanly.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
Add a cleanup function net_stack_cleanup() that calls a new NetStack::ShutDown() method.
Make sure this method works even if the network stack was never initialized.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
This allows the loader to skip BFS partitions that don't contain
a bootable system. Useful when you have a BFS data partition that
comes before the system partition when iterated over.
Currently, only the UEFI loader actually returns more than one
possible partition.
Chunks may be physically contiguous, but virtually disjoint. Adding
physical addresses may cause ranges to be merged incorrectly.
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
The HashMap constructor was called before the heap is initialized,
ending up calling malloc from the OpenHashMap constructor.
Oddly it was still working on x86 but broke other platforms.
Instead we add a Lookup() static method to Partition,
which by default walks gPartitions for the id,
and recursively calls itself on the children lists.
This means we must add a partition even temporarily to gPartitions
before Scan()ing it though.
Signed-off-by: François Revol <revol@free.fr>
* Only set HAIKU_BOOT_PLATFORM to bios_ia32 if not defined
* Add gnuefi build feature
* Introduce BOOT_LDFLAGS, and move options for passing to linker
into ArchitectureSetup
* x86_64 compile fixes for warnings in boot loader
* loader/elf.cpp: don't include ELF32 support when targeting EFI
* relocation_func.cpp: copy of the relocation code from gnuefi
to make _relocate extern "C", and avoid including <efilib.h>
* boot_loader_efi.ld: copy of gnuefi's elf_x86_64_efi.lds,
modified to include support for C++ constructors, etc. Keep in
sync with the gnuefi package
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Reduce duplication of code by
* Removing from elf_common.h definitions available in os/kernel/elf.h
* Deleting elf32.h and elf64.h
* Renaming elf_common.h to elf_private.h
* Updating source to build using public and private ELF header files
together
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
For potential boot volumes with older packages states the respective
item in the boot volume menu now has a sub menu for selecting a state.
The boot loader functionality for this feature is complete -- i.e. the
respective kernel is loaded and the name of the old state is added to
the kernel args -- but kernel packagefs and package daemon support is
still missing.
* Set max cpu to 1 for PPC until atomic functions are finished
* We have atomic functions inline in the kernel and assembly
code in libroot post-scheduler merge... isn't that a lot of
duplication?
Add boot loader debug menu option "Save syslog from previous session
during boot". If enabled (defaults to true), the previous session's
debug syslog data is copy to a separate buffer and passed to the
kernel, which writes it back to the file /var/log/previous_syslog.
As long as Haiku still boots, this should now be the most convenient way
to retrieve the output from a kernel crash.
