My Haiku RISC-V port progress

Diver · May 31, 2021, 9:10pm

Probably arch related. Noto has any arch.

KapiX · May 31, 2021, 10:50pm

haiku/haiku/blob/master/src/kits/package/solver/libsolv/LibsolvSolver.cpp#L610


status_t
LibsolvSolver::_InitPool()
{
	_CleanupPool();
	fPool = pool_create();
	pool_setdebuglevel(fPool, fDebugLevel);
	// Set the system architecture. We use what uname() returns unless we're on
	// x86 gcc2.
	{
		const char* arch;
		#ifdef HAIKU_TARGET_PLATFORM_HAIKU
			#ifdef __HAIKU_ARCH_X86
				#if (B_HAIKU_ABI & B_HAIKU_ABI_MAJOR) == B_HAIKU_ABI_GCC_2
					arch = "x86_gcc2";
				#else
					arch = "x86";
				#endif

Seems to be related to uname returning unknown?

github.com

haiku/haiku/blob/8f16317a5b6db5c672f331814273e5857555020f/src/system/libroot/posix/sys/uname.c#L55


	strlcat(info->version, systemInfo.kernel_build_date, sizeof(info->version));
	strlcat(info->version, " ", sizeof(info->version));
	strlcat(info->version, systemInfo.kernel_build_time, sizeof(info->version));
	snprintf(info->release, sizeof(info->release), "%" B_PRId64,
		systemInfo.kernel_version);
	error = get_cpu_topology_info(&root, &count);
	if (error != B_OK || count < 1)
		platform = "unknown";
	else {
		switch (root.data.root.platform) {
			case B_CPU_x86:
				platform = "BePC";
				break;
			case B_CPU_x86_64:
				platform = "x86_64";
				break;
			case B_CPU_PPC:
				platform = "ppc";
				break;
			case B_CPU_PPC_64:

X512 · June 1, 2021, 2:21am

After fixing uname, and adding vesa driver to haiku.hpkg (it was included only for x86) haiku-minimum.image with package_fs enabled is working:

screenshot69

X512 · June 1, 2021, 2:58am

When compiling on RISC-V Haiku, headers/posix/limits.h is not included for some reason. It is supposed to be included by #include_next in GCC limits.h.

screenshot70

ModeenF · June 1, 2021, 8:13am

don’t know but ut feals that this port finds/fixes alot of stuff other ports will hit? Nice work. Feels good when one working on this and another one are working in the Intel driver . I need to boost my own development

jt15s · June 1, 2021, 10:27am

Seems that our ARM port is getting some attention, with @pengphei working on it. See this thread for progress updates:

X512 · June 4, 2021, 6:44am

Network is working, but only when running TinyEMU on Linux. On Haiku it also should work in theory, but some strange errors occurs (bad packet checksum, malformed reply packets etc.). Currently there are no web browser compiled for riscv64 to test. Maybe it is possible to compile Netsurf without Haikuporter.

Screenshot_20210604_152943

nephele · June 4, 2021, 7:36am

Yes should be possible, I did this on amd64 couple of times.
doc: https://source.netsurf-browser.org/netsurf.git/plain/docs/building-Haiku.md

edit: it looks like upstream webkit also supports riscv64, so that can be investigated in the future ( 222959 – [CMake] Build fails on RISC-V with GCC 11 )

Coldfirex · June 4, 2021, 11:02am

maybe one of the commandline web browsers (link, etc.)?

X512 · June 5, 2021, 6:34am

Networking is working on Haiku host, but only 64 bit. TinyEMU embedded Slirp library is probably broken on 32 bits. Not working ping is fine because it is not supported by Slirp library, ping is used to check DNS resolver.

screenshot18

X512 · June 5, 2021, 12:19pm

I fixed network for 32 bit TinyEMU. It was caused by hardcoded pointer size in slirp_config.h. File contents looks like it was generated by configure and then copied. Also I fixed bug in virtio_mmio driver, virtio completed packet counter is 16 bit, but driver used 32 bit counter to track what packets are already processed. That counter is intermened for each completed packet and expected to wrap on overflow.

I used Ubuntu disk image for download stability test. It worked fine but run out of disk space because 2GB is currently allocated for virtual machine disk.

screenshot72

leavengood · June 5, 2021, 1:28pm

Why is there 100% CPU use when downloading?

X512 · June 5, 2021, 1:33pm

Because software CPU emulation is slow. No JIT is used.

Per-thread CPU usage when downloading:
screenshot73

Coldfirex · June 5, 2021, 1:36pm

Bad a$$ X512!

leavengood · June 5, 2021, 1:39pm

Makes sense. Awesome progress, of course. I guess the next thing to investigate is why some of the files have Jan 1, 1970 as the date. Maybe you already know? Maybe it is just the system clock starts there?

X512 · June 5, 2021, 1:43pm

It is because TinyEMU have no calendar clock, only monotonic timer is available. But it can be easily added for example as additional HTIF function. TinyEMU is already customized for this port so probably there are no problem to customize it more.

Also note that Deskbar clock time is also wrong.

X512 · June 5, 2021, 2:21pm

Fixed. But already created files still has wrong date. Network time synchronization work.

screenshot74

cocobean · June 5, 2021, 3:09pm

You may want to review MTR (traceroute tool, in HaikuPorts)…

X512 · June 5, 2021, 3:10pm

Still not working for riscv64.

khallebal · June 5, 2021, 7:59pm

Do you have an image we can download and a patch for Tinyemu to use under linux?