On 29 July 2015 at 07:42, Takumi Shimada <[email protected]> wrote: > Hi all, > > I am also interested in running rump kernel to use NetBSD drivers. > I plan to run rump kernel on the bare metal ARM board and use network > driver. > I wonder how to configure hardware information (e.g. like Linux's > DeviceTree) and how to implement hypcalls. > I have downloaded rumprun, frankenlibc and genode. But I cannot understand > how to implement hardware specific parts for rump kernel. > Could you explain what should I do for running drivers or tell me good > examples which implement hardware specific parts?
Is the board you are porting to already supported on NetBSD? NetBSD does not use devicetree but this article explains the basics of how config works on Arm http://www.netbsd.org/docs/kernel/porting_netbsd_arm_soc.html To get frankenlibc working, start by copying platform/qemu-arm and adjust the platform.sh and link.ld files as needed, then implement the __libc_start_main.c for the platfom init, and write.c to write to console. That should boot but you will then need to add a real clock driver and memory allocator, although the dummy ones should still boot. Justin > Thanks, > Takumi > > > > 2015-07-25 0:39 GMT+09:00 Antti Kantee <[email protected]>: >> >> On 24/07/15 14:58, Tony Zhang wrote: >>> >>> Hi all, >>> >>> I am quite new to this project and I have downloaded and looked around in >>> the >>> repo for some time. We are interested in using parts of rump kernels in >>> our >>> research OS. Specifially, we'd like to add more drivers to our OS, and >>> running >>> NetBSD drivers inside rumpkernels seems like a really good way to do >>> this. From >>> my limited understanding, this requires that I implement some hypercalls >>> used by >>> said drivers. I think I am on the right track but there seems to be more >>> to it >>> so I would appreciate your thought on this. Is it viable? >> >> >> Well, you obviously need to interface with the drivers somehow from your >> OS. Unlike POSIX'y syscalls, there's really no standardized interfaces for >> interfacing "into" the kernel. Check out section 3.6 of book.rumpkernel.org >> (1st edition) for some clues. Interfacing through syscalls might work too, >> but it's not possible to list the tradeoffs without knowing more about your >> case. See also http://wiki.rumpkernel.org/Platforms#integrating >> >
