TonyMac32

The OPPs are from mainline, perhaps someone knows of a place where alternatives are defined? Or, I have seen varying versions of down clocking CPU when up clocking GPU. Sent from my Pixel using Tapatalk

I will test again, my last round of testing had working USB. Not to say something didn't change, there was another time that an unexplainable loss of USB happened that fixed itself after some time and upstream patches that seemed unrelated. Sent from my Pixel using Tapatalk

I will have to take a look, there shouldn't be any reason it wouldn't run. Sent from my Pixel using Tapatalk

Have you flashed the latest bootloader into the spi flash? These are available from links in the campaign, a lot of changes were made early on. Sent from my Pixel using Tapatalk

Yes, I took care of it. Sent from my Pixel using Tapatalk

Echoing what Lanefu said, thanks for the info, and sorry about the rough edges! A new set of sound patches have been submitted upstream, I will take a look at them and see if they can be used as a means of cleaning up our current implementation (targeted originally for 4.19). The memory limit seems to be a potential u-boot issue. For the display, the Amlogic clock framework has been an ongoing project for mainline, with a lot of changes. I will spend some quality time with everyone's favorite S905X board and get back to you. 🙂

That is fascinating. Let me look over this stuff. https://github.com/ARM-software/u-boot/blob/master/common/image.c#L1076 I think it's unrelated to the packaging of U-boot, probably more the packaging of the kernel. Or I could be totally wrong, it's late

@Neil Armstrong looks like kernel troubles. I only see AXG and G12a changes in there, but I haven't dug in. Sent from my Pixel using Tapatalk

So somewhere between 5.4.13 and 5.4.20 things broke? Or is there some other workaround going on?

There was mention of La Frite as well from what I quickly read. I don't think this is U-boot related, personally. But I also haven't spent more than an hour on it.

Also note that Rock64 has a SPI flash that takes precedence over ALL other boot devices. My Rock64's have no contents in these flashes for exactly this reason, so I can faithfully test our U-boot's. I would have to ask the boilerplate "SD/power supply problems questions: Which Kernel (Current, Dev, Legacy) I know in this case it is a rev 2 Rock64 What SD card brand/version. My cards were immune to the voltage switching issues caused by the Codec pin mapping bug, so my testing of that correction may not be thorough enough to catch if there's still an issue The interaction of 3rd party U-boot configurations and Armbian really can't be tracked down meaningfully, so that SPI boot is something to look out for if it has been flashed. Our DT overlays/etc are all handled at boot by u-boot. (general info, not necessarily a specific issue here)

O RLY? Very nice. Sent from my Pixel using Tapatalk

building one now for test. :-) [edit] Good!

The fact that it won't boot without special power considerations is part of the reason it isn't building, until the mainline guys get their fusb302 driver working properly I'm afraid this one will be a csc/at your own risk target. I have done some work with it, but the power issues are pretty fundamental. On another note, @Igor my stack of Odroid MC1 Solos are refusing to boot the Buster 5.4 RC1, it gets to kernel (heartbeat), then faults out. I'm trying to find a 1.8V UART in my pile of stuff to do more debugging.

To be fair it takes maybe 5 minutes to figure this out for yourself. My last test booted successfully, I had to do some cleaning.