Let's make it easier to keep them in sync for now.
Change-Id: Ic0f1488c7f7da7770db56c25d07fb3ead5e3649e
Reviewed-on: https://review.haiku-os.org/c/1550
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This should not be necessary due to a note in the specification,
but it seems some controllers may not obey that; see inline comment.
Possibly fixes the "mouse slowness" of #15115 that began following
the Event Data changes.
The spec generally requires this feature, but some emulated hardware
(e.g. QEMU) does not support it. SPDK seems to just ignore the
error and continue on with a warning, so let's do the same here.
Change-Id: If11a892665d08f61c46b5a6a5b4bf0453225c3ee
Reviewed-on: https://review.haiku-os.org/c/1533
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Move host platform detection up, fix indentation.
If the host platform is a BSD (darwin|freebsd|openbsd) use stat -f,
otherwise use stat -c to check for a restrictive umask.
Change-Id: Ifb57eb69153221a23a84700445ff08a96517844a
Reviewed-on: https://review.haiku-os.org/c/1535
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
place parentheses around the '&&' expression to silence this warning
Change-Id: Ie6152d2371ed65f57e6e75c9541263a5e1511513
Reviewed-on: https://review.haiku-os.org/c/1532
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Change-Id: I1747de7afb2a5b2ec845c1c14f013dbcb9bd72f8
Reviewed-on: https://review.haiku-os.org/c/1528
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
* Now matches the rest of the architectures.
Change-Id: I6699e0c8f729923770f136f2c9599185a685336a
Reviewed-on: https://review.haiku-os.org/c/1527
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
* haiku_loader.u-boot doesn't fit in fat32 like haiku_loader.ub
* Adjust when writing. Update u-boot scripts to expect new filename
* Shrink loader partition to 32M, add our filesystem to end
Change-Id: I62936526a7dea2c41e26a7c0f9e05a368622a6a3
* For tracking, there are *mega* hacked together using
llvm's linker and functionality isn't a sure thing.
* Thanks waddlesplash for the sketchy changes :-)
* Hopefully gets non-bootstrap arm builds working again
and let us work on the toolchain without blocking arm
development.
Change-Id: I0617ed83cc757d098e6464222405f75eed91196e
The last time someone touched this directory, there was no floating
point support configured in ARM. Now we are targeting ARMv7a+, which
always has a hard FPU, so we need this now.
With this, a haiku.hpkg can (finally) be built again (at least
under lld, anyway!)
I am using this to use clang+lld for linking on ARM builds,
which seems to be more tolerant than binutils ld is, and
gets the build a bit farther for now.
The previous hack, which as the comment (and __MWERKS__) implies
dates all the way back to the Be era, finally broke: int32 is "int"
on non-x86, not "long", and so this generated an undefined symbol
error on ARM.
The best solution seems to be to make StartMenuBar merely protected,
and then make a subclass where it is fully public to call it.
This is a lot less fragile (and much less ugly.)
Change-Id: I0519d0d9eeb1cc4523d0c6dd4fdfe8688ed1092c
Reviewed-on: https://review.haiku-os.org/c/1516
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The changes in this commit are large but also subtle, so
an explanation of how they came to be seems to make sense:
Earlier today I tried booting Haiku on QEMU under USB3 ... and
discovered that it didn't work, with the "Operation timed out"
message from in usb_disk upon failing a data transfer. Indeed,
turning on tracing showed no event was being posted for the
transfer. So, I downloaded QEMU's source code, turned on XHCI
debugging, and began tracing what was going on.
Eventually I determined by adding more and more printfs into QEMU's
XHCI implementation that what was occuring was that it was evaluating
a Link TRB, hitting an empty TRB, and then deciding that the TD (aka.,
the "run" of TRBs) was not ready to be consumed, and bailing.
In fact, that very condition (a link TRB leading to an empty TRB)
is precisely what _LinkDescriptorForPipe did before this commit.
We allocate only a small (8 before this commit, 16 + 1 after this
commit) TRB ring for each *endpoint*, and larger ones on a per-*transfer*
basis; and just write Link TRBs onto the Endpoint ring pointing to
the transfer TD, and then one at the end of each transfer TD leading
back to the endpoint ring.
The reason this occured inside usb_disk, and not earlier (e.g.
during descriptor fetching), is that QEMU has special logic around
determining transfer lengths of control transfers which made it
not perform the "TRB valid?" check after evaluating the Link TRB.
So, being implementation-defined behavior, I am guessing that
this same problem was also the cause of boot failures on real
hardware.
This also means that the problem was essentially a race condition,
as if we posted another transfer to the ring before it evaluated
the TRB, it would always work.
The solution of course is to put some valid TRB at the end of
every transfer on the Endpoint ring. A "no-op" would have done
the job (well, maybe not, it appears QEMU does not implement "no-op"
TRBs for some reason), but there was another feature of XHCI
that we did not take advantage of: Event Data TRBs. These provide
the "total transferred length" as well as the status, instead of
the "remaining length" of the final TRB.
This of course required refactoring the use of the CHAIN bit
and the IOC bit (namely, more or less all TRBs save the Event Data
get the CHAIN bit set, and none save Event Data get the IOC bit.)
There was also an update to the XHCI spec since I've last committed here,
so the new comments are in reference to the "XHCI 1.2" spec. (I'll
eventually find time to update the old ones.)
Fixes booting from USB3 on QEMU, and most likely also on
bare metal, where it at least got to usb_disk (it does
not seem to fix the case where usb_disk does not even start.) Whew!
Adrien Destugues