* Add support for hubs in AllocateDevice().
* Prevent page fault in FinishTransfers().
* Set fCapabilityLength
* Correct in BIOS ownership code
* Fix context errors in _InsertEndpointForPipe().
* Update constants according to latest Specification (v1.1)
* Fix SMI code (reference
http://lkml.iu.edu/hypermail/linux/kernel/1204.2/02460.html).
* Fix Memory/Device-Slot leaks.
* Fix area allocation for TRBs.
* Fix for Intel Lynx Point and Panther Point chipsets. Also move init
of xhci before ehci, to switch USB 2.0 ports before the ehci module
discovers them.
Signed-off-by: Jérôme Duval <jerome.duval@gmail.com>
* There was a version mismatch between HaikuPorts gcc_bootstrap recipe
and build/jam/repositories/HaikuPortsCross/arm which prevented
building @bootstrap-raw for ARM. Thanks Ingo for helping out!
* Ditto for ppc, x86, x86_64.
Signed-off-by: Jérôme Duval <jerome.duval@gmail.com>
* Building gcc-4.8.3 on x86_64 with TLS support fails with an internal
compiler error. Until that problem is fixed, don't use TLS on x86_64,
which (due to libstdc++ compatibility) requires the same for the
host cross compiler.
* To avoid problems caused by the varying python versions used by the
different architectures, switch those packages from 'any' to explicit
architecture.
This also adds the libtool_cross_generic package to ARM bootstrap,
which seems to be required for building ncurses successfully. I did
not have the time to verify that this is the case for x86_64 too, so
I'm not yet adding it to there (yet).
Since hrev47198 we have ELF-based TLS support in Haiku. When building
gcc with haikuporter, this is detected by the configure script, but when
cross compiling gcc we need to manually enable it, as no runtime check
can be performed to detect the feature.
This should fix#10938 by avoiding the mix of TLS and non-TLS libstdc++.
* Cleanup the SD card image building to allow jam -q @bootstrap-mmc to
work.
There are a few remaining tricks before you can safely build an image:
* This uses a non-POSIX du option, and is only tested with Linux du
only (Linux is the only supported system to run bootstrap builds,
anyway)
* The Python recipe in haikuports.cross is known to not build on
Debian/Ubuntu, but work fine on OpenSuse. There is a patch available in
haikuports bugtracker to allow the reverse.
* You need to populate the haikuports repo package list with some
packages (which don't exist yet) to make the build system happy. But our
git hook to generate the repositories is preventnig me to share this
hack.
Once built, the image currently crashes early in the kernel execution.
On to debug that!
* That change did not make any sense, as the floppy-boot images
can't be built in debug mode anyway (the result is much too large).
This reverts commit 911821275a.
libalm.so is used by Stack & Tile as well as for the constraint-based
layout BALMLayout. This also adds libalm.so to the development package;
links it to /boot/system/development/lib.
* data files are still in the source tree.
* gutenprint headers contain a image.h header file which collides
with ours. This is solved by forcing include search first on
os/kernel directory.
* This solves the issue where libreadline wasn't actually linked to libncurses
* x86_64 update will follow later, as the build maxed out my x86_64 build VM
* Adjust the respective rules such that with disabled downloads, only
packages already available in the downloads folder will be considered
as available build features.
This way, the build system will not for instance try to build
<kdebug>qrencode after a bootstrap, as that package is not yet
available.
* If --no-downloads has been given, Haiku will be built without
trying to download anything, all required packages need to be put
into the download folder manually (the build will stop on missing
packages).
* As the required HaikuPorts repository can't be downloaded in this
mode, a local repository is created during the build, which only
contains the packages available in the downloads folder.
This is useful for building Haiku completely from source.
* The content of the preprocessed package-info files and the package
contents depend on the build type, so we use a different folder for
each build type.
Ideally, we would only need to set this in build/jam/board/*, but the
flags set there are not passed to the build of packages. The default is
using some early ARM variant, for which gcc lacks some more atomic
operations and emits calls to helper functions we don't implement.
Setting the default architecture avoids this, as all packages will now
be built to target the Cortex-A8.
Also set the proper VFP version in BeagleBoard config file.
Note this breaks the Verdex and Pi builds, but ARMv7 is what we should
focus on for now. We can try to make older archs work after finishing
the m68k port.
* This avoids mixup of the soft/hard float libs
* It also means we can use the hard-float libs for targets that supports
it
* Again, we could introduce an arm_softfp compiler for targets that
don't have floating point support, with a different gcc build.
* qrspec.h isn't yet part of the package for some reason.
* removed qrencode from the bootstrap package.
* only include qrencode when the qrencode package is found.
* didn't check qrencode itself, tests welcome.
