Announcement

Collapse
No announcement yet.

It's Becoming Possible To Run Linux Distributions On The HP/ASUS/Lenovo ARM Laptops

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

  • It's Becoming Possible To Run Linux Distributions On The HP/ASUS/Lenovo ARM Laptops

    Phoronix: It's Becoming Possible To Run Linux Distributions On The HP/ASUS/Lenovo ARM Laptops

    We've been looking forward to the possibility of having a nice 64-bit ARM Linux laptop with decent power and nice build quality. Several major vendors having been rolling out Windows ARM laptops powered by Qualcomm chips and the like with decent specs and quality, unlike some of the cheap ARM Linux laptop efforts we've seen. For those Windows ARM laptops, headway is being made in being able to run Linux on them...

    http://www.phoronix.com/scan.php?pag...in-Arm-Laptops

  • fraz
    replied
    Originally posted by pracedru View Post

    There has to be demand for it to happen. And if we buy Windows laptops and install Linux, then the producers of laptops have no idea the market exists. So... Please by your next Linux laptop from System76/Purism/Entroware etc.
    Just registered to say thank you for this. I hadn't heard of System76, but their Galago Pro looks like just what I want: matt IPS screen, full size arrow keys, page up/down on the right edge. And normal F keys. Looks like it even takes a secondary drive. Love it! Now, for my Yoga 700 to need replacing....

    Leave a comment:


  • oiaohm
    replied
    Originally posted by misGnomer View Post
    Among the recent FOSDEM news was a preview of one ARM SOC vendor's planned big brother to the $99 Pinebook ARM netbook with target being 14' 1080p / 4gb / 64gb plus an NVMe slot.

    Although the company was based in China (PRC) with the potential issues involved, they did seem genuinely supportive of open source and if the laptop (using RK3399 IIRC) has practical mainline kernel support it could become relatively popular if they hit the hoped $200 target.

    I don't know what distro they might preload or what bootloader/manager it uses, but if it runs Debian then the door is open.
    https://forum.pine64.org/showthread....7093&pid=43850
    Details of the Pinebook pro is here. Its 199 not 99.

    Being pine64 something normally uboot.

    https://fosdem.org/2019/schedule/eve...rule_them_all/

    Yes the work will allow the allwinner 99 dollar pinebook and the rockchip 199 dollar pinebook pro to have exact the same boot images.

    http://wiki.pine64.org/index.php/Pin...ftware_Release

    I would suspect something Ubuntu related again as default with selection of other distributions latter as images include something from debian family..

    Leave a comment:


  • misGnomer
    replied
    Among the recent FOSDEM news was a preview of one ARM SOC vendor's planned big brother to the $99 Pinebook ARM netbook with target being 14' 1080p / 4gb / 64gb plus an NVMe slot.

    Although the company was based in China (PRC) with the potential issues involved, they did seem genuinely supportive of open source and if the laptop (using RK3399 IIRC) has practical mainline kernel support it could become relatively popular if they hit the hoped $200 target.

    I don't know what distro they might preload or what bootloader/manager it uses, but if it runs Debian then the door is open.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Britoid View Post
    Hopefully that might trickle down to Android and we get single Android images. There's GSI but it requires vendors to put device configuration files in another partition and it's still device-specific kernels.
    Its android party why I said 12 months. This is not 100 percent tricking down from Android somethings are trickle up from android.

    Originally posted by Britoid View Post
    But some OEMs would never give up that control. I think it would be pretty amazing one day to be able to boot a phone off a USB stick, install the OS and have everything working.
    Google trebble work is only the tip.
    https://source.android.com/devices/a...odular-kernels "Future Android versions" and "Upstreaming" sections of this make it very clear what google will be pushing for in Android 10.

    Basically OEM never giving up that control is not exactly true. Since the upstreaming announcement from google as something that want to see in future we are seeing way more drivers up-streamed by the SoC vendors. This android caused up-streaming is also why the 3 laptops mentioned on this project have working kernels now.

    Google has quite extreme whip if you don't meet our quality control we will not certify you to ship with Google play store. Android device without Google play is not that sell-able. OEM and SOC vendor most critical requirement is that product will be bought by customer.

    Education users a lot of the PI and PI clone boards so this market is also applying a lot of force for vendors to open up drivers and other parts. With unified boot discs for these devices there will be more pressure .

    Other thing to remember SOC vendors don't reinvent every part of the SOC chip every time they make a new version. So SOC vendor releases drivers for all the current versions of their chips they also release a segment of drivers for all their older chips in some cases this is 100 percent of their product lines are in fact the current set of drivers.

    This is why Sonadows idea that we need different for arm embedded and arm desktop/arm server. Really we need the 1 unified image that can pressure vendors that if they don't support it they will lose big money currently this where android heading on phones.

    https://fosdem.org/2019/schedule/eve...rule_them_all/
    This one image to rule them all is truly a goal. This one image will apply more pressure on SOC and OEMs not to hold onto the control as tightly. Think about day comes that 1 image to boot most PI clone boards you attempt to sell a PI clone board with some OEM or SOC vendor unique driver and the 1 image no longer works your board will not sell.

    Part of the reason why x86 has some form of sanity is that Windows was the 1 image SOC/OEM had to support. Microsoft never really used the whip they had on vendors to create uniform generic driver coverage resulting in different windows machines being a total ass to reinstall when not using vendor install media.

    Arm platforms just need the same 1 image/images that SOC/OEM has to support to have sales.

    Leave a comment:


  • Britoid
    replied
    Originally posted by oiaohm View Post
    The price of a unified arm media looks at this stage will cost 1 meg area at start of media in boot up stuff I don't think that prices these days is too insane.
    Hopefully that might trickle down to Android and we get single Android images. There's GSI but it requires vendors to put device configuration files in another partition and it's still device-specific kernels.

    But some OEMs would never give up that control. I think it would be pretty amazing one day to be able to boot a phone off a USB stick, install the OS and have everything working.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by chithanh View Post
    If people would use the actual origin of device trees, namely Open Firmware (IEEE-1275), then those could come naturally and they would avoid the mess that is ACPI.
    There is even an example implementation of Open Firmware on ARM (OLPC XO-1.75). But there seems to be no commercial interest in having that.
    The origin of device trees predates Open Firmware (IEEE-1275) its 1991 sun open boot is where device tree starts.
    https://elinux.org/images/e/e2/Engag...ce_Trees_0.pdf

    Device Tree Blob (dtb)(Flat Device Tree) form of device tree is a pure Linux kernel development that is also used by uboot.
    https://git.kernel.org/pub/scm/utils/dtc/dtc.git this is the compiler you need to make dtb files. Large percentage of the device tree master files are part of the Linux kernel source.

    This is way different to the ACPI path where you leave it up to the vendor to put the right stuff in firmware of the device. When the vendor customises their windows install to ignore the screwups they made in firmware of course the so called generic windows installer completely bites the big one.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Sonadow View Post
    Even those same ARM laptops mentioned in the git repository have issues (read: not able to) installing a clean Windows ARM iso from USB.
    That a Windows problem. The report here said images when the reality is the 3 different brands of arm64 are in fact installing from 1 image with 1 grub and 1 Linux kernel.

    Originally posted by Sonadow View Post
    ARM needs to completely rethink their approach to non-embedded computing. Either set up a separate business unit to cater to desktop/laptop and server computing with SBSA, SBBR and UEFI to make a clean break from embedded ARM, or leave the non-embedded space completely.
    Really this does not make very much sense. Be it a dekstop/laptop or embedded arm in a lot cases you are talking about stack of identical drivers.

    Originally posted by Sonadow View Post
    It's not unheard of for SBSA-compliant ARM servers to not be able to boot and install a generic ARM Linux ISO image.
    Where do you get the idea of generic ARM Linux ISO those have not existed to boot with. Yes they have existed to provide applications after you have used a customised boot disc matching the hardware. This is why the following is really big news.

    https://fosdem.org/2019/schedule/eve...rule_them_all/
    This is the first time a proper generic ARM64 Linux image has attempted to be made. Patches are going up stream into uboot and UEFI standard..

    Yes this work means the 3 laptops that have been go booting with a single image uefi could be integrated on a image for booting raspberry pi 3 and related arm64 clones/forks from a single image.

    Basically we are about see what a single generic Linux boot image for arm64 can in fact do and what the limitations really are. Yes covering all the boards uboot support as a starting point is insanely impressive.

    uboot and uefi covers 90+ percent of everything arm.
    Last edited by oiaohm; 02-12-2019, 07:33 AM.

    Leave a comment:


  • chithanh
    replied
    Originally posted by oiaohm View Post
    The answer is no. dtb files contain more information about hardware than UEFI includes ,

    https://www.kernel.org/doc/Documentation/efi-stub.txt
    Yes EFI on arm in fact to Linux provided dtb or acpi. dtb the device tree can encode information you cannot put in acpi.
    If people would use the actual origin of device trees, namely Open Firmware (IEEE-1275), then those could come naturally and they would avoid the mess that is ACPI.
    There is even an example implementation of Open Firmware on ARM (OLPC XO-1.75). But there seems to be no commercial interest in having that.

    Leave a comment:


  • Sonadow
    replied
    Originally posted by oiaohm View Post

    https://fosdem.org/2019/schedule/eve...rule_them_all/

    This problem might be dealt with in the next 12 months if we are lucky. Part of the problem is no one until this group has really tried.
    12 months? Dream on. 12 years more like it.

    Even those same ARM laptops mentioned in the git repository have issues (read: not able to) installing a clean Windows ARM iso from USB.

    ARM needs to completely rethink their approach to non-embedded computing. Either set up a separate business unit to cater to desktop/laptop and server computing with SBSA, SBBR and UEFI to make a clean break from embedded ARM, or leave the non-embedded space completely.

    It's not unheard of for SBSA-compliant ARM servers to not be able to boot and install a generic ARM Linux ISO image.

    Leave a comment:

Working...
X