By updating $fdt_addr_r we can simplify boot-arm.scr.txt.
Now we can explicitly pass the device tree address to bootefi instead of
relying on a fallback inside U-Boot.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Change-Id: Ifceb574aca2814605a2e4e58e9187773817c5df2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2970
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
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>
check that the correct BIOS is found with the device and PCI ids.
make the allocated rom area bigger like Linux, otherwise page faults occur.
Change-Id: Iae6ff1c8dfd81ea16c20e73d511f9a0a96f9b071
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4844
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Regression caused by refactorings in hrev55348.
The logic for deciding when to use a built-in tracker icon was changed
incorrectly to ignore attributes on directories, trash, etc (anything
but executable applications). So the built-in icon was always used.
This commit restores the previous logic.
Shoud fix#17320 and #17371
Change-Id: I51ba22db59a8b6dd2bd1121b56c753ed47224c57
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4841
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* This was originally added in hrev55661 for x86_64
* riscv64 suffers the same issue after updating to gcc 11
* Presumably, all architectures might suffer from this,
so apply to all remaining architectures
Change-Id: I41f2adeb5153ce4f4094d667ae303394d537d8ec
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4837
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Moved machine mode code from kernel.
* Added MMU page table generation.
* Added QEMU ramfb video driver.
Change-Id: Icd67cd2e8dbf2b568d81ab8dd0d6127ca3cd97a8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4302
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
This partially reverts commit cc0226fad0.
This commit caused high CPU usage in app_server. The double buffering in
ActivityMonitor is not to avoid flickering, it allows to draw just a few
pixels of the the curves at each update, and reuse most of the bitmap
from the previous run.
Removing this means all the curves are fully redrawn at each update,
resulting in higher CPU usage (one core at 30% on my machine with 5
different graphs).
Keep the part of the changes removing code for custom background
drawing. B_TRANSPARENT_VIEW flag can be used instead.
Change-Id: Ie3438ca634c934f3e96ce5f7ad71ce7b3a435013
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4833
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Skip pixels with a coverage of 0. Since the source alpha channel is
ignored, we would otherwise cover pixels that shouldn't be.
Fixes#17449.
Change-Id: I373672a765b99efce5dceed4ffa81741f78b9d9f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4836
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The info is now available in cpu_info, we should do something with it.
Change-Id: Iac7bd697783d63b5c84c7da33770b3c9a7d417b4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4832
Reviewed-by: Kacper Kasper <kacperkasper@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
arch_elf is reused between the kernel and boot loader
No change for kernel mode compilation.
How to select 32-bit or 64-bit when building boot loader:
* build both when building BIOS loader
* build only 32-bit when building 32-bit EFI loader
* build only 64-bit when building 64-bit EFI loader
Change-Id: I9caa1248c7eb24318911a0c369137cedb638e4e4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4817
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Build both when building BIOS loader.
Build only 32-bit ELF support for 32-bit EFI loader.
Build only 64-bit ELF support for 64-bit EFI loader.
Change-Id: I88bb287fbb9a4b6618b365b2d03f85f64021f499
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4818
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This code was written with wired ethernet in mind, where changes are
rare. However, on wifi the "media" changes all the time (switching
between different connection speeds). So, only log linkup and linkdown.
The other events are not that important.
Change-Id: Iaafb74ceb05a59dedf94184eee23a4e81fa5e983
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4827
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- Number of retries could overflow. If we retry something more than 255
times and it fails, just stop, instead of flooding the network with
bogus requests
- The timeout could also overflow. It was stored in microseconds in a
time_t, which allows a bit more than an hour. This is fine for the
initial timeout (which starts at a few seconds and will go up to 64
seconds), but after that we switch to a slower rate driven by the
"state time". In particular, this can be the lease time, which DHCP
servers may set to several days, or at least easily more than an hour.
- The computaiton of the timeout in the "slow lease" case attempted to
do "not less than a minute", but missed a conversion from microseconds
to seconds so it ended up doing "not less than 60 microseconds"
The combination of all these things means we can end up with a negative
timeout, and we will send a burst of requests without ever stopping,
flooding the network.
Change-Id: I0eb811c90f4a4dd8c9d92bff728bc2bbb52fbd56
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4826
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
used by PR_OpenSemaphore in NSPR to check the creator inited.
Change-Id: I626c6ab0d50896c94224718ca4fa0788f74ae27a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4824
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* We pack the first 8 bits into a union for the raw
edid since alignment matters.
* Handing the raw_edid is a bit ugly, so in the edid struct
we drop the input_type from the union since packing doesn't
matter as much.
Change-Id: I32dbfe9484f9eb83cf491a44d30a32ca36d65b7b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4775
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
each poll_fd struct should be checked, valid when not -1 and revents not zero.
Change-Id: Ia624ad1369ad1a6066c9970a47cfac63fa773702
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4821
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
the socket interface module checks the receive.low_water_mark to automatically
notify a read event. available_data will be zero, thus enabling the notification.
fixes the test poll_nm in NSPR.
Change-Id: I5354faec439df96671506550cdb144a45f6082b1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4820
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
PulkoMandy in cb3199681e changed
the _GetDomainSupport functions to always Ref() the the object.
However, that means in the case of the second _GetDomainSupport
function, which is implemented in terms of the first, we should
not call Ref() as this will create a double-reference.
Fixes a memory leak.
Change-Id: Ib82b2dadc0c8cc8d8f95efcffeb2430ac602a0a9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4791
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
LGTM seems to provide GCC 9.2, for which the flag -Wformat-diag is falsely
detected as supported.
Change-Id: I95a5946d9c6cd2af73e85070973f855fba3fcc39
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4786
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
LGTM build failed since -Wformat-diag check is failed.
So we add g++ to check its version in LGTM.
May help to fix#17460.
Change-Id: I9400dbbab7800c522bf7ed797adae48299581a4e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4780
Reviewed-by: Jérôme Duval <jerome.duval@gmail.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>
Using a memcpy here is supremely dangerous, because we are writing to
an app_server buffer that we chose the length for, but using a size
that came from the client. And, indeed, because the buffer can contain
padding if the BBitmap was allocated with a non-standard BytesPerRow,
we will overflow the buffer and corrupt memory, causing app_server to crash.
So, instead, reorganize parameters a bit, and pass BytesPerRow along
with the other data needed to instantiate the bitmap, and then use
ImportBits.
Fixes an app_server crash I triggered with the experimental libX11
compatibility layer.
