Re: Trimming a diskless distribution
On 10/16/2018 2:23 PM, Brett Lymn wrote: On Mon, Oct 15, 2018 at 06:44:30PM -0700, Don NetBSD wrote: You're used to dealing with "computers" where you CAN change a piece of software AFTER release. I deal with devices/appliances where the cost of upgrading the device far exceeds the cost of the device (and comes at a huge "reputation cost" in the eyes of the user: "You mean, this device has been BROKEN all of this time?") Yes, I figured that was what you were doing but if there is any chance that your product will be featured in the technology news channels for having vulnerabilities that allow it to be used by bot herders or crypto currency miners it would be possibly more embarressing... IME, that happens when folks embrace some (large) piece of software (e.g., a Linux kernel) that they don't completely understand -- because it is never formally defined, in its entirety, in a way that those deploying it can grok. OTOH, when you develop a codebase specifically FOR a particular product, you avoid the risk of adding "cruft" to cover features and mechanisms that you aren't using. I'm looking to combine the best of both worlds -- use NetBSD to give me a flexible hardware platform that I can morph to suit the needs of proposed products (e.g., USB peripherals instead of having those same devices "on board" in a production version) at a prototype/proof-of-concept level; but the established (and "understood") codebase that we're already supporting for an eventual product deployment to free us from having to "support" a NetBSD implementation.
Re: Trimming a diskless distribution
On Mon, Oct 15, 2018 at 06:44:30PM -0700, Don NetBSD wrote: > > You're used to dealing with "computers" where you CAN change a piece of > software AFTER release. I deal with devices/appliances where the cost of > upgrading the device far exceeds the cost of the device (and comes at > a huge "reputation cost" in the eyes of the user: "You mean, this device > has been BROKEN all of this time?") > Yes, I figured that was what you were doing but if there is any chance that your product will be featured in the technology news channels for having vulnerabilities that allow it to be used by bot herders or crypto currency miners it would be possibly more embarressing... > I'm exploiting the fact that I can throw a NetBSD system onto some COTS > hardware (without requiring it to be a "PC"), embelish it with outboard > devices (so I don't have to get monies approved to build prototypes) and > pitch a proof of concept prototype to Management -- to fund REAL > development efforts. > Yes, this is not the first time that has been done. Good Luck :) -- Brett Lymn Let go, or be dragged - Zen proverb.
Re: uchcom USB-serial
On Tue, Oct 16, 2018 at 05:44:30PM +0200, Manuel Bouyer wrote: > On Tue, Oct 16, 2018 at 04:36:35PM +0100, Patrick Welche wrote: > > Just had a proper go, and see: > > > > uchcom0: QinHeng Electronics (0x1a86) USB2.0-Ser! (0x7523), rev 1.10/2.54, > > addr 3 > > uchcom0: CH341 detected > > ucom3 at uchcom0 > > uchcom0: cannot reset: STALLED > > uchcom0: cannot reset: STALLED > > uchcom0: cannot reset: STALLED > > uchcom0: cannot reset: STALLED > > uchcom0: cannot reset: STALLED > > uchcom0: cannot reset: STALLED > > uchcom0: cannot reset: STALLED > > ... > > > > I note that you have the full word "Serial"... > > Looks like a communication problem. Mine is manufactured by olimex, > which usually do robust hardware. I can see there is a true 12Mhz crystal. > Maybe yours uses a ceramic resonator, which is not stable enough ? This says "NLink Pax" on it. I think it is returning to where it came from... Thanks, Patrick
Re: uchcom USB-serial
On Tue, Oct 16, 2018 at 04:36:35PM +0100, Patrick Welche wrote: > Just had a proper go, and see: > > uchcom0: QinHeng Electronics (0x1a86) USB2.0-Ser! (0x7523), rev 1.10/2.54, > addr 3 > uchcom0: CH341 detected > ucom3 at uchcom0 > uchcom0: cannot reset: STALLED > uchcom0: cannot reset: STALLED > uchcom0: cannot reset: STALLED > uchcom0: cannot reset: STALLED > uchcom0: cannot reset: STALLED > uchcom0: cannot reset: STALLED > uchcom0: cannot reset: STALLED > ... > > I note that you have the full word "Serial"... Looks like a communication problem. Mine is manufactured by olimex, which usually do robust hardware. I can see there is a true 12Mhz crystal. Maybe yours uses a ceramic resonator, which is not stable enough ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: uchcom USB-serial
On Sat, Oct 13, 2018 at 12:39:35PM +0200, Manuel Bouyer wrote: > On Tue, Oct 09, 2018 at 04:13:32PM +0100, Patrick Welche wrote: > > I purchased a couple of USB-serial adapters. Unfortunately, given the lack > > of detail in the descriptions, they turned out to be > > > > uchcom0: QinHeng Electronics (0x1a86) USB2.0-Ser! (0x7523), rev 1.10/2.54 > > > > According to > > > > https://nxr.netbsd.org/xref/src/sys/dev/usb/uchcom.c#40 > > > > this is "the worst USB-serial chip in the world." > > > > Do these work at all? (Get "tip: link down", then change to a > > uplcom0: Prolific Technology Inc. and all is well.) > > I use one: > uchcom0: QinHeng Electronics (0x1a86) USB2.0-Serial (0x7523), rev 1.10/2.54, > addr 3 > uchcom0: CH341 detected > ucom0 at uchcom0 > > to connect to an ARM board's console. I didn't notice problems so far ... Just had a proper go, and see: uchcom0: QinHeng Electronics (0x1a86) USB2.0-Ser! (0x7523), rev 1.10/2.54, addr 3 uchcom0: CH341 detected ucom3 at uchcom0 uchcom0: cannot reset: STALLED uchcom0: cannot reset: STALLED uchcom0: cannot reset: STALLED uchcom0: cannot reset: STALLED uchcom0: cannot reset: STALLED uchcom0: cannot reset: STALLED uchcom0: cannot reset: STALLED ... I note that you have the full word "Serial"... Cheers, Patrick
