| 30 Jun 2022 |
 matthewcroughan - nix.how | Basically they give you a bunch of "bitbake" code, like nix code, which you import. Then it gets rid of all the quirks, and patches software, etc. Much like an overlay in nix. | 08:54:27 |
| matthewcroughan - nix.how | An example of what a bsp would do, is patch ffmpeg to have support for the Pi's OMX gpu. | 08:54:58 |
| matthewcroughan - nix.how | what we do with configureFlags = [ --enable-omx ] | 08:55:09 |
| matthewcroughan - nix.how | * what we do with configureFlags = [ "--enable-omx" ] | 08:55:20 |
 dramforever | In reply to @dramforever:matrix.org
I guess I should clarify that the thing I worry about most is not just linux_visionfive but all the other things in the PR IMHO We're not even sure how long the VisionFive will last, and what other things StarFive will do, and what the other Linux-capable RISC-V computers in the future will be like. We already know StarFive is working on a JH7110, an even better 8-core thing (I think these two are not the same?).
Will we be updating linux_visionfive or will we need linux_visionfive_v2? Are we prepared to deal with upstream issues in github:starfive-tech/*? Will StarFive keep upstreaming their drivers or not? | 08:55:39 |
| matthewcroughan - nix.how | https://github.com/agherzan/meta-raspberrypi | 08:55:49 |
| matthewcroughan - nix.how | here's what their "BSP" looks like | 08:55:54 |
| matthewcroughan - nix.how | So in order to patch mesa, they cannot just mesa.override since their language is simply terrifying and doesn't work like that, they do this https://github.com/agherzan/meta-raspberrypi/tree/master/recipes-graphics/mesa | 08:56:45 |
| matthewcroughan - nix.how | Line 6 of mesa-gl_%.bbappend is basically what we could do with foo.overrideAttrs (_: { postFixup = "rm -rf someFile"'; }) | 08:57:58 |
| dramforever | In reply to @dramforever:matrix.org
IMHO We're not even sure how long the VisionFive will last, and what other things StarFive will do, and what the other Linux-capable RISC-V computers in the future will be like. We already know StarFive is working on a JH7110, an even better 8-core thing (I think these two are not the same?).
Will we be updating linux_visionfive or will we need linux_visionfive_v2? Are we prepared to deal with upstream issues in github:starfive-tech/*? Will StarFive keep upstreaming their drivers or not? A question I've been thinking of throughout this discussion is... Why doesn't the Unmatched need all this, honestly, crap? | 08:59:51 |
| matthewcroughan - nix.how | Has it not just been around for longer and therefore upstreamed more stuff? | 09:00:25 |
| matthewcroughan - nix.how | And perhaps SiFive are just faster, better, at upstreaming? | 09:00:35 |
| matthewcroughan - nix.how | It's all down to upstreaming, etiquette, putting the work in, on behalf of the vendor isn't it? | 09:00:53 |
| dramforever | Upstreaming in this case means putting things into linux not linux_unmatched, right? | 09:01:21 |
| matthewcroughan - nix.how | It takes work and time to do the extra step of upstreaming the code, and ultimately the vendor needs to do that work | 09:01:24 |
| matthewcroughan - nix.how | In reply to @dramforever:matrix.org
Upstreaming in this case means putting things into linux not linux_unmatched, right? yes | 09:01:29 |
| matthewcroughan - nix.how | technically anyone can do the work of upstreaming the code to Linux, but it's a lot easier for people working for the vendor to do it | 09:01:49 |
| matthewcroughan - nix.how | And if it's simply not in the culture to do that, fast, and readily, then it just chugs along at a snails pace | 09:02:12 |
| matthewcroughan - nix.how | All of this will eventually settle, since all of the work is being done in the open | 09:03:02 |
| matthewcroughan - nix.how | With android phones there are genuine proprietary bits which make this a permanent problem though | 09:03:30 |
| dramforever | So the thing is about what we do in the meantime | 09:03:32 |
| matthewcroughan - nix.how | Yeah, and nixos-hardware is a collection of nix code, equivalent to yocto BSPs which you import and it gets rid of all the quirks. | 09:03:52 |
| matthewcroughan - nix.how | so it's definitely a good thing to figure out how we best integrate with that | 09:04:21 |
| matthewcroughan - nix.how | I wonder at which point we stop though. Where is the distinction? Yocto don't make one. | 09:05:26 |
| matthewcroughan - nix.how | In their BSPs, they will provide overlays which patch all of the software possible, which seems clearly wrong to me :D | 09:05:41 |
| matthewcroughan - nix.how | If Yocto were doing nixos-hardware, they would add overlays for all of the software that came to their mind, and patch it to work better with the hardware. | 09:06:12 |
| matthewcroughan - nix.how | I seem to remember a version off ffmpeg in nixpkgs specifically for the raspberry pi | 09:07:00 |
| dramforever | I feel like the situation with StarFive is slightly better than no upstreaming, because there's one person, Emil Renner Berthing, doing all the Linux upstreaming | 09:07:06 |
| matthewcroughan - nix.how | * I seem to remember a version of ffmpeg in nixpkgs specifically for the raspberry pi | 09:07:06 |
| matthewcroughan - nix.how | It looks like that too has been removed. But it's an interesting comparison. | 09:07:13 |
