see Devicetree Specification,
section 2.3.5 #address-cells and #size-cells
The #address-cells and #size-cells properties may be used in any
device node that has children in the devicetree hierarchy and
describes how child device nodes should be addressed.
The #address-cells and #size-cells properties are not inherited from
ancestors in the devicetree. They shall be explicitly defined.
If missing, a client program should assume a default value of 2
for #address-cells, and a value of 1 for #size-cells.
Change-Id: Iafed49358540f8ac7aa673c3dc0191c9b580250b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5144
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* move common SMP initialization code to x86/arch_smp.cpp
* factor out arch-specific SMP initialization to
arch_smp_32.cpp resp arch_smp_64.cpp
* implement smp_trampoline for x86 32-bit EFI loader
* rename SMP trampoline for x86_64 to long_smp_trampoline
* add new argument virtKernelArgs to arch_smp_boot_other_cpus
as the kernel args are not identity mapped on 32-bit architectures
Change-Id: I30d0bb1fa9bfb08f6784a2af34eb83d6b64afa57
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4869
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Change-Id: Iff9e4198aca706097889faf51e9559fe551126ad
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4782
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* Working under qemu smp 1,2+
* Working on SiFive Unmatched
* x86_64 efi not broken by smp_boot_other_cpus change
Change-Id: I32ebc17913e46ed082be9ade8f56448bbf12f16e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4705
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* A few things need alignment, instead of forcing them all
to align themselves, support alignment of the kernel_args
* Default of 1 is "no alignment"
Change-Id: Iff05dcec8adaa963c8444d701464ea11616062f6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4698
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This way it becomes much easier to write multiple console implementations
in one bootloader.
Tested for bios_ia32 and efi.
Change-Id: I67134f5c3de109b15d46898864ba7f51c6592afc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4642
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* This models the CpuInfo into a cross-architecture
platform_cpu_info
* Originally I was looking at merging this with "arch_cpu_info"
however that is "overall cpu" while CpuInfo is "indivial core
information" packed into an array.
* Since every dtb platform will report individual cores in fdt,
having a common cpu core info struct with at minimum the core
id makes sense.
* This could likely be refined further to some kind of core info
packed inside of arch_cpu_info, but this will fix arm,arm64,etc
for now until someone wants to dive into that.
Change-Id: Ia18a352403cd0da7130c1e637fc205d4311478ef
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4363
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Change-Id: I6cb31760519c8ba4542d217d6e68439602eda558
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4356
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* 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
