TonyMac32

@TonyMac32  Did I remember correctly that you have a MIQI Board (rk3288) ?

For Retro-reasons:
I did buy a old Acme Systems FOX G20 (because it was cheap (10EUR) -
normally I would like own a Acme Systems Arietta G25 because of the formfactor / pinout).
The Fox has only 400Mhz and 64MB of Ram (Arietta has 128 or 256MB but same CPU-Speed)
but could boot a wheezy (Sorry no armbian) in 9MB
I do find it very cool this very low memory useage - while running the SSH/FTP-Server.
 
Also I like the company name  
Reminds me at the companys allways could be seen in Cartoon series
(ACME Co. = https://en.wikipedia.org/wiki/Acme_Corporation )

The original image on the companys webpage was "infected" with emdebian wheezy-grip which is long EOL
So I had to multistrap a new rootfs from the pure debian archive wheezy and transplant the modules/firmware to the newer rootfs (kernel is the same).

Was something nice to learn here while staying home

I don't see any reason not to, the patchset is a lot of backported stuff anyway.

I have a cranky Asus board here that kernel panics on boot with our 4.4 (sounds familiar), I might scab the device tree into something mainline likes and skip legacy for the moment.
@Lanefu, we need to make sure the big patch isn't "undoing" any of the other patches, I got most of it cleaned up, but not all.

Sent from my Pixel using Tapatalk

I don't see any reason not to, the patchset is a lot of backported stuff anyway.

I have a cranky Asus board here that kernel panics on boot with our 4.4 (sounds familiar), I might scab the device tree into something mainline likes and skip legacy for the moment.
@Lanefu, we need to make sure the big patch isn't "undoing" any of the other patches, I got most of it cleaned up, but not all.

Sent from my Pixel using Tapatalk

:-/
 
I'll take a look around, and maybe we should ping @Neil Armstrong just to see, they don't have a C2 in their test lab, but perhaps he has an idea.

No
 
If  have test sample, it will take 2-3 hours to release the finished image (this is taking into account the complete build and testing / debugging of the launch).

@Marko Buršič
 
 
 

I will have to take a look, there shouldn't be any reason it wouldn't run.

Sent from my Pixel using Tapatalk

In case you wonder where you get views:
 

@Tommy21 perhaps a snippet of the errors?  :-)

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.  🙂

I've just upgraded and cpufreq-info now reports:
 
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 132 us.
  hardware limits: 126 MHz - 1.80 GHz
...
 
Thanks @TonyMac32 !

Well, I don't want to point out something that went wrong, but on the contrary I want to emphasize all the things that went well. Having been disconnected from Armbian for some months, I can see a major improvement in the project's organization. Things like a predictable release cycle, tagged repo with all the releases, scheduling and coordinating, bug tracking... I can see a lot of work has been put into it, and IMO the results are excellent. 
 
So a big congrats to everyone who took part on it! Great job! 

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
 

O RLY? Very nice.

Sent from my Pixel using Tapatalk

@TonyMac32 @Tido @fourtyseven I've updated userspaceio to build libgpiod master branch. It requires >= 5.5.0 kernel which I install using armbian-config. Now you will be on the bleeding edge of libgpiod.

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)

With the correct DTB, the sound works in the official images for rk3328 (I tried the official images for Renegade and Rock64). All it took was adding the correct DTB (with audio support). If use a DTB from roc-cc, there is no sound.
 
You can see how the sound was added to DTS here.
 
https://github.com/150balbes/Amlogic_s905-kernel/blob/5.4/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
 
https://github.com/150balbes/Amlogic_s905-kernel/blob/5.5/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts

I do have one of those gun like ones, thanks for reminding me. I checked some temps and the reported temps are pretty much spot on. It might run cooler without the 1.3ghz overlay cuz I think that increases the voltage, not sure though. Of course I can't measure the chip itself due to the heatsink but I did my best to get a close as possible and find the hottest parts. I do have a temp sensor for a multimeter somewhere that is probably small enough to sit between the heatsink and the dye of the chip but it will reduce the surface so might influence results a bit.
 
Edit: ran sbc-bench without errors: http://ix.io/28pz

I pushed a template for the NanoPi NEO (2/Air/Core/Plus2) onto my github:
 
https://github.com/Tonymac32/kicad-templates
 
If you want to make add-ons, that's fully labelled and the header positions are as correct as I could get them without official reference.  I have made a few boards with it, so can vouch that it will assemble.  I'll add more as I have time and money to do so, since I don't want to push any that aren't verified in some manner.

@TonyMac32 @Tido I've gone through all the demo code and everything is working with the updated libraries. non-root access works with everything except PWM which has been a bear to figure out. Also added system LED library which includes triggers. I still need to work on some demos for LED triggers. 

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

I knew I would get the right people into this conversation.

I think with the next LTS mainline kernel this will be possible. Right now there are still a few odds and ends, RK3399 is not as well supported as RK3288, for example. It's far better off than RK3328 though. We have some fragmentation of the RK3399 boards due to bootloader difficulties with RAM, Rockchip has been extraordinarily slow to improve LPDDR4 support

Sent from my Pixel using Tapatalk