Fixes regression introduced in c216360337
where the framebuffer info passed to the kernel came from
whatever video mode was highest numbered, rather than what
was actually selected.
Should fix#20161
Change-Id: I06c800bd8e941ed7f6b20998c1ff66cd6a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11197
Reviewed-by: waddlesplash <[email protected]>
This would underestimate the number of pages needed to map an address
range resulting in too-small page table page reservations, causing a crash
Change-Id: I34513621b36ecd60de71e128912950b66a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11129
Haiku-Format: Haiku-format Bot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Some systems need embedded controller access during their _INIs,
so we need to use the ECDT to initialize the embedded controller
during ACPI init.
Since we can now initialize the EC during ACPI module init, we can't go through
the ACPI module anymore, and instead call its functions directly
This should fix
"KERN: ACPI Error: Region EmbeddedControl (ID=3) has no handler"
seen in a few ACPI-related tickets, including:
#19602, #19407, #18864
Change-Id: Ia648ee8036b68416ed1ca1c51dd1daea6a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11058
Reviewed-by: Fredrik Holmqvist <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
It's possible for the EC to disable burst mode (maybe because
we're taking too long and it's impatient) before we check
the status register to see if burst mode is enabled. If that
happens, we consider the burst enable command to have failed,
even though it succeeded and put EC_BURST_ACK in the data register.
So, the next time we read the data register for a subsequent
command, we'll read that EC_BURST_ACK.
This fixes ACPI battery & shutdown on 2015 MacBook Pro
Change-Id: I49711b224fee027e28825674d9c845bf6a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11019
Reviewed-by: Fredrik Holmqvist <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
On some Intel MacBooks, system firmware configures the framebuffer
as X-tiled and uses the "Graphics Memory Fence Table Register"s to
transparently convert linear framebuffer accesses by the CPU to tiled
accesses. If you change the framebuffer base address or stride, you get
a garbled display since the "fence" configuration no longer matches
the framebuffer.
Might fix#17688
Change-Id: Iaf9ea7641f7809acb9b8fbf14b88ed656a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/11016
Reviewed-by: Adrien Destugues <[email protected]>
- Add more secondary CPU startup methods:
PSCI using EL3 secure monitor calls (used on most ARM64 CPUs)
Spin tables (used on Apple CPUs, which lack EL3)
- Secondary startup code was rewritten to pass all needed info
to secondaries using static variables, since we can't
pass any info to secondaries when using spin tables
- Setup MMU state to known good values as early as possible
instead of relying on the values set by the bootloader.
This also requires generating new page tables, since we're
(potentially) changing MAIR as well as the address space sizes
(which determine the number of page table levels we need)
Change-Id: I3b90aab04090fa0c6a8ad82a01df7fee6a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10984
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
- GICv2 _PerCpuInit and _EnableInterrupt were called twice,
before and within the call_all_cpus_sync
- GICv2 addresses were truncated to 32-bits
- Add "arm,gic-400" compatible
Change-Id: I34d62cb77f7ac002459c931ac750c8306a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10983
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
The kernel version previously differed from the userspace
version by sBootTime, which causes issues including:
- configure scripts thinking the build environment is broken
- an sBootTime-long delay between the desktop appearing
and the user gaining control
- apparent time travel
Change-Id: I8e616772631df1c40958db4f23b10cbe6a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10808
Haiku-Format: Haiku-format Bot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
* Implement arch_fill_topology_node
* Change uname to return 'arm64' in utsname.machine instead
of 'aarch64' to match what is used for packages (otherwise,
on startup, package daemon thinks every package has the
wrong architecture)
Change-Id: Ibba8784fca826023e0e13fef4222bdba6a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10684
Reviewed-by: waddlesplash <[email protected]>
When we exec, we push 2 iframes to the kernel stack: the one in
EXCEPTION_ENTRY, and the one in arch_thread_enter_userspace.
EXCEPTION_RETURN only pops one of these back off, so every time
we would exec, we were permanently reducing a thread's kernel stack
pointer, which would eventually lead to the kernel stack
overflowing.
Also, some redundant zeroing of registers in _eret_with_iframe
was removed.
Change-Id: I1e3e33f08bd05a3876f00d94cccb35fa6a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10683
Reviewed-by: waddlesplash <[email protected]>
mingw EDK2 gives us a memory map containing a one-page-long
entry that happens to be TTBR1. Because we were bailing out
in map_range, we couldn't update that page after entering
the kernel
Change-Id: Ie38fc593da268ab2a1f3ca98f3bffce36a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10658
Reviewed-by: waddlesplash <[email protected]>
Haiku-Format: Haiku-format Bot <[email protected]>
* SCTLR register definitions made 64-bit
* isb added after writing to SCTLR, to ensure we don't execute
instructions requiring the MMU prior to the MMU being enabled
* GICv2 has per-cpu registers for IRQs < 32, so enabling or
disabling those IRQs needs to be done on all cores
* MMU setup code in kernel and bootloader made per-cpu
* Signiture of arch_smp_boot_other_cpus is now the same on all
architectures, with an addr_t page table
Change-Id: I13bef7ca4efc5504d643833664560a9a6a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10649
Reviewed-by: waddlesplash <[email protected]>
Previously, we would increment the jmp_buf pointer in x0
while storing registers and then pass that adjusted pointer
to __setjmp_save_sigs, which would clobber whatever
happened to be after the jmp_buf
Change-Id: I5c466dbc6aa4fa9c69535ad5a5044af46a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10642
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
This is what other architectures do :)
Previously, we only handled signals after system
calls, which could result in a funny sequence of events:
- Thread gets spawned with spawn_thread
- Thread gets resumed with resume_thread, which sends
SIGNAL_CONTINUE_THREAD
- Thread's very first syscall is a read(), which promptly
gets interrupted by SIGNAL_CONTINUE_THREAD and the thread
has no idea why, and doesn't bother to read() again since
it never expected to receive a signal
^^^ PtyReader fell victim to this and Terminal was broken
Change-Id: I32c4c73be21c60cab97add2bb7052dc56a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10608
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
* Ensure some bits in TCR have known values, since the bootloader
might have configured something weird which causes problems for us
(such as configuring a virtual address space that's smaller than
we expect).
* ==NULL check in VMSAv8TranslationMap::UnmapPage was backwards
* Don't receive the number of syscall parameters from userspace. We were
previously reading twice as many arguments as needed when handling
a syscall.
* Save FP/SIMD registers as early as possible, since we can't know when
they might get used
* Reset iframe stack index to 0 upon arch_thread_enter_userspace.
Otherwise, when we exec, we push an iframe and never pop it off
again
Change-Id: I4bc7dcc9303b9103a97226cd7ece4c9b6a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10607
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
* It was actually disabling the UART
* I forgot this was C++ and not Rust and put a ! instead of
a ~, so this wasn't doing what I intended anyway
Change-Id: I0b7c3d44f3e041cc70cb933ccba886346a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10548
Reviewed-by: Fredrik Holmqvist <[email protected]>
Tested-by: Commit checker robot <[email protected]>
* E2H (EL2 Host) is enabled by default and usually can't be disabled
on CPUs with FEAT_VHE. Since EL2 becomes a superset of EL1 with
E2H, we can simply do nothing and everything that expects EL1
will Just Work
* Changed some register bits numbers to avoid C integer promotion
issues
* sEmptyTable needs to be filled in earler, before the kernel team
is created. Otherwise, we put the uninitialized value of sEmptyTable
in TTBR0, which immediately pends SError on Apple M1
Change-Id: I84ff7fd9134448f27315dadfd12bdd9df8c75b10
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10547
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
On Apple platforms, there are regions of memory not mentioned in
the memory map that are protected by the system. If the MMU
happens to encounter one of these regions while performing a table
walk, it will trigger a fault (even if you are not accessing
those regions).
So, we simply need to stick to what's in the memory map.
This also required fixing the memory mapping code, since it had a few
issues, including walking past the end of a page table and putting PTEs
in adjacent memory as well as mapping more memory than requested
Change-Id: I9166c909d510c82943cd15a9e62799b820ec53ed
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10546
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
The AX88179A has an English MAC address and will STALL if you
don't remind it of this fact.
Change-Id: Id4b1d9b8ff69327787d826ce42e6d78bc3cbcc30
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10529
Reviewed-by: waddlesplash <[email protected]>
* KERNEL_BASE differed from the base the kernel was linked for
* arch_mmu_is_kernel_address was off-by-one
Change-Id: Ic5a4a509e330bba2503532cc75f1fdaa85ad4f07
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10488
Reviewed-by: waddlesplash <[email protected]>
* macOS ships an ancient version of GNU Bison which wants
an '=' after %name-prefix
* macOS awk doesn't support strftime, so try to find a working
awk.
* _haiku_build_{open,openat,fcntl} are declared and defined with
different prototypes (variadic vs non-variadic). This is bad
on its own, but it "happens to" work on most platforms since
variadic parameters are usually passed in registers, same as other
arguments. On arm64 macOS, variadic parameters are always passed
on the stack, so you get weird and confusing bugs when using
these functions.
Change-Id: I8cee9ecac0ac9b039be6b7e35ceaf8ad7c0f4c44
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10468
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Allows building with GCC >=15, which defaults to c23 and disallows
function declarations without parameters and old-style function
declarations.
Fixes#19584
Change-Id: Idb141b804e80d3909558abecd2c74538cb3766ae
Reviewed-on: https://review.haiku-os.org/c/haiku/+/9684
Reviewed-by: waddlesplash <[email protected]>
Sam Roberts