1. SDHCI PCI Bus: Discovering SDHC device from the PCI bus
and registers a child node(MMC bus) to which slots
are attached. SDHC registers are mapped by MMUIO,
they are binded in a structure(struct* registers).
A pin based interrupt handler is also installed,
which triggers the handler function and interrupts
are being taken care of. Added API's to set-up and
the clock for SD/MMC card, change frequency and
reset the registers.
2. Device Manager: Currently, busses subdir lists are har-
dcoded and in order to load the driver. We hard
coded the bus dir under PCI devices.
3. MMC Disk Driver: In order to register the slots under
/dev/disk/mmc and hence data transfer and other
operations can be done.
4. MMC Bus Manager: Setted up a bus manager to create an object
to do a particular for eg certain data transfer and
get freed until another operation is requested.
Change-Id: I369354da6b79adc6b6dfb08fe160334af1392a34
Reviewed-on: https://review.haiku-os.org/318
Reviewed-by: Alexander von Gluck IV <kallisti5@unixzen.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.
It will probably be just stubs for the significant future, but,
here it is anyway.
Regarding the naming: Yes, the official name is "aarch64." However,
Linux, FreeBSD, and Zircon all call it "arm64", and so we will do the same.
I've configured it initially to be a Clang-only port, making no
changes to GCC buildtools whatsoever here. We'll see if that sticks,
however.
It seems not all of the kernel includes this, but some use new/delete
anyway. Further, operator delete[] was not implemented at all.
Possibly fixes the ARM build.
Clang's equivalent of .tfloat is .x86_fp80, but apparently that
is not enabled for Haiku. So for now, use .double instead.
This is the same thing MinGW does.
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
* <x86_gcc2>runtime_loader can also handle x86 binaries.
* At the moment the x86_64 kernel will execute the x86 runtime_loader
when it sees x86 and x86_gcc2 binaries. The reason is checking the GCC
version of a binary in the kernel seems cumbersome, the kernel should
just fallback using the x86_gcc2 runtime_loader when the x86 one is missing.
* gcc 7.x defines __arm__ and __ARM__ (and others)
* clang defines __arm__ and __arm
* cleanup a few related ifdef vs if macros
Change-Id: I5da4bafac590f6fa3e10e543688001c2449f840d
Before hrev46809, the "thread->priority = priority" line was below this
check, and so all was well. But that commit moved the line to its present
location, which means ever since then, the following code which updates
CPU entries, scheduler listeners, etc. has never been run.
On my VMware instance (which is probably pretty affected by the host system
and thus not the greatest performance test), "time jam -j2 HaikuDepot" decreased
from 46.0s real to 43.3s real, 52.3s user to 48.1s user, 12.1s sys to 12.2s sys.
So this seems to make some sort of impact.
Spotted by Fishpond in #10454 and confirmed by korli, but somehow neither of
them followed up on that in the 4.5 years since...
As Rene pointed out on the mailing list, if this is NULL after the file system
mount call occurs, then something has gone very wrong and we should treat it
as an error.
I got a reproducible KDL that upon close inspection seems to have been
a NULL dereference of this, thanks to GCC's mix-source-and-assembly
functionality.
Unfortunately, I deleted my mount_server settings before I fully understood
what was going on, and afterwards it no longer reproduced, so it seems to
have been related to that. I'm confident enough this is the correct fix to
commit it anyway.
6ad3d25212 changed the timezoneOffset type from
time_t to int32 without adjusting the user_memcpy size. Harmless as the
function is hardly used with a non-null argument.
instead of user_memcpy().
* fix#14204: the NTFS filesystem kernel addon uses the fcntl system call to
lock the underlying device. The user_memcpy replacement in the x86 compat
branch adds range checks for the user pointer, which exposes such problems.
The user iframe and associated data that the syscall entry pushes to the
stack directly were causing the stack to be mis-aligned by 8 bytes. Since
we re-aligned %rsp afterwards, for most usecases this wasn't a problem.
However, since we stored the pre-realinged %rsp in %rbp (as we need it to
access the iframe data), this also meant that anything which depended on
%rbp being 16-byte-aligned would run into serious problems.
As it turned out, GCC 7 assumed that %rbp was indeed 16-byte-aligned, and
so optimized certain accesses to use SSE instructions that depended on this
alignment. Since inside any callstack begining with a syscall this was not
the case, a "General Protection Exception" resulted (see #14160 for an example)
at the first usage of such an instruction. I wasn't really sure what was going
on when it first came up, and so "fixed" it by disabling the GCC optimization
that used such instructions. Replacing the -fdisable... with -mstackrealign thus
also "fixes" the problem, as I discovered earlier today, as it forces GCC to
realign the stack in function prologues.
So instead of rounding %rsp down to the nearest aligned address after the
pushes are complete, we offset %rsp by the amount the pushes are not,
thus fixing both %rsp and %rbp in syscall handling routines. This of course
depends on syscall_rsp being already aligned, which it is.
Thanks to PulkoMandy and js for the advice and guidance (and PulkoMandy
for the ASCII art), as this is essentially my first time working with
kernel assembly.
This reverts commit c558f9c8fe.
This reverts commit 44f24718b1.
This reverts commit a69cb33030.
This reverts commit 951182620e.
There have been multiple reports that these changes break mounting NTFS partitions
(on all systems, see #14204), and shutting down (on certain systems, see #12405.)
Until they can be fixed, they are being backed out.
* define compat_thread_info, compat_rlim_t, compat_rlimit and
compat_thread_creation_attributes to be used when applicable in compatibility
mode.
* handle 32-bit types in _user_spawn_thread(), _user_get_thread_info(),
_user_get_next_thread_info(), _user_getrlimit(), _user_setrlimit(),
other syscalls are compatible as is.
* init TLS for compatibility mode threads.
Change-Id: I483ba95e6198ddac9d240671bcb56fcd2ad831d2
* in load_image_internal(), elf32_load_user_image checks whether the binary
format requires the compatibility mode.
* we then set up the flag THREAD_FLAGS_COMPAT_MODE and the address space size.
* the compatibility mode runtime_loader is hardcoded with x86/runtime_loader.
* if needed, the 64-bit flat_args structure is converted in-place to its 32-bit
layout.
* a 32-bit flat_args isn't handled yet (a 32-bit team execs a 64-bit binary).
Change-Id: Ia6a066bde8d1774d85de29b48dc500e27ae9668f
* define compat_area_info to be used when applicable in
compatibility mode.
* handle 32-bit types in _user_reserve_address_range(), _user_get_area_info(),
_user_get_next_area_info(), _user_transfer_area(), _user_clone_area(),
_user_create_area(), _user_map_file(), other syscalls are compatible as is.
* _get_next_area_info() doesn't work well with a 32-bit address cookie (address
could be in 64-bit range). Instead use _compat_get_next_area_info() which uses
the area id as cookie, though the areas are not ordered by address any more.
Change-Id: Ic7519ca8824aa2d534b0f03ea75a1bf6ae321535
* handle 32-bit types in _user_send_signal(), _user_sigaction(), _user_sigwait(),
_user_set_signal_stack(), _user_restore_signal_frame(), other syscalls are
compatible as is.
Change-Id: I4c8dc47bfa80f36e363d444d2a5a7be6c621606d
* define compat_image_info, compat_extended_image_info
to be used for respective 32-bit types of syscalls in compatibility mode.
* handle 32-bit types in _user_register_image, _user_get_image_info,
_user_get_next_image_info, other syscalls are compatible as is.
Change-Id: Ibbd33e6796208dfa70d869e36bf745bc3e18d330
* define compat_flock, compat_timespec, compat_stat, compat_attr_info,
compat_fs_info, compat_fd_info to be used for respective 32-bit types
of syscalls in compatibility mode.
* handle 32-bit types in common_fcntl(), _user_read_stat(), _user_stat_attr(),
_user_read_index_stat, _user_read_fs_info, _user_write_fs_info,
_user_get_next_fd_info, other syscalls are compatible as is.
Change-Id: I5b372169fe142f67b81fd6c27e0627d5119ba687
* With the previous commit, we can now move functions that require
calling mmu_map_physical_memory to where they should have been
originally. This also allows the SMP safe mode menu entries to
be properly generated, now that smp_init is called prior to
main().
Change-Id: I05ddca5273b11cb4846021664c1ea2cf8ba723b7
* mmu_map_physical_address will get called prior to calling main()
which leaves us without a heap, malloc, and new. Instead, use
the kernel args physical allocated range array, and then
convert to our allocated memory region type on-demand.
Change-Id: I265fd165ef7143681e8e40c3686fda1a583c20dc
The call to smp_... is not working since it relies on gKernelArgs being
fully initialized, which it isn't at this stage in the EFI loader. Jessica
says that in order to have that happen, the heap would also need to be
initialized early, which it also is not.
At least you can now force a safe videomode, which is enough for me to
be able to test video drivers.
* install syscall handlers in compatibility mode.
* copy the syscall entry in the compatibility commpage, ATM only for Intel
SYSENTER.
* copy the thread exit handler in the compatibility commpage.
Change-Id: Ic350799938815194377d8a4560cb106fe7366cc6
* File locks created by flock should only apply for the file descriptor
that was used to lock the file. Another fd on the same file should then
be denied access (calling flock should fail).
* fcntl based locks, however, are in a separate namespace and are global
to a team.
* This issue was found when running webkitpy test suite, and should close
ticket #13795.
* Don't use session or team as comparison in release_advisory_lock(), as
that information might not be available anymore (e.g. when called from
Team::~Team()). This fixes#14121.
Change-Id: I9efb96cfcefe7e72b0060220c635a665e7e643cc
Co-authored-by: Axel Dörfler <axeld@pinc-software.de>
* This gives us a solid automatic entry point to u-boot
* A uEnv.txt specifies the fdt file name
* This should work on any modern u-boot for most architectures
* Non-mmc targets will likely need some work
Change-Id: I9a00316a213a15e85d3f2e18574d64920d9bdb76
* x86_64_signal_handler_compat is a dump of x86 x86_signal_frame_function().
* the x86 compiler should be used to produce this code, which ends up in the
commpage.
Change-Id: I03da02c376f67ff83dbaba9bcb144da726463996
* x86 uses a commpage with 32-bit addresses, incompatible with the one used for
x86_64. For this reason, a compatibility commpage is needed to support a 32-bit
userland on x86_64.
* define ADDRESS_TYPE as a macro for addr_t (default) or uint32 (for the 32-bit
commpage).
* team_create_thread_start_internal() will use clone_commpage_area() with
KERNEL_USER_DATA_BASE or clone_commpage_compat_area() with
KERNEL_USER32_DATA_BASE, to setup the correct commpage.
* real_time_clock (in compatibility mode) also updates the compatibility
commpage with real time data.
Change-Id: I61605077ce0beabab4439ef54edd1eae26f26fd2
* define ELF32_COMPAT to enable ELF32 macros.
* add a flag ELF_LOAD_USER_IMAGE_TEST_EXECUTABLE to only check the format.
It will be used by load_image_internal() to check which mode to use when
loading an image.
* in arch_elf_relocate_rel(), switch to elf_addr instead of addr_t, which
would be the wrong size for elf32 on x86_64.
* the ELF compat loader reuses the relevant parts of elf.cpp and arch_elf.cpp,
excluding for instance load_kernel_add_on() or dump functions.
Change-Id: Ifa47334e5adefd45405a823a3accbd12eee5b116
* only for Intel sysenter/sysexit.
* the entry function processes stack arguments as follows:
we look up the syscall in the table, find the number of arguments.
reserve place on the stack for the arguments.
copy arguments on the stack
pop register arguments
call the syscall function
place the return value in ax and dx registers.
* TODO: we need to store the arguments somewhere for the post-syscall tracing.
* the thread exit stub is 32-bit, for the time being use hexadecimal instructions.
Change-Id: Ie5c502eb596d4fa7613d238de80643566bc19ed8
* also adjust BOOT_GDT_SEGMENT_COUNT for x86, the definition is used by the
boot loader.
* add some 32-bit definitions.
* add a UserTLSDescriptor class, this will be used by 32-bit threads.
Change-Id: I5b1d978969a1ce97091a16c9ec2ad7c0ca831656
the x86_64 compat syscall entry needs size and offset of parameters to
handle them correctly to the syscall function. struct extended_syscall_info
and struct syscall_parameter_info provide parameter count, size and offsets.
Change-Id: I7e5c7b6e19e757b28b43c3b3419b7071fae321f8
use x86 as default sSearchPathSubDir in compatibility mode.
use the generic memset/memcpy when x86_64 is the primary arch.
Change-Id: Ib464c308ff97f7ae2482ef4c037de1b1bb2bf61b
the standard x86 implementation uses the commpage, which is difficult to setup. we could
also use the C++11 version instead.
Change-Id: I4be7e3466082ff2c91bc32bef377a664ce65f3fc
* A Node/Partition cannot be member of two lists at once. This
resolves an issue where a partition cannot be found later
due to corruption of a NodeList.
* The kernel's advisory locking implemenation must not be used if the
file system has its own (ie. network file systems).
* Added ASSERT to free_vnode() that assures there is no locking left;
I recently had a lot of them around.
Since wait_for_objects can wait on sems, threads and ports in addition
to FDs, limiting to RLIMIT_NOFILES as in the select/poll case does not
work. Since space is allocated for the wait objects in kernel memory,
limiting their number to a valid range is still desireable.
The limit is now placed at the sum of max sem, thread and port count
plus RLIMIT_NOFILES.
This also fixes a signed vs. unsigned comparison warning in
check_max_fds introduced in hrev51866.
It was limited to a uint32 and could for example be overflown by the
slab MemoryManager that uses size_t on a 64 bit system.
This aligns the signature with create_area() that already uses size_t
for the size argument.
Note that the function is currently private, so the impact should be
limited.
* Show old page table location and provide more feedback
* 16 int32 * 0x10000000 > sizeof(int32), fix to uint32
Change-Id: Ib68c34f5d3c6bfa1da53241e6586c07e4e494750
Output-only events (B_EVENT_ERROR, B_EVENT_DISCONNECTED and
B_EVENT_INVALID, with B_EVENT_INVALID masked out before passing down
events) are used to indicate error, so they should not be notified if
the vnode does not have select().
Bug: 13965
Output-only events (B_EVENT_ERROR, B_EVENT_DISCONNECTED and
B_EVENT_INVALID, with B_EVENT_INVALID masked out before passing down
events) are used to indicate error, so they should not be notified if
the device does not have Select().
Bug: 13965
Output-only events (B_EVENT_ERROR, B_EVENT_DISCONNECTED and
B_EVENT_INVALID, with B_EVENT_INVALID masked out before passing down
events) are used to indicate error, so they should not be notified if
the filesystem does not explicitly provide an fd_select() override.
Bug: 13965
* use MergeObject even if we don't need the merged object: the rule does what
is needed and is standardly used for instance in libroot.so.
* add a grist to source files for the bootstrap glue.
SMAP will generated page faults when the kernel tries to access user pages unless overriden.
If SMAP is enabled, the override instructions are written where needed in memory with
binary "altcodepatches".
Support is enabled by default, might be disabled per safemode setting.
Change-Id: Ife26cd765056aeaf65b2ffa3cadd0dcf4e273a96
gcc does re-align the stack in the main() function prologue, however,
we still need to set the right alignment for other cases: thread entry,
.init and .fini code that is executed before main() is called or after
it has returned, and signal handlers which may use a separate stack.
Part of #10509
