Announcement

Collapse
No announcement yet.

ASPEED's AST2500 Display To Be Supported By Linux 4.11's DRM

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

  • ASPEED's AST2500 Display To Be Supported By Linux 4.11's DRM

    Phoronix: ASPEED's AST2500 Display To Be Supported By Linux 4.11's DRM

    David Airlie sent in another pull request of DRM material for Linux 4.11, which follows last week's main DRM feature update for Linux 4.11...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    So on which side of the display is this driver living? Don't forget that we are talking host-cpu vs motherboard controller cpu, both running linux, the latter emulating a VGA card to the host.

    Comment


    • #3
      Originally posted by Ardje View Post
      So on which side of the display is this driver living?
      By looking at the commit descriptions here, it seems a driver for the Linux running on the x86 processor(s), not for the BMC itself.
      Linux kernel source tree. Contribute to ozbenh/linux development by creating an account on GitHub.


      Although it seems that one of the commits allows the host system (Linux on x86 processor) to fully initialize the GPU on its own, in case the BMC firmware or the vBIOS didn't initialize it.
      This is used when the BMC isn't running any code and thus has to be initialized by the host. The code originates from Aspeed (Y.C. Chen) and has been cleaned up for coding style purposes by Be...


      Same for older gens, there is a commit that fixes the initialization of the GPU in case the BMC firmware didn't initialize it https://github.com/ozbenh/linux-ast/...3bd4d11450ee06

      I'm a bit puzzled about how in the heck this thing works. It seems the GPU is actually shared and the host system can actually access it to pretty low level if it can initialize it from a cold state.

      Comment


      • #4
        It has video-over-ip, maybe that's why you can initialize it remotely. Sort of like wake on lan? Anyway, just guessing.

        Comment


        • #5
          Originally posted by AndyChow View Post
          It has video-over-ip, maybe that's why you can initialize it remotely. Sort of like wake on lan? Anyway, just guessing.
          The code in those patches isn't doing anything remotely. It's acting on a local GPU, as if both host CPU and BMC CPU have same access to that GPU.

          Comment


          • #6
            Originally posted by starshipeleven View Post
            I'm a bit puzzled about how in the heck this thing works. It seems the GPU is actually shared and the host system can actually access it to pretty low level if it can initialize it from a cold state.
            Afaik, the host thing is legit, and the BMC just can read the config and the VRAM is just shared memory. I really love those BMC's, especially when I have ssh root access to them because then I can put my own serial console clients (picocom) on them instead of the crap IPMI implementations...
            Anyway: having reviewed the binaries of the "remote KVM" (10 years ago ;-) )it is just a mangled version of VNC. It would have been nice if the BMC side had a H.264 encoder so it could do some more interesting stuff.
            These days the BMC's are unfortunately locked down and license riddled.

            Comment


            • #7
              Finally, these chips drive me nuts with conflicting error messages in kernel vs xorg module...

              Comment

              Working...
              X