* Add generic riscv64 support.
* Previously, missing architecture syscall.inc's would
result in obsecure unrecognized opcode messages.
* The logic should be identical, but with a friendly error.
Change-Id: I8f4878e99faf0f64465d2a27c3da2dd1e43c4ba5
Reviewed-on: https://review.haiku-os.org/c/1402
Reviewed-by: Alex von Gluck IV <[email protected]>
* 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 <[email protected]>
* This iSCSI implementation only worked on PPC big-endian atm.
* We're pretty sure iSCSI support in haiku_loader doesn't make
much sense anymore. iPXE on (on arm,x86,etc EFI/BIOS platforms)
supports iSCSI boot of disks.
* Haiku could use a iSCSI driver add-on, but it would exist much
higher up and likely use standard drivers vs bare-minimum iSCSI
target impementations.
* Leaving TCP and adding to all arches since it could make sense
for haiku's native network disk subsystem or network debugging?
Change-Id: Ic181b93a1d8ffd77f69e00e372b44b79abbddb42
Reviewed-on: https://review.haiku-os.org/c/899
Reviewed-by: Alex von Gluck IV <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
* First re-fix of what was reverted in 85f8e7001
* haikuporter calls these during bootstrap and needs absolute paths
Change-Id: I40f1b15ffd474d3286356f3151eacd9a4a09add2
* 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
* The PWD's are live based on jam run location which means
they shouldn't bind the generated directory to a fixed path
as before.
* We also need an absolute LD_LIBRARY PATH since haikuporter
loses the context invoking host tools.
* I don't think we can run jam from outside of the generated
directory anymore... but I don't think that was a thing.
Change-Id: I020f902ce5235bf268c9075d6e2ae85296a4ad20
* haikuporter's cwd is the haikuporter path during execution
(haikuporter/HaikuPorter)
* We have to pass the full working path and can't use a relative
path here
* Seems to fix the bootstrap build
Change-Id: Ibb139f164c5e08eda3a08136c4e9ea2c9eaeae9e
* The bootstrap process will pick up on local toolchains such
as clang and use them instead of the correct gcc cross-tools.
* This limits environmental factors which can break bootstrap.
Change-Id: Iacdd2a44cf26e18f838c9251fb9eddfbcb12565e
We won't need the mailbox for most chipsets except bcm2835
to determine the framebuffer base address.
(especially at this early boot stage)
This simplifies things by making the mailbox usage limited
to boot_arch_arm and not spreading it all thoughout the
platform u-boot code... however we keep the mailbox driver
as-is since it would make a good kernel driver someday.
mmu_man mentioned us "finding" the fb base from the mailbox
and modifying the FDT to let it know the base reg of the
framebuffer... that's beyond 'just getting things building'
though :-)
Change-Id: Ic2772b85dff004f9d21447ea5958b5ae9776d526
* 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
* haiku_loader is the hpkg name in system/packages and not the
loader name.
* bios_ia32 stage1 assumes the bios_ia32 loader is the first
file in haiku_loader.hpkg. This isn't ideal.. but space in
stage1 is *limited*
* Version font is https://fonts.google.com/specimen/Oswald
* We're no longer alpha, lets refine our logo a bit :-)
Change-Id: Ic7297944252e28281a928112ddf718b8ad5dbd62
* This gives us plenty of space for source packages.
* A Mini-DVD is 1.4 GiB, and USB sticks of 2 GiB are at
the sweet spot of low-price vs size.
* Unused space will be compressed in release zip.
* We blew by 700 MiB long ago. Sorry CD-R folks.
Change-Id: I3bbe4508777027f6fe7c0ee2992637541feeb88f
* Set url (identifier) as generic hpkg.haiku-os.org url
* Set base-url (actual repo location) as eu.hpkg.haiku-os.org (our eu mirror)
* Drop old "repository" url mess
I had a realization that haikudepot operates off of the base-url, if
we continue using old url's after r1beta1, we're going to be stuck
with all the symlinks and redirects for a looooong time.
This also opens the chance for us to go off of the generic "url"
for haikudepot identification, which will let it work when users
leverage mirrors.
Change-Id: Ic8fa954190cc26602911e133dd3c25ce2a96ce9d
* Realized we already had a function which iterates over
an fdt node and maps it's memory regs. Make it work for
physical mappings or identity mappings.
Change-Id: I0e3e323798bc2dfcead1accc1d403b30a8ab188f
* Consolidate all fdt code into fdt bus_manager
* Build boot and kernel static libraries
Change-Id: I2a69cd7e1f1276999a80734ff12918fd49b599e5
Reviewed-on: https://review.haiku-os.org/440
Reviewed-by: Alexander von Gluck IV <[email protected]>
* This fixes booting Haiku on Raspberry Pi and qemu (-M raspi2)
* Makes several assumptions which need corrected.
/axi is broadcom only
size is fixed
* The final solution will be "probing" each simple-bus device
from the fdt. A lot of fdt support code needs written though
for "finding" compatible devices and determining the full size
of the devices in memory.
Change-Id: Ifd5fbab7490c8456247115f5aada618909f1bb9e
We lost these tunings when I moved us away from board focused
builds. I feel like most of our ARM interest is around ARMv7+
Change-Id: Ie301d275a74d48ee3d0c4c7dc7d6cdd635288a7b
