lanefu

https://zuckerbude.org/the-pinebook-pro/

Let's do it
 
P.S.: Not a big fan of ZSH so far. I installed it on my Ubuntu PC, and it all just looked like an unconfigured BASH, needing plenty of work to make it useful. I guess the Armbian version comes pre-configured, I'll give it a chance in some near future.

@ballerburg9005 I just wanted to add a few of my own thoughts to this thread.  Overall I can see both sides to the above discussion.  There are valid points made by everyone commenting.  While we all sometimes need to have 'grand visions' of the future we would like to work towards, we also have to deal with the reality of where we currently are.  I often think of a saying "crawl, walk, run".  While we all want to be running to the finish line of an Olympic race, we all start by crawling first.  As that relates to armbian and more specifically armbian on TV boxes, we are at the crawling stage.  There is a lot of work to be done to just get us walking.  That doesn't mean that crawling and walking in themselves aren't valid and productive stages (they are and you can use a lot of different TV boxes today to do a lot of productive stuff).
There is a lot of work to be done today to improve our crawling.  We need volunteers (like you) to pick up that work if we ever hope to get further along our path.  We need to build a community one volunteer at a time.  While visions are important, if we don't have people willing to do work today then we will never more forward.
If you hang around armbian for any extended period of time, you will learn that the single thing that most bothers the core maintainers of the project are people having grand visions or even small visions of what should be done but who don't contribute any time to help and expect others to do the work for them.
Whether intentional or not, that is how your post came across to Igor and Balbes and they reacted as they normally do to such posts.
If you want to run to the finish line with your vision, you need to start by crawling.  Spend time on these forums following the issues to build your knowledge.  Help support new users to allow others with the technical knowledge time to work on development and progress on our shared goals.  This all doesn't happen overnight.
I welcome your contributions to the efforts here, but starting off by getting into a disagreement with two of the core maintainers isn't likely the best way to have started.  Overtime you will realize we all share a lot of the same goals and can work together even through we have different personalities and sometimes have to overcome language/cultural differences.

From my wishlist:
Wake on Lan - yep, I know that Helios64 supports WOL, but practically it is still not working a properly wired 2.5 GB connector - yep, I know, but it is frustrating anyways, especially due to the warranty handling of kobol (send it back on your risk, wait 2 month, send a replacement back, wait another 2 month, hope it works) standard SATA connectors - my ZFS fails rather often due to checksum errors, this seems to be related to bad cables. With the shipped non-standard cables, this is however hard to solve. If the enclose / board had standard connectors, I could simply use one of the 1000 cables laying around here. more RAM - or support for standard ram modules and yes, the sliders for the disks need a redesign, too (color is cool, but they are rather "cheap" and you need a lot of power to push them in / pull them out)  

It looks like sufficient support for defaulting ZSH is not going to happen  But it will remain as a second choice ... lets repeat this question year later.

Speaking on armbian-config ... @tparys started to help on enhancements, I do what I can ... still more helping hand is needed. It's a long term job. Any idea how to get more movement there? Yes, its a wonderful tool, but require constant love. Like other parts of the project.

@ballerburg9005
 
I read what you write and once again I was convinced-you are a banal troll, who, hiding behind beautiful slogans, is trying to get support for the shit that you bought. You're trying to convince other users to buy this shit ($30 aml tv boxes), and then try to get support by relying on a lot of idits who will follow this advice and buy this shit. There is no point in proving anything to the troll, it is useless. I wouldn't be surprised if you turned out to be a banal peddler of this shit. If you are such a freedom fighter, here is a ready - made solution for your ideas about freedom-Station M1\P1. This is a completely finished product for the most "average Joe". It does not need to alter anything for normal cooling, you do not need to assemble it from different parts, you do not need to spend time on debugging software, etc.And most importantly, this equipment has guaranteed support, and for every taste - Android or Linux (Armbian Slarm Freebsd and bunch of different specialized distributions for different tasks, etc.). But you don't need it, you want to make others work for the shit that you like (profitable) .
 
 
P.S. About the inner kitchen of AML and the device, I know much more than you and my refusal to support them is based on real knowledge, but I'm not going to waste time explaining everything to you in detail and convincing you. The only advice I can give to anyone reading this is to absolutely avoid this shit.

Mostly because I was bored and for self-educational purpose I desigend a custom fan hat for the Nanopi R4S.
Planned to mill it from 2mm aluminum.
 
As reference I created a heavily simplified version of the board (4GB version) using the provided 2D drawing from Friendlyarm.
 
Fan: https://www.amazon.de/dp/B071JN6HKM?ref=ppx_pop_mob_ap_share
Heat sink: https://www.aliexpress.com/i/4000107291369.html
Bolts and nuts: Whatever fits... M2
 
 


Baugr1.mkv

I know this topic's already marked solved, however wanted to add something interesting that I found in my travels.
 
If for some reason a software software controlled read-only switch isn't sufficient, it is actually possible to make a MicroSD card read-only.
 
https://github.com/BertoldVdb/sdtool
 
I'll still echo that overlayroot is generally the way to go. But in some applications that may not be sufficient.
 
And the permlock function does work as advertised.

After checking, /var/log/armbian-hardware-monitor.log 
I detected btrfs did not exist in my build. I went back to lib/configuration.sh and saw btrfs-progs package was not installed if BUILD_MINIMAL = YES. 
 
if [[ "$BUILD_MINIMAL" != "yes"  ]]; then     # Essential packages     PACKAGE_LIST="$PACKAGE_LIST bridge-utils build-essential fbset \         iw wpasupplicant sudo linux-base crda \         wireless-regdb unattended-upgrades \         console-setup unicode-data initramfs-tools \         ca-certificates expect iptables automake html2text \         bison flex libwrap0-dev libssl-dev libnl-3-dev libnl-genl-3-dev keyboard-configuration"     # Non-essential packages     PACKAGE_LIST_ADDITIONAL="$PACKAGE_LIST_ADDITIONAL alsa-utils btrfs-progs dosfstools iotop stress screen \         ntfs-3g vim pciutils evtest pv libfuse2 libdigest-sha-perl \         libproc-processtable-perl aptitude dnsutils f3 haveged hdparm rfkill vlan bash-completion \         hostapd git ethtool unzip ifenslave libpam-systemd iperf3 \         software-properties-common libnss-myhostname f2fs-tools avahi-autoipd iputils-arping qrencode sunxi-tools" fi  
I changed then this from
 
PACKAGE_LIST="bc cpufrequtils device-tree-compiler fping fake-hwclock psmisc chrony parted dialog \         ncurses-term sysfsutils toilet figlet u-boot-tools usbutils openssh-server \         nocache debconf-utils python3-apt"  
to
 
PACKAGE_LIST="bc btrfs-progs cpufrequtils device-tree-compiler fping fake-hwclock psmisc chrony parted dialog \         ncurses-term sysfsutils toilet figlet u-boot-tools usbutils openssh-server \         nocache debconf-utils python3-apt"  
And now it works. I suppose btrfs-progs needs to be added to PACKAGE_LIST (or DEBOOTSTRAP_LIST?) only in the case ROOTFS_TYPE=btrfs and irrespectively of BUILD_MINIMAL.

This is a tricky shit that hides behind openness, but in fact tightly controls the main part-the loader. I.e., at any time, it can block or completely control any unwanted person's actions.
 
 
It's funny, you described a whole theory about freedom, and as a result it all came down to advertising and pushing aml shit. 
For your information, aml imposes its BSP shit on everyone, which is stuffed with Trojans and bookmarks to gain full control over those who use their shit. They lie to all users about their hardware and actively cooperate with those you are trying to protect yourself from.
 
In general, everything is as usual, if you remove the beautiful words about freedom, it all came down to the fact that "someone" would spend their time and money and provide the rest with free use of aml shit.
 

I think I tried that.
 
 
Or copy config if not exists:
 
[[ ! -f "${homedir}"/.config/htop/htoprc ]] && cp /etc/skel/.config/htop/htoprc "${homedir}"/.config/htop/htoprc
File origin for PR:
https://github.com/armbian/build/blob/master/packages/bsp/common/etc/NetworkManager/dispatcher.d/80-update-htop-and-offload-tx

Hi,
 
Thanks to the hard work of your team, the Pine64-plus touchscreen now works great with the mainline kernel and legacy images are no longer listed in the download options, but it looks like some of the instructions at https://www.armbian.com/pine64/
are still referring to the "old way" of doing things:
 
ie:
Pine64’s own LCD with touchscreen support can simply be activated in /boot/armbianEnv.txt by setting pine64_lcd=on and adding gt9xxf_ts to /etc/modules followed by a reboot.
 
The LCD screen is now activated by manipulating the DT overlays, which can even be done from armbian-config - hardware, and the touchscreen module is now called "goodix".
 
 Please can someone find the time to update the instructions on the page?
 
BR.
 
 

I'll continue to help with PBP..   As you all are familiar my work usually comes in bursts..  But yeah i'd like to build kind of a specific community up for it.. almost wonder if its worth a subforum under RK3399 or osmething.

I'm getting a PBP bare motherboard that i can use for the bare metal testing of liek uboot etc... and @Rich Neesehas a PBP coming in the mail
 

You should state in the topic title and in the post in which corner of the globe you life. This can be done with abbreviations like EU, US, ASIA and so on. This will help reduce unnecessary further inquiry of items location. It also also a good idea to state if you are actually looking for or offer something. You can use offer or request in both topic title and posting.  
I tried to create a select box that handles this for you but I have to admit it did not work out as I was expecting it. I may revisit this in future.

Yes, see my comment https://forum.armbian.com/topic/4089-espressobin-support-development-efforts/?do=findComment&comment=110303 After my tests it seems to be stable on 1GHz CPU, but testers are welcome! I'm planning to send a new version of patches.
 
 
 
Do you have a board with 1.2GHz SOC variant? I'm asking because I have not seen Armada3720 SOC with 1.2GHz CPU yet. See my comment https://forum.armbian.com/topic/15059-espressobin-mainline-u-bootatf/?tab=comments#comment-109760 where I wrote how to detect CPU variant.
 

Stumbled across while digging through Github.
https://github.com/sharkdp/bat
 
Its like code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } cat but has syntax highlight and other cool stuff. Nicely they provide arm and arm64 binaries for lazy people

Second link seems ok, I would like to use it to restore backups made by ReaR (https://github.com/rear/rear) made on an orangepipc+ (For some reason rear backup only support the PXE output on arm)

I have a TFTP server set up on a windows computer on the network (with Tftpd64) serving the ReaR backup folder (containing: orangepipcplus.initrd.gz, orangepipcplus.kernel, orangepipcplus.message, rear-orangepipcplus, backup.tar.gz)

What command to use in uboot to load the image on armbian? Would need similar process indicated from https://docs.armbian.com/User-Guide_Recovery/ not sure how to make it match the example above

 

Release planning: January 2nd. Meeting location is IRC channel #armbian on freenode. Meeting starts at 2pm GMT.
 
Open topics / development directions:

- desktop branch merge into the master
- enabling 3D support on desktop(s)
- update u-boot (where possible) to 2020.10 and K5.10.y
- ZSH setting to default or optimise 1st run choosing
- moving blob section (except build packages) to newly created structure inside "desktop" branch (need to discuss best way / adjust framework if needed and set rules!)
- and Jira bugs / features we chose to deal with by then
 
There are reports about some broken images on Rockchip legacy, K5.9.y is EOL so there is an option to squeeze another bugfix update with focus on u-boot / kernel update + image refreshing. Anything that is outside of my test rig - I have no idea about the statue - except well known NIC troubles with Orangepi 3.
 
@Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @Heisath @chwe @ning @lanefu @gprovost @aprayoga @5kft @JMCC @martinayotte @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava

Yes for the next batch we will finally offer board only purchase option ;-)

I am running Linux 5.9.14-mvebu for over 14 days now (up 14 days, 20:12) without any problem.
Thank you very much to all involved tracking down and fixing the issue.

Hi friends. It is not needed anymore. Infact after the first boot I found the CLI version directly!! It is beautifull. By the command: sudo armbian-config, I made the job!!! I installed the wi-fi settings, the italian keyboard and go!!! I don't need desktop software because I would try to create a Cluster over the Armbian layer on four SBC connected in a box!! Thanks! I  love thus way to do: CLI and then if needed Desktop!!!!

Yeah we held back the opi3 to kernel 5.8 but it looks like the download page was accidentally update to 5.9
 
You can find stable images with 5.8 kernel here
 
https://armbian.hosthatch.com/archive/orangepi3/archive/

I don't think the usb_storage module is involved in libusb bulk transfers?  I did try playing around with CPU affinity for the USB interrupts, but it didn't change anything.

I have a ToupTek MU300 USB2 camera that I was trying to get working with my LePotato.
The camera does not have native kernel support, but the manufacturer provides an SDK with a pre-compiled lib for x86/arm, and additionally I have a kernel module which works on X86/X64 with this camera as well as userspace libusb based code to access the camera.
 
The camera is very sensitive to having buffers available during bulk transfer, otherwise the image will be corrupted.  Generally synchronous bulk transfer is not fast enough, and requires multiple buffers supplied in asynchronous mode.
 
On x86-64 and Rpi3/4, everything works as expected.  I can grab images via the vendor supplied SDK as well as with my libusb based code (and on x86-64 the kernel module...which is untested on RPi).
 
However on the amlogic boards I have, the exact same code results in corrupted image frames being returned.  The camera responds properly to control messages, and I do get data via bulk transfer, but the packets are not uniformly sized as they should be, and data is missing (converting the raw data to an image shows broken line alignment, indicating missing data)
 
What I've tried:
Tested 5.9.14 and 4.19 kernels Tested armhf and aarch64 Tested LePotato and ODroid-C4 Tested Kernerl-module, libusb, binary SDK Tested synchronous and asynchronous bulk transfers Tested with powered USB hub as well as directly plugged into SBC Tested with conservative and performance governors  
In all the above cases the camera performs the same way, yet there are no issues on RPi3, RPi4 or X86-64.  I'm not sure what other options I might have to debug.  I'm guessing it is something related to the USB stack, but it must be subtle, since I've seen no issues with other USB devices.  I have looked at the traces in wireshark, and there is nothing obvious (besides that the bulk transfers are not uniformly the correct size)
 
Does anyone have any ideas for other ways I may continue debug?
 

Hi all.
I've just finished a new video where I show how to build Armbian images on your ARM SBC. 
Here is the video.

All have a jolly good Christmas or other holiday or normal day.