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?).
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 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.
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.