TonyMac32

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.

I would guess it is a power issue. For boards like this I designed myself a 3A power supply HAT that sends power directly to the GPIO. I haven't used it with the H64B however Sent from my Pixel using Tapatalk

Hi @Comedicles, Do you have some more info about the low light/etc? I don't see a lot of content at the FB link.

This looks very much like what I did, I'll have to dig a bit deeper since it didn't work for me. I applied the dtsi and dts patches as proposed for the sound pipeline on mainline, I'll just have to dig around and see what else is different. @balbes150 I forgot to enable i2s0 and 1... Works now, but PulseAudio isn't piping audio until I change outputs back and forth a few times... (Bionic)

I am going to assume you simply need to feed it an "audio stream" that would replicate what you want. That said I've never tried it.

I'm at my day job, so let me make sure I'm clear, I made the observation that it didn't work when I started cleaning up the mainline kernel switch. I never went back to mess with it, so it's entirely possible it just works with very minor adjustment, or even was fixed in the meantime. I'd entirely forgotten it. ;-) Sent from my Pixel using Tapatalk

I can do that, this topic was covering the current release, where we'll be using 5.4. For next release I agree to look at 5.5 specifically, especially as it is now released. Sent from my Pixel using Tapatalk

Renegade w/5.4, thank you for reminding me to look at that. Sent from my Pixel using Tapatalk

Do you have a thermometer to double-check the reported values? I remember these Allwinner parts have some very touchy temp sensors (voltage dependence, etc) Sent from my Pixel using Tapatalk

For RK3399 IIRC it should be possible to build u-boot without a blob, of course I haven't looked at the new Helios offering (DDR4 + Rockchip is a PITA) Sent from my Pixel using Tapatalk

I've been tied up on all the things I left unattended last year, getting close to being able to give this a proper attention again. Thanks for the add@chwe Sent from my Pixel using Tapatalk

I verified the 1.5 GHz operating point for rk3328, had forgotten where the max frequency variable was set. The default is 1.3 GHz max, can be set by the user to 1.5. we are missing a 1.4 GHz operating point though. Sent from my Pixel using Tapatalk

this is still happening? hmmmm. Let me see, since I'm crawling around in the renegade stuff

Bumping with update, then closing this thread as the original content is for 5.7 USB3 driver has been added to Kernel 5.4 images for RK3328 boards.

The media script is only functional with the rockchip 4.4 kernel. The upstream decoder support is incomplete, and incompatible with the Rockchip driver.