Re: nandemulator
On Sat, Feb 23, 2019 at 12:40 PM David Holland wrote: > Do we have docs for the object nandemulator is supposed to be > emulating? Some questions have arisen about how complete it is and > nobody I've talked to seems to really have answers. > So looking at the code... It's an ONFI emulator. That mens Intel/Micron parts (as opposed to the so-called 'Toggle' parts from Toshiba/Samsung). It's from 2011, so it can't be emulating anything newer than 30ish nm processes. The limited command set suggests that it's emulating just SLC parts. It uses bogus manufacturer data, and a place holder name (NANDEMULATOR made by NetBSD), so I doubt there's a specific model used here. It hard codes a 32MB device with 2k pages, which suggests an even older device (45nm SLC generation maybe). It emulates things at a much lower level than FreeBSD's nandsim, it would appear, but I've not studied either more than briefly for this email. This is in keeping with the other nand_*.c files in that directory. They are for parts like the Micron MT29F2G08AAC and such. These date from 2005 to 2008 if I can believe the quick sample of data sheets that I found. The list of supported commands is approximately that of the emulator for the Micron part. No mention is made of MLC or TLC, which usually indicates on the older parts they are SLC. MLC and TLC parts sometimes have additional features / commands required (or sometimes just desired) for coping with partial page programming, etc. It doesn't look super complete to my eye. But it's been 6 years since I was building NAND based PCIe storage devices for a living. I know these aren't definitive answers as I didn't write the code and am basing this on briefly studying the code + the knowledge I picked up about NAND while working with planar SLC and MLC NAND in the 34nm to 19nm technology nodes for Intel, Micron and Toshiba. So in the absence of other answers, mine may be OK. However, I'd be happy to defer to someone who wrote the code and/or did a comparison of commands vs datasheets from that era. Warner
Re: RFC: New userspace fetch/store API
> On Feb 23, 2019, at 6:35 PM, Robert Elz wrote: > > fuword/fuiword/suword/suiword (etc) are all ancient, and I would > have expected, largely deprecated these days - but what's wrong > with copyin/copyout ?Those could be optimised for particular > data sizes if there was some real need for that. Hey Robert — The copyin / copyout API contract is like bcopy(); arbitrary byte alignment and no guarantees that the load / store to the specified memory location will be of any specific size, or will even be a single load or store operation. I thought there would value in having something like the old fetch / store API, which did provide those sorts of API guarantees, just freshened up a little. Furthermore, there isn’t a provision for using copyin / copyout in interrupt context (e.g. fuswintr()) … Now, it may be that is’s time to abandon that… but I’ll stick with the above argument. -- thorpej
Re: RFC: New userspace fetch/store API
fuword/fuiword/suword/suiword (etc) are all ancient, and I would have expected, largely deprecated these days - but what's wrong with copyin/copyout ?Those could be optimised for particular data sizes if there was some real need for that. kre
Re: RFC: New userspace fetch/store API
> On Feb 23, 2019, at 4:19 PM, Jason Thorpe wrote: >> On Feb 23, 2019, at 4:04 PM, matthew green wrote: >> >> i like this. the current API is ... odd. >> >> can you add alignment documentation? eg, if only to say that it >> must support aligned or unaligned accesses for the relevant >> datatypes. not sure what we need currently, ie, if unaligned is >> needed because that happens today, or we can define it as wrong >> in this API. > > Yah, I’ll make that clear. It’s implicit in the current API (alpha would > blow up otherwise), but I will make it explicit. I added the following: All addresses MUST be naturally-aligned for their type. If unaligned access is required, use copy(9). OK? -- thorpej
Re: RFC: New userspace fetch/store API
> On Feb 23, 2019, at 4:04 PM, matthew green wrote: > > i like this. the current API is ... odd. Oh… any thoughts on “have intrsafe or not”? -- thorpej
Re: RFC: New userspace fetch/store API
> On Feb 23, 2019, at 4:04 PM, matthew green wrote: > > i like this. the current API is ... odd. > > can you add alignment documentation? eg, if only to say that it > must support aligned or unaligned accesses for the relevant > datatypes. not sure what we need currently, ie, if unaligned is > needed because that happens today, or we can define it as wrong > in this API. Yah, I’ll make that clear. It’s implicit in the current API (alpha would blow up otherwise), but I will make it explicit. -- thorpej
re: RFC: New userspace fetch/store API
i like this. the current API is ... odd. can you add alignment documentation? eg, if only to say that it must support aligned or unaligned accesses for the relevant datatypes. not sure what we need currently, ie, if unaligned is needed because that happens today, or we can define it as wrong in this API. thanks. .mrg.
RFC: New userspace fetch/store API
The existing fetch(9) / store(9) APIs have some problems. Specifically: ==> Their return semantics mean that fuword() cannot disambiguate between an error condition (-1) and a legitimate fetch of -1 from user space. ==> “word” is poorly defined. For all practical purposes, it means “long”, and there is thus no way to fetch/store an “int” value on LP64 platforms. ==> There are lots of legacy aliases lying about that are no longer meaningful (I-space and D-space variants, for example). A project I’m working on has a need for a proper “int” size fetch / store on all platforms, and it seems best to just tidy the whole mess up. So, I am proposing a new replacement user fetch/store API. I have implemented the new API for alpha and amd64, and am putting together a test harness to exercise all aspects of the new API. Once that is done, I’ll tackle the remaining architectures. Outstanding question before I go too far down the rabbit hole: should I bother with the “intrsafe” variants? The only application for it in the tree right now is in the profiling code, as an optimization to avoid taking an AST when it’s time to bump the counters. Feedback appreciated. = This API provides support for fetching and storing single cells of memory from/to user space addresses in 8-bit, 16-bit, 32-bit, and 64-bit (_LP64 platforms only) widths. The functions return 0 on success and an errno (usually EFAULT) if the address is not mapped, is not a user-space address, or is otherwise invalid. These functions may block (to service a page fault), and are NOT safe to call from any interrupt context. The implementation is entirely in architecture-dependent code. The following fetch primitives must be supplied: int ufetch_8(const uint8_t *uaddr, uint8_t *valp); int ufetch_16(const uint16_t *uaddr, uint16_t *valp); int ufetch_32(const uint32_t *uaddr, uint32_t *valp); #ifdef _LP64 int ufetch_64(const uint64_t *uaddr, uint64_t *valp); #endif The following aliases must also be provided, mapped to the appropriate fixed-size primitives: int ufetch_char(const unsigned char *uaddr, unsigned char *valp); int ufetch_short(const unsigned short *uaddr, unsigned short *valp); int ufetch_int(const unsigned int *uaddr, unsigned int *valp); int ufetch_long(const unsigned long *uaddr, unsigned long *valp); int ufetch_ptr(const void **uaddr, void **valp); The following store primitives must be suppled: int ustore_8(uint8_t *uaddr, uint8_t val); int ustore_16(uint16_t *uaddr, uint16_t val); int ustore_32(uint32_t *uaddr, uint32_t val); #ifdef _LP64 int ustore_64(uint64_t *uaddr, uint64_t val); #endif The following aliases must also be provided, mapped to the appropriate fixed-size primitives: int ustore_char(unsigned char *uaddr, unsigned char val); int ustore_short(unsigned short *uaddr, unsigned short val); int ustore_int(unsigned int *uaddr, unsigned int val); int ustore_long(unsigned long *uaddr, unsigned long val); int ustore_ptr(void **uaddr, void *val); If __HAVE_INTRSAFE_USER_FETCH_STORE is defined by the architecture’s header, then "intrsafe" variants of each call are also provided, e.g.: int ustore_short_intrsafe(unsigned short *uaddr, unsigned short val); These functions are equivalent to their non-intrsafe counterparts, except that they will NOT block; they will immediately return an error if a page fault occurs. = -- thorpej
nandemulator
Do we have docs for the object nandemulator is supposed to be emulating? Some questions have arisen about how complete it is and nobody I've talked to seems to really have answers. -- David A. Holland dholl...@netbsd.org
Fix the NetBSD/i386 build with Kernel Sanitizers
Please review. Build errors and proposed patches are in the .txt files. http://netbsd.org/~kamil/patch-00087-amdgpu_cz_smc.c.txt http://netbsd.org/~kamil/patch-00088-amdgpu_display.c.txt http://netbsd.org/~kamil/patch-00089-amdgpu_gfx_v8_0.c.txt http://netbsd.org/~kamil/patch-00090-sctp_asconf.h.txt http://netbsd.org/~kamil/patch-00091-mcd.c.txt http://netbsd.org/~kamil/patch-00092-mt.c.txt signature.asc Description: OpenPGP digital signature
