TonyMac32

If you apt upgrade let me know what kernel you wind up with, and double check the available frequencies. The op points are defined in the device tree, they shouldn't have changed. I will verify later

Entirely dependent on your SBC. For an Amlogic device, 2A is typically just fine. For an RK3288 device, well, not as much.

... Please tell me which image that is, also, perform an apt update and apt upgrade. I'm unaware of any image missing those op points, but to be fair I don't install every single generated image.

Ah, I misread. To be honest I think it was actually faster to start from scratch and install the build system on a PC and build than to recompile on the ARM device itself...

Docs.armbian.com

Rockchip updated again, all incremental patches included upstream again. If they continue to update at this frequency I'd say we can just trust that they'll do it.

I could put together a simplified equivalent cuircuit diagram for the web page to cover this sort of power confusion, since it is universal and based on very basic electrical concepts. As for the instability concern: what are the cooling options being used? I have a large heatsink, and left off a Tinkerboard-only CPU throttling patch when the GPU was in use. I've never had instability, and given the Tinker does not have the worst cooling in the RK3288 world, assumed the patch was unnecessary (I also have the thermal throttle set to 80 instead 85 C). I'm not ready to blame this strictly on the hardware just yet, unless it's possible your supply suffers from small "micro-break" events under heavy load. In this situation the device fails to provide stable power for some number of microseconds, potentially starving the board for power. I'll build a 4.4 kernel with the WZYY cpu/gpu patch for OP to evaluate. Sent from my Pixel using Tapatalk

@NicoD do you have any logs leading up to the crash? Also, @JMCC, can we just both verify the kernel being used? If one is 4.4 and one is 4.14 or 4.16, then we still have a possible software issue. I will try this test if possible as well

Sorry, at the day job, now on lunch. I never used the Tinker Board kernel, so the DVFS settings were always patched in using the Tinker and Rockchip references. I will verify the settings As far as power, there is no debate. The 1.8 A is the minimum spec for current capability, I have information that says these are tested far beyond that, but again, multiple mate/unmate cycles would reduce that. So, having dozens implemented with excellent supplies and top quality cables only plugged in a handful of times is not representative of a realistic situation for most users. I applaud the quality of the deployment in this case, but consider it anecdotal evidence at best that Ohm and Kirchoff can be safely ignored. This is independent of Tinker. While it's not uncommon to see in the field, "USB" and "industrial" are a bad combination.

It is none of my business how you destroy your things...

It's about the commits with upstream patches, If I cherry pick the ones for tinker board there's other stuff in them.

OK. Do you want to handle the upstream patches part? The first ones on Tinker were in a joint commit with 4.4 and 4.9 upstream. Should we write them down in the 5.42 thread?

The issue is an update to the vendor kernel. If you build against the development branch it will succeed. in config-default.conf (if that's the config you're using) add LIB_TAG="development" We're having a discussion now about how to better handle development changes/the repo, the development branch was an experiment to avoid breaking nightly builds before more thorough testing than one person can usually do. Once we get it all straightened out I would of course recommend sticking with the master branch unless you're actively developing

I was worried about that. Well, I can get to work on my part of the mess.

The raspberry Pi community is so strong because no one initially waited for others to do it for them, it's kind of a chicken and egg problem. A solid community and repository of knowledge brings in users, but it takes users to create such a community and repository of knowledge.

I think a gerneral one is to have very granular branches dedicated to specific things, but that isn't so practical I think. I saw we rolled out new Meson64 images, but the changes haven't been rolled into Master. My Git is not amazingly strong, however, would this be the proper case to use tags?

ugh, forgot that part. Perhaps something with all new boards could be decided if that were deemed reasonable. OK, but beyond that, does organizing things by SoC/board seem interesting? It would make documentation a bit easier as well, an example board template could be made readily. Right now, you have to navigate multiple trees, and realize the U-boot burning script is in a config file in the "sources" directory, etc. It's not the simplest thing to navigate if a new user is not extremely familiar with it. Adding the u-boot patch for Tinker S, for instance, took far longer than it should have, I had to rename the folder a couple times (I thought I needed a "default" or something in the name, turned out no). In a device-based directory tree I could just create a "uboot" folder in the SoC folder without being worried about getting the directory name wrong (whoever introduced the SoC had to worry about that.) Possible top level directory structure: bsp cache config lib output userpatch Patch and blobs are now under bsp arranged by SoC and (where appropriate in a non-breaking the universe way) board (potato, K2 u-boot blob would be in there, etc). Config now holds board definitions only, ideally merging the board definition with the sources part of the sources file, then moving all of the script-related parts of it to the new bsp tree. Bootenv/bootscripts/fex/kernel configs are likewise arranged in bsp folder by board. Would be a lot of work, I think it could be done incrementally (start with the patches, then work through the other parts), I just wanted to mention the idea and see if it seemed logical to me relatively late at night...

Of course it will, you just need some clippers to cut out the slots. ;-). I guess it depends on how close to the header that is...

Tkaiser is, of course, correct. Did you get the blue led before, or only with the updated image? Sent from my Pixel using Tapatalk

From a fab perspective, as in the context of the statement, they aren't. There isn't much on the board, so adding holes is not a technical concern. Now, to discuss fluid dynamics in conversational terms, a ton of small holes are most certainly inferior to a few properly sized ones for the rate of flow desired. For a given volume of air to travel through a reduced cross section it must gain velocity. Without a certain amount of pressure that cannot happen, so it simply maintains it's velocity and thereby less air flows.

This topic is a response to the growing number of kernels, growing number of boards with... "unique properties", and for the increased complexity of some platofrms (aarch64 and the atf, etc). I think the coherency of the chosen organizational method is starting to fall apart. So just a thought experiment on my part: Currently, we have a sources directory, and the sources file has not just sources, but also executable script functions in it. We also do our patches per SoC, mostly, but the organization is by the thing being compiled rather than by the target, making finding/adjusting a bit cumbersome in some cases. I would propose a directory tree looking something like this: ├── RK3288 │ ├── kernel │ │ ├── default │ │ ├── dev │ │ └── next │ ├── miqi │ ├── tinkerboard │ │ ├── kernel │ │ │ ├── default │ │ │ ├── dev │ │ │ └── next │ │ └── uboot │ │ ├── default │ │ ├── dev │ │ └── next │ └── uboot │ ├── default │ ├── dev │ └── next └── S905 In this case the organization is by SoC, then by board. All patches safe for the entire board population get put in the SoC-level kernel and uboot patch folders, anything unsafe (hardkernel-specific patches, Tinker board specific patches) go into the board-level folders. To reinforce that we want those folder to be "last resort", we could call them "C2_bugs, Tinker_bugs" etc. For our 64-bit targets, the trusted firmware would likewise have it's directory. I think it might also make for a lower barrier to entry on committing fixes, I still worry about patching things when I don't have all the boards to test on, this way, as a novice or as someone doing something that I can't test on other hardware, I can drop the patch into the board(s) I have, then they can be evaluated by the other devs on the remainder of the hardware. My particular set of boards benefit this way: Tinker board specific patches are many, integrating them safely is one of the biggest reasons we lag the vendor kernel, changes to the architecture files, changes to rk3288.dtsi instead of just to rk3288-minarm.dts, changes to various drivers for specific hardware issues, etc etc etc etc. Differences in gxbb vs gxl Meson64 devices. Most of these coexist peacefully, but then you have vendor issues with u-boot of the C2, K2, etc (everyone has their own bootloader blobs) I'd say we organize bootloader scripts similarly, rather than having executable scripts in the sources file we could place an include in the appropriate board folder covering the specifics. For example, if a board ships with a SPI boot flash, we don't need to burn u-boot, only provide the proper configuration of partitions/etc. That might be the only board in the series (an unusually awesome H3 board, for example). Ideally, at that point, adding a new board would require a new board definition file, and then the proper patches folder.

Yes, if you look at their history, they manufactured the Mini2440 until the SoC got EOL'd (so 2009 - 2016 or so I think). I'm glad to see the same being applied to the NanoPi series.

Yeah, it's there on the current ones I have on hand, it's just hidden by the barrel jack. I started with https://github.com/xesscorp/RPi_Hat_Template to get the board shape, Now that I (think) I've learned how to import layers into Kicad (like board outlines) I'll be making my own, it's easier to draw in an external application if you want precise dimensions/etc.

A look at some different use-cases is nice, as you can probably tell most of the discussion here is either extrmeely low-level or is for NAS/server capabilities.

Why yes, yes it does. And words on silkscreen are free. ;-) TBH, unless the reverse voltage were high enough to cause breakdown in the FET it doesn't matter anyway, the wrong polarity simply won't work. there will be some losses across the FET and various contacts, so there should be no trouble, I doubt you'll ever see more than 5.25 at the PMIC/LDO/etc. Yes, there was some playing with pad shapes to get through there "safely", but both 5V pins are solidly attached. I improved that area a bit further, but honestly that isn't where the drop was occurring anyway. Would you like me to prepare a boundary diagram and DFMEA?