Announcement

Collapse
No announcement yet.

Linux Kernel Patches Posted For Bringing Up Tesla's Full Self-Driving SoC

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux Kernel Patches Posted For Bringing Up Tesla's Full Self-Driving SoC

    Phoronix: Linux Kernel Patches Posted For Bringing Up Tesla's Full Self-Driving SoC

    Samsung in partnership with Tesla has posted a set of 23 patches for enabling Tesla's Full Self-Driving (FSD) SoC for the mainline Linux kernel...

    https://www.phoronix.com/scan.php?pa...SD-SoC-Patches

  • #2
    So, are those "neural processing units" of Jim Keller's design, or some derivative thereof?

    I'm honestly surprised by this, since I'd read someone claim that Linux isn't capable of being certified for self-driving. So, I wonder why they'd bother with Linux support, unless it's like just for the convenience of internal software development (e.g. testing the deep learning models and algorithms).

    Comment


    • #3
      Originally posted by coder View Post
      So, are those "neural processing units" of Jim Keller's design, or some derivative thereof?

      I'm honestly surprised by this, since I'd read someone claim that Linux isn't capable of being certified for self-driving. So, I wonder why they'd bother with Linux support, unless it's like just for the convenience of internal software development (e.g. testing the deep learning models and algorithms).
      What.


      You know that most of those systems run Linux right? Just with their own proprietary drivers.

      Comment


      • #4
        Originally posted by coder View Post
        So, are those "neural processing units" of Jim Keller's design, or some derivative thereof?

        I'm honestly surprised by this, since I'd read someone claim that Linux isn't capable of being certified for self-driving. So, I wonder why they'd bother with Linux support, unless it's like just for the convenience of internal software development (e.g. testing the deep learning models and algorithms).
        They probably need RTOS, but we have linux RTOS kernels...

        Comment


        • #5
          Now reiserFS has a rival in the open source murderer space

          Comment


          • #6
            Originally posted by scottishduck View Post
            Now reiserFS has a rival in the open source murderer space
            LOL.

            I wonder if anyone is tracking what operating systems killer robots and armed, autonomous drones are known to run. I mean, I'm sure it's classified but various specs on weapons systems do leak out...

            Comment


            • #7
              Originally posted by Doomsdayrs View Post
              What.

              You know that most of those systems run Linux right? Just with their own proprietary drivers.
              I'm no expert on the subject. Here's one data point: Nvidia's Drive OS is available for both Linux and QNX. Yet, the QNX version is the only one that's safety-certified.


              I've read people who sound like they're involved in self-driving claiming Linux can never meet the requirements needed for proper certification. If anyone has actual knowledge of this area, feel free to educate us.

              Comment


              • #8
                Originally posted by coder View Post
                LOL.

                I wonder if anyone is tracking what operating systems killer robots and armed, autonomous drones are known to run. I mean, I'm sure it's classified but various specs on weapons systems do leak out...
                Most people seem to think that completely autonomous "killer" drones need to be incredibly sophisticated machines to be useful in real-world combat scenarios.

                As a matter of fact I know how a certain class of autonomous "suicide bomber" drones already put to very effective, tide-turning use in a recent real war are built by a certain country:

                - Off-the-shelf commercial drones mass-purchased from China
                - nVidia's SoM (System-on-Module) AI/ML platform strapped-on in a very original & custom way running on Ubuntu with a hard real-time Linux kernel
                - trained to recognize human-looking targets from afar & simply drop on them when near enough (the more, the merrier)
                - PROFIT (since each unit costs only a few hundred bucks)

                Now, I know this may sound cynical, but it's simply the truth...

                Comment


                • #9
                  Originally posted by coder View Post

                  I've read people who sound like they're involved in self-driving claiming Linux can never meet the requirements needed for proper certification. If anyone has actual knowledge of this area, feel free to educate us.
                  While there are a number of possible safety certifications depending on exactly which sub-field of the whole transportation we are talking about, the most popular and widely used for automobiles is the Automotive Safety Integrity Level (ASIL) delineated in the ISO 26262 (Road vehicles – Functional safety") which is in turn a derivative from IEC61508.

                  It has 4 levels from A to D, with A being the weakest one, used for items such as external lighting, where the risk in case of failure is relatively limited while D is the strongest one used for stuff like ABS brakes and ECU, where a failure is very likely to result in injuries or even death, think ECU randomly accellerating with full power during a turn or ABS completely preventing you to brake while doing an emergency brake (on the dry).
                  Most automotive Electronics falls somewhere in the middle at ASIL B or C.

                  The first hurdle to clear for ASIL (at least for the highest levels) is that the certification does not only cover the item in itself, but also the whole development process, this requires formally documenting how and why requirements are formulated, how the development process is carried out in order to fill those requirements, and so on.
                  All of this is very, very, very far from how the linux kernel in particular, and most general purpose software in general is developed, so a full certification of the entire kernel "as is" is basically unthinkable.

                  The second problem is that for the higher levels of ASIL ( namely C and D) extensive failure analysis is required, to identify all the possible failure modes and how these could affect the safety of the entire vehicle and what mitigations are put in place so that such failure does not lead to catastrophic consequences. Doing such a detailed analysis on a project with the scale of the entire kernel (with upwards of 20 milion lines of code) is basically unthinkable.

                  The final issue (and probably the biggest) is that all these analyses and documentation requirements do no apply to the kernel itself (or rather to any single component) but to the complete product being developed (the entire ECU for example, and not to the processor running the firmware alone). And thus need to be tailored to each specific case, and can not be just done once.

                  Now all of this work is only valid for a single point in time ( a specific kernel release for example), a significant chunk of the process must be re-done for all subsequent releases as it must be shown that the changes do not interact negatively with the rest of the design

                  Now the linux kernel could at some point meet all requirement for use in an ASIL certified product at the lower levels (A or B) i dont belive there is any incentive in adopting it in priducts with higher ratings, as it will be much, much cheaper, safer and faster to develop something from scratch that just include the necessary stuff, minimizing the potential failure points

                  Comment


                  • #10
                    Thanks filssavi for clarifying the exact ISO norms that one need to meet, but that makes it even more bizzare that Tesla is able to run its so called "Full Self-Driving" software on Linux as it would seem from the article. Or are they doing something like: each of the three clusters is running its own independent Linux with software on it, and the mentioned in the article additional IP blocks merge them into one output (e.g. all agree -> make the decision, exactly two agree -> go into emergency mode, but still able to it fairly safely, all disagree -> some sort of emergency stop, hopefully never happens), and argue that the random variables coresponding to each of the cluster failing have very little correlation to each other (that seems like a big ask).

                    Comment

                    Working...
                    X