TonyMac32

Because the board is intended to work on any Pi-shaped board that can be powered via gpio, Like a Pi, Le Potato, etc. A lot of those don't pull as much as the ATB. Sent from my Pixel using Tapatalk

wow. I guess I'll give it a shot too? Could be a device tree problem?

On March 6th a big update to the rock64 DTS happened on the default kernel upstream. It included hooking to the SoC codec, so we should have that feature available soon, I haven't personally tested it yet.

*RK3288. It's a 32-bit quad core, the RK3328 is a 64-bit quad core, absolutely incompatible bootloaders/images. I only bring it up so there's no confusion for anyone else reading.

I was about to mention that, I saw quite a few performance and bugfix tweaks go through on nand-sata-install. One involved unbinding the screen progress update from the data transfer, and resulted in a huge performance gain.

So, let me ask some questions to make sure I have the full picture, and unpack some of this: Have you tried booting the device with only 1 device plugged into the Rock64, in the usb2 port that is giving you trouble? Is the USB3 drive you are using self-powered or powering from the USB port itself, and what are it's power requirements? Some background: One of the USB 2 ports on these boards is a USB OTG with the device tree specifying it as a host. That used to be problematic before the "host" mode was explicitly stated. That said, I don't think that's the issue here, although I'll double check a new image if I get time. The other issue is basic single board computer reality, which is always a tough pill to swallow: The entire board only has available the amount of power a single USB 3.0 port is allowed to consume according to specification. I wish USB had some kind of split specification compliance so that you could show that your device is USB3 communication compliant but not USB 3.0 power compliant. It sounds like the USB power is falling below 4.75 volts and some of your devices are disconnecting due to under powering. If the drive has no provisions for power other than the USB port, then a powered hub or powering the board via GPIO (only for the experienced) is recommended. Even if the drive seems to work without other things plugged in, you will face data corruption if you're underpowering it.

What does it identify itself as on a system that recognizes it?

LED's are all encompassing. Sent from my Pixel using Tapatalk

I agree that u-boot is modern enough as it stands, but we should work to get all u-boot for rk3399 boards commonized instead of the double work double functionality double headache we have now Sent from my Pixel using Tapatalk

Honestly I think we should try to roll a u-boot that works for both, not just glue one into the other or vice versa. Same for kernel, we can keep the vendor kernels for 4.4, but Mai line should be vanilla with patches we track IMHO. Sent from my Pixel using Tapatalk

Do you have anything plugged into the hub when you boot the board? This may be related to the other issue concerning partial power-down.

Question, what is hardkernel's performance governor?

The exact module you have would be helpful if I had any module, but unfortunately I don't. Now, for both of you, please provide the output of armbianmonitor -u as is requested of all community members on submitting an issue. Then, perhaps, if we know anything at all about what kernel and hardware you have, we can see if anything obvious shows up within Armbian, or if perhaps @Neil Armstrong is aware of something/recognizes a potential issue in the drivers. It could be something simple like a speed being removed from the device tree due to instability with the mainline MMC driver, or something more complex such as an issue with tuning.

Right, I did it once before the new platform detection code was merged, I just didn't go through the effort of doing it again yet and submitting a PR since it doesn't seem sustainable for the number of boards we have, let alone the other targets. I am designing some hardware of my own however, and I want to take a closer look at this.

Driver differences I assume hard kernel is on vendor kernel, we use mainline, I don't have the hardware (eMMC) so I can't test. It's also important to note which eMMC, some have issues the others dont

I have Tritium h3 started in their system, it just needs the board ID bit done, but that's a bit of a hairball, not sure how to do it better since I'm a Python Noob.

https://github.com/armbian/build/blob/master/patch/kernel/rockchip-next/1008-rockchip-dwc2-usb-partial-power-down.patch Obviously applied to the Meson64 part of the code. Sent from my Pixel using Tapatalk

Well, let's avoid other distros and their management as far as discussion topics go. That's a bummer, and your patches are welcome here.

I use a USB uart daily Sent from my Pixel using Tapatalk

You can get 5" with the same hdmi and touch controller as the 7", I think also from Waveshare.

Lol we will have some work to do on new kernel anyway, making it dev. My goal is to wean us off of the special kernels so we can work on getting rk3399 integrated into a single family, what we're doing right now is insane.

ugh, some power sequence is not correct, or a supply marked "always on" that shouldn't be perhaps.

I'm getting the old bug where the hub powers down if nothing is attached. I thought I killed that one, but maybe in the switch it came back. Doesn't completely fit your issue but we'll see.

Yes, I've been watching those, going to try them out once they stabilize a bit, as you can see there's some back and forth going on on the mainline mailing list as well Sent from my Pixel using Tapatalk

Thanks for reporting this, my last test of Next worked just fine, I'll take a look.