Me not yet, don’t have one. But seeing your progress I am definitely interested and will probably try to get one in the near future.
Of course I will want to try to get Nvidia going and maybe matrox in that case… I do hope multiple cores will work by then so we get max speed from the system 
Thank you very much for your dedication on this project!
Works for me using an ancient Radeon GPU (still ATI labeled) – great work! The display is a bit stretched, since the system is connected to a wide screen monitor. USB keyboard and mouse also work, but it seems that the kernel can’t find the Ethernet interface (or this required some setup or loading a driver?).
Nice! Though that’s a very old (c) year: 2008 
Year is calculated from RTC clock. There are no driver for HiFive Unmatched RTC so 1970 year is displayed at boot. Time can be set manually and copyright date in AboutSystem will be fixed.
There are no Ethernet driver for SiFive Unmatched for now, it is not PCI device, it is FDT bus device from OS perspective. It should be ported from FreeBSD of written from scratch. USB Ethernet or PCIe WiFi may work with existing Haiku drivers.
It may be possible to change screen resolution in Screen preference.
That explains it 
. I tried to connect an ancient ASIX-based Apple USB to Ethernet adapter, this is detected but the driver complains about a bad parameter:
usb_asix:04.15.576:Read::Error of queue_bulk_v request:0x80000000
PMA: bad value for allocate (27487790720 bytes)
usb error xhci 0: failed to allocate TRBs
So I guess it’s time for me to start debugging drivers…
Yes, that worked nicely, I have lots of screen space now!
I also found haikuports.cross problem that Bison package include Linux binary instead of Haiku. It doesn’t run on Haiku.
Pe is mostly compiling, only PCRE and Bison are missing.
I got infinite recursion in ld when I tried to compile Bison with autotools. Stack stace is so long and UART is slow so writing full stack trace takes a lot of time. System is still running, but ld thread takes a lot kernel CPU time to print stack trace to UART. Thread is also unkillable until stack trace finishes.
<libroot.so>ffs seems to be miscompiled or incorrectly implemented.
FP: 0x37f7a01220, PC: 0x12f7a2c337 <libroot.so> ffs + 15
FP: 0x37f7a01230, PC: 0x12f7a2c337 <libroot.so> ffs + 15
FP: 0x37f7a01240, PC: 0x12f7a2c337 <libroot.so> ffs + 15
FP: 0x37f7a01250, PC: 0x12f7a2c337 <libroot.so> ffs + 15
extern "C" int
ffs(int value)
{
return __builtin_ffs(value);
}
__builtin_ffs() have no inline implementation for riscv64 GCC and it calls ffs() causing infinite recursion.
To me the recipe looks ok: haikuports.cross/bison_bootstrap-3.0.5.recipe at b98463ad4a26f6f9a6661d60dda3cc1777ce8c92 · haikuports/haikuports.cross · GitHub
Perhaps it should look more like the older recipe? haikuports.cross/bison_bootstrap-2.4.3.recipe at b98463ad4a26f6f9a6661d60dda3cc1777ce8c92 · haikuports/haikuports.cross · GitHub
Is “27487790720 bytes” the buffer size it’s trying to allocate? That would make it 25Gb: looks like huge to me
I’m still trying to figure out where exactly the allocation takes place. But 27487790720 = 0x666666680, so I suspect there’s a memory alignment/data size problem somewhere in the driver code.
I would rather think of some erroneous computation with signed / unsigned integers. Something like (unsigned) -1 = -2147483647. Now in hexadecimal, 0x0.6666666… = 0x0.(6) = 6/15 = 2/5. It could be some computing starting with -1 (but assuming it unsigned) followed by some multiplication / division and then addition of some small offset, which leads to 0x666666680.
Still the same problem:
user@localhost:~/Packages/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build> readelf -h /home/user/Packages/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/bison_bootstrap/work-3.0.5/sources/bison-3.0.5/src/bison
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x403b50
Start of program headers: 64 (bytes into file)
Start of section headers: 1562296 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 13
Size of section headers: 64 (bytes)
Number of section headers: 39
Section header string table index: 38
user@localhost:~/Packages/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build> readelf -d /home/user/Packages/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/bison_bootstrap/work-3.0.5/sources/bison-3.0.5/src/bison
Dynamic section at offset 0x56e00 contains 25 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000000000000c (INIT) 0x403000
0x000000000000000d (FINI) 0x43fb54
0x0000000000000019 (INIT_ARRAY) 0x457df0
0x000000000000001b (INIT_ARRAYSZ) 8 (bytes)
0x000000000000001a (FINI_ARRAY) 0x457df8
0x000000000000001c (FINI_ARRAYSZ) 8 (bytes)
0x0000000000000004 (HASH) 0x4003c0
0x000000006ffffef5 (GNU_HASH) 0x400738
0x0000000000000005 (STRTAB) 0x401378
0x0000000000000006 (SYMTAB) 0x4007f0
0x000000000000000a (STRSZ) 1410 (bytes)
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000015 (DEBUG) 0x0
0x0000000000000003 (PLTGOT) 0x458000
0x0000000000000002 (PLTRELSZ) 2376 (bytes)
0x0000000000000014 (PLTREL) RELA
0x0000000000000017 (JMPREL) 0x401b70
0x0000000000000007 (RELA) 0x401a50
0x0000000000000008 (RELASZ) 288 (bytes)
0x0000000000000009 (RELAENT) 24 (bytes)
0x000000006ffffffe (VERNEED) 0x4019f0
0x000000006fffffff (VERNEEDNUM) 1
0x000000006ffffff0 (VERSYM) 0x4018fa
0x0000000000000000 (NULL) 0x0
The same with python3.
Problem seems to be solved by adding following options to configure: --build=$buildMachineTriple --host=$targetMachineTriple.
I compiled Pe text editor directly on hardware without cross-compiling. PCRE is currently disabled.
Nice, that should be the right way. Another thing to check is the gcc-bootrstrap and the binutils that may not match what is in buildtools that well.
I am thinking this is our problem: Installing Python Modules (Legacy version) — Python 3.9.6 documentation so maybe by default it just copies libs…