TonyMac32

What is the name of the terminal when you start up? ttyS0? @Rfreire same time posting haha

@Myy I wonder if this might be able to be adapted for Tinker mainline bluetooth? So much time so little to do!... Strike that, reverse it.

Well, remember that bandwidth and frequency are different, probably some Wikipedia time would help, it's a bit too much to get into here. Also, for all that serial work, you can use a $20 logic analyzer (has evil PC software though) look up "24 MHz logic analyzer" and "sigrok"

Oh dear, well, I'd have pointed you toward a PicoScope, but you're cranky. This will sound terrible, but I've never spent any real amount of time with a bench scope under 100 MHz bandwidth, and only have experience with Techtronix, LeCroy, and HP/Agilent/Keysight (<--- might be a new name by the time you read this) Do you truly need 4 channels? https://www.amazon.com/Rigol-DS1102E-Digital-Oscilloscopes-Bandwidth/dp/B0039N9ZBA I didn't see an external trigger on the other one, something I use a good bit.

Well, that depends which kernel you are using. "Default" kernel 4.4 was moved to the Rockchip repository, which provided a huge number of bugfixes/adjustments/new drivers. 4.14 has simply seen the typical maintenance patching.

I haven't tried the separate I2S pins, but the patchset we are using includes HDMI audio/etc. I have a 5102A board lying around to look at it later (too nice a day to be inside right now)

I don't know if Microcenter is in Canada, but http://www.microcenter.com/product/475761/tinker_board_2gb

It is inherently just a cortex binary, it could be "disassembled" by someone with enough arm assembly knowledge. The question becomes how the cortex core is actually tied into the SoC, and how you handle the whole operation legally.

Let me check later, we had a windstorm and I'm running on generator power. :-/

I had to manually switch back to Armbian theme as well, Android 8/ Chrome

Correct. A bit strange. There is a dw-hdmi patch that needs a fixup, but I tried to to no effect. @Igor my support patches for this board do the opposite of the OPi PC2 image I tried, I get debug console with uboot on mine, but no kernel hdmi, the opi image made today has no uboot hdmi but does have kernel. I'm sure I'm doing something ridiculous... Any argument about uploading as CSC even though it's headless? it's only a csc, uboot and kernel patch to add the dts's?

Hmmm, having a strange situation where, even using the appropriate device tree entries, HDMI fails on any images I make using the appropriate upstream device tree sources... https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/sunxi-libretech-all-h3-cc.dtsi?h=next-20180503&id=b8f4f1180726d53778771ebf8421bea13a63fc9b This is a shared dtsi that each of the three boards includes, only defining the compatible string and board name, and including the correct proccessor dtsi. This works on 4.17, but for some reason, despite looking correct for our patched 4.14 doesn't seem to do the job... It's worth noting the 2017.11 u-boot has no problem with this structure either. [edit] Forgot: http://ix.io/19mU ### Loaded modules: Module Size Used by zram 28672 4 ir_lirc_codec 16384 0 lirc_dev 20480 1 ir_lirc_codec sun4i_codec 49152 3 sun8i_codec_analog 28672 1 snd_soc_core 155648 2 sun4i_codec,sun8i_codec_analog snd_pcm_dmaengine 16384 1 snd_soc_core sunxi_cir 16384 0 snd_pcm 106496 2 snd_pcm_dmaengine,snd_soc_core snd_timer 32768 1 snd_pcm sun4i_gpadc_iio 16384 0 iio_hwmon 16384 0 sunxi 20480 0 musb_hdrc 98304 1 sunxi industrialio 65536 2 iio_hwmon,sun4i_gpadc_iio sun8i_dw_hdmi 16384 0 sun4i_tcon 28672 1 sun8i_dw_hdmi dw_hdmi 28672 1 sun8i_dw_hdmi cec 53248 1 dw_hdmi rc_core 32768 5 ir_lirc_codec,cec,lirc_dev,sunxi_cir sun4i_drm 16384 0 hmmm

The Pi has bottlenecks on RAM, storage access, and network, I'd look at that as the problem first. Also, your name just makes me think

I use a smaller one from Amazon, 50mm x 25mm x 10mm, but they are unavailable now...Worst case you need to cut off a couple fins to clear passives that stick up too high... https://www.amazon.com/gp/product/B01HSBM5JM/ https://www.amazon.com/Easycargo-Anodized-Aluminium-50x25x10mm-50mmx25mmx10mm/dp/B07CQJMD6P/

There should be no difference other than the RAM capacity.

I build small test boxes for my company's products, sometimes for the end customer for field debugging. Visibility in sunlight is important, and the newer devices have complex enough output that graphical representation is handy to have. For the customer/field tech ones I try to keep the cost minimal, as they get destroyed a lot or handed out for free. I usually use Cypress PSoC controllers for the testers, but that's becoming less practical as well, so a move to a NanoPi duo or core may be in the future. (10 years ago the "debugger" only had to be a battery and LED... [emoji38] Sent from my Pixel using Tapatalk

To be fair I think a capped blob is acceptable to everyone, as long as it is answering to the kernel and is accurately reporting it's behavior.

Powerbanks generally use high frequency boost/buck converters to provide their "5V". These are not always very good at dynamic power situations (causing dips and surges), and can provide very noisy power in general. Perhaps I'll be able to afford an inexpensive oscilloscope for some educational material soon, I can't make any excuses for monitoring power banks at work...

Aliexpress? I have uses for these at that price...

This is a consequence of the PCIe interface, I see it as a happy side effect, perhaps the boards will all be adequately powered. I had a brief conversation about this at some point, the rk3399 having only 2 fast and 4 slow cores means it may not pull much more pwer than say a Tinker Board or MiQi with 4 fast cores.

For the stripped down image, I made a fork and was starting to play around with RT patches and cutting out the bigger apps that may be overkill for an HMI sort of environment. So far I like the functionality of Notion, but I would love some feedback on anyone else's experience with tiling managers. Sent from my Pixel using Tapatalk

https://github.com/armbian/build/blob/development/config/kernel/linux-rockchip-default.config It's enabled as a module in default.

Well, you could consider it "enforced granularity". ;-)

I agree KISS is best, but we might have to give up some for user stability. The development branch demonstrated the stumbing blocks almost immediately, in not being granular enough. It makes maintaining the history of changes better to add a little granularity. If similar problems happen in a family-specific fork or branch, it should be much easier to sort out, and can be done by the primary contributor to that branch/fork, and they can ask for a review of the merge if they have any concerns (IE, bootscript stuff, new/old/removed blobs, etc). It would add some extra work for upstream patches and the addition of drivers across all platforms (like wireless), but truthfully that could probably be implemented in a build-script-maintenance branch and then merged upstream, where everyone else can pull it down and see how their WIP reacts. For forks vs branches, I think the result is the same, but if the working branch variable can be modified on the command line instead of only in the script that may be easier on the user of the script, rather than cloning a different repo if they want to do a PR they just need to go to the proper branch.

Should we start branches per SoC/Family as briefly discussed earlier? It would reduce the insanity perhaps, by adding another (more easily sorted) insanity.