TonyMac32

Of course they aren't sharing their work on Github because "beta". I've got some emails to write I guess...

Something like that. The drawbacks are considerable, and probably more trouble than it's worth, I just see it as an easy way for a well-intentioned blogger to completely bypass all attempts to educate the user.

I dream of a world with mainline linux for all... So, any chance a compliance matrix could be made per board, including key information such as default kernel capabilities, and parse this by the build script? Instead of hard-coding everything into the script? Ideally the same data source document (tab delimited or xml?) could be shared between the web page board description and the build script to reduce double work. And not to try to add barriers, but perhaps we should somehow stop direct linking to images? Require linking to the board's description?

*chirp chirp chirp* I'm still waiting on mine to make the slow boat ride from China, anything new come up? *edit* looks like schematic 2.0 is available. @Xalius , what tool did you use to copy the first 16 MB over to the SPI-NOR?

IIRC, they are A12's but ARM called them A17 due to the performance level.

The rtl8723BS driver can be found in a few repos if you're willing to build yourself, I had to add it to the Rockchip 4.4 kernel for the Tinker Board.

I like the feature matrix idea personally, of course someone has to do the paperwork to keep it up to date. Red. --> Yellow. --> Green. And gray (grey?) for untested. The "champion" for each board could be the caretaker of the information, then we just need to lace it into each board's DL/info page.

Well, I am the only poor guy to have the board. ;-)

I have confirmed the issue, the window attempts to render then crashes to desktop on 4.12. Which kernel are you running?

I would guess it was dd that got you, I've booted Tinker OS 1.8 on my board successfully

The Legacy 4.4 kernel has the wifi and bluetooth, , although I have to warn you I have not tried A2DP with it. Remember WiFi and BT are sharing a single antenna, that will result in some less than amazing throughput if using both simultaneously. You will probably also want to change the default frequency governor, and I have not tried using any webcams with the board.

*Head Explodes*

This I have not enabled yet as I do not have one to test. If you're willing to be a guinea pig (and someone else has a how-to on using the camera), I can work on enabling it in the kernel.

The rk3288's H.265 support is supposedly a bit buggy and is considered "legacy" hardware by Rockchip. I've not tested it to be honest, as I've been working on the peripherals/etc. @chwe I doubt my reply meets Heinrich's quality standard for freely provided information, sadly.

5 years learning German and 10 more working for German companies and I never learned that gem. For the use case statement, if a board is geared to one of them it would be only "for" a subset of the intended audience, and will turn people away simply on that notion. On the other hand, be equally garbage at everything and you'll sell better.

I really feel like a vendor needs to align with the community and really give 100% to a single board and make it actually work. Making new boards all over the place is just insane. Although I kind of want to make "Le Turnip" or "Le Brussel Sprout". Ooooh, maybe "Le Radish". In all seriousness though, I'm glad chip vendors are getting the hint and beginning to actively open-source the software/support Linux. I'm glad we're seeing people actually design things that are geared toward individual use. I'm not sold that more than 10% of these boards are actually any good at anything though, especially considering the speed of release on most of them. Well, I got more disappointed looking at it carefully, I had initially thought one of the headers right next to the power in was a pin header for power. Nope. :'( PS: I apologize for any crazy typing issues, I'm getting used to a new laptop I got so I could escape my basement workstation while designing some hardware.

Look at rockchip patchwork area, they are adding the RK805, which I believe is the pmic involved here? They are very similar, but not quite the same. https://patchwork.kernel.org/project/linux-rockchip/list/?q=rk805

Yeah, I know the points. The trouble is no one with that much technical know-how would be on here complaining about the issue, they'd just solve it, or never have it because they knew going in. The people who wind up in trouble because of the micro-USB are the new-to-SBC crowd who don't have the experience to know what it will do.

I can contribute to this, I would recommend having a checklist for each SBC marking off what Armbian-related documentation has been completed. People with specific hardware would of course have to step up, of course a lot of this stuff exists in piecemeal throughout the forums.

I have some SPI flashes in the mail for a tinker board experiment. ;-)

Do you have a document for the format of the SPI to boot? Or is it the same as eMMC?

Yes, I just had to disable DMA on the uart for the Tinker Board, it was locking up the kernel.

I've been toying with the idea of designing a simple board and publishing the artwork/BOM for it, but if you look around, one for the raspberry pi should be available, look for DIN rail pi accessories, some of them have regulator hats. As far as filtered (I forgot to hit that point), I am referring to a capacitor/zener diode combo to protect against switching noise and over voltage.

Yes, they are enabled, UART2 is the terminal.

This wouldn't be a chip-specific quirk, this would be back at the SPI driver itself, and would cause problems with any device attached to a given transmission line. I didn't give a clean enough break between the topics, the SPI mode used, I agree, the driver should handle, but I always like to double check. As for a needed sample delay due to routing capacitance, there is no automatic software solution that can talk to that, essentially the data received is just wrong/arbitrary, it would be a physical layer issue with the trace lengths/long parallel runs/coupling to other traces/etc. @Xalius, can you grab a shot of a single transaction (16 bits?) and grab the rise/fall time of the Clock, MOSI and MISO lines? Very nice scope by the way, I'm afraid I only have things that shiny at work. ;-) We use LeCroy WaveRunners and, when budget matters, PicoScopes. I was thinking about snagging a Picoscope for myself, as I currently just have to "trust the magic" on high speed signals. Also check to see if you have flux built up around the IC terminals.