Announcement

Collapse
No announcement yet.

Linux Thunderbolt Support Can Work On Arm Systems

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

  • #11
    Originally posted by SteamPunker View Post
    The Raspberry Pi 4 has an internal PCIe bus. It would be great if the Raspberry Pi Foundation released a variant with the PCIe bus somehow exposed, either through an M.2 connector on the board or an external Thunderbolt port. It's nice to know that the kernel will be ready for this.
    Thunderbolt chipsets are physically bigger than Raspi Soc and cost more than 50$ apiece for the bare silicon, so I'd say rofl no.

    A M.2 slot would be perfectly fine for a raspi.

    Perhaps it was even someone at the Raspberry Pi Foundation who requested Thunderbolt support to be enabled for ARM architectures in the Linux kernel, since they are currently working on such a board?
    What for, their usecase (embedded development for kids) does not even require 64bit, why would they care about triplicating board size and price for a gimmick like that.

    Perhaps some other manufacturer or startup could even crowdfund the development of a mini-ATX board with multiple PCIe slots (and perhaps even conventional PCI slots through a bridge), as well as USB 3.0, better sound, SODIMM slots for RAM expansion, possibly integrated graphics, etc, which you could simply plug a Raspberry Pi 4
    Thunderbolt does not support RAM slots, wtf is this.

    Not to mention one which you could easily upgrade by swapping out the Pi board with a possible Raspberry Pi 5 or some other compatible SBC in the future.
    Unless it's using EFI swapping the board won't work. Good luck booting a raspi disk image on a different embedded board.
    Last edited by starshipeleven; 18 May 2020, 11:54 AM.

    Comment


    • #12
      Originally posted by starshipeleven View Post
      Thunderbolt does not support RAM slots
      ... but it IS PCIe; technically you could put ram there, but you'd need a PCIe DRAM controller too. I'm sure there's one out there.

      Comment


      • #13
        Originally posted by kcrudup View Post
        ... but it IS PCIe; technically you could put ram there, but you'd need a PCIe DRAM controller too. I'm sure there's one out there.
        The fact that you can't find PCIe cards with RAM slots on them to "expand your system RAM" should mean something. You can theoretically DMA into it, but you get performance hits, latencies increase A LOT, and more importantly there is no software support whatsoever for doing something like that.

        Not saying it's not possible, this is done in GPU computing, where the stuff has to be moved back and forth from the GPU internal vRAM to the system RAM over PCIe, and they are still working on how to do so in an efficient way.

        Expecting crappy embedded developers (as Raspi foundation) or even a normal hardware manufacturer (that isn't a big company with a strong vested interest like NVIDIA or AMD) to take a stab at something like this is madness.

        Comment


        • #14
          All that you say is true, but:

          Originally posted by starshipeleven View Post
          The fact that you can't find PCIe cards with RAM slots on them to "expand your system RAM" should mean something.
          Well, it wouldn't be for "regular users", I'm thinking industrial/legacy PCs that need more memory but for whatever reason can't swap hardware.

          .. and for the RPi case, (big) IF someone had the necessity to do this, it could be done on an M.2 module that would fit the form factor. But yeah, I don't expect one either, it would be too expensive for the use-case anyway.

          Comment


          • #15
            Originally posted by starshipeleven View Post
            there is no software support whatsoever for doing something like that
            You'd just have to feed the physical address/length of the block in the map into the NUMA system "by hand", right?

            Comment


            • #16
              Originally posted by kcrudup View Post
              industrial/legacy PCs that need more memory but for whatever reason can't swap hardware
              This usecase simply does not exist.
              You'd just have to feed the physical address/length of the block in the map into the NUMA system "by hand", right?
              You'd have to create a driver that enlarges the RAM size by X, and remap all calls to write/read that memory to instead DMA to your card. And do that in a safe and performant manner.

              As I said it is not impossible, it's just a massive pain in the ass to do, and that's all costs you must pass on to the customer.

              Comment


              • #17
                Originally posted by starshipeleven View Post
                The newer Gigabyte thunderbolt card https://www.gigabyte.com/Motherboard...IDGE-rev-10#kf and this Asrock card https://www.asrock.com.tw/mb/spec/pr...el=Thunderbolt 3 AIC R2.0 work on AMD x570 boards too, but it still requires the TBT header. Afaik they are not keyed to a specific brand so you can use it on boards of another manufacturer as long as the pinout is the same. WHich for Gigabyte and Asrock is.

                in the manual they call the pins "Ground, Platform Sequence Control, Platform Sequence Control, Plug Event, Power" but that does not help much as the two Platform Sequence Control are digital communication and can do whatever.
                Interesting. As far as I know it's still an Intel cryptographic (?) handshake though -- there's a certification process for the platform and my guess is the AMD board manufacturer just paid Intel for the license. Unfortunately for those of us wanting open platforms, so far as I am aware part of that process is DRM support (HDCP etc.) on the video side and quite likely other restrictions on the firmware itself.

                It's proven very hard to find this information though, so I'm adding a lot of qualifiers above. If anyone has citable information to the contrary or manages to get one of those cards working on a platform without the DRM control header, I'd be very, very interested...

                Comment


                • #18
                  Originally posted by madscientist159 View Post

                  Was about to ask the same thing. That special header is partly for a hardware lock (dongle / DRM stuff) that stops the card working on non-Intel platforms.

                  If anyone else gets a Thunderbolt card working on a non-Intel box, I'm all ears!
                  The special motherboard header for the GigaByte titanridge Thunderbolt 3 card is not a real requirement to get TB3 working on unsupported Intel and AMD machines it can be circumvented with a jumper cable to get most of the features working , it does affect however Hotplug and bootoptions. Also Wendel form level1tech did a proof of concept with some firmware fiddling with TB3 on AMD CPU's before this jumpercable trick.

                  See the following picture:
                  https://egpu.io/wp-content/uploads/w...367385823.jpeg

                  And posts from egpu.io forumuser karatekid430:
                  https://egpu.io/forums/thunderbolt-e...vices/paged/9/

                  For non TB3 Apple MacPro's there was a need to first boot Windows 10 with the Gigabyte card to load the thunderbolt firmware so it could work after a reboot within MacOS, but now there is even modified firmware for the Titanridge card to work directly without reboot to Windows on MacOS:
                  https://github.com/ameyrupji/thunder...-TitanRidge.md

                  Comment


                  • #19
                    Originally posted by walterav View Post

                    The special motherboard header for the GigaByte titanridge Thunderbolt 3 card is not a real requirement to get TB3 working on unsupported Intel and AMD machines it can be circumvented with a jumper cable to get most of the features working , it does affect however Hotplug and bootoptions. Also Wendel form level1tech did a proof of concept with some firmware fiddling with TB3 on AMD CPU's before this jumpercable trick.
                    Very interesting, I did not know about that!

                    Has anyone tried to decode the protocol? Is it crypto protected as was indicated some time ago, or merely obfuscated? Since e.g. our POWER platforms are fully open firmware, if the protocol is known we could potentially add support for hotplug even on our existing products via the on-board FPGA...

                    Comment


                    • #20
                      Originally posted by madscientist159 View Post
                      Has anyone tried to decode the protocol?
                      From what was described in those threads, there seems to be no protocol involved in the TBT header on that chipset. It's just a PCIe device doing its thing downstream. It's kind of surprising for a Intel puppy technology like that.

                      See this post: https://egpu.io/forums/postid/44262/
                      jumping pin 3 to VCC pin 5 seems to keep them awake for detection at boot without any need for any devices attached.

                      and also this https://egpu.io/forums/postid/44564/

                      someone mention on a forum that to get this Titan Ridge to work with his Asus Intel X299 board they had to set in the BIOS "GPIO3 Force Pwr" to True.
                      Which is likely the same as what you've done.
                      ---

                      What is interesting is how Titan Ridge is always awake, unlike Alpine Ridge, and yet the force power still helps at boot time.


                      The header seems to just be GPIO to turn it on or off with the motherboard and the jumper trick is just forcing it "always on" by giving VCC to that pin.

                      So as long as it is powered on the board firmware should find it (and stuff connected to it) on boot. Maybe there is a UEFI driver blob like for SAS HBA/RAID or GPUs.
                      Last edited by starshipeleven; 19 May 2020, 03:59 PM.

                      Comment

                      Working...
                      X