3 ms·

I'd hardly argue that the RK3399 SoC is more "open" than any of the broadcom SoCs. You can't even _see_ the MMIO tables for the RK3399 without an NDA. This isn'

I'd hardly argue that the RK3399 SoC is more "open" than any of the broadcom SoCs. You can't even _see_ the MMIO tables for the RK3399 without an NDA. This isn't different from Broadcom SoCs, but at least the Pi has a large community behind reverse engineering everything. The RK3399 is barely supported by non-Linux distributions (last I checked FreeBSD didn't even boot the A72 core cluster, just the A53s, which leaves a ton of perf on the table) because any work to support it requires either a) blackbox reverse engineering or b) mucking around with the patches vendors (who _do_ have NDA access) have submitted to Linux.

octoberfranklin 5y ago
> I'd hardly argue that the RK3399 SoC is more "open" than any of the broadcom SoCs. What? The gru-kevin chromebook (RK3399) can be booted without using a single binary blob, absolutely everything (even the arm trusted firmware) built from source. I use mine that way. I've never seen a laptop with a "broadcom SoC" that could make that claim. I think you've been deluded by a certain fruit pastry vendor's marketing budget. https://github.com/SolidHal/PrawnOS https://github.com/SolidHal/PrawnOS
- Sirened 5y ago
  I think we're coming at this from two different definitions of "open". There is a very large difference between "blobless Linux compatible" and "open hardware". Have you tried to use any of these SoCs on any OS other than Linux? Good luck lol, because as I said Rockchip has only really upstreamed support for this chip in Linux and has left everyone high and dry. This is why I specifically called out the issue of MMIO mappings. Seriously, try and scrounge up the addresses for the DMA engines on the RK3399. Or, hell, literally any information whatsoever about the UARTs. The primary place to find any of this is not in public vendor documentation but rather in the device trees Rockchip has submitted to Linux and the various drives different vendors have submitted. Device trees and digging through a pile of barely document C spaghetti is not a suitable replacement for actual documentation. I am coming at this primarily from the perspective of an OS developer. I am not particularly concerned with blobs and non-free code. I am, however, incredibly frustrated by the fact that I cannot do even very basic things with my hardware without spending hours going spelunking in the Linux kernel because vendors refuse to actually provide public documentation for the products they ship. There is a subtly annoying trend in the FOSS community to assume that Linux and Linux derivatives are the only operating systems worth caring about. An undocumented chip which ""runs Linux without blobs"", while perfectly great for Linux users, is not some wonderful thing for everyone who doesn't care about Linux. Frankly, I'd much prefer a blob-ful SoC if it meant I could actually do hardware bring up because a sprinkling of non-free components is much better than not supporting an entire platform.
  - imtringued 5y ago
    I don't know how you turned a classic ARM vendor problem into an anti Linux rant. If it weren't for the GPL you would just get a binary blob for a proprietary Linux fork and then you would have to reverse engineer the undocumented features from raw machine code.
    - Sirened 5y ago
      This isn't a criticism of Linux itself or the GPL, it's a criticism of the fact that both people replying to me and vendors treat Linux as if it's the only operating system worth caring about. Support for Linux is neat but it is not (and cannot) be the definition of open hardware because Linux is not the only things. >If it weren't for the GPL you would just get a binary blob for a proprietary Linux fork and then you would have to reverse engineer the undocumented features from raw machine code. Just because they could be doing significantly worse does not mean that they're actually good. Yes, they could do this. It would not be an open hardware platform. They could also upstream software support in such a way that it is a pain in the ass to figure out how the hardware works, which I also contend is not open hardware platform. And, anyways, it's a rather bold assumption of yours to assume that the drivers actually work as intended lol. I'm sure many in the Linux kernel community would deeply appreciate being able to just write the damn drivers themselves instead of being left with broken and incomplete drivers with little recourse outside of reverse engineering the hardware or begging random vendors to fix it. This is not indicative of open hardware, this is literally just the same problem except now you've blessed the platform as open.
      - bri3d 5y ago
        I see your point. I think everyone is getting caught up around the definition of "open," and we have different wants and needs. I see how it's frustrating to you that people get GPL source and declare "victory" and give up, leaving BSD in the dust. I'm definitely someone who does this, and you made me think about how much nicer it would be if people continued to advocate for documentation instead. What I want from my "open" hardware is the ability to access the full source code for what is being executed on my device, to ensure there are not unexpected background tasks and to be able to debug issues end to end without having to do as much reverse engineering. So for me, the giant supervisor blob on the Pi is obnoxious - it does random things I don't know about, and I can't look into it to see what's going on. What you want from "open" hardware is the ability to write driver code under a very specific software license (BSD). So for my needs, I'll take GPL drivers against hardware all day versus documentation against a black-box HAL. For your needs, maybe the black-box HAL is OK since it lets you run BSD. Also, "the drivers work as intended" could just as easily be moved to "the blackbox HAL works as intended" and you have the same problem in your "Broadcom is fine because the HAL interface is documented" scenario. If you make a HAL call and it doesn't do what you expect, you're back to RE again anyway. Anyway, I think we can all agree that full documentation is the ideal state, but sans that ideal state, I'll take GPL source over documentation and a HAL blob, and you'll take the HAL blob and documentation over GPL source. I think everyone wins if we all keep pushing for the ideal state of unencumbered documentation where we can, instead of sitting back when we have one thing or the other!
bri3d 5y ago
What's wrong with A or B? Obviously documentation would be ideal, but I still think an SoC with freely licensed source code available that talks to peripheral devices directly qualifies as much more "open" than one where even "open source" drivers are actually just talking to mailboxes to a HAL running in an RTOS. I think the challenge with the Broadcom stuff is fundamentally architectural - even with more reverse engineering eyes on the scene, you're working with an SoC that's a big proprietary blob running on an obscure architecture (VPU) which is hosting an ARM Linux box, vs. the Rockchip stuff which is a much more traditional model with memory and register mapped peripherals.
- Sirened 5y ago
  I am also a big Broadcom VideoCore hater (lol), but: >an SoC with freely licensed source code Free as in "GPL". The GPL is incompatible with a slew of other licenses and so being dependent on reading the Linux source for how to write drivers for your own OS is an incredibly perilous legal position should you not license your code under the GPL. Real documentation (for talking to blobs or real hardware) almost allows you to license your code however you please and so it is objectively more free. This, mind you, is not a hypothetical: I am quite literally in this position and have abandoned Rockchip SoCs (despite being all around better tech) because supporting them would possibly violate the project license and the rights of the other contributors. I can, however, support Broadcom SoCs because their documentation is freely available without licensing stipulations despite their non-free blobs. The Rockchip SoCs are free and open only to the extent you either like Linux or can adhere to the GPL, which is frankly a bizarre position to be in when trying to use an SoC.

octoberfranklin 5y ago

> I'd hardly argue that the RK3399 SoC is more "open" than any of the broadcom SoCs. What? The gru-kevin chromebook (RK3399) can be booted without using a single binary blob, absolutely everything (even the arm trusted firmware) built from source. I use mine that way. I've never seen a laptop with a "broadcom SoC" that could make that claim. I think you've been deluded by a certain fruit pastry vendor's marketing budget. https://github.com/SolidHal/PrawnOS https://github.com/SolidHal/PrawnOS

Sirened 5y ago
I think we're coming at this from two different definitions of "open". There is a very large difference between "blobless Linux compatible" and "open hardware". Have you tried to use any of these SoCs on any OS other than Linux? Good luck lol, because as I said Rockchip has only really upstreamed support for this chip in Linux and has left everyone high and dry. This is why I specifically called out the issue of MMIO mappings. Seriously, try and scrounge up the addresses for the DMA engines on the RK3399. Or, hell, literally any information whatsoever about the UARTs. The primary place to find any of this is not in public vendor documentation but rather in the device trees Rockchip has submitted to Linux and the various drives different vendors have submitted. Device trees and digging through a pile of barely document C spaghetti is not a suitable replacement for actual documentation. I am coming at this primarily from the perspective of an OS developer. I am not particularly concerned with blobs and non-free code. I am, however, incredibly frustrated by the fact that I cannot do even very basic things with my hardware without spending hours going spelunking in the Linux kernel because vendors refuse to actually provide public documentation for the products they ship. There is a subtly annoying trend in the FOSS community to assume that Linux and Linux derivatives are the only operating systems worth caring about. An undocumented chip which ""runs Linux without blobs"", while perfectly great for Linux users, is not some wonderful thing for everyone who doesn't care about Linux. Frankly, I'd much prefer a blob-ful SoC if it meant I could actually do hardware bring up because a sprinkling of non-free components is much better than not supporting an entire platform.
- imtringued 5y ago
  I don't know how you turned a classic ARM vendor problem into an anti Linux rant. If it weren't for the GPL you would just get a binary blob for a proprietary Linux fork and then you would have to reverse engineer the undocumented features from raw machine code.
  - Sirened 5y ago
    This isn't a criticism of Linux itself or the GPL, it's a criticism of the fact that both people replying to me and vendors treat Linux as if it's the only operating system worth caring about. Support for Linux is neat but it is not (and cannot) be the definition of open hardware because Linux is not the only things. >If it weren't for the GPL you would just get a binary blob for a proprietary Linux fork and then you would have to reverse engineer the undocumented features from raw machine code. Just because they could be doing significantly worse does not mean that they're actually good. Yes, they could do this. It would not be an open hardware platform. They could also upstream software support in such a way that it is a pain in the ass to figure out how the hardware works, which I also contend is not open hardware platform. And, anyways, it's a rather bold assumption of yours to assume that the drivers actually work as intended lol. I'm sure many in the Linux kernel community would deeply appreciate being able to just write the damn drivers themselves instead of being left with broken and incomplete drivers with little recourse outside of reverse engineering the hardware or begging random vendors to fix it. This is not indicative of open hardware, this is literally just the same problem except now you've blessed the platform as open.
    - bri3d 5y ago
      I see your point. I think everyone is getting caught up around the definition of "open," and we have different wants and needs. I see how it's frustrating to you that people get GPL source and declare "victory" and give up, leaving BSD in the dust. I'm definitely someone who does this, and you made me think about how much nicer it would be if people continued to advocate for documentation instead. What I want from my "open" hardware is the ability to access the full source code for what is being executed on my device, to ensure there are not unexpected background tasks and to be able to debug issues end to end without having to do as much reverse engineering. So for me, the giant supervisor blob on the Pi is obnoxious - it does random things I don't know about, and I can't look into it to see what's going on. What you want from "open" hardware is the ability to write driver code under a very specific software license (BSD). So for my needs, I'll take GPL drivers against hardware all day versus documentation against a black-box HAL. For your needs, maybe the black-box HAL is OK since it lets you run BSD. Also, "the drivers work as intended" could just as easily be moved to "the blackbox HAL works as intended" and you have the same problem in your "Broadcom is fine because the HAL interface is documented" scenario. If you make a HAL call and it doesn't do what you expect, you're back to RE again anyway. Anyway, I think we can all agree that full documentation is the ideal state, but sans that ideal state, I'll take GPL source over documentation and a HAL blob, and you'll take the HAL blob and documentation over GPL source. I think everyone wins if we all keep pushing for the ideal state of unencumbered documentation where we can, instead of sitting back when we have one thing or the other!

bri3d 5y ago

What's wrong with A or B? Obviously documentation would be ideal, but I still think an SoC with freely licensed source code available that talks to peripheral devices directly qualifies as much more "open" than one where even "open source" drivers are actually just talking to mailboxes to a HAL running in an RTOS. I think the challenge with the Broadcom stuff is fundamentally architectural - even with more reverse engineering eyes on the scene, you're working with an SoC that's a big proprietary blob running on an obscure architecture (VPU) which is hosting an ARM Linux box, vs. the Rockchip stuff which is a much more traditional model with memory and register mapped peripherals.

Sirened 5y ago
I am also a big Broadcom VideoCore hater (lol), but: >an SoC with freely licensed source code Free as in "GPL". The GPL is incompatible with a slew of other licenses and so being dependent on reading the Linux source for how to write drivers for your own OS is an incredibly perilous legal position should you not license your code under the GPL. Real documentation (for talking to blobs or real hardware) almost allows you to license your code however you please and so it is objectively more free. This, mind you, is not a hypothetical: I am quite literally in this position and have abandoned Rockchip SoCs (despite being all around better tech) because supporting them would possibly violate the project license and the rights of the other contributors. I can, however, support Broadcom SoCs because their documentation is freely available without licensing stipulations despite their non-free blobs. The Rockchip SoCs are free and open only to the extent you either like Linux or can adhere to the GPL, which is frankly a bizarre position to be in when trying to use an SoC.