Recently I testet a current image of NetBSD on the Pi and I had a quite well impression. The last time I tried, the filesystem got destroyed after trying to resize it. However, I identified two things that contribute to a very slow boot process: -One is postfix, which (I don´t know) may require quite much CPU or I/O. I think it is only necessary to deliver cron´s / at´s mails and - for this task - is pretty heavywight. -Two is devpubd, which seems to invoke several instaces of the MAKEDEV script. If I disable both of these things, the boot process becomes dramatically faster. Another thing I noticed is that X (even the mouse pointer) becomes sluggish when opening huge applications (I suspect this is also a CPU and/or I/O issue). The rest is great :) 2015-01-30 12:59 GMT+01:00 Jared McNeill <jmcneill%invisible.ca@localhost>: > I think at that time DEBUG and maybe LOCKDEBUG were enabled in the kernel. > No longer the case, and lots of improvements since then. SD card performance > is pretty good now, considering we don't support UHS-I transfer modes yet: > > undine# dd if=/dev/rld0c of=/dev/null bs=1m count=128 > 128+0 records in > 128+0 records out > 134217728 bytes transferred in 7.632 secs (17586180 bytes/sec) > > > On Fri, 30 Jan 2015, Stephan wrote: > >> That sounds great. The last time I tried a current NetBSD image on the >> Raspberri Pi, the overall performance subjectively felt a bit slower >> compared to Linux; e.g. regarding the boot time or SSH key generation. >> Though I didn?t perform any kind of benchmark. That was at the time >> when DMA support for the 2835 was just imported. >> >> Are there any benchmarks or known issues in terms of performance with >> the NetBSD ARM port or 2835 support? >> >> 2015-01-30 12:46 GMT+01:00 Jared McNeill <jmcneill%invisible.ca@localhost>: >>> >>> The kernel driver is BSD licensed (see src/sys/external/bsd/vchiq) and >>> source code is available for the userland libaries (EGL, GLES, GLES2, >>> OpenMAX IL, etc): https://github.com/raspberrypi/userland >>> >>> Once vc4 drm and the Mesa support matures, we can look into bringing that >>> in >>> at some point as well. >>> >>> >>> On Fri, 30 Jan 2015, Stephan wrote: >>> >>>> Hi >>>> >>>> How was this achieved? Wasn?t there mainly proprietary (Linux?) bits >>>> for 3D accelleration? The Mesa driver isn?t yet finished, is it? >>>> >>>> 2015-01-30 11:57 GMT+01:00 Jared McNeill <jmcneill%invisible.ca@localhost>: >>>>> >>>>> >>>>> Hi folks -- >>>>> >>>>> 3D graphics and hardware video decode are now working on the Raspberry >>>>> Pi >>>>> More info on the NetBSD blog: >>>>> >>>>> http://blog.netbsd.org/tnf/entry/raspberry_pi_gpu_acceleration_in >>>>> >>>>> Anybody want to package XBMC? :) >>>>> >>>>> Cheers, >>>>> Jared >>>> >>>> >>>> >>> >> >