Anyone in the #PostmarketOS community able to recommend some good "hands on" or (kinda) guided way to learn how to port it to new devices and get to know all of the low level stuff required for it?
Like get this very cheap dev board or phone and this old version of the code and then follow along all of the steps involved in getting #Linux to run on this hardware? (Best for both cases when you have documentation and circuit diagrams and when you don't)
It's such a complex topic that I feel lost
@agowa338 I don't think there can ever be an effective guide like this. The first step is always "get to know your particular hardware well", and that's what determines what and how will have to be done next.
@dos Well it would obviously be a guide containing a trial and error process to "get to know" the "particular hardware well".
But I currently get lost in all of that. I don't even know where to start or what I would have to look for or even what I could do in order to do that (sanely).
Like if I have datasheets, ok I guess but what information do I need from there?
@agowa338 But the answer is still: it depends. What's the existing software support for the SoC and peripherals? How similar is it to already supported ones? How does the boot process look like? What resources you have available to base your research on? This all varies greatly device-to-device and if there was a guide it would have been already done.
If I were to write a guide, it would be: start with small steps on existing ports, observe others working, and you'll get there eventually.
@dos Of course. But if you don't know what it depends upon or how do account for the variables it is a lost battle.
Just for example pentesting is similar. You also don't know what to look for before you find it but still there are things and "workflows" (in a lack of a better word) you can use to approach it.
I currently don't even know what I don't know...
@dos
Oh and btw that's kinda why I imagined the guide to start with "buy this cheap dev board or phone" and use this older version of the code base (where support for it was not yet implemented). And basically replicate the entire process using that guide on your side. With all of the questions and considerations laid out in plain sight.
@agowa338 I really have no better idea than "observe what's missing and try to fill the gaps, then repeat". What needs to be done will be very different across devices, and you'll have to rely on having wide enough background knowledge to connect the dots.
Pretty much all existing ports, including Librem 5 and PinePhone, still have plenty of low hanging fruits to deal with. That's what you'd start with to get to know the stack. Also: browse the commits, especially those beyond your grasp *yet*.
Maybe it's yet again one of these "differences in learning between bottom-up and top-down".
I know some people learn best by starting with the fundamentals individually and then later on being able to glue them together. But for me I need to get the final problem first and then start learning all of the components one by one. Like a puzzle where you first look at what you'd like to be creating.
@agowa338 My impression would be that knowing the fundamentals individually is just required for this kind of tasks. Sure, you could probably get away without it on some subset of devices that are similar enough to what's already supported, but otherwise you'll either end up outsourcing what's actually hard about it to people you'll be asking for help, or you won't really do much.
@agowa338 That said, it's not like it's some kind of black magic only to be known by insiders either. If you play with microcontrollers, can write and debug a I2C driver, set up clocks, find your way in the device tree and hack your phone's kernel and/or u-boot on an existing port, you should already be able to do plenty of useful work on a brand new port just on your own.
@dos I can do a bunch of these things individually, but I have absolutely no clue "why" it would be required for this or "how" all of these come together.
And ngl, learning I2C and such without having anything that already works to tinker with is also a huge pain. But Ben Eater https://www.youtube.com/@BenEater was a huge help to get started. You get something working to start with and shown all of the basic tools you'd need and can adventure out from there on your own.
@agowa338 That's why I'm talking about hacking on existing ports so much. It gives tangible results right away while operating in the same knowledge space.
@dos I see your point. I'm also not saying "No" to it. It'll be what I'll do as no such guid exists yet.
However I hope you can see why I think such a guide would be a huge help, too. Like right now even if I'd try to start to work on any of these there are so many unknowns and no way to even know what individual pieces exist or how they come together that it is quite challenging to get started or even know what you can do...
Like lets make it more specific. There is a port for one device and the camera on it doesn't work because "it is missing in the device tree". Is this something I could work on? Or not? It is quite reasonable to expect it to "not be that simple" especially when it existed for 5 years by now. I imagine if it was easy and "something a beginner can do" someone would already have done it...
@dos And then there are also a lot of things involved that literally aren't well documented.
Like for some devices it says to wipe the dtbo partition. But nobody says "WHY". From my current understanding the the device tree overlay and the device tree need to be merged for it to work properly. But yet for some odd reason not?!?!
@dos
In the end it probably is a lot of these little details that keep confusing me right on the journey.
@agowa338 > It is quite reasonable to expect it to "not be that simple" especially when it existed for 5 years by now.
There are so many things I have worked on in mobile GNU/Linux (cameras included) that weren't done for several years that turned out to be just a case of "nobody has looked deep enough at it yet" that it's generally safe to assume you'll be able to do *something*, and even if not then figuring out why it's not the case is still a valuable outcome 😛
oh, ok. Also a guide would help here to convince oneself to just take a leap anyway and try I think.
> My impression would be that knowing the fundamentals individually is just required for this kind of tasks
Of course it is. But think about it like an advanced equation in math. I need to see the complex one (even though I don't have the tools to solve it yet) to make it way easier to learn all of the fundamentals required for it one by one. That's probably because it just fits into a big picture and allows to fit it into a frame way easier instead of floating around in a vacuum
@dos until all of the loose ends get tied up eventually.
@agowa338 But there's no equation there yet. Your job is to come up with one 😜
@dos In my analogy that process is the equation.
Basically all of this boils down to I want to know the thing I'm working on can work and that there would be someone to ask for help when I'm stuck (if you do CTFs, kinda like that). And not that I'm putting all of my energy into something that others way more skilled already failed at and never knowing if I'm doing it wrong or if it is just not possible (yet) because of external factors I'm not (yet) aware of even exist nor skilled enough to
@dos identify on my own.
@dos
> wide enough background knowledge to connect the dots.
Yea, hence the wish for such a guide. Even it is only for a particular device it'll still show the journey and will massively simplify asking the right questions instead of just "how do I get linux to work on a device it currently doesn't work on?" (which is not actionable and not helpful).
I don't expect such a guide do at least go through the process once and know where all of the moving parts are to see the bigger picture.