TonyMac32

Given the simplicity of it, a ton of holes aren't really a problem. This rearrangement of the "Lite" version puts a USB power where needed in case you have any "Y" adapter situations, leaves one in the original position to power either the touchscreen, provide power to the sbc the traditional way (probably not the greatest idea), or something completely unrelated (I powered a Tinker Board off of the USB on the power board while powering "Le Potato"). Thicker traces for power and an improved area around the header pins to reduce the drop there as well. @JMCC's slots for cooling, we'll see if the fab gets mad about that. ;-)

Just because you hooked 12 V into Chuck and your credit card computer didn't survive doesn't make it Chuck's fault. Chuck is a member of the Church of Darwin.

@Igor We had reduced the speed to 150 MHz from 200 MHz, but apparently in 4.13 and older kernels, it was actually running at 1/2 the requested speed, so 75 MHz (If I'm reading the thread properly). I'm matching the upstream at 100 MHz to start. As for SD I'm just going to drop the clock from 100 MHz to 50 MHz, looking at the vendor kernel they have 85MHz as max, but as noted they still seem sensitive. Since @alain can't boot properly to install a new dtb package I'm just building a server image to see if it will work. If it does, hooray and push the bugfix, if it doesn't, well then we have a mystery. So TL;DR: eMMC: down to 100 MHz to match upstream 4.17 WIP SD: down to 50 MHz to try to avoid all the issues. http://electricgraveyard.com/armbian/C2/Armbian_5.42_Odroidc2_Ubuntu_xenial_next_4.14.32.zip Again, I can't test it, but please try it from eMMC and from SD

I'm going to take another shot at it, there's no good reason for it not to work if the Rockchip guys have done it, it's just that the kernel config documentation is not always so good. (Like for the Wifi, I had to find out what I was doing wrong by looking at the commit history)

And that is the one that seems problematic. Ok, really this should just be as easy as changing the device tree, so I should have a link for a command line image in a few hours (just getting home, food an whatnot)

I could just build a server image for OP to see if that helps, since it seems likely that OP has one of the sensitive boards. If it fixes the issue, then ok, but if not, then I'd rather not handicap the boards needlessly. @alain which eMMC do you have? Sent from my Pixel using Tapatalk

https://patchwork.kernel.org/patch/10254657/ https://patchwork.kernel.org/patch/10000643/ It would seem (and the symptoms agree with the conclusion) this is a board layout problem. I don't have a board to test this on, however, @Igor I think we should reduce the max frequencies on both the SD and the eMMC, that SD sensitivity has to be a similar issue, the drivers aren't any different for other boards that don't have the problem as far as I know.

The "scorched Earth" solution might be to disable all HS modes, making your SD card slow as... Well, an RPi. The Odroid is also very sensitive to eMMC timing, I'll have to check if the phase timing issue was in 4.14 or not, again, the solution was to significantly limit transfer speeds.

At present we don't have the isp1 driver working, so neither RPi camera is functional. I have both cameras, but have not gotten the DT/kconfig right to make it work. There is also the issue that both cameras use the same resources, so they can't both be defined in the DT without overlays.

I'll see about updating the master branch, since it's failing the build.

Oui, check the development branch. ;-)

Amlogic meson64 kernels have been rearranged, default is 4.14.y, Next is 4.16.y, dev remains mainline/master. Anyone with boards, please test. 4.14 default is lowest risk, 4.16 is brand new and a new patchset from @Neil Armstrong, and new kernel config, etc etc etc.

My understanding is that this has been rectified, I found that to be true on my early sample and reached out, the concern obvious. So, production boards should be fine. I thought of this, I could put that in here. As far as a grilled circle goes, well, the slats will make noise depending on the fan orientation and proximity, but perhaps that's a secondary concern in this case. Probably a slotted rectangle to account for the maximum number of cpu positions, and increase airflow in any event.

...maybe with a stick man on fire?

I was thinking "Maximum input 5.3 VDC" and a center positive image, and probably "Do not exceed 4.5 Amps"

Thank you Neil, I have them in the development branch, testing out the basic stuff. I also updated the 4.14 patchset to reflect your latest changes, tested out the new video modes on a couple monitors, no problems. @Tido will be pleased, as long as his monitors support - 640x480@60Hz - 800x600@60Hz - 1024x768@60Hz - 1152x864@75Hz - 1280x1024@60Hz - 1600x1200@60Hz - 1920x1080@60Hz

I monitored at the barrel jack, at the output of the FET, at the GPIO pins, and at the USB out on the board in the various load conditions. No, the Dupont connectors go to the RPi touchscreen. Yes, I was able to verify the drop was on the trace. The terrifying reality is, even with a crappy header, you have about 4x the contact area as a microUSB. Now, were this the 1950's I'd just say to mercury wet the pins for luck. It's a shame all the best functioning things are also toxic... As far as the spartan nature of the board, the goal was to be simple and effective. What always happens (at least to me), is if I don't draw a line in the sand and call it done, then it will never be done. An example, I could use a hall-based sensor to have a much better SNR and an effectively non-existent loss. So, as far as features go, this is the first version, like I said I've moved a few things around and am "beautifying" it, labels/messages/warnings in the silkscreen, etc.

I've done some load testing of my first prototype power "mezzanine" board (can't say "hat") The voltage drop of powering the RPi touchscreen off of the GPIO while the tinker is on micro-USB is insane, I was reading 3.9 Volts on the USB ports when I ran minerd --benchmark. I may have finally worn out the Micro-USB connector... This is a project for learning the ins and outs of kicad and get an idea of the capabilities of the PCB houses I have reasonably fast access to (Chinese ones unfortunately always get stuck in customs for a week or more on top of the normal shipping and fab times, so the cost savings is lost in time) I have some more interesting things in mind, but I thought I'd start out (very) small. The input is protected by the recommended ideal diode circuit from the RPi guys, stress testing didn't even make it warm. If a better solution is needed, it can obviously be designed, but this is extremely cheap all things considered and that was part of the G&O for this project. By comparison, using this GPIO board to power everything resulted in a minimum 4.8 volts while also powering a USB 2.0 spinning disk HDD. (lower than I'd hoped, I'm going to make some adjustments to see if I can squeeze a bit more out once I get the redesigned version 2 back, I forgot about the temperature rise factor... ) One of the issues goes back to our friends at RPi, the 5V pins are on the outside edge, so you have to go around the inner row to get to them. This complicates moving big conductors around somewhat... The chip in the back is a SPI NOR for booting the Tinker (experimental, I threw it in there as an experiment and never actually performed the experiment...) I'll probably wipe it from the board, perhaps leave an 8-pin SMT-adapter-sized pattern to the SPI for the adventurous. Power supply used here is the Odroid XU4 supply. This initial run has no overvoltage or overcurrent protection. And I need finer tipped soldering iron... I'll GitHub this one after some cleaning and citation of sources, normal disclaimers for those who want to build one. I will have moved one of the USB ports though since @chwe happily pointed out that Y-cables don't reach that far to get from the real ports to the power-only ones... (oops) Boards successfully powered by this configuration (I don't / can't own one of everything... ): Tinker Board Le Potato NanoPi K2 (Already has a barrel jack, by the way, but you never know, maybe you want the bigger one)

Ah ok, Stuff LIB_TAG="development" into the config-default.conf file to use the active dev branch.

Let me take a look-see. Are you use the development branch?

I'd review the SD cards again, if you look under common issues you'll find the token error is an overwhelming sign of a bad flash of the SD card.

It looks like they may be avoiding the exposed 8-bit TS interface they have on the board. I saw a driver for it hit the Rockchip kernel, not sure if any hardware exists to make use of such a thing. I'll do a quick test on relocating the uart, but I can't promise this will be a simple update for existing users, they may need to modify scripts manually.

Linux 3.14.79-odroidc2 (odroidc2) 04/02/2018 _aarch64_ (4 CPU) OK, so you're using a default image, which seems, according to google, to be problematic with a great many USB DAC's. Nothing too crazy in there, a lot of noise about the HDMI audio system settings, but I'm not so familiar with this kernel. If you are willing to go through the work, could you configure an SD using an armbian-next image? (4.14 LTS kernel) I'm afraid I can't buy one of these DACs for testing... unless you want to donate one... Assuming this SBC is being used as nothing more than a Roon endpoint, a Stretch Server image may be best. https://dl.armbian.com/odroidc2/Debian_stretch_next_nightly.7z That will give you command line only with no extra muss, assuming you can install/configure everything from there.

well, I'll give it another go, at the moment I'm disposing of some RPi hardware by making a jukebox for my 5 year old.