On sparc, the minimal page size we can use is 8K. Since B_PAGE_SIZE and
PAGESIZE defines were hardcoded to 4K, this resulted in a lot of
confusion in all code trying to manipulate pages.
- Remove cpu.h from headers/private/kernel/arch/*. It dates back from
NewOS and was not used anymore since our kernel uses B_PAGE_SIZE
(PAGE_SIZE was the only thing defined in this header).
- Add posix/arch/*/limits.h with the arch specific page size and include
it from the main limits.h.
- Adjust bios_ia32/debug.cpp which was the only place using the
PAGE_SIZE constant from the deleted headers.
- Change OS.h to define B_PAGE_SIZE to be the same as POSIX PAGESIZE.
- Define PAGESIZE in the build header if the host OS doesn't.
Change-Id: I8c3732cf952ea3c2f088aa16d216678fbf198b96
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3558
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Fixes the ARM image to actually include Haiku within
a partition on the SD card.
* Drops the mtools requirement
* Drops the C/H/S requirements
Change-Id: Ie2776a09399ac181daab7a503e96e27ab7093af4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3608
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
- The quirk was not properly applied due to misuse of the device API
- The interrupts could run out of sync, leading to not properly waiting
for commands to terminate before reading their result. Add panic to
check for that (at the start of the next command) and fix the code.
Change-Id: If83b7bbb3c3446d374115ed22c09b91020028578
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3609
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
I built only the bootloader for sparc when testing, so some code was
disabled because it's guarded by _BOOT_MODE.
Confirmed that the generated assembler is not larger than before (the
disassembly file is the same size, but for some reason functions were in
a different order, making it difficult to compare more closely)
It needs to be done once per device and only after we have decided that
the device is supported and should be handled by the driver.
Change-Id: Ia00c1fbb151ab181abbfcfaed538cf58985aea07
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3601
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The BFS on-disk data is not aligned. Reading it to memory and trying to
access fields directly does not work on sparc. memcpy the data to an
aligned variable before handling it with its native size.
gcc knows how to access unaligned data, but we need to tell it when to do
so. This is done with the "packed" attribute, but it works only on
structs. So we have to wrap the values in a struct.
Thanks to C++ features, we can make the struct
relatively transparent by having an assigment operator (for writes) and
a cast operator (for read access), so there is no need to access the
value inside the struct with ".value" everywhere. The rest of the code
is then largely unchanged (except for use in printf statements and other
vararg functions, where the implicit casting can't work).
gcc takes care of performing the access in the correct way on platforms
that need it (old ARM, sparc) and can still optimize things on other
architectures where specific code is not needed for unaligned access.
Fixes#9255
Change-Id: I3bf62590dee059ad32b1845bdc4eace165b73203
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2363
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The NetworkStatus applet by default only shows the first address
on the interface, assuming IPv4 semantics and ignoring others.
This assumption doesn't hold true for IPv6-enabled systems, which
not only have both IPv4+IPv6 addresses, but typically multiple
IPv6 addresses (link-local and global at a minimum).
In addition, it's not unheard of to have multiple IPv4 addresses
on a single interface, even though it's difficult to configure in
Haiku at time of writing.
This change loops through all available addresses and prints them
in the status.
No attention to ordering is made; future enhancements could
include sorting IPv6 global/link-local, displaying the type, etc.
Change-Id: Ib437e32fc878b5baafa8c2437659e10fb6fcffbf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3550
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Package files to be committed may already exist in the packages folder,
there is no good reason to fail the transaction. These may be packages
which are not activated, or there may be other reasons. While I have
not investigated how this situation may form, I don't see a good reason
to spend the time. Simply compare the contents of the existing file
with the file from the transaction, only fail if they are different.
Change-Id: I2a574df38385c8dead8bac2beace94436d43760a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3597
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
There is a quirk needed to switch the controller to standard SD mode
(copied from FreeBSD).
The response type configuration for R7 response was incorrect, this
response type does not have a data phase. This made the Ricoh SDHCI
implementation generate an unexpected "transfer complete" interrupt,
while apparently the implementation in QEMU didn't.
The interrupt generation is a bit different from what I got in QEMU
when developping the driver, for some commands, we get only a
"transfer complete" and no "command complete" interrupt as I'd expect
when the command completes.
This is handled in the following way:
- The interrupt always releases the semaphore to notify that something
has happened (once per event)
- When the main thread waits for an event, it always uses the same
pattern:
while (!condition)
acquire_sem(...)
This pattern makes it not wait at all if the condition is already
satisfied. If the interrupt triggers later or already happened when the
code gets to execute this while loop, the semaphore can be left with
some tokens in it. These will be emptied the next time the thread waits
on something.
To make sure ths works properly and everything is synchronizing as
expected, some extra checks are added before execution of a command to
make sure the hardware is in the expected state.
There is also lots of extra tracing, I prefer to leave this enabled
initially and wait for some other users to test this new driver on their
hardware. When we are confident enough that it is compatible with
several implementations, we can reduce the tracing or turn it off.
Change-Id: Ib9617dbea62f87124dbaad0027b53a13d949641f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3600
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
The main differences:
- The initialization sequence requires an additional command (this was
already done)
- The layout of the CSD register and the way to compute the device
geometry from it changes
- The read and write commands parameter is a sector number instead of a
byte position
Change-Id: Ie729e333c9748f36b37acd70c970adfd425cf0b6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3512
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
- The restrictions are now set by the sdhci bus and retrieved from there
by the DMAResources.
- Configure SDMA with the maximal available boundary check of 512K and
publish the corresponding DMA restrictions.
- dma_resource cannot be initialized implicitly as a member of
mmc_disk_driver_info because mmc_disk_driver_info is allocated with
malloc/free, not new/delete. So we now explicitly allocate and delete
it.
This allows reads and writes of more than a single block at a time.
Change-Id: Ibb97c91543312c7970c28a7a8c68a12708263e32
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3505
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
The SDHCI spec also offers an "advanced DMA" mode where we can use
scatter-gather lists. It would allow to remove several of the DMA
restrictions, but hardware support for it is optional, so we need this
version anyway.
The geometry is retrieved on demand in the first read or write or in a
call to the get geometry or get device size ioctl. It is not possible to
retrieve it from the device initialization because that is called as
part of the mmc_bus scanning, which needs a specific sequence of
commands and keeps the bus locked to prevent drivers to insert their own
commands in the middle of that sequence.
TODO:
- Move the DMA restrictions definition to sdhci_pci and forward it up to
mmc_disk (which is the one creating the IOScheduler)
- Decide if we want to keep non-DMA support (probably should, but it
makes things more complex, because it uses virtual addresses)
Change-Id: Ib1dd14eacf62052d747bfb3ef7820bc5a34d3030
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3471
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* The "default" of 3MiB wasn't enough for modern larger media
formats, resulting in inability to play 4k video no matter
how much horse power you threw at Haiku. (4k is ~8MiB)
* This dynamically calculates the ChunkCache based on the
video framesize * 2.
* 4k video now plays smoothly on my Ryzen 1800x.
Change-Id: I65bf6bd6fa60ac3196ea70eeeb5e655d43c10bcd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3598
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Mostly the same as PowerPC, using OpenFirmware.
Change-Id: I197cc181e92da92c272ee9cfa20c8ad2d2c63d41
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3579
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
If we need to display some text during boot, it's nicer to have it on
top of the splashscreen, rather than scroll the display down.
Change-Id: I897073d31120ec3eebd2edc4632960db7eb7977d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3596
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The manually written code was all wrong (missing branch delay slots,
wrong type of return instruction used, probably more bugs). Use the same
approach as x86 to have inline functions instead, which is much better
for performance and simpler to write.
Change-Id: Iac0fc814c15311658f983da58ac7f9d3edd75b81
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3595
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The definition in SupportDefs.h using gcc builtins is sufficient. No
need for a custom one. The same approach is used on x86 with gcc8
already, but other platforms had not been adjusted to use it.
Change-Id: I3973ff723a31f90cc8d19ac098eb1e85d471d610
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3594
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Our bootloader really doesn't want the executable section to also be
writable (even if it needs to, for relocation purposes).
Force it to be read-only in program headers by explicitly setting the
flags.
Change-Id: I5b780f6fd9df5f073f0cbc6cc96bc21479004d2c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3584
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The sparc ABI reserves the g7 register for this.
Change-Id: I93b81ecef72cde859972ef7b7f6b9991d35f9f29
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3583
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This was copied from PPC and is not done on any other architecture.
Having the stack use the kernel address results in the kernel being
loaded elsewhere. Not really a problem (the kernel is relocatable), but
it's annoying when debugging as addresses need to be converted between
the elf file and the actual loading address.
Change-Id: Iab25af1fb8998b7ef5c583459c134aea80be8d72
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3581
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Currently about 366K are used. Round up to next power of two.
Change-Id: Id6713b4f4eebfbced310bbd75a16a5737228ae72
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3577
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The code was ignoring most of the memory and eventually didn't find
enough of it to load all kernel modules.
Change-Id: I8abcb6cd20eb2a37147d720eb63af1c2820628f3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3576
Reviewed-by: waddlesplash <waddlesplash@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>
It's hard enough to debug bootloader code already, let's gather as much
info as we can from error messages.
Change-Id: I47dff402286625d1213caa36ae6ee8ecf707dfad
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3574
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
We now have a bootsplash on sparc!
Change-Id: I583a3015a86618292088fe4379f548467d30ec4f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3572
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is what our bootloader expects. For some reason, ld does this by
default on x86, but not on other platforms. So, define the headers
ourselves.
Change-Id: I4b37938e7e6d48b19c8af68cf4a77193269335d4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3569
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The realtime clock is used only to seed the random number generator for
picking a random TCP port. This is not very important, so there's no
reason to completely fail when it doesn't work.
Change-Id: I50123433153c16595118fdf923f4b707e2c98fdd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3568
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The elf region structure is packed. So it's not possible to use a
pointer to one of its fields on sparc. Use a temporary variable that's
properly aligned.
Change-Id: I9dd9b9f2b1d14821e34bc2f5b3da661086ef3fef
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3567
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Some code was enabled only for EFI, but is in fact correct for all
platforms except BIOS. Switch the defines around to have the correct
code enabled by default.
Change-Id: I58b1d17a78dcf273ceee88318338b4770b500bb3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3566
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
