Just how open source is Pine64 anyway?

[binarian]

Greetings all!



This post is mainly directed at the owners/operators/admins/mods/etc. of the entire Pine64 project, but I welcome community feedback as well.  The question is simple: Just how open source is Pine64 anyway?

Some context:
A friend of mine is absolutely in love with the concept of the Librem 5 phone, as well as pretty much everything else that organization does.  My understanding there is that that org has gone above and beyond the reaches of the entire bloody galaxy to open source their hardware and software.  As an example, not only is all of their Software FOSS, and not only do they provide datasheets (and I'm pretty sure schematics), but they've even collaborated with chip manufacturers to ensure components are FOSS-respecting, removed IME code from their intel CPUs (I think), written their own BIOS and UEFI bootloader, and I'm pretty sure I read somewhere that they replaced microcode on something somewhere.

But, as expected, this attention to minute detail comes at a cost, and their products are rather expensive.

So, Pine64 organization, I ask you: Just how open source is Pine64 anyway?  You've certainly avoided the issues of intel's IME by using a different chip on your products.  Do you, too, speak with your chip manufacturers?  Is it a non-issue because everything is an SOC which is itself FOSS?  Do you have any sort of custom super swanky bootloader?

I ask all of this, because the aforementioned friend also told me that he just didn't get a good vibe from you folks (several years ago when he first encountered you).  I have no such qualms (I encountered you much more recently), and he couldn't put his finger on what exactly he took issue with, but I'm mostly curious to see how you would respond to such an initial reaction.

Thank you all for your awesome work!

[chithanh]

removed IME code from their intel CPUs (I think)

About the other matters I can't say with confidence, but I am pretty sure Purism did not remove the Intel ME code. Intel ME is a hardware feature, it is needed for booting the CPUs. What they do is set a flag called the "HAP bit" in the firmware, which requests ME to disable itself some time after boot.

Any manufacturer who claims to "disable" or "neutralize" Intel ME is probably exaggerating at best and lying to you at worst. OEMs cannot disable Intel ME, only Intel can.

[binarian]

removed IME code from their intel CPUs (I think)

About the other matters I can't say with confidence, but I am pretty sure Purism did not remove the Intel ME code. Intel ME is a hardware feature, it is needed for booting the CPUs. What they do is set a flag called the "HAP bit" in the firmware, which requests ME to disable itself some time after boot.

Any manufacturer who claims to "disable" or "neutralize" Intel ME is probably exaggerating at best and lying to you at worst. OEMs cannot disable Intel ME, only Intel can.

Huh, interesting!  I really don't know too much about IME so I most likely just misrepresented that part.  Thanks for the info!

[Thra11]

You should be able to see schematics and datasheets for the components used on the wiki pages. For example, the RockPro64 wiki page.

Pine64 have quite a range of products, which use a variety of different chips and peripherals, so if you want a definitive answer wrt whether any unfree blobs are required, it might help to focus on a specific product.

[binarian]

You should be able to see schematics and datasheets for the components used on the wiki pages. For example, the RockPro64 wiki page.

Pine64 have quite a range of products, which use a variety of different chips and peripherals, so if you want a definitive answer wrt whether any unfree blobs are required, it might help to focus on a specific product.

I'm more asking about their philosophy as an organization than a specific product.  I specifically DON'T want to focus on a single product.

[fire219]

Greetings all!



This post is mainly directed at the owners/operators/admins/mods/etc. of the entire Pine64 project, but I welcome community feedback as well.  The question is simple: Just how open source is Pine64 anyway?

Some context:
A friend of mine is absolutely in love with the concept of the Librem 5 phone, as well as pretty much everything else that organization does.  My understanding there is that that org has gone above and beyond the reaches of the entire bloody galaxy to open source their hardware and software.  As an example, not only is all of their Software FOSS, and not only do they provide datasheets (and I'm pretty sure schematics), but they've even collaborated with chip manufacturers to ensure components are FOSS-respecting, removed IME code from their intel CPUs (I think), written their own BIOS and UEFI bootloader, and I'm pretty sure I read somewhere that they replaced microcode on something somewhere.

But, as expected, this attention to minute detail comes at a cost, and their products are rather expensive.

So, Pine64 organization, I ask you: Just how open source is Pine64 anyway?  You've certainly avoided the issues of intel's IME by using a different chip on your products.  Do you, too, speak with your chip manufacturers?  Is it a non-issue because everything is an SOC which is itself FOSS?  Do you have any sort of custom super swanky bootloader?

I ask all of this, because the aforementioned friend also told me that he just didn't get a good vibe from you folks (several years ago when he first encountered you).  I have no such qualms (I encountered you much more recently), and he couldn't put his finger on what exactly he took issue with, but I'm mostly curious to see how you would respond to such an initial reaction.

Thank you all for your awesome work!

Most of the negative connotations people have with Pine64 is from the difficulties very early on where in the initial Kickstarter there was something like 50x the expected demand for the original Pine A64 boards.

Our products are as open as we've been able to make them on the razor-thin profit margins on the hardware, due to a large amount of work from several community developers. Almost everything is community driven.

At this point, most if not all of the boards(+laptops+Pinephone) can run almost completely libre. The issues in that regard are largely isolated to WiFi/BT driver blobs, and the initial stage 1 bootloader (which does DRAM initialization). You can use external WiFi/BT dongles to avoid the former, and some devs are working on coreboot and/or libreboot for the latter.

[Der Geist der Maschine]

At this point, most if not all of the boards(+laptops+Pinephone) can run almost completely libre. The issues in that regard are largely isolated to WiFi/BT driver blobs, and the initial stage 1 bootloader (which does DRAM initialization). 

When it comes to the pinebook pro, I think you mean the stage 2 loader - that's the binary blob which is does the DDR init and loads uboot. There is a stage 1 loader, but it resides in ROM and can never be replaced.

Rockchip's documentation is somewhat cryptic. Some time ago I tried to understand the boot process and made notes. You can read about it on my website (click my "website icon" below).

[MikeInMass]

At this point, most if not all of the boards(+laptops+Pinephone) can run almost completely libre. The issues in that regard are largely isolated to WiFi/BT driver blobs, and the initial stage 1 bootloader (which does DRAM initialization). 

When it comes to the pinebook pro, I think you mean the stage 2 loader - that's the binary blob which is does the DDR init and loads uboot. There is a stage 1 loader, but it resides in ROM and can never be replaced.

Rockchip's documentation is somewhat cryptic. Some time ago I tried to understand the boot process and made notes. You can read about it on my website (click my "website icon" below).

I'd be excited about a libre ARM64 product in form factor more extensible than the Librem phone that someone mentioned. And I think an open source-- or at least transparent-- bootloader and boot process would be appealing to many coreboot/libreboot users and others focused primarily on security who mistrust the Intel ME. So I wanted to understand what aspects of the boot process are still opaque.

Thanks for your notes,  Der Geist der Maschine!  I also found Rockchip's documentation a little cryptic, but from looking at "Build Rockchip U-Boot" it's documented that make.sh creates a "pre-loader", a "trust image", and a u-boot image.  

Taking the RK3399 as an example, inputs to this process are the binary blobs like rk3399_ddr_800MHz_v1.23.bin for SDRAM initialization; rk3399_usbplug_v1.19.bin for USB; and files that create the "trust" image, e.g. rk3399_bl31_v1.29.elf. These files are processed by executables in the "tools" directory such as trust_merger; there's no source provided for these.

Is open sourcing this toolchain part of Pine64's eventual roadmap? Or is it too heavily encumbered by licensing or trade secrets or whatever for that to be realistic? 

And what about the Stage 1 loader in ROM? It would be very exciting to get something like stage0 in there.

I'd be very interested in any thoughts, or pointers to places to learn more. Thanks!

[Der Geist der Maschine]

At this point, most if not all of the boards(+laptops+Pinephone) can run almost completely libre. The issues in that regard are largely isolated to WiFi/BT driver blobs, and the initial stage 1 bootloader (which does DRAM initialization). 

When it comes to the pinebook pro, I think you mean the stage 2 loader - that's the binary blob which is does the DDR init and loads uboot. There is a stage 1 loader, but it resides in ROM and can never be replaced.

Rockchip's documentation is somewhat cryptic. Some time ago I tried to understand the boot process and made notes. You can read about it on my website (click my "website icon" below).

I'd be excited about a libre ARM64 product in form factor more extensible than the Librem phone that someone mentioned. And I think an open source-- or at least transparent-- bootloader and boot process would be appealing to many coreboot/libreboot users and others focused primarily on security who mistrust the Intel ME. So I wanted to understand what aspects of the boot process are still opaque.

Thanks for your notes,  Der Geist der Maschine!  I also found Rockchip's documentation a little cryptic, but from looking at "Build Rockchip U-Boot" it's documented that make.sh creates a "pre-loader", a "trust image", and a u-boot image.  

Taking the RK3399 as an example, inputs to this process are the binary blobs like rk3399_ddr_800MHz_v1.23.bin for SDRAM initialization; rk3399_usbplug_v1.19.bin for USB; and files that create the "trust" image, e.g. rk3399_bl31_v1.29.elf. These files are processed by executables in the "tools" directory such as trust_merger; there's no source provided for these.

Is open sourcing this toolchain part of Pine64's eventual roadmap? Or is it too heavily encumbered by licensing or trade secrets or whatever for that to be realistic? 

And what about the Stage 1 loader in ROM? It would be very exciting to get something like stage0 in there.

I'd be very interested in any thoughts, or pointers to places to learn more. Thanks!

First off, what I write in this thread is to best of my understanding. I might be wrong from time to time.

These binary blobs are provided by Rockchip. I doubt Pine64 has access to the source.

The ROM is internal to the SOC and memory mapped to the the address of the start address of the CPU execution. You can't replace that with your own ROM (or flash or whatever). The memory mapping as well as the contents of the ROM are programmed at time of manufacturing the SOC.

What is not very helpful for this discussion, but I would like to point out that other ARM SOCs are more open source friendly. At work, we use the AST2500 from a Taiwanese company named Aspeed. Here, the memory controller is memory mapping a spi flash to the start address of the CPU execution. What's there is plain u-boot which is doing everything like initing RAM and loading the kernel and device tree. IMHO, that's very elegant and I got disappointed when I looked at Rockchip's way of booting up the SOC. Well, that way better/more transparent than our current computers

[MikeInMass]

At this point, most if not all of the boards(+laptops+Pinephone) can run almost completely libre. The issues in that regard are largely isolated to WiFi/BT driver blobs, and the initial stage 1 bootloader (which does DRAM initialization). 

When it comes to the pinebook pro, I think you mean the stage 2 loader - that's the binary blob which is does the DDR init and loads uboot. There is a stage 1 loader, but it resides in ROM and can never be replaced.

Rockchip's documentation is somewhat cryptic. Some time ago I tried to understand the boot process and made notes. You can read about it on my website (click my "website icon" below).

I'd be excited about a libre ARM64 product in form factor more extensible than the Librem phone that someone mentioned. And I think an open source-- or at least transparent-- bootloader and boot process would be appealing to many coreboot/libreboot users and others focused primarily on security who mistrust the Intel ME. So I wanted to understand what aspects of the boot process are still opaque.

Thanks for your notes,  Der Geist der Maschine!  I also found Rockchip's documentation a little cryptic, but from looking at "Build Rockchip U-Boot" it's documented that make.sh creates a "pre-loader", a "trust image", and a u-boot image.  

Taking the RK3399 as an example, inputs to this process are the binary blobs like rk3399_ddr_800MHz_v1.23.bin for SDRAM initialization; rk3399_usbplug_v1.19.bin for USB; and files that create the "trust" image, e.g. rk3399_bl31_v1.29.elf. These files are processed by executables in the "tools" directory such as trust_merger; there's no source provided for these.

Is open sourcing this toolchain part of Pine64's eventual roadmap? Or is it too heavily encumbered by licensing or trade secrets or whatever for that to be realistic? 

And what about the Stage 1 loader in ROM? It would be very exciting to get something like stage0 in there.

I'd be very interested in any thoughts, or pointers to places to learn more. Thanks!

First off, what I write in this thread is to best of my understanding. I might be wrong from time to time.

These binary blobs are provided by Rockchip. I doubt Pine64 has access to the source.

The ROM is internal to the SOC and memory mapped to the the address of the start address of the CPU execution. You can't replace that with your own ROM (or flash or whatever). The memory mapping as well as the contents of the ROM are programmed at time of manufacturing the SOC.

What is not very helpful for this discussion, but I would like to point out that other ARM SOCs are more open source friendly. At work, we use the AST2500 from a Taiwanese company named Aspeed. Here, the memory controller is memory mapping a spi flash to the start address of the CPU execution. What's there is plain u-boot which is doing everything like initing RAM and loading the kernel and device tree. IMHO, that's very elegant and I got disappointed when I looked at Rockchip's way of booting up the SOC. Well, that way better/more transparent than our current computers

Thanks again, Der Geist der Maschine! In my mind I had been conflating Rockchip and Pine64; it is helpful to understand what is provided by which company.

It will be interesting to see how far transparency can get in the ARM64 world.