* 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 <pulkomandy@gmail.com>
* 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 <kallisti5@unixzen.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Should constitute a minor performance gain, with no functional change
(the kernel ELF loader does not do any semantic interposition; or
any interposition for that matter.)
* 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 <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Signed-off-by: Jaroslaw Pelczar <jarek@jpelczar.com>
Change-Id: Ie043af5b7471f626a1ffe100848151c832dcc439
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1853
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Change-Id: If11a892665d08f61c46b5a6a5b4bf0453225c3ee
Reviewed-on: https://review.haiku-os.org/c/1533
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* 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
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.
It warns on snprintf's output "possibly" being truncated (e.g.,
two B_PATH_NAME_LENGTH chars being concatenated together) which may
be exactly the behavior the programmer wanted. So that's not very
helpful.
All of Barrett's individual reverts have been squashed into this
one commit, save a few actual bugfixes.
Change-Id: Ib0a7d0a841d3ac40b1fca7372c58b7f9229bd1f0
* I added this early on, but to be honest, any interesting
workstation class hardware would be riscv64.
* Since riscv32 is mostly embedded or low power, just drop.
Change-Id: Id36274c882c46e766268f2ab53eb1bd5f95227be
Reviewed-on: https://review.haiku-os.org/c/1352
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
On x86 and x86_64, this warning is never emitted because it is perfectly
fine to do unaligned access. On sparc, such accesses are not supported
by the hardware and will generate a SIGBUS. This must be caught by a
trap handler, and the unaligned access performed there, slowly, using
byte by byte access.
However, making this a Werror is annoying because it will trigger
everytime one casts a byte pointer to something larger, even when
alignment is actually preserved. So, removing all such warnings would be
nearly impossible (for example, just for the mergesort function, there
is a whole GSoC project for it at FreeBSD).
Keep it as a warning for now. The warning can be silenced by using
BytePointer, if desired. We should also investigate where the SIGBUS
trap is triggered a lot and consider improving the alignment of data
where possible.
Change-Id: I6b90025e8c6d69ef1ccda3c10eee270ccc1ebd29
Reviewed-on: https://review.haiku-os.org/c/1103
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Gets the stage0 bootstrap to run.
Imlementation is probably nonsense at this point.
Change-Id: I10876efbb54314b864c0ad951152757cdb2fd366
Reviewed-on: https://review.haiku-os.org/c/1061
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It warns when you try to use some standard library functions
without including the system headers, which we don't
care about as we are providing the system headers in the tree.
I added this here so that one could set -Wextra in BuildConfig and
not be bombarded with useless warnings; but it seems that GCC2 chokes
on it instead of ignoring it. Oh well.
* Move -fPIC to ccBaseFlags, as we don't want it in ASFLAGS.
* Remove -fPIC from BOOT_CCFLAGS, as we never want it in there.
* Move EFI flags to the actual EFI setup location.
Clang doesn't support -maccumulate-outgoing-args, -nostartfiles
is not needed in LDFLAGS (and lld doesn't know about it anyway),
and Clang uses .dynstr so we need to copy it also.
* I mean, qemu 3.0 supports it.
* Nobody get excited, we need all the triplets added to
our gcc buildtools. clang 7.0 seems to be cool with riscv though.
Change-Id: I17728163e4f28a3c16cee482a253364724b06f3a
* We're making the assumption about EFI here, but it's
fine since those defines will just go unused on non-efi builds.
* Jam segfaults when we get two for's, a case, and an if deep.
(adding an x86_64 check to efi section just below)
Change-Id: Id98e87b6570ddc7d9c2195cd05b0526e71771675
* Move MMU image to a real image define vs being crammed into
the u-boot bootloader Jamfile
* ARM not working yet, but better!
* x86 still builds
Change-Id: I3fb873dbac06fe2db893915b667bf3ce1df44686
* Store pointers in an addr_t instead of int32, for 64-bit's sake
* Use DebugSupport.h instead of userlandfs Debug.h and remove extra parentheses
* Create a header-only String class based on the userlandfs String and use it
* RecursiveLock instead of Locker.
* Jamfile cleanups and other misc. changes.
It isn't yet adapted to the new VFS API, so the build is still somewhat
broken.
The former is passed to the compiler when linking using it,
the latter is passed to ld when it is invoked directly.
Also modify ArchitectureRules to not overwrite this setting.
