lanefu

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. 

I seem to be running around in circles trying to make a decision about a new SBC to add to the herd.
 
The job is currently being done by an OrangePi PC (H3, 1Gb), and is mostly about generating static web sites, which means rendering static HTML/json/js files and uploading them via SCP to a cheap shared hosting provider (the orange pi does not do the actual hosting).
 
This means daily downloading of data from the web (a few hundred MB) and crunching this data to use it for the site. Currently it downloads my country's official covid cases data and generates per-city-daily-cases-per-capita with rolling averages in HTML graphs, this allows easier comparison across time and across cities, of local covid conditions.
 
The Orange Pi PC does it fine. But then I have other projects and I'd prefer to have a separate "production" SBC, so that I can tinker more freely with the "dev SBC" without fear of breaking things. 
 
And then I think: "well, I might as well get a beefier board, you know? Future-proofing!". 
... Perhaps a beefier CPU? That octacore Nano Fire 3 looks interesting, although might be memory bottlenecked.
... Perhaps more durable storage. The USB Stick will die. My recent PC upgrade just freed a 250Gb Samsung 840 SSD that would likely last longer if used for this. (¿Hopefully trim will work through USB?). I don't really *need* USB3 but it'd be nice to get more juice from the SSD.
... Perhaps 2Gb of RAM will last longer, but then again those boards with 2Gb cost twice as much as the 1Gb boards, without bringing twice the cores nor double the MHz.
 
So I see two things:
 
First there's the cost: prices rise quickly for faster CPUs/USB3, and rather sharply with 2Gb.
 
Then, the faster chips seem to run much hotter. The NanoPi Neo 3 looks attractive at first (1 or 2 Gb, USB3) but reviews and forum posts suggest the RK3328 gets really hot even at idle, and throttles down under load/heat (perhaps failing to get the peak promised performance), with everyone adding active cooling and even huge heatsink-cases. Similar things seem to be going for the Fire 3 SBC, the H6 chip, A9....   It's like the faster SBCs gave up on passive cooling.
 
It can be hot here in the tropics: right now at noon it's 29°C, and the OPi is idle at 42°.
 
I really don't want to add active cooling. The allwinner H3 can be "slow", but they are really cool and draw so little power. Meanwhile I don't like the way my RPi3B (a home nas/minidlna) complained if anything less than 2A was fed to it. And I've seen small house Geckos warm up on the RPi, I kid you not!
 
So I end up going full circle and wondering if all I need is just another H3 OrangePi PC.
 
¿Perhaps you guys know of a "faster" SBC that draws under 1A and doesn't throttle at full load with passive cooling?

@jeyjey For supported SBCs the easiest way to get minimal or server-only images of armbian is to setup a own armbian-buil-system
on a 64bit Ubuntu or a VM:
https://docs.armbian.com/Developer-Guide_Build-Preparation/
 
with the armbian-build-system you will have a menu driven selection if you want to create a image for the type minimal, server or desktop
you can select between ubuntu and debian flavour of armbian and the version of ubuntu or debian...as long your SBC is supported by armbian.
 

Hello.
 
@ Igor
I'm sorry if I wasted your time with my first post. That wasn't my intention. I have great respect for the work you are doing here and I am very grateful for that. I can already find out from the article that there is a problem in the kernel so far. I just wanted to confirm that my Orange Pi 3 is the same. That may have been stupid of me. I'm sorry.
 
@ Werner
Thank you for the info!
I'm switching back to a system with kernel level 5.8, and I'm waiting for development.

Thanks, this did the trick for me. A choose manually a mirror and worked.

Hi sorry for the troubles.   I've added some quick documentation on how to manually choose a mirror.   Hopefully this is an easy workaround for the short-term
 
https://docs.armbian.com/User-Guide_Fine-Tuning/#choosing-an-apt-mirror

Good evening,
 
Is it possible to "re-use" the system on SATA ? And how would I do that.
 
I use a HC4 with SD card, a SSD and a HDD 
I flashed the SD card with Armbian_20.11.1_Odroidhc4_buster_current_5.9.12.img.xz
then used armbian-config to Boot from SD - system on SATA.  (sdb2)
also I installed PiHole, OMV ...
 
Due to an power failure the HC4 was not booting anymore.
With a newly flashed SD card its booting again, but of course its not using the system on sdb2 
When using armbian-config it would erase by sdb2 before 
Could I somehow use the system which still should be on sdb2 instead of starting from beginning?
 
thanks for your help
best Regards
Igge

Unfortunately this is not working, 
I changed the rootdev UUID from the current one of mmcblk1p1 to the one of my sdb2 in /boot/armbianEnv.txt using nano.
When I reboot, board is not booting at all now.
 
I will flash the SD card again.

Hi Nico,
thanks for your help. Sorry to answer only now, I needed to wait 24 hours to be able to write again.
 
What you describe is what I did 
blkid showed for /dev/mmcblk1p1: UUID="719e2259-339c-4a64-8012-cdd30ffc7dfc"
 
This UUID was the one mentioned in /boot/armbianEnv.txt
 
And I changed it to the UUID of /dev/sdb2: UUID="bd07f3d4-1caa-443d-b91a-07e4057b41f6"
 
didnt work
 

Name pkg:
linux-image-current-sunxi64_21.02.0-trunk_arm64.deb
What kernel version does this package contain?
Name img:
Armbian_21.02.0-trunk_Orangepipc2_focal_current_5.9.14_minimal.img
In this title you can see everything.
 
I was just asking. I was hoping that someone would remember the reason why they chose this particular style of name.
These package names have been around for quite some time.
@5kft  I assume this is due to reinstalling the package to a new one.
Easy installation instead of the same name. And there is always only one core in the system.
If this is indeed the case, then the best option is to leave the naming as it exists.
For a source package, it doesn't matter.
 
Yesterday I tested the collected images of a minimal system with different cores. All images are working.
The linux-source-5.*.deb, linux-libc-dev-*.deb packages are installed and uninstalled. The problem occurred with linux-headers -*. deb.
I did a clean build on the master. Tomorrow I will watch and make a comparison.

Woohoo, seems like I am one of the winners

@user-2020-12-7,
 
To be honest this has been bothering me ever since your OP.  FWIW I had put this in my own personal issue tracker to follow up on until now.
 
So when some discussion came up today in IRC about this, and another user confirm that it's working again (I specifically ask him about screen), it made me think about this again.
 
I know it's stated in other thread you linked already, but apparently there was some issue with newer kernel, and therefore PineBook A64 was rolled back to legacy (5.4.y) in the meantime, which works well enough apparently.  As I am sure you are aware by now.
 
However I realize your OP was more about the term "Supported" on the download page.  I think misunderstanding may have come from not understanding what "Supported" means in terms of Armbian, so I will try to expand a bit on what has already been written at that link.
 
Supported is a more general and longer term condition, based on a lot of factors mentioned in linked article above.  And so, just because something breaks (even something so important as display on a laptop) does not mean that device suddenly becomes "not Supported."  If situation were impossible, or constant breakage, etc. then that would be a different story.
 
So I hope I help clear that up a bit and again I thank you for your concern and your report.  Cheers!
 
I am taking the liberty to mark my own post as solution in this case.
 
 

In the future we hope to maintain releases by branch, and only apply hot-fixes and cherry pick needed enhancements.  I think that will also minimize risk of unexpected breakages.

In the future we hope to maintain releases by branch, and only apply hot-fixes and cherry pick needed enhancements.  I think that will also minimize risk of unexpected breakages.

Blerg.  The error is telling the truth.  Most likely mirror sync.     Mirror validation is something for us to work on next.

Thanks for your response. I'm only allowed to answer after 24 hours, for some reason.
 
I disabled the log2ram but the log files are still not showing anything interesting. Crash happened on 15th of December around 16:00 and restart was around 19:50.
Here's the relevant section from /var/log/syslog:
 
/var/log/kern.log:
 
Nothing interesting found in /var/log/dmesg.
 
Do you mean connecting via COM/USB? I lose connection if it happens, but I can try.
 
 
Anything else I can do to investigate this? Do you think my device is broken?

Helios64 LAN2 is completely disable thanks to the following commit : https://github.com/armbian/build/commit/6bb68d7ff787614bf0798b2d3fad9883144a9c2d
The mainline kernel r8153 driver doesn't support the vendor ID and product ID used in Helios64, so the interface is completely disable, it's not just losing 2.5Gb speed :-(
 
We didn't see at all this commit, and personally I wasn't aware of the publication of 20.11.3 release, because most probably I'm not following the right thread. Can someone point me out what thread I'm supposed to follow before a new minor release is being pushed ?

You can use armbian-config for this. Check the Freeze option.

I've gotten my Station P1. 
It looks great. I love the metal case. 
There seems to be PCIe GPIO's. Also RTC battery. 

It is sweet. Thank you for informing me about this. 

 

Or is it the other way around?