Announcement

Collapse
No announcement yet.

Red Hat / Fedora To Work On Bringing Up Arm Laptops Under Linux

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

  • #31
    Originally posted by kpedersen View Post
    I don't suppose you can you still link me to where the KDE community "found" their Arm laptops?
    I don't get your point. The laptop I'm referring to is the Pinebook. You can buy it here for $99.

    Comment


    • #32
      Originally posted by msotirov View Post
      I don't get your point. The laptop I'm referring to is the Pinebook. You can buy it here for $99.
      Buy or rather pray for it?

      A special coupon code is required to buy Pinebook during checkout. Visit Pinebook Build To Order (BTO) Booking page to register, we will fulfill the BTO queue based on first come first served basis and starting on 28 March 2017. Our sales team will email the special coupon to you when it is your turn in the queue.

      Comment


      • #33
        these laptop have finger scanner integration? so i won't need to type in my password all the time on linux?

        Comment


        • #34
          Originally posted by [email protected] View Post
          Fixed that for you, Intel evangelist. /S

          Anyway, AMD is about to release the Zen 2 architecture with that chiplet thingies, that could be perfect for the big.LITTLE format.
          Yes, there is real potential there, though as of right now that doesn't seem to be what they're planning on doing.


          Originally posted by Britoid View Post
          ARM does have UEFI. It's used in ARM Servers (the few that exist) as well as Microsoft's Windows Phone 8+ and Windows 10 ARM devices.
          I wasn't aware of the servers have a UEFI (never had access to one) but I'm not entirely sure if the Windows phones and tablets use it. It could just be a pseudo-UEFI, kinda like what some of the Chromebooks and Android devices have, where you get a primitive boot menu but you can't really do anything else with it.

          Comment


          • #35
            Originally posted by Britoid View Post

            ARM does have UEFI. It's used in ARM Servers (the few that exist) as well as Microsoft's Windows Phone 8+ and Windows 10 ARM devices.
            Actually there is also at least three HiKey boards with UEFI support. Here is the first one: https://wiki.debian.org/InstallingDe...96Boards/HiKey

            Comment


            • #36
              Originally posted by schmidtbag View Post
              In my experience, the slowness is only due to insufficient driver support. Relative to x86, it'll still be less bloated.
              I was just meaning when compared to a 4 or 5 ghz Intel or AMD CPU. x86 has the brute force that ARM seems to be lacking.

              Originally posted by schmidtbag View Post
              Actually it can handle x86 exclusive tasks too, you're just going to sacrifice a lot of performance in doing so.
              But yeah, I agree. I've even found that old quad core Cortex A9 CPUs are perfectly adequate at handling most everyday CPU-bound tasks. The thing is, most software isn't compiled to use most of the special instructions you find in x86, which Clear Linux really helps exemplify. So, with the exception of a few libraries accelerated by certain x86 instructions (or by other hardware, like GPUs), you can actually have a pretty fluid ARM experience.
              I have an older Westmere. One generation before UEFI and AVX. ARM is like my CPU, it gets it done and fast enough, but there are better and faster ways.

              Originally posted by schmidtbag View Post
              I've considered this concept, since they kinda did the same thing with x86-64 (which is arguably a hybrid architecture). But I think it'd add way too much bloat and complexity to run both ARM and x86-64 binaries at the same time. Keep in mind that the separate cores would have to run their own kernel and basically run totally independent of each other, which also implies there'd be some performance issues getting them to communicate to each other.

              I figure the bloat and complexity can't be any worse than targeted binaries that support multiple x86_64 instruction sets as far as launching programs is concerned. I don't think they'd need multiple kernels, just a kernel that understands both architectures and can interoperate between the two. Any graphics changeover from ARM to Radeon shouldn't be that different than various laptop setups where the Intel GPU switches to the AMD or Nvidia GPU when you play game. An ARM/x86 hybrid isn't that far out of the box considering all the work AMD has put into HSA, APUs, Infinity Fabric, and whatnot.

              Originally posted by schmidtbag View Post
              I think it'd make more sense for AMD to make an x86 equivalent of big.LITTLE, where you have 4 low-power cores without SMT, uses short pipelines, and limited instructions. They'd likely remain below 1GHz and don't have boost clocks. Then you have another set of cores (of varying quantities depending on model) that are much more beefy, and can adjust their clock speeds independently of the low-power cores.

              The low-power cores would be used for background processes and foreground tasks that barely demand any CPU power, like a text editor or a calculator. Then all of your main foreground and CPU-intensive tasks would be used for the other cores. All this would take is an adjustment to the CPU scheduler, and there could even be a profiler implemented so the scheduler automatically knows which core to assign the process to. In most systems, I'm sure you could just simply set the affinity based on the user (so for example, root-run processes would be run by the low-power cores).
              Using a big.LITTLE-like approach for x86 could really help improve efficiency without the need to recompile software or have a nasty impact on latency. It's the same idea as using ARM.
              Without a recompile, scheduler adjustments and a profiler would seem to be mandatory. I'm imagining something like Feral's Gamemode with NUMA support (something I need). A dameon that sends the low power stuff to node 0 and high power to node 1 based on a blacklist with the scheduler as backup.

              I'm actually surprised x86 big.LITTLE hasn't been done via software by now. Seems like something that one of those Android governor people would make for a desktop or laptop CPU.

              Comment


              • #37
                Originally posted by debianxfce View Post
                A much better and cheaper laptop for real (no company connection) open source Linux users:
                https://www.notebooksbilliger.de/not...otebook+414001
                Acer is a shit brand, stay away from it.

                Comment


                • #38
                  Originally posted by schmidtbag View Post
                  I wasn't aware of the servers have a UEFI (never had access to one)
                  ARM servers are supposed to have UEFI firmware because you can't seriously ask with a straight face to jump through all the idiocy required to boot a system on different embedded ARM devices for server hardware.

                  but I'm not entirely sure if the Windows phones and tablets use it. It could just be a pseudo-UEFI, kinda like what some of the Chromebooks and Android devices have, where you get a primitive boot menu but you can't really do anything else with it.
                  UEFI isn't the GUI interface, nor the ability to set hardware settings like you do with a consumer x86 system.
                  UEFI is the internal firmware structure and API offered to the OS and to run EFI applications (usually boot managers, tools and filesystem drivers, and also the native GUI application that allows you to set up the hardware settings from the UEFI environment, that you mistakenly thought was UEFI itself).

                  And yes Windows phones/tablets use the true UEFI firmware.
                  https://www.windowslatest.com/2018/0...-lumia-950-xl/
                  http://i.imgur.com/XkMRx3E.jpg

                  Worthy of note is that u-boot is also capable of UEFI boot and it can do without ACPI (and its many evils) since it can pass the linux kernel a the board's flattened device tree on boot.

                  Comment


                  • #39
                    Kernel, and VPU drivers have been the main issue on ARM.
                    the 2 ARM products worth hacking on now are the Odroid_N2 and the RockPro64 , Fedora was quick to fix the one application bug I found on ARM, but they will also need to start compiling against gl4es if they want the distro to work out of the box. Examples; https://forum.odroid.com/viewtopic.php?f=150&t=30170

                    Comment


                    • #40
                      Originally posted by George99 View Post
                      Did you read the topmost comment (31.01.2019) complaining about poor Linux compatibility of this machine?
                      Windows users do not know how to use latest open source drivers and software.

                      Comment

                      Working...
                      X