>Having worked with devicetrees and hated it, I don't like this idea. I don't like the modern world of ARM and embedded where you have hardcoded firmware images for every single device. I like the x86 model, where you have a one size fits all boot disk which just loads different drivers. You don't port your OS to a new computer, you just write drivers for the new hardware parts. And your hardware describes itself to the OS.
Having worked with ARM too I have to disagree. I found device trees really flexible and easy to get going.
However, I worked with Rockchip hardware so I had pretty good documentation, lots of examples, and source code for everything(for an old linux kernel, but still). This basically ensured I could do everything I wanted.
Of course, when a vendor doesn't provide documentation and example driver source this may not be so easy.
I guess the different experience is because I had to deal with Allwinner.
But even with Rockchip, different vendors have different levels of support. We had one potential vendor that had excellent documentation, delivered the source code to everything, and responded really quickly and helpfully - in english - to questions. But they were way to expensive. And we had another who just gave us some mystery Android + Linux images, GPL violation included. No schematics. I spent some time porting Linux from one board to the other - they were very similar - but never finished, and constantly was afraid of configuring a voltage regulator wrong and blowing it up, or something similar.
Compare to x86 where I can just order random parts form newegg, screw them together and pop in a boot USB drive, and it will mostly work. I know that you get what you pay for, but at least I would expect the SBC vendors to do hardware enablement, and provide some kind of abstraction that I can run my OS on (or upstream their code).
Have you ever configured a generic MIPI LCD panel and showing a custom splash screen?
With EDK2, on x86?
Or configure and tuning some custom DDR that happen to be already soldered on the board? Or bootstraping some parameters from an EEPROM or external microcontroller?
Compiling and customizing EDK2 for x86 (to boot Windows) was a nightmare and I never want to do it again. I'd rather "make aboot -j8" my entire life.
Please tell me you've found the secret formula to automagically add ANY display panel purchased somewhere in Asia, on x86. Otherwise I'll back to praise the devicetree.
I’ve been struggling with Rockchip! Do you have any links to the docs you’ve used? The ones I have found for the rock pi n10 on radxa’s site are very incomplete.
Yes, but all my docs are for rk3566, pine's Quartz64-A and soquartz boards. Radxa uses the same chip in few places, but I'm not sure if the board schematics will be of any use to you. If this is the chip you need info for let me know by replying to this message and I'll do a pastebin listing the docs I have.
Everything I have came from 3 sources. There is a Linux BSP SDK file (36GB or so) and an Android SDK (75gb or so). Both have docs folders with lots of docs documenting various sdks (for the gpu, npu, camera etc). Those files also contain drivers source for old linux kernels that can be adapted to newer ones with a bit of work. Both are linked on pine's wiki under soquartz. Just Google soquartz pine wiki.
Having worked with ARM too I have to disagree. I found device trees really flexible and easy to get going.
However, I worked with Rockchip hardware so I had pretty good documentation, lots of examples, and source code for everything(for an old linux kernel, but still). This basically ensured I could do everything I wanted.
Of course, when a vendor doesn't provide documentation and example driver source this may not be so easy.