lanefu

Rock 5b test images, from armbian-next. Using vendor u-boot + patches, and vendor kernel, both straight from radxa's git
 
XFCE desktop with "browsers" app group
- https://github.com/rpardini/armbian-release/releases/download/20220710b/Armbian_20220710b-rpardini_Rock-5b_jammy_legacy_5.10.66_xfce_desktop.img.xz
 
CLI
- https://github.com/rpardini/armbian-release/releases/download/20220710b/Armbian_20220710b-rpardini_Rock-5b_jammy_legacy_5.10.66.img.xz
 
PR: https://github.com/armbian/build/pull/3984 (against master)
All work by @amazingfate I just gathered stuff and built images.
Thanks to @monkaBlyat @lanefu @piter75 @amazingfate for tests / patches etc
 
 

ROCK Pi 5B has been added to upcoming hardware. @rpardini@amazingfate
A few upcoming hardware forums have been "demoted" to sub-forums within News due to lack of activity

Hello everyone!
 
Well, I have been reading through the entire post and trying to learn and apply what I learned for the past few days. In fact, many of the replies by @TheLinuxBugand @guidolhad the answers and solutions I've been looking for. I had this Licheepi thing for over two months now and I struggled a lot to get Ethernet working. Let alone the space constrained PCB that made things very awkward for soldering/de-soldering even for a pin header, though I'm well trained and experienced in soldering/de-soldering fine pitch QFP128 chips. I didn't mind paying a few bucks more to get a PCB that is less constrained and compact like this one.
 
Well, I'm totally new to SBCs and Embedded Linux and I'm coming from another architecture, but I'm now getting more familiar with the build system and toolchain. I got this board because I needed it to control/interface with an ASIC that is fully supported since kernel 3.5. Of course, the communication is done over SPI bus and I have seen several implementations out there utilizing the Licheepi Zero Dock with the ASIC concerned.
 
For the first time ever, I was able to get Ethernet working. Thanks again for this great and helpful post. However, I still have a few questions regarding the adaptation of SPI bus, device trees and overlays support, GPIOs, interrupts, LCD, framebuffer, and adding support for FT5406 touch screen (the one attached to my LCD at the moment).
 
I tried the Debian image with LXDE available here: https://licheepizero.us/. It works fine with my LCD.
Another website I found for Licheepi pre-compiled images, but non of them worked for some reason:
https://sd-card-images.johang.se/boards/lichee_pi_zero.html
 
If someone can help, I would love to hear from you!
 
Thanks
 
 
 
 
 

Hi @Igor,
           I am happy to contribute to the project if it helps. 
Do the maintainers need a Pine RockPro64 with 64Gb eMMC ?
I can order a couple more at the end of the month and send one to the maintainers. just let me know with a DM.
 
I'm also happy to test releases if people want me to, but I spend most of my free time on DE10 Nano and the Pine RocPro64 Pico Clusters I run are mainly to test orchestration toolsets like Ansible and SaltStack and Distributed DB's like Cassandra.
I have a VMWare Server to run RHEL Container platforms like Openshift to test things like Service Discovery Consul and Monitoring with Prometheus/Grafana for proprietary apps. 
That's my background I'm no bootstrap expert (after UEFI I gave up interest in the subject), but I can pick stuff up
I don't check this forum often so somebody would have to reach out to me to be part of a QA Process for that board.  
 
I seem to spend weeks when I am doing a cluster rebuild just testing and trying to find a stable image that is;
 
1). Debian based distro
2). 64bit (arm64)
3). That boots to eMMC.
4). That has a Desktop build for the control plane node that supports attached Nvme Storage
5). That has a CLI build for the worker nodes.
 
Its seems to be a constant problem with these Pine RockPro64 boards.
They are hardly an AliExpress Clone outfit ... Pine are quite well established 🙂 www.pine64.org
 
Let me know how you feel I can contribute 
 

Many do not know, but the correct interpretation of the designation "Armbian" does not come from ARM, but sounds like this. An automated workplace based on ubuntu\debian.
 
 
For those who want to take part in the development of this direction, there is some progress (but this does not mean that it will necessarily be included in the official part of the build system) ....
 
https://forum.armbian.com/topic/21465-armbian-image-and-build-support-for-risc-v/?do=findComment&comment=141582

Since release images are made theoretically a bunch of boards are now to be dropped to CSC since maintainers failed either one or both of these criteria:
https://docs.armbian.com/User-Guide_Board-Support-Rules/
 
However since this is the first release with the new support model and this may not have been clearly enough be communicated it is still to determine if the demotion is enforced this time.

Try to understand the error message correctly. There is an issue with your apt indexes.
https://packages.debian.org/bullseye/bind9-dnsutils
Packages is there upstream.

This is what can be confidently called the most correct part of the algorithm.
 
You've already done everything! Well done!
This is something that I am happy to store in a local folder.
And the ability to extract from the archive to the target folder cache/sources/linux-mainline.
This algorithm will greatly save free space inside the virtual machine.
 
But then the process of creating these archives in the build system is not necessary. It becomes a simple periodic manual work. Update this storage once a month.

IMHO this is "incorrect logic", i.e. this is "implicit" behavior, the concept of ".ignore_changes" needs to be changed to a "normal" variable with "explicit" behavior. I would remove this mechanism altogether, and make a "generally accepted" option for using GIT branches (when switching to any branch, only data from this branch is used, without automatic hidden switching to the master branch). The key ".ignore_changes" should be used in relation to the current changes in the current branch in the form of a service message with a user-only solution.
 
Therefore, I propose to change this "implicit" behavior, it is familiar to those who know the system, but creates problems for beginners who are accustomed to the "generally accepted" ways of using GIT (switched to the branch, which means its code is automatically used).
 

I seem to have made a mistake in my original post. radxa-zero-ubuntu-focal-server-arm64-20220501-0334-mbr is actually a radxa built image and so needs the user and pass to both be rock. It turns out it works fine. I am not sure about the politics between Armbian and DietPi but I hope there is not too much ill will between the two as they have been good projects for me.
 
Also because of the nature of my job, I do not always have extra cash on hand on a regular basis so I cannot be a regular subscriber, but I did make a one time donation today to Armbian via paypal of 100 euros since I happen to have some money at the moment. Hope this helps. I can continue to test new images as they come out and hopefully offer more feedback. Thanks.

Dear all,
 
I occasionally have a full /var/log at startup on various boards, probably because the logs are not rotated /vaccuumd at boot (we had a thread about this in the old opi1 forum). The rotating /vaccuum is currently done every 15 minutes, so I figured why not do it directly at boot as well?
 
For this purpose I updated /etc/cron.d/armbian-truncate-logs with an extra @reboot line:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin */15 * * * * root /usr/lib/armbian/armbian-truncate-logs @reboot root /usr/lib/armbian/armbian-truncate-logs I rebooted several times, and didn't get a full /var/log anymore.
All subsequent problems like failing networking when filesystem full also vanished;-)
 
Kind regards,
Dennis

Ok here's a new version, 5.18-rc7 from tobetter's tree. Still very early days.
tobetter is doing a fantastic job this time around, keeping his tree rebased properly this time.
 
This version has working NVMe (!), panfrost somewhat works, some hangs when panfrost is used.
eMMC does NOT work in my experience, it hangs the machine if trying to use it. use SD card.
 
unzstd, burn to SD, boot either with or without holding the button. (it should NOT go into or through Petitboot either way, instead the SPL in SPI should find and boot uboot in the SD card, or with button boot all blobs from SD).
 
https://github.com/rpardini/armbian-release/releases/download/20220522c/Armbian_20220522c-rpardini_Odroidm1_jammy_edge_5.18.0.img.zst
 
(4.x stuff still does not have HDMI, I've no idea why, it's otherwise stable, but I won't post it here since most people just assume it does not work at all if HDMI does not work)

@Excel I've an image. Unofficial. Unsupported. unzstd it, burn it to SD, put jumper J3 in Maskrom mode, UART at 1500000.
 https://github.com/rpardini/armbian-release/releases/download/20220522c/Armbian_20220522c-rpardini_Tinkerboard_jammy_edge_5.17.9.img.zst (WRONG! That is for the TB1!)
 
UPDATE: https://github.com/rpardini/armbian-release/releases/download/20220522c/Armbian_20220522c-rpardini_Tinkerboard-2_jammy_edge_5.17.9.img.zst (correct for the TB2)
 
Good luck!
 
 
 
Sorry boss, I've all these images laying around and can't help myself. 😉
 
 
 

I will run mvebu tests tomorrow. Sorry for not being available for the meeting, turns out, building a house is a pretty major thing...

thank you!  merged!

I have the same issue and I've tested the script with the --delete option. The change solved my issue. Before I had about 74 MB in /var/log.hdd/journal. After the change and executing the cronjob I have about 7 MB now. So the ramdisk will not be overfilled anymore.
 
I've created a pull request with this small change: https://github.com/armbian/build/pull/3779

@Contributor/Maintainer If something has to be squeezed into the code ... I guess merging armbian-next has to be postponed. After Sunday, bugs bugs bugs. Solving, not generating new ones  

Release is not just freezing the code and generating images. Its a time when we pull together stronger, agree and deal with common goals and ideas. Things we are dealing with are complicated. Linux is complex, our framework is getting there too and only together we can deal with all this.
 
I started on freezing the kernel version. There is also some breakage, some related to our patches, some not. But since we have to freeze it sooner or later, perhaps now its the right time.
 
This brings a few good things at once:
temporally release people that are working close with maintaining kernel code @going@jock@balbes150@amazingfate myself ... this can bring more resources on trying to match with / merge armbian-next. @rpardiniworked for moths on this. Lets review the code and help sorting out bugs. Again. IMHO it is possible to merge, but if code remain unstable by the code freeze date (2022-05-14), we are merging after new images are generated. asking @Contributor/Maintainer board maintainers to engage in images building and testing (currently still from master branch) and bug reporting as earlier as possible (once PR 3736 gets merged) reproducible build framework in release branch. Which is most important long term consequence. Additionally, we would like to finish u-boot upgrade on Rockchip and release major forum refactoring @TonyMac32 @piter75 @balbes150
 
Happy Workers' Day!

Sorry could not make the meeting.  I just read the notes.
 
I am back to work now but locally (almost no travel) so I can have a little time here and there maybe to help with the release somehow.
 
I'll try to hang out in IRC.

FYI, it worked for me:
1. Backup the `/etc/apt/apt.conf.d/02-armbian-compress-indexes`
2. Change `/etc/apt/apt.conf.d/02-armbian-compress-indexes`
```diff
-Acquire::GzipIndexes "true";
+Acquire::GzipIndexes "false";
```
3. `sudo rm -rf /var/lib/apt/lists/*`
4. apt search ...

Was kind a painful to add 70 tags by hand one by one since invision refuses to deal with either spaces, tabs or line-breaks...
anyway all supported boards got their individual tag. in bug tracker forums only those must be chosen, for some other forums tags are open but supported board tags are marked as recommended.

@private/contributor 
 
Unifying TAGS as much as possible - as low count / universal as possible has been enforced to GitHub merge requests and issues. From now on, we have only 12 labels:


 

Ban is still in place  I am writing an email right now. In general it would be better to use Google mirror primarily. Or we need to use kernel.org Git for bundles?
 

You mean like having our own full kernel mirror?
 

I would not push on moving everything to distro compilers at once. What works, works and we do this gradually. Going on half now, removing them all in one year. Something like that. Even today, sometimes we will need to deal with a special compiler, so support has to remain. And a few of them if there is too much work with adopting the code.

Thanks for update. Will do another cycle of review when possible.

Or I guess Balbes support is free and easy.    
 
Note this is balbes and not official support status

Since you can’t always rely on single board computer (SBC) vendors to provide a case to match your needs, some went the DIY route. William Tarreau designed some laser-cut enclosures with Inkscape for various SBCs, while hominoids went a step further by developing the “SBC Case Builder” tool to automatically generate various types of 3D printable enclosures using OpenSCAD. William designed five similar enclosures for Khadas VIM3/VIM3L, FriendlyELEC NanoPi Fire3, SolidRun Clearfog Base networking SBC, Libre Computer AML-S805X-AC (aka “La Frite”), and AAEON UP Board. All cases are available in Inkscape SVG format, and William accepts contributions for other boards. You’ll need a laser engraver or CNC router to cut out those enclosures. Hominoids’ SBC Case Builder project attempt to automatize enclosure generation for SBCs using SBC Model Framework written in OpenSCAD. Work has focused on ODROID boards so far, but it should work for other vendors too. The parameters [...]
The post DIY SBC cases and SBC Case Builder tool based on OpenSCAD appeared first on CNX Software - Embedded Systems News.
View the full article