TonyMac32

I'm using a chassis supply set to 5.25 with a Fluke and monitored, measured 19 C ambient. Which Amlogic release did that BL30 come from? Since we're using blobs, mine hasn't been updated in some time.

From the Facebook users group, a general hardware note, when using expansion boards with Le Potato, be certain to use nylon standoffs. One of the A/V connector pads is encroaching on the space for the mounting hole, creating a potential risk of a short if using metal ones, depending on the expansion board (By spec they should have a large keep-out zone as well, but it can't be assumed).

I agree in the context of any single board, or even any single vendor. I think something like this would require all of the vendors using these SoC's to approach this together. Probably not the most feasible approach, but given the increasing activity on the open source front on their part, it may at least be possible to get correct readouts on future devices. (Assuming they want to save face and not admit fault by correcting the existing codebase) I'd be curious to see what the AXG is reporting vs actually doing... Given the work BayLibre is putting into mainlining has a lot to do with clocks at the moment, is there any means of indirectly determining the clock frequency so the kernel can at least report properly, if not command? I'm currently running it on a production board and red heat sink. I can try it as well on the older board with my heat sink which is easily 2x the mass. I did as prescribed by @tkaiser, I am currently running the performance governor. I have to admit I find it hard to believe it would be throttling that quickly, but testing is better than conjecture any day.... Hold please. *a few minutes later* Well then: Maximum prime number checked in CPU test: 20000 Test execution summary: total time: 6.4887s total number of events: 10000 total time taken by event execution: 25.9452 per-request statistics: min: 2.58ms avg: 2.59ms max: 10.43ms approx. 95 percentile: 2.60ms Threads fairness: events (avg/stddev): 2500.0000/2.12 execution time (avg/stddev): 6.4863/0.00 Hmmm, mere seconds later and I'm getting again. Massively over-protective thermal throttling?

Indeed. I've seen a few reports of bad behavior on mainline kernels now with Tinker, I'll poke around and see if there's any explanation for it from the kernel side.

Afraid not, in fact even if it physically fit, and electrically worked, it's possible it could have the wrong partition layout, which cannot be changed. Remember these are intended to be soldered directly to the application, the socketing is just a nice SBC thing for the most part

Agreed. Indeterminate behavior counts as an issue, since it could, in as yet unknown circumstances, result in undefined behavior, or at least unexpected.

Right. There won't be much hacking involved, I could replace the "add tritium H3" patches and support all 3 fairly easily, they share the entire device tree, only difference board to board is the board/SoC compatible, and at the latest I think 4.18 will support them without patches. Other than the unexpected appearance of unknown hardware bugs, these boards are quite literally the SoC, the PMIC, the RAM, and the various plugs. The support question comes down to dealing with the typical micro-USB issues, and probably folks who don't know which board they have since they are all exactly the same looking...

To my knowledge that u-boot is incapable of booting from USB media. Until I switch to mainline that won't change.

Fair. If I have a bit of time I'll look at the driver and see two things: 1) can it be compiled as a module and 2) can I use the device tree to load it so it isn't a problem for the MiQi. I need to get on the device tree overlays work, that's the only way most of this stuff will ever be properly done, like those lame 2-lane cameras. Sent from my Pixel using Tapatalk

For network adapter, no, I've not done anything to affect that.I can't speak to the management thereof, however.

If anyone has put considerable time into testing this let me know. Otherwise it has to stay in the develoen branch for a while longer

Did you buy the eMMC with the Le Potato? I have no idea if it is compatible with other vendor parts, I don't think there's any expectation that it would be.

With taskset -c 0-4: Maximum prime number checked in CPU test: 20000 Test execution summary: total time: 6.5926s total number of events: 10000 total time taken by event execution: 26.3611 per-request statistics: min: 2.58ms avg: 2.64ms max: 13.11ms approx. 95 percentile: 2.63ms Threads fairness: events (avg/stddev): 2500.0000/62.95 execution time (avg/stddev): 6.5903/0.00

Maximum prime number checked in CPU test: 20000 Test execution summary: total time: 8.8837s total number of events: 10000 total time taken by event execution: 35.5098 per-request statistics: min: 2.58ms avg: 3.55ms max: 26.71ms approx. 95 percentile: 6.63ms Threads fairness: events (avg/stddev): 2500.0000/53.08 execution time (avg/stddev): 8.8774/0.00 Running it a second time yielded: Maximum prime number checked in CPU test: 20000 Test execution summary: total time: 6.9951s total number of events: 10000 total time taken by event execution: 27.9649 per-request statistics: min: 2.58ms avg: 2.80ms max: 38.21ms approx. 95 percentile: 2.67ms Threads fairness: events (avg/stddev): 2500.0000/97.83 execution time (avg/stddev): 6.9912/0.00

http://ix.io/18Fb From an H3 and H2+ Tritium board, H3 first, H2+ last building against the WIP board definition. Needs some work (stuck at 912 MHz, a couple other odds and ends) but not bad. I'll play with the DT overlays on these as well, I have some hardware laying about that should work for testing. I have an H5, need to figure out where to start with it.

If that code depends on the memory mapped IO driver, that is still in the development branch.

Everyone seems to have a scope but me... :-( I have a bad feeling I know what this is, stay tuned. I probably need to reapply a patch to the device tree after the kernel shuffle. gxbb based boards are also affected by that memory allocation bug that was fixed for gxl, I should work on getting mainline u-boot implemented ASAP.

This looks like the same one I have (and sent 3 others to friend/family), mine seemed to fit a bit better than that, the case gets warm to the touch and the SoC stays cool. I think the thin thermal pad should do the job.

I saw that in the FB group this morning, I'll take a look.

Interesting. I'd say you could use them as HMI screens for *some random monitoring thingy* Also, have you looked at @Larry Bank's GPIO library? I think he has a means to write to those screens rather quickly.

What specific model? It may be that we can include its driver in the Armbian kernel. Then with an adjustment to the device tree you could use it directly as a system device instead of running a userspace driver (I assume that's how it's working now)

OK, development branch will reflect the change, on existing installations you will have to manually add console=ttyS3,115200n8 to the armbianEnv.txt file in /boot. I did a tiny bit of house cleaning as well, putting the Tinker u-boot patches into a board-specific directory so they don't impact the MiQi.

I will be testing this change tonight or tomorrow, it was put on hold because it presented problems for the MiQi, but I since learned I can make per-board U-boot patches. I will update here on completion.

It was said only in relation to

Very nice. They dropped the 5V barrel jack though I see...