Werner

Hello cyph84,
 
    Yes, this was working in the past, I can take a look.
 

Thanks Igor, I've created a pull request (https://github.com/armbian/build/pull/3967) after some tweaks & tests with non-rsync ramlog.

Hello Everyone!
 
Just wanted to check back and say that so far the first two community voice chats have been a lot of fun with more people showing than we originally expected!
 
I know that the currently set time is a bit more difficult for our European friends to make, though it has been difficult to come up with a time that would be better that would fit everyone.
 
The current time corresponds with the end of business day in the Eastern timezone where, so far, the bulk of our participants have been from.  It may be possible to make it an hour earlier or so, but would be interested to hear from the community on if you guys think there would be a better time in general?
 
We will continue with the Friday 5:00 PM Eastern time this week, but if we can come to an agreement on a better time before next week, we can move it to the new time.
 
Look forward to seeing you all there!
 
Cheers!
 
 
 
 

PR make
 
https://github.com/armbian/build/pull/3964

Good start if you have the time and use case.
 
 
You will have to think outside the 'book' its examples are different soc.
 
Whats your use case? Is it fun or fairly serious project.
 
If it a project that you have time to put into, then effort might be justifiable, should you make some progress contribute back to the community. Otherwise keep hoping that someone else will make the effort and part with that back to community.
 
Best of luck.

In general I think this is a good move.
Specifically I'm assuming your proposal is to replace the TV boxes link under "Unmaintained (CSC/EOL/TVB) / Other" with the content from the TV Boxes Club.
 
 

Jammy boots up fine: http://ix.io/41zg
apt upgrade & reboot was fine too
Armbian_22.05.3_Nanopi-r4s_jammy_current_5.15.48.img.xz
 
Bullseye boots up fine: http://ix.io/41zi
apt upgrade & reboot was fine too
Armbian_22.05.3_Nanopi-r4s_bullseye_current_5.15.48.img.xz
 
 
Tests performed with 32GB Sandisk Extreme V30 U3 A1
Images written and verified with USBimager 1.0.8

Post count and location display have been removed from topic view. Irrelevant information that can be checked in user profile if somebody cares .
 

Good news!
 
The updated operating points for the RK3308B-S do work.
sysbench confirms a 10% speed improvement.
But, more importantly, idle power consumption is almost halved!!!!
[from 0.39W measured previously to about 0.20W when running the CPUs at 0.85V as opposed to 0.95V]
I need to run this overnight to confirm.
 
I'll look into the other B-S silicon device tree updates soon.
 
Does anyone have ideas on how best to package this?
 
I've read the docs here:
https://docs.armbian.com/User-Guide_Allwinner_overlays/
 
but they refer to Allwinner for 64-bit arm and some of the example dirs seem to be missing.
 
Are device tree overlays supported for Rockchip?
Can anyone point to an example of their use?
 
Do we end up with a magic rk3308bs.dtbo file that one moves into an overlay to optimize performance?
 
Is there a better approach?
Does the older (B) silicon even boot with these updated (BS) operating points?
 
Attached is the latest version of the rk-3308-rock-pi-s.dtb optimized for the BS chips.
rk3308-rock-pi-s.dtb

So far no luck.  We do have a redundant patch adding the nodes, but that isn't the culprit.  The driver complains it doesn't have the host-drv pin defined, but it's shared with the USB2 (same situation between Renegade and Rock64)
 
EDIT:  A PHY driver was added back in the dark days before USB3 support by the kernel.  It is only used by the Rock64 and Renegade, (and apparently also the RK3328 Station M-whatever).  I've removed the entries and USB3 is working again now that mainline supports it without said special case driver.  I will open a PR tonight with the fixes.

@Igor might know

Hey Everyone!
 
Last week we tried out doing a community Discord get together on Friday night and it went really well!  We are going to try and do the same thing again this week on July 1st, 2022 at 5:00 PM EST.
 
Everyone is invited, just come to the Armbian Discord (You can click our invite link: here if you are not already part of our Discord) and on Friday evening at 5:00 PM EST we will open up the public voice chat for all who would like to participate.
 
The meet-up will last 1 hour and there are no official topics set for the conversation, of course, if you have something fun to share that is always welcome!
 
Hope to see you there!
 
Cheers!
 
 

If you downloaded an Armbian image, did you do an integrity check?
https://docs.armbian.com/User-Guide_Getting-Started/#how-to-check-download-integrity
 
Did you verify the image when you flashed it to the SD?
https://docs.armbian.com/User-Guide_Basic-Troubleshooting/#writing-images-to-the-sd-card

sure thing.

sure thing.

Yes.
Unfortunately it is not that easy since it needs a bit of tinkering and probably try'n'error as well.
General building instructions for Armbian are here: https://docs.armbian.com/Developer-Guide_Build-Preparation/
 
ATM sources for sun50iw9 family (which H616 SoC is member of) are legacy (which comes directly from vendor, so old stuff) and mainline  (current 5.15.y and edge 5.18.y).
Since jernejsk's sources are 5.15 I'd suggest to go for "current" branch first try.
Armbian patchset which is applied against mainline sources for whole sunxi family you can find here: https://github.com/armbian/build/tree/master/patch/kernel/archive/sunxi-5.15
Try putting the mentioned patches there after cloning the repo and build it. May fail due to upstream adjustments, patch order, solar winds....  That is the point where tinkering and try'n'error is necessary. Unfortunately I have neither time to get into more detail nor to try that myself at the moment.

v21.08.2 (Linux 5.10) is the latest which works. U-boot seems irrelevant since only updating the kernel breaks it and updating/flashing U-boot doesn't solve it.
 
It works on NanoPi NEO3 (same SoC), which probably indicates an issue with the device tree, if the USB3 host is the same?

Same has happened on EspressoBin running Buster 5.10. I don‘t believe it to be a filesystem problem. It looks like something happening at boot time perhaps while running /usr/lib/armbian-hardware-optimization.sh ? I will try to go further into it.

Then either adjust one of the ip addresses to be in the same /24 subnet or adjust subnet mask on both to /16

Unlikely, unless the PC is ancient. Most interfaces these days have auto-MDI-X.

Are you perfectly sure that the SoC is not as hot as htop tells?
I have an OPi1 with the same kernel but Buster as userspace and temperature is normal.
 
Btw. it is Armbian, not Arabian
 

@Fra Armbian is streached thin.  Unless human or financial resources are provided (eg. A person willing to be a maintainer for this board and/or money to offset the increased costs) it is unlikely this will ever be supported. 
 
You really should be contacting the board manufacturer (i.e those who are making money from this board) and encourage them to work with / financially contribute to Armbian to provide a well supported os for their board.  Since Armbian doesn't make any money from the board, it is unfair to ask us to provide support for free while others who do make money from the board (the board manufacturer) just benefit without contributing..
 
 
 

This sounds quite confusing.
 
PHY is set to DHCP by default so it tries to aquire a lease by a DHCP server available in the network. If you don't have one you have to find another way to make the board connectable via copper. Like using UART serial console or build your own script using custom configuration.
Cannot say about using Pi as DHCP since I dont know your full network setup and therefore no idea if that would work. A dhcp server is usually also some kind a router to NAT data to a different network or WAN.

To prevent abusive behavior by editing older postings this is no longer possible after a certain period of time.
Exception is granted for contributors, maintainers and frequently active members of the community.

To prevent abusive behavior by editing older postings this is no longer possible after a certain period of time.
Exception is granted for contributors, maintainers and frequently active members of the community.