Re: CVS commit: src/sys/arch/usermode
Is possible to have vncfb as a general NB device commonly useful across various ports? There are a number of headless computer-alike products around us and vncfb could be a break-thru making them into general purpose NetBSD boxes. Module Name:src Committed By: jmcneill Date: Thu Dec 29 21:22:49 UTC 2011 ... Modified Files: Added Files: src/sys/arch/usermode/dev: vncfb.c vnckbdmap.c Removed Files: src/sys/arch/usermode/dev: genfb_thunkbus.c Log Message: Replace the SDL based genfb driver with a wsdisplay and wskbd driver that implements the VNC (RFB) protocol. To enable the VNC server, add 'vnc=640x480,5900' to the kernel command line (where 640x480 is the desired fb resolution and 5900 is the TCP port). Screenshot of it here: http://www.netbsd.org/~jmcneill/usermode.tiff Toru Nishimura / ALKYL Technology
RE: CVS commit: [matt-nb5-mips64] src/sys
Committed By: matt Date: Wed May 25 23:58:51 UTC 2011 Modified Files: ... Log Message: Make uvm_map recognize UVM_FLAG_COLORMATCH which tells uvm_map that the 'align' argument specifies the starting color of the KVA range to be returned. ... Make the socket and pipe loan color-safe. ... Make the mips pmap enforce strict page color (color(VA) == color(PA)). Oh, YES! So, NetBSD is now the world's first VIPT cache aware OS, isn't it? Since the introduction of MIPS R4000, OS designers have been in trouble about how to make VM VIPT cache coherent. The answer was simple; make sure to have colour(VA) == colour(PA). Toru Nishimura / ALKYL Technology
Re: device major numbers
Frank Wille said; either way, 144 is wrong. Ok. So you would suggest to allocate 100 for all powerpc ports? arch/powerpc/conf/major.powerpc contains gtmpsc for Marvell Discovery PPC system controller which is particular for a very specific platform. Then, it'd be forgiving to cope with having char 100 line in the powerpc common definition. Toru Nishimura / ALKYL Technology
Re: CVS commit: src
Simon Burge pointed; Added Files: [ ... ] src/sys/arch/emips: Makefile Out of curiosity, was there any thought is adding this to evbmips instead of getting its own top-level arch subdir? I think the independent port is acceptable as it's intended for a research platform to fourlish instead of as engineering samples of a particular SoC. Over use of evb* umbrella spoils the potentials, so I believe. Toru Nishimura / ALKYL Technology
Re: CVS commit: src
Antti Kantee said; eMIPS is a platform developed at Microsoft Research for researching reconfigurable computing. eMIPS allows dynamic loading and scheduling of application-specific circuits for the purpose of accelerating computations based on the current workload. NetBSD eMIPS support for NetBSD 4.x was written at Microsoft Research by Alessandro Forin and Neil Pittman. Microsoft Corporation has donated full copyright to The NetBSD Foundation. Could you provide us the reference pointer to the eMIPS project? It's long time ago last I saw Mr. Forin name in CS research field. Toru Nishimura / ALKYL Technology
Re: CVS commit: src/sys/arch/pmax/stand/common
Hmm, but `boot' variable (3/rz2/netbsd -aN) is still kept and `enet' is cleared even after abort by haltbutton without powercycle. Anyway, NULL pointer dereference is a bad thing. The original code used to be ok for long time, at the age. Toru Nishimura / ALKYL Technology
Re: CVS commit: src/sys/uvm
Masao Uebayashi uebay...@tombi.co.jp responds as; The VIPT rule is simple; just make sure to match colour between VPN and PFN. Hmmm. I've thought that the page colouring constraint is *should*, not *must*. Colour match between VPN and PFN is *must* If not obeying the rule, it's possible two or more cache index is selected for given a physical address. Consider the reason why VIPT alias issue vanishes when PAGE_SIZE is increased. It would make the number of colour into one _by_matching_ low order bits (= colour selector field) of VPN and PFN. Toru Nishimura / ALKYL Technology
Re: CVS commit: src/sys/uvm
Some more rambling commments; Colour match between VPN and PFN is *must* There are two cases when colour match rule does matter; 1. new physical page is assigned for a given va. - just make sure to choose matched PFN with VPN. 2. kernel double maps another va, which may be KVA or UVA. - just make sure to choose a matched va. - for example, vmapbuf() is responsible to do it right. Infamous SOSEND_NO_LOAN option fails into the second case. ipc_socket.c is apparently ignorant about KVA colour matching. It ends up with potential VIPT alias by choosing conflicting KVA to make double map. The most common usage of mmap(2) is like; va = mmap((void *)0, ... ); Kernel is free to choose and return va which fits at colour boundary. If conflicting va is given in the 1st argument, mmap neglects the hint value and choose matched va which may or may not be close to the hint. For each port, it's just ok to tell UVM the number of colour at boot time. In PIPT system, the number is one, which makes whole VM logic works just as before. In VIPT system, determine the number of colour from cache size and way count to tell. No pmap fixup code is necessary. I would emphasis here that whole VIPT issue lies in MI part of VM, which is unware of colour match scheme and makes VIPT alias by itself, not in VM MD part. Toru Nishimura / ALKYL Technology
Re: CVS commit: src/sys/uvm
Matt Thomas modified UVM colour matching scheme; Modified Files: src/sys/uvm: uvm_extern.h uvm_fault.c uvm_km.c uvm_page.c Log Message: Add better color matching selecting free pages. KM pages will now allocated so that VA and PA have the same color. On a page fault, choose a physical page that has the same color as the virtual address. This change is a big forward-reap to have VIPT-safe NetBSD VM for R4000 and modern ARM. Combined with matched KVA selection against UVA, found in vm_machdep.c::vmapbuf(), there remains little ocasion where VM chooses mistakenly wrong colour combination to bind VPN and PFN. The entire effect is to eliminate the necessity of VIPT fixup efforts in port-specific pmap.c and ends up with improving the cache effeciency in large degree. This is _the intent_behind VIPT design. So far OS virtual memory strategy paid little attention to make VIPT cache work correctly. Toru Nishimura / ALKYL Technology
Re: CVS commit: src/sys/uvm
Masao Uebayashi uebay...@tombi.co.jp responds as; The entire effect is to eliminate the necessity of VIPT fixup efforts in port-specific pmap.c and ends up with improving the cache effeciency in large degree. This is _the intent_ behind VIPT design. So far OS virtual memory strategy paid little attention to make VIPT cache work correctly. It'd be nice if we can really eliminate VIPT fixup *code* in pmaps. And I *think* this is possible if we don't remap pages using pmap_kenter_pa(). The VIPT rule is simple; just make sure to match colour between VPN and PFN. It's the mandatory programming practice. This rule is clearly documented in _many_ CPU architecture documents with VIPT cache. - mmap(2) must refuse to map mixed colour VA. - dynamic linker should pay attention to map share library at colour boundary. This ensure cache lines shared between processes. Toru Nishimura / ALKYL Technology
Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips
David A. Holland said; Change MIPS_CURLWP from s7 to t8. ... Huh. That surprises me slightly. Good to know though. Remember to bump the kernel version when you merge the branch, or anyone using modules will get a nasty surprise :-) It's a major incompatiblity to change MIPS label_t definition (for pcb-pcb_context), which I hesitate to accept. Yes, a large caution (for NetBSD mips people) is required before branch merge. Toru Nishimura / ALKYL Technology
