mmu_free was only used for ACPI and only set a released flag
in the region. This released flag was never checked anywhere.
platform_free_region removes region from linked list now.
There are a lot of calls to it, so it should save some mem and make
memory layout cleaner.
Compiles on boots on AMD64
Compiles on ARM and loads kernel, but can't start it, since we havn't
setup the mmap with proper virtual addresses (with some other fixes to
ld-script and ELF32 loader EFI code.
Change-Id: Icfe871fa400b49f19e7ca1dbb9e1561309b21a22
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3403
Reviewed-by: Rene Gollent <[email protected]>
There is one efi_block_io_protocol per disk and one per partition.
All we need to do is find the disk ones and let Haiku find
bootable partitions.
There is a special case for a device with one fixed partition
which does not have one for disk, but it is unlikely we will
ever want to boot from such a device.
Fixes#15587.
Change-Id: I915870d6d3b19947bc58b32a969f9f89d2d2245d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2232
Reviewed-by: waddlesplash <[email protected]>
Registrar schedules an event every second to do
fRoster-CheckSanity(). This uses 2.5% cpu on my machine
when idle. Changing it to five seconds lowers it to 0.1%
waddlesplash then pointed me to this bug which changes it
to watch for team deletion and call fRoster->CheckSanity()
As I know little in this area, it's mostly based on what
LaunchDaemon does in MessageRecieved.
Change-Id: Ie69f9399cab41d2d492d469b5d3dc88e6080c15c
Reviewed-on: https://review.haiku-os.org/c/876
Reviewed-by: waddlesplash <[email protected]>
Registrar schedules an event every second to do
fRoster-CheckSanity(). This uses 2.5% cpu on my machine
when idle. Changing it to five seconds lowers it to 0.1%
waddlesplash then pointed me to this bug which changes it
to watch for team deletion and call fRoster->CheckSanity()
As I know little in this area, it's mostly based on what
LaunchDaemon does in MessageRecieved.
Does handle coords correctly, but two finger jumps position somewhere
We can also report actual buttons, but not sure how movementmaker handles
it.
Will do cleanup once working
To test or help out return B_OK in probe_elantech
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
Tested on x86_64 and x86_gcc2, works on my machine and most likely fixes
that was most likely due to missing lock sync in previous ACPI upgrade.
* Redid some of kallisti5's work as it was easier to start from earlier
version.
* Evaluating 64 bit physical addressing on 32 bit Haiku again as this
was likely the cause of pagefaults (#12377):
"Implemented internal support for full 64-bit addresses that appear in all
Generic Address Structure (GAS) structures. Previously, only the lower 32
bits were used. Affects the use of GAS structures in the FADT and other
tables, as well as the GAS structures passed to the AcpiRead and
AcpiWrite public external interfaces that are used by drivers. Lv Zheng."
* Mostly bugfixes in ACPICA
It was discussed and introduced based on docs that some systems
need this to shutdown properly. I can find no mention of this in
ACPICA or ACPI docs.
This needs to be re-evalutad, as all my shutdowns been successful
after disabling it and I can't locate where this info came from
or if it actually helped.
See 1316462ab0 for original commit
and bug 12306 on current shutdown issue.
* The global lock, needed for hw <-> os to sync, was a no op.
This means that OS and HW could read and write to same value
at the same time, causing garbled data and crashes. This is easiest
to see in battery status, where battery values and OEM name would
become garbage. It also causes instability and failure to shutdown
* ACPI used 64 bit addressing (which it normally should) on 32 bit.
This would cause page faults as it would jump to incorrect addresses
gnuefi package was replaced by gnu_efi_kernel, but build
was not updated. This is guesswork, as I couldn't track down what changed.
It finds headers, headers_arch and lib and works so should be ok.
Now we can see who has Elantech touchpad.
Driver is currently in very bad shape on my hw:
* mouse jumps
* mouse clicks maps to wrong button
* keyboard not working properly when enabled
* power button only works in force shutdown mode
Connecting to wifi is very slow, there are several issues.
Easiest to find and fis is that on my wifi DHCP always took
4s, as first request fails. Still investigating why..
Reducing timeout to 0.25s makes DHCP process fast.
Moved timout handling into its own struct, and changed state
timeout from max(remaing, 60s) to min(remaining, MAX_TIMEOUT)
Not sure about that change, but why would you want a max value
that is at least 60s?
FreeBSD has a simple inlined bus_space_read while Haikus had one
with call overhead.
This still needs cleanup as it is x86 specific, which it was already.
Also it redefines inX and outX defines as arch/x86/arch_cpu.h has a
C++ namespace so it can't be included from FreeBSD drivers C-files.
The results of these changes should be worth it though.
Even on 32 bit machines the default is to use 64 bit addresses
because of PAE. Haiku currently forces 32 bit addresses which
probably should be fixed.
See achaiku.h: define ACPI_32BIT_PHYSICAL_ADDRESS
This allows me to find and boot disks and cds(*)
platform_add_boot_device tries to find the disk of the EFI partition
As on other platforms if boot disk isn't found platform_add_block_devices
will be called.
platform_add_block_devices will find all block devices that arn't partitions as
they are handled by Haiku already.
Currently first found suitable partition will be selected.
TODO:
* pass in partition UUID's as boot-loader arg to setup boot for
any partition.
* Better cd detection
* Better disk_identifier
*) vfs_boot.cpp is very restrictive when it comes to booting cds.
It either do very Anyboot check where boot partition should be at offset 0,
which isn't true for EFI. In my case it's not even on that disk.
Or it only allow data session partition types.
This is currently failing as the Anyboot partition type is BFS.
EFI boot needs -fpic but all boot code was built with -fno-pic.
This is now set accordingly in HAIKU_BOOT_CCFLAGS and
HAIKU_BOOT_C++FLAGS.
Also setup compile flags for EFI platform.
* 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 <[email protected]>
Changelog: https://acpica.org/sites/acpica/files/changes_29.txt
* This is based on the upgrade waddlesplash aborted due to a bug
in ACPICA which has since been fixed.
* Some ACPICA code is excluded until needed. (You may want to
compare our acpica dir to ACPICA if you are missing functions.)
NetworkAddressTest passes (most) tests when you have network.
When no network interface (ie -net none in QEMU) tests take forever and
more tests fail.
When network interface exists but is disabled in Haiku, tests are fast but
more tests fail.
It is only useful for ACPI devs. If the need ever arise it can
easily be reworked to be enabled / disabled at runtime.
For everyone else it was just syslog garbage.
Currently find display adapters and attached displays but nothing more.
I would like it to publish adapters and displays in dev tree, so that
you can open and control the adapter (get firmware, boot display) and
the adapter itself would have child devices for displays (brightness ..).
However that part could use some review, and since my time is limited it
is better to make it availble for others to work on as well.
Fredrik Holmqvist