Date: Sun, 10 Nov 2024 22:29:17 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: Kevin Bowling <kevin.bowling@kev009.com>, Colin Percival <cperciva@tarsnap.com>, freebsd-arch@freebsd.org, Ed Maste <emaste@freebsd.org>, Warner Losh <imp@freebsd.org> Subject: Re: CAN bus support Message-ID: <20241110222917.e186f6795bcf615263041ece@dec.sakura.ne.jp> In-Reply-To: <da18a88fe67fd430871e33cad02a72a6@Leidinger.net> References: <CAK7dMtC6uFquq1ZBcA3MwZ_4J21JgdaEeF%2B=LY-jAwsroHXy%2BQ@mail.gmail.com> <0100019312f6cb5f-56730680-f87f-4baa-a0e8-8a51d037fabe-000000@email.amazonses.com> <CAK7dMtA1G6vvN1yVjE-ENh-usof88jDymoHGWKc4YeKB%2B0dcgA@mail.gmail.com> <da18a88fe67fd430871e33cad02a72a6@Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi. Commenting partially. On Sun, 10 Nov 2024 12:57:13 +0100 Alexander Leidinger <Alexander@Leidinger.net> wrote: > Am 2024-11-09 23:14, schrieb Kevin Bowling: > > On Sat, Nov 9, 2024 at 3:06 PM Colin Percival <cperciva@tarsnap.com> > > wrote: > >> > >> On 11/9/24 13:57, Kevin Bowling wrote: > >> > A FreeBSD vendor is interested in interacting with CAN bus on FreeBSD. > >> > [...] > >> > Is there other interest or concern about the topic? > >> > >> As release engineer, I'm interested in hearing more (perhaps off-list) > >> about what they're doing, since the time scales for most devices which > >> use a CAN bus are significantly longer than the time scales for > >> FreeBSD > >> releases. > > > > It is an amd64 appliance with a bus attached controller and not a > > special SoC so it probably shouldn't be impactful to arch support > > expectations. > > > >> No obligation of course, and they're free to do whatever works for > >> them; > >> this is purely a case of "knowing more about how FreeBSD is being used > >> might help us support said uses better". > > > > I'll find out some more information and see what is appropriate from > > their perspective to share. > > Not related to this, but based upon this thread I had a quick discussion > with someone who worked on an automotive headunit and some other stuff: > > Currently a lot of the stuff which needs CAN bus support is either a > critical system (some sort of ECU, signal processing from sensors, ... > everything which influences the direct safety of a vehicle) which runs > on QNX and needs at least soft-realtime if not hard-realtime support, or > some kind of headunit where the industry has moved or is moving to > Android (more easy to integrate the app support and better support from > 3rd party vendors like Spotify and co), or a telemetry / gateway system > (no real-time requirements, but efficiency requirements, so we could be > a good fit), or some testing system in a lab (would also be an easy fit > for us). > > The industry seems to be willing to move away form QNX, or at least > would like to have options. There was some interest to get Linux > certified into this area, but at least a while ago this wasn't feasible > (I did not get info about specifics). (Micro)ITRON, the smallest variant of TRON project, can be an option, and at least, Toyota uses it for ECU. https://en.wikipedia.org/wiki/ITRON_project > So theoretically speaking, if a 3rd party wants to sell a test system to > a car manufacturer without releasing their code, we may be interesting, > and it may not need as much of a support timefame from us (if done right > on the vendor side). If a car vendor wants to build a test system for > their lab, they most probably stick with Linux (automotive linux has a > lot of stuff to offer and has support from big volume brands). > > If the issues with the certification of Linux instead of QNX are in > areas which are more easily handled with our code, we may run into the > area where some kind of looong term support may be needed, but this > looks to me either like a case similar to Sony / Playstation or would > have as a pre-req some code drop to us in the sense of some kind of > "automotive FreeBSD". Or FreeBSD as a process on RTOS. IIRC, there were some Linux implementations (not a full distro) running as such for mainly (G)UI. Critical things runs directly on the RTOS. > The telemetry/gateway area seems to be an easy target to use FreeBSD > too, not as strict in the requirements as the critical stuff. > > All of this is not only about the code, but also about legal stuff. Car > homologation in general is a big topic and the cost of it is not > negligible > (https://www.tuvsud.com/en/industries/mobility-and-automotive/automotive-and-oem/homologation-and-global-market-access). > > The digital security by design Jessica mentioned together with CheriBSD > may also be some interesting aspect, but I'm not sure how much the > industry is willing to invest into this ATM (your speedometer and your > car keys are still not that hard to manipulate than they could be, there > are still to many keyless entry systems which aren't secure enough, and > more or less you can not be really sure about the mileage of any car in > the market). > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF -- Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20241110222917.e186f6795bcf615263041ece>