* Try to return relevant errors when we can.
* The style on these needs cleaned up badly.
* I don't want the fix to be lost in style changes.
Change-Id: I8a1661385fbeb8eec86a2c15828b449980050a78
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3386
Reviewed-by: Jérôme Duval <[email protected]>
* IEEE Std 1003.1-2017, read, write
* golang performs a write of 0 length with a NULL buffer to
"create" an empty file. We return BAD_ADDRESS for this.
* If condition above occurs, continue as a length of 0 means
we won't read the passed buffer.
Change-Id: I8718abb92f5865a7b6f4fb7f2b74f803497ebef0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3285
Reviewed-by: Alex von Gluck IV <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
* If you're building a hybrid, each arch directory gets included.
* If the architectures are all non-legacy, you end up getting
"all architectures" built in each architecture directory.
* This prevents this condition by filtering on sane architecture
matches per arch directory.
Change-Id: I529e2b3d315b0930aff594239dadd9db70dc9cfa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3316
Reviewed-by: Alex von Gluck IV <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
* This was originally added circa 2012. via hrev43954
* Our toolchain appears to work fine now with explicit
multilib enabled.
Change-Id: I1f5d55c63a6b3b6ab1c4db95da3d14d5ef2da0df
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3315
Reviewed-by: Jérôme Duval <[email protected]>
* This looks wrong, but is functionally equal.
* Supposed to return a MouseSettings*, but returned
a B_OK (0) on a seemingly error result (NULL).
Change-Id: Id6c50369790b90e38fd6ec037c466c5fb314edf5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3303
Reviewed-by: Adrien Destugues <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
* Essentially, EFI system partitions are just FAT32 formatted.
* We really haven't tried EFI booting on MBR (normal choice is GPT)
* I see no reason to *not* allow folks to create these.
* Align partition name to GPT's naming
Change-Id: I4cd52d542ea618f1ffe52927e15237fc10bb386c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3224
Reviewed-by: Alex von Gluck IV <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
* Tianocore is still in an early state for RISCV64 with a lot of work
needed around qemu support.
* u-boot however is working, and can load EFI binaries... so follow the
arm model for now. (EFI via u-boot, or EFI via EFI Bios)
Change-Id: I3dfde25db17b114aedce6faefc58d7556e17a46a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3176
Reviewed-by: Alex von Gluck IV <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
* mmc might be not ideal. But raw is just a single partition and
anyboot is heavily x86. MMC will technically work for now to get
bootable images.
* floppyboot isn't used on EFI platforms, since we call two different
actions, just drop floppyboot altogether on EFI SD Images.
Change-Id: Idabb5483304007dd601bf8a1158036ffd24f73aa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3165
Reviewed-by: Adrien Destugues <[email protected]>
* An upstream bug exists which results in the tianocore
bios crashing when attempting to read from qemu's
(unconfigured, but present) flash device.
Change-Id: Ie9f02a290abc29cce3a5e279382750c0b14164dc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3049
Reviewed-by: Adrien Destugues <[email protected]>
* BSolver is implemented by solver add-ons
* We may want to (unlikely) leverage another
package solver in the future.
* We may want to (likely) implement a dummy
solver when libsolv is unavailable on new
architectures without bootstrap.
* This also makes solving missing libsolv a little
more graceful vs the "include "libsolv.h" not
found.
Change-Id: Iedd9d0f022fb743c4c7606bd33a4b6dbef0576f7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/819
Reviewed-by: Adrien Destugues <[email protected]>
* Migrate some platform agnostic architecture code into
boot/arch from efi/arch. This helps to avoid conflicts
between kernel and boot sources as well.
* Conflicts between arch_cpu in efi and kernel code means
bootcode really should *never* directly use kernel arch
headers. (other platforms don't, which is why they don't
have this same issue)
* We carefully thread any needed kernel headers (namely
assembly helper macros) into the bootloader headers without
mixing in the whole conflicting kernel/arch headers.
* ARM now properly get its cpu init code called, and we
progress further into the EFI bootloader.
Change-Id: If67ec9758b5ce68563ebd9eb45d5196401911c67
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2975
Reviewed-by: waddlesplash <[email protected]>
* Otherwise, important HAIKU_BOOT_* flags don't make it into
the build commands.
* Ensure any external sources used by EFI get recompiled
vs reused due to potential differences in wchar length
(EFI dictates short-wchar, but no wchar's in our code)
Change-Id: I7a4a0347d39239c73fa510378e048f51be1cd360
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2965
Reviewed-by: Alex von Gluck IV <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
* boot.scr was growing past Jam MAXLINE and was causing segfaults
* Break out to tree, data/boot could be used for other arches
* boot.scr is getting a bit complex, but supports the old
u-boot haiku_loader, as well as u-boot starting our EFI loader.
Change-Id: I93a3167ab0bc78747c1d70fedd08595e9ac89662
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2963
Reviewed-by: Adrien Destugues <[email protected]>
* Stub out makebootable like on u-boot
* Place haiku_loader.efi at EFI/BOOT/BOOTXXX.EFI
* Generate boot.scr for u-boot + EFI
* haiku-mmc.image now attempts to auto-boot in qemu-system-arm
* Same code paths should roughly apply for arm64,riscv,etc
Change-Id: I563ebd77422d9e5dfcfeeedadcbc60471e8a57f4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2938
Reviewed-by: Alex von Gluck IV <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
* This should 'fix' the arm build
* No longer parse FDT in bootloader, just pass ptr.
* The EFI loader doesn't load yet on arm
* It compiles though. Ship it!
Change-Id: I7c8ce588298dfaf4fba8054c6b6d9a92733b5943
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2903
Reviewed-by: Alex von Gluck IV <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
* These are hand plucked from Linux's atombios parser.
drm code has been leaking into Linux's version :-|
Change-Id: Iaab4f474edf57f0e5011e20a21bd1036b54ba47c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2912
Reviewed-by: waddlesplash <[email protected]>
* Store gFDT as a global in efi to appease non-x86
* gFDT might need refactored out of fdt bus_manager?
Change-Id: I3fb1be04ceb696677aa5476381786c36adc6fc0a
* We *might* no longer need FDT knowledge in the bootloader?
* For now though, arm sources reference gFDT, so we need it.
* Need to move away from lazy gFDT and store in arch_kernel_args.
(which is next and will be a larger commit)
Change-Id: I77cce0fc645143b78a7fd9f50ac8b96c97b5c862
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2268
Reviewed-by: Adrien Destugues <[email protected]>
* arm efi additions
* cleanup some cpu headers which were oddly
split between efi and bios_ia32
* Move calculate_cpu_conversion_factor over to
arch_timer since it is timerish, and x86 only
* Drop some duplicated code from efi start. Move
hpet init code into efi timer/hpet code
Change-Id: Ia4264a5690ba8c09417b06788febc4f572f111ce
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2259
Reviewed-by: Alex von Gluck IV <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
* This is the bulk of the work. Anything else should be
minor cleanups and tweaking.
* riscv64 isn't a viable EFI platform yet.. just acting
as a stand-in to test a non-x86 EFI haiku_loader
Change-Id: Ib03de81e2b562e693987b86d7b4318209fb1c792
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2256
Reviewed-by: Alex von Gluck IV <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
* "xorriso doesn't support much of the mkisofs options"
* Dropping the hfs map made our bootloader no-longer get
mapped as :tbxi which means qemu + Apple devices refused
to boot it.
* Switch to genisoimage which can generate the correct image.
(xorriso -as genisoimage doesn't work either)
Change-Id: Id71b97796f5004f6ddf6244644c51a5787f9bf8e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2241
Reviewed-by: Alex von Gluck IV <[email protected]>
* A few tips for future folks follows.
* fenv.h gets wrapped in our buildtools
* If anything in the arch fenv.h "doesn't work" buildtools
will silently fail early on (autotools HAVE_FENV_H)
Change-Id: Icae064fde42af3bbed5ea2eadfaa8c18c677e6a6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2164
Reviewed-by: Alex von Gluck IV <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
* Move x86 hpet behind timer interface.
* Add a few if x86,x86_64 macros to start.cpp.
Change-Id: I583ec1b064785182e6d48dfbcd91b1bb2ead4b44
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1929
Reviewed-by: Alex von Gluck IV <[email protected]>
* After a bunch of trials, the groupings for VPN and Dial-up
connections look too busy. By putting the "connections"
at the same level as the interfaces things get a bit clearer
and a little more modern.
* Lots of work to do still for "adding / removing" connections.
